Les clés du déploiement d’un SOC selon le Clusif

Une organisation à part entière…

Surtout, pour les auteurs, « le SOC s’appuie sur des outils mais […] ne se résume pas à une liste de produits achetés sur étagère et agglomérés les uns aux autres ». Il s’agit donc d’une organisation opérationnelle à part entière « s’appuyant sur des processus documentés […], des ressources humaines et des ressources techniques ». Une façon de rappeler qu’un projet SOC n’a pas à être construit autour du seul déploiement d’un système de gestion des informations et des événements de sécurité (SIEM).

Le Clusif présente donc les grands principes de fonctionnement d’un SOC, assorti d’exemples de processus (pour la détection, la qualification des alertes, mais aussi la supervision et l’administration du SOC, notamment), de structuration des équipes, d’instances de pilotage. Sans compter les interfaces multiples avec les exploitants du système d’information. 

Force est constater que les membres du groupe de travail du club ont poussé loin leur travail, allant jusqu’à décrire précisément différents rôles au sein du SOC, de la maîtrise d’ouvrage au reporting, en passant par la veille, les analystes, la coordination des actions ou encore la maintenance et l’administration, notamment. 

Dans leurs conclusions, on trouvera également des exemples d’indicateurs de contrôle et de suivi de l’activité, ainsi que d’indicateurs stratégiques, comme le taux de disponibilité de la fonction détection ou le nombre d’incidents avérés sur le SI, mais également d’organisation de la gouvernance, entre comité de pilotage et comité stratégique. 

Connectée au reste de l’entreprise

Pour le Clusif, le SOC a d’abord et avant tout un rôle de surveillance du système d’information. Ce n’est donc pas lui qui s’occupe de l’analyse de risque, ni de la conception du plan de continuité de l’activité. Il n’organise pas non plus la gestion de crise et ne se substitue pas aux équipes de réponse à incident (CSIRT), même si la présentation du catalogue de services du SOC peut en donner l’impression. Le SOC « est en interaction forte » avec ces équipes. C’est à elles qu’il incombe d’enquêter sur les alertes remontées par le SOC. Lequel soutient les équipes de réponse à incident dans leurs missions, ne serait-ce qu’en s’interfaçant avec la plateforme de réponse aux incidents.

Cette interface avec les processus de réponse aux incidents n’est pas la seule : « le SOC ne doit surtout pas fonctionner seul, mais doit s’intégrer aux processus existants » eux-mêmes liés à la gestion de la sécurité, mais pas uniquement. Au total, « le SOC devra intégrer l’ensemble des parties concernées au-delà du seul RSSI », ce qui recouvre aussi les métiers ou encore le support. Au final, il convient donc de définir les processus opérationnels qui seront traités dans le SOC et ceux qui ne le seront pas.

Et soutenue par le sommet de la hiérarchie

Dans ce contexte, le groupe de travail du Clusif relève que la mise en place d’un SOC doit s’inscrire dans « la stratégie globale de l’entreprise », telle que définie par le comité exécutif, après réflexion sur « la place de la sécurité des systèmes d’information dans cette stratégie » ainsi que sur « les évolutions, tant dans l’environnement externe qu’interne de l’entreprise ». C’est cet ensemble qui doit servir à la définition des objectifs de la mise en place d’un SOC.

Mais les auteurs des conclusions préviennent : « le SOC demande une quantité de travail importante pour produire des résultats, et il est nécessaire de limiter sa couverture dans un premier temps, afin d’obtenir des résultats rapides et concluants ». Et cela commence donc par les segments du SI les plus critiques, notamment pour pouvoir mobiliser les intervenants, en se concentrant sur les composants d’infrastructure, parce que « c’est là que l’on peut détecter les principaux vecteurs d’attaque ». 

Reste à convaincre tous les acteurs concernés. Le Clusif conseille là de « commencer par les entités métiers » afin que le promoteur du projet puisse affiner sa présentation. Mais il faut ensuite convaincre le comité exécutif, de manière progressive, notamment en sensibilisant pour « obtenir l’adhésion au projet ». 

Un large éventail d’outils

Le Clusif ne fait bien sûr pas l’impasse sur les ressources techniques du SOC, soulignant qu’il a besoin de s’intégrer avec le reste du SI pour « accéder à des bases d’information telles que des annuaires, des bases d’inventaire (CMDB), des bases de vulnérabilités ». Tout cela permet notamment de disposer de données relatives au contexte interne. Le renseignement sur les menaces permet quant à lui de se doter d’informations sur le contexte externe. 

A ces sources s’ajoutent les journaux d’activité des composants fonctionnels, d’infrastructure et de sécurité du système d’information. Autant de données à consolider et traiter, et c’est tout l’objet du SIEM. Mais toutes ces sources de données peuvent être complétées par d’autres, comme des systèmes de détection/prévention d’intrusion sur les hôtes, ou encore les systèmes de détection et de remédiation sur le point de terminaison (EDR). Le SIEM lui-même peut se faire épauler par des systèmes d’analyse comportementale (UEBA) pour la découverte d’anomalies.

Le Clusif ajoute à cet éventail une base de connaissances permettant de stocker les documents produits et reçus par le SOC. Enfin, le SOC doit être « correctement maîtrisé » pour assurer la confidentialité et l’intégrité des données qu’il traite, avec une traçabilité complète des actions. Et cette sécurisation du SOC vaut autant pour « la sécurité physique que logique ».