Penetration test per SOC 2: scegliere un test che dia informazioni utili sulla sicurezza

Un penetration test fornisce evidenze sulle vulnerabilità sfruttabili di un sistema definito. Il suo valore dipende da che cosa esaminano i tester, da come lo indagano e da che cosa fa il team di engineering con i risultati. Un report che tralascia i confini di fiducia rilevanti del prodotto può soddisfare una scadenza interna, ma dire ben poco sulla sicurezza.

Per un CTO, la domanda utile non è semplicemente se un test sia stato svolto. È se l'incarico metta davvero alla prova i controlli che proteggono i dati dei clienti e produca risultati che il team possa riprodurre, correggere e verificare.

Che cosa richiede il SOC 2 e che cosa no

Il SOC 2 è un report di attestazione, non una certificazione. I suoi criteri sono basati su principi: non impongono a ogni organizzazione un requisito universale di penetration test né una cadenza annuale. Sono il rischio, i controlli che descrivete, le aspettative dell'auditor e i contratti con i clienti a determinare quali test siano appropriati.

Discutete con il vostro auditor l'obiettivo e le evidenze attese prima di commissionare l'incarico. Se un controllo documentato promette una determinata frequenza o un determinato perimetro di test, preparatevi a dimostrare di aver mantenuto quell'impegno.

Le garanzie per i clienti sono una questione a parte. Un acquirente può esigere un test applicativo indipendente anche quando il vostro approccio all'audit non lo prevede. Chiarite presto queste aspettative, ma non lasciate che una checklist dell'ufficio acquisti sostituisca la definizione tecnica del perimetro. Né un report SOC 2 né un penetration test dimostrano che un sistema sia privo di vulnerabilità.

Definire il perimetro della superficie di attacco, non solo del sito web

Partite dall'architettura, dai flussi di dati sensibili e dai confini di fiducia. La guida di OWASP al threat modeling offre una base utile per individuare che cosa potrebbe andare storto e dove concentrare i test.

Per un prodotto SaaS multi-tenant, testare solo la landing page pubblica lascia inesplorati i confini applicativi importanti. Fornite al fornitore un inventario che comprenda API, elaborazioni in background, strumenti amministrativi e infrastruttura rilevante, non soltanto un elenco di domini.

Indicate esplicitamente esclusioni e limitazioni. Un client mobile non testato, un ruolo non disponibile o un ambiente inaccessibile devono restare visibili nel report finale. Il perimetro dovrebbe inoltre distinguere i sistemi di vostra proprietà dai servizi di terze parti che non potete autorizzare i tester ad attaccare.

Scegliere un metodo che risponda alle vostre domande

La scansione automatizzata individua potenziali vulnerabilità e supporta l'igiene ricorrente. Un penetration test aggiunge un'indagine qualificata sulla sfruttabilità e sui percorsi di attacco significativi all'interno di un perimetro autorizzato. Gli strumenti sono utili; l'output di uno scanner rietichettato come penetration test non equivale a quell'indagine.

Il test black-box parte da una conoscenza limitata del sistema. Il test gray-box fornisce informazioni o accessi selezionati, spesso compresi degli account. Il test white-box offre una visibilità più profonda, che può includere codice sorgente e architettura. Questi approcci rispondono a domande diverse anziché costituire una semplice classifica di qualità.

Per i test di autorizzazione applicativa, account distribuiti su più ruoli e tenant possono rendere l'indagine più efficace. Un test della sola infrastruttura esterna non può stabilire se gli utenti autenticati siano in grado di oltrepassare i confini tra tenant.

Valutare il fornitore e i deliverable

Chiedete chi svolgerà il lavoro e se ha già testato architetture paragonabili. Le qualifiche pertinenti supportano la due diligence, ma le certificazioni da sole non dimostrano una competenza specifica sull'applicazione. Richiedete un report di esempio anonimizzato e discutete di come il team indaga la logica di business, non solo le vulnerabilità software note.

Prima di firmare, chiarite:

• Quali sistemi, ruoli e percorsi di attacco sono coperti e come viene distribuito l'impegno.
• Quale indagine manuale integra gli strumenti automatizzati.
• Come vengono comunicati i risultati urgenti prima del report finale.
• Se i risultati includono evidenze riproducibili, componenti interessati, impatto e indicazioni per la remediation.
• Se il retest è incluso, entro quale finestra temporale e che cosa succede se le correzioni arrivano più tardi.
• Come vengono protetti ed eliminati, a tempo debito, report, credenziali e dati raccolti.

Confrontate le offerte in base a copertura e deliverable, non solo al prezzo. Un preventivo più basso può corrispondere a un incarico più ristretto anziché a un lavoro equivalente svolto in modo più efficiente.

Stabilire regole di esecuzione sicure

Documentate l'autorizzazione e le regole di ingaggio prima che inizino i test. Indicate host, account, ambienti e finestre di test approvati, contatti di emergenza e condizioni di interruzione. Concordate se siano esclusi test di denial of service, social engineering, persistenza o estrazione di dati.

I test in produzione possono far emergere problemi di configurazione reali, ma creano anche un rischio operativo. Un ambiente di staging rappresentativo può essere più sicuro, a condizione che le differenze rispetto alla produzione siano documentate. Utilizzate dati di tenant sintetici ove possibile e concordate quali evidenze siano sufficienti a dimostrare l'impatto senza raccogliere informazioni dei clienti non necessarie.

Assicuratevi che i team di monitoraggio sappiano distinguere l'attività autorizzata da un incidente non correlato. I test non dovrebbero diventare un pretesto per disattivare i controlli di protezione senza documentarne le conseguenze.

Esempio pratico: un risultato sull'isolamento dei tenant

Consideriamo un incarico SaaS a scopo illustrativo. Supponiamo che il prodotto abbia due tenant di test, utenti ordinari, amministratori di tenant e un ruolo di supporto. Il test comprende le API autenticate e i workflow di esportazione; l'infrastruttura di identità di terze parti è esclusa.

Un tester scopre che un endpoint di esportazione verifica il login ma non applica in modo coerente l'appartenenza al tenant. Utilizzando record sintetici, dimostra che un utente del tenant A può richiedere un'esportazione appartenente al tenant B.

Il risultato dovrebbe indicare l'endpoint, i privilegi necessari, il workflow interessato, le evidenze riproducibili e l'impatto sul business. Il team di engineering riconduce il problema a un worker in background che si fida di un identificatore di tenant fornito dalla richiesta.

La correzione verifica l'appartenenza prima di pianificare l'esportazione e di nuovo al momento del suo recupero. I test di regressione coprono le richieste tra tenant diversi e i ruoli pertinenti. Il retest conferma che il percorso originale è bloccato e controlla i percorsi di esportazione correlati. Il team conserva il risultato originale, le evidenze dell'implementazione e l'esito del retest; non si limita a segnare il ticket come "completato".

Trasformare i risultati in lavoro di engineering con responsabilità chiare

Classificate i risultati in base alla gravità tecnica e all'esposizione per il business. Considerate i privilegi necessari, l'esposizione su Internet, i dati interessati, l'affidabilità dell'exploit e i controlli compensativi. Un problema nominalmente moderato può meritare un trattamento urgente quando viola un confine critico per i clienti.

Assegnate a ogni risultato un responsabile, una data obiettivo e un metodo di verifica. Ove opportuno, adottate una mitigazione provvisoria mentre preparate la correzione definitiva. Fate approvare ogni rischio residuo accettato da un risk owner designato, con motivazione e data di revisione; il silenzio del team di engineering non equivale ad accettazione.

Registrate la versione del prodotto e l'ambiente testati. Un risultato precedente a un'importante riprogettazione delle autorizzazioni non può descrivere la nuova implementazione. Come raccomandazione pratica, rivalutate le esigenze di test dopo modifiche architetturali rilevanti, incidenti gravi o nuove esposizioni, oltre alla cadenza già stabilita.

Mantenere le evidenze utili per auditor e clienti

Conservate il perimetro concordato, le regole di ingaggio, il report finale, la documentazione della remediation, le evidenze del retest e le decisioni sul rischio. Mantenete il report completo ad accesso riservato, perché può contenere dettagli sensibili sugli exploit.

Preparate una sintesi per i clienti che descriva date del test, perimetro, metodologia, limitazioni e stato della remediation senza esporre inutilmente istruzioni di attacco. Per le domande successive, leggete la nostra guida alla valutazione delle garanzie di sicurezza.

In Secani, collegate le evidenze del test ai sistemi, ai requisiti, ai controlli, ai responsabili e alle decisioni di revisione pertinenti. Tracciate le lacune nelle evidenze come attività e mantenete l'approvazione umana delle conclusioni. In questo modo il rapporto tra ciò che è stato testato e ciò che è cambiato resta disponibile per le revisioni successive.

Prima di richiedere offerte, redigete un perimetro di una pagina che copra confini di fiducia, account di test, esclusioni, deliverable e aspettative sul retest. Quel documento offre al fornitore, all'auditor e al team di engineering una base comune per un test che dia informazioni utili sulla sicurezza.