C'è una domanda che divide chi fa sicurezza da chi la fa solo per relazione: conviene mentire all'attaccante? La risposta professionale è sì, e da molto tempo. Il punto non è la tecnologia: è la matematica. Un difensore deve indovinare una sola cosa — cosa protegge — e indovinare bene significa inventariare tutto. Un attaccante deve capire tutto per riuscire a non notare nulla. Asimmetria a favore del difensore, e la deception technology esiste per esagerarla.
1986-1991: il traffico come prova
Cliff Stoll, 1986, gestisce due sistemi sul collegamento con il Los Alamos. Nota che l'uso della linea è sospetto: qualcuno sta sfogliando l'help di stampa di qualcosa che non è un utente. Il metodo non è un IDS: è economia forense. Chi scarica pagine di documentazione di stampa consuma caratteri dalla riga telefonica. Conta i caratteri, divide per la lunghezza media delle pagine, e ottiene il numero di job di stampa rubati. Un dato indiretto che diventa una prova.
Nello stesso periodo, all'università Purdue, Eugene Spafford progetta — e pubblicherà anni dopo — quello che lui stesso descrive come un possibile primo sistema di honeypot con deception, pensato per osservare chi credeva di aver trovato il suo sistema principale. Le intrusioni del 1991 che documenterà nei suoi articoli sono importanti per un motivo preciso: non hanno attivato nessuno degli allarmi allora esistenti. E hanno installato una backdoor maneggiata in modo che i file modificati mostrassero ancora il checksum CRC precedente, mentre i timestamp di modifica rimanevano coerenti.
È un dettaglio che smonta molte certezze: nel 1991 la capacità di un avversario di nascondersi era già superiore alla capacità dei difensori di accorgersene.
1991-1992: la notte di Berferd
L'altro testo fondativo è di Bill Cheswick. Un intruso, "Berferd", entra nel suo sistema e i due passano la notte a giocare. Cheswick descrive la cosa come un serraglio, e il nome "honeypot" si consolida. Nel 1992 esce "an evening with berferd", e l'idea viene pubblicizzata: la trappola non deve essere nascosta, deve essere abbastanza reale da non far sospettare, e abbastanza isolata da non essere un rischio.
Da quel momento la ricerca si biforca:
Strumenti. Dopo "Deceptive Toolkit" (1997, che gioca anche il ruolo dell'aggressore) e "Cybercop Sting" (primo honeypot commerciale, 1998), arrivano strumenti come dionaea (2003-2006, di Dino Welin), che emula decine di servizi e reagisce a exploit, o KipZ e Cuckoo Sandbox, orientati all'analisi automatizzata.
Teoria. Nel 1999 Lance Spitzner formalizza i concetti chiave — interaction level (quanto profondo deve essere l'inganno) e realism (quanto deve sembrare reale) — che ancora oggi sono la griglia con cui si giudica una deception technology. Più avanti, nel 2003, coniato anche il termine honeytoken: l'oggetto esca.
Perché un token batte spesso un honeypot
Un honeypot è un servizio: va patchato, monitorato, protetto. Un honeytoken è
un dato: costa una riga di codice e una regola di alert. Nei progetti reali il
rapporto costo/beneficio è quasi sempre a favore del token, e il motivo è
che l'attaccante medio automatizzato preferisce il bersaglio ovvio. Uno
scanner che enumera bucket S3 non valuta il contenuto: trova
prod-backup-2024, lo scarica, e il token fa il resto.
Anche la forma del token conta più del suo tipo. Credenziali finte con nomi
plausibili, un file Word che contiene davvero un documento, un indirizzo email
archive@ con un autoresponder: sono tutte cose che devono reggere un'occhiata
di un secondo. Un honeytoken con nome token_test_123.txt non è un honeytoken,
è rumore.
Dove siamo oggi
La deception si è spostata dal server al perimetro logico:
Microsegmentazione dinamica. Il concetto più interessante: l'honeypot non è una macchina separata, è una subnet o un'istanza creata apposta per essere l'unica cosa che l'attaccante incontra dopo la compromissione iniziale.
Miglioramento automatico. Varianti di canary token generate da LLM che adattano nome, dimensione e contenuto al contesto del sistema che si vuole proteggere, e che quindi somigliano davvero a ciò che sta intorno.
Falsi profili di credenziali. Su ambienti cloud e identity provider si generano chiavi che somigliano a quelle di produzione, con nomi di servizio plausibili. Usarle fa scattare l'alerta prima che l'escalation riesca.
Cosa tenere a mente
La deception non sostituisce le fondamenta: patching, segmentazione, least privilege, logging. Funziona come rivelatore di bassissimo costo, ed è tanto più utile quanto meno siete visibili. Il giorno in cui l'attaccante sa che esiste una rete di honeypot, il vantaggio si assottiglia: da quel momento l'inganno diventa un gioco che dovete vincere ogni volta.
Per questo la regola pratica è sempre la stessa: se non avete un canale di alert che funziona, non aggiungete token. Un canario che nessuno sente è peggio di nessun canario, perché genera la convinzione di essere protetti.