← Todos os posts

12 min de leitura

Construa uma linha do tempo verificável de incidentes de segurança sem torná-la pública

Como uma equipe de segurança pode carimbar no tempo e selar as evidências de um incidente à medida que são coletadas — uma linha do tempo durável e verificável de forma independente, que prova o que existiu e quando, sem publicar detalhes sensíveis.

Uma equipe de segurança pode construir uma linha do tempo comprovável de um incidente sem torná-lo público antes da hora certa. À medida que as evidências são coletadas, você calcula o hash de cada artefato importante e publica o digest na Cardano sob o Label 309. Qualquer pessoa que você escolher pode, mais tarde, confirmar que estes bytes exatos existiam em ou antes de um horário público de bloco — sem confiar nos seus servidores, no seu domínio ou na sua palavra. O material sensível pode ser selado, de modo que o texto claro permaneça cifrado enquanto apenas o compromisso fica público.

Na prática, você calcula o hash de relatórios, logs, exportações forenses, capturas de tela, avisos a clientes, minutas para reguladores e manifestos de evidências à medida que o incidente se desenrola. Cada publicação ancora um compromisso em um horário público. O texto claro pode ser selado para destinatários nomeados, então a cadeia prova quando sem revelar o quê.

Isto é uma camada de evidência, não um substituto para a resposta a incidentes, para a assessoria jurídica, para as decisões de divulgação ou para os relatos regulatórios. Ela dá à linha do tempo por trás dessas decisões uma âncora externa e à prova de adulteração.

Por que a linha do tempo vira evidência durante um incidente?

Durante um incidente, o próprio tempo é evidência.

Depois, a equipe muitas vezes precisa responder a perguntas como estas:

  • quando a atividade suspeita foi observada pela primeira vez;
  • quando o incidente foi escalado;
  • quando a assessoria jurídica foi avisada;
  • quando a contenção começou;
  • quais logs existiam antes de os sistemas serem reconstruídos;
  • quais registros de clientes se acreditava estarem afetados em cada estágio;
  • qual versão de um relatório foi para o conselho;
  • qual aviso ao regulador foi redigido ou protocolado;
  • o que mudou entre a primeira avaliação e o relatório final.

O problema é que as evidências de um incidente se movem rápido. Logs rotacionam. Tíquetes são editados. Relatórios são revisados. Capturas de tela são coladas em slides. Exportações são reexecutadas. Uma sequência de eventos que parecia óbvia no primeiro dia pode ser difícil de provar seis meses depois.

Um compromisso com carimbo de tempo dá a cada artefato importante uma âncora externa que ninguém — incluindo você — consegue retrodatar.

O que uma equipe de segurança deve carimbar no tempo?

Carimbe no tempo os artefatos que importariam caso a linha do tempo viesse a ser contestada.

Para um incidente de segurança, isso costuma incluir:

  • notas de detecção inicial;
  • exportações de alertas;
  • buscas da sua ferramenta de SIEM (gestão de informações e eventos de segurança);
  • exportações da sua ferramenta de EDR (detecção e resposta em endpoints);
  • logs de firewall e de acesso;
  • logs do provedor de identidade;
  • logs de auditoria em nuvem;
  • amostras de malware ou hashes de amostras;
  • manifestos de imagens forenses de disco ou de memória;
  • listas de contas afetadas;
  • estimativas de clientes afetados;
  • notas de contenção e erradicação;
  • tíquetes do incidente;
  • relatórios internos de status;
  • atualizações ao conselho;
  • minutas para reguladores;
  • minutas de notificação a clientes;
  • relatórios finais do incidente.

Não publique segredos em texto claro. Um hash, uma raiz Merkle ou um texto cifrado selado é quase sempre mais seguro do que texto público — e igualmente comprovável.

Como o Label 309 se encaixa na resposta a incidentes?

Use-o como uma camada de prova ao lado das ferramentas que você já opera.

Uma equipe de resposta a incidentes não precisa substituir seu SIEM, sua ferramenta de gestão de casos, seu sistema de tíquetes, sua plataforma forense ou seu repositório de documentos. Você exporta ou tira um instantâneo dos artefatos importantes, calcula os hashes e publica registros em pontos definidos da resposta.

Um fluxo típico:

  1. A equipe de detecção exporta o primeiro pacote de alertas.
  2. O líder do incidente monta um manifesto dos arquivos.
  3. O manifesto tem seu hash calculado.
  4. Um registro Label 309 ancora o hash, ou uma raiz Merkle sobre o pacote.
  5. Os arquivos sensíveis são selados para a assessoria jurídica e a liderança de segurança.
  6. A referência da transação é anexada ao caso do incidente.

Mais tarde, qualquer pessoa com essa referência da transação pode confirmar que um determinado arquivo ou manifesto corresponde aos bytes comprometidos no carimbo de tempo público — usando o verificador, a ferramenta de linha de comando de código aberto ou qualquer implementação de terceiros do padrão. O código de publicação e de verificação é de código aberto em github.com/cardanowall.

Por que selar os registros do incidente em vez de publicar os bytes?

Os detalhes de um incidente costumam ser perigosos de publicar.

Eles podem conter vulnerabilidades não corrigidas, credenciais, endereços IP, dados de clientes, dados de funcionários, detalhes sobre o agente de ameaça, fatos sensíveis para as autoridades policiais ou planos de remediação comercialmente sensíveis.

Um registro selado permite que você publique um compromisso enquanto mantém o arquivo cifrado. O registro na cadeia carrega o hash do texto claro — a prova do momento — mais uma chave encapsulada que apenas os destinatários escolhidos conseguem abrir. O texto cifrado fica em uma URI de armazenamento endereçado por conteúdo, e não na cadeia, e as chaves públicas dos destinatários também nunca aparecem na cadeia. Um observador aprende apenas que existe um registro selado, qual é o seu horário de bloco e para quantos destinatários ele foi selado — nunca quem são eles nem o que foi selado.

Assim, você consegue preservar a evidência original sem revelar o incidente através do próprio registro de prova. Para saber mais sobre como selar arquivos para pessoas específicas sem expor o conteúdo, veja divulgação confidencial sem arquivos públicos.

Como isso ajuda com os prazos dos reguladores?

Muitos regimes de incidentes dependem do momento, e um registro à prova de adulteração de quando você soube o quê pode sustentar essas determinações.

  • Nos Estados Unidos, as regras da SEC exigem que os registrantes nacionais protocolem um Form 8-K sob o Item 1.05 para um incidente de cibersegurança material dentro de quatro dias úteis a partir da determinação de que o incidente é material — o relógio começa a contar a partir da determinação de materialidade, não da descoberta. A SEC também enfatizou que a determinação de materialidade deve ser feita sem demora injustificada.
  • Na União Europeia, a Diretiva NIS2 estabelece um relógio de três estágios para um incidente significativo: um alerta inicial dentro de 24 horas de tomar conhecimento dele, uma notificação do incidente dentro de 72 horas e um relatório final dentro de um mês.
  • Para as entidades financeiras da UE, o Digital Operational Resilience Act (DORA) introduziu obrigações harmonizadas de gestão de incidentes de TIC e de relato de incidentes graves, que passaram a vigorar em 17 de janeiro de 2025.

As obrigações exatas dependem da empresa, do setor, da jurisdição e do incidente, e mudam ao longo do tempo — isto é um contexto geral, não aconselhamento jurídico. Uma prova não decide se um relatório é exigido e não prova que você cumpriu um prazo. O que ela pode fazer é preservar um registro à prova de adulteração dos artefatos e das avaliações por trás dessas decisões, para que a linha do tempo em que você se baseou possa ser exibida mais tarde. Trate-a como uma evidência que pode sustentar um caso; ela não substitui a assessoria jurídica.

Como é, na prática, um fluxo de trabalho de prova?

Defina um pequeno conjunto de momentos de prova antes mesmo de precisar deles.

Uma empresa poderia definir pontos de verificação de prova do incidente assim:

  • T0: primeiro sinal ou pacote de alertas detectado;
  • T1: incidente declarado;
  • T2: avaliação inicial de escopo;
  • T3: ação de contenção iniciada;
  • T4: minuta de avaliação de materialidade ou de obrigatoriedade de relato;
  • T5: atualização ao conselho ou à diretoria;
  • T6: minuta de aviso ao regulador ou ao cliente;
  • T7: relatório final do incidente;
  • T8: revisão pós-incidente e plano de remediação.

Cada ponto de verificação produz um manifesto. O manifesto pode ter seu hash calculado diretamente ou ser incluído como uma folha Merkle dentro de uma raiz de incidente mais ampla.

O resultado é uma linha do tempo fácil de explicar depois: aqui estão os pontos de verificação, aqui estão os artefatos, aqui estão os carimbos de tempo públicos e aqui está como verificar que os arquivos correspondem.

Quando você deve comprometer uma raiz Merkle em vez de um registro por arquivo?

Use uma raiz Merkle quando o conjunto de evidências for grande.

Um incidente sério pode envolver milhares ou milhões de linhas de log, alertas, pacotes, hashes de arquivos, eventos em endpoints e atualizações de tíquetes. Publicar um registro por artefato é caro e difícil de gerenciar.

Em vez disso, construa um manifesto determinístico, calcule o hash de cada entrada em uma folha, monte uma árvore Merkle e publique uma única raiz de 32 bytes para o ponto de verificação. Mais tarde, você pode provar que uma exportação de log, um evento ou um hash de arquivo específico estava naquele ponto de verificação — com uma prova de inclusão curta — sem revelar o restante do conjunto de evidências.

Isso se encaixa naturalmente para:

  • lotes diários de evidências do incidente;
  • logs de nuvem de alto volume;
  • listas de impacto em clientes;
  • inventários de artefatos de endpoints;
  • manifestos de coleta forense;
  • instantâneos de varreduras de vulnerabilidades;
  • evidências de correções e remediações.

Uma ressalva: uma raiz só é útil se você preservar o manifesto, a lista ordenada de folhas e as provas de inclusão. A cadeia armazena a raiz; você armazena tudo o que é necessário para provar que uma folha está sob ela. O mesmo padrão — um registro representando um conjunto enorme — é abordado em um registro para milhares de arquivos.

Como funcionam as correções quando os fatos mudam?

Os relatórios de incidentes mudam porque os fatos melhoram, e o padrão permite tornar isso visível.

As estimativas iniciais muitas vezes estão erradas. Uma equipe pode acreditar a princípio que 200 contas foram afetadas, depois descobrir que foram 2.000 e então excluir 150 falsos positivos. Essas mudanças não deveriam ser escondidas — elas deveriam ser explicáveis.

Um registro pode carregar um ponteiro de substituição: o hash de transação de 32 bytes de um registro anterior que ele substitui. O registro anterior permanece na cadeia e continua verificável de forma independente; a cadeia é somente de acréscimo, então a substituição não remove nem invalida nada. O ponteiro simplesmente diz, na prática, esta é a versão mais recente. Ele não carrega nenhum campo de motivo — qualquer significado humano pertence ao novo conteúdo, não ao ponteiro.

Essa distinção importa: ela preserva a diferença entre uma revisão honesta e uma reescrita silenciosa. O histórico fica visível, em ordem e comprovável.

Quem deve receber os registros selados do incidente?

Mantenha a lista de destinatários pequena e deliberada. Cada destinatário a mais é mais uma parte que pode decifrar — e, depois de decifrar, vazar — o texto claro.

Os destinatários comuns incluem:

  • a assessoria jurídica externa;
  • o jurídico interno;
  • o comandante do incidente;
  • o CISO ou a liderança de segurança;
  • um parceiro forense;
  • um contato no regulador, quando apropriado;
  • a assessoria jurídica do seguro cibernético ou um fornecedor credenciado da seguradora;
  • um comitê de segurança do conselho;
  • uma identidade de arquivo confiável controlada pela empresa.

Cada destinatário deve fornecer um endereço de recebimento que você realmente verificou por um canal paralelo — confirmando que a chave de fato pertence àquela pessoa, e não a alguém se passando por ela. Selar para a chave errada sela para o leitor errado, e a cadeia não vai pegar esse erro por você; verifique um destinatário antes de selar um arquivo mostra como. Para evidências sensíveis e de longa duração, prefira o endereço de recebimento híbrido pós-quântico opcional, onde o fluxo de trabalho oferecer suporte a ele. Ele é projetado para resistir a um ataque de "harvest now, decrypt later", em que um adversário armazena o texto cifrado hoje e espera por um futuro computador quântico para quebrá-lo.

O que nunca deve entrar nos metadados públicos?

Mantenha os segredos do incidente totalmente fora do registro público.

Não publique:

  • detalhes de exploração em texto claro;
  • credenciais;
  • chaves privadas;
  • dados pessoais de clientes;
  • nomes de host internos ou endereços IP sensíveis;
  • detalhes da infraestrutura do atacante que devem permanecer confidenciais;
  • análise jurídica privilegiada;
  • acusações sem sustentação;
  • informações destinadas apenas ao regulador que não devem ser públicas.

A cadeia pública deve carregar compromissos — hashes, raízes, envelopes selados — não a narrativa do incidente. A narrativa fica nos seus sistemas e, quando necessário, dentro do texto cifrado selado.

Uma prova mostra que a empresa lidou bem com o incidente?

Não. Ela é mais restrita do que isso, de propósito.

Uma prova pode mostrar que determinados arquivos ou manifestos existiam até um horário público. Ela pode mostrar que uma chave de assinatura específica atestou um registro, quando a assinatura de autoria opcional está presente. Ela pode mostrar que um artefato posterior corresponde a um compromisso anterior.

Ela não prova que a investigação foi completa, que a empresa tomou as decisões certas, que os prazos legais foram cumpridos, que os controles foram eficazes ou que os clientes foram notificados corretamente. É evidência sobre momento e integridade, não sobre verdade, julgamento ou conformidade. Para a versão geral dessa fronteira, veja o que uma prova não prova.

O que pode dar errado?

As falhas mais comuns são operacionais, não criptográficas.

Você pode carimbar no tempo os arquivos errados. Você pode perder a evidência original. Você pode deixar de preservar as folhas Merkle das quais uma raiz depende. Você pode colocar um fato sensível em um campo público. Você pode selar para um endereço de recebimento que ninguém verificou. Você pode deixar gente demais decifrar. Você pode começar a tratar a camada de prova como o seu sistema de relatos, em vez de uma camada de evidência por trás dele.

A melhor defesa é processual: defina seus pontos de verificação de prova antes de um incidente, automatize as partes tediosas e mantenha a assessoria jurídica envolvida sempre que houver possibilidade de exposição legal.

A versão curta

Os incidentes de segurança precisam de uma linha do tempo que sobreviva à pressão.

O Label 309 ancora os artefatos, relatórios e manifestos do incidente a um horário público. Os registros selados mantêm as evidências sensíveis cifradas para destinatários escolhidos. As raízes Merkle comprometem grandes conjuntos de evidências com um único registro. Os ponteiros de substituição tornam as correções visíveis em vez de silenciosas — sem confiar em nenhum servidor ou fornecedor isolado.

Use-o para provar o que existiu e quando. Não o use para substituir a resposta a incidentes ou o relato legal — e não espere que ele prove qualquer coisa além de momento e integridade.

Leitura adicional

securityincident-responseproof-of-existence