La maggior parte dei programmi di gestione delle vulnerabilità si definisce “continuativa”. In realtà sono pochi quelli che lo sono. La differenza è fondamentale: un programma che effettua scansioni settimanali ma si definisce “continuativo” crea un falso senso di sicurezza, lasciando esposizioni non coperte tra un ciclo e l’altro, mentre la dirigenza presume che la copertura sia completa.
La gestione continua delle vulnerabilità, o CVM, è un processo continuo e automatizzato volto a individuare, analizzare, classificare in ordine di priorità e correggere le falle di sicurezza presenti nell’infrastruttura IT di un’organizzazione. A differenza dei cicli periodici di scansione e segnalazione, il CVM garantisce una visibilità in tempo reale sullo stato delle risorse e sul livello di vulnerabilità, riducendo il lasso di tempo a disposizione degli aggressori per sfruttare le falle appena rese note.
Il presente articolo fornisce un quadro diagnostico per valutare se il programma attualmente in uso soddisfi lo standard operativo implicito nel termine “continuo”, illustrando le condizioni specifiche, gli indicatori e le strutture di coordinamento che distinguono i programmi realmente continui da quelli semplicemente frequenti.
Cosa si intende effettivamente per “continuo” e perché la maggior parte dei programmi non soddisfa tale requisito
La maggior parte dei programmi che si definiscono “continui” funzionano comunque con cicli di scansione settimanali o mensili. Stabiliscono le priorità in blocco, creano i ticket manualmente e danno per scontato che la risoluzione del problema sia andata a buon fine senza verificarla. Nel frattempo, la superficie di attacco dell’ è in continua evoluzione: vengono attivati nuovi asset, le configurazioni subiscono variazioni e le vulnerabilità CVE recentemente rese note creano finestre di esposizione che i cicli di scansione settimanali non riescono a colmare.
I programmi periodici pianificano le scansioni, assegnano le priorità in batch e generano manualmente i ticket. I programmi continui garantiscono il monitoraggio in tempo reale dello stato dei sistemi, attivano la definizione delle priorità al variare delle condizioni e verificano l’efficacia delle misure correttive tramite controlli a ciclo chiuso.
Un programma realmente continuo soddisfa tutte le seguenti condizioni:
- Le nuove risorse vengono individuate e inventariate nel giro di poche ore, non di giorni
- Le vulnerabilità recentemente individuate vengono valutate rispetto all’inventario completo delle risorse nell’ambito di uno SLA definito
- Lo stato della bonifica viene verificato a livello di programma, non dato per scontato
La maggior parte dei programmi non soddisfa almeno una di queste caratteristiche, e il motivo risiede solitamente nella loro posizione all’interno dello spettro di maturità del monitoraggio.
Tre livelli di continuità del monitoraggio: periodico, ad alta frequenza e in tempo reale
Comprendere a che punto si colloca il vostro programma nello spettro del monitoraggio continuo delle vulnerabilità aiuta a chiarire quali siano i costi effettivi di tale "continuità" e quali lacune permangano.
Livello 1: Scansione periodica. Le scansioni pianificate vengono eseguite settimanalmente, mensilmente o trimestralmente. La latenza nel rilevamento delle vulnerabilità è misurata in giorni o settimane. Tra un ciclo e l’altro si riscontrano lacune nella copertura. Questo approccio funziona in contesti stabili e poco soggetti a cambiamenti, ma non rileva le vulnerabilità che emergono a metà ciclo.
Livello 2: Scansione ad alta frequenza. I cicli di scansione giornalieri o quasi giornalieri riducono la latenza di rilevamento a poche ore. La copertura migliora negli ambienti dinamici, ma le risorse effimere, quali i container e le istanze cloud a scalabilità automatica (compresi i carichi di lavoro in esecuzione su cluster Kubernetes che possono essere avviati e terminati nell’arco di un singolo intervallo di scansione), possono comunque esistere tra una finestra di scansione e l’altra e non essere rilevate.
Livello 3: Monitoraggio dello stato in tempo reale basato su agenti. Gli agenti persistenti segnalano continuamente lo stato e la configurazione delle risorse. La latenza di rilevamento si riduce a pochi minuti. Vengono coperti sia gli asset effimeri che quelli che si riconnettono in modalità offline. Il compromesso riguarda i costi di implementazione e gestione degli agenti.
| Livello | Latenza di rilevamento | Asset copertura | La soluzione più adatta |
|---|---|---|---|
| Periodico | Da giorni a settimane | Intervalli tra i cicli | Ambienti stabili e poco soggetti a cambiamenti |
| Ad alta frequenza | Orari | Manca la voce "attività effimere" | Un’infrastruttura dinamica ma prevedibile |
| In tempo reale | Verbale | Riguarda le risorse offline/effimere | Ambienti di grandi dimensioni, distribuiti o in rapida evoluzione |
La maggior parte dei programmi aziendali opera al Livello 1 o 2 e parte dal presupposto che siano “continui”. Tanium'L'architettura a agente singolo di s fornisce dati sullo stato in tempo reale, eliminando il ritardo intrinseco nelle scansioni programmate delle vulnerabilità . La questione non è quale livello sia il “migliore”. Si tratta di stabilire quale livello corrisponda al profilo di rischio e alla velocità di cambiamento del Suo ambiente.
Il livello di monitoraggio determina la rapidità con cui si individuano le vulnerabilità. Ciò che accadrà in seguito determinerà se trovarli sia importante.
I punti deboli dei programmi CVM aziendali: il divario di coordinamento tra IT e SecOps
L'individuazione senza misure correttive non è altro che una costosa opera di sensibilizzazione. Il principale problema di continuità nell’ambito del CVM aziendale non è di natura tecnologica. Si tratta di un problema di coordinamento che impedisce ai team di risolvere le vulnerabilità individuate con la rapidità richiesta dal programma. Tale mancanza di coordinamento comporta conseguenze concrete: le ricerche dimostrano costantemente che molte violazioni dei dati non sono riconducibili a vulnerabilità non individuate, bensì a vulnerabilità note rimaste senza patch poiché nessuno si era assunto la responsabilità del passaggio di consegne tra il reparto sicurezza e quello IT.
I team di sicurezza Detect vulnerabilità. La risoluzione dei problemi dipende dai team operativi IT, che presentano priorità, SLA e processi di controllo delle modifiche diversi. Il divario tra «l’abbiamo individuato» e «l’abbiamo risolto» è proprio il punto in cui si annida il rischio.
Errori nell'integrazione del sistema di biglietteria. Quando le segnalazioni relative alle vulnerabilità richiedono la creazione manuale di un ticket, sono frequenti i ritardi che si protraggono per diversi giorni. La gestione integrata dei ticket assume una forma diversa: i risultati generano automaticamente dei ticket corredati di livello di gravità, contesto dell’asset e indicazioni per la risoluzione. I passaggi di consegne manuali comportano attriti che si accumulano con l’aumentare del numero di risultati.
Disallineamento SLA. La sicurezza definisce la criticità in base al punteggio CVSS o al punteggio di rischio. Il reparto IT definisce le priorità in base alla disponibilità delle finestre operative e all’impatto sul business. In assenza di livelli SLA condivisi, le vulnerabilità critiche rimangono in coda mentre i team discutono sulla pianificazione.
Una struttura pratica dello SLA potrebbe presentarsi come segue:
- Livello 1 (critico, oggetto di attacchi attivi): SLA per la risoluzione entro 24 ore
- Livello 2 (alto, vulnerabilità sfruttabile): SLA di 7 giorni (raggiungibile su larga scala con l’applicazione automatizzata delle patch; da adeguare in base alla complessità dell’ambiente)
- Livello 3 (medio/basso): Risk- finestra di manutenzione approvata o programmata
Ambiguità in materia di proprietà. Quando nessuno si assume la responsabilità dell’esito della risoluzione del problema dall’inizio alla fine, le vulnerabilità rimangono in sospeso nelle code dei ticket. Un processo di risoluzione dei problemi chiaramente definito risponde a tre domande: Chi è il responsabile del ticket? A chi spetta la responsabilità della verifica? A chi spetta la responsabilità in caso di rinvio delle misure correttive?
Allora, che aspetto ha in realtà un programma veramente continuo? La sezione seguente suddivide il tutto in cinque condizioni verificabili.
Le cinque condizioni che un programma realmente continuo soddisfa
Consideri quanto segue come una lista di controllo, non come un ciclo di vita. Ogni condizione è soddisfatta oppure non è soddisfatta. Il credito parziale non riduce l’esposizione.
1. Inventario completo e in tempo reale delle risorse
Il programma gestisce un inventario dello stato attuale che tiene conto delle risorse effimere, remote e offline. Non un “ CMDB ” che resta indietro rispetto alla realtà di giorni o settimane.
Test: È in grado di confermare entro un’ora se una vulnerabilità critica CVE appena resa nota abbia un impatto su una qualsiasi risorsa del Suo ambiente? Se la risposta è «dovremmo prima eseguire una scansione», significa che c’è una lacuna nella continuità.
2. Rilevamento basato sugli eventi
Le nuove vulnerabilità attivano i flussi di lavoro di rilevamento immediatamente dopo la loro divulgazione, non alla successiva finestra di scansione. Ciò richiede un’integrazione attiva con i feed di intelligence sulle minacce dell’ e con gli avvisi di sicurezza dei fornitori, inclusi gli aggiornamenti KEV della CISA, le pubblicazioni dell’NVD e i bollettini specifici dei fornitori quali Microsoft Patch Tuesday e Linux , in modo che gli eventi di divulgazione avviano automaticamente la valutazione delle risorse anziché attendere una scansione programmata.
Test: Quando viene pubblicato un CVE critico, quanto tempo occorre affinché il Suo programma verifichi la conformità di ogni risorsa rispetto a tale ? L'orario è continuativo. I giorni sono frequenti. La settimana è un periodo.
3. Definizione delle priorità contestuale integrata nel flusso di lavoro
La definizione delle priorità si basa sulla criticità delle risorse, su indicatori di vulnerabilità quali EPSS e CISA KEV, nonché sulle informazioni relative alle minacce (comprese le minacce emergenti che potrebbero non presentare ancora punteggi CVSS elevati, ma che vengono attivamente sfruttate in ambiente reale). Il sistema di valutazione delle previsioni di sfruttamento delle vulnerabilità (EPSS) stima la probabilità che una vulnerabilità venga sfruttata in ambiente reale entro 30 giorni, fornendo un’indicazione prospettica che la sola gravità CVSS non è in grado di cogliere. Si tratta del sito dedicato alla gestione delle vulnerabilità basata sul rischio, che illustra la metodologia.
4. Correzione con verifica a ciclo chiuso
Ogni azione correttiva viene verificata a livello di programma. La vulnerabilità non viene contrassegnata come "risolta" finché un controllo successivo non confermi l'applicazione della correzione. L'articolo " " (Risoluzione automatizzata delle vulnerabilità) illustra i diversi approcci di implementazione.
5. Misurazione e rendicontazione continue
Il programma monitora i propri indicatori di prestazione e li comunica alle parti interessate con cadenza prestabilita. Non solo quando lo chiedono i revisori. Se non è in grado di rispondere alla domanda: «Qual è il nostro tempo medio necessario per risolvere le vulnerabilità critiche?», Senza generare un report personalizzato, il programma fornisce i dati su richiesta, anziché effettuare misurazioni in tempo reale.
Il mancato rispetto di una sola di queste condizioni comporta un rischio. Un programma che garantisce un rilevamento perfetto ma non prevede alcuna verifica si limita a segnalare l’attività, non i risultati.
Tra le cinque condizioni, la verifica è quella che la maggior parte dei team tralascia del tutto. Vediamo perché questo è importante.
Convalida: la fase del CVM che la maggior parte dei programmi tralascia
La maggior parte dei team contrassegna le vulnerabilità come "risolte" al momento della distribuzione di una patch, non quando si ha la conferma che la vulnerabilità è stata eliminata. Quel divario tra «abbiamo implementato la correzione» e «la correzione ha effettivamente funzionato» è fonte di falsa sicurezza.
Prima degli interventi di bonifica
Conferma prima dell'intervento di bonifica
Prima di assegnare una vulnerabilità da correggere, si assicuri che il risultato rilevato dallo scanner rappresenti un’esposizione reale e sfruttabile. Non si tratta né di un falso positivo né di un artefatto di configurazione. Questa fase individua inoltre le configurazioni errate che gli scanner segnalano come vulnerabilità: si tratta di problemi che potrebbero richiedere una modifica della configurazione anziché l’applicazione di una patch e che vengono indirizzati in modo errato quando si salta la fase di valutazione preliminare prima della correzione. Saltare questa fase comporta uno spreco di risorse IT e, nel tempo, mina la fiducia nel programma di virtualizzazione.
Una volta implementata la correzione
Verifica successiva alla bonifica
Dopo l’applicazione di una patch di sicurezza o di una modifica alla configurazione, si verifichi a livello di programmazione che la vulnerabilità sia stata effettivamente risolta. Una nuova scansione o una verifica dello stato tramite agente conferma che la vulnerabilità non è più presente sulla risorsa. "Il ticket è chiuso" non costituisce una verifica.
Per i beni di alto valore
Convalida avversaria
Per le risorse di alto valore o le fasi critiche del processo di bonifica, i test di penetrazione offrono un livello di validazione dal punto di vista dell’avversario che la verifica automatizzata non è in grado di eguagliare. Le nuove scansioni programmate confermano che una specifica vulnerabilità è stata risolta; un test mirato va oltre. I controlli automatici confermano che una pratica è stata chiusa. Non sono in grado di confermare che l'esposizione sia cessata.
Quando non è possibile procedere alla bonifica
Gestione delle eccezioni
Per le vulnerabilità che non possono essere risolte, come nel caso dei sistemi legacy o delle applicazioni critiche per l’azienda soggette a blocchi delle modifiche, si definisca una procedura formale di deroga. Si documentino l’accettazione del rischio, i controlli compensativi, la frequenza delle revisioni e le date di scadenza. Le eccezioni prive di data di scadenza si trasformano in un’esposizione permanente.
Un programma CVM che non sia in grado di dimostrare l’efficacia delle misure correttive si limita a misurare il carico di lavoro, non la sicurezza.
La verifica consente di stabilire se le singole correzioni abbiano funzionato. Gli indicatori consentono di stabilire se il programma stesso sta funzionando. Ecco come distinguerli.
Come valutare l’efficacia del Suo programma CVM
Le metriche rappresentano l’unico modo per distinguere un programma che sia realmente continuo da uno che sia semplicemente frequente. Monitorate i seguenti aspetti, rendetene conto regolarmente e utilizzateli per promuovere il miglioramento. Nel loro insieme, questi indicatori forniscono alla dirigenza una visione quantificabile dello stato di sicurezza dell’organizzazione: non solo un’istantanea dei ticket aperti, ma una linea di tendenza che mostra se il programma stia effettivamente riducendo il rischio informatico nel corso del tempo.
| Sistema metrico decimale | Cosa misura | Benchmark in buona salute |
|---|---|---|
| Percentuale di copertura della scansione | Percentuale delle attività note sottoposte a monitoraggio attivo | Si avvicina al 100%, con eccezioni documentate |
| Ore trascorse tra la pubblicazione su * CVE * e la conferma dell’impatto | Ore per le vulnerabilità CVE critiche, non giorni | |
| Tempo medio di risoluzione (MTTR) | Tempo trascorso dal rilevamento alla chiusura verificata, in base alla gravità | Nell’ambito dei livelli SLA definiti |
| Tasso di falsi positivi | Percentuale di risultati non utilizzabili | In calo nel corso del tempo |
| Tasso di eccezioni | Percentuale di anomalie per cui il rischio è stato accettato rispetto a quelle corrette | Stabile o in calo, tutto documentato |
| Tasso di convalida della bonifica | Percentuale dei casi "risolti" verificati a livello di programma | Si avvicina al 100% per i livelli critico/alto |
L’invecchiamento delle vulnerabilità costituisce una settima metrica facoltativa: per quanto tempo le vulnerabilità rimangono aperte nell’ambiente nel corso del tempo? Una distribuzione equilibrata tende a privilegiare una rapida chiusura, con un’età massima accettabile ben definita per ciascun livello di gravità e aspettative chiare riguardo alle tempistiche di risoluzione.
Se la dirigenza prende visione dei dati relativi alla vulnerabilità solo quando richiesto dall’ufficio di conformità, il programma si limita a fornire report su richiesta, anziché effettuare misurazioni continue o gestire il rischio in modo proattivo.
Gli indicatori vi consentono di capire se il programma sta funzionando. Non tengono conto delle realtà operative che rendono più difficile l'attuazione. Il modo in cui un programma soddisfa tali requisiti varia quando l’ambiente stesso è complesso e distribuito.
Il CVM in contesti complessi e regolamentati
Gli ambienti complessi non esentano un programma dal rispetto delle condizioni di continuità definite in precedenza. Essi comportano vincoli operativi che il programma tiene in considerazione.
- Endpoint distribuiti e offline: Gli agenti remoti possono funzionare con connessione intermittente. I programmi continui gestiscono questa situazione tramite la sincronizzazione dello stato al momento della riconnessione, le azioni correttive in coda e il monitoraggio delle lacune di copertura per le risorse offline che superano una soglia definita.
- Endpoint convergenti OT/IT: La scansione può causare interruzioni nei sistemi di tecnologia operativa. I programmi continui si adattano tramite monitoraggio passivo, modalità senza agenti o con agenti in sola lettura laddove l’ambiente OT lo consenta, flussi di lavoro separati per il rilevamento e la correzione delle risorse OT, nonché politiche di esclusione esplicite con controlli compensativi.
- Settori regolamentati (Legge NIST, PCI DSS, HIPAA): CVM produce prove pronte per l’audit, correlate ai quadri normativi di conformità, attraverso la raccolta continua di prove, la mappatura automatizzata dei risultati rispetto ai requisiti di controllo e la gestione documentata delle eccezioni nel contesto normativo.
Lo standard di continuità rimane invariato. L'implementazione si adatta.
Una volta affrontata la questione della complessità dell’ambiente, la domanda finale è: in che modo il CVM si integra con tutti gli altri elementi del vostro stack di sicurezza e IT?
Integrazione di CVM con i Suoi flussi di lavoro esistenti in materia di sicurezza e IT
Un programma continuativo si integra con i Suoi strumenti di sicurezza e informatici esistenti, anziché sostituirli. Il suo valore dipende dalla qualità dell'integrazione.
- SIEM /SOAR: I risultati relativi alle vulnerabilità confluiscono nei flussi di lavoro delle operazioni di sicurezza tramite avvisi automatici per i risultati critici, un contesto arricchito negli eventi “ SIEM ” e playbook SOAR che attivano azioni di applicazione delle patch e di configurazione.
- ITSM/gestione dei ticket: Le azioni correttive confluiscono nel processo di gestione delle modifiche dell’IT. In questo caso si applicano i requisiti relativi allo SLA e alla gestione dei ticket indicati nella sezione dedicata alle lacune di coordinamento.
- Pipeline CI/CD e DevOps: Per le organizzazioni con cicli di rilascio rapidi, i controlli delle vulnerabilità vengono integrati nelle pipeline di distribuzione anziché essere eseguiti dopo la distribuzione. In un modello DevSecOps, l’approccio “shift-left” consente di individuare i problemi di sicurezza già in fase di sviluppo.
- Patch gestione: Un programma continuativo si basa su un flusso di lavoro efficiente per la gestione delle patch, al fine di trasformare i risultati in vulnerabilità risolte. L’applicazione delle patch al sistema operativo copre la più ampia gamma di risorse; l’applicazione delle patch alle applicazioni riguarda invece il software di terze parti, i browser e le suite di produttività, che rappresentano una quota significativa delle vulnerabilità sfruttate, ma che sono spesso escluse dai flussi di lavoro incentrati sul sistema operativo. In assenza di processi strutturati di applicazione delle patch su entrambi i livelli, i dati relativi al rilevamento si accumulano senza produrre risultati in termini di correzione.
- Gestione degli endpoint: La piattaforma CVM condivide i dati con l’infrastruttura degli agenti utilizzata per la gestione dell’ endpoint , oppure opera sulla stessa infrastruttura, eliminando così la necessità di agenti di scansione separati e consentendo la correzione delle vulnerabilità dalla stessa console che le ha individuate.
In che modo “ Tanium ” supporta la gestione continua delle vulnerabilità
Quanto sopra descrive i requisiti di un programma continuo. È proprio nel periodo che intercorre tra l’individuazione di una vulnerabilità e la conferma della sua risoluzione che la maggior parte dei programmi perde continuità, ed è in questo momento che l’architettura della piattaforma determina se il programma sia effettivamente in grado di garantire i risultati previsti.
Gli strumenti di rilevamento individuano il problema. La bonifica dipende da un team diverso, da uno strumento diverso e da un elenco di priorità diverso. È proprio quel passaggio di consegne, che si ripete in migliaia di risultati, a trasformare un programma “continuativo” in uno periodico.
La piattaforma IT autonoma Tanium colma tale lacuna, gestendo il rilevamento, la definizione delle priorità, la correzione e la verifica all’interno di un unico set di dati. I team addetti alla sicurezza e all’IT operano sulla base degli stessi dati in tempo reale provenienti dall’ endpoint , il che elimina il ritardo tra il momento in cui “abbiamo individuato il problema” e quello in cui “lo abbiamo risolto”. Quando viene rilasciato un aggiornamento critico CVE , Tanium è progettato per fornire ai team una visibilità quasi istantanea e una visione completa delle azioni correttive in tutto l’ambiente, aiutandoli a passare direttamente dall’identificazione all’applicazione delle patch.
Dal punto di vista operativo, ciò si riflette nell’intero ciclo di vita del CVM:
- Il monitoraggio in tempo reale delle risorse sostituisce i dati di scansione obsoleti: Tanium rileva lo stato attuale direttamente dagli endpoint, coprendo dispositivi gestiti, non gestiti e quelli che si riconnettono dopo essere stati offline. Ciò significa che l'inventario delle risorse riflette ciò che esiste effettivamente in questo momento, non ciò che esisteva durante l'ultima finestra di scansione.
- La correzione avviene nel punto stesso in cui avviene il rilevamento: Findings confluiscono direttamente nei flussi di lavoro relativi alle patch e alla configurazione all’interno della stessa piattaforma. Nessuna creazione manuale di ticket, nessun ritardo nel passaggio di consegne, nessuna ambiguità in merito alla responsabilità tra il reparto sicurezza e quello IT.
- La verifica a ciclo chiuso conferma le correzioni, non solo le implementazioni: Tanium verifica le correzioni a livello di codice senza pianificare una nuova scansione. I dati relativi allo stato, basati sugli agenti, confermano se la condizione di vulnerabilità persiste; pertanto, una vulnerabilità viene contrassegnata come risolta solo quando la correzione viene confermata presso l’ endpoint. Non quando il termine per l'acquisto dei biglietti scade.
L'implementazione iniziale degli agenti su una flotta di grandi dimensioni richiede una pianificazione accurata, in particolare in ambienti caratterizzati da un rigoroso controllo delle modifiche; tuttavia, l'onere operativo continuativo è compensato dall'eliminazione della necessità di gestire più strumenti di scansione e correzione.
Non si tratta di distinzioni teoriche. Recovery Centers of America ha utilizzato Tanium per individuare 400.000 vulnerabilità nei propri 2.200 endpoint, vulnerabilità che in precedenza non erano state rilevate. Tanium ha poi aiutato l'organizzazione a ridurre tale numero del 80 per cento in poco più di due settimane. RCA ha inoltre sfruttato l’integrazione di Tanium'con ServiceNow per consolidare strumenti separati e integrare i dati in tempo reale di endpoint nei flussi di lavoro relativi alla gestione dei ticket, alla gestione delle modifiche e alla gestione delle risorse. Legga il caso di studio “”.
Tanium 'L’architettura unificata della piattaforma affronta il problema strutturale che impedisce alla maggior parte dei programmi CVM di raggiungere una continuità effettiva: il divario tra il rilevamento e la correzione verificata.
Grazie alla gestione in tempo reale dei dati relativi allo stato dell’ endpoint e e alla possibilità offerta ai team di sicurezza e IT di effettuare operazioni di “ Detect”, stabilire le priorità, correggere i problemi e verificare l’efficacia delle misure adottate da un unico sistema, Tanium elimina i ritardi dovuti al coordinamento e l’onere legato al passaggio da uno strumento all’altro, che trasformano i programmi “continui” in programmi sporadici. Le organizzazioni acquisiscono la capacità operativa di stabilire, nel giro di poche ore, se una vulnerabilità appena resa nota ( CVE ) abbia un impatto sul proprio ambiente e di confermare a livello di programma quando la correzione è stata completata: queste sono le due condizioni che distinguono i programmi continui da quelli puramente aspirazionali.
Domande frequenti sulla gestione continua delle vulnerabilità
Una vera continuità dipende dal colmare il divario tra l’individuazione e la risoluzione verificata del problema. Le domande che seguono riguardano le lacune più comuni che i team riscontrano quando valutano o sviluppano un programma CVM.
Che cos’è la gestione continua delle vulnerabilità?
La gestione continua delle vulnerabilità è un processo continuo e automatizzato volto a individuare, analizzare, classificare in ordine di priorità e correggere le falle di sicurezza presenti nell’infrastruttura IT di un’organizzazione, che garantisce una visibilità in tempo reale e e sullo stato delle risorse e sul livello di vulnerabilità, anziché basarsi su cicli di scansione periodici.
In che modo la gestione continua delle vulnerabilità si integra con gli strumenti di sicurezza esistenti?
La gestione continua delle vulnerabilità si integra con gli strumenti di sicurezza e IT esistenti tramite piattaforme SOAR ( SIEM) per flussi di lavoro automatizzati di allerta e risposta, sistemi ITSM/di gestione dei ticket per il monitoraggio delle azioni correttive, piattaforme di gestione delle patch per la distribuzione e la verifica automatizzate, nonché un’infrastruttura di gestione “ endpoint ” volta a eliminare gli agenti ridondanti e a consolidare il rilevamento e la correzione su un unico set di dati.
In che modo la gestione continua delle vulnerabilità si inserisce in una strategia di sicurezza informatica?
La gestione continua delle vulnerabilità costituisce il livello operativo che traduce la strategia di sicurezza in una riduzione misurabile del rischio, garantendo una visibilità in tempo reale sulla superficie di attacco, stabilendo le priorità di correzione in base alla vulnerabilità e al contesto aziendale e fornendo una misurazion e e continua delle tendenze di esposizione che orientano le decisioni più ampie in materia di gestione del rischio.
In che modo la gestione continua delle vulnerabilità migliora il livello di sicurezza?
La gestione continua delle vulnerabilità migliora il livello di sicurezza riducendo l’intervallo di tempo che intercorre tra la segnalazione di una vulnerabilità e la correzione verificata, eliminando le lacune di copertura causate dalle scansioni periodiche e fornendo alla dirigenza prove misurabili della riduzione del rischio attraverso indicatori quali il tempo medio di rilevamento (mean time to detection, ), il tempo medio di correzione (mean time to remediate,) e le tendenze relative all’anzianità delle vulnerabilità.
Come si misura il successo della gestione continua delle vulnerabilità?
Il successo si misura in base alla capacità del programma di ridurre in modo dimostrabile l'esposizione nel corso del tempo. I sei indicatori chiave illustrati in precedenza in questo articolo (percentuale di copertura della scansione, tempo medio di rilevamento, tempo medio di risoluzione, tasso di falsi positivi, tasso di eccezioni e tasso di convalida della risoluzione) forniscono le prove misurabili. Un programma funziona quando i vertici aziendali possono osservare una linea di tendenza che evidenzia una riduzione dei tempi di esposizione, e non solo un’istantanea dei ticket aperti.
La gestione continua delle vulnerabilità non costituisce una categoria di prodotti. Si tratta di uno standard operativo. La questione non è se i Suoi strumenti di eseguano scansioni. Si tratta di capire se il Suo programma sia in grado di indicare, in questo preciso momento, quali risorse siano esposte e se le correzioni apportate ieri abbiano effettivamente funzionato. Questa è la differenza tra “frequente” e “continuo”.
Tanium'La piattaforma unificata di offre ai team di sicurezza e IT la visibilità in tempo reale e la verifica a ciclo chiuso necessarie per soddisfare tale standard, eliminando le lacune di coordinamento che impediscono alla maggior parte dei programmi di raggiungere una continuità effettiva. Prenoti una demo personalizzata per scoprire come la soluzione possa adattarsi al Suo ambiente all’indirizzo.
