Il SOC 2 richiede un penetration test? Cosa dicono i Trust Services Criteria

No. Un esame SOC 2 riferisce sui tuoi controlli rispetto ai Trust Services Criteria dell'AICPA, e i criteri non prescrivono controlli. L'introduzione ai criteri del 2017 (con i punti di attenzione rivisti nel 2022) lo dice in modo diretto:

• I criteri indicano i risultati che i controlli di un'organizzazione dovrebbero di norma raggiungere, e servono a valutare e riferire indipendentemente dai controlli specifici che il management adotta.
• In questo si distinguono dai framework di processi e controlli che impongono un insieme preciso di controlli: i criteri riconoscono che non esiste un insieme di processi e controlli capace di mitigare tutte le minacce, le vulnerabilità e i rischi specifici di ogni organizzazione.

Sotto ogni criterio il documento elenca dei punti di attenzione (points of focus). Come nel COSO, rappresentano caratteristiche importanti dei criteri e aiutano management e auditor a valutare se i controlli erano progettati in modo adeguato e hanno operato efficacemente. L'AICPA aggiunge che alcuni punti di attenzione possono non essere adatti o pertinenti per un'organizzazione, e che il management può adattarli o considerarne altri.

Il penetration test compare proprio a questo livello: come una delle valutazioni elencate in un punto di attenzione del CC4.1. La risposta onesta ha quindi due metà. Nessun criterio dice «esegui un penetration test». E un SOC 2 sulla sicurezza senza test tecnici a sostegno dei criteri su monitoraggio e vulnerabilità è difficile da difendere davanti a un auditor o a un cliente.

Il CC4.1 corrisponde al principio 16 del COSO: l'organizzazione seleziona, sviluppa ed esegue valutazioni continue e/o separate per accertare che le componenti del controllo interno siano presenti e funzionanti.

Il punto di attenzione aggiuntivo per gli incarichi che usano i Trust Services Criteria, Considers Different Types of Ongoing and Separate Evaluations, nella revisione 2022 dice: il management usa diverse valutazioni continue e separate dei rischi e dei controlli per stabilire se i controlli interni sono presenti e funzionanti; a seconda degli obiettivi dell'organizzazione, queste valutazioni possono comprendere monitoraggio e test dei controlli di prima e seconda linea, attività di internal audit, verifiche di conformità, valutazioni di resilienza, scansioni di vulnerabilità, security assessment, penetration test e valutazioni di terze parti.

L'edizione di marzo 2020 citava già il penetration test nello stesso punto di attenzione, accanto alle certificazioni indipendenti rispetto a specifiche consolidate (per esempio le certificazioni ISO) e all'internal audit. La revisione del 2022 ha allargato l'elenco; non lo ha trasformato in un obbligo.

I punti di attenzione del COSO sotto il CC4.1 contano per il modo in cui organizzi i test:

• Uses Knowledgeable Personnel: chi valuta ha conoscenze sufficienti per capire cosa sta valutando.
• Adjusts Scope and Frequency: il management varia perimetro e frequenza delle valutazioni separate in base al rischio.
• Objectively Evaluates: le valutazioni separate si svolgono periodicamente per dare un riscontro obiettivo.

Il CC4.2 riguarda poi cosa succede ai risultati: management e consiglio li esaminano, le carenze vengono comunicate a chi deve correggerle e il management verifica che siano sanate in tempi adeguati.

Il CC7.1 dice: per raggiungere i propri obiettivi, l'organizzazione usa procedure di rilevamento e monitoraggio per individuare (1) modifiche di configurazione che introducono nuove vulnerabilità e (2) l'esposizione a vulnerabilità scoperte di recente.

Il suo punto di attenzione Conducts Vulnerability Scans descrive scansioni di vulnerabilità di infrastruttura e software pensate per individuare vulnerabilità o errori di configurazione su base periodica e dopo modifiche significative all'ambiente, con interventi per correggere tempestivamente le carenze trovate. Gli altri punti di attenzione del CC7.1 riguardano standard di configurazione definiti per l'hardening, il monitoraggio del rispetto di quegli standard, meccanismi di rilevamento delle modifiche come il file integrity monitoring e l'individuazione di componenti sconosciuti o non autorizzati.

Tra i criteri di valutazione del rischio, il CC3.2 comprende il punto di attenzione Identifies Vulnerability of System Components: l'organizzazione individua le vulnerabilità dei componenti di sistema, compresi processi, infrastruttura e software.

Le scansioni da sole rispondono al CC7.1. Un penetration test aggiunge ciò che una scansione non può dire: quali di quelle vulnerabilità, e quali loro concatenazioni, sono davvero sfruttabili nel tuo ambiente. È l'informazione che serve all'analisi del rischio del CC3.2 e alle priorità di correzione del CC4.2. Vedi vulnerability assessment e penetration test.

Un report SOC 2 riguarda i controlli presenti nella descrizione del sistema fatta dal management. I criteri descrivono due tipi di incarico:

• Il tipo 2 riferisce sull'adeguatezza della progettazione e sull'efficacia operativa dei controlli lungo un periodo determinato, e contiene una descrizione dettagliata dei test sui controlli svolti dal service auditor e dei loro esiti.
• Il tipo 1 riguarda lo stesso oggetto ma non contiene un giudizio sull'efficacia operativa né la descrizione dei test.

Per questo la domanda «il pentest è obbligatorio?» ha una risposta pratica. Se la tua descrizione dice «una società indipendente esegue ogni anno un penetration test esterno e i finding sono seguiti fino alla correzione», l'auditor verifica quel controllo, di solito chiedendo il report, confrontandone la data con il periodo e seguendo un campione di finding fino alla chiusura. Un test saltato o finding non corretti diventano eccezioni nel report che leggono i tuoi clienti.

Aspettati richieste come queste:

1. Il report di penetration test datato nel periodo esaminato o comunque pertinente, con perimetro e metodologia.
2. Evidenze su chi l'ha eseguito e sul perché è qualificato e obiettivo.
3. I risultati delle scansioni di vulnerabilità nel periodo, comprese quelle dopo modifiche significative.
4. Ticket o registrazioni che mostrano priorità, correzione e retest dei finding, e l'approvazione di ogni rischio accettato.
5. Evidenze che i risultati sono arrivati al management e, dove serve, al consiglio (CC4.2).

Cadenza. I criteri non ne fissano una. Il punto di attenzione del CC4.1 chiede di variare perimetro e frequenza in base al rischio, e quello del CC7.1 chiede scansioni periodiche e dopo modifiche significative. L'intervallo che scrivi nella descrizione è quello che l'auditor verifica: scegline uno che puoi rispettare in ogni periodo. Se rispondi anche al PCI DSS o alla NYDFS Part 500, il loro minimo di un penetration test almeno annuale è un riferimento naturale; vedi la guida mondiale agli obblighi di penetration test per normativa.

Indipendenza. I criteri non richiedono un tester esterno. Chiedono valutatori con conoscenze sufficienti e valutazioni separate che diano un riscontro obiettivo. Un red team interno può soddisfarli se è separato da chi gestisce i sistemi nel perimetro; una società esterna per il test annuale rende comunque l'obiettività più facile da dimostrare.

Il service auditor è una società di revisione (CPA firm) indipendente da te, ma esamina i tuoi controlli: non esegue il tuo penetration test, e i suoi test sui controlli non lo sostituiscono.

Scritto nei criteri:

• CC4.1: valutazioni continue e/o separate per stabilire se le componenti del controllo interno sono presenti e funzionanti.
• CC7.1: procedure di rilevamento e monitoraggio delle modifiche di configurazione che introducono vulnerabilità e delle vulnerabilità scoperte di recente.
• CC3.2 e CC4.2: individuazione e analisi dei rischi, valutazione, comunicazione e correzione tempestiva delle carenze.

Punti di attenzione, pertinenti salvo prova contraria:

• Penetration test, scansioni di vulnerabilità e security assessment come tipi di valutazione (CC4.1, testo 2022).
• Scansioni di vulnerabilità periodiche e dopo modifiche significative, con correzione tempestiva (CC7.1).
• Valutatori competenti, perimetro e frequenza basati sul rischio, valutazioni separate obiettive.

Deciso dalla tua descrizione dei controlli:

• Se il penetration test fa parte dei tuoi controlli, e con quale frequenza, lo decidi tu; una volta che la descrizione del sistema lo dichiara, l'auditor lo verifica. Chiedi all'auditor e ai clienti principali cosa si aspettano prima che inizi il periodo di audit.

Non scritto da nessuna parte:

• Un penetration test obbligatorio, un intervallo fisso, un fornitore di test imposto o una certificazione del tester.

Zero Hunt è un red team AI autonomo per reti e infrastrutture: penetration test automatizzati su un'appliance on-premise, con AI privata e human in the loop. Non è una società di revisione, non emette né firma report SOC e non sostituisce il service auditor né il tester indipendente che indichi nella descrizione del sistema. Aggiunge evidenze per i mesi tra un test annuale e l'altro.

• Mappatura sui Trust Services Criteria. Il SOC 2 è uno dei 34 framework su cui il motore mappa i risultati, con i criteri del 2017 e i punti di attenzione del 2022. I finding alimentano in automatico il CC7.1 e, insieme alle evidenze che aggiungi tu, il CC4.1; lo stesso registro si esporta per l'auditor.
• Periodici e dopo modifiche significative. Campagne black box e gray box eseguite una volta, ogni giorno, ogni settimana, ogni mese o con una pianificazione personalizzata: le scansioni e i test promessi nella descrizione avvengono davvero, anche dopo le modifiche.
• Sfruttato, non solo rilevato. Ogni finding registra se la vulnerabilità è stata effettivamente sfruttata, ed è questo che distingue una priorità di correzione da una riga dello scanner; ogni correzione si ritesta con la stessa prova per il CC4.2.
• Approvazione umana dei passi rischiosi. Cinque livelli di autonomia stabiliscono cosa deve attendere un operatore. Vedi human in the loop.
• Registri che reggono per tutto il periodo di un tipo 2. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256, e i report esportati sono firmati ECDSA.
• Nessun dato del cliente lascia l'appliance. I modelli girano sull'appliance senza servizi AI esterni: nessun fornitore AI esterno tratta i risultati dei test.

Il SOC 2 Type II di Zero Hunt è pianificato, non ancora ottenuto; lo stato è nel Trust Center. Per verificare come si inserisce nella tua descrizione e nella matrice dei controlli, prenota una call di readiness di 30 minuti.

• 2017 Trust Services Criteria (With Revised Points of Focus, 2022), pagina della risorsa (AICPA & CIMA)
• 2017 Trust Services Criteria (With Revised Points of Focus, 2022), TSP section 100 (AICPA & CIMA, PDF)