Sviluppare software nel 2020 è molto diverso dal passato: le grandi software house hanno snellito i processi di sviluppo, scrollandosi di dosso le metodologie Waterfall, e i piccoli, consci della pericolosità delle loro lacune, hanno invece cominciato a strutturare processi, entrambi sulla scia della filosofia di sviluppo agile.
Questa filosofia premia rilasci veloci, pianificazioni passo passo e che si fonda sulla reiterazione e sull’interazione con chi il software lo utilizza.
Ora, il mondo dello sviluppo software sta cambiando nuovamente. È infatti in procinto di affrontare una nuova grande sfida che nel prossimo futuro entrerà sempre più nelle agende dei Product e Project Manager di questo settore.
Due importanti forze sono entrate in campo: in primo luogo il GDPR, che ha richiesto a tanti fornitori di servizio di prender coscienza e di attestarsi la responsabilità sulla sicurezza dei propri sistemi, ed in secondo luogo, ma altrettanto importante, il Perimetro Nazionale di Sicurezza Cibernetica, che ha dato il via ufficiale alle valutazioni di sicurezza sui prodotti software.
Da qui, la domanda: come conciliare questo modello di sviluppo così veloce e snello, con i requisiti di sicurezza, robustezza e privacy?
Indice degli argomenti
Il modello di sviluppo agile
Esistono varie tipologie di sviluppo agile, ognuna con le sue peculiarità, diversi ruoli e terminologie differenti. Tuttavia, almeno per gli scopi di questo articolo, possiamo sintetizzare alcuni concetti chiave trasversali alle metodologie agili che, appunto, si fondano su di un processo di sviluppo iterativo, su rilasci frequenti e su feedback continui.
Riassunti all’osso, al netto delle diverse nomenclature, i concetti chiave delle sono semplici ed eleganti, ovvero:
- le “User Stories”, descrizioni sulle aspettative del software dal punto di visto dell’utente finale;
- gli “Sprint”, blocchi di lavoro che si prefiggono di progettare, realizzare, testare e rilasciare certe funzionalità, casi d’uso o “user stories”;
- il Backlog di Prodotto, ovvero le funzionalità da aggiungere al software;
- il Backlog dello Sprint, contenente le funzionalità da realizzare nello specifico Sprint.
Le problematiche dello sviluppo agile
Eleganza, semplicità e rilasci frequenti hanno un risvolto della medaglia. I requisiti di sicurezza sono infatti difficili da inserire perché a guidare lo sviluppo sono le richieste del cliente, le nuove funzionalità o la risoluzione di malfunzionamenti.
I metodi di sviluppo tradizionali, a differenza di quelli agili, hanno una componente predittiva molto importante: le fasi di analisi e pianificazione iniziale, nelle quali è possibile pensare alla sicurezza delle architetture software e progettare un’implementazione ed un ciclo di manutenzione sicuro.
Purtroppo, queste sono proprio le fasi che le nuove metodologie sono andate a erodere.
Inoltre, la mancanza di una pianificazione dettagliata e, soprattutto, di chiarezza sul risultato finale, non aiuta di per sé a includere la sicurezza durante i vari Sprint. Tipicamente perché spesso la sicurezza è inquadrata come requisito “non-funzionale”. Ovvero, anche se non c’è, le cose funzionano ugualmente.
Sviluppo agile: il Secure SDLC
Prima di addentrarci nel come inserire la sicurezza all’interno delle metodologie di sviluppo agile è bene chiarire che cosa significa esattamente ciclo di sviluppo sicuro.
Qui, Microsoft ci viene in aiuto. Ha infatti reso disponibile alla comunità degli sviluppatori la sua interpretazione di “sviluppo sicuro”. Il Secure SDLC (Software Development Life-Cycle) di Microsoft getta infatti i quattro pilastri che devono esserci per poter parlare di ciclo di sviluppo sicuro, ovvero:
- Security by Design: considerare gli aspetti di sicurezza a livello architetturale, modellare le minacce, eliminare le vulnerabilità conosciute e porre attenzione alle problematiche del software “legacy”, ovvero ereditato dal passato.
- Security by Default: utilizzare meno privilegi possibile, sfruttare i concetti della “Defense in Depth” per avere sovrapposizioni nei controlli di sicurezza ed avere una politica conservativa sulle configurazioni di default.
- Deployment Security: ovvero mettere in produzione il software in sicurezza, gestire il rilascio e la distribuzione delle patch di sicurezza.
- Communication: prevedere punti di contatto per la gestione e la comunicazione degli aggiornamenti di sicurezza, rispondendo ai propri utenti e clienti riguardo alle vulnerabilità od ai cambiamenti nella sicurezza del software.
Questi principi, una volta calati nel ciclo di sviluppo software, danno inevitabilmente vita ad una serie di attività come il risk assessment, il threat modeling, l’analisi statica del codice (e.g. strumenti SAST, Static Application Security Testing), l’analisi dinamica (DAST, Dynamic Application Security Testing), le politiche di sicurezza e la preparazione di piani di Incident Response. Attività che vanno poi messe in pratica nei giusti tempi ed in modo efficace.
Le varie fasi dello sviluppo agile secondo il Secure SDLC di Microsoft (fonte).
Come e quando applicare il Secure SDLC nello sviluppo agile
L’applicazione dei principi dello sviluppo sicuro del software è agevolata nei cicli di sviluppo tradizionali, dove l’introduzione delle attività di sicurezza risulta intuitiva, all’apparenza più semplice, ma non per questo priva di sfide come la modifica dei processi, la gestione del cambiamento od il reperimento delle competenze necessarie.
Tuttavia, nel mondo agile ci si trova subito di fronte ad un dilemma: quando mi occupo della sicurezza se tutto è spezzettato e reiterato?
In linea di massima, esistono due principali approcci all’inserimento del Secure SDLC in questa famiglia di metodologie: il primo concentra la sicurezza in uno Sprint, rendendo più facile l’interazione e la comunicazione con il committente, ed il secondo più pervasivo, dove la sicurezza è iniettata all’interno di ogni Sprint.
Il Security Sprint
Con un Security Sprint dedicato è possibile concentrare ed affrontare appositamente le questioni di sicurezza con tempo e risorse adeguate.
Predisporre uno Sprint dedicato aiuta inoltre a creare più consapevolezza e più valore agli occhi del committente, permette di catturare i requisiti di sicurezza realmente necessari, di tradurli in aspettative (“user stories”) e concordare su cosa dovrà essere presente a fine Sprint.
Il Security Sprint è un ottima opportunità per confrontarsi ed approfondire i requisiti di sicurezza in termini di:
- gestione utenze e controllo accessi, ad esempio toccando quello che è il ciclo di vita delle utenze, gli accessi amministrativi e le politiche di controllo;
- attività di sicurezza, l’analisi delle minacce a livello architetturale, la gestione delle chiavi crittografiche ed eventuali assessment di terze parti;
- preparazione agli Incidenti, disponibilità dei servizi, business continuity e backup;
- conformità ai requisiti di sicurezza esterni (e.g. regolamentazioni, standard, contratti);
- logging applicativo di sicurezza, standardizzazione e log degli accessi ai dati personali;
- notifiche agli utenti e Privacy Policy;
- inventario dei componenti;
- gestione delle patch e dei cambiamenti;
- sicurezza dei contenuti e operativa, hardening di piattaforma e architettura di rete;
- capacità di rilevamento, integrazione con sistemi di protezione, validazione degli input e requisiti di monitoraggio.
Sicurezza in ogni Sprint
L’inserimento della sicurezza in ogni Sprint è senz’altro il modo più consistente di garantirne alti livelli. Tuttavia, è bene ricordare che inserire davvero le questioni di sicurezza dentro alle unità fondamentali del mondo agile significa vincolare il rilascio del software.
Per gestire al meglio questo nuovo vincolo diventa quindi importante fare leva sulle pratiche DevOps, creando pipeline automatizzate per velocizzare buona parte dei controlli quotidiani, che però non sollevano sviluppatori e Project Manager dall’occuparsi di sicurezza.
La formazione del personale in tema di codice sicuro è estremamente importante: contribuisce ad evitare le falle perché, nella pratica, automatizzare i controlli su tutte le code-base non è affatto scontato, e soprattutto scrivere subito codice sicuro fa risparmiare tempo a chi poi deve rimediare alle debolezze individuate dagli strumenti automatici, velocizzando quindi i rilasci del software.
Altrettanto importante è la modellazione delle minacce, che necessita di essere aggiornata e rivista ad ogni Sprint proprio per via della mutevole natura dei desideri, di funzionalità e aspettative del committente. Delegare questa parte ad un automatismo ne fa perdere il significato.
Per meglio chiarire il tutto, vi sono quindi una serie di attività di sicurezza estemporanee e trasversali, come la formazione, altre da eseguire una volta all’interno del progetto, come il risk assessment, il design di una architettura sicura o la definizione di un piano di Incident Response, altre da reiterare durante ogni Sprint, come il Threat Modelling e le pratiche di codice sicuro, ed altre ancora da tenere in “Bucket List”, ovvero da ripetere periodicamente durante il corso del progetto.
Esempio di Secure SDLC calato nella metodologia agile.
Conclusioni
Approcciare un ciclo di sviluppo sicuro sarà sempre più importante per l’industria del software, specie alla luce delle direzioni che il mercato digitale sta prendendo.
Il Perimetro Nazionale di Sicurezza Cibernetica e il GDPR stanno dando, infatti, nuovo slancio alla rilevanza della sicurezza nelle nuove infrastrutture software che digitalizzeranno il tessuto economico nazionale. Slancio che sarà sempre più valorizzato anche nel mercato B2B e B2C.
Per le aziende che operano in questo dinamico settore, stare al passo dei nuovi requisiti normativi e delle nuove sfide del mercato richiede accorgimenti che vanno oltre alla semplice installazione di strumenti. Approcciare lo sviluppo sicuro significa infatti mettere mano a processi, alle competenze delle persone e anche alle tecnologie in uso, ed è possibile farlo efficacemente ed efficientemente anche con le metodologie di sviluppo agile.
