pular para o conteúdo
voltar ao mapa
conceito
etapa: prepare
2 min de leitura

O ciclo de vida da resposta a incidentes

O momento de um incidente não é hora de inventar um processo. As equipes que respondem bem definiram papéis, níveis de severidade e canais de comunicação muito antes de algo quebrar.

NIST SP 800-61PagerDuty / OpsgenieSlack or Teams incident channelticketing and case managementTheHiverunbooks in version control

As fases

O guia de tratamento de incidentes do NIST descreve um ciclo que a maioria dos programas adota de alguma forma. Trate-o como um laço, não como uma linha: o que você aprende alimenta a preparação.

  • Preparação: política, escala de plantão, ferramentas e acessos prontos, logging que responde perguntas, playbooks praticados, listas de contatos (jurídico, comunicação, fornecedores, reguladores).
  • Detecção e análise: reconhecer que algo está errado, decidir se é um incidente, delimitar o escopo e atribuir uma severidade.
  • Contenção: impedir que se espalhe ou piore, com a menor interrupção que funcione, preservando as evidências.
  • Erradicação e recuperação: remover o acesso do atacante e a causa, restaurar os sistemas a partir de um estado confiável e acompanhar de perto à medida que voltam ao ar.
  • Atividade pós-incidente: uma , lições aprendidas e mudanças em detecção, controles e playbooks.

Papéis e comunicação

  • : é dono da resposta, toma as decisões e não faz o trabalho técnico.
  • Líderes técnicos: investigam e contêm, um por frente de trabalho (endpoint, identidade, nuvem, rede).
  • Comunicação: atualizações internas em horários fixos e mensagens externas a clientes, parceiros e reguladores, aprovadas pelo jurídico.
  • Escriba: mantém uma linha do tempo, com timestamps em UTC, do que foi visto e feito e por quem.
  • Use um canal como fonte da verdade e um canal fora de banda caso o principal esteja comprometido.

Severidade e um registro

Combine os níveis de severidade com antecedência para que ninguém discuta sobre eles durante o evento, e abra um registro no momento em que declarar o incidente.

incident-record.ymlyaml
id: INC-2026-0142
declared_at: 2026-10-13T14:05:00Z      # sempre em UTC
severity: SEV2                          # SEV1 dados de clientes ou queda do núcleo; SEV2 contido mas grave; SEV3 menor
commander: a.silva
summary: Logins suspeitos no console de administração vindos de um país novo
scope:
  affected: [identity-provider, admin-console]
  data_at_risk: none confirmed
timeline:
  - { at: 2026-10-13T13:52:00Z, event: "Alert fired: impossible travel", by: detection }
  - { at: 2026-10-13T14:05:00Z, event: "Incident declared", by: a.silva }
next_update: 2026-10-13T15:00:00Z

Princípios que valem em todo incidente

  • Preserve as evidências antes de mudar as coisas: faça snapshots, copie logs, registre o que você fez.
  • Contenha de forma proporcional: desligar a produção às vezes é certo e muitas vezes é exagero.
  • Assuma que o atacante está observando: não anuncie o plano no canal que ele pode estar lendo.
  • Decida com informação incompleta e atualize conforme os fatos chegam.
  • Anote enquanto avança; a memória sob estresse não é confiável.
  • Pratique com exercícios de mesa para que a primeira vez não seja a real.
Postmortemrevisão sem culpadosUma revisão escrita de um incidente que pergunta como o sistema permitiu o problema, e não quem errou, e termina com ações que têm responsável.ver no glossário →Comandante do incidenteICA pessoa que é dona da resposta e toma as decisões, enquanto os outros fazem o trabalho técnico. Manter esses papéis separados evita que o líder desapareça nos detalhes técnicos.ver no glossário →

conexões no mapa

atualizado em 14/10/2026 · fontes para aprofundar · reportar erro

em outros domínios

Desbloqueia

teste o que entendeu

Carregando perguntas…