A parte mais difícil de um incidente de segurança geralmente ocorre depois que o incidente em si termina: quando a empresa precisa explicar o que aconteceu, quando foi descoberto, quais dados foram envolvidos, quem foi afetado e por que certas decisões foram tomadas.
Para muitas PMEs, esses registros não existem de forma completa. Os detalhes podem estar espalhados por mensagens de chat, caixas de entrada, tickets de helpdesk, capturas de tela e na memória dos membros da equipe. As empresas se mantêm à tona durante um incidente com esses registros fragmentados, mas eles se tornam um problema quando autoridades de supervisão, uma seguradora, um cliente ou um membro do conselho pedem uma linha do tempo clara.
Empresas de todos os tamanhos precisam de um registro completo de incidentes de segurança. Ele deve ser uma fonte única de verdade para registrar o que aconteceu, como o incidente foi tratado e quais evidências sustentam as decisões tomadas ao longo do caminho.
O registro é valioso mesmo quando você não precisa relatar um incidente. Vamos explicar por que os registros de incidentes de segurança são úteis para sua empresa e como criar o seu próprio.
Por que os registros de incidentes de segurança são importantes
Registros de incidentes vs planos de resposta a incidentes
O que um registro de incidentes de segurança deve conter
Um modelo simples de registro de incidentes para PMEs
Como registrar decisões de notificação
O que as autoridades de supervisão esperam dos registros de incidentes de segurança
O registro de acesso a credenciais
Por que os registros de incidentes de segurança são importantes
Os registros de incidentes de segurança criam responsabilidade no momento em que uma empresa tem maior probabilidade de perder o controle dos detalhes. Durante um incidente, as ações acontecem rapidamente: senhas são redefinidas, contas são desativadas, provedores de TI são contatados, dados de clientes são verificados e a liderança é informada. Essas etapas podem ser exatamente o que a empresa precisa no momento, mas se tornam muito mais difíceis de explicar depois se ninguém registra quando cada ação aconteceu, quem a aprovou e quais evidências sustentaram a decisão.
Para empresas sediadas na Europa, isso não é apenas uma boa prática. De acordo com o Regulamento Geral de Proteção de Dados (GDPR), tanto no Reino Unido quanto na UE, as violações de dados pessoais precisam ser avaliadas, e algumas devem ser comunicadas à autoridade de supervisão correspondente.
No Reino Unido, a orientação comunicar uma violação(nova janela) do ICO explica que as organizações devem avaliar o risco provável aos direitos e liberdades das pessoas e notificar o ICO quando esse risco for provável. O Artigo 33 também exige que os controladores documentem violações de dados pessoais, incluindo os fatos da violação, seus efeitos e as medidas corretivas tomadas. Os mesmos requisitos se aplicam ao GDPR da UE.
Por exemplo, o ICO não espera que todas as PMEs tenham sistemas de nível empresarial, mas espera registros adequados. Sua estrutura de resposta e monitoramento de violações afirma que as organizações devem ter procedimentos para garantir que incidentes e violações de dados pessoais sejam detectados, gerenciados e registrados adequadamente. Isso significa que um registro de incidentes não deve ser criado apenas quando uma violação grave já aconteceu. Ele deve fazer parte do processo normal de resposta.
Bons registros também ajudam em sinistros de seguro. Seguradoras cibernéticas podem pedir evidências de quando o incidente foi descoberto, quais medidas de contenção foram tomadas, quais contas foram afetadas e se a empresa seguiu seu processo de resposta a incidentes. Um registro bem mantido pode mostrar que a empresa agiu prontamente e de forma consistente.
Também ajuda a empresa a aprender. Memórias e registros orais não são confiáveis, mas um registro que mostra que o incidente começou com uma senha reutilizada, falta de autenticação multifator (MFA), acesso de fornecedor ou desligamento tardio dá à empresa algo concreto para corrigir e uma direção mais clara para fortalecer a segurança ao longo do tempo.
Registros de incidentes vs planos de resposta a incidentes
Um registro de incidentes de segurança e um plano de resposta a incidentes estão conectados, mas não são o mesmo documento.
Um plano de resposta a incidentes explica o que a empresa deve fazer quando algo dá errado. Ele atribui funções, rotas de escalonamento, etapas de contenção, responsabilidades de comunicação e procedimentos de recuperação. O registro de incidentes documenta o que realmente aconteceu. Ele é a linha do tempo, a trilha de evidências, o registro de decisões e o arquivo de acompanhamento de um evento específico.
Essa distinção é importante porque até um bom plano pode falhar sem documentação. Uma empresa pode seguir as etapas corretas, mas ainda ter dificuldade para provar isso depois. O registro deve possibilitar responder a perguntas práticas: quando soubemos, quem agiu, o que contivemos, quais dados estavam em risco, o que decidimos e o que mudou depois?
| Plano de resposta a incidentes: o que sua empresa deve fazer | Registro de incidentes de segurança: o que realmente aconteceu |
| Quem lidera a resposta Quem contata TI, jurídico, seguradora ou reguladores Como conter, recuperar e comunicar | Quando o incidente foi descoberto Quais sistemas e dados foram afetados Quais ações foram tomadas, por quem e quando |
O que um registro de incidentes de segurança deve conter
Um registro de incidentes útil precisa ser consistente o suficiente para que uma empresa reconstrua o evento depois e explique as decisões tomadas durante a resposta.
Data e hora da descoberta
Registre quando a empresa tomou conhecimento do incidente pela primeira vez, quem o percebeu e como ele foi descoberto. Se o horário for aproximado, marque-o como aproximado. O horário da descoberta é importante porque os prazos de notificação do GDPR e os requisitos de seguro muitas vezes dependem de quando a empresa tomou conhecimento do problema.
Natureza do incidente
Descreva o que aconteceu em linguagem simples. Evite rótulos vagos como “problema de segurança” ou “possível violação” sem contexto. O registro deve explicar quais sistemas foram afetados e se o incidente envolveu credenciais, e-mail, arquivos, dados de clientes, sistemas de pagamento, pontos de extremidade ou acesso de terceiros.
Dados envolvidos
Se dados pessoais podem ter sido afetados, registre que tipo de dados foi envolvido: nomes, endereços de e-mail, números de telefone, endereços, detalhes de conta, informações financeiras, registros de funcionários, comunicações com clientes, credenciais de início de sessão ou qualquer outra categoria relevante. Estime quantas pessoas podem ser afetadas e deixe claro se o número é confirmado ou ainda está em investigação.
Causa provável
Registre a causa conhecida ou suspeita, mesmo que a investigação ainda esteja em andamento. À medida que novos detalhes surgem, o registro pode ser atualizado de “causa desconhecida” para “e-mail de phishing levou a comprometimento de credenciais” ou “conta de ex-contratado permaneceu ativa”. O registro deve mostrar como o entendimento da empresa mudou ao longo do tempo.
Ações imediatas de contenção
Documente o que foi feito para limitar os danos. Isso pode incluir redefinições de senha, revogação de sessão, aplicação de MFA, suspensão de conta, remoção de regra de caixa de correio, isolamento de dispositivo, remoção de acesso de fornecedor, alterações no firewall ou interrupções temporárias de serviço. Quando possível, inclua o responsável e o carimbo de data/hora de cada ação.
Decisões de notificação
Registre se a empresa notificou a autoridade de supervisão competente (a ICO no Reino Unido, ou a autoridade nacional de proteção de dados em outras partes da UE), as pessoas afetadas, os clientes, os fornecedores, as seguradoras, os assessores jurídicos ou as autoridades policiais. Se a decisão foi de não notificar, documente a justificativa. Essa explicação costuma ser tão importante quanto a própria notificação.
Etapas de remediação e cronograma
A contenção aborda o incidente imediato. A remediação reduz a chance de o mesmo problema acontecer novamente. Registre ações de acompanhamento, como aplicar MFA, remover credenciais compartilhadas, atualizar políticas de acesso, melhorar o desligamento, corrigir uma configuração incorreta ou alterar a forma como os backups são protegidos.
Lições aprendidas
Termine com o que a empresa aprendeu e o que vai mudar. Isso não deve ser escrito como culpa. Deve identificar a fraqueza, a melhoria necessária e quem é responsável pelo acompanhamento.
Um modelo simples de registro de incidentes para PMEs
Software especializado não é necessário para documentar incidentes. Uma planilha, um formulário interno seguro, um sistema de tickets ou um registro compartilhado podem funcionar se o acesso for controlado e os registros forem mantidos consistentes.
Um registro de incidentes eficaz deve incluir estes campos:
- ID do incidente: Um número de referência exclusivo.
- Data e hora da descoberta: Quando a empresa tomou conhecimento do incidente.
- Reportado por: Funcionário, prestador, cliente, fornecedor, alerta de monitoramento ou parte externa.
- Tipo de incidente: Phishing, malware, comprometimento de credenciais, perda de dados, acesso não autorizado, ransomware, incidente com fornecedor, perda de dispositivo, e-mail enviado por engano ou outro.
- Resumo: O que aconteceu, escrito em linguagem simples.
- Sistemas afetados: Aplicativos, contas, dispositivos, bancos de dados, caixas de entrada ou serviços de terceiros envolvidos.
- Dados envolvidos: Se dados pessoais foram afetados, de que tipo, e quantas pessoas podem ter sido impactadas.
- Causa provável: Conhecida, suspeita ou em investigação.
- Ações de contenção: O que foi feito imediatamente.
- Decisão de notificação: Autoridade supervisora, pessoas, clientes, seguradora ou nenhuma notificação com justificativa.
- Links de evidências: Capturas de tela, tickets, registros, e-mails, registros de acesso, arquivos exportados ou relatórios de prestadores.
- Ações de remediação: Medidas tomadas após a contenção.
- Responsável: Pessoa responsável pelo acompanhamento.
- Status: Aberto, em monitoramento, contido, resolvido, fechado.
- Lições aprendidas: O que deve mudar.
Como registrar decisões de notificação
As decisões de notificação merecem um espaço próprio em um registro de incidentes de segurança, pois costumam ser revisadas após o incidente.
No âmbito do GDPR do Reino Unido e da UE, as organizações devem avaliar o risco provável aos direitos e liberdades das pessoas quando ocorre uma violação de dados pessoais. Se o risco for provável, a autoridade supervisora deve ser notificada o mais rápido possível e, quando viável, em até 72 horas: a ICO(nova janela) no Reino Unido, a autoridade nacional de proteção de dados em cada estado-membro da UE. Se o risco for alto, as pessoas afetadas também devem ser notificadas sem demora injustificada. Os limites e o prazo são os mesmos dos dois lados; apenas a autoridade muda.
Um bom registro de incidentes deve mostrar que a empresa fez essa avaliação. Ele deve registrar se dados pessoais foram envolvidos, que tipo de dano poderia resultar, quais proteções estavam em vigor e por que a empresa decidiu notificar ou não.
Por exemplo, um incidente envolvendo uma senha de administrador exposta pode não revelar imediatamente se dados pessoais foram acessados. O registro deve refletir essa incerteza. Ele pode registrar a preocupação inicial, as etapas da investigação, a revisão da atividade da conta e a conclusão final quando houver evidências disponíveis.
Nesse ponto do processo, muitas empresas se concentram em organizar a correção técnica e esquecem de registrar a justificativa de conformidade. As senhas são redefinidas, as contas são protegidas e as operações continuam. Semanas depois, a empresa não consegue explicar por que decidiu que o incidente não era notificável.
O que as autoridades supervisoras esperam dos registros
As autoridades supervisoras não analisam apenas se uma violação foi notificada. Elas também podem perguntar como a empresa:
- Identificou o incidente
- Avaliou o risco
- Decidiu se a notificação era necessária
- Documentou as ações tomadas
Um bom registro deve deixar a história do incidente clara do início ao fim. Ele deve mostrar o que aconteceu, quais dados pessoais foram envolvidos, que dano poderia resultar, o que a empresa fez para conter o problema e por que notificou ou não a violação.
O nível de detalhe deve corresponder à gravidade do incidente. Um e-mail enviado por engano não precisará do mesmo registro que um ataque de ransomware, mas ainda precisa ser documentado para mostrar que a empresa o avaliou adequadamente.
Esses registros também devem ser armazenados com segurança. Os registros de incidentes podem incluir detalhes sensíveis sobre pessoas afetadas, sistemas expostos, ações de funcionários, capturas de tela, registros de acesso ou etapas de remediação. O acesso deve ser limitado às pessoas que precisam dele, e a retenção deve estar alinhada com a política mais ampla de retenção de dados da empresa.
O registro de acesso a credenciais
Muitos incidentes envolvem credenciais: eles podem ser desencadeados por uma senha reutilizada, uma conta compartilhada, uma caixa de entrada comprometida, um início de sessão de administrador exposto, uma solicitação de MFA suspeita ou um funcionário que não foi desligado corretamente.
Por esse motivo, os registros de acesso a credenciais podem se tornar uma entrada direta na documentação de incidentes de segurança cibernética. Quando um incidente envolve um início de sessão compartilhado ou uma conta sensível, a empresa precisa saber quem tinha acesso, como o acesso foi compartilhado, se as permissões mudaram e se a credencial foi rotacionada após o incidente.
Um gerenciador de senhas corporativo como o Proton Pass for Business ajuda as equipes a gerenciar credenciais em cofres criptografados, gerar senhas exclusivas, usar preenchimento automático, compartilhar credenciais com segurança, gerenciar passkeys e usar a autenticação de dois fatores integrada. Para a documentação de incidentes, o valor mais forte é a trilha de acesso em torno das credenciais: quem tinha acesso a cofres/contas compartilhados, como o acesso era gerenciado e quem o usava, e o que mudou após o incidente.
Um gerenciador de senhas para equipes de TI adiciona recursos de administrador, como políticas, relatórios, registros, controle de acesso baseado em funções, provisionamento SCIM e integração com SSO. Esses recursos podem ajudar as empresas a mostrar como o acesso a credenciais é controlado e fornecer evidências quando um incidente relacionado a credenciais é investigado.
Um gerenciador de senhas não substitui um registro de incidentes, uma avaliação jurídica, um processo de notificação regulatória ou um plano de resposta a incidentes. Mas ele fornece evidências de credenciais que podem alimentar esses processos.
Mantenha uma trilha de auditoria completa do acesso a credenciais com um gerenciador de senhas corporativo.
