“Non c’è nulla di più ingannevole di un fatto ovvio” (Sherlock Holmes).
È impossibile la quantificazione del cyber rischio. Il fatto ovvio da cui partire riguarda la minaccia cyber criminale: è ovvia la sua natura, le intenzioni ed i metodi, ma al contempo è sua caratteristica principale quella di essere difficilmente quantificabile e di sfuggire a ragionamenti metodologici che possano quantificare il ritorno sull’investimento in protezione e difesa.
Di fronte a questa incertezza, le risposte di maggior valore che possiamo chiedere agli esperti di cyber security riguardano la quantificazione di un ritorno sugli investimenti in effort di mitigazione del cyber rischio: in un panorama di risorse limitate è necessario affrontare seriamente la problematica di allocazione delle risorse per contenere la minaccia cyber.
Queste risposte si basano su metodologie di misurazione che devono considerare e sempre più includere nella definizione di quello che in gergo si chiama “superficie d’attacco” non solo reti e sistemi propri ma anche fornitori e partners, sia formali che informali, includendo sempre più gli ecosistemi tecnologici di business aperto (sistemi di API, librerie open, microservizi).
È talmente difficile che ci troviamo di fronte ad un fallimento di mercato, infatti i regulators offrono incentivi, il mercato offre “la qualunque”.
La difficoltà di misurazione del cyber rischio e soprattutto la questione del dimensionamento delle azioni relative non è una tematica nuova. Se da un lato i regolamenti che si sono dati il sistema bancario ed assicurativo prevedono la misurazione del rischio IT, purtroppo non affrontano il dettaglio del cyber rischio, e non danno delucidazioni.
Identicamente il regolamento per antonomasia di cui si parla in questi mesi definisce sanzioni importanti, ribadendo l’esistenza di un rischio che, pur delineando una serie di operazioni organizzative e tecniche che rappresentano un comune denominatore nella protezione del dato, non pare potere essere quantificato. Questo dipende in gran parte dal panorama in continua evoluzione, dalle interdipendenze sistemiche, dalla scarsità e bassa affidabilità dei dati disponibili per effettuare previsioni.
Ragionando in termini di business case: la GDPR è un serio incentivo, che riduce il rapporto costo/opportunità per la protezione cyber, senza però offrire strumenti di quantificazione alle organizzazioni coinvolte.
Se qualcuno avesse dubbi sul fatto che vi sia incertezza basti pensare alla quantità diversa di soluzioni GDPR proposte dal mercato: chi si concentra sull’accesso, chi sul tracciamento, chi sulla sicurezza, chi sull’encryption, chi – ancora, giustamente per chi fosse sguarnito – sul perimetro, chi addirittura su apparecchiature hardware (abbiamo recentemente trovato chiavette USB criptate che “abilitano” la GDPR)
La sicurezza applicativa e della filiera?
Un aspetto critico su cui troviamo limitata attenzione da parte del mercato per la cyber protection è quello della sicurezza applicativa, storicamente sottovalutata come area su cui operare per mitigare appropriatamente il cyber rischio, proprio per la difficoltà di misurazione ed impraticabilità dei percorsi di mitigazione.
Il ragionamento sulla cybersecurity delle applicazioni non può essere affrontato senza considerare nel perimetro delle valutazioni le filiere di fornitura software (open o proprietario). Oggi è evidente che per fare sicurezza applicativa bisogna dotarsi di un processo di acquisizione e sviluppo che possa misurare anticipatamente la sicurezza applicativa.
Da un lato gli sforzi decennali di organizzazioni non governative (intendo il MITRE in primis, che annovera e censisce continuamente le vulnerabilità applicative), possono essere messi a frutto dalle organizzazioni che utilizzano componenti di terze parti, censiti nel database CVE (Common Vulnerabilities Exposures). Tools online (Cast Hightlight) permettono di scansionare le librerie utilizzate dalle proprie applicazioni.
Dall’altro rimane il problema della quantificazione del cyber rischio: se per la mitigazione i sistemi di checklist e scoring (formulati da NIST, da OWASP, e da altri CSC/SANS) indirizzano la soluzione, purtroppo non offrono dei meccanismi di gestione e prioritizzazione del rischio applicativo (non misurano, elencano), né permettono di costruire delle filiere di procurement di software sicuro (non sono misure automatiche).
La sicurezza applicativa senza una misurazione economica, oggettiva e ripetibile, porta ad assumere approcci totalitari, vuoi destinati ad eccedere i budget (la crescita combinata delle superfici d’attacco e delle minacce cyber eccedono qualsiasi crescita di budget per la sicurezza), o a sottostimare il rischio a cui si è esposti.
In un recentissimo report, Forrester conferma come i professionisti della sicurezza oggi non possano fare a meno di considerare l’analisi statica della sicurezza applicativa come migliore strumento di prevenzione rispetto a problemi complessi di flusso dati e di manipolazione ingannevole dei contenuti web (XSS/CSRF).
Che la crescita dei budget sia incessante è dato certo. Dopo i data breaches massivi della fine degli anni 2000, le organizzazioni più esposte a livello globale hanno iniziato a dotarsi di figure dedicate (spesso i CISO che incontriamo oggi sono i primi nel loro ruolo) a gestire responsabilità crescenti e budget che, a livello globale, sono raddoppiati ogni 3 anni e che continueranno ad una crescita di almeno il 10% fino al 2021. (dati forbes/cybersecurity ventures).
Ciononostante il trend delle violazioni è di continua crescita
Purtroppo anche il dato che riguarda la crescita dei data breaches, non offre un quadro roseo: i tempi intercorrenti tra un evento di intrusione o furto di dati e la sua scoperta (c.d. dwell time) si stanno allungando con una media superiore ai 3 mesi – indicando la necessità di investire in strumenti di monitoraggio, mentre la crescita degli incidenti dovuti a negligenza (che ora si attestano al 28%) appare giustificare la crescita in formazione e attenzione da parte di tutti i ruoli aziendali. (fonte dati CSO online)
Quello che serve è un salto di qualità: l’industrializzazione delle cyber – difese
In questo panorama, è chiaro come sia fondamentale investire sulla sicurezza delle applicazioni, ed è evidente che il mercato necessita di strumenti innovativi per misurare la propensione di un’applicazione ad essere violata, di quantificarne al contempo le modifiche urgenti, offrendo anche una simulazione di costo.
Le misure automatiche
Oltre 4 anni fa OMG, organizzazione non profit con la missione di promuovere standard tecnologici comuni tra i player commerciali dei settori IT di rilievo, ha iniziato a lavorare, tramite il gruppo di lavoro CISQ con Robert Martin del MITRE per stilare uno standard misurabile automaticamente di vulnerabilità di sicurezza relative al software (in termini tecnici – quindi – una traduzione in un linguaggio automatizzabile – delle database CWE, che possiamo tradurre come “i modi noti in cui non scrivere codice applicativo”). All’inizio dell’anno scorso OMG ha reso pubblicamente disponibile lo standard ASCSM (automated source code security measure), risultando un elemento innovativo e potenzialmente disruptive nel panorama degli approcci alla cybersecurity.
L’adozione di un criterio di security, misurabile automaticamente, già permette a molte organizzazioni internazionali di ridurre in maniera concreta il rischio contenuto in applicazioni sviluppate dai fornitori. Non ultimo, è immediato capire come questo elemento possa contribuire positivamente ad arricchire gli aspetti non dimensionali delle forniture per la PA.
La situazione attuale in italia
Riguardo quest’ultima tematica l’identificazione di misure minime per l’adeguamento delle forniture non può prescindere dall’adozione di standards di misurazione che vadano a misurare le attività in tema di sicurezza ma anche in ambiti collegati (robustezza, affidabilità), prima della messa in esercizio così da potere essere utilizzate in un’ottica di gestione del rischio.
Le misure minime stilate da AGID e quanto previsto dal Piano Triennale in materia di sicurezza sono un primo gradino di un lungo percorso di un cambiamento culturale nell’atteggiamento verso la sicurezza dei dati: questo deve passare per cambiamenti organizzativi (la figura del DPO è appunto cardine di questo processo), e non può arrestarsi all’interno della singola organizzazione.
Sono possibili filiere di acquisizione sicure del software
L’estensione del concetto della sicurezza alla filiera permette di realizzare ed estendere il concetto di Secure Software Development Cycle alla filiera di approvvigionamento: l’attenzione deve essere posta sulla trasparenza e la misura degli attributi di sicurezza e della quantificazione del rischio inerente ai componenti che vengono integrati.
Avendo aperto con una massima derivata dalla letteratura classica, vorrei chiudere richiamando invece una massima del management e dell’ingegneria:
“Non puoi gestire ciò che non puoi misurare”
(attribuita al padre del lean management E.Deming, anche se lo stesso la usava paradossalmente per invitare i managers a considerare tutti i dati a disposizione e prendere decisioni anche in situazioni di incertezza), a richiamare l’importanza di una corretta misurazione a base delle metodologie di gestione, anche quando questa non possa essere precisa, deve basarsi quanto possibile su dati oggettivi.
[personaggi id=16832]
