Revue de conservation Security DC : historique lisible

Qu’est-ce qu’une revue de conservation du journal Security des DC ?

Une revue de conservation Security DC établit quels événements Security un enquêteur peut encore lire sur chaque contrôleur de domaine, dans ses archives et dans la destination de journalisation centrale. Le résultat utile est un dossier de preuves daté, rattaché à une politique approuvée par l’organisation. Une taille maximale de fichier configurée, un ancien événement ou une connexion de transfert fonctionnelle ne constitue qu’une partie de ce dossier.

Trois questions demandent des réponses distinctes : les événements requis ont-ils été générés, sont-ils encore lisibles localement et le système central prévu les a-t-il reçus et conservés ? Commencez par les contrôles de la politique d’audit effective pour la génération des événements. Ce guide utilise auditpol pour examiner les paramètres d’audit ; cette revue porte sur l’historique lisible, le comportement du canal, les archives et la preuve d’une copie centrale.

Cette procédure couvre les contrôleurs de domaine Active Directory et leurs canaux Windows Security. Elle n’évalue pas la conservation des journaux d’audit Microsoft Entra. Les commandes ci-dessous sont des exemples tirés de la documentation, destinés aux opérateurs Windows autorisés ; elles n’ont pas été exécutées sur un domaine client pour cet article. La documentation et le comportement du collecteur ont été examinés le 4 octobre 2026.

Fonctionnement de la capacité du canal et du mode de conservation

Microsoft documente trois comportements pertinents avec wevtutil : lorsque la conservation est désactivée, les nouveaux enregistrements écrasent les plus anciens quand la capacité est atteinte ; lorsque la conservation est activée et la sauvegarde automatique désactivée, les enregistrements existants restent et les nouveaux sont abandonnés quand le journal est plein. La sauvegarde automatique exige que la conservation soit activée et sauvegarde le journal lorsqu’il atteint sa taille maximale. Le paramètre /ms définit une limite en octets, pas un nombre de jours garanti. Consultez la référence de la commande wevtutil.

Traitez chaque contrôleur de domaine séparément. L’historique d’un serveur peu actif ne peut pas représenter un contrôleur plus sollicité, et un export de configuration ne remplace pas une lecture d’événement réussie. Conservez les paramètres effectifs avec les observations au lieu de clôturer la revue sur la seule base des paramètres.

Définissez la politique avant de rendre un verdict. Demandez au responsable désigné de préciser les populations d’événements, la période requise, les responsabilités locales et centrales, les exigences d’accès et le comportement de reprise acceptable. Consignez la version de la politique et son approbation. Le guide de correspondance pour la conformité relie les contrôles nommés aux preuves de production ; appliquez cette approche à la politique de conservation réelle plutôt que d’inventer une durée réglementaire universelle.

Détection : constituer un dossier daté pour chaque DC

Étape 1 : lire la configuration effective du canal Security

Exécutez ces commandes localement sur chaque DC identifié avec un accès autorisé. Leur syntaxe est documentée par Learn ; Security est le canal sélectionné pour cette procédure.

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

La référence Get-WinEvent documente -ListLog, les propriétés de configuration, l’ordre des événements, -MaxEvents, -Oldest et la lecture des journaux sauvegardés avec -Path. Capturez LogMode, MaximumSizeInBytes, FileSize, RecordCount, IsLogFull et LogFilePath lorsqu’ils sont renvoyés. Conservez la sortie brute, l’identité de l’hôte, l’heure de collecte avec son fuseau, l’opérateur et le résultat de la commande.

N’excluez pas silencieusement un DC parce qu’une lecture échoue. Conservez l’erreur et classez ses preuves comme indisponibles dans l’attente d’une investigation. Une erreur d’autorisation, un résultat vide et un journal lu avec succès sont des résultats différents. Le registre de revue doit rendre les trois visibles à son responsable.

Étape 2 : lire les deux extrémités de la séquence d’événements disponible

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’ordre par défaut commence par les événements les plus récents ; -Oldest l’inverse. Conservez les horodatages et les identités renvoyés sans supposer qu’ils prouvent une couverture ininterrompue. Harmonisez la présentation des fuseaux horaires avant de comparer les sources. Ces lectures limitées identifient les extrémités de la séquence disponible, plutôt que de calculer les horodatages minimal et maximal sur l’ensemble des enregistrements.

Pour la revue, consignez l’étendue observée et ses limites. Si le premier enregistrement lisible est postérieur au point de départ exigé par la politique, recherchez si une archive ou une copie centrale approuvée fournit l’historique manquant. S’il est antérieur à ce point, poursuivez les contrôles des populations d’événements requises et des interruptions connues. Un horodatage ancien ne suffit pas à établir l’exhaustivité.

Étape 3 : consigner les preuves et la décision associée

Utilisez une ligne par DC, puis des lignes liées pour les archives et les destinations centrales. Évitez une seule cellule de réussite ou d’échec pour tout le domaine qui masquerait un serveur inaccessible. Le tableau suivant propose un registre de preuves ; il ne présente pas des résultats mesurés :

Demandez au réviseur de distinguer une insuffisance démontrée d’une question sans réponse. Une archive illisible constitue une lacune de preuve même si le fichier existe. Une requête centrale qui omet un DC est un test incomplet même si la destination renvoie de nombreux enregistrements d’autres serveurs. Préservez ces distinctions dans le ticket de remédiation.

Vérifier les archives et la copie centrale

Un inventaire d’archives doit déboucher sur des lectures réelles. Adaptez cette syntaxe documentée de -Path à chaque emplacement d’archives Security approuvé ; le chemin ci-dessous est un exemple, pas un fichier découvert.

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

Consignez les échecs avec les lectures réussies. Recherchez ensuite dans les archives les populations d’événements et les périodes exigées par la politique. Un échantillon lisible aux bornes établit seulement que ces enregistrements peuvent être ouverts ; la revue exige encore une recherche explicite couvrant les questions pertinentes pour l’investigation.

Pour WEC ou une autre destination de journalisation, sélectionnez des événements sources connus et localisez leurs enregistrements centraux correspondants. Conservez l’ordinateur source, le canal, le fournisseur, l’identifiant d’événement, l’horodatage et les données d’événement pertinentes pour la comparaison. Documentez toute transformation dans la chaîne d’ingestion au lieu de supposer qu’un numéro d’enregistrement attribué par la destination est celui de la source.

Distinguez la réception de la possibilité de rechercher. Le dossier de preuves doit montrer la destination centrale d’ingestion et la requête utilisée par un enquêteur, avec les filtres, la plage temporelle et le résultat. Un enregistrement visible dans un journal de réception mais indisponible par le chemin de recherche approuvé laisse une lacune pratique pour l’investigation. Inversement, un échantillon central retrouvé avec succès ne certifie pas tous les enregistrements ni tous les DC.

Remédiation : respecter la politique approuvée et tester la reprise (Remediation)

Étape 1 : résoudre la lacune précise

Choisissez la modification à partir des preuves : capacité locale, gestion du journal plein, accès aux archives, périmètre d’abonnement, stockage central ou chaîne de recherche. Attribuez un responsable et une étape de vérification. Les décisions de taille et de mode exigent le volume d’événements attendu et le scénario d’interruption de cet environnement ; cet article ne prescrit aucune limite universelle en octets ni aucune période universelle de conservation.

Avant de modifier un canal, préservez la configuration actuelle et les preuves requises. Appliquez la configuration approuvée selon le processus géré de l’équipe, puis répétez les lectures de configuration et d’événements. Consignez le paramètre prévu et le résultat observé. Ne videz pas un journal Security pour faire disparaître une ancienne préoccupation de conservation, et ne considérez pas une capacité accrue comme la preuve que l’historique précédemment perdu est revenu.

Étape 2 : examiner les paramètres documentés de livraison WEF

Les recommandations Microsoft sur WEF pour la détection d’intrusions expliquent que WEF lit les événements existants des canaux ; il n’active pas leur génération et ne redimensionne pas le journal source. Le journal local met les événements en tampon pendant la déconnexion. L’écrasement peut perdre des événements sans notification de lacune à WEC. Le guide documente également les signets, les signaux de présence, l’option de lecture des événements existants et les paramètres de livraison personnalisés.

Voici les paramètres d’exemple de Microsoft, à examiner dans un shell avec élévation de privilèges pour un abonnement de test approuvé sur WEC ; ce ne sont pas des recommandations de dimensionnement en production :

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

/cf:Events sélectionne le format d’événement ; /cm:Custom sélectionne la livraison personnalisée ; /dmi définit le nombre maximal d’événements par livraison, tandis que /dmlt définit la latence maximale de livraison en millisecondes. Ne remplacez les noms d’exemple qu’après avoir examiné l’abonnement prévu. Lire les événements existants peut récupérer l’historique disponible ; cela ne peut pas recréer des événements écrasés ou jamais générés.

Étape 3 : valider une interruption approuvée

Planifiez un test contrôlé avec le responsable de la supervision, un périmètre défini, une condition d’arrêt et une procédure de reprise. Choisissez une activité bénigne déjà couverte par les paramètres d’audit et l’abonnement requis. Consignez les événements sources correspondants avant, pendant et après l’interruption. Précisez à l’avance quels enregistrements devront pouvoir être recherchés au niveau central et quand l’équipe les évaluera.

Rétablissez la collecte, puis vérifiez ces enregistrements par le chemin central de recherche approuvé. Conservez les preuves sources, la chronologie de l’interruption, les paramètres d’abonnement, les résultats centraux et les erreurs. Examinez les écarts même si la connectivité est rétablie. Signalez explicitement tout intervalle manquant et déterminez si des archives restantes ou une autre copie approuvée peuvent le fournir.

Étape 4 : clôturer la revue des preuves

La clôture doit préciser exactement ce qui a été évalué : les DC concernés, les événements requis, la période de la politique, l’historique local disponible, les archives, la destination centrale et le chemin de recherche. Joignez les exceptions non résolues avec un responsable et une date de revue. Si le test n’a couvert qu’un contrôleur ou certains événements, indiquez ce périmètre et planifiez les contrôles restants.

Conservez des preuves datées. Répétez la revue après toute modification affectant les DC concernés, la configuration de journalisation, les archives ou la collecte centrale. La maintenance utile consiste à actualiser les preuves sous-jacentes et à examiner les écarts, plutôt qu’à recopier le verdict précédent dans un nouveau rapport.

Comment EtcSec détecte ce problème

Dans etc-collector au commit 9f698083354a1cb7f625df5cb490a515823c3257, AUDIT_LOG_RETENTION_SHORT émet un constat Info avec un Count=1 constant. Son Detect() ne lit aucun champ de DetectorData et renvoie le rappel même sans données de DC. Il ne mesure ni la capacité des journaux ni la conservation lisible, ne peut pas distinguer un environnement conforme d’un environnement déficient et ne peut pas passer automatiquement au vert après remédiation.

Le chemin de collecte AD examiné récupère les objets d’annuaire et les données GPO via LDAP ; ce détecteur n’invoque aucun fournisseur de journaux d’événements et ne lit aucun canal Security local. Utilisez le rappel pour demander les preuves par DC décrites ci-dessus, pas comme preuve d’un déficit de conservation.

Consignez la revue manuelle et la décision approuvée avec le rappel. Gardez les preuves d’historique lisible et les résultats de recherche centraux à la disposition du responsable qui accepte la clôture.