SOC : ce qu'il ne faut pas faire...

Oublier l’approche par les risques

Si le SOC s’inscrit dans une démarche de sécurité opérationnelle, son efficacité reste limitée sans la définition préalable d’une véritable stratégie de surveillance. Définir les scénarios de risque les plus redoutés, identifier les sources de données permettant de les détecter et implémenter les rapports et alertes permettant de le faire sont des étapes incontournables de la construction d’un SOC. 

Les négliger en se contentant de schémas génériques limite fortement le retour sur investissement d’une structure dont les ressources sont par essence finies (collecte et stockage de logs pas ou peu utiles augmentant le coût du SIEM, mobilisation des analystes sur des tâches d’analyse non essentielles, etc.). 

Il est qui plus est très inconfortable pour le SOC et ses responsables de devoir expliquer à posteriori à leurs sponsors qu’ils n’avaient pas mis en place les dispositifs qui auraient permis de détecter un incident de sécurité critique.

Ne pas vivre avec son temps

Comme son « O » l’indique, le SOC est une structure de production. Elle appelle donc à l’industrialisation de certains de ces processus internes. La nécessité de clairement documenter son fonctionnement et d’automatiser certaines tâches simples ne doit toutefois pas pousser vers l’approche presque caricaturale de certains SOC adossés à un catalogue d’alertes convenues au démarrage du service et n’évoluant pas ou peu au fil des mois, voire des années.

Cette approche a, il est vrai, le mérite de la simplicité et de la lisibilité en termes de suivi du service et de son coût. Elle fait malheureusement peu de cas du « S » de SOC et de la constante dynamique de l’environnement et des menaces auxquelles doivent faire face les entreprises.

La politique de surveillance doit au contraire être en constante évolution afin d’intégrer de nouveaux scénarios de risque, de nouvelles menaces, mais également les retours d’expérience du SOC lui-même (échec à détecter en amont une attaque survenue, capitalisation sur les indicateurs de compromission issus d’une investigation numérique, etc.).

N’analyser que des logs

Les journaux techniques restent aujourd’hui la source d’information principale du SOC, tout comme la solution de gestion des informations et des événements de sécurité (SIEM) permettant de les collecter, stocker et analyser, reste au centre de son outillage.

Ils ne permettent cependant pas de tout voir. Ils n’offrent par exemple qu’une vue réduite et souvent indirecte sur le poste de travail qui est pourtant le point d’entrée privilégié des cyber-attaques : journaux rarement collectés pour des raisons pratiques (requiert le déploiement et l’exploitation d’agents sur plusieurs milliers ou dizaines de milliers de postes), importance d’indicateurs de compromission non journalisés (clés de registre, fichiers, etc.).

Le SIEM va naturellement concentrer la détection sur les composants d’infrastructures en périphérie des postes de travail et donc sur des signaux de compromission plus faible.  Une surveillance plus complète suppose donc de disposer d’autres sources et outils, et notamment de capacités d’analyse du trafic réseau (sondes, sandboxing), d’acquisition de données de bas niveau et d’intervention sur les postes de travail.

Cet outillage complémentaire représente un coût qui peut s’avérer insurmontable, notamment pour les structures les plus réduites. La priorité sera alors de tirer le meilleur parti de son SIEM – en retenant donc une approche par les risques… –  et d’assumer clairement le risque à ne pas pouvoir surveiller de manière optimale certains scénarios.

N’exploiter que des alertes en temps réel

L’alerte en temps réel, si possible déclenchée par la corrélation de plusieurs événements de sécurité, est une finalité logiquement poursuivie par tout responsable de SOC – pour réduire de l’écart entre la survenance d’une attaque et sa détection – et savamment entretenue par les éditeurs de solutions à coup d’analyse comportementale, d’intelligence artificielle et autre machine learning.

Cette tendance ne doit pas occulter la difficulté à définir des règles de corrélation et de production d’alertes efficaces contre les attaques un minimum ciblées autrement qu’en s’appuyant sur l’analyse d’incidents déjà survenus.  En pratique, se concentrer uniquement sur les alertes en temps réel revient bien souvent à se concentrer sur des événements de moindre intérêt ou tout du moins à délaisser la chasse aux cyber-attaques pour une approche de contrôle permanent – contrôle binaire de bonne application de certaines règles de la politique de sécurité des systèmes d’information (PSSI), notamment celles portant sur l’administration et le contrôle d’accès logique. Pire, cela peut aboutir à simplement expliciter l’efficacité de solutions de sécurité dont les journaux sont collectés : comme, par exemple, une alerte sur la détection d’un malware par l’antivirus ou le blocage d’un phishing par une passerelle de messagerie.

L’analyse des alertes en temps réel doit donc être complétée par une analyse plus ouverte des logs s’appuyant sur des rapports générés par le SIEM ou d’autres consoles, et revus par les analystes pour détecter « à l’œil » d’éventuels comportements anormaux.

Tous ces défauts sont malheureusement encore courants, même s’ils ne sont pas toujours aussi marqués. Ils minorent de fait la valeur ajoutée des SOC qui en souffrent et les réduit, dans le pire des cas, à la production régulière de compteurs d’événements de sécurité de faible impact.

A contrario, les structures suivant une politique de surveillance alignée sur les principaux risques de l’entreprise et régulièrement mise à jour pour prendre en compte les résultats des processus de veille, en s’appuyant sur des sources d’informations et un outillage plus variés que le couple « logs/SIEM », et en donnant une part importante à l’analyse et l’expertise humaine, sont aujourd’hui les plus aptes à détecter et répondre aux cyber-attaques.