Lacune Windows 2 : pas de reporting sur les connexions/déconnexions

Il n'existe aucun moyen dans Windows d'obtenir un rapport disant « Jean s'est connecté à 08h00 et s'est déconnecté à 11h00 »

A nouveau, la raison en est que le contrôleur de domaine de garde pas trace du fait que Jean est encore connecté à partir de tel ordinateur.

Certains d'entre vous pensent peut-être qu'en collationnant les journaux d'événements de ces contrôleurs de domaine et en filtrant correctement ces événements, il serait possible d'obtenir un rapport listant toutes ces connexions initiales ainsi que les connexions vers d'autres serveurs. Si vous avez essayé, vous savez à quel point il peut être compliqué d'obtenir une simple liste de toutes les connexions initiales à partir des événements de sécurité d'un contrôleur de domaine, à moins d'avoir la capacité à corréler et regrouper de multiples événements en un seule ligne.

D'autres pourraient suggérer qu'en traquant tous les événements de connexion et de déconnexion du réseau, puis en les rassemblant, il devrait être possible de savoir quand Jean s'est connecté, combien de temps est-il resté connecté et quand s'est-il déconnecté. Et bien cela ne marche tout simplement pas : lorsqu'un utilisateur « mappe » un lecteur réseau sur un serveur, ouvre un fichier puis le referme, le serveur de fichier ferme cette session (dans un délai de quelques secondes à deux ou trois minutes) et insère un événement de déconnexion dans le journal de sécurité.

L'utilisateur est toujours installé à son poste de travail et n'a aucune idée du fait qu'il vient de se déconnecter du serveur. Lorsqu'il essaie à nouveau d'ouvrir un fichier sur ce serveur, son poste de travail détecte qu'il a été déconnecté et se reconnecte silencieusement au serveur, ce qui génère un nouvel événement de connexion. Puis lorsque l'utilisateur ferme ce fichier et n'a pas d'autres fichiers ouverts sur ce serveur, le serveur ferme à nouveau la connexion, générant un nouvel événement de déconnexion.

Cela explique pourquoi les serveurs de fichiers génèrent des centaines d'événements de connexion et de déconnexion par utilisateur en une seule journée.

Il n'existe donc aucun moyen de collecter toutes les informations de connexion d'un utilisateur donné en analysant les journaux d'événements d'un contrôleur de domaine ou d'un serveur de fichiers.

Restent donc les journaux de sécurité de tous vos postes de travail… A l'exception de certains réseaux de petite taille hyper-sécurisés, généralement utilisés par des organismes gouvernementaux (services secrets, etc.), il est rarissime qu'une organisation, publique ou privée, collecte l'ensemble des journaux de sécurité de ses postes de travail. Cela n'est pas théoriquement impossible, mais vous imaginez les coûts de stockage et de licences logicielles générés par une telle tâche, sans compter la difficulté d'obtenir des informations cohérentes et exploitables…

Pourquoi est-il tellement important d'obtenir un reporting fiable sur les connexions/déconnexions ?

Cela permet en particulier de répondre à des questions cruciales lors d'investigations suivant l'occurrence d'un incident. Qui était réellement connecté ? D'où se sont-ils connectés ? Quand se sont-ils connectés ? Combien de temps sont-ils restés connectés ? Quand se sont-ils déconnectés ? A un instant donné, qui était vraiment connecté ? Les fonctionnalités natives de Windows ne permettent pas de répondre avec précision à ces questions.

Cette fonctionnalité est pourtant indispensable pour la mise en conformité d'un système d'information avec les contraintes réglementaires suivantes :

• Sarbanes-Oxley (section 404 et 802)
• LSF (sections «Contrôle d'implémentation» et «Reporting»)
• Bâle II (sections «Collecte et journalisation des incidents» et «Reporting»)
• PCI (sections «Surveillance» et «Suivi et archivage»)
• US Patriot Act (section «User monitoring and management»)