di Stefano Locatelli, Technology Integration leader Alfa Group

Finalmente, dopo tanti anni ad aspettare (e sperare…) che qualcuno venisse in soccorso dei referenti di security, costretti a districarsi tra sollecitazioni e istanze di responsabili, direttori, fornitori, ingegnerie di prodotti, supporti tecnici e assistenze varie, ci siamo. Le aziende hanno iniziato a prendere coscienza della complessità del processo di gestione delle vulnerabilità e dei rischi, delle conseguenze e più in generale delle “beghe” che un incidente di sicurezza porta con sé.

Per questa ragione all’interno delle organizzazioni è emerso il bisogno di avere un sistema più strutturato e solido per la gestione delle vulnerabilità, che agisca a livello aziendale e non ricada sulle spalle dei soli responsabili di Security. Si necessita di visibilità e valutazioni continue che tengano conto delle normative di conformità, dei requisiti organizzativi e degli standard di settore, mantenendo il passo con il numero sempre crescente di nuove vulnerabilità.

Per rispondere a queste necessità è stato elaborato l’ormai “famoso” framework che definisce le linee guida e gli step che le aziende dovrebbero seguire per ottenere un processo di Vulnerability Management efficace:

 

Il processo ciclico appena descritto mostra in maniera chiara le azioni da svolgere nella gestione delle vulnerabilità, ma nel cercare di fornire delle linee guida standard, tende a scontrarsi con le difficoltà pratiche della sua implementazione all’interno dei singoli contesti aziendali, come:

• La visibilità su tutte le risorse IT non adeguata, spesso dovuta all’assenza di un repository centralizzato nel quale raccogliere e analizzare chiaramente i dati di tutti gli asset aziendali;
• Il livello di rischio delle vulnerabilità è difficile da comprendere, ed implica molte volte una errata classificazione delle stesse sulla base della priorità di intervento;
• Molti step del processo di Vulnerability Management sono svolti manualmente, aumentando i tempi di esecuzione, e le scansioni non sempre vengono pianificate con frequenza regolare;
• La remediation non è sempre tempestiva, sia per la difficoltà di individuarne uno specifico owner, che per la mancanza di un sistema integrato e continuo di revisioni.

A queste difficoltà si aggiunge la tendenza di vedere il ciclo di vita delle vulnerabilità come un processo con una frequenza ben definita, spesso in linea con quella che è la politica delineata per le scansioni Vulnerability Assessment pianificate. Invece, oggi le vulnerabilità non sono più solo quelle dei sistemi, delle infrastrutture e delle reti: ci sono quelle sulle applicazioni, i loro codici sorgente, le loro librerie, le infrastrutture in cloud, le infrastrutture OT, e ognuna di queste ha una sua propria frequenza di investigazione, a volte addirittura completamente dipendente da altri cicli o servizi di gestione (es. rilascio del software in Software Development Life Cycle).

L’esperienza coltivata negli anni, ci ha permesso di raccogliere e condividere informazioni utili con le diverse organizzazioni con le quali abbiamo lavorato. Il confrontarci con l’applicazione pratica del suddetto framework nelle singole realtà aziendali ci ha permesso di riportare alla luce questo “ciclo”, di raffinarlo, per fornire alle organizzazioni e ai nostri clienti un approccio di gestione delle vulnerabilità che affronti e superi le difficoltà pratiche e operative del framework “tradizionale”.

Dunque, quali sono le fasi di questo nuovo ciclo di gestione delle vulnerabilità?

1) Discovery o identificazione del perimetro

Nella prima fase del framework, vengono visionati gli asset dell’organizzazione (inclusi software, hardware, sistemi operativi e servizi) e definiti gli obiettivi degli assessment da eseguire: le regole e le configurazioni necessarie ad impostare le attività. In genere, questo passaggio viene indirizzato da specifiche funzionalità delle tecnologie per le scansioni di Vulnerability Assessment, che garantiscono una ricerca degli host attivi sulla rete dell’organizzazione del cliente.

Ad oggi, questo non è più sufficiente: la superficie di attacco di un’azienda non è più soltanto costituita dalla propria infrastruttura, ma anche da tutti i relativi servizi ed applicazioni “on premise” ed “in cloud”. Per fornire un corretto perimetro da cui partire per svolgere qualsiasi attività di Security Assessment, occorre adottare un approccio di continuous monitoring della superficie d’attacco (Attack Surface Management, ASM), insieme a quello ormai collaudato della gestione del ciclo di vita del software (Software Development Life Cycle, SDLC) e sue relative metodologie, come Agile e DevOps, che non adottano un approccio lineare, ma bensì sottolineano la natura iterativa dello sviluppo del software.

2) Assessment

Le vulnerabilità, una volta identificate, vengono valutate sulla base del loro livello di rischio e/o criticità. L’utilizzo di tecnologie all’avanguardia, ha sicuramente garantito che questa fase fosse la più evoluta. Negli anni la scansione delle vulnerabilità ha guadagnato una dignità importante ed una certa verticalizzazione sui singoli test di sicurezza: tools per Vulnerability Assessment infrastrutturali, Web Application scanner, tools per SAST, DAST etc. La necessità di tener traccia dei risultati di ognuno di questi strumenti presuppone che possano essere interrogati dall’esterno o che, viceversa, permettano l’invio delle informazioni ad un sistema terzo.

In questo contesto appare evidente come l’avere un unico repository centralizzato relativo a tutte le tipologie di vulnerabilità dell’azienda sia un requisito fondamentale per l’implementazione di un processo strutturato di Vulnerability Management.

2a) Context enrichment.

Parallelamente alla fase di assessment (detection delle vulnerabilità), diventa necessario poter fruire anche di ulteriori informazioni di governance. La possibilità di attingere dai directory aziendali, dall’Asset Management e da tutte quelle sorgenti delle aziende che concorrono a determinare i rischi e le minacce, gli attori, le responsabilità e le relazioni con gli asset oggetto di analisi di sicurezza è un’opportunità incredibile per permettere al “ciclo” di girare ad una buona velocità. Queste informazioni nel processo Vulnerability Managament sono importanti perché garantiscono:

• il coinvolgimento e la partecipazione alle fasi operative del processo, delle strutture o dei servizi interni di un’azienda
• la possibilità di rivalutare la severità di una vulnerabilità
• l’assegnazione automatica di Responsabilità, Ruoli e Permessi sul processo e sui dati
• l’individuazione degli asset più critici
• una guida per la definizione della prioritizzazione
• l’analisi delle vulnerabilità nel contesto dell’azienda

Affinché il processo non venga sospeso, interrotto o rallentato, le informazioni di governance devono essere costantemente aggiornate con procedure automatiche per garantire che ogni task sia sempre adeguatamente assegnato ai relativi stakeholders.

2b) Prioritizzazione.

È sempre in parallelo alla fase di assessment che trova spazio il concetto di Prioritizzazione: determinare quali sono le azioni da intraprendere per prime. Questo processo è legato fortemente alle informazioni di contesto (del cliente), agli asset aziendali e agli strumenti di assessment che mettono in relazione dettagli delle vulnerabilità con informazioni di Threat Intelligence proprie e/o di provider che le forniscono.

3) Analisi e Report

La terza fase è di analisi, categorizzazione e assegnazione delle vulnerabilità, raggruppate in base alle policy definite dall’organizzazione e, naturalmente, in base agli stakeholders stessi. Questo passaggio è fondamentale perché consente di razionalizzare le azioni e, in certi casi, gestire e chiudere diverse pratiche aperte con il minor numero di interventi possibile.

Tutto ciò è stato tradizionalmente gestito con azioni manuali e con comuni strumenti di comunicazione (e-mail, telefonate, messaggi). Per evitare che tali modalità possano generare “colli di bottiglia”, questa fase deve essere indirizzata con strumenti avanzati di tracciamento delle operazioni.

La parola chiave è automatizzare, rendere dinamico il processo e le azioni stesse. Queste ultime, pur se automatiche, necessitano una serie di attori interessati che ne determino la responsabilità di essere eseguite (R), le responsabilità del successo delle stesse (A), la possibilità di essere consultate (C) e la capacità di essere visibili a coloro che ne devono essere informati (I), in linea con la più comune matrice delle responsabilità (RACI). Solo in questo modo, oltre a garantire il coinvolgimento e la presa in carico, è possibile tracciare le operazioni e svolgere gli opportuni controlli in ambito auditing e compliance.

È rilevante sottolineare l’importanza della predisposizione di dashboard, reportistica executive e di dettaglio per definire correttamente le strategie da implementare e documentare ogni azione. Anche in questa fase notiamo quanto avere uno strumento unico per la raccolta di tutti i dati sia essenziale per ottimizzare il “movimento” del ciclo di gestione delle vulnerabilità.

4) Remediation

In questa fase viene finalizzata la strategia di sicurezza da implementare per porre rimedio alle vulnerabilità identificate. Per uno svolgimento fluido di questo step è importante che l’assegnazione e la conseguente presa in carico di quelle che definiamo “pratiche di remediation” (raggruppamento di vulnerabilità che devono essere sanate) sia automatizzata. La responsabilità del successo della remediation deve essere assegnata ad un unico stakeholder, che dovrà condividere le analisi delle vulnerabilità, le strategie di mitigazione e, soprattutto, impostare il Piano di rientro.

Il processo di remediation deve basarsi su parametri chiari, spesso definiti da chi governa l’intero ciclo di vita delle vulnerabilità. Sulla base delle informazioni raccolte dagli strumenti di analisi di sicurezza, di quelle prelevate dalle piattaforme di Asset Inventory o dalle policy normative e interne, si stabiliscono i tempi entro cui occorre aggiornare un sistema, modificare una configurazione, effettuare l’upgrade di un software o applicare una fix su un codice sorgente. Successivamente l’owner della pratica pianifica gli interventi necessari e la inoltra al team o al servizio, interno o esterno, che dovrà agire nei termini definiti, con un costante monitoraggio, per eseguire la mitigazione.

Dopo la predisposizione dei piani di remediation, il processo entra in una fase di attesa nella quale sono previsti controlli, scambi ed eventuali procedure di escalation per ottenere un’attività di bonifica delle vulnerabilità nei tempi definiti. Per questo diventa indispensabile che la visibilità di quanto pianificato sia trasversale e accessibile a tutti i responsabili dell’esecuzione che avranno il compito di richiedere la chiusura della pratica di remediation ottenuta la conferma del rientro delle vulnerabilità.

5) Verifica

Nell’ultima fase del “ciclo” viene fatta la valutazione complessiva della strategia di sicurezza attuata e la “richiesta di chiusura” (diversa dalla vera e propria chiusura dell’incident della pratica di remediation). Questa presuppone un nuovo controllo, utilizzando gli strumenti di assessment, per accertarsi che le misure applicate abbiano effettivamente ridotto o eliminato con successo le minacce prioritarie dall’infrastruttura, applicazione o, più in generale, asset del cliente. Solo una volta svolto questo controllo, il processo si chiude e ricomincia un nuovo giro dalla fase di discovery indirizzando questa volta anche l’analisi del trend delle vulnerabilità.

Key takeways di governance aziendale

La revisione del tradizionale framework per la gestione delle vulnerabilità appena descritta presuppone quindi un processo in cui possano essere selezionati gli strumenti, i prodotti e le tecnologie necessarie per un’ottimale analisi delle vulnerabilità, ma anche definiti aspetti di governance quali l’organizzazione e il monitoraggio delle informazioni, degli stakeholders e delle loro relative azioni. Più le interazioni tra queste componenti saranno agevoli più sarà consolidata la sicurezza della propria azienda.

Alfa Group supporta i team di sicurezza nella creazione di un sistema integrato per la gestione delle vulnerabilità, attraverso servizi a valore e una tecnologia proprietaria dinamica e all’avanguardia. La nostra piattaforma RHD VM consente di analizzare, implementare e configurare l’intero ciclo di governo delle vulnerabilità in maniera efficiente e strutturata, ma con la flessibilità necessaria per adeguarsi agilmente al contesto delle singole organizzazioni in termini di: scelta della tecnologia per le fasi di discovery e assessment, determinazione delle fonti di asset inventory, di anagrafiche o di informazioni di governo, definizione di regole di pianificazione e/o verifica finale delle remediation.

Scopri di più sulle soluzioni Alfa Group in ambito Vulnerability Management