Nucleo comune: requisiti di sicurezza condivisi da ogni framework

Raramente le organizzazioni rispondono a un solo framework di sicurezza. Un'azienda di software vende a clienti statunitensi che chiedono un report SOC 2 e a clienti europei che chiedono ISO 27001; un fornitore di servizi di pagamento aggiunge PCI DSS; un fornitore digitale dell'UE rientra ora nel campo di applicazione della NIS2. Ogni framework arriva con una propria struttura, una propria numerazione e un proprio vocabolario, ed è facile concludere che ciascuno richieda un programma separato.

Non è così. Sotto la numerazione diversa c'è molto terreno comune, e una parte ristretta di esso è condivisa da ogni framework che mappiamo. Abbiamo cercato gli argomenti che hanno un requisito mappato in tutti gli undici: NIST CSF 2.0, NIST SP 800-53, ISO 27001, CIS Controls, SOC 2, PCI DSS, CMMC Level 2, la HIPAA Security Rule, GDPR, NIS2 e Essential Eight dell'ASD.

I cinque argomenti presenti in ogni framework

Argomento	ISO 27001	SOC 2	PCI DSS	NIS2
Gestione degli asset	A.5.9	CC6.1	12.5.1	12.4
Gestione delle vulnerabilità	A.8.8	CC7.1	6.3.1	6.5
Backup e ripristino	A.8.13	A1.2	9.4.1.1	4.2
Gestione degli incidenti	A.5.24	CC7.4	12.10.1	3.1
Segnalazione	A.5.5	CC2.3	12.10.1	3.3

5 di 50 argomenti hanno un requisito mappato in tutti i 11 framework. Ogni pagina di argomento elenca gli ID dei requisiti di ciascun framework e le evidenze per ogni collegamento.

Questo è il nucleo comune: gestione degli asset, gestione delle vulnerabilità, backup e ripristino, risposta agli incidenti e notifica degli incidenti. Ciascuno degli undici framework ha almeno un requisito per ognuno, anche GDPR, che è una normativa sulla privacy, e l'Essential Eight, che è un breve elenco di misure tecniche di mitigazione.

È un elenco volutamente breve. Molti altri argomenti, come controllo degli accessi, logging e cifratura, sono coperti da dieci degli undici framework, e la maggior parte dei framework condivide molti più di cinque argomenti. Ma questi cinque sono quelli che nessun framework omette.

Perché proprio questi cinque

Seguono il ciclo di vita di un incidente. Non si può proteggere ciò che non si sa di possedere (gestione degli asset). La maggior parte degli attacchi sfrutta ancora debolezze note (gestione delle vulnerabilità). Quando qualcosa va storto bisogna ripristinare sistemi e dati (backup e ripristino), gestire l'incidente (risposta agli incidenti) e informare chi deve saperlo: direzione, clienti, autorità di vigilanza (notifica degli incidenti).

I framework divergono su quasi tutto il resto: se la governance sia un sistema di gestione o un insieme di risultati, quanto debbano essere prescrittivi i controlli tecnici, con quale frequenza le attività debbano essere svolte. Su questi cinque, invece, concordano, perché senza di essi il resto non funziona.

Stesso argomento, diverso livello di dettaglio

Un argomento condiviso non significa un requisito identico. Prendiamo la gestione delle vulnerabilità:

Framework	Gestione delle vulnerabilità	Collegamento
NIST CSF 2.0	ID.RA-01ID.RA-08	Definizione dell'argomento
ISO 27001	A.8.8	Crosswalk
CIS v8.1	CIS 7.1CIS 7.2CIS 7.5CIS 7.6CIS 7.7CIS 16.6CIS 18.1CIS 18.2CIS 18.3CIS 18.4CIS 18.5	Crosswalk
SOC 2	CC7.1	Redazione
PCI DSS	6.3.111.3.111.3.2	Crosswalk
CMMC	RA.L2-3.11.2RA.L2-3.11.3	Crosswalk
800-53	RA-5CA-8	Crosswalk
HIPAA	§164.308(a)(1)(ii)(A)§164.308(a)(1)(ii)(B)§164.308(a)(8)	Crosswalk
GDPR	Art.32(1)(d)	Redazione
NIS2	6.56.10	Crosswalk
Essential Eight	ISM-1807ISM-1808ISM-1698ISM-1699ISM-1701ISM-1702	Redazione

Dettaglio completo e motivazione di ogni collegamento: Gestione delle vulnerabilità nei framework →

Il punto A.8.8 di ISO 27001 chiede di ottenere informazioni sulle vulnerabilità tecniche, valutare l'esposizione e adottare misure adeguate, lasciando la tempistica alla valutazione del rischio. PCI DSS richiede scansioni interne ogni tre mesi e dopo modifiche significative (11.3.1), scansioni esterne da parte di un Approved Scanning Vendor (11.3.2), e l'applicazione di patch per le vulnerabilità critiche e ad alta gravità entro un mese dal rilascio (6.3.3). L'Essential Eight fissa scadenze per le patch che si restringono a ogni livello di maturità. HIPAA affronta l'argomento attraverso i suoi requisiti di analisi e gestione del rischio, anziché con un requisito specifico sulle vulnerabilità.

Il nucleo comune quindi indica cosa ogni framework si aspetta che facciate, non quanto. Quando costruite un controllo, progettatelo in base al framework più stringente cui rispondete: gli altri di solito ne seguiranno il livello.

Come si presenta nella pratica

• Gestione degli asset: un unico inventario di hardware, software, servizi cloud e archivi di dati, con i responsabili indicati e mantenuto aggiornato con strumenti di discovery, non solo con fogli di calcolo.
• Gestione delle vulnerabilità: scansioni pianificate (interne ed esterne), una classificazione della gravità, scadenze di rimedio per gravità e prove che le scadenze siano rispettate.
• Backup e ripristino: backup di dati, software e configurazioni, protetti da modifiche e cancellazioni, con ripristini testati secondo un calendario.
• Risposta agli incidenti: un piano scritto con ruoli, livelli di gravità ed escalation, esercitato almeno una volta l'anno.
• Notifica degli incidenti: una procedura che stabilisca chi deve essere informato, entro quale termine e da chi: la direzione interna, i clienti con cui esistono contratti e le autorità di vigilanza (ad esempio, il preavviso (early warning) della NIS2 entro 24 ore o la notifica all'autorità di controllo entro 72 ore prevista dal GDPR).

Perché il nucleo conta

Se state avviando un programma di sicurezza, costruite prima questi cinque. Sono i requisiti che incontrerete in ogni framework che potreste adottare in seguito, quindi il lavoro non va mai sprecato.

Se gestite già più framework, usate il nucleo come base di un insieme comune di controlli: un controllo per ciascuno di questi argomenti, mappato su ogni framework cui rispondete, con le evidenze raccolte una sola volta. La stessa logica si estende agli argomenti condivisi da dieci, nove o otto framework. La nostra matrice di copertura mostra tutti i cinquanta argomenti rispetto agli undici framework, e la gap analysis mostra, requisito per requisito, cosa si trasferisce tra due framework qualsiasi.

Come l'abbiamo misurato

Ogni argomento in ControlMapping è definito dai risultati di NIST CSF 2.0 e riporta il requisito di ciascun framework che lo affronta. Un collegamento è indicato come Crosswalk quando un Crosswalk pubblicato (di NIST, ENISA, CIS o PCI SSC) lo supporta, ed è indicato come Redazione quando riflette il nostro giudizio, con la motivazione mostrata. I collegamenti per SOC 2, GDPR ed Essential Eight sono sempre di Redazione, perché per essi non esiste un Crosswalk con licenza aperta. Il metodo completo è nella pagina metodologia, e ogni numero citato sopra proviene dai dati in tempo reale, quindi si aggiorna quando cambiano le mappature.

Domande

Quali controlli di sicurezza sono richiesti da ogni framework?

Nei dati di ControlMapping, cinque argomenti hanno un requisito mappato in tutti gli 11 framework: gestione degli asset, gestione delle vulnerabilità, backup e ripristino, risposta agli incidenti e notifica degli incidenti. La formulazione esatta e il livello di dettaglio variano da framework a framework.

Soddisfare la versione di un framework basta anche per gli altri?

Non automaticamente. Una mappatura indica che i requisiti riguardano lo stesso argomento; uno dei due può essere molto più specifico (PCI DSS e Essential Eight fissano scadenze e frequenze che ISO 27001 lascia alla vostra discrezione). Verificate il testo di ciascun framework.