Una notizia di oggi, segnalatami dal sempre attentissimo Nicola Del Ben, mi porta a riflettere ancora una volta sul ruolo delle assicurazioni come strumento per la gestione del rischio cyber. Negli ultimi anni ho visto un’evoluzione di approccio e di proposta passando da sterili questionari a veri e propri assessment in grado di dare una buona stima dei fattori di rischio in ambito sicurezza delle informazioni.
Non è questa la sede per parlare dell’efficacia del modello, anche perché servirebbe un dibattito con qualche decina di esperti in più settori. Il tema che porto all’attenzione è relativo alle parole di Mario Greco, AD di Zurich, che ritiene si stia andando verso uno scenario dove il rischio cyber non sarà assicurabile.
Pone inoltre l’attenzione su un’altra questione, ovvero sulla difficoltà di fare previsioni sulle conseguenze di un attacco, soprattutto in situazioni complesse che toccano servizi infrastrutturali o dati privati dei cittadini. Come discusso in molte occasioni anche con Andrea Dainese, il livello di pervasività tecnologica è così elevato da rendere effettivamente difficile fare previsioni su ciò che potrebbe accadere se venisse compromesso un sistema fondamentale per un’azienda, un’organizzazione o uno Stato.
Abbiamo delegato molto alla tecnologia e il concetto di security by design non è ancora permeato nella cultura di molte aziende produttrici, tanto meno nelle aziende utilizzatrici. Troppo spesso acquisiamo tecnologia che non abbiamo compreso, in alcuni casi anche il partner che ci sta proponendo una certa tecnologia non ne ha una completa padronanza. In altre parole stiamo costruendo sovrastruttura tecnologica che non governiamo ed è ovvio non riuscire a prevedere le conseguenze di un eventuale incident.
Gestire questa complessità richiede consapevolezza, la consapevolezza la otterremo a seguito di un percorso culturale fatto di studio, acquisizione di competenze, acquisizione di esperienze. Dobbiamo entrare nell’ordine di idee che la sicurezza informatica non si “compra” in senso stretto. E’ possibile comprare dei supporti (la tecnologia) e dei facilitatori (consulenti e partner esperti di sicurezza informatica).
Mia riflessione: lo strumento assicurativo, per quanto utile, non è la risposta alla prevenzione. Ha aiutato e può aiutare ad assorbile parte del rischio, ma il grosso del lavoro non è avere una buona polizza assicurativa (anche in virtù della previsione di Greco).
La gestione del rischio deve diventare un tema di strategia per aziende ed organizzazioni, non può restare una task list da dispacciare a diversi dipartimenti. Serve un filo conduttore a livello aziendale, una visione comune che tenga conto di cosa sia la cyber security e che utilizzi i mezzi a disposizione (tecnologia, competenze, assicurazioni, ecc.) come strumenti utili allo scopo e non come obiettivi.
A chi è del mestiere ed è attivo da qualche annetto nel mondo cyber security (e/o ambienti acari di un tempo non così lontano) potrebbe capitare di essere poco avvezzo all’utilizzo di strumenti di apprendimento come gli ambienti simulati ed appositamente preparati per essere “attaccabili”.
Personalmente ne faccio poco uso pur trovandoli molto divertenti ed interessanti: il mio approccio mi porta a trovare più stimolante costruire un ambiente realistico, spesso riproducendo scenari reali che ho incontrato, per allenare una tattica o preparare qualcosa di nuovo. Ovviamente questo ha senso per chi ha esigenza di immergersi in scenari reali, mentre chi è in una fase di studio o di miglioramento di specifiche skills probabilmente trova più vantaggioso utilizzare un ambiente simulato e preparato appositamente per quell’esigenza.
Ho avuto modo di usare diverse piattaforme compreso il progetto italiano pwnx.io che, lo dico senza problemi, a me piace molto. Si tratta chiaramente di ottime risorsa per imparare, per prendere confidenza con gli ambienti, per crescere. Va anche tenuto in considerazione il fatto che il mondo vero di solito è un po’ diverso, non intendo più facile o più difficile ma semplicemente diverso. Usiamo quindi queste piattaforme con la consapevolezza di affrontare qualcosa che è stato creato ad hoc.
Banale? Come al solito sì, ma non credo di essere l’unico che si è trovato d’avanti ad un “Cyber Security Expert” con punteggi favolosi sulle piattaforme di simulazione e con gravi lacune tecniche sul funzionamento base di un sistema o di una rete. Diciamocelo, se approcciamo così queste piattaforme – che, ripeto, sono utilissime per imparare – stiamo commettendo un errore non da poco.
Come sempre per me la cosa migliore è fare un po’ di mix, esplorare più scenari, più piattaforme, più argomenti e farsi un’idea generale per poi approfondire l’ambito che più ci interessa o dove preformiamo meglio… ma approfondire sul serio, non solo a livello di tools e scripts da usare in batteria… non basta capire come funzionano le cose ma anche perché funzionano. La famosa differenza tra “apprendere” e “comprendere” (rif. alle lezioni di Umberto Galimberti).
Con questo spirito condivido gli articoli ed i post sui miei lab di studio che simulano situazioni reali e con questo spirito questa sera partecipo ad una CTF con un team letteralmente improvvisato al puro scopo di condividere un’esperienza assieme ed imparare dal confronto (https://ctf.nahamcon.com/).
Per chi vuole fare due chiacchiere ci vediamo questa sera sul mio server Discord o sul canale Twitch.
Vi condivido una breve riflessione a seguito di diversi casi reali che ho avuto modo di osservare nelle ultime settimane, ovviamente senza dare riferimenti di nessun tipo sui protagonisti. E’ per me importante condividere questo tipo di esperienza per un motivo banale: è qualcosa che può accadere a chiunque e non è detto che si abbiano gli strumenti per intercettare rapidamente alcuni indicatori di compromissione, è quindi opportuno condividere esperienze in merito al fine di essere tutti più consapevoli.
Lo scenario è oggi un grande classico ma solo un paio di anni fa, quando ne parlavo con i diretti interessati, sembrava fantascienza: un dispositivo IoT interconnesso alla rete dell’azienda con esigenza di accesso alla rete internet per conversare, anche solo dall’interno verso l’esterno, con i sistemi in cloud del fornitore e/o gestore del servizio. Nel corso dell’ultimo anno ho seguito diverse attività in ambito cyber sec. in contesti di “rete di fabbrica” ed ho avuto la fortuna di vedere in dettaglio alcune implementazioni. La banalizzo un po’ per rendere il concetto fruibile a più persone possibili, gli esperti mi perdoneranno ed eventualmente integreranno con la loro saggezza (sempre apprezzata).
Di solito abbiamo diversi dispositivi che dialogano con i sistemi di produzione per raccogliere informazioni e/o impartire istruzioni. I sistemi su cui queste informazioni vengono depositate possono essere all’interno dell’infrastruttura di rete come all’esterno. Molti player del mondo Public Cloud mettono a disposizione fantastiche piattaforme per la gestione di questi dati, non è quindi raro trovare sistemi IoT che dialogano con l’esterno della rete per atterrare sui sistemi che ospitano i servizi incaricati di elaborare i dati raccolti.
Quella che nel disegno è definita come “magic network(s)” sappiamo essere un tema complesso ma non è il focus di questo post; l’argomento segregazione delle reti in ambito IT ed OT in risposta alle esigenze di prevenzione delle minacce informatiche che hanno come target i sistemi industriali merita un capitolone dedicato. In questa occasione mi concentro sulle implicazioni di un sistema che dall’interno della rete è titolato a dialogare con un sistema all’esterno della rete di cui non abbiamo una completa gestione (visto che non è nostro) e di cui non siamo in grado di definire direttamente le politiche di sicurezza dovendo accettare, si spera dopo averle validate, quelle del fornitore.
In relazione ai dati scambiati il tema è relativamente semplice: proporzionalmente all’impatto che avrebbe la perdita, la manomissione o la sottrazione di questi dati dovremmo definire delle politiche di protezione, dalla sicurezza della comunicazione alle politiche di backup dei dati storici. Questo è un elemento che di solito trovo presidiato: si cerca di utilizzare protocolli che facciano uso della cifratura e si prediligono servizi consoni al trasferimento di informazioni. Per farla breve, c’è ancora chi spara archivi .zip via FTP ma, almeno nei contesti in cui opero io, sono decisamente pochi.
Avendo la possibilità di dialogare sempre con la propria infrastruttura cloud il dispositivo IoT viene spesso dotato di procedure di self provisioning si per le configurazioni che per le componenti software, fino a poter anche aggiornare il firmware del dispositivo stesso. E’ una scelta tecnicamente validissima in quanto da modo al fornitore di aggiornare il dispositivo senza intervenire on-site, sarà quindi il dispositivo a chiedere ai sistemi centralizzati se ci sono nuovi elementi software da installare o configurazioni da modificare. Per chi fa il mio lavoro ricorda molto il funzionamento dei C2.
Se chi gestisce la rete in cui il dispositivo viene inserito ha l’onere di assicurarsi che le policies di comunicazione siano idonee (ne parliamo in un post a parte come già detto), chi gestisce la cloud deve garantire la sicurezza delle informazioni e dei sistemi a cui i devices accedono. Un threat actor in grado di accedere ai sistemi cloud potrebbe compromettere in profondità il sistema in cloud oppure potrebbe limitarsi a manomettere il sistema al fine di far atterrare sul device IoT una componente malevola. In questo caso l’attacker avrebbe potenziale accesso a tutti i sistemi IoT che afferiscono alla cloud compromessa.
La scelta dipende ovviamente dalle funzionalità che il sistema mette a disposizione: se è possibile impartire comandi al dispositivo IoT (ci sono sistemi che lo prevedono per garantire un certo livello di amministrazione) diventa possibile eseguire azioni anche molto invasive dall’interno della rete target in un contesto tipicamente delicato come la rete di fabbrica, diventa quindi semplice eseguire attività di ricognizione a caccia di altri sistemi o informazioni utili a mettere radici.
Come intercettare il problema
Premesso che dovremmo iniziare a lavorare di prevenzione qualificando opportunamente i fornitori, è bene avere una strategia di intercettazione e gestione di questa tipologia di incident. Non avendo pertinenza sulla componente cloud ed essendo le comunicazioni necessariamente autorizzate oltre che cifrate, la detection difficilmente può avvenire a monte (non impossibile, ma difficile). Quello che possiamo sicuramente fare è lavorare sulla pertinenza locale: eventuali attività da parte dell’attacker genereranno sicuramente del traffico in rete verso destinazioni differenti dalle solite. In molti casi questi dispositivi dialogano con un numero limitato di sistemi interni, potremmo quindi insospettirci di qualsiasi comunicazione verso hosts insoliti (funzionalità disponibile in molte soluzioni di detection).
Anche il tipo di traffico è un elemento importante, questi sistemi solitamente utilizzano un set specifico di protocolli del mondo OT oltre ad HTTPS per la comunicazione con le API ed a qualche protocollo base come NTP e DNS. Proprio su questi ultimi due va fatto un focus ulteriore: esistono diverte tattiche di tunnelling basate proprio su questi protocolli, pur essendo traffico spesso legittimo è bene fare degli approfondimenti per verificare che non siano in corso azioni di exfiltration. Personalmente suggerisco di utilizzare, se disponibili, servizi interni per NTP e DNS in modo da negare il traffico verso l’esterno da questi dispositivi, ma non è sempre possibile.
Gli attacchi informatici, ce lo diciamo spesso, non sono composti da singola azioni chirurgiche. Esiste un path, un set di azioni che vengono svolte in sequenza e che inevitabilmente lasciano qualche traccia. In un contesto come quello descritto, in cui l’attacker di fatto trova un punto di accesso a causa di un problema introdotto da un terzo attore, è indispensabile essere preparati per intercettare gli effetti delle azioni di attacco più che le azioni in se in quanto potenzialmente non visibili.
Conclusioni e riflessioni
Nel prossimo periodo parlerò in più occasioni di detection e delle soluzioni e servizi che possiamo mettere in campo a tal fine. In questa occasione la riflessione che vorrei portare si riferisce ad un tema di strategia e predisposizione. E’ ovvio che le aziende debbano dotarsi di strumenti che avranno l’esigenza di dialogare con l’esterno della rete. E’ anche ovvio che le aziende non possono gestire la sicurezza informatica dei propri fornitori. Quello che è possibile fare è qualificare il fornitore definendo dei requisiti minimo di sicurezza che il fornitore deve rispettare.
Le aziende e le organizzazioni sono troppo interconnesse tra loro per non considerare questo aspetto della sicurezza informatica. E’ un tema di strategia che possiamo gestire in modo strutturato.
Qualche giorno fa, assieme ai mitici Stefano Giraldo, Andrea Dainese e Mario Rosi, abbiamo condiviso una sessione su Twitch (disponibile a breve anche sul mio canale YouTube) sul tema Anti-DDoS in cui Stefano ci ha illustrato il funzionamento delle tecnologie di mitigazione di questa tipologia di attacchi e gli scenari per una corretta difesa.
L’occasione è stata utile per discutere anche alcune tecniche di DDoS che fanno uso tattiche di “amplificazione” degli attacchi, una pratica particolarmente furba che vorrei approfondire in una delle prossime live.
Stefano ha acconsentito alla distribuzione delle slide che trovate di seguito:
Ringrazio ancora una volta Stefano per averci messo a disposizione il suo tempo e la sua competenza per discutere apertamente di temi complessi al solo scopo di condividere un po’ di cultura ed esperienza.
Rocco Sicilia 