La boîte à outil du SOC : de la détection à la gestion des incidents

Le CERT propose également d’autres services à mettre en avant, absent de la partie SOC justement et c’est ça qu’il faut valoriser.

Pour exemple, pas plus tard qu’hier, le CERT a permis d’identifier la cause d’un blacklistage par Google d’un site de nos clients via leur surveillance.

Quelle répartition des rôles entre un SOC et un CERT ?

Dès lors qu'un incident est identifié, le SOC initie la phase de réponse à l'incident en proposant un premier plan de remédiation « à chaud » et va pouvoir s’appuyer sur les équipes du CERT (Computer Emergency Response Team) pour une investigation approfondie. Le CERT est le prolongement opérationnel du SOC, les équipes du CERT ont la capacité d’aller sur le terrain et au contact des systèmes concernés par l'incident. Le modèle appliqué détection-réponse est similaire aux systèmes de télésurveillance de plus en répandus pour protéger nos habitations contre les vols et effractions. Les échanges entre un SOC et un CERT vont également bien au-delà de la seule phase de remédiation ; le CERT fournissant différents services de veille, dont la Threat Intelligence qui va permettre d’améliorer la détection du SOC.

Quels sont les besoins de communication entre des personnes du SOC et d'un CERT ?

Sur confirmation d’un incident sécurité, le CERT va être activé soit directement par le SOC, soit à la demande du client à la réception du premier rapport d’investigation ; pour une réponse efficace la communication tripartite SOC – client – CERT est clé.. Si les emails restent un grand classique, ils rendent difficiles toute velléité de traçabilité ou de capitalisation. L'utilisation d'un système de ticketing est donc essentielle, et permet de conserver le trace et l'état de traitement de chaque incident. Encore très souvent, les systèmes utilisés par un SOC ne sont que rarement interconnectés avec un système de ticketing ou, lorsqu'ils le sont, c'est fait via des scripts développés en interne et le copier/coller manuel entre outils a encore la vie dure !

Pour que le CERT puisse intervenir rapidement et de façon efficace, il doit obtenir les informations les plus pertinentes possible sur l'incident, mais aussi sur son contexte. Les mises à jour doivent être régulières, car la situation peut rapidement évoluer. Le SOC doit aussi conserver la visibilité sur les activités du CERT afin d'affiner la supervision, mettre à jour ses règles sur la base d'IOC découvertes par le CERT, etc. Durant la gestion d'un incident, la communication entre les équipes du SOC et du CERT doit être continue et bidirectionnelle - les outils utilisés ont donc une place importante à jouer pour les échanges restent le plus fluides et complets possible.

Interconnexion avec d'autres systèmes métiers

S'ils doivent communiquer entre eux, le SOC et le CERT ont aussi besoin d'informations le plus à jour possible sur les systèmes d'information - et de connaitre les points de contact associés (administrateurs ou personnes responsables). Avec ces informations, le SOC et le CERT seront en mesure d'ajuster leur réponse au niveau de criticité du système, des données présentes sur celui-ci, des applications métiers spécifiques, ce afin de demander éventuellement le soutien des personnes - pour de la documentation ou pour simplement les informer que leur système est l'objet d'un incident de sécurité. Ces informations sur les systèmes, leur configuration et points de contact sont habituellement stockés dans des bases de données ou applications connues sous le terme de CMBD (Configuration Management Database).

Alors que les outils utilisés entre le SOC et le CERT sont assez fréquemment interconnectés (même si cela est fait de façon plus ou moins "artisanale"), c'est très rarement le cas avec d'autres systèmes comme les CMDB. Sans l'interconnexion avec un référentiel comme un CMDB, pour chaque incident - ou presque - c'est la course pour collecter des informations sur un système, obtenir des points de contact sur les personnes en charge de celui-ci ...

Interconnexion entre plusieurs outils, consolidation d'outils ou un seul et unique outil ?

Pour fluidifier les échanges entre les équipes du SOC en charge de la supervision et celles du CERT en charge de la réponse à incident ainsi que les personnes assurant la gestion opérationnelle au quotidien des systèmes, 3 approches peuvent être envisagées :

1. Interconnecter les systèmes entre eux en utilisant les API, quand cela est possible, via des scripts ou autres traps SNMP, ou même via des protocoles ou format de données spécialement conçus pour le partage d'informations sécurité comme TAXII ou STIX. Cette approche a le mérite de conserver l'existant, mais elle reste complexe, surtout si l'on souhaite interconnecter un grand nombre de systèmes. Cette intégration reste souvent limitée aux systèmes de sécurité utilisés par le SOC et le CERT sans aller jusqu'à une interconnexion avec les référentiels métiers comme les CMDB.
2. Déployer un IRP (Incident Response Platform) ou SIRP (Security Incident Response Platform) permettant d'avoir un système unifié et cohérent pour que les personnes du SOC et celles du CERT puissent partager de façon efficace les informations utiles durant la gestion d'un incident de sécurité, tout en proposant une interconnexion plus ou moins complète avec les référentiels métiers de type CMDB. On parle ici d'outils spécifiques par exemple "Resilient" proposé par IBM, "Archer Security Operations" de RSA ou encore la solution OpenSource FIR (Fast Incident Response) issue du CERT Société Générale.
3. A l'opposé de ces systèmes conçus initialement pour la gestion des incidents de sécurité, on voit aussi que des acteurs comme ServiceNow qui étaient historiquement spécialisés dans les services Cloud de gestion de systèmes (ITSM - IT Seervice Management) proposent des fonctions de type ISP/SIRP. L'approche est séduisante, car elle permet d'avoir une intégration quasi instantanée avec les activités opérationnelles des systèmes et des équipes en charge de ceux-ci. La limite de tels systèmes, pour le moment du moins, c'est qu'ils auront des difficultés à s'intégrer avec des sources de "Threat Intelligence", à intégrer des fonctions d'analyse des risques, etc. que l'on retrouve dans les IRP/SIRP.

Solution du futur ou est-ce que c'est du "real-life" ?

Ces solutions "intégrées de bout en bout" restent encore assez peu déployées opérationnellement, mais les projets sont là, que ce soit chez des opérateurs de services de cybersécurité ou encore des organisations particulièrement exposées comment celles du monde de la finance ou de l'énergie. Si le déploiement d'un système "intégré" comme un SIRP peut être à la cible, ce type de projet prend du temps, car il implique un grand nombre d'autres acteurs et de directions. Le point de départ évident est de mettre en place une interface plus forte via des scripts (ou autres outils développés en interne) avec les systèmes de ticketing ou de référencement du parc, pour ensuite lancer un projet de refonte avec le déploiement d'un SIRP qui capitalisera sur la connaissance acquise lors des premières étapes du projet.

Dans le cas de l'utilisation d'une plateforme d'ITSM en mode cloud, cette intégration sera grandement facilitée, au moins sur le volet technique, car le déploiement est à la portée de quelques clics une fois les options de service souscrites. Quel que soit le mode de déploiement, le volet organisationnel et les processus attenants restent équivalents.

Les systèmes de SIRP sonnent-ils le glas pour les outils spécialisés à des "verticaux métiers" ?

Non, comme les systèmes de type SIRP se positionnent après le SIEM, ce dernier continue à assurer notamment la fonction de collecte des logs et informations en provenance des systèmes supervisés. Pour détecter des menaces spécifiques à l'activité d'un client il y a besoin de systèmes eux aussi spécifiques, par exemple détecter des transactions frauduleuses dans des flux bancaires ou encore des attaques sur des systèmes SCADA. Ces systèmes sont techniquement différents, le format et la nature des informations collectées sont différents et la façon de les corréler et de les analyser est elle aussi spécifique.

Il faut donc conserver des outils spécifiques pour superviser chaque famille de systèmes, pour ensuite générer des alertes à destination du SIEM qui fera à son tour son travail de corrélation entre systèmes potentiellement hétérogènes - une fois les informations "normalisées".

En quelques mots, comment sont organisées les activités de SOC et de CERT d'Orange Cyberdefense ?

Au sein d'Orange Cyberdefense, les activités de SOC et de CERT proposées à nos clients sont organisées autour d'un SOC localisé sur Rennes avec des équipes du CERT réparties sur le territoire national sur Lille, Lyon et évidemment Paris, ainsi qu’à l’international à Singapour et Montréal. Nos clients sont majoritairement de grandes entreprises Européennes et Français mais aussi des clients de la sphère gouvernementale. De fait, les systèmes dont nous avons la charge sont de taille variable et pour certains d'entre eux particulièrement complexes.

Propos recueillis par Jean-François AUDENARD

Pour aller plus loin

[Infographie] Baromètre Cybersécurité 2017 : où en est l’industrie française ?

Le CyberSOC, un centre opérationnel pour la détection d'incidents de sécurité

Computer Emergency Response Team : qu'est ce qui fait l'efficacité d'un CERT ?

Orange Cyberdefense protège vos essentiels