Smetti di comprare strumenti di compliance prima di aver scritto le policy

Una sequenza familiare: l'azienda deve ottenere SOC 2 o ISO 27001, qualcuno fa ricerche e il primo acquisto è uno strumento: una piattaforma di compliance, una suite per gli endpoint, un SIEM, un generatore di policy. Mesi dopo lo strumento è configurato a metà, i suoi alert vengono ignorati e l'auditor pone domande a cui non sa rispondere. Lo strumento non era il problema. Il problema era l'ordine.

Gli strumenti implementano decisioni

Ogni controllo richiede alcune decisioni prima che qualsiasi strumento sia utile: cosa rientra nel perimetro, chi ne è responsabile, con quale frequenza viene eseguito, cosa significa "buono" e cosa succede quando fallisce. Queste decisioni sono le vostre policy e procedure. Acquistare uno scanner di vulnerabilità senza di esse significa ottenere migliaia di risultati di cui nessuno risponde; acquistare un SIEM senza di esse significa avere log che nessuno legge.

I framework concordano

Nessun framework di riferimento richiede un prodotto specifico. ISO 27001 chiede policy, trattamento dei rischi e controlli che siano operativi. SOC 2 verifica se i controlli sono progettati e operano in modo efficace. PCI DSS inizia ciascuno dei suoi dodici requisiti con policy e procedure documentate e ruoli assegnati. Tutti presuppongono che la riflessione venga prima.

Un ordine migliore

1. Perimetro e rischio: cosa stiamo proteggendo, da cosa, e quali framework si applicano? Una gap analysis mostra cosa aggiunge il framework successivo a ciò che già avete.
2. Decidere ogni controllo: responsabile, frequenza, standard ed evidenze. Scrivetelo in breve: questo è il vostro insieme di policy (vedi un unico insieme di policy per molti framework).
3. Eseguitelo prima manualmente, dove possibile. Una verifica trimestrale degli accessi in un foglio di calcolo vi insegna cosa deve fare lo strumento.
4. Poi acquistate strumenti che automatizzino decisioni già prese, e valutateli in base a tali decisioni.

Quando gli strumenti vengono prima, e il lavoro

Ci sono eccezioni. La protezione degli endpoint, l'MFA e i backup meritano di essere implementati immediatamente perché il loro valore non dipende da una messa a punto. E le piattaforme di compliance che aiutano a scrivere policy e a tracciare i controlli possono accelerare il secondo passo, purché si trattino i loro modelli e le mappature come bozze, non come risposte (abbiamo scritto dei Crosswalk che non si possono verificare).

Come appare decidere prima

Prendete la gestione delle vulnerabilità, il controllo più spesso acquistato come prodotto. Prima di scegliere uno scanner, decidete:

• Perimetro: quali asset vengono scansionati (interni, esterni, cloud, container) e come saprete che l'elenco degli asset è completo.
• Frequenza: PCI DSS richiede scansioni interne ogni tre mesi e dopo modifiche significative; i CIS Controls chiedono scansioni automatizzate degli asset interni ed esterni; il vostro rischio specifico potrebbe richiederne di più.
• Gravità e scadenze: come vengono valutati i risultati e quanto rapidamente ogni livello di gravità deve essere risolto.
• Responsabilità: chi effettua il triage dei risultati, chi li risolve e chi accetta il rischio quando qualcosa non può essere corretto.
• Evidenze: quale report dimostra che il controllo è stato eseguito e che i risultati sono stati gestiti.

Con queste cinque risposte scritte, la valutazione di uno strumento diventa semplice: copre il perimetro, viene eseguito con la frequenza richiesta, valuta la gravità secondo le vostre regole e produce le evidenze? Senza di esse, ogni demo sembra impressionante e nessuna risponde al vostro audit. Lo stesso esercizio vale per il logging, la protezione degli endpoint e la gestione degli accessi. Le nostre pagine sugli argomenti mostrano cosa richiede ogni framework per ciascun controllo, una buona checklist per le decisioni, e l'argomento gestione delle vulnerabilità è un buon punto di partenza.

Punti chiave

• Gli strumenti implementano decisioni; acquistateli dopo aver deciso perimetro, responsabili, frequenza ed evidenze.
• Nessun framework di riferimento richiede un prodotto specifico.
• Eseguite prima manualmente un controllo, se possibile, poi automatizzatelo.

Il test

Prima di acquistare, chiedetevi: quale controllo implementa questo strumento, chi è responsabile di quel controllo e quali evidenze produrrà? Se nessuno sa rispondere, l'acquisto è prematuro.

Domande

Cosa dovrebbe venire prima, le policy o gli strumenti?

Prima le decisioni: perimetro, rischi e modalità operativa di ogni controllo (chi, con quale frequenza, con quale standard). Una volta messe per iscritto, queste decisioni sono le vostre policy e procedure; gli strumenti poi le implementano.

Gli auditor richiedono strumenti specifici?

Nessun framework di riferimento richiede un prodotto specifico. Gli auditor verificano che i controlli siano operativi e producano evidenze, indipendentemente da come siano implementati.

Vale la pena avere una piattaforma di automazione della compliance?

Può valerne la pena, una volta che si sa quali controlli si eseguono e chi ne è responsabile. Le piattaforme sono utili per promemoria, raccolta delle evidenze e tracciamento; non possono decidere al posto vostro il perimetro o la propensione al rischio.