SSI_416

98 AUTOMAZIONE OGGI 416 SOLUZIONI SOFTWARE PER L’INDUSTRIA vulnerabilità S SI l’utenza IT dovrebbe comprendere il software installato, le informazioni sull’hardware, le patch mancanti, la geolocaliz- zazione e 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 peri- metro 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 a 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 azienda, come definire- ste 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 ri- uscite solo a barcamenarvi con il Vulnerability Assessment? Se la risposta è TVM, dovreste espandere il modello verso altre direzioni e processi. A quale livello Come definireste allora il li- vello di maturità raggiunto dalla vostra azienda? Ad esempio, verso le pipe- line Sdlc e CI/CD: avete ac- quisito una maturità abbastanza solida per poter integrare la security orientandovi dove la superficie vulnera- bile ha origine. Molto probabilmente avete già implementato metodologie agili di sviluppo, mettendo in atto Scrumper migliorare l’efficienza operativa. È necessario però valutare la maturità e la sensibilità del pro- cesso 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 tool del Sdlc (Sy- stem 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’ap- plicazione delle patch, tenendo conto di scadenze e obso- lescenza, 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 er- rori nelle configurazioni rientrano tra le principali cause di perdita di dati nei programmi di adozione del cloud, come è dimostrato anche da pubblicazioni quali ‘The Treache- rous 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: server- less computing, piattaforme CaaS (container as a service) e orchestrazione federata per l’ottimizzazione delle istanze. Queste recenti evoluzioni dell’ambiente di computing richiedono capa- cità altamente qualificate di visibilità, raccolta dati e accu- ratezza nell’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 del flusso di lavoro alla base. Come ultimo, serve ottimizzare il processo di Asset Ma- nagement: spesso già operativo nelle aziende con gradi di efficienza differenti, ma da potenziare e rinnovare per co- struire 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 sin- cronizzazione 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 Business As Usual, SecOpS, De- vOps e altri ancora. In sintesi, è un duro e arduo percorso che qualcuno chiama Digital Transformation. Qualys - www.qualys.com Foto tratta da www.pixabay.com