Uma equipe de TI de três pessoas pode conter um ransomware em 4 horas se seguir um playbook de 7 passos baseado no NIST SP 800-61, mas 78% das PMEs da América Latina não possuem templates para notificar clientes ou se comunicar com seu CSIRT nacional. Aqui está o manual que usamos na CyberShield para equipes pequenas: fases, ferramentas open source e exemplos reais de notificações que cumprem com regulamentações locais.

Por que 80% dos incidentes em PMEs escalam (e como evitá-lo em 30 minutos)

O primeiro erro não é técnico: é assumir que "isso não vai acontecer conosco". Em 2023, o ENISA Threat Landscape reportou que 43% dos ciberataques na Europa afetaram empresas com menos de 50 funcionários. Na América Latina, o número supera 60% segundo dados da OEA. A diferença entre um incidente contido e outro que paralisa a operação geralmente se resume a dois fatores:

A solução não requer orçamento adicional, mas clareza nos papéis. Em equipes de 1-3 pessoas, recomendamos atribuir estes três chapéus desde o primeiro alerta:

  1. Primeiro respondente (First Responder): Quem recebe o alerta (ex.: "o servidor não responde"). Sua única tarefa é verificar se é um falso positivo ou um incidente real usando uma checklist de 5 perguntas (ver seção 3).
  2. Contenedor (Containment Lead): Quem isola o sistema afetado. Em casos de ransomware, isso significa desconectar o equipamento da rede antes de desligá-lo (para preservar a memória volátil).
  3. Comunicador (Comms Lead): Quem redige o primeiro rascunho de notificação interna e externa. Este papel é crítico: uma mensagem mal redigida pode gerar pânico em clientes ou violar regulamentações como a Lei de Proteção de Dados Pessoais no México ou a LGPD no Brasil.

Na CyberShield, documentamos que equipes que praticam essa divisão de papéis com simulações trimestrais reduzem o tempo de contenção em 40%.

Fase 1: Detecção e análise — Como distinguir um falso positivo de um ataque real (com exemplos)

37% dos alertas em PMEs são falsos positivos (dados do Graylog em ambientes SMB). A chave está em uma matriz de decisão que combine indicadores técnicos e contexto empresarial. Aqui está a que usamos, adaptada do NIST SP 800-61:

Indicador Falso positivo (exemplo) Incidente real (exemplo)
Tráfego de rede Pico de tráfego às 3h da manhã por atualização automática do Windows. Conexões de saída para IPs na Rússia a partir de um servidor de folha de pagamento (que não deveria ter tráfego internacional).
Comportamento de usuário Um funcionário inicia sessão em dois locais em 5 minutos porque esqueceu de encerrar a sessão no telefone. O usuário "admin" inicia sessão a partir de um IP na Nigéria quando a equipe opera apenas na Argentina.
Arquivos modificados O arquivo de log do Apache cresce 2GB por um erro de configuração. Todos os arquivos na pasta "Faturas" têm extensão .locked e uma mensagem de resgate em um arquivo de texto.
Mensagens do sistema O antivírus reporta "PUP.Optional" em um arquivo de instalação do Zoom. O firewall reporta "ET TROJAN Cobalt Strike Beacon" na porta 4444.

Ferramentas open source para esta fase:

Um erro comum nesta fase é subestimar alertas "menores". Em 2022, um cliente da CyberShield ignorou um aviso de "falha na conexão RDP" em seu servidor de faturamento. Três dias depois, esse mesmo servidor estava criptografado com LockBit. A literatura disponível sugere que 60% dos ransomwares usam RDP como vetor inicial (Coveware, 2023).

Fase 2: Contenção — Isolar sem destruir evidências (checklist de 7 passos)

A contenção é onde a maioria das equipes pequenas comete erros irreversíveis. Desligar um equipamento afetado por ransomware pode apagar chaves de criptografia na memória que poderiam ser usadas para descriptografar arquivos. Aqui está o protocolo que seguimos, baseado nas diretrizes da ENISA e testado em mais de 50 incidentes:

  1. Documentar o estado atual:
    • Tirar screenshot dos processos ativos (ps aux no Linux, tasklist no Windows).
    • Registrar conexões de rede (netstat -tulnp ou netstat -ano).
    • Fotografar a tela se houver mensagens de ransomware (nunca salvar a foto no equipamento afetado).
  2. Desconectar da rede:
    • Em equipamentos físicos: desconectar o cabo Ethernet ou desativar o Wi-Fi (não desligar o equipamento).
    • Em VMs: pausar a máquina ou desconectar a interface de rede a partir do hypervisor.
  3. Criar uma imagem forense (se possível):
    • Usar dd no Linux (dd if=/dev/sda of=/mnt/backup/incidente.img bs=4M) ou FTK Imager no Windows.
    • Se não houver tempo, pelo menos copiar os logs críticos (/var/log/ no Linux, C:\Windows\System32\winevt\Logs\ no Windows).
  4. Identificar o vetor de entrada:
    • Revisar logs de VPN, RDP ou e-mail em busca de acessos não autorizados.
    • Procurar arquivos modificados recentemente (find / -type f -mtime -1).
  5. Conter o alcance:
    • Alterar senhas de contas com acesso remoto (VPN, RDP, SSH).
    • Bloquear IPs suspeitas no firewall.
    • Desabilitar serviços não essenciais (ex.: SMBv1, RDP se não for usado).
  6. Notificar o CSIRT nacional:
    • No México: CERT-MX (formato de relatório em seu site).
    • Na Colômbia: ColCERT (requer registro prévio).
    • Na Argentina: BA-CSIRT (para empresas em CABA).
    • Incluir no relatório: timestamp do incidente, IOCs identificados (hashes, IPs, domínios) e ações tomadas até o momento.
  7. Decidir se escalar:
    • Escalar para um provedor externo se: o incidente afetar dados de clientes, houver risco de vazamento de informações sensíveis ou a equipe não tiver capacidade para recuperar os sistemas.
    • Na CyberShield, operamos um serviço de resposta a incidentes 24/7 para PMEs da América Latina com stack próprio: agente endpoint multi-OS, monitoramento de CVE em tempo real e resposta em menos de 2 horas. O plano básico custa 10 USD/mês por 2 equipamentos e inclui simulações trimestrais.

Um caso real: Em 2023, uma PME de logística no Peru sofreu um ataque de ransomware que criptografou seu banco de dados de envios. A equipe de TI seguiu este protocolo à risca:

O tempo total de contenção: 3 horas e 47 minutos. O custo do incidente: 0 USD em resgate e 2 dias de operação reduzida.

Fase 3: Erradicação e recuperação — Como limpar sem reinfectar (e quais ferramentas usar)

A erradicação é a fase mais técnica e onde as equipes pequenas costumam falhar por duas razões:

  1. Não eliminam todos os artefatos do atacante (ex.: contas de usuário criadas, tarefas agendadas ou serviços maliciosos).
  2. Restauram sistemas sem corrigir as vulnerabilidades que permitiram o ataque.

O protocolo que recomendamos:

1. Eliminar o malware

2. Corrigir vulnerabilidades

3. Restaurar sistemas

4. Monitorar reinfecções

Ferramentas open source para esta fase:

Fase 4: Comunicação — Templates para notificar clientes, funcionários e autoridades (com exemplos reais)

A comunicação durante um incidente é tão crítica quanto a resposta técnica. Uma mensagem mal redigida pode gerar desconfiança, processos judiciais ou até multas por descumprimento de regulamentações. Aqui estão os templates que usamos na CyberShield, adaptados para PMEs na América Latina:

1. Notificação interna (funcionários)

Assunto: [URGENTE] Incidente de segurança em andamento - Ações requeridas

Corpo:

Prezado time,

No dia [data] às [hora], detectamos uma atividade suspeita em nossos sistemas que atende aos critérios de um incidente de segurança. Ativamos nosso protocolo de resposta e, neste momento, o incidente está contido. Não há evidências de que dados de clientes tenham sido comprometidos.

Ações requeridas:

  • Não acessem os sistemas internos até novo aviso.
  • Não abram e-mails de remetentes desconhecidos.
  • Se receberem ligações ou mensagens perguntando por informações da empresa, verifiquem a identidade do remetente antes de responder.

Manteremos a equipe informada a cada 2 horas com atualizações. Para dúvidas, contatar [nome] em [telefone/e-mail].

Atenciosamente,
[Nome]
[Cargo]
[Empresa]

2. Notificação a clientes (versão genérica)

Assunto: Aviso importante sobre a segurança de seus dados

Corpo:

Prezado/a [Nome do Cliente],

Gostaríamos de informar que no dia [data], detectamos um incidente de segurança em nossos sistemas. Tomamos medidas imediatas para conter o incidente e estamos trabalhando com especialistas em cibersegurança para investigar o alcance.

Informações importantes:

  • Não encontramos evidências de que seus dados pessoais tenham sido acessados ou exfiltrados.
  • Como medida de precaução, recomendamos que altere sua senha em nosso sistema e em qualquer outro serviço onde utilize a mesma senha.
  • Notificamos as autoridades competentes, incluindo [nome do CSIRT nacional], e estamos cooperando com sua investigação.

Entendemos a importância da segurança de seus dados e lamentamos qualquer inconveniente que isso possa causar. Comprometemo-nos a mantê-lo informado à medida que avançamos na investigação.

Para dúvidas, pode nos contatar em [telefone/e-mail].

Atenciosamente,
[Nome]
[Cargo]
[Empresa]

3. Notificação a autoridades (exemplo para o México)

Assunto: Relatório de incidente de segurança - [Nome da Empresa]

Corpo:

CERT-MX,

Por meio deste, [Nome da Empresa], com RFC [RFC], reporta um incidente de segurança conforme estabelecido no artigo 63 da Lei Federal de Proteção de Dados Pessoais em Posse de Particulares.

Detalhes do incidente:

  • Data e hora da detecção: [data e hora]
  • Tipo de incidente: [ex.: ransomware, acesso não autorizado, vazamento de dados]
  • Sistemas afetados: [ex.: servidor de faturamento, banco de dados de clientes]
  • Dados potencialmente comprometidos: [ex.: nomes, e-mails, números de telefone]
  • Ações tomadas: [ex.: contenção do sistema afetado, notificação a clientes, colaboração com provedor de cibersegurança]
  • IOCs identificados: [ex.: hashes de arquivos maliciosos, IPs suspeitas, domínios C2]

Anexamos evidências coletadas até o momento. Comprometemo-nos a manter o CERT-MX informado sobre qualquer desenvolvimento relevante.

Ficamos à disposição para qualquer solicitação adicional.

Atenciosamente,
[Nome]
[Cargo]
[Empresa]
[Telefone]
[E-mail]

Um erro comum é prometer mais do que se pode cumprir. Frases como "seus dados estão 100% seguros" ou "isso não acontecerá novamente" podem ser usadas contra você em caso de litígio. Em vez disso, use linguagem precisa:

Fase 5: Post-mortem — Como aprender com o incidente sem culpar (template de relatório)

O post-mortem é a fase mais valiosa e a que menos equipes pequenas realizam. Segundo a ENISA, apenas 22% das PMEs na Europa fazem uma análise formal após um incidente. Na América Latina, o número é ainda menor. No entanto, é a única forma de evitar que o mesmo incidente ocorra duas vezes.

Aqui está o template de relatório post-mortem que usamos, baseado no NIST SP 800-61 e adaptado para equipes pequenas:

1. Resumo executivo (1 parágrafo)

No dia [data], às [hora], foi detectado um incidente de [tipo de incidente] em [sistema afetado]. O incidente foi contido em [tempo] e os sistemas foram restaurados em [tempo]. Não houve impacto em [dados críticos ou processos-chave]. O vetor de entrada foi [vetor], explorando a vulnerabilidade [CVE ou descrição]. Foram notificados [autoridades, clientes, funcionários] e implementadas [medidas corretivas].

2. Cronologia do incidente

Data e hora Evento Responsável Notas
[data e hora] Primeiro alerta gerado por [ferramenta] [nome] Alerta inicial: [descrição]
[data e hora] Verificação do incidente [nome] Confirmou-se que era um incidente real porque [razões]
[data e hora] Contenção do sistema afetado [nome] Foi desconectado [sistema] da rede
[data e hora] Notificação a [autoridade/cliente/funcionário] [nome] Notificação enviada por [canal]
[data e hora] Erradicação do malware [nome] Foi eliminado [malware] usando [ferramenta]
[data e hora] Restauração de sistemas [nome] Foi restaurado [sistema] a partir do backup [nome do backup]

3. Análise de causas-raiz (RCA)

Usar o método dos "5 porquês":

Problema: O servidor de faturamento foi criptografado por ransomware.

1. Por quê? Porque um funcionário clicou em um link malicioso em um e-mail.

2. Por quê? Porque o e-mail parecia legítimo (phishing com logo de um fornecedor real).

3. Por quê? Porque o funcionário não havia recebido treinamento em phishing nos últimos 6 meses.

4. Por quê? Porque o treinamento não é obrigatório na empresa.

5. Por quê? Porque não há uma política de segurança formal que exija treinamento periódico.

Causa-raiz: Falta de uma política de segurança que inclua treinamento periódico em phishing.

4. Lições aprendidas