A parte mais difícil de um incidente de segurança ocorre normalmente depois de o incidente terminar: quando a empresa tem de explicar o que aconteceu, quando foi descoberto, que dados estiveram envolvidos, quem foi afetado e porque foram tomadas determinadas decisões.
Para muitas PME, estes registos não existem de forma completa. Os detalhes podem estar dispersos por mensagens de chat, caixas de entrada, pedidos de apoio técnico, capturas de ecrã e memórias dos membros da equipa. As empresas mantêm-se à tona durante um incidente com estes registos fragmentados, mas estes tornam-se um problema quando as autoridades de supervisão, uma seguradora, um cliente ou um membro do conselho de administração pede uma cronologia clara.
Empresas de todos os tamanhos precisam de um registo de incidentes de segurança completo. Deve ser uma única fonte de verdade para registar o que aconteceu, como o incidente foi tratado e que provas sustentam as decisões tomadas ao longo do processo.
O registo é valioso mesmo quando não é necessário comunicar um incidente. Este artigo explica por que razão os registos de incidentes de segurança são úteis para a sua empresa e como criar o seu próprio registo.
Porque é que os registos de incidentes de segurança são importantes
Registos de incidentes versus planos de resposta a incidentes
O que deve conter um registo de incidentes de segurança
Um modelo simples de registo de incidentes para PME
Como registar decisões de notificação
O que as autoridades de supervisão esperam dos registos de incidentes de segurança
O registo de acesso a credenciais
Porque é que os registos de incidentes de segurança são importantes
Os registos de incidentes de segurança criam responsabilidade no momento em que é mais provável que uma empresa perca o rasto aos detalhes. Durante um incidente, as ações acontecem rapidamente: as palavras-passe são repostas, as contas são desativadas, os fornecedores de TI são contactados, os dados dos clientes são verificados e a liderança é informada. Estas medidas podem ser exatamente o que a empresa precisa no momento, mas tornam-se muito mais difíceis de explicar mais tarde se ninguém registar quando cada ação aconteceu, quem a aprovou e que provas sustentaram a decisão.
Para as empresas sediadas na Europa, isto não é apenas uma boa prática. Ao abrigo do Regulamento Geral sobre a Proteção de Dados (GDPR), tanto no Reino Unido como na UE, os incidentes com dados pessoais têm de ser avaliados e alguns devem ser comunicados à autoridade de supervisão correspondente.
No Reino Unido, a orientação do ICO para comunicar um incidente(nova janela) explica que as organizações têm de avaliar o risco provável para os direitos e liberdades das pessoas e notificar o ICO quando esse risco for provável. O artigo 33.º exige também que os responsáveis pelo tratamento documentem incidentes com dados pessoais, incluindo os factos do incidente, os seus efeitos e as medidas corretivas tomadas. Os mesmos requisitos aplicam-se ao abrigo do GDPR da UE.
Por exemplo, o ICO não espera que todas as PME tenham sistemas de nível empresarial, mas espera que tenham registos adequados. O seu quadro de resposta e monitorização de incidentes afirma que as organizações devem ter procedimentos para garantir que os incidentes de dados pessoais são detetados, geridos e registados de forma adequada. Isto significa que um registo de incidentes não deve ser criado apenas quando já ocorreu um incidente grave. Deve fazer parte do processo normal de resposta.
Os bons registos também apoiam os pedidos de indemnização aos seguros. As seguradoras cibernéticas podem pedir provas de quando o incidente foi descoberto, que medidas de contenção foram tomadas, que contas foram afetadas e se a empresa seguiu o seu processo de resposta a incidentes. Um registo bem mantido pode mostrar que a empresa agiu de forma pronta e consistente.
Também ajuda a empresa a aprender. As memórias e os registos orais não são fiáveis, mas um registo que mostre que o incidente começou com uma palavra-passe reutilizada, falta de autenticação multifator (MFA), acesso de fornecedores ou desvinculação tardia dá à empresa algo concreto para corrigir e uma direção mais clara para reforçar a segurança ao longo do tempo.
Registos de incidentes versus planos de resposta a incidentes
Um registo de incidentes de segurança e um plano de resposta a incidentes estão ligados, mas não são o mesmo documento.
Um plano de resposta a incidentes explica o que a empresa deve fazer quando algo corre mal. Atribui cargos, rotas de escalonamento, medidas de contenção, responsabilidades de comunicação e procedimentos de recuperação. O registo de incidentes regista o que realmente aconteceu. É a cronologia, o rasto de provas, o registo de decisões e o ficheiro de acompanhamento de um evento específico.
Essa distinção é importante porque mesmo um bom plano pode falhar sem documentação. Uma empresa pode seguir os passos certos, mas ainda assim ter dificuldade em prová-lo mais tarde. O registo deve permitir responder a questões práticas: quando é que se soube, quem agiu, o que foi contido, que dados estavam em risco, o que foi decidido e o que mudou depois?
| Plano de resposta a incidentes: o que a sua empresa deve fazer | Registo de incidentes de segurança: o que realmente aconteceu |
| Quem lidera a resposta Quem contacta a TI, o departamento jurídico, a seguradora ou os reguladores Como conter, recuperar e comunicar | Quando o incidente foi descoberto Que sistemas e dados foram afetados Que ações foram tomadas, por quem e quando |
O que deve conter um registo de incidentes de segurança
Um registo de incidentes útil tem de ser suficientemente consistente para que uma empresa possa reconstruir o evento mais tarde e explicar as decisões tomadas durante a resposta.
Data e hora da descoberta
Registe quando a empresa tomou conhecimento do incidente pela primeira vez, quem o detetou e como foi descoberto. Se a hora for aproximada, marque-a como aproximada. A hora da descoberta é importante porque os prazos de comunicação do GDPR e os requisitos dos seguros dependem frequentemente de quando a empresa tomou conhecimento do problema.
Natureza do incidente
Descreva o que aconteceu em linguagem simples. Evite etiquetas vagas como «problema de segurança» ou «possível incidente» sem contexto. O registo deve explicar que sistemas foram afetados e se o incidente envolveu credenciais, e-mail, ficheiros, dados de clientes, sistemas de pagamento, pontos finais ou acesso de terceiros.
Dados envolvidos
Se os dados pessoais podem ter sido afetados, registe que tipo de dados estiveram envolvidos: nomes, endereços de e-mail, números de telefone, endereços, detalhes de conta, informações financeiras, registos de colaboradores, 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 está confirmado ou ainda em investigação.
Causa provável
Registe a causa conhecida ou suspeita, mesmo que a investigação ainda esteja em curso. À medida que surgem novos detalhes, o registo pode ser atualizado de «causa desconhecida» para «e-mail de phishing levou a comprometimento de credenciais» ou «conta de antigo contratado permaneceu ativa». O registo deve mostrar como a compreensão da empresa mudou ao longo do tempo.
Ações imediatas de contenção
Documente o que foi feito para limitar os danos. Isto pode incluir reposições de palavras-passe, revogação de sessões, aplicação de MFA, suspensão de contas, remoção de regras de caixa de correio, isolamento de dispositivos, remoção de acesso de fornecedores, alterações de firewall ou encerramentos temporários de serviços. Sempre que possível, inclua o responsável e a data e hora de cada ação.
Decisões de notificação
Registe se a empresa notificou a autoridade de supervisão relevante — o ICO no Reino Unido ou a autoridade nacional de proteção de dados noutro país da UE —, as pessoas afetadas, os clientes, os fornecedores, as seguradoras, os consultores jurídicos ou as autoridades policiais. Se a decisão foi não notificar, documente a fundamentação. Essa explicação é frequentemente tão importante como a própria notificação.
Medidas de remediação e cronologia
A contenção resolve o incidente imediato. A remediação reduz a probabilidade de o mesmo problema voltar a acontecer. Registe ações de acompanhamento, como aplicar MFA, remover credenciais partilhadas, atualizar políticas de acesso, melhorar a desvinculação, corrigir uma má configuração ou alterar a forma como as cópias de segurança são protegidas.
Lições aprendidas
Termine com o que a empresa aprendeu e o que vai mudar. Isto não deve ser escrito como uma acusação. Deve identificar a fraqueza, a melhoria necessária e quem é responsável pelo acompanhamento.
Um modelo simples de registo de incidentes para PME
Não é necessário software especializado para documentar incidentes. Uma folha de cálculo, um formulário interno seguro, um sistema de tickets ou um registo partilhado podem funcionar se o acesso for controlado e as entradas forem mantidas consistentes.
Um registo de incidentes eficaz deve incluir estes campos:
- ID do incidente: um número de referência único.
- Data e hora da descoberta: quando a empresa tomou conhecimento do incidente.
- Comunicado por: Colaborador, prestador de serviços, cliente, fornecedor, alerta de monitorização ou entidade 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 mal encaminhado ou outro.
- Resumo: O que aconteceu, descrito em linguagem simples.
- Sistemas afetados: Aplicações, contas, dispositivos, bases de dados, caixas de entrada ou serviços de terceiros envolvidos.
- Dados envolvidos: Se dados pessoais foram afetados, que tipo e quantas pessoas podem ser afetadas.
- Causa provável: Conhecida, suspeita ou em investigação.
- Ações de contenção: O que foi feito de imediato.
- Decisão de notificação: Autoridade de controlo, titulares dos dados, clientes, seguradora ou não notificar, com justificação.
- Ligações de evidências: Capturas de ecrã, tickets, registos, e-mails, registos de acesso, ficheiros exportados ou relatórios de prestadores.
- Ações de remediação: Medidas tomadas após a contenção.
- Responsável: Pessoa responsável pelo seguimento.
- Estado: Aberto, em monitorização, contido, resolvido, fechado.
- Lições aprendidas: O que deve mudar.
Como registar decisões de notificação
As decisões de notificação merecem um espaço próprio num registo de incidentes de segurança, porque são frequentemente revistas após o incidente.
Ao abrigo do GDPR do Reino Unido e da UE, as organizações devem avaliar o risco provável para os direitos e liberdades das pessoas quando ocorre uma violação de dados pessoais. Se o risco for provável, a autoridade de controlo deve ser notificada o mais rapidamente possível e, sempre que viável, no prazo de 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 elevado, as pessoas afetadas também devem ser notificadas sem demora injustificada. Os limiares e o prazo são os mesmos em ambos os lados; apenas a autoridade muda.
Um bom registo de incidentes deve mostrar que a empresa fez esta avaliação. Deve registar se estavam envolvidos dados pessoais, que tipo de dano poderia resultar, que proteções existiam e porque decidiu a empresa comunicar ou não comunicar.
Por exemplo, um incidente que envolva uma palavra-passe de administrador exposta pode não revelar imediatamente se foram acedidos dados pessoais. O registo deve refletir essa incerteza. Pode registar a preocupação inicial, as etapas de investigação, a revisão da atividade da conta e a conclusão final assim que houver provas.
Nesta fase do processo, muitas empresas concentram-se em organizar a correção técnica e esquecem-se de registar a fundamentação de conformidade. As palavras-passe são repostas, as contas são protegidas e as operações continuam. Semanas mais tarde, a empresa não consegue explicar porque decidiu que o incidente não era comunicável.
O que as autoridades de controlo esperam dos registos
As autoridades de controlo não se limitam a verificar se um incidente foi comunicado. Também podem perguntar como a empresa:
- Identificou o incidente
- Avaliou o risco
- Decidiu se era necessária notificação
- Documentou as ações tomadas
Um bom registo deve tornar a história do incidente clara do início ao fim. Deve mostrar o que aconteceu, que dados pessoais estavam envolvidos, que dano poderia resultar, o que a empresa fez para conter o problema e porque comunicou ou não o incidente.
O nível de detalhe deve corresponder à gravidade do incidente. Um e-mail mal encaminhado não precisa do mesmo registo que um ataque de ransomware, mas ainda assim precisa de ser documentado para mostrar que a empresa o avaliou devidamente.
Estes registos também devem ser armazenados de forma segura. Os registos de incidentes podem incluir detalhes sensíveis sobre pessoas afetadas, sistemas expostos, ações de colaboradores, capturas de ecrã, registos de acesso ou medidas de remediação. O acesso deve ser limitado às pessoas que dele necessitam e a retenção deve estar alinhada com a política de retenção de dados mais ampla da empresa.
O registo de acesso a credenciais
Muitos incidentes envolvem credenciais: podem ser desencadeados por uma palavra-passe reutilizada, uma conta partilhada, uma caixa de entrada comprometida, um início de sessão de administrador exposto, um pedido de MFA suspeito ou um colaborador que não foi desligado corretamente.
Por esse motivo, os registos de acesso a credenciais podem tornar-se uma entrada direta na documentação de incidentes de cibersegurança. Quando um incidente envolve um início de sessão partilhado ou uma conta sensível, a empresa precisa de saber quem tinha acesso, como o acesso foi partilhado, se as permissões mudaram e se a credencial foi rotacionada após o incidente.
Um gestor de palavras-passe empresarial como o Proton Pass for Business ajuda as equipas a gerir credenciais em cofres encriptados, gerar palavras-passe únicas, usar o preenchimento automático, partilhar credenciais em segurança, gerir chaves de acesso e usar autenticação de dois fatores integrada. Para a documentação de incidentes, o valor mais forte é o rasto de acesso em torno das credenciais: quem tinha acesso a cofres/contas partilhados, como o acesso era gerido e quem o utilizava, e o que mudou após o incidente.
Um gestor de palavras-passe para equipas de TI acrescenta funcionalidades de administração como políticas, relatórios, registos, controlo de acesso baseado em cargos, aprovisionamento SCIM e integração SSO. Estas funcionalidades podem ajudar as empresas a mostrar como o acesso a credenciais é controlado e a fornecer provas quando um incidente relacionado com credenciais é investigado.
Um gestor de palavras-passe não pode substituir um registo de incidentes, uma avaliação jurídica, um processo de notificação regulamentar ou um plano de resposta a incidentes. Mas fornece provas de credenciais que podem alimentar esses processos.
Mantenha um rasto de auditoria completo do acesso a credenciais com um gestor de palavras-passe empresarial.
