Mappare una serie di policy su più framework, senza riscriverle

Uno schema ricorrente: un'azienda redige un set di policy per ISO 27001; poi un cliente chiede SOC 2 e qualcuno acquista un secondo pacchetto di template; infine arriva PCI DSS con i propri requisiti. Tre set di policy sovrapposti, ognuno leggermente obsoleto, nessuno che corrisponda a ciò che le persone fanno davvero. Le policy non devono essere specifiche per framework. Devono essere specifiche per l'organizzazione, e mappate.

Struttura: tre livelli

1. Una policy per la sicurezza delle informazioni: breve, approvata dalla direzione, che definisce obiettivi, ambito, responsabilità e impegno. Sia ISO 27001 al punto 5.2 sia PCI DSS 12.1.1 la richiedono.
2. Politiche per argomento (una dozzina circa): controllo degli accessi, uso accettabile, gestione degli asset, crittografia, risposta agli incidenti, continuità operativa, sicurezza dei fornitori, sviluppo sicuro, gestione delle vulnerabilità e delle patch, logging e monitoraggio, sicurezza fisica, sicurezza delle risorse umane.
3. Procedure e standard a un livello inferiore, dove vivono le frequenze, le configurazioni e i passaggi operativi. Cambiano più spesso e non dovrebbero richiedere ogni volta l'approvazione della direzione.

Inserite i dettagli specifici di ciascun framework nelle procedure, non nelle policy: « l'accesso viene verificato ogni sei mesi » appartiene alla procedura di revisione degli accessi, dove può trovare posto la frequenza richiesta da PCI DSS senza appesantire la policy.

Mappare, non riscrivere

Tenete una tabella di mappatura: una riga per ogni sezione della policy, con i requisiti che essa copre in ciascun framework. L'argomento Governance Policy mostra cosa si aspetta ciascun framework al livello più alto:

Framework	Politica di governance	Collegamento
NIST CSF 2.0	GV.PO-01GV.PO-02	Definizione dell'argomento
ISO 27001	A.5.1A.5.37Clause 5.2	Crosswalk
CIS v8.1	—	Nessuna mappatura nei nostri dati
SOC 2	CC5.3CC1.1	Redazione
PCI DSS	12.1.112.1.2	Crosswalk
CMMC	—	Nessuna mappatura nei nostri dati
800-53	PM-1PL-1	Crosswalk
HIPAA	§164.316(a)§164.316(b)(2)(iii)	Crosswalk
GDPR	Art.24(2)	Redazione
NIS2	1.1	Crosswalk
Essential Eight	—	Nessuna mappatura nei nostri dati

Dettaglio completo e motivazione di ogni collegamento: Politica di governance nei framework →

Quando arriva un nuovo framework, eseguite una Gap analysis e verificate i requisiti di governance e policy: la maggior parte corrisponderà a una policy che già possedete; i restanti diventeranno nuove sezioni o procedure.

Cosa richiedono per iscritto i framework

• ISO 27001: una policy per la sicurezza delle informazioni (5.2) e politiche specifiche per argomento secondo necessità (A.5.1), comunicate e riesaminate.
• SOC 2: policy che stabiliscono cosa ci si attende, attuate tramite procedure (CC5.3).
• PCI DSS: per ciascuno dei suoi dodici requisiti, policy e procedure documentate e aggiornate (x.1.1) e ruoli assegnati (x.1.2), riesaminate almeno una volta l'anno.
• NIS2: una policy sulla sicurezza dei sistemi informativi e di rete e politiche specifiche per argomento (punto 1 del Regolamento di esecuzione).
• NIST CSF 2.0: la policy è stabilita, comunicata e applicata (GV.PO).

Un set minimo di policy

Per la maggior parte delle organizzazioni piccole e medie, questi documenti coprono i requisiti in materia di policy di ISO 27001, SOC 2, NIST CSF, PCI DSS e NIS2:

1. Policy per la sicurezza delle informazioni (livello superiore, approvata dalla direzione)
2. Policy di uso accettabile
3. Policy di controllo degli accessi
4. Policy di gestione degli asset e classificazione dei dati
5. Policy di crittografia
6. Policy di sviluppo sicuro e gestione dei cambiamenti
7. Policy di gestione delle vulnerabilità e delle patch
8. Policy di logging e monitoraggio
9. Policy di risposta agli incidenti (con gli obblighi di notifica)
10. Policy di continuità operativa e backup
11. Policy di sicurezza dei fornitori
12. Policy di sicurezza delle risorse umane
13. Policy di sicurezza fisica

Tredici documenti, la maggior parte lunga poche pagine, ciascuno con un responsabile e una data di revisione. Le procedure contengono il dettaglio e cambiano più spesso.

Punti chiave

• Le policy dovrebbero essere specifiche per l'organizzazione e mappate, non specifiche per framework.
• Inserite frequenze e configurazioni nelle procedure.
• Tredici policy brevi coprono la maggior parte dei framework.
• PCI DSS richiede che le proprie policy e procedure siano riesaminate almeno una volta l'anno.

Mantenerle aggiornate

• Scrivete ciò che fate, non ciò che dice un template. Gli auditor verificano le policy rispetto alla pratica.
• Riesaminatele annualmente e dopo ogni cambiamento significativo, con un'approvazione registrata.
• Breve è meglio di completo: una policy di controllo degli accessi di due pagine che le persone leggono è migliore di venti pagine che nessuno legge.

Per un set completo di controlli comuni basato sulla stessa idea, vedete un unico set di controlli per SOC 2 e ISO 27001.

Domande

Quante policy di sicurezza servono?

Meno di quante ne suggeriscano la maggior parte dei template. Una policy per la sicurezza delle informazioni di livello superiore, più una dozzina circa di policy per argomento (accessi, uso accettabile, risposta agli incidenti, sicurezza dei fornitori e così via), di solito copre ISO 27001, SOC 2, NIST e PCI DSS.

PCI DSS richiede policy specifiche?

Sì. Ogni requisito di PCI DSS inizia con l'obbligo di avere policy e procedure documentate e aggiornate per quell'area (x.1.1), oltre a ruoli e responsabilità (x.1.2).