Sécurité du SI : Comment externaliser son centre opérationnel de sécurité

Face à la croissance du nombre de cyberattaques, vous êtes nombreux à rechercher des solutions pour protéger votre entreprise. En vous renseignant sur le sujet, vous en êtes arrivés à la conclusion que le Security Operation Center (SOC) est la solution pour sécuriser vos systèmes d’information.

Un SOC a pour mission de détecter les incidents de sécurité sur la base de traces ou de logs et d’initier les actions de réponse dès lors que cela est nécessaire. Un SOC ne remplace pas les mesures de sécurité traditionnelle (patch management, gestion du périmètre, firewalling, durcissement, …) qui restent essentielles et qui doivent être présentes. Mettre en place une détection d’incidents sans des bases saines ne fait évidemment pas de sens.

Les missions assurées par un SOC externalisé seront différentes en fonction du mode dans lequel il va s’intégrer avec l’organisation de son client. Dans le premier mode le SOC va analyser les logs sur la base de jeux de règles pour ensuite remonter vers son client les alertes pour que ce dernier puisse les qualifier et réagir.

Dans un tel mode de fonctionnement, la valeur ajoutée du SOC reste modérée, car il lui sera difficile de contextualiser les remontées d’informations – mais il a comme atout d’être rapide à mettre en œuvre.

Dans le second mode il assure directement le traitement et/ou le suivi des incidents pour lequel il va directement s’adresser aux équipes opérationnelles du client et mettre en place les actions de remédiation.

Dans ce mode, les équipes sécurité opérationnelles du client pourront rester mobilisées sur la mise en place des actions de remédiation ; les fonctions de supervision étant assurées par le SOC.

Une telle répartition des rôles et activités nécessite que le client dispose d’un système de type ITSM (IT Service Management). Il permettra au SOC de soumettre des demandes de façon autonome aux équipes en charge du SI tout en restant en contact avec les équipes sécurité opérationnelle pour les activités plus complexes.

Que faut-il mettre en place en interne pour externaliser son SOC ?

Pour qu’il soit efficace, un SOC a besoin d’éléments de contexte sur le SI qu’il supervise. Pour qu’un projet de SOC soit réussi, il est donc essentiel de disposer en interne d’une cartographie à jour de ses équipements et systèmes – via une CMDB (Configuration Management Database) ou un équivalent.

Quand on externalise un SOC, on va chercher de l’expertise dans le domaine de la supervision sécurité. En revanche, il est essentiel de maitriser les technologies et systèmes de génération de logs pour alimenter correctement le SOC avec des informations pertinentes pour faire face aux menaces détectées. Si une entreprise souhaite externaliser son SOC, elle devra investir humainement et techniquement dans ce domaine – ce qui passe par la définition de règles d’ingénierie spécifiques pour que les systèmes (applications, OS, équipements réseau ou de sécurité …) soient configurés de manière à générer les bons logs vers des systèmes définis.

Pourquoi un SOC doit-il évoluer dans le temps, comment doit-on s’y prendre ?

Les mesures de sécurité traditionnelles mises en place pourront se révéler insuffisantes (vulnérabilités, mauvaise configuration, etc…) et la détection devient un axe de travail primordial dans la posture de défense du client. D’autre part, les menaces, le système d’information et les solutions de sécurité évoluent rapidement.

Il est donc essentiel de mettre en place une boucle d’amélioration continue pour renforcer la résilience des systèmes dans le temps et diminuer les angles morts ; ceci de façon que le SOC soit en mesure de s’améliorer.

L’un des facteurs de réussite réside dans un challenge réciproque et collaboratif entre l’organisation et son prestataire de SOC. Le SOC doit savoir challenger son client pour l’aider à faire évoluer ses systèmes et faciliter la détection des menaces et des incidents. Parmi l’éventail des recommandations d’un SOC, on peut citer l’évolution et la contextualisation des règles de détection mais aussi des recommandations d’évolution concernant les sources de logs afin d’améliorer la qualité des événements à traiter.

Une bonne collaboration entre l’organisation et son prestataire de SOC passe par un reporting sur les incidents et leur traitement, mais aussi un suivi des actions d’amélioration continue.

Le contrat entre le client et le prestataire de SOC doit d’une part intégrer ces sujets d’amélioration continue et d’innovation. Il doit aussi proposer un catalogue de services définissant des évolutions inclues en standard dans l’offre de service (règles, parseurs, PoC R&D, etc) afin d'éviter de repasser à chaque fois via un cycle de contractualisation qui peut être lent.

Vous avez un projet de SOC ? Venez en discuter avec nos équipes et nous aiderons à le mettre en place.


STD Webinar: Digitalisation des processus & Transformation Digitale