È un termine poco conosciuto da parte dei non addetti ai lavori ma il dwell time è forse uno degli elementi più importanti da conoscere per chi opera nell’ambito della cybersecurity.
Che cosa è il dwell time in ambito cybersecurity
Il termine inglese dwell time significa letteralmente tempo di sosta o più correttamente tempo di permanenza (il termine dwell significa permanere). È quindi un termine generico che può essere utilizzato in vari ambiti operativi come, ad esempio, nelle strategie di marketing e nella cybersecurity.
In ambito di cybersecurity (o cibersicurezza come da Direttiva UE 2022/2555) il termine dwell time è fondamentale ed identifica l’intervallo di tempo compreso tra l’infezione del sistema da parte di una minaccia, al suo effettivo rilevamento. L’azienda di sicurezza Checkpoint ha fornito un’utile definizione del dwell time descrivendolo come segue:
Attack dwell time, the interval between an initial breach and its detection, is a crucial metric in cybersecurity. The longer attackers go undetected, the more damage they can inflict.
Il tempo di permanenza degli attacchi, l'intervallo tra una violazione iniziale e la sua rilevazione, è una metrica cruciale nella sicurezza informatica. Più a lungo gli attaccanti rimangono non rilevati, maggiori sono i danni che possono infliggere.
Perchè è importante il dwell time
Il dwell time è importante per una serie di motivi: il primo tra tutti è che tale intervallo di tempo rappresenta un momento critico del ciclo d’infezione in un attacco multi-staging. È un momento “non sorvegliato”, in cui spesso i sistemi di sicurezza non percepiscono la minaccia. La stessa Checkpoint spiega molto chiaramente che le piattaforme di Security Orchestration, Automation and Response (SOAR), deputate all’organizzazione e risposta agli incidenti, rimangono spesso inerti perchè non individuano la minaccia in questa primissima fase.
Durante questi primi momenti la minaccia inizia a comporsi e quindi comincia ad assumere quella che poi sarà la configurazione più minacciosa e devastante espressa dal programma malevolo. Il motivo per il quale le piattaforme SOAR non funzionano, secondo Checkpoint, è da ricondurre al fatto che “questi sistemi spesso operano all’interno di silos di dati isolati, portando a una visibilità frammentata e a risposte ritardate“. Ci sono poi altri problemi legati al volume degli avvisi che, anche in modo capzioso, potrebbero portare gli esperti del team SOC a sottovalutare o ignorare quelli effettivamente reali.
Anche Checkpoint rimarca l’utilità del supporto dell’intelligenza artificiale nella gestione di questi fenomeni e nel supporto ai team SOC poichè “consente un rilevamento e una risposta più rapide e accurate, sfruttando il vigore dell’IA e dell’automazione per migliorare i processi TDIR (ndr: Threat Detection and Incident Response)”. Questo è stato argomento di docenza al MEDDLE che si è tenuto a Milano e di un articolo che è possibile leggere qui.
Dwell Time e Fasi di attacco
Per comprendere bene dove si inserisce il dwell time all’interno di un data breach è possibile fare riferimento allo schema sotto riportato. S’immagini un normale attacco ransomware:
- Fase 1: l’hacker avvia le fasi di exploitation e installazione degli applicativi malevoli.
- Fase 2: l’hacker ottiene il controllo sul sistema e avvia la fase di esfiltrazione.
- Fase 3: l’hacker avvia l’attività di cifratura/cancellazione dei dati.
Il dwell time corrisponde all’intera fase 2, ed è il motivo per cui la traduzione più corretta è tempo di permanenza. L’hacker permane all’interno del sistema per tutta la fase due attuando le politiche di comando e controllo necessarie a gestirlo e ad esfiltrare i file; in questa fase la sua attività è silenziosa, spesso invisibile ma costante.
Nella fase 3, invece, vi è l’evidenza dell’attacco: i file vengono resi inaccessibili e di questo si accorgono tutti gli operatori e non solo i membri del team SOC. Si potrebbe dire che “ormai è tardi”, l’hacker ha già ottenuto tutto ciò di cui aveva bisogno (il controllo del sistema e i file).
Gestire il dwell time
Il National Institute of Standards and Technology (NIST) ha pubblicato un interessante documento creato dall’azienda Mandiant ed intitolato “Using Metrics to Mature Incident Response Capabilities” (link). È opportuno fare presente che il documento non è aggiornato, anzi è piuttosto datato (09 aprile 2014) ma riporta informazioni interessanti su cui riflettere e che rispondono ad una domanda: è possibile parametrizzare attraverso il modello DRAIN CVR. Si tratta di un acronimo che significa:
- Detect
- Review
- Analyze
- Identify
- Notify
- Collect
- Validate
- React
Secondo Mandiant l’attività di gestione del dwell time deve essere realizzata attraverso specifiche attività tese ad eseguire le azioni sopra descritte. Il grafico sotto riportato può aiutare a comprendere meglio la metodologia proposta da Mandiant.
In italiano potremmo adattare il modello DRAIN CVR come segue:
| INGLESE | ITALIANO |
|---|---|
| Detect | Determina |
| Review | Rivedi |
| Analyze | Analizza |
| Identify | Identifica |
| Notify | Notifica |
| Collect | Colleziona |
| Validate | Valida |
| React | Reagisci |
È altresì importante notare come Mandiant abbia diviso il momento DRAIN da quello CVR: il primo è composto da azioni d’indagine e segnalazione che appartengono al dwell time. Il secondo prevede attività di contenimento.
Quanto può durare un dwell time?
Ci sono casi molto interessanti di data breach estremamente longevi e chi sostiene che il dwell time duri pochi giorni se non addirittura ore, semplicemente sbaglia. Nell’articolo “Breach Detection | Controlling Dwell Time Is About Much More Than Compliance” di R. MacMillan è scritto “secondo gli ultimi rapporti di M-Trend la media del tempo di permanenza globale è di 99 giorni. Le regioni EMEA e Asia-Pacifico vanno ancora peggio, con una media di 106 giorni per Europa, Medio Oriente e Africa, salendo a 172 giorni in Asia.”
La class action intentata contro Noodles & Co l’anno scorso è stata basata in parte sulla responsabilità che la società aveva per consentire al malware di persistere inosservato per un periodo di tempo così lungo, in tal caso il tempo di permanenza era di circa 5 mesi.
Fonte: “Breach Detection | Controlling Dwell Time Is About Much More Than Compliance” di R. MacMillan
È quindi importante comprendere che l’intervallo di permanenza è una vera e propria criticità nell’ambito della gestione della cybersecurity.
Incoerenze di configurazione
Se quindi da una parte vi è la necessità d’intervenire sulle piattaforme, adottando quelle più evolute, sofistica e reattive, dall’altrà vi è però l’obbligo di farsi alcune domande in merito al controllo della configurazione. I recenti provvedimenti del Garante per la Protezione dei Dati (si pensi ad esempio al 10002324 sulla società LazioCrea S.p.A., o il 10002287 sulla Regione Lazio, o il 9941232 sulla ASL Napoli 3 Sud) dimostrano quanto poco ci sia attenzione verso le regole base della sicurezza informatica. Il filtraggio del traffico, piuttosto che la segmentazione delle reti rappresentano la base per qualsiasi infrastruttura informatica e la loro assenza non faciliterà il lavoro dei sistemi di sicurezza.
Senza contare che, molto spesso, i sistemi di sicurezza di cui sopra vengono installati in ecosistemi datati, non aggiornati o addirittura già compromessi da minacce presenti sui server. In condizioni del genere diventa quindi difficile, se non impossibile, ottenere risultati quantomeno apprezzabili. Vi è quindi un’incoerenza di base: non posso garantire la sicurezza dei sistemi se gli stessi sono mal configurati oppure operano in un regime di sicurezza troppo basso o insufficiente.
Conclusioni
Il dwell time è un problema, soprattutto perchè non sempre le azioni condotte dall’hacker in questo periodo sono tali da sollecitare l’attivazione delle misure di sicurezza. È quindi fondamentale avere, da una parte sistemi ben operanti e dall’altra corretti meccanismi di controllo (sia a livello tecnico che operativo-metodologico) senza i quali è pressochè impossibile ottenere risultati soddisfacenti. Senza dubbio l’intelligenza artificiale è in grado di supportare le attività di monitoraggio e identificazione non tanto dei singoli comportamenti messi in atto dall’hacker, quanto dai risultati provenienti da questi che potrebbero essere problematici.
