O que é um incidente de segurança
"Um incidente de segurança da informação é qualquer evento que compromete a confidencialidade, integridade ou disponibilidade de sistemas, dados ou serviços de TI, ou que viola as políticas de segurança da organização."
A definição abrange um espectro amplo de situações. Exemplos concretos de incidentes de segurança incluem:
- Acesso não autorizado a sistemas ou dados por utilizadores internos ou externos
- Ransomware que cifra ficheiros e exige pagamento para os recuperar
- Fuga de dados (data breach) com exposição de informação confidencial ou pessoal
- Phishing com sucesso em que um colaborador revela credenciais a um atacante
- Compromisso de credenciais por força bruta, reutilização de passwords ou credential stuffing
Diferença entre evento de segurança e incidente de segurança
Nem tudo o que os sistemas de monitorização detectam é um incidente. Um evento de segurança é qualquer ocorrência observável que pode ter implicações de segurança: um login falhado, uma porta bloqueada pela firewall, uma anomalia no tráfego de rede. A maioria dos eventos é benigna.
Um incidente de segurança é um evento de segurança que foi confirmado como tendo impacto real ou potencial na organização. A triagem eficaz distingue ruído de ameaças reais, evitando que a equipa passe o tempo a investigar falsos positivos.
Do ponto de vista regulatório, o RGPD impõe uma obrigação clara: em caso de violação de dados pessoais, a organização tem 72 horas para notificar a autoridade de controlo. Em Portugal, essa autoridade é a CNPD (Comissão Nacional de Protecção de Dados). O incumprimento pode resultar em coimas significativas, além do dano reputacional.
Níveis de severidade
A classificação da severidade de um incidente de segurança determina a velocidade e a escala da resposta. Sem uma matriz de severidade clara, as equipas tendem a tratar todos os incidentes com a mesma urgência, o que desperdiça recursos e atrasa a resposta aos casos verdadeiramente críticos.
| Nível | Descrição | Exemplos | Tempo de resposta |
|---|---|---|---|
| P1 Crítico | Compromisso de dados sensíveis em larga escala, ransomware activo, indisponibilidade total de sistemas críticos | Ransomware a cifrar servidores de produção; exfiltração massiva de dados de clientes | Imediato (15 min) |
| P2 Alto | Acesso não autorizado a sistemas críticos, fuga de dados limitada, comprometimento de conta privilegiada | Acesso não autorizado à base de dados de RH; password de administrador comprometida | 1 hora |
| P3 Médio | Malware contido num endpoint, tentativa de phishing com sucesso parcial, anomalia confirmada sem impacto imediato | Trojan detectado e isolado numa workstation; colaborador clicou em link de phishing mas sem entrega de credenciais | 4 horas |
| P4 Baixo | Tentativa de ataque bloqueada, anomalia detectada sem impacto, violação menor de política | Scan de portas bloqueado pela firewall; tentativa de login falhada repetida de IP externo | Próximo dia útil |
A matriz de severidade deve ser aprovada pela gestão e incluída no plano de resposta a incidentes. O escalamento entre níveis deve estar também definido: um P3 que evoluiu pode tornar-se P2 se a contenção falhar.
A equipa de resposta
O CSIRT (Computer Security Incident Response Team), também designado IRT (Incident Response Team), é a equipa responsável por coordenar a resposta a incidentes de segurança. A sua existência formal, com papéis definidos e treinados, é o factor que mais distingue organizações com respostas eficazes daquelas que reagem de forma improvisada.
Papéis essenciais
- Incident Commander: coordena toda a resposta, toma decisões críticas, é o ponto de escala final durante o incidente. Idealmente o responsável de segurança (CISO ou equivalente).
- Analistas de segurança: investigam o incidente, recolhem evidências forenses, executam as acções de contenção e erradicação.
- Representante de TI operacional: conhece a infraestrutura, executa acções nos sistemas afectados (isolamento, restauro).
- Comunicação e relações públicas: gere a comunicação externa com clientes, media e reguladores. Fundamental em incidentes com exposição pública.
- Jurídico: avalia as obrigações legais e regulatórias, nomeadamente o cumprimento do RGPD, e aconselha sobre comunicação para evitar responsabilidade.
- Representante de negócio: toma decisões sobre impacto operacional e prioridades de recuperação do ponto de vista do negócio.
Activação e cadeia de escalamento
O plano deve definir claramente quem pode activar a equipa de resposta, como o fazer (canal de comunicação de emergência fora dos sistemas potencialmente comprometidos) e a cadeia de escalamento conforme a severidade do incidente.
Formação e simulacros
Uma equipa de resposta nunca treinada é uma equipa que vai falhar no momento crítico. Os tabletop exercises (simulacros de mesa) são sessões estruturadas em que a equipa pratica a resposta a cenários hipotéticos sem o stress de um incidente real. Permitem identificar lacunas no plano e nas competências antes de serem necessárias. A frequência recomendada é pelo menos anual, com exercícios mais frequentes para organizações com maior exposição.
As 6 fases de resposta (NIST)
O NIST (National Institute of Standards and Technology) publicou o guia SP 800-61, que define seis fases para a resposta a incidentes de segurança. Este framework é o mais adoptado a nível internacional e serve de base para a maioria dos planos de resposta a incidentes.
Preparação
A fase mais importante, embora ocorra antes de qualquer incidente. Inclui o desenvolvimento do plano de resposta, a constituição e treino da equipa, a aquisição e configuração de ferramentas de detecção e análise forense, e a definição de procedimentos para cada cenário. Uma organização que não investe na preparação irá sempre falhar nas fases seguintes.
Identificação
Detecção, triagem e confirmação de que existe efectivamente um incidente. As fontes de detecção incluem sistemas SIEM, alertas de antivírus e EDR, relatórios de utilizadores, monitorização de rede e threat intelligence. A triagem distingue falsos positivos de incidentes reais e classifica a severidade.
Contenção
Limitação do impacto e propagação do incidente. A contenção é feita em duas fases: contenção de curto prazo (isolamento imediato dos sistemas afectados para parar a propagação) e contenção de longo prazo (medidas que permitem operar com segurança enquanto a erradicação é preparada). Requer decisões rápidas sobre o trade-off entre disponibilidade e segurança.
Erradicação
Remoção completa da causa do incidente: malware, backdoors instalados pelo atacante, vulnerabilidades exploradas, credenciais comprometidas. Esta fase exige análise forense cuidadosa para garantir que nenhum vestígio do atacante permanece nos sistemas antes de avançar para a recuperação.
Recuperação
Restauro dos sistemas ao estado operacional normal, com monitorização reforçada para detectar qualquer sinal de reinfecção. A ordem de recuperação é definida com base na criticidade do negócio. Esta fase articula-se directamente com a gestão da continuidade de serviço.
Lições aprendidas
Reunião pós-incidente para documentar o que aconteceu, o que funcionou, o que falhou e o que deve ser melhorado. O objectivo não é atribuir culpas mas fortalecer a capacidade de resposta futura. As conclusões alimentam a actualização do plano e dos procedimentos.
"Nunca avançar da contenção para a recuperação sem concluir a erradicação. Restaurar sistemas comprometidos sem eliminar a causa raiz é o caminho mais curto para um segundo incidente."
Cenários comuns
A preparação para cenários específicos, com playbooks detalhados para cada um, reduz significativamente o tempo de resposta e o impacto. Estes são os três cenários mais frequentes nas organizações portuguesas.
Isolamento imediato dos sistemas afectados para parar a propagação (contenção de curto prazo). Nunca pagar o resgate: não garante a recuperação dos dados, financia criminosos e sinaliza a organização como alvo. Restauro a partir de backups testados e actualizados. Análise forense para identificar o vector de entrada e garantir que não existe persistência. Notificação à CNPD se dados pessoais foram afectados.
Avaliar o âmbito: que dados foram expostos, volume e sensibilidade. Se incluir dados pessoais, notificar a CNPD em 72 horas. Comunicar aos titulares dos dados afectados se o risco for elevado. Identificar e corrigir a vulnerabilidade ou configuração que permitiu a fuga. Monitorizar a dark web para detectar publicação dos dados.
Reset imediato de passwords das contas comprometidas. Revogar todas as sessões activas. Verificar todos os acessos realizados com as credenciais comprometidas para identificar o âmbito do incidente. Activar autenticação multi-factor (MFA) se ainda não estava activa. Investigar como as credenciais foram obtidas (phishing, password spray, data breach externo).
A gestão de riscos de TI ajuda a identificar os cenários mais prováveis antecipadamente, permitindo desenvolver playbooks antes de os necessitar.
Comunicação durante incidentes
Um dos aspectos mais subestimados da resposta a incidentes é a comunicação. Incidentes de segurança graves geram pressão enorme: a gestão quer saber o que está a acontecer, os utilizadores reportam problemas, os clientes tentam perceber se os seus dados estão seguros. Sem um plano de comunicação, a informação flui de forma desordenada e contraditória.
Canais de comunicação de emergência
O primeiro princípio é crítico: os canais de comunicação da resposta ao incidente devem ser independentes dos sistemas potencialmente comprometidos. Se o email corporativo ou o sistema de mensagens foi comprometido, comunicar por esse canal é comunicar directamente com o atacante. Tenha canais alternativos definidos: números de telefone pessoais, grupo de WhatsApp ou Signal, sala de reunião física.
Quem comunica, a quem e quando
Comunicação interna: a equipa de resposta recebe actualizações frequentes do incident commander. A gestão recebe actualizações regulares com nível de detalhe adequado. Os colaboradores afectados recebem instruções claras sobre o que fazer (ou não fazer). A regra é: informação suficiente para agir, sem criar pânico.
Comunicação externa: clientes e parceiros afectados devem ser notificados de forma clara e atempada. Reguladores (CNPD, se dados pessoais) têm prazos legais. A comunicação com media deve ser centralizada num único porta-voz e coordenada com o departamento jurídico.
Template de comunicação
Para cada audiência, o template deve incluir: o que aconteceu (factos confirmados), o impacto actual, o que está a ser feito, o que os destinatários devem fazer, e quando terão nova actualização. A regra fundamental é sempre a mesma: comunicar factos, não especulações. Uma comunicação que depois tem de ser corrigida agrava a crise de confiança.
Lições aprendidas
A fase de lições aprendidas fecha o ciclo de resposta a incidentes e é a que mais frequentemente é ignorada quando a pressão passa. É também aquela com maior potencial de retorno a longo prazo.
Reunião pós-incidente
A reunião pós-incidente deve realizar-se dentro de 5 dias úteis após o encerramento do incidente, enquanto os detalhes ainda estão frescos. Participam todos os elementos da equipa de resposta e os principais stakeholders afectados. O tom deve ser de aprendizagem, não de julgamento.
Relatório de incidente
O relatório documenta a cronologia completa do incidente, as acções tomadas em cada fase, o que funcionou bem, o que falhou ou demorou demasiado, e as recomendações de melhoria. Este documento tem dupla função: serve de referência interna para melhorar os procedimentos e pode ser exigido por reguladores ou auditores.
Actualização de procedimentos e playbooks
Cada incidente real ensina algo que os simulacros não conseguem replicar completamente. As descobertas devem traduzir-se em actualizações concretas: novos passos nos playbooks, ferramentas adicionais, formação específica, ou alterações à infraestrutura para prevenir recorrência.
Cultura de partilha sem culpa
A cultura de "blameless post-mortem", popularizada pelas equipas de engenharia de alta performance, é igualmente aplicável à resposta a incidentes de segurança. Quando os colaboradores temem consequências negativas por reportar erros ou pedir ajuda durante um incidente, as organizações ficam cegas aos seus próprios pontos fracos. A melhoria contínua garante que cada incidente reforça a postura de segurança em vez de apenas ser esquecido.
Descarregue a template de plano de resposta a incidentes
Plano de resposta a incidentes de segurança completo e adaptável à sua organização.
Perguntas frequentes
Documento que define os procedimentos, papéis e recursos para detectar, conter, erradicar e recuperar de incidentes de segurança da informação. Inclui cenários, matrizes de escalamento e protocolos de comunicação. Deve ser revisto regularmente e testado através de simulacros para garantir que funciona quando é verdadeiramente necessário.
72 horas após ter conhecimento da violação, se esta representar um risco para os direitos dos titulares dos dados. A notificação é feita à autoridade de controlo (CNPD em Portugal). Se o prazo não for cumprível com informação completa, notifica-se dentro do prazo com a informação disponível e complementa-se posteriormente. Omitir a notificação é um risco regulatório significativo.
As autoridades e especialistas de segurança recomendam não pagar. O pagamento não garante a recuperação dos dados, financia grupos criminosos e torna a organização um alvo para futuros ataques. Estudos mostram que uma parte significativa das organizações que pagam não recuperam os dados ou são atacadas novamente. A melhor protecção são backups testados, actualizados e armazenados offline (regra 3-2-1).
Pelo menos uma vez por ano com simulacros (tabletop exercises). Organizações com maior exposição a riscos devem realizar testes trimestrais. O plano também deve ser testado sempre que houver alterações significativas na infraestrutura, na equipa ou no contexto de ameaças. Um plano não testado é um plano que não funciona quando mais é necessário.
Um incidente de TI é qualquer interrupção não planeada de um serviço. Um incidente de segurança envolve especificamente a violação de confidencialidade, integridade ou disponibilidade por acção maliciosa, negligência ou vulnerabilidade. Todos os incidentes de segurança são incidentes de TI, mas nem todos os incidentes de TI são de segurança. Um servidor que cai por falha de hardware é um incidente de TI; o mesmo servidor comprometido por um atacante é um incidente de segurança.
No mínimo: responsável de segurança (incident commander), analistas de segurança, representante de TI operacional, jurídico e comunicação. Em organizações maiores, inclui-se também gestão de risco e representante de negócio. A composição exacta depende da dimensão da organização, mas é fundamental que todos os membros conheçam o plano e tenham praticado os seus papéis antes de um incidente real.
Quer preparar a organização para incidentes de segurança?
A formação ITIL e ISO 27001 da Better Skills dota as equipas com os frameworks e práticas para gerir incidentes com eficácia.
Ver formação disponível