SOC, SIEM et SOAR : détecter et répondre

Le PC sécurité des Arcades, allumé jour et nuit

Au sous-sol du centre commercial « Les Arcades », derrière une porte sans enseigne, une pièce reste éclairée en permanence. Un mur d'écrans y affiche les images des caméras réparties dans les galeries, les réserves, les parkings et les issues de secours. Devant ce mur, des agents de sécurité se relaient par roulement, vingt-quatre heures sur vingt-quatre.

Installer des caméras ne suffit pas. Une caméra qui filme un vol sans que personne ne regarde l'écran ne protège rien du tout. Ce qui protège réellement le centre, c'est la chaîne complète : capter les images, les rassembler au même endroit, repérer ce qui sort de l'ordinaire, et surtout déclencher une action quand quelque chose cloche.

Détecter et répondre sont deux choses distinctes. Une alerte que personne ne traite ne vaut pas mieux qu'une absence d'alerte. Le danger se déplace simplement de « on ne voit rien » vers « on voit mais on ne fait rien ».

Après avoir géré les identités et les accès à privilèges dans le billet précédent, le sujet du jour est la supervision. Trois termes reviennent sans cesse et se mélangent : le SOC, le SIEM et le SOAR. Ce billet les sépare proprement. Le SIEM, c'est la vidéosurveillance et le PC sécurité qui collectent et recoupent les images. Le SOC, ce sont les agents qui regardent les écrans en continu et décident quoi faire. Le SOAR, ce sont les procédures automatiques qui s'enclenchent quand un scénario connu se présente : déclencher l'alarme, fermer les rideaux, prévenir la police.

Le SOC : les humains derrière les écrans

Avant de parler d'outils, parlons des gens. Le SOC (Security Operations Center, centre des opérations de sécurité) est l'équipe et le processus qui surveillent la sécurité d'une organisation en continu. Aux Arcades, c'est l'équipe d'agents qui se relaie devant le mur d'écrans, qui connaît les habitudes du centre, et qui sait distinguer un client perdu d'un repérage suspect.

Un SOC n'est pas une pièce ni un logiciel, c'est une fonction. Sa mission tient en quelques verbes : surveiller, détecter, qualifier, et coordonner la réaction. Il tourne en 24/7 parce qu'une attaque ne respecte pas les heures d'ouverture. Le braquage se prépare souvent la nuit, quand on imagine la vigilance relâchée.

Le SOC est avant tout une affaire humaine et organisationnelle. Les outils l'amplifient, mais c'est le jugement d'un analyste qui transforme une alerte brute en décision.

Les niveaux d'analystes

Un SOC s'organise en général sur plusieurs niveaux, comme un service d'urgence trie ses patients. Tout le monde ne traite pas tout.

• Niveau 1 (L1) : le premier filtre. L'analyste surveille le flux d'alertes, écarte le bruit évident, et qualifie ce qui mérite attention. Aux Arcades, c'est l'agent qui balaie les écrans et repère qu'un même individu repasse pour la troisième fois devant la bijouterie.
• Niveau 2 (L2) : l'investigation. Quand une alerte tient debout, le L2 creuse, recoupe plusieurs sources, comprend l'enchaînement. C'est l'agent qui rembobine les enregistrements de plusieurs caméras pour reconstituer un trajet.
• Niveau 3 (L3) : l'expertise et la chasse. Les analystes les plus aguerris traitent les incidents complexes, cherchent activement les menaces qui ont échappé aux règles automatiques (le threat hunting), et améliorent les détections. C'est le responsable sécurité qui anticipe un mode opératoire jamais vu au centre.

Mesurer ce qui compte

Pour savoir si un SOC fait son travail, deux indicateurs reviennent partout. Le MTTD (Mean Time To Detect, délai moyen de détection) mesure le temps entre le début d'un incident et le moment où on le repère. Le MTTR (Mean Time To Respond, délai moyen de réponse) mesure le temps entre la détection et la maîtrise de l'incident.

Aux Arcades, le MTTD c'est le délai entre l'instant où le voleur entre dans la réserve et celui où l'agent le remarque. Le MTTR c'est le délai entre ce repérage et le moment où la porte est verrouillée et la police prévenue. Plus ces deux durées sont courtes, moins l'attaquant a le temps d'agir. Tout le reste du billet sert à les réduire.

Le SIEM : tout voir au même endroit

Un SOC humain ne peut pas surveiller à l'œil nu des milliers d'événements par seconde répartis sur des centaines de machines. Il lui faut un outil qui rassemble les informations et fait remonter ce qui compte. C'est le SIEM (Security Information and Event Management, gestion des informations et des événements de sécurité).

Aux Arcades, le SIEM correspond à l'ensemble vidéosurveillance plus PC sécurité : tous les flux des caméras convergent vers un même mur d'écrans, où ils peuvent être comparés. Sans cette centralisation, chaque commerçant aurait sa petite caméra dans son coin et personne n'aurait de vue d'ensemble.

Un SIEM ne sécurise rien par lui-même. Il donne au SOC une vue unifiée et corrélée, pour que des signaux faibles, dispersés et anodins pris isolément, deviennent un signal fort une fois rapprochés.

Collecte, normalisation, corrélation

Le SIEM travaille en plusieurs temps. D'abord la collecte : il aspire les journaux (logs) de toutes les sources, pare-feu, serveurs, postes de travail, applications, annuaire d'identités. Chacune parle son propre dialecte.

Vient ensuite la normalisation : le SIEM traduit ces formats hétérogènes vers une structure commune, pour pouvoir comparer une ligne de pare-feu avec une ligne de serveur. Aux Arcades, c'est l'équivalent d'horodater toutes les caméras sur la même horloge, sinon impossible de reconstituer une chronologie.

Enfin la corrélation : le SIEM applique des règles de détection qui rapprochent des événements venant de sources différentes. Un échec d'authentification isolé n'est rien. Cinquante échecs en une minute depuis une adresse inconnue, suivis d'une connexion réussie, puis d'un accès à un partage sensible, dessinent une attaque. La règle de corrélation relie ces points que personne ne verrait séparément.

Le revers : le bruit et les faux positifs

Tout n'est pas magique. Une règle trop large génère des faux positifs, des alertes qui ressemblent à une attaque sans en être une. Aux Arcades, c'est l'agent qui sursaute à chaque livreur passant devant une caméra, jusqu'à ne plus prêter attention aux alertes.

C'est le piège classique de la supervision : trop d'alertes équivaut à pas d'alerte, parce que l'analyste finit par toutes les ignorer (la fatigue d'alerte). Régler un SIEM consiste autant à écrire des règles qu'à les affiner pour réduire le bruit sans rater la vraie menace.

Le tableau suivant montre quelques sources de logs courantes et ce qu'on cherche à y détecter.

Le SOAR : automatiser la réponse

Détecter ne suffit pas, il faut agir, et agir vite. Quand le SOC repère un incident, une partie des gestes de réponse sont toujours les mêmes et se répètent à l'identique. Les automatiser, c'est le rôle du SOAR (Security Orchestration, Automation and Response, orchestration, automatisation et réponse de sécurité).

Aux Arcades, le SOAR ce sont les procédures qui s'enclenchent dès qu'un scénario connu se présente. Intrusion détectée dans la salle des coffres après la fermeture ? La séquence se déroule sans hésitation : déclencher l'alarme, fermer automatiquement les rideaux de fer du secteur concerné, verrouiller les issues, prévenir le commissariat. Personne n'a besoin de réfléchir à l'ordre des gestes, ils sont écrits à l'avance.

Le SOAR ne remplace pas l'analyste, il lui retire les tâches répétitives pour qu'il se concentre sur le jugement. La machine exécute le connu, l'humain tranche l'inconnu.

Playbooks et orchestration

Le cœur du SOAR, c'est le playbook : une procédure de réponse écrite à l'avance, une suite d'étapes déclenchées par un type d'incident. Face à un poste infecté, un playbook peut isoler la machine du réseau, désactiver le compte concerné, collecter les preuves et ouvrir un ticket, en quelques secondes au lieu de plusieurs minutes manuelles.

L'orchestration désigne la capacité du SOAR à faire dialoguer les outils entre eux : demander au pare-feu de bloquer une adresse, à l'annuaire de suspendre un compte, à l'EDR d'isoler un poste, le tout depuis un point central. Plutôt que de jongler entre dix consoles, l'analyste valide une décision et le SOAR exécute la chaîne.

L'automatisation se dose. Les actions réversibles et à faible risque (enrichir une alerte, ouvrir un ticket) peuvent être entièrement automatiques. Les actions à fort impact (couper un accès en production) gardent souvent un humain dans la boucle, qui valide avant exécution. Aux Arcades, fermer un rideau de fer se fait tout seul, mais évacuer tout le centre reste une décision humaine.

Le flux complet, de bout en bout

Le schéma ci-dessous relie les trois briques : les sources émettent des logs, le SIEM les corrèle et lève une alerte, le SOC trie, et le SOAR exécute le playbook adapté.

Le tableau suivant résume ce qui distingue le SIEM du SOAR, deux outils complémentaires souvent confondus.

Scénario B : Target, détecter sans répondre

L'histoire la plus parlante sur la différence entre détecter et répondre est la compromission de l'enseigne américaine Target fin 2013. Pendant la période des fêtes, des attaquants ont exfiltré les données d'environ quarante millions de cartes de paiement après s'être introduits dans le réseau de l'entreprise.

Le détail marquant n'est pas que les outils aient échoué, c'est qu'ils ont fonctionné. D'après l'enquête du Sénat américain sur la violation de données de Target, les solutions de détection déployées par l'entreprise ont bien généré des alertes au moment où le logiciel malveillant a été installé sur les systèmes de paiement. Le journaliste spécialisé Brian Krebs, qui a révélé l'affaire, a documenté de près la chronologie de l'intrusion sur Krebs on Security.

Le problème s'est situé après la détection. Les alertes ont été émises, mais elles n'ont pas été traitées à temps par l'équipe de sécurité. L'outil a vu, personne n'a agi assez vite, et l'exfiltration s'est poursuivie.

Target avait l'équivalent d'un SIEM qui a parfaitement repéré l'intrusion. Ce qui a manqué, c'est le maillon humain et organisationnel du SOC : transformer l'alerte en réponse. Un MTTD court ne sert à rien si le MTTR explose.

Transposé aux Arcades, le scénario est limpide. Les caméras filment le braquage en direct, l'alerte s'affiche sur le mur d'écrans du PC sécurité, mais l'agent regarde ailleurs ou l'alerte se noie dans des dizaines d'autres. Le voleur repart pendant que l'enregistrement, lui, tourne sagement. La leçon est nette : un SIEM qui voit n'est utile que si un SOC agit, et qu'un SOAR ou une procédure transforme vite l'alerte en geste concret.

Points clés

• SOC, SIEM et SOAR ne sont pas synonymes. Le SOC est l'équipe et le processus (les humains), le SIEM est l'outil qui collecte et corrèle les logs, le SOAR est l'outil qui automatise la réponse.
• Le SIEM transforme du bruit en signal par la collecte, la normalisation et la corrélation, mais ses faux positifs doivent être maîtrisés sous peine de fatigue d'alerte.
• Le SOAR exécute des playbooks pour les gestes répétitifs et fait dialoguer les outils, en gardant un humain dans la boucle pour les actions à fort impact.
• Détecter et répondre sont deux étapes distinctes, mesurées par le MTTD et le MTTR. Le cas Target 2013 montre qu'une détection sans réponse rapide ne protège pas.
• Tout converge vers la rapidité de réaction : raccourcir le délai entre l'alerte et l'action est l'objectif central de toute la chaîne SOC/SIEM/SOAR.

Dans la série

Palier 3 : Tenir la galerie. Domaine : Détection & réponse.

• Précédent : IAM et PAM, les accès à privilèges
• Suivant : CTI, IOC et réponse à incident
• Vue d'ensemble : Par où commencer dans Les Arcades

Pour aller plus loin

• NIST SP 800-61, Computer Security Incident Handling Guide : le cadre de référence sur le traitement des incidents, en aval de la détection.
• MITRE ATT&CK : la base de connaissances des techniques d'attaquants, utilisée pour écrire et prioriser les règles de détection d'un SIEM.
• Enquête du Sénat américain sur la violation de données de Target et Krebs on Security sur l'affaire Target : les sources documentées de l'incident de 2013.
• Le billet précédent de la série, IAM et PAM : gérer identités et accès à privilèges, sur la maîtrise des comptes et des accès sensibles.
• Cyber Kill Chain et MITRE ATT&CK : anatomie d'une attaque pour comprendre ce que le SOC cherche à repérer étape par étape.
• Pour situer la supervision dans une démarche outillée plus large, voir Qu'est-ce que le DevSecOps ?.