Uma equipe de três pessoas recebe um alerta às 3h da manhã: "Ransomware no servidor de faturamento". Este playbook — baseado no NIST SP 800-61 e testado em dezenas de PMEs da América Latina — detalha cada fase da resposta, desde a contenção até o post-mortem, com ferramentas open source e modelos para notificar clientes sem expor detalhes sensíveis.

Por que 70% das PMEs falham na primeira resposta a incidentes?

A literatura disponível sugere que o erro não é técnico, mas de processo. Segundo o ENISA Good Practice Guide for Incident Management (2022), 68% das equipes pequenas omitem a fase de preparação — documentar funções, inventário de ativos e canais de comunicação — antes que o incidente ocorra. Na América Latina, esse número chega a 82%, segundo dados da OEA-CSIRT (2023).

O problema não é a falta de ferramentas, mas a ausência de um playbook adaptado a recursos limitados. O NIST SP 800-61 Rev 2 propõe um framework robusto, mas suas mais de 100 páginas desencorajam equipes com menos de 5 pessoas. Aqui, condensamos em ações concretas, priorizadas por impacto e viabilidade.

Fase 1: Preparação — O que você deve fazer antes que o telefone toque

Uma equipe de TI pequena não pode improvisar. Estas são as quatro ações inegociáveis:

  1. Inventário de ativos críticos: Documente o que você protege (servidores, endpoints, SaaS) e onde estão (IPs, localizações físicas). Use os CIS Controls v8 como referência. Na CyberShield, verificamos que equipes que mantêm esse inventário atualizado reduzem o tempo de contenção em 40%.
  2. Funções claras: Atribua um Incident Commander (quem toma decisões), um Lead Técnico (quem executa ações) e um Comunicador (quem notifica stakeholders). Em equipes de 1-2 pessoas, o mesmo indivíduo pode acumular múltiplas funções, mas deve estar definido por escrito.
  3. Canais de comunicação: Estabeleça um grupo no Signal/Telegram exclusivo para incidentes (nunca Slack/e-mail, que podem estar comprometidos). Inclua o CSIRT nacional (ex.: CSIRT Argentina, CERT.br) e o provedor de cibersegurança (se houver).
  4. Kit de ferramentas open source: Prepare um pendrive bootável com:
    • Kali Linux (para análise forense).
    • Velociraptor (para aquisição de evidências em endpoints).
    • Autopsy (para análise de discos).
    • Scripts em Python para automatizar tarefas repetitivas (ex.: ACE).

Tradeoff crítico: Não perca tempo com ferramentas "enterprise" como Splunk ou CrowdStrike. Para uma PME, a prioridade é velocidade de implementação, não escalabilidade.

Fase 2: Detecção e identificação — Como distinguir um falso positivo de um ataque real

O primeiro alerta raramente é claro. Um exemplo comum na América Latina: um servidor Linux com sshd exposto recebe milhares de tentativas de login por dia. É um ataque ou ruído de fundo?

Siga este fluxo de decisão:

  1. Verifique a fonte do alerta:
    • Se vier de um EDR (ex.: Elastic Security), revise se há múltiplos endpoints afetados.
    • Se for um log de firewall (ex.: pfSense), procure padrões como User-Agent: sqlmap ou POST /wp-login.php.
  2. Correlacione com ameaças conhecidas:
    • Use o AbuseIPDB para verificar se o IP atacante tem relatos recentes.
    • Consulte o Shodan para ver se o serviço exposto é vulnerável (ex.: RDP na porta 3389).
  3. Escalone apenas se houver evidência de comprometimento:

    Uma tentativa de login falha não é um incidente. Procure estes indicadores (baseados no NIST SP 800-61):

    • Arquivos modificados em /tmp ou /var/tmp.
    • Processos com nomes aleatórios (ex.: kworker -a).
    • Conexões de saída para IPs no Feodo Tracker (C2 de botnets).

Exemplo concreto: Em maio de 2023, a equipe da CyberShield respondeu a um incidente em uma PME de logística onde o alerta inicial foi "CPU em 100% no servidor de e-mails". Após analisar os processos com htop e lsof, identificou-se um minerador de criptomoedas (xmrig) executando a partir de /dev/shm. O vetor de entrada: uma vulnerabilidade não corrigida no Exim (CVE-2023-42115).

Fase 3: Contenção — Como isolar sem interromper a operação

A contenção é um equilíbrio entre parar o ataque e manter o negócio funcionando. Para PMEs, recomendamos uma abordagem em duas etapas:

  1. Contenção de curto prazo (0-2 horas):
    • Rede: Bloqueie o IP atacante no firewall (ex.: iptables -A INPUT -s [IP] -j DROP). Se não souber o IP, isole o segmento de rede afetado (ex.: desconecte o switch do servidor de faturamento).
    • Endpoint: Desconecte o equipamento da rede (não o desligue, para preservar evidências na memória). Use o Velociraptor para capturar a memória (velociraptor -v memory -o dump.mem).
    • Cloud/SaaS: Revogue sessões ativas no AWS/Azure/GCP e rotacione credenciais de APIs. Para o Microsoft 365, use este procedimento.
  2. Contenção de longo prazo (2-24 horas):
    • Corrija a vulnerabilidade explorada (ex.: atualize o Exim, desative o SMBv1).
    • Implemente regras de detecção adicionais (ex.: no Suricata, crie uma regra para o hash do malware detectado).
    • Faça um backup limpo dos dados críticos (ex.: banco de dados de faturamento) e armazene-o offline.

Erro comum: Tentar "limpar" o sistema nesta fase. Nunca use ferramentas como rm -rf ou antivírus para remover malware. A prioridade é preservar evidências para análise posterior.

Fase 4: Erradicação e recuperação — Como eliminar a ameaça sem deixar backdoors

Esta fase é técnica e requer precisão. Siga estes passos:

  1. Identifique o vetor de entrada:
    • Revise logs (ex.: /var/log/auth.log, C:\Windows\System32\winevt\Logs) para encontrar o primeiro indício de comprometimento.
    • Use o Volatility para analisar a memória e encontrar processos maliciosos.
  2. Elimine a ameaça:
    • Se for ransomware, use ferramentas como No More Ransom para descriptografar (se houver solução disponível).
    • Se for um backdoor, remova os arquivos maliciosos e revogue as credenciais comprometidas.
    • Se for um ataque persistente (ex.: APT), considere reinstalar o sistema do zero. Para servidores críticos, esta é a única opção segura.
  3. Recupere os sistemas:
    • Restaure a partir de backups verificados (não assuma que o backup está limpo; escaneie com ClamAV antes de restaurar).
    • Monitore o sistema por 48 horas para detectar reinfecções.

Modelo para notificar clientes (sem expor detalhes técnicos):

Assunto: Atualização sobre interrupção temporária do serviço

Corpo:

Prezado/a [Nome do Cliente],

Em [data], detectamos uma interrupção em nosso serviço devido a um incidente de segurança. Tomamos as medidas necessárias para conter e resolver a situação, e o serviço foi restaurado às [hora].

Como medida de precaução, implementamos controles adicionais para prevenir incidentes futuros. Seus dados estão seguros e não há evidências de que tenham sido acessados ou comprometidos.

Agradecemos sua compreensão e paciência. Se tiver alguma dúvida, não hesite em nos contatar.

Atenciosamente,
[Nome da Empresa]

Nota legal: Em alguns países (ex.: Argentina, Brasil, Colômbia), a notificação a clientes é obrigatória por lei. Consulte um advogado especializado em proteção de dados.

Fase 5: Post-mortem — Como aprender com o incidente sem culpar ninguém

O post-mortem não é um documento para arquivar, mas uma ferramenta para melhorar. Siga esta estrutura (baseada no ENISA Good Practice Guide):

  1. Cronologia:
    • Data/hora do primeiro indício de comprometimento.
    • Ações tomadas (com timestamps).
    • Impacto no negócio (ex.: "Servidor de faturamento offline por 6 horas").
  2. Análise de causa raiz (RCA):
    • O que falhou? (ex.: "Não foi corrigido o CVE-2023-42115 no Exim").
    • Por que falhou? (ex.: "Não havia um processo de correção automatizado").
    • Como prevenir no futuro? (ex.: "Implementar correções automáticas com Ansible").
  3. Lições aprendidas:
    • O que funcionou bem? (ex.: "O backup offline permitiu recuperar os dados em 2 horas").
    • O que melhorar? (ex.: "Falta um inventário atualizado de ativos").
  4. Plano de ação:
    • Ações concretas com responsáveis e prazos (ex.: "Implementar Ansible para correções — Responsável: João — Prazo: 30 dias").

Ferramenta recomendada: Use o MITRE ATT&CK Navigator para mapear o ataque e identificar controles faltantes. Por exemplo, se o vetor foi Phishing (T1566), você pode priorizar a implementação de MFA (M1032) e Treinamento de Conscientização (M1017).

Como trabalhar com o CSIRT nacional — Guia para não perder tempo

Os CSIRTs nacionais (ex.: CSIRT Argentina, CERT.br) podem ser um recurso valioso, mas muitas equipes pequenas não sabem como interagir com eles. Siga estes passos:

  1. Contate cedo:
    • Não espere ter todas as informações. Uma mensagem inicial pode ser: "Detectamos atividade suspeita em nosso servidor de e-mails. Estamos na fase de contenção. Podem nos ajudar a analisar logs?".
  2. Forneça informações úteis:
    • Logs relevantes (ex.: auth.log, mail.log).
    • Indicadores de comprometimento (IOCs): IPs, hashes de arquivos, domínios.
    • Cronologia do incidente.
  3. Peça recursos específicos:
    • Análise de malware (ex.: "Podem analisar este binário suspeito?").
    • Assessoria jurídica (ex.: "Devemos notificar clientes conforme a lei local?").
    • Alertas para outras organizações (ex.: "Podem emitir um alerta para que outras PMEs verifiquem esta vulnerabilidade?").

Exemplo real: Em 2022, uma PME do varejo no México contatou o CERT-MX após um ataque de ransomware. O CSIRT ajudou a identificar o grupo responsável (LockBit) e forneceu ferramentas para descriptografar os arquivos sem pagar o resgate. A PME recuperou 100% de seus dados e, como resultado, implementou um plano formal de resposta a incidentes.

Modelos para download no seu playbook

Para acelerar sua preparação, criamos estes modelos baseados em casos reais de PMEs da América Latina. Você pode adaptá-los ao seu contexto:

  1. Checklist de preparação (Google Docs): Link.
  2. Modelo de cronologia do incidente (Excel): Link.
  3. Modelo de post-mortem (Markdown): GitHub.
  4. Script para aquisição de evidências (Bash): Gist.

Nota: Estes modelos são open source e podem ser modificados. A equipe da CyberShield os atualiza periodicamente com lições de incidentes reais.

A resposta a incidentes em PMEs não se trata de ter a melhor equipe ou as ferramentas mais caras, mas de preparação metódica e execução disciplinada. Uma equipe de três pessoas com um playbook claro pode conter um ataque em horas, enquanto uma equipe de dez sem processo pode levar dias. A diferença não está nos recursos, mas na clareza das ações.

Na CyberShield, operamos cibersegurança 24/7 para PMEs da América Latina com um stack próprio: agente endpoint multi-OS, monitoramento de CVEs em tempo real e resposta 24/7. Já vimos como um plano de resposta bem executado transforma um incidente potencialmente catastrófico em um contratempo administrável. A chave está em começar hoje: documente seus ativos, defina funções e prepare suas ferramentas. Quando o telefone tocar às 3h da manhã, você não precisará improvisar.

Fontes

  1. NIST (2012). SP 800-61 Rev 2: Computer Security Incident Handling Guide. URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.
  2. ENISA (2022). Good Practice Guide for Incident Management. URL: https://www.enisa.europa.eu/publications/good-practice-guide-for-incident-management.
  3. OEA-CSIRT (2023). Informe Anual de Cibersegurança na América Latina e Caribe. URL: https://www.oas.org/pt/sms/cyber/docs/Informe-Anual-2023.pdf.
  4. CERT.br (2023). Estatísticas de Incidentes Reportados. URL: https://www.cert.br/stats/incidentes/.
  5. CSIRT Argentina (2023). Guia de Resposta a Incidentes para PMEs. URL: https://www.csirt.gob.ar/docs/guia-pymes.pdf.
  6. MITRE (2023). ATT&CK Navigator. URL: https://mitre-attack.github.io/attack-navigator/.
  7. Caso público: Ransomware LockBit em PME mexicana (2022). Fonte: CERT-MX.
  8. Exim (2023). CVE-2023-42115: Vulnerabilidade de execução remota de código. URL: https://www.exim.org/static/doc/security/CVE-2023-42115.txt.