Resiliência a Ransomware: Porque avaliar agora e o que realmente importa
As organizações continuam a investir em prevenção de ransomware. E devem continuar. Mas a conversa mudou de tom: hoje já não falamos só de prevenir, mas sim de recuperar com previsibilidade quando (não se) acontecer um incidente.
É este o enquadramento certo para avaliar resiliência: menos obsessão com ferramentas isoladas, mais foco na continuidade do negócio.
O ransomware como risco operacional
O ransomware deixou de ser um evento raro. É um risco operacional que afeta transversalmente qualquer organização:
- Interrupção completa de operações
- Exfiltração de dados e dupla extorsão
- Custos diretos de recuperação e indiretos de perda de confiança
- Pressão regulatória crescente (RGPD, NIS2)
- Seguros de ciber-risco cada vez mais exigentes
A pergunta que realmente importa é simples:
“Se tivermos um incidente amanhã, quanto tempo demoramos a voltar a operar?”
Um assessment de resiliência credível tem de responder a isto com dados concretos, não com suposições.
Como os atacantes realmente entram
Depois de acompanhar múltiplos incidentes, o padrão é consistente. Os atacantes entram por onde é mais fácil:
Email e engenharia social — O phishing continua a ser a porta principal. Um colaborador cansado, um link aparentemente legítimo, e pronto.
Credenciais comprometidas — Passwords reutilizadas, MFA mal configurado ou simplesmente inexistente. RDP exposto na internet continua a ser surpreendentemente comum.
Vulnerabilidades conhecidas — VPNs sem patches, portais web desatualizados. Os atacantes têm catálogos de vulnerabilidades e fazem scan sistemático.
Cadeia de fornecimento — Aquele fornecedor com acesso privilegiado que foi comprometido? É um vetor cada vez mais explorado.
Movimento lateral — Uma vez dentro, o problema amplifica-se: privilégios excessivos, partilhas abertas, abuso de ferramentas legítimas do Windows.
Isto não se resolve com uma ferramenta mágica. Requer camadas de defesa e, sobretudo, evidência de que funcionam quando é preciso.
O que avaliar num assessment de resiliência
A lista não precisa de ser longa. Precisa de ser essencial e verificável.
1. Governação e cadeia de comando
- Quem declara o incidente? Quem decide se pagamos resgate?
- Que serviços são críticos e qual a ordem de recuperação?
- Existe um mapa claro de dependências entre sistemas?
Se estas respostas não existem ou demoram dias a obter, há um problema.
2. Controlos nos vetores de ataque
- Estado real dos controlos de email, identidades e endpoints
- Segmentação de rede e privilégio mínimo implementado
- Ciclo de patching consistente e verificável
- Acessos de terceiros sob controlo
Não basta ter as ferramentas. É preciso provar que estão configuradas e funcionais.
3. Backups e capacidade de recuperação
Este é o ponto crítico. “Temos backups” não é resposta suficiente.
- Arquitetura 3-2-1: três cópias, dois tipos de media, uma offline/imutável
- RTO e RPO definidos por serviço crítico
- Testes regulares de recuperação — quando foi o último restore completo do Active Directory?
- Segregação total — as credenciais de backup não podem ser as mesmas do domínio
Sem testes documentados, não há confiança. Simples.
4. Gestão de vulnerabilidades
- Inventário atualizado de ativos
- Scans regulares internos e externos
- Processo de remediação com prazos definidos, para vulnerabilidades críticas e importantes.
Exceções? Podem existir, mas documentadas e com responsável assumido.
5. Fator humano e treino
Para além de testes e taxa de cliques em phishing, existe uma outra dimensão muitas vezes esquecida: a taxa de reporte.
Se os colaboradores não reportam emails suspeitos, o problema não é técnico — é cultural. Testes regulares, formação contextual e criar um ambiente onde seja encorajado, por exemplo com uma plataforma de “rewards”.
6. Deteção e resposta
- Capacidade de identificar sinais anómalos rapidamente
- Playbooks testados para diferentes cenários
- Tempo de deteção medido e melhorado continuamente
O que distingue um assessment útil de mais um relatório é a sua objetividade, ao apresentar lacunas específicas e comprovadas com impacto claro em vez de generalidades. Deve ser fundamentado em resultados de testes reais e não só em suposições teóricas. Testes práticos que fazem a diferença
Os testes podem passar por:
Teste de recuperação — Escolhe um sistema aleatório. Restaura para a semana passada. Funciona? Quanto tempo demora?
Simulação de ransomware — Numa sexta às 17h, simula a encriptação de três servidores. Mede o tempo até deteção, decisão e início de recuperação.
Exercício Tabletop com twist — A meio do exercício, o responsável de TI “perde acesso”. E agora?
Em Conclusão
Falar de ransomware sem testar a recuperação é teatro de segurança.
Um assessment de resiliência deve validar as proteções aos diversos vetores de ataque, testar vulnerabilidade técnicas e humanas e capacidade de recuperação, convertendo prevenção teórica em capacidade real de resposta. É a diferença entre esperar que nada aconteça e estar preparado para quando acontecer.
Porque no final do dia, a questão não é se vamos ser atacados. É como resistimos e recuperamos.
