Un valutatore non legge il report di un penetration test come lo legge un tecnico. Cerca il perimetro e se corrisponde all’ambiente sottoposto ad audit, il metodo, le date, la qualifica e l’indipendenza dei tester, e la prova che i rilievi sono stati corretti e sottoposti a retest.
Definiamo il perimetro del test in base al requisito che deve soddisfare e strutturiamo il report in modo che queste risposte siano facili da trovare. Il test in sé non viene ridotto: un test pensato solo per superare un audit non protegge nulla, e i valutatori lo riconoscono sempre più spesso quando lo vedono.
01Perimetro
Che cosa testiamo
PCI DSS v4.0.1: penetration test esterni e interni ai sensi del requisito 11.4
PCI DSS: test di segmentazione dell’ambiente dei dati dei titolari di carta
SOC 2: test come prova per i criteri di monitoraggio e di gestione delle vulnerabilità
ISO/IEC 27001:2022: controlli di gestione delle vulnerabilità tecniche e di test di sicurezza
DORA: test di resilienza operativa digitale dei sistemi di TIC
NIS2: valutazione dell’efficacia delle misure di gestione dei rischi
GDPR, articolo 32: test regolari delle misure tecniche e organizzative
Questionari di sicurezza di clienti e partner che richiedono un test recente
02Approccio
Come si svolge il lavoro
01
Mappatura dei requisiti
Stabiliamo a quale requisito serve il test, che cosa richiede in termini di perimetro, frequenza e metodo, e che cosa si aspetta di vedere il tuo valutatore.
02
Allineamento del perimetro
Il perimetro del test viene fatto corrispondere al confine dell’ambiente sottoposto ad audit. Le differenze vengono documentate e motivate.
03
Test
Il test segue la nostra metodologia standard per il tipo di sistema. Nulla viene tralasciato perché il framework non lo nomina.
04
Prove
Il report indica metodo, date, qualifica e indipendenza dei tester. Dopo il retest, una lettera riassume l’esito per i terzi, senza dettagli tecnici.
No. La conformità viene stabilita dal tuo valutatore sulla base di tutti i controlli. Il test fornisce le prove per i requisiti che riguardano i test di sicurezza e ti dice che cosa correggere prima dell’arrivo del valutatore.
SOC 2, ISO/IEC 27001, NIS2 o il GDPR richiedono un penetration test?
Nessuno di essi lo indica con queste parole come controllo obbligatorio. Richiedono che le vulnerabilità vengano individuate e che l’efficacia delle misure venga testata regolarmente. Un penetration test è la prova che gli auditor si aspettano più spesso per questi requisiti. PCI DSS e DORA sono espliciti.
Ogni quanto va ripetuto il test?
PCI DSS richiede un penetration test almeno una volta ogni dodici mesi e dopo modifiche significative, e un test di segmentazione almeno una volta ogni dodici mesi, ogni sei mesi per i fornitori di servizi. DORA richiede di testare i sistemi critici almeno una volta all’anno. Per gli altri framework la frequenza deriva dalla tua valutazione dei rischi; di solito ci si aspetta un test annuale.