Penetration test in Arabia Saudita: i controlli ECC 2-10 e 2-11 dell'NCA e le frequenze CSCC per i sistemi critici

La National Cybersecurity Authority (NCA) fissa con gli Essential Cybersecurity Controls (ECC) i requisiti minimi di cybersecurity per i soggetti nazionali. La versione attuale è l'ECC-2:2024, che aggiorna l'ECC-1:2018. Secondo il loro ambito, i controlli si applicano a:

• Enti governativi del Regno dell'Arabia Saudita, compresi ministeri, autorità ed enti, e alle società ed entità a essi collegate, in Arabia Saudita e all'estero.
• Soggetti privati che possiedono, gestiscono o ospitano infrastrutture critiche nazionali (CNI).

L'NCA incoraggia tutti gli altri soggetti del Regno a usare i controlli come buona pratica. Ogni soggetto deve rispettare tutti i controlli che gli sono applicabili; alcuni dipendono dalle tecnologie usate, per esempio i controlli sul cloud valgono per chi usa o prevede di usare servizi cloud.

La conformità è continua, non una certificazione una tantum. In base all'articolo 10(3) dello Statuto dell'NCA e all'High Order n. 57231, i soggetti nel perimetro devono adottare tutte le misure necessarie per un rispetto costante e continuo, e l'NCA lo verifica tramite autovalutazioni, report periodici del suo strumento di conformità e visite ispettive. Il documento precisa che per il significato e l'interpretazione fa fede la versione araba.

Il sottodominio 2-10 mira a rilevare tempestivamente e correggere efficacemente le vulnerabilità tecniche, per prevenirne o ridurne la probabilità di sfruttamento.

• 2-10-1: i requisiti di cybersecurity per la gestione delle vulnerabilità tecniche sono definiti, documentati e approvati.
• 2-10-2: quei requisiti sono attuati.
• 2-10-3 fissa il contenuto minimo:
• 2.10.3.1: vulnerability assessment e rilevazione periodici.
• 2.10.3.2: classificazione delle vulnerabilità per gravità.
• 2.10.3.3: correzione in base a quella classificazione e ai rischi cyber associati.
• 2.10.3.4: patch management, con integrità ed efficacia di aggiornamenti e correzioni verificate in un ambiente non di produzione prima dell'applicazione.
• 2.10.3.5: comunicazione e iscrizione a fonti affidabili sulle nuove vulnerabilità.
• 2-10-4: l'attuazione di questi requisiti è riesaminata periodicamente.

Il vulnerability assessment compare anche prima, nella gestione di progetti e modifiche: il 1-6-2 richiede come minimo vulnerability assessment e correzione, e la verifica di configurazione sicura, hardening e pacchetti di aggiornamento, prima che progetti e modifiche entrino in esercizio.

Il sottodominio 2-11 ha un obiettivo chiaro: valutare e verificare l'efficacia delle capacità di difesa del soggetto simulando metodi e tecnologie di attacco reali, per scoprire debolezze sconosciute che potrebbero portare a una violazione.

• 2-11-1: i requisiti di cybersecurity per il penetration test sono definiti, documentati e approvati.
• 2-11-2: quei requisiti sono attuati.
• 2-11-3 fissa il contenuto minimo:
• 2.11.3.1: il perimetro comprende tutti i servizi erogati verso l'esterno (via internet) e i loro componenti tecnici, tra cui infrastruttura, siti web, applicazioni web, app per smartphone e tablet, posta elettronica e accesso remoto.
• 2.11.3.2: i penetration test sono eseguiti periodicamente.
• 2-11-4: l'attuazione di questi requisiti è riesaminata periodicamente.

Due aspetti saltano all'occhio. Il perimetro minimo è la superficie d'attacco esterna, elencata in dettaglio; i sistemi interni non fanno parte del minimo ECC, anche se l'obiettivo di scoprire debolezze che portano a una violazione è difficile da raggiungere senza di essi. E l'ECC non fissa la periodicità: è ciò che aggiungono i CSCC per i sistemi critici.

I Critical Systems Cybersecurity Controls (CSCC-1:2019) estendono l'ECC ai sistemi critici nazionali. Si applicano ai sistemi che le organizzazioni che li possiedono o li gestiscono considerano critici, siano esse enti governativi in Arabia Saudita o all'estero, oppure società controllate da enti governativi o private. È critico un sistema il cui guasto, modifica o accesso non autorizzato, o la compromissione dei cui dati, può danneggiare i servizi dell'organizzazione o avere impatti economici, finanziari, di sicurezza o sociali a livello nazionale. Tra i criteri di identificazione: impatto sulla sicurezza nazionale, perdite finanziarie significative (oltre lo 0,01% del PIL), impatto su servizi usati da oltre il 5% della popolazione, perdita di vite umane, divulgazione di dati classificati Top Secret o Secret, impatto su settori vitali.

Per questi sistemi i CSCC fissano intervalli precisi:

• 2-9-1-1: metodi e strumenti affidabili per il vulnerability assessment.
• 2-9-1-2: valutazione e correzione delle vulnerabilità sui componenti tecnici dei sistemi critici almeno una volta al mese per i sistemi esterni e connessi a internet, e almeno una volta ogni tre mesi per i sistemi critici interni.
• 2-9-1-3: correzione immediata delle vulnerabilità critiche, nel rispetto del change management approvato.
• 2-9-2: con riferimento all'ECC 2-10-3-1, vulnerability assessment sui componenti tecnici dei sistemi critici almeno una volta al mese.
• 2-10-1-1: il perimetro del penetration test copre tutti i componenti tecnici del sistema critico e tutti i suoi servizi interni ed esterni.
• 2-10-1-2: penetration test eseguiti da un team qualificato.
• 2-10-2: con riferimento all'ECC 2-11-3-2, penetration test sui sistemi critici almeno una volta ogni sei mesi.
• 1-4-1 e 1-4-2: la funzione cybersecurity riesamina l'attuazione dei CSCC almeno una volta l'anno, e soggetti indipendenti interni all'organizzazione, esterni alla funzione cybersecurity, la riesaminano almeno ogni tre anni.

I CSCC rimandano ai sottocontrolli ECC 2-10-3-1 e 2-11-3-2, che nell'ECC-2:2024 mantengono la stessa numerazione.

Scritto nei controlli:

• ECC: requisiti documentati e approvati per gestione delle vulnerabilità e penetration test, attuati e riesaminati periodicamente; vulnerability assessment periodico con correzione in base alla gravità; penetration test periodici su tutti i servizi erogati verso l'esterno; vulnerability assessment prima dell'entrata in esercizio di progetti e modifiche; riesame e audit indipendenti dei controlli.
• CSCC, per i sistemi critici: vulnerability assessment mensile, correzione mensile o trimestrale a seconda dell'esposizione, correzione immediata delle vulnerabilità critiche, penetration test su tutti i servizi interni ed esterni almeno ogni sei mesi da parte di un team qualificato.

Non scritto in questi testi:

• Una periodicità fissa per i penetration test dei sistemi non critici: «periodicamente» è l'intervallo che stabilisci, documenti, fai approvare e sai difendere.
• L'obbligo di un tester esterno o accreditato. L'ECC non dice chi testa; i CSCC chiedono un team qualificato. Il requisito di indipendenza dell'ECC 1-8 riguarda il riesame e l'audit dei controlli, non ogni singolo test.
• Il red teaming come controllo a sé. Il sottodominio 2-11 descrive la simulazione di metodi di attacco reali, cioè la definizione di penetration test, non un'esercitazione avversaria distinta.

I regolatori di settore possono aggiungere requisiti propri a quelli dell'ECC: verifica anche gli strumenti che si applicano al tuo settore.

1. Stabilisci quali sistemi sono critici con i criteri dei CSCC e documenta la decisione. Tutto il resto del programma dipende da questo elenco.
2. Censisci i servizi erogati verso l'esterno indicati al 2.11.3.1: infrastruttura, siti web, applicazioni web, app mobili, posta elettronica e accesso remoto. È il perimetro minimo del penetration test per ogni sistema nell'ambito dell'ECC.
3. Metti per iscritto i requisiti e falli approvare (2-10-1 e 2-11-1), compresi gli intervalli scelti per i sistemi non critici e le relative ragioni.
4. Applica la cadenza CSCC ai sistemi critici: vulnerability assessment mensile, correzione mensile o trimestrale e un penetration test almeno ogni sei mesi che copra i servizi interni oltre a quelli esterni.
5. Testa prima dell'entrata in esercizio: vulnerability assessment e correzione per ogni progetto e modifica (1-6-2), e patch verificate in ambiente non di produzione (2.10.3.4).
6. Riesamina periodicamente (2-10-4, 2-11-4) e organizza il riesame e l'audit indipendenti previsti dal 1-8, con gli esiti presentati come richiede il 1-8-3.

• I documenti dei requisiti approvati per gestione delle vulnerabilità e penetration test (2-10-1, 2-11-1).
• L'elenco dei sistemi critici con i criteri applicati, e l'inventario dei servizi erogati verso l'esterno.
• I registri di vulnerability assessment con classificazione di gravità, decisioni di correzione basate sul rischio e date che dimostrino la cadenza mensile sui sistemi critici.
• I registri delle patch che mostrino la verifica in ambiente non di produzione prima del rilascio.
• I report di penetration test con perimetro, data e team, che dimostrino la copertura di ogni servizio esterno e, per i sistemi critici, di tutti i servizi interni ed esterni almeno ogni sei mesi.
• Le valutazioni prima dell'entrata in esercizio di progetti e modifiche.
• I riesami periodici e gli esiti degli audit indipendenti presentati al comitato di supervisione cybersecurity e all'Authorized Official, con perimetro, osservazioni, raccomandazioni, azioni correttive e piani di rimedio (1-8-3).

Un red team AI autonomo per reti e infrastrutture non approva i tuoi requisiti, non è il riesame indipendente dell'ECC 1-8 e non decide da solo se i tuoi tester sono il team qualificato che chiedono i CSCC. Rende più facile sostenere la cadenza richiesta dai controlli, su un'infrastruttura che controlli tu. Per la categoria vedi penetration test automatizzato.

• Mensile e semestrale senza buchi. Campagne black box a calendario sui servizi esterni e gray box con i privilegi di un utente standard all'interno della rete, agli intervalli dei CSCC e dopo ogni modifica: l'assessment mensile e il test semestrale non dipendono da un'unica finestra di incarico.
• Gravità basata su prove. Ogni finding indica se è stato dimostrato sfruttabile nel tuo ambiente, il dato che serve alla correzione basata sul rischio del 2.10.3.3, e ogni correzione si può ritestare con la stessa prova.
• Approvazione umana dei passi rischiosi. Cinque livelli di autonomia definiscono cosa deve attendere un operatore, e i proof of concept di exploit possono restare in attesa di revisione. Vedi human in the loop.
• Mappatura e registri. Saudi NCA è tra i 34 framework su cui il motore mappa i finding, con report di conformità esportabili; il collegamento dei report a 2-10, 2-11 e ai controlli CSCC resta nella tua documentazione. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256 per campagna, verificabile offline.
• I dati restano nel Regno. I modelli girano sull'appliance, senza servizi AI esterni, e nessun dato del cliente ne esce; in modalità air-gapped sono disattivati anche i download da fonti pubbliche. Vedi red team AI on-premise e la guida all'acquisto di una piattaforma di pentest on-premise.

• NCA: pagina degli Essential Cybersecurity Controls (nca.gov.sa)
• NCA Essential Cybersecurity Controls ECC-2:2024, versione inglese, ambito, 1-6, 1-8, 2-10 e 2-11 (PDF, nca.gov.sa)
• NCA: pagina dei Critical Systems Cybersecurity Controls (nca.gov.sa)
• NCA Critical Systems Cybersecurity Controls CSCC-1:2019, ambito, criteri, 1-4, 2-9 e 2-10 (PDF, nca.gov.sa)