Il security assessment è un processo rivolto a identificare i beni/servizi di valore/critici di un’organizzazione e valutare qual è il grado di protezione su di essi al momento della valutazione rispetto alle vulnerabilità intrinseche di tutte le componenti interessate nel contesto di riferimento.
L’assessment, infatti, è di per sé una valutazione di conformità rispetto a criteri che possono essere identificati in requisiti di cogenza, norme volontarie, schemi tecnici e non per ultimo vulnerabilità intrinseche di sistemi, persone e/o processi.
Il termine security, invece, tipicamente tradotto con sicurezza, in questo caso assume il significato di “protezione” di un bene o di un servizio da qualcosa di non desiderato che vada a danneggiare il suo possessore/erogatore e/o le sue parti interessate.
Mettendo insieme i due termini ecco che abbiamo chiarito il concetto di security assessment sul patrimonio aziendale.
Indice degli argomenti
Security assessment: identifichiamo cosa proteggere
È necessario identificare innanzitutto ciò che vogliamo proteggere dando una forma al patrimonio aziendale attraverso una rappresentazione grafica che sia semplice ma al tempo stesso completa.
La proposta si basa sullo sviluppo di una mappa mentale (strumento di rappresentazione gerarchico-associativa) che abbia come nodo di partenza il bene/servizio da proteggere, il cui sviluppo possa essere modellato secondo una logica di scomposizione che raggiunga, attraverso un percorso di dipendenze, le componenti elementari costituenti il servizio con i loro attributi caratteristici, da cui le vulnerabilità nel contesto di riferimento e gli eventuali fattori di mitigazione presenti.
Perché fare un security assessment
Nell’era connessa in cui viviamo, immersi nell’IoT (Internet of Things), con le facilities dei Virtual Payment gestiti tramite gli smartphone, con l’Industry 4.0 e la nuova dimensione dei servizi operabili tramite il 5G, pressati dal time to market dell’innovation, stiamo perdendo il sano approccio della “validazione” ovvero del tempo di maturazione necessario a garantire che processi, tecnologia e sistemi di nuova realizzazione diano evidenza di essere robusti/sicuri così come li abbiamo pensati.
Fattore aggravante in questo scenario evolutivo è la complessità sempre maggiore dei sistemi di interscambio delle informazioni e dei dati, a volte operanti con protocolli proprietari, affogati in una giungla di applicativi sostenuti dai più disparati framework, alcuni di brand blasonati, altri open integrati all’occorrenza o con il principio di maggior convenienza (tempi/costi).
È pertanto inevitabile che qualsiasi sistema del presente e a maggior ragione del futuro, risentirà sempre di più di tutti gli elementi di debolezza correlati ai componenti di natura eterogenea sopra menzionati e alla variabile tempo.
Consapevoli di questo confuso ed allettante scenario, pieno di inviti ad attaccare, sono i nuovi criminali informatici. Il termine “hacker, che nell’immaginario collettivo era una figura isolata dedita a violare i sistemi degli enti governativi solo per dimostrare le proprie capacità, oggi, con la disponibilità in rete di know how specifico e risorse nel Deep Web (parte del WEB non indicizzata dai comuni motori di ricerca e non convenzionalmente visibile) è impersonato da personale tecnico specialistico il quale, grazie alle nuove tecniche di invisibilità garantite da servizi VPN (Virtual Private Network) di anonimizzazione, può dedicarsi ad attacchi ai dati, alle informazioni ed ai sistemi per scopi altro che etici.
A valle di questa triste constatazione nasce una considerazione basilare: se la mia organizzazione dovesse essere attaccata, sicuramente non saremmo in grado di risalire all’attaccante (a meno che non sia particolarmente sprovveduto) ed in ogni caso il danno è fatto.
Occorre pertanto mettere in atto tutte le difese possibili per evitare di subire conseguenze di un attacco da parte della criminalità informatica.
Che succede se la mia organizzazione viene attaccata con successo?
Perdita di reputazione e conseguentemente mercato (es: servizi bancari erogati in modalità multicanale), possibile applicazione di sanzioni contrattuali (Internet Service Provider per perdita/degrado di servizio), ancor peggio sanzioni applicate dal sistema regolatorio nazionale o sovrannazionale (es: sottrazione e diffusione di dati personali – data breach GDPR).
Mi sembra che le motivazioni siano stimolanti per affrontare come si deve un security assessment
Come fare un security assessment
Lo svolgimento di un security assessment non deve essere un esercizio di stile finalizzato a riempire fogli Excel di numeri con valori di probabilità a volte improbabili e impatti descritti in modo qualitativo derivando rischi di difficile quantificazione/interpretazione a volte anche difficilmente giustificabili ad un management che deve stanziare un budget per l’implementazione delle contromisure di mitigazione.
Il security assessment è un approccio ragionato, consapevole che deve indagare, non limitatamente al solo aspetto tecnologico (mi piace ricordare che il “bug” risiede sempre tra la sedia e la tastiera), ma deve essere esteso all’interno della propria organizzazione anche su processi e risorse.
Questo per dire che attività di penetration test e vulnerability assessment, così come li conosciamo, non sono sufficienti a garantire la copertura di un security assessment che ha altre dimensioni non esplorabili con le due attività menzionate.
Quale supporto all’approccio ragionato abbiamo ipotizzato l’utilizzo della mappa mentale in quanto essa, partendo da un nodo che impersona il bene/servizio da proteggere, consente di sviluppare l’assessment lungo delle direzioni che possono essere strutturate secondo delle logiche di copertura del dominio di interesse.
Ci sono dei rami della mappa che partono dal nodo principale a mio avviso identificabili come “rami obbligati” quali ad esempio:
- i processi: con i quali sono definite le modalità di governo e controllo del bene/servizio;
- gli asset tecnologici: che consentono l’automazione e distribuzione del bene/servizio;
- le risorse umane: che soprassiedono e fruiscono del bene/servizio interagendo con esso e modificandone le proprietà/comportamento;
A partire da questi rami l’analista che svolge il security assessment inizia a scomporre il contesto di riferimento sino ad arrivare, come precedentemente annunciato, alle componenti elementari costituenti il servizio, gli asset, con i loro attributi le “caratteristiche costituenti”, da cui le vulnerabilità nel contesto di riferimento e le eventuali contromisure di mitigazione presenti.
Proviamo a illustrare questa teoria con un esempio pratico.
Si desidera valutare la sicurezza del servizio che gestisce la fatturazione del traffico telefonico di una rete di fonia mobile. Allora il servizio sarà il nodo principale della mappa cui agganciare i “rami obbligati”. Definiti questi, scegliamone uno e sviluppiamolo: il ramo degli “ASSET TECNOLOGICI” e operiamo su di esso la seguente scomposizione gerarchica: (HARDWARE; SOFTWARE)
Scomponiamo ancora gerarchicamente:
- “HARDWARE” in: server, switch, firewall, router, UPS, gruppi elettrogeni, chiller, cablaggio, cabina ecc.;
- “SOFTWARE” in: application server, sistemi operativi, DBMS, virtualization e via dicendo.
A questo punto siamo giunti all’individuazione di asset fisici con un grado di atomicità tale da consentirci di identificarne le “caratteristiche costituenti” e le relative vulnerabilità.
Scegliamo ad esempio l’asset “FIREWALL”, un componente adibito a permettere la corretta comunicazione ed instradamento delle informazioni tra sorgente e destinazione attraverso regole definite ad alto livello per far interagire logiche applicative e dati secondo gli obiettivi del servizio e declinate in termini di “policy” all’interno del dispositivo da parte dei network administrator.
Si evince immediatamente come una non corretta configurazione, dolosa o colposa che sia, comporti un disservizio in termini di disponibilità di una risorsa oppure un accesso non autorizzato alla risorsa con possibile compromissione di dati ed informazioni.
Le regole del firewall sono quindi una “caratteristica costituente” dell’apparato (senza regole non funziona e non serve), per arricchire l’esempio consideriamo anche il “firmware del firewall” (è il sistema operativo dell’apparato senza il quale le regole non sono implementabili e il dispositivo neanche si accende).
Nella mappa mentale ho evidenziato queste “caratteristiche costituenti” in giallo. Adesso viene lo sforzo dell’analista che, facendosi supportare dall’esperto di dominio e/o tecnico, deve ragionare con lo spirito del “guastatore”, ovvero con la mentalità da hacker, cercando di identificare il maggior danno arrecabile alla “caratteristica costituente” traendone maggior vantaggio per sé e maggior danno per il bene/servizio/organizzazione.
Etichettiamo il ramo che si svilupperà dalla caratteristica oggetto di valutazione con [M] “minaccia-vulnerabilità” e etichettiamo con [C] i rami figli di [M] relativi all’enumerazione (1..n) delle [C] contromisure applicabili a [M], nel contesto di riferimento.
Ecco la mappa che descrive l’esempio:
Chiediamo al network administrator se sono presenti delle contromisure per limitare l’apertura non controllata delle porte o la creazione di regole improprie (traccio questa domanda come ramo figlio della caratteristica “regole firewall”: [M] apertura di porte e protocolli non strettamente necessari (sfruttabili da agenti interni o esterni non autorizzati per penetrare la rete).
La risposta del network administrator è che esiste un processo per il quale il network administrator effettua la validazione delle regole richieste ad esempio dal reparto di sviluppo applicativi.
Si crea allora il ramo figlio di [M] “minaccia/vulnerabilità” e lo si indica con [C] “processo di validazione delle regole prima della loro implementazione.
Tutte le contromisure già esistenti vengono colorate con il verde. Qualora per un ramo [M] non sia già presente una contromisura occorre fare uno sforzo per identificarne una possibile o comunque abbozzare, laddove possibile, una proposta da validare a posteriori e la si colora di blu.
In questo modo al termine del ragionamento risulta immediatamente evidente, a sfondo blu, qual è il piano d’intervento per “proteggere” il proprio servizio.
Sulla mappa ho ripetuto questo procedimento per alcune altre caratteristiche a mero titolo di esempio, senza dettagliarne la descrizione in modo testuale.
Da questo procedimento, ne consegue una vista ad ampio spettro di tutte le componenti costituenti il bene / servizio di cui valutare vulnerabilità e relativo grado di protezione.
In questo procedimento la figura chiave è l’analista che deve decide la scomposizione più consona all’ambiente sottoposto ad analisi identificando il livello di approfondimento che rende l’assessment più efficace.
Un elevato livello di granularità sicuramente non lascerebbe nulla di trascurato, potrebbe tuttavia costituire elemento di dispersione rendendo il procedimento macchinoso e poco gestibile.
È importante quindi trovare il giusto compromesso per massimizzare l’efficacia del procedimento rispetto al ragionevole sforzo per realizzarlo.
Il lettore può procedere per esercizio a sviluppare gli altri rami della mappa volutamente lasciati in bianco.
Conclusioni
Questa è una metodologia, sicuramente fuori dagli standard cui siamo abituati, che personalmente uso con successo in quanto mi garantisce:
- visibilità a 360 gradi sul bene/servizio da proteggere oggetto del security assessment di tutti i fattori costituenti;
- chiara identificazione delle dipendenze di “caratteristiche costituenti” degli asset oggetto della valutazione;
- copertura integrale delle minacce/vulnerabilità rilevate.
La mappa mentale non è statica ma è funzione del contesto in cui è immersa e potrebbe essere anche, in base alla complessità del contesto esaminato, un nodo di un grafo più complesso che collega più mappe.
In ogni caso il buon esito di questo procedimento è fortemente legato alla sensibilità dell’analista, colui che esegue il security assessment, nello stabilire la granularità delle ramificazioni della mappa e identificare la “qualità” degli ultimi due rami.
