Esta página faz parte do nosso guia para montar um plano de resposta a incidentes e detalha a etapa 7: a lista da primeira hora e um playbook para cada um de cinco incidentes comuns. O guia sobre o conteúdo do plano cobre as funções, o escalonamento e os níveis de gravidade em que esses playbooks se apoiam.
Uma lista de verificação da primeira hora
A primeira hora define o que vem depois. Trate esta lista como um ponto de partida, não como uma sequência estrita. A contenção pode precisar acontecer nos primeiros minutos, enquanto a preservação das evidências e a avaliação da notificação ocorrem paralelamente, e alguns itens levarão bem mais de uma hora para serem concluídos. Pule o que não se aplica ao incidente à sua frente; cabe ao líder do incidente garantir que cada item aplicável tenha um responsável.
- Abra o registro de decisões: quando o incidente foi detectado, quem o relatou e o que viu
- Nomeie o líder do incidente e confirme quem o substitui
- Atribua um primeiro nível de gravidade, sabendo que pode mudar
- Mova a equipe de resposta para o canal fora de banda se o e-mail, o chat ou o SSO puderem estar comprometidos, e confirme ali a identidade de cada pessoa
- Contenha sem destruir evidências: desconecte os sistemas afetados da rede em vez de desligá-los ou apagá-los
- Preserve logs que são sobrescritos rapidamente, como firewall, VPN, provedor de identidade, auditoria de e-mail e logs de detecção de endpoint
- Proteja os backups: confirme que estão off-line ou imutáveis e corte o acesso de rede ao sistema de backup se ele estiver comprometido
- Ligue para a linha de incidentes da sua seguradora cibernética e para o jurídico; muitas apólices exigem aviso à seguradora antes da contratação de equipes externas
- Se houver dados pessoais envolvidos, registre o momento em que você tomou conhecimento e comece a avaliar se é preciso comunicar
- Informe o patrocinador executivo: o que é conhecido, o que não é, o que foi feito e quando será a próxima atualização
Playbooks por tipo de incidente
O plano cobre a estrutura e os playbooks cobrem os cenários. O plano diz às pessoas qual processo seguir; o playbook diz o que fazer naquele tipo específico de incidente. Escreva playbooks para os tipos de incidente mais relevantes para sua organização. Os cinco abaixo cobrem os cenários mais frequentes.
Ransomware
Indicadores de detecção (mudanças na extensão do arquivo, eventos de acesso em massa a arquivos, notas de resgate aparecendo, atividade de exclusão de backup). Etapas de isolamento imediato: desconecte os sistemas afetados da rede sem desligá-los onde a preservação forense for necessária. Verifique a integridade do backup e o ponto de recuperação antes de continuar. Estabeleça se os dados foram copiados antes da criptografia, porque muitos grupos de ransomware agora também roubam dados, o que altera tanto a avaliação da notificação quanto o risco de extorsão. Restaure num ambiente sabidamente limpo, e não em sistemas que ainda possam conter ferramentas do invasor. Acione o jurídico e a seguradora cibernética antes de qualquer comunicação externa ou decisão de pagamento. Avalie se há obrigação de comunicar (houve acesso a dados pessoais ou criptografia deles?). Estabeleça um canal de comunicação limpo fora do ambiente afetado. A decisão sobre pagar o resgate deve seguir um processo estruturado, com o jurídico, a seguradora e a liderança, e não ser tomada às pressas.
Comprometimento de e-mail corporativo (BEC) e desvio de pagamento
Se for descoberta uma instrução de pagamento fraudulenta, entre em contato imediatamente com o banco remetente. Muitos bancos têm procedimentos de bloqueio e devolução em caso de fraude que podem recuperar o dinheiro em poucas horas, se acionados antes que a conta de destino seja esvaziada. Se o pagamento foi por Pix, peça ao seu banco que acione o Mecanismo Especial de Devolução (MED). Preserve todas as evidências de e-mail, incluindo cabeçalhos, antes de redefinir contas. Em seguida, redefina a senha, revogue as sessões ativas e atualize os tokens e verifique os métodos MFA registrados, porque os invasores geralmente adicionam os seus próprios; onde houver suspeita de comprometimento, remova-os e peça ao usuário que cadastre o MFA de novo. Identifique se outras contas estavam envolvidas, se foram definidas regras de encaminhamento ou de caixa de entrada e se algum aplicativo OAuth recebeu acesso. Avise as partes afetadas, como fornecedores ou clientes, se os dados ou pagamentos delas estiverem envolvidos.
Incidente com dados pessoais
Um incidente com dados pessoais vai além do roubo. Inclui dados pessoais enviados para a pessoa errada, um laptop perdido ou roubado, registros alterados ou excluídos sem autoridade e dados indisponíveis, por exemplo, quando o ransomware criptografa a única cópia. Levante os dados afetados: quais categorias, quantos titulares, em que período. Avalie o risco para os titulares e decida se precisa comunicar uma autoridade de proteção de dados, e qual. De acordo com a LGPD, a comunicação deve chegar à ANPD no prazo de três dias úteis após o conhecimento de que o incidente afetou dados pessoais; outros países têm prazos diferentes, resumidos abaixo. Quando a comunicação é obrigatória, os titulares afetados devem ser avisados no mesmo prazo. Preserve a cadeia de custódia das evidências. Documente a decisão mesmo quando concluir que a comunicação não é necessária: a Resolução CD/ANPD nº 15/2024 exige o registro de todos os incidentes, inclusive os não comunicados.
Comprometimento de conta
Antes de retornar a conta para uso, redefina a senha, revogue todas as sessões ativas e atualize os tokens e remova e recadastre os métodos de MFA quando houver suspeita de comprometimento. Uma redefinição de senha por si só pode deixar as sessões existentes funcionando. Audite todas as ações realizadas pela conta comprometida durante o período do comprometimento: e-mails enviados, arquivos acessados, permissões alteradas, regras criadas, aplicativos autorizados. Verifique regras de encaminhamento de e-mail, novas contas de administrador e atribuições de funções privilegiadas, concessões de consentimento OAuth para aplicativos conectados, alterações nas configurações de federação ou domínios confiáveis e alterações nas políticas de autenticação ou acesso condicional. O ponto mais esquecido na recuperação é a conta comprometida que foi usada para criar acesso persistente em outro lugar.
Incidente ou queda de um fornecedor
Alguns dos incidentes mais disruptivos começam fora da sua rede. Seu provedor de serviços gerenciados (MSP) é invadido, uma plataforma de nuvem fica fora do ar por dois dias ou uma atualização defeituosa de um fornecedor de segurança derruba seus notebooks, como a atualização CrowdStrike fez com milhões de máquinas Windows em 19 de julho de 2024. Quando o ransomware atingiu o serviço de patologia Synnovis em junho de 2024, os hospitais do NHS em Londres que dependiam dele adiaram milhares de compromissos e operações. Você não pode investigar sistemas que não são seus e talvez nunca veja os logs deles. Por isso, este playbook trata das decisões que estão nas suas mãos. Para cada fornecedor crítico, ele responde a três perguntas: como saberemos, o que desligamos e como continuamos operando?
Confirme o incidente por um contato que você já tem, e não por um número ou link do próprio alerta; invasores se passam por fornecedores. Depois, descubra se o fornecedor foi invadido ou só está fora do ar, porque cada caso pede ações diferentes.
Se o fornecedor foi invadido e tem acesso ao seu ambiente, decida cedo se vai cortar esse acesso. Desative as ferramentas de acesso remoto e as contas de VPN dele, suspenda integrações e conexões de API e troque as senhas ou chaves que ele tenha. A ferramenta de gerenciamento remoto de um MSP alcança todas as máquinas que ele gerencia, por isso trate um MSP invadido como uma possível invasão da sua própria rede. Verifique quais dados o fornecedor guarda ou trata para você e se há dados pessoais entre eles.
Se o fornecedor estiver fora do ar, mas não houver sinal de comprometimento, cortar seu acesso traz pouco ganho e pode retardar a recuperação dele e a sua. Mantenha a conexão sob observação e passe para a solução alternativa combinada (um processo manual, um segundo fornecedor ou um serviço reduzido). Em ambos os casos, diga aos funcionários o que muda para eles.
Pergunte ao fornecedor, por escrito, o que aconteceu e quando, quais dos seus sistemas e dados foram afetados e quais indicadores de comprometimento você deve procurar. Registre cada solicitação e cada resposta. Pela LGPD, comunicar a ANPD é dever seu, como controlador, e não do fornecedor, e seus três dias úteis são contados a partir do momento em que você toma conhecimento de que o incidente afetou dados pessoais. O aviso do fornecedor costuma iniciar essa contagem, mas uma notícia, a reclamação de um cliente ou o seu próprio monitoramento podem iniciá-la antes, então avalie na hora e registre quando e como você soube. Como as regras impõem essa obrigação a você, seu contrato deve exigir que o fornecedor avise você rapidamente. O GDPR europeu divide a obrigação da mesma forma. Se o fornecedor demorar a dar detalhes, comunique dentro do prazo o que já sabe e complemente depois. Nosso guia de segurança da cadeia de suprimentos trata das cláusulas contratuais e dos controles de acesso que facilitam este playbook.
Se a sua empresa é o fornecedor, vale o inverso. Seus contratos com clientes e acordos de tratamento de dados podem fixar prazos de aviso mais curtos do que os de qualquer regulador. Coloque no plano esses prazos, os contatos do cliente e a pessoa que decide o que dizer aos clientes.
