Operations Manager (Ops Mgr) est l’outil de supervision proposé par Microsoft. Anciennement appelé MOM (pour Microsoft Operations Manager), cette nouvelle version propose des fonctions de sécurité dont le chiffrement de bout en bout. Si cette solution est capable d’auditer des événements de toute nature, l’article focalisera sur les aspects sécurité.
Etape 0 : Définition du traitement de l’information
Afin de cadrer notre sujet, il est important de distinguer les différentes étapes du traitement de l’information :
- La collecte qui consiste à récupérer les informations par des agents généralement.
- L’agrégation qui consiste à rassembler les informations et de les transférer vers un composant d’exploitation des données.
- La consolidation qui consiste à exploiter les informations (statistique, reporting, …) qui sont rassemblées et enregistrées dans une base de données associée ;
- La corrélation qui consiste à exploiter l’information de manière intelligente, basée sur des règles et une intelligence artificielle. Cela permet par exemple de déterminer une attaque grâce à la corrélation de plusieurs alertes.
Etape 1: Classification des données
Ce sont les données auditées qui détermineront la suite, c'est-à-dire le choix de l’outil, l’architecture, l’installation des composants et les configurations par exemple. Les questions suivantes devraient aiguiller le choix de l’entreprise :
- Quel est le but de la collecte ? (détection d’attaque, statistiques, reporting, …) ;
- Quel est l’existant de l’entreprise ? (solution de supervision déjà mise en place, logs déjà centralisés, alertes déjà remontées, incidents déjà traités, …) ;
- L’entreprise est-elle exposée ? (accès Internet, serveurs applicatifs en frontal, accès VPN, …) ;
- L’entreprise est-elle ciblée ? (peu ou de nombreux incidents ont-il été détectés ? Quelle est la criticité de ces incidents ?) ;
- Quelles sont les moyens mis à disposition ? (Espace disque, bande passante, et autre performance matérielle) ;
- Quelle est la nature des données transitant sur les réseaux de l’entreprise ? (informelle, critique, top secret, …) ;
- Etc.
- Les contrôles d’accès (ex : les tentatives de connexion) ;
- La sécurité de l’administration des serveurs (ex : gestion du domaine) ;
- La sécurité des ressources (ex : l’accès aux données sensibles) ;
- La sécurité des traces (ex : les règles de traçage) ;
- Etc.
- Le niveau critique qui demande une action urgente pour éviter un risque de compromission et de propagation ;
- Le niveau intermédiaire pour les évènements à traiter dès que possible et les preuves dans le cadre d’une investigation ;
- Le niveau basic pour les évènements additionnels qui nous apporterons des éléments nécessaires pour une action de forensics ou d’incident sécurité général.
Etape 2: Le choix de l’architecture
Nous supposons maintenant que le choix de la solution est Operations Manager 2007 qui nous servira donc d’exemple dans le reste de cet article. En voici les composants de sécurité :
- Le Root Management Server (RMS) : ce rôle est indispensable. C’est le point central de l’architecture et d’où seront déployées les configurations ;
- Le Management Server (MS) : rôle intermédiaire entre le RMS et les agents (ou le rôle Gateway Server). Il a le rôle de consolidation des informations ;
- L’Audit Collector Server (MS-ACS) : il s’agit d’un MS particulier chargé de traiter les informations de sécurité. Ils sont reliés à une base de données dédiées aux évènements de sécurité, l’Audit Database ;
- Le Gateway Server : ce rôle est une passerelle qui permet notamment de traverser des zones réseaux en assurant la sécurité des communications. A ce niveau, nous parlons d’agrégation de l’information ;
- Les Agents : ils ont pour but de superviser les serveurs ou les postes de travail. Ils ne sont pas indispensables car il existe un mode sans agent mais cela n’est pas recommandé d’un point de vue sécurité. Une fois l’agent installé sur une machine, nous pouvons configurés des Management Packs (MP), c'est-à-dire des modules dédiés à la supervision de machines particulières. Par exemple, il existe un MP Exchange 2007.
Etape suivante, le design de l’architecture. Il dépend de l’existant et des besoins de l’entreprise mais voici des principes de bonnes pratiques :
- Installer un rôle ACS par chaque zone cloisonnée du périmètre pour assurer que tous les évènements souhaités sont remontés ;
- Relier chaque ACS à une base Audit Database dans le même sous-réseau ;
- Installer chaque ACS sensible en cluster ;
- Relier les ACS à un RMS, le dernier devant être dans une zone sécurisée puisqu’il contient l’ensemble des informations de l’entreprise ;
- Installer le rôle Gateway Server avant de traverser un pare-feu. Ainsi, une seule connexion est à ouvrir entre les deux zones ;
- Installer des agents sur les serveurs et machines à auditer. En effet, le mode sans agents utilise des flux RPC et DCOM non protégés ;
- Eviter au mieux le déplacement d’information sensible ;
- Eviter au mieux la transmission d’information sur des réseaux externes ou non sécurisés (cas des entreprises internationales).
Etape 3 : Sécuriser les échanges
Par défaut, les authentifications reposent sur le protocole Kerberos v5. Cependant, il est possible de mettre en place une authentification mutuelle basée sur SSLv3.
Dans le cas où les agents et le MS ne sont pas installés sur le même domaine, l’authentification via Kerberos n’est plus possible. Par conséquent, seul SSL peut apporter la sécurité suffisante. A noter que l’exemple donné entre les agents et le MS est valable aussi entre les agents et un Gateway Server, deux MS dans un même domaine ou un MS et un RMS par exemple.
Si l’entreprise fait le choix de mettre en place une authentification avec SSL, il est recommandé d’utiliser les certificats de la PKI groupe de la compagnie.
Une fois les composants authentifiés, la communication repose sur la même sécurité que le protocole d’authentification, c'est-à-dire Kerberos ou SSL. En général, il est recommandé de mettre en place SSL dans les cas suivants :
Dans le cas où les agents et le MS ne sont pas installés sur le même domaine, l’authentification via Kerberos n’est plus possible. Par conséquent, seul SSL peut apporter la sécurité suffisante. A noter que l’exemple donné entre les agents et le MS est valable aussi entre les agents et un Gateway Server, deux MS dans un même domaine ou un MS et un RMS par exemple.
Si l’entreprise fait le choix de mettre en place une authentification avec SSL, il est recommandé d’utiliser les certificats de la PKI groupe de la compagnie.
Une fois les composants authentifiés, la communication repose sur la même sécurité que le protocole d’authentification, c'est-à-dire Kerberos ou SSL. En général, il est recommandé de mettre en place SSL dans les cas suivants :
- les données traversent deux zones et/ou deux domaines différents ;
- les données traversent une zone externe (comme l’Internet) ou non de confiance.
Etape 4 : La gestion des rôles, des comptes et des droits
Etape 4.1 : Au niveau de l’agent
L’agent doit disposer de droits suffisants pour récupérer les évènements de sécurité (notamment les Event logs de Windows par exemple). En fait, l’application des droits se fait sur un compte de service nommé agent action account. Pour fournir un minimum de droit, nous devons lui attribuer un compte de domaine avec les droits suivant uniquement :
- Membre du groupe Local Users ;
- Membre du groupe Performance Monitor Users ;
- Attribuer le droit Allow log on locally.
S’il s’agit des droits minima requis, en réalité, les droits nécessaires dépendent aussi des Management Packs déployés et des politiques de sécurité de l’entreprise.
Quant au déploiement des agents, ils requièrent des droits administrateurs via un compte dédié. Ce dernier peut ensuite être supprimé. En pratique, le déploiement pourra être réalisé par un outil tel que SCCM.
Quant au déploiement des agents, ils requièrent des droits administrateurs via un compte dédié. Ce dernier peut ensuite être supprimé. En pratique, le déploiement pourra être réalisé par un outil tel que SCCM.
Etape 4.2 : Au niveau des serveurs
En premier lieu, un compte de service est aussi activé sur chaque composant de la solution de supervision. Les droits à attribuer sont similaires, la contraintes des Managements Packs en moins.
Ensuite, le rôle des administrateurs doit être défini pour chacun afin de lui attribuer l’un des rôles fournis par Ops Mgr. Il est important de profiter de la granularité des profiles proposés par la solution. Les rôles en question sont : Administrator, Author, Advanced Operator, Operator, Read-Only Operator et Report Operator.
Conclusion
La supervision sécurité est un sujet indispensable pour se prémunir des attaques informatiques. Autant se faire attaquer peut être grave pour l’entreprise, autant se faire attaquer et ne pas le savoir n’est pas concevable. Aussi, il est important de savoir que la supervision demande un travail en amont (la classification des informations) et en aval (comme la corrélation et la détection d’attaque) afin que le projet fournisse un réel bénéfice à l’entreprise.
NB : Bientôt, vous trouverez sur Internet une version plus longue ... patience et bonne recherche cher agent ;)
