9 facteurs clés à prendre en compte lors du déploiement d’un CSOC

Un Centre des Opérations de Cybersecurité (CSOC) est de plus en plus reconnu comme un élément essentiel d'une approche de cybersécurité en défense en profondeur, où plusieurs couches de contrôles de sécurité couvrent l'ensemble du paysage IT, offrant des mesures variées pour :

▪️ Identifier les actifs ainsi que les risques et menaces auxquels ils sont exposés,

▪️ Protéger les actifs et les données contre ces menaces,

▪️ Détecter les menaces et les attaques, 

▪️ Réagir face à ces attaques,

▪️ Rétablir les systèmes après une attaque.

Facteurs clés lors du déploiement d'un CSOC

Notre expérience dans la mise en place de notre propre CSOC, ainsi que dans l'accompagnement d'entreprises pour la création de leur CSOC internes, a montré qu'il existe plusieurs facteurs essentiels à considérer lors de la planification et de l'exécution d'un déploiement de services CSOC, à savoir :

1️⃣ Comprendre les exigences d'engagement d'un CSOC,

2️⃣ Avoir une vision claire du parc d'équipements et d'applications (dimensionnement, actifs critiques),

3️⃣ Gérer les ressources tierces,

4️⃣ Assurer la compréhension du projet par les parties prenantes,

5️⃣ Savoir ce qu’un service CSOC ne fournira pas,

6️⃣ Intégrer le service CSOC dans les processus existants,

7️⃣ Gérer les risques,

8️⃣ Commencer petit et évoluer progressivement,

9️⃣ « Plus » n’est pas synonyme de « mieux » en ce qui concerne le nombre de cas d’usage déployés.

1️⃣ Comprendre les exigences d'engagement d'un CSOC

Il existe encore, dans certains milieux, la croyance que la sécurité est une « boîte noire » que l'on peut acheter et ajouter facilement. Même les dispositifs de sécurité présentés comme rapides et simples à déployer doivent être configurés, surveillés et maintenus par des ressources compétentes.

Un CSOC illustre parfaitement le fait que la qualité du service dépend du niveau d’implication de l’entreprise dans le projet de déploiement. La solidité de la relation entre l’entreprise et le fournisseur de services CSOC (qu’il s’agisse d’un MSSP ou d’une équipe interne) est cruciale. Comprendre les enjeux dès le début de la mise en œuvre d’un CSOC est un investissement qui portera ses fruits, non seulement pendant le projet, mais aussi tout au long de la vie du CSOC.

Pour surveiller les équipements, leurs logs doivent être identifiés, priorisés en fonction du niveau de risque des actifs, puis intégrés dans une plateforme SIEM (Security Incident and Event Management). Les règles SIEM s’appliquent aux logs entrants afin de détecter des signes d’incidents de sécurité, auxquels l’équipe CSOC devra réagir.

Si l’on considère l’étendue des « sources de logs » dans une organisation, elles incluent serveurs, pare-feu, infrastructures virtuelles, Active Directory, applications, bases de données, et bien d’autres. Chacune constitue une cible potentielle pour des acteurs malveillants cherchant à exploiter une vulnérabilité afin de nuire à votre entreprise et à votre réputation.

Pour analyser ces logs, il faut d’abord les identifier tous. Cette première étape représente souvent un défi majeur pour l’entreprise, car les ressources techniques doivent fournir l’inventaire nécessaire.

L’entreprise doit également s’assurer que chaque source de logs est configurée pour transmettre les logs au SIEM pour traitement.

Enfin, des ressources expertes seront sollicitées pour affiner les règles SIEM. Ce réglage est essentiel pour éliminer les faux positifs et adapter les règles aux besoins spécifiques de l’entreprise. Cela nécessite la contribution de personnes capables de fournir des scénarios réels pour alimenter le processus d’optimisation. 

Comme vous pouvez le constater, le niveau d’engagement de l’entreprise ne doit pas être sous-estimé. Mais un investissement d’effort à ce stade se traduira par moins de retards dans le projet et un service de meilleure qualité.

2️⃣ Avoir une vision claire du parc d'équipements et d'applications (dimensionnement, actifs critiques)

Un vieil adage dit qu’un équipement ne peut être géré que si l’on sait qu’il existe. Cela n’a jamais été aussi vrai que dans le cadre d’un CSOC.

En gardant à l’esprit le point n°1, la première tâche d’un projet CSOC consiste à définir le périmètre des équipements à intégrer. Quels sont-ils ? Où se trouvent-ils ? Combien sont-ils ? Le rêve de tout MSSP est de disposer d'une CMDB, Configuration Management Database) mature et à jour, offrant une vue immédiate et précise des équipements à intégrer dans le SIEM. Malheureusement, cela arrive rarement, et il faut souvent déployer des efforts considérables pour collecter les informations d’inventaire à partir de sources diverses.

Le lancement d’un projet CSOC est souvent un catalyseur pour relancer les discussions autour du projet CMDB, régulièrement repoussé. Si seulement nous avions un système capable de nous fournir un inventaire des actifs à jour…

Si vous disposez d’une telle CMDB, félicitations : vous faites partie d’une minorité, et les premières étapes de votre projet CSOC devraient se dérouler sans encombre.

Pour le meilleur ou pour le pire, il est possible que la CMDB la plus utilisée au monde soit Microsoft Excel. Pour ceux qui commencent avec une feuille de calcul vierge, votre nouvel inventaire des actifs IT devrait, au minimum, inclure des informations telles que :

▪️ Nom de l'actif,

▪️ ID,

▪️ Type (ex.: pare-feu, application or serveur),

▪️ Technologie (ex.: Windows, Cisco),

▪️ Version,

▪️ Adresse IP

▪️ Localisation.

D’autres projets bénéficieront certainement de ce type d’inventaire. L’objectif doit donc être de passer d’une approche ponctuelle à une gestion industrialisée de l’inventaire. Peut-être qu’un jour, ce projet CMDB deviendra réalité.

3️⃣ Gestion de ressources tierces

L’époque où une entreprise hébergeait l’intégralité de son infrastructure IT sous son propre toit, gérée par ses propres équipes, est révolue pour beaucoup d’organisations. Le besoin de flexibilité et de scalabilité rapides a conduit à multiplier les partenariats avec des tiers pour l’hébergement et la gestion des systèmes informatiques.

Plus récemment, la migration vers le cloud s’est accélérée, transformant la consommation IT en un modèle de commodité, où le CPU et le stockage sont perçus comme des abstractions indépendantes du matériel sous-jacent.

Ces changements de paradigme ont ajouté de la complexité à la fois à la mise en œuvre d’un CSOC et aux services CSOC qui en découlent.

Il est essentiel d’impliquer un partenaire de gestion IT dès les premières étapes afin de garantir son engagement dans l’intégration des sources de logs, le réglage des systèmes et les activités post-projet. Vous devez également vous poser des questions telles que :

📌 Votre partenaire vous fournira-t-il les fichiers logs des équipements qu'il gère pour vous ?

📌 Quelles sont les considérations contractuelles à prévoir ?

4️⃣ Compréhension du project CSOC par les parties prenantes

En plus de la gestion des tiers, il est essentiel de veiller à ce que toutes les parties prenantes soient informées, dans le cadre d’une stratégie de communication. Cette stratégie doit être portée par la direction (C-level) afin de diffuser le message qu’un CSOC apportera des bénéfices significatifs et renforcera la posture de sécurité de l’entreprise.

L’importance des ressources techniques disposant de connaissances sur les équipements sous-jacents a déjà été mentionnée.

Les équipes de développement peuvent collaborer avec le CSOC pour adapter leurs fichiers journaux et y inclure des éléments permettant d’identifier des anomalies de sécurité dans leurs applications.

Le Service Desk joue un rôle clé en cas d’incident de sécurité et doit être formé en conséquence.

Les syndicats / délégations du personnel peuvent avoir des questions sur les données collectées et leur utilisation. Le projet doit répondre à ces interrogations pour informer et rassurer les parties prenantes.

Il est clair que votre nouveau service CSOC aura des implications importantes à travers l’entreprise, et une certaine diplomatie est nécessaire dans la communication autour du projet.

5️⃣ Comprendre ce qu'un service CSOC ne fournit pas

« J’ai un CSOC, mais nous avons quand même subi une fuite de données. Comment est-ce possible ? » J’ai personnellement entendu cette plainte d’un professionnel IT désemparé, confronté aux conséquences d’un incident de sécurité.

Ce point est lié au précédent, car il concerne la compréhension des objectifs du projet. Il est tout aussi important de savoir ce qu’un service CSOC ne fournit pas.

Comme indiqué dans l’introduction, l’approche défense en profondeur en cybersécurité couvre les activités suivantes : Identifier, Protéger, Détecter, Répondre et Rétablir. Le niveau de maturité cybersécurité d’une entreprise se mesure à la manière dont ces points sont adressés. Bien qu’un CSOC soit un élément essentiel des mesures de cybersécurité, il ne couvre pas l’ensemble de ces activités.

Un CSOC peut être considéré comme un contrôle offrant des capacités de détection (et parfois certaines capacités de réponse). C’est comparable à une alarme incendie : elle signale le danger, mais ce n’est ni un système d’extinction ni un dispositif de suppression du feu. Nos articles Comment réagir à un incident cyber ? et Gestion de crise cyber en 4 étapes offrent des pistes pour aborder les phases Répondre et Rétablir.

Les entreprises doivent donc adopter une approche globale de la cybersécurité et réfléchir aux mesures à mettre en place en complément d’un service CSOC.

6️⃣ Intégrer le service CSOC dans les processus existants

Comme indiqué précédemment, un service CSOC n’est pas une boîte noire et n’existe pas en vase clos.

Le SIEM collecte des journaux provenant de sources réparties dans toute l’entreprise, mais ce paysage évolue constamment, ce qui rend la cible plus difficile à atteindre. Les procédures de gestion des changements doivent donc être mises à jour pour inclure des étapes visant à actualiser l’inventaire des actifs lors de modifications pertinentes (ajout, retrait ou mise à niveau d’un actif).

7️⃣ Gestion des risques

Voici quelques scénarios réels rencontrés lors de projets de mise en œuvre de CSOC :

📌 Un ancien PC sous Windows XP exécute une application critique que personne ne sait administrer depuis le départ du responsable il y a 10 ans.

📌 Un projet de Data Centre a été reporté plusieurs fois, mais devrait démarrer bientôt (en principe). Le prestataire responsable du DC ne souhaite pas investir du temps pour intégrer les serveurs avant la migration.

📌 Une partie de l’entreprise a été vendue, et un projet de désengagement de 6 mois est en cours pour séparer les serveurs et autres infrastructures concernées. Il faut veiller à ne pas intégrer ces équipements dans le CSOC.

📌 Un POC de migration vers le cloud a été réalisé. Il est possible qu’une migration massive vers le cloud soit validée prochainement.

Chacun de ces cas présente des risques qui doivent être pris en compte dans le projet. Une approche basée sur les risques doit être adoptée pour décider quels équipements ne verront pas leurs journaux intégrés au SIEM. Même un simple retard d’intégration peut exposer l’entreprise à des risques.

Ces décisions dépassent la responsabilité du chef de projet. La gestion des risques IT doit être informée de toutes ces exceptions potentielles afin de prendre des décisions éclairées.

8️⃣ Commencer petit et évoluer progressivement

Il est utile d’imaginer l’objectif global d’un service CSOC comme une chaîne d’activités :

📌 Collecte en temps voulu des sources de journaux via un canal sécurisé,

📌 Alimentation du SIEM,

📌 Déclenchement des cas d’usage,

📌 Consolidation des alertes en incidents de sécurité via un processus de triage,

📌 Transmission pour remédiation si nécessaire.

Mettre en place cette chaîne peut commencer avec une seule source de logs envoyant des fichiers au SIEM, et une seule règle appliquée à ces fichiers. Il n’est pas logique de concentrer tous les efforts sur l’intégration de toutes les sources avant de réfléchir aux cas d’usage.

Un POC (Proof of Concept) permet de résoudre les problèmes liés au processus d’intégration des journaux et de s’assurer que tous les participants sont à l’aise avec le flux de travail. Bien sûr, pendant ce POC, vous pouvez continuer à compléter votre inventaire des sources de journaux afin qu’il soit prêt pour la phase suivante.

Une approche par étapes est également utile pour démontrer la valeur aux parties prenantes. Dès que les premières alertes sont détectées, le projet dispose d’un résultat tangible qui peut être communiqué.

Les phases peuvent être structurées en fonction :

📌 de la criticité des actifs (en commençant par les infrastructures de sécurité comme les pare-feu),

📌 de la localisation,

📌 de la criticité des sites.

9️⃣ « Plus » ne signifie pas « mieux » lorsqu’il s’agit du nombre de cas d’usage déployés dans un CSOC

L’expérience montre que certaines organisations, au début de leur parcours CSOC, se focalisent sur le nombre de cas d’usage proposés “clé en main” par un MSSP potentiel. Dans certains cas, ce critère peut même influencer le choix du fournisseur.

Prenons l’exemple d’un MSSP ayant déployé des services CSOC pour un client industriel utilisant des dispositifs SCADA et PLC. Un grand nombre de cas d’usage ont été développés spécifiquement pour ces équipements et figurent désormais dans sa bibliothèque. Aucun de ces cas d’usage ne sera utile à une organisation non industrielle qui n’exploite pas ce type de dispositifs.

Ainsi, si un MSSP annonce en phase pré-commerciale qu’il dispose de 400 cas d’usage prêts à l’emploi, il est judicieux de demander des précisions. Concentrez-vous sur la valeur de chaque cas d’usage proposé et assurez-vous de comprendre dans quelle mesure il sera possible d’ajouter de nouveaux cas d’usage au cours de la vie du service.