Come primo post a poco più di un anno dal fatidico evento di CrowdStrike voglio parlare e approfondire il tema degli EDR(Endpoint Detection & Response), del loro funzionamento all’interno del kernel di Windows e dei futuri riscontri che potremo vedere in merito.
Prima di tutto però dobbiamo capire come funziona un kernel Windows, come l’EDR si interfaccia con esso e cosa permette.
Il kernel è il cuore di ogni sistema operativo, un programma fondamentale che detiene il controllo completo dell’intero sistema. La sua funzione principale è quella di fornire un accesso sicuro e controllato all’hardware per tutti i processi in esecuzione sul computer.
Per semplicità ne riporto qui la struttura:

Le principali funzioni del kernel si possono riassumere in:
- Gestione delle risorse fisiche hardware
- Gestione della catena dei processi, delle richieste da parte delle applicazioni e delle code di richieste
- Fornire un interfaccia attraverso il quale l’utente può interagire con il sistema operativo
Intel in questo ha fornito un modello di architettura che spiega ancora meglio privilegi e accessi all’interno di un sistema operativo. L’architettura va dall’interno verso l’esterno riducendo i privilegi al minimo al livello delle applicazioni.
Il modello ci spiega come al livello kernel l’accesso sia privo di restrizioni mentre al livello delle applicazioni i permessi siano ridotti al minimo(verso il kernel).
L’architettura Intel è la seguente:

All’anello 0 troviamo il kernel e i driver kernel ad esso collegati.
Al primo anello troviamo solitamente i driver dedicati ai device. Quindi i driver per l’interazione che forniscono al kernel input e output.
Al secondo anello troviamo i servizi di sistema e i servizi intermedi tra le applicazioni e il kernel.
Nel terzo anello sono presenti tutte le applicazioni del sistema ed è dove è distribuito gran parte del software che l’utente normalmente utilizza.
📓 Per approfondire ulteriormente consiglio la lettura di: https://blog.codinghorror.com/understanding-user-and-kernel-mode/
Ora che abbiamo appreso qualche informazione ulteriore sul funzionamento del kernel e sui suoi livelli, possiamo concentrarci sull’approccio che gli EDR hanno in merito. In generale gli EDR hanno dei kernel drivers, diversamente da come potremmo pensare, non lavorano nel ring 1 o 2 ma direttamente nel ring 0. La maggior parte degli EDR(CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, Sophos, Trellix, etc) lavora quindi al livello 0 come ci ha voluto dimostrare l’evento BSOD(Blue Screen Of Death) del 19 Luglio 2024, link per eventuali dettagli.
Questo approccio per gli EDR è fondamentale in quanto permette piena visibilità(memory visibility), piena capacità di risposta (un esempio è la network isolation) e un utilizzo di risorse basso perchè hanno accesso “diretto” alle risorse. Gli EDR infatti hanno capacità di identificare minacce anche a livello di boot e temono eventuali driver kernel malevoli in quanto questi possono andare a modificare o bypassare la soluzione EPP(Endpoint Protection Platform).
Proprio a causa dell’interruzione dei sistemi avvenuta lo scorso anno Microsoft a fine 2024, durante il Microsoft Ignite, è stato annunciato un cambio di paradigma e quindi la volontà di chiudere il kernel Windows a produttori software di terze parti e forzare così la sola user-mode.
La user-mode si traduce in una perdita parziale ma importante rispetto alle capacità riportate poco più sopra, anzi, ogni tipo di richiesta al sistema passerà a quel punto per le API di sistema che gestiranno la coda delle richieste rispetto anche alle altre applicazioni. Sia chiaro che alcuni prodotti EDR, per esempio CrowdStrike, presentano già delle capacità di visibilità, analisi e telemetria di dati in user-mode.
Il programma Microsoft costruito e pensato per questo cambio è il WRI (Windows Resiliency Initiative) e attualmente è privo di date o timeline, l’unico step definito è la distribuzione di una demo ai produttori di EPP nel 2025. Anche il funzionamento di questo nuovo approccio,sembra, ancora da definire, l’unico concetto esplicitato è appunto la volontà di portare i prodotti EDR esclusivamente in user-mode.
Dobbiamo però fare delle considerazioni a riguardo in quanto rispetto al feedback fornito dalle aziende di sicurezza diventa abbastanza esplicito pensare che Microsoft Defender for Endpoint (MDE per gli amici) potrebbe essere facilmente avantaggiato e qui sicuramente le organizzazioni antitrust e per la concorrenza dovranno lavorare in modo preciso e dettagliato nel gestire la situazione.
Inoltre questo cambio di approccio a cui dovranno rispondere tutti i brand potrebbe portare a risvolti davvero interessanti in metriche e analisi tecniche partendo dal MITRE ATT&CK Evaluations Tool fino alle analisi comparative( Gartner, Forrester, etc).
A livello tecnico inoltre il tema diventa ancora più ampio perchè le telemetrie dei prodotti cambieranno, le funzionalità di protezione necessiteranno un cambio di approccio e/o di visione e i prodotti potrebbero riportare i rallentamenti “classici” dei vecchi prodotti antivirus nelle attività di analisi delle applicazioni.
Il cambio di paradigma potrebbe portare sicuramente a dei benefici per la produttività e la stabilità del sistema Windows, tuttavia personalmente ho la sensazione che quanto accaduto lo scorso anno venga utilizzato come capro espiatorio per ampliare la fetta di mercato di Defender senza dover pareggiare gli agli EDR ed EPP in campo tecnico.
Continuerò a seguire l’argomento e l’intenzione è sicuramente quello di monitorare i cambiamenti che accadranno nel panorama EDR in futuro.
Resources and credits:
- https://www.cs.ru.nl/masters-theses/2025/J_Jagt___Analysis_of_Windows_Secure_Kernel_security_bugs.pdf
- https://www.techtarget.com/searchenterprisedesktop/tip/Understanding-Windows-kernel-structure-and-why-it-matters
- https://it.wikipedia.org/wiki/Kernel
- https://en.wikipedia.org/wiki/Protection_ring
- https://www.crowdstrike.com/wp-content/uploads/2024/07/CrowdStrike-PIR-Executive-Summary_it-IT-1.pdf