Criteri · Evidenze · Prezzo

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

Non per nome. I Trust Services Criteria sono scritti deliberatamente come esiti e non come attività prescritte, e nessun criterio contiene le parole "penetration test". In pratica un test è il modo normale di evidenziare CC4.1, che copre le valutazioni su se i controlli funzionano, e supporta CC7.1 sul rilevamento di vulnerabilità e cambi di configurazione. È il vostro auditor a decidere cosa soddisfa i criteri, quindi la risposta definitiva viene da lì. Chiedete presto, perché la risposta determina perimetro e tempi.
Cambia più i tempi che il test. Il Tipo I esamina se i controlli sono progettati adeguatamente in un dato momento, quindi di solito bastano un test recente e un piano di remediation. Il Tipo II esamina l'efficacia operativa su un periodo, tipicamente da tre a dodici mesi, quindi l'auditor vuole vedere test, remediation e retest tutti dentro la finestra di osservazione. Programmare un test troppo tardi in una finestra Tipo II è un errore comune e costoso.
Di solito quattro cose: un perimetro definito che copra plausibilmente il sistema della vostra descrizione, risultati con gravità e motivazione dichiarata, remediation documentata con date, ed evidenza che le correzioni sono state verificate. Una lettera di attestazione che indichi cosa è stato testato e quando lega il tutto. Un report da solo, senza traccia di remediation, è il motivo più comune per cui questo controllo riceve un rilievo.
Il framework non cambia il costo sottostante del test, solo le evidenze che vi servono. Per un tipico prodotto SaaS significa un perimetro applicativo da 500 $, oppure da 1.500 $ quando l'infrastruttura cloud o una rete aziendale entrano davvero nel perimetro. Le società che commercializzano uno specifico "pentest SOC 2" di solito vendono lo stesso test con la documentazione confezionata diversamente.
Il test annuale è la base comune che gli auditor accettano, con un test aggiuntivo dopo un cambiamento architetturale significativo. Poiché il Tipo II guarda un periodo e non una data, il requisito pratico è che esistano evidenze di test e remediation dentro ogni finestra di osservazione, non che un test avvenga in una data precisa.

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.

Contatti