Un'attribuzione fallita non dimostra che l'attaccante fosse anonimo
Un caso senza un colpevole identificato mostra cosa potevano stabilire le prove, non che l'anonimato abbia funzionato. Separa la linea guida, la sua adozione e il fallimento dell'attribuzione.
Un caso che si chiude senza un colpevole identificato tende a essere descritto come anonimo, e quella parola fa molto lavoro silenzioso. Trasforma un'affermazione sulle prove in un'affermazione sul mondo. Le due cose non sono uguali, e per gli incidenti più vecchi la differenza è spesso l'unica cosa che il documento superstite può sostenere. Un incidente non attribuito ti dice cosa si poteva stabilire, non cosa era possibile.
Cinque controlli tengono separate le due cose.
Controllo 1: separa la linea guida dalla sua adozione
L'RFC 1281, pubblicato nel novembre 1991, raccomandava di conservare e verificare i registri rilevanti per la sicurezza, sostenere la tracciatura delle connessioni e nominare un contatto di sicurezza per la gestione degli incidenti. Chiedeva inoltre agli operatori di pubblicare cosa raccoglievano e chi poteva usarlo. È un documento datato di ciò che era raccomandato, che è un'affermazione diversa da ciò che ha fatto una rete specifica.
Una raccomandazione è prova che la preoccupazione esisteva. Non è prova di attuazione, e certamente non è prova che un'indagine specifica sia riuscita.
Controllo 2: indica quale anello dell'attribuzione si è rotto
L'attribuzione è una catena, e ogni anello fallisce a modo suo: un'osservazione di rete, l'account associato, il controllo di quell'account in quel momento e le prove che collegano quel controllo a una persona. Un indirizzo intermedio non è una posizione. Un nome utente non è prova di chi ha digitato sulla tastiera. Una sessione registrata non è prova che il titolare dell'account fosse presente.
Annota quale anello manca prima di annotare una conclusione.
| Evidence | What it actually establishes |
|---|---|
| Source address in a log | An address at that moment, not a person |
| Account name | A credential was used, not who held it |
| Session window | When activity happened, not intent |
| Cross-network correlation | A path, not an identity |
Controllo 3: data le prove che citi
I rapporti vecchi comprimono male il tempo. I registri mai tenuti, quelli scaduti per una politica di conservazione, quelli che esistevano ma non sono mai stati correlati tra organizzazioni e le indagini semplicemente non proseguite lasciano tutti la stessa traccia in un riepilogo moderno: nulla. Solo il primo è un'affermazione sulla capacità tecnica.
Preferisci documenti primari datati ai riepiloghi ricordati e cita la frase su cui ti basi.
Controllo 4: resisti alla tentazione di trasformare la storia in un catalogo di tecniche
La domanda storica è cosa era osservabile e cosa se ne poteva stabilire. Un elenco di servizi esposti e credenziali predefinite risponde a un'altra domanda, ed è il tipo sbagliato di risposta per un lettore che cerca di capire l'attribuzione. È anche inutile, perché l'argomento regge senza dettagli operativi.
Se un esempio ha bisogno di una ricetta per essere interessante, l'esempio sta facendo il lavoro sbagliato.
Controllo 5: enuncia la conclusione più ristretta che puoi difendere
Una conclusione difendibile si legge così: il documento superstite mostra che la linea guida esisteva, che alcuni operatori raccoglievano registri di autenticazione e che il caso specifico non ha prodotto prove sufficienti a identificare una persona. Questo è più ristretto di dire che nessuno guardava, ed è più utile perché è verificabile. Annota anche cosa avrebbe cambiato l'esito, perché una correlazione mancante è un fallimento diverso dai dati mancanti. Poi fermati.
Le affermazioni ampie su un intero decennio richiedono documenti di quel decennio, non una storia plausibile su com'erano le cose una volta.