Audit et journaux Event Log¶

1. Pourquoi l'audit est indissociable du hardening¶

Le hardening empêche une partie des actions adverses. Il ne supprime ni l'erreur humaine, ni les écarts de configuration, ni les contournements, ni les changements non maîtrisés.

Sans visibilité, vous ne savez pas si un réglage a cessé d'être appliqué, si un compte privilégié s'est connecté hors procédure, ou si une modification sensible a eu lieu sur un DC.

La sécurité Windows produit déjà une grande quantité d'événements. L'objectif n'est pas de tout journaliser. L'objectif est de journaliser ce qui change votre niveau de risque.

L'audit est donc la couche qui transforme un hardening statique en contrôle vérifiable. Il répond à trois questions simples :

• qui a fait l'action ;
• où l'action s'est produite ;
• est-ce attendu ou non.

Dans un incident, cette chronologie devient déterminante. Un durcissement sans logs vous laisse avec des hypothèses. Un durcissement avec logs vous donne des faits corrélables.

2. Audit basique vs audit avancé¶

Windows expose deux niveaux de configuration d'audit. Le niveau historique est basé sur neuf catégories générales. Le niveau recommandé repose sur des sous-catégories beaucoup plus fines.

Les catégories basiques vivent sous Local Policies > Audit Policy. Elles sont trop grossières pour une exploitation moderne. Une seule case cochée peut activer beaucoup plus d'événements que prévu.

Les sous-catégories vivent sous Advanced Audit Policy Configuration. Elles permettent de choisir précisément ce qui vous intéresse : logon, Kerberos, gestion de comptes, registre, AD, etc.

Microsoft déconseille de mélanger les deux modèles. Quand des paramètres avancés sont appliqués par GPO, les paramètres basiques peuvent produire des résultats inattendus.

Le point important est structurel : une catégorie basique active tout un ensemble de sous-catégories. Vous perdez donc le contrôle fin sur le bruit et sur la pertinence.

Le chemin GPO à retenir est : Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration

Dans certaines consoles GPMC, le nœud Policies apparaît entre Computer Configuration et Windows Settings. Le point important est le nœud Advanced Audit Policy Configuration.

Si vous utilisez ce modèle avancé, activez aussi l'option suivante : Local Policies > Security Options > Audit: Force audit policy subcategory settings to override audit policy category settings

Cette option évite qu'une ancienne catégorie basique réinjecte un comportement incohérent dans la politique effective.

3. Sous-catégories les plus utiles¶

La table suivante propose une base opérationnelle. Les colonnes Valeur recommandée reflètent une baseline défensive pragmatique. Elles ne remplacent pas un pilote sur votre parc.

3.1 Logon/Logoff : Audit Logon¶

Audit Logon couvre les créations de session sur la machine accédée. Sur un poste, vous voyez les connexions locales et distantes. Sur un serveur, vous voyez aussi les accès réseau vers la ressource hébergée.

Les événements les plus utiles sont :

• 4624 : ouverture de session réussie ;
• 4625 : ouverture de session échouée ;
• 4634 : fermeture de session.

Le réglage recommandé est Success + Failure. Vous voulez voir à la fois l'usage normal et les échecs. Les échecs seuls ne suffisent pas pour reconstituer une séquence complète.

3.2 Account Logon : Kerberos et validation d'identifiants¶

Audit Kerberos Authentication Service journalise les demandes de TGT. Cette sous-catégorie n'a de sens que sur les contrôleurs de domaine. Son volume est naturellement élevé sur les KDC.

Les événements principaux sont :

• 4768 : demande de TGT Kerberos ;
• 4771 : pré-authentification Kerberos en échec ;
• 4772 : événement défini mais non invoqué en pratique, 4768 en échec est utilisé.

Le réglage recommandé est Success + Failure sur les DC. Vous obtenez les authentifications Kerberos réussies et les échecs liés aux mots de passe, aux certificats ou au chiffrement.

Audit Credential Validation complète cette vue. Cette sous-catégorie est utile pour les validations d'identifiants, notamment NTLM, et pour les comptes locaux sur la machine autoritative.

L'événement clé est 4776. Le réglage recommandé est Success + Failure. En domaine, le volume sera surtout porté par les DC.

3.3 Object Access : Audit File System et Audit Registry¶

Ces deux sous-catégories sont puissantes, mais elles ne doivent jamais être activées à l'aveugle. Elles génèrent des événements seulement si une SACL existe sur l'objet ciblé.

Audit File System est utile pour :

• des partages sensibles ;
• des répertoires de secrets ou d'exports ;
• des dossiers d'outils d'administration ;
• des emplacements où une écriture non prévue est critique.

Audit Registry est utile pour :

• des clés d'exécution automatique ;
• des clés de sécurité ;
• des paramètres d'agents, d'EDR ou de durcissement ;
• des zones de persistance ou de configuration critique.

La logique recommandée est la suivante :

• Audit File System seulement si vous avez un besoin ciblé ;
• Audit Registry de manière ciblée sur quelques clés critiques ;
• Success + Failure uniquement sur des objets avec SACL soigneusement définie.

3.4 Privilege Use : Audit Sensitive Privilege Use¶

Cette sous-catégorie suit l'usage de privilèges sensibles. Elle peut devenir bruyante si vous activez tout partout, mais elle est très utile sur les systèmes d'administration et les serveurs critiques.

L'événement le plus consulté est 4672, qui signale qu'une nouvelle session a reçu des privilèges spéciaux. Il permet de repérer rapidement les ouvertures de session à haut niveau de droits.

La recommandation courante est Success. Vous capturez l'usage effectif des privilèges sensibles, sans vous exposer immédiatement au bruit maximal de certains scénarios d'échec.

3.5 Policy Change : Audit Audit Policy Change¶

Cette sous-catégorie documente les changements de politique d'audit. Elle est critique parce qu'un attaquant ou un administrateur maladroit essaie souvent de réduire la visibilité avant ou après une action sensible.

L'événement clé est 4719. Il signale qu'une politique d'audit système a changé. Microsoft précise que 4719 est toujours journalisé.

Le réglage recommandé reste Success + Failure. Même si 4719 est particulier, vous voulez une famille Policy Change cohérente sur tout le parc.

3.6 Account Management : Audit User Account Management¶

Cette sous-catégorie couvre la création, l'activation, la modification du mot de passe, la désactivation et le verrouillage des comptes.

Les événements les plus utiles pour une baseline sont :

• 4720 : création d'un compte ;
• 4722 : activation d'un compte ;
• 4723 : tentative de changement de mot de passe ;
• 4725 : désactivation d'un compte ;
• 4740 : verrouillage d'un compte.

La recommandation est Success + Failure. Vous suivez les changements valides, mais aussi les tentatives ratées qui signalent un usage anormal ou une erreur.

3.7 DS Access : Audit Directory Service Changes¶

Audit Directory Service Changes ne concerne que les contrôleurs de domaine. Il suit les changements sur les objets AD DS et permet de voir les anciennes et nouvelles valeurs sur des modifications ciblées.

L'événement le plus utile est 5136, qui indique qu'un objet de service d'annuaire a été modifié. C'est un événement central pour suivre les dérives dans Active Directory.

La recommandation usuelle est Success sur les DC. Le prérequis reste le même : des SACL pertinentes doivent être posées sur les objets surveillés.

auditpol /get /category:*
Get-WinEvent -ListLog Security | Format-List LogName, MaximumSizeInBytes, RecordCount

4. Taille des journaux Event Log¶

Un bon audit peut être ruiné par un journal trop petit. Quand le volume dépasse la taille disponible, les événements les plus anciens sont écrasés ou les nouveaux sont perdus selon la rétention.

Le point de configuration demandé au niveau local est : HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security\MaxSize

Le même principe existe pour :

• HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application\MaxSize
• HKLM\SYSTEM\CurrentControlSet\Services\EventLog\System\MaxSize

En GPO, le chemin recommandé est : Computer Configuration > Administrative Templates > Windows Components > Event Log Service

Vous y trouverez les nœuds Security, System et Application, avec le réglage Specify the maximum log file size (KB).

Les valeurs pratiques suivantes constituent une baseline robuste :

Ces valeurs ne sont pas une limite haute universelle. Elles correspondent à une base raisonnable pour éviter une rotation trop rapide sur postes et serveurs standards.

Sur un DC, un serveur de fichiers, ou une machine fortement auditée, la taille du journal Security peut devoir être supérieure.

La politique de rétention compte autant que la taille. Si le journal atteint sa taille maximale :

• en mode écrasement, les anciens événements disparaissent ;
• en mode rétention stricte, les nouveaux événements peuvent être perdus.

5. Centralisation des logs : WEF vs SIEM¶

La centralisation n'est pas optionnelle dès que le parc grandit. Un événement utile laissé sur un poste compromis est un événement facile à perdre.

WEF, pour Windows Event Forwarding, est la brique native Windows. Elle lit les événements sur les postes et serveurs et les transmet à un serveur WEC, Windows Event Collector.

Un SIEM va plus loin. Il ne se contente pas de collecter. Il corrèle, historise, recherche, alerte et croise plusieurs sources.

La comparaison utile n'est donc pas "WEF ou SIEM ?" mais "où s'arrête la collecte Windows native et où commence l'analytique de détection ?"

Dans une architecture mature, WEF sert souvent de couche de collecte Windows et le SIEM de couche d'analyse. Le collecteur WEC peut devenir le point de transit vers le SIEM.

Si vous n'avez pas encore de SIEM, WEF est déjà un gain réel. Vous sortez de la dépendance aux journaux locaux dispersés.

Si vous avez un SIEM, WEF reste utile pour normaliser le transport natif Windows et réduire la dépendance aux scripts ou aux agents improvisés.

Sysmon : supervision avancée¶

Sysmon, de la suite Sysinternals, ajoute des événements orientés détection que les journaux Windows natifs ne produisent pas toujours avec le même niveau de détail. Il ne remplace pas l'audit Windows : il le complète avec une télémétrie plus riche sur les processus, le réseau, les fichiers et certains comportements système.

Exemples d'événements utiles :

Le point critique est la configuration. Un Sysmon installé avec une configuration trop large peut générer beaucoup de bruit. Des configurations communautaires comme celle de SwiftOnSecurity sont souvent utilisées comme base de départ, mais elles doivent être relues et adaptées au parc.

.\Sysmon64.exe -accepteula -i .\sysmonconfig.xml

.\Sysmon64.exe -c .\sysmonconfig.xml

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 20 |
    Select-Object TimeCreated, Id, ProviderName, Message

Les parametres Sysmon sont stockes dans le registre :

• HKLM\SYSTEM\CurrentControlSet\Services\Sysmon64\Parameters\ConfigFilePath — emplacement du fichier de configuration actif
• HKLM\SYSTEM\CurrentControlSet\Services\Sysmon64\Parameters\HashAlgorithms — algorithmes de hash utilises (SHA256 recommande)

6. Flux de centralisation¶

Le schéma suivant résume un flux simple et robuste. Les postes et serveurs produisent les événements, WEF les transmet à un collecteur, puis le SIEM assure la corrélation et l'investigation.

flowchart LR
    A["Poste ou serveur Windows"] --> B["WEF<br/>abonnement et filtrage"]
    B --> C["Collecteur WEC<br/>journal Forwarded Events"]
    C --> D["Collecteur central<br/>normalisation / rétention courte"]
    D --> E["SIEM<br/>corrélation, alertes, hunting"]

Ce modèle reste valable même si le collecteur central et le serveur WEC sont la même machine. L'important est la séparation logique des rôles.

7. Pièges classiques¶

Le premier piège est l'audit trop large. Quand tout est journalisé, rien n'est exploitable. Vous surchargez le stockage, les collecteurs et les analystes.

Le deuxième piège est l'oubli du disque. Un journal Security sous-dimensionné fait tourner les événements plus vite que votre collecte.

Le troisième piège est l'absence de filtre utile. Une alerte sur tous les 4625 sans contexte, ou sur tous les 4672 sans liste de systèmes sensibles, crée du bruit au lieu de créer de la détection.

Le quatrième piège est de croire qu'une sous-catégorie suffit. Pour File System, Registry et Directory Service Changes, la politique doit être combinée avec des SACL ciblées.

Le cinquième piège est l'oubli des DC. Une partie de la vérité d'authentification vit sur le contrôleur de domaine, pas sur le poste utilisateur.