À quelles difficultés font face ces équipes au quotidien ? Comment rester efficace alors que les attaques des cybercriminels deviennent extrêmement élaborées ?

Le SIEM : un pilier du SOC… à condition d’être bien implémenté !

L’apparition d’outils comme le SIEM (Security Information and Event Management), il y a environ 10 ans, a permis aux équipes de sécurité opérationnelle d’industrialiser la surveillance en simplifiant l’analyse de multiples sources d’événements de sécurité (console antivirus, proxy, Web Application Firewall…). Cet outil a également rendu possible la corrélation de nombreux événements provenant d’équipements ou d’applications hétérogènes pour détecter des scenarii de menace avancés.

Cependant, la mise en place d’un SIEM doit être le résultat d’un projet ayant un investissement proportionnel à la complexité du système d’information surveillé. En effet, la pertinence d’un SIEM repose à la fois sur :

• La présence de contrôles contextualisés au système d’information (notamment au travers de l’exploitation de la sensibilité des assets surveillés).
• L’étude et l’implémentation de scénarii de menaces avancés et adaptés aux enjeux du métier de l’entreprise.

Concernant le périmètre de surveillance, les premiers équipements habituellement intégrés sont les équipements de sécurité car ils sont nativement configurés pour laisser des traces exploitables pour les équipes opérationnelles. Il est néanmoins souvent constaté que leur intégration se limite à une simple retranscription des contrôles déjà existants ; ce qui ne permet pas de tirer parti de la corrélation d’évènements proposé par un SIEM.

En revanche, l’intégration d’applications métiers est plus délicate en raison notamment des besoins différents entre les équipes métiers et sécurité : la principale préoccupation pour le métier se résume généralement à l’indisponibilité de son application (ou de certaines de ses fonctionnalités), alors que la sécurité adresse un éventail de risques plus complet, que ce soit de l’indisponibilité, de la compromission de l’intégrité de données ou encore de la fuite d’informations confidentielles.

Il s’avère donc primordial de sensibiliser les métiers aux enjeux sécurité dans leur ensemble pour pouvoir déterminer des scenarii de menace réalistes et propres à chaque périmètre. De plus, ces applications n’ont traditionnellement pas de fonctionnalités avancées en termes de sécurité. Par conséquent, il est difficile de disposer d’un système de surveillance efficace (configuration d’envoi de logs complexe, fichiers de logs très peu verbeux…).

De manière générale, l’implémentation trop simpliste de contrôles dans un SIEM rend l’activité du SOC inefficace. Les équipes de surveillance se voient alors noyées de « faux positifs » et les évènements de sécurité sont traités unitairement au lieu d’être analysés dans leur ensemble afin de détecter de réels scenarii de menace (par exemple : une authentification non autorisée sur un serveur puis la désactivation de son antivirus devra être traité comme un seul incident à investiguer).

Des équipes pas assez intégrées dans l’organisation de la sécurité

Outre les problématiques liées à une mauvaise implémentation du SIEM évoquées ci-dessus, on constate également des problématiques d’ordre organisationnel.

En effet, le SIEM est souvent perçu comme une « boîte noire » par les analystes de niveau 1 et 2 au sein des équipes du SOC. Cela est généralement dû à la méconnaissance des problématiques réelles de production (identification des assets critiques, des interactions entre les différents systèmes…). Les incidents détectés par le SIEM se retrouvent alors tous traités au même niveau sans aucune priorisation et identification en amont des éléments les plus sensibles.

Pour maintenir un niveau de compétence suffisant au sein des équipes de sécurité opérationnelle, de la veille technologique doit être réalisée par les investigateurs niveau 3 pour ensuite être communiquée aux analystes niveau 1 et 2. Des sujets tels que la présentation de nouveaux IOC (Indicator Of Compromise) venant compléter des règles de détection permettront aux équipes de gagner en efficacité dans leur manière d’appréhender les incidents. Ces types d’initiatives contribueront à l’amélioration continue du service en évitant sa dégradation dans le temps.

De plus, les équipes doivent participer en continu aux nombreuses initiatives sécurités initiées par la DSI tels que des projets de sécurisation des infrastructures ou applications. Par ailleurs, des exercices de gestion de crises doivent être organisés afin d’éprouver les différents processus et outils mis en place et de permettre aux interlocuteurs métiers et sécurité de pouvoir échanger sur leurs rôles respectifs en cas de crise.

Dans un contexte où la cybercriminalité ne cesse de se réinventer (comme le démontre l’attaque sur les systèmes Swift récente), les équipes opérationnelles sont de plus en plus sollicitées pour intégrer de nouveaux périmètres. Cette pression constante exercée notamment par les décideurs accentue les phénomènes de mauvaise implémentation des contrôles et de méconnaissance des scénarii de menace réels. Une bonne surveillance nécessite plus qu’un simple envoi de logs dans un SIEM ; les équipes projet doivent s’efforcer de respecter et faire respecter le processus complet d’intégration de nouveaux périmètres : identification des scénarii d’attaques, mise en place des mécanismes de collecte, création des règles de détection, tests et mise en production. L’oubli d’une de ces étapes risque de rendre la collecte des logs du périmètre inutile.

Quel avenir pour les SOC ?

De nombreux facteurs vont venir bouleverser l’écosystème des prestataires de la sécurité opérationnelle.

En effet, la LPM (Loi de Programmation Militaire) va exiger de tous les OIV (Opérateur d’Importance Vitale) de choisir des prestataires certifiés PDIS (Prestataires de Détection des Incidents de Sécurité), pour ceux qui font appel à de telles prestations externes. De nombreux prérequis seront nécessaires afin de pouvoir être certifié, tels que le cloisonnement des données des clients ou la mise en place de zones d’administrations (enclaves), uniquement accessible par le prestataire, par lesquelles les logs seront récupérés pour ensuite être transmis au SIEM. Ces facteurs vont entraîner de nombreux changements au sein des organisations et infrastructures mises en place actuellement.

Par ailleurs, la part grandissante du cloud dans les systèmes d’information des entreprises amène une nouvelle complexité : celle de la collecte des logs auprès des fournisseurs. De nouveaux acteurs sont donc apparus dans le marché de la sécurité : les CASB (Cloud Access Security Brokers). Leur promesse : répondre aux problématiques de sécurité pour le cloud. Ces entités se situent entre les utilisateurs et les divers services cloud et proposent de nouvelles briques de sécurité telles que l’utilisation d’API pour détecter directement des scenarii de menaces (création de fichiers de journalisation des accès aux applications, implémentation de ces données dans un SIEM…).

L’objectif de demain : gagner en maturité

La sécurité opérationnelle a encore de nombreux défis à relever. La plupart des entités assurent actuellement l’hygiène minimum du système d’information et la maturité des équipes leur permet de se prémunir des menaces diffuses (virus, spam…). Cependant, le dispositif actuel doit se renouveler afin de répondre aux nouveaux enjeux liés à la cybersécurité pour pouvoir lutter contre les menaces opportunistes (hacker isolé) et ciblées (cyber-mafia, gouvernement), plus complexes à détecter.

Dans ce contexte et face aux obligations légales, les SOC ont (et auront) un rôle très important à jouer nécessitant une expertise technique approfondie ainsi qu’une intégration avec la sécurité dans les projets.

Cet article Cybersécurité : l’heure du bilan pour les SOC est apparu en premier sur RiskInsight.