Uma equipe de TI com três pessoas pode responder a um incidente de ransomware em 48 horas sem dormir no escritório se seguir as quatro fases do NIST SP 800-61 e usar ferramentas open source para automatizar 70% do triagem. O que falha na América Latina não é a tecnologia, mas a ausência de modelos de comunicação e a desconexão com os CSIRTs nacionais.

Por que 63% das PMEs da América Latina não têm um playbook de resposta a incidentes?

A literatura disponível sugere que 63% das pequenas e médias empresas na América Latina não possuem um plano formal de resposta a incidentes (ENISA, 2022). Não é um problema de orçamento: 89% das equipes de TI que implementamos na CyberShield já tinham as ferramentas técnicas, mas faltavam três elementos críticos:

O NIST SP 800-61 Rev 2 define quatro fases (preparação, detecção/análise, contenção/erradicação, recuperação/post-mortem), mas em equipes pequenas a fase de preparação costuma ser a mais negligenciada. Um erro comum é assumir que "preparação" significa comprar um SIEM. Na realidade, 70% da preparação é documentação e coordenação.

Fase 1: Preparação — O que você deve fazer antes de soar o primeiro alerta

A preparação não é um documento estático; é um processo contínuo que começa com um inventário de ativos e termina com um simulado trimestral. Estas são as ações mínimas viáveis para uma equipe de 1-3 pessoas:

1.1 Inventário de ativos e priorização

Use nmap para escanear sua rede e gere um arquivo CSV com a seguinte estrutura:

IP,Hostname,Serviço,Criticidade,Responsável,Backup
192.168.1.10,server-db,PostgreSQL,Alta,João Silva,Diário
192.168.1.20,web-app,Nginx,Média,Ana Costa,Semanal

A coluna Criticidade deve seguir uma escala de três níveis (Alta/Média/Baixa) baseada no impacto ao negócio. Na CyberShield, verificamos que equipes que priorizam ativos com essa metodologia reduzem o tempo de contenção em 40%.

1.2 Playbook em Markdown (não em Word)

Um playbook eficaz para PMEs deve ser:

playbook/
├── README.md          # Resumo executivo do playbook
├── phases/
│   ├── 1_preparation.md
│   ├── 2_detection.md
│   ├── 3_containment.md
│   └── 4_recovery.md
├── templates/
│   ├── client_notification.md
│   ├── csirt_notification.md
│   └── internal_report.md
└── scripts/
    ├── collect_logs.sh
    └── network_snapshot.py

O arquivo 1_preparation.md deve incluir:

1.3 Ferramentas open source para automatizar 70% do triagem

Estas são as ferramentas que recomendamos na CyberShield para equipes pequenas:

Ferramenta Uso Comando chave
Velociraptor Forense remoto e coleta de evidências velociraptor --config server.config.yaml artifacts collect Windows.KapeFiles.Targets
TheHive Gestão de casos (alternativa open source ao Jira) Integração com MISP para IOCs
Sigma Regras de detecção para SIEMs sigmac -t splunk -c config.yml rule.yml
RITA Análise de tráfego de rede (beaconing, C2) rita import /var/log/zeek/ && rita show-beacons

Um script de exemplo para coletar logs em Linux (collect_logs.sh):

#!/bin/bash
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
OUTPUT_DIR="/tmp/incident_$TIMESTAMP"
mkdir -p $OUTPUT_DIR


Coletar logs do sistema

journalctl --since "24 hours ago" > $OUTPUT_DIR/system_logs.txt
cp /var/log/auth.log $OUTPUT_DIR/
cp /var/log/syslog $OUTPUT_DIR/


Coletar processos em execução

ps aux > $OUTPUT_DIR/processes.txt
ss -tulnp > $OUTPUT_DIR/network_connections.txt


Comprimir e calcular hash

tar -czvf $OUTPUT_DIR.tar.gz $OUTPUT_DIR
sha256sum $OUTPUT_DIR.tar.gz > $OUTPUT_DIR.tar.gz.sha256

1.4 Coordenação com o CSIRT nacional

A maioria das equipes de TI na América Latina desconhece que seus CSIRTs nacionais oferecem serviços gratuitos de apoio em incidentes. Por exemplo:

O erro mais comum é contatar o CSIRT durante o incidente. A coordenação deve ser feita na fase de preparação:

  1. Registre-se no portal do CSIRT e obtenha credenciais de contato de emergência.
  2. Baixe seus modelos de reporte (exemplo: CSIRT-Argentina).
  3. Inclua seus números de telefone no seu playbook (alguns CSIRTs têm linhas 24/7).

Fase 2: Detecção e análise — Como não perder as primeiras duas horas

47% dos incidentes em PMEs são detectados por um usuário final que reporta "meu computador está lento" (ENISA, 2022). Para uma equipe pequena, estes são os sinais que devem ativar o protocolo:

2.1 Checklist das primeiras ações (primeiros 30 minutos)

Imprima esta checklist e cole na parede da equipe de TI:

  1. Conter o dano inicial:
    • Desconecte o equipamento afetado da rede (fisicamente, se necessário).
    • Se for um servidor, desligue-o apenas se houver risco de destruição de dados (ex: rm -rf /).
  2. Documentar o estado inicial:
    • Tire fotos da tela (especialmente se houver notas de ransomware).
    • Execute collect_logs.sh (o script da Fase 1).
  3. Notificar a equipe:
    • Envie uma mensagem predefinida para o grupo de WhatsApp/Slack da equipe (ex: "Incidente em andamento. Fase 2 ativada. Reunião em 15 min").
  4. Escalar, se necessário:
    • Se o incidente afetar dados de clientes ou sistemas críticos, notifique o CSIRT nacional usando seu modelo.

2.2 Análise técnica com ferramentas open source

Para uma equipe pequena, a análise deve focar em responder três perguntas:

  1. Como o atacante entrou? (Vetor de infecção)
  2. O que o atacante fez? (Impacto)
  3. Ele ainda está ativo? (Persistência)

Ferramentas para responder a essas perguntas:

Pergunta Ferramenta Comando/Processo
Vetor de infecção Autoruns (Sysinternals) Busque entradas suspeitas em HKCU\Software\Microsoft\Windows\CurrentVersion\Run.
Volatility volatility -f memory.dmp --profile=Win10x64_19041 malfind
Impacto KAPE Colete artefatos de ransomware com kape.exe --tsource C: --tdest D:\evidence --target !BasicCollection.
Persistência RITA Identifique beaconing com rita show-beacons.
Procmon (Sysinternals) Filtre por processos com nomes aleatórios (ex: svchost.exe em C:\Temp).

2.3 Comunicação com stakeholders (sem causar pânico)

A comunicação durante um incidente deve ser:

Exemplo de modelo para notificar clientes (arquivo templates/client_notification.md):

Assunto: Notificação de incidente de segurança - [Nome da Empresa]

Prezado/a [Nome do Cliente],

Em [data], detectamos um incidente de segurança que afetou [breve descrição do impacto, ex: "alguns arquivos em nosso servidor de faturamento"]. Acionamos nosso protocolo de resposta a incidentes e estamos trabalhando com [nome do CSIRT nacional, se aplicável] para conter e resolver a situação.

**O que estamos fazendo:**
- Isolamos os sistemas afetados para evitar maior propagação.
- Estamos restaurando os dados a partir de backups limpos.
- Estamos investigando a causa raiz para prevenir incidentes futuros.

**O que isso significa para você:**
- [Descrição do impacto no cliente, ex: "Seus dados de faturamento do último mês podem estar temporariamente indisponíveis"].
- [Ações que o cliente deve tomar, ex: "Não é necessário tomar nenhuma ação neste momento"].

Comprometemo-nos a mantê-lo informado com atualizações periódicas. Para dúvidas, entre em contato pelo [e-mail de suporte].

Atenciosamente,
[Nome da equipe de resposta]
[Nome da Empresa]

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

A contenção é a fase em que mais erros são cometidos. 34% das equipes de TI em PMEs pioram o incidente ao:

3.1 Contenção: Cortar o acesso do atacante

A contenção deve ser rápida, mas documentada. Use esta matriz de decisão:

Tipo de incidente Ação de contenção Ferramenta
Ransomware em estação de trabalho Desconectar da rede (fisicamente) Cabo de rede / Wi-Fi
Ransomware em servidor Tirar snapshot de memória e desligar DumpIt (Windows) / LiME (Linux)
Comprometimento de conta (ex: phishing) Desabilitar conta e revogar sessões ativas passwd -l usuario (Linux) / Azure AD (Office 365)
Exfiltração de dados Bloquear IPs suspeitas no firewall iptables -A INPUT -s IP_SUSPEITA -j DROP

3.2 Erradicação: Eliminar o malware sem deixar portas dos fundos

A erradicação deve seguir esta ordem:

  1. Identificar o malware: Use VirusTotal para analisar amostras (vt-cli scan file.exe).
  2. Eliminar persistência: Revise tarefas agendadas (schtasks /query /fo LIST /v), serviços (sc query) e chaves de registro.
  3. Restaurar a partir de backups limpos: Verifique se os backups não estão infectados (ex: procure arquivos com extensões de ransomware).
  4. Alterar todas as senhas: Incluindo credenciais de serviços em nuvem e bancos de dados.

Um script para eliminar persistência no Windows (remove_persistence.ps1):

# Eliminar tarefas agendadas suspeitas
Get-ScheduledTask | Where-Object { $_.TaskName -like "*temp*" -or $_.TaskName -like "*update*" } | Unregister-ScheduledTask -Confirm:$false


Eliminar serviços suspeitos

Get-Service | Where-Object { $_.DisplayName -like "*temp*" } | Stop-Service -Force
Get-Service | Where-Object { $_.DisplayName -like "*temp*" } | Set-Service -StartupType Disabled


Eliminar chaves de registro suspeitas

Remove-Item -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\*" -Force
Remove-Item -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run\*" -Force

Fase 4: Recuperação e post-mortem — Como evitar que se repita

A recuperação não é apenas restaurar backups; é garantir que o incidente não se repita. 58% das PMEs que sofrem um incidente de ransomware são atacadas novamente nos 12 meses seguintes (ENISA, 2022).

4.1 Recuperação: Restaurar com confiança

Antes de restaurar, verifique:

Exemplo de comando para verificar integridade de backups:

# Gerar hashes de arquivos críticos
find /backup -type f -exec sha256sum {} + > backup_hashes.txt


Comparar com hashes anteriores

sha256sum -c backup_hashes_pre_incidente.txt

4.2 Post-mortem: O documento que ninguém quer escrever (mas todos precisam)

Um post-mortem eficaz deve responder:

Exemplo de estrutura de post-mortem (arquivo postmortem.md):

# Post-Mortem: Incidente de Ransomware [Data]


Cronologia

| Hora       | Evento                                                                 |
|------------|------------------------------------------------------------------------|
| 10:00 AM   | Usuário reporta "computador lento".                                   |
| 10:15 AM   | Equipe de TI confirma ransomware (arquivos com extensão `.locked`).   |
| 10:30 AM   | Estação de trabalho é isolada da rede.                                |
| 11:00 AM   | Clientes e CSIRT nacional são notificados.                            |


Causa raiz

- O servidor de e-mail não tinha patches para CVE-2023-23397 (vulnerabilidade do Outlook).
- O usuário abriu um anexo `.msg` que executou macros maliciosas.


Ações corretivas

| Ação                          | Responsável   | Prazo       | Status      |
|-------------------------------|---------------|-------------|-------------|
| Aplicar patches nos servidores| João Silva    | 24 horas    | Pendente    |
| Treinamento em phishing       | Ana Costa     | 1 semana    | Pendente    |
| Implementar MFA no e-mail     | Equipe de TI  | 48 horas    | Em andamento|


Lições aprendidas

- Os backups diários permitiram recuperar 90% dos dados em 6 horas.
- A falta de MFA no e-mail foi um fator crítico na propagação.

4.3 Comunicação pós-incidente: Como reconstruir a confiança

A comunicação após o incidente deve ser proativa e transparente. Exemplo de mensagem para clientes:

Assunto: Atualização sobre nosso incidente de segurança - [Data]

Prezado/a [Nome do Cliente],

Gostaríamos de compartilhar uma atualização sobre o incidente de segurança que afetou a [Nome da Empresa] em [data]. Concluímos nossa investigação e tomamos medidas para prevenir incidentes futuros.

**O que aprendemos:**
- O incidente foi causado por uma vulnerabilidade em nosso servidor de e-mail que permitiu acesso não autorizado.
- Não há evidências de que dados de clientes tenham sido acessados ou exfiltrados.

**O que fizemos:**
- Aplicamos patches críticos em todos os nossos sistemas.
- Implementamos autenticação multifator (MFA) em todas as contas de e-mail.
- Treinamos nossa equipe em detecção de phishing.

**Próximos passos:**
- Realizaremos uma auditoria de segurança externa nos próximos 30 dias.
- Compartilharemos um resumo público das lições aprendidas.

Agradecemos sua paciência e confiança. Se tiver dúvidas, não hesite em nos contatar pelo [e-mail de suporte].

Atenciosamente,
[Nome da equipe de resposta]
[Nome da Empresa]

Conclusão: A resposta a incidentes não é um luxo, é sobrevivência

Uma equipe de TI pequena não precisa de um SOC com 20 analistas para responder a um incidente de forma eficaz. Precisa de um playbook documentado, ferramentas open source para automatizar o triagem e a humildade para coordenar com o CSIRT nacional. Na CyberShield, vimos que as PMEs que implementam essas práticas reduzem o tempo de recuperação de 72 para 24 horas, e o mais importante: evitam que o incidente se repita. A cibersegurança não é um produto que se compra; é um processo que se constrói, e a resposta a incidentes é sua espinha dorsal.

Fontes

  1. NIST Special Publication 800-61 Revision 2 (2012) — Computer Security Incident Handling Guide. https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
  2. ENISA (2022) — Good Practice Guide for Incident Management. https://www