CENÁRIOS · GUIA DE LEITURA
Simulação de crise com ransomware
Qual pergunta uma simulação precisa responder?
Uma simulação de crise com ransomware deve responder a uma pergunta concreta: quando sistemas críticos deixam de funcionar, há indícios de que dados foram copiados e as informações disponíveis são incompletas, como a organização decide o que proteger primeiro, quem pode autorizar as medidas e em que condições retoma a operação? A utilidade do exercício depende menos de representar um ataque cinematográfico e mais de expor decisões que atravessam tecnologia, continuidade, segurança, jurídico, comunicação e liderança.
A pergunta não é apenas se a equipe sabe identificar uma nota de resgate ou acionar uma ferramenta. É se as pessoas conseguem estabelecer uma imagem comum da situação, tomar medidas proporcionais, sustentar serviços prioritários e explicar suas decisões enquanto fatos mudam. Uma crise real combina urgência com incerteza: a indisponibilidade pode ter várias causas; uma evidência inicial pode ser incompleta; a equipe que detém uma informação essencial pode estar inacessível; e uma ação tecnicamente correta pode criar impacto operacional se ninguém avaliar dependências.
O que caracteriza uma simulação de crise com ransomware?
É uma atividade planejada em que participantes recebem uma situação fictícia, em etapas, e respondem usando os papéis, os procedimentos e os meios de comunicação que teriam à disposição. Um facilitador apresenta fatos e perguntas, observa as decisões e controla o ritmo. Um observador registra evidências do processo sem assumir o comando da resposta. A equipe discute o que faria, por que faria, quem autorizaria e quais informações precisaria obter.
A modalidade de mesa ocorre principalmente por conversa guiada, com documentos e mensagens simulados. É indicada para avaliar governança, comunicação, prioridades e fluxo de decisão sem alterar sistemas. Um laboratório autorizado acrescenta componentes técnicos isolados, por exemplo, a análise de alertas fictícios, um inventário preparado para o exercício ou a validação de um procedimento de restauração em ambiente de teste. Essas formas podem se complementar, mas não são intercambiáveis: discussão não valida uma restauração, e um teste técnico isolado não avalia se a direção, o jurídico e as áreas de negócio conseguem decidir em conjunto.
Contexto: por que exercitar antes de uma ocorrência?
A resposta a um incidente é um trabalho distribuído. Segurança pode detectar e analisar; operações de tecnologia podem isolar componentes e restaurar serviços; a continuidade pode priorizar processos; os donos do negócio conhecem impactos e alternativas; jurídico e privacidade avaliam obrigações e preservação; comunicação coordena mensagens; fornecedores mantêm partes da infraestrutura; e a liderança resolve conflitos de prioridade ou risco. Em uma organização menor, várias dessas atribuições recaem sobre poucas pessoas. Em qualquer escala, funções críticas podem depender umas das outras.
Em uma interrupção, o custo de esperar por uma decisão precisa ser comparado com o custo de agir sem informação suficiente. Desconectar um ambiente pode limitar propagação, mas interromper uma operação necessária. Manter um sistema ativo pode preservar uma função e também prolongar exposição. Restaurar um serviço pode reduzir o impacto, mas trazer de volta um componente comprometido ou dados inconsistentes. Não existe escolha universal que dispense conhecimento do ambiente, autoridade definida e revisão técnica.
Limites entre fatos, alertas e hipóteses
O roteiro deve usar rótulos explícitos para que todos saibam o que está confirmado dentro do cenário. Um alerta é um sinal que merece investigação, como uma detecção de comportamento incomum ou uma mensagem de fornecedor relatando degradação. Um relato é a informação atribuída a uma pessoa ou fonte: por exemplo, um funcionário diz que não consegue abrir arquivos. Uma hipótese é uma explicação possível, como atividade maliciosa ou falha de atualização. Uma confirmação exige evidência definida no exercício, como uma análise autorizada que estabeleça o estado de um ativo fictício.
Essas categorias descrevem o conhecimento dos participantes; não são conclusões sobre o mundo real. O facilitador deve evitar transformar um indício em veredito sem apresentar a transição. Se o material de injeção diz “um analista suspeita de cópia de dados”, a equipe deve discutir como validaria essa suspeita e o que faria enquanto não sabe. Se uma etapa posterior confirmar um evento no universo ficcional, o facilitador deve indicar qual evidência sustentou a confirmação e quais dúvidas permanecem.
Objetivos e escopo: o que será observado?
Antes de escrever as injeções, escolha poucos objetivos que possam ser observados. Um objetivo útil descreve uma capacidade: “identificar quem pode autorizar isolamento de um serviço crítico fora do horário comercial” ou “estabelecer como a equipe decidiria se inicia uma restauração quando há dúvida sobre o ponto de recuperação”. “Melhorar a resposta” é amplo demais para orientar o roteiro e avaliar o resultado.
Escopo define quais unidades, serviços, períodos e funções participam, assim como o que está fora da atividade. Um primeiro exercício pode concentrar-se em um processo essencial e nos sistemas que o suportam. Isso não significa ignorar as conexões: se o serviço depende de identidade, rede, fornecedor ou processo manual, esses vínculos devem aparecer em algum momento. O escopo precisa ser estreito o bastante para permitir decisões detalhadas e amplo o bastante para não dar uma falsa impressão de independência.
Papéis: quem decide, executa e observa?
O patrocinador dá legitimidade ao exercício, aprova objetivos e assegura que as áreas necessárias possam participar. Não precisa conduzir a conversa nem conhecer previamente todas as injeções. O facilitador mantém o ritmo, apresenta informações, formula perguntas neutras e evita sugerir a resposta desejada. Um bom facilitador não transforma o encontro em prova surpresa de memória nem debate para defender seu próprio procedimento.
O controlador do cenário administra a sequência e responde a pedidos de informação de maneira consistente com o roteiro. Em atividades pequenas, facilitador e controlador podem ser a mesma pessoa, desde que consigam separar a condução da avaliação. Observadores registram o que ocorreu: que decisão foi tomada, por quem, com quais informações, em quanto tempo contextual e quais dependências foram citadas. Eles não corrigem os participantes durante a sessão, salvo para esclarecer limites ou evitar uma ação que ultrapasse o ambiente autorizado.
Fontes de evidência pertinentes
A preparação deve partir de materiais que a organização tem autorização para usar e que sejam adequados ao objetivo. Podem ser relevantes o plano de resposta a incidentes, o plano de continuidade, inventário de serviços, classificação de dados, mapas de dependência, procedimentos de cópia e restauração, critérios de prioridade, matriz de autoridade, lista de escalonamento, contatos de fornecedores e modelos de comunicação. O roteiro não precisa reproduzir documentos extensos; deve usar versões controladas e apontar quais materiais foram consultados.
A seleção deve respeitar acesso mínimo. Não distribua diagramas detalhados, informações de autenticação ou contratos completos a todos os participantes quando um resumo basta. Materiais preparados para a sessão devem ter controle de versão e indicação visível de que são fictícios ou de exercício. Isso reduz confusão e mantém a utilidade do registro sem expor informação operacional desnecessária.
Construção do cenário: progressão sem respostas prontas
Uma narrativa útil começa com um serviço reconhecível e uma perturbação plausível. Em vez de entregar uma explicação completa, o facilitador oferece informação gradual. A primeira etapa pode mostrar falhas de acesso em uma aplicação importante, acompanhadas por relatos divergentes. A equipe precisa decidir como classificar o evento, quem acionar, quais registros preservar e como entender o impacto imediato. Ainda não é necessário dizer que houve ransomware.
Uma etapa seguinte pode acrescentar um alerta sobre atividade incomum em uma estação fictícia ou uma mensagem de extorsão encontrada em um ambiente simulado. A informação aumenta a plausibilidade de incidente, mas não explica alcance nem causa. Pergunte quais sistemas devem ser avaliados e como a decisão de isolamento considera dependências operacionais. Evite fornecer um mapa perfeito do ambiente: a dificuldade de obter uma visão confiável pode ser parte do objetivo.
Cenários contrastantes para testar julgamento
Um cenário de indisponibilidade sem confirmação de exfiltração testa resposta técnica e continuidade sem exigir que se presuma exposição de dados. Os participantes recebem alertas e relatos compatíveis com um incidente, mas a causa e o alcance permanecem em análise. A questão central é como reduzir impacto e preservar evidências sem anunciar uma conclusão que não existe. A organização deve manter abertura para causas alternativas, inclusive falhas operacionais, enquanto segue os critérios de escalonamento definidos.
Outro contraste pode ser a disponibilidade do decisor: em uma rodada, o titular responde; em outra, está indisponível e o substituto precisa assumir. Isso testa se a delegação está documentada e se o substituto tem contexto e autoridade suficientes. Se não tiver, o achado é de desenho organizacional, não uma falha pessoal de quem foi chamado para a atividade.
Decisões práticas durante a resposta simulada
A contenção deve começar pela pergunta sobre finalidade e efeitos: que risco a ação pretende reduzir, que serviço pode ser interrompido, que evidência pode se perder e quem tem autoridade para autorizá-la? O exercício pode discutir isolamento de um ativo ou segmento fictício, suspensão de uma integração ou revogação de acesso. Não precisa incluir instruções técnicas de execução. O foco é testar se a equipe tem informações e mecanismos para agir com segurança, confirmar a execução e reavaliar a decisão quando o quadro mudar.
A preservação de evidências requer que investigação e continuidade conversem. A equipe deve saber quem mantém registros relevantes, qual procedimento interno orienta a preservação, como solicitar apoio especializado e como documentar alterações feitas durante contenção. Uma simulação de mesa pode perguntar quais evidências seriam necessárias e de que fonte; um laboratório autorizado pode validar um fluxo previamente aprovado com dados de teste. Nenhum participante deve coletar dados reais fora do escopo ou modificar sistemas de produção para “demonstrar” capacidade.
Backups, dependências e a falsa sensação de prontidão
A existência de uma cópia não equivale à capacidade de recuperação. É preciso considerar se ela está disponível durante uma interrupção, se as pessoas autorizadas conseguem acessá-la, se os dados são suficientemente recentes, se a restauração foi exercitada em condições relevantes e se há infraestrutura e conhecimento para concluir o processo. Também importa saber se a cópia depende de serviços de identidade, rede, chaves, catálogo ou fornecedor que possam estar indisponíveis no cenário.
O exercício não deve afirmar que o backup está íntegro simplesmente porque há uma política que exige cópias. Também não precisa presumir que todas as cópias falharam. O facilitador pode manter o estado como desconhecido e observar como a equipe busca confirmação. Alternativamente, pode introduzir uma evidência fictícia sobre um conjunto específico, deixando claro o alcance limitado. Um teste técnico controlado, separado da conversa, pode fornecer evidência de restauração de um conjunto e ambiente definidos; ainda assim, não elimina outras dependências.
Exercício de mesa: formato e condução
Uma sessão de mesa pode durar algumas horas ou ser dividida em blocos, conforme os objetivos e a disponibilidade das funções. O convite deve explicar o propósito, o escopo, os participantes esperados, a regra de confidencialidade e a ausência de julgamento individual. Envie apenas a preparação necessária: por exemplo, uma descrição curta do serviço escolhido e a indicação de consultar procedimentos existentes. Se o objetivo for testar a capacidade de localizar esses procedimentos, não envie cópias organizadas especialmente para o encontro.
Na abertura, o facilitador apresenta regras, canais fictícios, frase de pausa e limites de segurança. Reforça que ninguém deve executar ações reais em sistemas, enviar mensagens para fora ou acionar fornecedores como se a ocorrência fosse verdadeira. As decisões serão narradas e registradas como escolhas do exercício. Participantes podem pedir esclarecimento, reconhecer que não sabem e indicar o que precisariam descobrir. Essa liberdade aumenta a qualidade dos achados.
Laboratório autorizado: quando acrescentar prática técnica
Um laboratório é apropriado quando o objetivo exige verificar uma ação técnica que conversa não comprova, como a capacidade de restaurar um conjunto de teste ou de consultar um painel de monitoramento preparado para a atividade. Ele deve usar ambiente segregado, dados sintéticos, contas de exercício, autorização explícita e procedimento de reversão conhecido. Os limites precisam indicar ativos incluídos, atividades permitidas, janela, responsáveis e condições de parada.
Uma demonstração segura pode avaliar se o operador localiza o procedimento correto, reconhece o ponto de recuperação designado, valida um conjunto de dados fictício e registra a aprovação do dono do serviço. A atividade não precisa reproduzir código malicioso, explorar vulnerabilidades, simular propagação real ou acessar sistemas de terceiros. Se a organização decidir realizar teste técnico mais amplo, deve tratá-lo em processo próprio de autorização e controle, com avaliação de risco e escopo definidos por especialistas.
Critérios de avaliação sem métricas inventadas
Critérios devem ser definidos antes da sessão e vinculados aos objetivos. Para governança, pode-se observar se a decisão teve autoridade identificável, substituto e registro. Para consciência situacional, se os participantes distinguiram fato, relato e hipótese, atualizaram o quadro comum e indicaram lacunas. Para continuidade, se priorizaram serviços por impacto e consideraram alternativas operacionais. Para recuperação, se estabeleceram condições de validação, dependências e aceite do negócio.
Avalie evidências, não impressões sobre confiança ou eloquência. Uma equipe pode falar com segurança e deixar de registrar a decisão; outra pode reconhecer incerteza e pedir uma informação essencial antes de agir. A segunda resposta pode ser mais robusta. O observador deve anotar contexto: qual injeção estava disponível, quem participou, que decisão foi tomada, que informação faltou, que efeito isso teve e se o procedimento aplicável foi localizado.
Também convém observar como a equipe lida com desacordo. Uma divergência entre segurança e operação pode ser produtiva se as opções, impactos e autoridade forem explicitados. O exercício deve registrar se houve mecanismo para resolver o impasse e se a decisão foi reavaliada diante de novos fatos. Não é necessário que todos concordem; é necessário que o processo permita uma decisão responsável e comunicável.
Erros comuns e como evitá-los
Um erro é escrever uma história longa, mas sem decisões. Se cada mensagem apenas aumenta o drama, a equipe fica ocupada reagindo sem exercitar prioridades. Revise cada injeção e pergunte qual questão nova ela apresenta. Se não introduzir uma escolha, uma dependência ou uma evidência que mude a avaliação, talvez não seja necessária.
Outro erro é preparar a resposta correta com antecedência e conduzir participantes até ela. Isso transforma o exercício em validação da opinião do autor. O facilitador deve permitir alternativas e explorar consequências. Se a escolha estiver fora de política ou parecer perigosa, pergunte qual autorização e condição seriam necessárias; não ensine procedimento técnico inseguro no calor da sessão.
Também evite tratar velocidade como único sinal de qualidade. Uma decisão rápida, sem base nem autoridade, pode criar risco adicional. Considere se o tempo foi suficiente para reconhecer a informação, consultar o papel correto e explicar o efeito. Se medir tempo fizer parte do objetivo, defina início e término observáveis e interprete o resultado no contexto da complexidade apresentada.
Roteiro de implementação
Comece com uma conversa de escopo entre patrocinador, segurança, continuidade e donos de serviço. Selecione um processo relevante e identifique as funções cuja decisão será necessária. Defina uma pergunta central e até alguns objetivos observáveis. Escolha a modalidade de mesa ou laboratório com base na evidência pretendida, e determine limites, participantes, duração e regra de parada.
Em seguida, reúna procedimentos existentes e valide a versão e o proprietário. Mapeie as dependências que o cenário precisa envolver: dados, identidade, rede, aplicações, pessoas, fornecedores e meios de comunicação. Não tente preencher todo o inventário no roteiro; identifique o que é essencial para as decisões. Marque incertezas preparatórias, pois elas também podem constituir achados se forem relevantes para a resposta.
Após a sessão, envie um resumo executivo que mostre as decisões e os riscos que exigem patrocínio, além do registro detalhado para os responsáveis pelas ações. Defina como a liderança receberá atualizações sobre ações atrasadas ou bloqueadas. Uma revisão posterior pode verificar se as mudanças foram incorporadas aos procedimentos e se os participantes relevantes sabem onde encontrá-las.
Exemplo defensivo hipotético
Considere, apenas como exemplo hipotético, uma organização que processa pedidos por um portal interno e mantém atendimento ao cliente por telefone. No início, parte dos usuários não consegue acessar o portal. A equipe recebe dois relatos, um de falha de autenticação e outro de documentos que parecem ter nomes alterados. Nenhuma evidência confirma a causa. O líder registra indisponibilidade parcial como fato do cenário, a hipótese de incidente cibernético como hipótese e designa responsáveis para verificar identidade, aplicação e impacto no atendimento.
Uma segunda rodada hipotética poderia fornecer uma resposta validada: o canal alternativo consulta uma fonte separada, mas exige um procedimento de reconciliação ao restabelecer o portal. A equipe teria então de definir quem registra as operações manuais, como evita duplicidade e quem valida a conciliação antes de declarar normalizado o serviço. O contraste demonstra que continuidade envolve qualidade e integridade do processo, além de manter uma atividade em funcionamento.
Como transformar achados em melhoria
O relatório deve começar com escopo, objetivos, participantes por função, modalidade e limitações. Em seguida, apresenta um resumo da situação, as decisões relevantes, as capacidades observadas e as lacunas. Cada achado deve ter evidência suficiente para que o leitor entenda o que aconteceu, sem atribuir intenção ou culpa. Se uma conclusão é inferência do observador, marque-a como tal e indique qual observação a sustenta.
Priorize achados pelo impacto potencial, pela abrangência e pela dependência que criam. Uma autoridade de isolamento sem substituto pode ser mais urgente que um modelo de mensagem pouco elegante, dependendo dos serviços e do risco. Não use uma fórmula numérica improvisada para dar aparência objetiva. A liderança responsável deve entender a base da prioridade e qualquer incerteza na avaliação.
FAQ
Com que frequência realizar uma simulação?
A frequência depende de mudanças na organização, criticidade dos serviços, exigências internas e resultados anteriores. Uma mudança de fornecedor, arquitetura, liderança ou processo de recuperação pode justificar nova atividade antes do ciclo planejado. Não existe uma frequência única que prove prontidão. O princípio útil é exercitar as capacidades relevantes e acompanhar as melhorias, sem transformar o calendário em substituto para avaliação de risco.
Quem deve participar?
Inclua as funções que precisam decidir, executar ou aconselhar dentro do escopo. Uma sessão só de tecnologia pode ser adequada para um objetivo técnico delimitado, mas não permite concluir que a comunicação executiva ou as decisões de negócio foram testadas. Considere substitutos e cobertura fora do horário se isso fizer parte do risco analisado. Convide pessoas por função e deixe claro o papel esperado.
Uma simulação de mesa prova que os backups funcionam?
Não. Ela pode revelar se a equipe sabe onde buscar informação, quem autoriza uma restauração e que critérios pretende usar. A capacidade de restaurar precisa de evidência técnica em ambiente controlado, nos limites do teste realizado. Mesmo essa evidência não comprova todos os serviços, volumes, pontos de recuperação ou dependências possíveis.
Devemos simular uma nota de resgate?
Pode ser útil apresentar uma mensagem fictícia claramente identificada como material de exercício, se isso se relacionar a um objetivo. Use dados inventados e mantenha a mensagem dentro do ambiente da sessão. Não envie a peça por canais reais sem coordenação, pois alguém pode interpretá-la como ameaça verdadeira. A mensagem deve abrir uma discussão sobre validação e resposta, não induzir uma decisão predeterminada.
Como tratar a hipótese de exfiltração?
Trate-a conforme a evidência disponível no cenário. Um alerta, uma alegação de atacante e uma confirmação técnica têm pesos diferentes. Defina quem investigaria, quais registros seriam relevantes, como preservá-los e quem avaliaria impactos e obrigações. Enquanto não houver confirmação, a comunicação deve refletir a incerteza sem esconder a possibilidade que está sendo investigada.
É necessário usar uma ferramenta de simulação?
Não necessariamente. Uma sessão de mesa pode ser conduzida com roteiro, materiais fictícios, quadro de decisões e registro de observações. Ferramentas podem ajudar a organizar participantes ou linha do tempo, mas não resolvem falta de autoridade, informação ou procedimento. Para teste técnico, use apenas recursos aprovados e ambientes que correspondam ao objetivo.
Leitura relacionada
O capítulo 8 do manuscrito original de Hiago Kin Levi, publicado pela Editora Brasport, trata de operações de resposta, contenção e recuperação. Essa relação é pertinente porque uma simulação de crise conecta decisões de contenção à continuidade e ao retorno dos serviços, incluindo a necessidade de registrar ações e validar condições de recuperação. A obra pode apoiar a reflexão sobre esses temas, mas não substitui documentação técnica atualizada, treinamento prático nem o julgamento das equipes responsáveis pelo ambiente.
CONTINUE NO LIVRO
Confronto Cibernético
Este assunto se relaciona ao capítulo 8 da versão original, “Operações de resposta a incidentes”. Leia o trecho identificado na página do capítulo.
Leia o trecho identificado do capítulo ↗Veja onde encontrar o livro ↗Referência para aprofundar
Consulte também a fonte primária NIST SP 800-61 Rev. 3. O artigo apresenta uma síntese editorial para estudo; decisões em incidentes reais dependem do contexto, da autorização e da equipe responsável.