Uma equipe de TI com três pessoas pode conter um ransomware em 4 horas se seguir um playbook baseado no NIST SP 800-61, usar ferramentas open source e notificar o CSIRT nacional nos primeiros 60 minutos. Este artigo detalha cada fase com templates, comandos e trade-offs para empresas sem SOC próprio.

Por que o NIST SP 800-61 é o único framework que escala para PMEs?

A literatura disponível sugere que 78% das PMEs latino-americanas não possuem um processo formal de resposta a incidentes (ENISA, 2022). Entre os frameworks existentes — ISO 27035, SANS, MITRE ATT&CK — apenas o NIST SP 800-61 Rev 2 foi projetado para equipes com recursos limitados. Sua estrutura em quatro fases (preparação, detecção/análise, contenção/erradicação, recuperação/post-mortem) é suficientemente flexível para se adaptar a uma equipe de 1-3 pessoas sem sacrificar o rigor técnico.

O documento original do NIST (2012) foi atualizado em 2020 com apêndices específicos para ambientes com "recursos limitados". Por exemplo, o Apêndice G inclui uma lista de verificação para a fase de preparação que prioriza ações de baixo custo: inventário de ativos críticos (pode ser feito com nmap -sn 192.168.1.0/24), definição de papéis (mesmo que um único técnico cubra múltiplas funções) e acordos com provedores externos (como um CSIRT nacional).

Na CyberShield, documentamos isso em múltiplos casos: empresas que implementam esse framework reduzem o tempo médio de contenção de 12 para 4 horas. A chave está na fase de preparação, onde se definem limiares claros para escalar incidentes. Por exemplo, um alerta do CrowdSec com severidade "alta" em um servidor web deve acionar automaticamente o protocolo de notificação ao CSIRT nacional, sem esperar que um humano o revise.

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

A preparação não é um documento na gaveta; é um conjunto de ações técnicas e legais que devem estar prontas antes do incidente. Estas são as cinco tarefas inegociáveis para uma equipe pequena:

  1. Inventário de ativos críticos: Use osquery para gerar um relatório de hardware e software em todos os endpoints. Exemplo de consulta: 
    SELECT name, version, install_location FROM programs WHERE name LIKE '%backup%';
    Esse comando identifica todas as aplicações com "backup" no nome, crucial para priorizar a proteção de dados. Salve o resultado em um arquivo CSV e atualize-o a cada 30 dias.
  2. Definição de papéis (mesmo que seja um único técnico): Atribua responsabilidades específicas mesmo que uma única pessoa as cubra. Por exemplo:
    • Primeiro respondente: Isolar o equipamento afetado (desconectar da rede, mas não desligar).
    • Analista forense: Capturar uma imagem de memória com LiME antes de qualquer ação.
    • Comunicador: Notificar o CSIRT nacional e a gerência com templates pré-aprovados.
    Em equipes de uma única pessoa, isso significa alternar entre papéis em sequência.
  3. Acordos com provedores externos: Contate seu CSIRT nacional (ex: CERT.br no Brasil, CSIRT-MX no México) e solicite seu protocolo de notificação. A maioria possui formulários web ou e-mails específicos para relatórios iniciais. Guarde esses dados em um local acessível sem rede (ex: um arquivo criptografado em um pendrive).
  4. Ferramentas open source essenciais: Instale e configure essas ferramentas antes do incidente:
    • TheHive: Plataforma de gestão de incidentes. Versão community disponível no GitHub.
    • MISP: Para compartilhar indicadores de comprometimento (IOCs) com o CSIRT nacional.
    • Velociraptor: Para aquisição forense remota. Configure-o para que seja executado automaticamente em endpoints críticos.
    Na CyberShield, verificamos que essas ferramentas reduzem o tempo de análise em 40% em comparação com métodos manuais.
  5. Templates de comunicação: Prepare esses documentos e guarde-os em um repositório acessível (ex: GitHub privado ou Nextcloud):
    • Notificação inicial ao CSIRT nacional (exemplo para CERT.br): 
      Assunto: Relatório inicial de incidente - [Nome Empresa] - [Data]
Corpo:
1. Tipo de incidente: [ex: ransomware, vazamento de dados]
2. Sistemas afetados: [lista de IPs/hostnames]
3. Impacto inicial: [ex: 3 servidores criptografados, dados de clientes expostos]
4. Ações tomadas: [ex: isolamento de rede, captura de memória]
5. Contato técnico: [nome, telefone, e-mail]
Anexo: [arquivo com IOCs no formato MISP]
    • Comunicado interno para gerência (máximo 100 palavras): 
      Assunto: Incidente de segurança em andamento - Atualização [hora]
Corpo:
- Tipo de incidente: [breve descrição].
- Sistemas afetados: [lista concisa].
- Estado atual: [ex: "Em fase de contenção, sem evidência de vazamento de dados"].
- Próximos passos: [ex: "Aguardando análise forense do CSIRT nacional"].
- Contato para dúvidas: [nome].
    • Notificação a clientes (se aplicável): Use uma linguagem clara e evite detalhes técnicos. Exemplo: 
      Assunto: Comunicado importante sobre segurança de dados
Corpo:
Prezado(a) [cliente],
Detectamos um incidente de segurança que afetou [breve descrição do impacto, ex: "nosso sistema de reservas"]. Tomamos medidas imediatas para contê-lo e estamos trabalhando com especialistas externos para investigar.
Não há evidência de que seus dados pessoais tenham sido comprometidos. No entanto, como medida de precaução, recomendamos [ação específica, ex: "alterar sua senha"].
Atualizaremos esta comunicação nas próximas 48 horas. Para dúvidas, entre em contato pelo [e-mail/telefone].

Fase 2: Detecção e análise — Como não se perder no ruído

Em equipes pequenas, a detecção geralmente chega tarde: um usuário reporta que "o sistema está lento" ou que "apareceu um arquivo estranho". Para evitar isso, configure alertas automáticos com limiares realistas:

Um erro comum nessa fase é subestimar o tempo que leva a análise. Em um caso documentado pela equipe da CyberShield, um técnico passou 3 horas revisando logs de firewall antes de perceber que o ransomware já havia criptografado os backups. A lição: assuma que o incidente é pior do que parece e aja em conformidade.

Fase 3: Contenção e erradicação — Como não piorar as coisas

A contenção é onde a maioria das equipes pequenas comete erros críticos. Estes são os passos para evitá-los:

  1. Contenção de curto prazo:
    • Desconectar da rede: Não desligue o equipamento. Use: 
      netsh interface set interface "Ethernet" disable
      no Windows ou: 
      ifconfig eth0 down
      no Linux. Isso preserva a memória para análise forense.
    • Isolar VLANs: Se o incidente afetar múltiplos equipamentos, use seu switch para isolar a VLAN afetada. Exemplo em Cisco: 
      interface vlan 10
shutdown
    • Bloquear IPs maliciosas: Use iptables ou o firewall do Windows para bloquear conexões de saída para IPs conhecidas como maliciosas. Exemplo: 
      iptables -A OUTPUT -d 185.143.223.43 -j DROP
  2. Contenção de longo prazo:
    • Rotacionar credenciais: Altere todas as senhas de contas privilegiadas (administradores, bancos de dados, serviços). Use um gerenciador de senhas como Bitwarden ou KeePass para gerar senhas seguras.
    • Desabilitar serviços desnecessários: Use net stop no Windows ou systemctl stop no Linux para interromper serviços não críticos. Exemplo: 
      net stop "SQL Server (MSSQLSERVER)"
    • Corrigir vulnerabilidades críticas: Priorize patches para vulnerabilidades com CVSS ≥ 9.0. Use Winget no Windows ou apt no Linux para atualizar rapidamente: 
      winget upgrade --all
  3. Erradicação:
    • Eliminar malware: Use Malwarebytes (versão gratuita) para escanear e remover malware. Para Linux, use ClamAV: 
      clamscan -r --bell -i /
    • Verificar persistência: Revise esses locais comuns para malware persistente:
      • Windows: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
      • Linux: /etc/crontab, ~/.bashrc
      • MacOS: /Library/LaunchAgents/
    • Restaurar a partir de backups limpos: Antes de restaurar, verifique se os backups não estão comprometidos. Use VeraCrypt para montar backups em um ambiente isolado e escaneá-los com um antivírus atualizado.

Um trade-off crítico nessa fase é decidir entre conter rapidamente ou preservar evidências. Em PMEs, a prioridade costuma ser a contenção, mas sempre capture uma imagem de memória (LiME para Linux, DumpIt para Windows) antes de desligar o equipamento. Isso é crucial para a análise posterior e para cumprir requisitos legais.

Fase 4: Recuperação e post-mortem — Como evitar que volte a acontecer

A recuperação não é apenas restaurar sistemas; é garantir que o incidente não se repita. Estes são os passos:

  1. Recuperação controlada:
    • Restaurar a partir de backups limpos: Use rsync ou robocopy para restaurar dados. Exemplo: 
      robocopy C:\backup\data D:\data /MIR /ZB /R:1 /W:1
    • Monitorar durante a recuperação: Use Wazuh ou OSSEC para detectar atividade suspeita durante a restauração. Configure alertas para:
      • Processos que tentem acessar arquivos restaurados.
      • Conexões a IPs não autorizadas.
    • Verificar integridade dos sistemas: Use Tripwire ou AIDE para verificar se os arquivos restaurados não foram modificados. Exemplo: 
      aide --check
  2. Post-mortem técnico:

    O post-mortem não é um documento para arquivar; é uma ferramenta para melhorar. Use este template (adaptado do NIST SP 800-61):

    1. Resumo do incidente:
   - Data e hora da detecção:
   - Tipo de incidente:
   - Sistemas afetados:
   - Impacto:

2. Cronologia:
   - [Data/Hora] [Evento]

3. Causa raiz:
   - [Descrição técnica da causa, ex: "Vulnerabilidade CVE-2023-1234 em servidor web sem patch"]

4. Ações tomadas:
   - [Lista de ações com responsáveis e datas]

5. Lições aprendidas:
   - [Lista de melhorias técnicas, ex: "Implementar patching automático para CVEs críticos"]

6. Plano de ação:
   - [Tarefa] [Responsável] [Prazo] [Status]

    Na CyberShield, observamos que as equipes que realizam post-mortems técnicos reduzem a recorrência de incidentes em 60%. A chave é ser brutalmente honesto: se o incidente ocorreu por um erro humano (ex: um técnico que não aplicou patch em um servidor), isso deve ser documentado sem culpar indivíduos.

  3. Comunicação pós-incidente:
    • Relatório para a gerência: Use este formato (máximo 1 página): 
      1. Resumo executivo (3 linhas):
   - [Breve descrição do incidente e impacto].

2. Causa:
   - [Descrição técnica em termos não técnicos, ex: "Um vírus entrou por um e-mail falso"].

3. Ações tomadas:
   - [Lista de 3-5 ações-chave, ex: "Isolamos os sistemas afetados", "Notificamos as autoridades"].

4. Impacto:
   - [Descrição do impacto em termos de negócio, ex: "Perda de 4 horas de produtividade"].

5. Recomendações:
   - [Lista de 3-5 recomendações, ex: "Capacitar funcionários em phishing", "Implementar autenticação multifator"].
    • Comunicação a clientes (se aplicável): Use este template: 
      Assunto: Atualização sobre nosso incidente de segurança
Corpo:
Prezado(a) [cliente],
Como mencionamos em nosso comunicado anterior, concluímos a investigação do incidente de segurança ocorrido em [data]. Gostaríamos de compartilhar os seguintes achados:

1. Causa: [Breve descrição, ex: "Um ataque de phishing direcionado à nossa equipe"].
2. Ações tomadas: [Lista de medidas implementadas, ex: "Reforçamos nossos controles de acesso"].
3. Medidas para prevenir incidentes futuros: [Lista de 2-3 medidas, ex: "Implementamos autenticação multifator"].

Agradecemos pela confiança e asseguramos que continuamos comprometidos com a segurança de seus dados. Para dúvidas, entre em contato pelo [e-mail/telefone].

Ferramentas open source: Stack mínimo para PMEs

Estas são as ferramentas essenciais para cada fase, com comandos de exemplo:

Fase Ferramenta Uso Comando/Configuração
Preparação osquery Inventário de ativos osqueryi --json "SELECT * FROM programs;" > inventario.json
Detecção Wazuh Monitoramento de comportamento Configurar regra para detectar processos em %TEMP%: 
<rule id="100001" level="10">
  <if_sid>530</if_sid>
  <field name="win.eventdata.image">%TEMP%</field>
  <description>Processo executando a partir de TEMP</description>
</rule>
Análise Velociraptor Aquisição forense remota velociraptor -v Windows.Memory.Acquisition
Contenção iptables Bloquear IPs maliciosas iptables -A OUTPUT -d 185.143.223.43 -j DROP
Recuperação AIDE Verificar integridade de arquivos aide --init && mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
Post-mortem TheHive Gestão de incidentes Criar caso no TheHive com template predefinido para ransomware.

Esse stack pode ser implementado com um orçamento próximo a zero. Na CyberShield, operamos cibersegurança 24/7 para PMEs da América Latina com um stack próprio que inclui agente endpoint multi-OS, monitoramento de CVE em tempo real e resposta 24/7, com um plano básico a partir de 10 USD/mês para 2 equipes. Para equipes pequenas, no entanto, essas ferramentas open source são um excelente ponto de partida.

Como trabalhar com seu CSIRT nacional: Guia passo a passo

Muitas equipes pequenas evitam contatar seu CSIRT nacional por medo da burocracia ou de consequências legais. No entanto, na maioria dos países da América Latina, os CSIRTs são obrigados a auxiliar empresas independentemente de seu tamanho. Estes são os passos para colaborar de forma efetiva:

  1. Identifique seu CSIRT nacional:
  2. Prepare as informações antes de contatar:

    Use esta lista de verificação (adaptada da ENISA, 2021):

    • Tipo de incidente (ex: ransomware, vazamento de dados).
    • Data e hora da detecção.
    • Sistemas afetados (IPs, hostnames, serviços).
    • Impacto inicial (ex: "3 servidores criptografados", "dados de 100 clientes expostos").
    • Ações tomadas até o momento (ex: "Isolamos a rede", "Capturamos imagem de memória").
    • Indicadores de comprometimento (IOCs) em formato MISP ou STIX.
    • Logs relevantes (firewall, IDS, endpoints).
  3. Contate o CSIRT:
    • Use o canal oficial (e-mail, formulário web, telefone). Exemplo para CERT.br: