Endpoint Protection ed EDR restano indispensabili, ma rispondono a una domanda diversa da quella a cui risponde l'Application Control. Un EDR osserva cosa succede dopo che un processo è partito; l'Application Control decide, prima che parta, se quel processo ha il permesso di eseguire. Non sono due modi di fare la stessa cosa: sono due livelli di controllo complementari.
Chi osserva, chi decide, cosa copre, dove si integra
| Criterio | EDR/XDR | Application Control |
|---|---|---|
| Chi osserva | Comportamento a runtime: process tree, syscall, traffico, artefatti post-esecuzione | Identità del componente prima dell'esecuzione: publisher, firma, certificato, hash, percorso |
| Chi decide | Il motore di detection, in base a euristiche e comportamento osservato dopo l'avvio | La policy, definita a priori da chi gestisce la sicurezza, prima che il processo parta |
| Cosa copre | Ransomware behavior, C2, movimento laterale, tecniche note e anomale a runtime | RMM non autorizzati, driver vulnerabili (BYOVD), LOLBAS, software dual-use non ammesso |
| Dove si integra | Post-esecuzione, con SIEM/SOC per correlazione, escalation e incident response | Pre-esecuzione, con Intune/GPO/Configuration Manager per la distribuzione delle policy |
Il caso VEN0m: perché un EDR "aggiornato" non basta da solo
Il ransomware VEN0m ha mostrato in laboratorio quanto il percorso dei driver vulnerabili possa diventare critico. Ransom-ISAC ha documentato una chain in cui Windows Defender non ha interrotto l'attacco, mentre un EDR commerciale non identificato ha bloccato il driver vulnerabile circa 127 millisecondi dopo la scrittura, impedendo le fasi successive.
Il punto utile per una strategia Application Control non è attribuire quel test a un prodotto specifico - il report Ransom-ISAC non identifica il vendor dell'EDR che ha fermato il driver - ma osservare il controllo che ha fatto la differenza: impedire l'uso del driver vulnerabile prima che diventasse un primitive kernel-level. Il payload era lo stesso in entrambi gli scenari: la differenza non stava nella capacità di detection comportamentale, ma in una decisione preventiva sull'esecuzione, presa prima che il codice venisse caricato.
Vuoi vedere il caso completo? Analisi tecnica: VEN0m ransomware e attacchi BYOVD
Tre esempi concreti di cosa copre l'Application Control
RMM non autorizzati
Un tool di remote management legittimo, firmato e whitelistato da EDR e antivirus, diventa un vettore d'attacco quando non è censito né autorizzato: l'Application Control lo blocca in base alla policy, indipendentemente dal fatto che il file sia "pulito".
LOLBAS
Utility di sistema legittime (PowerShell, certutil, mshta e simili) possono essere usate fuori dal loro contesto previsto per eseguire codice, muoversi lateralmente o esfiltrare dati. Un EDR può rilevare un uso anomalo; l'Application Control può impedire l'esecuzione di quella utility in un contesto non autorizzato a monte.
BYOVD
Come nel caso VEN0m, un driver kernel firmato ma vulnerabile permette operazioni privilegiate che bypassano ogni ispezione user-mode, incluse quelle di un EDR tradizionale. Una policy che blocca il caricamento di driver vulnerabili noti chiude questo percorso prima che venga sfruttato.
Perché servono entrambi
Un EDR resta necessario per rilevare, investigare e rispondere a ciò che l'Application Control non ha (o non poteva) prevenire - comportamenti nuovi, tecniche non ancora catalogate, movimento laterale successivo a una compromissione riuscita altrove. L'Application Control riduce il numero di percorsi che un attaccante può usare per partire. Nessuno dei due sostituisce l'altro: insieme, riducono sia la superficie di esecuzione sia il tempo di risposta a ciò che riesce comunque a passare.
Valuta con Nexsys una soluzione Application Control aziendale con fase di audit, tuning ed enforcement progressivo.
