Il dogma Agile continua a diffondersi. Secondo Vectra AI, è dovere di un manager della sicurezza imparziale respingerlo
A cura di Massimiliano Galvagna, Country Manager Italia di Vectra AI
“Agile” è ormai diventata una parola d’ordine nel mondo IT. Adottato dapprima con il proposito di migliorare la qualità del software e la velocità di consegna, negli ultimi vent’anni il principio è stato considerato la panacea di tutti i mali dell’Information Technology. La metodologia dà la priorità all’autonomia, alla velocità di consegna e all’etica del “move fast, fail fast“. Abbastanza per far trasalire qualsiasi CISO.
Agente di cambiamento o agente di sventura?
Il metodo agile ha i suoi vantaggi. Come approccio iterativo allo sviluppo del software, può aiutare i team ad accelerare il time-to-market e a rimuovere gli ostacoli. Può essere particolarmente efficace per le piccole aziende e i piccoli team. Ma non è molto scalabile e non è adatto ad ambienti eterogenei complessi. Certamente non trasformerà un team di delivery fallimentare in un gruppo di lavoro efficace.
Eppure la metodologia agile viene sempre più adottata come modello operativo per l’intero settore tecnologico, per guidare la trasformazione ovunque, dagli servizi di assistenza ai data center. I CIO sono incoraggiati da un business che non comprende le sfumature della metodologia stessa. Almeno la metà delle aziende ha impiegato negli ultimi tre anni le pratiche agile per la trasformazione. Ma è ancora appropriato continuare ad adottarle?
Basta dire “no”
“Puoi darmi un’eccezione di accettazione del rischio/sicurezza?”. È la classica richiesta che viene avanzata ai responsabili della sicurezza e che potrebbe essere tradotta più precisamente con un’altra domanda: “Puoi compromettere la sicurezza per aiutarmi a raggiungere i miei obiettivi di consegna agile?”. Una risposta appropriata da parte del CISO sarebbe: “Certo, purché siate pronti ad assumervi la piena responsabilità se qualcosa va storto”.
La sicurezza deve essere accettata come un requisito funzionale obbligatorio di qualsiasi progetto. È più economico, più facile e più sicuro integrarla sin dall’inizio piuttosto che dover aggiornare il progetto per tener conto anche di questa esigenza. Eppure è sorprendente vedere quanti progetti agile considerano la valutazione di sicurezza quale ultimo elemento dello sprint, il che porta inevitabilmente a ritardi.
La conformità alle norme di legge di base è in gran parte irrilevante nel panorama delle attuali minacce informatiche. I test dovrebbero, quindi, essere fatti con strumenti performanti e, se del caso, con team di esperti indipendenti. I CISO hanno bisogno di strumenti che possano monitorare da vicino gli ambienti, gli errori e le configurazioni errate per mitigare efficacemente il rischio. L’azienda, in generale, deve capire che un prodotto non è completo finché tutti i requisiti di sicurezza non sono soddisfatti.
La realtà è che i CISO rappresentano, in qualche modo, la coscienza del business. Perché i progetti agile abbiano successo, a volte bisogna rallentare un po’ le cose e fare domande difficili. A volte bisogna mettere in dubbio la fiducia di molti CIO e dei loro team.
Fare la parte del “cattivo” a volte va bene. E va bene anche dire di no alle metodologie agile quando esistono soluzioni migliori.
