L’audit dei sistemi informativi

Oggi parlerò di un argomento poco noto ai verinerd™: Information System Audit.

Prima di intraprendere un lungo discorso definiamo cos’è un audit (si dovrebbe leggere audit perché è una parola latina ma ormai è uso comune dirla in versione inglese):

Processo sistematico tramite il quale una persona competente ed indipendente ottiene e valuta in maniera oggettiva evidenze relative a determinati ambiti allo scopo di formarsi una opinione ed emettere una relazione sul grado di conformità, rispetto ad un insieme predefinito di standards, di tali ambiti.

Qualunque audit che comprenda l’analisi e la valutazione, totale o parziale, di sistemi automatizzati di elaborazione dati, dei processi manuali ad essi correlati e delle relative interfacce è un IS audit.

Missione dell’IS Audit

L’obiettivo dell’Information System Audit è di assicurare che i sistemi informativi:

• Tutelino adeguatamente gli asset aziendali. Un asset è un qualunque elemento che è all’interno di un ambiente che deve essere protetto. Se l’azienda definisce un valore su un elemento sotto il suo controllo e ritiene che esso sia abbastanza importante da proteggere, sarà oggetto di gestione ed analisi del rischio.
• Mantengano l’integrità dei dati. Più in generale, termini come confidenzialità, integrità e disponibilità sono considerati tra i più importanti principi di sicurezza. Tuttavia, l’importanza di ciascuno dipende da obiettivi e da requisiti di sicurezza propri dell’azienda. Sono valutati anche altri aspetti quali la privacy, la responsabilità (inteso come obbligo, il termine più appropriato è accountability), non ripudio.
• Raggiungano gli obiettivi dell’organizzazione in modo efficace ed efficiente. Senza troppi giri di parole bisogna salvaguardare gli interessi degli stakeholder, ovvero gli azionisti, gli amministratori, etc.
• Conferiscano valore aggiunto. Identificare aspetti di riduzione del rischio e appropriate azioni conseguenti che forniscono valore aggiunto, derivante dalla riduzione dei rischi.

L’analisi dei rischi

La sicurezza è volta a prevenire la perdita o la divulgazione di dati sostenendo al tempo stesso l’accesso autorizzato. La possibilità che possa accadere qualcosa che possa danneggiare, distruggere, o divulgare dati è conosciuto come rischio. L’ISO/IEC 13335-1 definisce rischio La possibilità che una data minaccia si concretizzi facendo breccia nei punti di vulnerabilità di un bene (asset) o di un gruppo di beni, con danno per l’organizzazione.

L’obiettivo primario della gestione del rischio è quello di ridurre il rischio a un livello accettabile, dipendente comunque dagli obiettivi di business, dal valore degli asset e dal budget disponibile.

Il processo attraverso il quale si realizza l’obiettivo primario della gestione del rischio è noto come analisi dei rischi. Tale attività, chiamata anche risk assessment, si caratterizza come un’iterazione ciclica (PDCA: plan-do-check-act) che parte con l’identificazione degli obiettivi di business, del patrimonio informativo e dei sistemi sottostanti o delle risorse informatiche che producono/salvano, utilizzano o elaborano le risorse (hardware, software, database, persone, ecc.) critiche per conseguire questi obiettivi.

Una volta identificate le risorse informative, sensibili e/o critiche, si esegue una valutazione dei rischi, identificandoli e determinando la probabilità di accadimento, l’impatto risultante e le protezioni aggiuntive che ridurrebbero questo effetto ad un livello considerato come accettabile al management.

Controlli

Come abbattere o limitare i rischi identificati? Attraverso la predisposizione/integrazione di controlli. I controlli sono politiche (policy), procedure, prassi e le strutture organizzative messe in atto per ridurre i rischi, dando sufficiente garanzia che gli obiettivi di business vengano raggiunti.

Servono principalmente per salvaguardare gli asset, per aderire alle politiche aziendali (conformance) ed alle normative vigenti (compliance), assicurare che le abilitazioni per gli accessi ai sistemi informativi siano coerenti con le autorizzazioni definite (Segregation of Duties), fornire elevata accuratezza e completezza delle transazioni e dell’elaborazione dei dati immessi nel sistema, garantire l’affidabilità delle elaborazioni, dei backup e, soprattutto, dei restore e produrre efficienza ed economicità dell’esercizio.

La tassonomia dei controlli varia in base al modello adottato dalle associazioni di professionisti (ISACA, ISC2, ASIS, ISSA, SANS, etc.) che hanno scritto centinaia di gigabyte di documentazione a supporto, ma secondo me quella più completa è quella definita da ISC2:

• direttivo: finalizzato ad attuare o incoraggiare azioni ed eventi necessari per il raggiungimento degli obiettivi. Ad esempio sono le procedure, le policy, gli standard, linee guida, leggi, regolamenti;
• preventivo: finalizzato a prevenire il verificarsi di inefficienze, errori o irregolarità, il dissesto di processi, la mancanza di correttezza nella autorizzazioni e nell’utilizzo delle attività. Ha una funzione inibitoria. Ad esempio sono il controllo degli accessi, una porta chiusa a chiave, le dogane;
• investigativo o di rilevazione: finalizzato ad individuare e correggere errori, inefficienze o irregolarità. Questo tipo di controllo non fornisce una completa efficacia perché è svolto dopo il verificarsi di un evento o dopo che un prodotto è stato erogato. Può però ridurre il rischio di conseguenze indesiderabili perché consente di attuare azioni correttive. Ad esempio l’analisi dei log, telecamere a circuito chiuso, IDS, antivirus, software di vulnerability assessment (Nessus);
• correttivo: sono istruzioni, procedure e linee guida usate per invertire gli effetti di un’azione non voluta, come attacchi al sistema ed errori. Ad esempio sono: logging/journaling dei file system, installazione di patch di sicurezza, impianto di antincendio;
• di ripristino: qualunque azione atta a recuperare lo stato di un sistema a seguito di un incidente. Ad esempio i restore dei backup, reboot di una macchina, sistemi fault-tolerant, punti di ripristino del sistema operativo.

Testing

Abbiamo analizzato i rischi, ci siamo fatti dire (e dare) i controlli predisposti dall’azienda, vediamo se è tutto oro ciò che luccica? Test di conformità e di sostanza. Il test di conformità è la raccolta di evidenze al fine di verificare la conformità dell’organizzazione con le procedure di controllo. Si contrappone al test di sostanza, in cui si raccolgono evidenze per valutare l’integrità di singole transazioni, dati o altre informazioni.

Un test di conformità stabilisce se i controlli siano effettuati in modo da aderire alle politiche e alle procedure della direzione. L’obiettivo generale di qualsiasi test di conformità è dare all’IT auditor una garanzia sufficiente che un particolare controllo, sul quale egli pensa di fare affidamento, stia operando come prefigurato nella valutazione preliminare.

Un test di sostanza fornisce evidenza sull’integrità dell’elaborazione effettiva. Immaginate di voler verificare se la vostra banca, che eroga mutui, calcoli e applichi correttamente gli interessi che avete concordato alla stipula del contratto.

La procedura si dovrebbe occupare di calcolare le differenze tra il piano di ammortamento finanziario (che si trova tra le mille pagine che forniscono) e i prelievi che mensilmente fa la banca ai mutuanti.

Se trovate delle differenze accettabili, dovute ad arrotondamenti o a variazioni del piano perché in un determinato mese applicavano interessi diversi allora va tutto bene, altrimenti passerete notti insonni per capire gli scostamenti oggetto di materialità.

Comunicazione dei risultati

Finalmente il lavoro è finito, è stato lungo, noioso e faticoso ma ce l’abbiamo fatta. E quindi? Cosa è emerso? Va tutto bene? Va tutto male? Va tutto? L’intervista conclusiva, condotta alla fine del lavoro, consente all’IT auditor di discutere con la direzione i rilievi e le raccomandazioni. In tale occasione si possono esporre gli obiettivi e la copertura dell’audit e fornire spiegazioni sul processo di audit.

Durante l‘intervista conclusiva, l’IT auditor dovrebbe assicurarsi che i fatti menzionati nel rapporto di audit siano corretti, assicurarsi che le raccomandazioni siano fattibili ed economicamente praticabili; in caso contrario può cercare di negoziare soluzioni alternative con il management dell‘area sottoposta ad audit e consigliare le scadenze per l’applicazione delle raccomandazioni concordate. Quindi sono state identificate problematiche? Condividere i risultati e proporre un piano di remediation per le aree più critiche.

Non mi dilungo più di tanto su questo punto perché non esiste un modo preciso per condividere i risultati, posso assicurare che è lo step cruciale del lavoro perché è il risultato del tempo speso (e perso) nell’identificare e valutare tutti i punti precedenti.

Conclusioni

L’IT auditor non è un programmatore, non è un sistemista, non è un web designer, non è un system architect, non è un DBA, ma deve sapere esattamente cosa fanno tutti questi specialisti perché deve essere in grado di relazionarsi con loro per comprendere come i processi di business funzionino nel contesto di un sistema informativo.