Surveillance de l'activité des utilisateurs dans Active Directory : ce qu'il faut surveiller et comment

Lorsqu'un compte utilisateur est compromis dans un environnement Windows sur site, le point de départ est toujours le moment où l'attaquant tente de s'authentifier auprès d'Active Directory (AD). Ce qui se passe avant et après cet événement d'authentification, et la visibilité dont vous disposez à ce sujet, déterminera la rapidité avec laquelle vous détectez une violation et l'étendue des dommages. La surveillance de l'activité des utilisateurs dans AD n'est pas seulement une bonne pratique de sécurité. C'est l'un des contrôles les plus directs dont disposent les équipes informatiques qui gèrent des environnements Windows sur site et hybrides.

Un long historique d'incidents réels confirme ce que la plupart des administrateurs AD savent déjà : le point faible de la plupart des réseaux est le compte utilisateur et le système d'identité Active Directory qui sous-tend la connexion. Cet article explique comment fonctionne la surveillance de l'activité des utilisateurs dans Active Directory, quels signaux sont les plus importants, et comment des outils spécialisés complètent, voire remplacent parfois, les plateformes SIEM de niveau supérieur.

Il n'y a pas si longtemps, cela aurait semblé improbable : le hacking traditionnel consistait à trouver des ports ou des interfaces mal sécurisés et à s'y introduire. L'idée qu'un attaquant puisse simplement se connecter avec des identifiants valides était jugée peu probable.

Les organisations ont ensuite découvert à quel point il était facile de deviner ou de voler des identifiants légitimes, et le paysage des menaces a évolué. Aujourd'hui, les identifiants des utilisateurs représentent le principal risque pour la sécurité des réseaux, au point que l'identité des utilisateurs est devenue le périmètre que les équipes de sécurité surveillent le plus.

Il en résulte une attention croissante portée à la surveillance directe des comptes utilisateurs au niveau de la couche d'authentification, plutôt que de s'appuyer uniquement sur les contrôles de périmètre réseau.

Historiquement, les organisations ont cherché à résoudre ce problème en ajoutant des systèmes de sécurité spécialisés pour chaque nouvelle catégorie de menace : des pare-feux analysant le trafic au niveau des paquets, des ports et des protocoles ; des pare-feux de nouvelle génération avec surveillance des applications et des utilisateurs ; des solutions de détection et réponse aux points de terminaison (EDR) pour les PC et les serveurs. Chacun apporte de la visibilité, mais pas nécessairement de la clarté. Il reste possible pour les attaquants de se dissimuler en imitant un utilisateur ou une connexion légitime.

Le problème est qu'aucun système de sécurité ne dispose d'une vue suffisamment complète pour identifier avec certitude un attaquant. Il y a tout simplement trop d'événements et d'alertes pour tous les suivre.

La réponse a été les plateformes SIEM centralisées, qui ingèrent, normalisent et corrèlent les données provenant des pare-feux, des solutions EDR, des systèmes IDS/IPS, des appels API et applicatifs, des systèmes de prévention des pertes de données, des fournisseurs d'identité cloud, ainsi que des journaux AD et Windows. Grâce aux SIEM, la relation entre des événements en apparence sans lien devient plus claire. Les SIEM suivent également les schémas d'événements par rapport à une base de référence normale dans la durée.

En théorie, cela réduit la fatigue liée aux alertes en séparant automatiquement le signal du bruit. En pratique, cela soulève une autre question : quel rôle jouent les systèmes de sécurité de niveau inférieur lorsqu'autant de données sont corrélées via les analyses SIEM ?

La réponse est que les deux ont leur place. Les systèmes de niveau inférieur sont souvent là où un attaquant est détecté en premier ; la corrélation avec les données SIEM amplifie ou confirme une vision d'ensemble. Mais toutes les organisations n'ont pas ou ne nécessitent pas un déploiement SIEM complet, qui fonctionne mieux dans un environnement SOC géré par une équipe expérimentée. Certaines organisations externalisent cette fonction auprès d'un MSSP ; d'autres gèrent un petit nombre de contrôleurs de domaine pour lesquels une surveillance spécialisée de niveau inférieur est tout à fait suffisante.

Parfois, la vue d'ensemble ralentit les choses lorsqu'il est plus important d'être au plus près du problème. C'est là qu'interviennent des outils spécialisés comme UserLock, qui suit les authentifications Windows, et FileAudit, qui surveille les accès aux fichiers.

Les SIEM offrent une vue d'ensemble des événements sur plusieurs contrôleurs de domaine (DC). Mais la mise en œuvre de la sécurité commence toujours par la capacité à voir les authentifications des utilisateurs et les événements Windows en détail, pour chaque DC, au moment où ils se produisent, avant que ces données ne soient transmises en amont vers un SIEM.

À chaque ouverture de session, Windows génère un volume important de données dans les journaux d'événements. Ces données sont fragmentées et longues à traiter avec les seuls outils natifs. AD a été conçu comme une plateforme d'authentification, et non comme un système de sécurité.

UserLock comble cette lacune en contextualisant les données de session, offrant aux administrateurs une vue ciblée des activités de connexion et de session. Pour chaque événement d'authentification, UserLock présente aux équipes informatiques une vue claire sur :

• L'utilisateur qui s'est authentifié

• Le serveur auquel l'utilisateur a accédé

• L'horodatage de la session

• Si l'accès provient d'une IP réseau, d'un VPN, d'une connexion RDP, d'une RemoteApp ou d'un Wi-Fi

• Si des sessions simultanées ont été ouvertes

• Si l'accès a enfreint des restrictions de stratégie ou échoué aux vérifications de l'authentification multifacteur (MFA)

Au lieu d'interpréter une série d'identifiants d'événements Windows, les administrateurs disposent d'une vue claire et en temps réel du comportement des comptes utilisateurs, avec la possibilité de bloquer les activités suspectes via des stratégies.

FileAudit accomplit un travail comparable pour les événements d'accès aux fichiers sur l'ensemble des systèmes de stockage, en enregistrant les lectures, les écritures, les créations, les suppressions, les renommages, les copies et les modifications de droits d'accès. Pour chaque événement de fichier, il capture :

• L'utilisateur qui a accédé au fichier

• Les actions effectuées

• L'heure à laquelle les actions ont eu lieu

• L'adresse IP de l'accès

• Si l'action a abouti ou a été bloquée par une stratégie

Les deux sont complémentaires. Si UserLock suit la façon dont les utilisateurs s'authentifient auprès d'AD, FileAudit surveille la façon dont ils interagissent avec les fichiers et les données une fois connectés.

Comprendre le comportement des utilisateurs en temps réel n'est qu'une partie du tableau. La capacité à analyser rétrospectivement les données d'activité pour modéliser les schémas d'accès aux comptes dans le temps est tout aussi utile.

De nombreuses anomalies sont trop subtiles pour être détectées à partir d'un seul événement. Elles nécessitent une analyse rétrospective sur une période plus longue. C'est particulièrement vrai pour les accès aux fichiers. Les menaces internes se manifestent rarement en un seul événement ; c'est le comportement d'accès détaillé sur plusieurs jours ou semaines qui est le plus révélateur.

Le même principe s'applique à l'analyse des sessions. Si un incident de type ransomware est suspecté, la première tâche consiste à identifier l'origine de la violation. L'historique des sessions fourni par un outil tel que UserLock est indispensable pour ce type d'investigation, ainsi que pour l'analyse post-incident approfondie.