Il Metodo dell'Auditor: Pensare da IS Auditor

Un IS auditor non è assunto per trovare ogni bug o errore di configurazione in un sistema. Il lavoro è più ristretto e, onestamente, più difficile: capire se i controlli in place forniscono ragionevole assicurazione che i rischi per il business sono gestiti. Questa distinzione cambia come affronti quasi ogni compito, dalla lettura di un set di regole firewall all'intervista a un system owner.

Rischio prima, tecnologia dopo

Un penetration tester chiede "posso rompere questo?" Un auditor chiede "importa, e se fallisce, cosa succede al business?" Prima di toccare un singolo controllo, un auditor cerca di capire cosa fa il sistema, quali dati tocca, e cosa succederebbe se confidenzialità, integrità o disponibilità fossero compromesse. Questo è perché i programmi di audit solitamente iniziano con una valutazione dei rischi o una walkthrough, non una vulnerability scan.

Nello specifico: se stai revisionando i controlli di accesso su un sistema payroll, la prima domanda non è "l'MFA è abilitato?" È "qual è l'impatto se una persona non autorizzata può cambiare i dati dello stipendio o visualizzare PII?" Una volta che conosci l'impatto, puoi giudicare se i controlli esistenti (MFA, workflow di approvazione, segregazione di compiti) sono proporzionati.

Prove rispetto ad asserzioni

I system owner ti diranno che le cose funzionano. Il lavoro di un auditor è verificare, non fidarsi. Questo significa chiedere artefatti: uno screenshot di una schermata di configurazione, un'esportazione dei diritti di accesso degli utenti, un ticket di cambio con timestamp di approvazione, log entries che mostrano un controllo effettivamente eseguito. Se qualcuno dice "rivediamo l'accesso trimestralmente," l'auditor chiede di vedere gli ultimi tre record di revisione, non solo la policy che lo impone.

Questa abitudine basata su prove è ciò che separa un finding di audit da una conversazione nei corridoi. Un finding deve resistere allo scrutinio: cosa è stato testato, quale popolazione è stata campionata, quali criteri sono stati usati, e cosa è stato effettivamente osservato. Affermazioni vaghe come "i controlli sembrano adeguati" non reggono in un report che il management e i regolatori leggeranno.

Design vs. efficacia operativa

Una delle più utili divisioni mentali in questo campo è separare il design del controllo dall'operazione del controllo. Una policy di password che richiede 14 caratteri e MFA è ben progettata sulla carta. Ma se l'ultima access review è stata 11 mesi fa, o se gli account di servizio sono esentati senza documentazione, il controllo non sta operando come previsto. Gli auditor testano entrambi: il controllo esiste come descritto, e sta effettivamente venendo seguito giorno dopo giorno?

Ecco perché il campionamento importa. Testare l'accesso di un utente non ti dice molto. Estrarre un campione di 25 dipendenti terminati e verificare se i loro account sono stati disabilitati entro la finestra SLA (diciamo, 24 o 48 ore) ti dà una base difendibile per una conclusione.

Segregazione di compiti come tema ricorrente

Una parte enorme dei finding di audit risale a segregazione di compiti (SoD): la stessa persona che richiede un cambio lo approva anche, o uno sviluppatore ha accesso diretto al database di produzione insieme ai diritti di deployment. Gli auditor cercano questi sovrapposizioni costantemente, perché i fallimenti di SoD sono come frode e errori involontari scivolano via senza una seconda serie di occhi che li catturi.

Quando rivedi un ambiente, chiediti: chi può iniziare un'azione, chi può approvarla, e chi può eseguirla? Se una persona detiene due o più di questi ruoli senza un controllo compensativo (come logging dettagliato revisionato da qualcun altro), è un gap che vale la pena documentare.

Scrivere finding che vengono risolti

Un finding tecnicamente corretto su cui nessuno agisce è un audit sprecato. I buoni finding dichiarano la condizione (cosa è stato osservato), i criteri (la policy o lo standard che viola), la causa (perché è successo), e l'effetto (quale rischio ciò crea) — la struttura classica 4C che molti audit shop usano. Finding vaghi come "i controlli di accesso hanno bisogno di miglioramenti" vengono ignorati. Quelli specifici come "14 di 25 dipendenti terminati campionati hanno mantenuto l'accesso VPN per più di 5 giorni dopo la loro data di terminazione, violando l'SLA di deprovisioning di 24 ore nella policy SEC-014" vengono rimediati perché l'owner sa esattamente cosa correggere.

Sviluppare l'abitudine

Sviluppi questa prospettiva praticandola su sistemi ordinari, non solo su impegni formali. Scegli un'applicazione che usi quotidianamente e chiediti: qual è il rischio se fallisce, quali controlli esistono, e come proverei che funzionano? Fai questo abbastanza volte e l'istinto dell'auditor — scetticismo accoppiato a una domanda di prove — diventa automatico.

Se questo tipo di pensiero su controlli e rischi ti interessa, consulta i segmenti di Korra Studio su modelli di controllo di accesso e framework di security governance per un fondamento tecnico più profondo.