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

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.