Ivanti Blog: Sicurezza

Siamo nell’apocalisse delle patch. Ecco perché queste tre scuse IT non funzioneranno più.

Wed, 29 Apr 2026 14:00:07 Z

Il 7 aprile, Anthropic ha annunciato che il suo modello Claude Mythos Preview aveva identificato autonomamente migliaia di vulnerabilità zero-day ad alta gravità e critiche in tutti i principali sistemi operativi e browser web. Oltre il 99% non era stato corretto con patch il giorno della divulgazione.

Due settimane dopo, il 21 aprile, Mozilla ha dichiarato di aver utilizzato lo stesso modello per individuare e correggere con patch 271 vulnerabilità nell’ultima release di Firefox. La valutazione di Mozilla: “Finora non abbiamo trovato alcuna categoria o complessità di vulnerabilità che gli esseri umani possano individuare e che questo modello non sia in grado di trovare”.

271 è solo la prima ondata. Chrome, Edge, Windows, macOS, Linux, FreeBSD: la falla di esecuzione di codice da remoto vecchia di 17 anni in FreeBSD divulgata dal red team di Anthropic (CVE-2026-4747) è un primo esempio di ciò che sta arrivando. Ogni vendor nell’ambito del Project Glasswing di Anthropic è nella posizione di rilasciare correzioni a un ritmo mai visto prima nel settore. Tutte queste correzioni diventano CVE pubbliche con patch disponibili, e finiscono tutte nello stesso posto: il tuo ambiente.

Anche la storia del contenimento presenta una crepa. Il 21 aprile, Bloomberg ha riferito che un gruppo collegato a Discord ha ottenuto accesso non autorizzato a Mythos tramite l’ambiente di un vendor di terze parti. Anthropic afferma che l’attività non si è estesa oltre quel vendor. Indipendentemente dal fatto che capacità simili siano già o meno nelle mani degli attaccanti, il margine di manovra difensivo è più breve di quanto lasciasse intendere l’annuncio del 7 aprile.

Mythos è arrivato in un mondo che stava già andando in questa direzione. Il Global Threat Report 2026 di CrowdStrike ha documentato nel 2025 un aumento dell’89% su base annua degli attacchi abilitati dall’AI. Questa tendenza era precedente a Mythos.

Chiamiamola apocalisse delle patch. Quella operativa, concreta: il volume e la cadenza delle CVE pubbliche con patch disponibili stanno per superare il modo in cui oggi lavora la maggior parte dei team IT e di sicurezza.

Il NIST sta già subendo gli effetti dell’apocalisse delle patch. Ad aprile, l’agenzia ha annunciato un importante cambiamento nelle operazioni del National Vulnerability Database (NVD) in risposta a un aumento del 263% delle segnalazioni. Il NIST non fornirà più un arricchimento dettagliato per tutte le vulnerabilità inviate e lo farà invece solo per quelle che soddisfano criteri di rischio elevato, come le vulnerabilità presenti nel catalogo CISA Known Exploited Vulnerabilities o quelle che interessano software governativo critico. Il NIST farà affidamento sulle CVE Numbering Authorities (CNA), come Ivanti, anziché condurre una propria valutazione indipendente.

Dall’annuncio, ho sentito tre versioni della stessa risposta da clienti e colleghi. Tutte e tre sono varianti di un programma pensato per un mondo più lento.

“Abbiamo uno scanner di vulnerabilità”

Qualys, Rapid7 e Tenable svolgono bene l’attività di discovery delle vulnerabilità. Gli scanner individuano, segnalano, assegnano punteggi ed elencano. Distribuzione, verifica, gestione dei riavvii e rollback sono fuori dal loro ambito. Quel lavoro deve comunque essere svolto da qualche parte. Nella maggior parte dei programmi avviene in uno strumento separato, con un team separato, seguendo una cadenza separata.

Con la finestra di exploit ormai misurata in ore e la coda di Glasswing destinata quasi a raddoppiare il backlog, uno scanner che produce 587 vulnerabilità critiche e passa l’elenco a un team umano diventa una responsabilità. La scelta pratica è collegare lo scanner che già possiedi a un motore di remediation in grado di agire automaticamente sui risultati. Una piattaforma di gestione autonoma degli endpoint (AEM), con distribuzione ad anelli e rollback, e intelligence sulle vulnerabilità per fornire un contesto basato sul rischio a supporto di decisioni di remediation efficienti, così l’elenco si riduce senza che siano gli esseri umani a prendere ogni decisione.

“Gestiamo le approvazioni tramite il nostro sistema di ticketing”

A proposito di esseri umani che devono prendere decisioni… I lunghi processi di approvazione lineari rallenteranno in modo significativo la remediation. Quand’è stata l’ultima volta che hai dovuto decidere se distribuire l’ultimo aggiornamento del sistema operativo o del browser?

Le organizzazioni sanno già che distribuiranno questi aggiornamenti. Spesso il processo di approvazione è dovuto a complesse dinamiche interne e a un disallineamento sugli obiettivi di sicurezza. Il risultato? Un processo molto lineare che richiede lo scanner di vulnerabilità citato in precedenza, un analista che approvi ciò che sai già debba essere fatto, ticket inviati ai responsabili di business per l’approvazione e lasciati nelle caselle di posta in attesa, e in definitiva tempo prezioso sprecato per una decisione che era sostanzialmente già chiara e non doveva essere presa.

Il passaggio del mercato all’Exposure Management affronta questo processo in modo molto diverso, concentrandosi sulla definizione della propensione al rischio di un’organizzazione e sul monitoraggio della postura di rischio. La prossima volta che verrà rilasciato un aggiornamento del sistema operativo Windows, saprai già che lo distribuirai, con quale pianificazione lo farai e con quali SLA e metriche di conformità misurerai il successo. Quello che vuoi davvero sapere è:

1. Devo muovermi più rapidamente perché l’aggiornamento include vulnerabilità note sfruttate attivamente?

Oppure

2. L’aggiornamento sta impattando le operazioni e dobbiamo rallentare (per fortuna la piattaforma di Autonomous Endpoint Management include la distribuzione ad anelli con rollback)?

“Abbiamo Intune”

Microsoft Intune presenta due limiti di ambito che qui contano.

In primo luogo, gestisce solo i dispositivi registrati. Gli endpoint non registrati e non gestiti — server, laptop di collaboratori esterni, shadow IT, dispositivi edge trascurati — restano completamente fuori dalla sua visibilità. Nei periodi di aumento del volume di vulnerabilità, questi punti ciechi si moltiplicano più rapidamente di quanto i team possano gestire manualmente.

In secondo luogo, sebbene Intune semplifichi la distribuzione e gli aggiornamenti delle applicazioni, la copertura delle applicazioni di terze parti e la profondità della prioritizzazione sono più limitate di quanto la maggior parte degli amministratori immagini. Intune può dirti cosa non è aggiornato, ma non cosa aumenta davvero la tua esposizione––costringendo i team ad applicare patch a tutto in modo reattivo, oppure basandosi su ipotesi quando il tempo è poco.

La maggior parte degli ambienti enterprise non è esclusivamente Windows, completamente registrata o basata su uno stack applicativo ridotto e omogeneo. Quando le divulgazioni di vulnerabilità aumentano improvvisamente, instradare il patching lascia lacune e si trasforma in un rischio sistemico.

Mantieni Intune. Affiancalo a un livello di discovery e remediation che trovi gli asset che Intune non riesce a vedere, dia priorità alle vulnerabilità più importanti e applichi le patch con fiducia nelle applicazioni che Intune non copre.

Cosa fare

L’automazione è il modello operativo. Deve essere integrata nel workflow.

I professionisti conoscono questo principio da tempo. Si manifesta in tre aree:

Triage continuo. Le vulnerabilità note sfruttate attivamente possono seguire un percorso di risposta zero-day, soprattutto nelle aree meno sicure dell’organizzazione, come i sistemi degli utenti finali. Inoltre, definisci applicazioni specifiche, come browser e app di telecomunicazione, da aggiornare su un percorso prioritario controllato settimanalmente o anche quotidianamente. Tutto il resto può attendere la finestra di manutenzione ordinaria.
Distribuzione ad anelli con rollback automatizzato. Anello di test, anello early adopter, produzione estesa, sistemi mission-critical. La sequenza è poco entusiasmante, ma funziona per la maggior parte delle attività di manutenzione. Ciò che è cambiato è che alcuni aggiornamenti dovranno essere compressi per rientrare nella finestra di exploit, anziché attendere la manutenzione mensile. L’anello di test deve essere automatizzato e strumentato: una checklist umana non può muoversi a quella velocità.
Verifica a ciclo chiuso. La patch non è distribuita finché non viene verificata l’installazione sull’endpoint, e la CVE non viene chiusa finché una nuova scansione non lo conferma. La maggior parte dei team salta questo passaggio, ed è per questo che la prova di conformità diventa un’emergenza la settimana prima dell’audit. È per questo che questa settimana abbiamo rilasciato la conformità continua nella nostra piattaforma: così le evidenze di conformità vengono prodotte in modo continuo e automatico man mano che le patch vengono distribuite, mentre l’automazione gestisce le decisioni di prioritizzazione per cui la maggior parte dei team non ha capacità disponibile.

Le 271 vulnerabilità di Firefox individuate da Mozilla sono un’anticipazione. Ogni principale vendor software sotto Glasswing sta per iniziare a correggere più vulnerabilità e a un ritmo accelerato, e gli attaccanti con la stessa classe di capacità cercheranno esattamente quelle aperture ogni volta che avranno accesso a un modello simile. La conseguente corsa agli armamenti basata sull’AI avrà un effetto diretto sul numero e sulla frequenza degli aggiornamenti che le organizzazioni dovranno gestire con attività di remediation, e a un ritmo accelerato. L’automazione è ciò che consente a un programma di reggere. I team che ancora applicano patch solo su base mensile si troveranno ad affrontare un periodo difficile.

Se gestisci un programma IT o di sicurezza, vale la pena fare ora un’autovalutazione. Prendi l’ultima patch critica che hai distribuito. Ancora meglio: se uno zero-day uscisse di venerdì, riusciresti a risolverlo entro lunedì? Misura il tempo dalla pubblicazione della CVE all’installazione verificata sull’ultimo endpoint. Se quel numero si misura in settimane, l’apocalisse delle patch ti raggiungerà.

Sovranità digitale e cloud sovrano: proteggere i dati cloud dell’UE per la resilienza operativa

Fri, 17 Apr 2026 12:30:01 Z

La protezione tradizionale dei dati seguiva un principio semplice: i dati archiviati nel Paese A sono protetti dalle leggi del Paese A; i dati archiviati nel Paese B sono protetti dalle leggi del Paese B. Ma nell’economia globale di oggi, il luogo in cui i dati risiedono fisicamente non determina più quali governi possano richiederne l’accesso.

L’infrastruttura cloud ha introdotto una nuova complessità giurisdizionale. L’ubicazione fisica dei data center, la nazionalità della sede centrale del provider cloud e l’entità che controlla le operazioni possono generare rivendicazioni giurisdizionali concorrenti, consentendo potenzialmente a più governi di richiedere l’accesso agli stessi dati.

Che cos’è la sovranità digitale?

Questa sfida ha un nome: sovranità digitale. La sovranità digitale è il principio in base al quale le organizzazioni mantengono il controllo completo dei propri dati nel quadro giuridico della giurisdizione di appartenenza. Questo concetto è diventato una necessità per la resilienza organizzativa, mentre le aziende operano in un contesto geopolitico più frammentato e caratterizzato da minore fiducia. Le organizzazioni private e pubbliche hanno bisogno di un accesso sicuro a piattaforme basate sul cloud che siano conformi ai requisiti normativi locali e protette dai rischi geopolitici, noti o sconosciuti, che interessano la loro area geografica.

In che modo il CLOUD Act statunitense incide sulla residenza dei dati nell’UE

Il CLOUD Act statunitense del 2018 (Clarifying Lawful Overseas Use of Data) ha ulteriormente rafforzato queste preoccupazioni per le organizzazioni dell’UE. Questa legge conferisce alle autorità di contrasto statunitensi il potere di obbligare qualsiasi provider cloud con sede negli Stati Uniti a fornire dati archiviati in qualunque parte del mondo, indipendentemente dalla posizione fisica dei dati o dalla nazionalità del cliente.

Sia il CLOUD Act statunitense sia il Foreign Intelligence Surveillance Act (FISA) hanno dato motivo di preoccupazione alle aziende dell’Unione europea. Attraverso queste due normative, le autorità statunitensi potrebbero accedere ai dati contenuti nelle piattaforme cloud di qualsiasi organizzazione con sede centrale negli Stati Uniti, anche quando il data center cloud si trova in un altro Paese.

Per le aziende con sede nell’UE, l’utilizzo di strumenti statunitensi comporta specifici obblighi GDPR perché i dati personali escono dall’UE. Inoltre, da quando lo Scudo UE-USA per la privacy è stato invalidato (decisione nota come “Schrems II”), le aziende dell’UE hanno bisogno di altre misure di protezione. Le clausole contrattuali standard (SCC) restano valide, ma sono condizionate e complesse, poiché richiedono una valutazione caso per caso.

Da allora è stato introdotto un successivo Data Privacy Framework, ma la fiducia di fondo tra le nazioni coinvolte ha comunque dei limiti. Queste dinamiche hanno aumentato la pressione per garantire la protezione dei dati, rendendo necessarie soluzioni di cloud sovrano per assicurare la resilienza operativa.

Ivanti Neurons for MDM – Sovereign Edition: progettata per la sovranità cloud dell’UE

Per i nostri partner e clienti nell’UE, Ivanti Neurons for MDM Sovereign Edition risponde a questi requisiti attraverso un’architettura e un modello operativo radicalmente diversi. Situata in Germania e gestita in modo indipendente, questa soluzione è stata progettata per allinearsi al Cloud Sovereignty Framework della Commissione europea ed è stata valutata dall’autorevole cyberintelligence.institute, la cui valutazione esperta ha spiegato:

“Ivanti Sovereign Cloud dimostra un elevato livello di controllo europeo nelle aree dell’elaborazione dei dati, della sicurezza e della governance della conformità. Nella sua configurazione attuale, Ivanti Sovereign Cloud raggiunge almeno la certificazione SEAL 2, il che significa che la sovranità dei dati è garantita in tutte le aree. Inoltre, Ivanti Sovereign Cloud soddisfa i requisiti per la certificazione SEAL 3 in molte aree rilevanti, conseguendo così la resilienza digitale.”

È possibile leggere la valutazione tecnica completa per saperne di più.

Raggiungere la conformità alla sovranità dei dati con fiducia

Neurons for MDM – Sovereign Edition – EU offre alle aziende europee una base strategica per la loro piattaforma IT e di sicurezza, fornita da un leader affidabile, mantenendo al contempo le protezioni giurisdizionali locali per la gestione del rischio. Ciò significa che le entità pubbliche e private possono proseguire la propria trasformazione digitale con la certezza che i dati nel cloud resteranno sicuri e che le loro operazioni acquisiranno maggiore resilienza.

Prossimi passi? Leggi il nostro whitepaper Il cloud sovrano come necessità strategica per le organizzazioni europee per scoprire in che modo Ivanti Neurons for MDM Sovereign Edition raggiunge e supera la certificazione SEAL 2 e offre l’architettura di cloud sovrano di cui le organizzazioni europee hanno bisogno per mantenere la sovranità dei dati, abilitando al contempo una trasformazione digitale sicura.

Trusted Ownership: come Ivanti Application Control va oltre l'allowlisting

Wed, 25 Feb 2026 14:25:15 Z

Il controllo applicazioni è uno di quei temi di sicurezza su cui molte persone conservano vecchie convinzioni. L'allowlisting tradizionale sembra sicuro, ma diventa rapidamente un onere di manutenzione. Il blocklisting appare reattivo e incompleto. E se strumenti come Microsoft AppLocker hanno portato molti a credere che un allowlisting rigoroso sia lo standard di riferimento, gli attacchi moderni hanno dimostrato il contrario. Gli attaccanti si affidano sempre più a strumenti legittimi e firmati — utilizzati nel contesto sbagliato — per aggirare completamente i controlli basati su elenchi.

Quando quindi le organizzazioni valutano Ivanti Application Control o Ivanti Neurons for App Control e incontrano Trusted Ownership, inizialmente potrebbe sembrare simile al blocklisting, perché sono possibili blocchi espliciti. In realtà, Trusted Ownership è un modello di applicazione molto più ampio e molto più leggero dal punto di vista operativo, ispirato alla provenienza, che controlla l'esecuzione in base all'origine, non solo all'identità.

Invece di gestire elenchi in continua crescita, applica la sicurezza in base a chi ha inserito il software nel sistema, allineandosi in modo naturale alle moderne pratiche di distribuzione del software e ai principi zero trust. È più corretto considerarlo non come un ulteriore meccanismo basato su elenchi, ma come un modello di applicazione ispirato alla provenienza che controlla l'esecuzione in base all'origine, non solo all'identità.

Questo cambio di prospettiva porta a una domanda più efficace per il controllo applicazioni moderno: non solo che cosa sia un file, ma come sia arrivato lì.

Oltre gli elenchi: perché il controllo della provenienza oggi è importante

La domanda su come un file sia arrivato sul sistema è al centro del controllo della provenienza. Invece di considerare attendibili i file solo in base a editore, percorso o hash, il controllo della provenienza valuta l'origine e il processo che li hanno introdotti. Chi ha scritto il file su disco? Attraverso quale meccanismo? L'installazione ha seguito un workflow IT controllato? Questa valutazione sposta il controllo applicazioni dalla fiducia nell'oggetto alla fiducia nel processo, creando un perimetro di sicurezza molto più solido.

In Ivanti Application Control, il controllo della provenienza viene implementato come Trusted Ownership. Qualsiasi file inserito da un proprietario attendibile viene consentito; qualsiasi elemento introdotto da un utente viene negato per impostazione predefinita. Questo vale in modo coerente per eseguibili, DLL, programmi di installazione e script. Poiché identità come SYSTEM, TrustedInstaller e Administrators sono attendibili per impostazione predefinita, il software distribuito tramite canali di deployment standard come MS Intune, MECM, Ivanti Endpoint Manager (EPM) o altri strumenti enterprise viene eseguito immediatamente, senza manutenzione delle regole o eccezioni.

Questo rappresenta una rottura fondamentale rispetto all'allowlisting classico. Le regole di AppLocker dipendono da definizioni esatte di editore, percorso o hash. Non valuta l'origine dell'installazione e non considera automaticamente attendibili i meccanismi di deployment. Il software distribuito da Intune richiede comunque una regola di autorizzazione preesistente, spesso basata su impostazioni predefinite ampie che consentono le directory Program Files o Windows.

Questa distinzione è importante perché gli attacchi moderni trasformano sempre più spesso strumenti legittimi in armi, usandoli in contesti impropri. Il controllo della provenienza neutralizza gran parte di questo rischio applicando la fiducia a come arriva il software, non solo a che cosa sia. Si allinea ai principi zero trust, riduce l'esposizione della supply chain e restringe drasticamente, per impostazione predefinita, le opportunità di abuso Living off the Land (LotL).

Una volta compresa l'importanza dell'origine, la domanda successiva diventa: come applicarla su larga scala?

La risposta: applicare la provenienza in modo coerente a tutti i modi in cui il software viene eseguito e a tutti i modi in cui viene distribuito.

Oltre le blocklist: una copertura ampia progettata per il deployment software moderno

Il controllo della provenienza sposta la sicurezza applicativa dalla gestione di elenchi interminabili alla convalida del processo con cui il software arriva sul sistema. Una volta adottata questa prospettiva, diventa chiaro che Trusted Ownership non è un approccio basato su blocklist. È un perimetro di fiducia basato sull'origine, che si comporta in modo molto diverso dall'allowlisting tradizionale.

Un equivoco comune è che Trusted Ownership assomigli al blocklisting perché gli amministratori a volte aggiungono regole di negazione mirate per strumenti Windows noti. In pratica, queste regole di negazione sono misure di hardening difensivo contro le tecniche Living off the Land. Ogni metodo serio di controllo applicazioni utilizza restrizioni mirate di questo tipo. Il nucleo di Trusted Ownership è l'opposto del blocklisting. Il software distribuito tramite un processo controllato e attendibile è consentito per impostazione predefinita, mentre il contenuto introdotto dall'utente è negato per impostazione predefinita.

Un elemento di differenziazione più importante è la copertura. Molte organizzazioni che si affidano agli allowlist classici finiscono per concentrarsi quasi esclusivamente sui file eseguibili. Spesso evitano di applicare lo stesso controllo a DLL, script e pacchetti MSI perché questi tipi di file rendono la manutenzione delle regole molto più complessa. Questo crea lacune che gli attaccanti moderni sfruttano di frequente.

Trusted Ownership evita queste lacune applicando lo stesso controllo basato sull'origine all'intera catena di esecuzione. Eseguibili, DLL, script, programmi di installazione MSI e componenti correlati vengono valutati attraverso lo stesso modello di fiducia. Poiché la fiducia è determinata da chi ha introdotto il file, non servono criteri separati per ogni tipo di file. Uno script nella cartella Download, una DLL creata in una directory di build temporanea o un EXE eseguito da un profilo utente ricevono tutti lo stesso trattamento di negazione predefinita quando hanno origine al di fuori di un processo di installazione controllato.

Questo modello di fiducia si allinea inoltre in modo naturale al modo in cui le moderne piattaforme di gestione degli endpoint distribuiscono il software. Soluzioni come Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager e sistemi simili installano in genere le applicazioni utilizzando l'identità SYSTEM o un altro account di servizio attendibile.

Poiché queste identità sono già Trusted Owner, il software distribuito tramite questi canali viene eseguito immediatamente senza creare regole di autorizzazione, mantenere percorsi file o aggiornare criteri. Solo quando si utilizzano intenzionalmente account di installazione alternativi, come agenti DevOps personalizzati o installazioni tramite script nel contesto utente, è necessario identificare tale identità come Trusted Owner.

Il risultato è un modello con una copertura ampia e coerente su tutti i tipi di file rilevanti. Funziona senza interruzioni con le moderne distribuzioni software ed evita l'overhead operativo associato agli allowlist classici, che si concentrano principalmente sui file eseguibili.

Trusted Ownership colloca la fiducia non nei singoli oggetti, ma nei processi controllati attraverso cui il software viene distribuito, creando un approccio al controllo applicazioni più scalabile e più sicuro.

Il ruolo di WDAC (App Control for Business)

Microsoft mantiene due tecnologie di controllo applicazioni: AppLocker e App Control for Business (in precedenza WDAC). Sebbene entrambe esistano ancora, Microsoft è chiara sui rispettivi ruoli. AppLocker aiuta a impedire agli utenti di eseguire applicazioni non approvate, ma non soddisfa i criteri di manutenzione per le funzionalità di sicurezza moderne ed è quindi classificato come meccanismo di difesa in profondità piuttosto che come controllo di sicurezza strategico.

La direzione futura di Microsoft per il controllo applicazioni è App Control for Business e Microsoft afferma esplicitamente che AppLocker è feature-complete e non è più in sviluppo attivo, oltre agli aggiornamenti di sicurezza essenziali. Ciò significa che tutte le nuove funzionalità vengono fornite solo in WDAC e non in AppLocker.

App Control for Business introduce il concetto di Managed Installer. Questo consente a Windows di considerare automaticamente attendibili le applicazioni installate tramite piattaforme di deployment designate, come Intune o MECM. La fiducia deriva dal canale di distribuzione anziché dai singoli file, riducendo in modo significativo la manutenzione delle regole.

Questo si allinea strettamente al modello Trusted Ownership di Ivanti Application Control. Entrambi gli approcci considerano attendibile il software in base al processo controllato che lo ha installato, anziché in base ad attributi discreti dei file. Tuttavia, Trusted Ownership applica questo concetto in modo più semplice e più accessibile dal punto di vista operativo. Ivanti considera attendibili identità come SYSTEM e gli account di servizio designati, senza richiedere livelli di policy complessi, definizioni XML o competenze approfondite su WDAC.

Ivanti sente da molte organizzazioni che l'operatività di WDAC è complessa. I criteri WDAC richiedono una progettazione attenta, test prolungati in modalità audit, gestione delle eccezioni per driver e kernel e manutenzione continua di più set di criteri. Questo spesso porta le organizzazioni a combinare WDAC con AppLocker per coprire sia l'applicazione a basso livello sia il controllo quotidiano dello spazio utente, finendo per generare overhead amministrativo.

Ivanti Application Control offre un'alternativa unificata. Attraverso Trusted Ownership, Trusted Vendors e la convalida delle firme digitali, fornisce un modello di negazione predefinita basato sulla provenienza, con copertura coerente su eseguibili, DLL, script e pacchetti MSI.

Invece di mantenere due piani di controllo Microsoft con ambiti diversi, le organizzazioni gestiscono un unico criterio semplificato che applica la fiducia in base a come il software viene introdotto nel sistema. Questo consente di raggiungere molti degli obiettivi pratici che i clienti cercano di ottenere con un deployment combinato di WDAC e AppLocker, ma con minore complessità operativa e un modello di fiducia coerente.

LOLBins e controllo a livello di argomenti

Una volta stabilita una copertura ampia, il tema diventa come gestire gli strumenti legittimi già presenti su ogni macchina, che gli attaccanti amano sfruttare.

Gli attaccanti moderni spesso evitano di utilizzare malware tradizionale e si affidano invece agli strumenti già presenti su ogni dispositivo Windows. Questi strumenti Living off the Land (LOLBins) sono legittimi e necessari per le normali operazioni, il che li rende difficili da bloccare senza incidere sulla produttività. L'allowlisting tradizionale fatica in questo contesto, perché blocchi troppo ampi interrompono i workflow, mentre autorizzazioni troppo ampie lasciano pericolose lacune.

Un modello basato sulla provenienza come Trusted Ownership cambia questa dinamica. Anche se un attaccante tenta di utilizzare uno strumento integrato, il contenuto che prova a eseguire di solito non proviene da un processo di installazione attendibile. Poiché Ivanti valuta l'origine di quel contenuto, la maggior parte dei tentativi di uso improprio fallisce automaticamente. Lo strumento può essere legittimo, ma il contenuto che gli viene chiesto di eseguire non lo è, e Trusted Ownership lo blocca prima dell'esecuzione.

È importante capire non solo quali strumenti vengono eseguiti, ma anche che cosa viene chiesto loro di fare. Molti interpreti e runtime, come PowerShell, Python o Java, possono essere perfettamente sicuri in un contesto e rischiosi in un altro. Un'applicazione aziendale può basarsi su Java per avviare un processo specifico e approvato, mentre un file JAR scaricato da un utente rappresenta uno scenario completamente diverso.

Ivanti gestisce questo aspetto con un approccio a livelli. Un file JAR viene prima valutato tramite Trusted Ownership, che lo blocca immediatamente se è stato introdotto da un utente anziché tramite un processo di deployment controllato. Oltre a questo, gli amministratori possono creare semplici regole di autorizzazione che specificano esattamente quali comandi Java sono consentiti, garantendo che vengano eseguite solo applicazioni basate su Java legittime, mentre i tentativi di avviare file JAR non approvati vengono negati in modo silenzioso.

Lo stesso principio si applica anche ad altri strumenti. I criteri possono approvare il comportamento esatto di cui l'organizzazione ha bisogno, bloccando al contempo le attività che escono da quei limiti. Questo evita regole ampie e fragili e mantiene fluido il lavoro quotidiano.

Il risultato è un approccio equilibrato e moderno. Trusted Ownership blocca per impostazione predefinita i contenuti non attendibili. L'hardening mirato si allinea alle best practice governative e della community per ridurre gli abusi living off the land, mentre i controlli consapevoli dell'intento assicurano che i processi legittimi continuino a funzionare senza aprire porte agli attaccanti.

Questo approccio è strettamente allineato alle attuali linee guida della community e degli enti governativi sulla mitigazione delle tecniche living off the land. Agenzie come CISA, NSA, FBI e l'Australian Cyber Security Centre sottolineano l'importanza di ridurre le opportunità per gli attaccanti di usare strumenti integrati, controllando come vengono utilizzati e limitando i contenuti non attendibili su cui operano. Le loro linee guida congiunte evidenziano che gli attacchi LOTL dipendono dall'abuso di strumenti nativi e sottolineano la necessità di controlli che limitino questo uso improprio senza bloccare i processi di sistema legittimi.

Il modello di Ivanti riflette queste linee guida. Trusted Ownership blocca automaticamente i contenuti non attendibili su cui gli attaccanti fanno affidamento, mentre un numero limitato di restrizioni mirate interviene sul piccolo insieme di strumenti che richiede particolare attenzione.

Trusted Ownership in azione: scenari reali

Ecco alcuni esempi operativi di come Ivanti Application Control e Trusted Ownership funzionano nella pratica.

Un'applicazione portatile viene copiata nel profilo utente. Ivanti la blocca perché è di proprietà dell'utente. AppLocker la blocca solo se esistono regole corrispondenti. Senza le regole di percorso o editore corrette, il comportamento può variare.
Un allegato email avvia uno script PowerShell dalla cartella Download. Ivanti lo nega a causa della proprietà utente. AppLocker dipende dalle regole sugli script e, in caso di eventi di blocco, forza PowerShell in Constrained Language Mode, che eseguirà comunque lo script.
Abuso di strumenti del sistema operativo come rundll32 o mshta. Entrambi i modelli richiedono un hardening di negazione mirato. Ivanti lo combina con il controllo della provenienza, che in genere riduce il numero di eccezioni necessarie. AppLocker si basa su set di negazione curati e richiede una regolazione periodica.
Un aggiornamento di un fornitore distribuisce nuovi file firmati. Ivanti consente l'aggiornamento quando arriva tramite il canale di deployment attendibile grazie a Trusted Ownership. AppLocker può gestire questo caso con regole basate sull'editore, ma il riutilizzo della firma su più prodotti o percorsi di installazione insoliti spesso comporta manutenzione aggiuntiva e una fiducia più ampia del previsto.
Un utente scarica un file JAR e tenta di eseguirlo con Java. Ivanti blocca il tentativo perché il JAR è introdotto dall'utente e non supera Trusted Ownership. Se necessario, gli amministratori possono consentire solo l'invocazione approvata esatta confrontando l'intera riga di comando. AppLocker non può confrontare gli argomenti e si basa su regole di editore, percorso o hash.

Conclusione

Il controllo della provenienza sposta il controllo applicazioni da un problema di gestione a un modello di fiducia. Invece di considerare attendibili i singoli file, considera attendibile il processo con cui il software arriva su un sistema, rendendo la sicurezza sia scalabile sia praticabile.

Trusted Ownership si inserisce pienamente in questo approccio. Non è né una blocklist né un allowlist classico, ma un modello in cui il software che arriva tramite un processo IT controllato è consentito per impostazione predefinita, mentre tutto ciò che resta fuori da quel processo viene negato per impostazione predefinita. Applicando i controlli sull'origine e sulla proprietà anziché su file ad hoc, Ivanti Application Control e Ivanti Neurons for App Control si allineano molto meglio alle tecniche di attacco moderne e all'attuale distribuzione del software.

Se si continua a trattare il controllo applicazioni come un esercizio di gestione degli elenchi, l'onere amministrativo si farà sentire. Se lo si considera come un perimetro di fiducia, si ottengono scalabilità, sicurezza e praticabilità operativa.

Come i CEO vogliono che i CISO comunichino la strategia di gestione del rischio di cybersicurezza

Tue, 17 Feb 2026 13:00:01 Z

La maggior parte dei CEO sa citare i benchmark trimestrali e i ricavi fino all’ultima cifra decimale, ma se si chiede loro dell’esposizione al rischio cyber della propria organizzazione, le risposte diventano più vaghe. Non è che i CEO di oggi non si interessino alla sicurezza: la cybersicurezza è tra le principali preoccupazioni di consigli di amministrazione e team executive. Il problema è più profondo: una rottura fondamentale nel modo in cui i rischi di sicurezza vengono spiegati ai leader aziendali, che trascura il loro impatto sui risultati di business.

La maggior parte dei problemi di comunicazione tra CISO e CEO non dipende da una mancanza di competenza. Derivano da un problema noto: la maledizione della conoscenza. La maledizione della conoscenza è una sfida comune in cui gli esperti, in questo caso i responsabili della sicurezza, possono dare per scontato che tutti i presenti abbiano una comprensione di base delle informazioni e della terminologia tecnica; di conseguenza, non riescono a spiegare rischi complessi in un linguaggio semplice né a inserirli in un contesto concreto.

Il Report sullo stato della cybersicurezza 2026 di Ivanti evidenzia questa disconnessione. Quasi sei professionisti della sicurezza su dieci affermano che i loro team sono solo moderatamente efficaci nel comunicare l’esposizione al rischio alla leadership executive.

Quando CEO e CISO non parlano la stessa lingua, vulnerabilità aziendali critiche possono essere oscurate dal gergo tecnico. Quando la comunicazione si interrompe, le organizzazioni sprecano tempo e denaro in investimenti non correttamente indirizzati, mentre le lacune nella protezione passano inosservate finché una violazione non costringe ad affrontare il tema.

Con l’aumento dei livelli di minaccia, gli attacchi abilitati dall’AI diventano sempre più sofisticati e le violazioni dei dati finiscono ogni settimana sui giornali. La posta in gioco per una comunicazione chiara tra CISO e leadership executive non è mai stata così alta.

Per capire perché questo divario comunicativo persiste, dobbiamo esaminare sia le sfide fondamentali sia le metriche utilizzate per misurare il successo.

Perché la comunicazione del rischio cyber fallisce: la maledizione della conoscenza

Questa disconnessione tra CEO e CISO non è causata da una mancanza di dati. Semmai, è vero il contrario. Dal punto di vista del CEO, la sfida non riguarda l’attenzione o l’intenzione. Consiste piuttosto nel vedere dashboard, metriche, acronimi e punteggi di gravità senza comprendere l’impatto di questi risultati sull’intera azienda.

I responsabili della sicurezza devono partire dal presupposto che molti dei presenti non comprendano le implicazioni di termini come punteggi CVSS, superfici di attacco e vulnerabilità zero-day. I CEO vogliono più di dashboard piene di metriche, acronimi e punteggi di gravità.

I briefing sulla cybersicurezza devono fare un passo in più e dimostrare le implicazioni finanziarie, legali e reputazionali di questi risultati per l’azienda. Un CISO potrebbe riferire "587 vulnerabilità critiche rilevate questo mese", mentre ciò che il CEO deve davvero sapere è: "Quali di queste minacciano la nostra capacità di servire i clienti e qual è il nostro piano per affrontarle?"

I KPI di cybersicurezza che contano per i CEO

I KPI utili collegano chiaramente le attività di gestione delle vulnerabilità al rischio aziendale. Tuttavia, la nostra ricerca sulla cybersicurezza rileva che i KPI più utilizzati dai team di sicurezza non riescono a riflettere il contesto del rischio.

Attualmente, solo la metà delle aziende (51%) monitora i punteggi di esposizione alla cybersicurezza o altri indici basati sul rischio. Molti team di sicurezza si affidano ancora a metriche di processo, come il tempo medio di correzione (47%) o la percentuale di esposizioni risolte (41%).

Metriche come MTTR, velocità di applicazione delle patch e percentuale di correzioni effettuate sono importanti per i team di sicurezza, ma misurano l’efficienza operativa, non l’esposizione aziendale o il potenziale impatto finanziario. Considerate isolatamente, possono sembrare rassicuranti, pur oscurando la vera domanda: stiamo gestendo il nostro rischio in modo efficace?

Queste metriche, incentrate su rapidità e copertura, possono apparire positive da sole, ma dicono poco sul fatto che le attuali attività di correzione migliorino davvero la postura di rischio. Conta meno quanto rapidamente le vulnerabilità vengono corrette e quante ne vengono affrontate. Ciò che conta di più è se vengono affrontati i problemi giusti.

Una comprensione condivisa tra team di sicurezza, consiglio di amministrazione e C-Suite richiede di collegare metriche poco leggibili a conseguenze concrete. Per i CEO, questo significa allinearsi con il proprio CISO sui rischi più importanti per la specifica organizzazione: la vostra organizzazione è un istituto finanziario che affronta spesso schemi di frode sofisticati, rigorosi requisiti di conformità come PCI-DSS e SOX e la minaccia costante di ransomware che prendono di mira i dati finanziari dei clienti? Oppure un’organizzazione sanitaria alle prese con la protezione di una rete in espansione di dispositivi medici connessi, mantenendo al contempo rigorosi standard di conformità per proteggere i dati sensibili dei pazienti?

Illustriamo la differenza tra un briefing executive sulla sicurezza che si basa solo su metriche tecniche e uno che aggiunge contesto e impatto sul business.

Cosa dice il CISO:

"Abbiamo rilevato 11.000 vulnerabilità".
"L’MTTR è sceso da 25 a 15 giorni".
"Abbiamo raggiunto un tasso di correzione dell’88% sulle CVE critiche".

Cosa deve davvero sapere il CEO:

"Abbiamo identificato dieci vulnerabilità critiche che potrebbero avere un impatto sui sistemi che generano ricavi".
"Se venissimo attaccati oggi, potremmo ripristinare le operazioni critiche in sei ore, rispetto alle 48 ore dello scorso anno".
"Questa protezione ci consente di puntare all’espansione nell’UE senza ulteriori rischi di conformità".

Costruire un framework di propensione al rischio a livello executive

La comunicazione executive dipende da framework condivisi e da un punto di riferimento comune per definire, misurare e discutere il rischio. Per eliminare incoerenze e confusione, tutti gli stakeholder dovrebbero essere coinvolti nella creazione e nell’applicazione di un framework di propensione al rischio.

Uno degli obiettivi principali di queste conversazioni è aiutare i leader aziendali a comprendere che lo scopo del programma di cybersicurezza non è essere completamente “senza rischio”: è impossibile per qualsiasi organizzazione moderna diventare completamente priva di rischi. In altre parole, i CEO devono saper distinguere tra la loro propensione al rischio e la postura di rischio.

1. Propensione al rischio: il livello di rischio che l’azienda è attualmente disposta a tollerare nel perseguimento dei propri obiettivi generali.

2. Postura di rischio: la realtà dell’attuale esposizione al rischio dell’organizzazione.

La maggior parte delle organizzazioni riconosce ormai la necessità di formalizzare il livello di rischio cyber che è disposta ad accettare. La ricerca di Ivanti mostra che oltre l’80% delle organizzazioni dispone di un framework di propensione al rischio documentato.

Tuttavia, meno della metà delle organizzazioni afferma che questi framework vengono seguiti attentamente nelle operazioni quotidiane. Quando i framework esistono sulla carta ma non guidano le decisioni effettive, è molto probabile che la propensione al rischio e la postura di rischio della vostra organizzazione non siano allineate.

In che modo la gestione dell’esposizione colma il divario comunicativo

La gestione dell’esposizione è un approccio basato sul rischio che identifica, prioritizza e convalida in modo continuo la portata delle potenziali minacce nell’intera superficie di attacco. Praticare la gestione dell’esposizione aiuta a unire responsabili della sicurezza e leader executive attorno a una strategia unica e completa, che riorienta la cybersicurezza sul rischio critico per il business.

Invece di trattare tutte le vulnerabilità come equivalenti, la gestione dell’esposizione si concentra sull’identificazione e sulla prioritizzazione dei rischi più elevati per l’organizzazione ponendo queste domande:

Quali esposizioni attuali vengono sfruttate attivamente dagli attori delle minacce?
Quali asset devono essere prioritizzati in base alle attuali operazioni aziendali?
Quali asset, se compromessi, avrebbero il maggiore impatto in termini di danni reputazionali, per i clienti o legali?

Il report di ricerca di Ivanti mostra che quasi due terzi delle organizzazioni investono oggi nella gestione dell’esposizione e che la comprensione da parte della leadership è aumentata anno su anno. Ma l’esecuzione è ancora in ritardo: solo circa un quarto delle organizzazioni valuta come eccellente la propria capacità di valutare l’esposizione al rischio.

Per colmare questo divario e rendere operativa in modo efficace la gestione dell’esposizione, i CISO dovrebbero basare la comunicazione executive su tre principi

1. Tradurre i segnali tecnici in contesto aziendale. Invece di riportare il numero di vulnerabilità, spiegate quali esposizioni incidono sui sistemi che generano ricavi, sui dati dei clienti o sugli ambienti regolamentati.

2. Prioritizzare le minacce emergenti in base all’impatto, non al volume. Gli executive non devono monitorare ogni nuova tecnica di attacco. Devono capire quali situazioni potrebbero interrompere in modo significativo l’attività aziendale e quanto l’organizzazione sia pronta a rispondere.

3. Usare scenari, non fogli di calcolo. Narrazioni basate sui dati, che collegano causa, impatto e risultato, aiutano i leader a interiorizzare il rischio e a prendere decisioni più rapide.

Questo approccio sposta la strategia di mitigazione del rischio da una difesa reattiva a un processo decisionale proattivo.

La strada da seguire

Quando executive e responsabili della sicurezza parlano la stessa lingua, la maledizione della conoscenza può essere superata e la cybersicurezza diventa un abilitatore strategico che protegge il valore aziendale, favorisce la crescita e trasforma la forza della sicurezza in vantaggio competitivo.

La maledizione della conoscenza può essere superata: una metrica tradotta, una conversazione incentrata sul business e una decisione chiara alla volta.

Gestione dell’esposizione vs. gestione delle vulnerabilità: quale consente una reale riduzione del rischio?

Thu, 29 Jan 2026 13:00:01 Z

La gestione delle vulnerabilità supporta da anni le organizzazioni e il settore della cybersecurity. È una pratica efficace che ha aiutato le aziende a difendere la propria superficie di attacco e a impedire agli autori delle minacce di sfruttare le vulnerabilità.

Ma la tecnologia e l’infrastruttura IT si sono evolute. La gestione delle vulnerabilità non è più in grado di affrontare le sfide introdotte da questa evoluzione. Ora la gestione dell’esposizione offre un approccio ancora più olistico alla sicurezza degli endpoint, coprendo le aree in cui la gestione delle vulnerabilità risulta insufficiente.

Analizziamo le differenze per aiutarti a decidere come proteggere la tua organizzazione.

Che cos’è la gestione delle vulnerabilità?

La gestione delle vulnerabilità è una pratica di cybersecurity che include l’identificazione, la valutazione, la prioritizzazione e la correzione continue e proattive delle vulnerabilità che gli hacker possono utilizzare per infiltrarsi nella tua organizzazione.

Tuttavia, è importante notare che esistono due diversi tipi di gestione delle vulnerabilità:

Gestione tradizionale delle vulnerabilità

Gestione delle vulnerabilità basata sul rischio

Consiste nel tentativo di correggere il maggior numero possibile di vulnerabilità. Questo spesso comporta un notevole impegno e aspettative di successo irrealistiche, offrendo al contempo un falso senso di sicurezza.

Una pratica evoluta di gestione delle vulnerabilità che tiene conto del rischio nella prioritizzazione delle vulnerabilità. Ciò consente alle organizzazioni di applicare patch alle vulnerabilità critiche che rappresentano una minaccia reale, proteggendo la tua organizzazione dagli autori delle minacce e garantendo al tempo stesso una solida postura di sicurezza e una gestione efficace delle risorse.

Un approccio di gestione delle vulnerabilità basata sul rischio va oltre la gestione tradizionale delle vulnerabilità, offrendo alla tua organizzazione i seguenti vantaggi:

Monitora continuamente le vulnerabilità per una sicurezza proattiva.
Identifica le esposizioni sfruttate attivamente.
Consente iniziative di correzione efficaci.
Riduce il rischio.
Aiuta le organizzazioni a raggiungere la conformità.

Sebbene la gestione delle vulnerabilità basata sul rischio copra molti aspetti, non offre ancora l’approccio olistico alla cybersecurity di cui le organizzazioni hanno bisogno per rimanere protette e sicure. È qui che entra in gioco la gestione dell’esposizione.

Che cos’è la gestione dell’esposizione?

La gestione dell’esposizione è una pratica di cybersecurity in evoluzione che offre una visibilità completa sull’intera superficie di attacco. Consente ai team IT e di sicurezza di individuare esattamente dove la tua organizzazione potrebbe essere esposta, includendo prioritizzazione basata sul rischio, correzione e molto altro. La gestione dell’esposizione si concentra sul mantenimento della propensione al rischio definita autonomamente dall’organizzazione. Comprende quindi quattro fasi:

Come la gestione delle vulnerabilità basata sul rischio, la gestione dell’esposizione aiuta a dare priorità alle vulnerabilità e alle esposizioni da affrontare per prime in base al rischio reale, ma va oltre considerando ciò che è più rilevante per il tuo specifico business. Questo approccio alla cybersecurity garantisce che le esposizioni a più alto rischio vengano corrette in modo proattivo, prima che possano essere sfruttate dagli attaccanti.

Gestione dell’esposizione vs. gestione delle vulnerabilità: qual è la differenza?

La gestione dell’esposizione rappresenta la successiva evoluzione rispetto alla gestione tradizionale delle vulnerabilità. Mentre la gestione delle vulnerabilità si concentra principalmente sull’identificazione e sulla risoluzione delle debolezze in server ed endpoint, la gestione dell’esposizione amplia questo ambito offrendo visibilità completa sull’intera superficie di attacco.

Le differenze principali includono:

La gestione dell’esposizione è progettata per tipologie di asset più recenti: gli ambienti IT moderni sono diventati sempre più complessi e oggi includono asset come applicazioni Software-as-a-Service (SaaS), dispositivi IoT, infrastrutture cloud e altro ancora. La gestione dell’esposizione è progettata per tenere conto di queste tipologie di asset più recenti, assicurando che i team IT e di sicurezza possano identificare i rischi ovunque si trovino nell’organizzazione. In questo modo, la gestione dell’esposizione offre una comprensione completa di tutti i potenziali punti di ingresso. Ciò consente alle organizzazioni di gestire e ridurre il rischio in modo più efficace che mai.
La gestione dell’esposizione comprende la realtà operativa e promuove un approccio basato sulla propensione al rischio: ancora una volta, la gestione delle vulnerabilità è incentrata sull’applicazione di patch alle vulnerabilità. Sebbene la gestione delle vulnerabilità basata sul rischio offra prioritizzazione del rischio e orchestrazione della correzione, questa pratica non riconosce che non è realistico per un’organizzazione applicare patch a ogni vulnerabilità. Il termine propensione al rischio indica la misura, definita autonomamente da un’organizzazione, del livello di rischio che è disposta ad accettare. È un approccio decisamente più realistico, che coinvolge l’intera organizzazione nel raggiungimento di KPI condivisi per misurare il successo in modo coerente tra i team.
La gestione dell’esposizione va oltre CVE e CVSS: la gestione delle vulnerabilità si concentra principalmente su vulnerabilità ed esposizioni comuni (CVE). Sebbene le CVE siano un obiettivo importante per la maggior parte delle organizzazioni, non sono gli unici fattori che gli autori delle minacce possono usare per causare danni alla tua organizzazione. Gli hacker possono comunque sfruttare le seguenti esposizioni, non coperte dalla gestione delle vulnerabilità, per infiltrarsi nella tua organizzazione:
Configurazioni errate.
Problemi di sicurezza delle applicazioni.
Policy dei sistemi IT.
Controlli degli accessi privilegiati.

Ricollegandoci all’approccio olistico, la gestione dell’esposizione copre tutti questi asset moderni. Inoltre, la gestione delle vulnerabilità dipende fortemente dal Common Vulnerability Scoring System (CVSS) per la prioritizzazione della correzione. Sebbene il CVSS sia una valida misura della gravità, non offre una prospettiva efficace corretta per il rischio.

Il rischio è un fattore importante da tenere presente, perché include elementi come l’eventuale sfruttamento di una vulnerabilità, il suo collegamento a ransomware o malware oppure la sua attuale diffusione. Non considerare il rischio crea un falso senso di urgenza con il CVSS, portando i team IT e di sicurezza a sprecare tempo e risorse su vulnerabilità che non sono realmente urgenti.

Come proteggere la tua organizzazione

Ora che abbiamo esaminato le differenze tra gestione dell’esposizione e gestione delle vulnerabilità, è il momento di sfruttare i vantaggi offerti dalla gestione dell’esposizione. Scopri come il portfolio di gestione dell’esposizione di Ivanti può valorizzare i tuoi team IT e di sicurezza.