Entrate in quasi qualsiasi azienda di software e chiedete dove vive la sua sicurezza. La risposta è raramente una persona con un mandato chiaro. È un foglio di calcolo con gli esiti dell'ultimo penetration test, una coda di ticket che qualcuno smaltisce lentamente e una casella di conformità da spuntare prima del lancio. Niente di tutto questo è sbagliato, in senso stretto - solo che non è una strategia di sicurezza. È un accumulo di cose successe, che ora si ripianano in ritardo.
La differenza conta perché il modello al ticket ha un tetto. Può solo reagire a ciò che è già stato trovato, e tratta la sicurezza come un centro di costi il cui unico compito è chiudere i buchi a posteriori. Una funzionalità, al contrario, è qualcosa che progetti, nomini, circoscrivi, costruisci e - punto chiave - misuri. Non si arriva alla seconda specie emettendo ticket.
Perché il modello al ticket fallisce in ritardo
Un arretrato di esiti di audit rassicura perché produce attività: i ticket si aprono, si assegnano, si chiudono. Ma quell'attività guarda indietro. Ripulisce ciò che l'ultimo audit ha notato per caso, che non è la stessa cosa di sapere a cosa un attaccante determinato potrebbe davvero arrivare. Le liste di esiti parlano del passato. Un modello di minacce parla del presente - e del futuro che conta, quello in cui il vostro prodotto cambia.
Peggio: il modello al ticket non ha un responsabile naturale oltre a chi tiene in mano il mouse quando arriva il prossimo audit. La sicurezza diventa la cosa che appartiene a tutti, che in pratica significa che non appartiene a nessuno. Il team pubblica una modifica che allarga in silenzio una regola di accesso, e nessuno se ne accorge fino al prossimo scan trimestrale. L'esito viene registrato, il ciclo si ripete e il sistema si sposta un po' più in là ogni volta.
La responsabilità vive in un titolare, non in una coda
Il primo passo per fare della sicurezza una funzionalità è darle un titolare nominato, con un mandato che sopravviva a un rilascio. Non un reparto sicurezza che audita da lontano - ma una persona o un team la cui descrizione del ruolo includa le parole « secure by design » e che sia nella stanza quando si decidono architettura e perimetro, non solo quando si manca una scadenza. Quando uno sviluppatore ha un dubbio su una decisione di controllo accessi, c'è una sola persona senza ambiguità a cui andare, e quella persona ha l'autorità di dire no.
La titolarità fa la differenza tra una checklist che si consulta e una checklist di cui si dà la colpa. Sulla carta le due sono identiche. La differenza emerge la prima volta che qualcuno deve prendere una decisione di giudizio sotto pressione, e la risposta a « chi decide? » è una persona, non una riunione.
Partite da un modello di minacce, non da una checklist di conformità
Le checklist di conformità sono tetti travestiti da pavimenti. Dicono il minimo che un auditor vuole vedere, e a un attaccante determinato il vostro auditor interessa poco. Ciò che davvero predice quanto danno può fare un attaccante è un modello di minacce: un resoconto scritto di ciò che un attaccante vorrebbe dal vostro sistema, delle vie che potrebbe prendere per ottenerlo e di quali di quelle vie vi farebbero più male.
Il modello non è un documento da archiviare una volta sola. È un artefatto vivo, aggiornato ogni volta che il sistema cambia in un modo che altera una superficie d'attacco - un nuovo tipo di dato, una nuova integrazione, un nuovo ruolo. Se una via cambia, cambiano anche i controlli che la proteggono. Una checklist risponde a « cosa siamo tenuti a mostrare? » Un modello di minacce risponde alla domanda che davvero vi tiene svegli la notte: « qual è il modo peggiore in cui questo può fallire, e abbiamo deciso che quel rischio è accettabile? »
La conformità vi dice cosa verificherà un auditor. Un modello di minacce vi dice cosa tenterà un attaccante. Solo uno dei due vi protegge.
Misurate i controlli, non la casella
Un controllo che non potete misurare è una casella. « L'API richiede autenticazione » suona come una dichiarazione e si comporta come una speranza. La sicurezza misurata si presenta diversa: quante credenziali esposte ci sono nel codice, e quel numero sta scendendo? Quanto tempo passa prima che si noti che una regola di accesso è stata allargata senza approvazione, e quel numero può essere portato da mesi a minuti? Quale percentuale di segreti viene ruotata con calendario, e qual è l'eccezione più longeva?
Scegliere le metriche è già di per sé lavoro di progettazione. Una funzionalità di sicurezza si misura come si misura qualsiasi funzionalità: vi accordate sul risultato, lo strumentate e guardate la linea di tendenza tra i rilasci invece di un sì/no binario in un solo giorno. Quando la sicurezza è misurata, diventa qualcosa che potete dirigere, budgetizzare e migliorare - che è esattamente quello che è una funzionalità, e quello che non è un ticket.
Prezzate la sicurezza come una funzionalità, non come una tassa
I team che trattano la sicurezza come una tassa la schiacciano nell'ultimo cinque per cento di uno sprint, proprio quando la pressione a consegnare è massima, il che garantisce che riceva il lavoro meno pensato. I team che la trattano come una funzionalità la circoscrivono come qualsiasi altra capacità: un'allocazione esplicita di tempo, un titolare proprio e un punto di revisione in cui la sua efficacia viene messa in discussione invece che data per scontata. La differenza non è lo sforzo - è il punto del ciclo in cui quello sforzo arriva.
Questa è anche una decisione di prezzo. Un partner che include la sicurezza come ripensamento non ha alcun incentivo a renderla misurabile, perché il suo costo è nascosto in un importo forfettario e la sua qualità non viene mai ispezionata. Un partner che tratta la sicurezza come un flusso di lavoro circoscritto vi dà le due cose che il modello al ticket non dà mai: una voce visibile di cui esigere conto e un modo per sapere - mentre il lavoro avviene, non dopo un incidente - se state ricevendo ciò per cui pagate.
Domande per il vostro prossimo fornitore
Chi è il titolare della sicurezza nel vostro team, e quella persona è nella stanza quando si concorda il perimetro - o solo quando qualcosa si rompe? Com'è il vostro attuale modello di minacce e quando è stato aggiornato l'ultima volta? Illustratemi un controllo di sicurezza che misurate tra i rilasci, e cosa mostra la linea di tendenza. Quando chiedo un audit di sicurezza, chi subisce le conseguenze degli esiti - voi o io? Se le risposte sono vaghe, la sicurezza è vaga, e i ticket saranno vostri.
La sicurezza come funzionalità è il modo in cui il software resta qualcosa che possedete invece di qualcosa di cui siete solo responsabili. In senso onesto non costa di più - investe lo sforzo prima e in modo visibile, dove può essere misurato e indirizzato, invece che dopo e in modo invisibile, dove può solo essere pagato. Il premio che pagate non è per più sicurezza. È per sapere, in ogni momento, esattamente quanto siete al sicuro.