Revisione conservazione Security DC: storico leggibile

Che cos’è una revisione della conservazione del registro Security dei DC?

Una revisione conservazione Security DC stabilisce quali eventi Security un investigatore può ancora leggere da ciascun controller di dominio, dai suoi archivi e dalla destinazione centrale dei log. Il risultato utile è una raccolta di evidenze datata e collegata a una politica approvata dall’organizzazione. Una dimensione massima del file configurata, un vecchio evento o una connessione di inoltro funzionante costituisce solo una parte di tale raccolta.

Tre domande richiedono risposte separate: gli eventi necessari sono stati generati, sono ancora leggibili localmente e il sistema centrale previsto li ha ricevuti e conservati? Iniziate dalle verifiche dei criteri di controllo effettivi per la generazione degli eventi. Quella guida usa auditpol per esaminare le impostazioni di controllo; questa revisione riguarda lo storico leggibile, il comportamento del canale, gli archivi e la prova di una copia centrale.

Questa procedura riguarda i controller di dominio Active Directory e i relativi canali Windows Security. Non valuta la conservazione dei log di audit di Microsoft Entra. I comandi seguenti sono esempi basati sulla documentazione per operatori Windows autorizzati; non sono stati eseguiti su un dominio di un cliente per questo articolo. La documentazione e il comportamento del collector sono stati esaminati il 4 ottobre 2026.

Come funzionano la capacità del canale e la modalità di conservazione

Microsoft documenta tre comportamenti rilevanti tramite wevtutil: con la conservazione disabilitata, i nuovi record sovrascrivono i più vecchi quando viene raggiunta la capacità; con la conservazione abilitata e il backup automatico disabilitato, i record esistenti rimangono e quelli in arrivo vengono scartati quando il log è pieno. Il backup automatico richiede la conservazione abilitata e salva il log quando raggiunge la dimensione massima. L’impostazione /ms controlla un limite in byte, non un numero garantito di giorni. Consultate il riferimento del comando wevtutil.

Trattate ogni controller di dominio separatamente. Lo storico di un server poco attivo non può rappresentare un controller più impegnato, e un’esportazione della configurazione non sostituisce una lettura riuscita degli eventi. Conservate le impostazioni effettive insieme alle osservazioni, anziché chiudere la revisione sulla sola base delle impostazioni.

Definite la politica prima di assegnare un verdetto. Chiedete al responsabile di specificare gli insiemi di eventi, il periodo richiesto, le responsabilità locali e centrali, i requisiti di accesso e il comportamento di ripristino accettabile. Registrate la versione della politica e la relativa approvazione. La guida alla mappatura della conformità collega controlli identificati a evidenze di produzione; applicate questo approccio alla politica di conservazione effettiva, anziché inventare una durata normativa universale.

Rilevamento: acquisire evidenze datate per ogni DC

Passaggio 1: leggere la configurazione effettiva del canale Security

Eseguite questi comandi localmente su ogni DC identificato con accesso autorizzato. La loro sintassi è documentata da Learn; Security è il canale selezionato per questa procedura.

wevtutil gl Security
Get-WinEvent -ListLog Security
Get-WinEvent -ListLog Security | Format-List -Property *

Il riferimento di Get-WinEvent documenta -ListLog, le proprietà di configurazione, l’ordinamento degli eventi, -MaxEvents, -Oldest e la lettura dei log salvati tramite -Path. Acquisite LogMode, MaximumSizeInBytes, FileSize, RecordCount, IsLogFull e LogFilePath quando vengono restituiti. Conservate l’output grezzo, l’identità dell’host, l’ora di raccolta con fuso orario, l’operatore e l’esito del comando.

Non escludete silenziosamente un DC perché una lettura non riesce. Conservate l’errore e classificate le sue evidenze come non disponibili in attesa di un’indagine. Un errore di autorizzazione, un risultato vuoto e un log letto correttamente sono esiti diversi. Il registro della revisione deve rendere tutti e tre visibili al responsabile.

Passaggio 2: leggere entrambe le estremità della sequenza di eventi disponibile

Get-WinEvent -LogName Security -MaxEvents 1 -Oldest |
    Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName
Get-WinEvent -LogName Security -MaxEvents 1 |
    Select-Object MachineName, LogName, TimeCreated, RecordId, Id, ProviderName

L’ordine predefinito parte dagli eventi più recenti; -Oldest lo inverte. Conservate i timestamp e le identità restituiti senza presumere che dimostrino una copertura ininterrotta. Uniformate la rappresentazione dei fusi orari prima di confrontare le fonti. Queste letture limitate identificano le estremità della sequenza disponibile, anziché calcolare i timestamp minimo e massimo su tutti i record.

Ai fini della revisione, annotate l’estensione osservata e i suoi limiti. Se il primo record leggibile è successivo al punto iniziale richiesto dalla politica, verificate se un archivio o una copia centrale approvata fornisce lo storico mancante. Se è precedente a quel punto, continuate a verificare gli insiemi di eventi richiesti e le interruzioni note. Un timestamp antecedente, da solo, non può dimostrare la completezza.

Passaggio 3: registrare le evidenze e la relativa decisione

Usate una riga per DC, poi righe collegate per gli archivi e le destinazioni centrali. Evitate una sola cella di esito positivo o negativo per l’intero dominio che nasconda un server inaccessibile. La tabella seguente propone un registro delle evidenze; non rappresenta un output misurato:

Chiedete al revisore di distinguere una carenza dimostrata da una domanda senza risposta. Un archivio illeggibile è una lacuna di evidenza anche se il file esiste. Una query centrale che omette un DC è un test incompleto anche se la destinazione restituisce molti record da altri server. Preservate queste distinzioni nel ticket di correzione.

Verificare gli archivi e la copia centrale

Un inventario degli archivi deve portare a letture effettive. Adattate questa sintassi documentata di -Path a ciascuna posizione approvata degli archivi Security; il percorso seguente è un esempio, non un file individuato.

Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1 -Oldest
Get-WinEvent -Path 'C:\ApprovedArchives\Security.evtx' -MaxEvents 1

Registrate gli errori insieme alle letture riuscite. Cercate poi negli archivi gli insiemi di eventi e i periodi richiesti dalla politica. Un campione leggibile ai limiti dimostra solo che quei record possono essere aperti; la revisione richiede ancora una ricerca esplicita che copra le domande pertinenti per l’indagine.

Per WEC o un’altra destinazione dei log, selezionate eventi di origine noti e individuate i relativi record centrali. Conservate il computer di origine, il canale, il provider, l’identificatore dell’evento, il timestamp e i dati dell’evento pertinenti per il confronto. Documentate qualsiasi trasformazione nella pipeline di acquisizione, anziché presumere che un numero di record assegnato dalla destinazione sia quello del record di origine.

Separate la ricezione dalla possibilità di ricerca. Il pacchetto di evidenze deve mostrare la destinazione centrale di acquisizione e la query usata da un investigatore, inclusi filtri, intervallo temporale e risultato. Un record visibile in un log di ricezione ma non disponibile attraverso il percorso di ricerca approvato lascia una lacuna pratica nell’indagine. Viceversa, un campione centrale trovato correttamente non certifica ogni record né ogni DC.

Correzione: rispettare la politica approvata e testare il ripristino (Remediation)

Passaggio 1: risolvere la lacuna specifica

Scegliete la modifica in base alle evidenze: capacità locale, gestione del log pieno, accesso agli archivi, ambito della sottoscrizione, archiviazione centrale o pipeline di ricerca. Assegnate un responsabile e un passaggio di verifica. Le decisioni su dimensione e modalità richiedono il volume di eventi previsto e lo scenario di interruzione per quell’ambiente; questo articolo non prescrive un limite universale in byte né un periodo universale di conservazione.

Prima di modificare un canale, preservate la configurazione attuale e le evidenze richieste. Applicate la configurazione approvata attraverso il processo gestito del team, poi ripetete le letture della configurazione e degli eventi. Registrate sia l’impostazione prevista sia il risultato osservato. Non cancellate un log Security per far scomparire un vecchio problema di conservazione, e non considerate un’impostazione di capacità maggiore come prova che lo storico precedentemente perso sia tornato.

Passaggio 2: esaminare le impostazioni documentate di consegna WEF

La guida Microsoft a WEF per il rilevamento delle intrusioni spiega che WEF legge gli eventi già presenti nei canali; non ne abilita la generazione e non ridimensiona il log di origine. Il log locale conserva gli eventi nel buffer durante la disconnessione. La sovrascrittura può perdere eventi senza una notifica di lacuna a WEC. La guida documenta anche segnalibri, segnali di attività, l’opzione di leggere gli eventi esistenti e impostazioni di consegna personalizzate.

Questi sono i parametri di esempio di Microsoft, da esaminare da una shell con privilegi elevati per una sottoscrizione di test approvata su WEC; non sono raccomandazioni di dimensionamento per la produzione:

Wecutil ss "testSubscription" /cf:Events
Wecutil ss "SubscriptionNameGoesHere" /cm:Custom
Wecutil ss "SubscriptionNameGoesHere" /dmi:1
Wecutil ss "SubscriptionNameGoesHere" /dmlt:10

/cf:Events seleziona il formato degli eventi; /cm:Custom seleziona la consegna personalizzata; /dmi imposta il numero massimo di eventi per consegna, mentre /dmlt imposta la latenza massima di consegna in millisecondi. Sostituite i nomi di esempio solo dopo aver esaminato la sottoscrizione prevista. Leggere gli eventi esistenti può raccogliere lo storico disponibile; non può ricreare eventi sovrascritti o mai generati.

Passaggio 3: convalidare un’interruzione approvata

Pianificate un test controllato con il responsabile del monitoraggio, un ambito definito, una condizione di arresto e una procedura di ripristino. Scegliete attività innocue già coperte dalle impostazioni di controllo e dalla sottoscrizione richieste. Registrate gli eventi di origine corrispondenti prima, durante e dopo l’interruzione. Specificate in anticipo quali record dovranno essere ricercabili centralmente e quando il team li valuterà.

Ripristinate la raccolta, poi verificate quei record attraverso il percorso centrale di ricerca approvato. Conservate le evidenze di origine, la cronologia dell’interruzione, le impostazioni della sottoscrizione, i risultati centrali e gli errori. Esaminate le discrepanze anche se la connettività è stata ripristinata. Segnalate esplicitamente ogni intervallo mancante e identificate se gli archivi rimasti o un’altra copia approvata possono fornirlo.

Passaggio 4: chiudere la revisione delle evidenze

La chiusura deve identificare esattamente ciò che è stato valutato: i DC inclusi, gli eventi richiesti, il periodo della politica, lo storico locale disponibile, gli archivi, la destinazione centrale e il percorso di ricerca. Allegate le eccezioni irrisolte con responsabile e data di revisione. Se il test ha coperto solo un controller o alcuni eventi selezionati, dichiarate tale ambito e pianificate le verifiche rimanenti.

Mantenete le evidenze datate. Ripetete la revisione dopo modifiche che interessano i DC inclusi, la configurazione dei log, gli archivi o la raccolta centrale. L’attività di manutenzione utile consiste nell’aggiornare le prove sottostanti e indagare sulle discrepanze, anziché copiare il verdetto precedente in un nuovo rapporto.

Come EtcSec rileva questo problema

In etc-collector al commit 9f698083354a1cb7f625df5cb490a515823c3257, AUDIT_LOG_RETENTION_SHORT emette un rilievo Info con un Count=1 costante. Il suo Detect() non legge alcun campo di DetectorData e restituisce il promemoria anche senza dati dei DC. Non misura né la capacità dei log né la conservazione leggibile, e non può distinguere un ambiente conforme da uno carente né passare automaticamente al verde dopo la correzione.

Il percorso di raccolta AD esaminato recupera gli oggetti della directory e i dati GPO tramite LDAP; questo detector non invoca alcun provider dei log eventi e non legge alcun canale Security locale. Usate il promemoria per richiedere le evidenze per DC descritte sopra, non come prova di una carenza nella conservazione.

Registrate la revisione manuale e la decisione approvata insieme al promemoria. Mantenete le prove dello storico leggibile e i risultati delle ricerche centrali a disposizione del responsabile che accetta la chiusura.