Nessun risultato trovato
Prevenire è meglio che curare anche in ambito informatico: si potrebbero riassumere così la realtà delle infrastrutture IT e le problematiche connesse alla sicurezza informatica, perché la complessità delle tecnologie, la prolificità degli hacker e la costante connessione in Rete dei computer e delle reti locali aziendali non consente la certezza di avere un’infrastruttura sempre al sicuro. Quindi è indispensabile fare e aggiornare l’analisi dei rischi, intesa come l’individuazione del rischio che l’infrastruttura corre e la classificazione per priorità, ossia l’identificazione di quali rischi sono più concreti e pericolosi per l’attività e quali meno, per poter strutturare un piano di protezione della rete aziendale e delle macchine che ne fanno parte in base alle vulnerabilità riscontrate.
Questo tutorial affronterà il tema spiegando che cos’è e come si conduce l’analisi dei richi nelle infrastrutture IT proprie o di clienti, partendo da alcune domande basilari.
In questo tutorial approfondiremo le tematiche che chiunque nel suo lavoro abbia a che fare con la sicurezza informatica deve affrontare. Che si tratti di un SysAdmin, di uno sviluppatore (Dev) o di un DevOps, tutti devono per quanto di loro competenza garantire la massima sicurezza dei loro "beni".
La prima cosa da fare è scegliere l’approccio giusto e questo non può che essere quello dell’hacker: solo se riuscirete ad entrare nella mente di chi vuole attaccare la vostra infrastruttura sarete in grado di difendere meglio la vostra rete e le vostre applicazioni. Quindi pensate per un istante a cosa fareste se voleste attaccare una rete e tutto sarà più chiaro.
Tutti gli asset aziendali sono soggetti a rischio, indipendentemente dalla loro natura. Identificare i rischi è fondamentale per agire preventivamente laddove possibile o per preparare un piano di emergenza.
Per effettuare un’analisi dei rischi si ricorre a procedure codificate e standardizzate, ad esempio secondo ISO/IEC 27001 o RFC-6274).
In questo tutorial vedremo strumenti di analisi più legati all'ambito business management ma comunque non meno importanti.
Stabilito che il primo step è un’analisi accurata dei rischi ai quali un determinato asset aziendale è sottoposto, possiamo avere quello che effettivamente è un piano d’azione contenente delle strategie correttive che ci permettono di minimizzare i rischi laddove questi siano significativi.
È importante procedere con un'analisi di questo tipo in modo sistematico, cioè ogni qualvolta si avvia un nuovo progetto, perché non è pensabile farla una-tantum: ogni cambiamento può far emergere nuove vulnerabilità.
Infatti una delle cose da ricordare quando si parla di Risk Management e di Risk Assessment è che non si tratta di un una cosa che viene fatta una volta nella vita e basta: non è un'operazione che si fa ogni tanto quando abbiamo tempo, non si fa un'analisi dei rischi cui seguono delle raccomandazioni e la cosa finisce lì.
È un processo che va ripetuto nel tempo e rivisto ogni qualvolta si è intervenuti per esempio con le misure correttive; quando iniziamo un nuovo progetto, la gestione del rischio dev’essere parte integrante della gestione del progetto.
Il discorso nasce in ambito di business management perché in generale gli asset di un’azienda sono soggetti a rischio e questo è indipendente dalla loro natura; quindi sia che si tratti di beni materiali o immateriali, di rischi finanziari o rischi di impresa, ed anche di sistemi IT che possono essere compromessi, smettere di funzionare o possono essere soggetti a varie vulnerabilità. Senza contare le nuove problematiche sorte con il GDPR, inerenti ai rischi legati al trattamento dei dati personali, che potrebbero essere trafugati o accidentalmente essere diffusi e quant'altro.
Vedremo di seguito un metodo di valutazione che è generico e si basa su una definizione di rischio totalmente indipendente dal contesto, però faremo degli esempi che sono invece più vicini alla mentalità del tecnico e quindi al mondo IT.
È importante dare una definizione al rischio utilizzando termini semplici da intuire ma che, derivando dalla terminologia del business management e soprattutto dall'inglese, hanno un'accezione un po' diversa rispetto quella lingua italiana; ad esempio il rischio nell’ambito del business management ha solo un’accezione negativa perché si parla di rischio anche quando si rischia avvenga un evento positivo, mentre nel caso del Risk Management per l’IT parliamo soltanto di eventi indesiderabile e quindi il rischio esprime la probabilità che è un attività porti a un evento indesiderabile per l'azienda.
Dunque, nell’Information Technology il rischio esprime la probabilità che una determinata attività (interna o esterna) porti ad un evento indesiderabile per l’azienda. I fattori che concorrono alla definizione di un rischio sono:
Un esempio di asset è un sito web di e-commerce, mentre una tipica minaccia è un attacco DDOS esterno; una vulnerabilità può riguardare le reti CDN e i firewall e in generale il software, quindi essere una vulnerabilità di sicurezza che potenzialmente lo espone a una minaccia esterna (l’attacco di hacker che mira a minare il funzionamento del sistema).
Notare che nell’analisi delle vulnerabilità possono rientrare anche elementi positivi, ossia in grado di escluderne alcune come i sistemi anti-DDOS; quindi, per quanto possa sembrare controintuitivo, se ad esempio un sito di e-commerce dispone di sistemi in grado di evitare gli attacchi DDOS, nell’analisi delle vulnerabilità andrà elencato anche questo, pur trattandosi di una caratteristica che in realtà è a favore e non a sfavore.
Sulla base delle valutazioni di asset, minacce e vulnerabilità è possibile creare un prospetto che per ciascuno assegni un valore, come nell’esempio seguente, riguardante un sito di e-commerce definito come asset critico (perché può essere la fonte di introito di un’azienda e contenere dati personali la cui incorretta gestione può far incorrere in sanzioni contemplate nel GDPR) per cui è stata individuata come minaccia probabile l’attacco DDOS esterno e tra le cui vulnerabilità figurano reti CDN e firewall, mentre come elemento positivo spicca la presenza di sistemi atti a prevenire la minaccia individuata. Non a caso la vulnerabilità di questo sito è improbabile.
Questo esempio ci porta a poter quantificare il rischio, che anche se nell’immagine è indicato come risultato di una formula, in realtà non deriva da un calcolo matematico perché parliamo di valori discreti che comunque ci permettono di assegnare un’etichetta a questo rischio; la valutazione si fa tenendo conto dei valori che abbiamo indicato quindi di quanto è importante l’asset, quanto è probabile la minaccia e di quanto è probabile la vulnerabilità.
Nell’eseguire l’analisi dei rischi bisogna fare tante di queste valutazioni quanti sono gli asset, quindi per prima cosa individuare gli asset e poi per ognuno vedere quali sono le vulnerabilità e le minacce. Tale attività coinvolge persone che hanno un background differente, tecnici e non tecnici e ciò è fondamentale per la qualità dell’analisi del rischio, perché altrimenti un tecnico si concentrerà soltanto sugli aspetti legati all’IT, il management dell'azienda potrebbe concentrarsi soltanto sugli aspetti che hanno un effetto diretto indiretto sul cash flow ecc.
Per identificare e gestire, controllare e mitigare i rischi cui sono sottoposti gli asset aziendali esistono diverse procedure codificate e standardizzate secondo ISO 27001, RFC-6274 e via di seguito.
Con tali premesse possiamo andare a elencare i punti in cui si deve articolare una corretta procedura di analisi del rischio:
I primi tre punti li abbiamo già esposti ed anche il quarto, in un certo senso, intendendo con incidente il verificarsi del rischio. In caso di incidente è importante valutare l’impatto che avrebbe sull’attività dell’azienda, che può essere di natura economica o meno anche qui non è detto che è il verificarsi di un rischio si possa tradurre direttamente in un impatto economico o immediato: esistono rischi che portano ad avere disservizi, danni di immagine e via di seguito, che magari per una società commerciale divengono nel tempo fattori negativi e pregiudizievoli.
Molto importante è elaborare le raccomandazioni e le azioni di controllo e correzione, nel senso che qualora ci trovassimo di fronte a un rischio con probabilità elevata bisognerebbe intervenire affinché questa probabilità di rischio si abbassi. Quindi nella procedura nella redazione del documento di Risk Assessment si indicano proprio le raccomandazioni e le azioni da effettuare, dopodiché l’analisi va effettuata nuovamente quando verranno implementate queste correzioni.
Vediamo ora gli step della procedura con maggiore dettaglio partendo dall’1, ossia l’identificazione degli asset: l’asset è tutto ciò che ha valore per l’azienda, quindi server (anche istanze Cloud), dati, documenti sensibili, codici sorgente e in generale la definizione di asset dipende dal contesto. In questa identificazione occorre pernsare a utto ciò che può scatenare il verificarsi dell’evento descritto dal rischio, quindi cause naturali (ad esempio incendi) malfunzionamenti e guasti, errore umano (ad esempio errori di configurazione) e cause esterne (ad esempio il più volte citato attacco DDOS). Perciò di questi asset bisognerà individuare minacce e vulnerabilità ed anche la probabilità che possano occorrere.
A riguardo, è importante sottolineare che il rischio definisce un evento probabile e non un evento certo, cioè se vi trovate di fronte una realtà per la quale sapete che accadrà sicuramente un determinato evento quello non è un rischio ma una certezza e bisogna immediatamente intervenire, correggere, minimizzare e quantomeno far diventare la certezza una semplice probabilità.
Nella valutazione della probabilità rientra il cercare di capire cos'è che può favorire il verificarsi del rischio, ossia se la causa può essere interna o esterna; ad esempio nel caso in cui il rischio sia quello di cancellazione dei dati e l’asset sia un database aziendale, la minaccia può essere interna quando è un nostro operatore aziendale che ha cliccato sul pulsante sbagliato e ha e ha cancellato dei dati, oppure esterna e quindi parliamo di un attacco di informatico.
Includere degli scenari di disastro in una valutazione di rischio può sembrare banale ma non lo è, perché a seconda della scala della valutazione è importante prevedere dei piani di Disaster Recovery e quindi è fondamentale includere anche questi scenari. Poi ci possono essere cause esterne che magari difficilmente vengono considerate in prima battuta: ad esempio un NAS che si trova in ufficio è esposto al richio di furto, quindi può anche succedere che arrivino i ladri rubino tutto, incluso l’unico sistema dove si trovano dati sensibili, magare le copie di backup dei nostri dati ecc.
Questi esempi fanno capire che non dobbiamo solo concentrarci sulle vulnerabilità di sicurezza, ma in generale occorre fare un audit di quelli che sono gli asset aziendali e a quel punto di possono identificare le loro vulnerabilità.
Nel caso del software, quindi di asset che sono in qualche modo connessi a sistemi informativi, è più o meno facile definire delle vulnerabilità, perché esistono degli strumenti esterni che ci consentono di fare delle valutazioni, come per esempio i database di vulnerabilità: basta scrivere la versione del software che stiamo utilizzando e verificchiamo se ci sono delle vulnerabilità conosciute. Esistono poi strumenti che consentono di fare delle analisi proprio sullo stato di sicurezza del nostro sistema, ad esempio mediante penetration testing. Però non è detto che questi strumenti siano esaustivi: ad esempio laddove si utilizzi un software open source che però non è manutenuto e non è aggiornato da tanti anni, come facciamo a capire se è possiamo ancora fidarci? Questo è il caso in cui conviene rivolgersi a dei consulenti che si mettono lì ad analizzare il codice e verificano se ci sono problemi di sicurezza che sono stati trascurati da una determinata applicazione.
Una volta individuato un asset, definita una minaccia per essa e le vulnerabilità che la espongono al rischio, dobbiamo calcolare la probabilità che si verifichi un incidente, ovvero quanto è probabile che una vulnerabilità venga sfruttata; questo corrisponde al punto 4 della nostra procedura. Trattandosi di valutazioni empiriche ci dobbiamo affidare a valori dicreti e nello specifico, tipicamente si utilizzano tre soglie: probabilità bassa, media o alta.
Vi sono dei casi in cui, dovendo far confluire nella stessa analisi degli aspetti meramente tecnici e aspetti ambientali e/o esterni, potrebbe essere difficile individuare una scala universale: per esempio, in una scala con 5 valori possiamo esprimere la probabilità che entrino i ladri, ma con questi cinque valori non è detto che riusciamo ad esprimere la probabilità che venga sfruttato un exploit di sicurezza su una versione di un software.
Facciamo un esempio riferendoci alla minaccia rappresentata da un attacco DDOS: questo tipo di attacco è molto frequente, secondo le statistiche riportate dal sistema anti-DDOS, quindi alla minaccia assegniamo un punteggio ALTO.
Sotto l’aspetto della vulnerabilità, il sistema anti-DDOS è robusto e riceve aggiornamenti costantemente, quindi il punteggio corrispondente è BASSO.
La probabilità che l’incidente si verifichi è quindi MEDIA.
Per ogni caso dobbiamo approntare scale di valutazione differenti e appropriate prendendo in considerazione i casi estremi e stabilendo l’intervallo in cui ricadiamo. Per esempio nel caso dell’attacco DDOS, per valutare la probabilità di un attacco guardiamo i dati storici e quindi le statistiche da cui possiamo desumere più o meno qual è la nostra visibilità è quanto di frequente possiamo incorrere in una minaccia di questo tipo. In mancanza di dati storici dobbiamo rifarci a delle statistiche pubbliche.
Eccoci al punto 5 della nostra procedura: anche in questo caso la valutazione può essere empirica e per valutare il danno che subiremmo in caso di concretizzazione del rischio dobbiamo avere dati di riferimento o statistici, che possono anche essere quelli del nostro settore di riferimentoo di competitor. Riprendendo l’esempio di un sito di e-commerce, se sappiamo che mediamente in un’ora di attività produce entrate per circa 5.000 euro, sappiamo che un'ora di down-time avrà un impatto medio di circa 5.000 euro di mancati introiti. Poi in realtà non è sempre così perché entrano in gioco numerosi fattori, tra cui la possibilità che un potenziale cliente che trova il sito “giù” non aspetti e comperi da un competitor.
Quindi possiamo fare una valutazione delle azioni di controllo e correzione da intraprendere qualora ce ne sia bisogno; quindi se abbiamo una probabilità di rischio alta, affinché il rischio si abbassi possiamo intervenire sulle minacce o vulnerabilità, ovvero implemetare un sistema di business continuity con web server ridondanti. Ancora, se abbiamo delle macchine che strategicamente sono asset importanti e si trovano nello scantinato sotto un un tubo dell'acqua, l'azione di controllo e correzione è quella di spostare immediatamente queste macchine in una posizione più sicura; nel momento in cui faremo questo, automaticamente avremo abbassato la probabilità del rischio.
In linea generale, identificati i rischi occorre intraprendere azioni stabilendo priorità in base all’entità e probabilità del rischio.
Riprendendo il caso del rischio di attacco DDOS che è MEDIO, poiché la vulnerabilità relativa è BASSA conviene implementare politiche di alerting e monitoraggio continuo al fine di intervenire in caso di attacco (ad esempio, scalando il numero di risorse disponibili) visto che comunque la frequenza di attacchi è alta.
Comunque non è detto che le azioni siano solo di correzione: anche nel caso in cui il rischio è basso si possono elaborare dei suggerimenti che servono ad assicurarci che il rischio rimanga tale, perché fondamentalmente lo stato degli asset aziendali è in continua evoluzione, perché l’azienda si trasforma in continuazione, quindi è normale che anche la valutazione del rischio muti nel tempo.
Arriviamo quindi all’ultimo passo della procedura, ossia redigere la documentazione; per descriverla e strutturarla utilizziamo la tabella seguente, fermo restando che può non bastare perché in un’analisi esaustiva c’è tutta una serie di raccomandazioni e di descrizioni dello stato dell'azienda. La tabella riassume quello che è stato spiegato finora e in essa abbiamo una colonna per ognuno degli elementi che corrisponde a uno step della procedura.
Ogni riga della tabella rappresenta la documentazione relativa all’analisi di un asset e qui ne sono stati individuati tre, descritti ognuno da uno degli aspetti. Ad esempio nella prima riga troviamo il sito di e-commerce e il caso esemplificato è quello di una minaccia corrispondente all’attacco DDOS, la casella vulnerabilità contiene gli elementi che proteggono il sito o consentono questa minaccia, l'impatto che ha il verificarsi di un incidente (ossia cosa succede quando si verifica un incidente, in questo caso down-time), la probabilità desunta dalle statistiche (tre valori: basso, medio, alto) il rischio (perdita di acquisti) e poi nella documentazione aggiungiamo una nota che spiega esattamente cosa significano i livelli di probabilità in pratica. La colonna RISCHIO è importante perché con il suo contenuto occorre far capire chiaramente al cliente per cui si sta facendo l’analisi del rischio che cosa può comportare non eseguire le azioni, correzioni, contromisure ecc. per mitigarlo, riportate nella colonna AZIONI.
In questo ci sono di aiuto le statistiche, specie quelle pubbliche consultabili sul web ed anche i dati sulle vulnerabilità certificate per sistemi operativi e applicativi.
Un esempio si può avere sul sito https://cve.mitre.org/ (Common Vulnerabilities and Exposures) che offre un report sulle vulnerabilità per prodotto di ogni singolo top vendor, dove possiamo vedere le statistiche sulla probabilità di 23 bug nei prodotti. Per quanto riguarda gli attacchi, sempre sul web si trovano le statistiche (ad esempio it.netscout.com) riguardanti il numero di attacchi e quanto tempo durano.
Le statistiche di solito includono anche altri due parametri che sono fondamentali: uno è relativo alla banda, cioè alla potenza d'azione e l’altro riguarda l’area geografica da dove vengono portato, cosa utile ad esempio perché se c’è una ondata di attacchi DDSO che però riguarda l’America e noi abbiamo solo asset in Europa, difficilmente saremo sottoposti a tale ondata, sebbene di riflesso potremmo anche noi subire dei rallentamenti o essere oggetto di attacchi di amplificazione; per esempio se abbiamo un server su Cloud Amazon in USA e questo va giù, è chiaro che anche noi, operando in Europa, potremmo esserne toccati indirettamente.
Le statistiche che sono lo strumento che possiamo utilizzare più spesso per questo tipo di valutazioni e possono essere pubbliche o interne, quindi descrivono quella che è stata la vera vita dell’azienda e rappresentano informazioni di prima mano su sull'andamento degli asset aziendali.
I dati statistici interni sono vitali se abbiamo a che fare con un software sviluppato internamente o specificatamente per noi, in quanto in Rete non troveremo statistiche ne informazioni sull’uso di eventuali vulnerabilità
Torniamo alla tabella per spiegare cosa va inserito nella colonna AZIONI: si tratta dei comportamenti e delle correzioni o contromisure per scongiurare il concretizzarsi del rischio e su queste bisogna sensibilizzare il cliente per cui si è condotta l’analisi; a riguardo va enfatizzata l’importanza di intraprendere queste azioni chiarendo che se non si fa una determinata cosa si possono perdere dei soldi, che non sono necessariamente quelli dell’intervento tecnico di riparazione ma anche e soprattutto di interruzione del business. Quindi se questi costi o perdite possono essere evitati con delle azioni correttive, ben vengano!
