La maggior parte dei programmi di gestione delle vulnerabilità si definisce "continuo". Pochi in realtà lo sono. La differenza è importante: un programma che esegue la scansione settimanale ma si definisce continuo crea una falsa fiducia, lasciando aperte le esposizioni tra i cicli mentre la leadership presume che la copertura sia completa.
La gestione continua delle vulnerabilità, o CVM, è un processo continuo e automatizzato per scoprire, analizzare, assegnare priorità e correggere i punti deboli della sicurezza nell’infrastruttura IT di un’organizzazione. A differenza dei cicli periodici di scansione e report, CVM mantiene la visibilità in tempo reale sullo stato delle risorse e sullo stato delle vulnerabilità, riducendo la finestra che gli aggressori devono sfruttare i difetti appena divulgati.
Questo articolo fornisce un quadro diagnostico per valutare se il programma esistente soddisfa lo standard operativo che "continua" implica, coprendo le condizioni specifiche, le metriche e le strutture di coordinamento che separano i programmi veramente continui da quelli frequenti.
Che cosa significa "continua" in realtà e perché la maggior parte dei programmi non si qualificano
La maggior parte dei programmi che si definiscono "continuo" continuano a funzionare su cicli di scansione settimanali o mensili. Stilano le priorità, creano i ticket manualmente e presumono che la correzione abbia funzionato senza verificarla. Nel frattempo, la superficie di attacco continua a cambiare: nuove risorse si attivano, le configurazioni si spostano e le nuove CVE divulgate creano finestre di esposizione che i cicli di scansione settimanali non possono chiudere.
I programmi periodici pianificano le scansioni, prioritizzano i batch e generano i ticket manualmente. I programmi continui mantengono la consapevolezza dello stato in tempo reale, attivano la prioritizzazione quando le condizioni cambiano e verificano la correzione attraverso controlli a ciclo chiuso.
Un programma veramente continuo soddisfa tutti i seguenti requisiti:
- I nuovi asset vengono rilevati e inventariati in poche ore, non in giorni
- Le vulnerabilità appena divulgate vengono valutate rispetto all’inventario completo delle risorse all’interno di uno SLA definito
- Lo stato di risanamento è verificato in modo programmatico, non presunto
La maggior parte dei programmi non è all'altezza di almeno una di queste proprietà, e il motivo è di solito dove si siedono nello spettro di maturità del monitoraggio.
Tre livelli di continuità del monitoraggio: periodico, ad alta frequenza e in tempo reale
Capire dove si trova il tuo programma nello spettro del monitoraggio continuo delle vulnerabilità aiuta a chiarire quali costi "continui" effettivamente e quali lacune rimangono.
Livello 1: Scansione periodica. Le scansioni programmate vengono eseguite settimanalmente, mensilmente o trimestralmente. La latenza di rilevamento delle vulnerabilità viene misurata in giorni o settimane. Tra un ciclo e l'altro sono presenti divari di copertura. Questo approccio funziona per ambienti stabili e a basso cambiamento, ma non coglie 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 ore. La copertura migliora per gli ambienti dinamici, ma le risorse effimere come i container e le istanze cloud con scalabilità automatica (compresi i carichi di lavoro in esecuzione nei cluster Kubernetes che possono girare e terminare entro un singolo intervallo di scansione) possono ancora esistere tra le finestre di scansione e passare inosservate.
Livello 3: monitoraggio in tempo reale dello stato basato su agenti. Gli agenti persistenti segnalano continuamente lo stato e la configurazione delle risorse. La latenza di rilevamento scende a minuti. Le risorse di riconnessione effimere e offline sono coperte. Il compromesso è rappresentato dal sovraccarico di distribuzione e gestione degli agenti.
| Livello | Latenza di rilevamento | Asset copertura | Migliore vestibilità |
|---|---|---|---|
| Periodico | Da giorni a settimane | Spazi tra i cicli | Ambienti stabili e a basso cambiamento |
| Alta frequenza | Ore | Manca risorse effimere | Infrastruttura dinamica ma prevedibile |
| Tempo reale | Minuti | Copre le risorse offline/emeriche | Ambienti grandi, distribuiti o in rapida evoluzione |
La maggior parte dei programmi aziendali opera a livello 1 o 2 e presuppone che siano "continui". Tanium L'architettura ad agente singolo di fornisce dati sullo stato in tempo reale che eliminano il divario di latenza insito nella scansione delle vulnerabilità pianificate. La questione non è quale livello è “migliore”. È il livello che corrisponde al profilo di rischio del tuo ambiente e alla velocità di modifica.
Il livello di monitoraggio determina la velocità con cui si individuano le vulnerabilità. Quello che succede dopo determina se trovarli è importante.
Dove si interrompono i programmi CVM aziendali: il divario di coordinamento IT/SecOps
Il rilevamento senza rimedio è solo una consapevolezza costosa. Il più grande errore di continuità in un sistema CVM aziendale non è un problema tecnologico. È un problema di coordinamento che impedisce ai team di correggere le vulnerabilità rilevate alla velocità richiesta dal programma. Questo gap di coordinamento ha conseguenze reali: la ricerca mostra costantemente che molte violazioni dei dati non fanno risalire a vulnerabilità non rilevate, ma a vulnerabilità note che non hanno ricevuto patch perché nessuno era padrone del passaggio tra sicurezza e IT.
I team di sicurezza Detect le vulnerabilità. La risoluzione dipende dai team operativi IT con priorità diverse, SLA diversi e processi di controllo delle modifiche diversi. Il divario tra "lo abbiamo trovato" e "lo abbiamo risolto" è dove vive l'esposizione.
Errori di integrazione dei ticket. Quando i risultati delle vulnerabilità richiedono la creazione manuale di ticket, i ritardi misurati in giorni sono comuni. La gestione integrata dei ticket ha un aspetto diverso: i risultati generano automaticamente i ticket con la gravità, il contesto delle risorse e le linee guida per la risoluzione dei problemi allegati. I passaggi manuali introducono attriti che aggravano migliaia di risultati.
Disallineamento degli SLA. La sicurezza definisce la criticità in base al CVSS o al punteggio di rischio. L'IT definisce la priorità in base alla disponibilità della finestra di modifica e all'impatto sul business. Senza livelli di SLA condivisi, le vulnerabilità critiche rimangono in coda mentre i team discutono sulla pianificazione.
Una struttura SLA pratica potrebbe essere simile a questa:
- Livello 1 (critico, sfruttato attivamente): SLA di correzione di 24 ore
- Livello 2 (alto, disponibile exploit): SLA di 7 giorni (ottenibile su larga scala con patching automatizzato; adattabile in base alla complessità dell’ambiente)
- Tier 3 (medio/basso): Finestra di manutenzione programmata o accettata in base al Risk
Ambiguità di proprietà. Quando nessuno possiede il risultato della correzione end-to-end, le vulnerabilità invecchiano nelle code dei ticket. Un processo di correzione chiaramente definito risponde a tre domande: Chi possiede il ticket? Chi è il titolare della verifica? Chi è responsabile dell’eccezione se la correzione viene rinviata?
Quindi, che aspetto ha un programma realmente continuo? La sezione successiva lo suddivide in cinque condizioni verificabili.
Le cinque condizioni che un programma realmente continuo soddisfa
Pensa a quanto segue come a una lista di controllo, non a un ciclo di vita. Ogni condizione è soddisfatta o non soddisfatta. Il credito parziale non riduce l'esposizione.
1. Inventario completo e in tempo reale degli asset
Il programma mantiene un inventario dello stato corrente che tiene conto delle risorse effimere, remote e offline. Non un CMDB che rimane indietro di giorni o settimane rispetto alla realtà.
Test: Puoi confermare entro un'ora se un CVE critico appena divulgato influisce su una risorsa nel tuo ambiente? Se la risposta è "dovremmo eseguire prima una scansione", si ha un gap di continuità.
2. Rilevamento basato su eventi
Le nuove vulnerabilità attivano i flussi di lavoro di rilevamento immediatamente dopo la divulgazione, non nella finestra di scansione successiva. Ciò richiede un’integrazione attiva con i feed di intelligence sulle minacce e gli avvisi di sicurezza dei fornitori, compresi gli aggiornamenti KEV CISA, le pubblicazioni NVD e i bollettini specifici dei fornitori come Microsoft Patch Tuesday e gli avvisi di distribuzione Linux , in modo che gli eventi di divulgazione avviino automaticamente la valutazione delle risorse anziché attendere una scansione programmata.
Test: Quando viene pubblicato un CVE critico, quanto tempo ci vorrà prima che il tuo programma valuti ogni risorsa rispetto ad esso? Le ore sono continue. I giorni sono frequenti. Le settimane sono periodiche.
3. Prioritizzazione contestuale integrata nel flusso di lavoro
La prioritizzazione utilizza la criticità degli asset, i segnali di sfruttabilità come EPSS e CISA KEV e l’intelligence sulle minacce (comprese le minacce emergenti che potrebbero non avere ancora punteggi CVSS elevati ma che vengono attivamente utilizzate come arma in natura). Exploit Prediction Scoring System (EPSS) stima la probabilità che una vulnerabilità venga sfruttata in natura entro 30 giorni, fornendo un segnale lungimirante che la gravità della CVSS da sola non può catturare. Questo è il dominio della gestione delle vulnerabilità basata sul rischio, che copre la metodologia.
4. Risanamento con verifica a circuito chiuso
Ogni azione correttiva viene verificata a livello di programmazione. La vulnerabilità non è contrassegnata come "risolta" fino a quando un controllo di follow-up non conferma la correzione. La correzione automatizzata delle vulnerabilità copre gli approcci di implementazione.
5. Misurazione e reporting continui
Il programma tiene traccia delle proprie metriche di performance e le segnala alle parti interessate con una cadenza definita. Non solo quando i revisori lo chiedono. Se non sai rispondere "Qual è il nostro tempo medio per rimediare alle vulnerabilità critiche?" senza estrarre un rapporto personalizzato, il programma sta generando rapporti su richiesta, non misurando continuamente.
Il guasto su una singola condizione crea esposizione. Un programma con rilevamento perfetto ma nessuna verifica sta segnalando l'attività, non i risultati.
Delle cinque condizioni, la verifica è quella che la maggior parte delle squadre salta interamente. Vediamo perché è importante.
Convalida: la fase CVM che la maggior parte dei programmi salta
La maggior parte dei team contrassegna le vulnerabilità come “risolte” quando viene distribuita una patch, non quando l’esposizione viene confermata come chiusa. Quel divario tra "abbiamo spinto la correzione" e "la correzione ha effettivamente funzionato" è la fonte di falsa fiducia.
Prima della correzione
Conferma pre-correzione
Prima di assegnare una vulnerabilità per la correzione, verificare che il rilevamento dello scanner rappresenti un’esposizione reale e sfruttabile. Non è un falso positivo o un artefatto di configurazione. Questo passaggio rileva anche le configurazioni errate che gli scanner emergono come vulnerabilità: problemi che potrebbero richiedere una modifica della configurazione piuttosto che una patch e che vengono instradati in modo errato quando viene saltato il triage pre-rimediazione. Saltare questo passaggio spreca cicli IT ed erode la fiducia nel programma VM nel tempo.
Dopo la distribuzione della correzione
Verifica post-risanamento
Dopo l'implementazione di una patch di sicurezza o di una modifica della configurazione, verifica a livello di programmazione che la vulnerabilità sia effettivamente chiusa. Una nuova scansione o un controllo dello stato basato su agente conferma che la condizione vulnerabile non esiste più sull’asset. “Il ticket è chiuso” non è una verifica.
Per beni di alto valore
Convalida contraddittorio
Per le risorse di alto valore o le tappe fondamentali della correzione, i test di penetrazione forniscono un livello di convalida contraddittorio che la verifica automatizzata non può replicare. Le ripetizioni programmatiche confermano che una specifica condizione vulnerabile è chiusa; un test mirato va oltre. I controlli automatici confermano che una condizione è chiusa. Non possono confermare che l'esposizione è andata.
Quando la correzione non è possibile
Gestione delle eccezioni
Per le vulnerabilità che non possono essere risolte, come i sistemi legacy o le applicazioni business-critical con blocco delle modifiche, definite un processo di eccezione formale. Documentare l’accettazione del rischio, i controlli compensativi, la cadenza di revisione e le date di scadenza. Le eccezioni senza data di scadenza diventano esposizione permanente.
Un programma CVM che non è in grado di dimostrare l'efficacia delle azioni correttive misura l'occupabilità, non la sicurezza.
La verifica risponde se le singole correzioni hanno funzionato. Le metriche rispondono se il programma stesso sta funzionando. Ecco come capire la differenza.
Come valutare se il tuo CVM funziona
Le metriche sono l'unico modo per distinguere un programma che è veramente continuo da uno che è semplicemente frequente. Tieni traccia dei seguenti elementi, segnalali regolarmente e utilizzali per promuovere il miglioramento. Nel loro insieme, questi indicatori forniscono alla leadership una visione misurabile della posizione di sicurezza dell’organizzazione: non solo un’istantanea dei ticket aperti, ma una linea di tendenza che mostra se il programma sta effettivamente riducendo il rischio informatico nel tempo.
| Metrica | Cosa misura | Sano Benchmark |
|---|---|---|
| Percentuale di copertura scansione | Percentuale di attività note sotto monitoraggio attivo | Si avvicina al 100%, con eccezioni documentate |
| Tempo medio di rilevamento (MTTD) | Ore tra la pubblicazione della CVE e la conferma dell’impatto | Ore per i CVE critici, non giorni |
| Tempo medio di risoluzione (MTTR) | Tempo dal rilevamento alla chiusura verificata, per gravità | All'interno di livelli SLA definiti |
| Tasso di falsi positivi | Percentuale di risultati non sfruttabili | Declino nel tempo |
| Tasso di eccezione | Percentuale di risultati accettati dal rischio rispetto a quelli corretti | Stabile o in calo, tutto documentato |
| Tasso di convalida degli interventi correttivi | Percentuale di risultati "risolti" verificati a livello di programmazione | Approssimandosi al 100% per i valori critici/alti |
L’invecchiamento delle vulnerabilità è una settima metrica facoltativa: per quanto tempo le vulnerabilità rimangono aperte in tutto l’ambiente nel tempo? Una distribuzione sana tende a una rapida chiusura, con un’età massima accettabile definita per ciascun livello di gravità e aspettative chiare per le tempistiche di risoluzione.
Se la leadership vede solo i dati sulle vulnerabilità quando la conformità lo richiede, il programma sta segnalando su richiesta, non misurando continuamente o gestendo il rischio in modo proattivo.
Le metriche ti dicono se il programma sta funzionando. Non tengono conto delle realtà operative che rendono più difficile l'implementazione. Il modo in cui un programma soddisfa questi requisiti cambia quando l'ambiente stesso è complesso e distribuito.
CVM in ambienti complessi e regolamentati
Gli ambienti complessi non esonerano un programma dalle condizioni di continuità definite in precedenza. Aggiungono vincoli operativi che il programma accoglie.
- Endpoint distribuiti e offline: gli agenti remoti possono operare connessi in modo intermittente. I programmi continui gestiscono questo attraverso la sincronizzazione dello stato alla riconnessione, le azioni di correzione in coda e il monitoraggio delle lacune di copertura per le risorse offline oltre una soglia definita.
- Endpoint convergenti OT/IT: la scansione può interrompere i sistemi tecnologici operativi. I programmi continui si adattano con monitoraggio passivo, modalità agente senza agente o di sola lettura laddove l’ambiente OT lo consente, flussi di lavoro separati di rilevamento e correzione per le risorse OT e policy di esclusione esplicite con controlli compensativi.
- Settori regolamentati (NIST, PCI DSS, HIPAA): CVM produce prove pronte per l'audit mappate ai framework di conformità attraverso la raccolta continua di prove, la mappatura automatizzata dei risultati per controllare i requisiti e la gestione documentata delle eccezioni con il contesto normativo.
Lo standard di continuità non cambia. L’implementazione si adatta.
Una volta affrontata la complessità dell’ambiente, la domanda finale è come CVM si connette a tutto il resto dello stack IT e della sicurezza.
Collegare CVM ai flussi di lavoro IT e di sicurezza esistenti
Un programma continuo si lega agli strumenti di sicurezza e IT esistenti anziché sostituirli. Il suo valore dipende dalla qualità dell’integrazione.
- SIEM /SOAR: i risultati delle vulnerabilità confluiscono nei flussi di lavoro delle operazioni di sicurezza attraverso avvisi automatici per i risultati critici, contesto arricchito negli eventi SIEM e playbook SOAR che attivano le azioni di patch e configurazione.
- ITSM/ticketing: le azioni correttive confluiscono nel processo di gestione delle modifiche dell'IT. Qui si applicano gli SLA e i requisiti di emissione dei biglietti dalla sezione di coordinamento.
- Pipeline CI/CD e DevOps: per le organizzazioni con cicli di rilascio rapidi, i controlli delle vulnerabilità vengono incorporati nelle pipeline di distribuzione anziché eseguire post-implementazione. In un modello DevSecOps, la scansione shift-left rileva i risultati di sicurezza durante lo sviluppo.
- Patch gestione: un programma continuo dipende da un flusso di lavoro di gestione delle patch funzionante per tradurre i risultati in esposizioni chiuse. Le patch del sistema operativo coprono la più ampia impronta di asset; le patch delle applicazioni riguardano software, browser e suite di produttività di terze parti che rappresentano una quota significativa di vulnerabilità sfruttate, ma sono spesso escluse dai flussi di lavoro incentrati sul sistema operativo. Senza processi di patching strutturati su entrambi i livelli, i dati di rilevamento si accumulano senza produrre risultati di correzione.
- Gestione degli endpoint: la piattaforma CVM condivide i dati con o opera sulla stessa infrastruttura degli agenti della gestione degli endpoint , eliminando gli agenti di scansione separati e consentendo la correzione dalla stessa console che ha rilevato la vulnerabilità.
In che modo Tanium supporta la gestione continua delle vulnerabilità
Tutto quanto sopra descrive ciò che un programma continuo richiede. Il divario tra il rilevamento di una vulnerabilità e la conferma che è stata risolta è il punto in cui la maggior parte dei programmi perde continuità e dove l'architettura della piattaforma determina se il programma effettivamente fornisce.
Gli strumenti di rilevamento individuano il problema. La risoluzione dipende da un team diverso, da uno strumento diverso e da un elenco di priorità diverso. Questo passaggio, ripetuto in migliaia di risultati, è ciò che trasforma un programma "continuo" in uno periodico.
La piattaforma IT autonoma Tanium colma questa lacuna mantenendo il rilevamento, la definizione delle priorità, la correzione e la verifica su un singolo set di dati. I team di sicurezza e IT lavorano sugli stessi dati degli endpoint in tempo reale, eliminando il ritardo tra "lo abbiamo trovato" e "lo abbiamo risolto". Quando un CVE critico scende, Tanium è progettato per fornire ai team una Visibilità di correzione quasi istantanea nell’intero ambiente per aiutarli a passare direttamente dall’identificazione all’applicazione di patch.
Dal punto di vista operativo, questo si verifica durante tutto il ciclo di vita del CVM:
- La consapevolezza delle risorse in tempo reale sostituisce i dati di scansione obsoleti: Tanium estrae lo stato attuale direttamente dagli endpoint, coprendo i dispositivi gestiti, non gestiti e che si ricollegano offline. Ciò significa che l'inventario delle risorse riflette ciò che esiste effettivamente in quel momento, non ciò che esisteva nell'ultima finestra di scansione.
- La correzione avviene dove avviene il rilevamento: Findings confluiscono direttamente nei flussi di lavoro di patch e configurazione all’interno della stessa piattaforma. Nessuna creazione manuale di ticket, nessun ritardo nella consegna, nessuna ambiguità di proprietà tra sicurezza e IT.
- La verifica a ciclo chiuso conferma le correzioni, non solo le distribuzioni: Tanium verifica la correzione a livello di programmazione senza dover pianificare una nuova scansione. I dati di stato basati su agenti confermano se la condizione di vulnerabilità persiste, quindi una vulnerabilità viene contrassegnata come risolta solo quando la correzione viene confermata all' endpoint. Non quando il ticket si chiude.
L’implementazione iniziale degli agenti in una grande flotta richiede una pianificazione, in particolare per gli ambienti con un rigoroso controllo delle modifiche, ma il sovraccarico operativo in corso viene compensato eliminando la necessità di gestire più strumenti di scansione e correzione.
Non sono distinzioni teoriche. Recovery Centers of America ha utilizzato Tanium per scoprire 400.000 vulnerabilità nei suoi 2.200 endpoint, vulnerabilità che in precedenza non erano state rilevate. Tanium ha poi aiutato l'organizzazione a ridurre tale conteggio del 80 % in poco più di due settimane. RCA ha anche sfruttato l’integrazione di Tanium con ServiceNow per consolidare strumenti separati e inserire i dati degli endpoint in tempo reale nei flussi di lavoro di ticketing, gestione delle modifiche e gestione delle risorse. Leggi il caso di studio.
Tanium L’architettura della piattaforma unificata di risolve il problema strutturale che impedisce alla maggior parte dei programmi CVM di di raggiungere una continuità effettiva: il divario tra il rilevamento e la correzione verificata.
Mantenendo i dati sullo stato degli endpoint in tempo reale e consentendo ai team di sicurezza e IT di Detect, assegnare priorità, correggere e verificare da un singolo sistema, Tanium elimina i ritardi di coordinamento e i costi di commutazione degli strumenti che trasformano i programmi “continui” in programmi frequenti. Le organizzazioni acquisiscono la capacità operativa di rispondere entro poche ore se una CVE appena divulgata influisce sul loro ambiente e di confermare programmaticamente quando la correzione è completa, le due condizioni che separano i programmi continui da quelli aspirazionali.
Domande frequenti sulla gestione continua delle vulnerabilità
La vera continuità dipende dal colmare il divario tra il rilevamento e la correzione verificata. Le seguenti domande affrontano le lacune più comuni che i team incontrano quando valutano o costruiscono un programma CVM.
Che cos’è la gestione continua delle vulnerabilità?
La gestione continua delle vulnerabilità è un processo continuo e automatizzato di scoperta, analisi, prioritizzazione e correzione dei punti deboli della sicurezza nell’infrastruttura IT di un’organizzazione che mantiene la visibilità in tempo reale sullo stato delle risorse e sullo stato delle vulnerabilità, piuttosto che fare affidamento 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 SIEM/SOAR per flussi di lavoro automatizzati di avviso e risposta, sistemi ITSM/ticketing per il monitoraggio delle correzioni, piattaforme di gestione delle patch per distribuzione e verifica automatizzate e infrastruttura di gestione degli endpoint per eliminare gli agenti ridondanti e consolidare il rilevamento e la correzione su un unico set di dati.
Come si inserisce la gestione continua delle vulnerabilità in una strategia di sicurezza informatica?
La gestione continua delle vulnerabilità funge da livello operativo che traduce la strategia di sicurezza in una riduzione del rischio misurabile mantenendo la visibilità in tempo reale sulla superficie di attacco, dando priorità alla correzione in base alla sfruttabilità e al contesto aziendale e fornendo una misurazione continua delle tendenze di esposizione che informano decisioni di gestione del rischio più ampie.
In che modo la gestione continua delle vulnerabilità migliora il livello di sicurezza?
La gestione continua delle vulnerabilità migliora il livello di sicurezza riducendo la finestra tra la divulgazione delle vulnerabilità e la correzione verificata, eliminando le lacune di copertura create dalla scansione periodica e fornendo alla leadership prove misurabili della riduzione del rischio attraverso metriche come il tempo medio di rilevamento, il tempo medio di correzione e le tendenze dell’invecchiamento delle vulnerabilità.
Come si misura il successo della gestione continua delle vulnerabilità?
Il successo è misurato dal fatto che il programma riduca in modo dimostrabile l’esposizione nel tempo. Le sei metriche principali trattate in precedenza in questo articolo (percentuale di copertura della scansione, tempo medio di rilevamento, tempo medio di correzione, tasso di falsi positivi, tasso di eccezioni e tasso di convalida della correzione) forniscono le prove misurabili. Un programma funziona quando la leadership può vedere una linea di tendenza che mostra finestre di esposizione in contrazione, non solo un'istantanea di ticket aperti.
La gestione continua delle vulnerabilità non è una categoria di prodotto. È uno standard operativo. La domanda non è se i tuoi strumenti eseguono scansioni. È se il tuo programma può rispondere, in questo momento, quali risorse sono esposte e se le correzioni di ieri hanno effettivamente funzionato. Questa è la differenza tra frequente e continuo.La piattaforma unificata di
Tanium 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 vera continuità. Pianifica una demo personalizzata per vedere come può funzionare per il tuo ambiente.
