Le SOC, un projet au moins aussi organisationnel que technique

Les entreprises sont de plus en plus nombreuses à s’équiper d’un centre opérationnel de sécurité (SOC). Un hasard ? Pas vraiment.

Dans certaines organisations, la réglementation en fait un passage obligé. On pense aux opérateurs d’importance vitale. Ou à la future directive européenne NIS qui va ap­porter de nouvelles obligations à un éventail plus large d’organisations. Sans oublier le règlement européen sur la protection des données personnelles.

En somme, le SOC s’impose comme élément critique de la cybersécurité, comme un cockpit indispensable pour assurer la supervision d’une infrastructure, contre les menaces internes et externes.

Et pourtant, beaucoup échouent à surveiller effective­ment les menaces existantes et émergentes. Selon une récente de HPE, huit SOC sur dix sont en-deçà du niveau de maturité nécessaire : ils n’atteignent pas le niveau où les opérations sont « bien définies, évaluées de manière subjective et flexibles ». La méthodologie retenue par HPE et son échantillon peuvent prêter à discussion, mais force est de reconnaître que son étude n’est pas la seule à aboutir à cette conclusion.

A l’automne dernier, SecuriView a présenté les résul­tats d’un sondage de 33 utilisateurs de SOC en France. L’approche de Stéphane Dahan, son président, était sim­ple : « beaucoup d’entreprises sont dans le brouillard pour leurs projets SOC. Il existe, certes, une littérature dense pour leur mise en place, mais pas pour leur exploita­tion ». D’où l’idée de collecter des témoignages, pour dé­gager des tendances, sur toutes les phases d’un tel projet, depuis sa conception jusqu’à son exploitation.

Son premier constat est sans ambiguïté. « Beaucoup de choses sont faites sans maturité ». De quoi effectivement produire beaucoup de déconvenues.

Dans le détail, Stéphane Dahan explique que les projets SOC sont souvent initiés de manière isolée par le RSSI, sans soutien de la direction générale, ni de la gestion du risque, ni du juridique, et encore moins des métiers.

Les conséquences, lorsque le projet prend forme après, parfois, des années de réflexion, sont sans surprise. Il s’agit alors d’impliquer des tiers, à commencer par les métiers, la production. Mais pour eux, « c’est alors une charge de travail qui n’était pas prévue, qui n’a pas été an­ticipée ».

Et ce qui peut être perçu comme imposé brutalement, fait souvent grincer quelques dents. « Les phases de con­struction traînent, avec beaucoup d’équivalents temps plein qui n’avaient pas été provisionnés ». Dès lors, les budgets prévus s’avèrent, en définitive, trop serrés.

Souvent également, les entreprises apparaissent se lancer seules, sans recourir à une prestation d’assistance à maî­trise d’ouvrage, dans des projets plus construits autour d’un système de gestion des informations et des événe­ments de sécurité (SIEM) que d’une réflexion sur les ris­ques. De quoi, là encore, trahir un manque de maturité.

Parce qu’en fait, si le SOC s’appuie sur des outils tech­niques, il n’est que le bras d’une politique de sécurité du système d’information claire, précisément définie avec les métiers, sur la base d’une analyse des risques concernant l’organisation.

Le tout s’articulant autour de processus rigoureux pour la réponse aux incidents. De quoi souligner, si c’était nécessaire, qu’un projet SOC comporte une composante organisationnelle au moins aussi importante que sa com­posante technique.