Gestão de resposta a incidentes

Um logon, uma atualização de software e uma requisição web são eventos: ocorrências observáveis que envolvem ativos computacionais. A maioria dos eventos é normal. Um evento adverso tem uma consequência negativa, como uma falha de disco, uma queda de energia ou uma infecção por malware.

Decida quando uma resposta de segurança é necessária

Um incidente de segurança cibernética compromete ou ameaça comprometer de forma iminente a confidencialidade, a integridade ou a disponibilidade de informações ou sistemas, sem autorização legal. Também inclui violações reais ou iminentes de leis, políticas de segurança, procedimentos de segurança ou políticas de uso aceitável. A organização documenta critérios de incidente para que os analistas possam aplicar essa definição de forma consistente.

Um atacante usando uma senha roubada caracteriza um incidente mesmo antes de alguém confirmar o roubo de dados. Uma queda de energia rotineira é um evento adverso, mas geralmente não atende aos critérios de incidente de segurança. Uma violação de dados é um tipo de incidente que envolve acesso ou divulgação não autorizados de dados. Um ataque de negação de serviço pode ser um incidente sem violação de dados.

Um alerta é um sinal para investigar. Quando as evidências atendem aos critérios documentados, um analista declara um incidente: abre o registro do incidente, designa um responsável e ativa as regras de severidade, resposta e comunicação do plano. Tratar todo alerta como incidente cria ruído; esperar a comprovação de roubo deixa passar incidentes que já ameaçam sistemas.

Relacione as fases

O ciclo de vida clássico agrupa o trabalho em quatro fases:

1. Preparação: estabelecer autoridade, contatos, acesso, ferramentas, registro de eventos, cópias de segurança e procedimentos praticados.
2. Detecção e análise: validar sinais, estabelecer o que aconteceu, encontrar os ativos afetados e avaliar o impacto.
3. Contenção, erradicação e recuperação: interromper o dano, remover o acesso do atacante e suas causas e restaurar serviços confiáveis.
4. Atividade pós-incidente: revisar a resposta e acompanhar as melhorias.

Os programas de certificação podem dividir o trabalho intermediário em etapas separadas, totalizando sete etapas. Isso descreve o mesmo trabalho com mais detalhes. As fases se sobrepõem. Um analista pode descobrir uma segunda conta comprometida durante a contenção e voltar à determinação do escopo. Uma limpeza malsucedida pode levar um sistema de volta ao isolamento.

Entenda o modelo atual do NIST

A NIST SP 800-61 Revisão 3, publicada em abril de 2025, insere a resposta a incidentes nas seis funções do Cybersecurity Framework (CSF) 2.0. Governar, Identificar e Proteger apoiam a preparação por meio de uma gestão de riscos mais ampla. Detectar, Responder e Recuperar organizam a própria resposta a incidentes. A categoria Melhoria dentro de Identificar reúne lições de qualquer atividade, inclusive de um incidente em andamento.

Por exemplo, uma equipe descobre durante a contenção que sua lista de contatos de nuvem está desatualizada. Ela atualiza a lista imediatamente e registra a alteração para revisão. Não é preciso esperar que todos os serviços sejam recuperados para melhorar a prontidão. Incidentes podem levar semanas ou meses para ser resolvidos, portanto compartilhar lições apenas no fim deixaria uma lacuna conhecida aberta durante todo esse tempo.

Uma resposta precisa de autoridade e de uma maneira prática de usá-la. Três níveis de documentação conectam decisões da gestão a ações em um console.

Dê uma função clara a cada documento

A política estabelece o compromisso da gestão, o escopo, as definições e a autoridade, incluindo quem pode desconectar um sistema. O plano explica como a organização responde: papéis, categorias de incidentes, níveis de severidade, caminhos de escalonamento, comunicação, recursos e documentação. Procedimentos e roteiros de resposta explicam as etapas e decisões para situações específicas.

Um plano utilizável inclui listas de contatos, substitutos, requisitos de evidências, links para roteiros de resposta e um cronograma de revisão. Ele atribui papéis que permanecem apesar de mudanças na equipe. Se apenas um executivo específico puder aprovar o isolamento e essa pessoa estiver inacessível, o plano terá um ponto único de falha. Autorize previamente a contenção para situações definidas e indique substitutos para tomar decisões.

Associe decisões a papéis

O gestor de incidentes, também chamado de comandante do incidente, coordena o trabalho, distribui tarefas, acompanha a situação e toma decisões dentro da autoridade prevista no plano. Os profissionais de resposta a incidentes validam achados, preservam evidências e executam ações de resposta. As equipes de sistemas, redes, nuvem e desenvolvimento fazem alterações em seus serviços.

A liderança fornece recursos e aprova ações de alto impacto. Os responsáveis pelos ativos explicam o impacto nos negócios e as prioridades de recuperação. A assessoria jurídica orienta sobre preservação, contratos e notificações; a equipe de relações públicas cuida dos comunicados públicos. Recursos humanos participa de casos relacionados a funcionários, e a segurança física apoia o acesso às instalações.

Uma CSIRT interna é uma equipe de resposta a incidentes de segurança em computadores. Um modelo terceirizado pode usar um provedor de serviços gerenciados de segurança (MSSP) ou uma empresa de resposta contratada previamente. Um modelo híbrido combina profissionais internos de resposta com especialistas externos. Para serviços de nuvem, registre quais camadas o provedor gerencia e quais permanecem sob responsabilidade do cliente, incluindo como obter evidências do provedor.

Planeje a comunicação antes do incidente

O plano de comunicação diz quem recebe uma atualização, quem a envia, quando, por qual canal e com quais detalhes. Os públicos internos incluem profissionais de resposta, liderança, responsáveis pelos ativos, central de suporte e funcionários afetados. Os públicos externos podem incluir clientes, parceiros, órgãos reguladores, autoridades de investigação, seguradoras e mídia. A liderança e a assessoria jurídica decidem sobre notificações externas; os analistas seguem o caminho definido.

Use comunicação por canal alternativo se o e-mail, o chat ou os sistemas de identidade puderem estar comprometidos. Uma conferência telefônica separada ou um serviço de mensagens independente impede que um atacante no ambiente principal acompanhe a resposta. Compartilhe detalhes do incidente com base na necessidade de conhecimento.

Às 02:10, um analista confirma a criptografia em um servidor de folha de pagamento. O plano classifica o caso como severidade 1. O analista aciona o gestor de incidentes, que abre uma conferência telefônica separada e informa o CISO. A assessoria jurídica avalia as implicações para dados pessoais. A equipe de relações públicas prepara um comunicado inicial para aprovação. O registro do incidente documenta cada ação e horário.

Torne a prontidão prática

Mantenha planos desconectados, contatos atualizados de fornecedores e funcionários, inventário de ativos, diagramas de rede, registros centralizados de eventos com relógios sincronizados, linhas de base de atividades e acesso pré-aprovado para profissionais de resposta. Um kit de resposta a incidentes contém um notebook limpo, ferramentas forenses, bloqueadores de escrita, armazenamento, cabos, sacos para evidências e formulários de custódia. Revise o plano pelo menos anualmente e após incidentes graves ou mudanças significativas; teste se os contatos e acessos realmente funcionam.

Um roteiro de resposta apresenta etapas e decisões para um tipo de incidente, como phishing, ransomware, comprometimento de conta ou exfiltração de dados. Um procedimento operacional costuma ser um procedimento técnico mais específico, como isolar um host no console de detecção e resposta em endpoints (EDR). As equipes às vezes usam os termos de maneiras diferentes, portanto defina-os no plano.

Escreva decisões que os profissionais de resposta possam seguir

Um roteiro de resposta útil indica seu gatilho, as perguntas iniciais de triagem, as evidências a coletar, os papéis responsáveis, as ações de contenção e recuperação, os critérios de escalonamento, as etapas de comunicação e as condições de encerramento. Uma lista de verificação sozinha não pode decidir se uma conta de administrador comprometida precisa de uma resposta diferente da aplicada a uma conta comum.

Considere o relato: “Digitei minha senha em uma página de phishing.” Um roteiro de resposta pode orientar o profissional nestas ações:

1. Confirmar o relato e localizar a mensagem.
2. Usar registros de e-mail e proxy para identificar destinatários, cliques e usuários que inseriram credenciais.
3. Redefinir senhas expostas, revogar sessões e tokens e remover dispositivos de MFA adicionados pelo atacante.
4. Procurar acessos do atacante nos registros de entrada e verificar regras de caixa de correio que encaminhem ou ocultem mensagens.
5. Bloquear o remetente e a URL, remover a mensagem das caixas de correio e informar os usuários afetados.

Associe decisões às etapas. Por exemplo, faça o escalonamento se a conta for privilegiada ou se aparecerem entradas feitas pelo atacante. Indique quem aprova alterações que interrompem operações. A automação pode executar etapas de rotina, mas uma ação como desligar um servidor crítico mantém seu ponto de aprovação humana.

Treine para responsabilidades diferentes

Os profissionais de resposta praticam com SIEM, EDR, ferramentas forenses e procedimentos de evidência. Os líderes praticam decisões urgentes sobre interrupção de serviços e recursos. Todos os funcionários aprendem a relatar rapidamente atividades suspeitas e a preservar a situação para investigação. Apagar um notebook após encontrar uma mensagem de exigência de resgate pode destruir evidências e atrasar a determinação do escopo.

Um exercício de mesa testa decisões por meio de discussão. Um facilitador apresenta um cenário e depois acrescenta novas informações em etapas, chamadas estímulos de cenário. Os participantes usam o plano para explicar suas próximas ações. Isso expõe autoridade pouco clara, contatos ausentes e suposições conflitantes sem alterar sistemas de produção.

Uma simulação, ou exercício funcional, faz os participantes executarem ações com ferramentas em um ambiente de teste sob pressão de tempo. Ela pode revelar que um comando de isolamento falha ou que uma exportação de evidências demora mais do que o esperado. Um exercício em escala real envolve várias equipes e, muitas vezes, parceiros externos na resposta.

Transforme os achados do exercício em melhorias

Em um exercício de mesa sobre ransomware, cinco chamadas à central de suporte relatam a criptografia de uma unidade compartilhada às 07:30. Às 08:15, um estímulo revela arquivos de recursos humanos vazados. Às 10:00, um jornalista liga. A equipe deve decidir quem declara o incidente, quem aprova tirar os servidores do ar, quem fala publicamente e quais cópias de segurança podem ser restauradas primeiro.

Se ninguém souber o tempo de restauração, registre uma ação como: “Responsável pelo armazenamento: testar uma restauração completa do servidor de arquivos até o fim do trimestre e registrar a duração medida.” Atualize o roteiro de resposta e teste novamente. Um exercício é útil quando revela lacunas que a organização pode eliminar; tratá-lo como uma prova na qual é preciso passar incentiva as pessoas a esconder justamente as fraquezas que ele deveria encontrar.

Sinais de segurança chegam por alertas de SIEM e EDR, antivírus, ferramentas de detecção de rede, registros de eventos da nuvem e de identidade, ferramentas de prevenção contra perda de dados e relatos de pessoas dentro ou fora da organização. Um precursor aponta para um possível incidente futuro, como uma varredura ou um novo código de exploração para um software em uso. Um indicador aponta para uma atividade que pode já ter acontecido ou estar acontecendo.

Reúna contexto em torno do sinal

A coleta de registros de eventos torna acessíveis registros de endpoints, servidores, dispositivos de rede, sistemas de identidade e serviços de nuvem. Relógios sincronizados, normalmente mantidos pelo Protocolo de tempo de rede (NTP), ajudam a compará-los. A correlação relaciona registros por atributos como host, conta, endereço e horário. O enriquecimento acrescenta criticidade e responsável pelo ativo, função do usuário, localização e reputação em inteligência de ameaças.

Um grande upload de um servidor de backup durante sua tarefa agendada tem significado diferente do mesmo upload feito por um processo desconhecido em um notebook da recepção. A reputação pode ajudar a investigar um domínio, mas é apenas uma parte do contexto.

Faça a triagem

1. Leia o alerta e entenda o que a regra detectou.
2. Identifique o host, o usuário, o processo e o horário.
3. Verifique a importância do ativo, os privilégios, o comportamento normal e os chamados de mudança relevantes.
4. Examine logons, processos pai, conexões e arquivos relacionados.
5. Verifique a reputação de domínios, endereços e hashes de arquivos.
6. Decida se a atividade é benigna, um falso positivo ou uma suspeita de incidente. Faça o escalonamento de suspeitas não esclarecidas.

Um alerta que identifica corretamente uma atividade maliciosa é um verdadeiro positivo. Um falso positivo é acionado por uma atividade benigna. Um falso negativo é uma atividade maliciosa que não produziu alerta; ela não aparece na fila. Um verdadeiro negativo é uma atividade benigna sem alerta.

Siga as evidências até a declaração

Às 07:55 UTC, um alerta de EDR informa um comando PowerShell codificado em FIN-LT-042. Seu processo pai, WINWORD.EXE, abriu “Invoice_0310.docm” a partir de um e-mail. Em seguida, o PowerShell contatou um domínio registrado três dias antes. Esses achados justificam tratar o caso como suspeita de incidente e investigá-lo prontamente.

O analista decodifica o comando e descobre que ele baixa e executa um script na memória. Os registros do proxy confirmam o download, e o conteúdo do script comprova a execução maliciosa. O alerta agora é um verdadeiro positivo confirmado. O critério da organização, “execução confirmada de código malicioso em um endpoint da empresa”, fundamenta a declaração do incidente.

Um domínio recente ou um comando codificado, isoladamente, também pode ocorrer em trabalho legítimo. A decisão se baseia no conjunto dos achados e no critério documentado. Da mesma forma, a negativa de um usuário é insuficiente para encerrar o caso sem verificar os dados.

Mantenha o registro da resposta desde o início

Registre o número do chamado, quem fez o relato, o horário da detecção em UTC, as observações, as fontes de evidências e cada ação com quem a executou e o horário. Documente falsos positivos e encaminhe achados úteis para o ajuste fino. Se o antivírus informar “Ameaça removida”, investigue a chegada e a execução antes do encerramento: a remoção de um arquivo não responde se outro código foi executado, se credenciais foram expostas ou se há persistência.

A determinação do escopo estabelece os hosts, contas, aplicações, dados e locais afetados, bem como o ponto de entrada e se o atacante continua ativo. O primeiro host que gerou um alerta é o ponto de partida dessa busca. Novos achados podem ampliar o escopo durante a contenção e a erradicação.

Siga cada indicador útil

O pivoteamento investigativo consiste em pesquisar outras evidências usando um atributo encontrado no caso: hash, nome de arquivo, domínio, endereço, conta, chave de registro ou nome de tarefa. Um domínio malicioso em um notebook pode aparecer nos registros de proxy de outros dois notebooks. Um logon de um desses dispositivos em um servidor de arquivos acrescenta outro host e outra conta à investigação.

Para cada ramificação, pergunte como o acesso começou, o que foi executado, qual mecanismo de persistência foi instalado, quais contas foram usadas, por onde o atacante se movimentou, quais dados foram acessados ou exportados e quando a atividade apareceu pela primeira e pela última vez. Registre os sistemas como afetados, suspeitos ou verificados sem achados correspondentes; explique as evidências e a janela de busca que fundamentam cada situação.

Normalize os horários antes de ordenar

Uma linha do tempo combina horário, fonte, host, usuário e uma descrição do evento. Mantenha as marcas temporais e os deslocamentos originais, converta-os para UTC e registre erros conhecidos de relógio. Marcas temporais locais originais de fusos diferentes podem inverter a ordem aparente de um ataque.

Considere estes registros de uma investigação:

Subtraia um deslocamento positivo para obter UTC. Após a conversão, a entrega precede o logon, a execução e a conexão. Preserve também a data, pois a conversão pode atravessar a meia-noite. Um deslocamento registrado com o evento esclarece mudanças de horário de verão com mais confiabilidade do que apenas o nome de uma cidade.

Use volumes e intervalos de tempo com cuidado

Registros de fluxo de rede mostram 2,4 GB enviados para fora em 40 minutos. Em unidades decimais do SI, são 2.400 MB, e a duração é de 2.400 segundos:

A média é de 1 MB/s. Em uma estação de trabalho que normalmente envia apenas alguns megabytes por dia, isso é um forte motivo para investigar exfiltração. O volume não identifica os arquivos; combine-o com evidências de acesso a arquivos, processo e destino.

O tempo de permanência sem detecção vai do comprometimento inicial à detecção. De 2 de fevereiro às 14:00 UTC a 19 de fevereiro às 09:30 UTC são 16 dias e 19,5 horas. Um tempo maior dá ao atacante mais oportunidades e pode fazer com que a atividade inicial ultrapasse o prazo de retenção dos registros.

Mantenha a incerteza visível na linha do tempo

Marque achados confirmados separadamente de hipóteses e cite cada fonte de evidência. Escreva “Registros anteriores a 1º de março não estão disponíveis porque o prazo de retenção é de 30 dias” quando essa for a lacuna. Escrever “O atacante chegou em 1º de março” transformaria o início das evidências disponíveis em uma data de início sem fundamento. Revise a contenção quando novos pivoteamentos revelarem outro caminho de acesso.

A severidade descreve o impacto do incidente. A prioridade determina a ordem de trabalho com base no impacto e na urgência. Um upload em andamento de arquivos confidenciais pode exigir contenção imediata mesmo quando outro caso grave já está estável. O plano da organização fornece a escala, os critérios e as expectativas de resposta.

Avalie o impacto nos negócios

Considere o impacto funcional: quais serviços de negócios estão indisponíveis ou prejudicados? Considere o impacto sobre a informação: informações privadas ou proprietárias foram expostas, ou a integridade dos dados foi prejudicada? Em seguida, avalie a capacidade de recuperação: os recursos existentes podem restaurar o serviço de forma previsível, são necessários recursos extras, o esforço de recuperação é incerto ou a perda é irreversível?

Examine também a importância do ativo, os usuários e sistemas afetados, a sensibilidade dos dados e se o atacante ainda tem acesso. Um único controlador de domínio comprometido pode colocar muitos sistemas em risco. Contar hosts que geraram alertas sem considerar a função deles pode subestimar muito a severidade.

Aplique a escala do plano

Um exemplo de escala de quatro níveis é:

• Severidade 1, crítica: um serviço essencial aos negócios está indisponível, foi confirmado o roubo de dados confidenciais ou sujeitos a regulamentação, ou um atacante tem privilégios de administrador de domínio.
• Severidade 2, alta: servidores ou contas privilegiadas estão comprometidos, ou malware está se espalhando.
• Severidade 3, média: uma conta comum ou estação de trabalho foi comprometida e contida.
• Severidade 4, baixa: uma tentativa foi bloqueada ou uma violação de política não tem impacto.

Em um plano desse tipo, a severidade 1 pode exigir resposta em até 15 minutos a qualquer hora. Esses rótulos e prazos pertencem à escala do exemplo; em uma resposta real, aplique os critérios da organização em questão.

Escolha o próximo caso pelo risco e pela urgência

Chegam três casos: adware no notebook de um usuário comum; uma adição inesperada ao grupo Domain Admins às 03:12, registrada pelo evento 4728 do registro Security; e um site com conteúdo alterado, sem evidência atual de acesso a dados. Investigue primeiro a alteração no grupo privilegiado, pois o controle desse grupo por um atacante ameaça todo o domínio. A perda de integridade e o impacto público do site vêm em seguida; o caso limitado de adware fica por último.

O registro da adição ao grupo ainda precisa ser validado. Determine se ela foi autorizada, identifique a conta adicionada e verifique a atividade dessa conta. Um sinal de alto risco merece análise rápida mesmo antes de todas as implicações serem confirmadas. A classificação por tipo, como comprometimento de conta, ransomware ou ataque a aplicação web, permite selecionar o roteiro de resposta e a equipe especializada.

Faça o escalonamento e o encaminhamento à gestão de forma planejada

O NIST distingue escalonamento, que amplia os recursos ou prazos da resposta, de encaminhamento ao nível superior de gestão, que envolve um nível mais alto de gestão nas decisões de resposta. Um especialista forense ou uma empresa contratada previamente acrescenta capacidade de resposta; um CISO decidindo se interrompe um serviço crítico acrescenta autoridade de gestão. Ambos podem acontecer no mesmo caso.

Siga os gatilhos do plano: incidentes críticos chegam ao CISO, o envolvimento de dados pessoais leva à participação da assessoria jurídica e do encarregado de privacidade, e a suspeita de uso indevido por um funcionário leva à participação de recursos humanos. Atualize a severidade quando as evidências mudarem, registrando o horário e o motivo. Um caso inicialmente tratado como adware pode revelar um programa de roubo de credenciais e acesso mais amplo; sua classificação deve mudar com esses achados.

As evidências incluem memória, dados de disco, registros de eventos, capturas de pacotes, mensagens, capturas de tela, registros de auditoria da nuvem e anotações dos profissionais de resposta. A coleta começa pelas perguntas do caso e pelo risco de perder os dados necessários para respondê-las.

Trabalhe em ordem de volatilidade

A volatilidade descreve a facilidade com que os dados mudam ou desaparecem. A RFC 3227 apresenta esta ordem como exemplo, do mais ao menos volátil:

1. Registradores e cache da CPU.
2. Tabelas de roteamento e ARP, tabelas de processos, estatísticas do kernel e memória.
3. Sistemas de arquivos temporários.
4. Conteúdo do disco.
5. Dados de registro e monitoramento remotos.
6. Configuração física e topologia de rede.
7. Mídias de arquivamento, incluindo cópias de segurança.

Use essa ordem para planejar a coleta, verificando os prazos reais de retenção e as condições. Um registro da nuvem prestes a expirar precisa ser preservado prontamente. Vários profissionais de resposta podem preservar fontes diferentes em paralelo enquanto o responsável pelas evidências acompanha o trabalho.

Preserve dados de sistemas em execução antes de reiniciar

A resposta em sistema em execução reúne memória, processos, conexões, usuários conectados, arquivos abertos e outros dados variáveis de um sistema ligado. Reiniciar remove malware presente apenas na memória, conexões ativas e possíveis chaves de criptografia. O isolamento de rede pode interromper a comunicação enquanto mantém essas evidências disponíveis.

Use ferramentas confiáveis de mídias externas somente de leitura ou de uma plataforma de EDR. Os próprios utilitários do host suspeito podem ter sido alterados por um atacante. Carregar uma ferramenta de coleta ainda altera um sistema em execução: registre os comandos, o horário, os resultados e os efeitos inevitáveis dessa ferramenta para que outro analista possa entender a aquisição.

Escolha o método de aquisição adequado

Uma imagem forense de disco é uma cópia bit a bit, incluindo espaço não alocado e dados excluídos recuperáveis. Formatos comuns incluem imagens brutas dd e Expert Witness (E01). Uma cópia lógica coleta arquivos visíveis selecionados e deixa de fora outras áreas de armazenamento.

Para uma unidade fora de operação, use um bloqueador de escrita para impedir gravações na origem durante o imageamento. Sistemas em execução e volumes na nuvem usam ferramentas para sistemas em execução ou instantâneos do provedor; um bloqueador de escrita para unidades fora de operação não serve para essas aquisições. Documente o método de coleta e as alterações que ele pode causar.

Exporte registros de auditoria da nuvem e de identidade antes que a retenção os elimine. Capture instantâneos de discos virtuais e obtenha exportações de administrador das aplicações quando apropriado. O contrato com o provedor pode determinar como solicitar evidências das camadas que ele gerencia. Um instantâneo de disco preserva um estado do disco; colete a memória separadamente quando essa evidência volátil for necessária.

Acompanhe uma coleta em servidor em execução

Um alerta de EDR mostra extração de credenciais em um servidor de arquivos de produção. O profissional de resposta primeiro o isola pela contenção do EDR, mantendo o canal de gerenciamento de segurança. Em seguida, captura a memória em armazenamento externo e calcula imediatamente o hash da captura. A equipe então registra processos, conexões e entradas de inicialização automática; exporta os registros Security, System e do PowerShell; e captura um instantâneo de disco virtual ou uma imagem de disco.

Só após a preservação a equipe decide se desligará ou reconstruirá o sistema. Uma varredura completa de antivírus antes da coleta pode remover amostras e alterar metadados de arquivos. Quando a destruição em andamento não pode ser interrompida por isolamento, interromper o dano tem prioridade; registre por que a perda de evidências foi aceita.

As evidências são confiáveis quando a equipe consegue explicar de onde vieram, como foram manuseadas e se seu conteúdo mudou. Cadeia de custódia, verificações de integridade e armazenamento protegido respondem a partes diferentes dessa questão.

Registre cada transferência

A cadeia de custódia é o registro contínuo de coleta, manuseio, transferência e armazenamento. Atribua a cada item um identificador vinculado ao caso. Registre sua descrição, marca e modelo do dispositivo quando pertinente, número de série, local de coleta, responsável pela coleta, horário e valores de hash. Cada transferência exige remetente, destinatário, horário, finalidade, assinaturas e novo local de armazenamento.

Lacre e identifique os itens físicos. Armazene evidências digitais em local controlado com registro de acessos. Um hash correspondente não explica um período não documentado em que uma unidade esteve fora do armazenamento controlado; isso é uma lacuna de custódia, mesmo que os bytes sejam verificados corretamente depois.

Estabeleça uma referência de integridade

Um hash criptográfico converte dados em uma impressão digital de tamanho fixo. SHA-256 é uma escolha comum. MD5 e SHA-1 têm fraquezas conhecidas relacionadas a colisões, embora ferramentas possam registrá-los junto com SHA-256. Um valor SHA-256 correspondente fornece forte evidência de que uma cópia posterior tem os mesmos bytes do item registrado; ele não identifica quem criou esses bytes.

Para uma origem estável, como uma unidade desligada, calcule o hash da origem na aquisição e verifique a imagem em relação a ele. A origem deve permanecer estável para que essa comparação tenha significado. Para memória em execução, faça a captura primeiro e calcule imediatamente o hash do arquivo resultante. A memória muda durante a aquisição, portanto tentar calcular o hash da memória em execução duas vezes não fornece uma referência reproduzível da origem.

Uma pequena alteração no conteúdo pode produzir uma impressão digital muito diferente. O texto “Case IR-2026-0142” tem o prefixo SHA-256 45a24047; alterar o último dígito para formar “Case IR-2026-0143” produz 8e5320c9. Registre o hash completo para verificar evidências; esses prefixos curtos ilustram a alteração.

Verifique transferências e analise cópias

Suponha que o hash do item de captura de memória M-03 seja calculado na aquisição. Antes de um segundo analista abrir uma cópia transferida, esse analista recalcula o SHA-256 da cópia e o compara com o valor de aquisição registrado. Uma divergência significa que a cópia não passou na verificação. Verifique o item de origem, a transferência, o armazenamento e possíveis erros de aquisição antes de confiar na cópia; faça uma nova aquisição quando possível.

Calcule o hash na aquisição, após transferências e antes da análise. Mantenha o original preservado como referência e analise cópias de trabalho verificadas. Registre os hashes no registro de evidências, onde sua relação com o item e o horário fique clara.

Preserve os dados pelo tempo necessário

A preservação inclui armazenamento somente de leitura ou de gravação única, recipientes criptografados para evidências, acesso controlado e exportações de registros que de outra forma expirariam. Suspenda a exclusão ou rotação dos registros necessários à investigação.

Uma obrigação de preservação para fins jurídicos, normalmente emitida pela assessoria jurídica, exige a preservação de informações relevantes para uma ação judicial ou investigação real ou razoavelmente esperada. Ela prevalece sobre os cronogramas normais de exclusão dos dados, das pessoas e dos sistemas indicados. A equipe de TI confirma que a exclusão foi interrompida e mantém a obrigação até que a assessoria jurídica a encerre. Reconstruir um notebook não autoriza apagar sua unidade original sujeita à preservação.

A perícia digital transforma dados preservados em respostas sobre entrada, execução, uso de contas, persistência, movimentação e perda de dados. Comece por essas perguntas do caso para que o exame tenha um propósito.

Siga as quatro fases forenses

A NIST SP 800-86 descreve coleta, que identifica e adquire dados; exame forense, que extrai informações relevantes preservando a integridade; análise, que interpreta esses achados; e elaboração do relatório, que explica achados, métodos, ferramentas e recomendações. Extrair uma linha de comando é exame. Decidir o que ela mostra sobre o incidente é análise.

Leia registros do Windows em contexto

O registro Security pode mostrar os seguintes eventos, quando a auditoria correspondente está habilitada:

O evento 7045 no registro System registra a instalação de serviço. O registro de blocos de script do PowerShell usa o evento 4104 em um registro do PowerShell. Mantenha o canal junto ao ID do evento para que outro analista possa recuperar o registro correto.

Falhas repetidas seguidas de sucesso para a mesma conta sugerem tentativas de adivinhação de senha, mas verifique também a origem e a autorização. A adição a um grupo pode ser administração rotineira ou obtenção de privilégios por um atacante. O registro estabelece a ação; as evidências relacionadas estabelecem seu significado.

A persistência no Windows pode aparecer nas chaves de registro Run e RunOnce, em tarefas agendadas ou em serviços. O Prefetch pode mostrar que um programa foi executado, quando e com que frequência em sistemas onde está habilitado. Histórico do navegador, downloads, conteúdo da Lixeira e metadados da tabela mestre de arquivos ($MFT) acrescentam informações sobre atividades de arquivos e usuários.

Verifique evidências do Linux, de memória e de rede

Registros de autenticação do Linux costumam aparecer em /var/log/auth.log no Debian e Ubuntu e em /var/log/secure em sistemas baseados no Red Hat. Examine o histórico do shell, como ~/.bash_history, tarefas do cron, unidades do systemd, /etc/passwd, chaves adicionadas em ~/.ssh/authorized_keys e registros de acesso web. O histórico e os registros locais podem estar incompletos ou alterados, portanto procure registros independentes.

A análise de memória, por exemplo com o Volatility, pode revelar processos, código injetado, módulos carregados, linhas de comando e conexões que nunca chegaram ao disco. Pacotes e registros de fluxo de rede fornecem destinos, horários e volumes. O tráfego criptografado ainda deixa metadados úteis mesmo quando seu conteúdo não está disponível.

Construa e questione uma explicação

Às 02:09 UTC, o evento 4624 do tipo 10 registra o logon de svc_backup a partir de um host interno. O Prefetch mostra que RCLONE.EXE foi executado pela primeira vez às 02:14. Os fluxos do firewall mostram 2,4 GB enviados para fora entre 02:15 e 02:55. A sequência sustenta uma hipótese de acesso por RDP seguido de um upload com rclone.

Para estabelecer a ligação, procure telemetria de rede vinculada ao processo, a linha de comando, a configuração ou registros do rclone e evidências de que esse uso da conta não foi autorizado. Um administrador legítimo pode usar o mesmo software. Relate os fatos observados separadamente da interpretação e informe quais lacunas permanecem.

A antiforense tenta ocultar atividades por meio de limpeza de registros, exclusão ou alteração de marcas temporais. O evento 1102 pode revelar a limpeza do registro Security. Horários de criação NTFS em $STANDARD_INFORMATION anteriores aos de $FILE_NAME podem indicar adulteração de marcas temporais. Investigue esses indícios junto com outros artefatos; a ausência de registros locais deixa uma questão a ser testada com registros remotos e outras evidências.

A contenção limita danos, propagação e perda de dados enquanto cria tempo para a investigação. Escolha-a cedo, usando o plano, o escopo conhecido e as consequências de deixar o atacante ativo.

Compare as vantagens e desvantagens

Considere os danos potenciais e o roubo de recursos, a preservação de evidências, a disponibilidade do serviço, o tempo e os recursos necessários, a eficácia e a duração. Uma medida que funciona por horas pode ser inadequada por várias semanas. Registre o efeito esperado e o custo para os negócios para que a decisão possa ser reavaliada conforme o escopo muda.

A contenção de curto prazo age imediatamente: isolar um host, desconectar um caminho de rede, bloquear um domínio ou endereço do atacante, desativar uma conta comprometida, revogar sessões e tokens ou interromper um serviço. A contenção de longo prazo mantém o trabalho essencial funcionando sob restrições enquanto a erradicação é preparada. Ela pode usar um segmento de rede restrito, permissões mais rígidas, regras temporárias de firewall, correções emergenciais e monitoramento ampliado.

Distinga níveis de restrição

A segmentação limita quais sistemas podem se comunicar. O isolamento corta a comunicação de um host, exceto, possivelmente, com seu canal de gerenciamento de segurança. A remoção tira um sistema de operação por completo, por exemplo, desligando-o. O desligamento causa a perda da memória volátil; o isolamento de rede bem-sucedido pode preservar essa evidência enquanto bloqueia as comunicações do atacante.

Um console de EDR pode informar uma solicitação de isolamento antes que ela seja bem-sucedida. Verifique o estado resultante e o tráfego. Verifique também se o canal de gerenciamento permitido alcança apenas a infraestrutura de segurança necessária para a resposta.

Coordene os caminhos de acesso conhecidos

Se um atacante tiver vários pontos de apoio, bloquear um host pode alertá-lo enquanto outros acessos permanecem disponíveis. Ele pode trocar de conta, destruir dados ou iniciar a criptografia. A contenção coordenada remove os caminhos conhecidos ao mesmo tempo após uma determinação de escopo suficiente. Criptografia ou exfiltração em andamento exige ação imediata para interromper o dano; esperar conhecimento perfeito pode piorar a perda.

Em um caso de phishing, FIN-LT-042 e FIN-LT-057 contataram o domínio do atacante, e uma conta de administrador do setor financeiro acessou um servidor de arquivos. Às 10:30 UTC, os profissionais de resposta isolam ambos os notebooks, bloqueiam o domínio no DNS e no proxy, desativam a conta de administrador e revogam suas sessões. Depois, restringem o acesso ao servidor de arquivos, acrescentam registros de eventos e continuam as buscas de indicadores em todo o ambiente.

A coordenação abrange hosts, acesso à rede e identidade. Desativar apenas uma conta local pode deixar utilizável um token de nuvem existente. Inclua essas sessões no plano de contenção e verifique o resultado nos registros de identidade.

Verifique se a contenção se mantém

Confirme o estado de isolamento no EDR, inspecione registros de DNS e proxy em busca de novas conexões do atacante e verifique se contas comprometidas ainda conseguem se autenticar. Procure atividades associadas a indicadores recém-descobertos e revise os limites da contenção quando necessário.

Algumas organizações optam pela observação controlada para aprender mais sobre um invasor antes da contenção. Como isso mantém um caminho para novos danos, a escolha exige aprovação da liderança e da assessoria jurídica. Excluir o arquivo de malware detectado também é insuficiente como estratégia de contenção: outros acessos, mecanismos de persistência e identidades expostas podem continuar ativos mesmo após o desaparecimento desse arquivo.

A erradicação remove o atacante e o que ele deixou: malware, portas dos fundos, shells web, tarefas, serviços, entradas de registro, contas, chaves SSH e outros mecanismos de persistência. A remediação corrige as fraquezas que tornaram a intrusão possível. Ambas dependem da verificação de todo o escopo do incidente.

Decida se a confiança pode ser restaurada pela limpeza

Reconstruir a partir de uma imagem reconhecidamente confiável ou de um modelo de infraestrutura como código é mais confiável quando um atacante tinha privilégios de administrador, usou um rootkit ou deixou persistência desconhecida. A limpeza direcionada pode ser adequada para malware comum bem compreendido em um sistema de baixo valor, desde que a verificação cubra as alterações conhecidas.

Uma cópia de segurança feita após o comprometimento pode restaurar o acesso do atacante junto com arquivos legítimos. Antes de usá-la, verifique quando o comprometimento começou, o que a cópia contém e se a imagem ou o modelo é confiável. Preserve as evidências necessárias antes de reconstruir um sistema afetado.

Remova o acesso por identidades e os arquivos

Contenha prontamente contas e sessões comprometidas. Coordene a substituição duradoura de credenciais após fechar os caminhos de acesso do atacante e estabelecer um local limpo para usar os novos segredos. Caso contrário, um invasor pode roubar as credenciais substitutas do mesmo host comprometido.

Redefina credenciais expostas de usuários e serviços, revogue tokens, sessões e chaves de API e faça a rotação de segredos de aplicações. Remova métodos de MFA, regras de encaminhamento e contas não autorizadas adicionados pelo atacante. Considere todas as credenciais expostas em sistemas comprometidos, incluindo contas que ainda não geraram seu próprio alerta.

Em caso de suspeita de tíquetes Kerberos forjados, a recuperação coordenada do Active Directory inclui redefinir a senha KRBTGT duas vezes, com replicação entre as redefinições. Os controladores de domínio podem aceitar tíquetes protegidos pela senha atual ou anterior, portanto uma única redefinição mantém a chave anterior válida. Essa é uma ação coordenada de domínio com verificação, não uma etapa isolada de limpeza de estação de trabalho.

Corrija a causa e verifique a correção

Aplique correções ao software explorado, corrija configurações incorretas, exija MFA onde não havia, remova privilégios excessivos e feche serviços expostos. Se uma correção completa não estiver disponível, aplique um controle compensatório, como uma regra de firewall de aplicações web ou acesso apenas por VPN, e registre o risco remanescente.

Um servidor público contém um shell web introduzido por uma falha de upload sem correção. A equipe verifica se há outros servidores vulneráveis e encontra mais dois. Ela reconstrói os três a partir de um modelo com configurações reforçadas, implanta a aplicação corrigida, faz a rotação do segredo do banco de dados armazenado na configuração da aplicação e procura requisições ao shell web nos registros dos servidores.

Uma varredura de vulnerabilidades confirma que a falha foi corrigida. A equipe verifica locais de persistência, executa varreduras com assinaturas atualizadas, procura todos os indicadores conhecidos e monitora logons e conexões do atacante. Nesse caso, sete dias de monitoramento não mostram requisições bem-sucedidas ao caminho do shell web. Os critérios de erradicação do plano determinam se essas evidências são suficientes.

Corrigir a falha de upload fecharia um caminho de entrada, mas deixaria intacta qualquer porta dos fundos existente. Excluir apenas o shell web removeria um artefato, mas deixaria a aplicação explorável em operação. Portanto, a verificação precisa de evidências tanto sobre o acesso remanescente do atacante quanto sobre a correção da fraqueza.

A recuperação devolve sistemas e serviços à operação normal por meio de restauração, reconstrução, reconexão e testes funcionais. Ela pode começar para sistemas não afetados ou verificados como limpos enquanto a erradicação continua em outros locais.

Selecione fontes confiáveis de restauração

Verifique se as cópias de segurança apresentam corrupção, criptografia e sinais de comprometimento. Escolha um ponto anterior à entrada do atacante e verifique a versão ou o hash das imagens de reconstrução. Uma cópia recente pode conter o mesmo mecanismo de persistência que a equipe acabou de remover. A data, por si só, não comprova que a cópia está limpa.

Identifique o trabalho que a restauração deixará de fora. Uma cópia de segurança de 3 de março às 23:00 UTC é 7 horas e 20 minutos anterior a um comprometimento iniciado em 4 de março às 06:20 UTC. Esse intervalo corresponde à idade da cópia no momento do comprometimento. Restaurá-la faz perder todas as alterações posteriores até a retirada do sistema de operação, incluindo trabalho legítimo realizado após as 06:20, a menos que alterações limpas possam ser recuperadas de outras fontes.

Possíveis fontes incluem arquivos verificados como limpos ou cópias locais dos usuários. Valide-os antes de incorporar as alterações recuperadas para que a restauração não reintroduza conteúdo malicioso nem sobrescreva dados confiáveis.

Restaure na ordem das dependências

As prioridades dos negócios e as dependências técnicas atuam em conjunto. Uma aplicação ERP precisa de seu banco de dados; o banco de dados e a aplicação podem precisar primeiro de serviços de rede, DNS e identidade. Uma ordem típica é rede e identidade, banco de dados, ERP e, depois, ferramentas de relatórios. Iniciar a aplicação primeiro pode produzir um processo em execução sem um serviço útil por trás dele.

Use as metas de recuperação acordadas, incluindo o tempo de indisponibilidade e a perda de dados aceitáveis, como insumos para definir a ordem. Confirme que os próprios serviços dos quais os sistemas dependem são confiáveis antes de conectar os sistemas restaurados a eles. Uma aplicação crítica conectada a um serviço de identidade comprometido continua exposta.

Aplique os critérios de liberação do isolamento

Antes de reconectar, verifique se o sistema foi reconstruído ou limpo, recebeu as correções e está livre de mecanismos de persistência conhecidos. Faça a rotação das credenciais expostas, confirme que as ferramentas de segurança estão funcionando e enviando informações, estabeleça monitoramento reforçado e obtenha a aprovação do responsável pelo ativo. Reconecte em etapas para que comportamentos inesperados possam ser contidos antes de afetar todo o serviço.

Para o servidor de arquivos reconstruído, a equipe restaura uma cópia de segurança verificada, procura indicadores conhecidos nos dados, restaura as permissões e pede ao responsável que teste a abertura e a alteração de arquivos representativos. As verificações de segurança incluem o envio de informações pelo EDR e as conexões esperadas. O responsável aprova a liberação do serviço após esses testes, e a equipe inicia o período de monitoramento acordado.

Distinga a liberação do fim da recuperação

Compare processos, conexões, desempenho e comportamento do serviço com a linha de base normal. O monitoramento reforçado pode durar 30 dias em um plano de resposta, com alertas adicionais para os indicadores do incidente. Defina o período e os critérios conforme o caso e o plano.

O gestor de incidentes declara a recuperação concluída quando os serviços estão restaurados e estáveis, o período de monitoramento não mostra atividade do atacante e a documentação da resposta está completa.

O ransomware criptografa dados ou bloqueia sistemas e exige pagamento pelo acesso. Na dupla extorsão, os atacantes também roubam dados e ameaçam publicá-los. A extorsão com dados pode ocorrer sem criptografia, portanto o dano visível aos arquivos é apenas uma parte da investigação.

Reconheça a atividade antes da criptografia

Uma sequência comum de ataque começa com phishing, credenciais de acesso remoto roubadas ou uma vulnerabilidade exposta. Os atacantes descobrem sistemas, roubam credenciais, movimentam-se lateralmente, desativam ferramentas de segurança, atacam cópias de segurança e exfiltram dados antes da criptografia em massa.

Os sinais de alerta incluem ferramentas inesperadas de gerenciamento remoto, novas contas privilegiadas, grandes uploads e exclusão de cópias de sombra. Um comando como vssadmin delete shadows precisa ser investigado no contexto de seu processo e usuário. Esses precursores podem dar aos defensores uma oportunidade de intervir antes do início da criptografia generalizada.

Siga as três primeiras etapas de resposta

A lista de verificação de ransomware da CISA apresenta estas ações em ordem:

1. Identifique e isole imediatamente os sistemas afetados. Priorize os sistemas críticos. Se vários sistemas ou sub-redes forem afetados, desconecte no nível dos switches quando necessário. Proteja sistemas críticos não afetados e cópias de segurança dos mesmos caminhos de acesso.
2. Desligue apenas se a desconexão da rede for impossível. O desligamento sacrifica evidências voláteis, incluindo possíveis chaves e atividades presentes apenas na memória, mas pode ser necessário para impedir maior propagação quando o isolamento não puder ser realizado.
3. Faça a triagem dos sistemas para restauração. Use a lista de ativos críticos e as dependências técnicas para identificar quais serviços devem voltar primeiro.

Coordene por telefone ou outro canal alternativo. Os atacantes podem monitorar o e-mail ou chat da empresa e reagir acelerando a destruição. Verifique se o isolamento foi bem-sucedido antes de confiar nele.

Preserve evidências e estabeleça o alcance do ataque

Capture evidências de memória e disco de uma amostra representativa dos sistemas afetados e crie instantâneos dos volumes relevantes na nuvem. Preserve mensagens de exigência de resgate, extensões de arquivos criptografados, amostras de malware, registros de eventos e indicadores. Esses elementos ajudam a identificar a variante, reconstituir a entrada e a movimentação e apoiar a investigação dos parceiros de resposta.

Use a mensagem, a extensão e as amostras para verificar se há uma ferramenta de descriptografia disponível por meio de serviços confiáveis, como o No More Ransom, ou das autoridades de investigação. Investigue também o acesso anterior e a exfiltração. Recuperar arquivos criptografados não esclarece se os atacantes ainda têm uma conta, um token ou uma porta dos fundos.

Às 03:40 UTC de um sábado, dois servidores de arquivos apresentam cerca de 1.200 alterações de nome por minuto, ou 20 por segundo, com a extensão “.lckd”. O profissional de resposta isola os servidores e o controlador de domínio usado pela conta do atacante, e a equipe de rede desativa o enlace de saída do segmento afetado. Os sistemas permanecem ligados. Um profissional captura a memória de um servidor e salva a mensagem enquanto outro verifica as cópias de segurança protegidas.

Acione os parceiros de resposta previstos no plano

O gestor de incidentes envolve a liderança, a assessoria jurídica, a seguradora e as autoridades de investigação conforme o plano. As condições do seguro podem exigir aviso imediato ou empresas de resposta aprovadas. A assessoria jurídica determina as obrigações de notificação aplicáveis quando há dados envolvidos. Acompanhe essas frentes enquanto a contenção técnica continua. Uma reinstalação imediata destruiria evidências e poderia devolver um servidor a uma rede na qual o atacante ainda tem acesso.

A recuperação após ransomware deve eliminar a capacidade do atacante de repetir o dano. Contenha os acessos conhecidos, erradique a persistência, estabeleça um ambiente limpo, substitua credenciais expostas e restaure dados verificados em sistemas reconstruídos. Devolva à operação apenas sistemas verificados como limpos.

Proteja e teste a fonte de recuperação

Cópias de segurança desconectadas, imutáveis ou protegidas de outra forma podem sobreviver a tentativas de excluir cópias on-line. Antes do uso, verifique se o ponto selecionado é anterior ao comprometimento, não está criptografado e não contém ferramentas ou mecanismos de persistência conhecidos do atacante. Uma cópia não criptografada feita durante o período de permanência do atacante ainda pode ser insegura.

Meça antecipadamente a taxa de transferência na restauração. Em unidades decimais do SI, 48 TB são 48.000.000 MB. A uma taxa medida de 400 MB/s, a transferência contínua leva:

Isso corresponde a 120.000 segundos, ou cerca de 33,3 horas. Se os serviços críticos exigirem apenas 6 TB, sua transferência será:

Isso corresponde a cerca de 4,2 horas. Esses são tempos de transferência. Reconstruções, validação, dependências e reconexão também levam tempo, portanto devem constar da estimativa de recuperação operacional. Restaure os serviços críticos na ordem das dependências em vez de colocar todos os conjuntos de dados na fila com a mesma prioridade.

Investigue a infraestrutura de identidade

Ataques de ransomware operados por pessoas frequentemente envolvem credenciais privilegiadas roubadas. Estabeleça se contas privilegiadas, controladores de domínio ou KRBTGT foram comprometidos. Quando o comprometimento do domínio é confirmado ou há suspeita fundamentada, coordene a recuperação do domínio: reconstrua ou restaure controladores confiáveis, redefina credenciais privilegiadas e de serviço, revise a Política de Grupo e faça as redefinições necessárias de KRBTGT com replicação entre elas.

A Política de Grupo pode distribuir alterações para muitas máquinas. Deixar uma política maliciosa ou uma identidade confiável controlada pelo atacante em operação pode comprometer reconstruções de servidores que, de outra forma, estariam limpas. O escopo determina a extensão necessária desse trabalho; a criptografia em uma única estação de trabalho, por si só, não comprova comprometimento do domínio.

Entenda o que o pagamento pode e não pode resolver

A CISA e o FBI desaconselham o pagamento de resgate. Um pagamento não garante uma ferramenta de descriptografia funcional nem a exclusão dos dados roubados. Ferramentas de descriptografia podem ser lentas, defeituosas ou incompletas. O pagamento financia novos crimes, e a vítima pode voltar a ser alvo. Em 2021, o Escritório de Controle de Ativos Estrangeiros (OFAC) do Departamento do Tesouro dos Estados Unidos alertou que pagamentos de ransomware podem violar sanções. A liderança trabalha com a assessoria jurídica e geralmente com a seguradora; um analista não decide pagar.

Apresente à liderança opções de recuperação verificadas, tempos de restauração medidos, exposição de dados conhecida e questões não resolvidas. Consulte fontes confiáveis de ferramentas de descriptografia antes de tratar o pagamento como única opção. Uma ferramenta de descriptografia não remove a persistência nem corrige o caminho de acesso inicial.

Continue a resposta ao roubo de dados

O serviço restaurado não resolve a divulgação. Identifique quais dados foram levados e quem foi afetado, apoie a avaliação das notificações pela assessoria jurídica e monitore sites de vazamentos relevantes. Uma promessa do atacante de excluir as cópias não pode ser verificada.

Depois, reforce as cópias de segurança protegidas e os testes de restauração, exija MFA no acesso remoto e detecte atividades iniciais, como a exclusão de cópias de segurança. Compartilhe indicadores apropriados com autoridades ou grupos setoriais pelo processo aprovado da organização.

Uma revisão pós-incidente, ou revisão de lições aprendidas, examina o que aconteceu, como a resposta funcionou e o que deve mudar. Compartilhe lições úteis assim que surgirem durante o incidente. Realize uma revisão estruturada após incidentes significativos enquanto as evidências e decisões ainda estão recentes.

Prepare um relato compartilhado do incidente

Uma revisão geralmente ocorre entre alguns dias e duas semanas após o encerramento. Reúna os profissionais de resposta, a equipe de tecnologia, os responsáveis pelos ativos, a gestão e outras partes envolvidas. Use um facilitador para manter o foco da discussão. Um incidente grave merece uma revisão própria; casos menores podem ser agrupados em sessões regulares.

Prepare a linha do tempo do incidente, o registro de ações, o escopo, o impacto e as medições relevantes. Distinga o que era conhecido no momento de uma decisão das informações descobertas depois. Caso contrário, a equipe pode julgar uma escolha inicial razoável usando fatos que não estavam disponíveis a quem a tomou.

Pergunte sobre a resposta e também sobre o ataque

Examine o que aconteceu e quando, como ocorreu a detecção e quais etapas funcionaram bem. Depois, examine atrasos, instruções pouco claras, ferramentas e permissões ausentes e informações necessárias mais cedo. Identifique os precursores ou indicadores que poderiam revelar outra tentativa.

Uma revisão sem culpabilização concentra-se em sistemas, processos e decisões. Registrar que alguém clicou em um link de phishing é necessário para explicar a entrada. Parar aí oferece pouca orientação sobre por que um clique permitiu acesso a um servidor de arquivos. Pergunte quais controles, privilégios e disposições de resposta permitiram que o impacto aumentasse.

Mantenha o que funcionou e corrija o que falhou

Em uma resposta a phishing, o EDR detectou a execução em até 15 minutos. Mantenha a detecção e verifique se ela continua eficaz. A contenção levou 2,5 horas porque o analista de plantão não tinha permissão de isolamento no EDR. Crie uma alteração de acesso específica com responsável e teste, usando os limites de autoridade do plano.

O servidor de arquivos não tinha auditoria de acesso a arquivos, portanto a equipe não conseguiu estabelecer quais arquivos foram lidos. Registre essa lacuna de evidências e habilite uma auditoria adequada. O roteiro de resposta para contas omitia a revogação de tokens de nuvem; atualize-o e faça os profissionais de resposta praticarem a etapa revisada. Esses achados tratam de falhas diferentes e precisam de ações separadas.

Escreva um relatório pós-ação que possa ser usado

O relatório contém resumo executivo, descrição e linha do tempo do incidente, escopo e impacto, causa raiz e fatores contribuintes, ações de resposta com horários, o que funcionou e o que falhou, ações corretivas com responsáveis e prazos e métricas do incidente. Use as evidências para fundamentar os achados e mantenha visíveis as questões não resolvidas.

Incorpore as mudanças aprovadas ao plano, aos roteiros de resposta, às detecções, às listas de contatos, ao treinamento e ao registro de riscos. Compartilhe indicadores ou lições com grupos apropriados pelo processo aprovado. Defina onde acompanhar a lista de ações para que reuniões posteriores possam verificar o progresso.

“Melhorar a comunicação” deixa indefinidos o responsável, a mudança e o teste de sucesso. Uma ação útil poderia especificar uma conferência telefônica separada para incidentes, seu responsável, um prazo e um teste para verificar se a equipe de plantão consegue participar sem acesso ao sistema de identidade da empresa. A revisão como reunião está concluída; o trabalho de melhoria continua até que suas ações sejam verificadas.

A análise de causa raiz pergunta por que existiam as condições para um incidente. A causa imediata é a causa técnica direta. Os fatores contribuintes tornaram o incidente mais provável ou mais danoso. Uma falha subjacente de processo pode explicar por que esses fatores permaneceram.

Acompanhe as causas além da primeira falha

A técnica dos 5 porquês pergunta repetidamente por que uma falha foi possível. O nome descreve uma abordagem, não uma exigência de parar exatamente em cinco perguntas. Em um caso de ransomware:

1. Os servidores foram criptografados porque o atacante obteve privilégios de administrador de domínio.
2. Essas credenciais foram obtidas em um servidor acessível.
3. O atacante chegou a ele por meio de uma conta de VPN de prestador de serviços sem MFA.
4. A conta tinha uma dispensa temporária de MFA desde uma migração realizada dois anos antes.
5. As dispensas não tinham prazo de validade nem processo de revisão.

A ausência de um processo de revisão é uma causa subjacente nessa cadeia. A ausência de MFA e as credenciais privilegiadas expostas continuam sendo fatores técnicos a corrigir. Um diagrama de Ishikawa (espinha de peixe) agrupa possíveis causas em categorias como pessoas, processo, tecnologia e ambiente. A análise de linha do tempo pergunta qual controle poderia ter impedido ou revelado cada etapa.

Escreva ações com comprovação de conclusão

Uma ação corretiva precisa de uma mudança específica, responsável, prazo, resultado mensurável e verificação. Por exemplo: “Exigir MFA em todas as 214 contas de VPN até 30 de novembro; responsável: líder de gestão de identidades e acessos; verificar com um relatório mostrando zero contas de VPN sem MFA.”

Acompanhe as ações no sistema de chamados ou de riscos e teste se funcionam, inclusive em um exercício posterior. Ações preventivas reduzem a recorrência; ações de detecção revelam a próxima tentativa mais cedo. Acrescentar uma revisão de validade trata o processo de dispensa, enquanto um alerta para o uso de contas dispensadas acrescenta detecção. Uma única ação não precisa contemplar todas as partes da solução.

Defina a métrica antes de calculá-la

O tempo médio de detecção (MTTD) é a média do intervalo entre o início da atividade maliciosa e sua detecção. O tempo de contenção geralmente vai da detecção à contenção; o tempo de remediação vai da detecção à correção. As equipes também acompanham o tempo de permanência sem detecção, categorias e severidade de incidentes e casos detectados internamente em comparação com os relatados externamente. Informe os pontos de início e fim, pois as organizações usam alguns nomes de métricas de formas diferentes.

Quatro tempos de detecção são 2, 30, 6 e 82 horas:

A média é de 30 horas. Ordene os valores como 2, 6, 30 e 82; a mediana é a média dos dois valores centrais:

O caso de 82 horas eleva a média consideravelmente. Informe as duas medidas e investigue esse caso. Se a contenção levou 1,5; 4; 3 e 9,5 horas, a média é 18 dividido por 4, ou 4,5 horas.

Compare tendências apenas com definições consistentes e contexto adequado. Uma equipe recompensada apenas pelo encerramento rápido de chamados pode encerrar casos antes do fim da análise. Combine rapidez com evidências de resposta completa e ações verificadas para que a métrica apoie a melhoria.