cyber security, OT/IoT

Sicurezza dei sistemi industriali e centralizzazione dei controlli (Rif. CVE-2021-33721)

Qualche giorno fa ho avuto modo di analizzare una CVE relativa ad un sistema di gestione delle reti appositamente creato per proteggere i sistemi che compongono una rete industriale, ovvero quel complesso aggregato di sistemi connessi da un lato alle reti IP e dall’altro alle reti OT.

La CVE in questione, datata 10 agosto, notifica la possibilità di eseguire “Command Injection” ai danni del prodotto Siemens Sinec NMS. La cosa interessante è che il prodotto è stato concepito per semplificare la gestione della sicurezza dei dispositivi OT di una rete industriale con specifiche funzionalità di firewalling, asset management, patch management, ecc…

In una rete complessa e ricca di dispositivi, nel mondo IT tanto quanto nel mondo OT, è indispensabile definire procedure e regole per l’aggiornamento e la protezione dei sistemi, se la rete è particolarmente grande o complessa è poco plausibile pensare di fare tutto a manina. Adottare strumenti di gestione centralizzati è quindi del tutto naturale oltre che auspicabile.

In un contesto operativo dove è del tutto normale strutturare sistemi di gestione centralizzati va ancor di più considerato il livello di allerta nella gestione degli asset che ci semplificano la governance in quanto un problema di sicurezza su una piattaforma centralizzata potrebbe generare fastidi e incident di una certa portata.

SINEC wiki Documentation

La CVE in oggetto è un esempio perfetto: stando alla documentazione ufficiale il software è in grado di eseguire la gestione dei sistemi OT attraverso la rete (rif. documentazione Siemens: https://assets.new.siemens.com/siemens/assets/api/uuid:4fc55df6-c6da-4fbc-8112-8a910b668e23/network-management-for-more-network-security.pdf). Vista la tipologia della vulnerabilità descritta anche in una nota del produttore (https://cert-portal.siemens.com/productcert/pdf/ssa-756744.pdf) sarebbe possibile compromettere il sistema di gestione e di conseguenza interferire sull’operatività dei dispositivi stessi.

E’ molto probabile che gli utilizzatori di queste tipologie di software siano in parte dipendenti dal buon funzionamento della piattaforma, ragion per cui il business impact potrebbe essere stato classificato come elevato. Il rilevamento di una vulnerabilità con score elevato come quella riportata in questa CVE deve quindi innescare una immediata reazione di mitigation e remediation in accordo con il piano di gestione delle vulnerabilità che tutti dovremmo avere.

Nel caso specifico la nota di Siemens segnala che non ci sono azioni di mitigation salvo valutare l’applicazione di rules per limitare l’accesso al sistema. E’ però già disponibile una versione che non presenta la falla: SINEC NMS V1.0 SP2 rilasciata il 18 maggio.

La nota di rilascio della v1.0 SP2 da un altro spunto di riflessione: l’update non era classificato come security update, si trattava infatti di un rilascio che riportava nuove funzionalità e miglioramenti al software. Spesso vengono implementati piani di patch management che tendono ad escludere o non dare nessuna priorità agli update e si tende a dar seguito al patching dei sistemi quando si presenta un fix legato alla sicurezza del sistema.

In questo caso questa condotta avrebbe portato ad una involontaria esposizione ad un rischio (anche se non noto) in quanto l’installazione della SP2 avrebbe di fatto prevenuto lo sfruttamento della vulnerabilità segnalata solo tre mesi dopo.

Patch Management e Vulnerability Management sono due procedure che possono convergere ma non sarebbe sano adottare solo una delle due.

cyber security

Fenomenologia del Dark Web: la vendita di dati falsi

In relazione ad un recente e noto attacco informatico ad un ente pubblico italiano ho avuto modo, come molti professionisti e ricercatori del settore, di svolgere qualche analisi per comprende le dinamiche, imparare qualcosa di nuovo e, se possibile, migliorarsi ed aiutare altri a migliorare.

Ieri sera (11/08) ho dedicato un po’ di tempo alla lettura di alcuni canali e siti non fruibili nel di superficie e ho trovato un paio di conversazioni interessanti che qui vorrei analizzare almeno in parte.

In entrambi i casi un utente apriva una richiesta di trading manifestando interesse per i dati potenzialmente sottratti durante il noto attacco. Le conversazioni che ho analizzato iniziano a partire dal 3 agosto e gli scambi sono ancora in corso. Il modello è abbastanza tipico: qualcuno chiede, qualcuno risponde e vengono scambiati dei dati parziali a dimostrazione dell’effettivo possesso delle informazioni.

Ho controllato qualche set di dati tutt’ora disponibili su piattaforme di libero accesso (se si ha il link ovviamente) come Pastebin al fine di verificare la potenziale autenticità delle informazioni. Mi sono limitato ad alcuni controlli semplici che qui espongo.

Profili social

Buona parte dei nominativi ha una o più corrispondenze con profili social sulle principali piattaforme. Ho concentrato alcuni check su LinkedIn per ipotizzare una verosimile età anagrafica e un’area geografica di riferimento.

Codice fiscale

Con il semplice calcolo “inverso” del codice fiscale esposto è possibile verificare banalmente il nome, data e luogo di nascita. I codici fiscali analizzati avevano effettivamente tutti delle corrispondenze da cui si deduce una possibile autenticità o l’utilizzo di un algoritmo per la generazione dei dati ben fatto (non è cosa difficile).

Mobile

L’estratto dei dati riportava anche un riferimento mobile sul quale è possibile eseguire una semplice ricerca a livello di presenza su piattaforme come WhatsApp e Telegram. Molti profili (non tutti) risultano presenti ed i numeri sono effettivamente reali, tutta da dimostrare la corrispondenza con il nominativo immediatamente verificabile sono in pochissimi casi.

Google è tuo “amico”

Ho incrociato i risultati con qualche ricerca a livello web con qualche query strutturata e ne emerge che moltissimi dei dati riportati sono di fatto pubblici, in particolare i numeri di telefono.

Una delle conversazioni su RaidF.

Sommando tutte le informazioni è lecito pensare che questi data set siano stato costruiti ad arte con azioni di scraping, fenomeno che trovo estremamente interessante e da approfondire. Da un lato potrebbe essere il banale tentativo di truffare il truffatore vendendo un falso DB, ma è anche un interessante segnale di “rumore” che può mettere in allarme la vittima in una situazione complicata come quella del ricatto.

Personalmente questo modello mi incuriosisce molto e sarebbe interessante misurare quanti di questi falsi dati vengono scambiati. Interessante anche la facilità con cui è possibile costruire un falso DB verosimile.

In ogni caso questo tipo di scambi è bene monitorarli e soprattutto verificarli (mi sono stati segnalati fior di servizi giornalistici non proprio accurati) anche per comprendere come si è evoluto l’attacco. E’ un’analisi che aiuta a definire nuove strategie di difesa con l’obiettivo di ridurre il rischio e, dovendo comunque fare i conti con l’eventualità dell’attacco, imparare a gestirlo al meglio.

cyber security, hacking

Individuazione delle vulnerabilità: attacco e difesa (prima parte)

La gestione delle vulnerabilità è ovviamente un tema ricorrente nelle organizzazione che devono governare infrastrutture IT/OT/IoT dal punto di vista della sicurezza cibernetica. Tutte le componenti, tecnologiche e non, di una organizzazione sono di fatto potenziali target per attacchi atti a raccogliere informazioni o compromettere i sistemi, cosa che, nei contesti di produzione, metto a rischio il funzionamento dell’organizzazione ed in alcuni casi il prodotto stesso (gli smart device sono l’esempio più ovvio).

Negli ultimi giorni ho avuto modo di illustrare alcuni step di attacco ad un collega “temporaneo” (abbiamo “a bordo” un ragazzo in alternanza scuola lavoro con una sincera passione per la tecnologia e la cyber security) e nelle chiacchierate è emerso un elemento che ho visto spesso anche in molti menbri degli uffici IT, compreso il management: di fronte ad un nutrito set di bug e vulnerabilità individuate tramite una o più fonti – non sempre grazie ad una metodologia di gestione del rilevamento delle stesse – si tende al disordine: l’assenza di una procedura definita per la gestione delle vulnerabilità lascia spazio alla propria interpretazione / percezione del rischio e l’organizzazione, se reagisce, lo fa in modo disorganizzato.

Inevitabilmente si tende a correre ai ripari per quanto riguarda le vulnerabilità che sembrano essere quelle più critiche a prescindere dal contesto. E’ vero che le vulnerabilità che consentono lo sviluppo di un attacco diretto sono estremamente pericolose in quanto più semplici — di solito — da sfruttare, ma la contestualizzazione della vulnerabilità può cambiarne sensibilmente il rischio correlato: esporre un sistema con evidenti vulnerabilità che consentono l’esecuzione di codice da remoto (Remote Code Execution) è ovviamente un elemento che rende il target estremamente appetibile, ma se il contesto presenta uno strumento di filtering in grado di riconoscere e bloccare i tentativi di exploiting (come IDP/IPS a livello firewall o un sistema di anti-exploiting a bordo del server) le probabilità che la vulnerabilità sia sfruttabile si riducono enormemente.

Attenzione: si riducono, non svaniscono.

E’ necessario poter correlare una vulnerabilità ad un asset e di quell’asset dobbiamo conoscere il contesto operativo e l’impatto sul business dell’organizzazione.

Dobbiamo necessariamente fare i conti con la realtà ed accettare che non tutte le organizzazioni hanno modo di costruire in tempi rapidi una mappa dei business impact legati agli asset. Inoltre, come accennato, non tutti dispongono di procedure di gestione delle vulnerabilità. Il modello che vorrei quindi proporre in questa mini serie – ed è anche la tesi discussa con il giovanissimo collega – è di approcciare la cosa per gradi mettendoci nella situazione peggiore ma spesso reale di non disporre di un database degli asset e delle loro caratteristiche.

Nota: lo scenario non è in alcun modo da considerarsi sostitutivo alla predisposizione di un processo di asset management e relativi strumenti di gestione. L’obiettivo dell’articolo è ragionare assieme.

Come spesso scrivo nei post e racconto sia nei podcast che di persona, l’approccio dell’attacker è metodico e prevede la qualifica del target per comprendere se esiste una reale convenienza nello sferrare un attacco: costruire un’azione offensiva a scopo estorsione per colpire un piccolo studio professionale è molto diverso rispetto a ciò che comporta la progettazione dello stesso attacco con target una multi nazionale. Cambiano le economie dell’impresa (d’attacco), la possibile revenue, i tempi di realizzazione, ecc. Il modello prevede quindi l’analisi costo/benefici al fine di individuare un target appetibile.

Esistono diversi metodi per individuare target appetibili, uno di questi è legato alle tecnologie in uso dalle organizzazioni. Come avvenuto per recenti attacchi che hanno coinvolto migliaia di organizzazioni, l’attacker può utilizzare una falla nota presente in sistemi e piattaforme largamente utilizzate per costruire campagne di attacco anche massive ma con un vettore molto specifico.

In poche parole si tratta di analizzare le vulnerabilità note di tecnologie che il target utilizza a caccia della falla che potrebbe consentire un accesso ai sistemi in modo relativamente semplice. Ovviamente la quantità di vulnerabilità su cui eseguire questa analisi è enorme ed esistono database utilizzabili sia a fini offensivi che difensivi: di base dobbiamo acquisire un’informazione in relazione alla presenza di tecnologia, all’interno dell’organizzazione, che può essere sfruttata per un attacco informatico.

Esistono meravigliosi tools per verificare se parte del vostro asset presenta delle vulnerabilità critiche: se avete implementato una procedura di Patch Management e/o Vulnerability Management probabilmente subito dopo vi siete dotati di una soluzione software che vi aiuti a governare tale procedure; se avete acquisito la soluzione software ma non avete una procedura ufficiale per la gestione di questi processi, avete un problema di governance e vi suggerisco di affrontarlo rapidamente per non vanificare l’investimento fatto.

Visto che in questa sede parliamo di metodologia e non di tools (per i quali farete le vostre valutazioni) vediamo come possiamo entrare in possesso delle informazioni minime che ci servono per valutare se esiste un reale rischio per la sicurezza dell’organizzazione (se la vediamo dal punto di vista del team che deve difendere l’organizzazione) o una opportunità di business (se la vediamo dal punto di vista dell’attacker). Gli ingredienti sono:

  • elenco asset / tecnologie in uso presso il target
  • elenco vulnerabilità in riferimento alle tecnologie in uso
  • contesto di utilizzo della tecnologia vulnerabile

Partiamo leggeri, non censiamo subito gli asset ma preoccupiamoci almeno delle tecnologie in suo. Esiste una convenzione che ci aiuta a definire, in modo univoco, la tecnologia che stiamo utilizzando: si chiama CPE (Common Platform Enumeration). Senza dilungarmi troppo (di seguito qualche link per documentarvi) si tratta di un metodo standard per identificare uno specifico vendor/prodotto/versione/ecc…

Pagina dedicata di wikipedia: https://en.wikipedia.org/wiki/Common_Platform_Enumeration
Mitre specification: https://cpe.mitre.org/specification/

Un primo step potrebbe essere quindi quello di censire i CPE di riferimento per le tecnologie in uso nella nostra organizzazione: se utilizziamo una specifica versione di Microsoft Windows Vista, ma non ricordiamo esattamente l’update o altri parametri di dettaglio, potremmo annotare nella lista il CPE più generico:

cpe:2.3:o:microsoft:windows_vista:6.0:*:*:*:*:*:*:*

Ovviamente questo elenco dovrà essere mantenuto aggiornato, quindi la versione alpha della procedura di inventory delle CPE dovrà prevedere che ogni nuova tecnologia introdotta/individuata nell’organizzazione dovrà essere censita in questa repository.

Una volta gestito questo patrimonio di informazioni (utile per fare una montagna di altre attività virtuose) nel modo più automatizzato ed efficiente possibile, possiamo andare ad analizzare un altro dataset interessante ben più noto dei CPE, ovvero i CVE: Common Vulnerability Enumeration. Esistono diversi siti ed organizzazioni che mettono a disposizione un database con l’aggregato delle CVE rilasciate per i vendor, c’è l’imbarazzo della scelta. Per questo piccolo esperimento utilizziamo una API di https://cve.circl.lu/ che consente di richiedere le ultime 30 CVE pubblicate in formato json.

Esempio di lettura delle CVE tramite API

All’interno di una CVE trovate le informazioni sulla vulnerabilità compreso lo score e le CPE vulnerabili, ovvero l’elenco delle versioni software (talvolta in combinazione con specifici hardware) che presentano la vulnerabilità.

Siamo arrivati all’epilogo di questa prima parte di “avvio” dell’argomento che sintetizzo così: chiunque sia a conoscenza di una specifica applicazione in uso all’interno dell’organizzazione può identificare un potenziale set di vulnerabilità associate. Scopo di questa mini serie è discutere assieme le metodologie per rilevare e correggere le vulnerabilità prima che siano sfruttate. Nel prossimo post discutiamo una bozza di procedura e prendiamo in considerazione alcune tecniche di rilevamento (offensive e difensive) delle vulnerabilità.

cyber security, hacking

La filiera del crimine cibernetico

Alcuni modelli di attacco risultano estremamente efficaci grazie ad una sorta di filiera nell’industria del crimine cibernetico. Esiste, ad esempio, un mercato molto attivo per quanto riguarda database ricchi di anagrafiche con relativi dati personali come indirizzi email, credenziali, profili social, ecc… dati che per essere acquisiti richiedono di per se un attacco finalizzato al furto degli stessi e spesso “monetizzato” ricattando il target di divulgare le informazioni sottratte tramite il data breach a meno che non venga corrisposta una somma in crypto valuta.

Ma l’attacker non si limita alla richiesta di riscatto che, come le statistiche riportano, potrebbe anche non andare a segno. I dati sono infatti spesso messi in vendita su diversi portali nel Dark Web e non (ormai ci sono molti siti che, con meccanismi curiosi basati su “crediti”, consento di entrare in possesso di queste informazioni) o altri metodi più immediati come famosi gruppi e canali su Telegram e simili.

Acquisire un database con credenziali di milioni di utenti è, per ovvie ragioni, un ottimo punto di partenza per l’attacker che cerca nuove vittime: in base al proprio modello di attacco potrà selezionare organizzazioni per le quali possiede informazioni utili ad eseguire azioni offensive: avere a disposizione anagrafiche spesso accompagnate da credenziali personali e/o aziendali (anche se non aggiornate) di membri di un ente o di una azienda consente infatti la progettazione di attacchi molto efficaci. Le credenziali obsolete possono comunque essere utilizzate per campagne di phishing mirate tramite cui acquisire nuove informazioni o altri dati sensibili.

In questi casi, pur avendo provveduto all’introduzione di policies atte a ridurre enormemente il rischio di accessi non autorizzati alla rete tramite credenziali trafugate, si deve far fronte a tecniche di social engineering e phishing particolarmente insidiose: non stiamo parlando della solita email truffaldina che, si spera, gli utenti hanno imparato a riconoscere ed i sistemi di Email Filtering/Security sanno segnalare come “anomala”, il phishing mirato è decisamente più subdolo in quanto le comunicazioni, che possono avvenire via email o altri mezzi, sono costruite per essere verosimili. Non è raro l’utilizzo di informazioni reperite tramite tecniche di analisi come OSInt (tema in parte raccontato in questo podcast) o ricavate da quel tesoretto di dati trafugati tramite altri data breach ed acquistati spesso a prezzi anche molto bassi.

Nota: il “valore economico” dei dati provenienti da un data breach varia in virtù di molti parametri, non ultimo l’epoca a cui risale.

La strategia di difesa deve quindi tenere in considerazione il fatto che l’attacker potrebbe agire sulla base di informazioni anche molto dettagliate sul vostro conto, sia personali che del contesto lavorativo. Per capirci riporto un banale esempio di azione offensiva che mi è capitato di realizzare in occasione di un security test (ovviamente commissionato da una organizzazione che aveva l’esigenza di misurare il proprio grado di consapevolezza) dove è stata progettata una campagna di phishing verso uno specifico gruppo di utenti in riferimento ad una verifica di sicurezza del proprio account aziendale per una applicazione terza (in cloud) il cui utilizzo era emerso grazie alle analisi OSInt (nel caso specifico i record DNS davano evidenza specifica dell’utilizzo del servizio). L’azione, nella sua senplicità, riprendeva qualcosa di estremamente noto alle vittime ed i risultati hanno consentito di misurare il livello di esposizione ad una minaccia estremamente diffusa.

Esistono infinite sfumature che possono essere utilizzate in un attacco di phishing mirato ed è relativamente semplice aggirare o eludere meccanismi di protezione. Ad esempio l’utilizzo di email regolarmente registrare con provider di tutto rispetto: è raro che un indirizzo email opportunamente formattato sia considerato una minaccia (asdfgh88@da.ru è ben diverso da franca.rossi@protonmail.com). Inoltre l’email non è certo l’unico canale per innescare un dialogo. E’ sensibilmente aumentato l’utilizzo di tecniche di impersonation finalizzate alla raccolta di informazioni… e visto l’attuale contesto, in cui è praticamente impossibile incontrare persone o enti che non fanno uso di social network, è ovvio che le tecniche di social engineering siano sempre più utilizzate e risultino particolarmente efficaci.

Ed arriviamo al problema del percepito: si tende ad osservare la singola azione, la singola minaccia quando il tema va approcciato facendo dieci passi indietro per osservare il contesto nella sua interezza e complessità. Le singole azioni “chirurgiche” di mitigation e remediation, se non le contestualizziamo in un processo più ampio, rischiano di essere inefficaci. Non ha senso combattere le singole minacce una ad una — oggi il phishing, domani le vulnerabilità dei sistemi di perimetro, settimana prossima la gestione dei dati sensibili — ovvio che è sempre meglio di niente, ma questo è “agire a sentimento” (per non dire a caso) per combattere un avversario che ha strategie e tattiche ben definite e collaudate. Chi la spunterà?

Va costruita una strategia che prenda in esame come siamo fatti (come persone e come organizzazioni) che sia la base per definire azioni e tempi, con ordine e KPI misurabili. Va gestita questa cosa delle “sicurezza cibernetica”, con metodo.

Per quanto mi riguarda per capire il contesto dovete circondarvi di persone — consulenti, dipendenti… come vi pare — che lo hanno vissuto, che fanno parte del complesso e vasto mondo delle sicurezza cibernetica (sul versante etico e legale ovviamente ma bel consci di come sia fatto alche l’altro versante). Orientarsi in questo universo è indispensabile per prendere decisioni efficaci ed efficienti.

Da non dimenticare che le aziende operano in un contesto di mercato dove, solitamente, esiste una certa competizione: non ci si può permettere di non considerare il vantaggio competitivo nell’ottenere una postura di sicurezza migliore rispetto agli altri attori di mercato, è evidente la restituzione di valore in termini di qualità, affidabilità, resilienza. E’ un processo già avviato, probabilmente accelerato dall’attenzione (spesso maldestra a dir la verità) dei media, ma è ovvio che il cliente (prima di tutte le aziende ma lo stesso discorso vale per l’end user) comincerà a prediligere il fornitore più affidabile anche dal punto di vista della sicurezza cibernetica. Ne va del suo business.

cyber security, update

Il fenomeno del crimine informatico

E’ un tema su cui continuerò a scrivere e che probabilmente porterà a dovermi ripetere spesso, ma è necessario che il fenomeno venga compreso a livello di funzionamento e strategia prima di affrontare i temi tattici e tecnici. Inoltre è molto più facile per le figure dirigenziali comprendere i concetti strategici rispetto alle tematiche che coinvolgono l’ambito tecnologico… validissimo motivo per approfondire.

Per prima cosa dobbiamo comprendere lo scenario in cui stiamo operando e vivendo. Il luogo comune, del quale ancora fatichiamo a liberarci, vuole che “l’hacker cattivo” (espressione di per se impropria) sia un ragazzotto in felpa e cappuccio che dal suo scantinato riesce a tenere in scatto aziende, enti e persino governi.

Questo pensiero è il refuso di una visione distorta ed estremamente obsoleta del mondo digitale sul quale media e cinema hanno giocato per anni disinformando il pubblico e spesso anche gli addetti ai lavori. Se è vero che c’è stato un periodo in cui diversi appassionati di settore giocavano in rete facendo talvolta qualche danno è altrettanto vero che oggi il mondo del crimine informatico è composto da figure estremamente diverse ed è governato dal logiche di puro business.

Abbiamo quindi a che fare con figure mosse dal lucro ingaggiate o facenti parte di organizzazioni criminali, l’obiettivo degli attacchi informatici è principalmente quello di ricavarne un profitto diretto (con meccaniche di estorsione) o indiretto grazie all’utilizzo di informazioni trafugate che possano danneggiare il target.

E’ inoltre interessante analizzare le revenues di questo modello di business per comprendere su quali fronti il crimine informatico è più attivo. Una stima proposta tra il 2019 ed il 2020 da più studi tra cui Atlas parlava di un 1.500 miliardi di USD l’anno… quasi il PIL di un paese industrializzato.

Ancor più interessante è la ripartizione di questo business. Una considerevole fetta riguarda la compravendita illegale di beni online, ambito di analisi interessante ma che difficilmente va a danneggiare direttamente il business delle aziende. Il resto della torta è sostanzialmente diviso per tre parti: compravendita di dati, compravendita di informazioni riservate e caas/ransomware.

Questa fetta del “mercato” del crimine informatico si riferisce quindi a tutte quelle tipologie di attacco che hanno come obiettivo la compromissione ed il furto di dati o il danneggiamento di sistemi (quelli informatici quanto quelli industriali: in entrambi i casi è possibile chiedere un riscatto). E’ inoltre interessante constatare come gli attacchi che utilizzano la tecnica forse più nota e più discussa — i ransomware — rappresentino una relativamente piccola fetta del totale: “solo” 1 miliardo di USD l’anno. Eppure è un dato di fatto che una delle prime preoccupazioni degli interlocutori con cui abbiamo a che fare sono i ransomware. Evidentemente il fenomeno del crimine informatico è solo in minima parte percepito da chi è chiamato a gestire il tema, cosa che porta inevitabilmente ad esporsi a rischi di cui non si conosce la natura.

Viviamo in un contesto in cui chi attacca è spesso “ingaggiato” da gruppi criminali e lavora dietro compenso al fine di colpire target da cui poi trarre un facile profitto e i dati ci dicono che “loro” di cui i criminali informatici vanno a caccia sono le informazioni.

E chiudo con una riflessione sul modello opportunista (nel senso proprio del termine) che si osserva: è evidente che da un punto di vista economico l’attacco deve costare meno di quanto si ritiene di poter ricavare, altrimenti il modello non sta in piedi. Il target non è quindi selezionato a caso ma viene accuratamente scelto sulla base di parametri anche abbastanza ovvi come la capacità di sostenere un riscatto e la possibilità reale di poter compromettere l’operatività del target con l’attacco così da indurlo al compromesso del pagamento.

La diretta conseguenza di questo ragionamento è che le aziende che espongono superfici attaccabili particolarmente “morbide” — identificabili con specifiche tecniche di analisi — vengono selezionate come appetibili per il mercato del crimine informatico.

Uno dei nostri obiettivi, tra gli altri, è quello di non essere catalogabili come appetibili.

cyber security, hacking

Capacità di reagire: modi e tempi

Nelle ultime settimane ho avuto modo di osservare e riflettere sulla capacità, di organizzazioni ed aziende, di reagire a specifici eventi legati alla sicurezza informatica. In particolare ho preso in esame la reattività ad eventi di segnalazione di una minaccia e la reattività ad eventi di rilevamento di un incident.

i tratta di due casistiche molto diverse tra loro in quanto la prima genera (o dovrebbe generare) valutazioni di rischio ed eventuali azioni di prevenzione mentre la seconda innesca (o dovrebbe innescare) azioni di gestione dell’incident.

La percezione del rischio

Ciò che è chiaro è che non tutti percepiscono il rischio allo stesso modo: la segnalazione di una minaccia, per quanto contestualizzata, viene spesso qualificata secondo la propria percezione personale e soggettiva di quanto il rischio sia elevato. Non sempre viene eseguita una valutazione di merito sui dati a disposizione secondo criteri oggettivi.

Ve la ricordate questa, vero?

Un buon metodo, secondo la mia esperienza ovviamente, è quello di mettere a fattor comune dati oggettivi come lo score della minaccia / vulnerabilità (dato che è facilmente reperibile dai security bulletins che voi tutti controllate) con il coefficiente di impatto che l’asset ha nella vostra infrastruttura. Questo secondo dato, che effettivamente non tutti gestiscono, deriva da una valutazione che le organizzazioni devono fare per comprendere quanto un asset ha impatto sul proprio business (si, è la Business Impact Analysis). Per semplificare il dato che serve avere è un coefficiente che vi aiuti a comprendere quanto un certo asset (o gruppo di asset) è critico per il funzionamento della vostra organizzazione o di uno specifico servizio. Facciamo un esempio facile facile: quanto è critica la posta elettronica per la vostra azienda? O meglio: quanto del vostro business viene impattato da un fermo dei servizi di posta o da un data breach che impatta i servizi di posta? Sulla base di questa informazione oggettiva che l’IT assieme al Management deve definire sarà possibile dedurre l’impatto del servizio in oggetto.

Ora è più facile: se mi viene notificata una minaccia con score elevato (9/10 è elevato nel caso ci siano dubbi) che coinvolge un asset che è stato classificato di elevato impatto (secondo la scala che avete deciso di applicare)… bhe, c’è poco da dire, siete di fronte ad un rischio elevato e dovere intervenire a prescindere dalle vostre opinioni soggettive.

Nota: l’ho molto semplificata, l’obiettivo in questa sede è trasferire il concetto di obiettività della valutazione.

La qualifica dell’impatto

In un contesto di security incident ovviamente la faccenda è un po’ diversa: non si parla più di minaccia e rischio ma di impatti e conseguenze e ancora una volta torna utile avere una mappa di impatto per comprendere dove mettere le mani e che azioni intraprendere.

Non serve aver gestito security incident (tema su cui ho un po’ di esperienza) o averne subiti (tema su cui chi vuole può contribuire in forma anonima per condividere la propria esperienza) per comprendere come sia complesso prendere decisioni razionali durante un evento di questo tipo. Mettersi a qualificare l’impatto sulla base della propria comprensione dell’aziende e dell’infrastruttura ad incident in corso è qualcosa di poco proponibile. La qualifica dell’impatto deve essere snella e definibile su dati oggettivi come la valutazione di impatto dei sistemi coinvolti (che dovrebbe già esistere), la classificazione dei dati presente sui sistemi coinvolti (che dovrebbe già esistere), l’elenco delle risorse da coinvolgere in relazione ai sistemi/servizi impattati. Vietato improvvisare… o meglio, chi non ha dati oggettivi e si trova a dover improvvisare si espone a rischi elevatissimi.

Reazione

Arrivo al vero tema del post… la reazione in termini di tempi e modi. E’ ovvio che se non c’è una procedura per gestire un evento come un incident o una notifica di potenziale vulnerabilità dei sistemi i team interessati agiranno a propria discrezione: chi subito, chi quando ha tempo, chi mai. E’ inoltre ovvio che, anche nel caso di una reazione immediata, l’assenza di una procedura porta ad azioni a discrezione della singola persona la cui efficacia dipenderà dal grado di competenza e conoscenza del sistema e del contesto. Quindi si ottengono risultati apprezzabili o meno a seconda di chi opera. Non lo trovo uno scenario accettabile per un’organizzazione il cui business potrebbe essere pesantemente impattato da un security incident.

L’assenza di procedure a supporto di una reazione commisurata all’evento spesso porta con se l’assenza di una metodologia per la gestione di un evento di incident e, per ovvia ragioni, l’assenza di strumenti adeguati sia a livello di tools che a livello di skills specifiche.

Come sempre faccio degli esempi idioti ma molto reali: nel corso di azioni di mitigation può capitare di dover eseguire azioni con impatti su grandi quantità di sistemi come il cambio di una policy o un banale reset password di decine di server e apparati. Eseguire queste operazioni in 25 secondi grazie a procedure e strumenti già definiti o eseguirle in 4 ore a mano (con relative implicazioni legate al fattore umano) è ciò che può cambiare gli esiti e gli impatti dell’incident sul business. In alcuni casi basterebbero poche procedure ben strutturate e qualche script in python per ribaltare la situazione (voglio essere provocatorio ma non è un’affermazione così lontana dalla realtà).

Ciò che trovo paradossale è il fatto che in molte aziende trovo le tecnologie abilitanti ad una gestione virtuosa della sicurezza informatica ma spesso mancano i processi per una efficiente ed efficacie gestione del proprio patrimonio digitale. La domanda su cui riflettere che vi lascio per il week-end è: quanta tecnologia avete adottato senza una strategia di gestione e delle procedure dedicate?

cyber security

Schermaglie cibernetiche e strategie di difesa

Mentre leggo curiose reazioni di chi si stupisce — a distanza di due settimane — della portata dell’attacco globale che sta interessando i sistemi Microsoft Exchange (lo ripeto: era chiaro dopo cinque minuti che sarebbe stato un disastro ed in questo post spiegavo i motivi) osservo con interesse le mosse del governo USA ben illustrate in un recente post di Bechis su Formiche.Net in cui, sintetizzo ma consiglio la lettura, viene riportata l’intenzione del governo americano di far cooperare le agenzie governative con i grandi gruppi privati per potenziare la propria capacità di anticipare azioni di attacco come quelle in corso.

Il problema è chiaro: NSA, USCYBERCOM e compagnia briscola (e scusate se è poco) faticano a tenere il passo con attacchi di questa portata in “rapida” successione, non si è ancora chiusa la non banale questione SolarWinds e si rende necessario preoccuparsi anche di questa nuova campagna di attacchi ben più estesa. Sarà interessante osservare le prossime mosse dei grandi gruppi che, a quanto pare, non sono così propensi ad avviare questa collaborazione.

Ora osserviamo lo scenario: abbiamo il Presidente degli Stati Uniti d’America che si rende conto di avere fior di strumenti come le agenzie e forze armate con risorse dedicate alla sicurezza cibernetica, ma il perimetro interessato dagli attacchi ed i relativi impatti vanno ben oltre la capacità di prevenzione e gestione delle forze in gioco. La mossa interessante e che vorrei sottolineare è in relazione alla scelta strategica: “come la gestiamo Joe” gli avrà chiesto un membro dello staff, “dobbiamo potenziare l’intelligence coinvolgendo le big tech” avrà risposto il Presidente… o almeno è così che mi immagino io il dialogo.

Primo tema da analizzare: Biden punta dritto all’intelligence. Ovviamente ha la necessità di essere un passo avanti, deve poter prevenire le mosse del suo nemico e per farlo ha bisogno di informazioni da analizzare e correlare. Non posso non citare Sun Tzu (chi mi ha incrociato in ambito professionale si è beccato tutta la trattazione filosofica):

Sun Tzu, L’arte della guerra

Ovviamente, aggiungo, conoscere le strategie del proprio nemico non solo permetterebbe agli USA di organizzare una difesa efficace, darebbe anche qualche spunto su come colpire a loro volta. Sì, stiamo parlando di Guerra Cibernetica. E quale potrebbe essere un asset ricco di dati, con elevate capacità di analisi e dove si annidano figure professionali particolarmente abili nella gestione della sicurezza cibernetica? Domanda retorica.

Non affronto, in questo pezzo, il tema delle figure legate al mondo del hacking e del cracking (nelle sue varie forme) che nel tempo hanno collaborato con enti governativi. E’ un altro capitolo e non ci interessa ai fini della riflessione.

Proviamo ad imparare qualcosa da questo macro esempio di strategia: è poco plausibile mantenere il “vecchio” modello in cui corriamo ai ripari quando qualcosa non va e mettiamo presidi sulla base di ciò che sappiamo senza considerare che non possiamo sapere tutto.

È molto più efficacie ed efficiente, anche dal punto di vista della sostenibilità economica, analizzare quali sono i nostri punti deboli in funzione dell’impatto che avrebbe una minaccia cibernetica nel nostro modello di business e, sulla base di dati reali, valutare una strategia di difesa. Un’analisi della nostra superficie d’attacco affiancata alla verifica delle potenziali minacce che, in un reale contesto, farebbero breccia nella nostra organizzazione ci consentirebbe di valutare appropriate precauzioni.

Un passaggio ulteriore è mettere a frutto questo percorso che può portare valore non solo in termini di maggiore sicurezza della propria organizzazione ma anche come garanzia di affidabilità nei confronti di altre aziende e clienti. È banale: se a parità di prodotto / servizio ciò che la vostra organizzazione eroga viene accompagnato da una nota che ne attesta la robustezza secondo specifici test (ad esempio) o scelte tattiche ne otterrete un vantaggio competitivo.

Non so voi ma se devo sottoscrivere un servizio o acquistare un prodotto e mi trovo a dover scegliere tra più proposte equivalenti dal punto di vista funzionale ed economico, quella che mi da maggiori garanzie dal punto di vista dell’affidabilità e della resilienza è la proposta che vince.

Dedicate qualche minuto al tema del vantaggio competitivo, ci torno nel prossimo podcast.

cyber security, podcast

Sintesi cibernetica #10

Inizio la mia rubrichetta (fatemi sperimentare un po’) su ciò che questa settimana ha calamitato la mia attenzione nel mondo cibernetico, ammesso che ci sia una qualche reale differenza rispetto al mondo fisico.

Lo 0-Day su Exchange ve lo siete già dimenticati tutti ma in realtà il tema è tutt’altro che chiuso e mi aspetto torni alla ribalta nel giro di qualche settimana. L’innesco è della settimana #9 e, oltre ad aver registrato una reattività non proprio eccellente da parte degli utilizzatori di questa piattaforma, i movimenti relativi alle vulnerabilità segnalate sono datati gennaio 2021 da diversi analisti. Ovviamente spero di sbagliarmi ma c’è la seria possibilità che fra qualche settimana vedremo gli effetti delle azioni di attacco in corso per mano di vari gruppi di criminali cibernetici.

Il tema della settimana è stato in realtà l’incendio che ha interessato il campus Datacenter di OVH a Strasburgo. Una delle quattro sale è andata completamente distrutta nella notte tra il 9 e 10 marzo, un’altra sala è stata in parte danneggiata. Tutto il sito è ovviamente stato spento per consentire le operazioni di verifica, pulizia e ripristino di ciò che si potrà accendere, ipostenicamente in settimana #12 come OVH stessa riporta sul proprio sito al seguente link: https://www.ovh.it/news/press/cpl1785.incendio-nel-dataceneter-strasburgo

L’evento è sicuramente qualcosa di eccezionale e le indagini chiariranno cosa è effettivamente accaduto considerando che questo tipo di installazioni sono tipicamente molto ben progettate e presidiate anche se in questo caso potrebbero esserci stati elementi o scelte architetturali un po’ datate. Per ora si possono fare solo supposizioni e speculazioni, cosa che personalmente eviterei fino a quando non ci saranno dei dati da analizzare e delle dichiarazioni da parte di OVH stessa che, proprio oggi, ha iniziato ha fornire qualche dettaglio sull’incidente che parrebbe essere stato causato da un guasto ad un UPS.

L’impatto è devastante: quattro sale spente di quella dimensione generano ripercussioni su migliaia di aziende e non saprei calcolale quanti utenti. Non si tratta semplicemente di avere dei siti web non disponibili, i Datacenter in oggetto ospitavano diversi sistemi e applicativi, oltre che molti archivi di dati al momento non disponibili. Per alcuni di questi archivi vi è la seria possibilità che non siano recuperabili.

Quasi tutti i commenti che ho letto ed ascoltato hanno il sapore del monito verso chi eroga servizi Datacenter o verso i clienti che ritengono di non aver bisogno di un Disaster Recovery. Propongo in alternativa una riflessione in relazione alla livello di dipendenza che abbiamo costruito nei confronti di una serie di tecnologie di cui generalmente non sappiamo nulla. Personalmente comincio a vedere delle debolezze nel paradigma dell’accessibilità alla tecnologie a prescindere da una consapevolezza di base, una sorta di livello minimo di cultura necessario per accedere ad una tecnologia di questo tipo. Soprattutto per chi ha poi intenzione di fare del business tramite questa tecnologia.

Ora l’evento in se è forse anche troppo estremo, ma i disservizi esistono anche nei migliori Service Provider che siano di qualche minuto, di qualche ora o di giorni interi come in questo caso. E’ qualcosa di cui bisogna essere consapevoli e solo quando ci sarà questa consapevolezza di base si potranno fare valutazioni di merito su temi tattici come i piani di recovery, la ridondanza geografica e tutto quello che volete metterci dentro.

Ultimo tema che mi ha interessato, un po’ in ritardo in realtà perché la notizia è della settimana #9, è la prossima missione che vedrà coinvolta Samantha Cristoforetti nel 2022. Da qualche tempo ho iniziato a seguire le evoluzioni tecnologie che ci stanno permettendo di avviare una nuova era di esplorazioni spaziali e, giusto per restare allineato al mio modo di approcciare la scienza e la tecnologia, ho iniziato a ragionare sulle implicazioni di un compromissione delle infrastrutture a supporto delle missioni spaziali e, più in generale, al tema della sicurezza cibernetica in uno scenario che vede l’umanità impegnata nell’esplorazione del sistema solare e nella colonizzazione di Marte. Una riflessione che è bene iniziare con largo anticipo.

cyber security

Competenza ed addestramento

Provo ad affrontare un tema che mi sta a cuore e per il quale sarà inevitabilmente necessario fare delle integrazioni al mio ragionamento, spero coinvolgendo proprio quelle figure che oltre ad essere competenti sono anche addestrate o desiderano esserlo.

“Credit: Venitas”

Mi limiterò, in questo post, alla mia area di competenza (appunto), ovvero la sicurezza informatica ed in particolare il tema della Difesa dalle minacce cyber che in un certo senso significa essere pronti alla gestione della minaccia, prevenirla, e combatterla in caso dovesse manifestarsi con un attacco.

Il ragionamento ha a che fare con l’abisso che esiste tra una figura professionale competente, che è già di per se una cosa non banale in quanto è conoscenza ed esperienza assieme (passatemi la semplificazione), ed una figura professionale addestrata. Non si tratta di temi da contrapporre, una persona addestrata su un particolare tema deve necessariamente essere competente, deve padroneggiare la conoscenza della materia. Non tutte le persone competenti sono addestrate, questo può diventare un problema.

Spostiamoci dalla filosofia al mondo vero e per semplicità partiamo dell’ambito prettamente informatico anche se il ragionamento deve essere trasversale.

Nota: circoscrivere la cyber security solo ai temi IT è un grave errore, ne parlerò in prossime occasioni.

Nel mio lavoro (mi occupo di aiutare le organizzazioni a costruire una strategia di difesa dalle minacce cibernetiche, al secolo i Cyber Attack) incontro moltissime persone competenti, persone estremamente in gamba, con anni di esperienza nel loro campo. Molto spesso queste persone, che vantano hard skills fenomenali, non sono addestrate a gestire una minaccia informatica, banalmente perché non sono nella condizione (fortunatamente per le loro organizzazioni) di passare da un security incident all’altro. E’ un tipo di esperienza che, chi ricopre ruoli di gestione tecnica e governance in ambito IT e Security, tipicamente non fa fino a quando l’incident si verifica.

Essere o non essere preparati, addestrati, fa tutta la differenza. Un percorso di addestramento per le figure chiamate a gestire la sicurezza informatica di una organizzazione è ciò che consentirà a quell’organizzazione di avere delle procedure di gestione degli incident, avere personale addestrato a reagire in modo corretto, avere una rete di contatti da coinvolgere in base all’esigenza… e mille altre “armi” di prevenzione e gestione. Non essere addestrati alla battaglia, l’ho visto mille volte, genererà panico.

Nota operativa:
Ci sono diversi gradi di “addestramento” che possono essere presi in considerazione dai team in base alle peculiarità del team stesso, personalmente — lavorando per lo più in ambito offensivo — mi sono occupato di addestrare Blue Team e strutture di presidio, come i SOC, per migliorare le procedure di difesa o per imparare a gestire casi reali tramite simulazioni di attacco. Questo è un esempio di addestramento di carattere tecnico, ma lo stesso lavoro può essere fatto per la consapevolezza o per la visione strategica.

Ora, visto che siamo sempre nel mondo vero, è difficile essere sempre nella condizione di avere un team competente ed addestrato su tutti i fronti, non vuole essere questo il messaggio banalmente perché potrebbe non essere economicamente conveniente avere un Cyber Security Team “completo” all’interno dell’organizzazione. Come in passate occasioni il suggerimento è di ragionare su come l’addestramento dei vari team operativi possa rendere efficiente ed efficace la gestione della sicurezza informatica in ottica di investimento qualitativo.

È un cambio di paradigma: da costo necessario ad investimento in aumento della qualità. Un investimento che deve necessariamente essere letto come un incremento dei presidi di sicurezza tanto quanto un aumento di valore dell’organizzazione che dovrà diventare sempre più anti-fragile e garantire livelli di servizio appropriati ai propri clienti e partner.

cyber security, hacking, update

Armamenti Cibernetici

WarGames (1983)

Da qualche giorno ho iniziato a riflettere su un tema etico che interessa tutto il mondo della ricerca scientifica in — credo — tutti i campi: la possibilità che il proprio lavoro sia trasformato in un’arma.

Siamo tutti consapevoli del fatto che la ricerca nel campo della sicurezza offensiva sviluppa competenze, tecniche e strumenti che possono essere / sono utilizzati anche dal mondo del crimine organizzato. E’ un tema con cui conviviamo da sempre e chi opera in questo settore sa quanto siano necessari questi strumenti per supportare le organizzazioni nello sviluppo di una strategia di difesa efficacie.

La riflessione che vorrei proporre è un’altra e va in una direzione assolutamente legale, mi riferisco all’evidente crescente esigenza delle organizzazioni governatore e militari di ricorrere all’impiego di “armi cibernetiche” per perseguire i propri scopi istituzionali. E’ un capitolo immenso di una storia che è appena agli inizi, ma non ha senso ignorarla.

Ragionando mi sono posto mille domande di cui di seguito alcune:

  • Le organizzazioni interessate a sviluppare delle strategia di difesa che comprendano l’uso di armi cibernetiche si attrezzeranno in autonomia o valuteranno collaborazioni con aziende e consulenti esterni? (preso atto del fatto che la materia è ad oggi padroneggiata per lo più da realtà private)
  • Si paleserà un mercato “aperto” di armi cibernetiche così come oggi esiste un mercato che vede protagonisti grandi gruppi industriali che producono armi “tradizionali”?
  • Le competenze e l’addestramento dei “soldati” e degli “operatori” chiamati ad utilizzare queste armi da chi sarà portato avanti? (tenendo in considerazione le verticalità dei temi e delle relative figura professionali)

Lungi da me fare la morale, non è il mio ruolo e non è mio interesse, ma un invito a riflettere mi sembra quanto meno opportuno. Tutti i ricercatori ed i professionisti che operano nel campo della sicurezza informatica sono potenzialmente interessati in prima persona, meglio avere le idee chiare per evitare di fare scelte azzardate, qualsiasi sia la direzione che si desidera prendere.