Penetration test e MAS TRM: cosa si aspetta la sezione 13 delle Technology Risk Management Guidelines

Le Technology Risk Management Guidelines sono state riviste a gennaio 2021 e si rivolgono alle istituzioni finanziarie (FI) vigilate dalla Monetary Authority of Singapore. La sezione 2 spiega come funzionano:

• Paragrafo 2.2: la misura in cui una FI attua le linee guida deve essere commisurata al livello di rischio e di complessità dei servizi finanziari offerti e delle tecnologie che li sostengono, e il grado di rispetto dello spirito delle linee guida è un elemento che la MAS considera nella vigilanza sulla FI.
• Paragrafo 2.3: le linee guida forniscono indicazioni generali e non sostituiscono la legge; vanno lette insieme alle leggi applicabili, alla normativa secondaria e alle direttive, agli avvisi (notice) e ai codici emanati dalla MAS.

Nessun punto della sezione 13 è quindi, da solo, un obbligo di legge, e il testo usa «should» e «is expected to». Nella pratica, un ispettore che scopre sistemi esposti su internet non testati da due anni lo confronterà con il paragrafo 13.2.4, e toccherà alla FI spiegare perché il suo approccio rispetta comunque lo spirito delle linee guida.

Il livello vincolante sta negli avvisi della MAS. Per le banche, il Notice FSM-N06 on Cyber Hygiene, emanato il 9 maggio 2024 ai sensi della sezione 29(1) del Financial Services and Markets Act 2022, è in vigore dal 10 maggio 2024; il Notice 655, che sostituisce, è stato revocato dalla stessa data. L'FSM-N06 usa «must» e copre sei pratiche: protezione delle utenze amministrative, applicazione delle patch di sicurezza entro tempi commisurati al rischio di ciascuna vulnerabilità (con controlli compensativi dove la patch non esiste), standard di sicurezza scritti per ogni sistema, controlli sul perimetro di rete, protezione dal malware e autenticazione a più fattori per le utenze amministrative dei sistemi critici e per gli accessi via internet ai dati dei clienti.

L'FSM-N06 non parla di penetration test. Chiede però tempi di patch coerenti con il rischio di ogni vulnerabilità, difficili da motivare senza sapere quali vulnerabilità sono davvero sfruttabili nel tuo ambiente. Se hai una licenza MAS di altro tipo, verifica quale avviso di cyber hygiene si applica.

La sezione 13, Cyber Security Assessment, ha sei parti.

• 13.1.1 Vulnerability assessment: un processo di VA regolare sui sistemi IT, per individuare le vulnerabilità e trattare in tempi adeguati il rischio che ne deriva. La frequenza deve essere commisurata alla criticità del sistema e al rischio a cui è esposto.
• 13.1.2 Perimetro del VA: come minimo, ricerca delle vulnerabilità, individuazione di configurazioni di sicurezza deboli, porte di rete aperte e vulnerabilità applicative; per i sistemi web, controlli sulle vulnerabilità web più comuni.
• 13.2.1 Penetration test: PT per ottenere una valutazione approfondita delle difese, con una combinazione di test black box e grey box per i servizi finanziari online. La nota definisce black box il test senza conoscenze preliminari salvo gli intervalli di indirizzi IP e gli URL noti, e grey box il test con credenziali, in cui chi valuta è autenticato con gli stessi diritti di un normale cliente.
• 13.2.2 Bug bounty: la FI può valutare un programma di bug bounty a complemento del PT.
• 13.2.3 Produzione: il PT va eseguito sull'ambiente di produzione per una valutazione più accurata, con adeguate salvaguardie.
• 13.2.4 Frequenza: dipende da fattori come la criticità del sistema e la sua esposizione al rischio cyber. Per i sistemi direttamente accessibili da internet la FI deve eseguire il PT almeno una volta l'anno o ogni volta che questi sistemi subiscono modifiche o aggiornamenti rilevanti.
• 13.3 Esercitazioni cyber: esercitazioni regolari basate su scenari, come social engineering, table-top o cyber range, per validare i piani di risposta, ripristino e comunicazione, coinvolgendo secondo i casi alta direzione, funzioni di business, fornitori e personale tecnico.
• 13.4 Simulazione di attacco avversario: un'esercitazione per verificare l'efficacia di difesa e risposta contro le minacce prevalenti. Obiettivi, perimetro e regole d'ingaggio si definiscono prima dell'avvio, e l'esercitazione si svolge in modo controllato, sotto stretta supervisione, perché il red team non interrompa i sistemi di produzione.
• 13.5 Scenari basati sull'intelligence: scenari fondati su minacce impegnative ma plausibili, eventualmente costruiti con threat intelligence sugli attori e sulle tattiche, tecniche e procedure più probabili contro la FI.
• 13.6 Gestione delle correzioni: un processo per tracciare e risolvere i problemi emersi da test ed esercitazioni che comprenda almeno la valutazione e classificazione della gravità, i tempi di correzione per ciascun livello di gravità, e una valutazione del rischio con strategia di mitigazione per le deroghe.

Le note riprendono le definizioni di PT e red teaming dalle Penetration Testing Guidelines del 2015 e dalle linee guida Red Team Adversarial Attack Simulation Exercise del 2018 dell'Association of Banks in Singapore (ABS). La sezione 6.1 aggiunge un filone distinto: i test di sicurezza applicativa del software sviluppato dalla FI, con metodi statici, dinamici e interattivi.

Scritto nelle linee guida:

• Un processo di VA con un perimetro minimo definito e una frequenza basata sul rischio.
• PT in produzione con salvaguardie, e test black box più grey box per i servizi finanziari online.
• PT almeno annuale, e dopo modifiche o aggiornamenti rilevanti, per i sistemi direttamente accessibili da internet.
• Esercitazioni cyber e simulazioni di attacco avversario con regole d'ingaggio.
• Un processo di correzione con tempi per livello di gravità e una gestione documentata delle deroghe.

Non scritto nella sezione 13:

• Una frequenza per il VA, per il PT dei sistemi interni o per il red teaming: dipende da criticità ed esposizione, e devi saper motivare la scelta.
• L'obbligo di far eseguire il PT a una società esterna o a un tester certificato. Le linee guida chiedono un audit IT che dia al board un parere indipendente e obiettivo, con auditor dotati delle competenze necessarie (15.1.1 e 15.1.4); per i test chiedono una valutazione approfondita, non un certo tipo di tester. Se il test lo esegue un team interno o una società esterna lo decidi tu, e il report deve mostrare la profondità richiesta dal 13.2.1.
• Una metodologia o un sistema di punteggio specifici.

Attenzione a cosa significa qui grey box. Per i servizi finanziari online le linee guida lo definiscono come test con i diritti di un normale cliente: il test autenticato richiesto dal 13.2.1 è quello che farebbe un truffatore con un conto rubato o appena aperto. Un test da una postazione di un dipendente risponde a un'altra domanda, ragionevole da aggiungere per i sistemi critici interni; vedi black box e gray box.

1. Elenca tutto ciò che è direttamente accessibile da internet, comprese le API dietro i canali web e mobile. Su questi sistemi grava l'unica soglia esplicita della sezione 13: è con questo elenco che un ispettore confronterà le date dei tuoi PT.
2. Definisci «modifica rilevante» nel change management, così che un rilascio, una nuova integrazione o uno spostamento di infrastruttura su un sistema esposto faccia partire un test in automatico, senza aspettare il ciclo annuale.
3. Stabilisci la frequenza del VA per fasce (per esempio esposti su internet, critici interni, altri) e scrivi perché ogni fascia ha il suo intervallo, con riferimento al 13.1.1.
4. Testa i servizi online in entrambi i modi: black box dall'esterno e grey box con credenziali da cliente. Per i sistemi critici interni aggiungi un test con i privilegi di un dipendente standard.
5. Metti per iscritto le salvaguardie per la produzione: finestre approvate, piani di rollback, condizioni di stop e referenti. Il 13.2.3 chiede PT in produzione, e sono le salvaguardie a renderlo accettabile per l'esercizio.
6. Pianifica le esercitazioni: quali esercitazioni cyber e quale simulazione di attacco avversario farai, con scenari basati sulle minacce e regole d'ingaggio concordate prima dell'avvio.
7. Chiudi il ciclo secondo il 13.6: classi di gravità, tempi di correzione per classe, un processo di deroga con valutazione del rischio e un retest che conferma ogni correzione.

• Registri di VA che mostrino il perimetro elencato dal 13.1.2: ricerca delle vulnerabilità, configurazioni deboli, porte aperte, vulnerabilità applicative e, per i sistemi web, le vulnerabilità web comuni.
• Report di PT con data, perimetro, tipo di test (black box o grey box), ambiente testato e salvaguardie applicate in produzione.
• L'inventario dei sistemi esposti su internet con la data dell'ultimo PT e di ogni PT innescato da una modifica.
• Registri delle esercitazioni: scenari, regole d'ingaggio, partecipanti ed esiti di esercitazioni cyber e simulazioni di attacco avversario.
• Il registro delle correzioni: gravità, tempo previsto, responsabile, evidenza di chiusura ed esito del retest, più ogni deroga approvata con la relativa valutazione del rischio e mitigazione.
• Per le banche, i registri delle patch ai sensi dell'FSM-N06, che mostrino come i tempi di ogni vulnerabilità siano derivati dal suo rischio, e i controlli compensativi dove la patch non esisteva.

Un red team AI autonomo per reti e infrastrutture non esegue la tua simulazione di attacco avversario, non fornisce threat intelligence e non sostituisce il test approfondito che board, auditor o MAS si aspettano da tester qualificati. Aggiunge copertura tra un test e l'altro. Per una panoramica della categoria vedi penetration test automatizzato.

• Black box e gray box a calendario. Campagne dall'esterno senza conoscenze preliminari e campagne autenticate con i privilegi di un utente standard, a calendario e dopo ogni modifica: la parte del 13.2.4 che dice «ogni volta che questi sistemi subiscono modifiche rilevanti» non dipende più dalla prenotazione di un incarico.
• Sfruttabilità come dato per le correzioni. Ogni finding indica se è stato dimostrato sfruttabile nel tuo ambiente: è il dato che serve alla classificazione di gravità del 13.6 e ai tempi di patch basati sul rischio dell'FSM-N06.
• Salvaguardie per la produzione. Il 13.2.3 chiede salvaguardie adeguate quando si testa la produzione. 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; i proof of concept di exploit possono restare in attesa di revisione. Vedi human in the loop.
• Mappatura sui framework. MAS TRM è tra i 34 framework su cui il motore mappa i finding, con report di conformità esportabili. Verifica la mappatura rispetto ai numeri di paragrafo di questa guida prima di mostrarla a un ispettore: il collegamento di ogni report a 13.1, 13.2 e 13.6 resta nella tua documentazione.
• Registri e localizzazione dei dati. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256 per campagna, verificabile offline, e nessun dato del cliente lascia l'appliance: i modelli girano lì, senza servizi AI esterni. Vedi red team AI on-premise e la guida all'acquisto di una piattaforma di pentest on-premise.

• MAS: Technology Risk Management Guidelines (mas.gov.sg)
• MAS Technology Risk Management Guidelines, gennaio 2021, paragrafi 2, 6.1, 13 e 15 (PDF, mas.gov.sg)
• MAS Notice FSM-N06 on Cyber Hygiene (mas.gov.sg)
• MAS Notice 655 on Cyber Hygiene, revocato dal 10 maggio 2024 (mas.gov.sg)