Cosa mi hanno insegnato 20 anni di cybersecurity sugli audit

Ho trascorso vent'anni nella cybersecurity, e gran parte di quel tempo è stata dedicata agli audit: prepararli, affrontarli, discutere dei rilievi e risolvere ciò che hanno fatto emergere. I framework sono cambiati più volte. Queste lezioni no.

1. Le evidenze battono la narrazione

Il rilievo di audit più comune non è un controllo mancante. È un controllo eseguito che però non si riesce a dimostrare. La revisione degli accessi è stata fatta, ma nessuno ha conservato l'elenco. La modifica è stata approvata in una chat poi cancellata. Gli auditor possono basarsi solo su ciò che riescono a vedere. Progettate controlli che lasciano evidenze come effetto collaterale della loro esecuzione, e la maggior parte dei rilievi scompare.

2. Il perimetro decide tutto

La maggior parte dei problemi negli audit risale al perimetro: definito troppo ampio, cosicché ogni sistema deve soddisfare ogni controllo; definito troppo ristretto, cosicché la certificazione non risponde alla domanda del cliente; oppure definito in modo vago, cosicché nessuno sa quali sistemi contano. Decidetelo deliberatamente, documentatelo e difendetelo. Il nostro articolo su come definire il perimetro del primo report SOC 2 vale per quasi ogni audit.

3. I controlli che falliscono sono quelli di cui nessuno è responsabile

Quando un controllo ha un responsabile nominato che lo esegue come parte del proprio lavoro, funziona. Quando appartiene genericamente a "IT" o "il team di sicurezza", si degrada fino alla settimana precedente l'audit. L'attribuzione di responsabilità è il miglioramento di controllo meno costoso che esista.

4. I documenti devono descrivere la realtà

Le policy standard che descrivono un'azienda che non siete sono peggiori di policy brevi che descrivono quella che siete davvero. Gli auditor verificano ciò che avete scritto. Ogni divario tra documento e pratica diventa un rilievo e, spesso, un problema di credibilità per tutto il resto di ciò che mostrate loro.

5. Gli auditor sono più utili come alleati che come avversari

Gli audit che vanno meglio sono quelli in cui il team considera l'auditor un secondo paio d'occhi anziché un avversario. Chiedete per tempo come testeranno un controllo. Dichiarate le debolezze note con un piano. Un rilievo sollevato da voi, con una correzione in corso, viene letto in modo molto diverso da uno che hanno dovuto scovare.

6. Il secondo framework dovrebbe costare poco

Le organizzazioni che gestiscono un programma per ogni framework pagano per intero ogni audit. Quelle che costruiscono un unico set di controlli, mappato su tutti i framework a cui rispondono, pagano quasi tutto una sola volta. Il lavoro di mappatura è noioso, ma rende sempre di più. È una delle ragioni principali per cui ho creato ControlMapping.

7. Framework diversi, stesse domande

Dopo un numero sufficiente di audit, i framework finiscono per confondersi. Gli auditor ISO, gli auditor SOC 2, i valutatori PCI e le autorità di vigilanza usano parole diverse, ma pongono le stesse poche domande: cosa rientra nel perimetro, chi ne è responsabile, come si sa che funziona e cosa succede quando non funziona? Un'organizzazione in grado di rispondere chiaramente a queste quattro domande, con evidenze, se la cava bene in quasi ogni audit. La matrice di copertura ne è un buon esempio: su undici framework, gli stessi argomenti centrali ritornano continuamente.

Punti chiave

• Progettate controlli che lasciano evidenze come effetto collaterale.
• Definite il perimetro deliberatamente e assegnate a ogni controllo un responsabile nominato.
• Considerate gli audit un sottoprodotto del gestire bene la sicurezza.

8. Superare l'audit non è l'obiettivo

Un audit senza rilievi significa che i controlli nel perimetro hanno funzionato sui campioni testati. Non significa che l'organizzazione sia sicura; la conformità non è sicurezza. I team migliori che ho visto trattano gli audit come un sottoprodotto del gestire bene la sicurezza, non come il suo scopo.

Se dovete portare via una sola cosa: decidete cosa fate, fatelo in modo coerente e lasciate che le evidenze si accumulino da sole. La gap analysis è un buon punto di partenza per capire quanto i vostri controlli attuali già coprono.

Domande

Qual è il motivo più comune dei rilievi di audit?

Per la mia esperienza, evidenze mancanti o incomplete per controlli effettivamente eseguiti: revisioni fatte ma non registrate, modifiche approvate verbalmente, popolazioni che non corrispondono.

Come bisogna prepararsi a un audit di sicurezza?

Eseguite i controlli in modo continuo e conservate le relative evidenze man mano, verificate che i documenti corrispondano alla pratica e ripercorrete voi stessi un campione prima che lo faccia l'auditor.

Dobbiamo dire all'auditor le debolezze che già conosciamo?

Di solito sì. Una debolezza che avete individuato, con un responsabile e un piano di rimedio, appare come un ambiente di controllo funzionante. Una che scopre l'auditor appare come una lacuna nella supervisione.