Blog

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?

podcast

Sintesi cibernetica #12

Ancora una volta una riflessione che parte dall’incidente di OVH: sono andato a cercare i video con le dichiarazioni di Octave Klaba, fondatore di OVH, in cui, pochi giorni dopo l’ormai famoso incendio, dice:

It seems that globally, the customers … understand what we are delivering, but some customers, they don’t understand what exactly they bought

Considerando la dichiarazione nel suo contesto (qui in parte sintetizzato e spiegato) è chiaro il riferimento al fiume di critiche verso OVH in relazione al non disporre di un piano di Disaster Recovery. In realtà, come è ovvio che sia, è onere dei clienti sottoscrivere servizi di Disaster Recovery e dotarsi di una procedura di attuazione del piano. La frase azzeccatissima di Klaba sulla “non comprensione di cosa esattamente hanno acquistato” può sembrare un po’ cruda ma è tremendamente vera.

La vicenda aiuta a portare alla luce un dato preoccupante: molte organizzazioni ed aziende, anche non piccole come abbiamo visto, stanno affrontando l’era dell’informazione senza una strategia che sia in grado di tutelare il loro business. L’esigenza di una strategia di Disaster Recovery, l’esigenza di un piano per la gestione della sicurezza cibernetica o per la tutela delle informazioni strategiche, è qualcosa che ci si aspetta dal management. I team operativi si possono poi occupare di come implementare queste strategie. Conviene uscire dal modello in cui tutto ciò che è digitale è a carico dell’IT, non è più vero da anni e le conseguenze di queste antiche credenze oggi finiscono sui giornali.

Passo dalla ramanzina ad un tema virtuoso: il crescente interesse da parte dei produttori tecnologia IoT nel rendere i propri device sicuri. L’argomento mi sta particolarmente a cuore occupandomi principalmente di sicurezza informatica e mi ha fatto molto piacere osservare che alcune realtà si stanno concretamente muovendo per approcciare un percorso che le aiuti a produrre device safe and secure.

Il problema ha radici profonde: la pervasività di questi device è un fatto relativamente recete ed i loro utilizzatori non necessariamente hanno maturato una consapevolezza in relazione al livello di sicurezza di oggetti come gli smart device per uso domestico o i sistemi di automazione industriale con i loro sensori, rilevatori ed attuatori.

Ad un certo punto abbiamo semplicemente iniziato ad introdurre nelle nostre vite e nelle nostre aziende oggetti in gradi di dialogare tra loro attraverso reti locali ed attraverso la rete internet. Chi ha progettato le prime generazioni di questi meravigliosi device non era sempre al corrente del contesto e delle minacce che possono essere veicolate attraverso la rete ed ha di fatto prodotti oggetti safe ma non secure.

L’epilogo è noto: il mondo del crimine organizzato ha iniziato ad utilizzare lo strumento degli attacchi informatici per mettere in scacco aziende ed organizzazioni.

Diventa quindi necessario portare la cultura della sicurezza informatica in un mondo che non parlava questa lingua… con l’aggravante che anche chi dovrebbe parlarla ancora oggi fatica a tenere il passo nei confronti delle sempre molto aggiornate tecniche e tattiche di attacco.

Qualche spunto di riflessione nel podcast di domani (29 marzo).

hacking

Esperimento podcast

La riflessione che mi ha portato a valutare il podcast è che non tutti hanno il tempo di leggersi con calma uno o più articoli anche se molto corti. E’ un tema di contesto: chi si sposta con un mezzo pubblico potrebbe facilmente ritagliarsi uno spazio quotidiano di aggiornamento sul tema di interesse, mentre chi abitualmente utilizza l’auto ha dei vincoli oggettivi e deve eventualmente definire uno spazio di lettura in un momento che probabilmente è già allocato dalle attività del day-by-day.

Ho quindi pensato di proporre un podcast partendo direttamente con una rubrica settimanale, che ho chiamato Sintesi Cibernetica, spazio di 7-10 minuti dedicato a pochi temi che hanno catturato la mia attenzione nel corso delle settimana appena trascorsa.

Inizialmente avevo valutato un’uscita il venerdì pomeriggio per poi passare alla domenica. Un mix di cause hanno portato al cambio di giornata: vorrei essere costante ed il venerdì non è sempre un giorno semplice, inoltre ho avuto la sensazione ci fosse una bassa propensione all’attenzione. La domenica è diventato il giorno ufficiale e dopo i primi due episodi mi sento di confermarlo.

Primi feedback: contenuti buoni, tono di voce troppo basso. Altri suggerimenti spaziano dal mettere un sottofondo musicale al creare una sigla standard. Devo rifletterci un po’ su, non amo particolarmente la sovrastruttura in un progetto che ha come l’informare al fine di avviare delle riflessioni in chi vi si imbatte.

Oggi la terza puntata. Devo selezionare i temi.

hacking

Dove la rete satellitare “tocca” Internet

Come avevo accennato in un podcast di qualche giorno fa, uno dei temi di ricerca che sto portando avanti ha a che fare con le comunicazioni satellitari, o per meglio dire riguarda le tecnologie che ci consentono di comunicare con e tramite i sistemi satellitari.

Potrebbe sembrare un tema distante ma in questa epoca storica è in corso una vera e propria rivoluzione in merito a ciò che stiamo mandando in orbita bassa e a come possiamo utilizzare questi oggetti. Qualche nota di contestualizzazione è doverosa per comprendere il tema.

Scenario

Per prima cosa va detto che i satelliti moderni posso essere anche molto piccoli: esistono diverse aziende che producono e lanciano mini satelliti delle dimensioni di pochi centimetri ed equipaggiati con non poca tecnologia per la rilevazione e la comunicazione a terra (personalmente seguo il progetto CubeSat nato presso l’Università Politecnica della California). Parallelamente grazie a progetti come il celeberrimo SpaceX (e ne stanno arrivando altri) i costi per mandare asset in orbita si stanno riducendo enormemente.

L’ovvia conseguenza è un aumento del “traffico” in orbita bassa, ovvero in quella regione attorno al nostro pianeta in cui vengono tipicamente collocate le costellazioni di satelliti per le comunicazioni, il tracciamento della posizione e rilevamenti di ogni tipo, per uso civile, commerciale e militare.

Da quando i satelliti sono diventati uno strumento anche ad uso civile, se un’azienda ha bisogno di eseguire un determinato tipo di rilevamento o deve comunicare, ad esempio, con la propria flotta navale/aerea/stellare (Starfleet, cit.) si può rivolgere ad un ente che si occupa di lanciare e gestire i propri satelliti tramite cui eroga un servizio e, nei limiti della tecnologia e degli strumenti disponibili, l’azienda cliente è messa in condizione di fruire dei servizi offerti.

Il nuovo modello che sta emergendo frammenta ulteriormente le competenze, consentendo — per come la vedo io — un miglioramento in termini di usabilità ed accesso a questo tipo di tecnologia. Il modello si presenta più o meno così:

  • chi ne capisce di satelliti si dedica alla progettazione e realizzazione di strumenti ricchi di tecnologia ma molto piccoli e leggeri
  • chi ne capisce di razzi e vettori si dedica a progettare ed implementare un servizio di trasporto in orbita bassa
  • chi ne capisce di telecomunicazioni si dedica a costruire una rete di comunicazione satellitare che sia in grado di dialogare con molte tipologie di satellite e mette a disposizione le interfacce

A questo punto le aziende il cui modello di business dipende o sfrutta una tecnologia che necessita di una rete satellitare possono rivolgersi ad una serie di interlocutori specializzati che gli consentiranno di acquisire una tecnologia come i CubeSat, di spararla in orbita e di collegarla a sistemi a terra che consentano l’accesso ai dati/servizi di cui hanno bisogno, senza doverti preoccupare dell’immensa infrastruttura che c’è dietro e con investimenti molto inferiori rispetto a solo 10 anni fa.

Un bel tassello di questo complesso puzzle lo mette a disposizione Amazon con il servizio AWS Ground Station che da la possibilità ad un’azienda di interconnettere un proprio satellite alle “stazioni a terra” di Amazon che gestiranno la comunicazione con l’orbita bassa. Inoltre il servizio mette a disposizione gli strumenti per collezionare i dati ed eseguire le eventuali analisi. Anche su questo fronte credo si possa ipotizzare che Amazon non sarà certo l’unica a muoversi in questo campo.

Dal punto di vista del White Hat

Premetto che questo tipo di tecnologia mi affascina enormemente, tanto quanto mi affascina l’hacking, la fisica e l’esplorazione spaziale. Sono frontiere che vengono quotidianamente abbattute, sono nuovo opportunità per la specie se sapremo utilizzarle.

Chi lavora e fa ricerca nel campo della sicurezza cibernetica e ha un po’ di esperienza, al solo pensiero di prendere un oggetto che orbita attorno al pianeta e che rileva dati potenzialmente molto delicati e metterlo in comunicazione, seppur tramite più layer fisici e logici, con la rete internet attraverso un servizio cloud… probabilmente è svenuto prima di aver letto tutta la frase.

Non c’è nulla di sbagliato nelle intenzioni, esiste però qualche trilione di fattori da considerare per implementare e renderle fruibili queste infrastrutture in modo sicuro. Qualche tempo fa ho azzardato una previsione — non ricordo se l’ho scritta o detta — in relazione ai sistemi di comunicazione satellitare identificando come potenziale punto debole la Ground Station. Prendendo visione di come si stanno rendendo accessibili queste tecnologie mi viene qualche dubbio anche sulle possibilità di configurazione ed integrazione delle piattaforme cloud, non per fattori legati alla tecnologia, bensì in riferimento alla capacità di costruire adeguate policy di sicurezza.

Lo scenario e così complesso e la tecnologia così potente da richiedere una riflessione subito, ben prima che diventi qualcosa di largamente utilizzato. A questo tema sicuramente dedicherò qualche laboratorio di approfondimento e ne parlerò nei prossimi podcast. Mi piacerebbe sentire la campana di qualcuno del settore aerospaziale (militare e/o civile).

podcast

Sintesi cibernetica #11

Gestire un incident, che si tratti di un fault, un attacco o un malfunzionamento di un sistema critico, è una pratica che richiede elevate competenze tecniche ed una buona dose di sangue freddo. Non bisogna solo sapere ciò che c’è da fare, bisogna anche sapere perché va fatto in un modo specifico, applicando “quella procedura” e non “l’altra”. Serve esperienza e pratica acquisibile grazie a tecniche come l’addestramento. Improvvisare non aiuta, anzi, si rischia di trasformare l’incidente in un disastro.

Bisogna anche rendersi conto che esistono situazione che non sono ripristinabili, nel senso che non esiste il processo che annulla quanto accaduto, è però possibile, con la giusta strategia, ricostruire e ripartire.

La settimana appena trascorsa ha dato diversi spunti di riflessione sulla gestione degli incident, in particolare OVH è alle prese con le prime ripartenze ma a quanto pare ieri (20 marzo) i sistemi sono stati nuovamente spenti a causa di un principio di incendio in uno del locali dove erano posizionate delle batterie UPS in quel momento non operative. La prossima settimana doveva essere quella dell’accensione dei sistemi ma questo nuovo incidente rischia di generare nuovi ritardi.

La vicenda OVH va seguita lasciando da parte il pensiero critico, è una scuola per tutti coloro che lavorano nel campo delle infrastrutture ad alta disponibilità di servizio. Osserviamo ed impariamo dagli errori tanto quanto dai successi… e consiglio di partire proprio dalle scelte comunicative che CEO che in prima persona aggiorna gli utenti tramite Twiter: https://twitter.com/olesovhcom.

Su Exchange non dico nulla se non di stare in campana, questa settimana si è parlato di DearCry, un crypto malware in grado di sfruttare la vulnerabilità ProxyLogon… evidentemente in molto stanno cercando una scusa per lanciare qualche job di restore dei dati.

Nuovi interessanti movimenti li ho trovati sul fronte SolarWinds, a distanza di settimane si sono osservate delle ingegnose tecniche per guadagnare un accesso permanente alle mailbox Office 365 di alcune delle aziende interessate dall’attacco (miglia di aziende). La tecniche è spiegata in questo articolo ed è molto semplice: l’attacker utilizza credenziali legittime, ovviamente sottratte tramite l’attacco già in corso, per eseguire una modifica alla configurazione delle mailbox rendendole accessibili in read-only. Silenziosi ed efficaci.

Qualche riflessione in più sul podcast.

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.

hacking

Exchange 0-day, una settimana dopo

Mi ero ripromesso di dedicare qualche minuto ad un approfondimento su quanto accaduto dopo la pubblicazione del post del CSIRT ed aver atteso una settimana ha consentito di considerare diversi eventi e di approfondire alcune analisi così da elaborare qualche considerazioni su una situazione che, a parer mio, è tutt’altro che risolta.

I fatti sono noti a tutti: il 03 marzo viene annunciato da tutti i siti di settore che è stato individuato un attacco 0-day in grado di sfruttare una serie di vulnerabilità di Microsoft Exchange (2013, 2016, 2019) con l’obiettivo di compromettere il sistema e, potenzialmente, rubare informazioni sensibili come il contenuto della posta elettronica del server attaccato.

Come ho scritto in un post poco dopo l’annuncio, si è trattato della “ricetta perfetta”: Exchange è largamente utilizzato da aziende medie e grandi, le vulnerabilità sono sfruttabili da remoto se il sistema espone funzionalità fruibili via https (cosa che ovviamente fanno tutti) e l’annuncio parlava di 0-day, non solo di vulnerabilità… quindi doveva essere chiaro che l’attacco era già cominciato.

Un post interessante lo trovate sul blog di FireEye dove vengono illustrati alcuni comportamenti osservati già da gennaio 2021 in relazione alle vulnerabilità CVE-2021–26855 e CVE-2021–26858. Le attività analizzate si riferivano allo sfruttamento delle vulnerabilità per il posizionamento di una web shell sul sistema target.

Quello che di fatto abbiamo osservato è che la fase “1” dell’attacco, relativa all’exploiting atto al posizionamento della web shell, era già in corso e sono certo che molti di quelli che si sono apprestati ad installare le patch suggerite da Microsoft hanno potuto verificare la presenza della web shell nel path c:\inetpub\wwwroot\apsnet_client\ del sistema Exchange sotto forma di file *.aspx; nel seguente repo di GitHub è stato riportato un elenco di possibili nomi dei file che vengono caricati attribuiti ad una famosa web shell nota con il nome di China Chopper.

Note: questo potrebbe dar sostanza ai sospetti di Microsoft stessa sul gruppo responsabile di questa campagna di attacchi che si ritiene essere HAFNIUM.

La prima doverosa nota tecnica si riferisce al comportamento dei firewall che tipicamente vengono configurati con un NAT per esporre i servizi di Exchange: molti firewall sono in grado di rilevare specifiche minacce grazie alle funzionalità di inspection, ma nel caso specifico l’azione avviene all’interno di una sessione HTTPS e quindi, a meno che il Firewall o il WAF non sia configurato per eseguire attività di SSL decryption, resta assolutamente invisibile al sistema di presidio del perimetro esterno.

Una volta portata a termine la prima fase dell’attacco, avendo a disposizione una web shell ricca di funzionalità, l’attacker è in grado di tentare ulteriori azioni anche contando sulla presenza delle altre vulnerabilità rese note nello stesso contesto (CVE-2021–26857 utilizzata per eseguire codice arbitrario sul sistema con utente SYSTEM e CVE-2021–27065 utilizzata per la scrittura arbitraria di file sul file system del server Exchange).

Nel caso specifico ciò che avviene è un tentativo di garantirsi un accesso persistente al sistema (il mio Red Team ha intercettato l’installazione di DLL e la registrazione di servizi al fine di garantire il dialogo persistente verso il server di Command and Control) e successive azioni che puntano al furto delle informazioni contenute nel sistema con particolare riferimento ai dati in memoria gestiti dal processo LSASS (quindi anche le credenziali) ed i dati presenti sul file system (le mailbox).

Le evoluzioni di questi comportamenti sono presentate anche in un post di Microsoft che è stato via via aggiornato e che da qualche spunto interessante.

Sulle azioni successive al primo exploit ci sono ulteriori elementi di analisi che possono essere utili ad una detection e mitigation dell’attacco. In particolare le attività che portano ad un dialogo verso il C2 server possono essere intercettate dai firewall che mettono a disposizione specifiche funzionalità di verifica del traffico e delle destinazioni. Una certa reattività potremmo aspettarcela anche dai sistemi di anti-exploiting di cui, spero, tutti facciate uso anche se, devo essere onesto, i rilevamenti fatti mi hanno lasciato perplesso su quest’ultimo fronte.

Per chiudere qualche suggerimento (banale ma doveroso):

  • Non avere ancora installato i fix? Mi complimento per il coraggio… fateli ma mettete anche in conto una bonifica del sistema.
  • Avete versioni precedenti di Exchange? Avete un problema ben peggiore perché state utilizzando un sistema end of support per gestire un asset fondamentale per la vostra organizzazione.
  • Avete applicato i fix subito dopo gli annunci? Bene, assicuratevi che il primo exploit non sia stato lanciato e verificate il traffico del vostro Exchange server sul firewall.
  • Precauzionalmente eseguite un cambio password del Domain Admin (due volte) e, già che ci siete, forzate un cambio password all’utenza.

Come sempre mi piacerebbe confrontarmi con chi si trova a gestire il problema all’interno delle organizzazioni. Ogni vostro contributo è prezioso alla community.

hacking

Punti di vista

Premetto che in questo pezzo vorrei far cadere qualche tabù, temi che tutti conosciamo bene ma che talvolta causano un po’ di imbarazzo. Mettiamolo da parte e guardiamoci serenamente in faccia… siamo tra professionisti.

Parte della mia ricerca in relazione allo studio delle tecniche di attacco è focalizzata sulla “percezione di sé”, ovvero come ognuno di noi interpreta la propria realtà. Quando osserviamo il nostro contesto abbiamo una percezione parziale di ciò che esiste dettata da molteplici aspetti: la nostra capacità di osservazione, il nostro grado di conoscenza del contesto, le nostre competenze… ma anche le nostre abitudini, la nostra esperienza, la nostra scala di valori. Analizzarsi è complesso e, pur non essendo impossibile, è estremamente inefficiente. Diventa più sensato, ritengo quasi in tutti i casi, sfruttare un punto di vista terzo e possibilmente non interessato, indipendente, agnostico. Su questo assunto ho basato parte del mio approccio in tema di gestione della sicurezza cibernetica delle organizzazioni.

Il punto di vista dell’organizzazione (del team IT di solito, ma in generale di chi ha ruoli di responsabilità) da solo non basta: è limitato a ciò che si conosce di sé e difficilmente è oggettivo, o quanto meno al sottoscritto non è ancora capitato di leggere un’analisi auto-prodotta oggettiva negli ultimi 20 anni.

Il punto di vista di chi vende, implementa e gestisce soluzioni (indispensabili, non lo dirò mai abbastanza) non è sufficiente a superare il traguardo dell’obiettività in quanto esiste un interesse specifico, soprattutto da parte dei vendor che producono soluzioni tecnologiche, di vendere la propria tecnologia.

Nota sui vendor: non me ne vogliate, fate cose meravigliose e ogni giorno che passa non mancano novità strabilianti, ma è un dato di fatto che ognuno porta la propria bandiera a prescindere da tutto… non ho mai visto un vendor non dire “la mia soluzione è quella migliore”. Non è una critica, è un dato di fatto, teniamolo in considerazione.

L’elemento terzo, indipendente e non legato ad interessi specifici, diventa necessario per portare un punto di vista disinteressato, o meglio, interessato ad un miglioramento della postura dell’organizzazione in tema di sicurezza cibernetica, a prescindere dal logo delle soluzioni che l’azienda vorrà adottare e dalla posizione dei team interni. L’obiettivo è migliorare e transita necessariamente per un cambiamento, fattore che tende a spaventare molto.

Dobbiamo scrollarci di dosso un po’ di paura. Dobbiamo voler cambiare. A chi leggerà queste quattro righe chiedo di fare una riflessione e, per chi lo vorrà, si potrebbe anche organizzare una chiacchierata tra attori interessati al tema.

hacking

L’approccio che genera competenza che genera valore

Ho avuto un giro di incontri e dialoghi fortunati (virtuali ovviamente): in tre occasioni, a distanza di pochi giorni, ho potuto discutere con altrettanti manager e figure di responsabilità di tre aziende molto strutturate — dimensioni oserei dire “ginormiche” — in merito alla gestione della sicurezza cibernetica all’interno del processo creativo e produttivo.

(Credit: Kahveci)

Nonostante le differenze a livello di modello di business e di mercato (il comune denominatore è la realizzazione di device interconnessi) delle tre organizzazioni il tema era sostanzialmente lo stesso e ruotava attorno alla stessa domanda: come si può implementare un modello di sviluppo che dia delle garanzie sulla sicurezza del prodotto finale dal punto di vista dell’esposizione alle minacce cibernetiche?

La portata del tema, credo sia chiaro, è immensa… è ovvio che le garanzie sulla sicurezza dei device (per lo più IoT in questo caso) che si connettono alle reti domestiche ed aziendali diventeranno un termine di paragone per l’utenza che ne dovrà valutare l’acquisto e l’impiego, su questo credo non ci siano dubbi.
La mia riflessione è però relativa ad un altra questione: è meritevole di attenzione l’approccio che le organizzazioni adotteranno per avviare un processo di crescita virtuoso che parta dalle fondamenta delle organizzazioni stesse, dalle persone.

Le persone, oltre ad essere il propulsore delle organizzazioni, sono anche parte della “miscela propulsiva” con le loro idee e le loro attitudini. Un corretto approccio alla gestione della sicurezza informatica, maturato all’interno di un percorso di consapevolezza, è ciò che potrebbe portare i componenti delle organizzazioni a farsi delle domande sul modo in cui agiscono (nel privato come in un contesto lavorativo), sulle procedure che seguono (e che non seguono), sul design di una soluzione, sugli impatti di una scelta strategica.

Mettere in discussione il modello corrente, individuandone e correggendone le falle, è ciò che consentirà alle organizzazioni di crescere. Se questo percorso viene indotto coinvolgendo gli interessati, ovvero i creatori e gli utilizzatori del “modello corrente”, non solo vi sarà l’opportunità di migliorare il modello ma si potrà instillare nei membri dell’organizzazione la capacità di mettere in discussione i modelli in uso al fine di migliorarli.

Esco dalla narrazione dei concetti e torno nel “mondo vero”. Mettendo in discussione il processo, ad esempio, di sviluppo software (vale per qualsiasi processo) di una divisione aziendale che si occupa di scrivere parte di una applicazione o del firmware di un device posso verificare se il modus operandi del team è, in qualche modo, exploitable. Esiste una procedura di validazione del codice? E’ documentata e nota a tutti? Viene rispettata? Come viene gestito il codice? Come viene eseguito il testing della soluzione? Esiste un piano di remediation? Esiste un piano di analisi dei bug? […] Io, da solo, posso formulare un centinaio di domande solo per questo contesto… un team interdisciplinare con specifiche competenze e con il corretto mindset è la base per iniziare mettere in discussione il modello, per perfezionarlo e per contagiare (mi concederete il termine) l’intero team di sviluppo e gli altri team affinché il modello diventi parte dell’organizzazione stessa. Da processo ad approccio.

Una nota conclusiva forse banale ma che mi ha fatto riflettere: il fatto che mi sia trovato a discutere questo tema con più persone di uno specifico settore non è da leggersi come una coincidenza, è un trend, un meraviglioso trend che porta le organizzazioni a ragionare sul valore del prodotto finale e sugli impatti delle scelte che sono chiamate a fare in tema di gestione della sicurezza informatica e tutela della privacy.