Fotolia

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

Poussés à la fois par un contexte réglementaire de plus en plus exigeant et des menaces de plus en plus nombreuses, les centres opérationnels de sécurité se multiplient. Mais leur mise en place est délicate. Le Clusif s’est longuement penché sur le sujet.

Le Club de la sécurité de l’information français (Clusif) vient de présenter les conclusions de son groupe de travail consacré à la mise en place d’un centre opérationnel de sécurité (SOC). C’est le fruit de longs mois de travail visant à partager l’expérience des membres du club, pour « aider » les entreprises à s’y « retrouver dans les offres de sous-traitance de SOC ou pour construire un SOC internalisé ». Et la tâche n’est pas des moindres. Début 2016, lors d’une table ronde organisée au Forum international de la cybersécurité (FIC), Martine Guignard, RSSI de l’Imprimerie Nationale, mais aussi secrétaire générale du Clusif, et Jean-Marc Grémy, fondateur de Cabestan Consultants et vice-président du club, relevait que la question de la définition même d’un SOC avait été au cœur de rien moins que trois réunions de deux heures du groupe de travail.

Les conclusions du groupe de travail du Clusif commencent donc sans surprise par la description d’une entité qui doit « répondre au besoin de détection » des incidents, mais également d’y répondre, de manière « industrialisée et efficace », et aussi les prévenir, « en prenant en charge, par exemple, tout ou partie de la gestion des menaces et des vulnérabilités ». 

Pour chacun de ces domaines, le Clusif détaille les services qui peuvent liés au SOC, directement ou indirectement. En matière de prévention, il s’agit de la veille sur les vulnérabilités critiques, de la sensibilisation, et de la gestion des vulnérabilités. Pour la détection, on relèvera les tests d’intrusion, la veille (cybercriminalité, cybersquatting), les contrôles ponctuels en cas de suspicion, la qualification des alertes de sécurité, le contrôle de conformité avec les politiques internes, la collecte et l’analyse des journaux d’activité, les contrôles automatisés ou encore l’analyse de production. Côté réaction, le SOC doit pouvoir fournir des services d’investigation, de réponse active, ou encore de lutte défensive. Il doit également fournir des services d’administration de la sécurité, avec gestion des droits et des dérogations, gestion des administrateurs et des privilèges, et administration des équipements de sécurité.

L’éventail peut paraître vaste. Mais les auteurs expliquent qu’il ne s’agit pas forcément, pour chaque SOC, de chercher à produire dès le départ un catalogue complet, ni à fournir tous les services en interne. L’externalisation au moins partielle reste une piste viable.

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 ».

Pour approfondir sur Gestion de la sécurité (SIEM, SOAR, SOC)

Close