Uno dei temi che l’ingegnere specializzato in Information Technology in azienda deve gioco forza affrontare è quello del corretto indirizzamento dei temi della sicurezza informatica.
Nell’era dei cyber attacchi e della diffusione del malware risulta piuttosto difficile districarsi nella giungla delle tante contromisure di sicurezza proposte sul mercato e individuare tra le molteplici policy e standard tecnici interni quali siano effettivamente necessari e quali potrebbero essere implementati successivamente. Quasi mai l’implementazione di un controllo di sicurezza è indolore senza impatti sull’applicativo o sui processi aziendali, quindi la scelta del controllo più importante deve essere fatta con oculatezza valutando non solo il beneficio ma anche l’impatto in termini di effort e costi indotti.
Forse vi sembrerà strano, ma uno dei principali ostacoli che troverete lavorando in una multinazionale sono le policy aziendali e gli standard tecnici da applicare sulle macchine. Parlo di ostacolo e non di agevolazione perché il lodevole tentativo di stabilire delle regole obbligatorie sulle piattaforme IT non tiene in nessun conto del rischio connesso alla minaccia e quanto quella contromisura agisca su rischio stesso mitigandolo o eliminandolo.
In realtà il giusto bilanciamento da adottare in azienda tra policy (obbligatorie by definition) e implementazioni risk based è alla base del successo delle politiche di sicurezza aziendali. In altri termini avere una lista corposa di policy e standard tecnici non è propriamente la soluzione migliore perché non lascia spazio per le implementazioni legate a rischi ad alto impatto e priorità distogliendo mezzi e risorse.
Un buon approccio per definire la politica della sicurezza IT in azienda è la definizione di una baseline di sicurezza secondo opportune best practice con un numero ristretto di controlli tecnici, un insieme di policy legate alla strategia IT e tutto il resto basato su di un approccio risk based.
Forse qualche esempio può chiarire il concetto. Avere una lista corposa di policy potrebbe portare ad una situazione in cui il team IT si dedica alla dispendiosa attività di patching delle macchine (praticamente all’interno di un classico processo di change management) ignorando la semplice implementazione di una politica delle password. Magari dopo mesi di lavoro per testare l’applicativo con le nuove patch o con il nuovo sistema operativo supportato un hacker potrebbe entrare sui sistemi semplicemente utilizzando la password (magari la stessa dalla notte dei tempi) identica al nome dell’account.
Il risk Management è diviso in due step l’assessment ed il treatment (elimino, accetto, mitigo o trasferisco il rischio).
A sua volta il risk assessment è un processo a due fasi: l’analysis e l’evaluation (individuazione probabilità e impatto).
La letteratura relativa alla gestione del rischio è molto vasta, anche perché i campi di applicazione sono molti. Esistono dei libri dedicati, tool di supporto, framework e metodologie e pubblicazioni approfondite. Vale la pena menzionare la pubblicazione del NIST “Guide for Conducting Risk Assessments” disponibile anche in formato epub e reperibile gratuitamente al seguente link:
Non me ne vogliano i puristi di questa materia ma io vorrei proporre un framework semplificato calato nell’ambito dell’Information Technology. Intendiamoci non voglio dire che quanto scritto dal NIST non sia utile oppure che non servano tool di supporto, ma solo che talvolta, soprattutto quando le esigenze del business non ti consentono di dedicarci troppo tempo, si è gioco forza portati ad adottare approcci più semplici e pragmatici.
Il framework semplificato nasce dalla considerazione che il rischio deriva dalla combinazione di una minaccia e di una vulnerabilità.
Circa l’identificazione delle minacce ci viene in aiuto il modello inventato da Microsoft noto come
che suddivide le minacce nelle seguenti categorie:
Spoofing identity: ottenere accesso illecito usando le credenziali di accesso di un altro utente
Tampering with data: modifica deliberata dei dati
Repudiation: possibilità che ha un utente di negare di aver commesso un’azione
Information disclosure: violazione della riservatezza di un dato
Denial of service: tentativo di negare ad utenti legittimi l’accesso ad un sistema
Elevation of privileges: ottenere in modo illecito privilegi a cui normalmente non si avrebbe diritto.
Il termine Vulnerabilità non va inteso nel senso più restrittivo come bug software di sicurezza del sistema individuabile con strumenti del tipo Nessus ma nel senso più ampio come mancata implementazione di un controllo (Organizzativo, procedurale, tecnologico, preventivo o di rilevamento).
Una lista di controlli da verificare va presa dal sistema di audit con cui si ha più confidenza ad esempio ISO27001 o PCIDSS 3.1.
La prima fase è l’identificazione degli asset oggetto dell’analisi. E’ opportuno circoscrivere il dominio di analisi ad esempio raggrupando gli apparati per aplicazione oppure per segmento di rete come la DMZ Internet.
Nel foglio excel ho ipotizzato l’utilizzo dei requisiti della PCIDSS 3.0 in relazione ad una lista di minacce tra le quali quelle definite da Microsoft (STRIDE), identificando i casi in cui una minaccia probabile è legata ad un controllo non implementato.
Il foglio excel è scaricabile al seguente url:
https://www.barbonetti.it/download/excel-per-un-semplice-risk-assessment/
Il risultato che viene fuori dal foglio excel è una lista di controlli da implementare in via prioritaria. Tra questi l’analisi dell’impatto potrebbe fornire un’ulteriore selezione dando l’elemento finale per la stesura di uno studio di fattibilità.
Di seguito gli aspetti da analizzare nella valutazione degli impatti di una minaccia:
- Finanziario
- Compliance
- Immagine
- Operatvo
Lo studio di fattibilità presuppone l’individuazione precisa dei controlli che consentirebbe l’eliminazione o la riduzione del rischio relativo ad una minaccia.
L’errore più comune in uno studio di fattibilità su tematiche di sicurezza è quello di evidenziare le sole contromisure tecniche (antivirus per contrastare la minaccia virus o IDS/IPS per contrastare la minaccia intrusione) ignorando i controlli procedurali (ad es. workflow di approvazione), preventivi (ad es. regole per l’accesso ai sistemi), organizzativi (istituzione di Security Operation Center) e di rilevamento (opportunamento collezionamento dei log).
La fase finale detta di treatment completa il processo di risk management e consiste, una volta noti i paramteri del rischio (tra i quali i costi dello studio di fattibilità) nella decisione relative al trattamento del rischio.
Gli alti costi necessari per eliminare o mitigare il rischio potrebbero portare il risk owner a decidere il trasferimento del rischio ad esempio mediante una polizza assicurativa oppure sempliecemente accettando il rischio essendo gli impatti più o meno equivalenti ai costi.
Il trattamento più frequente è tuttavia la mitigazione del rischio che porta ad un rischio residuo accettabile dal risk owner.
Il tema delle implementazione dei controlli porta con se delle assunzioni, valide come regole spesso non esplicitate nella letteratura sulle quali non si possono fare eccezioni:
1) Non serve implementare un sistema di log management (ad esempio basato su di un SIEM che raccoglie log dai sistemi, da firewall e ids/ips) senza un team dedicato al monitoraggio ed alla analisi dei log.
2) E’ molto importante delimitare il proprio dominio di rete con dei firewall ma è fondamentale definire il processo di gestione dei firewall con una chiara attribuzione delle responsabilità e con un processo di approvazione chiaro, altrimenti le regole implementate saranno ben presto inutili.
3) I penetration test sono importanti ma prima bisogna dotarsi di un sistema di Identity Management dove ogni account è associato ad una matricola/nome cognome. Se poi si gestisce un parco macchine di qualche centinaio di server è assolutamente consigliato avere un repository centralizzato con tutti gli account personali (active directory o LDAP server).
4) La Sicurezza IT, anche se sembrerà strano, non deve essere solo un problema di chi gestisce i sistemi ma deve coinvolgere tutte le strutture aziendali che utilizzano i sistemi stessi. I ruoli del business owner, del process owner e data owner devono essere chiari perché qualcuno che gestisce il rischio e che prende decisioni ci deve essere.
Quanto sopra per dire che vedere i singoli controlli come entità a se stanti è non solo errato ma invalida l’utilità del controllo stesso.
Come già accennato, il processo poc’anzi descritto non può essere applicato su tutto il parco macchine facendo un solo risk assement una volta per tutte. Gli asset vanno ovviamente tutti censiti e raggruppati in modo opportuno secondo le ownership definite in azienda. Una prima possibilità è fare un risk assessment per processo (CRM, DELIVERY, Datawarehouse o BILLING) oppure per cliente. Ovviamente le singole minacce avranno delle probabilità ed un impatto diverso nelle diverse aree.
Lo scenario attuale nell’ambito delle multinazionali è spesso diverso. La scelta di centralizzare l’organo decisionale delle policy, oltre a trascurare gli aspetti legislativi dei singoli stati, ha portato a definire un numero molto elevato di policy sui dispositivi informatici con moltissimi standard tecnici da applicare a sistemi, database, apparati di rete, middleware etc etc. L’obbligatorietà delle policy e dei relativi standard induce le varie country a chiedere budget su base estemporanea senza alcuna valutazione del rischio oltre ad avere un “mare magnum” di implementazioni impossibili da realizzare senza un’opportuna pianficazione.
Un’ultima considerazione riguarda i ruoli aziendali in merito alla sicurezza. E’ abbastanza usuale nelle aziende trovare un CSO (Chief Security Officer) ed un Compliance Manager ma decisamente raro che sia stato nominato un IT Security manager. Risultà altresì piuttosto complicato trovare un business o data owner che lavori sul trattamento del rischio prendendo le opportune decisioni sull’eventuale accettazione, eliminazione, trasferimento o mitigazione del rischio stesso.
In tale situazione le implementazioni di sicurezza sono quasi sempre una conseguenza di una non compliance relativa ad un audit, di un adeguamento normativo oppure vengono imposte dal team di governance centrale sulla base di programmi internazionali.
I enjoy the efforts you have put in this, appreciate it for all the great articles.