SOC 2 e penetration testing: cosa si aspettano davvero gli auditor

A ogni stagione di audit arriva lo stesso messaggio nella nostra casella di posta. Un fondatore ci inoltra la nota del suo auditor che chiede una “prova di penetration testing”, la finestra di audit si chiude tra tre settimane e in allegato c’è una scansione delle vulnerabilità del trimestre scorso con la domanda: vale? No. Ed è proprio in quel divario, tra ciò che un team presume soddisfi il requisito e ciò che un valutatore approverà davvero, che il penetration testing per SOC 2 crolla in silenzio.

Diciamo subito la parte scomoda. SOC 2 non impone un penetration test. Non c’è alcuna clausola nei Trust Services Criteria che reciti “farai un pentest ogni anno”. Ciò che il framework richiede è che tu monitori le vulnerabilità e dimostri che i tuoi controlli di sicurezza funzionano davvero. Un vero pentest si dà il caso sia la prova più pulita che puoi mettere davanti a un auditor per dimostrare entrambe le cose, ed è per questo che quasi ogni report Type II che seguiamo finisce per poggiare su di esso.

Quindi smetti di chiederti “mi serve un pentest per SOC 2”. Poniti le due domande che contano: cosa deve dimostrare il test, e cosa deve dire il report.

Punti chiave

• SOC 2 non nomina mai apertamente il penetration testing, ma richiede il monitoraggio delle vulnerabilità e la prova che i controlli funzionino, e un pentest è la prova più forte per entrambi.
• Un pentest si collega nel modo più diretto ai Common Criteria su valutazione del rischio e operatività dei sistemi, in particolare CC7.1, con il supporto di CC3.2 e CC4.1.
• Gli auditor vogliono uno scope che corrisponda al confine del tuo sistema di produzione, oltre alla prova che i finding siano stati tracciati e risolti, non una bella paginetta di riepilogo.
• Il test annuale è la baseline accettata, con un retest dopo cambiamenti significativi e dopo aver risolto i finding alti e critici.
• Una scansione delle vulnerabilità non è un penetration test, e spacciare l’una per l’altro è il motivo più comune per cui le prove vengono respinte.

Cosa chiede davvero SOC 2

SOC 2 poggia sui Trust Services Criteria dell’AICPA. La categoria Security, i Common Criteria, è obbligatoria in ogni report SOC 2. I criteri che riguardano i test si trovano nelle aree di valutazione del rischio e operatività dei sistemi.

CC7.1 è quello da mandare a memoria. Si aspetta che tu esegua procedure di rilevamento e monitoraggio che intercettino i cambiamenti di configurazione che introducono vulnerabilità e l’esposizione a quelle appena scoperte. Un penetration test è un modo diretto e difendibile per mostrare che stai facendo esattamente questo contro la tua superficie di attacco, invece di dare per scontato che le tue difese reggano. CC3.2 copre l’individuazione e l’analisi del rischio. CC4.1 copre la valutazione continua del funzionamento dei controlli. Un report di pentest ben costruito risponde a tutti e tre in una volta sola. Ecco perché ai valutatori piace riceverne uno.

Ecco il punto su cui SOC 2 è davvero pignolo: l’efficacia operativa nel tempo. In un report Type II, che copre un periodo di osservazione anziché una singola data, non basta dire che un controllo esiste. Devi dimostrare che ha svolto il suo compito per tutta la finestra. Un test che porta a galla problemi reali, insieme a una traccia di remediation che li chiude, racconta quella storia molto meglio di quanto farà mai un PDF di policy.

Come un pentest si collega ai Common Criteria

L’errore ricorrente è trattare il pentest come un artefatto a sé stante invece di collegarlo a criteri precisi. Gli auditor ragionano in termini di mappature dei controlli. Quindi consegna loro la mappatura.

In concreto: la sezione su scope e metodologia supporta CC3.2, l’individuazione e l’analisi del rischio. I finding stessi sono la prova per CC7.1, il rilevamento delle vulnerabilità. L’attività di remediation e retest supporta CC7.4, la risposta ai problemi di sicurezza individuati e la loro risoluzione. Struttura il report in modo che un valutatore possa indicare un finding, poi il ticket che lo ha corretto, poi il retest che ha confermato la correzione, e avrai coperto ciò su cui la maggior parte delle aziende inciampa: dimostrare che il controllo ha funzionato, non solo che esisteva sulla carta.

Il report che un auditor adora è noioso nel migliore dei modi. Scope chiaro, finding reali, remediation tracciata, retest confermato. Nessun dramma, piena tracciabilità.

Quale scope deve coprire un pentest SOC 2?

Lo scope deve rispecchiare il confine del sistema descritto nel tuo report SOC 2. In pratica significa la tua applicazione di produzione e l’infrastruttura che le sta dietro. Se la tua piattaforma SaaS, la sua API e l’ambiente cloud che la sostiene sono tutti nominati nel report, fanno parte del test. Un pentest che esclude in sordina proprio ciò a cui i tuoi clienti accedono ogni giorno è un campanello d’allarme, e un valutatore esperto se ne accorgerà.

Per la maggior parte delle aziende SaaS che si avviano verso SOC 2, questo si scompone in una manciata di filoni di lavoro concreti. Un test dell’applicazione web sia sulla superficie autenticata sia su quella non autenticata, perché il broken access control e i difetti di autorizzazione sono ciò che segnaliamo più spesso in questi ingaggi. Un test dell’API, dato che oggi gran parte della reale superficie di attacco si nasconde in endpoint non documentati o poco testati. E, dove si applica, un test di rete esterno dei servizi esposti su internet inclusi nello scope.

Fissiamo il confine per iscritto prima che parta una sola richiesta. La più grande causa in assoluto di una contestazione sulle prove più avanti è una definizione di scope sfumata in cui nessuno sa dire se un componente fosse dentro o fuori. Mettilo nero su bianco. Elenca gli host e le applicazioni inclusi nello scope. Annota ogni esclusione e il relativo motivo.

Come lo eseguiamo e cosa compare nel report

Un test allineato a SOC 2 si svolge comunque come un vero pentest, non come un rituale di conformità. Lavoriamo a partire da una metodologia consolidata, le guide di test OWASP per web e API oltre a una metodologia di rete standard per l’infrastruttura, affianchiamo gli strumenti automatizzati alla verifica manuale e confermiamo ogni finding a mano. Burp Suite per il lavoro interattivo, ffuf per la discovery di contenuti e parametri, nuclei per setacciare i problemi noti su larga scala. Questi ci danno la copertura. I critici arrivano quasi sempre dallo strato manuale: concatenare una falla di autorizzazione fino ai dati di un altro tenant, oppure trasformare una stack trace verbosa in una fuga di informazioni che alimenta il passo successivo.

Proprio quel lavoro manuale è ciò che SOC 2 vuole sondare. Un auditor vuole sapere se i tuoi controlli reggono di fronte a un attaccante motivato. Uno scanner che segnala un cifrario TLS debole non risponde a questa domanda. Un tester che dimostra come un account con privilegi bassi possa raggiungere una funzione riservata agli amministratori, sì.

Poniamo che un account di test sia limitato all’ID account 1042 e che percorriamo a mano l’identificatore dell’oggetto:

$ curl -s https://app.acme-corp.example.com/api/v2/accounts/1043/invoices \
    -H "Authorization: Bearer <low-priv-user-token>"

{"account_id":1043,"invoices":[ ... another tenant's billing data ... ]}

Un insecure direct object reference del genere, CWE-639, per un auditor risulta molto più convincente di una pagina di output di uno scanner. Mostra che un controllo che sarebbe dovuto esistere semplicemente non c’era.

Il report ha bisogno di alcune cose precise per superare la revisione di audit. Una chiara dichiarazione di scope e di confine. Una descrizione della metodologia. Finding classificati per gravità, con dettaglio tecnico sufficiente a riprodurli e a dimostrare che sono reali, non teorici. Indicazioni di remediation per ogni finding. Date di test che cadano all’interno del periodo di audit o ragionevolmente prima. E, idealmente, un’attestazione di retest che confermi la chiusura degli elementi alti e critici. È quest’ultimo pezzo a trasformare “abbiamo trovato problemi” in “il nostro controllo ha funzionato e abbiamo colmato la lacuna”. Quella frase è l’intera narrazione di SOC 2.

Ogni quanto occorre testare per SOC 2?

Una volta all’anno è la baseline accettata, ed è ciò che la maggior parte degli auditor si aspetta per un report Type II ricorrente. Oltre alla cadenza annuale, ripeti il test dopo qualsiasi cambiamento significativo al sistema incluso nello scope, e ripeti il test per confermare la remediation dei finding alti e critici. Rilascia una funzionalità importante a metà anno e un test precedente a quel rilascio diventa una prova più debole per il periodo corrente. Un valutatore attento segnalerà la discrepanza.

Per un primo SOC 2, testa durante la fase di readiness, prima che si apra la finestra di osservazione. Guadagni tempo per correggere i finding e costruire una traccia di remediation pulita, invece di affannarti a chiudere i critici mentre l’auditor sta già guardando.

Come aiuta CyberXplore

Eseguiamo penetration test per SOC 2 pensati per arrivare dritti al tuo auditor. Uno scope allineato al confine del tuo sistema, test a guida manuale che intercettano ciò che gli scanner si lasciano sfuggire, finding collegati ai Common Criteria pertinenti e un retest per chiudere il cerchio sugli elementi alti e critici. Se ti stai preparando per un Type I o un Type II, il nostro servizio di readiness per SOC 2 gestisce insieme il test e la preparazione delle prove, così non resti a tradurre da solo un report di pentest grezzo nel linguaggio dell’audit. Quando sei pronto a definirne lo scope, richiedi un preventivo e allineeremo l’ingaggio al confine del tuo report e alla tua tempistica di audit.

FAQ

SOC 2 richiede un penetration test?

Non per nome. SOC 2 richiede che tu monitori le vulnerabilità e dimostri che i tuoi controlli funzionano in modo efficace, soprattutto attraverso i Common Criteria come CC7.1. Un penetration test è il modo più diretto e ampiamente accettato per produrre quella prova, quindi la maggior parte dei report SOC 2 si appoggia a uno anche se lo standard non usa mai l’espressione esatta.

Una scansione delle vulnerabilità basta per SOC 2?

No, e questo è il motivo più comune per cui le prove vengono rimandate indietro. Una scansione elenca problemi noti da un database di firme. Un penetration test aggiunge test manuali, sfruttamento e analisi della logica di business che uno scanner non può svolgere. Gli auditor conoscono sempre di più la differenza e chiederanno se il test manuale faceva parte del lavoro.

Ogni quanto dovremmo eseguire un penetration test per SOC 2?

Una volta all’anno è la baseline, più un retest dopo cambiamenti significativi al sistema e dopo aver risolto i finding alti o critici. Per un primo audit, testa durante la fase di readiness così da avere il tempo di correggere i problemi prima che si apra la finestra di osservazione.

Cosa deve includere il report di pentest per l’auditor?

Uno scope e un confine del sistema definiti, una descrizione della metodologia, finding classificati per gravità con il dettaglio di riproduzione, indicazioni di remediation, date di test comprese nel periodo di audit o precedenti e, idealmente, un’attestazione di retest. La traccia di remediation e retest è ciò che dimostra che il controllo ha davvero funzionato, e questo è il cuore di un report Type II.

Chi definisce lo scope, noi o l’auditor?

Lo definite tu e il tuo partner di test, ma deve corrispondere al confine del sistema nel tuo report SOC 2. Se l’audit copre la tua applicazione di produzione, l’API e l’infrastruttura di supporto, il test dovrebbe coprire lo stesso. Testare una fetta più stretta di quella descritta nel report è il classico disallineamento di scope che causa contestazioni più avanti.