La tragedia della sicurezza muore nel crogiolo di DevOps

La sicurezza non è più quella di una volta. O forse è sempre stata così e sembra diversa soltanto a causa della lenta erosione del mio idealismo giovanile.

La sicurezza è biforcata. Lungo un percorso ci impegniamo a mantenere sicure le nostre organizzazioni. Fermare gli attori malevoli, proteggere dati e asset e difendere gli utenti dalle minacce e persino dai loro stessi errori. Lungo l'altro percorso si trova la conformità. Garantire che l'organizzazione soddisfi gli standard normativi, contrattuali e di altro tipo. Su entrambi i percorsi gestiamo i rischi: i rischi di violazioni e interruzioni di servizio, oppure i rischi di sanzioni normative.

La tragedia della sicurezza è un riflesso della tragedia dei beni comuni. Da Wikipedia:

La maggior parte della conformità in ambito sicurezza è concepita per ridurre il rischio di sicurezza. Almeno sulla carta. Ma nel tempo abbiamo visto standard dopo standard, normativa dopo normativa, disaccoppiare il rischio dalla conformità. La natura stessa degli standard di conformità impedisce alle organizzazioni di adattare le misure di sicurezza ai rischi organizzativi. Non affermo che ciò sia sempre vero, ma lo è in larga misura, soprattutto man mano che si sale verso organizzazioni più grandi. Non esiste alcuna prova che imporre la reimpostazione delle password ogni 90 giorni a utenti dotati di MFA o di altre restrizioni condizionali oggi di uso comune migliori la sicurezza. La persona che ha inventato i requisiti di complessità delle password se ne rammarica letteralmente e afferma che non funzionano. Non esiste né una prova né una solida base scientifica per imporre la cifratura non predefinita di tutti i volumi di archiviazione presso un provider cloud.

La sicurezza è una risorsa condivisa e finita. Abbiamo solo una certa quantità di denaro, un certo numero di professionisti della sicurezza e una certa quantità di tempo che il personale non dedicato alla sicurezza può destinare alla sicurezza a scapito dei propri altri obiettivi. Più ci spostiamo verso la conformità, meno di questo insieme resta disponibile per la sicurezza. Meno la conformità è allineata alla sicurezza, minore è il numero di iniziative che riducono i rischi di sicurezza.

Questa è la tragedia della sicurezza. Abbiamo disaccoppiato il rischio dalla conformità, rendendo la mancanza di conformità il rischio stesso. Quanto più i rischi reali maggiori sono disaccoppiati dalla conformità, tanto più rigido è il regime di conformità, tanto minori sono le risorse di sicurezza disponibili per la difesa e tanto minore è il supporto degli altri team alle iniziative di sicurezza.

Un ottimo esempio è emerso in una conversazione con Chris Farris. Parafrasando,

Agli sviluppatori la sicurezza interessa eccome. È la conformità a essere un'irritazione. Aiutateli a rendere sicura la loro applicazione e la sosterranno. Diteli di accettare un'interruzione di 4 ore nel fine settimana per ricostruire il loro database con la cifratura perché lo pretende un fanatico della conformità e non otterrete altro che farli infuriare.

Non sto dicendo che tutta la conformità sia fatta di regole stupide, ma alcune regole di conformità lo sono, e l'applicazione impropria di regole valide, scollegate dai rischi, lo è davvero.

DevOps diventa il crogiolo del futuro della sicurezza perché nel mondo del cloud e di DevOps i singoli team applicativi diventano responsabili dell'intero stack, inclusa gran parte della sicurezza. Nuovi server, reti e firewall sono a un semplice git commit e a qualche chiamata API di distanza. Ciò comporta anche un onere maggiore per quei team nel gestire la propria sicurezza e conformità. Abbiamo ancora una sicurezza centralizzata e risorse di sicurezza condivise, ma quando si arriva alla punta di diamante dipendiamo senz'altro di più dai team DevOps. Non possiamo creare una grande DMZ per il cloud. I confini tra reti interne ed esterne non possono più essere classificati in zone standardizzate. Molte applicazioni costruite su servizi cloud nativi non hanno nemmeno più una rete e si basano su regole IAM e policy di risorse scritte in JSON e distribuite dai team applicativi tramite infrastructure as code.

Per questo un buon numero dei miei recenti progetti di conformità incentrati su cloud e DevOps riguarda più che altro il fare prima buona sicurezza, per poi capire come redigere un report che faccia sembrare che si rispetti la lettera della conformità anche quando non è così, pur essendo più sicuri.

Esistono due possibili soluzioni.

La prima consiste nel rivedere gli standard di sicurezza affinché si adattino meglio al cloud e a DevOps e nel ridurre il numero di regole stupide o non applicabili. Parte di questo lavoro è in corso, ma sono giunto alla convinzione che richieda un cambio generazionale che non abbiamo il tempo di attendere. Non rinunciamoci, ma non dobbiamo aspettare.

L'altra consiste nell'utilizzare l'automazione per sottrarre ai singoli quanto più possibile dell'onere di sicurezza e conformità, lasciando loro comunque la libertà e il controllo necessari per costruire rapidamente. Non suggerisco che l'insieme complessivo della sicurezza si riduca, ma che si usino l'automazione e altre tecnologie per ridurre la necessità individuale di bruciare cicli sulle attività di minor valore.

È una questione di tempo e di focalizzazione di risorse limitate. E in fondo, che cosa ha più valore… un buon penetration test o un audit di conformità? Ora guardate quanto spendete in penetration test e quanto pagate per un audit.