Il rischio storico degli honeypot nasce da un fatto preciso: l'esca sta dentro la tua rete. Noi l'abbiamo messa altrove.
È la domanda che si fa ogni responsabile IT, ed è giusta: un honeypot è, per definizione, un sistema che qualcuno deve poter attaccare. Nella maggior parte dei prodotti quel sistema sta nella tua rete, e il rischio che ne deriva è reale. Nel nostro, l'esca non può aprire connessioni verso la tua rete. Qui trovi perché, e soprattutto come verificarlo, da noi e da qualsiasi altro fornitore.
In breve
- Il rischio storico degli honeypot è che l'esca, una volta compromessa, diventi un punto d'appoggio dentro la rete. Nasce dal fatto che l'esca sta nella tua rete.
- Loro portano l'esca nella tua rete. Noi portiamo la minaccia nella nostra, e la strada va in un solo senso.
- Per questo l'esca non può aprire connessioni verso la tua rete. Non devi crederci sulla parola: sono cose che si verificano, e più sotto trovi come.
Il rischio storico
Un honeypot, o esca, è un sistema che nessun utente legittimo ha motivo di toccare: quando qualcuno lo tocca, è un segnale (ne spieghiamo l'efficacia in Gli Honeypot sono molto più efficaci a rilevare minacce di quanto pensi). Più l'esca è realistica, più è convincente, e più una minaccia può sfruttarla a fondo. Evans (2002) lo riassume così: le esche realistiche sono di solito sistemi reali, e portano con sé un livello di rischio elevato per l'organizzazione che le ospita. Lo stesso quadro emerge da Pickett (2003), che riprende il lavoro di Spitzner. I rischi che descrivono, per un'esca ospitata nella rete di chi la usa, sono questi:
- Punto d'appoggio. Un'esca con un sistema operativo reale, se compromessa a fondo, può servire a una minaccia come base di partenza verso il resto della rete o verso terzi. È il rischio più citato.
- Vulnerabilità proprie. Un servizio emulato può avere difetti nella sua implementazione; un sistema reale ha quelli del suo sistema operativo, se non è aggiornato.
- Attenzione e ritorsioni. Evans osserva che una minaccia può concentrare l'attenzione sul blocco di indirizzi in cui si trova l'esca, alla ricerca di altri sistemi interessanti, e che chi si accorge di aver perso tempo può rivalersi sull'organizzazione, fino a un attacco denial of service. Ricorda anche che, dopo la pubblicazione delle loro ricerche, i sistemi del Honeynet Project subirono attacchi severi e coordinati.
- Esca riconosciuta e aggirata. Se la minaccia capisce che è un'esca, la evita, e l'esca non rileva nulla.
La letteratura aggiunge un tema di responsabilità: se l'esca viene usata per colpire terzi, l'organizzazione che l'ha installata può doverne rispondere. È una questione da affrontare con un legale.
Anche la riconoscibilità è stata misurata. Uno studio dell'Università di Cambridge (Vetterl e Clayton, 2018) ha mostrato che gli honeypot a bassa e media interazione costruiti con librerie di uso comune si distinguono dai sistemi reali con un solo pacchetto, e con scansioni su scala di internet ne ha individuati migliaia, su protocolli come SSH, Telnet e HTTP. Dallo stesso studio emerge che circa il 27% degli honeypot SSH non era stato aggiornato da 31 mesi: un'esca va tenuta aggiornata come qualsiasi altro sistema.
Il tema è riconosciuto anche dagli standard: lo NIST SP 800-53 include, nella famiglia dei controlli di protezione dei sistemi e delle comunicazioni, il controllo SC-26 (Decoys), dedicato alle esche.
Perché per noi non è una questione di contenimento
Il contenimento è la risposta abituale dei fornitori: isolamento, segmentazione, hardening attorno a un'esca che resta nella tua rete. Di solito regge, ma è un controllo, e lo mantieni tu.
Con la nostra architettura l'esca non sta nella tua rete. Gira nel nostro cloud, e nella tua rete c'è solo il dispositivo che la rende raggiungibile. Il traffico viene portato nella nostra infrastruttura prima che qualcosa debba essere contenuto.
Il contenimento avviene sul nostro lato, su infrastrutture costruite solo per questo. Gli hypervisor che ospitano le esche non sono in cluster e sono trattati come non affidabili dal resto della piattaforma, che è progettata per assorbirne la compromissione. Se il contenimento cede presso un altro fornitore, l'incidente è del cliente. Da noi, l'incidente è nostro.
Cinque domande da fare a qualsiasi fornitore, e la nostra risposta
Sono le stesse cinque della nostra guida deception e honeypot, qui con la nostra risposta e le fonti. Vale la regola della guida: non ogni domanda richiede una risposta positiva. Conta la coerenza. Accetta i limiti onesti e rifiuta le incongruenze, perché in gioco c'è la tua sicurezza.
1. Aggiornate le esche? Come arrivano gli aggiornamenti?
La risposta facile: «Non le aggiorniamo, devono essere vulnerabili.»
Perché conta. Un'esca con software obsoleto si riconosce subito: lo studio dell'Università di Cambridge (Vetterl e Clayton, 2018) ha trovato che circa il 27% degli honeypot SSH non era stato aggiornato da 31 mesi. Ma aggiornare un'esca che sta nella tua rete può aprire una strada verso la tua rete.
Cosa ascoltare: chi sceglie gli aggiornamenti e quali componenti restano volutamente esposti.
La nostra risposta. Le esche sono costruite, aggiornate e sostituite da noi, nel nostro cloud. Nella tua rete c'è solo il dispositivo che le rende raggiungibili. Non lo gestiamo da remoto e non possiamo inviargli aggiornamenti che ne modifichino il comportamento: è immutabile, con filesystem in sola lettura.
2. Come contenete un'esca compromessa?
La risposta facile: «È isolata.»
Perché conta. Il contenimento decide se l'esca è un vantaggio o un rischio. Macchine virtuali, container ed esche non interattive hanno rischi molto diversi, e il rischio più citato in letteratura (Evans, Pickett) è che l'esca compromessa diventi un punto d'appoggio.
Cosa ascoltare: cosa isola l'esca, dove avviene il contenimento e che cosa succede se cede.
La nostra risposta. L'esca gira nel nostro cloud. Il dispositivo inoltra il traffico verso l'esca e lascia tornare solo le risposte: qualsiasi richiesta che parte dall'esca viene bloccata. Il contenimento avviene sul nostro lato, su infrastrutture costruite solo per questo, e se cede l'incidente è nostro.
3. Quanto è efficace l'esca nel trattenere la minaccia?
La risposta facile: «È completamente interattiva.»
Perché conta. Pochi servizi emulati rilevano un primo contatto, ma si riconoscono in fretta: gli honeypot a bassa e media interazione basati su librerie comuni si distinguono da un sistema reale con un solo pacchetto. Serve un sistema completo e coerente, che regga anche dopo che la minaccia è entrata.
Cosa ascoltare: una dimostrazione concreta di ciò che trova chi ottiene una shell sull'esca.
La nostra risposta. L'esca è un sistema reale, non un servizio emulato, quindi non ha le impronte tipiche dell'emulazione. Non diciamo che sia invisibile.
4. Che accesso avete alla mia azienda e quale rischio di supply chain comportate?
La risposta facile: «Nessuno, le esche si collegano all'esterno.»
Perché conta. Connettersi verso l'esterno non equivale ad assenza di accesso: ogni componente che scarica aggiornamenti è una possibile via d'ingresso.
Cosa ascoltare: chi può inviare codice a quali sistemi, in quale direzione si aprono le connessioni e che cosa puoi verificare dal tuo lato.
La nostra risposta. Non abbiamo accesso al dispositivo che installi nella tua rete.
5. Dopo una compromissione, come viene ripristinata l'esca?
La risposta facile: «La reinstalliamo.»
Perché conta. L'esca è fatta per essere compromessa, e la minaccia potrebbe restarvi. Il ripristino non dovrebbe richiedere accesso alla tua rete, e ogni credenziale usata dall'esca per comunicare con il fornitore va considerata potenzialmente rubata.
Cosa ascoltare: come arriva un'immagine pulita, quanto ci vuole e quali credenziali vengono ruotate.
La nostra risposta. Distruggere e ricreare un'esca è un'operazione ordinaria della nostra piattaforma: avviene nel nostro cloud e non richiede alcun intervento nella tua rete.
La guida segnala anche due campanelli d'allarme da cercare: risposte ai comandi generate dall'intelligenza artificiale e più indirizzi per la stessa esca. Li trovi su /deception.
Per i dettagli del meccanismo non ripetiamo qui quello che trovi già spiegato: il Modello di sicurezza Hoxey descrive il dispositivo e l'isolamento, l'Architettura del sistema Hoxey i componenti della piattaforma, e Cos'è un Honeypot e come abbiamo innovato la tecnologia racconta come funziona il tunnel.
Domande frequenti
Un honeypot può essere usato per attaccare la mia rete?
Se l'esca sta dentro la tua rete ed è compromessa a fondo, può diventare un punto d'appoggio: è il rischio storico della categoria. Con la nostra architettura l'esca non sta nella tua rete, e qualsiasi richiesta che parte dall'esca viene bloccata dal dispositivo.
Cosa succede se l'esca viene compromessa?
Succede ciò per cui l'esca esiste: ricevi il segnale che c'è una minaccia. L'esca è nella nostra infrastruttura, dove il contenimento è un nostro compito, e non può aprire connessioni verso la tua rete.
Un honeypot attira più minacce verso la mia azienda?
La letteratura segnala il rischio che una minaccia concentri l'attenzione sul blocco di indirizzi dell'esca o reagisca quando capisce di aver perso tempo. Per questo conta dove e come l'esca è collocata, e che sia gestita.
Una minaccia può riconoscere un honeypot?
Dipende da come è costruito. Gli honeypot a bassa e media interazione basati su librerie comuni si riconoscono con un solo pacchetto, come mostra la ricerca. Un'esca che è un sistema reale non ha quelle impronte, ma nessuna esca è invisibile per definizione.
Un honeypot sostituisce l'antivirus o l'EDR?
No, si aggiunge. Gli strumenti che già usi continuano a fare il loro lavoro: antivirus ed EDR sono necessari, ma da soli non bastano. L'esca copre ciò che quegli strumenti non vedono, cioè la presenza di una minaccia già dentro la rete, il tema di Mura potenti. Nessun allarme. Per capire come ci si accorge di una violazione già avvenuta, leggi Come accorgersi che la rete aziendale è stata violata.
Fonti: Evans, Honeypots - Weighing up the Costs and Benefits (GIAC, 28 ottobre 2002); Pickett, A guide to the honeypot concept (GIAC, 2003); Vetterl e Clayton, Bitter Harvest: Systematically Fingerprinting Low- and Medium-interaction Honeypots at Internet Scale (USENIX WOOT, 2018); NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations.