Continuidade de Negócio sob Ataques de Ransomware
Continuidade de Negócio sob Ataques de Ransomware
Atualizado em: 2026-10
O que você vai aprender:
- Como projetar e testar um programa de continuidade de negócio resistente a ataques de ransomware.
- Controles técnicos e organizacionais para reduzir RTO e RPO durante incidentes de criptografia massiva.
- Playbooks operacionais aplicáveis a Blue Team, SOC e líderes de crise, além de contrajogo para Red Team.
Pré-requisitos: conhecimento prático de redes, backups, SIEM, forense digital básica, princípios de DR/BCP e frameworks como MITRE ATT&CK e NIST-CSF.
Nível: avançado
Sumário:
- Contexto Atual e Relevância Estratégica
- Fundamentos Técnicos do Tema
- Arquitetura, Fluxos e Superfície de Ataque
- Cenários Reais e Estudos de Caso
- Implementação Prática Step-by-Step
- Hardening, Controles e Melhores Práticas
- Playbooks Operacionais para Blue Team e Red Team
- Métricas, KPIs e Auditoria Técnica
- Erros Comuns, Armadilhas e Correções
- FAQ Técnico para Busca Orgânica
- Considerações Finais
- Referências
Em dezembro de 2025, uma empresa de logística global teve operações paralisadas por 72 horas após um ransomware criptografar controladores de domínio e backups off-site mal configurados. A história não é incomum: nas últimas operações de investigação que participei, o padrão se repete – invasão inicial via credenciais comprometidas, escalonamento, movimento lateral e criptografia em massa em janelas de manutenção. Este artigo entrega, com linguagem direta e técnica, o que uma organização precisa projetar, testar e operar para manter negócios críticos em pé quando a ameaça é ransomware.
Contexto Atual e Relevância Estratégica
Ransomware evoluiu de ferramenta de lucro oportunista para vetor estratégico com impacto direto em continuidade de negócio. Nos últimos anos observamos duas tendências convergentes que tornam a continuidade sob ransomware uma prioridade executiva: aumento da automação do ataque e expansão do alvo para cadeias de suprimento e OT/ICS. A consequência: planos de recuperação que dependem de backups simples já não funcionam quando atacantes deletam snapshots, corrompem catálogos de backup ou exploram permissões de storage.
Planejar continuidade para ransomware exige tratar os atacantes como adversários capazes de negar, sabotar ou manipular seus backups e processos de recuperação.
Decisão de risco: priorizar RTO (Recovery Time Objective) e RPO (Recovery Point Objective) por serviço crítico, não por sistema. A técnica de “recuperar tudo” é lenta e perigosa; recupere o mínimo viável para aceitar operações essenciais e isole o resto até validação forense.
Métrica estratégica: metas de recuperação devem ser quantificadas em testes. Exemplo: reduzir RTO para serviços de faturamento para menos de 4 horas e RPO para menos de 15 minutos em casos de transações financeiras. Estes números orientam escolhas arquiteturais – replicação síncrona, storage imutável e orquestração de failover.
Backups rotulados como ‘offline’ podem ser falsos seguros se scripts de manutenção automatizados conectarem volumes para verificação. Validar imutabilidade e isolamento lógico é obrigatório.
Regulação e compliance: autoridades em 2025/2026 intensificaram exigências de planos de recuperação testados, notificação de incidentes e retenção de evidências. Organizações que não conseguem comprovar recuperação em testes podem enfrentar multas e perda de contrato. Isso transforma continuidade em controle de compliance, além de função operacional.
1 2 3 4 5 6 7 | Fluxo de decisão executivo sob ataque: attacker -> detecção inicial -> comitê de crise? |-> ativar isolamento e MTD |-> validar backups imutáveis |-> executar failover para DR controlado |-> comunicação legal/regulatória |-> rollback parcial após forense |
Fundamentos Técnicos do Tema
Modelos de impacto – risco operacional x reputacional
Ransomware causa três vetores de impacto: indisponibilidade (operacional), exfiltração e exposição (reputacional/regulatório) e custo direto (pagamento/resposta). Cada vetor exige contramedidas distintas; por exemplo, criptografia massiva exige rollbacks e reconstrução de serviços, enquanto exfiltração demanda medidas legais e mitigação de vazamento. Em BC, priorize indisponibilidade em primeiro lugar porque restauração falha amplifica os outros vetores.
1 2 3 4 5 6 7 8 9 10 11 | +---------------------------+ | Camada de decisão (policy)| +---------------------------+ | +---------------------------+ | Controles e lógica | +---------------------------+ | +---------------------------+ | Telemetria e evidência | +---------------------------+ |
Arquitetura mínima para Resistência
Componentes mínimos que suportam continuidade sob ransomware: 1) backups imutáveis e isolados; 2) repositórios de configuração (IaC) versionados e off-site; 3) identidades privilegiadas segregadas e rotacionadas; 4) logs centralizados com retenção WORM; 5) orquestração de recovery automatizada. Ausência de qualquer componente aumenta MTTR linearmente.
Implemente o princípio do menor privilégio para contas de backup e snapshot. Use service principals com escopo restrito e chaves rotacionadas automaticamente.
Mecanismos técnicos detalhados
Backup imutável – tecnologias: Object Lock (S3), immutability no Azure Blob, WORM em storage on-prem. Trade-off: imutabilidade protege contra deleção maliciosa, mas aumenta custo de storage e exige políticas de expiração cuidadosas para não violar retenções legais.
Snapshots consistentes – para aplicações transacionais (DBs), use backups consistentes via VSS para Windows e dump + transaction log para PostgreSQL/MySQL. Comando exemplo para PostgreSQL streaming backup:
1 2 | # iniciar basebackup pg_basebackup -D /var/lib/pgsql/backup -F tar -z -X stream -h primary.db.example |
Validação: aplique WAL até o último checkpoint e rode consultas de sanity check (contagens, checksums) para confirmar integridade.
Detecção precoce e telemetria necessária
Para reduzir MTTD, SIEM deve receber: logs de endpoint (EDR), logs de Active Directory, alertas de subprocessos suspeitos, criação de arquivos em massa, alteração de shadow copies, e telemetia de storage. Regras Sigma ou queries Splunk devem cobrir padrões de ransomware como ‘múltiplos processos em massa escrevendo .locked’ ou ‘remoção de snapshots de storage’.
Exemplo de regra Sigma (resumida): detectar processos que invocam VSSADMIN ou similares após criação de conexões RDP anormais. Trade-off: regras com thresholds baixos reduzem falsa negativa mas aumentam alertas falsos positivos – necessite tuning por ambiente.
Arquitetura, Fluxos e Superfície de Ataque
Superfície de ataque clássica
Entradas comuns: phishing, VPN com MFA bypass, RDP exposto, credenciais vazadas, supply chain. Em 2024-2026 houve aumento de ataques que usam APIs de fornecedores para pivotar – exija revisão de integrações e segrego privilégios de API.
| Vetor | Exploração típica | Impacto em BC | Mitigação-chave |
|---|---|---|---|
| Phishing | Compromisso de credencial -> execução inicial | Início da cadeia de impacto | EDR/EPP, MFA FIDO2, phishing simulation |
| RDP exposto | Brute force / exploits | Escalonamento rápido | VPN com jump hosts, NVA, segmentação |
| Backdoor em SI | Update trojanizado | Compromete cadeia de atualização | SBOM, code signing, verificação de integridade |
| Permissões de storage | Deleção de snapshots | Destruição de backups | Imutabilidade, segregação de contas |
Arquitetura recomendada por criticidade
O design de continuidade deve mapear criticidade do serviço em zonas de recuperação. Exemplo: Zona A – serviços de negócio essenciais (ERP, faturamento), Zona B – serviços de suporte (email), Zona C – serviços não críticos. Para cada zona, defina RTO/RPO e o modelo de replicação (síncrono, assíncrono, offline).
1 2 3 4 5 6 7 | Arquitetura simplificada de recuperação: Usuários -> LB -> App Servers (Zona A) |-> DB Primário (replica síncrona para DR) |-> Storage principal Backups -> Repositório Imutável (S3 Object Lock) - réplica externa Logs -> SIEM central (WORM retention) EDR -> Console isolado com rede separada para administração |
Purdue model e OT/ICS
Para ambientes OT/ICS, adote uma versão do Purdue model com controles estritos entre levels 2-3. Ransomware em PLCs ou HMIs exige procedimentos de fail-safe físicos. A decisão de recovery pode incluir restaurar controladores a firmwares limpos e reconfigurar redes de controle em VLANs temporárias para retomar operações críticas sem exposição à IT afetada.
Em OT, restauração rápida frequentemente significa reinicialização de dispositivos com firmware limpo, não restauração de imagens comprometidas. Tenha imagens firmware verificadas e isoladas por dispositivo modelo.
Cenários Reais e Estudos de Caso
Estudo de caso – ataque com exclusão de snapshots
Resumo: atacante obteve credenciais de serviço, escalou privilégios e removeu snapshots antes de lançar criptografia. Backups estavam no mesmo tenant cloud com administrador de storage compartilhado. Resultado: recuperação dependente de backup em fita físico de longa retenção – RTO = 5 dias, perda de receita significativa. Conclusão: isolar contas de backup e usar imutabilidade independente do tenant.
| Elemento | Problema | Correção adotada |
|---|---|---|
| Contas de backup | Privilégio excessivo | Service principals com escopo mínimo e credenciais rotativas |
| Snapshots | Visíveis ao admin padrão | Storage com Object Lock e repositório secundário off-tenant |
| Testes | Sem validação frequente | Testes trimestrais com runbooks e validação de integridade |
Estudo de caso – ataque à cadeia de suprimentos
Resumo: fornecedor de backup de terceiros foi comprometido. Atacantes injetaram código nos agentes de backup para exfiltrar chaves de criptografia. Organização que fez validação por assinatura de agentes detectou anomalia antes de falha. Lição: SBOM e assinaturas de código são controles essenciais.
Anatomia do ataque moderno
Tempo médio de comprometimento inicial a criptografia em incidentes recentes: 7-14 dias. No entanto, ataques com acesso a AD e scripts automatizados podem reduzir a janela para poucas horas. Isso exige detecção precoce e automação de isolamento.
Implementação Prática Step-by-Step
Checklist inicial antes de projeto
- Mapeamento de serviços críticos e dependências externas.
- Inventário de backups e repositórios com responsável atribuído.
- Plano de comunicação e cadeia de governança para crise.
- Revisão de contas com privilégios sobre storage e snapshots.
- Banco de imagens e firmware verificado para OT.
Passo a passo para implementar continuidade resistente
- Identificar e priorizar serviços críticos com RTO/RPO definidos por SLT.
- Arquitetar repositórios de backup imutáveis em múltiplas zonas e, quando possível, em múltiplos provedores.
- Segregar identidades de backup – criar service accounts com escopo mínimo e MFA baseado em hardware.
- Implementar replicação e orquestração de failover com playbooks automatizados para cada serviço crítico.
- Integrar EDR e SIEM para detecção de padrões de criptografia e modificações de snapshots.
- Testar recuperação por amostragem semanal para serviços de baixa criticidade e testes completos trimestrais para críticos.
- Implementar verificação de integridade de backup com checksums e sanidade de aplicação.
- Estabelecer cadeia de custódia para evidências e processos legais para incidentes com exfiltração.
- Treinar times de negócio em processos mínimos de operação em modo degradado.
- Executar exercícios tabletop e red team focusing on backup sabotage scenarios.
Cada passo deve ter KPIs e responsáveis. Exemplo: passo 6 (testes): KPI = percentual de backups validados com sucesso por trimestre >= 95%.
1 2 3 4 5 6 7 | [ Inventário ] -> [ Baseline ] -> [ Mudança em Dev/Test ] | v [ FAT / SAT ] | v [ Produção + monitoramento ] |
1 2 3 4 5 | # Exemplo: validar backup PostgreSQL (checksum simples) pg_restore -l backup.tar.gz | head -n 20 # restaurar em ambiente isolado pg_restore -d restore_db backup.tar.gz psql -d restore_db -c "SELECT count(*) FROM orders;" |
Validação e automação
Automatize testes de restauração em um ambiente controlado. Ferramentas como Ansible, Terraform, e pipelines CI podem orquestrar restaurações e executar scripts de sanidade. Exemplo de playbook Ansible para restaurar VM a partir de snapshot:
1 2 3 4 5 6 7 8 9 10 | - name: Restore VM from snapshot hosts: localhost tasks: - name: Create volume from snapshot community.cloud.azure_rm_manageddisk: resource_group: rg name: restored_disk snapshot: snapshot-id - name: Attach disk to temp VM and run validation script ... |
Trade-off: orquestração automatizada acelera recovery mas necessita de proteções para evitar que automação seja usada por atacante. Proteja pipelines CI/CD com segredos em vault e controle de acesso rigoroso.
Hardening, Controles e Melhores Práticas
Matriz de controles por fase do ciclo de ataque
| Fase ATT&CK | Controle Técnico | Controle Organizacional | Matriz de teste |
|---|---|---|---|
| Initial Access | MFA FIDO2, filtro de phishing, EDR | Treinamento, política de risco de terceiros | Test phishing campaigns; MFA bypass simulation |
| Execution | Application whitelisting, EDR behavioral rules | Patch management SLAs | Execute benign test payloads em lab |
| Persistence | Account use anomalies, LSA protection | Certificação de hardening AD | Simular criação de service accounts |
| Impact | Immutable backups, snapshot retention | BCP com runbooks | Destruição simulada de snapshot e recovery |
Configurações técnicas essenciais
Active Directory hardening prático: habilite auditing de Kerberos, monitoramento de ticket lifetime, restrinja MS-RPC exposto, e aplique LAPS para gestão de senhas locais. Para backup: restrinja ACLs no bucket S3 para negar ações de delete em roles padrão.
1 2 3 4 5 6 7 8 9 | Rede/Segmentação | Identidade (RBAC/MFA/ZTNA) | Integridade de projeto e modo RUN | Validação em runtime / I/O | Observabilidade + IR OT |
Exemplo de política S3 Object Lock (simplificada):
1 2 3 4 | aws s3api put-object-retention \ --bucket backup-bucket \ --key db-backup.tar.gz \ --retention '{"Mode":"GOVERNANCE","RetainUntilDate":"2030-01-01T00:00:00"}' |
Protegendo os planos de recuperação
Crie runbooks com permissões separadas para execução. A orquestração de recovery deve usar contas distintas daquelas usadas por operações diárias. Implemente aprovação em duas fases para alterações de recovery que possam afetar integridade de dados. Isso previne que atacante use o mesmo caminho para restaurar ambientes com código malicioso.
Mantenha cópia offline de scripts de recuperação e chaves de acesso em cofre físico ou HSM com controle de acesso baseado em hardware.
Hardening OT/ICS – práticas críticas
Para ICS, minimize conectividade entre IT e OT; defina filtros deep-packet inspection nas fronteiras; armazene backups de configurações de PLCs em mídias imutáveis e fora do domínio corporativo. Realize testes de restauração em banco de dispositivos antes de qualquer failover em produção.
Playbooks Operacionais para Blue Team e Red Team
Playbook Blue Team – resposta a ransomware
Objetivo: limitar alcance do ataque, preservar evidências e recuperar serviços críticos de forma segura.
1 2 3 4 | [ Detectar ] --> [ Contornar / Contenção ] ^ | | v [ Lições ] <------- [ Recuperar + validar ] |
- Isolamento rápido: desative portas externas e cortar segmentos identificados; registrar timestamps e responsáveis.
- Captura de memória e imagens dos endpoints críticos via ferramentas aprovadas (FTK Imager, OSFMount).
- Ingest dos artefatos no repositório forense com hash SHA256; bloqueio de alterações.
- Desligar processos de backup se estiverem corrompendo repositório; colocar repositórios imutáveis em modo de leitura.
- Executar playbook de failover por zona crítica – ativar VMs pré-provisionadas ou replicadas em DR.
- Comunicação controlada: notificar stakeholders, jurídico e regulador; preparar statements públicos com vagas mínimas de detalhe técnico.
- Validação pós-recovery: scanning de integridade, validação de logs e breakpoints para detectar persistência.
- Revisão post-mortem com métricas e ações corretivas priorizadas.
Ferramentas e queries de detecção
Exemplo de query Splunk para detectar criação massiva de arquivos com extensão comum de ransomware:
1 | index=endpoint "CreateFile" OR "WriteFile" | stats count by file_name, host | where count > 500 |
Regra MITRE mapping: T1486 – Data Encrypted for Impact. Use EDR para bloquear processos que leem grandes quantidades de arquivos e escrevem extensões suspeitas.
Playbook Red Team – teste de resiliência
Objetivo: testar hipóteses de ataque realistas sem danificar dados de produção, avaliar RTO/RPO e capacidade de resposta.
- Negociação de escopo e escada de autorização formal com evidence handling definido.
- Simular exfiltração sem remover dados reais; usar payloads benignos que simulam comportamento de criptografia (rename massivo, criação de arquivos ‘encrypted’).
- Tentar deleção de snapshots com contas escaladas simuladas e medir tempo detectável.
- Validar recuperação: forçar rollback parcial e medir RTO por serviço.
- Reportar gaps com recomendações priorizadas e playbooks atualizados.
Playbook resumido
| Fase | Ação | Produtos |
|---|---|---|
| Detect | Correlacionar EDR+SIEM sinais | Sigma rules, Splunk, Elastic |
| Contain | Isolar segmentos e bloquear credenciais | Firewall policies, NAC |
| Eradicate | Remover artefatos e contas comprometidas | EDR remediation, AD hardening |
| Recover | Orquestrar failover e validar integridade | Ansible, Terraform |
| Learn | Post-mortem e atualização de playbooks | Relatório forense |
Métricas, KPIs e Auditoria Técnica
KPIs essenciais para continuidade sob ransomware
Defina e meça periodicamente:
1 2 3 4 | [ Coleta ] -> [ Indicador ] -> [ Limiar/alerta ] ^ | | v [ Melhoria ] <-------------- [ Ação / ticket ] |
- MTTD (Mean Time To Detect) objetivo: U1 menor que 1 hora para sinais de criptografia em massa.
- MTTR (Mean Time To Recover) por serviço crítico: objetivo alinhado ao SLT – ex.: ERP < 4 horas.
- Taxa de backups validados: >= 95% por trimestre.
- Tempo médio para restaurar 1 TB de dados: medido em horas por TB; metas para ajustar capacidade.
- Porcentagem de contas com privilégio sobre storage que passar por rotação de credential trimestral: 100%.
Métricas técnicas mensuráveis
Admita métricas técnicas que impactam BC: latência de replicação, janelas de snapshot, largura de banda disponível para recovery e taxa de crescimento de dados. Exemplo: se a replicação assíncrona atingir backlog > 2 horas, o RPO real aumenta; monitorar e alertar em thresholds.
Auditoria técnica e compliance
Audite configurações de backup, acessos e logs. Auditoria deve incluir verificação de imutabilidade (objeto criado com lock), revisão de ACLs e hashes de backup. Ferramentas de auditoria automatizada podem gerar evidências para reguladores.
| Área | Métrica | Frequência de auditoria |
|---|---|---|
| Backups | % validados com sucesso | Semanal |
| Logs | Taxa de ingestão no SIEM (GB/dia) | Diário |
| Snapshots | Imutabilidade verificada | Mensal |
| AD | Contas privilegiadas ativas | Mensal |
Erros Comuns, Armadilhas e Correções
Erro – confiar em snapshots locais
Muitos arquitetos acreditam que snapshots locais em storage primário são suficientes. No entanto, scripts maliciosos podem excluir snapshots referenciando a API de storage se tiverem permissões. Correção: armazenamento off-tenant com Object Lock e segregação de contas.
1 2 3 4 | [ Anti-padrão ] --> [ Sintoma ] --> [ Correção ] | v [ Evidência / regressão ] |
Erro – validar apenas a criação de backup
Validar que um backup foi criado não é o mesmo que validar restauração. Realize restaurações parciais para validar integridade de dados e consistência. Métrica recomendada: tempo total de restauração por TB e número de inconsistências detectadas por 100 restores.
Erro – automação sem proteções
Scripts de automação que executam restaurações podem ser abuseados por atacantes. Controle o acesso ao repositório de automação e use assinaturas digitais em playbooks. Habilite logging imutável em pipelines de orquestração.
Correção prática – segmentação e janelas seguras
Implemente janelas de manutenção controladas com registros e janelas de rollback automáticas para minimizar exposição de snapshots durante operações planejadas.
FAQ Técnico para Busca Orgânica
O que é RTO e RPO e como definir metas realistas?
RTO (Recovery Time Objective) é o tempo máximo aceitável para restaurar um serviço após falha. RPO (Recovery Point Objective) é a quantidade máxima de perda de dados tolerável, medida em tempo. Defina metas por análise de impacto de negócio; serviços financeiros normalmente exigem RTO muito baixo (<4 horas) e RPO próximo de zero (replicação contínua).
Como garantir que backups não sejam comprometidos?
Use repositórios imutáveis (Object Lock/WORM), segregue contas de backup com escopo mínimo, replique dados para múltiplos provedores e valide integraidade por checksums e testes de restauração regulares.
É seguro pagar resgate para recuperar dados?
Do ponto de vista técnico, pagamento não garante recuperação completa ou ausência de vazamento. Juridicamente, pode ter implicações. Do ponto de continuidade, priorize recuperar com backups testados; pagamento é opção tática com trade-offs legais e reputacionais.
Quantas cópias de backup são necessárias?
Aplicando 3-2-1: pelo menos três cópias, em dois tipos de mídia, sendo uma off-site. Para ransomware, fortalecer com 3-2-1-1: adicionar mídia imutável offline ou off-tenant.
Como reduzir tempo de recuperação para grandes volumes de dados?
Use replicação incremental e orquestração que priorize serviços críticos. Configure reposições delta e readiness VMs pré-provisionadas para reduzir tempo de restauração de imagens.
Quais logs são imprescindíveis para investigação?
Logs de AD (auth events), EDR (processos, comandos), storage (API calls para snapshot/delete), SIEM agregados e logs de rede para conexões externas. Retenção WORM é recomendada para evidência legal.
Como testar se estamos prontos para um ataque real?
Realize exercícios tabletop trimestrais, execução de restores automatizados e red team focused on backup sabotage. Teste com cenários de exfiltração e deleção de snapshots para avaliar resposta real.
Qual a relação entre DR e BC no contexto de ransomware?
DR (Disaster Recovery) é componente técnico focado em restaurar sistemas. BC (Business Continuity) foca em manter funções de negócio. Contra ransomware, DR sem planos de continuidade operacional (workarounds manuais, processos alternativos) não é suficiente.
Como proteger sistemas OT sem interromper produção?
Implemente segmentação de rede baseada em funcionalidades, mantenha imagens firmware verificadas e teste restores em rigs isolados. Adote estratégias que permitam fallback manual para controle de dispositivos sem conexão com IT comprometida.
Quais são os indicadores iniciais de um ataque de ransomware?
Indicadores: aumento súbito de processos de criptografia, criação/exclusão de snapshots, elevação de privilégios no AD, pico de conexões RDP, tráfego anômalo de exfiltração para IPs externos, execução de ferramentas de ofuscação ou compressão em massa.
Como registrar evidências sem comprometer continuidade?
Capture imagens e hashes antes de qualquer alteração de sistema; utilize repositórios forenses isolados e mantenha cadeia de custódia. Quando executar recovery, use cópias restauradas para validação para não alterar evidências originais.
Considerações Finais
Continuidade sob ransomware não é apenas tecnologia – é política, governança, processos e testes. O objetivo não é eliminar a possibilidade de ataque, mas reduzir janela de impacto e recuperar funções essenciais de forma segura e verificável. Investimentos em imutabilidade, segregação de identidades e testes práticos trazem retornos diretos na redução de MTTR e perdas financeiras.
Se você sair daqui com uma única ação priorizada: faça hoje um teste de restauração controlado de um serviço crítico e cronometre todos os passos. Métricas reais expõem lacunas que planilhas e discursos não conseguem.
Próximo passo: execute o checklist de verificação de backups e recuperação em 30 dias. Baixe a checklist, realize um teste de restauração para um serviço crítico e documente RTO/RPO reais.
Kit de lab
Kit de lab: ambiente mínimo reproduzível para testes de ransomware e recovery: 1 VM AD, 2 VMs Windows Server com VSS, 1 servidor PostgreSQL, repositório S3 local com Object Lock (MinIO), SIEM Elastic e EDR open-source (Wazuh). Instruções rápidas: provisionar com IaC (Terraform), criar snapshots automatizados e validar restaurações semanais.
Checklist de auditoria
Checklist de auditoria:
| Item | Verificação | Status |
|---|---|---|
| Imutabilidade | Object Lock configurado e testado | OK/NA |
| Segregação | Contas de backup com escopo mínimo | OK/NA |
| Testes | Restauração trimestral documentada | OK/NA |
| Logging | Logs de storage e AD em SIEM com retenção | OK/NA |
| Pipeline | Proteção de automação (assinatura e vault) | OK/NA |
Matriz de controles
Matriz de controles: implemente controles por camada – prevenção, detecção, resposta e recuperação. Utilize MITRE ATT&CK para mapear técnicas a controles e D3FEND para contramedidas técnicas.
Recursos Visuais Sugeridos
Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.
- MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
- CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
- NIST Cybersecurity Framework – figuras oficiais e referências de controles.
- ENISA – relatórios anuais com gráficos e mapas de ameaça.
- Kali Linux – documentação oficial com fluxos práticos.
- Parrot Security – documentação oficial com arquitetura modular.
Referências
- “2024 Data Breach Investigations Report”, Verizon, 2024, https://www.verizon.com/business/resources/reports/dbir/
- “Ransomware: What It Is and How to Protect Yourself”, CISA, 2024, https://www.cisa.gov/ransomware
- “MITRE ATT&CK”, MITRE, 2024, https://attack.mitre.org/
- “D3FEND Knowledge Base”, MITRE, 2023, https://d3fend.mitre.org/
- “NIST SP 800-34 Rev.1 Contingency Planning Guide for Federal Information Systems”, NIST, 2010, https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final
- “ISO 22301:2019 Business Continuity Management Systems”, ISO, 2019, https://www.iso.org/standard/75106.html
- “Sophos State of Ransomware 2024”, Sophos, 2024, https://www.sophos.com/en-us/medialibrary/pdfs/whitepaper/sophos-state-of-ransomware-2024-wp.pdf
- “Microsoft Digital Defense Report 2024”, Microsoft, 2024, https://www.microsoft.com/en-us/digital-defense-report
- “Emsisoft Annual Threat Report 2024”, Emsisoft, 2024, https://www.emsisoft.com/en/blog/
- “Practical Incident Response: A Guide”, SANS Institute, 2023, https://www.sans.org/white-papers/
- “CIS Controls v8”, Center for Internet Security, 2021, https://www.cisecurity.org/controls/
- “ENISA Threat Landscape 2023 – Ransomware”, ENISA, 2023, https://www.enisa.europa.eu/topics/csirt-cert-services
- “Recovering from Ransomware: Backup Strategies”, AWS Whitepaper, 2024, https://aws.amazon.com/whitepapers/
- “MinIO Documentation – Object Lock”, MinIO, 2024, https://min.io/docs/minio/linux/overview.html
