Uma equipe de TI com três pessoas pode responder a um incidente de segurança em menos de 4 horas se seguir um playbook baseado no NIST SP 800-61 e usar ferramentas open source. A diferença entre conter um ransomware em minutos ou perder dias em recuperação está em documentar quatro fases: preparação, detecção, contenção e post-mortem — não no orçamento.

Por que a equipe pequena é mais rápida que a grande?

As PMEs latino-americanas respondem a incidentes 37% mais rápido que empresas com equipes de segurança dedicadas, segundo dados da CyberShield em 2023. A razão não é técnica: é organizacional. Uma equipe de 1-3 pessoas não tem camadas de aprovação, reuniões de alinhamento nem escalonamentos burocráticos. Mas essa mesma agilidade se transforma em caos se não existir um playbook escrito.

Em 2022, uma PME mexicana de logística perdeu 18 horas para conter um ataque de ransomware porque o único administrador de sistemas tentou "consertá-lo" reiniciando servidores sem isolá-los primeiro. O malware se propagou para os backups. A empresa pagou resgate não por falta de ferramentas, mas por falta de processo. Documentamos na CyberShield: 82% dos incidentes em PMEs da América Latina se agravam por ações improvisadas nas primeiras duas horas.

O NIST SP 800-61 Rev 2 define quatro fases para resposta a incidentes. Em equipes pequenas, essas fases não são sequenciais: são paralelas. Enquanto um membro isola um endpoint, outro notifica o CSIRT nacional e o terceiro documenta em um ticket. A chave está em dividir responsabilidades por habilidades, não por cargos.

Fase 1: Preparação — o playbook que cabe em uma página

Um playbook útil para PMEs deve ter três características: ser curto, ser executável por alguém que não é especialista em segurança e estar impresso em um local visível. O modelo que usamos na CyberShield para clientes tem este formato:

1. Detecção inicial
- Ferramenta: Wazuh (open source) com regras personalizadas para a América Latina (ex.: detecção de phishing em espanhol).
- Ação: Se o Wazuh gerar um alerta de nível "High" ou "Critical", a equipe deve:
a) Verificar no console do Wazuh se o evento está correlacionado com outros.
b) Tirar screenshot do dashboard e anexá-lo ao ticket.
c) Notificar o responsável designado (ex.: "João é o POC para incidentes esta semana").

2. Contenção
- Endpoint: Desconectar o equipamento da rede (cabo físico ou WiFi). Não desligar.
- Servidor: Isolar VLAN no switch (comando: switchport access vlan 999).
- Cloud: Revogar permissões IAM temporárias e rotacionar chaves de API.

3. Comunicação
- Interno: Grupo de WhatsApp/Telegram com todos os funcionários. Mensagem pré-aprovada: "Incidente de segurança em andamento. Não abrir e-mails nem baixar arquivos até novo aviso."
- Externo: Modelo de notificação para clientes (ver seção 5).
- CSIRT: Enviar relatório inicial ao CSIRT nacional nas primeiras 2 horas (obrigatório no México, Colômbia e Chile).

O playbook deve incluir também:

Ferramentas open source essenciais para esta fase:

Na CyberShield verificamos que uma equipe de duas pessoas pode implantar essas ferramentas em menos de 4 horas usando contêineres Docker. O custo: zero, além do tempo de configuração.

Fase 2: Detecção — como distinguir um falso positivo de um ataque real em 15 minutos

68% dos alertas em PMEs são falsos positivos, segundo dados da ENISA. A diferença entre ignorar um alerta real e perder tempo com um falso está em três perguntas:

  1. O evento afeta um ativo crítico? (Ex.: servidor de faturamento, banco de dados de clientes).
  2. Há correlação com outros eventos? (Ex.: uma tentativa de login falha em um servidor + um processo desconhecido em execução).
  3. O comportamento é anômalo para esse usuário/equipamento? (Ex.: um contador que de repente executa PowerShell).

Regra prática: Se duas dessas três perguntas tiverem resposta afirmativa, o evento é um incidente até que se prove o contrário.

Exemplo concreto: Em 2023, uma PME argentina recebeu um alerta do Wazuh sobre um processo mimikatz.exe em um servidor. O administrador o descartou como falso positivo porque "o servidor não tem usuários interativos". O ataque evoluiu para ransomware em 3 horas. A empresa perdeu acesso a 5 anos de faturamento eletrônico. O correto teria sido:

  1. Verificar no Wazuh se havia outros eventos nesse servidor (havia: múltiplas tentativas de login RDP falhas).
  2. Isolar o servidor imediatamente (comando iptables -A INPUT -s IP_SERVIDOR -j DROP).
  3. Executar o Velociraptor para coletar evidências (velociraptor -v collect Windows.KapeFiles.Targets --output evidence.zip).

Ferramentas para acelerar a detecção:

Fase 3: Contenção — isolar sem destruir evidências

A contenção tem dois objetivos contraditórios: deter o ataque e preservar evidências. Em equipes pequenas, isso se traduz em:

  1. Contenção imediata (minutos):
    - Endpoints: Desconectar da rede (não desligar).
    - Servidores: Isolar VLAN ou bloquear IP no firewall.
    - Cloud: Revogar permissões IAM e rotacionar chaves de API.
    - E-mail: Bloquear domínio do remetente no gateway de e-mail (ex.: postfix access).
  2. Contenção a médio prazo (horas):
    - Criar um snapshot da máquina virtual ou disco rígido.
    - Executar ferramentas de forense remoto (Velociraptor, KAPE).
    - Alterar todas as senhas de contas privilegiadas.

Erro comum: Desligar um equipamento comprometido. Isso apaga a memória volátil, onde costumam residir artefatos críticos como chaves de criptografia de ransomware ou conexões ativas com C2. Em vez disso, usar ferramentas como dd para criar uma imagem forense do disco:

dd if=/dev/sda of=/mnt/backup/evidencia.img bs=4M status=progress

Na nuvem, tirar snapshots de instâncias e volumes antes de qualquer ação. Exemplo para AWS:

aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 --description "Snapshot pré-incidente"

Documentação obrigatória durante a contenção:

Fase 4: Post-mortem — o relatório que salva a empresa (e a equipe)

O post-mortem não é uma formalidade: é o documento que determina se a empresa sobrevive ao incidente. Deve responder três perguntas:

  1. O que aconteceu? (Timeline detalhado com horas e ações).
  2. Por que aconteceu? (Causa raiz: vulnerabilidade explorada, erro humano, falta de processo).
  3. O que faremos para que não aconteça novamente? (Ações concretas com responsáveis e prazos).

Modelo de post-mortem para PMEs (baseado no ENISA Good Practice Guide):

1. Resumo executivo
- Data e hora do incidente: [DD/MM/AAAA HH:MM].
- Tipo de incidente: [Ransomware/Phishing/Vazamento de dados/etc.].
- Impacto: [Ex.: "Perda de acesso a 3 servidores por 8 horas. Dados de clientes não comprometidos"].
- Tempo de detecção: [Minutos/horas desde o início do incidente].
- Tempo de contenção: [Minutos/horas desde a detecção].

2. Timeline
| Hora | Evento | Responsável | Evidência | |------------|------------------------------------------------------------------------|-------------|--------------------| | 14:32 | Wazuh alerta: processo mimikatz.exe no SRV-DB-01 | Ana | Screenshot #1 | | 14:35 | SRV-DB-01 isolado da rede (VLAN 999) | Luís | Logs do switch | | 14:45 | Velociraptor coleta evidências no SRV-DB-01 | Carlos | evidence.zip | | 15:10 | Notificação enviada ao CSIRT nacional | Ana | Ticket #INC-2023-04|

3. Causa raiz
- Vulnerabilidade explorada: [Ex.: "Conta de administrador com senha fraca (Password123)"].
- Vetor de ataque: [Ex.: "Phishing: funcionário clicou em link malicioso"].
- Falha no processo: [Ex.: "Não havia MFA em contas privilegiadas"].

4. Ações corretivas
| Ação | Responsável | Prazo | Status | |---------------------------------------------|-------------|------------|------------| | Implementar MFA em todas as contas admin | Luís | 7 dias | Pendente | | Treinamento em phishing para funcionários | RH | 14 dias | Pendente | | Atualizar regras do Wazuh para detecção de Mimikatz | Ana | 3 dias | Concluído |

O post-mortem deve ser revisado pela direção da empresa e compartilhado com o CSIRT nacional se o incidente envolveu dados pessoais. No México, a Lei Federal de Proteção de Dados Pessoais em Posse de Particulares (LFPDPPP) obriga a notificar o INAI em casos de violações de segurança. O modelo anterior atende aos requisitos de documentação para essas notificações.

Comunicação com o CSIRT nacional: o que dizer e o que não dizer

Os CSIRTs nacionais (ex.: CSIRT-MX no México, CSIRT-COL na Colômbia) são aliados, não auditores. Seu objetivo é ajudar a conter o incidente e prevenir ataques similares em outras empresas. O que deve ser incluído no relatório inicial (nas primeiras 2 horas):

O que não deve ser incluído no relatório inicial:

Exemplo de relatório inicial para o CSIRT-MX (via e-mail ou formulário web):

Assunto: Relatório de incidente - Ransomware LockBit - [Nome da Empresa]

Prezado time do CSIRT-MX,

Notificamos um incidente de segurança na [Nome da Empresa] ocorrido em [data] às [hora]. Detalhes:

  • Tipo de incidente: Ransomware (LockBit 3.0).
  • IPs envolvidas: 192.168.1.100 (servidor comprometido), 185.143.223.43 (C2 suspeito).
  • Impacto: 3 servidores criptografados. Dados de clientes não comprometidos.
  • Ações tomadas: Servidores isolados da rede, evidências coletadas com Velociraptor.

Anexamos logs iniciais e estamos à disposição para coordenar ações.

Atenciosamente,
[Nome]
[Cargo]
[Telefone de contato]

O CSIRT pode solicitar informações adicionais, como amostras de malware ou logs completos. Na CyberShield, observamos que as PMEs que colaboram com o CSIRT nacional contêm incidentes 40% mais rápido, graças ao threat intelligence compartilhado.

Notificação a clientes: modelo que cumpre regulamentações da América Latina

Se o incidente envolveu dados pessoais, a notificação aos clientes é obrigatória na maioria dos países da América Latina. O modelo deve ser claro, empático e cumprir os requisitos legais. Exemplo para o México (LFPDPPP):

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

Prezado/a [Nome do Cliente],

Na [Nome da Empresa], levamos a segurança de seus dados muito a sério. Lamentamos informar que em [data] detectamos um incidente de segurança que pode ter afetado a confidencialidade de alguns de seus dados pessoais armazenados em nossos sistemas.

O que aconteceu?
Em [data], às [hora], detectamos um acesso não autorizado a um de nossos servidores. Imediatamente ativamos nosso protocolo de resposta a incidentes e isolamos o sistema afetado. Trabalhamos com especialistas em cibersegurança para conter o incidente e estamos colaborando com as autoridades competentes.

Quais dados podem ter sido afetados?
De acordo com nossa investigação, os dados que podem ter sido comprometidos são: [ex.: "nome, endereço de e-mail e número de telefone"]. Gostaríamos de esclarecer que [ex.: "não foram afetados dados financeiros, como números de cartões de crédito ou senhas"].

O que estamos fazendo?
Tomamos as seguintes medidas para proteger seus dados e prevenir incidentes futuros:

  • Contivemos o incidente e eliminamos o acesso não autorizado.
  • Reforçamos nossos controles de segurança, incluindo [ex.: "autenticação multifator em todas as contas administrativas"].
  • Estamos colaborando com o INAI e o CSIRT-MX para investigar o incidente.

O que você pode fazer?
Recomendamos:

  • Ficar atento a comunicações suspeitas que possam usar seus dados pessoais.
  • Alterar suas senhas em outros serviços se você usa a mesma senha que na [Nome da Empresa].
  • Reportar qualquer atividade suspeita para [e-mail de suporte].

Entendemos a preocupação que situações como esta podem gerar e lamentamos sinceramente qualquer inconveniente. Para qualquer dúvida, entre em contato conosco pelo [telefone] ou [e-mail de suporte].

Atenciosamente,
[Nome do CEO ou responsável]
[Nome da Empresa]

Regulamentações-chave na América Latina que exigem notificação a clientes:

O descumprimento dessas notificações pode resultar em multas de até 4% da receita anual da empresa (LGPD no Brasil) ou sanções penais (Lei 1581 na Colômbia).

Na CyberShield, operamos cibersegurança 24/7 para PMEs da América Latina com stack próprio: agente endpoint multi-OS, monitoramento de CVE em tempo real e resposta 24/7. Observamos que as empresas que implementam esses processos não apenas respondem mais rápido a incidentes, mas também reduzem sua exposição a multas regulatórias. A preparação não é um gasto: é um seguro contra a interrupção do negócio.

A resposta a incidentes em equipes pequenas não se trata de ter mais ferramentas, mas de ter processos claros e pessoas treinadas para executá-los. Um playbook de uma página, ferramentas open source bem configuradas e comunicação proativa com autoridades e clientes podem fazer a diferença entre um incidente contido em horas e uma crise que coloque em risco a continuidade do negócio. Da próxima vez que um alerta de segurança soar, o relógio começará a contar. A pergunta é: sua equipe estará pronta para agir ou para improvisar?

Fontes

  1. NIST Special Publication 800-61 Revision 2 (2012) — Computer Security Incident Handling Guide. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
  2. ENISA (2018) — Good Practice Guide for Incident Management. https://www.enisa.europa.eu/publications/good-practice-guide-for-incident-management
  3. CSIRT-MX (2023) — Guia para a Notificação de Incidentes de Segurança. https://www.gob.mx/cms/uploads/attachment/file/548932/Guia_Notificacion_Incidentes_Seguridad.pdf
  4. INAI (2021) — Guia para a Notificação de Violações de Segurança. https://home.inai.org.mx/wp-content/uploads/2021/03/Guia-Notificacion-Brechas-Seguridad.pdf
  5. CyberShield System (2023) — Relatório Anual de Incidentes em PMEs da América Latina. Dados internos de 124 incidentes respondidos em 2022-2023. https://cybershieldsystem.site
  6. Cichonski, P. et al. (2012) — Computer Security Incident Handling Guide. NIST Special Publication 800-61 Revision 2. https://doi.org/10.6028/NIST.SP.800-61r2
  7. ENISA (2022) — Threat Landscape for Ransomware Attacks. https://www.enisa.europa.eu/publications/enisa-threat-landscape-for-ransomware-attacks
  8. Caso público: Ataque a PME mexicana de logística (2022). Fonte: Comunicado interno da empresa (documentado no relatório CyberShield).
  9. Lei Federal de Proteção de Dados Pessoais em Posse de Particulares (LFPDPPP), México. https://www.diputados.gob.mx/LeyesBiblio/pdf/LFPDPPP.pdf
  10. Lei Geral de Proteção de Dados (LGPD), Brasil. http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm