Penetration test nel Regno Unito: il CBEST per il settore finanziario e il Cyber Assessment Framework dell'NCSC

Nel Regno Unito non esiste un'unica regola sul penetration test. Per la maggior parte dei soggetti regolati contano due framework, che rispondono a domande diverse.

• CBEST è una valutazione di vigilanza per il settore finanziario. Dal 2014 fa parte degli strumenti comuni di Bank of England, Prudential Regulation Authority (PRA) e Financial Conduct Authority (FCA) per valutare la resilienza cyber di istituzioni e infrastrutture dei mercati finanziari (FMI). È un penetration test guidato dall'intelligence sui sistemi che sostengono gli important business service, svolto su richiesta dei regolatori da fornitori accreditati.
• Il Cyber Assessment Framework (CAF) è il metodo dell'NCSC per valutare come un'organizzazione gestisce il rischio cyber sulle proprie funzioni essenziali. Fissa risultati, non test, e lo usano le organizzazioni stesse o valutatori indipendenti, compresi i regolatori.

Una banca può trovarsi davanti a entrambi: il CBEST chiesto dalla vigilanza e i risultati in stile CAF ovunque le sue funzioni essenziali siano valutate con quel metro. Nessuno dei due sostituisce l'ordinaria gestione delle vulnerabilità e i test che entrambi danno per scontati.

La CBEST Implementation Guide della PRA, edizione 2024, descrive il processo.

Quando si fa un CBEST. Un'istituzione o una FMI svolge un CBEST quando (1) il regolatore lo richiede nel ciclo di vigilanza, sulla base di un elenco che PRA e FCA concordano periodicamente secondo le priorità tematiche e la strategia di vigilanza; (2) l'istituzione chiede di svolgerlo nell'ambito del proprio programma di resilienza cyber e il regolatore è d'accordo; (3) un incidente porta il regolatore a richiederlo a supporto delle azioni di rimedio e della loro verifica. La Bank of England lo descrive come uno strumento per rafforzare la resilienza delle istituzioni di rilevanza sistemica e, attraverso di esse, del sistema finanziario.

Chi testa. Le parti sono quattro: il regolatore, il Control Group dell'istituzione, un fornitore di threat intelligence (TISP) e un fornitore di penetration test (PTSP). Entrambi i fornitori devono essere accreditati CBEST, con un processo di accreditamento svolto dalla Bank of England, ed essere membri di CREST, che funge da organismo di accreditamento e certificazione del CBEST. I fornitori accreditati devono impiegare persone certificate: un CREST Certified Threat Intelligence Manager per il TISP, e un CREST Certified Red Team Manager o Cyber Scheme Red Team Manager con CREST Certified Red Team Specialist per il PTSP.

Cosa si testa. Un penetration test guidato dall'intelligence, con tecniche manuali e automatiche, sui sistemi che sostengono ciascun important business service nel perimetro, coprendo processi e sistemi end-to-end salvo diverso accordo. Il test avviene su sistemi in produzione: il PTSP prepara un piano di gestione dei rischi e il Control Group può ordinare in qualsiasi momento una sospensione temporanea. La riservatezza è limitata al Control Group; avvisare i responsabili dei sistemi o il SOC figura tra le manipolazioni del processo.

Quanto dura. Secondo i regolatori un CBEST dura in media da 9 a 12 mesi: avvio circa 6 settimane, threat intelligence circa 10, penetration test circa 14, chiusura circa 4.

Cosa segue. Il CBEST non ha esito promosso o bocciato. L'istituzione prepara un piano di rimedio, lo concorda con il regolatore, e il regolatore ne segue l'attuazione, di solito per sei-12 mesi o più. I regolatori pubblicano anche analisi tematiche anonime; la guida 2024 sottolinea il valore della simulazione di attaccanti interni con privilegi elevati, come insider malevoli e attacchi alla supply chain, e l'importanza di una solida igiene cyber di base.

Il CAF v4.0 è stato pubblicato il 4 agosto 2025. Ha quattro obiettivi, da A a D, e 14 principi, ciascuno articolato in risultati attesi con indicatori di buona pratica classificati come not achieved, partially achieved o achieved. La valutazione può farla l'organizzazione stessa o un soggetto esterno indipendente, come un regolatore o un fornitore qualificato dall'NCSC che agisce per suo conto. Due risultati riguardano i test.

B4.d Vulnerability management (principio B4, System security). Per il livello achieved devono valere tutte queste condizioni:

• Hai una comprensione aggiornata dell'esposizione delle funzioni essenziali alle vulnerabilità pubblicamente note.
• Le vulnerabilità annunciate per tutti i software, le reti e i sistemi che sostengono le funzioni essenziali sono tracciate, prioritizzate e mitigate (per esempio con le patch) tempestivamente.
• Esegui test regolari per comprendere a fondo le vulnerabilità dei sistemi che sostengono le funzioni essenziali e verifichi questa comprensione con test di terze parti.
• Massimizzi attivamente l'uso di software, firmware e hardware supportati.

Il livello partially achieved richiede già test regolari, ma non la verifica di terze parti, e ammette mitigazioni temporanee per le vulnerabilità non esposte all'esterno. Tra gli indicatori di not achieved: non aver testato di recente per verificare la comprensione delle vulnerabilità e non mitigare tempestivamente le vulnerabilità esposte all'esterno. La guida del principio B4 indica tra i metodi efficaci le valutazioni periodiche di vulnerabilità e sicurezza, per esempio penetration test e scansioni, e chiede di valutare con attenzione i test sulla tecnologia operativa (OT) in esercizio; l'assurance può venire anche da ambienti non operativi o da test di laboratorio sui singoli componenti.

A2.c Assurance (principio A2, Risk management). Per il livello achieved verifichi che le misure di sicurezza siano efficaci e restino tali, scegli metodi di assurance adeguati conoscendone punti di forza e limiti, puoi giustificare la tua fiducia davanti a una terza parte in grado di verificarla, e correggi in modo tempestivo ed efficace le carenze emerse. Tra gli indicatori di not achieved: applicare metodi di assurance senza coglierne i limiti, come i rischi del penetration test negli ambienti operativi, e dare per scontata la sicurezza perché finora non ci sono stati problemi noti.

L'NCSC è esplicito sul proprio ruolo: non ha responsabilità regolatorie, e le organizzazioni soggette a regolazione cyber devono chiedere ai propri regolatori se usare il CAF per rispettare gli obblighi.

La guida dell'NCSC sul penetration test spiega come il CAF si aspetta che i test vengano usati, e lo fa senza giri di parole:

• Il penetration test va visto come un metodo per ottenere garanzie sui processi di vulnerability assessment e gestione delle vulnerabilità, non come il metodo principale per individuare le vulnerabilità. L'NCSC lo paragona alla revisione contabile di processi che il tuo team svolge ogni giorno.
• Idealmente sai già cosa troveranno i tester prima che lo trovino; il loro report deve servire a migliorare i processi interni.
• Un test dimostra solo che i sistemi non sono vulnerabili a problemi noti nel giorno del test, e non è raro che tra un test e l'altro passi un anno o più.
• I test di terze parti vanno affidati solo a personale qualificato ed esperto, e l'NCSC raccomanda alle organizzazioni del governo britannico (HMG) tester e società dello schema CHECK.
• La valutazione e la mitigazione del rischio delle vulnerabilità sono un processo di business e non vanno esternalizzate interamente al team di test.

Letto insieme al B4.d, il modello è chiaro: la gestione continua e interna delle vulnerabilità trova i problemi, e i test periodici di terze parti verificano che funzioni.

Esplicito:

• CBEST, quando richiesto: TISP e PTSP accreditati, responsabili certificati, test su sistemi in produzione dietro gli important business service, piano di rimedio seguito dal regolatore.
• CAF B4.d al livello achieved: test regolari per comprendere le vulnerabilità, verificati da test di terze parti, e mitigazione tempestiva delle vulnerabilità annunciate.
• CAF A2.c: metodi di assurance scelti conoscendone i limiti e carenze corrette in modo tempestivo.
• Per le organizzazioni HMG, la raccomandazione dell'NCSC di usare tester CHECK.

Non scritto in questi testi:

• Una frequenza fissa. Il CBEST si fa quando il regolatore lo chiede; il CAF dice «regolarmente» e «di recente».
• Un requisito di accreditamento per i test ordinari fuori dal CBEST. Il CAF chiede una verifica di terze parti al livello achieved del B4.d, senza indicare uno schema.
• Che i test interni o automatizzati bastino da soli per il livello achieved del B4.d: la verifica di terze parti è un indicatore a sé.

Se sei soggetto a un regolatore di settore, la prima cosa da confermare è cosa chiede e quale profilo CAF si aspetta.

• Per il CBEST: specifica del perimetro, registri di accreditamento e certificazione dei fornitori, piani di test e di gestione dei rischi, report finale di penetration test, piano di rimedio e aggiornamenti inviati al regolatore fino alla chiusura di ogni azione.
• Per il B4.d: la registrazione dell'esposizione alle vulnerabilità note, il tracciamento e la prioritizzazione delle vulnerabilità annunciate con le date di mitigazione, calendario ed esiti dei tuoi test regolari e i report dei test di terze parti che li verificano.
• Per l'A2.c: i metodi di assurance scelti per ogni funzione essenziale e il perché, compreso come hai gestito i rischi dei test negli ambienti operativi, e la correzione delle carenze emerse.
• Tecnologia non supportata: l'elenco, le mitigazioni temporanee e il piano di migrazione, perché il B4.d guarda a entrambi.

Un red team AI autonomo per reti e infrastrutture non è un fornitore CBEST, non è accreditato e non fornisce threat intelligence. I test che esegui in proprio non sono nemmeno la verifica di terze parti che il B4.d chiede al livello achieved. Sostiene invece la parte che secondo l'NCSC deve trovare i problemi: i tuoi test regolari. Per la categoria vedi penetration test automatizzato.

• Test regolari tra un test di terze parti e l'altro. Campagne black box dall'esterno e gray box con i privilegi di un utente standard, a calendario e dopo ogni modifica: sai cosa troveranno probabilmente un tester esterno o un team CBEST prima che arrivino.
• La vista dall'interno. Le campagne gray box da un account standard mostrano fin dove arriva oggi il movimento laterale, la domanda a cui rimandano le analisi tematiche del CBEST con gli scenari di insider e supply chain.
• Cautela negli ambienti operativi. Validazione del perimetro, arresto di emergenza e cinque livelli di autonomia definiscono cosa gli agenti possono fare da soli e cosa deve attendere un operatore, e i proof of concept di exploit possono restare in attesa di revisione: il tipo di controllo che l'A2.c si aspetta quando si testano sistemi in esercizio. Vedi human in the loop.
• Mappatura e registri. CBEST e UK CAF sono tra i 34 framework su cui il motore mappa i finding, con report di conformità esportabili; il collegamento a B4.d e A2.c resta nella tua documentazione. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256 per campagna, verificabile offline.
• I finding restano in sede. I modelli girano sull'appliance, senza servizi AI esterni, e nessun dato del cliente ne esce. Vedi red team AI on-premise e la guida all'acquisto di una piattaforma di pentest on-premise.

• Bank of England: CBEST Threat Intelligence-Led Assessments, Implementation Guide 2024 (bankofengland.co.uk)
• NCSC: raccolta Cyber Assessment Framework (ncsc.gov.uk)
• NCSC: introduzione al CAF (ncsc.gov.uk)
• NCSC CAF v4.0: principio B4 System security, B4.d (ncsc.gov.uk)
• NCSC CAF v4.0: principio A2 Risk management, A2.c (ncsc.gov.uk)
• NCSC: changelog del CAF, v4.0 pubblicata il 4 agosto 2025 (ncsc.gov.uk)
• NCSC: guida al penetration test (ncsc.gov.uk)