Il tuo SOC 2 non è la tua sicurezza

Ogni fondatore fintech alla fine ha la stessa conversazione con il primo cliente enterprise. Il cliente chiede il SOC 2. Il fondatore lo commissiona. Sei mesi e quarantamila dollari dopo, l'audit si chiude pulito e il deal si chiude con esso.

Poi passa un anno, il prodotto cresce, e un tranquillo martedì il team di sicurezza trova qualcosa che non dovrebbe esserci. L'audit era pulito. Il sistema non lo era.

Questo non è una condanna del SOC 2. È una descrizione onesta di cosa è e non è il SOC 2, e dove vive il divario tra i due.

Cosa attesta davvero SOC 2

Un audit SOC 2 Type II conferma che si hanno controlli in atto e che quei controlli hanno operato come progettato durante una finestra — tipicamente tre, sei o dodici mesi. È un audit di processo. Il revisore verifica che si faccia quello che le proprie politiche dicono di fare.

Le politiche sono scritte da voi. Il perimetro è definito da voi. Il revisore controlla che abbiate seguito le vostre stesse regole.

Questo ha valore reale. Significa che un acquirente può chiedere "registrate gli accessi?" e fidarsi della risposta. Significa che un regolatore può vedere che prendete i controlli sul serio. Significa che un tribunale, se dovesse arrivare a questo, può vedere che avete esercitato una cura ragionevole.

Quello che non significa è che i controlli che avete scritto siano sufficienti, che il modello di minaccia che avete immaginato corrisponda a quello che affrontate davvero, o che l'implementazione di quei controlli sia priva di bug.

Il problema dei due sistemi

I sistemi fintech di solito hanno due posture di sicurezza che operano in parallelo.

La prima è la postura dichiarata — quello che dicono le vostre politiche, quello che descrivono i vostri runbook, quello che vede il revisore. È quello che attesta SOC 2.

La seconda è la postura vissuta — quello che accade davvero in produzione alle 3 di mattina quando un ingegnere on-call risponde a un incidente. Com'è l'ambiente di staging dopo sei mesi di "lo ripuliamo dopo." Cosa fa davvero l'SDK di terze parti che gestisce la tokenizzazione della carta.

La maggior parte delle violazioni non avviene perché la postura dichiarata era sbagliata. Avviene perché la postura vissuta si è discostata da essa e nessuno se n'è accorto.

Cosa fare davvero

Ci sono tre abitudini che colmano il divario.

Trattare l'audit come un pavimento, non un soffitto. Il revisore controlla che vengano registrati gli accessi. Bene. Poi chiedersi: stiamo registrando le cose giuste? Stiamo revisionando i log? Le azioni di un insider determinato risalterebbero, o sarebbero invisibili nel rumore? SOC 2 non farà questa domanda. Voi dovreste.

Eseguire esercizi di sicurezza sul sistema vissuto. Un tabletop su un incidente reale ogni trimestre. Un esercizio red-team annualmente. Qualcuno al di fuori del team che tenta di esfiltrare dati di test usando solo informazioni pubbliche. Gli esercizi che trovano di più sono di solito quelli che puntano al divario tra il runbook e la realtà.

Prestare molta attenzione alla deriva silenziosa. Un nuovo SDK viene aggiunto senza una security review. Un database di staging viene alimentato con uno snapshot della produzione. I permessi di un fornitore vengono ampliati "temporaneamente" e mai ristretti. Questa deriva è ciò che gli audit non vedono e le violazioni fanno.

L'offerta onesta

Un SOC 2 pulito è necessario. Non è anche sufficiente. Le agenzie e i consulenti che lo trattano come il traguardo — e ce ne sono molti — vi stanno vendendo l'audit, non la sicurezza.

Quando rilasciamo sistemi fintech, rilasciamo verso la postura vissuta, non quella dichiarata. L'audit si chiude di solito pulito come effetto collaterale. Questo è l'ordine in cui il lavoro deve avvenire.