vectorfusionart - Fotolia

SOC et réponse à incident : deux équipes, main dans la main

Les équipes chargées de la surveillance de l’infrastructure et de la détection des incidents sont appelées à travailler en étroite collaboration avec celles dediées aux réponses aux incidents.

Cet article se trouve également dans ce contenu premium en téléchargement : Information Sécurité: Information Sécurité N°2 : entre SoC et CSIRT

Le Club de la sécurité de l’information français (Clusif) a récemment présenté les conclusions de son groupe de travail consacré à la mise en place d’un centre opérationnel de sécurité (SOC). Dans celles-ci, le SOC est présenté comme ayant avant tout un rôle de surveillance du système d’information. Ce n’est donc  pas à lui qu’incombe la gestion de crise et il n’a pas vocation à se substituer aux équipes de réponse à incident (CSIRT), même s’il se doit d’être « en interaction forte » avec elles.

Laurent Besset, responsable des activités audit et forensics d’I-Tracing, explique que, en pratique, cela peut être plus compliqué : « ce ne sont pas forcément deux choses vraiment différentes ». Pour lui, le CSIRT apparaît « en complet recouvrement d’une partie des activités » du SOC : « il porte principalement les activités de réponse aux incidents, la partie réactive. Traditionnellement, il a aussi un fonctionnement un peu plus communautaire que le SOC ». Et c’est en particulier le cas « lorsque le CSIRT est étiqueté CERT : il a aussi le rôle de partager les informations pour créer et alimenter un très gros référentiel, à l’interne et à l’externe ».

Une connaissance spécifique précieuse

Dès lors, pour l’entreprise se lançant ex-nihilo, « il n’y a pas de raison de créer deux entités séparées. Après, c’est juste une question de désignation ». Mais Laurent Besset souligne une spécificité historique : « en France, dans la plupart des cas, les CSIRT sont apparus avant les SOC ». Dès lors, dans les grandes entreprises concernées, il y a bien, de facto, deux entités distinctes : « la répartition des tâches la plus naturelle consiste à laisser les équipes CSIRT existantes continuer à faire de la veille pour alimenter en aval le SOC, et s’appuyer sur les expertises en réponse à incident, en niveau 3 ; la gestion en niveau un et deux étant laissée au SOC ». Ainsi, pour les incidents les plus graves, c’est le CSIRT « qui reprend la main ».

Dans un tel contexte, les offres d’externalisation de SOC peuvent se montrer particulièrement séduisantes. Car là, explique Laurent Besset, l’entreprise a tout intérêt à conserver son CSIRT existant : « la difficulté que peut avoir un prestataire SOC externe est de bien contextualiser les incidents ». Et si cela peut ne pas prêter à de lourdes conséquences dans le cadre d’incident bénin, il en va tout autrement pour un incident grave. D’où l’importance de la connaissance contextuelle spécifique développée par le CSIRT interne.

L’externalisation n’est  pas un frein à la réactivité…

Mais en fait, qu’il y ait externalisation partielle ou complète, il ne faut pas s’attendre à des impacts négatifs sur la gestion des incidents. Tout d’abord, souligne Laurent Besset, « tout se négocie », à commencer par les niveaux de service. Mais surtout, en cas de crise cyber, c’est un dispositif de gestion de crise complet qui est mobilisé, « avec beaucoup de personnes, de la production, de la communication, des ressources humaines, etc. ». Et là, impliquer des équipes internes du SOC s’avère naturellement pertinent.

Toutefois, pas question de leur demander de piloter ou de coordonner la gestion de la crise : « le SOC et le CSIRT agissent principalement en maîtres d’œuvre », pour les analyses ou la remédiation - la maîtrise d’ouvrage est positionnée un cran au-dessus, et assurément, entre les mains d’un responsable interne à l’entreprise.

Surtout, le recours à l’externalisation, au moins partielle, du SOC peut s’avérer extrêmement bénéfique, en particulier pour les structures de taille modeste qui n’ont qu’une expérience limitée de la gestion d’incidents de sécurité informatique. Cela est pertinent, ne serait-ce que pour avancer dans la formalisation de certains processus clés.

Mais un accélérateur de maturité

 « Documenter les processus de gestion des incidents fait partie du montage de tout SOC, qu’il soit interne ou externe », souligne ainsi Laurent Besset : « qu’ils soient peu ou mal documentés, que l’on n’ait ou pas les matrices détaillées des interlocuteurs des différents périmètres techniques, cela n’est pas extrêmement préjudiciable pour des incidents mineurs. Mais cela limite déjà la valeur ajoutée du service acheté ». Pourquoi ? « Parce que l’on va se trouver face à quelqu’un qui va détecter des incidents de manière industrielle, et dont les alertes vont s’empiler, sans être corrigées, ou en l’étant très lentement ». Alors certes, ce qui reste ainsi en attente, « ce sont des choses peu préjudiciables à la sécurité de l’entreprise ». Mais « le jour où l’on a un gros problème, si l’organisation n’est pas connue ni documentée, l’ impact est immédiat : on perd du temps pour mettre en sécurité l’entreprise et pour mettre fin à l’incident ».

Et cela risque rapidement de se traduire par des pertes financières ou une dégradation d’image… « Les incidents graves mettent surtout en lumière des défauts d’organisations jusque-là perçus comme ennuyeux ».

Dernière mise à jour de cet article : septembre 2017

Approfondir

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close