top of page

Decisão sob estresse: o rito que separa decidir de improvisar num incidente

  • há 2 dias
  • 4 min de leitura

Um ataque cibernético é, antes de tudo, uma situação de crise. Crises não colocam à prova a tecnologia de uma organização. Colocam à prova sua capacidade de decidir sob pressão.


A maioria das empresas descobre o problema quando ele já está em curso. O sistema está fora. O time técnico está acordado às 3 da manhã. O CEO recebe uma ligação que não esperava. A próxima hora determina boa parte do custo total do incidente. E muito dessa hora depende de uma pergunta simples: quem decide o quê, e em qual janela de tempo?


Sala de reunião vazia e escura, com mesa, três cadeiras e relógio digital vermelho: DECISÃO CRÍTICA 16:45:30.

Se a resposta a essa pergunta ainda está sendo construída durante a crise, ela já chegou tarde.


Ataque é uma negociação de velocidade


A assimetria central de um ataque cibernético é temporal. O atacante preparou o movimento por dias, semanas ou meses. A organização tem horas. Às vezes minutos. Para responder de forma eficaz.


Cada hora de hesitação tem um custo que se acumula. Dados exfiltrados. Sistemas comprometidos adicionalmente. Janela de contenção que fecha. Em ataques de ransomware, o tempo até o isolamento dos sistemas afetados é o principal determinante da magnitude do impacto.


Decisões lentas não são apenas custosas. São multiplicadoras de risco. A velocidade de decisão, nesse contexto, é uma vantagem operacional que pode ser planejada com antecedência. Ou improvisada às pressas, com todos os riscos que isso implica.


Quem decide e em qual janela


O rito de decisão durante um incidente precisa estar definido antes do incidente. Essa afirmação parece óbvia, mas a maioria das organizações não tem esse rito formalizado.


Há três camadas de decisão num incidente relevante.


A primeira é operacional, nos primeiros 30 a 60 minutos. Containment. Isolamento. Preservação de evidências. Esse nível pertence ao time técnico. A decisão aqui é técnica e precisa ser rápida.


A segunda é de negócio, nas primeiras 2 a 4 horas. Quais sistemas podem ser desligados sem comprometer operação crítica? Qual a tolerância de indisponibilidade? O incidente já afetou clientes? Essa camada exige o envolvimento de alguém com visão de operação. Normalmente o COO ou equivalente. A decisão aqui é de prioridade de negócio, não de detalhe técnico.


A terceira é estratégica, nas primeiras 24 horas. Comunicar reguladores, clientes estratégicos, imprensa? Acionar seguro cyber? Engajar time jurídico externo? Essa camada pertence ao CEO e ao board. As decisões aqui têm implicações que vão além do incidente.


Sem esse mapeamento, as três camadas se misturam. O CEO recebe perguntas técnicas às 3 da manhã. O técnico toma decisões comerciais que não são suas. E o incidente se arrasta porque ninguém tem autoridade clara para decidir em cada janela.


O rito de decisão pré-incidente


A governança de crise que funciona não é improvisada. Ela é praticada antes que o incidente aconteça.


Isso não significa simular ataques virtuais em laboratório. Embora exercícios de red team tenham valor. Significa definir, documentar e revisar periodicamente: quem está na cadeia de resposta, qual é o critério de escalada para cada camada de decisão, qual é a tolerância de indisponibilidade por sistema crítico, e quem tem autoridade para desligar o quê.


Significa também que o board sabe o que esperar. Quando o CEO aciona o presidente do conselho às 2 da manhã com a notícia de um incidente, o tom da conversa é muito diferente se o board já discutiu cenários de crise anteriormente.


O enquadramento correto não é "temos um problema técnico". É "estamos executando nosso plano de resposta. Aqui está o status. Aqui está o que precisa de sua decisão".


Três casos, uma lição


Considere um hospital com sistemas de prontuário fora do ar às 23 horas de uma sexta-feira. A equipe de TI está presente, mas a decisão de acionar o fornecedor de suporte de emergência, que tem um custo elevado, precisa de aprovação. O contato de escalada disponível não tem autoridade para aprovar o gasto. São 40 minutos para localizar alguém com autoridade. 40 minutos de prontuários indisponíveis numa UTI.


Considere uma planta industrial com sistemas de controle comprometidos numa segunda-feira de manhã. A decisão de parar a linha, com custo de centenas de milhares por hora, é de quem? Do engenheiro de plantão, que claramente não tem essa alçada? Do gerente de operações, que não quer ser responsável por uma parada não autorizada? O incidente se alarga porque a decisão de containment aguarda aprovação de alguém que não foi notificado.


Considere uma instituição de ensino às vésperas do período de matrículas com sistema de inscrições fora do ar por um ataque. A decisão de comunicar publicamente é de quem? Comunicação, jurídico, diretoria? A demora na comunicação gera mais dano à reputação do que o próprio incidente.


Em todos os casos, o problema não foi técnico. Foi de governança.


Velocidade de decisão como vantagem


Organizações que tratam a governança de incidente como uma competência estratégica chegam numa posição diferente quando o incidente acontece. Elas têm playbook. Têm autoridade mapeada. Têm prática em tomar decisões sob pressão controlada.


Essa preparação não elimina o custo de um incidente. Mas reduz dramaticamente o custo de resposta. E reduz a extensão dos danos colaterais.


A pergunta para o board não é "temos um bom time de segurança?". É "se um incidente relevante acontecesse esta noite, quem tomaria a decisão de desligar nossos sistemas críticos? Em quanto tempo? Com base em qual critério?".


Se a resposta a essa pergunta não for imediata e clara, a governança de crise ainda está incompleta.


LeanBic Cibersegurança

 
 
 
bottom of page