Comment bien déployer un Security Operation Center ?

Un SOC est une entité qui s’appuie à la fois sur des logiciels et des analystes de sécurité organisés pour détecter, analyser, signaler, répondre et prévenir les incidents de cybersécurité.

Afin de mener à bien ces missions, le SOC repose sur l’analyse de volumes très importants de données, analysées en temps-réel.

Comme l’explique cet article de GBHackers : « Pour qu’une organisation soit considérée comme un SOC, elle doit fournir un moyen aux administrés de signaler les incidents de cybersécurité présumés, une assistance pour le traitement des incidents à ses membres et diffuser les informations relatives aux incidents aux parties prenantes et aux parties externes ».

Définir ses besoins

Avant d’être déployé, un SOC doit être pensé : sa conception a pour but de répondre à des besoins précis, qui sont propres à chaque entreprise. Il n’existe pas deux SOC identiques.

Pour certaines entités, une partie de ces besoins provient notamment des exigences règlementaires nationales, comme la loi de programmation militaire (LPM) qui impose le recours à un SOC qualifié PDIS (Prestataires de détection d’incidents de sécurité) pour les OIV (opérateurs d’importance vitale). Au niveau européen, c’est la directive NIS qui qualifie certaines entreprises d’OSE (opérateurs de services essentiels).

Penser la collecte des données

En plus des règles imposées par les lois nationales et internationales, la conception du SOC se base sur un certain nombre d’études. Celles-ci ont pour but de définir des règles de détection (auxquelles nous consacrons un paragraphe plus loin). Elles sont conçues pour couvrir les risques à partir des cas d’usage les plus probables et qui concernent le plus grand nombre (détection du phishing, des malwares, etc.) ou de scénarios plus spécifiques à chaque contexte. Un SOC identifie ainsi ce qui diffère d’une norme.

Afin de récolter les données nécessaires à la conception des règles de détection, il faut :

• réaliser une analyse de risques ;
• identifier les données qui sont collectables et qui permettent de couvrir les risques identifiés lors de l’analyse.

Penser l’organisation de travail

La construction d’un SOC nécessite une organisation complexe car ce dernier reste opérationnel 24/7/365. Un contexte qui soulève certaines questions en termes de recrutement et d’organisation du travail : sans analystes, pas de SOC.

Une fois les informations ci-dessus recueillies, la phase de « build » commence. Cette phase est assez technique puisque c’est celle de la configuration du SIEM, ou Security Information and Event Management. C’est le logiciel qui permet de détecter un incident ou une déviance. Le SIEM se configure pour répondre aux besoins et au contexte de sécurité de chaque entreprise.

Pour cela, il doit collecter des données.

SIEM : quelles données doivent-être collectées ?

Le but principal de la phase « build » est :

Les données collectées proviennent de sources aussi diverses que :

• les applications ;
• les postes et terminaux des utilisateurs (si l’entreprise utilise un dispositif de type EDR) ;
• d’extraire et de normaliser les données ;
• d’enrichir les données d’informations contextuelles ;
• de mettre en place les règles de corrélation.

Les données collectées proviennent de sources aussi diverses que :

• les applications ;
• les postes et terminaux des utilisateurs (si l’entreprise utilise un dispositif de type EDR) ;
• les équipement d’infrastructure ou de sécurité (relais, parefeu, anti-virus, etc.) ;
• les serveurs Windows & Linux, physiques, virtualisés, sur site ou dans un cloud ;
• des objets connectés, les systèmes industriels, etc.

SIEM : Comment déterminer les règles de détection ?

La mise en place des scénarios de détection est un processus complexe. Ces derniers sont basés sur l’analyse et la corrélation des données collectées.

Pour déterminer les bons scénarios pour votre entreprise, des règles d’infrastructure et des règles dîtes « métiers » seront établies. Ces règles sont tenues d’évoluer selon les réalités du terrain et notamment l’état de la menace, une veille permanente des logs est prévue.

SOC, SIEM : la gestion des faux positifs

Le SOC est conçu pour générer des alertes en cas de détection d’anomalies. Cependant, ces alertes peuvent être des faux-positifs. C’est-à-dire qu’elles ne sont pas des menaces réelles. Pour limiter au maximum ces fausses alertes, une définition précise des menaces et des actions d’un scénario sont nécessaires.

Un SIEM mal configuré fait perdre un temps considérable aux analystes. Aussi, il vaut mieux passer le temps nécessaire à déterminer la configuration pour son entreprise.

A noter que l’incorporation de renseignements sur les menaces – aussi appelée Threat Intelligence – demeure une solution efficace pour les phases d’enquête notamment.

Le déploiement d’un SOC dans une entreprise passe par la phase de RUN : c’est la conduite du SOC. Il s’agir de veiller à la remontée des alertes et réaliser les investigations.

Comme vu précédemment, un SOC doit être opérationnel continuellement. Cela nécessite donc des ressources humaines. Il faut des ingénieurs analystes, des opérateurs et des experts pour piloter et surveiller le SOC. Plusieurs options s’offrent à vous dans cette phase RUN. Vous pouvez opter pour la formation d’une équipe interne ou solliciter le service d’une équipe externe.

Par ailleurs, il est possible d’héberger le SIEM de l’entreprise au sein des infrastructures de cette dernière. Beaucoup d’entreprises optent pour un hébergement cloud. L’organisation du personnel en charge du SOC doit faire l’objet d’une étude plus approfondie et respectueuse du cadre règlementaire, notamment en ce qui concerne les rotations jour/nuit.

Pour être en mesure de fonctionner 24/7, une entreprise a besoin d’au moins six analystes par équipe, ce qui représente une grosse masse salariale chaque année. A ces coûts s’ajoutent ceux du recrutement, de la gestion et du maintien des compétences, mais aussi de l’acquisition, du développement ou de l’intégration des logiciels et infrastructures dont le maintien en conditions opérationnelles ou de sécurité doit être garanti. Il faut également prendre en compte le temps de mise en place nécessaire pour être opérationnel.

Ainsi, toutes les entreprises n’ont pas les moyens de construire leurs propres SOC. Elles se tournent donc vers des fournisseurs de services de cybersécurité.

L’automatisation de la gestion des alertes

L’automatisation de certaines tâches fastidieuses liées à l’exploitation du SOC serait d’une grande aide pour les opérateurs et les analystes. Bon nombre d’outils d’automatisation, dont ceux pour la gestion des alertes, existent sur le marché. D’autres sont encore en cours de développement. Il convient de bien les choisir selon leur réelle performance et leur maturité.

La mise en place d’une automatisation suppose néanmoins un prérequis en matière d’efficacité et de maturité des systèmes de détection orchestrés.

Pour en savoir plus, vo­us pouvez lire notre article « Vers le SOC automatisé ? », en cliquant ici.

Conclusion

Un SOC bien configuré est votre meilleur allié pour détecter les menaces. Aussi, il est important que les règles de détection et de corrélation soient régulièrement questionnées et mises à jour par des équipes expertes, expérimentées et au fait du contexte métier

La sécurité est un ensemble de processus, et non un produit.

Pour découvrir nos offres d’accompagnement à la construction d’un SOC (PDIS ou non) ou pour bénéficier des services de Manage Detection and Response (MDR), cliquez ici.