Audit ricorrente di Active Directory: perché gli audit annuali diventano obsoleti e come monitorare la postura in continuo

Un audit ricorrente di Active Directory dovrebbe significare molto più che rieseguire la stessa lista di controllo una volta all'anno. Active Directory è un piano di controllo vivo: l'appartenenza ai gruppi privilegiati cambia, le ACL derivano, le GPO vengono modificate, i template di certificato evolvono e la copertura di logging si degrada nel tempo. Una revisione puntuale annuale può ancora essere utile, ma non dice se la directory è rimasta sicura nella settimana successiva. Un modello migliore è un audit ricorrente di Active Directory: rimisurare gli stessi controlli ad alto valore con una cadenza fissa, indagare rapidamente la nuova deriva e usare ogni riesecuzione per verificare la bonifica invece di aspettare il ciclo di consulenza successivo.

Questo conta perché la directory è progettata per cambiare. Microsoft documenta eventi specifici per i cambiamenti di appartenenza ai gruppi di sicurezza, per le modifiche agli oggetti di directory e per i cambiamenti delle policy di dominio. La guida ANSSI del 2023 per gli ambienti che dipendono da Microsoft Active Directory si concentra su amministrazione sicura e segmentazione, mentre la guida ANSSI sulla registrazione di Active Directory copre raccolta e monitoraggio. Insieme supportano molto meglio un modello di revisione ricorrente di quanto faccia un report una tantum che poi finisce su uno scaffale. In pratica, le organizzazioni che mantengono AD più sano sono quelle che riesaminano ripetutamente le stesse famiglie di controlli e trattano la deriva di postura come un problema operativo, non come un acquisto annuale.

Cosa copre davvero un audit ricorrente di Active Directory

Un audit ricorrente di Active Directory non è la stessa cosa di un SIEM e non è la stessa cosa di un pentest. Si colloca tra una revisione una tantum e una rilevazione completamente event-driven. L'obiettivo è rivalutare lo stato di sicurezza strutturale della directory con una frequenza coerente con la velocità reale con cui l'ambiente cambia.

In Active Directory questo significa riesaminare almeno quattro livelli:

• identità privilegiate e appartenenza ai gruppi;
• deleghe di diritti e percorsi ACL pericolosi;
• impostazioni di sicurezza del dominio e dei controller di dominio;
• controlli di monitoraggio e recupero che determinano se sarà possibile rilevare o assorbire il prossimo incidente.

Questo perimetro è più ampio di una stretta revisione di hardening e più ristretto di una telemetria continua degli endpoint. Si tratta di rimisurare ripetutamente la superficie di attacco che continua a generare percorsi reali di compromissione negli ambienti AD: diritti di replica, delega Kerberos, postura LDAP debole, riutilizzo delle password di amministratore locale, account privilegiati obsoleti, percorsi di abuso dei certificati e punti ciechi nella policy di audit.

Perché gli audit AD point-in-time diventano presto obsoleti

Non è linguaggio di marketing. È una proprietà di come Windows e AD funzionano davvero.

Microsoft documenta che la gestione dei gruppi di sicurezza produce eventi di audit dedicati quando vengono aggiunti o rimossi membri. La stessa documentazione di audit descrive anche eventi di modifica degli oggetti di directory e eventi di cambio della policy di dominio. Questo basta a mostrare perché un PDF esportato una volta all'anno non può rappresentare a lungo lo stato della directory: gli oggetti che definiscono privilegio ed esposizione sono fatti per cambiare.

Alcuni dei punti di deriva più importanti sono operativi, non teorici:

• un utente viene aggiunto a un gruppo sensibile per un progetto e non viene più rimosso;
• un account di servizio riceve un nuovo SPN o una voce di delega troppo ampia;
• una GPO o una policy predefinita viene modificata per risolvere un problema di breve periodo e poi non viene mai ripristinata;
• l'applicazione di LDAP signing o channel binding resta più debole del previsto perché un client legacy ha bloccato il rollout;
• la copertura di LAPS cala perché nuovi server finiscono fuori dalla OU gestita o perché una nuova immagine è stata distribuita senza la policy corretta;
• i template AD CS o le ACL PKI cambiano durante lavori sui certificati;
• vecchi account amministrativi restano abilitati perché nessuno ripete la revisione degli account privilegiati dopo l'audit iniziale.

Per questo l'argomento contro le sole revisioni annuali è semplice: un audit point-in-time fotografa la directory nel giorno della raccolta. Non dice se gli stessi controlli ad alto valore tengono ancora dopo cambi di personale, progetti, migrazioni, acquisizioni, lavori PKI, modifiche a GPO o concessioni di privilegi di emergenza.

Le famiglie di controllo che vale la pena riesaminare a ogni ciclo

Un buon flusso ricorrente non rivaluta tutto con la stessa urgenza. Rivaluta i controlli che invecchiano peggio.

1. Gruppi privilegiati e account admin obsoleti

Se l'appartenenza privilegiata è uno dei modi più comuni con cui deriva la postura di sicurezza, dovrebbe essere anche una delle prime cose da rimisurare. Microsoft raccomanda esplicitamente di abilitare l'auditing di successo per la gestione dei gruppi di sicurezza proprio per vedere creazione, modifiche, cancellazioni di gruppi e nuovi membri. Questo conta perché il rischio reale raramente è "Domain Admins è sempre stato aperto a tutti". Molto più spesso è "l'appartenenza è cambiata, nessuno se n'è accorto e l'eccezione è diventata la norma".

La revisione ricorrente dovrebbe rispondere qui a domande semplici:

• chi possiede oggi appartenenza privilegiata diretta o indiretta;
• quali account privilegiati sono obsoleti o quasi inutilizzati;
• se gli account amministrativi integrati vengono usati per il lavoro quotidiano;
• se gli utenti privilegiati restano fuori da controlli di protezione aggiuntivi come Protected Users o schemi di autenticazione più forti.

È qui che Account obsoleti e sovra-privilegiati in AD diventa un tema operativo e non teorico.

2. ACL pericolose, diritti di replica e percorsi di controllo

Una directory può sembrare sana a livello di gruppi e allo stesso tempo esporre percorsi di takeover tramite ACL. Diritti di replica, WriteDACL, WriteOwner, GenericAll, diritti di auto-membership e modifiche ad AdminSDHolder sono esattamente il tipo di problemi che non dovrebbe aspettare la revisione dell'anno successivo.

Microsoft documenta il meccanismo AdminSDHolder perché gli oggetti protetti ereditano quel modello di security descriptor. Questo lo rende esattamente il tipo di oggetto del piano di controllo che merita uno scrutinio ripetuto. Se un diritto pericoloso atterra su un oggetto sensibile e vi resta per mesi, il fatto di avere avuto un audit pulito in passato diventa irrilevante.

La revisione ricorrente dovrebbe concentrarsi su:

• principal capaci di DCSync e diritti di replica fuori dallo scope previsto dei DC;
• diritti di scrittura pericolosi su utenti privilegiati, gruppi, OU, GPO e computer sensibili;
• deviazioni su AdminSDHolder e altre modifiche ACL favorevoli alla persistenza;
• percorsi di escalation legati ai certificati quando AD CS è presente.

Per questo Abuso ACL e DCSync: percorsi silenziosi verso Domain Admin non dovrebbe essere trattato come un semplice punto di reporting una tantum.

3. Delega Kerberos, Shadow Credentials e abuso dei certificati

Alcune esposizioni AD fanno poco rumore finché non vengono sfruttate. Delega Kerberos, msDS-KeyCredentialLink, mapping di certificato e diritti sui template di certificato sono esempi classici. Se li rivede solo durante una valutazione annuale, sta di fatto accettando un lungo tempo di esposizione per la prossima configurazione errata.

Questi controlli meritano una validazione ricorrente perché sono sensibili al cambiamento:

• delega non vincolata, vincolata e resource-based constrained delegation;
• esposizione a Shadow Credentials tramite msDS-KeyCredentialLink;
• weak certificate mapping o template AD CS rischiosi;
• nuove catene di abuso dei certificati introdotte da deriva nella configurazione dei template o della CA.

Esistono già approfondimenti specifici in Attacchi di delega Kerberos: da non vincolata a RBCD, Shadow Credentials: abuso di msDS-KeyCredentialLink in Active Directory, Weak Certificate Mapping in AD CS: perché l’associazione forte continua a contare e Attacchi ai template AD CS: da ESC1 a ESC8 fino a Domain Admin.

4. Postura dei controller di dominio e copertura di logging

Un flusso ricorrente deve anche ricontrollare se l'ambiente è ancora in grado di osservare il prossimo incidente. Microsoft documenta WEF come un meccanismo per inoltrare eventi selezionati a un collector e chiarisce esplicitamente che WEF è passivo: non crea gli eventi al posto suo. Se generazione degli eventi, categorie di audit, dimensioni dei log o logging PowerShell si allontanano dalla policy prevista, la visibilità si degrada anche se l'audit precedente era corretto quando è stato eseguito.

Questo significa che la revisione ricorrente dovrebbe includere:

• copertura della policy di audit sui controller di dominio;
• dimensionamento e retention del Security log;
• copertura del logging PowerShell;
• enforcement di LDAP signing e channel binding;
• requisiti di SMB signing sui DC;
• copertura WEF o altra raccolta centralizzata per gli eventi da cui dipende davvero.

Questo è il ponte pratico tra Monitoraggio della sicurezza AD: gli Event ID che contano davvero e un flusso di audit che continui a essere utile dopo il primo report.

5. Igiene delle password admin locali e deriva nel rollout di workstation e server

Alcuni finding non sono problemi "rotti per sempre". Ricompaiono perché l'infrastruttura cambia più rapidamente del rollout dello standard previsto. Windows LAPS è un buon esempio. Microsoft documenta Windows LAPS come una funzionalità di Windows che gestisce e salva automaticamente la password di un account amministratore locale. Ma l'esistenza della funzionalità non significa che l'intero parco sia oggi davvero coperto.

La revisione ricorrente dovrebbe quindi verificare:

• se LAPS è davvero distribuito con copertura sufficiente;
• se i nuovi sistemi rientrano nello scope gestito;
• se l'esposizione delle password locali privilegiate resta troppo ampia;
• se sistemi non gestiti stanno reintroducendo rischio di movimento laterale di tipo pass-the-hash.

Questo è il modello operativo descritto in Windows LAPS non distribuito: perché le password admin locali condivise contano ancora.

Una cadenza pratica che funziona meglio di una fotografia annuale

Non esiste una frequenza universale che vada bene per ogni organizzazione. La cadenza giusta dipende dal ritmo del cambiamento, dal modello amministrativo e dal fatto che AD CS, più foreste o l'identità ibrida aggiungano complessità. In pratica, un ritmo a livelli funziona meglio di una singola revisione annuale.

L'obiettivo non è creare più riunioni. L'obiettivo è ridurre il tempo tra cambiamento, misurazione e verifica.

Come trasformare questo modello in monitoraggio continuo della postura con EtcSec

È qui che il modello diventa più utile di una consegna annuale di consulenza.

Il catalogo AD attualmente pubblicato da ETC Collector elenca 340 rilevazioni distribuite su 14 categorie, con copertura che include account privilegiati, Kerberos, permessi, GPO, trust, monitoraggio e compliance, oltre a controlli ADCS e percorsi di attacco in Pro. Questo conta perché un flusso ricorrente funziona solo se llo stesso insieme di detector può essere eseguito di nuovo in modo coerente senza trasformare ogni revisione in un nuovo progetto di consulenza.

Ancora più importante: il modello di distribuzione è coerente con il flusso:

• il collector esegue l'audit di AD in modalità sola lettura via LDAP/LDAPS e SMB per SYSVOL;
• non viene apportata alcuna modifica alla directory;
• non è necessario distribuire agent sui controller di dominio;
• in modalità daemon, il collector opera come servizio persistente, interroga la piattaforma SaaS ogni 30 secondi per ricevere comandi, esegue gli audit localmente e restituisce i risultati da remoto;
• l'API espone lo stato dell'ultimo audit e supporta riesecuzioni sincrone o asincrone, esattamente ciò che serve a un flusso ricorrente.

Questo rende il prodotto più adatto a un modello di postura continua che a un PDF annuale. Il punto non è la "rilevazione in tempo reale" nel senso di SIEM. Il punto è che le stesse famiglie di controllo possono essere rimisurate ancora e ancora con poca frizione, e che la remediation può essere verificata rilanciando l'audit invece di attendere il ciclo di budget successivo.

I controlli EtcSec che contano di più in un flusso ricorrente

Un flusso ricorrente è credibile solo se si traduce in verifiche concrete. Sulla base del catalogo di vulnerabilità ETC attuale, i seguenti finding si prestano particolarmente bene a una revisione di postura ripetuta:

È questa lista che trasforma un audit in un flusso operativo. Invece di pagare ogni anno per riscoprire le stesse famiglie di controllo, il team può continuare a rivalutare prima quelle con più probabilità di derivare.

Remediation e validazione dopo ogni ciclo di correzione

Una revisione ricorrente funziona solo se ogni correzione termina con una verifica. Altrimenti il flusso ricade nel semplice tracciamento ticket senza nuova misurazione.

Dopo ogni change window, il team dovrebbe eseguire una sequenza operativa semplice:

• rilanciare lo stesso audit immediatamente dopo la modifica;
• verificare che il finding obiettivo sia scomparso dal report successivo;
• controllare se il rischio si è spostato in un'altra famiglia di controllo, per esempio da un'appartenenza privilegiata a una ACL pericolosa;
• validare che la remediation non abbia indebolito il monitoraggio, per esempio intervenendo su GPO, logging o enforcement;
• documentare le eccezioni accettate e pianificare la misurazione successiva.

Dopo ogni change window, il team dovrebbe anche riuscire a rispondere a domande di base:

• il finding indirizzato è scomparso dall'audit successivo;
• il rischio si è semplicemente spostato altrove, per esempio da un problema di appartenenza ai gruppi a un problema ACL;
• la correzione ha indebolito il monitoraggio, per esempio modificando GPO che influenzano logging o enforcement delle policy;
• un'eccezione ritenuta isolata ha creato un nuovo percorso tramite delega, diritti di replica o configurazione dei certificati;
• il punteggio di sicurezza è migliorato per la ragione giusta, cioè meno finding rilevanti e non soltanto meno oggetti scansionati.

È qui che un flusso ricorrente supera una valutazione annuale. Non serve aspettare mesi per verificare se una pulizia dei privilegi, un rollout di LAPS, un progetto di LDAP signing o un hardening di AD CS hanno davvero retto.

Dove il modello annuale di consulenza continua ad avere senso

Questo non significa che le revisioni esterne una tantum abbiano perso valore. Restano utili per revisioni architetturali profonde, incident response, validazione red team e checkpoint di governance. Ma non sostituiscono la misurazione ricorrente della directory stessa.

Un modello maturo di solito assomiglia a questo:

• revisione esterna approfondita quando architettura, confini di trust o contesto di incidente lo giustificano;
• misurazione ricorrente della postura guidata dal collector per le famiglie di controllo che derivano di più tra un ciclo e l'altro;
• follow-up mirato quando emergono nuovi finding o la remediation si blocca.

È una storia molto più solida che acquistare un audit costoso, archiviare il report e sperare che la directory resti nello stesso stato mentre amministratori, progetti e modifiche urgenti continuano a rimodellarla.

Come EtcSec distingue tra un report e un flusso operativo

EtcSec è più utile quando serve a trasformare la review della sicurezza AD in un ritmo operativo:

• rieseguire ripetutamente llo stesso insieme di detector;
• rendere rapidamente visibile la nuova deriva dei privilegi;
• verificare i cambiamenti di hardening dopo ogni rollout;
• mantenere ADCS, Kerberos, ACL e postura di monitoraggio nello stesso ciclo di revisione;
• gestire il processo dal SaaS lasciando la raccolta all'interno della rete del cliente.

Questa è la differenza importante. Un audit ricorrente di Active Directory non significa semplicemente "audit più frequenti". Significa passare da una assurance occasionale a monitoraggio continuo della postura attraverso misurazioni ripetute e a bassa frizione.

Riferimenti primari

• Microsoft Learn - Audit Security Group Management
• Microsoft Learn - Event 5136: A directory service object was modified
• Microsoft Learn - Event 4739: Domain Policy was changed
• Microsoft Learn - LDAP signing for Active Directory Domain Services on Windows Server
• Microsoft Learn - Windows LAPS overview
• Microsoft Learn - AdminSDHolder (MS-ADTS)
• Microsoft Learn - Use Windows Event Forwarding to help with intrusion detection
• ANSSI - Recommandations pour l'administration sécurisée des SI reposant sur AD
• ANSSI - Sécuriser la journalisation dans un environnement Microsoft Active Directory