Governança de incidentes: decida antes da contenção

Uma equipe pode detectar uma intrusão e ainda assim perder tempo decisivo se ninguém souber quem autoriza o isolamento, a revogação de credenciais ou a comunicação ao público. O problema afeta organizações de qualquer porte que dependem de sistemas digitais, sobretudo quando tecnologia, jurídico, privacidade e direção operam com informações diferentes. A ação prioritária é estabelecer autoridade, critérios de escalonamento e um registro comum antes da próxima crise.

O objetivo não é criar um manual extenso que ficará esquecido numa pasta. É transformar sinais técnicos em decisões rastreáveis. Um alerta de autenticação suspeita, uma alteração inesperada numa regra de rede ou uma indisponibilidade podem ter causas distintas. A equipe precisa avançar sem declarar uma violação antes de haver evidência suficiente, mas também sem esperar uma certeza impossível para conter uma ameaça.

O problema é decisório

Na prática, a resposta costuma travar em três pontos. O analista vê atividade anormal, mas não tem autorização para interromper o serviço. O gestor do negócio teme a indisponibilidade e pede mais confirmação. A área jurídica ou de privacidade só é chamada quando alguém já começou a preparar uma mensagem externa. Esse intervalo cria duas exposições: o atacante pode continuar atuando e a organização pode perder a oportunidade de preservar dados relevantes.

Uma resposta integrada ao risco trata a preparação, a detecção, a resposta e a recuperação como partes do programa de segurança, e não como uma operação isolada do time de infraestrutura. O NIST SP 800-61 Rev. 3 recomenda incorporar considerações de resposta a incidentes às atividades de gestão de riscos de cibersegurança. A consequência operacional é clara: autoridade e recursos precisam ser definidos durante a rotina, quando há tempo para negociar limites e substitutos.

O primeiro artefato deve ser uma matriz simples de decisão. Para cada ação, indique o responsável primário, o substituto, a condição que permite agir, o impacto esperado e quem deve ser informado. O responsável por identidade pode revogar uma sessão comprometida. O líder técnico pode isolar um equipamento. A direção pode aceitar a interrupção de uma aplicação essencial. A área de privacidade avalia a exposição de dados pessoais, enquanto o jurídico orienta preservação de provas, contratos e comunicações obrigatórias.

Defina autoridade antes

O plano deve funcionar mesmo quando o ambiente corporativo estiver degradado. Contatos, cópias de procedimentos e canais alternativos não podem depender exclusivamente do e-mail, do chat ou do armazenamento que pode estar sob investigação. A CISA descreve o plano de resposta como um documento escrito, aprovado formalmente pela liderança, que orienta a organização antes, durante e depois de um incidente confirmado ou suspeito.

Um plano aprovado pela liderança também reduz o risco de decisões contraditórias. A aprovação não deve ser apenas uma assinatura anual. Ela precisa confirmar que as pessoas nomeadas têm autoridade real, que os substitutos foram informados e que o negócio aceita os efeitos de determinadas medidas. Se desligar uma integração puder interromper faturamento, por exemplo, essa consequência deve aparecer no procedimento, junto com a pessoa que pode autorizar a ação.

Separe os níveis de resposta. Um evento de baixo impacto pode ser tratado pelo fluxo operacional. Uma conta administrativa suspeita, a alteração de controles de segurança, a exposição de informações pessoais ou a indisponibilidade de um serviço essencial devem subir para uma célula de crise. O critério não deve depender do cargo de quem percebeu o problema, mas do potencial de dano, da incerteza e da necessidade de coordenação entre áreas.

Registre fatos e hipóteses

O registro do incidente precisa distinguir observação, confirmação, hipótese, lacuna e decisão solicitada. “Foi detectado login fora do padrão” é uma observação. “A conta foi usada pelo invasor” é uma hipótese até que outros elementos sustentem essa conclusão. Essa separação protege a investigação e evita que uma mensagem a clientes transforme uma suposição em declaração definitiva.

Cada entrada deve manter horário, autor, fonte consultada e relação com a decisão. Evite apagar o histórico para deixar o documento “limpo”. Correções devem ser acrescentadas como novas entradas, preservando o que havia sido registrado. O objetivo é permitir que outra pessoa reconstrua a sequência sem depender da memória de quem estava na chamada.

Proteja a linha do tempo

Decisões confiáveis dependem de registros confiáveis. Logs dispersos, com retenção indefinida ou controlados pelas mesmas identidades que podem ter sido comprometidas, não oferecem uma linha do tempo suficiente. O guia do NIST sobre gestão de logs trata o processo como um ciclo que envolve geração, transmissão, armazenamento, análise e descarte. Isso muda a pergunta de “temos logs?” para “conseguimos demonstrar a origem e a integridade do evento?”.

Um repositório central de evidências deve ficar separado da conta ou do projeto que produz os registros. O acesso para apagar, reescrever ou alterar políticas de retenção precisa ser restrito e monitorado. A coleta deve ser testada em todas as contas, regiões e serviços relevantes, incluindo eventos de identidade, alterações de privilégios, mudanças de configuração e atividades administrativas.

O artigo sobre logs de nuvem íntegros detalha como separar a coleta do controle operacional. Já o guia sobre quem decide quando um incidente começa ajuda a ligar a evidência técnica à autoridade de contenção. Use esses dois fluxos em conjunto: não adianta preservar registros se ninguém pode agir sobre a conta comprometida, nem isolar um ativo sem documentar a justificativa e os efeitos.

Priorize sem improviso

Quando o incidente é aberto, classifique as próximas medidas em duas filas. Em P1 ficam ações que reduzem risco imediato: conter uma identidade ativa, preservar registros voláteis, bloquear uma rota de acesso, proteger sistemas essenciais e convocar os responsáveis pelo impacto. Em P2 ficam ações necessárias para ampliar a compreensão e preparar a recuperação: revisar escopo, validar cópias, confirmar dependências, analisar exposição de dados e atualizar as partes interessadas.

A classificação não deve virar uma disputa entre departamentos. Para cada ação, registre o benefício esperado, o risco de executá-la, o risco de adiá-la e a condição de reversão. Se a contenção puder destruir evidências, a equipe deve decidir como coletá-las antes, quando isso for compatível com o risco. Se preservar o ativo permitir movimentação do atacante, a direção precisa conhecer essa troca, e não recebê-la depois como surpresa.

Teste o plano

Um exercício de mesa revela falhas que nenhum documento identifica sozinho. Simule uma conta privilegiada comprometida, um serviço crítico indisponível e uma suspeita de exposição de dados. Não avalie apenas se o time conhece ferramentas. Observe se alguém consegue convocar a célula, autorizar ações, acessar contatos alternativos, preservar evidências e produzir uma comunicação coerente com os fatos disponíveis.

Ao final, transforme cada dificuldade em uma tarefa com responsável, prazo e critério de conclusão. Repita o exercício quando houver mudança relevante em fornecedores, arquitetura, pessoas ou obrigações regulatórias. O plano só é útil se continuar compatível com a organização que precisa executá-lo.

Para a próxima reunião de segurança, leve quatro decisões: quem pode conter uma identidade sem aprovação adicional; qual serviço exige escalonamento imediato; onde ficará a cópia protegida dos registros; e quando será realizado o próximo exercício. Se essas respostas não estiverem documentadas e testadas, a organização ainda está contando com improviso.

Fontes

• NIST — Incident Response Recommendations and Considerations for Cybersecurity Risk Management.
• CISA — Incident Response Plan Basics.
• NIST — Guide to Computer Security Log Management.