Agile è uno dei termini più in voga nel mondo dell'IT. Da iniziale tentativo ben intenzionato di migliorare la qualità del software e la velocità di consegna, negli ultimi vent'anni è stato sempre più spesso venduto come una panacea in grado di curare tutti i mali dell'IT. La metodologia privilegia l'autonomia, la velocità di consegna e una filosofia del "muoversi velocemente, fallire velocemente", che è sufficiente a far storcere il naso a qualsiasi CISO.
Mentre il dogma Agile continua a diffondersi, è nostro compito, in qualità di leader della sicurezza imparziali, opporci.
Agente di cambiamento o agente di sventura?
Agile ha i suoi vantaggi. Come approccio iterativo allo sviluppo di software, può aiutare i team ad accelerare il time-to-market e rimuovere gli ostacoli. Può essere particolarmente efficace per le piccole organizzazioni e i team di piccole dimensioni. Tuttavia, non è facilmente scalabile e non si adatta bene agli ambienti eterogenei complessi. Di certo non trasformerà un team di consegna fallimentare in uno efficace.
Eppure Agile viene sempre più adottato come modello operativo a livello tecnologico, per guidare la trasformazione in ogni ambito, dagli helpdesk ai data center. I CIO che ne promuovono l'adozione sono incoraggiati da aziende che non ne comprendono le sfumature. Si dice che circa la metà delle aziende utilizzi pratiche Agile per la trasformazione da almeno tre anni. Ma è sempre appropriato?
Basta dire no
In passato ho lavorato con numerosi team di CIO dell'indice FTSE 100 che dicevano: "Stiamo passando all'Agile". In realtà intendevano dire: "Ora siamo autonomi, quindi non abbiamo bisogno di interagire con la sicurezza e stiamo rinunciando alla governance aziendale".
Un'altra richiesta classica: "Puoi concedermi un'eccezione in materia di accettazione del rischio/sicurezza?", che potrebbe essere tradotta in modo più accurato come: "Puoi compromettere la sicurezza per aiutarmi a raggiungere i miei obiettivi di consegna Agile?".
Una risposta appropriata da parte del CISO sarebbe: "Certamente, purché siate disposti ad assumervi la piena responsabilità in caso di problemi".
La sicurezza deve essere accettata come requisito funzionale obbligatorio di qualsiasi progetto. Sappiamo tutti che integrarla fin dall'inizio nella progettazione è più economico, più facile e più sicuro che adattarla in un secondo momento. Eppure è sorprendente quanti progetti Agile abbiano l'"approvazione della sicurezza" come ultima attività dello sprint, il che inevitabilmente causa ritardi.
La conformità normativa di base è praticamente irrilevante nell'attuale panorama delle minacce. È invece necessario effettuare test con strumenti adeguati e, se del caso, con red team indipendenti. I CISO hanno bisogno di strumenti in grado di monitorare attentamente gli ambienti, gli errori e le configurazioni errate per mitigare efficacemente i rischi. L'azienda nel suo complesso deve rendersi conto che un prodotto non è completo finché non vengono soddisfatti tutti i requisiti di sicurezza.
La realtà è che, in qualità di CISO, siamo la coscienza dell'organizzazione. Affinché i progetti Agile abbiano successo, potrebbe essere necessario rallentare un po' il ritmo e porre alcune domande difficili. A volte è necessario mettere in discussione la fede dogmatica di molti CIO e dei loro team.
Va bene essere il cattivo. Dite no all'Agile quando esistono approcci migliori basati sul buon senso.
https://www.theregister.com/2021/12/16/move_fast_break_security_why/