Exporter (0) Imprimer
Développer tout

Surveillance de la sécurité et détection des attaques

Paru le 29 août 2006


Sur cette page

Introduction
Définition
Défis pour les entreprises de taille moyenne
Solutions
Résumé
Annexe A : Exclusion des événements inutiles
Annexe B : Implémentation des paramètres de stratégie de groupe

Introduction

Bienvenue dans ce document de la collection Guides de sécurité pour les entreprises de taille moyenne. Microsoft espère que les informations suivantes vous aideront à mettre en place un environnement informatique à la fois plus sûr et plus productif.

Synthèse

Le nombre croissant de menaces et d'incidents majeurs liés à des logiciels malveillants signalés par les médias a permis à la plupart des entreprises de prendre conscience de ce problème majeur et d'investir du temps et des ressources dans la lutte contre ce fléau. Toutefois, la menace la plus sérieuse qui pèse sur l'infrastructure d'une entreprise peut ne pas se présenter sous la forme d'une attaque extérieure, telle qu'un virus, mais résider au sein même du réseau interne.

Les attaques lancées à partir d'un réseau d'entreprise sont très susceptibles d'entraîner des conséquences graves, notamment si elles sont le fait de personnes qui occupent des postes à responsabilités et qui ont de ce fait accès à l'intégralité des ressources réseau de l'entreprise. Après une analyse minutieuse des risques externes et internes, de nombreuses entreprises décident de s'équiper de systèmes capables de surveiller les réseaux et de détecter les attaques, quelle que soit leur origine.

Les solutions de surveillance de la sécurité ne doivent pas seulement être prises en considération par les entreprises soumises à des réglementations strictes ; elles sont nécessaires. Ces réglementations peuvent même préciser la durée et le mode de conservation et d'archivage des documents relatifs à la surveillance de la sécurité. Les réglementations en constante évolution et les pressions sans cesse plus fortes auxquelles font face les entreprises qui en dépendent pour sécuriser leurs réseaux, contrôler les personnes ayant accès aux ressources et protéger les informations confidentielles obligent toutes les entreprises à mettre en œuvre des solutions efficaces de surveillance de la sécurité.

Les entreprises de taille moyenne, même si elles ne sont pas soumises à ces réglementations, doivent néanmoins s'intéresser de près aux solutions de surveillance de la sécurité et de détection des attaques, et ce pour plusieurs raisons. Parmi ces raisons figurent les conséquences subies par une entreprise au cas où une attaque visant son infrastructure venait à réussir. Le fonctionnement de l'entreprise pourrait être interrompu, ce qui entraînerait une baisse de productivité, voire des pertes financières. Sa réputation pourrait même en souffrir, ce dont l'entreprise pourrait mettre plus longtemps à se relever que de toute autre perte engendrée par une attaque.

Les journaux de sécurité disponibles dans Microsoft® Windows® peuvent constituer le point de départ d'une solution de surveillance de la sécurité. Cependant, ces journaux seuls ne fournissent pas suffisamment d'informations pour planifier les réactions face aux incidents. Ils peuvent être associés à d'autres technologies de collecte et de recherche d'informations afin de former la base d'une solution complète de surveillance de la sécurité et de détection des attaques.

L'objectif principal de cette solution est de faciliter l'identification des événements suspects se produisant sur un réseau, qui peuvent être le signe d'activités malveillantes ou d'erreurs de procédure. Cet article explique comment définir une stratégie de mise en place de ce type de solution sur les réseaux fonctionnant sous Windows. Il fournit également des instructions permettant d'implémenter, de gérer et de valider le système de surveillance de la sécurité et de détection des attaques.

Présentation

Cet article se compose de quatre sections principales, axées sur les concepts et les problèmes clés liés à l'implémentation d'une solution efficace de surveillance de la sécurité et de détection des attaques. La première section, que vous êtes en train de lire, s'intitule « Introduction ». Les autres sections sont les suivantes :

Définition

Cette section présente des informations permettant de comprendre les processus intervenant dans la création et l'application de la solution décrite dans cet article.

Défis pour les entreprises de taille moyenne

Cette section présente la plupart des difficultés rencontrées par les entreprises de taille moyenne lors de la mise en place d'un système de surveillance de la sécurité et de détection des attaques.

Solutions

Cette section fournit des informations détaillées sur le développement, l'implémentation, la gestion et la validation de la solution présentée dans cet article. Elle est divisée en deux sous-sections : « Développement de la solution » décrit les opérations préalables et les étapes de planification et « Déploiement et gestion de la solution » contient des informations qui vous aideront à déployer, gérer et valider votre système de surveillance de la sécurité et de détection des attaques.

Personnes concernées par ce guide

Cet article, consacré aux problèmes de confidentialité et de sécurité, s'adresse aux entreprises de taille moyenne, notamment celles qui sont obligées d'assurer la sécurité de leurs données via une protection et un contrôle des identités en raison de réglementations strictes. Par conséquent, sont concernées par ce document toutes les personnes (responsables et décideurs techniques, informaticiens et implémenteurs de technologie) chargées de la planification, du déploiement, du fonctionnement et de la sécurité du réseau d'une entreprise.

Certaines parties de ce document sont utiles à la plupart des décideurs techniques, mais les lecteurs doivent posséder de solides connaissances des problèmes et des risques liés à la sécurité dans leur propre environnement réseau. Il doivent également bien comprendre les concepts des services de journalisation des événements Windows afin de tirer parti de toutes les informations qu'il contient.

Définition

Outre les fonctions de gestion des services d'administration de la sécurité et de gestion des incidents MOF (Microsoft Operations Framework), ce document utilise le modèle de processus MOF.

En ce qui concerne la solution de surveillance de la sécurité et de détection des attaques, la solution présentée ici recommande l'utilisation de processus continus plutôt qu'un déploiement linéaire. Cette solution doit reposer sur les procédures illustrées dans la figure suivante :

Figure 1. Application de MOF

Figure 1. Application de MOF

La nature même de la surveillance de la sécurité exige la mise en place d'une solution fondée sur des processus continus de planification, d'implémentation, de gestion et de test. Les menaces pesant sur les réseaux d'entreprise ne cessant d'évoluer, le système qui gère la sécurité d'un réseau d'entreprise doit également être capable de s'adapter.

L'application de ces processus à la surveillance de la sécurité incombe à la fonction de gestion du service d'administration de la sécurité, chargée d'effectuer les opérations suivantes :

  • Évaluer les risques qui pèsent sur l'entreprise et identifier les ressources à protéger.

  • Rechercher des moyens de ramener les risques à un niveau acceptable.

  • Définir un plan pour limiter les risques.

  • Surveiller l'efficacité des mécanismes de sécurité.

  • Procéder à une réévaluation régulière de l'efficacité et des exigences en termes de sécurité.

Pour plus de détails sur MOF, reportez-vous au site Web Microsoft Operations Framework à l'adresse www.microsoft.com/mof (ce site peut être en anglais). Pour plus d'informations sur la fonction de gestion du service d'administration de la sécurité, visitez le site www.microsoft.com/technet/itsolutions/cits/mo/smf/mofsmsmf.mspx (ce site peut être en anglais).

La gestion des risques consiste à identifier un niveau de risque acceptable pour une entreprise, à rechercher des moyens de l'atteindre, à évaluer les risques actuels et à les gérer. Bien que cet article décrive des concepts relatifs à la gestion des risques et certaines méthodes d'évaluation des risques, la gestion des risques est un sujet à part entière qui mérite un examen approfondi. Pour plus d'informations sur l'analyse et l'évaluation des risques, consultez le Guide de gestion des risques de sécurité à l'adresse http://go.microsoft.com/fwlink/?linkid=30794.

Défis pour les entreprises de taille moyenne

Pour une entreprise de taille moyenne, la mise en place d'un système efficace de surveillance de la sécurité et des stratégies associées ne sont pas sans soulever de nombreuses difficultés. Ces entreprises doivent relever les défis suivants :

  • Comprendre la nécessité et les avantages de protéger l'environnement réseau dans son ensemble des menaces internes et externes.

  • Concevoir un système de surveillance de la sécurité et de détection des attaques comprenant des solutions pour identifier et déjouer les tentatives de violation des règles établies.

  • Implémenter des stratégies de surveillance exhaustives et efficaces, qui non seulement détectent les attaques, mais offrent également un aperçu global du niveau de sécurité d'un environnement afin de résoudre les problèmes.

  • Gérer des stratégies et des processus mettant en corrélation les rapports de sécurité et les règles établies afin de réduire les efforts administratifs nécessaires à la détection des activités malveillantes.

  • Implémenter et appliquer des pratiques et des stratégies efficaces pour soutenir les efforts de l'entreprise en termes de sécurité sans compromettre les exigences de son activité.

  • Déterminer les seuils de risque acceptables pour concilier facilité d'utilisation et limitation des risques.


Solutions

Comme indiqué précédemment, un processus complet de surveillance de la sécurité ne permet pas seulement une analyse des dommages ; il peut également s'agir d'une mesure de sécurité proactive fournissant des informations avant, pendant et après une attaque. La centralisation des rapports de sécurité permet de détecter une attaque avant, pendant, ou immédiatement après qu'elle ait eu lieu, afin de fournir aux personnes concernées les informations requises pour répondre efficacement à l'attaque et limiter ses conséquences.

Il est essentiel de comprendre les avantages offerts par la surveillance de la sécurité au cours de la phase de développement de la solution, de sorte que les stratégies mises en place puissent tirer parti de ces avantages. La surveillance de la sécurité offre notamment les avantages suivants :

  • Identification et correction des systèmes non conformes aux exigences de sécurité ou mise à jour des stratégies afin de limiter la vulnérabilité d'une entreprise de taille moyenne.

  • Identification des activités inhabituelles et production d'informations permettant de détecter les tentatives d'intrusion précédant une attaque.

  • Création et protection d'informations d'audit de sécurité pour améliorer l'analyse des dommages, dans un souci de conformité aux réglementations en vigueur et de limitation de l'impact des attaques éventuelles.

  • Contribution aux efforts d'analyse du niveau de sécurité afin de renforcer la sécurité globale.

  • Détection des activités, volontaires ou accidentelles, qui n'entrent pas dans le cadre des processus de l'entreprise.

  • Identification des systèmes non gérés d'un réseau et protection des périphériques vulnérables.

Développement de la solution

Pour de nombreuses entreprises, la sécurité est une priorité. Bien que la plupart d'entre elles assurent un niveau de sécurité physique raisonnable en employant des méthodes simples, telles qu'un verrou posé sur une porte, ou plus élaborées, telles que des contrôles d'accès par carte à puce, nombreuses sont celles qui ne protègent pas suffisamment les données dont elles sont de plus en plus dépendantes.

Les entreprises qui se soucient des problèmes de sécurité et de surveillance se contentent généralement de protéger les données en mettant en place des pare-feu à la périphérie du réseau. Cependant, cette approche fait que d'autres cibles restent vulnérables. Selon le document intitulé 2004 E-Crime Watch Survey (enquête sur les crimes électroniques commis en 2004) publié par les services secrets américains et le centre de coordination CERT (www.cert.org/archive/pdf/2004eCrimeWatchSummary.pdf), 29 % des utilisateurs malveillants identifiés provenaient de sources internes (salariés actuels, sous-traitants et anciens employés). À la lumière de ces informations, il devient évident qu'une approche multicouche de la sécurité doit être adoptée afin de garantir une protection contre toutes les menaces, internes et externes.

Une méthode allant dans ce sens consiste à implémenter un processus de journalisation d'audit de sécurité. Toutes les versions de Microsoft Windows, de Microsoft Windows NT® 3.1 à la version actuelle, font appel à un journal d'événements de sécurité intégré pour consigner les événements de sécurité. Bien que cette fonctionnalité puisse être utile pour analyser les dommages consécutifs à une attaque déjà perpétrée, il est difficile de l'utiliser de manière proactive pour détecter les activités précédant une attaque ou informer le personnel approprié des tentatives d'intrusion au moment où elles se produisent.

Comme indiqué précédemment, les journaux de sécurité sont généralement utilisés de manière réactive, au cours de l'examen des conséquences d'un incident de sécurité. Toutefois, dans le document 2005 Insider Threat Study (étude sur les menaces internes) publié en 2005 par les services secrets américains et le CERT (www.cert.org/archive/pdf/insidercross051105.pdf), l'analyse des conclusions montre que la surveillance et la journalisation des événements de sécurité peuvent être utilisées de manière proactive, et pas seulement réactive. Sachant que la plupart des utilisateurs malveillants, internes et externes, cherchent à brouiller les pistes en modifiant les journaux, il est important de prendre des mesures destinées à protéger les journaux système. Les journaux de sécurité et les autres méthodes utilisées pour surveiller et détecter les attaques peuvent jouer un rôle essentiel dans la protection du réseau, s'ils sont utilisés et sécurisés correctement.

Bien que ce document soit principalement consacré aux journaux de sécurité, ceux-ci ne sont que la base de la méthodologie de surveillance de la sécurité et de détection des attaques. D'autres éléments doivent être pris en compte, concernant notamment l'identification et la correction des systèmes qui ne respectent pas les règles de sécurité établies ou qui n'ont pas encore implémenté les correctifs de sécurité recommandés. L'infrastructure du réseau interne doit également être surveillée, y compris la sécurité des ports de commutation (pour empêcher les systèmes non gérés d'accéder au réseau) et les connexions sans fil (pour éviter toute connexion non autorisée et prévenir l'interception des paquets). Bien que la plupart de ces aspects ne soient pas abordés dans ce document, ils doivent être pris en compte lors de la création d'une solution exhaustive de surveillance de la sécurité.

Implémentation de la surveillance de la sécurité

Les sections qui suivent fournissent des informations sur l'implémentation d'un système de surveillance de la sécurité.

Journalisation des événements de sécurité Windows

Toutes les versions de Microsoft Windows, depuis Microsoft Windows NT version 3.1, proposent une fonctionnalité intégrée de journalisation des événements de sécurité. Dans un environnement Microsoft Windows, cette fonctionnalité constitue la base du système de surveillance de la sécurité. Toutefois, ces informations sont dispersées et doivent donc être mises en corrélation à l'aide d'outils supplémentaires pour pouvoir être utilisées de manière proactive.

Cc875806.SMAAD2(fr-fr,TechNet.10).gif

Figure 2. Journal de sécurité de l'Observateur d'événements

Le journal d'événements de sécurité (illustré ci-dessus) utilise un format de fichier personnalisé pour enregistrer les données de surveillance de la sécurité. Certains de ces enregistrements peuvent être affichés dans un éditeur de texte, mais un programme approprié tel que l'Observateur d'événements est nécessaire pour consulter l'intégralité des informations de ces journaux. Le journal des événements de sécurité (SecEvent.evt) se trouve dans le répertoire %systemroot%\System32\config. L'accès aux journaux est régi par le service Journal des événements, qui met en place un contrôle d'accès pour chaque journal.  Les droits d'accès par défaut au journal de sécurité sont limités par rapport à ceux des autres journaux du système ; seuls les administrateurs y ont accès par défaut.

Deux types d'événements sont consignés dans le journal des événements de sécurité : audits des succès et audits des échecs. Les événements de type Audit des succès indiquent une opération exécutée avec succès par un utilisateur, un service ou un programme. Les événements de type Audit des échecs décrivent les opérations qui ont échoué. Par exemple, les tentatives de connexion utilisateur infructueuses sont enregistrées en tant qu'événements de type Audit des échecs dans le journal des événements de sécurité si l'audit des connexions est activé.

Les paramètres de stratégie de groupe Stratégie d'audit, situés dans Configuration de l'ordinateur\Paramètres Windows\Stratégies locales, contrôlent les événements qui créent des entrées dans les journaux de sécurité. Les paramètres Stratégie d'audit peuvent être configurés à partir de la console Paramètres de sécurité locaux ou au niveau du site, du domaine ou de l'unité organisationnelle (OU) via Stratégie de groupe dans Active Directory.

Interprétation des événements d'audit

Les événements d'audit étant largement abordés dans ce document, il est important de comprendre leur structure et les informations qu'ils contiennent.

Figure 3. Fenêtre Propriétés de Événement

Figure 3. Fenêtre Propriétés de Événement

Les événements se composent de trois parties principales : un en-tête d'événement, une description d'événement et une section de données binaires.

Les en-têtes des événements sont constitués des champs suivants :

Tableau 1. En-tête d'événement

Champ

Définition

Date

Date à laquelle l'événement s'est produit.

Heure

Heure locale à laquelle l'événement s'est produit.

Type

Classification de la gravité ou du type de l'événement. Le type des événements d'audit de sécurité est toujours Audit des succès ou Audit des échecs.

Source

Application ayant consigné l'événement. Il peut s'agir d'un programme tel que SQL Server, d'un nom de pilote ou d'un composant du système tel que Sécurité.

Catégorie

Classification de la source de l'événement. Cette information est utile dans les journaux d'audit de sécurité car elle correspond à un type d'événement pouvant être configuré dans Stratégie de groupe.

ID événement

Ce code identifie le type d'événement. Dans la figure ci-dessus, l'ID d'événement est 680, qui indique qu'un ensemble d'informations d'identification a été transmis au système d'authentification par un processus local, un processus distant ou un utilisateur.

Utilisateur

Nom de l'utilisateur sous lequel l'événement s'est produit. Si celui-ci a été provoqué par un processus, il s'agit de l'ID du client et de l'ID principal si l'usurpation d'identité n'est pas utilisée. Dans le cas des événements de sécurité, les informations principales et d'usurpation d'identité s'affichent, si possible et s'il y a lieu.

Ordinateur

Nom de l'ordinateur sur lequel l'événement s'est produit.


Le champ de description d'événement contient en fait diverses informations qui peuvent varier d'un événement à un autre. Par exemple, dans l'exemple ci-dessus relatif à l'événement 680, le champ Code d'erreur : a la valeur 0xC000006A, qui indique qu'un mot de passe incorrect a été fourni. Des informations spécifiques à chaque type d'événement s'affichent dans ce champ.

Les événements du journal d'événements de sécurité Windows ne font pas appel à la section de données binaires de l'enregistrement d'événement.

Problèmes techniques

Les problèmes ci-dessous doivent être pris en compte lors de l'implémentation d'un système de surveillance de la sécurité et de détection des attaques fondé sur la journalisation des événements Windows.

  • Gestion de nombreux événements de sécurité. Pour faire face au nombre élevé d'événements de sécurité générés, les événements d'audit de sécurité à consigner doivent être précisément définis. Ces considérations sont essentielles, notamment lors de l'audit des accès aux fichiers et aux objets, qui peuvent générer des volumes de données très importants.

  • Stockage et gestion des informations dans un référentiel central. Selon la configuration du système de surveillance, le volume d'informations relatives aux événements à stocker peut se mesurer en téraoctets. Cet aspect doit notamment être pris en compte lors de l'examen des besoins en termes d'analyse des dommages ; il est décrit en détail dans la section correspondante.

  • Identification des signatures d'attaques et réaction. Pour identifier les schémas d'activités qui peuvent annoncer une attaque, un réviseur ou une requête configurée doit être en mesure d'extraire des informations fournies dans les événements associés à ces activités. Après l'identification d'une activité suspecte, un mécanisme doit être chargé de fournir une réponse rapide et pertinente.

  • Prévention du contournement des contrôles d'audit de sécurité par le personnel. Les personnes dotées de privilèges élevés, notamment les administrateurs des réseaux, doivent être cloisonnées afin de limiter l'accès aux informations d'audit, de sorte que seuls les spécialistes de la sécurité soient responsables de l'administration des systèmes d'audit.

Planification de la solution

Les opérations suivantes doivent être effectuées avant l'implémentation d'un système de surveillance de la sécurité et de détection des attaques :

  • Examen des paramètres d'audit de sécurité actuels.

  • Évaluation des rôles des administrateurs et des tâches des utilisateurs standard.

  • Examen des stratégies et procédures de l'entreprise.

  • Identification des systèmes vulnérables.

  • Établissement de la liste des ressources à valeur élevée.

  • Identification des comptes sensibles ou suspects.

  • Établissement de la liste des programmes autorisés.

Pour plus d'informations sur les exigences en matière de stockage, reportez-vous à la section « Implémentation de l'analyse des dommages » du présent document.

Examen des paramètres d'audit de sécurité actuels

Les entreprises doivent examiner les paramètres d'audit et du journal de sécurité en vigueur afin de fournir une base pour les modifications recommandées dans ce document. Cet examen doit être réalisé régulièrement après l'implémentation de la solution. Les informations suivantes doivent être collectées :

  • Paramètres d'audit de sécurité effectifs.

  • Niveau auquel s'appliquent ces paramètres (ordinateur local, site, domaine ou unité organisationnelle).

  • Paramètres actuels du journal (taille maximale et comportement lorsqu'elle est atteinte).

  • Paramètres d'audit de sécurité supplémentaires appliqués (audit de l'utilisation des privilèges de sauvegarde et de restauration, par exemple).

Vous pouvez utiliser les informations présentées dans l'« Annexe B : Implémentation des paramètres de stratégie de groupe » du présent document pour vous aider à identifier les paramètres à enregistrer. Pour plus d'informations sur les paramètres d'audit de sécurité, consultez le document Guide de sécurité Windows Server 2003 à l'adresse http://go.microsoft.com/fwlink/?LinkId=14845.

Évaluation des rôles des administrateurs et des tâches des utilisateurs standard

Un élément clé de l'implémentation d'une solution efficace de surveillance de la sécurité consiste à vérifier que les détenteurs de comptes administrateur sont connus et que leurs rôles et responsabilités sont bien compris. Par exemple, dans la plupart des entreprises, les administrateurs font partie du groupe Administrateurs du domaine ; ils peuvent donc créer de nouveaux comptes utilisateur dans le domaine. Toutefois, les stratégies de l'entreprise peuvent spécifier que seul un système d'attribution de privilèges d'accès installé est autorisé à créer de nouveaux comptes. Dans ce contexte, un événement de création de compte généré par un compte administrateur ferait l'objet d'une enquête immédiate.

L'évaluation des tâches des comptes utilisateur est généralement plus simple, dans la mesure où ces comptes ont par définition des accès aux ressources du réseau plus limités que ceux des comptes administrateur. Par exemple, étant donné que les utilisateurs standard n'ont généralement pas besoin d'accéder aux systèmes de fichiers d'ordinateurs résidant à la périphérie d'un réseau, la surveillance de ces serveurs devient secondaire.

Examen des stratégies et procédures de l'entreprise

L'analyse des processus et procédures de l'entreprise consiste principalement, mais pas uniquement, à évaluer les rôles et les responsabilités des administrateurs. Dans le cadre de cette analyse, il est important de passer en revue les processus de création d'utilisateurs et de contrôle des modifications, par exemple. L'examen des mécanismes mis en œuvre pour l'approbation et le suivi d'audit des événements survenant sur un réseau est essentiel pour mettre en corrélation les événements d'audit autorisés et les éventuelles tentatives d'intrusion.

Identification des systèmes vulnérables

Les systèmes vulnérables sont les ordinateurs et les périphériques d'un réseau susceptibles de faire l'objet de tentatives d'accès frauduleuses de la part d'attaquants externes. Ces ordinateurs résident généralement à la périphérie du réseau, mais les périphériques internes peuvent également être vulnérables aux attaques et ne doivent pas être négligés.

Un examen complet des systèmes vulnérables doit mettre en évidence les éléments suivants :

  • Toutes les mises à jour de sécurité et les service packs appropriés ont été appliqués.

  • Les services et les comptes utilisateur inutiles ont été désactivés.

  • Les services sont, dans la mesure du possible, configurés pour s'exécuter sous les comptes Service local ou Service réseau.

  • Les services exigeant des informations d'identification de comptes utilisateur sont contrôlés pour vérifier que ce niveau d'accès est requis, notamment si ces comptes disposent de privilèges administrateur.

  • Les modèles de stratégies hautement sécurisés ont été appliqués.

Remarque : cet examen ne doit pas être appliqué uniquement aux ordinateurs vulnérables situés à la périphérie du réseau. Dans le cadre d'une politique de sécurité efficace, il doit s'appliquer à tous les ordinateurs du réseau.

Pour savoir comment configurer les services pour une exécution sécurisée, consultez le guide de planification des services et des comptes de service à l'adresse http://go.microsoft.com/fwlink/?LinkId=41311 (ce document peut être en anglais).

Établissement de la liste des ressources à valeur élevée

Il est probable que la plupart des entreprises ont déjà identifié les ressources à valeur élevée stockées sur leurs réseaux, mais il est possible qu'elles n'aient pas formalisé ces informations dans le cadre d'une stratégie organisationnelle, en documentant et en détaillant les protections mises en place pour chaque ressource. Par exemple, une entreprise peut utiliser des listes de contrôle d'accès et des mécanismes de cryptage pour stocker les documents financiers importants en toute sécurité sur des partitions de système de fichiers NTFS. Cependant, une stratégie organisationnelle doit identifier ces documents en tant que fichiers protégés auxquels les utilisateurs et les administrateurs non autorisés ne doivent pas tenter d'accéder, de sorte que chacun soit informé de cette restriction.

Toute modification apportée à une liste de contrôle d'accès chargée de protéger ces fichiers doit être analysée, notamment en cas de modification de propriété ; en effet, ce type d'événement peut indiquer une tentative d'accès non autorisée. Ces modifications de propriété étant très rares, elles doivent être faciles à détecter une fois les ressources à valeur élevée identifiées et documentées.

Identification des comptes sensibles ou suspects

Tous les comptes sensibles doivent être passés en revue afin d'identifier ceux pour lesquels un niveau d'audit supérieur est requis. Parmi ces comptes figurent le compte Administrateur par défaut, les membres des groupes Administrateurs de l'entreprise, du schéma ou du domaine, ainsi que les comptes utilisés par les services.

Il est également important de définir les niveaux d'audit de sécurité appropriés pour les comptes des personnes identifiées comme susceptibles de participer à des activités illicites. Pour plus d'informations sur la définition des niveaux d'audit pour les comptes utilisateur individuels, consultez la section « Violations de stratégie et seuils » du présent document.

Établissement de la liste des programmes autorisés

Pour recueillir des informations sur un réseau, un utilisateur malveillant doit exécuter des programmes sur les systèmes appartenant à ce réseau. Le fait de placer des restrictions sur les programmes autorisés à s'exécuter sur un réseau permet de réduire considérablement les risques d'attaque. Afin de répertorier les programmes autorisés, un audit doit être effectué sur tous les programmes actuellement autorisés ou identifiés comme il se doit dans un environnement réseau. Tous les programmes inconnus découverts au cours de cet audit doivent être considérés comme suspects et analysés immédiatement. Microsoft Systems Management Server 2003 peut aider à réaliser des audits de logiciels, mais n'est pas obligatoire.

Remarque : certains ordinateurs peuvent faire l'objet d'exceptions, comme les stations de travail des développeurs sur lesquelles des exécutables en cours de développement peuvent ne pas faire partie de la liste de programmes autorisés. Toutefois, une approche plus rationnelle en termes de sécurité consiste à réaliser les tâches de développement et de test uniquement dans un environnement informatique virtuel ou dans un domaine de développement isolé.

Détection des violations de stratégie et seuils

Les violations de stratégie constituent la principale catégorie de problèmes de sécurité pour laquelle les entreprises doivent envisager une solution. Ces types d'incidents sont les suivants :

  • Création de comptes utilisateur sortant du cadre prévu.

  • Utilisation incorrecte ou non autorisée de privilèges d'administrateur.

  • Utilisation de comptes de service pour des ouvertures de session interactives.

  • Tentatives d'accès à des fichiers par des comptes utilisateurs non autorisés.

  • Suppression de fichiers auxquels les comptes utilisateurs ont accès.

  • Installation et exécution de logiciels non autorisés.

Les violations les plus courantes sont les tentatives d'accès involontaires, à des répertoires restreints par exemple. Ces violations sont également celles qui prêtent le moins à conséquence car elles sont gérées par des restrictions d'accès et des stratégies de gestion des droits efficaces. Volontaires ou accidentelles, les violations de stratégies administratives sont les plus graves, de par la nature même des droits administratifs.

Les privilèges d'administrateur accordent des droits d'accès étendus aux personnes dont la charge nécessite ce type d'accès. Toutefois, ces droits ne doivent pas être utilisés par leurs détenteurs hors du cadre de leur fonction. Le fait que les comptes administrateur aient la possibilité de créer et de modifier des comptes utilisateur, d'afficher les données à accès restreint et de modifier les droits d'accès aux données justifie un examen approfondi des moyens de limiter les risques inhérents à ces pouvoirs.

Modélisation des menaces

Comme on peut le constater, l'exécution d'audits peut permettre de minimiser certaines menaces. Toutefois, ces opérations ont un coût, que les menaces concernées ne justifient pas toujours. Il est important de bien comprendre qu'un point faible n'est pas nécessairement synonyme de menace pour un réseau. Pour identifier ceux qui doivent être corrigés, il peut être utile d'appliquer les principes de modélisation des menaces.

La modélisation des menaces est une technique d'ingénierie pouvant être utilisée pour identifier les menaces et les points faibles afin de créer des parades efficaces dans un environnement spécifique. Ce processus implique généralement trois étapes principales :

  • Comprendre le point de vue de l'attaquant.

  • Identifier le profil de sécurité du système.

  • Identifier et classifier les menaces existantes.

Plus précisément, analyser un environnement réseau du point de vue d'un utilisateur malveillant consiste à déterminer les cibles susceptibles d'être visées par une personne tentant d'accéder à un réseau et les conditions requises pour que l'attaque aboutisse. Une fois ces cibles identifiées, l'environnement peut être examiné pour déterminer l'efficacité des mesures de protection existantes. Ce processus met en évidence les menaces réelles (qui peuvent ensuite être classées selon le niveau de risque qu'elles présentent) et les mesures de protection les plus efficaces contre ces menaces. Il permet également de déterminer si ces mesures de protection affectent d'autres secteurs, de façon positive ou négative.

Pour que le processus de modélisation des menaces pesant sur un réseau soit efficace, les opérations suivantes doivent être effectuées :

  1. Identifier les ressources critiques : il s'agit de répertorier les ressources stratégiques pour le fonctionnement de l'entreprise afin d'optimiser l'utilisation des ressources de sécurité. Ce processus doit impliquer les propriétaires des processus de l'entreprise et les propriétaires de technologies, qui sont bien placés pour déterminer les ressources dont la mise en danger pourrait porter préjudice à l'entreprise.

  2. Identifier les points d'attaque potentiels : cette phase implique également deux perspectives. Tout d'abord, il convient de classifier les types de limites dans lesquelles les données du réseau peuvent résider. Ces limites appartiennent aux domaines critiques, sensibles et publics, en fonction des risques encourus en cas d'exposition de ces données. Ensuite, il convient d'examiner les points d'attaque d'un point de vue technologique, au moyen de vecteurs, afin d'identifier les points faibles qui pourraient donner accès aux ressources critiques et sensibles. La combinaison de ces informations peut permettre de concentrer les efforts en termes d'amélioration de la sécurité sur les points faibles susceptibles de fournir un accès aux données critiques.

  3. Identifier les menaces réelles : Une fois les ressources critiques et les points d'accès potentiels identifiés, une liste des actions susceptibles d'avoir des conséquences néfastes peut être créée. Cette liste permet de se concentrer sur les menaces réelles.

    Celles-ci peuvent être identifiées de différentes manières. La méthode STRIDE analyse les menaces en fonction des types d'attaques pouvant être menées. Le sigle STRIDE signifie Spoofing (usurpation d'identité), Tampering (falsification d'identité), Repudiation (reniement), Information disclosure (révélation des informations), Denial of Service (déni de service) et Elevation of Privilege (élévation des privilèges). D'autres mesures itératives sont également disponibles, consistant par exemple à classer les menaces par couches logiques (réseau, hôte et application, par exemple). Le choix de la méthode est laissé à l'appréciation de l'entreprise, selon les impératifs de son environnement.

  4. Catégoriser et classer les menaces : Cette étape fait intervenir les principes d'évaluation et de gestion des risques ; elle consiste à classer les menaces en fonction de leur réalité et de l'impact qu'elles pourraient avoir sur l'entreprise. La formule standard suivante est utilisée :

    Risque = Probabilité d'exploitation x Impact potentiel sur l'entreprise

    Plusieurs méthodes sont mises en œuvre au cours de cette étape, ainsi que des outils permettant d'évaluer les risques. Ceux-ci ne sont pas décrits dans cet article. Pour plus d'informations sur la gestion des risques et les méthodes utilisées, consultez le Guide de gestion des risques de sécurité à l'adresse http://go.microsoft.com/fwlink/?linkid=30794.

  5. Combattre et réévaluer : au cours des étapes précédentes, vous avez établi une liste des menaces réelles pesant sur votre entreprise, classées en fonction des risques qu'elles présentent pour le fonctionnement de cette dernière. Cette liste permet de déterminer les secteurs sur lesquels concentrer vos efforts, lesquels doivent également être évalués en fonction de leur rapport coût/bénéfice. Il peut exister différentes manières de combattre des risques spécifiques et certaines d'entre elles peuvent également s'appliquer à d'autres menaces, ce qui accroît leur efficacité.

Même après la mise en œuvre d'un plan de défense, la méthode de modélisation des menaces est un processus itératif qui doit être exécuté régulièrement, associé à une réévaluation constante des efforts de sécurité, afin que ceux-ci restent aussi efficaces et exhaustifs que possible.

Enquête sur les employés

La plupart des entreprises mènent une enquête sur leurs futurs salariés, mais ne la renouvellent pas une fois la personne embauchée. Il peut être utile d'effectuer ce type d'enquête régulièrement, notamment pour les employés qui occupent des postes critiques et ont accès aux informations confidentielles.

Accords sur l'utilisation des ressources

Les accords sur l'utilisation des ordinateurs ou du réseau sont importants, non seulement pour informer les employés sur l'utilisation qu'ils peuvent faire des ressources de l'entreprise, mais également sur les stratégies mises en œuvre pour surveiller l'activité du réseau et l'utilisation des ordinateurs, ainsi que sur les conséquences possibles des tentatives de violation des règles.

Ces documents prennent une dimension légale lorsqu'ils définissent ces règles en termes explicites et exigent l'accord de l'employé sous la forme d'une signature. Sans la preuve qu'un salarié avait connaissance des stratégies de surveillance de la sécurité en vigueur dans l'entreprise et de l'utilisation qu'il était autorisé à faire des ressources, il est très difficile de poursuivre l'auteur d'un délit.

Il est également important que les points d'accès au réseau d'une entreprise soient protégés par un message indiquant qu'il s'agit d'un réseau privé et que tout accès non autorisé est interdit et sera puni. Par exemple, les systèmes d'exploitation Windows peuvent afficher un message lors des tentatives d'ouverture de session, avertissant les utilisateurs qu'ils tentent d'accéder à une ressource protégée de l'entreprise et que tout accès non autorisé est interdit.

Il est important de signaler que ces documents et réglementations doivent exister, même si les aspects légaux liés à leur formulation exacte et à leur utilisation sortent du cadre de cet article. Vous pouvez trouver de nombreux exemples de ces documents sur Internet, mais il est préférable que ceux-ci soient préparés avec l'aide de conseillers juridiques qualifiés ; en effet, de nombreux aspects légaux régionaux et internationaux doivent être pris en compte lors de leur rédaction.

Séparation des tâches

Comme les différentes fonctionnalités des systèmes sont réparties sur un réseau dans un souci de sécurité, de performances et de disponibilité, il est également important de définir la séparation et la redondance des tâches lors de la planification du personnel requis pour un service de sécurité informatique.

Les rôles importants qui accèdent aux données et systèmes sensibles, et qui les contrôlent, doivent être redondants, dans la mesure du possible, non seulement pour éviter une perte de compétence en cas de départ d'un salarié, mais également pour maintenir la sécurité en cas de sabotage interne. Par exemple, si une seule personne connaît les mots de passe administrateur et qu'elle quitte la société sans les communiquer, les conséquences peuvent être graves.

Les rôles stratégiques doivent être d'une part redondants et d'autre part, séparés, notamment pour la surveillance de la sécurité. Le personnel chargé de gérer le réseau ne doit pas être également responsable d'analyser les informations d'audit de sécurité. De même, le personnel de sécurité ne doit pas disposer des mêmes droits administratifs que les administrateurs. Il est parfois nécessaire que le personnel administratif n'ait pas accès aux informations propres aux services, afin de renforcer la séparation des tâches. Par exemple, une entreprise peut se doter d'unités organisationnelles disposant de leurs propres systèmes ou comptes administratifs, dans un souci de protection des informations sensibles telles que celles concernant les finances ou les ressources humaines.

Remarque : bien qu'il soit difficile d'empêcher les détenteurs de comptes administrateur de contourner cette séparation des tâches, il est important de définir des règles régissant l'utilisation des droits d'administrateur fondées sur le principe de la séparation des tâches.

Validation de la fonctionnalité de surveillance de la sécurité

Avant d'implémenter une solution de surveillance de la sécurité, vous devez préparer un planning de test de cette solution. La phase de test initiale est essentielle pour la validation d'une solution de surveillance, mais le caractère changeant de l'environnement de sécurité exige des tests réguliers.

Vous pouvez par exemple effectuer des tentatives d'intrusion et tester les privilèges administratifs afin de déterminer si la solution est efficace pour détecter ce type d'activité. Il est également important de rester au fait des techniques de sécurité et des profils d'attaque pour déterminer si d'éventuelles modifications doivent être apportées. Les menaces pesant sur les réseaux d'entreprise sont en constante évolution, dans la mesure où les attaquants s'adaptent aux mesures de sécurité mises en œuvre ; les méthodes de défense et les techniques de surveillance doivent donc également évoluer pour rester efficaces.

Établissement de processus

Pour distinguer les événements de sécurité autorisés de ceux qui ne le sont pas, il est indispensable de créer un plan portant sur le contrôle des modifications obligatoires et les processus de gestion des problèmes. Ce plan peut prévoir la création de documents détaillés à mettre en corrélation avec les informations des journaux de sécurité. Dans la plupart des entreprises, des processus tels que l'émission de tickets d'assistance sont mis en place pour assurer le suivi des problèmes, mais le contrôle des modifications est souvent négligé. Il s'agit pourtant d'un mécanisme nécessaire, permettant non seulement d'identifier les systèmes ou les applications posant problème, mais également de renforcer la sécurité.

Les processus de contrôle des modifications doivent être exécutés de manière proactive. Les modifications doivent se limiter à l'utilisation d'un processus de gestion des problèmes. Dans le cadre d'un processus de contrôle des modifications, celles-ci doivent être soumises et approuvées avant d'être effectuées. Les informations suivantes sont requises :

  • Nom de l'approbateur

  • Nom de l'implémenteur

  • Date de la modification

  • Motifs de la modification

  • Nature de la modification

  • Systèmes affectés par la modification

  • Impact sur l'entreprise

  • Résultat réel de la modification

Un processus d'attribution de privilèges d'accès doit être mis en place via une procédure d'ajout/modification/suppression d'utilisateur, qui permettra également de créer un suivi d'audit destiné à empêcher toute modification non autorisée des comptes. Avant d'établir ce processus, un audit de sécurité des comptes existants doit être effectué afin de vérifier la validité de ces comptes et de valider cette liste à mesure qu'elle évolue.

L'utilisation de solutions automatisées d'attribution de privilèges d'accès et de gestion des identités, telles que Microsoft Identity Integration Server (MIIS) 2003, peut être utile. Cette solution automatise également les modifications des comptes et les processus sous-jacents. Si vous optez pour ce type de solution, n'oubliez pas que les comptes administrateur conservent le droit de créer de nouveaux comptes mais que ce privilège n'est pas indispensable dans la mesure où les comptes sont créés par un processus automatique. Par conséquent, les événements associés à la création de comptes, tel que l'événement 624, doivent être uniquement liés à MIIS 2003 ou à un autre compte de service établi utilisé pour l'attribution de privilèges d'accès automatique.

Bien que les médias fassent constamment état des menaces externes pesant sur les réseaux d'entreprise, l'expérience montre que les réseaux et les données d'entreprise sont bien plus vulnérables aux dommages causés par des configurations incorrectes ou des erreurs de procédure. Il est essentiel de prévoir une protection contre les menaces externes et internes ; de nombreux fournisseurs proposent des protections contre les menaces externes, mais aucun ne peut vous garantir que le personnel chargé de la gestion du réseau et de la sécurité ne commettra jamais d'erreurs. La meilleure manière de minimiser ce type de risque consiste à implémenter des processus et des procédures intelligents de contrôle des modifications effectuées sur le réseau.

Définition des réactions en cas d'incident

Pour limiter les dommages dus à une faille de sécurité, vous devez établir un plan de réaction approprié et des processus de réaction en cas d'incident. Des mesures telles que la création de rapports d'incident, la mise en place d'une équipe chargée d'intervenir rapidement en cas d'incident et l'établissement d'un protocole de réaction d'urgence peuvent faire partie de ce plan. Des réactions rapides et efficaces en cas d'incident contribuent à améliorer le profil de sécurité d'une entreprise et à limiter les dommages réels et ressentis causés par une tentative d'intrusion.

L'établissement d'un processus de réaction en cas d'incident permet non seulement de limiter les dégâts provoqués par ce type d'incident, mais également de dissuader les éventuels utilisateurs malveillants, en les informant que toute violation des règles de sécurité entraînera une réaction organisée et immédiate.

Ressources humaines

Selon des enquêtes réalisées par le CERT et les services secrets américains, de nombreuses attaques provenant de sources internes pourraient être déjouées si les entreprises remarquaient les changements de comportement des employés et prenaient les mesures appropriées. Les salariés d'une entreprise sont probablement les meilleurs agents de sécurité qu'elle puisse avoir ; ils sont en effet à même de noter le mécontentement grandissant d'un employé ou le comportement suspect d'un visiteur, et d'alerter le personnel de sécurité. En fait, l'une des premières tâches d'un groupe d'audit de sécurité extérieur consiste à rechercher les mots de passe notés sur papier, à repérer les machines non sécurisées ou à tenter de se connecter directement au réseau interne.

Le personnel d'une entreprise peut constituer un écran de protection non négligeable contre les menaces internes et externes. Encourager les salariés à signaler les comportements inquiétants de leurs collègues et apprendre au personnel de support à prendre au sérieux les remarques des employés concernant des activités inhabituelles peut grandement contribuer à lutter contre les tentatives d'intrusion ou les incidents liés à des logiciels malveillants. Une politique de formation interne doit également être menée pour apprendre aux employés à identifier les types de comportements devant être signalés. Cette formation fait également office de mesure préventive pour éviter les attaques par ingénierie sociale.

Mise en corrélation des violations des règles de sécurité et des événements d'audit

La mise en corrélation des informations sur les événements de sécurité consiste à collecter les événements de sécurité sur plusieurs systèmes et à centraliser ces données dans un endroit sûr. Une fois les informations de sécurité mises en corrélation, le personnel approprié peut analyser ce référentiel central pour identifier les violations ou les attaques externes. Ce référentiel sert non seulement à l'analyse des dommages, mais également à la détection des attaques et des points faibles. Les produits et outils Microsoft ci-dessous mettent en corrélation les journaux de sécurité et les autres informations de surveillance de la sécurité dans un référentiel central (il existe également de nombreuses solution tierces qui effectuent ces opérations).

EventCombMT

EventCombMT (multithread) est un composant décrit dans le document Introduction à la sécurité sur Windows Server 2003 , disponible à l'adresse http://go.microsoft.com/fwlink/?LinkId=14845. Cet outil analyse et collecte les événements des journaux d'événements stockés sur plusieurs ordinateurs. Il s'exécute en tant qu'application multithread et permet à l'utilisateur de spécifier les paramètres de son choix pour l'analyse des journaux d'événements, notamment :

  • Un ou plusieurs ID d'événement

  • Des plages d'ID d'événement

  • Des sources d'événement

  • Un texte d'événement spécifique

  • Un âge d'événement en minutes, heures ou jours

Cc875806.SMAAD4(fr-fr,TechNet.10).gif

Figure 4. EventCombMT

Certaines catégories de recherche spécifiques sont intégrées à EventCombMT, telles que les verrouillages de comptes (illustrés dans la figure ci-dessus), afin de permettre la recherche des événements suivants :

  • 529. Échec d'ouverture de session (nom d'utilisateur inconnu ou mot de passe incorrect)

  • 644. Compte d'utilisateur verrouillé automatiquement

  • 675. Échec de la pré-authentification sur un contrôleur du domaine (mot de passe incorrect)

  • 676. Échec de la demande de ticket d'authentification

  • 681. Échec d'ouverture de session

Il existe un autre événement de sécurité (12294), qui ne réside pas dans le journal de sécurité mais dans le journal système. Cet événement doit être ajouté aux recherches, car il permet de détecter les tentatives d'attaque contre le compte Administrateur. Celui-ci n'est pas associé à un seuil de verrouillage, ce qui en fait une cible tentante pour un éventuel utilisateur malveillant.

Remarque : l'événement 12294 apparaît comme un événement du gestionnaire de comptes de sécurité (SAM, Security Accounts Manager) dans le journal système, mais pas dans le journal de sécurité.

EventCombMT peut enregistrer les événements dans une table de base de données Microsoft SQL Server™ à des fins de stockage à long terme et d'analyse. Une fois stockées dans une base de données SQL Server, les informations issues des journaux d'événements sont accessibles via de nombreux programmes tels que SQL Query Analyzer, Microsoft Visual Studio® .NET ou d'autres utilitaires tiers.

Log Parser 2.2

Log Parser est un outil gratuit proposé par Microsoft, qui permet de rechercher des données dans un journal, de charger des journaux dans une base de données SQL ou un fichier CSV et de générer des rapports à partir de journaux d'événements, de fichiers CSV ou d'autres formats de journaux (y compris IIS, pour lequel il a été conçu à l'origine).

Cet outil de script en ligne de commande permet de mettre en corrélation les informations des journaux d'événements dans un référentiel central, d'effectuer une analyse syntaxique des événements pertinents et de générer des rapports. Il mérite une description détaillée qui sort du cadre de cet article. Pour plus d'informations sur Log Parser, son utilisation et les ressources de script, visitez la page Log Parser 2.2 à l'adresse www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx (cette page peut être en anglais) et consultez l'article consacré au fonctionnement de Log Parser 2.2 à l'adresse www.microsoft.com/technet/community/columns/profwin/pw0505.mspx (cet article peut être en anglais).

EventQuery.vbs

L'outil EventQuery.vbs a été introduit avec Windows XP. Il permet de répertorier les événements et les propriétés d'événements issus d'un ou plusieurs journaux. Pour que ce script puisse être utilisé, l'hôte de script de ligne de commande (CScript.exe) doit être en cours d'exécution. Si l'hôte de script Windows par défaut n'a pas été défini sur CScript, exécutez la commande suivante pour y remédier :

Cscript //h:cscript //s //nologo

Cet outil de script de ligne de commande est très souple ; ses résultats peuvent être filtrés et mis en forme à l'aide de nombreux paramètres. Pour plus d'informations sur cet outil et les paramètres disponibles, consultez la page consacrée à la gestion des journaux d'événements à partir de la ligne de commande dans la documentation relative à Windows XP Professionnel à l'adresse www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/event_commandline.mspx?mfr=true (cette page peut être en anglais).

Journalisation IIS (Internet Information Services)

La fonction de journalisation supplémentaire fournie avec IIS permet d'établir des rapports sur l'identité des visiteurs d'un site, sur les pages qu'ils ont visitées et sur la date d'accès. Les journaux IIS enregistrent les tentatives d'accès, fructueuses ou non, aux sites, dossiers virtuels et fichiers. Ils peuvent être configurés pour un audit sélectif de ces informations afin de limiter les besoins en termes de stockage et l'enregistrement d'informations inutiles.

Ces journaux peuvent être stockés dans un format natif sous forme de fichier, qui peut ensuite être filtré à l'aide de l'un des outils d'analyse syntaxique et de collecte mentionnés ci-dessus, ou dans un emplacement centralisé via la journalisation de base de données ODBC, qui permet de stocker les informations dans une base de données SQL ou une autre base de données compatible avec ODBC.

Certaines activités et séquences d'événements doivent être étroitement surveillées, par exemple :

  • Multiples tentatives infructueuses d'exécution de fichiers ou de scripts.

  • Nombre excessif d'échecs d'ouverture de session à partir d'une même adresse ou plage d'adresses IP, ce qui peut indiquer une tentative de déni de service ou d'élévation des privilèges.

  • Échecs de tentatives d'accès ou de modification de fichiers .bat ou .cmd.

  • Tentatives non autorisées de chargement des fichiers dans un dossier contenant des fichiers exécutables.

Depuis Windows Server 2003, de nouvelles fonctions d'audit sont intégrées à IIS. Vous pouvez les utiliser avec les nouvelles fonctions de journalisation d'IIS, les intégrer directement au journal d'événements ou y accéder via des pages ASP pour créer des solutions personnalisées. Pour plus d'informations sur ces fonctions et leur implémentation, consultez la documentation relative à IIS.

Microsoft Internet Security and Acceleration Server

Microsoft Internet Security and Acceleration (ISA) Server est un pare-feu avancé offrant des fonctions d'inspection des paquets avec état et de la couche application, ainsi que des fonctions de réseau privé virtuel et de mise en cache de proxy.

Outre sa fonction de défense, ISA Server assure également une fonction de surveillance de la sécurité en agissant comme un outil de journalisation centralisé capable de surveiller toutes les activités se déroulant à la périphérie d'un réseau. Parmi les fonctions de journalisation d'ISA Server figurent la possibilité de capturer le trafic transitant par le pare-feu, l'activité du proxy Web et les journaux de filtrage des messages SMTP. Ces journaux peuvent être filtrés, interrogés ou surveillés en temps réel à l'aide de la visionneuse de journal en temps réel intégrée (illustrée ci-dessous) ou du tableau de bord de surveillance.

Cc875806.SMAAD5(fr-fr,TechNet.10).gif

Figure 5. Visionneuse de journal en temps réel de Microsoft ISA Server 2004

Outre la journalisation intégrée, ISA Server propose une fonction capable de générer des alertes par courrier électronique ou via des entrées dans le journal des événements, ainsi que de démarrer ou d'arrêter des services. La fonction de consignation des activités suspectes dans le journal des événements s'inscrit exactement dans le cadre de cet article. Cette fonction permet d'enregistrer et de stocker les informations relatives aux attaques potentielles dans un emplacement centralisé, avec les autres données du journal des événements.

Au-delà des fonctions de journalisation et d'alerte, des outils de détection des intrusions intégrés peuvent être activés dans ISA Server. Ces services de base de détection des intrusions (IDS, Intrusion Detection Services) font partie d'ISS et comprennent plusieurs filtres de paquets IP, ainsi que des filtres d'applications DNS et POP. Ils sont en mesure de détecter la plupart des attaques courantes.

La fonction de détection des intrusions d'ISA Server peut consigner des événements et générer des alertes lorsque des attaques potentielles sont détectées. Elle peut également mettre fin à des services ou à des connexions suspectes. Les profils d'attaque suivants peuvent être détectés :

  • WinNuke (attaques hors bande Windows)

  • Attaques sur le terrain

  • Attaques de type semi-balayage IP

  • Bombes UDP

  • Balayages de ports

  • Attaques de dépassement de longueur de nom d'hôte DNS

  • Transferts de zone DNS à partir de numéros de ports TCP/IP privilégiés ou élevés

Que vous utilisiez ISA Server ou une autre solution de pare-feu ou de détection des intrusions, il est important de tenir compte du réseau périphérique (également appelé DMZ, zone démilitarisée ou sous-réseau filtré) lors de la conception d'un système de surveillance de la sécurité et de détection des attaques.

Microsoft Operations Manager 2005

Microsoft Operations Manager (MOM) gère plusieurs serveurs depuis un emplacement central dans un environnement d'entreprise. L'agent MOM collecte les événements des journaux d'événements et les transmet au serveur de gestion MOM, qui les place dans la base de données MOM. MOM 2005 et versions suivantes peuvent collecter des événements sur les ordinateurs n'exécutant pas les agents MOM.

MOM utilise les règles de son pack de gestion pour identifier les problèmes qui ont un impact sur l'efficacité des serveurs. D'autres règles peuvent être créées pour gérer des événements spécifiques et, lorsque ces événements se produisent, envoyer des notifications d'alerte par courrier électronique, via des messages contextuels ou directement sur des récepteurs de radiomessagerie.

Bien qu'il offre de nombreuses fonctions utiles pour la surveillance de la sécurité et la détection des attaques, MOM n'a pas été conçu dans cette optique. Les prochaines versions de MOM comporteront des fonctions de collecte d'événements de sécurité plus avancées.

Microsoft Systems Management Server 2003

Microsoft Systems Management Server (SMS) 2003 peut surveiller et gérer les serveurs et les stations de travail d'un réseau depuis un emplacement central. Bien qu'il soit principalement dédié aux tâches de gestion, il peut également assurer des fonctions de sécurité essentielles dans le cadre d'une solution de surveillance de la sécurité en gérant la distribution des mises à jour de sécurité et en signalant les installations de logiciels non autorisés.

La fonction d'inventaire de SMS fait office de solution de gestion des stocks centralisée en temps réel, essentielle dans le processus de surveillance et d'audit de la sécurité.

Implémentation de l'analyse des dommages

L'analyse des dommages est un sujet à part entière, que cet article ne peut couvrir intégralement. Par exemple, il ne traite pas de la gestion des preuves indispensable à l'analyse des dommages, ni des données autres que celles fournies par les journaux d'événements de sécurité.

L'analyse des dommages permet de déterminer la date, la gravité et les conséquences des problèmes de sécurité et d'identifier les systèmes affectés par les attaques. Pour être utiles, les informations recueillies à des fins d'analyse des dommages doivent mentionner les éléments suivants :

  • Date/heure d'une attaque

  • Durée d'une attaque

  • Systèmes affectés par une attaque

  • Modifications apportées au cours d'une attaque

Du fait de la complexité des règles régissant l'établissement des preuves, des types de données clés de l'analyse des dommages, des outils requis pour l'analyse, la collecte et la conservation des preuves, ainsi que des méthodes d'analyse, il nous est impossible de traiter ce sujet en détail dans le cadre de ce document. Toutefois, des ressources précieuses, telles que le First Responders Guide to Computer Forensics (guide du premier répondant pour l'analyse des dommages informatiques) du CERT (www.cert.org/archive/pdf/FRGCF_v1.3.pdf), sont disponibles sur des sites spécialisés dans le domaine de la sécurité.

Problèmes propres à l'entreprise

La planification de l'utilisation de l'analyse des dommages diffère de celle des autres approches, dans la mesure où elle implique l'examen des incidents a posteriori, et non en temps réel. Un historique détaillé des événements survenus sur plusieurs systèmes doit être conservé pendant une période prolongée. En raison de cette exigence spécifique, un système efficace d'analyse des dommages doit être centralisé et disposer d'une capacité de stockage considérable afin que de très nombreux enregistrements puissent être conservés dans une structure de base de données appropriée.

L'une des premières décisions que doit prendre l'entreprise concerne la durée pendant laquelle ces enregistrements seront conservés à des fins d'analyse des dommages, ainsi que le choix du type de cycle de conservation. Ces facteurs peuvent avoir un impact considérable sur les conditions de stockage et les équipements requis pour un plan d'analyse des dommages. Le tableau ci-dessous indique les durées de conservation généralement observées dans les entreprises ayant mis en place des plans d'analyse des dommages.

Tableau 2. Conditions de stockage requises pour l'analyse des dommages

Type de stockage

Durée de stockage

Commentaires

Stockage en ligne (base de données)

21 jours

Permet un accès rapide aux détails des événements

Stockage hors ligne (sauvegarde)

180 jours

Durée d'archivage raisonnable pour la plupart des entreprises

Environnement réglementé

7 ans

Durée d'archivage requise pour les entreprises soumises à des réglementations

Agences de renseignements

Permanente

Conditions d'archivage requises pour les organismes de défense et de renseignements


Remarque : dans certains secteurs d'activité réglementés (ceux qui gèrent des dossiers médicaux, par exemple), l'on utilise des règles du type « ne pas conserver plus longtemps que » au lieu de durées de conservation établies.

Une option possible consiste à utiliser des bases de données en ligne pour stocker les données d'analyse des dommages en ligne et à archiver les événements plus anciens dans un format texte (valeurs séparées par des virgules ou CSV, par exemple) pouvant être compressé à des fins de stockage hors ligne. S'il y a lieu, les fichiers CSV peuvent être réimportés dans la base de données en ligne pour être analysés.

Quelle que soit la solution choisie, assurez-vous qu'elle permet à l'entreprise d'analyser rapidement les événements récents, tout en lui offrant la possibilité de récupérer les événements plus anciens en cas de besoin. Un historique des incidents de sécurité survenus dans une entreprise associé à une liste des ressources disponibles doit permettre d'établir un plan définissant la meilleure combinaison possible de durées de conservation des données, pour les stockages en ligne et hors ligne. Si possible, testez le système de collecte des événements dans une base de données d'assez grande taille avec les rapports à exécuter et vérifiez que ceux-ci sont créés suffisamment vite et fournissent des informations exploitables.

La sécurité des données d'analyse des dommages doit également être prise en compte ; en effet, l'accès à ces informations n'est que rarement nécessaire. Si l'accès est requis, il doit être accordé uniquement à certains membres de confiance du personnel de sécurité. L'accès des administrateurs à ces informations doit faire l'objet de réglementations strictes et un processus de contrôle des modifications sécurisé doit être mis en place. Personne d'autre ne doit pouvoir accéder à ces données, en interrompre la collecte ou les modifier.

Problèmes techniques

Lors de la planification d'une solution de surveillance de la sécurité incluant l'analyse des dommages, des mesures doivent être prises pour permettre une collecte et un stockage sûrs et fiables d'un très grand nombre d'événements. Les exigences relatives à la surveillance de la sécurité sont les mêmes que celles décrites dans les autres scénarios, mais les ressources en termes de stockage de base de données et d'efficacité de la gestion des données sont bien supérieures.

Les difficultés techniques à prendre en compte sont les suivantes :

  • Stockage fiable et sûr des données en ligne.

  • Attribution d'une grande quantité d'espace disque hautes performances pour le stockage en ligne.

  • Systèmes de sauvegarde fiables pour stocker les événements anciens sur des supports d'archivage.

  • Processus de gestion des archives fiables.

  • Processus de restauration éprouvés pour extraire les informations des supports de sauvegarde.

Ces difficultés ne sont pas propres à la surveillance de la sécurité ; les administrateurs de bases de données les rencontrent également lors de la gestion des bases de données de traitement en ligne des transactions (OLTP). Toutefois, contrairement aux applications de base de données traditionnelles telles qu'OLTP, une base de données d'analyse des dommages doit faire face à un nombre d'opérations d'écriture nettement supérieur au nombre d'opérations de lecture.

Configuration requise

Pour préparer un programme efficace d'analyse des dommages, les conditions suivantes doivent être remplies :

  • Les paramètres de journalisation de sécurité sont configurés correctement.

  • Des processus sûrs de vérification des entrées des journaux sont établis.

  • Un point et un processus de collecte sûrs et centralisés sont créés pour les journaux de sécurité.

  • Les informations de surveillance de la sécurité sont stockées en lieu sûr.

  • Des plans et des plannings d'archivage efficaces sont mis en place.

Les exigences, capacités et restrictions réglementaires d'un environnement d'entreprise doivent être prises en compte lors de la préparation de la solution d'analyse des dommages, car ces aspects diffèrent d'un environnement à un autre.

Déploiement et gestion de la solution

L'objectif principal d'une solution de surveillance de la sécurité et de détection des attaques est d'être capable d'identifier une attaque, de la décrire et d'y répondre. La plus grande partie de cette section décrit en détail les événements qui, lorsqu'ils sont consignés dans un journal d'événements, peuvent indiquer qu'une attaque est en cours. Dans cette optique, une solution de surveillance de la sécurité et de détection des attaques doit être capable :

  • de détecter les violations des règlements internes ;

  • d'identifier les attaques provenant de sources externes ;

  • de déclencher une analyse des dommages efficace et précise.

Pour chacune de ces conditions, la solution décrite dans cet article fait appel à des composants similaires. D'autres conditions, présentées ultérieurement, doivent être remplies pour l'implémentation des fonctions d'analyse des dommages.

Surveillance de la sécurité et détection des attaques

La conception d'une solution de surveillance de la sécurité et de détection des attaques passe par la planification des niveaux appropriés d'audit de sécurité pour les secteurs suivants :

  • Gestion des comptes

  • Accès aux fichiers protégés

  • Modification de la stratégie de sécurité

  • Création et suppression d'approbations

  • Utilisation des droits utilisateur

  • Redémarrages du système et modifications de date/heure

  • Modifications du registre

  • Exécution de programmes inconnus

Le système de surveillance de la sécurité et de détection des attaques collecte les informations des journaux d'événements de sécurité et les rassemble dans un emplacement central. Les auditeurs de sécurité peuvent ensuite rechercher les activités suspectes dans ces données. Celles-ci peuvent être stockées et archivées à des fins d'analyse des dommages, s'il y a lieu.

Cette solution repose sur la configuration d'une fonction de Microsoft Windows 2003 avec Service Pack 1 (SP1) et Microsoft Windows XP avec Service Pack 2 (SP2), appelée audit par utilisateur. Les audits par utilisateur permettent de spécifier des niveaux d'audit différents pour les comptes d'utilisateur, afin que les comptes sensibles ou suspects puissent faire l'objet d'audits plus détaillés.

Configuration requise

La configuration de la solution de surveillance de la sécurité et de détection des attaques exige que les conditions suivantes soient remplies :

  • Les serveurs doivent exécuter Windows Server 2003 SP1 ou au-delà et résider dans un domaine Active Directory.

  • Les clients doivent exécuter Windows XP SP2 ou au-delà et être configurés en tant que membres d'un domaine Active Directory.

Remarque : si les ordinateurs situés à l'intérieur du périmètre d'une entreprise ne font pas partie d'un domaine, les paramètres de la stratégie de groupe Active Directory ne peuvent pas leur être appliqués. Les stratégies et les modèles locaux peuvent cependant être utilisés pour configurer ces systèmes.

Cet article est essentiellement consacré à l'identification des signatures caractéristiques des attaques. Il ne fournit aucun conseil relatif à la technologie à utiliser pour collecter les événements de sécurité mais indique toutefois un certain nombre de solutions possibles. Une fois le choix du mécanisme de collecte arrêté, les événements et séquences d'événements répertoriés dans ce document peuvent être utilisés pour créer des requêtes et des alertes destinées à détecter les comportements suspects.

Violations de stratégie et seuils

Microsoft Windows Server 2003 et Microsoft Windows XP avec SP2 proposent de nouvelles fonctions permettant de fixer des niveaux d'audit différents selon les comptes utilisateur. Par exemple, les niveaux d'audit peuvent être définis pour signaler uniquement les activités d'ouverture et de fermeture de session pour tous les utilisateurs, ou pour auditer toutes les activités d'un utilisateur donné. Vous pouvez également utiliser l'audit sélectif par utilisateur pour limiter le nombre d'événements consignés dans le journal de sécurité en n'activant pas l'audit de certaines activités pour des comptes spécifiques. Cette fonctionnalité permet uniquement d'auditer les comptes utilisateur ; elle ne concerne pas les groupes de sécurité et de distribution. Les comptes appartenant au groupe local Administrateurs ne peuvent pas être exclus de l'audit à l'aide de la fonction d'audit sélectif par utilisateur.

L'utilitaire en ligne de commande Auditusr.exe est utilisé pour la stratégie d'audit par utilisateur dans Windows Server 2003 et Windows XP SP2. Les catégories d'audit sélectif valides sont les suivantes :

  • Événement système

  • Ouverture/fermeture de session

  • Accès aux objets

  • Utilisation des privilèges

  • Suivi détaillé

  • Changement de stratégie

  • Gestion des comptes

  • Accès au service d'annuaire

  • Ouverture de session de compte

Exécuté à partir de la ligne de commande sans paramètre, Aauditusr.exe affiche les paramètres d'audit sélectifs actifs, qui sont d'ores et déjà vierges. Pour les définir, vous pouvez les entrer individuellement sur la ligne de commande ou globalement, en important un fichier de paramètres d'audit par utilisateur.

La syntaxe de Audituser.exe est la suivante :

Audituser.exe /paramètre CompteUtilisateur:”catégorie”

(ou une liste de catégories séparées par des virgules)

Par exemple, pour activer l'audit des échecs des événements système (SystemEvent) et des événements d'ouverture/fermeture de session (Logon/Logoff) pour le compte UtilisateurLocal, tapez la ligne de commande suivante :

Audituser /if UtilisateurLocal:”System Event”,”Logon/Logoff”

Les paramètres suivants peuvent également être indiqués sur la ligne de commande :

  • /is – ajoute ou modifie une entrée include-success

  • /if – ajoute ou modifie une entrée include-failure

  • /es – ajoute ou modifie une entrée exclude-success

  • /ef – ajoute ou modifie une entrée exclude-failure

  • /r – supprime toutes les entrées d'audit par utilisateur pour un compte utilisateur donné

  • /ra – supprime toutes les entrées d'audit par utilisateur pour tous les comptes utilisateur

  • /e – exporte les paramètres vers le fichier indiqué

  • /i – importe les paramètres à partir du fichier indiqué

Un fichier de paramètres d'audit par utilisateur est un fichier texte brut utilisant le format décrit dans la figure ci-dessous.

Figure 6. Exemple de fichier d'importation Auditusr.exe

Figure 6. Exemple de fichier d'importation Auditusr.exe

Remarque : le fichier d'importation doit commencer par la ligne “Auditusr 1.0”, comme indiqué, pour que l'importation aboutisse.

Par exemple, pour importer le fichier de paramètres d'audit illustré ci-dessus, il conviendrait d'utiliser la commande suivante :

Audituser /i chemin\audit.txt

Cet utilitaire permet de définir des seuils pour la consignation des informations d'audit, afin de limiter les besoins en termes de stockage et d'augmenter les chances de détecter les tentatives d'intrusion.

Violations de stratégie de sécurité et mise en corrélation des événements d'audit

Bien que cette section n'opère aucune distinction entre les violations de stratégie provenant de sources externes ou internes, il est important de préciser que les failles de sécurité internes peuvent se révéler tout aussi dangereuses pour une entreprise que les attaques venant de l'extérieur. Comme indiqué précédemment dans cet article, un pourcentage non négligeable d'attaques proviennent de sources internes. Ce pourcentage n'inclut pas les dommages accidentels causés par une utilisation de privilèges élevés hors du cadre des procédures établies.

Le risque lié à l'utilisation involontaire ou intentionnelle de privilèges élevés par des sources internes étant important, des stratégies et des procédures régissant l'utilisation de ces privilèges doivent être établies, ainsi que des suivis d'audit pour la mise en corrélation croisée. Après la mise en place d'un processus de gestion des modifications et d'une stratégie de documentation, une corrélation peut être développée pour mettre en correspondance les informations d'audit et les événements approuvés et non approuvés, et ce afin de détecter les comportements inhabituels au sein d'une entreprise. Pour vous aider à réaliser cette mise en corrélation, vous trouverez dans cette section une description des différents types d'événements pouvant être tracés et de leur application à des stratégies et des processus.

Accès à des ordinateurs non autorisés

Les personnels administratifs et de support recourent de plus en plus aux fonctions de gestion à distance telles que les services Terminal Server, pour se connecter à des systèmes distants et les administrer. Ces systèmes doivent être surveillés afin de détecter les tentatives d'ouverture de session interactives et la validité de chaque tentative doit être vérifiée. Au cours de ces vérifications, les opérations suivantes doivent être effectuées :

  • Identification des ouvertures de session par des comptes de service.

  • Enregistrement des tentatives d'accès par des comptes non autorisés.

  • Enquête sur les tentatives d'accès depuis des zones géographiques inhabituelles.

  • Établissement d'une liste de tentatives depuis des plages d'adresses IP externes.

Une attention particulière doit être accordée aux ressources à valeur élevée. Ces ressources critiques doivent résider sur des serveurs spécifiques paramétrés pour un audit et un contrôle d'accès stricts.

Le tableau ci-dessous répertorie les événements d'audit d'ouverture de session, qui doivent être comparés aux listes de comptes autorisés lorsqu'ils se produisent sur des systèmes contenant des ressources à valeur élevée.

Tableau 3. Événements relatifs à l'utilisation non autorisée des ordinateurs

ID d'événement

Occurrence

Commentaires

528

Ouverture de session réussie

Vérifiez les noms de la station de travail et du compte utilisateur. Assurez-vous que l'adresse réseau source réside bien dans un réseau.

529

Échec d'ouverture de session – Nom d'utilisateur inconnu ou mot de passe incorrect

Vérifiez les tentatives pour lesquelles le nom de compte cible Administrateur est utilisé (ou le compte administrateur par défaut si son nom est différent). Vérifiez également si plusieurs échecs d'ouverture de session se sont produits sans dépasser le seuil de verrouillage du compte.

530

Échec d'ouverture de session – Restrictions d'horaires d'accès

Indique une tentative d'ouverture de session effectuée hors de la plage horaire autorisée. Vérifiez les noms du compte utilisateur et de la station de travail.

531

Échec d'ouverture de session – Compte actuellement désactivé.

Vérifiez les noms du compte cible et de la station de travail. Cet événement signale une tentative d'intrusion par un utilisateur qui n'est plus actif ; une enquête doit être menée.

532

Échec d'ouverture de session – Compte utilisateur arrivé à expiration

Vérifiez les noms du compte cible et de la station de travail. Cet événement peut indiquer une tentative d'accès par un sous-traitant ou un employé intérimaire ; une enquête doit être menée.

533

Échec d'ouverture de session – Utilisateur non autorisé à ouvrir une session sur cet ordinateur

Indique qu'un utilisateur tente d'ouvrir une session sur une station de travail réservée.

534

Échec d'ouverture de session – Type d'ouverture de session non autorisé

Vérifiez les noms du compte cible et de la station de travail, ainsi que le type d'ouverture de session. Cet événement indique un échec d'ouverture de session interactive à l'aide des informations d'identification d'un compte de service alors que les paramètres de stratégie de groupe interdisent les ouvertures de session par ce type de compte.

535

Échec d'ouverture de session – Mot de passe arrivé à expiration

Indique qu'un utilisateur tente d'ouvrir une session avec un compte dont le mot de passe est arrivé à expiration. Une enquête peut être nécessaire si les tentatives se répètent sans que le mot de passe soit modifié ou le service d'assistance contacté.

536

Échec d'ouverture de session – Composant NetLogon inactif

Vérifiez que le service NetLogon est opérationnel. Si tel n'est pas le cas, cet événement peut nécessiter une enquête.

540

Ouverture de session réussie

Cet événement est l'équivalent réseau de l'événement 528.

Chevaux de Troie, rootkits et logiciels malveillants

L'ID d'événement 592, créé à chaque démarrage d'un nouveau processus, est particulièrement utile pour détecter l'utilisation des chevaux de Troie, des rootkits et autres logiciels malveillants. Lorsque cet événement se produit et que le nom du fichier image ne correspond à aucun processus répertorié dans la liste des programmes autorisés, une enquête doit être menée immédiatement.

Contrairement aux chevaux de Troie et aux enregistreurs de frappes, qui sont assez faciles à identifier, les rootkits sont particulièrement discrets. Pour les repérer, vous devez rechercher les programmes inconnus qui ne cessent de démarrer et de s'arrêter. Toutefois, une fois un rootkit lancé, le système d'exploitation ne peut pas le détecter et aucun événement n'est généré.

Les attaques de logiciels malveillants peuvent prendre la forme de pièces jointes à des courriers électroniques ou de sites Web infectés. Elles peuvent recourir à une élévation des privilèges lorsque le compte qui les exécute n'est pas autorisé à lancer de nouveaux programmes. Dans ce type de situation, les logiciels non autorisés doivent générer un événement d'échec qui doit faire l'objet d'une enquête, notamment lorsque les événements suivants se produisent :

  • Processus générés en tant que LocalSystem : les processus s'exécutant en tant que LocalSystem doivent être bien définis dans une liste de programmes autorisés ; ils peuvent inclure des processus tels que Services.exe.

  • Processus générés à des heures inattendues : si le système surveillé n'utilise pas de processus par lots planifiés, certaines activités (sauvegardes, CGI ou scripts, par exemple) doivent faire l'objet d'une enquête lorsqu'elles se produisent. Sinon, une enquête doit être menée lorsque ces événements se produisent hors des heures d'exécution planifiées.

Tableau 4. Événement 592

ID d'événement

Occurrence

Commentaires

592

Création d'un nouveau processus

Si un processus non approuvé est lancé, en cas d'heure de lancement inattendue ou lorsque des programmes inconnus ne cessent de démarrer puis de s'arrêter, vérifiez les noms du fichier image et de l'utilisateur.

Accès aux ressources par modification des droits d'accès aux fichiers

Une personne peut utiliser les privilèges administratifs pour accéder aux fichiers auxquels elle n'a pas accès en modifiant la propriété des données et en ajoutant son compte à la liste de ceux ayant accès en écriture à ces données. Dans Windows Server 2003, cette personne peut dissimuler ses activités en rétablissant la propriété et les droits d'accès d'origine.

Sachant cela, il devient essentiel d'identifier les ressources et les données à valeur élevée ; en effet, implémenter l'audit d'accès aux objets pour tous les fichiers du réseau d'une entreprise de taille moyenne serait contre-productif en raison du nombre considérable d'accès qui se produisent quotidiennement. L'audit d'accès aux objets doit être activé pour les fichiers et les dossiers sensibles, dans la mesure où les entrées des listes de contrôle d'accès ne fournissent pas une protection suffisante contre les tentatives d'accès non autorisées.

Pour une détection efficace des activités illicites, les facteurs suivants doivent être facilement identifiables pour tous les fichiers à valeur élevée :

  • Quel objet a été la cible d'une tentative d'accès ?

  • Quel compte a été utilisé pour demander l'accès ?

  • Quel compte a autorisé l'accès ?

  • Quel type de tentative d'accès a été effectué ?

  • Un événement de réussite ou d'échec a-t-il été généré ?

  • Quel système a été utilisé pour effectuer la tentative ?

Les paramètres de filtrage de l'Observateur d'événements intégré ne permettent pas de déterminer ces informations. EventCombMT ou un autre mécanisme doit par conséquent être utilisé pour effectuer cette analyse.

Les événements d'audit d'accès aux objets répertoriés dans le tableau ci-dessous s'appliquent à ce type de tentative d'accès.

Tableau 5. Événements de modification des droits d'accès aux fichiers

ID d'événement

Occurrence

Commentaires

560

Accès accordé à un objet existant

Indique qu'une demande d'accès à un objet a été satisfaite. Vérifiez l'ID d'ouverture de session principal, le nom d'utilisateur du client et le nom de l'utilisateur principal pour détecter les accès non autorisés. Vérifiez le champ d'accès pour identifier le type d'opération. Cet événement détecte les demandes d'accès mais n'indique pas si un accès s'est réellement produit.

567

Permission associée à un pointeur utilisée

Indique la première instance d'un type d'accès à un objet et signale que les permissions ont été modifiées si le champ d'accès comprend « WRITE_DAC ». Mettez cet événement en corrélation avec l'événement 560 en comparant les champs d'ID de pointeur.

Accès aux ressources par réinitialisation des mots de passe

Les modifications de mot de passe doivent être effectuées dans le cadre approuvé de procédures établies. Des niveaux d'audit configurés correctement doivent enregistrer les événements de gestion des comptes répertoriés dans le tableau ci-dessous et mettre ces événements en corrélation avec les procédures établies afin d'identifier toute activité non conforme à ces procédures.

Tableau 6. Événements de réinitialisation de mot de passe

ID d'événement

Occurrence

Commentaires

627

Tentative de modification de mot de passe

Indique une demande de modification de mot de passe pour laquelle le demandeur a fourni le mot de passe d'origine. Comparez le nom du compte principal et le nom du compte cible pour déterminer si le compte demandeur est le compte qui a été modifié.

628

Mot de passe de compte utilisateur défini ou réinitialisé

Indique une réinitialisation de mot de passe effectuée à partir d'une interface administrative et non au moyen d'un processus de modification de mot de passe. Le demandeur doit être un compte autorisé tel qu'un compte de service d'assistance ou un compte de réinitialisation de mot de passe en libre-service.

698

Modification du mot de passe du mode de restauration des services d'annuaire

Indique une tentative de modification du mot de passe du mode de restauration des services d'annuaire sur un contrôleur de domaine. Vérifiez l'adresse IP de la station de travail et le nom du compte. Cet événement mérite une enquête immédiate.

Modification de compte utilisateur

Toute modification de compte, qu'il s'agisse d'un ajout, d'une suppression ou d'un changement, doit s'inscrire dans un processus établi impliquant une procédure logique à plusieurs étapes déclenchée par une demande officielle d'un employé occupant un poste de gestionnaire. Tous les événements répertoriés dans le tableau ci-dessous doivent correspondre à une demande de modification de compte officielle ou faire l'objet d'une enquête immédiate.

Tableau 7. Événements de modification de compte utilisateur

ID d'événement

Occurrence

Commentaires

624

Création d'un compte utilisateur

Indique la création d'un compte réseau.

630

Suppression d'un compte utilisateur

Indique la suppression d'un compte réseau.

642

Modification d'un compte utilisateur

Indique la modification d'un compte utilisateur touchant à la sécurité non couverte par les événements 627 à 630.

685

Modification du nom d'un compte utilisateur

Indique une modification du nom d'un compte utilisateur.


Pour une identification efficace des problèmes de gestion des comptes, des requêtes chargées d'effectuer les opérations suivantes doivent être configurées :

  • Rechercher les activités anormales ou inhabituelles liées aux comptes.

  • Identifier les comptes de niveau administrateur qui abusent de leurs privilèges pour créer ou modifier des comptes.

  • Détecter les schémas d'activités liées aux comptes qui sortent du cadre de la stratégie de sécurité de l'organisation.

Il est également important de vérifier l'intervalle entre la création d'un compte et la première ouverture de session avec modification du mot de passe. Si un nouveau compte n'est pas utilisé pendant une période donnée (la date de première utilisation d'un compte est généralement enregistrée lors de la création de celui-ci), il doit être désactivé et une enquête doit être menée pour déterminer la cause du retard.

Modifications d'appartenance aux groupes

Une sécurité efficace repose sur le principe du moindre privilège, qui consiste à accorder aux comptes le niveau d'accès minimal dont ils ont besoin pour réaliser les tâches qui leur incombent. Lorsque cette pratique est mise en œuvre, la plupart des comptes appartiennent au groupe des utilisateurs du domaine par défaut, certains faisant partie de groupes de sécurité propres à l'entreprise.

L'appartenance aux groupes de sécurité doit être modifiée uniquement dans le cadre de procédures établies, notamment lorsque des comptes disposant de privilèges élevés sont concernés. Ces modifications ne doivent être effectuées que par des comptes dédiés à la gestion des comptes et les événements correspondants doivent être mis en corrélation avec un processus de modification établi. Tout changement n'entrant pas dans le cadre de ce processus doit faire l'objet d'une enquête immédiate.

Les événements d'audit de gestion des comptes répertoriés dans le tableau ci-dessous se rapportent aux modifications d'appartenance aux groupes.

Tableau 8. Événements de modification d'appartenance aux groupes

ID d'événement

Occurrence

Commentaires

631, 632,
633, 634

Modification de groupe global activé pour la sécurité

Vérifiez le nom du compte cible pour déterminer si le groupe modifié était global ou disposait de privilèges d'accès étendus.

635, 636,
637, 638

Modification de groupe local activé pour la sécurité

Vérifiez le nom du compte cible pour déterminer si le groupe Administrateurs, Opérateurs de serveur ou Opérateurs de sauvegarde a été modifié.

639, 641,
668

Modification de groupe activé pour la sécurité

Indique une modification de groupe qui n'est ni une suppression, ni une création, ni une modification d'appartenance. Vérifiez le nom du compte cible pour déterminer si un groupe à privilèges élevés a été modifié.

659, 660, 661, 662

Modification de groupe universel activé pour la sécurité

Vérifiez le nom du compte cible pour déterminer si un groupe à privilèges élevés, tel que Administrateurs de l'entreprise, a été modifié.


Remarque : l'appartenance à un groupe de distribution ne donne pas accès aux ressources réseau car ces groupes ne sont pas des entités de sécurité. Toutefois, l'appartenance à certains groupes de distribution peut créer des problèmes. Par exemple, si des comptes utilisateur sont placés dans un groupe de distribution d'administration ou de direction, ils peuvent recevoir des messages électroniques qui ne leur sont pas destinés.

Tentatives d'utilisation de comptes non autorisés

La promotion du premier contrôleur de domaine Active Directory dans une forêt crée un compte administrateur qui appartient aux groupes Administrateurs du domaine et Administrateurs de l'entreprise. La protection de ce compte doit être sans faille car il est le seul à ne pas être affecté par les paramètres de verrouillage de compte. Par conséquent, même lorsqu'une stratégie de verrouillage est mise en place, ce compte est particulièrement vulnérable aux attaques par dictionnaire.

Une solution efficace de surveillance de la sécurité doit détecter toutes les tentatives d'ouverture de session avec ce compte administrateur, même s'il a été renommé. Pour plus d'informations sur le renforcement de la sécurité des comptes administrateur, consultez le Guide de planification de la sécurité des comptes administrateur à l'adresse http://go.microsoft.com/fwlink/?LinkId=41315.

En outre, les tentatives d'ouverture de session avec des comptes désactivés ou arrivés à expiration peuvent indiquer qu'un ancien employé, un intérimaire ou un sous-traitant a tenté d'accéder au réseau sans informations d'identification valides. Ces événements doivent donner lieu à une enquête immédiate.

Le tableau ci-dessous répertorie les événements qui révèlent une utilisation de comptes non autorisés, appartenant aux catégories d'audit d'ouverture de session de compte et d'ouverture de session.

Tableau 9. Événements d'ouverture de session non autorisée

ID d'événement

Occurrence

Commentaires

528

540

Ouverture de session réussie

528 est un événement courant. En revanche, lorsque l'événement 540 se produit, le nom du compte cible doit être examiné afin de déterminer si l'événement a été provoqué par le compte administrateur par défaut.

529

Échec d'ouverture de session – Nom d'utilisateur inconnu ou mot de passe incorrect

Effectuez une enquête lorsque le nom du compte cible est le compte Administrateur ou le compte administrateur par défaut renommé, ou encore si le nombre d'échecs d'ouvertures de session est tout juste inférieur au seuil de verrouillage. Vérifiez également si des tentatives utilisant le compte administrateur ou le compte racine comme compte cible ont été enregistrées, avec un nom de domaine inconnu.

531

Échec d'ouverture de session – Compte désactivé

Examinez le nom du compte cible et le nom de la station de travail pour identifier la source. Cet événement mérite une enquête car il peut signaler une tentative d'intrusion par un utilisateur qui n'est plus actif.

532

Échec d'ouverture de session – Compte expiré

Examinez le nom du compte cible et le nom de la station de travail pour identifier la source. Cet événement mérite une enquête car il peut signaler une tentative d'intrusion par un utilisateur qui n'est plus actif.

576

Privilèges spéciaux attribués à une nouvelle ouverture de session

Indique une attribution de privilèges qui peut accorder les droits d'administrateur ou l'autorisation de modifier le suivi d'audit à un nouveau compte utilisateur. Comparez le champ d'ID d'ouverture de session aux événements 528 ou 540 pour déterminer facilement si un compte a obtenu les privilèges administrateur ou équivalents.


Un autre problème de sécurité impliquant l'utilisation non autorisée d'informations d'identification découle des stratégies de mot de passe mises en œuvre (mots de passe sûrs et durées de validité brèves), qui peuvent inciter les utilisateurs à noter leur mot de passe afin d'être sûrs de ne pas les oublier. Ce problème existe particulièrement dans les environnements utilisant plusieurs banques d'identités sans services de gestion des identités, ce qui exige l'utilisation de mots de passe et de comptes multiples.

Remarque : pour plus d'informations sur la gestion des mots de passe dans les environnements hétérogènes, consultez les kits Microsoft de gestion des identités et des accès à l'adresse http://go.Microsoft.com/fwlink/?LinkId=14841.

Les entreprises doivent dissuader les utilisateurs de noter leur mot de passe, en particulier au vu et au su de tous, car des individus mal intentionnés pourraient découvrir ces informations et les exploiter pour lancer une attaque. La surveillance de ce type d'intrusion peut se faire à l'aide des informations du tableau ci-dessus, mais celles-ci doivent être mises en corrélation avec l'historique des ouvertures de session réussies pour le compte utilisateur concerné afin qu'une liste des stations de travail auxquelles ce compte accède fréquemment puisse être créée à des fins de comparaison.

Remarque : la fonctionnalité Active Directory intégrée permet de cantonner certains comptes utilisateur à des stations de travail spécifiques. Toutefois, pour que cette fonctionnalité puisse être utilisée, le réseau doit prendre en charge les conventions de dénomination NetBIOS (Network Basic Input/Output System) telles qu'elles sont fournies par le services WINS (Windows Internet Naming Service), par exemple.

Ouverture de session interactive avec informations d'identification de compte de service

Au démarrage, les services doivent présenter des informations d'identification d'ouverture de session. Certains services peuvent nécessiter l'utilisation d'un compte de domaine pour l'exécution de services ou la connexion à des ordinateurs distants. D'autres peuvent même requérir des informations d'identification administrateur ou devoir interagir également avec le Bureau.

Dans Windows Server 2003 et versions ultérieures, certains comptes de service (le service Alertes, par exemple) peuvent être lancés avec le commutateur –LocalService. En outre, les services exigeant une connectivité réseau peuvent faire appel au compte de service réseau AUTORITÉ NT\Service réseau. Tous les services qui nécessitent des comptes utilisateur doivent être contrôlés afin de vérifier que ces derniers sont protégés par des mots de passe sûrs. Une mesure de surveillance de la sécurité doit être mise en place pour vérifier que les événements d'ouverture de session pour ces comptes se produisent uniquement au démarrage des services associés. Pour plus d'informations sur la sécurité élevée des comptes de service, consultez le guide de planification des services et des comptes de service à l'adresse http://go.Microsoft.com/fwlink/?LinkId=41311 (ce document peut être en anglais).

Le principal problème de sécurité lié aux comptes de service se pose lorsque ceux-ci ouvrent des sessions de manière interactive, et non en tant que services. Ces événements se produisent uniquement lorsqu'un intrus a forcé l'accès à un compte de service et l'utilise pour ouvrir une session. Si le compte de service forcé dispose des privilèges d'administrateur, l'intrus a alors accès à de nombreuses fonctionnalités et peut perturber le fonctionnement normal des services réseau.

Toutes les ressources auxquelles les comptes de service ont accès doivent être identifiées ; aucune permission donnant accès à des données à valeur élevée ne doit être accordée sans justification. Par exemple, une compte de service peut nécessiter l'accès en écriture à un dossier de fichiers journaux, mais cela ne se produit que ponctuellement. Les comptes de service pouvant interagir avec le Bureau doivent également faire l'objet d'une attention accrue car ils fournissent de nombreux angles d'attaque aux agresseurs.

Le tableau ci-dessous répertorie les événements d'audit d'ouverture de session et de connexion de compte qui révèlent une utilisation non autorisée des informations d'identification des comptes de service.

Tableau 10. Événements d'ouverture de session avec informations d'identification de compte de service

ID d'événement

Occurrence

Commentaires

528

Ouverture de session réussie – Attaque console ou services Terminal Server

Si le type d'ouverture de session 10, un compte de service ou le compte système local est associé à cet événement, celui-ci indique une attaque en cours. Cet événement doit faire l'objet d'une enquête immédiate.

534

Échec d'ouverture de session – Type d'ouverture de session non autorisé

Indique l'échec d'une tentative d'ouverture de session interactive avec les informations d'identification d'un compte de service, interdite par les paramètres de stratégie de groupe. Lorsque cet événement se produit, vérifiez le nom du compte cible, le nom de la station de travail et le type d'ouverture de session.

600

Jeton principal attribué à un processus

Indique qu'un service utilise un compte nommé pour ouvrir une session sur un système exécutant Windows XP ou supérieur. Mettez en corrélation cet événement avec les informations des événements 672, 673, 528 et 592.

601

Tentative d'installation d'un service par un utilisateur

Cet événement doit être très rare dans un environnement d'entreprise dans lequel une stratégie relative aux applications acceptables et un processus de standardisation des systèmes clairement définis sont appliqués. Dans ce type d'environnement, cet événement doit faire l'objet d'une enquête en cas d'absence de corrélation des processus de contrôle des modifications.

Exécution de programmes non autorisés

Les comptes de niveau administrateur peuvent installer et exécuter des programmes, c'est pourquoi ils ne sont généralement attribués qu'à des personnes de confiance qui ont besoin de ces privilèges élevés. En raison des risques associés aux logiciels non testés, il est important d'établir une liste de logiciels sous licence et approuvés, ainsi qu'une procédure de demande, de test et d'approbation des nouvelles applications. Les applications non approuvées doivent être utilisées uniquement dans un environnement de test isolé ; elles ne doivent pas être installées dans un environnement réseau de production hors du cadre d'un processus de contrôle des modifications bien établi. Même lorsque ces conditions sont respectées, elles ne doivent être utilisées qu'après avoir été ajoutées à une liste de logiciels approuvés.

Le tableau ci-dessous répertorie les événements de suivi des processus pouvant indiquer que des programmes non autorisés sont utilisés.

Tableau 11. Événements d'exécution de programmes non autorisés

ID d'événement

Occurrence

Commentaires

592

Création d'un nouveau processus

Indique qu'un nouveau processus a été créé. Comparez le nom du fichier image et le nom d'utilisateur à la liste des programmes autorisés, s'il existe dans l'entreprise une stratégie relative aux programmes acceptables. Recherchez également les invites de commande lancées à l'aide de LocalSystem ; en effet, il s'agit d'une méthode bien connue pour échapper à un suivi d'audit.

602

Création d'une tâche planifiée

Lorsque ces événements se produisent à des horaires inattendus, examinez le nom de la cible et l'heure de la tâche.


Remarque : les audits de sécurité de suivi de processus peuvent identifier les programmes non autorisés. Toutefois, le suivi des processus génère de nombreuses entrées dans le journal de sécurité ; vous devez donc vérifier que le nombre d'événements n'est pas trop élevé pour les mécanismes de détection de sécurité.

Accès à des ressources non autorisées

Le tableau ci-dessous répertorie les événements d'audit d'accès aux objets impliquant des tentatives d'accès à des ressources qu'un utilisateur n'est pas autorisé à exécuter.

Tableau 12. Événements de tentative d'accès à des ressources non autorisées

ID d'événement

Occurrence

Commentaires

560

Accès refusé à un objet existant

Examinez le nom d'objet pour identifier la ressource concernée et mettez en corrélation le nom d'utilisateur principal et le domaine principal ou le nom d'utilisateur client et le domaine client pour déterminer l'origine de l'accès.

568

Tentative de création d'une liaison fixe vers un fichier audité

Indique qu'un utilisateur ou un programme a tenté de créer une liaison fixe vers un fichier ou un objet. Une liaison fixe établie permet à un compte de manipuler un fichier sans créer de suivi d'audit si le compte dispose de droits sur l'objet.

Utilisation de systèmes d'exploitation non autorisés

L'utilisation de systèmes d'exploitation non autorisés peut être à l'origine de graves problèmes, allant d'un affaiblissement de la sécurité favorisant les attaques à la probable altération des données des systèmes de fichiers. Pour introduire des systèmes d'exploitation non autorisés dans un réseau, les administrateurs et les utilisateurs peuvent employer les méthodes suivantes :

  • Ordinateurs personnels connectés au réseau localement ou à distance.

  • Utilisation de systèmes d'exploitation sur CD amorçables.

  • Réinstallation d'un système d'exploitation Windows.

  • Utilisation d'images Virtual PC.

Les stratégies de l'entreprise peuvent définir le mode de connexion au réseau des utilisateurs à partir d'emplacements distants via un réseau privé virtuel ou un service d'accès distant. Elles peuvent inclure des exigences relatives à la connexion des systèmes telles que le type de système d'exploitation, le niveau de mise à jour et l'installation de mesures de protection de type pare-feu et antivirus. Pour plus d'informations sur la conformité des systèmes distants avec les stratégies de sécurité de l'entreprise, consultez le guide de planification de l'implémentation des services de quarantaine avec un réseau privé virtuel Microsoft à l'adresse http://go.microsoft.com/fwlink/?LinkId=41307 (ce document peut être en anglais).

Les utilisateurs peuvent également redémarrer leur ordinateur à partir d'un CD d'installation de Windows XP afin d'installer un système d'exploitation non géré. Ce type d'activité peut être détecté en repérant les tentatives d'ouverture de session effectuées par des comptes administrateur à partir d'un nom de groupe de travail non identifié ou du groupe de travail par défaut.

Remarque : certains systèmes d'exploitation open source sont disponibles sur CD amorçable ; il n'est donc pas nécessaire de les installer sur le système local pour les utiliser. Le système d'exploitation n'étant pas effectivement installé sur l'ordinateur local, ce type d'activité est particulièrement difficile à repérer. Cependant, les tentatives d'ouverture de session effectuées par des comptes nommés « root » dans un environnement réseau homogène ou par des noms d'ordinateur inattendus peuvent signaler l'utilisation d'un système d'exploitation non autorisé. Pour empêcher ce type d'activité, désactivez la possibilité de démarrer à partir d'un CD dans les paramètres BIOS d'un ordinateur et protégez par mot de passe la configuration BIOS. Toutefois, cette approche n'est pas des plus commodes dans certains environnements.

Les images Virtual PC fournissent une émulation complète de l'environnement d'un ordinateur sur un système hôte. Cette émulation exécute dans un environnement virtuel son propre système d'exploitation avec son propre nom d'ordinateur, ses comptes utilisateur, sa structure de services d'annuaire et ses programmes. Étant donné qu'une instance Virtual PC peut démarrer, s'exécuter et s'arrêter indépendamment d'un système hôte, il est peu probable qu'elle crée des événements d'audit sur ce système. Cette fonctionnalité, associée à la capacité d'un ordinateur virtuel de se connecter au réseau de l'hôte, d'obtenir des adresses IP et de se connecter à des lecteurs partagés, présente un certain nombre de dangers en termes de sécurité, lesquels vont d'une protection par mot de passe faible à une vulnérabilité accrue aux attaques. En effet, elle est peu susceptible d'être régie par un processus de mise à jour en place sur le réseau. Étant donné les risques liés aux ordinateurs virtuels, il est essentiel de réserver l'utilisation du logiciel Virtual PC à des personnes autorisées et de créer des processus documentés pour la création et l'utilisation d'instances Virtual PC.

Pour détecter l'utilisation d'un système d'exploitation non autorisé, une solution de surveillance de la sécurité doit être en mesure d'identifier les éléments suivants :

  • Comptes utilisateur, noms d'ordinateur, groupes de travail ou noms de domaine non reconnus.

  • Adresses IP en double ou hors plage.

  • Tentatives d'ouverture de session avec le compte administrateur par défaut.

Les événements de suivi de processus répertoriés dans le tableau ci-dessous peuvent permettre de détecter l'utilisation de systèmes d'exploitation non autorisés.

Tableau 13. Événements relatifs à l'utilisation de plateformes non autorisées

ID d'événement

Occurrence

Commentaires

529

Échec d'ouverture de session – Nom d'utilisateur inconnu ou mot de passe incorrect

Vérifiez si des tentatives d'ouverture de session avec le compte cible administrateur ou racine, ou avec un nom de domaine inconnu, ont été effectuées.

533

Échec d'ouverture de session – Utilisateur non autorisé à ouvrir une session sur cet ordinateur

Indique qu'un utilisateur tente d'ouvrir une session sur une station de travail réservée.

592

Création d'un nouveau processus

Vérifiez le nom de fichier image et le nom d'utilisateur pour déterminer si cette utilisation du programme est autorisée pour ce compte.

Création ou rupture de relations de confiance

Les relations de confiance permettent aux comptes d'un domaine d'accéder aux ressources d'un autre domaine. La création de relations de confiance n'est pas anodine ; elle doit s'inscrire dans le cadre d'un processus de contrôle des modifications établi. La rupture de ce type de relations doit également être approuvée par un processus de contrôle des modifications et n'être effectuée qu'après un examen approfondi des conséquences de l'opération sur le réseau.

Les événements d'audit de modification de stratégie répertoriés dans le tableau ci-dessous identifient les activités liées aux relations de confiance.

Tableau 14. Événements de modification de relations de confiance

ID d'événement

Occurrence

Commentaires

610
611
620

Une relation de confiance avec un autre domaine a été créée, supprimée ou modifiée

Ces événements sont générés sur le contrôleur de domaine qui a établi la relation de confiance. Lorsqu'ils ne sont pas associés à un processus établi de contrôle des modifications, ces événements doivent faire l'objet d'une enquête immédiate. Consultez le champ du nom d'utilisateur pour identifier le compte demandeur.

Modifications non autorisées de la stratégie de sécurité

Les paramètres de la stratégie de sécurité approuvée ne doivent être mis à jour que dans le cadre d'un processus de contrôle des modifications établi. Toute modification effectuée en dehors de ce type de processus doit donner lieu à une enquête immédiate.

Les modifications de la stratégie de sécurité portent sur les éléments suivants :

  • Paramètres de stratégie de groupe

    • Stratégie régissant les mots de passe des comptes utilisateur

    • Stratégie de verrouillage des comptes utilisateur

    • Stratégie d'audit

    • Paramètres du journal des événements applicables au journal des événements de sécurité

    • Stratégie IPsec

    • Stratégies de réseau sans fil (IEEE 802.1x)

    • Stratégies relatives aux clés publiques et au système de fichiers de chiffrement (EFS, Encrypting File System)

    • Stratégies de restriction logicielles

  • Paramètres de sécurité

    • Paramètres des droits des utilisateurs

    • Stratégie régissant les mots de passe des comptes utilisateur

    • Options de sécurité

La liste ci-dessus ne contient que les paramètres minimum ; la plupart des entreprises ajouteront probablement des paramètres supplémentaires à leur environnement. Au cours des audits de sécurité, les tentatives de modification de ces paramètres doivent être examinées, qu'elles aient abouti ou non. Les tentatives réussies doivent provenir de comptes autorisés à effectuer ces modifications dans le cadre d'un processus établi.

Le tableau ci-dessous répertorie les événements d'audit de modification de stratégie correspondant à des modifications de stratégie de groupe et de système local.

Tableau 15. Événements de modification de stratégie

ID d'événement

Occurrence

Commentaires

612

Modification de la stratégie d'audit

Indique une modification apportée à une stratégie d'audit. Pour déterminer si ces événements sont autorisés, ils doivent être mis en corrélation avec une stratégie de contrôle des modifications établie.

613
614
615

Modification de la stratégie IPsec

Indique une modification apportée à la stratégie IPsec. Ces événements doivent se produire au cours du démarrage du système. Si tel n'est pas le cas, ils doivent faire l'objet d'une enquête.

618

Stratégie de récupération de données chiffrées

Ces événements se produisent lorsqu'une stratégie de récupération de données chiffrées est utilisée. Toute occurrence hors du cadre des stratégies définies doit donner lieu à une enquête.


Remarque : pour plus d'informations sur les paramètres de stratégie de groupe, consultez la page relative aux paramètres de stratégie de sécurité à l'adresse http://technet2.microsoft.com/WindowsServer/en/library/bcd7ea4c-f989-4cee-969a-920f62f555111033.mspx?mfr=true (cette page peut être en anglais).

Tentative d'obtention d'informations d'identification

Pour obtenir les informations d'identification d'un compte utilisateur, les attaquants disposent d'un arsenal varié, allant des attaques par dictionnaire aux stratégies d'ingénierie sociale. Bien que la méthode la plus fréquemment utilisée soit l'attaque par dictionnaire menée contre un seul compte, une autre approche courante consiste à essayer une série de mots de passe sur tous les comptes d'une base de données de services d'annuaire. Dans le second cas, il est probable que l'attaquant a accès à la base de données d'annuaire de l'entreprise ou qu'il dispose de la liste des employés et a identifié la convention utilisée pour attribuer les noms d'utilisateur. Pour découvrir ce type d'attaque, il faut pouvoir détecter les comptes ayant effectué plusieurs tentatives infructueuses d'ouverture de session, même si les seuils de verrouillage des comptes ne sont pas atteints.

Les réinitialisations des mots de passe permettent également d'obtenir les informations d'identification des comptes. Étant donné que les réinitialisations et les modifications de mot de passe génèrent le même événement en cas d'échec et de succès, un attaquant peut contourner la stratégie de verrouillage de compte pour éviter d'être découvert. Pour contrôler ces tentatives, une solution de surveillance de la sécurité doit être capable d'identifier les tentatives multiples de réinitialisation ou de modification de mot de passe, notamment celles qui n'entrent pas dans le cadre de stratégies et de processus d'entreprise établis.

Bien que le fait d'inventorier les mots de passe ne constitue pas une attaque (il s'agit de tenter de contourner les stratégies de réutilisation des mots de passe en exécutant des scripts pour inventorier de nombreux mots de passe afin de trouver celui d'origine), il présente toutefois un danger en termes de sécurité. Au cours de ces opérations, le nombre de réinitialisations de mot de passe est à peu près identique au seuil de réutilisation ; elles sont donc signalées par une succession rapide d'événements 627. L'implémentation de stratégies régissant la durée de validité minimale des mots de passe peut mettre en échec ce type d'attaque.

Le tableau ci-dessous répertorie les événements pouvant révéler des tentatives d'attaque portant sur les informations d'authentification. Cependant, ces événements peuvent également se produire dans le cadre du fonctionnement normal du réseau (lorsque des utilisateurs autorisés oublient leur mot de passe, par exemple).

Tableau 16. Événements d'attaque des informations d'authentification

ID d'événement

Occurrence

Commentaires

529

Échec d'ouverture de session – Nom d'utilisateur inconnu ou mot de passe incorrect

Vérifiez si des tentatives dans lesquelles le nom du compte cible est Administrateur ou un autre compte de niveau administrateur non autorisé à modifier les mots de passe, ont été effectuées. Vérifiez également si plusieurs échecs d'ouverture de session se sont produits sans dépasser le seuil de verrouillage. Mettez cet événement en corrélation avec les événements 529 et 539 pour identifier les schémas de verrouillages de compte à répétition.

534

Échec d'ouverture de session – Type d'ouverture de session non autorisé

Indique qu'un utilisateur a tenté d'ouvrir une session avec un type de compte non autorisé (réseau, interactif, par lots ou service). Vérifiez les noms du compte cible et de la station de travail, ainsi que le type d'ouverture de session.

539

Compte verrouillé

Indique une tentative d'ouverture de session avec un compte verrouillé. Mettez cet événement en corrélation avec l'événement 529 pour identifier les schémas de verrouillages à répétition.

553

Attaque par répétition détectée

Indique qu'un package d'authentification, généralement Kerberos, a détecté une tentative d'ouverture de session par répétition des informations d'identification d'un utilisateur. Bien que cet événement puisse être le signe d'une configuration réseau incorrecte, il doit faire l'objet d'une enquête immédiate.

627

Tentative de modification de mot de passe

Indique qu'une personne autre que le détenteur d'un compte a tenté de modifier le mot de passe, lorsque le nom du compte principal ne correspond pas au nom du compte cible.

628

Mot de passe de compte utilisateur défini ou réinitialisé

Cette activité doit être réservée aux comptes autorisés tels que les comptes du service d'assistance ou de réinitialisation de mot de passe en libre-service.

644

Compte utilisateur verrouillé automatiquement

Indique qu'un compte a été verrouillé après que le nombre d'échecs d'ouverture de session successifs a dépassé le seuil de verrouillage du compte. Mettez cet événement en corrélation avec les événements 529, 675, 681 et 676 (Windows 2000 Server uniquement). Reportez-vous également à l'entrée de l'événement 12294 dans ce tableau.

675

Échec de pré-authentification

Indique un problème de synchronisation de temps ou des comptes d'ordinateur incorrectement connectés au domaine. Mettez cet événement en corrélation avec l'événement 529 pour identifier la cause exacte de l'échec de l'ouverture de session.

12294

Tentative de verrouillage de compte

Peut indiquer une attaque en force contre le compte administrateur par défaut. Les stratégies de verrouillage de compte n'étant pas appliquées à ce compte, cet événement est consigné en tant qu'événement SAM 12294 dans le journal des événements système. Cet événement pouvant révéler l'utilisation d'un système d'exploitation non autorisé, il doit faire l'objet d'une enquête. Vérifiez si le champ du nom de domaine contient un domaine inconnu.

Exploitation des points faibles

Les points faibles sont la cible principale des attaquants lors des tentatives d'intrusion. Ces points faibles sont susceptibles d'exister sur chaque ordinateur et ils peuvent être difficiles à éliminer. Le délai entre le moment où un point faible est détecté et celui où il est attaqué (appelé fenêtre d'exploitation de vulnérabilité) devient de plus en plus court, ce qui signifie que le délai de développement, de test et de distribution de correctifs pour ces points faibles diminue également.

La meilleure défense contre l'exploitation des points faibles est un processus de gestion des correctifs efficace chargé de tester et de déployer rapidement des mises à jour de sécurité dans un environnement. Microsoft Systems Management Server (SMS) 2003 ou Windows Software Update Service (WSUS) peuvent vous aider à mettre ce processus en place.

La surveillance de la sécurité à la périphérie du réseau revêt une importance particulière, dans la mesure où les ordinateurs qui s'y trouvent sont facilement accessibles pour les attaquants. Sans mécanismes destinés à détecter les attaques au moment où elles se produisent, une entreprise risque de ne prendre conscience des failles de sécurité du réseau qu'une fois celui-ci compromis. Par conséquent, il est vital que les événements d'audit qui se produisent sur les ordinateurs situés à la périphérie du réseau fassent l'objet d'une surveillance attentive.

Outre les événements déjà décrits, les plus importants indiqués dans la section « Tentative d'obtention d'informations d'identification » sont ceux relatifs aux tentatives d'accès non autorisées et à l'utilisation d'identités privilégiées. Le tableau ci-dessous répertorie certains des événements qui peuvent indiquer ce type d'attaque.

Tableau 17. Événements d'exploitation des points faibles générés par l'élévation des privilèges

ID d'événement

Occurrence

Commentaires

528

538

Ouverture et fermeture de session locales

Lorsque ces événements se produisent sur des ordinateurs périphériques, mettez-les en corrélation avec l'ID d'ouverture de session. Menez une enquête lorsque les champs de compte utilisateur, d'heure ou de station de travail contiennent des valeurs inattendues.

551

Fermeture de session demandée par un utilisateur

Cet événement est comparable à l'événement 538. Un jeton manquant peut empêcher l'audit de l'événement 538 et provoquer l'événement 551 à la place.

576

Ouverture de session privilégiée

Sur un ordinateur exécutant Windows Server 2003 avec SP1 ou supérieur, indique une ouverture de session par un compte administrateur, un compte disposant de privilèges suffisants pour falsifier la base informatique sécurisée (TCB, Trusted Computing Base) ou pour prendre le contrôle d'un ordinateur. Sur les versions antérieures de Windows, cet événement n'est intéressant que lorsqu'il est associé à des privilèges sensibles tels que SeSecurityPrivilege ou SeDebugPrivilege.


Remarque : dans les versions de Windows antérieures à Windows Server 2003, l'événement 576 apparaît dans la catégorie Utilisation d'un privilège. Dans Windows Server 2003 et versions supérieures, il apparaît également dans la catégorie Ouverture de session. La configuration des paramètres d'audit pour l'une ou l'autre de ces catégories entraîne la consignation de cet événement.

Tentatives de contournement des audits

Les attaquants disposent de nombreuses méthodes pour attaquer le réseau d'une entreprise et de techniques pour dissimuler ces tentatives et éviter d'être démasqués. Par exemple, un attaquant peut modifier la stratégie de sécurité d'un système ou d'un domaine compromis afin d'éviter que les activités suspectes soient consignées dans les journaux d'événements, ou encore supprimer un journal de sécurité pour effacer toute trace des informations d'audit.

S'il est possible de détecter les tentatives de mise en échec de la solution de surveillance de la sécurité par le biais de ces techniques, cela s'avère très difficile dans la mesure où la plupart des événements qui peuvent signaler une tentative de dissimulation des traces d'une intrusion se produisent également dans le cadre du fonctionnement normal du réseau.

Le tableau ci-dessous répertorie les types d'événement permettant d'identifier les tentatives de contournement des mesures d'audit par des attaquants cherchant à dissimuler les traces d'une brèche de sécurité.

Tableau 18. Événements de contournement d'audit

ID d'événement

Occurrence

Commentaires

512

Démarrage de Windows

Se produit généralement après l'événement 513. Les redémarrages inattendus doivent faire l'objet d'une enquête.

513

Arrêt de Windows

Se produit généralement avant l'événement 512. Le redémarrage des ordinateurs à valeur élevée ne doit être effectué que par des personnes autorisées et conformément à une procédure de contrôle des modifications établie. Cet événement, lorsqu'il se produit sur un serveur, doit donner lieu à une enquête.

516

Échec de l'audit

Cet événement peut se produire lorsqu'un nombre trop élevé d'événements entraîne une saturation de la mémoire tampon du journal d'événements ou lorsque le journal de sécurité n'est pas configuré pour l'écrasement. Bien que ces problèmes puissent être évités sur la plupart des ordinateurs en limitant le nombre d'événements surveillés, les ordinateurs à valeur élevée ou vulnérables exigent une surveillance plus détaillée.

517

Effacement du journal des événements de sécurité

Les journaux d'événements de sécurité ne doivent pas être effacés sans autorisation. Mettez le nom d'utilisateur client et le nom de domaine client en corrélation avec les noms des personnes autorisées et les enregistrements de procédures approuvées.

520

Modification de l'heure système

Cette activité peut fausser les analyses des dommages ou fournir de faux alibis aux attaquants. Mettez le nom d'utilisateur client et le nom de domaine client en corrélation avec les noms des personnes autorisées et vérifiez que le nom de processus est bien %windir%\system32\svchost.exe.

521

Impossible d'enregistrer les événements

Se produit lorsque Windows ne parvient pas à écrire les événements dans le journal. Cet événement doit faire l'objet d'une enquête lorsqu'il intervient sur un système à valeur élevée.

608

Un privilège de compte utilisateur a été attribué

Se produit lorsqu'un nouveau privilège est attribué à un compte utilisateur. Cette action est consignée dans le journal d'événements avec l'identificateur de sécurité (SID), et non le nom, du compte utilisateur.

609

Un privilège de compte utilisateur a été supprimé

Se produit lorsqu'un privilège est ôté d'un compte utilisateur. Cette action est consignée dans le journal d'événements avec l'identificateur de sécurité (SID), et non le nom du compte utilisateur.

612

Modification de la stratégie d'audit

Bien que cet événement ne signale pas nécessairement un problème, un attaquant peut modifier les stratégies d'audit pour mener une attaque. Cet événement doit être surveillé sur les ordinateurs à valeur élevée et sur les contrôleurs de domaine.

621

Accès système accordé à un compte

Se produit lorsque l'accès à un système est accordé à un utilisateur. Lorsque la permission d'accès est signalée comme interactive, les champs de nom d'utilisateur et de compte modifié doivent être contrôlés.

622

Accès système refusé à un système

Cet événement peut indiquer qu'un attaquant a tenté de supprimer des preuves mentionnant l'événement 621 ou qu'il tente de refuser un service à un ou plusieurs autres comptes.

643

Modification de la stratégie de sécurité du domaine

Se produit lors d'une tentative de modification de la stratégie de mot de passe ou d'autres paramètres de la stratégie de sécurité. Mettez le nom d'utilisateur en corrélation avec les enregistrements d'autorisations.

Analyse des dommages

Bien que l'analyse des dommages repose sur de nombreux éléments décrits dans ce document, elle diffère fondamentalement des autres solutions de surveillance de la sécurité et de détection des attaques car elle se concentre sur le stockage et l'examen des informations de sécurité et est utilisée en réponse à une attaque une fois que celle-ci s'est produite. La plupart de ces enquêtes commencent par l'établissement d'une liste d'événements associés à un utilisateur ou un système donné.

L'analyse des dommages dans le cadre de la surveillance de la sécurité requiert les éléments suivants :

  • Archivage des types d'événements sélectionnés.

  • Estimation du nombre d'événements quotidiens.

  • Définition de limites de durée pour le stockage en ligne, hors ligne et l'archivage.

  • Bases de données dimensionnées en fonction du nombre d'événements attendus.

  • Système de sauvegarde capable de faire face au nombre d'événements quotidiens attendus.

  • Définition de stratégies de gestion du système d'archivage.

Trois facteurs principaux déterminent les besoins en termes de stockage d'un programme d'analyse des dommages :

  • Nombre d'événements à enregistrer.

  • Fréquence à laquelle ces événements sont générés par les ordinateurs cibles.

  • Durée du stockage en ligne.

Pour définir une durée de stockage raisonnable tenant compte de ces trois facteurs, vous devez bien connaître les besoins de l'entreprise et vous appuyer sur les informations présentées dans ce document.

Résumé

Dans l'environnement réseau actuel, il est évident qu'une solution de surveillance de la sécurité et de détection des attaques efficace et complète n'est pas une option, mais bien une nécessité, pour les entreprises de taille moyenne. Les réseaux d'entreprise sont confrontés à de nombreux risques et menaces volontaires et accidentels qui proviennent non seulement de l'extérieur mais également de l'intérieur. Un système de surveillance de la sécurité rationnel doit tenir compte de tous les risques ; il exige donc une solide connaissance de ceux-ci, ainsi que de l'architecture d'un réseau d'entreprise et des caractéristiques des menaces et activités susceptibles de compromettre les données stockées sur les systèmes du réseau.

Microsoft, pour qui la question de la sécurité est prise très au sérieux, propose de nombreux outils qui vous aideront à développer un système efficace de surveillance de la sécurité et de détection des attaques. Windows Server 2003 et les autres versions du système d'exploitation Windows offrent des fonctions d'audit de sécurité intégrées sur lesquelles peut s'appuyer votre solution de surveillance de la sécurité. Ces fonctions, associées à d'autres composants tels que Microsoft Operations Manager et EventCombMT, ainsi qu'à des stratégies et des processus propres à l'entreprise, vous permettront de développer un système de surveillance de la sécurité complet.

Annexe A : Exclusion des événements inutiles

Les événements répertoriés dans le tableau ci-dessous sont généralement exclus des requêtes de surveillance de la sécurité car ils se produisent très fréquemment et ne produisent pas de résultats exploitables lorsqu'ils sont utilisés dans le cadre d'une solution de surveillance.

Tableau A1. Événements inutiles

ID d'événement

Occurrence

Commentaires

538

Fermeture de session utilisateur

Cet événement n'indique pas obligatoirement l'heure à laquelle un utilisateur a cessé d'utiliser un système. Par exemple, si celui-ci est arrêté ou si la connexion réseau s'interrompt, il est possible qu'aucun événement de fermeture de session ne soit enregistré.

562

Pointeur vers un objet fermé

Cet événement est toujours enregistré comme un succès.

571

Contexte client supprimé par le gestionnaire d'autorisations

Cet événement est attendu lorsque le gestionnaire d'autorisations est utilisé.

573

Un processus génère un événement d'audit non-système avec l'API AuthZ (Authorization Application Programming Interface)

Activité attendue.

577
578

Service privilégié appelé, Opération sur un objet privilégié

Ces événements très fréquents ne contiennent pas suffisamment d'informations pour pouvoir être exploités (ils n'identifient pas l'opération effectuée).

594

Pointeur vers un objet dupliqué

Activité attendue.

595

Accès indirect à un objet obtenu

Activité attendue.

596

Sauvegarde de la clé principale de protection des données

Activité attendue. Avec la configuration par défaut, cet événement se produit tous les 90 jours.

597

Récupération de la clé principale de protection des données

Activité attendue.

672

Demande de ticket AS Kerberos

Ne contient aucune information supplémentaire si l'audit détaillé des événements d'ouverture de session 528 et 540 est déjà enregistré. Cet événement indique qu'un ticket TGT Kerberos a été accordé. L'accès n'aura pas lieu tant qu'un ticket de service, audité par l'événement 673, n'aura pas été accordé. Si PATYPE a la valeur PKINIT, il s'agissait d'une ouverture de session par carte à puce.

680

Ouverture de session de compte

Activité déjà enregistrée par d'autres événements.

697

API de vérification de la stratégie de mot de passe appelée

Activité attendue.

768

Collision d'espaces de noms de forêt

Cet événement n'est pas lié à la sécurité.

769
770
771

Informations de forêt approuvées ajoutées, supprimées ou modifiées

Activité attendue. Ces événements ne doivent pas être confondus avec l'ajout, la modification ou la suppression de la relation de confiance elle-même.

832
833
834
835
836
837
838
839
840
841

Divers événements de réplication Active Directory

Ces événements ne sont pas liés à la sécurité.


Remarque : l'exclusion d'informations d'un audit présente des risques, mais ceux-ci doivent être pondérés en fonction des avantages liés à la réduction de la charge de travail incombant à un agent d'analyse.

Annexe B : Implémentation des paramètres de stratégie de groupe

Utilisez cette annexe pour vérifier les paramètres en vigueur dans un environnement. Elle présente d'autres paramètres ayant un impact sur la surveillance de la sécurité et la détection des attaques. Pour que les événements d'audit de sécurité de la stratégie de groupe soient configurés correctement, les paramètres du tableau ci-dessous doivent être appliqués.

Tableau B1. Paramètres d'audit de sécurité de la stratégie de groupe

Chemin d'accès de la stratégie

Stratégie

Paramétrage de la stratégie et commentaires

Stratégies locales/ Stratégie d'audit

Auditer les événements de connexion aux comptes

Activez l'audit des succès pour tous les ordinateurs car cet événement assure le suivi des personnes qui y ont accédé. Activez l'audit des échecs avec précaution car un attaquant ayant accès au réseau mais ne disposant pas d'informations d'identification pourrait lancer une attaque par déni de service en forçant un ordinateur à enregistrer ces événements et donc à consommer des ressources. Activez l'audit des succès avec précaution également car ce paramétrage peut entraîner des attaques par déni de service si les ordinateurs sont configurés pour s'arrêter une fois les journaux d'audit saturés. Mettez en corrélation les ouvertures de session administrateur avec les autres entrées suspectes.

Stratégies locales/ Stratégie d'audit

Auditer la gestion des comptes

Activez les événements de succès et d'échec. Mettez en corrélation les entrées d'audit de succès avec les autorisations administrateur. Tout échec doit être considéré comme suspect.

Stratégies locales/ Stratégie d'audit

Auditer l'accès au service d'annuaire

Ce paramètre est activé par défaut dans la stratégie de groupe des contrôleurs de domaine par défaut. Configurez les paramètres d'audit des objets d'annuaire sensibles en utilisant des listes de contrôle d'accès système dans Utilisateurs et ordinateurs Active Directory ou dans l'éditeur Active Directory Services Interface (ADSI Edit). L'implémentation des listes de contrôle d'accès système doit être planifiée et celles-ci doivent être testées dans un environnement réaliste avant d'être déployées dans un environnement de production. Cette méthode évite qu'un volume de données excessif entraîne la saturation des journaux de sécurité.

Stratégies locales/ Stratégie d'audit

Auditer les événements de connexion

Activez l'audit des succès pour tous les ordinateurs car cet événement assure le suivi des personnes qui y ont accédé. Activez l'audit des échecs avec précaution car un attaquant ayant accès au réseau mais ne disposant pas d'informations d'identification pourrait créer une situation de déni de service par génération d'un nombre d'échecs excessif.

Stratégies locales/ Stratégie d'audit

Auditer l'accès aux objets

Activez ce paramètre avec précaution car il peut engendrer un volume de données d'audit extrêmement important. Configurez les paramètres d'audit pour les dossiers à valeur élevée uniquement, via des listes de contrôle d'accès système, et auditez seulement les types d'accès qui présentent un intérêt. Si possible, auditez uniquement les événements d'écriture, et non les événements d'accès en lecture.

Stratégies locales/ Stratégie d'audit

Auditer les modifications de stratégie

Activez l'audit des succès et des échecs. Mettez en corrélation les événements de succès avec les autorisations administratives.

Stratégies locales/ Stratégie d'audit

Auditer l'utilisation des privilèges

N'activez pas l'audit d'utilisation des privilèges car cette configuration génèrerait un nombre excessif d'événements.

Stratégies locales/ Stratégie d'audit

Auditer le suivi des processus

Activez ce paramètre sur les ordinateurs vulnérables et enquêtez sur les activités liées aux applications inattendues, en isolant le système si besoin. N'activez pas ce paramètre sur les serveurs Web CGI (Common Gateway Interface), les systèmes de test, les serveurs exécutant des processus par lots ni les stations de travail des développeurs, car cette configuration pourrait entraîner une saturation des journaux d'événements.

Stratégies locales/ Stratégie d'audit

Auditer les événements système

Activez l'audit des succès et des échecs.

Stratégies locales/ Attribution des droits utilisateur

Générer des audits de sécurité

Ce paramètre est attribué par défaut aux comptes Système local, Serveur local et Service réseau. Ce droit doit être réservé aux comptes de service. Un utilisateur malveillant pourrait utiliser ce paramètre pour générer des événements faux ou inappropriés dans le journal de sécurité.

Stratégies locales/ Attribution des droits utilisateur

Gérer les journaux d’audit et de sécurité

Utilisez ce paramètre pour empêcher les administrateurs de modifier les paramètres d'audit des fichiers, des dossiers et du registre. Envisagez de créer un groupe de sécurité pour les administrateurs autorisés à modifier les paramètres d'audit et supprimez le groupe d'administrateurs des paramètres de la stratégie de groupe locale. Seuls les membres d'un groupe de sécurité doivent être autorisés à modifier les paramètres d'audit.

Stratégies locales/ Options de sécurité

Audit : auditer l'accès des objets système globaux

Ce paramètre ajoute des listes de contrôle d'accès système à des objets système nommés tels que les mutex, les sémaphores et les périphériques MS-DOS. Cette option n'est pas activée dans les paramètres par défaut de Windows Server 2003. N'activez pas ce paramètre car il génère un nombre élevé d'événements.

Stratégies locales/ Options de sécurité

Audit : auditer l'utilisation des privilèges de sauvegarde et de restauration

Les opérations de sauvegarde et de restauration fournissent des occasions de dérober des données en contournant les listes de contrôle d'accès. N'activez pas ce paramètre car il génère un nombre très élevé d'événements.

Stratégies locales/ Options de sécurité

Audit : arrêter immédiatement le système s'il n'est pas possible de se connecter aux audits de sécurité

N'activez ce paramètre qu'après mûre réflexion, uniquement sur les ordinateurs à valeur élevée, car les attaquants peuvent l'utiliser pour lancer des attaques par déni de service.

Journal d’événements

Taille maximale du journal de sécurité

Les paramètres recommandés dépendent des volumes d'événements attendus et des paramètres définis pour la conservation des journaux de sécurité. La valeur de ce paramètre utilise des incréments de 64 Ko ; la taille d'événement moyenne est de 0,5 Ko. Dans les environnements générant de très nombreux événements, ce paramètre peut avoir une valeur maximale de 250 Mo, mais la taille totale de tous les journaux d'événements combinés ne doit pas excéder 300 Mo.

Journal d’événements

Empêcher les groupes d'invités locaux d'accéder au journal de sécurité

Ce paramètre est activé par défaut dans Windows Server 2003 ; ne le modifiez pas.

Journal d’événements

Durée de stockage du journal des applications

N'activez ce paramètre que si la méthode de stockage choisie est « Remplacer les événements par jours ». Si vous utilisez un système de mise en corrélation des événements qui interroge les événements, assurez-vous que le nombre de jours est égal à au moins trois fois la fréquence d'interrogation, afin que les échecs du cycle d'interrogation soient possibles.

Journal d’événements

Méthode de conservation du journal de sécurité

Activez le paramètre « Ne pas remplacer les événements » dans les environnements hautement sécurisés. Dans ce cas, définissez des procédures pour vider et archiver régulièrement les journaux, notamment si le paramètre « Arrêter immédiatement le système s'il n'est pas possible de se connecter aux audits de sécurité » est activé.


Télécharger

Obtenir l'article Surveillance de la sécurité et détection des attaques



Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft