Requisiti SAMA per i penetration test
Se la Banca Centrale Saudita la vigila, il penetration test è un obbligo annuale ricorrente e non un progetto. Il framework è specifico su due punti che decidono se le sue evidenze superano la revisione: i test devono essere indipendenti e il perimetro deve raggiungere i sistemi che i suoi clienti possono toccare.
Il requisito, detto chiaramente
Dagli istituti vigilati dalla Banca Centrale Saudita ci si attende l'esecuzione di penetration test esterni indipendenti come minimo annuali, con perimetro che copra i sistemi esposti verso l'esterno, le applicazioni web e l'infrastruttura di rete.
Tre parole in quella frase portano tutto il peso, e ciascuna è un punto in cui le evidenze falliscono comunemente la revisione:
- Indipendenti — non eseguiti dal team che costruisce o gestisce i sistemi sottoposti a test.
- Annuali, come minimo — il ciclo annuale è un pavimento, e un cambiamento rilevante ai sistemi esposti su internet è un innesco separato.
- Penetration test — non una scansione di vulnerabilità con un'altra copertina. Gli assessor sono diventati bravi a distinguerli.
Dove le evidenze SAMA falliscono davvero
Quattro modalità di fallimento spiegano gran parte di ciò che viene contestato, e tutte e quattro costano meno a evitarsi che a rimediarsi.
Una scansione presentata come penetration test
Il segnale è strutturale: ogni finding è un CVE con una descrizione fornita dal vendor, nulla è concatenato e non c'è alcuna narrazione che spieghi cosa potrebbe ottenere un attaccante. Un penetration test dimostra l'impatto: questo servizio esposto consegna una credenziale, quella credenziale raggiunge questo sistema interno, che contiene questi dati. Se il suo report è un elenco ordinato di versioni, è una scansione. La distinzione per esteso.
Un'indipendenza che non regge
Test eseguiti dal team di ingegneria, dal fornitore di servizi gestiti che gestisce anche l'infrastruttura, o da un vendor che valuta il proprio prodotto. Ciascuno di questi casi fallisce il requisito di indipendenza per quanto competenti siano stati i test.
Un perimetro che manca il livello rivolto al cliente
Backend di mobile banking, API partner, la nuova integrazione fintech lanciata dopo la firma del perimetro. I sistemi esposti su internet e le applicazioni web sono nominati esplicitamente nel framework, quindi una lacuna qui è un'omissione diretta e non una questione di giudizio.
Nessun retest
Un report con dodici finding ad alta severità e nessuna evidenza che alcuno sia stato chiuso è, dal punto di vista di un revisore, la documentazione di un problema irrisolto. Il ciclo di remediation e retest è ciò che converte un test in evidenza di conformità.
Cosa copre l'incarico
La base regolamentare, ogni anno:
- Test di rete esterna — l'intero parco esposto su internet: internet banking, interfacce di pagamento, VPN e accesso remoto, infrastruttura di posta, e gli host pubblicati per un progetto e mai ritirati.
- Test di applicazioni web e API — autenticazione e gestione delle sessioni, autorizzazione e controllo accessi tra clienti, logica di business nei flussi transazionali, injection, e le API dietro le app mobili. In un istituto finanziario i finding di logica di business sono di norma quelli che contano di più e quelli che l'automazione non trova mai.
Raccomandato in aggiunta, e incluso dalla maggior parte degli istituti su ciclo annuale o alternato:
- Test di rete interna — fin dove arriva davvero un punto d'appoggio, e se regge la segmentazione tra ambiente aziendale e ambiente dei pagamenti.
- Active Directory — abuso di ADCS, Kerberoasting, delega e percorsi ACL verso Domain Admin. È così che un modesto punto d'appoggio diventa una compromissione dell'intera banca, ed è invisibile ai test esterni.
- Cloud — escalation in Entra ID e Azure RBAC, storage esposto ed errata configurazione delle identità, dove i carichi di lavoro si sono spostati.
- Assumed breach — partire da un punto d'appoggio anziché dal perimetro, cosa che risponde alla domanda che un consiglio pone davvero: fin dove potrebbe arrivare qualcuno?
Dove tratta anche dati di carta, il requisito 11.4 di PCI DSS si applica in parallelo e si sovrappone in misura sostanziale — dimensionati insieme sono un solo incarico, non due.
Il deliverable
Un report costruito per il modo in cui gli istituti finanziari lo consumano davvero: una sintesi esecutiva che il consiglio e il regolatore possono leggere senza traduzione, un corpo tecnico con passi di riproduzione, evidenze e valutazioni CVSS per i vostri ingegneri, e un mapping esplicito di ogni finding al controllo del framework che lo riguarda, così che il team compliance non debba costruire quel mapping da sé.
Poi le parti che trasformano un report in evidenza: supporto alla remediation mentre correggete, un retest dei finding chiusi e una lettera di attestazione che dichiari che il test è stato eseguito, da chi, su quale perimetro e in quali date. Tutto incluso. Un report di esempio mostra il formato.
Chi lo esegue
Tratta direttamente con chi esegue i test: nessun account manager, nessun junior che esegue tooling sotto il nome di un senior in fattura, nessuna attesa di tre settimane tra i test e il report. Per una scadenza regolamentare quella immediatezza è di solito ciò che permette di rispettare la data.
Certificazioni, dato che negli acquisti del settore finanziario la domanda arriva sempre: OSCP+, eCPPT, eWPT, eCIR, più AZ-500, SC-200 e SC-300 per la parte Microsoft e Azure — tutte verificabili tramite il credential wallet di OffSec. Prima di dedicarmi a tempo pieno al lavoro offensivo sono stato detection engineer e analista CTI, un bagaglio utile proprio in questo settore: il report le dice non solo come funziona un percorso d'attacco, ma che aspetto avrebbe avuto nel suo SIEM e se il suo monitoraggio l'avrebbe intercettato.
Lavoro da remoto da Amman su GMT+3, stessi orari e stessa settimana lavorativa di Riyad, in arabo o inglese.
Come iniziare
Mi dica il tipo di licenza, cosa rientra nel perimetro e entro quando il test deve essere completato. Riceverà un preventivo a prezzo fisso e una data di avvio. Se il ciclo annuale si avvicina e vuole prima vedere la sua esposizione esterna attuale, la scansione del perimetro gratuita richiede pochi minuti.
Correlati: penetration test in Arabia Saudita per come SAMA convive con NCA ECC, il controllo 2-11 dell'ECC se porta anche un obbligo governativo, e la panoramica conformità per tutto il resto. Si metta in contatto — l'arabo è benvenuto.
Domande su SAMA
Le organizzazioni membro vigilate dalla Banca Centrale Saudita: banche, compagnie di assicurazione e riassicurazione, società finanziarie, centrali rischi e prestatori di servizi di pagamento, incluse le fintech che operano con licenza SAMA o nella sua sandbox regolamentare. Se la sua licenza viene da SAMA, il framework le si applica. Le fintech ne restano spesso sorprese: l'obbligo arriva con la licenza, in una fase in cui il programma di sicurezza è spesso ancora in formazione.
Penetration test esterni indipendenti, come minimo annuali. Il «come minimo» fa un lavoro reale in quella frase: ci si aspetta generalmente che un cambiamento rilevante ai sistemi esposti su internet inneschi dei test indipendentemente dal punto del ciclo annuale, e un istituto che ha lanciato una nuova piattaforma rivolta ai clienti sei mesi dopo il test annuale senza testarla avrà una conversazione difficile. Tratti il test annuale come il pavimento e il cambiamento significativo come un innesco separato.
Che i test non possono essere eseguiti dalle persone che costruiscono o gestiscono i sistemi sottoposti a test. Una funzione di sicurezza interna che riporta separatamente dall'ingegneria ci si avvicina, ma la risposta più pulita e comunemente accettata è una parte esterna senza alcun ruolo nella costruzione o nella gestione dell'ambiente. È il requisito che gli istituti sbagliano più spesso, e lo scoprono in sede di revisione anziché di scoping — che è l'ordine costoso.
Il perimetro esplicitamente nominato è: sistemi esposti su internet, applicazioni web e infrastruttura di rete. La maggior parte degli istituti va oltre, e a ragione: un test che dimostra che un attaccante può raggiungere il perimetro ma non chiede mai cosa accade dopo risponde a metà della domanda. Lo schema che funziona bene è una valutazione esterna e applicativa completa ogni anno come base regolamentare, integrando test di rete interna e Active Directory almeno ad anni alterni o ogni volta che il parco cambia in modo rilevante.
Sì, ed è il caso abituale. Di norma avete già il mapping del framework, una funzione GRC e un rapporto con l'internal audit; ciò che serve sono i test e le evidenze che vi si incastrano. Dimensiono rispetto al controllo che dovete soddisfare, riporto i finding a quel controllo nel report e consegno il retest e l'attestazione che il vostro team compliance deve archiviare. Non sono una società di consulenza GRC e non proverò a vendervi un programma di framework: i test sono la parte che faccio io.
Test SAMA annuale in scadenza?
Indipendente, dimensionato sul framework, con il retest e l'attestazione che il vostro team compliance archivia.