Incidentes de segurança: tipos, causas, como detectar e responder com eficácia

Em maio de 2017, o ransomware WannaCry criptografou os arquivos de mais de 230.000 sistemas em 150 países em menos de 24 horas. O NHS britânico cancelou 19.000 consultas médicas. Hospitais desviaram ambulâncias porque seus sistemas de registro e diagnóstico ficaram inacessíveis. A vulnerabilidade que o WannaCry explorava — a EternalBlue no protocolo SMB do Windows — tinha um patch disponível há dois meses. A maioria dos sistemas afetados simplesmente não o havia aplicado.

Três anos depois, o ataque à SolarWinds demonstrou um vetor diferente e mais sofisticado: em vez de explorar vulnerabilidades conhecidas, atacantes inseriram código malicioso diretamente nas atualizações legítimas de um software amplamente usado. Agências do governo americano, empresas Fortune 500 e provedores de infraestrutura crítica instalaram a atualização infectada sem suspeitar. O comprometimento durou meses antes de ser detectado.

Esses dois casos capturam a amplitude do problema: incidentes de segurança vão de ataques oportunistas que exploram patches atrasados a operações de espionagem de estado com planejamento de anos. O que os une é que ambos tinham padrões detectáveis, e ambos poderiam ter sido contidos mais rapidamente com planos de resposta mais maduros.

Neste artigo, você vai entender o que define um incidente de segurança com precisão técnica, os seis tipos mais relevantes com análise dos mecanismos e casos reais, os fatores organizacionais e técnicos que amplificam vulnerabilidades, como estruturar as quatro fases de resposta a incidentes com playbooks práticos, as ferramentas que compõem um stack de detecção eficaz, e o quadro regulatório que define obrigações de notificação. Se você trabalha com segurança da informação ou é responsável pela continuidade de operações digitais, este guia tem o que você precisa.

O que define um incidente de segurança

A distinção que determina a resposta

Um evento de segurança é qualquer ocorrência observável em um sistema ou rede — um login bem-sucedido, um arquivo modificado, uma conexão de rede estabelecida. A grande maioria dos eventos é normal e esperada.

Um incidente de segurança é um evento ou conjunto de eventos que comprometem ou ameaçam comprometer a confidencialidade, integridade ou disponibilidade de informações ou sistemas. A distinção importa operacionalmente: um SOC que trata todo evento como incidente ficará paralisado pelo volume; um que filtra mal perde incidentes reais no ruído.

O NIST SP 800-61 (Computer Security Incident Handling Guide) fornece a definição operacional mais usada: uma violação real ou iminente de políticas de segurança de computadores, políticas de uso aceitável, ou práticas padrão de segurança.

Os vetores de origem dos incidentes:

• Ataques externos — atores maliciosos fora da organização explorando vulnerabilidades, usando engenharia social, ou comprando acesso a credenciais vazadas
• Ameaças internas — funcionários mal-intencionados, funcionários negligentes, ou terceiros com acesso autorizado que o abusam
• Falhas técnicas — bugs, misconfigurações, software sem suporte que criam vulnerabilidades exploráveis
• Erros operacionais — backups que não foram testados, deploys que expõem dados, configurações de cloud incorretas

💡 Dica: A maioria dos frameworks de resposta a incidentes distingue incidentes de violações (breaches). Uma violação é um incidente confirmado que resultou em acesso ou exposição não autorizada de dados. Essa distinção importa para fins regulatórios: a LGPD e o GDPR impõem prazos de notificação específicos para violações — não para todos os incidentes. Classificar corretamente desde o início da investigação direciona as obrigações de comunicação.

Os seis tipos mais relevantes de incidentes

1. Malware: o espectro mais amplo de ameaças

Malware é o termo guarda-chuva para qualquer software projetado para causar dano, obter acesso não autorizado, ou comprometer a integridade de sistemas. A família é diversa e os mecanismos de ação variam significativamente.

Vírus se anexam a arquivos legítimos e ativam código malicioso quando o arquivo hospedeiro executa. A propagação depende de ações do usuário — abrir o arquivo infectado, executar um instalador comprometido. O vírus ILOVEYOU (2000) se propagou via e-mail como um arquivo VBS que se auto-enviava para toda a lista de contatos do Outlook ao ser aberto, causando danos estimados em US$ 10 bilhões.

Worms dispensam o arquivo hospedeiro e a ação do usuário: exploram vulnerabilidades de rede para se propagar automaticamente. O worm Morris (1988) foi o primeiro incidente documentado de worm em escala — infectou aproximadamente 6.000 sistemas (10% da internet da época). O WannaCry é tecnicamente um cryptoworm: se propagava automaticamente via EternalBlue e instalava o componente de ransomware nos sistemas infectados.

Trojans se disfarçam de software legítimo — um utilitário, um jogo, uma atualização de software — mas executam código malicioso em background. Trojans frequentemente instalam backdoors que permitem acesso remoto ao sistema infectado, ou funcionam como downloaders que instalam outros componentes de malware após o comprometimento inicial.

Spyware e keyloggers monitoram silenciosamente as atividades do usuário — teclas digitadas, screenshots, capturas de webcam — e exfiltram essas informações para o atacante. Frequentemente combinados com trojans ou entregues via phishing.

Rootkits operam no nível mais baixo do sistema operacional, modificando o kernel ou o bootloader para ocultar a presença de outros componentes de malware. A detecção de rootkits exige técnicas específicas porque o próprio sistema operacional comprometido não os revela em varreduras normais.

Indicadores de comprometimento (IoCs) comuns para malware:

• Processos desconhecidos consumindo CPU ou rede em horários incomuns
• Conexões de rede para IPs ou domínios desconhecidos
• Arquivos modificados com timestamps inconsistentes
• Entradas de autorun ou serviços não reconhecidos
• Degradação inexplicada de performance

2. Phishing e Engenharia Social: atacando o vetor humano

Phishing é a técnica de engenharia social mais prevalente: o atacante cria uma comunicação fraudulenta que imita uma fonte confiável para induzir a vítima a revelar credenciais, executar um arquivo malicioso, ou transferir fundos.

O relatório Verizon Data Breach Investigations Report consistentemente aponta phishing como o vetor inicial de comprometimento em mais de 35% das violações documentadas. A razão é econômica: comprometer um endpoint via phishing custa frações de centavo em escala; explorar vulnerabilidades zero-day exige recursos de estados-nação.

Spear phishing é a variante direcionada: o atacante personaliza a mensagem com informações específicas sobre a vítima — seu nome, cargo, projetos recentes, colegas de trabalho — coletadas via OSINT em LinkedIn, redes sociais e dados de vazamentos anteriores. A taxa de clique em spear phishing supera 30%, contra menos de 5% em phishing genérico.

Business Email Compromise (BEC) é uma categoria específica onde atacantes comprometem ou imitam contas de e-mail executivos para autorizar transferências financeiras ou mudanças em dados de fornecedores. O FBI estima perdas de US$ 2,9 bilhões em 2023 apenas nos EUA por BEC.

Vishing (phishing por voz) e smishing (por SMS) exploram canais onde usuários têm menos ceticismo histórico que e-mail. Golpes de “deep voice” — onde IA sintetiza a voz de um executivo — começaram a aparecer em incidentes documentados.

⚠️ Atenção: Treinamentos de phishing que apenas ensinam usuários a “não clicar em links suspeitos” têm eficácia limitada porque ataques sofisticados não parecem suspeitos. O treinamento eficaz inclui simulações regulares com feedback imediato, ensina a verificar domínios de e-mail, e cria um processo fácil para reportar mensagens suspeitas — porque um usuário que reporta vale mais do que um que deleta sem contar para ninguém.

3. Ransomware: extorsão cibernética em escala industrial

Ransomware evoluiu de ataques oportunistas e automatizados para operações criminosas estruturadas com divisão de trabalho, suporte técnico e até programas de afiliados. O modelo RaaS (Ransomware as a Service) permite que criminosos sem expertise técnica executem ataques sofisticados comprando acesso ao ransomware e à infraestrutura de suporte de grupos especializados.

O ciclo de um ataque moderno de ransomware segue fases bem definidas:

Acesso inicial — via phishing, exploração de vulnerabilidades em serviços expostos (RDP, VPN sem MFA, servidores web), ou compra de credenciais em mercados da dark web.

Persistência e movimentação lateral — o atacante não age imediatamente. Permanece na rede por dias ou semanas, mapeia a infraestrutura, eleva privilégios, e compromete backups. O objetivo é maximizar o impacto quando o ransomware finalmente executa.

Exfiltração — grupos modernos extraem dados antes de criptografar, criando o modelo de “dupla extorsão”: pagamento pelo decryptor e pagamento para não publicar os dados exfiltrados. Alguns grupos adicionam uma terceira extorsão: ameaçam notificar clientes e reguladores das vítimas.

Criptografia — o payload de ransomware criptografa arquivos, frequentemente usando criptografia de chave pública onde apenas o servidor do atacante tem a chave privada de descriptografia.

O custo médio de recuperação de um ataque de ransomware — incluindo tempo de inatividade, reconstrução de sistemas, investigação forense e custos reputacionais — supera o valor do resgate em 7 vezes, segundo dados da Sophos State of Ransomware Report.

O que backups protegem e o que não protegem: Backups funcionais e testados permitem restaurar operações sem pagar o resgate. Não protegem contra a ameaça de publicação dos dados exfiltrados, não evitam o tempo de inatividade da restauração (que pode ser dias ou semanas), e não funcionam se os backups também foram comprometidos pelo atacante durante a fase de movimentação lateral.

4. Ataques DDoS: interrompendo a disponibilidade

Ataques Distributed Denial of Service sobrecarregam um serviço, servidor ou rede com volume de tráfego que excede sua capacidade de processamento, tornando-o inacessível para usuários legítimos. A distribuição é o elemento que diferencia DDoS do DoS simples: o tráfego malicioso parte de milhares ou milhões de fontes simultâneas (botnets de dispositivos comprometidos), tornando a mitigação por bloqueio de IPs individuais impraticável.

Três categorias de DDoS por mecanismo:

Volumétrico — satura a banda disponível com tráfego massivo. O ataque de 3,8 Tbps registrado pela Cloudflare em 2024 é o maior documentado publicamente. Exige mitigação upstream (antes de chegar à infraestrutura da vítima) por CDNs e scrubbing centers.

Baseado em protocolo — explora vulnerabilidades em protocolos de rede para consumir recursos de dispositivos de infraestrutura. SYN floods exploram o handshake TCP; ataques de amplificação DNS/NTP usam servidores de terceiros para amplificar o volume de resposta enviada à vítima.

De camada de aplicação — simula tráfego legítimo em nível HTTP/HTTPS para esgotar recursos da aplicação. Mais difícil de detectar porque cada requisição individual parece válida. Requer análise comportamental para identificar padrões de bot.

DDoS frequentemente funciona como distração: enquanto o time de segurança concentra atenção no ataque volumétrico, um segundo vetor de ataque mais cirúrgico compromete sistemas críticos em paralelo.

5. Violações de dados (Data Breaches): exposição não autorizada de informações

Uma violação de dados é a confirmação de que dados sensíveis foram acessados, copiados, exfiltrados ou divulgados por alguém sem autorização. Distingue-se de outros incidentes porque o dano — exposição de informações — frequentemente é irreversível: uma vez que dados pessoais ou propriedade intelectual vazam, não há como “des-vazar”.

Os vetores de violação mais documentados:

Credenciais comprometidas — o Verizon DBIR aponta credenciais como o fator mais comum em violações. Credential stuffing (testar credenciais vazadas de um serviço em outros serviços), força bruta e phishing são as origens mais frequentes.

Misconfigurações de cloud — buckets S3, Azure Blob Storage ou Google Cloud Storage configurados como públicos por acidente. O caso da Socialarks (2021) expôs 3,7 bilhões de registros de um bucket público sem autenticação.

Vulnerabilidades de aplicação — SQL injection, SSRF e outras vulnerabilidades de código exploradas para extrair dados de bancos de dados ou sistemas internos.

Insider malicioso ou negligente — funcionário que exfiltra dados antes de sair, ou que envia um arquivo com dados sensíveis para o destinatário errado.

O custo médio de uma violação de dados atingiu US$ 4,88 milhões globalmente em 2024 (IBM Cost of a Data Breach Report), sendo que o custo médio no Brasil foi de R$ 6,75 milhões — com saúde e finanças liderando por setor.

6. Acesso não autorizado: o comprometimento silencioso

Acesso não autorizado descreve qualquer situação onde uma pessoa, sistema ou processo acessa recursos sem a permissão necessária. A categoria é ampla e inclui desde comprometimentos técnicos sofisticados até abusos por funcionários autorizados que excedem seus privilégios.

Comprometimento de credenciais é o vetor mais comum de acesso não autorizado externo. O atacante obtém credenciais válidas via phishing, credential stuffing, ou compra em mercados de dados roubados, e acessa sistemas como se fosse um usuário legítimo — o que torna a detecção especialmente difícil.

Exploração de vulnerabilidades dá acesso direto sem credenciais: a vulnerabilidade cria um caminho que o atacante percorre até chegar ao sistema ou dado desejado.

Abuso de acesso privilegiado (Insider Threat) ocorre quando funcionários com acesso legítimo o usam de forma não autorizada — acessar registros de clientes além do escopo do trabalho, copiar propriedade intelectual antes de sair da empresa, ou explorar acesso administrativo para fins pessoais.

Tokens de sessão roubados permitem acesso sem credenciais: o atacante captura um cookie de sessão válido via XSS e o usa para acessar a conta do usuário sem saber a senha.

Os fatores que amplificam vulnerabilidades

Entender por que incidentes acontecem vai além de catalogar os ataques — exige compreender as condições organizacionais e técnicas que os tornam possíveis e mais graves.

Gestão de patches: a janela de oportunidade

Cada vulnerabilidade publicada com patch disponível abre uma corrida: atacantes que desenvolvem exploits versus administradores que aplicam as correções. Os atacantes geralmente vencem porque organizações têm processos de patch lentos e os atacantes têm incentivos fortes e ferramentas automatizadas.

O WannaCry explorou a EternalBlue (MS17-010) dois meses após o patch estar disponível. O Equifax foi comprometido via CVE-2017-5638 (Apache Struts) três meses após a correção. O padrão se repete com consistência perturbadora: a vulnerabilidade que causa o próximo grande incidente frequentemente já tem patch disponível.

Gestão de patches eficaz requer inventário atualizado de todos os ativos (você não pode patchar o que não sabe que existe), priorização por severidade e exposição (CVSS score + contexto de ambiente), janelas de manutenção definidas e cumpridas, controles compensatórios para sistemas que não podem ser patcheados imediatamente (segmentação de rede, desabilitar o serviço vulnerável), e métricas que rastreiam tempo médio entre publicação do CVE e aplicação do patch.

Erros humanos: o vetor mais persistente

O relatório Verizon DBIR atribui elemento humano a 74% de todas as violações. Esse número não reflete incompetência generalizada — reflete que atacantes diretamente visam o vetor humano porque é mais fácil convencer uma pessoa a clicar do que explorar um sistema devidamente configurado.

Erros comuns com impacto significativo:

• Abrir anexos maliciosos em e-mails que parecem legítimos
• Reutilizar senhas entre serviços pessoais e corporativos
• Desabilitar alertas de segurança que são percebidos como “falsos alarmes frequentes”
• Copiar dados sensíveis para dispositivos pessoais sem aprovação
• Responder a chamadas de suporte técnico não solicitadas (vishing)
• Commitar credenciais em repositórios de código

Ameaças internas: o adversário com acesso legítimo

Ameaças internas são especialmente difíceis de detectar porque o ator começa com acesso autorizado. A CISA (Agência de Cibersegurança e Segurança de Infraestrutura americana) categoriza as ameaças internas em três perfis:

Insider malicioso — funcionário que intencionalmente rouba dados, sabota sistemas, ou vende acesso a terceiros. Frequentemente motivado por insatisfação, demissão iminente, ou ganho financeiro.

Insider negligente — funcionário que causa danos sem intenção maliciosa, por ignorância ou displicência.

Insider comprometido — funcionário cujas credenciais foram roubadas por um atacante externo, que as usa para acessar sistemas internamente.

A detecção de ameaças internas depende de analytics comportamentais: download incomum de volumes de dados, acesso a sistemas fora do padrão normal, atividade em horários atípicos, conexões com sistemas não relacionados à função. UEBA (User and Entity Behavior Analytics) detecta esses padrões automaticamente estabelecendo baselines de comportamento normal e alertando para desvios.

Tecnologia obsoleta: superfície de ataque não gerenciada

Sistemas fora de suporte criam vulnerabilidades que nunca serão corrigidas porque o fabricante não lança mais patches. Windows XP saiu de suporte em 2014; sistemas hospitalares rodando Windows XP foram comprometidos pelo WannaCry em 2017 exatamente porque não havia patch para EternalBlue disponível para essa versão.

Além dos sistemas operacionais sem suporte, frameworks e bibliotecas abandonadas, appliances de rede com firmware desatualizado e software de terceiros sem versão mantida pelo fornecedor compõem o inventário de tecnologia obsoleta que a maioria das organizações carrega.

As 4 fases de resposta a incidentes

O NIST SP 800-61 organiza a resposta a incidentes em quatro fases: preparação, detecção e análise, contenção/erradicação/recuperação, e atividade pós-incidente. Cada fase tem objetivos, atividades e métricas específicos.

Fase 1: preparação — o trabalho antes do incidente

A preparação determina a eficácia da resposta quando um incidente ocorre. Times que nunca praticaram a resposta a incidentes descobrem que os planos documentados têm lacunas críticas no pior momento possível.

O que a preparação inclui:

Plano de resposta a incidentes documentado com papéis e responsabilidades claros, fluxogramas de decisão para os cenários mais prováveis, procedimentos de comunicação interna e externa, e critérios de escalação.

CSIRT (Computer Security Incident Response Team) estruturado com membros identificados de engenharia, segurança, jurídico, comunicações e liderança executiva. Cada membro precisa conhecer seu papel antes de ser chamado às 2h da manhã.

Runbooks por tipo de incidente — playbooks específicos para ransomware, violação de dados, comprometimento de conta, ataque DDoS. Um runbook eficaz descreve ações concretas, não princípios gerais.

Exercícios de simulação (tabletop exercises) — reuniões estruturadas onde o time trabalha um cenário de incidente hipotético para identificar lacunas no plano sem a pressão de um incidente real.

Ferramentas e acesso pré-configurados — o time de resposta precisa de acesso aos sistemas de log, SIEM, e ferramentas forenses antes do incidente. Descobrir que não tem as permissões necessárias durante um incidente ativo desperdiça tempo crítico.

Fase 2: detecção e análise — identificando o que está acontecendo

A detecção precoce comprime drasticamente o custo de um incidente. O IBM Cost of a Data Breach Report de 2024 aponta que organizações que detectaram violações em menos de 200 dias tiveram custo médio de US$ 3,84 milhões, contra US$ 5,89 milhões para detecções acima de 200 dias.

Fontes de detecção:

SIEM correlaciona eventos de múltiplas fontes e dispara alertas para padrões de comportamento suspeito. A qualidade de um SIEM depende da qualidade dos dados que recebe — logs de autenticação, logs de rede, logs de endpoint, e logs de aplicação precisam fluir para o SIEM em tempo real.

EDR (Endpoint Detection and Response) monitora comportamento nos endpoints em nível de processo, memória e rede. Detecta comportamentos característicos de malware — injeção de processo, uso de ferramentas de living-off-the-land como PowerShell e certutil — que scanners de assinatura tradicionais não identificam.

Feeds de threat intelligence integrados ao SIEM correlacionam IPs, domínios e hashes de arquivo observados no ambiente com indicadores de comprometimento conhecidos de grupos de ameaça.

A análise de um possível incidente responde às perguntas:

• Qual é o escopo? Quantos sistemas, contas e dados potencialmente afetados?
• Qual é o vetor? Como o comprometimento ocorreu?
• Qual é o estado atual? O ataque continua ativo ou já concluiu?
• Qual é a prioridade de impacto ao negócio? Sistemas críticos estão afetados?

Fase 3: contenção, erradicação e recuperação

Contenção interrompe a propagação do incidente. A contenção curta isola sistemas imediatamente comprometidos da rede. A contenção longa implementa controles que permitem operações continuarem enquanto a investigação prossegue — segmentação de rede mais restritiva, revogação de credenciais comprometidas, bloqueio de IPs e domínios maliciosos identificados.

A decisão de contenção é um trade-off: contenção agressiva minimiza o dano mas pode interromper operações críticas e alertar o atacante que foi detectado (o que pode fazer ele acelerar o ataque). Contenção conservadora permite observar mais o comportamento do atacante mas permite que o dano continue.

Erradicação remove a causa raiz: eliminar malware dos sistemas infectados, fechar as vulnerabilidades exploradas, revogar credenciais comprometidas, e eliminar backdoors que o atacante instalou para manter acesso. Erradicação incompleta resulta em reinfecção — um dos erros mais custosos em resposta a incidentes.

Recuperação restaura sistemas ao estado operacional normal após confirmar que a ameaça foi eliminada. Restaurar a partir de backups anteriores ao comprometimento, verificar a integridade dos sistemas antes de reconectá-los à rede, e monitorar intensivamente nos dias após a recuperação para detectar sinais de persistência residual.

💡 Dica: Preservar evidências forenses antes de qualquer ação de remediação é crítico tanto para entender o incidente quanto para fins legais e regulatórios. Fazer um snapshot de memória e disco de sistemas comprometidos antes de isolá-los preserva evidências que não estarão mais disponíveis após o desligamento. Essa prática é especialmente importante quando um processo judicial ou notificação regulatória pode ser necessário.

Fase 4: pós-incidente — aprendendo para não repetir

O post-mortem (ou lessons learned) acontece dentro de 2 semanas do incidente, enquanto as memórias ainda estão frescas. O objetivo não é atribuir culpa — é entender objetivamente o que aconteceu e o que mudar para prevenir ou detectar mais rapidamente um incidente similar.

Perguntas centrais do post-mortem:

• Qual foi a linha do tempo completa desde o comprometimento inicial até a detecção?
• O que tornou possível o comprometimento inicial? A vulnerabilidade era conhecida? Havia controles que deveriam ter prevenido mas não funcionaram?
• O que atrasou a detecção? Havia logs que teriam revelado o ataque mais cedo?
• A contenção e erradicação foram eficazes? Houve reinfecção ou persistência residual?
• Quais mudanças de controles, processos ou ferramentas teriam reduzido o impacto?

O post-mortem deve produzir ações específicas com responsáveis e prazo — não recomendações genéricas de “melhorar a segurança”.

O stack de ferramentas de detecção e resposta

SIEM: o centro de correlação de eventos

SIEM (Security Information and Event Management) agrega logs de múltiplas fontes, correlaciona eventos temporalmente, e dispara alertas para padrões que indicam ameaças. A eficácia de um SIEM depende diretamente da qualidade e completude das fontes de dados integradas.

Fontes de dados essenciais para um SIEM:

• Logs de autenticação (Active Directory, Azure AD, Okta)
• Logs de acesso a sistemas críticos e dados sensíveis
• VPC Flow Logs ou equivalente de rede
• DNS logs — queries DNS são um dos melhores indicadores de C2 (command and control)
• Logs de endpoint via agente EDR
• Logs de aplicação para sistemas críticos

Microsoft Sentinel, Splunk, Elastic SIEM, e Google Chronicle são as principais plataformas. Para organizações menores, Wazuh é uma alternativa open source com capacidades relevantes.

EDR: visibilidade no endpoint

EDR (Endpoint Detection and Response) monitora comportamento nos endpoints em nível granular — processos criados, conexões de rede estabelecidas, arquivos modificados, acesso ao registro do Windows — e detecta comportamentos característicos de malware e ataques.

A distinção crítica em relação ao antivírus tradicional: EDR detecta comportamento, não assinaturas. Um malware sem assinatura conhecida que tenta injetar código em um processo legítimo, ou usa certutil para baixar um payload — comportamentos de living-off-the-land — aparece nos alertas do EDR mesmo sem uma regra específica para aquele malware.

CrowdStrike Falcon, SentinelOne, e Microsoft Defender for Endpoint são as plataformas líderes de mercado. Wazuh cobre EDR básico como plataforma open source.

Threat Intelligence: contexto para detecção

Threat intelligence feeds fornecem indicadores de comprometimento (IoCs) atualizados — endereços IP de servidores C2 conhecidos, domínios de phishing ativos, hashes de arquivos maliciosos — e informações sobre táticas, técnicas e procedimentos (TTPs) de grupos de ameaça específicos.

Integrar feeds de threat intelligence ao SIEM permite correlacionar atividade observada no ambiente com indicadores externos conhecidos. Uma conexão de um servidor interno para um IP listado como C2 ativo de um grupo de ransomware é um alerta imediato que sem threat intelligence seria apenas uma conexão de rede genérica.

MISP (Malware Information Sharing Platform) é a plataforma open source de referência para sharing de threat intelligence entre organizações. O framework MITRE ATT&CK cataloga TTPs de grupos de ameaça reais — uma referência fundamental para calibrar detecções e cobrir as táticas mais usadas por adversários relevantes para o setor.

Regulamentações que definem obrigações de notificação

LGPD: o regime brasileiro

A Lei Geral de Proteção de Dados (Lei 13.709/2018) estabelece no artigo 48 a obrigação de comunicar incidentes de segurança que possam acarretar risco ou dano relevante aos titulares. A Resolução CD/ANPD nº 2/2022 especificou os prazos: dois dias úteis para notificação preliminar à ANPD em casos de incidentes de alto risco.

O que a notificação deve conter:

• Descrição da natureza dos dados afetados
• Informações sobre os titulares envolvidos
• Indicação das medidas técnicas e de segurança utilizadas para proteção
• Riscos relacionados ao incidente
• Medidas adotadas ou que serão adotadas para reverter ou mitigar os efeitos

A ausência de notificação quando obrigatória, ou notificação com atraso injustificado, agrava a avaliação da ANPD em eventual processo sancionatório.

GDPR: o padrão europeu

O GDPR (Regulamento 2016/679) estabelece no artigo 33 o prazo de 72 horas para notificação à autoridade supervisora após o controlador “tomar conhecimento” da violação — não após a violação ocorrer. A notificação aos titulares afetados é obrigatória quando a violação provavelmente resultar em “alto risco” para seus direitos e liberdades.

Para organizações que processam dados de cidadãos europeus — independentemente de estarem sediadas no Brasil — o GDPR se aplica e as obrigações de notificação valem simultaneamente com as da LGPD.

HIPAA: dados de saúde nos EUA

O HIPAA exige que covered entities e business associates nos EUA notifiquem pacientes afetados dentro de 60 dias após descobrir uma violação de Protected Health Information (PHI). Violações que afetam mais de 500 residentes de um estado exigem notificação imediata à mídia local, além do HHS (Department of Health and Human Services).

Para organizações de saúde brasileiras que também operam nos EUA ou que processam dados de pacientes americanos, HIPAA se aplica em paralelo com LGPD.

Perguntas frequentes sobre Incidentes de Segurança

Incidentes de segurança são inevitáveis; o impacto não!

Ao longo deste artigo, ficou claro que incidentes de segurança não são eventos excepcionais a serem evitados a todo custo — são ocorrências esperadas que precisam ser detectadas rapidamente e contidas eficazmente. O WannaCry, o Equifax, o SolarWinds, e centenas de casos menos noticiados demonstram que organizações de todos os tamanhos, setores e níveis de maturidade de segurança experimentam incidentes.

O que separa organizações que atravessam incidentes com dano limitado daquelas que sofrem consequências devastadoras é a preparação: inventário de ativos atualizado que permite saber o que foi comprometido, logs suficientes para entender o que aconteceu, plano de resposta que o time praticou antes do momento de crise, e backups testados que permitem restauração confiável.

Os três princípios que guiam programas de resposta a incidentes maduros são sempre os mesmos: detecção precoce (cada hora entre o comprometimento e a detecção aumenta o custo do incidente), contenção antes da erradicação (interromper a propagação tem prioridade sobre a remoção completa da ameaça), e aprendizado sistemático (cada incidente é uma oportunidade de fechar lacunas que, sem ele, talvez nunca fossem identificadas).

Segurança perfeita não existe. Respostas eficazes a incidentes existem, e constroem-se antes que o incidente aconteça.

👉 Compartilhe este artigo com equipes de segurança, gestores de TI e líderes que precisam entender como incidentes funcionam e como preparar suas organizações para responder com eficácia — pode ser o ponto de partida para construir um programa de resposta antes que seja necessário.