Mettre en place un SOC, un défi aux composantes multiples

Qu’est-ce qu’un SOC ?

Et cela commence par la définition d’un SOC. Si la question peut paraître naïve, il n’en est rien. Comme le relèvent Martine Guignard, RSSI de l’Imprimerie Nationale, mais aussi et surtout – dans le cadre de cette table ronde – secrétaire générale du Club de la Sécurité de l’Information Français (Clusif), et Jean-Marc Grémy, fondateur de Cabestan Consultants et vic-président du Clusif, la question a été au cœur de rien moins que trois réunions de deux heures d’un groupe de travail dédié au sujet. De quoi aboutir à un consensus autour des services attendus d’un SOC : la prévention, la détection et la réaction.

Rodrigue Le Bayon, responsable du pôle surveillance d’Orange Cyberdéfense, présente une analyse comparable : pour lui, le SOC est avant tout une « organisation opérationnelle » rassemblant plusieurs fonctions de supervision – « sans même parler de la réponse aux incidents qui est liée à la détection des attaques » car « la remédiation n’est pas forcément sous la responsabilité d’un SOC ».

Pour Arnaud Hess, directeur du développement de l’offre cybersécurité de Sopra Steria, la gestion des événements de sécurité est bien « la première activité qui peut caractériser un SOC ». Mais il y ajoute aussi la réponse aux incidents et « le maintien en conditions opérationnelles des outils de détection ». Et de préciser que « pour certains », le rôle d’un SOC est également de gérer les vulnérabilités.  

Les logs, premier carburant du SOC

Pour assurer un ensemble de missions qui peut donc paraître vaste, le SOC s’appuie en particulier sur les logs. Mais pas uniquement. Arnaud Hess relève ainsi que « l’on sait très bien qu’avec les logs, on ne voit que 5 % ou 10 % des attaques ». Dès lors, il appréhende plutôt la trousse à outils du SOC comme un « écosystème », dans lequel il fait également entrer la capture de flux, mais également les bacs à sable, les bastions d’administration, les systèmes de gestion des identités et des accès. Rodrigue Le Bayon ajoute à cela les outils de gestion des vulnérabilités ou de détection des « déviances comportementales ».

Le célèbre système de gestion des événements et incidents de sécurité (SIEM) s’ajoute à cet ensemble, comme « une clé de voute ». Et de voir là une « bonne nouvelle » : « les SIEM sont aujourd’hui arrivés à maturité. Il y a beaucoup de bonnes solutions sur le marché qui offrent les fonctionnalités nécessaires à la corrélation, à l’analyse. Ce qui n’était pas forcément le cas il y a cinq ans ».

Arnaud Hess va au-delà, évoquant l’importance du ticketing : « le SOC est une organisation. Il faut savoir communiquer des tickets, les transférer à des équipes de production, parce que le SOC est avant tout dans le faire-faire ».

De son côté, Martine Guignard ajoute à l’édifice les outils de reporting : « rapporter à différents niveaux est important, pour les équipes les plus techniques, mais aussi pour les RSSI qui veulent disposer d’une vision plus globale, et pour la direction générale qui a beaucoup investi et souhaite mesurer le retour sur investissement ».

Sur ce point, Arnaud Hess se montre très réservé : pour lui, il n’est pas trivial d’établir un retour sur investissement pour un SOC. Mais il n’en reste pas moins nécessaire « de montrer ce que l’on voit pour, le cas échéant, réorienter la capacité de détection ». Pour Martine Guignard, assurément, « un SOC qui ne produirait pas un certain nombre d’indicateurs n’aurait pas de saveur ».

L’autre pilier, les compétences

Mais les compétences s’imposent comme second pilier, clé, d’un SOC. Car pour Jean-Marc Grémy, si l’adage veut qu’il soit difficile de « chercher une aiguille dans une botte de foin », il est considérablement plus complexe de « chercher une aiguille dans une botte d’aiguilles ». Et pourtant, c’est bien à cela s’apparente le travaille d’un SOC. Et là, les compétences jouent un rôle essentiel, en particulier pour l’analyse. Et d’autant plus que, pour lui, si le centre opérationnel de sécurité est là pour identifier et réagir à des menaces, il doit aussi permettre de construire une approche de prévention, voire même d’anticipation. Et pour cela, il est essentiel de « mettre en relation des menaces avec le contexte de l’entreprise. C’est une compétence assez nouvelle à côté de laquelle il ne faut pas passer pour réussir son déploiement de SOC », juge-t-il.

Martine Guignard souligne toutefois que la mise en place d’un SOC est en fait « un projet comme un autre », qui nécessite un pilotage rigoureux, aligné sur la stratégie de l’entreprise « pour qu’il la valorise ». Mais il n’en est pas moins nécessaire de disposer de compétences bien spécifiques, pour « s’occuper des outils de base, comme le SIEM et les sondes. Ce ne sont pas des outils simples ». Sans compter aussi avec les personnes qui devront faire l’interface entre cette population et le pilotage.

Jean-Marc Grémy relève l’importance de spécialistes capables là d’ajuster précisément la configuration des différents systèmes impliqués. Car pour lui, lorsque l’on déplore les faux positifs, « c’est surtout parce que l’on ne connaît pas notre SI. Si on sait expliquer à la machine ce qu’elle doit faire, on n’a plus de faux positifs ».

Mais recruter et conserver les profils requis n’a rien de l’évidence. Les experts les plus compétents ne sont pas nombreux – « et l’on n’est pas forcément capable de les embaucher », relève Martine Guignard. Qui souligne également ceux-ci peuvent s’ennuyer dans la routine d’un environnement opérationnel où les incidents les plus stimulant – intellectuellement – ne relèvent pas forcément du quotidien. Un regard que partage Rodrigue Le Bayon : « les experts, c’est bien. On veut toujours les meilleurs. Mais le SOC est avant tout un métier opérationnel qui peut être usant ».

Commencer avec modestie

Dans la pratique, la mise en place d’un SOC apparaît devoir se faire de manière progressive, en commençant par un périmètre limité, on se préparant à « apprendre en marchant », souligne Jean-Marc Grémy. Ne serait-ce qu’afin de pouvoir commencer sur une base connue, comprise, maîtrisée. « Il ne faut pas être trop ambitieux au départ », insiste Martine Guignard, et se concentrer sur « un, deux ou trois systèmes d’information les plus critiques », en déployant « par couches », sans chercher à couvrir d’amblée toute la pile de l’infrastructure aux applications. Un point de vue qu’Arnaud Hess et Rodrigue Le Bayon partagent. Et à plus forte raison que les métiers doivent être impliqué dès le début, ne serait-ce que pour produire l’analyse de risques qui servira de base à la définition des alertes.

L’infrastructure peut fournir d’importantes informations, mais étendre la collecte et l’analyse aux applications peut s’avérer très difficile : « c’est un gros travail avec les métiers, car on ne trouve clairement pas ce dont on a besoin, dans leurs logs, pour faire de la sécurité », souligne Arnaud Hess.

Pour Rodrigue Le Bayon, l’approche progressive a également une autre justification : « pour réussir, il faut convaincre. Et pour convaincre, il faut être accessible ». Ce qui impose d’établir une feuille de route partant d’un périmètre initial et prévoyant des extensions. Avec à chaque fois, des retours d’expérience « pour montrer ce qui a pu être identifié et découvert », mettre en évidence les premiers gains.

Identifier ses besoins… et ses capacités

Actuellement, la conformité réglementaire – pour les opérateurs d’importance vitale, notamment, mais également les organisations traitant des données personnelles – constitue l’un des premiers moteurs qui poussent à la mise en place d’un SOC. Car pour pouvoir, par exemple, déclarer ses incidents de sécurité, « encore faut-il en avoir connaissance », souligne Martine Guignard. Mais même en interne, un SOC et les indicateurs qu’il produit peuvent aider à sensibiliser les collaborateurs aux questions de cybersécurité, explique Rodrigue Le Bayon.

Pour Arnaud Hess, le SOC peut aussi se présenter « comme une étape » naturelle dans l’évolution de la maturité des entreprises face à des questions d’image, de fuites de données, ou encore de prise de conscience du risque représenté par les menaces avancées persistantes (APT) – « certains directions veulent avoir des moyens de détection efficaces ».  

Mais là encore, il s’agit de se montrer réaliste et en adéquation avec ses capacités. Le SOC relève du « faire-faire », rappelle-t-il : « les plans d’action qui vont en sortir doivent pouvoir être traités ». Dès lors, est-il bien raisonnable de vouloir un SOC qui travaille en continu, en 24/7, si la production n’est disponible qu’en heures ouvrées ? Pour Arnaud Hess, la production doit être impliquée dès le début du projet.

De quoi peut-être, alors, justifier le recours au moins partiel à l’externalisation. Car pour Jean-Marc Grémy, si les attaquants misent la moindre baisse de vigilance, ne pas chercher à faire fonctionner un SOC en 24/7 n’a qu’un intérêt limité. Mais le faire, « ce n’est pas facile… »