La correzione delle vulnerabilità rappresenta una delle discipline più impegnative dal punto di vista operativo nel campo della sicurezza informatica. Tuttavia, l'individuazione delle vulnerabilità raramente rappresenta il punto debole di tali programmi. Per molte organizzazioni, la vera sfida consiste nell’attuare le misure correttive in modo coerente e nel verificare l’efficacia delle soluzioni entro tempi ristretti.
Il presente articolo si concentra sulle dinamiche di esecuzione: trasformare un elenco di priorità in un piano di implementazione, decidere quando procedere alla risoluzione definitiva piuttosto che alla mitigazione, gestire l’automazione in modo sicuro, coordinare le attività tra i vari team e verificare che le correzioni abbiano eliminato la vulnerabilità. Comprendere il processo di risoluzione delle vulnerabilità nella sua interezza, e non solo nelle singole fasi, è ciò che distingue i programmi in grado di ridurre il rischio in modo costante da quelli che generano attività senza risultati misurabili.
In cosa consiste effettivamente la correzione delle vulnerabilità
I tipi di vulnerabilità riscontrati dal Suo programma, tra cui difetti del software, configurazioni errate e altre vulnerabilità di sicurezza, richiedono ciascuno approcci correttivi diversi. La correzione delle vulnerabilità è il processo volto a eliminare tali punti deboli di sicurezza presenti nei sistemi, nelle applicazioni o nelle configurazioni, una volta che questi sono stati identificati e classificati in ordine di priorità.
Esso rappresenta le fasi di esecuzione e convalida del ciclo di vita della gestione delle vulnerabilità , in cui i risultati individuati e classificati in base alla priorità vengono tradotti in azioni correttive e in esiti convalidati. Nel panorama più ampio della sicurezza informatica, la correzione delle vulnerabilità costituisce il ponte fondamentale tra la consapevolezza di ciò che è esposto e la riduzione del rischio.
Sebbene in teoria sia semplice, è proprio qui che la maggior parte dei programmi inizia a perdere terreno.
Il processo di bonifica spesso fallisce quando i flussi di lavoro relativi all’identificazione, alla definizione delle priorità e all’esecuzione non sono integrati. Il Suo scanner rileva un errore critico CVE. Il risultato viene visualizzato in una dashboard di sicurezza, mentre il reparto IT opera da un sistema di ticket separato, senza che vi sia un passaggio di consegne coerente tra i due. I giorni passano. La vulnerabilità rimane aperta e tale ritardo allunga direttamente il lasso di tempo a disposizione degli aggressori per sfruttarla.
Il passaggio di consegne tra IT e SecOps costituisce un altro punto di vulnerabilità comune. I team di sicurezza individuano i casi e ne stabiliscono l'ordine di priorità. Il reparto operativo IT è responsabile dei sistemi e provvede alle correzioni. In assenza di una visione condivisa sia dello stato dell’implementazione che dei risultati della convalida, i ticket vengono chiusi prematuramente da entrambe le parti. In assenza di coordinamento, anche le vulnerabilità per le quali sono state stabilite chiaramente le priorità possono rimanere esposte.
C'è poi il divario di convalida. Viene distribuita una patch. La vendita dei biglietti termina. Ma la vulnerabilità è effettivamente scomparsa dall’ endpoint o è ancora accessibile o sfruttabile attraverso un altro percorso? Molti programmi contrassegnano le voci come risolte dopo che è stata intrapresa un’azione, e non dopo aver verificato che la correzione abbia prodotto il risultato previsto.
Una volta stabilita la priorità delle vulnerabilità, il problema non consiste più nel decidere quali siano quelle rilevanti, bensì nell’applicare le correzioni in modo affidabile e su larga scala.
Come trasformare un elenco di vulnerabilità ordinato per priorità in un piano di correzione
Avete a disposizione un elenco delle vulnerabilità classificato in base al punteggio. Il passo successivo consiste nel trasformare tale elenco in un’azione coordinata.
Decisioni relative al sequenziamento
I punteggi di priorità influenzano l'ordine di elaborazione, ma non lo determinano. Prima di procedere con l’analisi sequenziale, è inoltre opportuno filtrare i falsi positivi: i risultati dello scanner che non riflettono l’effettiva esposizione nel Suo ambiente ingrossano la Sua coda di attività e indirizzano in modo errato gli sforzi di risoluzione dei problemi. Un CVSS 9,8 su un server di test isolato ha una priorità inferiore nella Sua coda di distribuzione rispetto a un CVSS 7,5 su un controller di dominio.
La definizione delle priorità tiene conto della gravità, della criticità delle risorse, dell’esposizione (ad esempio, sistemi esposti a Internet rispetto a quelli interni), dei segnali di sfruttamento attivo e dei vincoli operativi quali le finestre di manutenzione e le dipendenze di sistema. Si tratta essenzialmente di una valutazione del rischio applicata a livello di vulnerabilità, che mette a confronto la probabilità di sfruttamento con il potenziale impatto aziendale di un attacco riuscito.
Le fonti di intelligence sulle minacce , quali il catalogo delle vulnerabilità note sfruttate (KEV) della CISA e i punteggi del sistema di valutazione delle previsioni sugli exploit (EPSS), aiutano a identificare quali vulnerabilità vengono attivamente sfruttate in ambiente reale. I risultati ottenuti dallo scanner dovrebbero essere incrociati con un database delle vulnerabilità, come il National Vulnerability Database (NVD), al fine di garantire che i metadati relativi all CVE , i punteggi di gravità e le linee guida per la risoluzione siano aggiornati e interpretati correttamente nel contesto. Le vulnerabilità critiche che si collocano all’intersezione tra “attivamente sfruttate” e “su una risorsa critica” devono essere trattate con la massima priorità.
Il catalogo KEV della CISA stabilisce le scadenze per l’adeguamento a carico delle agenzie federali; numerose criticità devono essere risolte entro termini prestabiliti, a seconda del rischio di sfruttamento.
La definizione delle priorità, di per sé, non garantisce l’efficienza nell’esecuzione. Per essere efficaci, i programmi di correzione devono mettere in relazione i risultati relativi alle vulnerabilità con le specifiche patch, le modifiche di configurazione o gli aggiornamenti necessari per porvi rimedio. In assenza di tale collegamento, i team spesso perdono tempo a tradurre i CVE in soluzioni concrete. Le piattaforme che collegano direttamente i dati relativi alle vulnerabilità alle azioni correttive, come ad esempio , che individua le patch mancanti associate a vulnerabilità attive, possono ridurre gli attriti tra i team di sicurezza e quelli IT e accelerare i tempi di risoluzione, trasformando i rischi classificati in base alla priorità in attività concrete all’interno dello stesso flusso di lavoro.
Una volta definite le decisioni relative alla sequenza, la pianificazione dell’esecuzione si concentra sull’attribuzione delle responsabilità e sull’assegnazione delle risorse.
Assegnazione delle risorse e dei diritti di proprietà
Prima dell’implementazione della prima patch, chiarite chi è responsabile dell’esecuzione per ciascun livello di priorità. Le vulnerabilità zero-day rappresentano il livello di priorità più elevato e richiedono in genere un flusso di lavoro accelerato con tempistiche ridotte. Gli elementi di livello critico richiedono spesso un’approvazione accelerata da parte dell’ , , nonché risorse dedicate. Gli interventi di entità media potrebbero essere raggruppati nelle finestre di manutenzione settimanali.
Ogni voce presente nella Sua coda genera o viene associata, di norma, a un ticket ITSM in cui sono già indicati l’ambito, le risorse interessate, la scadenza e i requisiti di approvazione. Tale ticket diventa il principale punto di coordinamento tra la sicurezza e le operazioni IT. Per i problemi di elevata gravità, funge inoltre da registro delle comunicazioni per le parti interessate che necessitano di informazioni sullo stato di avanzamento delle azioni correttive e sulle tempistiche.
Esempio di flusso di lavoro: Un CVSS 9,8 CVE figura nell’elenco KEV della CISA all’indirizzo 09 . La valutazione della priorità lo colloca nella categoria “critica”. Viene generato automaticamente un ticket ITSM contenente l'elenco delle risorse interessate. L'anello 1 viene distribuito su 50 endpoint pilota. Una nuova scansione di convalida viene eseguita con una cadenza prestabilita, che varia spesso da alcune ore a un giorno, a seconda delle attrezzature e della portata. Ring 2 viene implementato in ambiente di produzione. Per la chiusura è necessaria una prova di revisione che confermi la correzione.
Una volta definito il piano di implementazione, la decisione successiva consiste nello stabilire quale tipo di risposta sia più adeguato per ciascuna vulnerabilità.
Rimedio, mitigazione o deroga
Non tutte le vulnerabilità ricevono la stessa risposta. La decisione dipende dalla disponibilità delle soluzioni, dai vincoli operativi e dalla tolleranza al rischio.
| Tipo di risposta | What it does | Quando utilizzarlo |
|---|---|---|
| Remediation | Elimina la vulnerabilità alla radice | È disponibile una patch del fornitore che può essere implementata nel rispetto del Suo SLA |
| Mitigazione | Riduce la vulnerabilità agli attacchi senza eliminare la causa principale | Non è ancora disponibile alcuna patch, oppure l’implementazione richiede ulteriori test |
| Eccezione | Accetta formalmente il rischio senza porvi rimedio né mitigarne gli effetti | È prevista la messa fuori servizio dell'impianto, oppure i controlli di compensazione riducono il rischio a livelli accettabili |
La scelta del tipo di risposta adeguato è proprio il punto in cui i programmi spesso falliscono. Si eviti di ricorrere automaticamente alle patch quando i vincoli operativi lo rendono impraticabile e si eviti di ricorrere automaticamente alle eccezioni quando è disponibile una soluzione.
La bonifica rappresenta la soluzione più completa, ove possibile, in quanto elimina la vulnerabilità alla fonte. Ciò comprende l’applicazione di patch, l’ottimizzazione delle configurazioni o la sostituzione di software non più supportato, ma richiede anche coordinamento, test e una rigorosa disciplina nell’implementazione per garantire il successo su larga scala.
e di mitigazione consente di guadagnare tempo. Riduce la vulnerabilità senza risolvere il problema di fondo, limitando così l’entità del danno mentre i team attendono una patch o il completamento della verifica. Ciò lo rende utile dal punto di vista operativo, ma rischioso se considerato come una soluzione a lungo termine.
Le eccezioni generano debito tecnico. Accettare una vulnerabilità trasferisce l’onere alla governance: documentarne la giustificazione, mantenere controlli compensativi e riesaminare la decisione nel corso del tempo. Senza tale disciplina, i rischi accettati tendono ad accumularsi inosservati.
Attuazione delle misure correttive su larga scala
L’implementazione di correzioni su migliaia di endpoint senza causare interruzioni del servizio richiede un approccio rigoroso, non solo strumenti adeguati.
Applicazione delle patch dei fornitori
Patch L'implementazione segue un modello graduale. Acquisite la patch, preparatela per la distribuzione e testatela su un ambiente non di produzione prima di procedere alla distribuzione su larga scala. Una gestione efficace delle patch garantisce che tale processo sia ripetibile e verificabile, e non si limiti a reagire ai singoli CVE man mano che vengono individuati.
Il gruppo pilota individua i problemi in una fase precoce. Se una patch compromette una dipendenza dell’applicazione, ne interrompe il funzionamento o ne causa un calo delle prestazioni, è necessario venirne a conoscenza su 50 endpoint, non su 5.000. I periodi di attesa tra uno squillo e l’altro consentono di osservare i segnali di stabilità prima di procedere.
Gli endpoint disconnessi o offline rappresentano una sfida specifica. Molte piattaforme consentono ai team di definire in anticipo le azioni correttive, ma la loro esecuzione dipende comunque dal fatto che l’ endpoint e si ricolleghi e riceva tali istruzioni. Fino al ripristino della connessione, gli endpoint esposti rimangono a rischio.
Configurazioni errate relative alla sicurezza
La correzione delle configurazioni va ben oltre la semplice “modifica delle impostazioni”. State rilevando uno scostamento rispetto al valore di riferimento, creando uno script o applicando la correzione tramite una politica, e verificando che la modifica sia rimasta in vigore dopo le successive applicazioni della politica.
Tra gli obiettivi più comuni figurano:
- Credenziali predefinite: Nomi utente e password preimpostati in fabbrica che gli hacker sanno di dover provare per primi
- Porte aperte non necessarie: Punti di accesso alla rete che ampliano la superficie di attacco
- Controlli di accesso eccessivamente permissivi: Impostazioni che concedono un accesso più ampio di quanto necessario agli utenti
Ciascuna di queste rappresenta un modello di vulnerabilità comune che gli autori degli attacchi ricercano e sfruttano attivamente, rendendo il rafforzamento delle configurazioni una delle attività di correzione più efficaci a disposizione della maggior parte dei team. Gli strumenti di gestione della configurazione applicano le modifiche su larga scala, ma è la verifica a confermare che tali modifiche siano state effettivamente implementate.
Aggiornamento o sostituzione di software giunti a fine ciclo di vita
Il software fuori ciclo di vita (EOL) non riceve più le patch di sicurezza dell’ . Per “rimedio” si intende l’aggiornamento a una versione supportata, la sostituzione del software o la sua completa disattivazione. Ciò vale sia per i componenti commerciali che per quelli open source. In molti ambienti sono presenti librerie open source giunte a fine vita (EOL) integrate nelle applicazioni, che è facile trascurare durante i normali cicli di applicazione delle patch.
La bonifica EOL è complessa dal punto di vista operativo. La mappatura delle dipendenze mostra cosa smette di funzionare quando si esegue l'aggiornamento. I test garantiscono che la nuova versione funzioni correttamente nel Suo ambiente. L'approvazione da parte dell'azienda conferma la finestra temporale prevista per la modifica della produzione. Nonostante la loro complessità, le vulnerabilità EOL costituiscono obiettivi di correzione ad alto impatto, poiché rappresentano un’esposizione persistente.
Attuazione di controlli compensativi
Quando non è possibile attuare immediatamente misure correttive dirette, i controlli compensativi riducono il rischio nel frattempo. Ciò è particolarmente importante per i sistemi che archiviano o trattano dati sensibili, nei quali un’esposizione non mitigata può comportare conseguenze normative e commerciali che vanno oltre il rischio tecnico. Misure di controllo quali la segmentazione della rete, le restrizioni di accesso e un monitoraggio potenziato contribuiscono a limitare la diffusione laterale, a ridurre la superficie di attacco e a migliorare il rilevamento in caso di sfruttamento delle vulnerabilità.
Sebbene i controlli compensativi siano spesso di natura temporanea, in alcuni casi possono rimanere in vigore a lungo termine e richiedono un monitoraggio continuo per mantenere la loro efficacia al variare delle condizioni ambientali. È importante monitorarle insieme alle eccezioni, esaminarle regolarmente e sostituirle con una soluzione definitiva non appena sarà disponibile una correzione.
Gestione delle azioni correttive automatizzate
L'automazione accelera l'esecuzione. Può inoltre diffondere configurazioni errate o errori nell’applicazione delle patch su migliaia di endpoint nel giro di pochi minuti. La risposta non sta nel ridurre l'automazione. Si tratta di un’automazione gestit e: velocità bilanciata da controlli in grado di individuare i problemi prima che raggiungano la scala di produzione.
Valutazione dell’affidabilità e idoneità alla distribuzione
Il sistema di valutazione dell’affidabilità fornisce un contesto basato sui dati per aiutare i team a valutare la sicurezza di una patch o di una modifica alla configurazione prima della sua implementazione. Anziché prendere decisioni in modo automatico, il sistema supporta il giudizio dell’operatore mettendo in evidenza segnali quali il successo delle implementazioni precedenti, i risultati in termini di stabilità e l’impatto sulle prestazioni.
Le modifiche con un livello di affidabilità più elevato potrebbero rappresentare le opzioni più adatte per un'implementazione su più ampia scala, mentre quelle con un livello di affidabilità inferiore richiedono in genere un’ulteriore convalida, una fase di test o un’approvazione esplicita in base alle politiche aziendali.
L'implementazione basata su anelli come strumento di gestione del rischio
Implementazione di Ring : l’azienda sta estendendo il lancio a gruppi di endpoint sempre più ampi. Uno schema tipico: canary (5–10 endpoint), pilot (50–200), broad (i restanti).
La durata della pausa tra uno squillo e l’altro è importante. State monitorando i tassi di fallimento delle patch, gli errori di compatibilità delle applicazioni e i segnali relativi alla stabilità di endpoint . Le soglie di errore per ciascun anello definiscono quando interrompere l'operazione o eseguire il rollback. Criteri di escalation chiari stabiliscono chi ha l'autorità di portare avanti o interrompere un'implementazione.
L'implementazione ad anello è il meccanismo che contribuisce a rendere l'automazione più sicura su scala aziendale.
Esecuzione basata su playbook
I playbook definiscono la logica di correzione automatizzata, specificando il tipo di correzione da applicare, l’ambito di applicazione e le modalità di distribuzione tra i gruppi di endpoint .
L'attuazione prevede spesso fasi di approvazione e implementazioni graduali, consentendo ai team di esaminare le modifiche e verificare i risultati prima di procedere a una diffusione su più ampia scala.
L’esecuzione del playbook può inoltre integrarsi con i flussi di lavoro esistenti, compresi i processi di gestione dei ticket e delle modifiche, in modo che le azioni correttive e le approvazioni siano in linea con le modalità operative già adottate dai team.
Il problema del coordinamento tra IT e SecOps
Sapere cosa risolvere e sapere come farlo non garantisce che il problema venga effettivamente risolto. Il problema si verifica solitamente nel passaggio di consegne tra il reparto sicurezza e quello delle operazioni IT.
Quando il passaggio di consegne fallisce
I team di sicurezza individuano le vulnerabilità e ne stabiliscono l'ordine di priorità. I team operativi IT sono responsabili dei sistemi e provvedono alle riparazioni. In assenza di una visione condivisa dello stato di avanzamento dell’implementazione, dei risultati della convalida e delle responsabilità dei titolari, gli interventi correttivi possono apparire completati prima che le correzioni siano effettivamente confermate, lasciando aperte le vulnerabilità e rendendo incomplete le prove di audit.
Tra i punti di errore specifici figurano:
- Il reparto Sicurezza chiude un ticket quando una correzione è "raccomandata": Il reparto IT non l'ha ancora implementata.
- Il reparto IT chiude un ticket quando una patch viene “implementata”: Il reparto Sicurezza non ha ancora verificato se la correzione abbia risolto la vulnerabilità.
- Nessuna coda condivisa: Security opera sulla base di uno scanner di vulnerabilità . Il reparto IT opera tramite un sistema di gestione dei ticket nell’ambito della gestione dei servizi IT (ITSM). Non esiste una traduzione automatica tra le due lingue.
- Disaccordo in merito allo SLA: Security prevede che le vulnerabilità CVE critiche vengano risolte entro 48 ore. Il reparto IT dispone di finestre di gestione del cambiamento che si svolgono settimanalmente.
È proprio nel passaggio di consegne tra IT e SecOps che molti programmi di correzione perdono terreno: non perché i team non abbiano le giuste intenzioni, ma perché i flussi di lavoro non sono integrati tra loro.
L'integrazione ITSM come livello di coordinamento
L'integrazione dei flussi di lavoro ITSM svolge un ruolo fondamentale nel colmare il divario di passaggio di consegne. È possibile configurare la segnalazione delle vulnerabilità in modo che generi o venga associata a ticket ITSM con campo di applicazione, priorità e scadenza già compilati. Lo stato di implementazione viene trasmesso dall’IT al team di sicurezza.
La visibilità condivisa non è facoltativa per i programmi consolidati. Entrambe le squadre possono visualizzare in tempo reale lo stato di risoluzione di una vulnerabilità. I flussi di lavoro relativi alle approvazioni coinvolgono entrambi i team: chi approva prima della distribuzione e chi conferma dopo.
Modelli di proprietà condivisa
I programmi ad alto rendimento definiscono in modo esplicito le responsabilità. Uno SLA condiviso in materia di risoluzione dei problemi, concordato tra i responsabili SecOps e IT, definisce le aspettative. Le procedure di escalation consentono di gestire il mancato rispetto delle scadenze. Un'unica fonte di verità tiene traccia dello stato delle azioni correttive.
Le metriche rivelano dove si trovano i colli di bottiglia. Il tempo medio di risoluzione (MTTR) monitorato per fase (dalla scoperta alla creazione del ticket, dalla creazione del ticket alla distribuzione e dalla distribuzione alla convalida) consente di individuare se i ritardi derivino dall’identificazione o dall’esecuzione.
Verifica dell'efficacia della misura correttiva
L'applicazione di una patch non implica necessariamente che la vulnerabilità sia stata risolta. La convalida consente di verificare se l’esposizione sia stata effettivamente ridotta o eliminata, e non solo se sia stata affrontata nell’ambito del processo.
Molti programmi risolvono le vulnerabilità dopo aver intrapreso un'azione, non dopo aver verificato che la correzione abbia funzionato. Tale distinzione genera una falsa sicurezza riguardo al livello di sicurezza e comporta lacune nelle prove di audit.
La convalida richiede in genere l'esecuzione di una scansione delle vulnerabilità sugli endpoint interessati oppure la verifica dello stato endpoint dopo l'implementazione della correzione. Per l'applicazione della patch, si prega di verificare che l' CVE o non risulti più nelle scansioni e che la vulnerabilità non sia più presente né accessibile. Per quanto riguarda le modifiche alla configurazione, si prega di verificare che l'impostazione sia stata mantenuta e non sia stata sovrascritta da una successiva applicazione della politica.
Negli ambienti distribuiti, si raccomanda di effettuare la verifica su tutte le risorse interessate, e non solo su un campione, al fine di garantire che la correzione sia completa. In altri contesti, la convalida richiede inoltre di verificare che l’azione correttiva abbia risolto direttamente la vulnerabilità originaria, e non solo che sia stata apportata una modifica.
La distinzione è importante: "azione intrapresa" indica il completamento del processo. "Risk actually reduced" è il risultato che conta ai fini della conformità, delle prove di audit e del livello complessivo di sicurezza.
Una volta completata la validazione, la domanda finale è: come valutare se il vostro programma sta funzionando?
Valutazione dell’efficacia dei programmi di bonifica
Gli indicatori vi consentono di verificare se l'attuazione delle misure correttive sta dando i risultati sperati e, in caso contrario, di individuare dove intervenire.
Tempo medio necessario per la risoluzione del problema
L'MTTR misura il tempo medio trascorso dal rilevamento della vulnerabilità o dalla creazione del ticket (a seconda della definizione del programma) fino alla correzione convalidata, monitorato in base al livello di gravità.
Un aumento dell’MTTR relativo agli elementi di livello critico indica un’interruzione in qualche punto del flusso di lavoro. Il confronto tra i tempi che intercorrono tra l’individuazione del problema e l’apertura del ticket, tra l’apertura del ticket e la distribuzione e tra la distribuzione e la convalida consente di stabilire se il ritardo sia dovuto alla definizione delle priorità, all’esecuzione o alla convalida. Il tempo medio di riparazione (MTTR) monitorato a livello di programma non consente di individuare con precisione dove si verificano i ritardi. Suddividetelo per fase.
Tasso di copertura degli interventi di bonifica
Il tasso di copertura misura la percentuale di vulnerabilità individuate che sono state risolte entro il periodo di tempo da Lei definito.
Un MTTR elevato, unito a un alto tasso di copertura, indica una lentezza sistematica, ma non un fallimento del triage. Un basso tasso di copertura indica un’incapacità di stabilire le priorità o limiti nella capacità delle risorse. Monitorare il tasso di copertura per livello di attività. Il fatto che le risorse critiche ricevano una copertura inferiore rispetto agli endpoint standard indica un problema di definizione delle priorità.
Tasso di conformità allo SLA
Lo SLA verifica il rispetto delle scadenze definite per gli interventi correttivi in base al livello di gravità. Gli obiettivi di livello di servizio (SLO) più comuni sono i seguenti: critico entro 24–48 ore, elevato entro 7–14 giorni, medio entro 30 giorni.
I modelli di violazione degli SLA, suddivisi per livello di gravità, consentono di individuare con precisione quale fase del Suo flusso di lavoro esecutivo sia caratterizzata da risorse insufficienti o da una gestione inadeguata. La conformità allo SLA costituisce il parametro principale per gli audit di conformità. I quadri normativi e i mandati in materia di sicurezza interna spesso definiscono tempistiche specifiche per l’adozione di misure correttive in base al livello di gravità. Sono le prove documentate sia dell’implementazione che della convalida, e non solo la chiusura del ticket, a soddisfare tali requisiti.
L'MTTR vi indica quanto siete lenti. Il tasso di copertura indica il grado di completezza raggiunto. La conformità allo SLA vi indica in quali ambiti non state rispettando i vostri impegni. Qualsiasi programma di bonifica che operi senza questi tre elementi misura i risultati, non lo stato di salute dell’esecuzione. Tale divario si aggrava nel tempo, poiché vengono continuamente individuate nuove vulnerabilità.
In che modo “ Tanium ” contribuisce ad accelerare la risoluzione delle vulnerabilità
Le lacune operative descritte nel presente articolo, tra cui la frammentazione degli strumenti, i ritardi nei passaggi di consegne e una convalida limitata, derivano spesso da flussi di lavoro disgiunti e da una visibilità incompleta sugli endpoint.
La piattaforma IT autonoma Tanium consente di integrare l’identificazione delle vulnerabilità, le azioni correttive e i flussi di lavoro di convalida attraverso una visibilità in tempo reale endpoint e un controllo , riducendo la dipendenza da strumenti frammentati.
In pratica, ciò si manifesta attraverso funzionalità* quali:
- Visibilità in tempo reale dell’ endpoint , abbinata a valutazioni su richiesta delle vulnerabilità e delle configurazioni: Copre sistemi operativi, applicazioni e configurazioni, con il supporto di librerie di contenuti aggiornate regolarmente
- Avvisi in tempo reale relativi a vulnerabilità critiche ed emergenti: Forniti tramite Tanium Guardian con il supporto delle ricerche del Vulnerability Emergency Response Team (VERT) all’interno della console Tanium , che spesso includono azioni correttive raccomandate e linee guida
- Flussi di lavoro integrati per la correzione: Intervenite sulle vulnerabilità individuate e avviate i flussi di lavoro di correzione all’interno della stessa piattaforma, riducendo così la necessità di passare da uno strumento all’altro
- Punteggi di affidabilità: Utilizzate indicatori quali i tassi di successo dell’installazione, i risultati relativi alla stabilità e l’impatto sulle prestazioni per orientare le decisioni relative all’applicazione delle patch prima di procedere a una distribuzione su larga scala
- Implementazione progressiva basata su fasi: Si parte da un piccolo gruppo di " endpoint ", si verificano i risultati e si amplia l'implementazione man mano che ogni fase soddisfa i criteri di successo
- Guide pratiche per l’automazione low-code e no-code: Utilizza Tanium Automate per orchestrare endpoint e i flussi di lavoro di correzione sotto la supervisione degli operatori
- Funzionalità di convalida post-distribuzione: Consentono di verificare lo stato delle patch e di identificare i sistemi in cui le azioni correttive non sono state applicate come previsto
- Integrazione con , ServiceNow , e altri flussi di lavoro fondamentali: . Consente ai team IT e di sicurezza di accedere a dati coerenti relativi all’ endpoint nell’ambito dei processi esistenti
- Casi d’uso relativi alla valutazione della configurazione e alla gestione delle vulnerabilità: In linea con i principali standard quali PCI, HIPAA e SOX
- Visibilità sulle misure correttive: Evidenzia le vulnerabilità risolvibili tramite patch, le patch mancanti e lo stato di implementazione, per aiutare i team di sicurezza e operativi a monitorare lo stato di avanzamento delle misure correttive e a coordinarne l’esecuzione
*Le funzionalità e i risultati descritti si basano sulla documentazione relativa ai prodotti dell’ Tanium , su casi di studio dei clienti verificati e sull’utilizzo effettivo. I risultati effettivi possono variare a seconda dell'ambiente di implementazione, della configurazione e del grado di maturità organizzativa.
Con " Tanium", la convalida può essere integrata negli stessi flussi di lavoro utilizzati per l'implementazione delle azioni correttive. I team possono verificare lo stato di un endpoint , ad esempio lo stato di installazione delle patch o le modifiche alla configurazione, e rivalutare l’esposizione per determinare se le azioni correttive abbiano raggiunto il risultato previsto.
È proprio questo passaggio, dal monitoraggio delle attività di bonifica alla verifica della riduzione del rischio, a distinguere i programmi maturi da quelli reattivi.
La maggior parte degli strumenti di conformità vi indica cosa non va. Sono pochi quelli che vi indicano come procedere, e quasi nessuno vi permette di agire direttamente dalla stessa schermata. Visibilità delle attività di bonifica in Tanium Comply cambia questa situazione. Nel Tech Talks n. 121 di “ ”, Tanium Risk e Margie Sills, architetto di dominio per la conformità, illustrano in dettaglio come la funzionalità metta in relazione le vulnerabilità con patch applicabili, classificate in base all’impatto sulla riduzione del rischio, e come i team possano passare dall’individuazione alla risoluzione senza dover cambiare strumento o attendere il passaggio di consegne.
Domande frequenti sulla correzione delle vulnerabilità
L'esecuzione delle attività di bonifica solleva questioni pratiche che non trovano una chiara corrispondenza nella documentazione relativa al processo. Di seguito sono riportate le domande più frequenti che i team pongono spesso quando si tratta di tradurre i risultati delle analisi in azioni concrete.
Il mio scanner di vulnerabilità ha individuato centinaia di CVE. Da dove comincio?
Il punteggio CVSS da solo non è sufficiente per stabilire l'ordine di priorità. Un CVSS 7,5 presente sul Suo controller di dominio rappresenta un obiettivo di esecuzione con priorità maggiore rispetto a un CVSS 9,0 presente su un sistema di test isolato.
Filtri il Suo elenco in base a due criteri: lo stato di sfruttamento attivo (segnali CISA KEV ed EPSS) e la criticità delle risorse. Gli elementi che si trovano all’intersezione tra “attivamente sfruttati in ambiente reale” e “su una risorsa critica” costituiscono la vostra prima coda di esecuzione.
Perché il punteggio CVSS non è sufficiente per stabilire l’ordine di priorità delle correzioni da effettuare?
Il CVSS misura la gravità di base e quella contestuale in condizioni definite, ma non tiene conto dello sfruttamento attivo né del contesto aziendale. Il punteggio tiene conto della sfruttabilità e dell’impatto in condizioni ideali per l’autore dell’attacco, senza considerare se la vulnerabilità sia effettivamente sfruttata in ambiente reale né se il sistema interessato sia rilevante per la vostra attività.
Un CVSS 9,8 relativo a un software che non è in esecuzione nel Suo ambiente ha una priorità inferiore rispetto a un CVSS 6,5 relativo a un sistema che è oggetto di attacchi attivi ed è esposto a Internet. Una sequenza di esecuzione efficace combina il CVSS con l’EPSS (probabilità di sfruttamento) e la criticità delle risorse, non solo il punteggio di gravità.
In che modo la bonifica differisce dalla mitigazione?
La correzione affronta la vulnerabilità alla fonte tramite patch o modifiche alla configurazione, mentre la mitigazione riduce temporaneamente la possibilità di sfruttamento della vulnerabilità attraverso controlli quali la segmentazione della rete o le restrizioni di accesso, fino a quando non sia disponibile una soluzione definitiva.
Qual è un esempio di correzione di una vulnerabilità?
L'applicazione di una patch rilasciata dal fornitore per correggere una vulnerabilità nota ( CVE), il rafforzamento di una regola del firewall configurata in modo errato o l'aggiornamento di un software giunto a fine vita a una versione supportata sono tutte misure che rientrano nella categoria delle azioni correttive, poiché affrontano la vulnerabilità alla radice anziché limitarsi a ridurne l'esposizione.
La correzione delle vulnerabilità non consiste semplicemente nel risolvere tali vulnerabilità, ma nel verificare che il rischio sia stato effettivamente ridotto. I programmi che integrano la definizione delle priorità, l’esecuzione e la convalida in un flusso di lavoro continuo di tipo “ ” sono maggiormente in grado di ridurre i tempi di esposizione e di stare al passo con l’evoluzione delle minacce informatiche.
Fissate una demo per scoprire come ottimizzare e convalidare la correzione delle vulnerabilità in tutto il vostro ambiente con Tanium.
