Um incidente raramente começa com certeza. Pode surgir como alerta, relato de usuário, comportamento fora do padrão ou falha operacional. O desafio inicial é tomar decisões úteis sem apagar o contexto que permitirá entender o que aconteceu.
Este artigo organiza os primeiros passos — da triagem à contenção — e explica por que a ordem das ações importa tanto quanto as ações em si.
Antes: evento, evento adverso e incidente
Três palavras que parecem sinônimas e não são. O NIST as separa com precisão, e a distinção evita tratar ruído como crise:
- Evento: qualquer ocorrência observável em um sistema. Uma tentativa de login é um evento.
- Evento adverso: um evento com consequência negativa, de qualquer causa — inclusive falha de energia ou erro operacional.
- Incidente: uma ocorrência que efetivamente ou iminentemente compromete a integridade, a confidencialidade ou a disponibilidade de uma informação ou sistema; ou viola políticas de segurança.
A consequência prática: um alerta é um evento até que a análise o promova a incidente. Declarar incidente cedo demais mobiliza pessoas sem necessidade; declarar tarde demais custa tempo de contenção. A triagem existe exatamente para tomar essa decisão com base em evidência.
O modelo mudou: do ciclo de quatro fases às seis funções
Quem estudou resposta a incidentes provavelmente aprendeu o ciclo de quatro fases da revisão anterior do NIST: preparação → detecção e análise → contenção, erradicação e recuperação → atividade pós-incidente.
A revisão 3 do SP 800-61, publicada em abril de 2025, abandonou esse modelo. O documento explica o motivo: quando o ciclo foi criado, incidentes eram relativamente raros, de escopo estreito e resolvidos em um ou dois dias — o que tornava realista tratar a resposta como um conjunto separado de atividades, feito por uma equipe separada. Hoje incidentes são frequentes, a recuperação leva semanas ou meses, e as lições aprendidas precisam circular assim que aparecem, não depois que a recuperação termina.
O modelo atual organiza a resposta pelas seis Funções do CSF 2.0:
| Função | Papel na resposta |
|---|---|
| Govern | Define papéis, políticas e critérios de decisão — antes do incidente |
| Identify | Conhece ativos, riscos e o que é crítico |
| Protect | Reduz a chance e o impacto de incidentes |
| Detect | Descobre atividade adversa |
| Respond | Contém, erradica, comunica e gerencia |
| Recover | Restaura e valida o retorno à operação |
Governar, Identificar e Proteger são contínuas e envolvem toda a organização; Detectar, Responder e Recuperar entram em ação no incidente. A mudança de fundo é conceitual: resposta a incidentes deixou de ser um processo isolado e passou a ser parte da gestão de risco, integrada às operações.
Na prática, o que segue abaixo continua valendo em qualquer modelo. Se a sua organização usa o ciclo de quatro fases, ele não está errado — o próprio NIST diz que cada organização deve usar o modelo que melhor a atende.
Primeiro, registre o que você sabe
Anote horário com fuso, origem do alerta, ativo envolvido, pessoas acionadas e ações já tomadas. Preserve identificadores relevantes: conta, host, endereço de origem, sessão e eventos correlatos. Essa linha do tempo evita que a investigação dependa de memória ou de mensagens dispersas em um chat.
Um registro útil separa três colunas:
| Horário (UTC) | Observação | Classificação |
|---|---|---|
| 14:02 | Login de j.silva a partir de ASN não habitual | Fato |
| 14:03 | MFA aprovado na primeira tentativa | Fato |
| 14:05 | Conta possivelmente comprometida | Hipótese |
| 14:07 | Verificar se há novo método de MFA registrado | Próximo teste |
“A conta pode estar comprometida” é diferente de “a conta foi usada por um terceiro”. Separar fato, interpretação e próximo teste melhora a comunicação com quem decide o risco — e evita que uma hipótese vire conclusão por repetição.
Defina o impacto e a urgência
Pergunte quais sistemas e dados podem estar envolvidos, se há atividade em andamento e qual seria o efeito de esperar. A prioridade não deve depender do volume do alerta: uma ocorrência rara em um sistema crítico pode exigir ação antes de uma sequência barulhenta em um ambiente de baixo risco.
Critérios que sustentam a decisão:
- criticidade do ativo — o que para se ele parar;
- privilégio da conta — o que ela alcança além de si mesma;
- exposição de dados — natureza e volume;
- persistência — há indício de acesso mantido?
- propagação — pode alcançar outros sistemas?
Se esses critérios não existirem na organização, registre a lacuna para o processo ser melhorado depois — e decida com o que tem, documentando o raciocínio.
Contenha sem destruir a investigação
Às vezes é necessário revogar uma sessão, desabilitar uma conta, isolar uma máquina ou bloquear um indicador. A ação deve reduzir o risco imediato e ser proporcional à confiança da evidência.
A ordem importa. Em um host suspeito, coletar antes de desligar preserva o que só existe em memória:
- Isole a rede antes de mexer no host — interrompe o acesso sem apagar estado.
- Preserve a memória volátil, se houver capacidade, antes de qualquer reinício.
- Colete os registros que sustentam a decisão, incluindo os que podem rotacionar em breve.
- Depois execute a contenção mais invasiva.
Desligar uma máquina apaga processos em execução, conexões abertas e, com frequência, a evidência que explicaria como o acesso aconteceu. Reiniciar “para limpar” é a forma mais comum de destruir a investigação com boa intenção.
Evite ações amplas por reflexo. Quando o risco exigir contenção rápida e não houver tempo de coletar, documente quem decidiu, por quê e o que deixou de ser coletado — essa anotação vale mais do que parece na revisão posterior.
Coordene comunicação e recuperação
Defina quem atualiza as partes envolvidas, com que frequência e por qual canal. Se há suspeita de comprometimento do ambiente corporativo, considere um canal fora dele: discutir a resposta em um sistema que o atacante pode estar lendo é um erro caro.
Comunicação clara não exige detalhes técnicos desnecessários. Um formato que funciona: impacto atual · ação em curso · decisão pendente · próximo horário de atualização. O último item reduz a maior fonte de ruído em um incidente, que é gente perguntando se há novidade.
Depois da contenção, trate a causa que permitiu o incidente e confirme que a recuperação funciona. Uma correção só está completa quando é possível verificar que o comportamento não se repete e que os controles de detecção continuam úteis.
Feche o ciclo
Produza uma revisão curta: linha do tempo, impacto, evidências, decisões, melhorias e responsáveis. O objetivo não é apontar culpados; é tornar a organização mais capaz de reconhecer e responder ao próximo sinal relevante.
Duas perguntas que rendem mais que um relatório longo:
- O que nos fez perceber? Se foi um usuário e não a detecção, há uma lacuna de telemetria a corrigir.
- O que nos atrasou? Falta de acesso, de contato, de registro ou de critério — cada uma tem uma correção diferente.
Seguindo o modelo atual, essas lições devem ser compartilhadas assim que aparecem, não guardadas para um relatório final semanas depois.
Próximo passo
Você não precisa de um incidente para exercitar isso. Escolha um alerta recente do seu ambiente — mesmo um falso positivo — e escreva a linha do tempo de três colunas para ele. O exercício revela em minutos quais campos de log faltam, quem você não sabia acionar e qual critério de prioridade não existe por escrito.
Em situações reais, os procedimentos da organização, obrigações legais e responsáveis designados devem prevalecer. Este roteiro serve para preparar e raciocinar, não para substituir um plano de resposta aprovado. Pratique apenas em ambientes próprios ou com autorização explícita.
