Agile è la parola d'ordine dell'IT. Da uno sforzo benintenzionato per migliorare la qualità del software e la velocità di consegna, negli ultimi vent'anni è stato sempre più venduto erroneamente come una panacea per curare tutti i mali dell'IT. La metodologia privilegia l'autonomia, la velocità di consegna e l'etica del "move fast, fail fast", che è sufficiente a far fare una smorfia a qualsiasi CISO.
Mentre il dogma Agile continua a diffondersi, il nostro compito di leader spassionati della sicurezza è quello di reagire.
Agente di cambiamento o agente di sventura?
Agile ha i suoi vantaggi. Come approccio iterativo allo sviluppo del software, può aiutare i team a velocizzare il time-to-market e a rimuovere gli ostacoli. Può essere particolarmente efficace per organizzazioni e team di piccole dimensioni. Ma non è scalabile e non ama gli ambienti complessi ed eterogenei. Di certo non trasformerà un team di consegna fallito in uno efficace.
Eppure l'Agile viene sempre più spesso adottato come modello operativo a livello tecnologico per guidare la trasformazione ovunque, dagli helpdesk ai data center. I CIO evangelizzatori sono incoraggiati da un'azienda che non ne comprende le sfumature. Si dice che circa la metà delle aziende utilizzi le pratiche Agile per la trasformazione da almeno tre anni. Ma è sempre appropriato?
Dite semplicemente no
In passato ho lavorato con numerosi CIO di aziende FTSE 100 che dicevano: "Stiamo diventando Agili". In realtà intendono dire: "Ora siamo autonomi, quindi non abbiamo bisogno di interagire con la sicurezza e stiamo rinunciando alla governance aziendale".
Un'altra richiesta classica: "Puoi darmi un'eccezione di accettazione del rischio/sicurezza?" che potrebbe essere più accuratamente tradotta come: "Potete compromettere la sicurezza per aiutarmi a raggiungere i miei obiettivi di consegna Agile?".
Una risposta appropriata da parte del CISO sarebbe: "Certo, a patto che siate pronti ad assumervi la piena responsabilità quando le cose vanno male".
La sicurezza deve essere accettata come requisito funzionale obbligatorio di qualsiasi progetto. Sappiamo tutti che inserirla nella progettazione fin dall'inizio è più economico, più facile e più sicuro che adattarla a posteriori. Eppure è sorprendente vedere come molti progetti Agile prevedano l'"approvazione della sicurezza" come ultimo compito dello sprint, causando inevitabilmente dei ritardi.
La conformità normativa di base è praticamente irrilevante nel panorama odierno delle minacce. Dobbiamo invece effettuare test con strumenti capaci e, se del caso, con red team indipendenti. I CISO hanno bisogno di strumenti in grado di monitorare da vicino gli ambienti, gli errori e le configurazioni errate per ridurre efficacemente i rischi. L'azienda deve rendersi conto che un prodotto non è completo finché non sono soddisfatti tutti i requisiti di sicurezza.
La realtà è che, come CISO, siamo la coscienza dell'organizzazione. Affinché i progetti Agile abbiano successo, potrebbe essere necessario rallentare un po' le cose e porre alcune domande difficili. A volte dobbiamo mettere in discussione la fede dogmatica di molti CIO e dei loro team.
Va bene essere il cattivo. Dite no ad Agile quando esistono approcci migliori e di buon senso.
https://www.theregister.com/2021/12/16/move_fast_break_security_why/