Penetration test guidati dalla conformità
La maggior parte dei penetration test viene acquistata perché una normativa li impone. La normativa determina il perimetro, la frequenza e — la parte che si sottovaluta — le prove che dovrete essere in grado di produrre dopo. Questa pagina mette a confronto i regimi contro cui testo, perché possiate capire quale vi riguarda davvero.
Le normative a confronto
Ciascuno di questi regimi impone test di sicurezza indipendenti o li richiede di fatto. Le differenze che contano: chi è vincolato, con quale frequenza e cosa dovete poter dimostrare dopo.
Arabia Saudita
- NCA Essential Cybersecurity Controls (in inglese) - la base nazionale per enti pubblici, loro appaltatori e infrastrutture critiche. Il controllo 2-11 riguarda il penetration test: definito, documentato, approvato e attuato, con perimetro che copra almeno i servizi esposti a Internet e l'infrastruttura tecnica sottostante. Con cadenza periodica.
- NCA Critical Systems Cybersecurity Controls - quando i sistemi sono classificati critici, la frequenza passa ad almeno ogni sei mesi. È questo cambio di ritmo che di solito manda all'aria l'ipotesi di budget.
- SAMA Cyber Security Framework (in inglese) - banche, assicurazioni, società finanziarie e prestatori di servizi di pagamento vigilati dalla banca centrale saudita. Test esterni indipendenti almeno annuali, su sistemi esposti a Internet, applicazioni web e infrastruttura di rete.
Emirati Arabi Uniti
- NESA / UAE Information Assurance Standards (in inglese) - enti federali e infrastrutture informative designate critiche. Valutazioni delle vulnerabilità e penetration test vanno eseguiti e tracciati, annualmente nella pratica, con remediation documentata e prova di retest per i risultati critici e alti entro un termine definito. Gli auditor esaminano le qualifiche di chi ha testato.
- Dubai ISR (DESC) - enti pubblici di Dubai e loro fornitori. Convive con NESA; un unico incarico può documentare entrambi.
- CBUAE, DFSA e ADGM (in inglese) - banche e finanziarie onshore, società del DIFC, società dell'ADGM. In tutti e tre i casi sono attesi test indipendenti periodici.
- VARA - prestatori di servizi su attività virtuali di Dubai. Penetration test indipendente almeno annuale ai sensi del Technology and Information Rulebook, con test guidati dall'intelligence quando VARA lo ritenga proporzionato.
- ADHICS (in inglese) - strutture sanitarie di Abu Dhabi e loro fornitori tecnologici.
Internazionale
- PCI DSS - per chi memorizza, elabora o trasmette dati dei titolari di carta. Il requisito 11.4 impone penetration test interni ed esterni almeno annuali e dopo modifiche significative, oltre a test di segmentazione ove questa serva a ridurre il perimetro.
- SOC 2 - non è un obbligo prescrittivo, ma il penetration test è la prova che la maggior parte degli auditor si aspetta per CC4.1 e CC7.1, e i clienti enterprise lo richiedono sempre più nel report.
- ISO 27001 - gestione delle vulnerabilità tecniche dell'Allegato A, dove il test è il modo concreto per dimostrare che il controllo funziona.
Cosa chiedono davvero gli auditor
Il report è necessario ma non sufficiente. Quattro elementi compongono un fascicolo di prove completo, e la maggior parte delle organizzazioni si presenta solo con il secondo:
- Un documento di perimetro - cosa è stato testato, cosa no e perché quel perimetro corrispondeva al controllo. Un test che ha escluso proprio i sistemi di cui si occupa il controllo non passa, per quanto ben fatto.
- Il report - risultati, severità, dettaglio di riproduzione e corrispondenza con i controlli interessati.
- Remediation documentata - cosa avete corretto, quando, e cosa avete accettato come rischio con la relativa motivazione. Accettare un rischio è consentito; non verbalizzare la decisione no.
- Prova del retest - la conferma che i risultati critici e alti sono davvero chiusi, entro il termine della vostra normativa. L'aspettativa dei 90 giorni di NESA è quella che frega: un test all'undicesimo mese non lascia spazio a un retest prima della chiusura del ciclo.
Una lettera di attestazione — chi, quale perimetro, quali date — chiude il fascicolo ed è di solito ciò che viene archiviato o inoltrato a un cliente. Ogni incarico qui ne comprende una.
L'indipendenza è il requisito che si legge male
Diverse di queste normative usano la parola indipendente, con un significato preciso: il test non può essere svolto da chi ha costruito o gestisce il sistema in esame. Un team di sicurezza interno che testa l'infrastruttura della propria organizzazione soddisfa alcune normative e non altre; il team che ha scritto l'applicazione e poi la testa non ne soddisfa nessuna.
È in buona parte la ragione per cui esistono consulenti esterni in questo mercato, e vale la pena verificarlo rispetto al vostro obbligo specifico prima di dare per scontato che le capacità interne bastino. Sbagliare qui costa caro, perché lo si scopre in audit e non in perimetrazione.
Come imposto un incarico di conformità
La prima conversazione riguarda l'obbligo, non la tecnologia: quale normativa, quale controllo, quale scadenza e se qualcosa è cambiato in modo sostanziale dall'ultimo test. Da lì riesco di solito a dirvi in una chiamata se un unico incarico copre tutto ciò a cui siete soggetti e cosa deve includere il perimetro per produrre prove che reggano a un audit.
Cosa ottenete: prezzo fisso prima di iniziare, test svolto dalla persona con cui avete parlato, segnalazione immediata di qualunque elemento critico invece di una sorpresa nel documento finale, un report scritto insieme per la direzione e per gli ingegneri, supporto durante la remediation, un retest e la lettera di attestazione. C'è un report di esempio se volete vedere prima il formato (in inglese), e la pagina prezzi per gli ordini di grandezza.
Per regione
Se siete nel Golfo, le pagine regionali approfondiscono quali regimi si applicano e come interagiscono: penetration test in Arabia Saudita e penetration test negli Emirati. Per il resto, le pagine dei servizi trattano il test in sé, e scrivermi è la via più rapida a una risposta chiara.
Domande sui test di conformità
Di solito sì, ed è molto più economico dell'alternativa. Il perimetro tecnico si sovrappone ampiamente — superficie esterna, applicazioni web e API, rete interna, Active Directory, cloud — quindi ciò che cambia è la corrispondenza con i controlli e il formato del report, non il test in sé. La condizione è impostarlo così fin dall'inizio: un test definito solo per PCI non produrrà le prove che chiede NESA, benché il lavoro sottostante sia quasi identico. Indicatemi in fase di perimetrazione tutti i regimi a cui siete soggetti e il report collegherà i risultati a ciascuno.
No, ed è il motivo più frequente di rigetto delle prove. Una scansione confronta firme note con versioni note e produce un elenco; un penetration test concatena i risultati per mostrare cosa qualcuno potrebbe effettivamente farne. Le normative lo dicono in modo sempre più esplicito e gli auditor riconoscono ormai bene un report di scansione con copertina da pentest: il segnale è che ogni risultato è una CVE e nessuno si collega agli altri. La differenza in dettaglio (in inglese).
Quattro cose, e la maggior parte delle organizzazioni conserva solo la seconda. Un documento di perimetro che mostri cosa è stato testato e perché quel perimetro era adeguato. Il report stesso, con risultati, severità e dettaglio di riproduzione. La remediation documentata dei risultati critici e alti. E la prova di un retest che confermi che le correzioni hanno funzionato, entro il termine fissato dalla vostra normativa: 90 giorni è comune. Una lettera di attestazione che indichi chi ha testato, con quale perimetro e in quali date lega il tutto, ed è di solito la pagina che finisce agli atti.
Annualmente è la base abituale: SAMA, NESA, VARA e PCI DSS convergono lì. Due cose accorciano il termine: la classificazione come sistema critico ai sensi dei CSCC sauditi, che impone test almeno ogni sei mesi, e i cambiamenti significativi. Quasi ogni normativa richiede un nuovo test dopo modifiche sostanziali all'ambiente, indipendentemente da quando è avvenuto l'ultimo test annuale: una migrazione importante o una nuova applicazione esposta a Internet azzera di fatto il contatore.
Di norma sì, e le cause sono prevedibili: perimetro troppo stretto rispetto a quanto richiede il controllo; test svolto dal team che ha costruito il sistema, quindi non indipendente; nessuna prova di retest; oppure una scansione presentata come penetration test. Tutti e quattro i casi si risolvono, e il rimedio è normalmente un singolo incarico ben perimetrato, non un programma. Inviatemi il rilievo dell'auditor e il report precedente e vi dirò quale dei quattro era, prima che spendiate alcunché.
Non sapete quale normativa vi riguarda?
Una breve chiamata di solito basta — e vi dice se un solo test può coprirle tutte.