Costo del penetration test SOC 2
SOC 2 non contiene un controllo che dica "esegui un penetration test". Gli auditor se lo aspettano comunque, e la maggior parte delle società di readiness insiste. Capire perché spiega cosa il test deve produrre, e quindi cosa vi serve davvero comprare.
Perché un framework che non nomina mai i test li richiede comunque
SOC 2 si basa sui Trust Services Criteria, scritti come esiti e non come una checklist di attività. Non esiste un controllo numerato "penetration testing". Questo porta a uno di due errori: presumere che non serva alcun test, oppure comprarne uno grande perché l'ha detto un fornitore di readiness.
L'inquadramento utile è che un penetration test è evidenza, non un requisito. È il modo più pratico, per la maggior parte delle organizzazioni, di dimostrare due cose:
- CC4.1 - che eseguite valutazioni per determinare se i vostri controlli sono effettivamente presenti e funzionanti. Un test indipendente è una valutazione diretta, datata e prodotta esternamente, esattamente ciò che questo criterio cerca.
- CC7.1 - che rilevate vulnerabilità e cambi di configurazione non autorizzati. La scansione copre parte di questo in modo continuo; un test copre la parte che la scansione non raggiunge.
Poiché è una questione di evidenze e non una casella di compliance, l'opinione che conta è quella del vostro auditor. Chiedetegli specificamente e per iscritto cosa accetterà prima di dimensionare qualsiasi cosa. Gli auditor differiscono, e la differenza vale a volte migliaia di dollari di perimetro.
Come devono essere le evidenze
Un report da solo è il modo più comune in cui questo controllo riceve comunque un rilievo. La catena di evidenze completa ha quattro parti, e le lacune sono quasi sempre nelle ultime due.
- Perimetro. Il perimetro testato deve essere riconoscibilmente il sistema descritto nel vostro report SOC 2. Se la vostra descrizione del sistema copre una piattaforma SaaS multi-tenant e il test ha coperto un sito vetrina non autenticato, la discrepanza si vede subito.
- Risultati. Valutati per gravità, con motivazione dichiarata anziché un colore non spiegato, e con passi di riproduzione.
- Remediation. Documentata, con date, e con una decisione registrata per tutto ciò che viene accettato anziché corretto. L'accettazione del rischio è ammessa; il silenzio no.
- Verifica. Evidenza che le correzioni sono state ritestate e confermate. È la parte che manca più spesso, ed è quella che trasforma un report nella prova che un controllo funziona.
Una lettera di attestazione che indichi cosa è stato testato, quando, da chi e con quale esito è ciò che lega il tutto per l'auditor, ed è ciò che i vostri clienti chiederanno in seguito. Dovrebbe far parte dell'incarico e non essere un acquisto separato.
Tempi rispetto alla finestra di osservazione
Per il Tipo I, che valuta la progettazione in un dato momento, di solito bastano un test recente e un piano di remediation credibile. Per il Tipo II, che valuta l'efficacia operativa su un periodo tipicamente da tre a dodici mesi, test, remediation e retest devono cadere dentro la finestra. Prenotare un test tre settimane prima della chiusura della finestra non lascia spazio al ciclo correggi-e-ritesta, ed è l'errore di pianificazione più comune.
A ritroso: tre-cinque giorni lavorativi di test per un'applicazione piccola, una-tre settimane perché i vostri ingegneri correggano l'essenziale, e qualche giorno per il retest. Un mese dentro la finestra è comodo. Una settimana no.
Dimensionare per SOC 2 senza comprare troppo
Il perimetro dovrebbe essere il sistema della vostra descrizione del sistema, che per la maggior parte delle aziende SaaS è il prodotto e l'infrastruttura su cui gira. In pratica significa l'applicazione autenticata con ogni ruolo utente, il confine fra tenant, l'API e l'ambiente cloud che la ospita.
Cosa viene spesso venduto dentro il perimetro SOC 2 e raramente vi appartiene: la vostra flotta di portatili, se è fuori dalla descrizione del sistema; una valutazione completa di Active Directory, se non avete un dominio aziendale; e un ingaggio red team, che risponde a una domanda del tutto diversa da quella che pone CC4.1. Se un fornitore di readiness vi ha quotato tutto questo, chiedetegli quale criterio evidenzia ciascuna voce.
Quanto costa
SOC 2 non cambia il costo del test, solo la documentazione che vi serve. Per un tipico prodotto SaaS, un perimetro applicativo parte da 500 $ e copre il prodotto autenticato, i ruoli, l'isolamento fra tenant e l'API. Non appena infrastruttura cloud o una rete aziendale sono davvero dentro la descrizione del sistema, diventa un perimetro infrastruttura da 1.500 $.
Supporto alla remediation, retest e lettera di attestazione sono inclusi anziché fatturati a parte, il che qui conta più che nella maggior parte degli incarichi, perché sono precisamente gli artefatti che l'auditor chiederà. La pagina di servizio penetration test SOC 2 tratta il test più in profondità, costo del penetration test spiega il modello generale, e il report di esempio mostra il formato che riceverà un auditor.
Se siete soggetti anche a PCI DSS, i due possono spesso condividere un unico incarico, anche se i requisiti di evidenza differiscono. Vedete costo del penetration test PCI DSS, o test guidato dalla compliance per come si gestiscono i framework sovrapposti.
Domande sui test SOC 2
State dimensionando un test per una finestra SOC 2?
Portate il requisito del vostro auditor e la finestra di osservazione e dimensionerò a ritroso dalla data.