podcast

Gestione delle vulnerabilità: primo episodio podcast

Visto che l’argomento è corposo ho pensato di dar seguito anche con una serie di puntate sul podcast dove, oltre a riprendere le argomentazioni del post, provo a dare una lettura semplificata del tema con qualche esempio in più.

Come per il post preparerò diverse puntate con ritmo settimanale nonostante il periodo sia non particolarmente favorevole (spero ci sia chi ha deciso di staccare un po’).

Il primo episodio, di cui riporto il link, è di fatto introduttivo al tema ed ha come obiettivo la necessità di portare il focus sulla metodologia prima che sugli strumenti.

Il podcast è disponibile qui: https://www.spreaker.com/user/11123272/individuazione-delle-vulnerabilita-attac

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.

hacking

La curiosità che genera competenza e comprensione

L’essere curiosi, ovviamente in modo sano, è alla base della crescita (e non mi azzardo ad andare oltre per quanto riguarda i temi socio-psico-umano-robe).

It’s the law!

Molto più pragmaticamente posso dire che la curiosità è ciò che ha spinto il sottoscritto e molte altre persone che hanno vissuto la scena acara (a prescindere dall’epoca) a studiare come dei matti argomenti distanti da qualsiasi corso o università. Moltissime persone che lavorano nel campo della sicurezza informatica hanno acquisito competenza ed esperienza grazie alla capacità di non smettere mai di studiare, sperimentare, applicare, migliorare… in un loop infinito.

Sono certo che moltissimi professionisti del settore si trovano a dover rispondere a domande che fanno un po’ tenerezza, tipo: ma che scuola devo fare per diventare un hacker etico / pen tester / bug hunter?
Indubbiamente ci sono favolosi percorsi di studio e corsi che consento di avvicinarsi a questo mondo e di acquisire le nozioni tecniche per svolgere attività sia in ambito offensivo che difensivo, ma la materia è così vasta e richiede un background così forte che non c’è corso che tenga… non esiste una scorciatoia, bisogna studiare come dei dannati (anche grazie ai corsi) e passare ore, giorni e notti su documenti, libri, codice, laboratori, esperimenti…

Perché il punto non è sapere come funziona una cosa, il punto è capire perché funziona (cit. Capitano James T. Kirk) e se non siete mossi dalla curiosità di scavare a fondo il “perché” non sarà mai così chiaro.

Se questo approccio può aiutare le nuove leve a costruire una reale competenza, in questo come in altri campi, è anche vero che aiuta i professionisti a mantenere un adeguato livello di preparazione sia sul piano tecnico che sul piano manageriale. Gestire la sicurezza informatica (me lo vedrete scrivere fino a quando non vi sanguineranno gli occhi) non è una questione tecnologica, è un approccio, un modo di pensare ed agire che deve costantemente adattarsi a nuovi scenari.

Chi pretende oggi di gestire il fenomeno degli attacchi informatici con le stesse metodologie e procedure che utilizzava 3 anni fa (senza mettere in dubbio i successi del passato) rischia di passare dei brutti momenti. In pochi anni non solo sono cambiati i vettori d’attacco ma sono cambiate anche le strategie, i metodi di qualifica dei target, le “leve”. Dobbiamo uscire dalla trappola della “spesa” per difendersi e ragionare sugli “investimenti” per competere sul mercato. Essere cyber-sicuri è un vantaggio di business: significa essere affidabili, tutelare meglio i dati dei nostri clienti, offrire beni e servizi di qualità anche in relazione alla sicurezza.

Non è un percorso che ha una fine, è una costante ricerca del miglioramento e va alimentata con la curiosità.

podcast

Prima di un attacco (mini serie)

E’ un tema che porto spesso all’attenzione dei miei interlocutori e recentemente ho appreso che è di interesse anche per figure di management che non “bazzicano” il mondo cibernetico.

Quel primo episodio mi ha permesso di comprendere quanto il fenomeno del crimine informatico sia assolutamente non chiaro… talvolta non solo ai non addetti ai lavori.

Per risolvere un problema devi conoscerlo, devi sapere cosa c’è di “rotto” per decidere come sistemare le cose, eppure ognuno di voi — ne sono certo — può raccontare decine di situazioni in cui si sono messe “pezze” senza considerare quali fossero le minacce da cui era necessario difendersi, o basandosi sulla propria percezione del rischio.

Recentemente (grazie ad un evento a cui ho partecipato) ho avuto modo di riorganizzare le idee e con l’occasione ho pensato di portare qualche riflessione in tre puntate del podcast che curo. Le prime due sono online qui: https://www.spreaker.com/show/sintesi-cibernetica

Fatemi sapere se li avete trovati interessanti.

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?

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).