Di Marco Rottigni, Chief Technical Security Officer EMEA di Qualys
Nel corso degli ultimi anni, l’attenzione delle aziende si è focalizzata sull’importanza di avere capacità appropriate di rilevamento, prevenzione e risposta alle minacce. Ciò è stato causato dall’aumento di attacchi informatici sempre più sofisticati e diversificati, che hanno provocato violazioni di diverso impatto economico in imprese di piccole e grandi dimensioni e di ogni settore.
La situazione sta migliorando, pur rivelando con impressionante chiarezza il basso livello di maturità delle aziende che – per competenze e risorse – sono ancora ampiamente impreparate nel saper rispondere tempestivamente ad ogni nuovo attacco informatico.
Mentre alcuni stanno combattendo con l’illusione di poter prevenire o addirittura evitare qualunque tipo di attacco, i CISO più lungimiranti affinano le competenze in tema di resilienza. L’attenzione si sposta quindi dalla prevenzione delle intrusioni alla riduzione della superficie vulnerabile, potenziando capacità quali visibilità dell’intero ambiente digitale e accuratezza nel rilevamento su larga scala. Più piccola è la superficie vulnerabile, più efficace è la rilevazione, minore sarà la quantità degli eventi significativi su cui indagare e l’impatto sulle risorse qualificate, specializzate e costose disponibili. Per quanto banale possa sembrare, questo concetto non è ancorfa diffuso.
Troppe aziende continuano a considerare il Vulnerability Assessment come un processo ciclico, da attuare una volta al mese per verificare il numero di vulnerabilità da trasmettere ai responsabili delle applicazioni per la remediation che, spesso, viene guidata da questi stessi report. Con un processo di rimedio prioritizzato in base ai perimetri su cui si trovano le risorse, agli indicatori CVSS (Common Vulnerability Scoring System), all’obiettiva gravità della vulnerabilità e ad altre metriche, il processo di Vulnerability Assessment è considerato, sostanzialmente, un’attività tattica.
Paragonato al mondo dello sviluppo, questo approccio assomiglia al metodo a cascata o ‘Waterfall’, una metodologia che nel mondo dello sviluppo sta mostrando segni di obsolescenza in favore di approcci più agili, come lo ‘Scrum’ (la cosiddetta mischia utilizzata nel rugby). La necessità di agilità ha spinto quindi i CISO a considerare di evolvere il Vulnerability Assessment verso il Vulnerability Management, un processo dove la vulnerabilità viene gestita e monitorata nel tempo, con report utilizzati per individuare i difetti nei processi BAU (Business As Usual, i processi di gestione aziendale dell’IT).Cruscotti dinamici consentono di monitorare la superficie vulnerabile in tempo reale o quasi, con un contesto della vulnerabilità arricchito, così da permettere il potenziamento delle SecOps o la gestione delle patch con le corrette informazioni di prioritizzazione. Il processo di Vulnerability Management assume così un valore più operativo.
La medesima agilità sta guidando i CISO più saggi a fare un ulteriore passo: dal Vulnerability Management al Threat & Vulnerability Management. Questo processo abilita la creazione di flussi di informazione agili fra i diversi processi aziendali, dissolvendo le barriere che impediscono la fluidità dei processi. Si fonda su concetti quali orchestrazione trasparente tramite API (Application Programming Interface), immediatezza di interrogazione dell’ambiente digitale monitorato, resa operativa delle informazioni sulle minacce per creare livelli di astrazione, armonizzazione degli accessi ai dati dai vari stakeholder in base a punti di osservazione e nel modo più agevole.
Cosa si intende per Threat & Vulnerability Management
Orchestrazione trasparente significa fa leva su API rese disponibili da diverse tecnologie, per creare flussi sicuri di informazioni tra le piattaforme, migliorare l’efficienza e limitare gli errori utente. Per esempio: utilizzare i risultati di un’analisi della superficie vulnerabile e trasmetterli ad una app di Service Management, che fornisce informazioni e monitora il processo di rimedio. Una volta confermata la chiusura della vulnerabilità, l’applicazione attiva nuovamente la tecnologia di VA (Vulnerability Assessment) per verificare che la superficie vulnerabile sia realmente stata rimossa, anche attivando un cruscotto dinamico che tracci nel tempo l’efficacia del processo TVM, a vantaggio della consultazione semplificata da parte dell’esecutivo aziendale.
Con immediatezza di analisi si intende l’implementazione di ‘occhi’ (sensori) ovunque siano necessari all’interno dell’ambiente digitale. Questi occhi hanno il compito di raccogliere le informazioni e trasmetterle in un’unica posizione centralizzata dove vengono indicizzate, elaborate, aggregate e suddivise per essere utilizzate da diversi profili di utenza tramite un’interfaccia grafica agile oppure da piattaforme tecnologiche tramite API. Questo processo garantisce che per ogni interrogazione la risposta sia già pronta – grazie a data point indicizzati – ed accessibile in pochi secondi, per supportare al meglio decisioni a livello tattico, operativo e strategico.
Con “operazionalizzazione dell’intelligence sulle minacce informatiche” si intende rendere queste informazioni comprensibili, contestualizzate e consumabili, processando i dati di un feed e sovrapponendoli a dati dall’ambiente digitale, creando un livello di astrazione che risponde istantaneamente a domande complesse. Data una campagna di minacce, un esempio di questa astrazione è capire immediatamente quante risorse subirebbero l’impatto: tatticamente, grazie alla visibilità dell’elenco delle risorse e alla possibilità di ottenere maggiori dettagli su ognuna; operativamente, approfondendo ulteriormente le informazioni sulla minaccia per rafforzare la difesa e la resilienza; strategicamente, grazie alla rappresentazione olistica del rischio.
Armonizzare le esigenze delle parti interessate a consultare i dati da prospettive diverse significa sfruttare la rielaborazione dei dati raccolti in modo centralizzato per mostrare solo la parte di dati necessaria ai diversi profili di utenti in un formato ideale per il consumo. Ponendo il caso di un server: l’utenza IT dovrebbe comprendere il software installato, le informazioni sull’hardware, le patch mancanti, la geolocalizzazione ed altre informazioni simili. Il team di Security deve individuare gli indicatori di compromissione, verificare le possibilità di exploit delle vulnerabilità software e rilevare le anomalie. Il reparto Compliance vorrebbe capire se quella macchina è conforme al set di controlli definiti per il perimetro di cui fa parte il sistema.
Tutte queste funzionalità, se implementate correttamente, creano un insieme di flussi scorrevole, supportato da persone, processi e tecnologie che elevano il processo Threat & Vulnerability Management ad un livello strategico, mantenendo sia il vantaggio operativo del VM così come il valore tattico di un VA preciso e accurato.
Ora, pensando alla vostra organizzazione, come definireste il livello di maturità raggiunta nell’ottica sopra descritta? Può definirsi il vostro un processo di TVM? State ancora cercando di sviluppare il VM o riuscite solo a barcamenarvi con il Vulnerability Assessment? Se la risposta è TVM, dovreste espandere il modello verso altre direzioni e processi!
Ad esempio, verso le pipeline SDLC e CI/CD: avete acquisito una maturità abbastanza solida per poter integrare la security orientandovi dove la superficie vulnerabile ha origine. Molto probabilmente avete già implementato metodologie agili di sviluppo, mettendo in atto Scrum per migliorare l’efficienza operativa. È necessario però valutare la maturità e sensibilità del processo in tema di sicurezza: identificando il vostro Security Champion e collaborando con lui per guidare il processo. Pensate alla sicurezza come qualcosa che non rallenta il processo ma che, piuttosto, lo rende ancora più sicuro ed efficace. Una delle azioni che si potrebbero mettere in atto è abilitare i componenti basati su API nei tools del SDLC (System Development Life Cycle) come Jenkins o Bamboo, per attivare un testing dinamico ogni volta che il codice passa di stadio nella pipeline CI (Continuous Integration) da sviluppo a test a preproduzione e produzione.
Occorre poi potenziare la gestione delle patch: avete già una visione molto chiara di cosa significhi un contesto in tema TVM e la creazione dei diversi livelli di astrazione. Perché non espandere queste conoscenze per creare flussi di lavoro che ottimizzino l’operatività della remediation e aumentino efficacia ed efficienza, riducendo al minimo KPI come l’MTTR (Mean Time To Respond)? Pianificate l’applicazione delle patch, tenendo conto di scadenze e obsolescenza, mantenendo traccia della loro applicazione, dei risultati e dei KPI, monitorando il riavvio macchina dopo l’applicazione di ogni patch, che è una delle aree più confuse del processo.
Espandetevi poi verso gli ambienti cloud e i container: sviluppando ulteriormente il vostro TVM, per aumentare la visibilità laddove i perimetri si dissolvono, analizzando le relazioni tra le risorse istanziate negli ambienti multicloud per verificarne le errate configurazioni. Stranamente, gli errori nelle configurazioni rientrano tra le principali cause di perdita di dati nei programmi di adozione del cloud, come è dimostrato anche da pubblicazioni quali “The Treacherous Twelve” di Cloud Security Alliance. Inoltre, è bene affrontare le sfide che i programmi di containerizzazione impongono, che stanno radicalmente cambiando l’intero modo in cui concepiamo l’IT con concept estremi: serverless computing, piattaforme CaaS (container as a service) e orchestrazione federata per l’ottimizzazione delle istanze. Queste recenti evoluzioni dell’ambiente di computing richiedono capacità altamente qualificate di visibilità, raccolta dei dati ed accuratezza nella elaborazione; per poter affrontare anche esigenze organizzative più tradizionali come la Compliance.
Questa non è solo una sfida tecnologica, e dovrebbe portare il processo di selezione dei fornitori a privilegiare quelli che capiscono l’importanza il flusso di lavoro alla base.
Come ultimo, serve ottimizzare il processo di Asset Management: spesso già operativo nelle aziende con gradi di efficienza differenti ma da potenziare e rinnovare per costruire una ‘Single Source of Truth’ (SSOT) per tutte le risorse in un ambiente digitale in costante cambiamento. I nuovi criteri sono: discovery, normalizzazione, organizzazione e classificazione secondo tassonomia, in un ciclo che sia il più automatico e continuo possibile. Per proseguire con la sincronizzazione con sistemi CMDB, così da garantire coerenza con il processo ITAM a prescindere da chi abbia eseguito la discovery.
Nessun processo può più essere autodefinito e solamente tattico!
Una volta costruita la SSOT è bene che diventi il punto di riferimento per i processi BAU, SecOpS, DevOps ed altri ancora.
In sintesi, è un duro ed arduo percorso che qualcuno chiama “Digital Transformation”!
