Qual é a diferença entre o ciclo NIST SP 800-61 e o modelo PICERL do SANS?

O NIST SP 800-61 organiza a resposta em quatro fases: Preparação; Detecção e Análise; Contenção, Erradicação e Recuperação; e Atividade Pós-Incidente. O PICERL do SANS segmenta a terceira fase em etapas menores — Preparação, Identificação, Contenção, Erradicação, Recuperação e Lições Aprendidas — oferecendo granularidade operacional maior. Na prática, as duas abordagens são complementares: o NIST fornece a estrutura de governança, e o PICERL orienta o time técnico durante a crise.

Em quanto tempo uma empresa deve notificar a ANPD após um incidente envolvendo dados pessoais?

A LGPD (Lei 13.709/2018) e a Resolução CD/ANPD nº 15/2024 determinam que o controlador comunique a ANPD e os titulares afetados em até 3 dias úteis a partir da ciência do incidente, quando houver risco ou dano relevante. A notificação deve descrever a natureza dos dados, o número de titulares afetados, as medidas de contenção adotadas e o nome do Encarregado (DPO). Atrasos injustificados configuram infração sujeita a sanções administrativas.

O que é MTTD e MTTR e por que essas métricas importam?

MTTD (Mean Time to Detect) é o tempo médio entre o início de um incidente e sua detecção; MTTR (Mean Time to Respond) é o tempo médio entre a detecção e a contenção ou resolução. Essas métricas quantificam a maturidade do programa de resposta: um MTTD alto indica falhas de monitoramento ou cobertura de logs insuficiente; um MTTR alto aponta gargalos de playbook, falta de automação ou estrutura de decisão lenta. Benchmarks do setor (IBM Cost of a Data Breach 2024) registram MTTD médio global de 194 dias — organizações com SIEM e SOAR maduros reduzem esse número para menos de 30 dias.

Quando vale contratar um retainer de IR em vez de montar equipe interna?

Equipes internas oferecem contexto do ambiente e resposta imediata, mas exigem investimento contínuo em treinamento, ferramentas e retenção de talentos — inviável para a maioria das PMEs. Um retainer de IR garante acesso a especialistas multidisciplinares (forense, threat hunting, jurídico, comunicação) acionáveis 24x7 mediante SLA contratual, frequentemente com custo menor do que um único analista sênior. O modelo híbrido — coordenador interno + retainer externo — é o mais adotado por empresas médias no Brasil.

Quais playbooks são obrigatórios em um programa mínimo de resposta a incidentes?

Um programa mínimo deve cobrir: (1) ransomware e extorsão dupla; (2) comprometimento de credenciais e tomada de conta (ATO); (3) vazamento ou exfiltração de dados; (4) ataque de negação de serviço (DDoS); (5) comprometimento de e-mail corporativo (BEC/EAC); (6) acesso não autorizado a sistemas críticos. Cada playbook deve conter gatilhos de acionamento, árvore de decisão, contatos de escalonamento, evidências a preservar e critérios de encerramento.

Ferramentas de IR substituem consultoria especializada?

Não. SIEM, EDR, SOAR e plataformas forenses reduzem tempo de detecção e automatizam tarefas repetitivas, mas não substituem julgamento humano em situações de alta incerteza — como atribuição de ameaça, decisão de isolamento de sistemas críticos em produção ou negociação com agentes de ransomware. Ferramentas mal calibradas geram volume de alertas sem contexto (alert fatigue) e podem dar falsa sensação de segurança. O investimento em tecnologia deve acompanhar investimento proporcional em pessoas e processos.

Resposta a Incidentes: ciclo, equipe e ferramentas

Ciclo NIST SP 800-61, modelo PICERL, papéis do CSIRT, playbooks por ameaça, MTTD/MTTR, ferramentas SIEM/EDR/SOAR e obrigações LGPD na resposta a incidentes.

Resposta a incidentes (IR, do inglês incident response) é o conjunto de processos, papéis e ferramentas que uma organização aciona quando um evento de segurança ameaça a confidencialidade, integridade ou disponibilidade dos seus sistemas. Um programa de IR maduro reduz o impacto financeiro e reputacional, preserva evidências para análise forense e cumpre obrigações regulatórias — como a notificação à ANPD exigida pela LGPD.

O que caracteriza um incidente de segurança

Nem todo evento de segurança é um incidente. Um evento é qualquer ocorrência observável — um login falhado, um port scan externo — enquanto um incidente é um evento que efetivamente viola ou ameaça violar políticas de segurança, acordos de uso aceitável ou práticas de segurança padrão (NIST SP 800-61r2, 2012). Exemplos clássicos incluem: ransomware em execução, exfiltração de dados de clientes, comprometimento de credenciais privilegiadas, defacement de site e ataques DDoS que afetam operações.

A classificação por severidade — tipicamente P1 (crítico, impacto imediato ao negócio) a P4 (baixo, sem impacto operacional) — determina a velocidade e o nível de escalada da resposta. Equipes que não classificam incidentes no momento da detecção desperdiçam os primeiros minutos críticos tentando decidir quem acionar.

Ciclo NIST SP 800-61: as quatro fases

O Computer Security Incident Handling Guide do NIST organiza a resposta em quatro fases cíclicas. A natureza cíclica é intencional: cada incidente alimenta a preparação para o próximo.

1. Preparação

A fase mais negligenciada — e a mais determinante. Envolve inventário de ativos críticos, elaboração de playbooks por tipo de ameaça, estabelecimento de canais de comunicação de crise, aquisição de ferramentas (SIEM, EDR, solução forense) e realização de exercícios de tabletop. Organizações que investem em preparação reduzem o MTTD em até 60%, segundo o Verizon Data Breach Investigations Report. Preparação também inclui relações com fornecedores externos — advogados especializados em cyber, assessoria de comunicação de crise e a própria equipe de retainer de IR.

2. Detecção e análise

A detecção ocorre por monitoramento contínuo (SIEM correlacionando eventos de múltiplas fontes), por alerta de terceiros (cliente, parceiro, pesquisador de segurança) ou por descoberta acidental. A análise vai além de confirmar que algo aconteceu: exige determinar o escopo (quais sistemas, quais dados, qual período), o vetor inicial e o nível de comprometimento. Nesta fase preservam-se evidências — logs, capturas de memória volátil, imagens de disco — seguindo cadeia de custódia rigorosa para uso em processos judiciais ou regulatórios.

3. Contenção, erradicação e recuperação

A contenção de curto prazo (isolar um endpoint, bloquear um IP, revogar uma credencial) deve ser feita sem destruir evidências. A contenção de longo prazo mantém sistemas comprometidos operando de forma controlada enquanto a erradicação é preparada — útil quando o isolamento imediato causaria impacto operacional crítico. A erradicação remove artefatos maliciosos, fecha vulnerabilidades exploradas e valida a limpeza com varredura pós-erradicação. A recuperação restaura sistemas a partir de backups íntegros e monitora reinfecção nas primeiras 72 horas.

4. Atividade pós-incidente

A revisão pós-incidente (PIR ou lessons learned) deve ocorrer dentro de 5 dias úteis do encerramento. O objetivo não é apontar culpados, mas documentar linha do tempo, causa raiz, o que funcionou, o que falhou e melhorias com responsável e prazo definidos. Organizações que pulam o PIR repetem os mesmos erros — e os mesmos incidentes.

Modelo PICERL do SANS: granularidade operacional

O SANS Institute popularizou o modelo PICERL, que divide a resposta em seis etapas: Preparation, Identification, Containment, Eradication, Recovery e Lessons Learned. Em relação ao NIST, o PICERL separa explicitamente a identificação (confirmação e classificação do incidente) da contenção, o que é útil em ambientes de grande complexidade onde a análise inicial pode levar horas. As duas estruturas são complementares: o NIST orienta a governança do programa; o PICERL guia o analista durante a crise.

Papéis e estrutura do CSIRT

Um Computer Security Incident Response Team (CSIRT) eficiente distribui responsabilidades claras para evitar paralisia decisória durante a crise.

Comandante do incidente (IC): coordena todas as atividades, toma decisões de escalonamento e mantém o registro cronológico (war room log). Não precisa ser o analista mais técnico — precisa ser o melhor comunicador sob pressão.
Analistas técnicos: executam detecção, forense, contenção e erradicação. Em times pequenos, um analista pode acumular funções; em incidentes P1, é recomendável separar análise de forense e contenção operacional.
Jurídico: avalia obrigações de notificação (LGPD, BACEN, CVM), orienta sobre preservação de evidências para litígio e gerencia comunicação com autoridades.
Comunicação e relações públicas: prepara mensagens para clientes, imprensa e reguladores. A ausência desse papel em incidentes com exposição pública é uma das causas mais frequentes de dano reputacional amplificado.
Gestor de negócio: toma decisões que envolvem trade-off entre segurança e continuidade operacional — como decidir se um sistema crítico deve ser isolado imediatamente ou monitorado por mais tempo.
Encarregado de dados (DPO): obrigatório pela LGPD; avalia se dados pessoais foram expostos e coordena a notificação à ANPD e aos titulares.

Playbooks por tipo de incidente

Um playbook é um procedimento passo a passo para um tipo específico de incidente. Playbooks de qualidade reduzem o tempo de resposta, diminuem erros sob pressão e permitem que analistas menos experientes conduzam a resposta inicial com segurança. Os tipos essenciais são:

Ransomware e extorsão dupla: isolamento imediato, preservação de evidências, avaliação de backups, decisão sobre pagamento (jurídico + C-level), comunicação regulatória.
Comprometimento de credenciais / ATO: identificação do escopo de acesso, revogação de sessões, reset forçado, revisão de MFA, investigação de movimentação lateral.
Vazamento de dados: identificação do volume e natureza dos dados, mapeamento de titulares afetados, acionamento do DPO, notificação ANPD em 3 dias úteis.
DDoS: acionamento de mitigação (CDN/scrubbing center), avaliação de impacto operacional, comunicação com ISP, monitoramento pós-ataque para variantes.
BEC/EAC (fraude por e-mail corporativo): bloqueio de conta comprometida, rastreamento de transações financeiras, acionamento do banco em até 1 hora para reversão, comunicação jurídica.
Acesso não autorizado a sistemas críticos: análise de logs de acesso, identificação de alterações em configurações ou dados, avaliação de backdoors persistentes.

Métricas de maturidade: MTTD e MTTR

Duas métricas são universalmente adotadas para medir a eficiência do programa de IR:

Métrica	Definição	Referência (IBM 2024)	Meta madura
MTTD	Tempo médio entre início do incidente e sua detecção	194 dias (global)	Menos de 30 dias
MTTR	Tempo médio entre detecção e contenção/resolução	64 dias (global)	Menos de 7 dias (P1)

Além dessas, programas maduros acompanham volume de incidentes por severidade por mês, taxa de falsos positivos no SIEM, cobertura de playbooks (% de tipos de incidente com playbook documentado) e tempo de notificação regulatória.

Ferramentas essenciais de IR

Nenhuma ferramenta substitui processo e pessoas, mas a ausência de tecnologia adequada limita severamente a capacidade de resposta em escala.

SIEM (Security Information and Event Management): agrega e correlaciona logs de múltiplas fontes em tempo real. Exemplos: Microsoft Sentinel, Splunk, IBM QRadar, Elastic SIEM. A eficácia depende da qualidade das regras de correlação e da cobertura de fontes de dados.
EDR/XDR (Endpoint/Extended Detection and Response): visibilidade profunda em endpoints com capacidade de isolamento remoto, coleta forense e resposta automatizada. Exemplos: CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint.
SOAR (Security Orchestration, Automation and Response): automatiza fluxos de trabalho repetitivos — enriquecimento de alertas, notificações, criação de tickets — e integra ferramentas díspares em playbooks executáveis. Reduz MTTR ao eliminar tarefas manuais de baixo valor.
Plataformas forenses: permitem aquisição e análise de memória volátil (Volatility), imagens de disco (FTK, Autopsy, Axiom) e análise de tráfego de rede (Wireshark, Zeek). Essenciais para atribuição e preservação de evidências com cadeia de custódia.
Threat intelligence: feeds de IoCs (indicadores de comprometimento), plataformas como MISP ou OpenCTI, e inteligência tática sobre TTPs (MITRE ATT&CK) orientam a investigação e reduzem o tempo de análise.
Plataforma de gestão de incidentes: registra cronologia, atribuição de tarefas, evidências e comunicações em um único local auditável. Pode ser um sistema dedicado (PagerDuty, TheHive) ou integrado ao SOAR.

IR interno versus retainer externo

A decisão entre construir uma equipe interna de IR ou contratar um retainer externo depende de porte, regulação e perfil de risco. Equipes internas têm contexto do ambiente, acesso imediato a sistemas e capacidade de resposta sub-hora — mas exigem investimento contínuo em salários, ferramentas, treinamento e retenção. O mercado brasileiro apresenta escassez crônica de analistas de IR sênior, tornando essa equação desfavorável para empresas abaixo de 500 colaboradores.

Um retainer de IR contratado com SLA garante acesso a especialistas multidisciplinares — forense digital, threat hunting, jurídico cyber, comunicação de crise — sem o custo fixo de uma equipe dedicada. O modelo mais eficiente para médias empresas é o híbrido: um coordenador interno de segurança que conhece o ambiente e mantém a operação cotidiana, com retainer externo acionável 24x7 para incidentes P1 e P2.

Obrigações regulatórias no Brasil

A resposta a incidentes no Brasil opera sob um conjunto crescente de obrigações legais que determinam prazos e destinatários das notificações:

LGPD / ANPD (Resolução CD/ANPD nº 15/2024): incidentes que envolvam dados pessoais com risco ou dano relevante aos titulares devem ser comunicados à ANPD e aos titulares em até 3 dias úteis da ciência do incidente. A comunicação deve incluir natureza dos dados, número de titulares, medidas de contenção e dados do DPO.
Banco Central (Resolução BCB nº 85/2021 e Circular nº 3.909): instituições financeiras reguladas pelo BACEN devem notificar incidentes relevantes em até 72 horas e adotar Política de Segurança Cibernética com plano de IR documentado e testado.
ANATEL: prestadoras de telecomunicações seguem regulamento específico para incidentes que afetam a continuidade ou confidencialidade dos serviços.
ISO/IEC 27035: norma internacional que estrutura o processo de gestão de incidentes de segurança da informação, complementar ao NIST SP 800-61 e adotada como referência em auditorias de conformidade ISO 27001.

Organizações que operam em múltiplos setores regulados devem mapear todas as obrigações aplicáveis no plano de IR — o não cumprimento dos prazos de notificação, independentemente da qualidade técnica da resposta, configura infração autônoma.

Referências

NIST SP 800-61 Revision 2 — Computer Security Incident Handling Guide (2012), National Institute of Standards and Technology.
SANS Institute — Incident Handler's Handbook, Patrick Kral (2011).
ISO/IEC 27035-1:2023 — Information technology — Information security incident management.
IBM Security — Cost of a Data Breach Report 2024.
ANPD — Resolução CD/ANPD nº 15, de 24 de abril de 2024.
MITRE ATT&CK Framework — Adversarial Tactics, Techniques, and Common Knowledge, versão 15.

Perguntas frequentes

Qual é a diferença entre o ciclo NIST SP 800-61 e o modelo PICERL do SANS?: O NIST SP 800-61 organiza a resposta em quatro fases: Preparação; Detecção e Análise; Contenção, Erradicação e Recuperação; e Atividade Pós-Incidente. O PICERL do SANS segmenta a terceira fase em etapas menores — Preparação, Identificação, Contenção, Erradicação, Recuperação e Lições Aprendidas — oferecendo granularidade operacional maior. Na prática, as duas abordagens são complementares: o NIST fornece a estrutura de governança, e o PICERL orienta o time técnico durante a crise.
Em quanto tempo uma empresa deve notificar a ANPD após um incidente envolvendo dados pessoais?: A LGPD e a Resolução CD/ANPD nº 15/2024 determinam que o controlador comunique a ANPD e os titulares afetados em até 3 dias úteis a partir da ciência do incidente, quando houver risco ou dano relevante. A notificação deve descrever a natureza dos dados, o número de titulares afetados, as medidas de contenção adotadas e o nome do Encarregado (DPO). Atrasos injustificados configuram infração sujeita a sanções administrativas.
O que é MTTD e MTTR e por que essas métricas importam?: MTTD (Mean Time to Detect) é o tempo médio entre o início de um incidente e sua detecção; MTTR (Mean Time to Respond) é o tempo médio entre a detecção e a contenção ou resolução. Essas métricas quantificam a maturidade do programa de resposta: um MTTD alto indica falhas de monitoramento ou cobertura de logs insuficiente; um MTTR alto aponta gargalos de playbook, falta de automação ou estrutura de decisão lenta. Benchmarks do setor (IBM Cost of a Data Breach 2024) registram MTTD médio global de 194 dias — organizações com SIEM e SOAR maduros reduzem esse número para menos de 30 dias.
Quando vale contratar um retainer de IR em vez de montar equipe interna?: Equipes internas oferecem contexto do ambiente e resposta imediata, mas exigem investimento contínuo em treinamento, ferramentas e retenção de talentos — inviável para a maioria das PMEs. Um retainer de IR garante acesso a especialistas multidisciplinares acionáveis 24x7 mediante SLA contratual, frequentemente com custo menor do que um único analista sênior. O modelo híbrido — coordenador interno + retainer externo — é o mais adotado por empresas médias no Brasil.
Quais playbooks são obrigatórios em um programa mínimo de resposta a incidentes?: Um programa mínimo deve cobrir: (1) ransomware e extorsão dupla; (2) comprometimento de credenciais e tomada de conta (ATO); (3) vazamento ou exfiltração de dados; (4) ataque de negação de serviço (DDoS); (5) comprometimento de e-mail corporativo (BEC/EAC); (6) acesso não autorizado a sistemas críticos. Cada playbook deve conter gatilhos de acionamento, árvore de decisão, contatos de escalonamento, evidências a preservar e critérios de encerramento.
Ferramentas de IR substituem consultoria especializada?: Não. SIEM, EDR, SOAR e plataformas forenses reduzem tempo de detecção e automatizam tarefas repetitivas, mas não substituem julgamento humano em situações de alta incerteza — como atribuição de ameaça, decisão de isolamento de sistemas críticos em produção ou negociação com agentes de ransomware. Ferramentas mal calibradas geram volume de alertas sem contexto (alert fatigue) e podem dar falsa sensação de segurança. O investimento em tecnologia deve acompanhar investimento proporcional em pessoas e processos.

Como a Decripte atua em resposta a incidentes

A Decripte oferece resposta a incidentes 24x7 e forense digital para organizações de 1 a mais de 100.000 colaboradores. Nossa equipe combina analistas de IR, especialistas em forense, jurídico cyber e comunicação de crise — acionáveis em minutos via retainer ou contrato avulso. Atuamos em contenção imediata, análise de causa raiz, preservação de evidências com cadeia de custódia, notificação regulatória (LGPD/ANPD, BCB) e revisão pós-incidente com plano de melhoria. Para empresas que querem estar prontas antes do incidente acontecer, oferecemos o plano de Resposta a Incidentes com preparação, testes de tabletop e acesso prioritário à equipe. Conheça o plano de Resposta a Incidentes ou comece gratuitamente com o Plano de Ameaças.