CERT

SMSI, CERT et SOC : la répartition des missions

Le SMSI, le CERT et le SOC ont tous trois pour mission de réduire le risque cyber et améliorer la résilience du système d’information. Pour autant, lorsqu'une organisation dispose de ces trois entités, la répartition des responsabilités peut rapidement devenir difficile à appréhender. Ces trois fonctions poursuivent le même objectif général mais interviennent à différents niveaux.

Un problème assez récurrent survient alors lorsque la répartition des missions n'est pas clairement définie. Un chevauchement des missions est inévitable dans un tel environnement, mais il doit être maitriser. Il faut éviter les responsabilités floues, les actions réalisées en double, les mesures de sécurité sans propriétaire, les incidents qui passent d’une équipe à l’autre ou, à l’inverse, les sujets dont personne ne se considère responsable.

L’objectif n’est donc pas de construire trois silos indépendants, mais de définir qui pilote, qui réalise, qui conseille et qui contrôle chaque activité.

1. Trois fonctions, trois niveaux d’intervention

Une manière simple de comprendre la différence entre ces trois fonctions consiste à les positionner sur trois niveaux.

Le SMSI se situe principalement au niveau de la gouvernance et du pilotage du risque. Il définit le cadre dans lequel l’organisation doit assurer sa sécurité : politique de sécurité, analyse de risques, exigences de sécurité, conformité, indicateurs, plans d'action et amélioration continue. ISO/IEC 27001 définit précisément le SMSI comme un système permettant d'établir, de mettre en œuvre, de maintenir et d'améliorer continuellement la sécurité de l'information.

Le SOC se situe principalement au niveau de la détection et de la surveillance. Il exploite les journaux, les outils de détection et les alertes de sécurité afin d'identifier des comportements suspects ou des attaques. Son rôle est essentiellement de répondre à la question : « Que se passe-t-il actuellement sur le système d'information ? »

Le CERT, intervient principalement sur la réponse aux incidents et sur l'amélioration de la capacité de défense. Il prend en charge les incidents nécessitant une analyse ou une réponse coordonnée, réalise ou pilote les investigations, accompagne les équipes techniques et contribue au retour d'expérience. Le CERT s'axe sur la réponse à incident et la consolidation de l'infrastructure.

Cependant, ces périmètres ne sont pas totalement étanches. Un SOC peut détecter un incident, mais il doit pouvoir transmettre celui-ci au CERT. Le CERT peut identifier une faiblesse lors d'un incident, mais cette information doit pouvoir alimenter le SMSI. Le SMSI peut identifier un risque nécessitant une mesure technique, dont le déploiement devra ensuite être suivi par les équipes opérationnelles.

2. Les zones de chevauchement

2.1 Un chevauchement inévitable

La difficulté commence lorsque l'on cherche à tracer une frontière parfaitement nette entre les trois équipes.

Prenons par exemple la gestion des incidents :

Le SMSI doit définir le processus de gestion des incidents, les niveaux de gravité, les responsabilités, les règles d'escalade et les indicateurs.
Le SOC va détecter et qualifier certains événements.
Le CERT va traiter les incidents nécessitant une réponse approfondie.

Qui « gère » réellement l'incident ?

La réponse dépend du sens donné au mot gestion :

Le SMSI peut être responsable du processus de gestion des incidents.
Le SOC peut être responsable de la détection et qualification.
Le CERT peut être responsable de la réponse opérationnelle.
Et les équipes IT restent responsables de l'exécution des changements techniques nécessaires à la remédiation.

Il n'y a donc pas nécessairement trois équipes qui font la même chose. Elles interviennent sur des dimensions différentes d'une même activité. Et cette distinction fait tout son sens. Et l'important ici, c'est que chaque responsabilité est définie et qu'il n'y ai pas de zone non-exploité.

2.2. Les dérives

2.2.1 Le CERT : une équipe de sécurité générale

Une première dérive consiste à transformer le CERT en équipe de sécurité générale.
Parce que le CERT possède des compétences techniques importantes, on peut progressivement lui demander de réaliser le hardening, les audits, les pentests, la validation des fournisseurs, le suivi des projets ou encore la gestion des vulnérabilités.

Le risque est alors de transformer une équipe de réponse à incident en une équipe « qui fait tout ce qui concerne la cybersécurité ».

2.2.2 Le SOC : centre de traitement des alertes informatiques

Une deuxième dérive consiste à transformer le SOC en centre de traitement de toutes les alertes informatiques. Le SOC finit alors par traiter des incidents qui ne relèvent pas de la sécurité, ou par effectuer des tâches d'administration nécessaires pour résoudre les problèmes détectés.

À l'inverse, on peut également créer un SOC qui détecte énormément d'événements mais dont personne ne prend réellement en charge les alertes escaladées.

2.2.3 Le SMSI : équipe de contrôle opérationnel permanent

Une troisième dérive consiste à faire du SMSI une équipe de contrôle opérationnel permanent. Le SMSI produit alors des exigences, réalise lui-même les vérifications techniques, relance les équipes pour chaque action et finit par devenir responsable de la mise en œuvre des mesures qu'il était initialement chargé de piloter.

Le risque est alors de perdre la séparation entre gouvernance et exécution.

2.2.4 Personne n'est responsable

Le problème inverse est probablement encore plus dangereux. Lorsqu'une activité se situe entre deux équipes, chacune peut considérer qu'elle relève de l'autre.

Prenons le cas d'une vulnérabilité critique :

le SMSI considère qu'il a identifié le risque
le CERT considère qu'il a communiqué la vulnérabilité
le SOC considère qu'il ne fait que surveiller
l'équipe système considère qu'elle attend une validation sécurité

Résultat : tout le monde a participé au traitement, mais personne n'en est réellement responsable.

C'est précisément pour éviter cette situation qu'une organisation doit attribuer un propriétaire à chaque processus ou activité.

La répartition des responsabilités

SMSI	CERT	SOC
Sensibilisation	Coordination de la réponse à incident	Qualification des événements de sécurité
Analyse de risque	Gestion de crise	Gestion des outils de détection
Définition des politiques de sécurité	Forensique	Qualification des détections
Suivi des indicateurs de sécurité	Root Cause Analysis	Gestion des vulnérabilités
Pilotage de la conformité	Audit technique
Suivi de la mise en place des mesures de sécurité	Hardenning des systèmes
Suivi des fournisseurs	Définition des mesures de sécurité

Conclusion

Cette répartition des responsabilités n'est qu'une proposition par rapport à ce qu'est censé représenter chaque équipe. Cependant, il est évident, que chaque organisation possède une vision propre de la répartition des missions entre ces équipes. Ce qui fonctionne pour une ne fonctionnera pas forcément pour un autre et sera même amené à évoluer avec l'organisation elle même.

Ce qui est important à retenir, c'est qu'il est indispensable de définir qui est responsable de quoi ; même si ça veut dire le redéfinir tout les ans ; pour éviter que certains point critique passe entre les mailles du filet. Et il faut aussi être conscient des biais qui existe et éviter de surcharger une équipe au détriment de son objectif initial.

_Sources :