A comunicação durante um incidente de segurança é tão crítica quanto a resposta técnica em si. Uma comunicação falha pode atrasar a contenção, aumentar o impacto e prejudicar a confiança na equipe. Nesta aula, você vai dominar os fundamentos da comunicação de incidentes: como escalar corretamente, como manter o status atualizado, como identificar e engajar stakeholders e como usar templates para padronizar e agilizar a troca de informações.

Vamos explorar cada um desses pilares com exemplos práticos e modelos que você pode adaptar ao seu contexto. O objetivo é que, ao final, você seja capaz de planejar e executar uma comunicação clara, precisa e oportuna durante qualquer incidente, minimizando ruídos e maximizando a eficiência da resposta.

Escalação

Escalação é o processo de envolver níveis adicionais de autoridade, conhecimento ou recursos quando um incidente não pode ser resolvido no nível atual. Uma escalação bem executada garante que as decisões sejam tomadas rapidamente por quem tem o poder e a informação necessária, evitando atrasos que podem agravar o impacto.

Existem dois tipos principais de escalação: hierárquica (subir na cadeia de comando) e funcional (acionar especialistas de outras áreas, como jurídico, comunicação ou infraestrutura). A definição de quando escalar deve ser baseada em critérios objetivos, como o impacto nos negócios, a criticidade do sistema afetado ou o tempo decorrido sem solução.

Um bom processo de escalação começa com um plano claro: definir quem são os contatos primários e secundários para cada tipo de incidente, quais os limites de tempo para escalar e quais informações devem ser repassadas. Ferramentas de gestão de incidentes, como PagerDuty ou Opsgenie, ajudam a automatizar notificações e a documentar a trilha de escalação.

Exemplo de política de escalação em texto:

Política de Escalação - Nível 1 (Suporte Técnico)
- Incidente com impacto em um único usuário: tentar resolver em 30 minutos.
- Se não resolver, escalar para Nível 2 (Engenharia).
Nível 2 (Engenharia)
- Incidentes que afetam um sistema crítico: resolver em 1 hora.
- Se não resolver, escalar para Nível 3 (Gerência de TI).
Nível 3 (Gerência de TI)
- Incidentes de grande impacto ou que envolvem dados sensíveis: acionar o Comitê de Crise.
- Decisões de comunicação externa e jurídica são tomadas nesse nível.

É fundamental documentar cada escalação: quem foi acionado, quando, por qual motivo e qual a resposta. Isso gera um histórico útil para melhorias futuras e para auditorias.

Status

Manter um status atualizado e acessível é essencial durante um incidente. O status deve refletir o estado atual do incidente, as ações em andamento e o que ainda precisa ser feito. Uma boa prática é usar um post mortem ou um ticket de incidente como registro central, onde todos os envolvidos possam consultar as últimas atualizações.

Os status típicos em um ciclo de vida de incidente são: Detectado, Investigando, Mitigando, Resolvido e Encerrado. Cada status deve ter uma definição clara e um responsável por atualizá-lo. É recomendável que as atualizações de status sejam feitas em intervalos regulares (ex.: a cada 30 minutos) ou sempre que houver uma mudança significativa, para que os stakeholders não fiquem no escuro.

Além do status, é importante incluir um resumo executivo (1 ou 2 frases) que explique o impacto e as ações em andamento. Isso é especialmente útil para quem não está envolvido tecnicamente, como executivos ou clientes.

Exemplo de atualização de status em um canal de comunicação:

[STATUS] Incidente #1024 - Falha no banco de dados principal
- Status: Mitigando
- Impacto: Sistema de pedidos indisponível desde 14:30 UTC.
- Ação em andamento: Failover para réplica de leitura em andamento.
- Próxima atualização: em 15:00 UTC.
- Responsável: João Silva (Engenharia)

Use ferramentas como Slack, Microsoft Teams ou um painel de status público (se for um serviço voltado ao cliente) para divulgar o status. Lembre-se de que comunicação é via de mão dupla: incentive os envolvidos a reportarem novas informações ou mudanças no impacto.

Stakeholders

Stakeholders são todas as pessoas ou grupos que têm interesse no incidente ou que podem ser afetados por ele. Eles podem ser internos (funcionários, gerência, executivos) ou externos (clientes, parceiros, reguladores). Identificar corretamente os stakeholders é crucial para direcionar a comunicação adequada a cada público.

Para cada stakeholder, é preciso definir: qual o seu nível de envolvimento, quais informações ele precisa receber, com que frequência e por qual canal. Por exemplo, um CEO pode querer apenas um resumo executivo diário, enquanto o time de desenvolvimento precisa de detalhes técnicos contínuos.

Uma matriz de stakeholders pode ser criada para organizar isso:

| Stakeholder | Nível de Interesse | Canal Preferido | Frequência | Informações Necessárias |
|-------------|-------------------|-----------------|------------|-------------------------|
| CEO         | Alto              | E-mail/Telefone | Diário     | Resumo executivo, impacto financeiro |
| Time de TI  | Muito Alto        | Slack           | Contínuo   | Detalhes técnicos, ações em andamento |
| Clientes    | Alto              | Status público  | A cada mudança | Impacto, previsão de resolução |
| Jurídico    | Médio             | E-mail          | A cada mudança | Riscos legais, notificações obrigatórias |

É importante também definir quem é o comandante do incidente (incident commander), que será o ponto central de coordenação e comunicação. Ele deve ser o único a autorizar comunicações externas, para evitar mensagens contraditórias.

Lembre-se de que os stakeholders podem mudar durante o incidente. Por exemplo, um incidente que inicialmente era interno pode ganhar repercussão pública, exigindo a inclusão da equipe de comunicação. Revise a lista de stakeholders periodicamente.

Templates

Templates são modelos pré-definidos de comunicação que padronizam a linguagem e as informações em diferentes fases do incidente. Eles economizam tempo, reduzem erros e garantem que nenhum dado importante seja omitido. Um bom template deve ser flexível o suficiente para ser adaptado a diferentes cenários, mas específico o bastante para guiar a escrita.

Os templates mais comuns são: notificação inicial (quando o incidente é detectado), atualização de status (durante a investigação e mitigação), comunicação de resolução (quando o incidente é resolvido) e notificação pós-incidente (para clientes ou reguladores). Cada um tem campos específicos, como impacto, ações tomadas, próximos passos e contato.

Exemplo de template de notificação inicial:

ASSUNTO: [URGENTE] Incidente em [SERVIÇO] - [DATA/HORA]

Prezados,

Detectamos um incidente em [SERVIÇO] às [HORA] (UTC).
Impacto atual: [DESCREVER O IMPACTO, EX.: indisponibilidade total, lentidão]
Sistemas afetados: [LISTAR]

Nossa equipe já está investigando a causa. A próxima atualização será enviada em [HORA] ou assim que houver novas informações.

Para mais detalhes, acesse [LINK DO PAINEL DE STATUS].

Atenciosamente,
[EQUIPE DE RESPOSTA]

Exemplo de template de atualização de status:

ASSUNTO: Atualização do Incidente [ID] - [STATUS]

Olá,

Status atual: [STATUS]
Resumo: [UMA FRASE SOBRE O QUE ESTÁ ACONTECENDO]
Ações em andamento: [LISTA DE AÇÕES]
Impacto atual: [DESCREVER]

Próxima atualização: [HORA] ou quando houver mudança relevante.

Se você tiver dúvidas, responda a este e-mail ou contate [CONTATO].

Além de templates textuais, considere criar modelos para páginas de status (como statuspage.io) ou para postagens em redes sociais. Manter uma biblioteca de templates revisada e aprovada pela equipe evita improvisos e melhora a qualidade da comunicação.

Referências

Exercícios

  1. Descreva os dois tipos de escalação (hierárquica e funcional) e dê um exemplo de cada em um contexto de incidente de segurança.

    2. ✓ Resposta: Escalação hierárquica: envolve subir na cadeia de comando, como de um analista de suporte para o gerente de TI quando o incidente não pode ser resolvido no prazo estipulado. Exemplo: um analista de suporte recebe um alerta de possível invasão, mas não tem autoridade para isolar o sistema; ele escala para o gerente de TI, que decide desligar o servidor.
    Escalação funcional: envolve acionar especialistas de outras áreas, como jurídico, comunicação ou infraestrutura. Exemplo: durante um vazamento de dados, o time técnico aciona o departamento jurídico para avaliar obrigações legais de notificação.
  2. Liste os cinco status típicos de um incidente e explique o que deve ser incluído em cada atualização de status.

    3. ✓ Resposta: Os cinco status típicos são: Detectado (incidente identificado), Investigando (buscando causa e impacto), Mitigando (ações para conter), Resolvido (sistema restaurado) e Encerrado (documentação concluída). Cada atualização deve incluir: status atual, resumo executivo, impacto, ações em andamento, próximos passos e a hora da próxima atualização.
  3. Usando o template de atualização de status fornecido na aula, crie uma atualização fictícia para um incidente de phishing que afetou 20 funcionários. Inclua as informações necessárias.

    4. ✓ Resposta: 
    ASSUNTO: Atualização do Incidente #2031 - Phishing Interno

Olá,

Status atual: Mitigando
Resumo: Detectamos um e-mail de phishing que foi aberto por 20 funcionários. Estamos isolando as contas comprometidas.
Ações em andamento: Reset de senhas em lote, varredura de endpoints, bloqueio do remetente.
Impacto atual: Possível exposição de credenciais de 20 funcionários, mas nenhum dado sensível foi acessado até o momento.

Próxima atualização: 16:00 UTC ou assim que houver mudança relevante.

Se você tiver dúvidas, responda a este e-mail ou contate a equipe de segurança.
  4. Identifique três stakeholders diferentes para um incidente de violação de dados que envolve informações de clientes e explique quais informações cada um precisa receber.

    5. ✓ Resposta: Clientes: precisam saber quais dados foram expostos, se há risco real, e o que devem fazer (ex.: trocar senhas). Devem ser notificados de forma clara e sem pânico.
    Jurídico: precisa avaliar obrigações legais, como notificar órgãos reguladores (LGPD) e possíveis ações judiciais.
    Equipe de TI: precisa de detalhes técnicos sobre a causa, sistemas afetados e ações de contenção para evitar novos ataques.
  5. Crie um template de notificação de resolução de incidente, incluindo os campos que você considera essenciais. Explique por que cada campo é importante.

    6. ✓ Resposta: 
    ASSUNTO: Incidente [ID] Resolvido - [SERVIÇO]

Prezados,

O incidente [ID] em [SERVIÇO] foi resolvido às [HORA] (UTC).

Resumo do incidente: [DESCREVER CAUSA E IMPACTO]
Ações tomadas: [LISTA DE AÇÕES]
Medidas preventivas: [O QUE SERÁ FEITO PARA EVITAR RECORRÊNCIA]

Se você tiver dúvidas, responda a este e-mail ou contate [CONTATO].

Atenciosamente,
[EQUIPE]

    Importância dos campos: O resumo do incidente ajuda a entender o que aconteceu; as ações tomadas mostram o que foi feito; as medidas preventivas demonstram compromisso com a melhoria; e o contato facilita o follow-up.

Boas Práticas e Observações Finais

Para encerrar, lembre-se de que a comunicação de incidentes deve ser tratada com a mesma seriedade que a resposta técnica. Sempre documente todas as comunicações, pois elas podem ser necessárias para auditorias ou investigações. Revise seus templates e planos de comunicação regularmente, e realize simulações de incidentes para treinar a equipe.

Outra boa prática é manter um canal de comunicação dedicado e silencioso para updates, evitando ruídos em canais gerais. E nunca subestime o poder de uma comunicação clara: ela pode ser a diferença entre um incidente controlado e uma crise de reputação.