Malgrado la difficoltà di installare un numero sempre più elevato di patch nel minor tempo possibile, la gestione di questa attività deve essere considerata come una parte fondamentale della governance IT di ogni azienda. Un possibile approccio a tale sfida, prevede l’utilizzo della metodologia Agile e il framework Agile Scrum.
La necessità è data dall’aumento delle minacce cybersecurity. Nel 2018, Clusit ha pubblicato un’analisi che evidenzia come nel mondo negli ultimi due anni si siano intensificati attacchi informatici che hanno portato a rilevanti perdite economiche, danni alla reputazione e diffusione di dati sensibili. Molte di queste violazioni derivano dallo sfruttamento di falle nel perimetro della sicurezza derivanti da bug non prontamente corretti.
Indice degli argomenti
La metodologia Agile
Il concetto Agile nasce nel 2000 quando i paradigmi di sviluppo software del tempo avevano evidenziato delle mancanze in termini di velocità e aderenza alle effettive necessità del cliente. La metodologia propone un nuovo approccio allo sviluppo software con l’obiettivo di consegnare al cliente frequenti rilasci di funzionalità autoconsistenti. Dal 2001, anno della pubblicazione del manifesto Agile ad oggi, sono emerse diverse metodologie Agile (Scrum, XP, Kanban) in grado di coprire un sempre più ampio spettro di attività.
L’adozione della metodologia, se correttamente declinata, può essere estesa anche nella gestione di progetti IT, compresa la distribuzione di patch di sicurezza ed aggiornamenti software. La combinazione della metodologia Agile Scrum e delle linee guida sul patch and vulnerability management definita dal NIST (National Institute of Standards and Technology) permette di ottimizzare tempo, risorse e di ridurre eventuali rischi operativi (come errata prioritizzazione, mancanza di piani di roll-back).
| Agile Scrum terms | Definizione | NIST SP 800-40 |
| Stories | Semplice descrizione ad alto livello di una funzionalità o componente di un prodotto | Patches |
| Grooming | Processo di stima del backlog esistente utilizzando sforzo, raffinando i criteri di accettazione per le storie, dividendo storie più grandi in storie di minore complessità | Patch Prioritization |
| Product Backlog | Liste ordinate di requisiti relative al prodotto | Remediation Database |
| Spring Planning Meeting | Meeting di otto ore (per sprint di un mese) tentuto all’inizio di ogni sprint per pianificare il lavoro da svolgere durante sprint e preparare lo sprint backlog | Selection of next patches to deploy |
| Spring Backlog | Lista del lavoro che il team effettuarà durante lo sprint successivo, selezionando una quantità di storie/funzionalità dal product backlog | Patch Activity Definition and Sign-up |
| Sprint | Unità di base dello sviluppo dalla durata di 1-4 settimane | Patch Preparation and Testing |
| Sprint Review | Meeting per verificare la conformità del prodotto finito | Remediation Verification/Audit |
| Sprint Retrospective | Meeting per creare un piano di miglioramento da attuare durante lo Sprint successivo | Patch Lessons Learned |
Tabella 1: Associazione di termini derivanti dal metodo Agile e mappati nella linea guida NIST
Il framework Agile Scrum
Il framework Agile Scrum è caratterizzato da tre componenti principali:
- Ruoli tra cui scrum team, scrum master e product owner;
- Artefatti tra cui backlog, stories e burn-down;
- Eventi tra cui sprint planning, daily stand-up meeting e sprint retrospective.
I principali ruoli sono descritti di seguito, al fine di evidenziare le similitudini tra il framework Scrum e le linee guida definite dal NIST
- Scrum Team: è un team dedicato composto da 7-10 membri provenienti da funzioni aziendali diverse (es. Security, IT Operations, QA) che lavorano giornalmente a stretto contatto per garantirsi un allineamento continuo e l’identificazione di eventuali nuovi requisiti tecnici e di business. Il NIST identifica questa squadra come gruppo di patch e vulnerabilità (Patch and Vulnerability Group – PVG). Anche in questo caso si tratta di team cross-funzionale: i rappresentanti di Security confermano l’efficacia delle patch, i rappresentanti del gruppo IT Operations definiscono ed implementano i gruppi di patch, mentre i rappresentanti di QA confermano che le patch non dannegino le applicazioni sui sistemi;
- Scrum Master: coordina le attività e la comunicazione tra i membri del team, assicura il rispetto delle tempistiche e l’aderenza dei rilasci sulla base degli effettivi requisiti. Come lo scrum master collabora con il product owner, anche il patch service owner collabora con il responsabile della sicurezza per definire un accordo (Definition of Done – DoD) che viene utilizzato per valutare se un requisito sia stato completato correttamente. Ciò è fondamentale in quanto esenzioni, limitazioni delle risorse e tempi possono influenzare il risultato. È importante sottolineare che il patch service owner assicura che il processo di patching sia seguito e compreso ma non ha autorità formale sul Patch and Vulnerability Group come un tradizionale responsabile di dipartimento.
- Product Owner: è responsabile della gestione delle relazioni con gli stakeholder e definisce funzionalità, priorità e tempistiche. Allo stesso modo, il security manager monitora le notifiche delle patch dai fornitori di software, esegue la valutazione preliminare del rischio, conduce la discussione con le parti interessate, identifica le dipendenze e misura i progressi durante le diverse fasi di rilascio. Al termine di ogni fase di lavoro (sprint), il security manager conduce un’analisi per confermare che la patch sia stata adeguatamente testata.
Analizziamo ora gli artefatti:
- Una storia è una semplice descrizione ad alto livello di una funzionalità o componente di un prodotto e viene utilizzata per descrivere i requisiti, incluso dipendenze e stima dello sforzo richiesto. Analogamente, per il NIST ogni storia rappresenta una correzione di vulnerabilità/patch e contiene i requisiti necessari per il patching definiti dal team di sicurezza (es. valutazione del rischio, istruzione del fornitore, posizione del codice patch, priorità, esenzioni e dipendenze);
- Il product backlog contiene l’elenco delle storie e il relativo sforzo richiesto durante la fase di sviluppo. Il NIST lo definisce come remediation database contenente una valutazione dei rischi, i requisiti di alto livello per l’applicazione delle patch e le informazioni su come rimuovere le vulnerabilità definite dal security manager. Il product backlog e il remediation database sono dinamici in quanto nuove esigenze tecniche (es. nuove patch rilasciate) o di business (es. nuove funzionalità richieste) sono identificate con nuove storie. Per questo motivo le storie vengono esaminate periodicamente dal security manager per garantire che quelle più importanti siano prioritizzate di conseguenza;
- il grafico di burndown viene aggiornato quotidianamente con i progressi nel lavoro svolto dal team durante lo sprint.
I principali eventi, noti anche come cerimonie Agile, includono:
- selezione della storia: Il team seleziona dal product backlog una o più storie che possono essere completate entro lo sprint successivo. Durante lo sprint non è possibile introdurre nuove storie e i requisiti di funzionalità non dovrebbero cambiare. Nel NIST in questa fase si selezionano le patch da testare e installare.
- pianificazione dello sprint (sprint planning): Il product owner, lo scrum master e il team si incontrano per pianificare il lavoro durante lo sprint: le storie sono suddividere in piccole attività (breakout) da completare all’interno dello sprint. Queste attività sono pubblicate all’interno dello sprint backlog. Il team decide le azioni, le dipendenze e il tempo necessario per completare ogni attività. Nel NIST il team suddivide la gestione del bug in piccole attività e stima lo sforzo (in unità di giorni) di ogni singola attività.
- incontri quotidiani (daily standup meeting): lo scrum master e il team si incontrano quotidianamente per allinearsi su quanto è stato completato, sulle attività giornaliere ed eventuali criticità. Queste riunioni si tengono a inizio giornata e durano 15-30 minuti. Per il NIST l’esecuzione dello sprint equivale alla preparazione e al test delle patch; dopo lo stand up, il team avvia le attività previste per la giornata come ad esempio la creazione di pacchetti di patch, la definizione di asset target, la verifica della compatibilità delle patch con i programmi applicativi, la scansione delle vulnerabilità, l’elaborazione delle esenzioni/accettazione di rischio.
- sprint review: al termine dello sprint viene eseguita una dimostrazione in cui il product owner e gli stakeholder osservano e approvano le nuove funzionalità. Questa revisione avviene anche per il patching ed è chiamato patch remediation verification. La Definizione di Fatto è fondamentale per i requisiti di non funzionalità in quanto le “nuove funzionalità” delle patch non sono facilmente osservabili: il DoD fornisce l’unico mezzo per qualificare che il lavoro è stato completo come stabilito.
- Sprint retrospective: una riunione retrospettiva tra il team e le parti interessate per discutere di ciò che ha funzionato e delle opportunità di miglioramento. Anche nel caso del NIST, le opportunità di miglioramento vengono identificate nel patching lessons learned.
L’integrazione delle patch
Il pacchetto di patch è quindi pronto per il rilascio. Il PVG non implementa la patch, la prepara solamente in quanto, idealmente, l’organizzazione dispone già di una organizzazione per la distribuzione del software o una automazione per gestione dei rilasci.
I pacchetti di patch vengono quindi integrati con le altre attività di gestione del ciclo di vita del software facilitando anche l’adozione di metodologie DevOps. In sintesi, combinando le metodologie NIST e Agile, le organizzazioni possono massimizzare la loro capacità di adattarsi ai cambiamenti in ambito Operations- Security dove ogni mese vengono rilasciate nuove patch che determinano cambiamenti di priorità e requisiti.
