Penetration test e gestione delle vulnerabilità nella NYDFS Part 500 — il playbook §500.5

La Part 500 si applica a ogni covered entity: chiunque operi, o sia tenuto a operare, in base a licenza, registrazione, charter, certificato, permesso, accreditamento o autorizzazione analoga ai sensi del Banking Law, dell'Insurance Law o del Financial Services Law dello Stato di New York, anche se vigilato da altre autorità (§500.1(e)). Esempi tipici sono banche, compagnie assicurative, agenti e broker assicurativi, società di mutui e operatori in valute virtuali autorizzati dal DFS.

Tre categorie cambiano ciò che si applica:

• Esenzione limitata (§500.19(a)): meno di 20 tra dipendenti e collaboratori indipendenti, affiliate comprese, oppure meno di 7.500.000 dollari di ricavi lordi annui in ciascuno degli ultimi tre esercizi dalle attività della covered entity e da quelle newyorkesi delle affiliate, oppure meno di 15.000.000 di dollari di attivo totale a fine esercizio, affiliate comprese. Questi soggetti sono esenti dal §500.5 e da diverse altre sezioni, e devono depositare una Notice of Exemption entro 30 giorni da quando accertano di averne diritto.
• Società di Classe A (§500.1(d)): almeno 20.000.000 di dollari di ricavi lordi annui in ciascuno degli ultimi due esercizi dalle attività della covered entity e da quelle newyorkesi delle affiliate e, in più, oltre 2.000 dipendenti in media nei due esercizi oppure oltre 1.000.000.000 di dollari di ricavi lordi annui in ciascuno dei due, in entrambi i casi contando le affiliate ovunque si trovino. Contano solo le affiliate che condividono sistemi informativi, risorse di cybersecurity o parte del programma. La Classe A aggiunge audit indipendenti del programma (§500.2(c)), gestione degli accessi privilegiati e blocco delle password più comuni (§500.7(c)), EDR e raccolta centralizzata di log e allarmi (§500.14(b)).
• Tutte le altre covered entity: il §500.5 si applica per intero.

Il §500.5 è identico per una società di Classe A e per una covered entity di medie dimensioni. Cambia il livello di controllo attorno: l'audit indipendente di una Classe A verificherà il programma di gestione delle vulnerabilità come qualsiasi altro controllo.

Il §500.5 richiede policy e procedure scritte di gestione delle vulnerabilità, basate sulla valutazione del rischio e pensate per verificare e mantenere l'efficacia del programma di cybersecurity. Devono garantire quattro cose.

1. Penetration test (§500.5(a)(1)) dei sistemi informativi, sia dall'interno sia dall'esterno del loro perimetro, eseguiti almeno una volta l'anno da un soggetto qualificato, interno o esterno.
2. Scansioni automatiche (§500.5(a)(2)) dei sistemi informativi e revisione manuale di quelli che le scansioni non coprono, per individuare, analizzare e segnalare le vulnerabilità, con la frequenza stabilita dalla valutazione del rischio e tempestivamente dopo ogni modifica rilevante ai sistemi.
3. Monitoraggio (§500.5(b)): un processo che informi tempestivamente delle nuove vulnerabilità.
4. Correzione (§500.5(c)): correzioni tempestive, con priorità stabilita in base al rischio che ogni vulnerabilità comporta per la covered entity.

La Part 500 definisce il penetration test come la verifica della sicurezza dei sistemi informativi tentando di aggirare o superare le loro misure di sicurezza, autorizzando tentativi di penetrazione in database o controlli dall'esterno o dall'interno dei sistemi (§500.1(l)). Ne discendono due conseguenze. Un test del solo perimetro esterno non corrisponde al testo: il test deve partire anche dall'interno, dalla posizione di un insider o di un attaccante che ha già un punto d'appoggio. E una scansione di vulnerabilità non è un penetration test: la definizione richiede un tentativo di superare i controlli, non un elenco di patch mancanti.

Il Second Amendment è entrato in vigore il 1° novembre 2023 (§500.21(b)) e ha introdotto i nuovi requisiti nell'arco di due anni (§500.22(c) e (d)):

• 30 giorni: i nuovi obblighi di comunicazione del §500.17.
• 180 giorni: tutti i nuovi requisiti non elencati sotto, compresa la nuova formulazione del penetration test nel §500.5(a)(1).
• Un anno (1° novembre 2024): governance (§500.4), cifratura (§500.15), risposta agli incidenti e continuità operativa (§500.16) e la nuova esenzione limitata del §500.19(a).
• 18 mesi (1° maggio 2025): scansioni automatiche e revisione manuale (§500.5(a)(2)), privilegi di accesso (§500.7), controlli contro il codice malevolo (§500.14(a)(2)) ed EDR con log centralizzati per la Classe A (§500.14(b)).
• Due anni (1° novembre 2025): autenticazione a più fattori (§500.12) e inventario degli asset (§500.13(a)).

Sono tutte scadute. Il 2026 è quindi il primo anno solare in cui ogni requisito modificato si applica dal 1° gennaio, e la certificazione, o la dichiarazione di non conformità, che lo copre va presentata entro il 15 aprile 2027 (§500.17(b)). L'inventario degli asset pesa sul §500.5 più di quanto suggerisca la sua numerazione: la completezza del perimetro di scansioni e penetration test si può dimostrare solo rispetto a un inventario completo.

Il regolamento fissa il minimo (almeno una volta l'anno, entrambe le prospettive, un soggetto qualificato) e affida il resto alla valutazione del rischio. Un test che regge a un'ispezione di solito prevede:

• Un perimetro ricavato dall'inventario degli asset e dalla valutazione del rischio, con i sistemi esclusi e il motivo di ogni esclusione messi per iscritto.
• Due punti di partenza: fuori dal perimetro (servizi esposti su internet, accesso remoto, applicazioni pubblicate) e dentro (una postazione utente standard o un account compromesso), con i percorsi verificati da ciascuno.
• Una scelta del tester documentata. La Part 500 non definisce il termine «qualificato»: conserva ciò che giustifica la scelta, cioè esperienza e certificazioni pertinenti, indipendenza dai team che gestiscono i sistemi testati e metodologia adottata.
• Regole d'ingaggio approvate prima dell'avvio: bersagli, tecniche escluse, finestre di test e chi può interrompere il test.
• Finding che alimentano il §500.5(c): ogni finding sfruttabile entra nel processo di correzione con livello di rischio, responsabile e data obiettivo, e viene ritestato dopo la correzione.

L'annualità è una soglia minima. Il §500.9 chiede di aggiornare la valutazione del rischio almeno una volta l'anno e ogni volta che un cambiamento del business o della tecnologia modifica in modo rilevante il rischio cyber: una grande migrazione, un'acquisizione o un nuovo servizio esposto su internet sono buoni motivi per ritestare prima del ciclo annuale successivo.

Il §500.5(a)(2) lega la frequenza delle scansioni alla valutazione del rischio: la frequenza va quindi scritta e motivata, non ereditata dall'impostazione predefinita di uno strumento. Tre dettagli sfuggono spesso. Le scansioni vanno ripetute tempestivamente dopo ogni modifica rilevante, non solo a calendario. I sistemi che gli scanner non coprono, come appliance, tecnologia operativa o configurazioni SaaS, richiedono una revisione manuale documentata. E i risultati vanno analizzati e riportati, non solo raccolti.

Per il §500.5(b), indica le fonti monitorate (advisory dei fornitori, il catalogo CISA Known Exploited Vulnerabilities, gruppi di condivisione di settore) e chi ne fa il triage. Per il §500.5(c), tempestivo e basato sul rischio significa tempi di correzione che dipendono da sfruttabilità ed esposizione, non solo dal punteggio CVSS; il playbook sulla finestra di patch d'emergenza KEV propone un modo per fissarli.

Le indicazioni del DFS nel 2026 vanno nella stessa direzione. A maggio 2026 ha chiesto ai soggetti vigilati di individuare e correggere rapidamente le vulnerabilità note come sfruttate, soprattutto sui sistemi esposti su internet, e ha avvertito i CISO che i modelli AI di frontiera amplificano efficacia, scala e velocità con cui si trovano vulnerabilità ed exploit. Entrambe le lettere precisano di non introdurre nuovi requisiti: servono a orientare la gestione del rischio e la conformità alla Part 500.

Entro il 15 aprile di ogni anno la covered entity presenta una certificazione di sostanziale conformità alla Part 500 nell'anno solare precedente, oppure una dichiarazione di non conformità che indica le sezioni non rispettate, descrive natura ed estensione delle lacune e fornisce un calendario di correzione o conferma che la correzione è avvenuta (§500.17(b)). Entrambe sono firmate dal vertice esecutivo e dal CISO. La certificazione deve basarsi su dati e documenti sufficienti a stabilire e dimostrare la sostanziale conformità, e la documentazione va conservata per cinque anni. Le FAQ del DFS aggiungono che non si può certificare se nell'anno precedente non si era in sostanziale conformità con tutti i requisiti applicabili.

Per il §500.5, il fascicolo che un ispettore si aspetta di trovare:

• Policy e procedure scritte di gestione delle vulnerabilità, con evidenza dell'approvazione annuale prevista dal §500.3.
• La valutazione del rischio in vigore e la motivazione che la collega alla frequenza delle scansioni e al perimetro dei test. La guida del DFS di settembre 2026 sulle valutazioni del rischio chiede documentazione che mostri come i rischi sono stati individuati, valutati e affrontati, con metodologia, dati considerati e motivazioni.
• Ogni report di penetration test, con le prospettive interna ed esterna, il perimetro, le esclusioni e le qualifiche del tester.
• Calendari e risultati delle scansioni, l'elenco dei sistemi sottoposti a revisione manuale e le scansioni eseguite dopo modifiche rilevanti.
• Le fonti di monitoraggio e il registro di triage delle nuove vulnerabilità.
• I registri di correzione: finding, livello di rischio, responsabile, date previste ed effettive, esito del retest ed eccezioni approvate.
• Il report scritto annuale del CISO all'organo di governo (§500.4(b)), che tratta i rischi cyber rilevanti e i piani per correggere le carenze rilevanti.

1. Test solo dall'esterno. Un test del perimetro senza prospettiva interna non corrisponde al testo del §500.5(a)(1).

2. Tester non documentato. Se il fascicolo non mostra perché il tester era qualificato, la certificazione poggia su un'ipotesi.

3. Frequenza delle scansioni slegata dalla valutazione del rischio. Un calendario mensile può andare bene, ma la valutazione del rischio deve spiegare perché, e le modifiche rilevanti richiedono scansioni dedicate.

4. Lacune di copertura silenziose. Sistemi che lo scanner non raggiunge, senza alcuna revisione manuale registrata.

5. Correzioni guidate solo dal CVSS. Il §500.5(c) chiede una priorità basata sul rischio per la covered entity, che dipende da esposizione e sfruttabilità nel suo ambiente.

6. Certificare pur sapendo di una lacuna. Le FAQ del DFS legano la rilevanza a natura, durata, portata e impatto potenziale della non conformità. Per il §500.20(b) anche un singolo atto o una singola omissione possono costituire violazione, compreso il mancato rispetto sostanziale di una qualsiasi sezione per un periodo di 24 ore. La dichiarazione di non conformità con un calendario di correzione è la strada che il regolamento prevede.

Un red team AI autonomo non sostituisce il soggetto qualificato richiesto dal §500.5(a)(1) e non decide se l'entità è stata in sostanziale conformità: lo decidono il CISO e il vertice esecutivo. Cambia invece le evidenze disponibili tra un test annuale e l'altro.

• Entrambe le prospettive, in continuo. Campagne black box dall'esterno del perimetro e gray box dall'interno, con le credenziali di un utente standard, a calendario e dopo ogni modifica rilevante invece che una volta l'anno. Vedi black box e gray box.
• Priorità basate su prove. I finding arrivano con l'evidenza che sono sfruttabili nel tuo ambiente, cioè il dato che serve alla prioritizzazione del §500.5(c). Vedi correggi prima ciò che è stato dimostrato sfruttabile.
• Retest su richiesta. Ogni correzione si verifica con la stessa prova che ha trovato la falla, e il registro di correzione si chiude.
• Approvazione umana. Cinque livelli di autonomia stabiliscono cosa gli agenti possono fare da soli e cosa deve attendere una persona, dall'approvazione di qualsiasi scansione attiva al livello più basso fino all'assenza di soglie di approvazione al livello più alto, scelto in modo esplicito. Vedi human in the loop.
• Registri che reggono. Ogni tentativo di attacco è registrato in una catena di hash SHA-256 per campagna, con ogni voce firmata Ed25519: i registri dei test alla base della comunicazione del 15 aprile si possono dimostrare inalterati.
• Nessuna nuova terza parte. I finding sui sistemi sfruttabili, insieme ai dati dei clienti o alle credenziali che un test può toccare, possono rientrare nella definizione di informazioni non pubbliche della Part 500 (§500.1(k)). Zero Hunt usa modelli propri sull'appliance, senza servizi AI esterni: quei dati non arrivano a un fornitore AI che diventerebbe a sua volta un third-party service provider da valutare ai sensi del §500.11. Vedi red team AI on-premise.

• 23 NYCRR Part 500 come modificato dal Second Amendment (NYDFS, PDF)
• Cybersecurity submissions: comunicazione annuale di conformità, esenzioni e notifiche di incidente (NYDFS)
• What is required: requisiti standard e di Classe A (NYDFS)
• Cybersecurity FAQs (NYDFS)
• Lettera del 21 maggio 2026: Heightened Cybersecurity Risks Associated with Frontier AI Models (NYDFS)
• Lettera del 21 maggio 2026: Measures Regulated Entities Should Consider in a Heightened Cybersecurity Threat Environment (NYDFS)
• Lettera del 10 settembre 2026: How to Conduct and Use Risk Assessments Required by the Cybersecurity Regulation (NYDFS)