← Tutti gli articoli

12 min di lettura

Costruire una timeline verificabile di un incidente di sicurezza senza renderlo pubblico

Come un team di sicurezza può marcare temporalmente e sigillare le prove di un incidente man mano che le raccoglie — una timeline duratura e verificabile in modo indipendente, che dimostra cosa esisteva e quando, senza divulgare i dettagli sensibili.

Un team di sicurezza può costruire una timeline dimostrabile di un incidente senza renderlo pubblico prima di essere pronto. Man mano che raccogli le prove, calcoli l'hash di ogni artefatto importante e pubblichi il digest su Cardano sotto la Label 309. Chiunque tu scelga potrà in seguito confermare che quei byte esatti esistevano entro un dato block time pubblico — senza dover dare fiducia ai tuoi server, al tuo dominio o alla tua parola. Il materiale sensibile può essere sigillato, così che il testo in chiaro resti cifrato e solo l'impegno sia pubblico.

In pratica calcoli l'hash di report, log, export forensi, screenshot, comunicazioni ai clienti, bozze per le autorità e manifest di prove man mano che l'incidente si sviluppa. Ogni pubblicazione ancora un impegno a un momento pubblico. Il testo in chiaro può essere sigillato per destinatari specifici, così la catena dimostra quando senza rivelare cosa.

Questo è un livello di prova, non un sostituto della risposta all'incidente, della consulenza legale, delle decisioni di divulgazione o della reportistica verso le autorità. Dà alla timeline che sta dietro a quelle decisioni un punto di ancoraggio esterno e a prova di manomissione.

Perché la timeline diventa una prova durante un incidente?

Durante un incidente, il tempo stesso è una prova.

A posteriori, un team deve spesso rispondere a domande come queste:

  • quando è stata osservata per la prima volta un'attività sospetta;
  • quando si è proceduto con l'escalation dell'incidente;
  • quando è stata informata la consulenza legale;
  • quando è iniziato il contenimento;
  • quali log esistevano prima della ricostruzione dei sistemi;
  • quali record dei clienti si riteneva fossero coinvolti a ciascuno stadio;
  • quale versione di un report è arrivata al consiglio di amministrazione;
  • quale notifica all'autorità è stata redatta o inviata;
  • cosa è cambiato tra la prima valutazione e il report finale.

Il problema è che le prove di un incidente si muovono in fretta. I log ruotano. I ticket vengono modificati. I report vengono revisionati. Gli screenshot finiscono incollati nelle slide. Gli export vengono rieseguiti. Una sequenza di eventi che il primo giorno sembrava ovvia può diventare difficile da dimostrare sei mesi dopo.

Un impegno con timestamp dà a ogni artefatto importante un punto di ancoraggio esterno che nessuno — te compreso — può retrodatare.

Cosa dovrebbe marcare temporalmente un team di sicurezza?

Marca temporalmente gli artefatti che avrebbero peso se la timeline venisse mai messa in discussione.

Per un incidente di sicurezza, di solito rientrano in questa categoria:

  • le note di rilevamento iniziali;
  • gli export degli alert;
  • le ricerche dal tuo SIEM (security information and event management);
  • gli export dal tuo EDR (endpoint detection and response);
  • i log di firewall e di accesso;
  • i log dell'identity provider;
  • i log di audit del cloud;
  • i campioni di malware o i loro hash;
  • i manifest delle immagini forensi di disco o di memoria;
  • gli elenchi degli account coinvolti;
  • le stime dei clienti coinvolti;
  • le note di contenimento ed eradicazione;
  • i ticket dell'incidente;
  • i report di stato interni;
  • gli aggiornamenti al consiglio;
  • le bozze per le autorità;
  • le bozze di notifica ai clienti;
  • i report finali dell'incidente.

Non pubblicare segreti in chiaro. Un hash, una Merkle root o del testo cifrato sigillato è quasi sempre più sicuro del testo pubblico — e altrettanto dimostrabile.

Come si inserisce la Label 309 nella risposta agli incidenti?

Usala come livello di prova accanto agli strumenti che già utilizzi.

Un team di incident response non ha bisogno di sostituire il proprio SIEM, lo strumento di gestione dei casi, il sistema di ticketing, la piattaforma forense o il repository documentale. Esporti o catturi uno snapshot degli artefatti importanti, calcoli gli hash e pubblichi i record in punti definiti della risposta.

Un flusso tipico:

  1. Il team di rilevamento esporta il primo bundle di alert.
  2. Il responsabile dell'incidente costruisce un manifest dei file.
  3. Si calcola l'hash del manifest.
  4. Un record Label 309 ancora l'hash, oppure una Merkle root sull'intero bundle.
  5. I file sensibili vengono sigillati per la consulenza legale e i vertici della sicurezza.
  6. Il riferimento della transazione viene allegato al caso dell'incidente.

In seguito, chiunque disponga di quel riferimento della transazione potrà confermare che un dato file o manifest corrisponde ai byte impegnati al timestamp pubblico — usando il verificatore, lo strumento a riga di comando open source o qualunque implementazione di terze parti dello standard. Il codice di pubblicazione e di verifica è open source su github.com/cardanowall.

Perché sigillare i record di un incidente invece di pubblicare i byte?

I dettagli di un incidente sono spesso pericolosi da pubblicare.

Possono contenere vulnerabilità non corrette, credenziali, indirizzi IP, dati dei clienti, dati dei dipendenti, dettagli sull'autore della minaccia, fatti sensibili per le forze dell'ordine o piani di remediation commercialmente sensibili.

Un record sigillato ti permette di pubblicare un impegno mantenendo il file cifrato. Il record on-chain porta con sé l'hash del testo in chiaro — la prova della tempistica — più una chiave incapsulata che solo i destinatari scelti possono aprire. Il testo cifrato risiede a un URI di storage indirizzato per contenuto, non sulla catena, e nemmeno le chiavi pubbliche dei destinatari compaiono mai sulla catena. Un osservatore apprende soltanto che esiste un record sigillato, il suo block time e a quanti destinatari è stato sigillato — mai chi siano né cosa sia stato sigillato.

Così puoi preservare la prova originale senza divulgare l'incidente attraverso il record di prova stesso. Per approfondire come sigillare file a persone specifiche senza esporne il contenuto, vedi la divulgazione riservata senza file pubblici.

In che modo questo aiuta con le timeline verso le autorità?

Molti regimi in materia di incidenti ruotano attorno alla tempistica, e un record a prova di manomissione di cosa sapevi e quando lo sapevi può sostenere quelle valutazioni.

  • Negli Stati Uniti, le regole della SEC impongono ai soggetti registrati nazionali di depositare un Form 8-K ai sensi dell'Item 1.05 per un incidente di cybersicurezza rilevante entro quattro giorni lavorativi dalla determinazione che l'incidente è rilevante — il conto alla rovescia parte dalla determinazione della rilevanza, non dalla scoperta. La SEC ha inoltre sottolineato che la determinazione della rilevanza deve essere effettuata senza indebito ritardo.
  • Nell'Unione Europea, la Direttiva NIS2 fissa un conto alla rovescia in tre fasi per un incidente significativo: un preallarme entro 24 ore dalla presa di consapevolezza, una notifica dell'incidente entro 72 ore e una relazione finale entro un mese.
  • Per le entità finanziarie dell'UE, il Digital Operational Resilience Act (DORA) ha introdotto obblighi armonizzati di gestione degli incidenti ICT e di segnalazione degli incidenti gravi, applicabili a partire dal 17 gennaio 2025.

Gli obblighi precisi dipendono dall'azienda, dal settore, dalla giurisdizione e dall'incidente, e cambiano nel tempo — questo è un inquadramento generale, non un parere legale. Una prova non decide se un report sia necessario, e non dimostra che tu abbia rispettato una scadenza. Quello che può fare è preservare un record a prova di manomissione degli artefatti e delle valutazioni che stanno dietro a quelle decisioni, così che la timeline su cui ti sei basato possa essere mostrata in seguito. Trattala come una prova che può sostenere un caso; non sostituisce la consulenza legale.

Come si presenta un flusso di prova concreto?

Definisci un piccolo insieme di momenti di prova prima ancora di averne bisogno.

Un'azienda potrebbe definire dei checkpoint di prova per l'incidente in questo modo:

  • T0: primo segnale rilevato o bundle di alert;
  • T1: incidente dichiarato;
  • T2: valutazione iniziale del perimetro;
  • T3: avvio dell'azione di contenimento;
  • T4: bozza di valutazione della rilevanza o dell'obbligo di segnalazione;
  • T5: aggiornamento al consiglio o ai dirigenti;
  • T6: bozza di notifica all'autorità o ai clienti;
  • T7: report finale dell'incidente;
  • T8: revisione post-incidente e piano di remediation.

Ogni checkpoint produce un manifest. Del manifest si può calcolare direttamente l'hash, oppure lo si può includere come foglia di Merkle in una root più ampia dell'incidente.

Il risultato è una timeline facile da spiegare in seguito: ecco i checkpoint, ecco gli artefatti, ecco i timestamp pubblici ed ecco come verificare che i file corrispondano.

Quando conviene impegnarsi su una Merkle root invece che su un record per ogni file?

Usa una Merkle root quando l'insieme delle prove è ampio.

Un incidente serio può coinvolgere migliaia o milioni di righe di log, alert, pacchetti, hash di file, eventi sugli endpoint e aggiornamenti di ticket. Pubblicare un record per ogni artefatto è costoso e difficile da gestire.

Costruisci invece un manifest deterministico, calcola l'hash di ogni voce trasformandola in una foglia, costruisci un Merkle tree e pubblica una singola root da 32 byte per il checkpoint. In seguito potrai dimostrare che un determinato export di log, evento o hash di file faceva parte di quel checkpoint — con una breve inclusion proof — senza rivelare il resto dell'insieme delle prove.

Si presta naturalmente a:

  • i batch giornalieri di prove dell'incidente;
  • i log cloud ad alto volume;
  • gli elenchi di impatto sui clienti;
  • gli inventari degli artefatti sugli endpoint;
  • i manifest di raccolta forense;
  • gli snapshot delle scansioni di vulnerabilità;
  • le prove di patch e remediation.

Un'avvertenza: una root è utile solo se preservi il manifest, la lista ordinata delle foglie e le inclusion proof. La catena conserva la root; tu conservi tutto ciò che serve per dimostrare che una foglia si trova sotto di essa. Lo stesso schema — un solo record al posto di un insieme enorme — è trattato in un record per migliaia di file.

Come funzionano le correzioni quando i fatti cambiano?

I report di un incidente cambiano perché i fatti migliorano, e lo standard ti permette di rendere visibile questo cambiamento.

Le stime iniziali sono spesso sbagliate. Un team può inizialmente credere che fossero coinvolti 200 account, poi scoprirne 2.000, poi escludere 150 falsi positivi. Questi cambiamenti non dovrebbero essere nascosti — dovrebbero poter essere spiegati.

Un record può portare un puntatore di supersessione: l'hash della transazione da 32 byte di un record precedente che va a sostituire. Il record precedente resta sulla catena e rimane verificabile in modo indipendente; la catena è append-only, quindi superare un record non rimuove né invalida nulla. Il puntatore dice semplicemente, in sostanza, questa è la versione successiva. Non porta alcun campo per la motivazione — qualunque significato destinato a una persona appartiene al nuovo contenuto, non al puntatore.

Questa distinzione conta: preserva la differenza tra una revisione onesta e una riscrittura silenziosa. La storia è visibile, in ordine e dimostrabile.

Chi dovrebbe ricevere i record sigillati di un incidente?

Mantieni la lista dei destinatari piccola e ragionata. Ogni destinatario in più è un'altra parte che può decifrare — e, una volta decifrato, far trapelare — il testo in chiaro.

Tra i destinatari più comuni ci sono:

  • la consulenza legale esterna;
  • l'ufficio legale interno;
  • l'incident commander;
  • il CISO o i vertici della sicurezza;
  • un partner forense;
  • un referente presso l'autorità, dove appropriato;
  • la consulenza legale per la cyber-assicurazione o un fornitore del panel;
  • un comitato per la sicurezza del consiglio;
  • un'identità di archivio fidata controllata dall'azienda.

Ogni destinatario dovrebbe fornire un indirizzo di ricezione che hai effettivamente verificato tramite un canale separato — confermando che la chiave appartenga davvero a quella persona, e non a qualcuno che la sta impersonando. Sigillare verso la chiave sbagliata significa sigillare verso il lettore sbagliato, e la catena non rileverà l'errore al posto tuo; verifica un destinatario prima di sigillare un file spiega come farlo. Per prove sensibili e di lunga durata, preferisci l'indirizzo di ricezione ibrido post-quantum opzionale, dove il flusso di lavoro lo supporta. È progettato per resistere a un attacco «harvest now, decrypt later», in cui un avversario archivia oggi il testo cifrato e attende un futuro computer quantistico per violarlo.

Cosa non dovrebbe mai finire nei metadati pubblici?

Tieni i segreti dell'incidente completamente fuori dal record pubblico.

Non pubblicare:

  • dettagli di exploit in chiaro;
  • credenziali;
  • chiavi private;
  • dati personali dei clienti;
  • hostname interni o indirizzi IP sensibili;
  • dettagli sull'infrastruttura dell'attaccante che dovrebbero restare riservati;
  • analisi legali coperte da privilegio;
  • accuse non supportate;
  • informazioni destinate solo all'autorità che non dovrebbero essere pubbliche.

La catena pubblica dovrebbe portare degli impegni — hash, root, buste sigillate — non la narrazione dell'incidente. La narrazione resta nei tuoi sistemi e, dove serve, dentro al testo cifrato sigillato.

Una prova dimostra che l'azienda ha gestito bene l'incidente?

No. È più circoscritta di così, ed è una scelta voluta.

Una prova può dimostrare che certi file o manifest esistevano entro un momento pubblico. Può dimostrare che una particolare chiave di firma ha garantito per un record, quando è presente la firma di paternità opzionale. Può dimostrare che un artefatto successivo corrisponde a un impegno precedente.

Non dimostra che l'indagine fosse completa, che l'azienda abbia preso le decisioni giuste, che le scadenze legali siano state rispettate, che i controlli fossero efficaci o che i clienti siano stati avvisati correttamente. È una prova relativa alla tempistica e all'integrità, non alla verità, al giudizio o alla compliance. Per la versione generale di questo confine, vedi cosa una prova non dimostra.

Cosa può andare storto?

I fallimenti più comuni sono operativi, non crittografici.

Puoi marcare temporalmente i file sbagliati. Puoi perdere la prova originale. Puoi non riuscire a preservare le foglie di Merkle da cui dipende una root. Puoi inserire un fatto sensibile in un campo pubblico. Puoi sigillare verso un indirizzo di ricezione che nessuno ha verificato. Puoi lasciare che troppe persone decifrino. Puoi iniziare a trattare il livello di prova come il tuo sistema di reportistica, anziché come un livello di prova che gli sta dietro.

La difesa migliore è procedurale: definisci i tuoi checkpoint di prova prima di un incidente, automatizza le parti noiose e tieni coinvolta la consulenza legale ovunque sia possibile un'esposizione legale.

In breve

Gli incidenti di sicurezza hanno bisogno di una timeline che regga alla pressione.

La Label 309 ancora gli artefatti, i report e i manifest di un incidente a un momento pubblico. I record sigillati mantengono cifrate le prove sensibili per i destinatari scelti. Le Merkle root impegnano grandi insiemi di prove con un singolo record. I puntatori di supersessione rendono le correzioni visibili anziché silenziose — senza dover dare fiducia a un singolo server o fornitore.

Usala per dimostrare cosa esisteva e quando. Non usarla per sostituire la risposta all'incidente o la reportistica legale — e non aspettarti che dimostri qualcosa oltre alla tempistica e all'integrità.

Approfondimenti

securityincident-responseproof-of-existence