Che caratteristiche ha un sistema XDR?
Come può aiutare chi è stato colpito da un attacco?
LA CYBERSECURITY RICHIEDE OLISMO
Una delle mie convinzioni in tema di CyberSecurity è che gli attacchi si realizzino sugli endpoint; o, quantomeno, che il punto di contatto tra il mondo digitale e l’utente sia strumentale e fondamentale affinché un attacco possa aver luogo.
È infatti l’endpoint il posto in cui l’utente – da sempre l’anello più debole della catena di difesa – interagisce con il cyber-verso, si espone online, viene compromesso da un tentativo di attacco.
In questi tempi moderni di remotizzazione digitale e utilizzo massivo del cloud, la propagazione degli effetti di un attacco è caratterizzata da una viralità ed una pervasività impressionanti.
Tutto ciò mette a durissima prova le capacità delle aziende di rilevare e rispondere in tempi adeguati a mitigare l’impatto, così come dannosissime conseguenze in termini reputazionali, finanziari e di continuità operativa.
Oltre agli esempi più immediati, la veridicità di quanto affermato resta anche negli scenari più complessi: un utente accede con una forma di autenticazione forte ad un ambiente di sviluppo, essendo responsabile della configurazione di un sistema di risorse cloud; durante il processo di terraforming (termine tipicamente utilizzato per definire la fase di configurazione) dimentica una istruzione per ridurre la lista di IP che possono accedere all’istanza di storage configurata. Ecco create – sempre grazie all’interazione tra l’utente e il cyber-verso avvenuta tramite un endpoint – le condizioni ideali per un attacco di data leak in cloud.
Una delle mie convinzioni in tema di CyberSecurity è che gli attacchi si realizzino sugli endpoint; o, quantomeno, che il punto di contatto tra il mondo digitale e l’utente sia strumentale e fondamentale affinché un attacco possa aver luogo.
È infatti l’endpoint il posto in cui l’utente – da sempre l’anello più debole della catena di difesa – interagisce con il cyber-verso, si espone online, viene compromesso da un tentativo di attacco.
In questi tempi moderni di remotizzazione digitale e utilizzo massivo del cloud, la propagazione degli effetti di un attacco è caratterizzata da una viralità ed una pervasività impressionanti.
Tutto ciò mette a durissima prova le capacità delle aziende di rilevare e rispondere in tempi adeguati a mitigare l’impatto, così come dannosissime conseguenze in termini reputazionali, finanziari e di continuità operativa.
Oltre agli esempi più immediati, la veridicità di quanto affermato resta anche negli scenari più complessi: un utente accede con una forma di autenticazione forte ad un ambiente di sviluppo, essendo responsabile della configurazione di un sistema di risorse cloud; durante il processo di terraforming (termine tipicamente utilizzato per definire la fase di configurazione) dimentica una istruzione per ridurre la lista di IP che possono accedere all’istanza di storage configurata. Ecco create – sempre grazie all’interazione tra l’utente e il cyber-verso avvenuta tramite un endpoint – le condizioni ideali per un attacco di data leak in cloud.
Un altro esempio calzante potrebbe essere un'architettura di Active Directory configurata male, con i sistemi che appartengono al dominio non standardizzati e molti di questi fuori supporto. In caso di attacco diventa importante supportare la resilienza dell'ecosistema, la cui postura di sicurezza è evidentemente non ottimale, correlando indicatori di anomalie con le informazioni provenienti dall'asset management.
Nascono quindi due domande importanti:
Come rilevare nel modo più olistico possibile questi eventi anomali, unendo tutti i puntini per aumentare la comprensione del contesto e dell’urgenza al fine di prioritizzare l’intervento?
Come effettuare questo rilevamento nel modo più rapido possibile, per accelerare risposta e rimedio?
Nascono quindi due domande importanti:
Come rilevare nel modo più olistico possibile questi eventi anomali, unendo tutti i puntini per aumentare la comprensione del contesto e dell’urgenza al fine di prioritizzare l’intervento?
Come effettuare questo rilevamento nel modo più rapido possibile, per accelerare risposta e rimedio?
Più in generale, l’annoso problema è nella minimizzazione del dwell time: questo il nome del tempo che intercorre tra la compromissione di un ecosistema e il rimedio del danno, passando per il momento intermedio in cui la compromissione viene rilevata.
 |
| Stando a un report di Mandiant del 2021, il numero medio di giorni di dwell time nel 2020 in EMEA è aumentato a 66 giorni, da 54 che era nel 2019. Non solo questa cifra è un segnale di peggioramento medio, ma espandendo il dato medio troviamo una situazione molto preoccupante1, che riporto nell’illustrazione che segue – presa dal report. |
 |
Figura 1 - Fonte: Mandiant M-Trends Report 2021 |
In 225 giorni il pianeta Venere compie un giro intero intorno al Sole! Immaginate il livello di danno che un attaccante motivato potrebbe apportare all’organizzazione che è riuscito a compromettere. Per avere un quadro più preciso dei danni e costi che derivano da questi attacchi, in cui la permanenza offre all’attaccante tutto il tempo di eseguire ogni tipo di azione negli ecosistemi compromessi, è possibile far riferimento al report Data Breach Investigation Report di Verizon.
RISOLVERE IL PROBLEMA: DA EDR A XDR, PASSANDO PER MDR
Per mitigare questo problema potenziando le capacità richieste, negli anni scorsi sono emerse soluzioni di Endpoint Detection and Response.
L’aiuto tangibile di un EDR è a due livelli:
- rilevamento e blocco preventivo di un tentativo di compromissione, con azioni attive simili a quelle di un antivirus sofisticato.
- identificazione del contesto post-compromissione, al fine di semplificare il rilevamento delle anomalie sfuggite alla prevenzione e permettere azioni di risposta per mitigare il danno: ad esempio quarantena di file, terminazione di processi in esecuzione, isolamento controllato in rete della macchina infetta.
Questi strumenti molto potenti ed efficaci sono spesso sottoutilizzati dalle aziende a causa della scarsità o dell’incompetenza di risorse interne. Tale situazione ha stimolato la richiesta e la nascita di specifici servizi che facessero economia di scala nelle competenze e risorse necessarie per esercire in modo efficace sistemi di rilevamento e risposta per conto terzi.
Questi servizi vanno sotto il nome di Managed Detection and Response o MDR.
Si diceva però all’inizio di come la complessità crescente della biodiversità digitale, che caratterizza ogni organizzazione moderna, comportasse un problema di visibilità dell’intero ecosistema IT. Scarsa visibilità che rappresenta un limite enorme alle attività di rilevamento e risposta così importanti per una corretta postura di cybersecurity.
Questa esigenza olistica ha determinato l’evoluzione del concetto di EDR verso una detection e response espansa a coprire tutto il panorama digitale di un’organizzazione: da qui l’acronimo XDR, eXpanded Detection and Response.
Un sistema XDR permette di concentrarsi sul comportamento anomalo tipico di una strategia di attacco, considerando i segnali dell’intero ecosistema adeguatamente normalizzati e correlati per essere consumabili da esseri umani.
Non solo quindi la telemetria visibile sull’endpoint, fatta di file, di processi e di comunicazioni di rete ricevute e iniziate verso l’esterno; bensì informazioni dall’ambiente circostante sull’interazione che l’endpoint ha avuto con lo stesso e con entità simili, quindi altri endpoint, oppure dispositivi IoT, router, firewall, proxy, sistemi di gestione identità, risorse cloud e molto altro.
Questa logica spiega perché XDR viene considerato da molti CISO una soluzione ad annosi problemi che tutt’ora affliggono l’efficacia e l’efficienza della CyberSecurity difensiva.
Un XDR è caratterizzato da tre importanti tratti distintivi:
- la capacità di integrarsi con elementi circostanti in modo bidirezionale: cioè ricevendo flussi di informazioni sugli eventi tracciati, ma anche inviando istruzioni su reazioni che possono essere eseguite solo da questi elementi. Un esempio con un sistema proxy sarebbe di bloccare la navigazione verso uno specifico sito web, in quanto fonte di download malevoli.
- la capacità di analizzare la telemetria ricevuta e rilevata: cioè normalizzare e correlare enormi quantità di dati praticamente in tempo reale, sfruttando forme di intelligenza artificiale (IA) che permettano di trovare segnali, sentieri di briciole di pane lasciate dall’attaccante, in mezzo a enormi spiagge di granelli di sabbia molto simili tra loro. Questa operazione non sarebbe certamente alla portata di nessun team di security operations ed è tipicamente demandata a infrastrutture cloud per l’elevata capacità computazionale e di memorizzazione dati che richiede.
Da notare che la intelligenza artificiale deve essere di tipologia supervised, cioè beneficiare di una pre-istruzione che permetta di identificare il malevolo dall’anomalo e dal normale. Per approfondire le diverse tipologie di IA, rimando all’interessante articolo che Orazio Danilo Russo ha pubblicato lo scorso luglio.
- La capacità di rispondere in modo attivo, sfruttando interfacce di comunicazione chiamate API (Application Programming Interface), tramite le tecnologie con cui si integra. Di norma questa azione avviene seguendo delle procedure precodificate chiamate Playbook, che descrivono le varie sequenze di operazioni in modo da accelerare ed automatizzare il più possibile la risposta.
Va da sé che la capacità olistica messa in campo da un sistema XDR ben integrato con il proprio ecosistema IT potenzia enormemente le risorse specializzate, sia quelle interne all’organizzazione che quelle eventualmente attivate tramite un servizio MDR.
La domanda a conclusione di questo articolo potrebbe quindi essere: come misuro l’efficacia di un sistema XDR?
La risposta che vorrei proporre è strutturata in due ambiti: valutazione qualitativa e metriche.
Da un punto di vista qualitativo l’XDR dovrebbe potenziare tre aree:
- Security Analytics, cioè l’insieme di dati aggregati, correlati e processati che supportano il processo di monitoraggio della postura di sicurezza e rilevamento tempestivo di minacce a tale postura.
- Proactive Threat Hunting, cioè l’attività di identificazione di minacce in modo proattivo a partire da anomalie oppure da segnali tenui, scremando efficacemente l’enorme rumore di fondo. Quanto diventa più facile unire i puntini per capire – magari utilizzando un unico identificativo per ogni incidente – cosa è successo retrospettivamente, al fine di pianificare il prosieguo delle operazioni?
- Automated Incident Response, cioè l’aumento della velocità di reazione nella risposta all’incidente fino alla mitigazione o al rimedio.
Dal punto di vista quantitativo, l’adozione di una soluzione XDR dovrebbe permettere di iniziare a sviluppare metriche su tempo medio di rilevamento attacco (MTD, da Mean Time to Detect) e tempo medio di risposta/rimedio (MTR, da Mean Time to Respond/Remediate).
Oppure raffinare le misurazioni già attivate alla luce delle nuove capacità, per verificare la bontà dell’investimento e bilanciare meglio i modelli ibridi che prevedano l’utilizzo di servizi esterni e risorse interne combinate.
Marco Rottigni
Nessun commento:
Posta un commento