Uno dei più diffusi metodi per stabilire quale sia il grado di sicurezza IT di un’azienda è eseguire un security audit. Con il termine security audit (o anche security assessment) si intende una verifica dei sistemi effettuata prestando una particolare attenzione al livello applicativo. In pratica, definito un certo insieme di regole, si ricercano i comportamenti sotto le stesse. Per esempio, si può verificare che i sistemi siano allineati e che gli sviluppi siano fatti in ambiente develop e solo in un secondo tempo trasportati correttamente in produzione. Si può anche verificare se gli utenti di business o IT non abbiano autorizzazioni critiche in produzione oppure come sono fatte le connessioni tecniche tra i sistemi e se sono protette. Il numero di regole, che può variare in base al tipo di audit, solitamente viene definito in base alle specifiche esigenze.
Quando viene completato l’iter formale di approvazione dell’intervento, il processo prevede essenzialmente tre passaggi.
Security Audit, il primo passaggio – La configurazione
Perché risulti davvero efficace, quando sarebbe necessario in un’azienda effettuare un security audit? La risposta arriva da Domenico Rotundo, Specialist in ambito Security di Data Networking Consulting (DNC): “Solitamente, un security audit è un evento sporadico ed emergenziale, cui si ricorre per risolvere un problema che è emerso. Poi lo si dimentica. Niente di più sbagliato. Un security audit dovrebbe essere un evento sistematico la cui prima esecuzione andrebbe effettuata ancor prima di implementare un sistema. Ovviamente non è possibile eseguire un audit prima di avere il sistema configurato, ma durante la fase implementativa si può prevedere che sarà eseguito in un secondo tempo. Nel corso degli anni, ci siamo resi conto che in un progetto green field, in un roll out o in un upgrade di release è molto facile impostare regole e policy prima di rilasciare il sistema al business. È invece molto più complicato togliere alcuni privilegi di utilizzo a degli utenti dopo averglieli concessi per un certo tempo”.
Ciò che Rotundo evidenzia è che in fase di implementazione di un sistema è molto importante pensare, impostare e realizzare i ruoli business in conformità con la segregation duty e non in funzione delle richieste degli utenti, come invece spesso accade. Questo vale anche per il personale IT: non tutti devono potersi muoversi liberamente all’interno del sistema, bensì deve essere presente una gerarchia con precisi permessi di accesso.
Stabilite le regole, è necessario condividere gli elementi da ricercare/verificare partendo da un catalogo predefinito di controlli. Questo può essere deciso internamente se l’audit è interno, oppure può essere proposto dalla società che si occuperà dell’audit, ma in questo caso è bene prevedere la possibilità di personalizzazioni.
Secondo passaggio – L’esecuzione
Se il security audit è un evento sporadico ed emergenziale, non solo non consente di mantenere un adeguato livello di sicurezza, ma viene vissuto come un evento frustrante e affrontato in affanno. Per creare un’infrastruttura solida, il security audit dovrebbe invece essere un processo continuo. Come ulteriore punto a favore, aiuta anche a consolidare la cultura di governance.
D’altra parte, siccome i sistemi IT vengono aggiornati o modificati con una certa frequenza, le verifiche di audit sono soggette a obsolescenza. Perciò, un approccio strategico dovrebbe prevedere la verifica dei sistemi con cadenze cicliche, anche trimestrali, tramite un cruscotto ICFR (Internal Controlling Financial Reporting) o SAS con cui si possono controllare le autorizzazioni IT.
Come per tutti i tipi di audit, anche il security audit può essere eseguito dal personale interno oppure contando sull’appoggio di una società esterna. Ci sono casi, però, in cui non è possibile scegliere. Per esempio, per le società quotate l’audit esterno è un passaggio obbligato, mentre in generale aziende con fatturati molto rilevanti scelgono l’audit esterno per dare agli stakeholder e al mercato l’idea della trasparenza del loro operato.
È chiaro che un audit eseguito da un provider esterno non è influenzato da rapporti interaziendali e interpersonali. Ma qui sta anche il suo limite. Infatti, l’approccio maggiormente empatico con il business che può comportare un audit interno può dar vita a una più intensa collaborazione nello scambio documentale. “Questo – afferma Domenico Rotundo – spesso porta a identificare buchi di processo o errate configurazioni di sistema che realmente potrebbero recare danni economici all’azienda e che non è detto avrebbe individuato un audit fatto dall’esterno. Negli internal audit mi è capitato spesso di assistere a notevoli sforzi sinergici tra business e IT per sistemare processi e flussi”.
Terzo passaggio – Il monitoraggio e la gestione dei dati ottenuti
Organizzare un processo di monitoraggio permetterà nel momento (più temuto e teso) dell’audit esterno di avere migliori risultati. In effetti, il rilascio di una non conformità, rossa o gialla che sia, mette sempre una certa agitazione ai referenti di business e agli IT aziendali. Per contro, un audit interno tende a essere meno intransigenze su alcune mancanze da parte dell’ente controllato.
“Nel caso in azienda si usi SAP – precisa Rotundo – molte funzionalità inerenti il security audit, come la crittografia le password policy di iterazione, il SAL (Security Audit Log) o la tracciatura degli eventi non andati a buon fine, vanno attivate, spesso attraverso degli aggiornamenti software o add-on. Per scaricare i dati solitamente si installa un estrattore nel sistema oggetto delle analisi. In alternativa, può essere effettuato completamente tramite la tecnologia RFC (senza installare alcun software). In questo caso è necessario avere accesso diretto al sistema. Una volta effettuato lo scarico dei dati avviene l’elaborazione”.
Quando si esegue un security audit, le principali aree di ricerca sono le seguenti:
- Analisi di Segregation of Duties
- Ricerca delle attività degli amministratori di sistema, anche in capo ad utenti finali
- Utilizzo delle best practice nella profilazione
- Attivazione di audit Log e trace nei sistemi per capire chi ha fatto cosa
- Gestione delle autorizzazioni nei sistemi Human Resource.
- Verifica della conformità al GDPR
Effettuata l’elaborazione e l’analisi dei dati ottenuti, ogni scheda dell’audit riporta diversi elementi:
- che cosa viene ricercato e quale dovrebbe essere la situazione ideale;
- il risultato di quanto presente a sistema al momento dell’analisi dei dati;
- i commenti da parte di chi ha effettuato l’audit;
- eventuali azioni da eseguire affinché il controllo sia superato;
- eventuali allegati a supporto del finding rilevato;
- grado di criticità;
- eventuali schemi normativi di riferimento (per esempio: Dlgs. 231/2001, Legge 262/2005, Legge 300/1970, SoX, Dlgs. 196/2003, UE 679/2016 GDPR – Dlgs. 101/2018, ISO27001, ISO29134, ISO29151, ISO9001);
- schede di riferimento per ogni area di ricerca.
“A seguito di un security audit – conclude il Manager di DNC – è facile che si individuino alcuni interventi di rimedio, che possono essere effettuati in autonomia oppure con il supporto di un’azienda esterna. Qualunque sia la scelta, tali interventi devono essere eseguiti e non dimenticati. Inoltre, successivamente all’audit, è essenziale attivare degli strumenti per il monitoraggio costante della security, in particolare in ambiente SAP, e pianificare sessioni di verifica durante il tempo”.
