La gestione delle vulnerabilit\u00e0 non \u00e8 cambiata molto nel corso degli anni. Eseguiamo scansioni pianificate, esaminiamo i risultati, organizziamo per priorit\u00e0 i rischi e risolviamo i problemi durante la prossima finestra disponibile. Questo modello \u00e8 stato progettato per la prevedibilit\u00e0 e per un tempo diverso. Ma il software non cambia pi\u00f9 secondo programmi prevedibili. Ogni giorno compaiono nuove applicazioni, gli aggiornamenti sono continui e gli attori delle minacce non aspettano la prossima scansione.<\/p>\n
Eppure ci sono molti programmi di gestione delle vulnerabilit\u00e0 che operano ancora in questo modo.<\/p>\n
La gestione delle vulnerabilit\u00e0 basata su scansioni \u00e8 diventata lo standard del settore perch\u00e9 pratica e facile da misurare. Scansioni regolari hanno fornito ai team di sicurezza una visione chiara del rischio e hanno stabilito cicli di reporting strutturati per la conformit\u00e0. I flussi di lavoro sono stati progettati intorno a questo programma, dalla definizione delle priorit\u00e0 alla risoluzione dei problemi, fino al reporting per i dirigenti esecutivi. Il modello funzionava bene per gli ambienti che cambiavano lentamente ed erano pi\u00f9 facili da gestire.<\/p>\n
La scansione delle vulnerabilit\u00e0 \u00e8 stata originariamente progettata per le infrastrutture centralizzate, dove le modifiche erano poco frequenti e i sistemi erano pi\u00f9 facili da monitorare. I programmi di conformit\u00e0 hanno rafforzato questo modello richiedendo scansioni regolari e cicli di reporting formali. L’approccio \u00e8 riuscito a migliorare la visibilit\u00e0, ma non \u00e8 mai stato progettato per ottimizzare la velocit\u00e0 di correzione.<\/p>\n
Nei modelli tradizionali, le vulnerabilit\u00e0 vengono rilevate durante le scansioni pianificate che spesso vengono eseguite periodicamente. Le scansioni settimanali e mensili sono le pi\u00f9 comuni. Questa configurazione crea un divario prevedibile tra le modifiche ai software e il rilevamento dei rischi. Non \u00e8 dovuto alla negligenza, ma al fatto che il sistema si basa su controlli periodici.<\/p>\n
Con i dispositivi distribuiti in luoghi diversi, le modifiche avvengono costantemente e questo ritardo aumenta il rischio. Se sai che qualcuno sta cercando di entrare in casa tua, perch\u00e9 lasciare la finestra aperta e la porta aperta fino alla prossima ispezione?<\/p>\n
Come gi\u00e0 detto, la cadenza di scansione del settore \u00e8 spesso settimanale o mensile e in molti ambienti le finestre di esposizione si estendono per 15-30<\/a> giorni tra i cicli di scoperta. Durante questo periodo, nuove vulnerabilit\u00e0 possono essere gi\u00e0 note pubblicamente, mentre lo sfruttamento accelera. Il volume dei CVE<\/a> continua a crescere di anno in anno e i tempi di sfruttamento si riducono. Storicamente, la gestione delle vulnerabilit\u00e0 si basa sulla scoperta periodica; ci\u00f2 significa che il rischio viene identificato dopo che l’esposizione \u00e8 gi\u00e0 presente. Il modello \u00e8 stato ottimizzato per i cicli di reporting piuttosto che per l’immediatezza.<\/p>\n La maggior parte delle organizzazioni dispone gi\u00e0 di strumenti che rilevano le vulnerabilit\u00e0. Ci\u00f2 che li rallenta \u00e8 il divario tra il rilevamento e l’azione. I flussi di lavoro tradizionali spesso dividono la scansione, la reportistica e la correzione tra sistemi separati. I risultati passano da un team all’altro e da uno strumento all’altro prima che si intervenga per la risoluzione. L’attrito introduce la latenza, e la latenza prolunga l’esposizione.<\/p>\n Pi\u00f9 tempo ci vuole per passare da “conosciuto” a “risolto”, pi\u00f9 ampia diventa la finestra di vulnerabilit\u00e0. La visibilit\u00e0 da sola non riduce il rischio, ma la velocit\u00e0 s\u00ec.<\/p>\n NinjaOne adotta un approccio diverso. Invece di dipendere dai cicli di scansione, abbina continuamente i dati del software degli endpoint in tempo reale con le informazioni CVE attuali. La consapevolezza delle vulnerabilit\u00e0 viene attivata dalle modifiche dei software piuttosto che dai programmi di scansione. Ci\u00f2 significa che l’esposizione viene rilevata entro pochi minuti dal cambiamento, anzich\u00e9 settimane dopo. Il cambiamento elimina la scansione come dipendenza per la consapevolezza delle vulnerabilit\u00e0.<\/p>\n Il cambiamento pi\u00f9 significativo \u00e8 quello che avviene dopo. La gestione tradizionale delle vulnerabilit\u00e0 si comporta spesso come una pipeline: scansione, esportazione dei risultati, creazione di ticket e successiva correzione. NinjaOne collega la consapevolezza delle vulnerabilit\u00e0 direttamente ai flussi di lavoro delle patch. Il rilevamento e la correzione condividono lo stesso sistema operativo. L’IT \u00e8 responsabile della consapevolezza e della correzione, mentre SecOps verifica e monitora. La gestione delle vulnerabilit\u00e0 diventa un ciclo continuo piuttosto che un esercizio di reporting periodico.<\/p>\n Nella cybersecurity, la semplificazione viene spesso fraintesa come compromesso. In realt\u00e0, la riduzione della complessit\u00e0 operativa pu\u00f2 rafforzare la sicurezza accelerando le risposte.<\/p>\n Le configurazioni tradizionali della gestione delle vulnerabilit\u00e0 utilizzano spesso molti strumenti: scanner, motori di reporting, piattaforme di correzione e livelli di conformit\u00e0. Ogni strumento pu\u00f2 migliorare la visibilit\u00e0, ma aggiunge anche complessit\u00e0 operativa. Integrando la consapevolezza delle vulnerabilit\u00e0 nella gestione degli endpoint, NinjaOne riduce il sovraccarico di strumenti ed elimina i passaggi di consegne. Il risultato \u00e8 una correzione pi\u00f9 rapida e un modello di sicurezza pi\u00f9 semplice e unificato.<\/p>\n Per molto tempo, la gestione delle vulnerabilit\u00e0 \u00e8 iniziata con la scansione, considerata il modo migliore per individuare i rischi. Ma le cose sono cambiate. I software sono in continua evoluzione, gli endpoint sono distribuiti ovunque e gli exploit si verificano rapidamente. La scansione \u00e8 ancora utile, ma non deve pi\u00f9 essere il primo passo.<\/p>\n Quando la consapevolezza delle vulnerabilit\u00e0 viene innescata da un cambiamento e la correzione avviene all’interno dello stesso flusso di lavoro operativo, le finestre di esposizione si riducono da settimane a minuti. La gestione delle vulnerabilit\u00e0 passa da una disciplina di reporting a una disciplina operativa.<\/p>\n Il termine “cambio di paradigma” \u00e8 spesso abusato nel marketing della cybersecurity, e viene associato anche a piccoli miglioramenti o dashboard pi\u00f9 rapide. In questo caso, significa passare da controlli occasionali a una consapevolezza costante, cicli continui e risposte guidate da cambiamenti effettivi.<\/p>\n La gestione delle vulnerabilit\u00e0 \u00e8 stata progettata per un mondo pi\u00f9 lento, ma l’ambiente IT di oggi lavora velocemente e cos\u00ec anche NinjaOne.<\/p>\n","protected":false},"excerpt":{"rendered":" La gestione delle vulnerabilit\u00e0 non \u00e8 cambiata molto nel corso degli anni. Eseguiamo scansioni pianificate, esaminiamo i risultati, organizziamo per priorit\u00e0 i rischi e risolviamo i problemi durante la prossima finestra disponibile. Questo modello \u00e8 stato progettato per la prevedibilit\u00e0 e per un tempo diverso. Ma il software non cambia pi\u00f9 secondo programmi prevedibili. Ogni […]<\/p>\n","protected":false},"author":260,"featured_media":792848,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"","_relevanssi_noindex_reason":"","_lmt_disableupdate":"no","_lmt_disable":"","footnotes":""},"categories":[4367],"tags":[],"class_list":["post-817990","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicurezza"],"acf":[],"modified_by":"Sergio Oricci","_links":{"self":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts\/817990","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/users\/260"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/comments?post=817990"}],"version-history":[{"count":0,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/posts\/817990\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/media\/792848"}],"wp:attachment":[{"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/media?parent=817990"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/categories?post=817990"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ninjaone.com\/it\/wp-json\/wp\/v2\/tags?post=817990"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Il problema non \u00e8 la visibilit\u00e0, ma la latenza<\/h2>\n
La consapevolezza della vulnerabilit\u00e0 dovrebbe essere innescata dal cambiamento<\/h2>\n
Dalla pipeline di reporting al ciclo operativo<\/h2>\n
La semplificazione \u00e8 un vantaggio per la sicurezza<\/h2>\n
Un nuovo modo di pensare alla gestione delle vulnerabilit\u00e0<\/h2>\n