Test di sicurezza nella APRA CPS 234: test dei controlli, indipendenza dei tester e cosa dice la CPG 234 sul penetration test

La Prudential Standard CPS 234 Information Security si applica a tutti i soggetti vigilati dall'APRA:

• Authorised deposit-taking institutions (ADI), comprese le ADI estere, e le holding non operative (NOHC) bancarie autorizzate.
• Assicuratori danni, compresi gli assicuratori di Categoria C, le NOHC assicurative autorizzate e le capogruppo dei gruppi assicurativi di livello 2.
• Compagnie di assicurazione vita, comprese le friendly society e le compagnie vita estere ammesse (EFLIC), e le NOHC vita registrate.
• Assicuratori sanitari privati registrati ai sensi del PHIPS Act.
• RSE licensee (gestori di fondi pensione) ai sensi del SIS Act, per le loro attività.

Per ADI estere, assicuratori di Categoria C ed EFLIC gli obblighi valgono solo per le attività della filiale australiana. Il soggetto che è capogruppo applica i requisiti a tutto il gruppo, anche alle entità non vigilate dall'APRA. Lo standard è in vigore dal 1° luglio 2019; per gli asset informativi gestiti da terzi si è applicato dal primo rinnovo del contratto o dal 1° luglio 2020, se precedente, quindi oggi ogni asset nel perimetro è coperto.

Lo standard vale anche per gli asset gestiti da parti correlate e da terzi, e questo conta per i test: se un fornitore testa i controlli sui tuoi asset e tu fai affidamento su quei test, il paragrafo 28 ti chiede di valutare se natura e frequenza rispettano gli stessi criteri dei tuoi.

Sotto il titolo Testing control effectiveness:

• Par. 27: verificare l'efficacia dei controlli di sicurezza con un programma di test sistematico. Natura e frequenza devono essere commisurate a (a) la velocità con cui cambiano vulnerabilità e minacce, (b) la criticità e la sensibilità dell'asset, (c) le conseguenze di un incidente, (d) i rischi dell'esposizione ad ambienti in cui il soggetto non può imporre le proprie politiche di sicurezza (ambienti non fidati), (e) la rilevanza e la frequenza dei cambiamenti sugli asset.
• Par. 28: se gli asset sono gestiti da una parte correlata o da un terzo e ti affidi ai suoi test, valuta se quei test sono commisurati ai criteri da (a) a (e) del par. 27.
• Par. 29: portare a Board o alta direzione ogni esito di test che evidenzi carenze dei controlli non correggibili in tempi adeguati.
• Par. 30: assicurare che i test siano eseguiti da specialisti adeguatamente competenti e funzionalmente indipendenti.
• Par. 31: riesaminare l'adeguatezza del programma di test almeno una volta l'anno o quando cambiano in modo rilevante gli asset o il contesto di business.

Tre paragrafi vicini completano il quadro:

• Par. 26: riesaminare e testare ogni anno i piani di risposta agli incidenti di sicurezza.
• Par. da 32 a 34: l'internal audit verifica il disegno e l'efficacia operativa dei controlli, anche di quelli gestiti da parti correlate e terzi, con personale competente, e valuta le garanzie fornite dai terzi su cui intende fare affidamento quando un incidente potrebbe colpire in modo rilevante il soggetto o i suoi clienti.
• Par. 35 e 36: notificare all'APRA entro 72 ore dalla conoscenza un incidente di sicurezza rilevante, ed entro 10 giorni lavorativi dalla conoscenza una debolezza rilevante dei controlli che il soggetto prevede di non poter correggere in tempi adeguati.

Il paragrafo 36 è quello che collega i test al regolatore. Un penetration test che trova una debolezza rilevante su un sistema critico non produce solo un finding: se la correzione richiederà più tempo del ragionevole, fa partire il termine di notifica.

La Prudential Practice Guide CPG 234 (giugno 2019) esprime la visione dell'APRA sulle buone pratiche. L'APRA precisa che le practice guide trattano i requisiti di leggi e standard prudenziali ma non creano di per sé obblighi vincolanti. Mostrano però il metro con cui un ispettore ti valuterà.

• Frequenza. Secondo l'APRA frequenza e perimetro dei test dovrebbero garantire che un insieme sufficiente di controlli sia testato almeno una volta l'anno, e i controlli che proteggono asset esposti ad ambienti non fidati, compresi internet e i collegamenti con fornitori e clienti, sarebbero di norma testati durante tutto l'anno. Test aggiuntivi possono essere innescati da cambiamenti di vulnerabilità, minacce o asset.
• Impostazione. Il soggetto di norma descrive l'insieme dei propri controlli e mantiene un programma che ne verifica nel tempo disegno ed efficacia operativa. I criteri di successo si definiscono prima, compresi i casi in cui serve un retest, e gli esiti si riportano con azioni di follow-up tracciate formalmente.
• Indipendenza. I tester devono essere abbastanza indipendenti da dare una valutazione priva di condizionamenti, senza conflitti di interesse, il che comprende l'uso di tester che non hanno responsabilità operative sui controlli verificati. Il livello di indipendenza dipende dalla natura e dall'importanza del test.
• Tecniche (Allegato G). Penetration test per la protezione della rete; penetration test con tecniche più avanzate, comunemente chiamati test «red team», per la rilevazione tempestiva di accessi non autorizzati; revisioni di progetto, penetration test, revisione e scansione del codice e fuzzing per il software; un penetration test dell'ambiente di backup; scansioni di vulnerabilità e penetration test per individuare e correggere in tempo le nuove vulnerabilità.
• Capacità e reporting. I test di sicurezza, compreso il penetration test, figurano tra le capacità che un soggetto mantiene di norma, e l'Allegato H indica «penetration testing (by type, count and finding rating)» tra le metriche riportate abitualmente a Board e management.
• Affidamento dell'internal audit. Quando l'internal audit si basa su test svolti da altre funzioni, l'APRA si aspetta che ne valuti perimetro e qualità.

Vincolante, nella CPS 234:

• Un programma di test sistematico con natura e frequenza che seguono i cinque criteri del paragrafo 27.
• Test eseguiti da specialisti competenti e funzionalmente indipendenti.
• Un riesame annuale dell'adeguatezza del programma e l'escalation delle carenze non correggibili in tempo.
• L'internal audit su disegno ed efficacia operativa dei controlli.
• La notifica all'APRA entro 72 ore per gli incidenti rilevanti ed entro 10 giorni lavorativi per le debolezze rilevanti non correggibili in tempi adeguati.

Aspettativa dell'APRA, nella CPG 234:

• Un insieme sufficiente di controlli testato almeno ogni anno, e test continui durante l'anno per i controlli esposti ad ambienti non fidati.
• Penetration test e test red team tra le tecniche per protezione della rete, rilevazione e gestione delle vulnerabilità.
• Tester senza responsabilità operative sui controlli che testano.

Non scritto in nessuno dei due:

• Un penetration test annuale obbligatorio per ogni sistema.
• L'obbligo di ricorrere a una società esterna o a un tester certificato. L'indipendenza funzionale si può ottenere anche all'interno, purché i tester non siano le persone che gestiscono i controlli.
• Una metodologia imposta.

1. Descrivi l'insieme dei controlli, come suggerisce la CPG 234, e collega ogni controllo agli asset che protegge, alla loro criticità e sensibilità.
2. Scegli il tipo di test per ogni controllo: scansioni di vulnerabilità e penetration test per gestione delle vulnerabilità e protezione della rete, test in stile red team per la rilevazione, revisione del codice e test applicativi per il software interno, test di ripristino e dell'ambiente di backup per la resilienza.
3. Testa in continuo i controlli rivolti ad ambienti non fidati. Servizi esposti su internet, accesso remoto e collegamenti con fornitori e clienti sono i punti in cui la CPG 234 si aspetta test durante tutto l'anno, non una volta sola.
4. Documenta l'indipendenza. Per ogni test, chi l'ha eseguito e perché non ha responsabilità operative sui controlli testati.
5. Definisci criteri di successo e condizioni di retest prima del test, e segui le azioni correttive fino alla chiusura.
6. Inserisci nel processo la decisione sulla notifica. Quando un finding è rilevante e la correzione non sarà tempestiva, qualcuno deve decidere in pochi giorni se si applica il paragrafo 36 e fare l'escalation prevista dal paragrafo 29.
7. Riesamina il programma ogni anno e dopo cambiamenti rilevanti, e conserva il riesame.

• Il programma di test: l'insieme dei controlli, tipo e frequenza dei test per ciascun gruppo e le motivazioni rispetto ai criteri da (a) a (e) del par. 27.
• I report dei test con perimetro, data, tecnica, criteri di successo, esiti, nomi e ruoli dei tester.
• I registri di indipendenza, che mostrino come i tester non avessero responsabilità operative sui controlli testati.
• Le valutazioni dei test svolti da terzi ai sensi del par. 28 per gli asset gestiti da parti correlate o terzi.
• Il registro dei finding con correzioni, retest ed escalation a Board o alta direzione ai sensi del par. 29.
• Le decisioni sul par. 36: per ogni debolezza rilevante, se era correggibile in tempi adeguati e, in caso contrario, la notifica.
• Il riesame annuale del programma e i report di internal audit che vi hanno fatto affidamento.
• Il reporting al Board, per esempio i penetration test per tipo, numero e gravità dei finding, come suggerisce l'Allegato H della CPG 234.

Un red team AI autonomo per reti e infrastrutture non rende i tuoi tester funzionalmente indipendenti: il paragrafo 30 riguarda chi esegue e rivede i test, non lo strumento usato, e resta da documentare a te. Non sostituisce nemmeno i test specialistici o red team previsti dal programma. Ti dà un modo per testare durante tutto l'anno i controlli esposti ad ambienti non fidati, come si aspetta la CPG 234. Per la categoria vedi penetration test automatizzato.

• Test continui dell'esposizione non fidata. Campagne black box dall'esterno e gray box con i privilegi di un utente standard, a calendario e dopo ogni modifica, sui sistemi esposti su internet e verso i partner.
• Prove per il triage. Ogni finding indica se è stato dimostrato sfruttabile nel tuo ambiente, e aiuta a decidere in fretta se una debolezza è rilevante ai sensi del paragrafo 36.
• Retest come criterio di successo. Ogni correzione si verifica con la stessa prova che ha trovato la falla: il finding si chiude con un'evidenza.
• 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. APRA CPS 234 è tra i 34 framework su cui il motore mappa i finding, con report di conformità esportabili; il collegamento dei report ai paragrafi da 27 a 31 resta nella tua documentazione. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256 per campagna, verificabile offline: un registro su cui l'internal audit può fare affidamento.
• Nessuna nuova terza parte. I modelli girano sull'appliance, senza servizi AI esterni, e nessun dato del cliente ne esce: i test non creano un altro terzo di cui valutare i controlli ai sensi della CPS 234. Vedi red team AI on-premise e la guida all'acquisto di una piattaforma di pentest on-premise.

• APRA Prudential Standard CPS 234 Information Security, paragrafi 3-6 e 26-36 (apra.gov.au)
• APRA Prudential Practice Guide CPG 234 Information Security, giugno 2019 (PDF, apra.gov.au)