Au sein des SOC européens, une révolution silencieuse est en cours. Face à des volumes d’événements toujours plus importants et une pénurie persistante d’experts, une nouvelle génération d’outils de sécurité, dopés à l’intelligence artificielle, émerge pour identifier des corrélations que les équipes humaines ne peuvent plus traiter seules. L’IA ne remplace pas les analystes, mais elle accélère et optimise leur travail. Entre les ambitions d’hyper-automatisation, les enjeux de transparence des modèles et la volonté croissante d’une souveraineté européenne, le paysage des solutions de détection et réponse à incident évolue à vitesse grand V. 

Pour accompagner au mieux la transformation du marché, l’Agence nationale de la sécurité des systèmes d’information (ANSSI) et le Centre de coordination cyber français (NCC-FR) hébergé par l’ANSSI ont lancé une initiative ambitieuse visant à capturer l’état de l’art du secteur, en menant une étude [1] structurée auprès des principaux acteurs européens spécialisés dans les solutions à destination des SOC

Les objectifs de l’étude étaient doubles : 

1. Recenser les acteurs européens développant des solutions destinées aux SOC intégrant des fonctionnalités basées sur l’IA [2].
2. Construire un panorama le plus exhaustif possible des cas d’usage proposés sur le marché, y compris par les principaux acteurs US présents en Europe. 

Cet article synthétise les enseignements clés tirés de notre étude menée auprès de 48 éditeurs de solutions de détection et de réponse.  

Répartition géographique des éditeurs rencontrés 

Un marché européen bouillonnant en cours de consolidation  

L’étude a porté sur 48 éditeurs. Parmi eux, 34 sont des éditeurs européens (sur un total de 72 acteurs européens initialement identifiés), tandis que les 14 restants sont des éditeurs US, solidement implantés en Europe.  

Le marché montre une consolidation tangible, marquée par de nombreux rachats, le plus souvent d’acteurs européens par des sociétés US. Ces acquisitions visent principalement à renforcer les capacités de détection et de réponse des solutions, à étendre la couverture de protection proposée ou, plus marginalement, à intégrer directement des briques d’IA dédiées à la détection. Les éditeurs convergent ainsi vers une logique de plateforme unifiée capable de répondre à l’ensemble des besoins d’un SOC. 

Certaines initiatives européennes, telles que l’alliance OPEN XDR, visent à proposer une réponse collective aux enjeux de plateformes, sans recourir à des stratégies de rachat entre acteurs. 

Les rencontres avec les éditeurs ont permis de dégager plusieurs constats majeurs. 

Tout d’abord, la GenAI, pour Generative AI (IA capable de générer du contenu original à partir d’instruction), fait son apparition dans les solutions SOC, principalement via des chatbots intégrés aux interfaces d’analyse; leurs fonctionnalités restent toutefois très limitées et hétérogènes. Ces chatbots reposent presque systématiquement sur des technologies externes, en particulier sur des LLMs fournis par un nombre restreint d’acteurs majeurs tels que OpenAI, Google, Meta, Anthropic ou encore Mistral AI, qui concentrent l’essentiel du marché. Cette dépendance à des solutions tierces, impliquant souvent un transfert de données vers les environnements de ces fournisseurs, soulève des questions importantes quant à la protection des données sensibles manipulées au sein des SOC.

Pour réduire cette dépendance, plusieurs éditeurs envisagent désormais d’adopter des LLM open source, déployables directement dans leurs propres environnements, afin de mieux maîtriser leurs données et garder leurs flux en interne. 

Panorama des LLM utilisés par les éditeurs EU rencontrés 

Ensuite, l’usage de la PredAI, pour Predictive AI (IA capable de prédire ou classifier un input grâce à des « connaissances » acquises lors d’une phase d’apprentissage), se révèle nettement plus avancé : certains éditeurs européens s’appuient sur ces approches depuis plus de 15 ans pour traiter des cas d’usage allant de la détection comportementale à la priorisation d’alertes, démontrant une réelle maturité et une expertise éprouvée. La grande majorité de ces usages reste toutefois concentrée sur la phase de détection, où les modèles prédictifs sont aujourd’hui les plus largement exploités, les mieux maîtrisés et les plus pertinents. 

Par ailleurs, plusieurs acteurs commencent à explorer les approches agentiques, avec l’ambition de déléguer progressivement une partie des tâches répétitives ou chronophages, notamment la qualification initiale des alertes et certaines étapes d’investigation.  

Enfin, ces observations doivent être abordées avec prudence : l’échantillon d’éditeurs rencontrés ne reflète qu’une partie du dynamisme technologique actuellement à l’œuvre sur le marché. 

Cartographie des acteurs européens proposant des solutions de détection et de réponse aux incidents intégrant l’IA 

Panorama des cas d’usage de l’IA dans les outils de détection et réponse à incident  

Panorama des cas d’usage de l’IA sur la chaine d’opérations d’un SOC 

L’étude a permis de recenser une cinquantaine de cas d’usage. Au sein des outils de détection et réponse à incident, une distinction claire apparaît entre deux grandes familles de cas d’usage : 

• les cas d’usage fondés sur des modèles de Predictive AI, principalement destinés à la détection d’incidents ; 
• et ceux basés sur la Generative AI, plutôt orientés vers les tâches d’investigation et de réponse à incident. 

Même si les cas d’usage sont nombreux et difficiles à lister de manière exhaustive, on peut néanmoins identifier plusieurs grands ensembles conçus pour répondre à des problématiques similaires et poursuivant le même objectif.  

Pour la détection d’incidents, l’IA est notamment utilisée pour :

• la détection de comportements anormaux d’utilisateurs ou d’assets ; 
• la détection d’anomalies dans le trafic réseau ; 
• la détection d’événements révélateurs d’une attaque ; 
• la détection de tentatives de phishing ; 
• et la détection de fichiers malveillants. 

Si ces ensembles répondent à un même objectif, un autre agrégat de cas d’usage emerge : celui où l’ensemble des usages est adressé par l’IA générative, notamment au travers de chatbot-assistants. Les éditeurs concentrent aujourd’hui une grande partie de leurs efforts sur ces assistants destinés aux analystes, dans lesquels ils intègrent progressivement plusieurs cas d’usage. Leur priorité consiste d’abord à faciliter l’accès à la documentation et à fournir des réponses aux questions opérationnelles, avant d’étendre ces capacités vers des tâches plus avancées de qualification ou d’investigation. 

Pour cela, presque tous adoptent la même approche : 

• l’exploitation d’un modèle tiers de fondation, 
• du prompt engineering pour exploiter au mieux les capacités du modèle en l’orientant vers des sujets précis 
• et l’usage du RAG (Retrieval Augmented Generation), qui personnalise et enrichit les recherches du modèle en lui fournissant une base documentaire prioritaire pour construire ses réponses. 

Enfin, même s’ils restent encore limités, des cas d’usage dits agentic, reposant sur des agents autonomes, commencent à émerger. Ils sont aujourd’hui proposés principalement par les acteurs les plus avancés et les plus matures du secteur, ou par des start-ups cherchant à bousculer le marché. 

Contrairement à la majorité des éditeurs qui intègrent progressivement des cas d’usage IA au sein d’une plateforme cyber existante, ces nouveaux entrants misent sur des solutions d’IA spécialisées, conçues pour répondre à une tâche cyber bien précise. Parmi ces cas d’usage, on trouve par exemple des agents dédiés au threat hunting, à l’analyse malware avancée (type reverse engineering automatisé), ou encore à la qualification initiale des alertes. 

Ces usages restent cependant peu déployés à ce jour.  

Pour aller plus loin…. 

L’ANSSI propose un rapport complet, reprenant tous les résultats de l’étude :  https://cyber.gouv.fr/enjeux-technologiques/intelligence-artificielle/etude-de-marche-lia-au-service-de-la-detection-et-de-la-reponse-a-incident/  

Ce document constitue désormais une référence pour comprendre les tendances, les évolutions futures du rôle de l’IA dans la détection et réponse à incident.  

En définitive, l’étude met en lumière un marché européen de la cybersécurité en pleine structuration, porté par l’essor de l’IA mais également marqué par une dynamique forte de consolidation. Dans ce paysage en mouvement, l’IA poursuit sa montée en maturité au sein des outils pour le SOC : des cas d’usage de détection fondés sur la PredAI, aux assistants analytiques basés sur la GenAI, jusqu’aux approches agentic encore émergentes mais prometteuses. Cette trajectoire confirme que l’automatisation intelligente deviendra un levier majeur pour gagner en efficacité opérationnelle et renforcer la capacité des organisations à se protéger des attaques de demain. 

Références 

[1] Étude réalisée d’octobre 2024 à juillet 2025 – https://cyber.gouv.fr/enjeux-technologiques/intelligence-artificielle/etude-de-marche-lia-au-service-de-la-detection-et-de-la-reponse-a-incident/  

[2] Fonctionnalités basées sur l’Intelligence artificielle :  Ensemble de fonctionnalités utilisant des modèles d’apprentissage automatique (ML, deep learning, LLM) capables d’apprendre à partir de données et de produire des analyses, prédictions ou contenus nouveaux. 

Cet article Intégration de l’IA dans les outils du SOC : Etat de l’art technologique et tendances actuelles sur le marché européen  est apparu en premier sur RiskInsight.

S’il y a 10 ans, construire son SOC revenait à se demander quels scénarios superviser, quelles sources de logs collecter et quel SIEM choisir, les évolutions récentes du SI proposent de nouveaux défis : comment mettre en place la supervision dans un environnement partiellement on-premise et/ou multicloud ? En effet, en 2021, avoir un SI hébergé chez plusieurs fournisseurs IaaS est plus proche de la règle que de l’exception ; et si AWS reste l’acteur le plus rencontré, les offres d’Azure et de GCP intéressent de plus en plus d’équipes IT.

Comment construire sa stratégie de détection ? Où positionner le ou les SIEM ? Comment centraliser les logs, les alertes ? D’ailleurs, faut-il des logs ou des alertes ? Et comment tirer parti des solutions managées proposées par les fournisseurs cloud ?

Dans cet article, nous discuterons de bonnes pratiques : utilisation d’une stratégie de détection bottom-up, optimisation via le choix des services natifs cloud les plus pertinents, simplification de l’architecture de collecte ; toujours basées sur des retours d’expérience de construction de stratégies de supervision multicloud.

(Re)penser sa stratégie de détection pour le multicloud

La première question que devrait se poser l’équipe en charge du SOC est celle de la stratégie de détection. Autrement dit, quels scénarios va-t-on superviser ?

Un bon réflexe cyber consiste à utiliser une approche dite « top-down » : partir d’une analyse de risques pour identifier les alertes à prioriser, les formaliser puis les traduire techniquement dans le SIEM. En pratique, trois facteurs démontrent que cette approche est insuffisante :

• Peu d’équipes disposent d’analyses de risques qui soient suffisamment exhaustives, à jour et pragmatiques pour permettre une déclinaison des scénarios de menaces en scénarios supervisables, en particulier pour des périmètres complexes comme le cloud public,
• Rien ne garantit que les scénarios obtenus par cette méthode puissent concrètement être mis sous supervision, que les limites soient liées aux solutions déployées ou à la nécessité pour les équipes SOC de disposer de connaissances métier.
• Cette approche définit quelques chemins d’attaques selon la criticité des actifs, mais ne couvre pas tous les chemins d’attaques qu’un attaquant pourrait emprunter.

De ce fait, une stratégie de détection multicloud efficace sera obtenue en complétant l’approche par les risques par une approche « bottom-up » : en partant des capacités de journalisation des solutions dont on dispose pour identifier les alertes que le SIEM devra remonter, pour enfin prioriser en se basant sur leur intérêt en termes de couverture des risques. Partir de l’existant garantit le pragmatisme et l’efficacité de la démarche.

Chez Wavestone, nous sommes de plus en plus sollicités par des clients souhaitant être accompagnés sur cette nouvelle approche. Le périmètre concerne les principales solutions utilisées en multicloud : Microsoft 365 (SaaS) et les solutions managées des offres IaaS des 3 principaux acteurs du marché : Amazon Web Services, Microsoft Azure et Google Cloud Platform.

Mettre en place la supervision de l’infrastructure Microsoft 365

Sur le papier, l’équipe SOC a toutes les clés en main pour monitorer son infrastructure cloud :

• Des logs bruts pour les services d’Office 365 (Teams, SharePoint Online, Exchange Online, etc.)
• Des logs bruts, rapports de sécurité, alertes et Identity Secure Score pour Azure AD
• Des logs bruts, alertes, Microsoft Secure Score et recommandations Azure pour les outils de sécurité comme ATP, AAD Identity Protection, Intune, AIP, etc.

En pratique, naviguer entre les logs et tous les outils mis à disposition (et leurs consoles) peut vite devenir un casse-tête. Et si nous entendons régulièrement qu’il y a trop de logs ou d’interfaces d’administration à maîtriser, sur le terrain les difficultés sont accentuées :

• Par les faibles capacités de personnalisation des outils natifs proposés,
• Par le manque de scénarios disponibles avec la licence achetée,
• Par la durée de rétention de 90 jours des logs,
• Par le manque général de compétences Office 365 ou AzureAD dans les équipes SOC.

Pour éviter de se perdre, nous conseillons de simplifier le terrain de jeu autant que possible. Les bonnes pratiques consistent à penser alertes, et pas collecte de logs, puis à centraliser leur gestion dans le SIEM en utilisant des connecteurs comme ceux de Security Graph API. A titre d’exemple, il est possible d’arriver à un modèle comme celui donné ci-dessous :

Une fois l’architecture identifiée, configurer une durée de rétention de logs adaptée aux besoins (au sein d’Azure ou à l’extérieur) et entreprendre l’adaptation des processus SOC aux spécificités de M365 selon les choix réalisés lors de l’étape précédente.

Mettre en place la supervision des autres cloud en IaaS

Afin de dessiner l’architecture de collecte sur ces clouds, il convient de distinguer les différents types de logs mis à disposition par les CSP.

Logs système

Le cas des logs système générés par les VM et les flux réseau peut être traité en premier ; il est possible de les collecter de la même manière qu’on-premise, avec des agents syslog, par exemple. Les infrastructures des CSP mettent à disposition des briques comme Log Analytics chez Azure pour faciliter la remontée.

Logs d’administration de l’infrastructure

On peut aussi envisager la supervision des opérations d’administration des composants « sensibles » de l’infrastructure (VPN, FW, scanner de vulnérabilités, etc.) comme on le ferait on-premise. En effet, la plupart de ces solutions disposent de leur pendant IaaS chez les fournisseurs cloud : elles s’obtiennent via la Marketplace et disposent de console d’administration web ou s’interfacent directement à la console de management du CSP (c’est par exemple le cas de l’appliance du scanner Qualys).

Logs des appels d’API

Enfin, les appels d’API réalisés par les processus/comptes sur l’infrastructure cloud et par les opérations d’administration génèrent des logs qui sont facilement récupérables via les services managés suivants :

• CloudTrail chez AWS
• Activity Log & Monitor chez Azure
• Audit Logging chez GCP

Pour éviter de se perdre, retenons la leçon suivante : « Utilisons et abusons des services natifs du cloud ». En effet, qui de mieux placé que le fournisseur pour proposer des services adaptés et intégrés au mieux à l’environnement ? En pratique, nous constatons qu’implémenter la gestion des logs et des alertes cloud dans un SIEM on-premise coûte cher (même en cherchant à limiter les coûts de stockage dans la solution de supervision) et est chronophage.

L’utilisation du cloud implique de passer à la philosophie du cloud : adoptons ses codes et domptons ses services et outils. L’occasion de renforcer les synergies entre les équipes cloud et le SOC !

En synthèse, un exemple d’architecture de monitoring sur AWS est proposé ci-dessous. Il présente plusieurs façons de réaliser la supervision, en s’appuyant sur des services natifs pour les logs et pour les alertes (NB : tous les flux vers S3 et d’autres services n’ont pas été représentés pour des raisons de lisibilité).

Définir l’architecture de centralisation des alertes multicloud

C’est l’une des questions qui nous est la plus posée : quelle architecture SIEM faut-il envisager en multicloud ? Si chaque contexte est différent, parce que chaque infrastructure IT dispose de legacy et d’un historique qui lui est propre, la présence d’autant de ressources et d’outils doit amener une équipe SOC à considérer l’adoption d’un SIEM dans le cloud central (comme Azure Sentinel, Splunk SaaS, etc. ; AWS et Chronicle de Google ne proposant pas à date de solution équivalente).

Pour aider les équipes SOC à choisir le scénario adapté, nos recommandations sont les suivantes :

• Privilégier le scénario à un seul SIEM central
• Limiter autant que possible le nombre de consoles de supervision cloud
• Remonter au maximum des alertes déjà préanalysées par les services natifs mis à disposition étudiés précédemment
• Tirer profit des synergies éventuelles entre produits du même fournisseur : Azure Sentinel pour monitorer l’infrastructure Microsoft 365 par exemple
• Tirer profit des nombreux connecteurs mis à disposition par les fournisseurs de SIEM cloud
• Etudier les impacts de chaque scénario sur l’organisation du SOC (taille des équipes, compétences technologiques, etc.) et les coûts associés (développements nécessaires, volumétrie et coûts d’ingestion, etc.)

Un exemple d’architecture reprenant l’ensemble des recommandations de cet article est proposé ci-dessous, il utilise Azure Sentinel comme SIEM cloud central.

Synthèse : les principes clés à adopter pour garder la tête au-dessus des nuages

En résumé, l’équipe SOC souhaitant adapter sa stratégie de détection au multicloud devrait :

• Compléter son approche classique top-down par l’approche bottom-up, particulièrement adaptée au contexte complexe du multicloud,
• Utiliser dès que c’est possible les services natifs mis à disposition par les fournisseurs afin de tirer pleinement parti des avantages du cloud,
• Simplifier l’architecture de collecte et centraliser au maximum des alertes préanalysées par les services natifs cloud,

Une fois la tête sortie du nuage, la stratégie formalisée et l’architecture de collecte déployée, le SOC retrouve bien sa place de tour de contrôle du SI : la prolifération des services dans le cloud ne lui fait plus peur !

Les prochaines étapes peuvent consister à étudier les possibilités d’automatisation, avec la mise en place d’un SOAR, par exemple. Nous ne manquerons pas de discuter du sujet dans un prochain article.

Cet article Adapter sa stratégie de détection au multicloud sans se perdre dans les nuages est apparu en premier sur RiskInsight.

En effet, toutes les entreprises n’ont pas les moyens nécessaires (ou la volonté) de développer en interne ce type de technologie et se tournent alors vers des solutions du marché en se confrontant à une problématique majeure : comment réussir à choisir et intégrer rapidement une solution efficace dans mon contexte ?

Pourquoi utiliser du Machine Learning en cybersécurité ?

Le caractère statique des solutions de détection actuelles (antivirus utilisant des bases de signatures, alertes seuils d’alerte dans un SIEM…) ne permet plus de faire face à des attaques de plus en plus nombreuses et variées. En outre, les équipes de sécurité sont surchargées par le volume de données à analyser.

Comme expliqué dans l’article « La saga de l’été sur les nouveaux outils du SOC » (Partie 2 & Partie 3), le Machine Learning permet de répondre à ces problématiques que rencontre le SOC en utilisant des méthodes d’analyse comportementale pour détecter des attaques avancées et prioriser les alertes à analyser.

Principe de détection d’anomalies dans un SOC

Si ces types de solutions apportent une réelle plus-value, elles ne permettent pas de totalement s’affranchir des moyens de détection actuels et sont plutôt utilisées pour compléter les outils en place.

Par ailleurs, leur niveau de complexité (déploiement, traitement des alertes) requiert en prérequis d’avoir déjà atteint un niveau de maturité suffisant en termes de détection et réaction (organisation, outillage, ressources, centralisation de la donnée) avant qu’il soit pertinent de se lancer dans un projet basé sur du Machine Learning. La phase de cadrage n’en sera que facilitée et le déploiement accéléré.

En avance de phase : définir le cahier des charges

Quel est le cas d’usage que je souhaite adresser ?

Lors de nos différentes interventions chez nos clients, nous avons accompagné l’intégration de nombreuses solutions et nous pouvons faire ressortir quatre grands types de cas d’usages sur lesquels les entreprises investissent :

• La lutte contre la fraude: outils de détection de déviation(s) dans le(s) comportement(s) d’un utilisateur
• La surveillance des emails: outils de prévention contre le phishing ou la fuite d’informations (DLP)
• La détection de menaces sur le réseau: sondes « Next-Gen »
• L’identification des menaces sur les endpoints: anti-virus « Next-Gen »

Le choix d’une solution (et donc d’un cas d’usage) ne devra pas être défini de manière unilatérale par la filière SSI mais devra être réfléchi avec les différents acteurs concernés (SSI, DSI, métiers…). Cet échange permettra de préciser la cible ainsi que de valider les prérequis techniques et organisationnels (accessibilité des logs, ressources à mobiliser, taille des équipes…) pour préparer au mieux son intégration et son exploitation.

Quel type de solution choisir ?

Selon les outils déjà en place et en fonction du besoin, plusieurs solutions sont envisageables :

• Choisir d’implémenter une solution clé en main permettant de traiter des cas d’usages très précis et non spécifiques à des problématiques métiers (EDR, biométrie comportementale…). Ce choix convient généralement à un besoin immédiat plutôt qu’à une stratégie à long terme.
• Activer un module de Machine Learning sur un outil déjà en place (SIEM, puits de logs…) dans le but de pouvoir étendre son périmètre de détection. Ce choix permet notamment de pouvoir tester rapidement des cas d’usages et de s’affranchir des phases d’intégration d’un nouvel équipement au sein du son SI.

Enfin, il est essentiel de se rappeler qu’il n’existe pas de solution miracle et que chaque type de solution répond à des besoins précis.

Devant l’éditeur : challenger les points essentiels

Tester la solution et réfléchir à son évolutivité

Une fois que tous ces prérequis sont définis, il est d’usage de réaliser avec l’éditeur un Proof of Concept (PoC). Cependant, dans le cas spécifique d’une solution de Machine Learning, le PoC permettra de répondre à plusieurs interrogations spécifiques :

• Mes données actuellement collectées permettent-elles d’avoir des résultats rapidement satisfaisants ? Les solutions de Machine Learning requièrent l’analyse d’un très grand nombre de données potentiellement enrichies par des référentiels permettant de croiser plusieurs sources. Il est donc nécessaire de s’assurer en avance de phase avec l’éditeur que les données actuellement collectées permettent déjà d’obtenir des premiers résultats.
• Combien de temps la phase d’apprentissage durera-t-elle dans mon contexte ? Certaines solutions de Machine Learning produisent des résultats qu’à partir de plusieurs mois voire années car les phases d’apprentissages peuvent-être extrêmement longues du fait du contexte particulier à chaque entreprise. La possibilité d’utiliser un historique de logs pour les tests permettrait de s’affranchir d’une période d’apprentissage conséquente.

Des questions spécifiques seront également à traiter afin d’anticiper le plus long terme :

• Sera-t-il possible d’enrichir les analyses avec d’autres types de données ? Les solutions de Machine Learning permettent de pouvoir effectuer des analyses sur de nombreux types de données pouvant avoir des formats hétérogènes, il est donc nécessaire de pouvoir s’assurer que les analyses pourront être enrichies avec de nouveaux types de données collectées.
• Sera-t-il possible de mettre en place de nouveaux algorithmes de détection ? La possibilité de pouvoir personnaliser ces solutions en y ajoutant de nouveaux types d’algorithmes (et potentiellement de manière indépendante) est non négligeable.
• Comment suis-je assuré que mon éditeur soit toujours à la pointe de la technologie ? Au vu de l’évolution exponentielle des techniques sur ce sujet, il est important de s’assurer que l’éditeur poursuive sa course à l’avancée technologique afin de proposer de nouveaux moyens de défense contre des attaques qui ne cessent de se complexifier.

Se préparer à protéger le cycle de vie de la donnée

Les méthodes de détection basées sur de l’analyse comportementale nécessitent la collecte et le traitement de données sensibles/personnelles. Ainsi, particulièrement dans le cas où la solution est hébergée chez l’éditeur, les problématiques liées à l’usage des données devront être adressées au plus tôt. D’une part les exigences contractuelles de sécurité devront bien sûr être renforcées, et d’autre part il pourra être utile de faire appel en amont à des solutions permettant un traitement plus sécurisé du cycle de vie de la donnée.

Par exemple, des startups comme SARUS travaillent sur le masquage des données personnelles, permettant aux data scientists d’effectuer du Machine Learning sans accéder aux données sources. Des startups comme HAZY travaillent elles sur la génération de données synthétiques gardant la valeur statistique des données utiles, mais perdant leur caractère sensible. Ce type de solution permet également d’agrandir artificiellement l’échantillon fourni, et d’obtenir une quantité quasiment illimitée de données, ce qui peut être très utile dans le cadre d’un PoC où les données actuellement disponibles sont en quantité limitées.

Une fois que la pertinence de la solution est validée, la partie ne fait que commencer !

Au travers de nos différentes expériences, nous avons pu nous forger une conviction : le marché est assez mature pour fournir des résultats intéressants, notamment sur les quatre cas d’usages mentionnés ci-dessus. La mise en place de tels outils saura être efficace si les solutions sont connectées à un écosystème riche et qu’elles répondent à un besoin spécifique. En effet, la mise en place d’une même solution peut être une franche réussite ou un échec dans deux contextes différents. Le résultat dépendra notamment de la clarté du besoin, du périmètre visé, de l’expertise présente (Cybersécurité et Data Science), et encore de la disponibilité de la donnée (qualité et quantité).

Si le choix d’une solution de Machine Learning n’est pas simple, le meilleur moyen de se faire rapidement une idée est de réaliser un PoC pouvant être rapide et peu engageant : nous avons pu constater chez certains de nos clients que des solutions remontaient déjà des résultats intéressants après uniquement deux semaines de PoC.

Tout en gardant en tête que le PoC n’est que le début de l’aventure. Il résultera sur le lancement d’un projet de plusieurs mois passionnant (analyse de nouveaux types d’alertes, découvertes de nouvelles techniques…), apportant une réelle plus-value sécurité (détection de nouveaux évènements…), impulsant un nouveau souffle au sein des équipes opérationnelles de sécurité (priorisation des efforts, possibilité d’optimisation des tâches rébarbatives…).

Cet article MACHINE LEARNING POUR SA CYBERSECURITE : COMMENT SE RETROUVER DANS LA JUNGLE DES PRODUITS est apparu en premier sur RiskInsight.

Il y a 15 ans, lors de nos premiers travaux sur la mise en place de SOC chez nos clients, la définition d’une feuille de route était simple : mise en place d’un outillage puis collecte et analyse des logs des équipements de sécurité et des actifs critiques/exposés.

Cependant, de nouveaux enjeux liés à la décentralisation du SI, à l’évolution d’une menace toujours plus évoluée et également à la crise que nous traversons (généralisation du télétravail, baisse des budgets de cybersécurité…) doivent nous faire prendre conscience que le SOC doit se réinventer !

Impliquer (vraiment) tout le monde !

En refaisant l’histoire par le début, le SOC est géré par une population SSI qui a donc mis en place des mécanismes de surveillance sur des équipements SSI avec des use-cases SSI. Le résultat est mitigé, cela fonctionne plus ou moins bien et les chiffres de notre benchmark CERT sont là pour en attester : 167 jours en moyenne pour détecter un incident !

Les premières stratégies de détection étaient bien évidemment définies, challengées et validées par la filière SSI. Elles avaient pour objectif d’étendre de plus en plus le périmètre de surveillance via la collecte de toujours plus de logs (pares-feux, WAF…) et la mise en place de nouveaux équipements de surveillance (SIEM, sondes…).

Ce premier constat s’est fatalement retrouvé dans la majorité de nos conclusions d’audits de SOC : les objectifs sont mal définis et non alignés avec les attentes des clients du SOC (RSSI, DSI, métiers), entrainant une perte de confiance et de crédibilité.

Des exemples frappants permettent d’expliquer ce sentiment : manque de SLAs, périmètre mal défini, reporting trop bruts, non contextualisés et contenant des informations erronées…

Si vous ne voulez pas redéfinir une nouvelle fois votre stratégie SOC de manière peut-être partiale, l’organisation d’un séminaire est le bon exercice pour établir un nouveau point de départ. Toutes les parties prenantes doivent être présentes (équipes sécurité, DSI, clients du SOC…) et le but est d’adresser les principales problématiques :

• Redéfinition des objectifs : concentrer la surveillance sur des périmètres beaucoup plus restreints et faisables tant techniquement qu’humainement
• Clarification de la gouvernance : redéfinir le positionnement et le rôle du SOC dans l’organisation
• Refonte du reporting : partager les incompréhensions et les irritants des clients afin de remonter le bon niveau d’information

Nous avons pu constater que cette étape, indispensable au renouveau du SOC, permet de fédérer tout un ecosystème autour d’une cible commune.

Privilégier la qualité à la quantité !

Paradoxalement, bien que la surface d’attaque du SI ait augmenté de manière significative, la priorité est bien de restreindre le périmètre de surveillance pour se concentrer sur ce qui a réellement de la valeur.

Premièrement, dès lors que le périmètre fonctionnel de surveillance a été redéfini et validé par tous, la mission du SOC est de traduire techniquement ces nouveaux objectifs en scénarios de détection dans les outils. Pas besoin de réinventer la roue car de nouveaux Framework tels que MITRE ATT&CK permettent maintenant de recenser et matérialiser de manière claire les différents types d’attaques (techniques utilisées, exemples/références et suggestions pour la détection). L’objectif n’est bien évidemment pas de pouvoir couvrir toutes les techniques utilisables (330 au total) mais de prioriser les efforts sur ce qui permettra d’atteindre les objectifs.

De plus, un constat RH a également été remonté dans la plupart de nos audits : les équipes manquent de motivation, recul et autonomie pour apporter de la plus-value dans les opérations.

Ce constat entraine un fort turn-over car certaines tâches sont jugées peu intéressantes. L’objectif est de concentrer l’effort humain sur ce qui apporte réellement de la valeur ajoutée. Nous avons accompagné de nombreux clients dans l’implémentation d’outils de type SOAR (Security Orchestration, Automation and Response) permettant d’automatiser les tâches répétitives des équipes en charge de l’analyse et de la réaction. Ces outils sont extrêmement efficaces pour automatiser le traitement des attaques courantes, très rébarbatives (ransomware, phishing…) qui représentent une grande part des alertes.

Une fois ces mesures en place, les équipes peuvent alors être mobilisées sur des activités ayant une plus forte valeur ajoutée telles que la mise en place des tâches d’automatisation, les activités de Threat Hunting…

Et maintenant… s’améliorer et se challenger en continu !

Dès lors que toutes les fondations sont mises en place pour donner un nouveau souffle à son SOC, comment fait-on pour rester à la page ?

La réponse à cette question aurait été complexe il y a encore 5 ans mais de nombreux standards reconnus permettent dorénavant de pouvoir évaluer la maturité de son SOC dans une logique d’amélioration continue. SOC CMM est le parfait exemple car ce référentiel permet de pouvoir s’auto-évaluer à partir d’un ensemble de questions précises adressant toutes les problématiques en termes d’outillages et d’organisation. Cette méthodologie nous a permis d’accompagner des clients sur de nombreuses comparaisons avant/après.

Les opérations de Red Team ou Purple Team sont également d’excellents moyens permettant de challenger les dispositifs mis en place par rapport aux objectifs définis. Ces exercices permettent de mettre en avant des exemples concrets de vulnérabilités ainsi que des recommandations précises pour y remédier. De plus, le Framework MITRE ATT&CK peut être utilisé pour consolider les tests effectués par type d’attaque, ainsi que leurs résultats.

Ces différentes initiatives ne permettent pas de traiter l’exhaustivité des problématiques que rencontrent le SOC actuellement mais permettent de souligner nos principaux constats : un SOC isolé, des outils mal configurés et des équipes démobilisées.

L’exercice de redéfinition d’une stratégie SOC est une formidable opportunité permettant de remobiliser tout un ecosystème sous une même bannière. Cette initiative permet de redonner du sens à la fois aux équipes opérationnelles mais également à toutes les parties prenantes de l’activité du SOC… Bref, il n’y a plus qu’à !

Cet article Le SOC est mort d’ennui, de fatigue, de mauvais positionnement ? Découvrez comment le réanimer ! est apparu en premier sur RiskInsight.

Penser un projet Smart City avec la cybersécurité

Il est fondamental d’intégrer les aspects cybersécurité dès le démarrage d’un projet Smart City. En effet, le réaliser plus tard dans le projet pourra s’avérer plus complexe et couteux, avec le risque de ne pas en traiter / pouvoir traiter tous les risques.

Ceci nécessite de repenser l’organisation du projet vis-à-vis de la donnée et de la gouvernance de la sécurité : les principes de sécurité doivent être définis à l’échelle globale du projet et pris en compte par chacun des sous projets composant la Smart City, en fonction de leurs contraintes. Cela est d’autant plus vrai que les Smart Cities impliquent un grand nombre d’acteurs aux cœurs de métier, aux moyens et à la maturité cybersécurité différents. Une vision globale et partagée est indispensable pour s’assurer que chaque élément traite la donnée avec le niveau de sécurité adéquat.

Il convient ensuite de définir les grands principes d’architecture et d’interopérabilité, selon les contraintes inhérentes à la Smart City, liées à l’Edge Computing et au déploiement d’objets en milieu hostile. La résilience du système doit être au cœur des exigences de sécurité, la chute ou la compromission d’un élément ne devant pas entrainer la chute de la totalité du système.

A cet effet, des standards communs doivent être adoptés, en s’appuyant sur des frameworks spécifiques comme ETSI ou OneM2M. Ces derniers augmentent les chances de maintenir des systèmes interopérables évolutifs. Plus généralement, le NIST ou la norme ISO 27002 sont des référentiels de cybersécurité éprouvés sur lesquels il serait intéressant de s’appuyer.

Le mode de développement doit être agile, en intégrant une vision sur le long terme pour anticiper les nouveaux cas d’usage, et en jalonnant court afin de délivrer rapidement les premiers services. La cybersécurité doit être incluse dans les processus de développement, par la définition d’Evil User Stories, permettant d’identifier et de prendre en compte les risques à chaque évolution des services ou du SI, et par la nomination d’experts cybersécurité dans un rôle de support et de validation.

La définition et le maintien d’un niveau de sécurité satisfaisant passera plus que jamais par l’intégration rigoureuse de la sécurité dans toutes les phases du projet, cela pouvant induire des investissements humain et technologique plus importants mais nécessaires.

Protéger les données critiques et régulées

Etant donnée la propension de la Smart City à collecter et traiter de grandes quantités de données, leur protection passera en premier lieu par l’identification des données et des actifs critiques.

La majorité des services proposés par la Smart City sont à destination des citoyens. Par conséquent, des données identifiantes et ainsi potentiellement sensibles vont être collectées. Par ailleurs, une perte de disponibilité ou d’intégrité de certains services pourront avoir de graves répercussions étant donné que certaines composantes du SI ont une prise directe sur le monde physique. Les Smart Cities n’échappent pas aux réglementations, notamment au Règlement Général sur la Protection des Données (RGPD), mais aussi selon les usages au Référentiel Général de Sécurité (RGS), à la Loi de Programmation Militaire (LPM) ou à la directive européenne Network and Information Security (NIS), dont les exigences en matière de protection des données devront être intégrées dans les programmes.

Des niveaux de classification de la sensibilité de la donnée doivent donc être formalisés afin de permettre la priorisation des actions et la mise en place de cadres de traitement des données critiques adaptés tels que le chiffrement et l’anonymisation.

Le problème de l’accès aux données devra aussi être posé. Les acteurs de la Smart City sont nombreux et il sera nécessaire de segmenter la « vision » qu’ils pourront avoir du SI. Cela passera par une phase préalable de définition des profils d’habilitations, nécessaires au respect du principe de moindre privilège, associée à une revue régulière de leurs affectations afin de s’assurer qu’elles soient toujours légitimes.

Opérer sur des environnements de confiance

Le projet Smart City s’appuiera nécessairement sur différents socles techniques et organisationnels. Si ces socles sont au Système d’Information ce que les fondations sont à une maison, il est aisé de comprendre qu’il sera difficile de bâtir quoi que ce soit si cette base est fragile.

Comme toujours, ces socles techniques doivent être couverts par les mesures fondamentales de la sécurité : mise en place de bulles de confiance, durcissement des systèmes, patch management, sécurisation des comptes à privilèges et de leur usage, etc.

Par ailleurs, un système d’information à la surface d’attaque aussi large que celui de la Smart City devra nécessairement rompre avec le modèle de sécurité traditionnel dit « château-fort », en jouant davantage sur des aspects de cloisonnement et de contrôle d’accès à la donnée elle-même. La conformité des actifs au sein du système d’information devra être évaluée continuellement en s’appuyant sur des référentiels de configuration et de durcissement communs. Les systèmes et applications exposés doivent faire l’objet de contrôles et audits, particulièrement pendant la phase de développement, mais aussi pendant la phase d’exploitation.

Par ailleurs, la continuité et la reprise d’activité devront être au cœur de la stratégie de sécurité. Des plans devront être formalisés, mais aussi testés, incluant à la fois les considérations techniques comme la résilience des différents systèmes, incluant la capacité à restaurer des systèmes indépendamment des autres, mais aussi organisationnelles par la réalisation d’exercices de gestion de crise.

Enfin, la Smart City impliquant un grand nombre d’acteurs, toutes les parties prenantes devraient garantir la mise en œuvre de moyens significatifs dans la protection des systèmes d’information impliqués et se conformer aux exigences de la politique de sécurité du projet. Pour cela, ils devront être engagés contractuellement, à minima par l’inclusion d’exigences de sécurité dans les contrats, mais aussi par la formalisation et la mise en œuvre de plans d’assurance sécurité, notamment pour les prestataires les plus critiques. Des contrôles réguliers pourront être commandités afin de s’assurer du maintien du niveau de sécurité dans le temps et adresser les futurs scénarios de risque.

Détecter, réagir et partager

La Smart City ne peut se passer d’un service de détection et de traitement des incidents de sécurité.

Il conviendra de collecter les traces de l’activité sur les systèmes et rechercher les signaux faibles. Face au nombre important d’évènements à traiter, il sera indispensable de définir les risques dont on souhaite se prémunir et de s’appuyer sur des solutions de corrélation afin de faciliter ces recherches. L’utilisation d’outils d’automatisation permettra d’effectuer un premier tri des faux positifs, facilitant le travail des analystes dans la qualification des alertes de sécurité.

La construction du service de détection et de réaction pourra se faire en s’appuyant sur les référentiels PDIS et PRIS. On pourra au besoin recourir à des fournisseurs externes qualifiés sur ces deux services.

Le recours à des services de Cyber Threat Intelligence apportera un gain important d’efficacité dans la création et l’enrichissement des règles de détection du SOC. En effet, il sera ainsi possible d’adopter une posture de détection proactive en effectuant une veille sur les attaques ayant ciblé des Smart Cities et des modes opératoires utilisés. Ceci présentera également l’avantage d’améliorer l’efficacité du service de réaction par l’économie d’un temps d’investigation précieux.

Enfin, le processus de traitement des incidents de sécurité significatifs et majeurs ne pourra se faire sans la formalisation d’une cellule de gestion de crise, composée d’acteurs aux rôles bien définis et formés à cet exercice. Un point d’attention particulier sera porté sur le dispositif de communication externe, la « gravité » d’une crise dépendant autant de l’événement qui en est à l’origine que de la perception qu’en a le monde extérieur.

En conclusion, et comme nous l’avons vu au travers de ces deux articles, la Smart City est une évolution qui s’impose d’elle-même dans une époque où se mêlent à la fois des enjeux démographiques, écologiques et économiques. Ses promesses sont séduisantes, mais le cadre de mise en œuvre peut susciter certaines craintes.

Comme pour n’importe quelle transformation numérique, la garantie d’un niveau de sécurité en adéquation avec les enjeux du projet passera nécessairement par l’identification des failles et des risques de sécurité qu’elle engendre.

A l’ère des cyberguerres et des cybermenaces, la Smart City devrait être considérée comme un Fournisseur de Service Numérique, au sens de la directive NIS, et être protégée par les mesures de sécurité adaptées à ce statut.

La proposition de services sécurisés, respectueux des données de leurs usagers est une condition sine qua none au succès d’un projet Smart City, dont les bénéfices n’auront d’égal que l’ampleur de l’impact d’une cyberattaque réussie.

Cet article Les enjeux de Cybersécurité autour de la Smart City (2/2) est apparu en premier sur RiskInsight.

La sécurisation d’Office 365 passe par de nombreuses thématiques à adresser, dont la nécessité d’être en capacité de tracer les actions, afin de détecter des comportements illicites ou de remonter à la cause d’un incident.

En France, de nombreuses entreprises ont cependant des difficultés pour consolider les logs et définir des cas d’usages de supervision. La maîtrise de la journalisation doit être au cœur de cette démarche.

La supervision des actions d’administration, une nécessité

Pour ce décryptage sur la journalisation, prenons le cas des administrateurs de la plateforme.

Comme pour les autres solutions SaaS (Google Cloud Platform, Salesforce, etc.), l’atteinte à l’intégrité ou à la confidentialité des données à la suite d’une erreur ou d’une action malveillante d’un administrateur de l’entreprise se retrouve parmi les risques majeurs identifiés par nos clients

Par définition, les administrateurs Office 365 possèdent des privilèges élevés :

• Configuration des différents services – ou workloads – et des API ;
• Gestion des permissions sur les OneDrive et les boîtes mails des utilisateurs ;
• Gestion du cycle de vie des espaces de collaboration.

Il est facile d’imaginer les conséquences désastreuses qui pourraient résulter d’une utilisation malveillante ou non maîtrisée de ces privilèges. En effet, des paramètres tels que le partage à l’externe de SharePoint Online, les autorisations des API ou la configuration de la messagerie pourraient introduire des vecteurs de fuite de données significatifs.

Les bonnes pratiques du SI on-premise (cycle de vie, principe de moindre privilège, segmentation des droits, authentification forte, just-in-time access etc.) doivent aussi être appliquées sur le Cloud. Le Cloud aussi doit être maîtrisé et contrôlé.

Cependant, l’implémentation des bonnes pratiques  bien que nécessaire, ne suffisent pas. En effet, elles ne permettent pas de s’assurer qu’un administrateur ne réalise pas des actions diminuant le niveau de sécurité ou des actions illicites. On peut donc naturellement se demander comment il serait possible d’auditer les actions effectuées et de lever des alertes le cas échéant.

Quels sont les moyens fournis par Microsoft ? Comment prévenir qu’une personne malveillante n’efface ses traces (ce qui rendrait une attaque plus difficile à détecter et à reconstituer) ?

Afin d’illustrer les différentes possibilités, nous allons suivre les quatres exemples ci-dessous :

Figure 1 – Exemple d’actes d’administration suspects

Quels journaux sont disponibles ?

Unified Audit Logs : journalisation unifiée des différents services

Pour des raisons historiques et techniques, Office 365 possède nativement plusieurs sources de journaux : Unified Audit Logs, Exchange Logs et Azure Logs. Ces sources sont complémentaires et doivent être analysées conjointement afin d’avoir une vision exhaustive des actions d’administration réalisées.

La source de logs la plus couramment citée et utilisée sont les « Unified Audit Logs ». Ces logs centralisent les traces des utilisateurs et celles des administrateurs, pour l’ensemble des services de la plateforme : SharePoint Online, Azure AD, Exchange Online, Teams, Power Platforms. Microsoft intègre progressivement les différentes sources et continue à rajouter des nouveaux logs.

Pour revenir à nos exemples concrets, les logs intéressants sont :

• Modification de la Politique de partage à l’externe de SharePoint Online : SharingPolicyChanged
• Attribution de droits à un OneDrive : SiteCollectionAdminAdded
• Attribution de droits à une boîte mail : AddMailboxPermission
• Modification d’un rôle d’administration : AddMembertoRole

Ces logs sont accessibles et exportables via les Centres de Conformité et de Sécurité, les API Office 365 Management et PowerShell (via la cmdlet Search-UnifiedAuditLog). Notons que la journalisation doit être activée via le Centre de Conformité ou via PowerShell afin de pouvoir enregistrer des logs et permettre la recherche.

Il est possible de configurer directement des alertes liées à l’occurrence de certains logs dans les Centres de Sécurité et de Conformité.

Exchange Logs : journalisation de l’infrastructure de messagerie

La deuxième source de logs intéressante sont les « Exchange Logs ». Ces logs fournissent des informations quant aux actions d’utilisation et d’administration réalisées sur le service Exchange Online ainsi que sur les boîtes aux lettres personnelles ou partagées. Deux typologies de journaux peuvent être distinguées :

• Administrator Audit Logs: Logs d’administration du service ou d’une boîte aux lettres (ex : modification des permissions d’un utilisateur, modification de la durée de rétention de conservation des journaux d’une boîte aux lettres etc.)
• Mailbox Audit Logs : Logs d’utilisation d’une boîte aux lettres par l’utilisateur principal, un utilisateur délégué ou un administrateur de service (ex : accès à la boîte aux lettres, envoi d’un mail à la place de l’utilisateur principal, déplacement d’un élément dans un dossier, suppression définitive, etc.)

Pour revenir à nos exemples concrets, les logs qui vont nous intéresser ici sont :

• Attribution de droits à une boîte aux lettres : AddMailboxPermission
• Accès à un dossier ou à une boîte aux lettres : FolderBind (non activé par défaut):
• Accès à un mail : MailItemAccessed (uniquement pour les utilisateurs ayant une licence E5)

Pour aller plus loin avec les Administrator Audit Logs

Les Administrator Audit Logs sont générés pour toute action d’administration Exchange pouvant être reliée à une cmdlet PowerShell autre que Get, Search ou Test. Ces logs sont liés aux Unified Logs et peuvent être exploités dans le Centre d’Administration Exchange, les Centres de Sécurité et de Conformité, les API Office 365 Management et PowerShell.

Pour aller plus loin avec les Mailbox Audit Logs

Les Mailbox Audit Logs sont la seule catégorie de logs à être configurable (périmètre et granularité). Ces logs permettent de tracer les actions réalisées par un owner (propriétaire), un delegate (utilisateur ayant des permissions) et d’un admin (accès via les outils eDiscovery).

Depuis Janvier 2019, la journalisation des Mailbox Audit Logs est activée par défaut pour l’ensemble des locataires Office 365. A date, si la journalisation est activée par défaut, l’ensemble des boîtes aux lettres sont auditées (même si le paramètre « -AuditDisabled » est à « True »). La seule façon de ne pas journaliser les actions d’une boîte mail est d’implémenter une règle de by-pass avec « Set-MailboxAuditBypassAssociation ».

Il faut toutefois noter que certaines actions ne sont pas auditées par défaut, comme par exemple l’accès d’un delegate ou d’un admin à une boite mail d’un utilisateur. Il est par conséquence primordial d’analyser les journaux à activer, lors de la configuration initiale du service.

Selon le niveau de licences et la configuration, ces logs peuvent être liés aux Unified Logs et être exploités dans le Centre d’Administration Exchange, les API Office 365 Management et PowerShell ou les Centres de Sécurité et de Conformité.

Azure Logs et Rapports : journalisation d’Azure Active Directory

La dernière source de logs, mais pas la moins importante, sont les « Azure AD logs ». Ces logs permettent de fournir des traces complètes pour la brique d’identité d’Office 365 ainsi que sur les actions d’administration associées. Plusieurs catégories de journaux et de rapports sont disponibles :

• Azure Audit Logs: Logs d’administration de la brique d’identification ou de modification des éléments (ex : attribution du rôle « SharePoint Administrator », création d’un utilisateur ou d’un groupe de sécurité, autorisation d’une API, configuration des utilisateurs invités, etc.)
• Azure Sign-in Logs: Logs de connexion à un service Office 365 (ou à des applications / ) avec des informations sur la chaîne de connexion (ex : protocole, adresse IP, terminal, etc.)
• Risky Sign-in: Rapports de connexion avec des indicateurs liés à des connexions suspectes.

Ces logs et rapports sont accessibles et exportables via le portal Azure, les API Graph ou Azure Management et PowerShell. Certains des logs directement liés à Office 365 se retrouvent aussi dans les Unified Audit Logs.

Pour revenir à nos exemples concrets, les logs intéressants sont :

• Modification d’un rôle d’administration : AddMembertoRole
• Ajout d’une application : CoreDirectory – ApplicationManagement – Add service principal / Add application
• Consentement à une application : Core Directory – ApplicationManagement / Add delegated permission grant / Consent to application (ConsentContext.IsAdminConsent)

Figure 2 – Récapitulatif des caractéristiques des logs d’Office 365

En résumé, les Unified Audit Logs apportent une vision consolidée des différents services d’Office 365, mais certaines informations peuvent être manquantes. Il sera nécessaire de s’assurer que les journaux requis soient bien présents, et ensuite d’approfondir une investigation dans les logs et les rapports d’Exchange ou Azure.

Quelle rétention pour les différents journaux d’Office 365 ?

Une fois les logs adéquats identifiés, se pose le défi de la rétention. Comment être sûr que les journaux sont bien conservés sans être altérés, pendant toute la durée requise par la politique de sécurité de l’entreprise et les différentes réglementations, comme la loi anti-terroriste ou le RGPD ?

Par construction, et contrairement aux solutions Exchange and SharePoint on-premise, tous les logs cités précédemment sont inaltérables – c’est-à-dire non modifiables ni supprimables par les administrateurs de l’entreprise. Par ailleurs, les durées de conservation définies par défaut ne peuvent être modifiées (à savoir 90 jours pour les logs Office 365 et 7 ou 30 jours pour les logs Azure avec des licences standards). Ceci à une exception près, un administrateur Exchange a la possibilité d’effacer les journaux des boîtes aux lettres, en modifiant la durée de rétention associée.

Si on reprend nos exemples, on pourrait tout à fait imaginer un administrateur malveillant se donnant des droits pour accéder à une boîte mail, puis regarder les mails et effacer les logs d’accès en fixant une durée de rétention nulle. Dans ce cas, ne serait conservée que l’élévation de privilège réalisée dans les Administrator Audit Logs.

Afin de se mettre en conformité avec les exigences de sécurité ou la réglementation, il pourra de plus être nécessaire de s’assurer que les journaux des différents services soient conservés plus de 7, 30 ou 90 jours.

Quelques étapes pour implémenter une journalisation pertinente au sein d’Office 365

1. Définition et activation des logs nécessaires: les Unified Audit Logs peuvent ne pas être suffisants (suivi des API Office 365 et Azure AD, journalisation des accès des administrateurs aux boîtes aux lettres, etc.)
2. Configuration d’un export automatique des journaux identifiés vers un stockage externe  (via PowerShell ou les API Management) ;
3. Suivi de l’état du tenant : implémentation d’un tableau de bord des paramètres du tenant configuration d’alertes liées à un changement de la configuration des journaux (via le Centre de Sécurité ou Conformité, les API Office 365 Management ou PowerShell), comme la désactivation des Unified logs ou à une modification de la rétention des logs d’une boîte aux lettres ;

Figure 3 – Bonnes pratiques pour la journalisation du tenant

Après avoir réalisés ces trois actions, l’entreprise aura les informations nécessaires pour auditer les actions d’utilisation et d’administration du tenant. Cependant, elles ne répondent pas encore au besoin plus large de supervision des administrateurs. Il pourra être utile de mettre en place des alertes (via le Centre de Sécurité ou de Conformité ou des outils tierces spécialisés).

1. (Pour aller plus loin) Mise en place d’une supervision basique : définition de scénarii de détection sécurité généralistes, identification des logs concernés, activation de l’alerte associée dans les Centres de Sécurité ou de Conformité ;
2. (Pour aller encore plus loin) Mise en place d’une supervision avancée : identification de scénarii liés à un contexte métier, implémentation, définition de la gouvernance associée, amélioration continue.

Quels outils utiliser pour analyser les journaux ? Quels scénarios de détection prioriser ? Quelle gouvernance mettre en place pour définir, implémenter et suivre des alertes ? Autant de questions qui doivent être traitées dans l’implémentation de la supervision de la plateforme de collaboration.

Il faudra également prendre en compte les changements réguliers apportés par Microsoft sur ces services, ainsi que sur la structure des logs et des API. D’autant plus que cohabitent les fonctionnalités en Preview et celles en General Availability.

Cet article Journalisation d’Office 365 : un cas concret avec les administrateurs est apparu en premier sur RiskInsight.

Des méthodes de détection statiques à de l’analyse comportementale

Les attaques évoluant de plus en plus rapidement et de manière toujours plus élaborée, le SOC (Security Operations Center) est forcé de revoir son approche concernant les outils en place car les mécanismes de détection statiques deviennent trop rapidement obsolètes :

• L’approche historique repose sur la reconnaissance de comportements et d’empreintes connues (ex : signatures de malwares). Cette méthode, appelée misuse-based, remonte des alertes explicites et simples à analyser pour les opérationnels, mais seules les attaques déjà subies et détectées pourront être reconnues.
• La nouvelle approche vise à analyser les actions déviant du comportement normalement observé sans avoir à définir explicitement et exhaustivement un acte malveillant (ex : comportement d’un individu s’éloignant de celui de ses collègues). Cette approche anomaly-based permet de détecter des attaques non renseignées directement dans les outils mais nécessite d’exploiter de plus larges volumes de données.

L’approche anomaly-based exploite les capacités de corrélation des algorithmes d’apprentissage non supervisé mettant en avant des liens dans des données non labellisées (non catégorisées comme normales ou anormales).

Recette de l’été : détection d’anomalies sur lit de Machine Learning

Pour savoir si le Machine Learning convient à son contexte, la meilleure solution reste de réaliser un PoC (Proof of Concept). Comment l’implémenter ? Quels sont les points d’attention ? Voici les étapes clés de notre développement.

Entrée, plat ou dessert : définir le cas d’usage

Faire du Machine Learning, c’est bien. Savoir pourquoi, c’est mieux. Définir un cas d’usage revient à répondre à la question « Que voulez-vous observer ? » et déterminer les moyens disponibles pour y répondre.

Dans notre contexte, un cas d’usage est un scénario de menace portant sur un ou des groupes de comptes (administrateurs malveillants, exfiltration de données sensibles…). Pour les évaluer, plusieurs critères sont à prendre en considération :

• Utilité: quel serait l’impact si le scénario se réalisait ?
• Disponibilité des données: quelles sont les sources de données utiles disponibles ?
• Complexité des données: les données disponibles sont-elles structurées (nombres, tableaux) ou non structurées (images, texte) ?

Nous avons choisi de travailler sur la compromission de comptes de services : certains peuvent avoir des droits importants, et leurs actions automatisées génèrent des données relativement structurées. Dans le cadre d’un PoC, un périmètre restreint et des sources de données homogènes et facilement accessibles sont à privilégier pour obtenir des résultats concrets et exploitables, avant d’envisager des cas d’usages plus ambitieux.

Pesée des ingrédients : déterminer le modèle de données

Afin d’exploiter au mieux les données, il est nécessaire de définir une représentation permettant de modéliser un comportement à partir des informations disponibles. Ici intervient notamment l’expertise métier : une action isolée peut-elle être signe de compromission ou faut-il plutôt prendre en compte une série d’actions pour détecter un comportement malveillant ?

Dans un premier temps, nous avons défini un modèle basé sur l’analyse de logs unitaires et de même famille (ex : connexions, accès aux ressources…) pour évaluer le fonctionnement global. Cependant, un modèle trop simple ignorera des signaux faibles cachés dans des corrélations d’actions, tandis qu’une représentation trop complexe ajoutera du temps de traitement et sera plus sensible aux biais de modélisation.

Sélection des ustensiles : choisir l’algorithme

Plusieurs types d’algorithmes peuvent être employés pour la détection d’anomalies :

• Certains tentent d’isoler chaque point : si un point est facile à isoler, il est éloigné des autres et donc plus anormal.
• Les algorithmes de clustering créent des groupes de points qui se ressemblent et calculent le barycentre de chacun correspondant au comportement moyen : si un point est trop éloigné du barycentre, il est considéré comme anormal.
• Moins fréquents, les auto-encodeurs sont des réseaux de neurones artificiels qui apprennent à recréer le comportement normal avec moins de paramètres : les erreurs de reproduction du comportement pourront être considérées comme un score d’anomalie.

D’autres approches existent encore, jusqu’aux plus exotiques systèmes immunitaires artificiels qui imitent les mécanismes biologiques pour créer un outil de détection évolutif. Il faut cependant ne pas oublier qu’un outil simple et bien optimisé est souvent plus efficace qu’un outil trop complexe.

L’algorithme de clustering des k-moyennes a été sélectionné dans notre cas : utilisé notamment dans la détection de fraude bancaire, il simplifie le réentrainement qui permet à l’outil de rester adapté malgré les évolutions des comportements.

Tous ces algorithmes peuvent également être enrichis, selon le modèle de comportements choisi, pour prendre en compte une suite d’actions. Ainsi, des réseaux de neurones convolutifs ou récurrents peuvent être ajoutés en amont pour prendre en compte des séries temporelles.

Préparation des ingrédients : transformer les données

Une fois que l’algorithme a été sélectionné, il faut traiter les données brutes afin de les rendre exploitables. Ce traitement s’effectue en plusieurs étapes :

• Le nettoyage: correction des erreurs de parsing, suppression des informations inutiles et ajout des informations manquantes
• L’enrichissement: ajout des données venant d’autres sources et retraitement des champs pour mettre en avant une information (ex : indiquer si une date est un jour férié…)
• La transformation: création de colonnes binaires pour les données qualitatives (ex : nom de compte, type d’événement…) ne pouvant pas être directement transformées en nombres (une colonne pour chaque valeur unique, indiquant si la valeur est présente ou non)
• La normalisation : retraitement des valeurs afin qu’elles soient toutes comprises entre 0 et 1 (pour éviter qu’un champ ne prenne l’ascendant sur un autre)

En raison de la variété d’événements possibles et de la complexité des logs, nous avons fait le choix d’automatiser ce processus : pour chaque champ, l’algorithme détecte le type de données et sélectionne la transformation adaptée dans une bibliothèque prédéfinie. L’opérateur peut ensuite interagir avec l’outil pour modifier ce choix avant de continuer le processus.

Assaisonnement : tester et optimiser l’outil

Une fois le modèle défini, l’algorithme choisi et les données transformées, l’outil développé devrait être en capacité de lever des alertes sur des anomalies. Ces alertes ont-elles du sens ou sont-elles des faux positifs ?

Afin d’évaluer la performance de l’outil, nous avons effectué deux types de tests :

• La simulation d’intrusion en effectuant des actions malveillantes pour vérifier si elles sont bien détectées comme anormales (cette approche peut être également traitée en ajoutant directement de « faux » logs dans les sets de données)
• L’analyse des anomalies en vérifiant si les alertes levées correspondent effectivement à des comportements malveillants

De nombreux paramètres peuvent être ajustés dans les algorithmes permettant d’affiner la détection. L’optimisation des performances se fait par itérations, en modifiant les paramètres et en observant l’effet sur un set de données de validation. Chronophage manuellement, elle peut être améliorée par l’approche AutoML qui cherche à automatiser certaines étapes par l’utilisation d’algorithmes d’optimisation.

Cependant, l’optimisation des paramètres ne suffit pas : les résultats de notre PoC nous ont permis de constater que la qualité d’une détection basée sur de l’analyse comportementale repose en grande partie sur la pertinence des comportements définis en amont du développement de l’algorithme.

ML or not ML: that may not be the question

Malgré ses atouts indéniables, le Machine Learning est un outil à utiliser de manière raisonnée : les frameworks deviennent de plus en plus accessibles et simples d’utilisation, mais les étapes cruciales restent la définition du use-case et du modèle de comportement. Ces choix, où l’expertise métier est indispensable, influenceront de manière irréversible le choix des données, la sélection de l’algorithme de détection et les tests à effectuer.

La question n’est donc plus « Où puis-je mettre du Machine Learning dans mon SOC ? », mais « Parmi toutes les approches disponibles, quelle est la plus efficace pour répondre à mon problème ? ».

Pour le savoir, une seule solution : allumez les fourneaux !

Cet article Détecter des incidents cyber par Machine Learning : notre maquette en 5 étapes clefs ! est apparu en premier sur RiskInsight.

Compléter la détection avec de nouvelles approches

Raisonner identité pour détecter les comportements suspects : UEBA

Les technologies UEBA (pour User and Entity Behavioral Analysis), précédemment appelées UBA, sont parmi les derniers nés des outils venant compléter l’arsenal de détection des SOC. Comme leur nom l’indique, leur approche est claire : faire abstraction des considérations techniques des solutions actuelles (SIEM…) en analysant le comportement des utilisateurs et des entités (comprendre terminaux, applications, réseaux, serveurs, objets connectés…).

Le principe est simple, mais son implémentation l’est beaucoup moins. En effet, pour être efficace, les dispositifs UEBA ont besoin de sources nombreuses, avec des formats de données variés. Les sources traditionnelles, telles que le SIEM et le(s) gestionnaire(s) de logs, mais aussi directement certaines ressources (AD, proxy, BDD…) sont souvent utilisées.

Mais afin de parfaire la détection, les solutions UEBA interrogent aussi de nouvelles sources : informations sur les utilisateurs (applications RH, gestion des badges…), échanges entre employés (chats, échanges vidéo, emails…), ou toute autre contribution pertinente (applications métiers à surveiller…).

À partir de toutes ces informations, les solutions UEBA analysent les comportements des utilisateurs (et entités) pour identifier de potentielles menaces. Elles peuvent utiliser des règles statiques, sous forme de signatures à détecter (souvent déjà implémentées dans les solutions SIEM) : connexions simultanées depuis deux endroits différents ou hors des plages horaires classiques…

Mais la véritable force des UEBA réside dans l’utilisation d’algorithmes de Machine Learning pour détecter des modifications du comportement d’utilisateurs ou services : opération métier suspecte, accès à des applications critiques jamais utilisées auparavant lors de congés, transferts de données inhabituels…

Si, à l’origine, les UEBA étaient pensés pour lutter contre les fraudes, leur rôle s’est cependant peu à peu élargi pour couvrir certains périmètres posant habituellement des problèmes aux SIEM : vols de données, compromission -ou prêt- de comptes applicatifs, infection de terminaux ou serveurs, abus de privilèges…

Ainsi, les UEBA se positionnent aujourd’hui en compléments des SIEM, en complétant l’approche « technique » par une vision « utilisateur », et en ajoutant une couche d’intelligence supplémentaire dans l’analyse.

Au vu du marché, il probable que les solutions UEBA cessent d’exister en tant que telles dans les années à venir et s’intègrent à des solutions existantes (SIEM, EDR…), passant de produits à fonctionnalités.

Exemples d’éditeurs UEBA :

Piéger les attaquants : Deceptive Security

La Deceptive Security peut être considérée comme un passage au niveau supérieur des Honey Pots. Des leurres, sous formes de données, d’agents ou d’environnements dédiés, sont répartis à grande échelle dans tout ou partie du SI.

Selon les solutions et les besoins, les outils de Deceptive Security peuvent poursuivre deux buts. En détournant l’attention des attaquants des vraies ressources et en les dirigeants vers de fausses pistes, ils peuvent agir comme moyens de protection.

Mais surtout, la surveillance de ces leurres peut permettre de détecter des menaces se propageant au sein du SI. En effet, ces leurres n’ayant d’autres utilités que d’appâter de potentiels attaquants ou de divulguer de fausses informations, toute communication avec l’un d’entre eux est nécessairement suspecte.

Ce type de solution ne remplace par les solutions existantes, mais répond à des cas d’usage bien spécifiques, pour lesquels les dispositifs de détection classiques sont peu efficaces : les APT, spécialement conçus pour les contourner, et plus largement les mouvements horizontaux au sein du SI.

Pour plus de détails sur les solutions de Deceptive Security, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs Deceptive Security :

Détecter les signaux faibles sur le réseau : sondes « Machine Learning »

Les sondes de détection classiques (IDPS), basées sur l’analyse de trafic et la comparaison avec des signatures d’attaques connues, sont peu efficaces lorsqu’il s’agit de détecter des menaces subtiles (APT…) ou inconnues (0 days…). Pour pallier ce problème, les IDPS nouvelles générations intègrent des capacités de Machine Learning (parfois présenté comme de l’Intelligence Artificielle) dans leur arsenal de détection.

Selon les solutions, deux types d’usage du Machine Learning sont à distinguer. D’une part, l’utilisation de ces algorithmes en mode supervisé, pour apprendre à reconnaître le comportement de certaines attaques ou phases d’attaque lors de leur phase active : commande & contrôle, scans, mouvements latéraux, fuite de données…

Une fois la sonde déployée, l’ajustement des seuils de détection au contexte client est lui aussi basé sur des algorithmes de Machine Learning (comme le font déjà bon nombre de solutions IDPS classiques).

Ce mode de fonctionnement permet un déploiement rapide (solution utilisable out-of-the-box et phase d’apprentissage écourtée), et une meilleure capacité à détecter les attaques caractérisées précédemment. En contrepartie, la détection des attaques non couvertes par l’apprentissage ou complètement inconnues restent difficiles.

A l’opposé de cette approche, des solutions misent sur l’apprentissage non-supervisé pour détecter les attaques. Pour cela, lors du déploiement, les sondes sont positionnées sur le réseau pour observer le trafic, et apprendre à reconnaître le trafic légitime.

Une fois la phase d’apprentissage terminée, les sondes sont capables de détecter des anomalies, et donc de lever des alertes en cas de comportement suspect. Cette approche permet de détecter des attaques inconnues, mais nécessitent généralement une phase d’apprentissage plus longue pour être efficace et atteindre un taux de fausses alertes acceptables.

Dans les deux cas, les sondes « Machine Learning » permettent de compléter l’arsenal des SOC, aujourd’hui majoritairement destiné à détecter des attaques connues, par des capacités de détection capables de distinguer des attaques complexes, méconnues, ou créés pour contourner les dispositifs de sécurité classiques.

Nos premiers retours terrains montrent que ces technologies peuvent en effet détecter des menaces passant au travers des dispositifs de sécurité classiques. Les faux positifs sont cependant très fréquents (la courbe d’apprentissage variant grandement selon les solutions et les contextes), et il reste difficile de juger de l’exhaustivité des menaces détectées.

Les sondes « Machine Learning » ont donc un avenir certain parmi les outils du SOC, même si un gain en maturité reste à réaliser pour qu’elles atteignent leur plein potentiel.

Exemples d’éditeurs de sondes ML :

Pour retrouver notre troisième et dernier article sur cette saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (2/3) est apparu en premier sur RiskInsight.

Dans un contexte où l’on assiste à une véritable pénurie de compétences cybersécurités, ces problématiques ne peuvent être adressées uniquement par le renforcement des effectifs du SOC. L’utilisation de nouveaux outils, basée sur 4 axes stratégiques, est indispensable pour permettre au SOC d’avoir de l’avance sur les nouvelles menaces.

Ainsi, l’extension de la détection à de nouveaux périmètres permet de protéger de nouvelles parties du SI, aujourd’hui insuffisamment sécurisées (Cloud) ; et des ressources de plus en plus prises pour cibles (attaques ransomware sur les terminaux, attaques ciblées utilisant les AD…).

Dans le même temps, l’adoption de nouvelles approches devient une nécessité pour détecter les attaques ciblées (0days, « low signal » …), dont la subtilité croissante met à mal les dispositifs de sécurité existants.

En complément de nouveaux outils de détection, une connaissance avancée des menaces et des attaquants peut venir améliorer les capacités de détection existantes, aider à la priorisation des incidents à traiter et faire gagner en efficacité lors de la réaction.

Mais les équipes SOC éprouvent déjà des difficultés à traiter les évènements générés par les outils existants. Il est donc primordial d’industrialiser et d’automatiser les interactions entre équipes et systèmes, et, lorsque c’est possible, les étapes d’analyse et de réaction !

Pendant l’été, suivez les épisodes de notre saga pour découvrir les moyens d’outiller ces 4 axes stratégiques !

Étendre la détection à de nouveaux périmètres

Une solution unique pour sécuriser tous les Cloud : CASB

Les CASB (pour Cloud Access Security Broker) adressent un périmètre du SI aujourd’hui mal desservi par les mesures de sécurité classiques : le Cloud. Par sa nature, sa protection nécessite en effet des adaptations par rapport aux SI classiques : pas ou peu de maîtrise des ressources (infrastructures, OS ou applications, selon le type d’offre), localisation à l’extérieur du SI…

Les CASB visent à centraliser et à faire appliquer les politiques de sécurité aux services situés dans le Cloud. Certains fournisseurs Cloud proposent leurs propres services de sécurisation CASB (par exemple Microsoft avec Microsoft Cloud App Security) ; mais, selon les besoins, il est parfois préférable d’utiliser des solutions tierces, même si l’ajout d’un acteur supplémentaire a un coût. En effet, le CASB visant à s’assurer du niveau de sécurité du Cloud, confier ce rôle aux fournisseurs du service à surveiller peut être contre-productif, et l’utilisation d’un « tiers de confiance » est à privilégier.

Dans tous les cas, les CASB sont des solutions variées, pouvant regrouper de très nombreux services, leurs maturités variant selon les éditeurs de solution, les fournisseurs Cloud et le type d’hébergement (IaaS, PaaS, SaaS…).

D’une part, les solutions CASB permettent d’adresser les enjeux spécifiques aux Cloud, en palliant le manque de visibilité sur ces environnements (détection du Shadow IT, statistiques d’utilisation…), et en s’assurant de leur conformité (vérification des configurations…).

D’autre part, elles participent au déploiement des mesures de sécurités classiques sur ce périmètre. En particulier, les enjeux de sécurité de la donnée (DLP et mesures de chiffrement, particulièrement appréciées par les régulateurs) et de détection des menaces (centralisation des logs Cloud pour transmission au SIEM, détection de comportements anormaux -UEBA !, voir partie dédiée-…) font parties des capacités classiques proposées par les éditeurs. En complément, certaines problématiques d’IAM peuvent aussi être adressées par ces solutions (SSO, contextualisation des accès…).

Il existe deux principaux modes de déploiement pour la mise en place de ces fonctionnalités, chacun possédant ses avantages (et inconvénients). Les solutions types proxy sont placées en coupure entre les utilisateurs et le service Cloud.

A l’opposé, dans le cas des solutions de type API, parfois appelées out-of-band, les consommateurs du service Cloud communiquent directement avec celui-ci. Pour chaque accès, le service interroge les API du CASB afin de d’évaluer les risques, et d’autoriser ou non la consommation du service. Les solutions API s’appuient cependant sur les interfaces proposées par le fournisseur Cloud pour fonctionner, ce qui peut limiter certaines possibilités.

Aujourd’hui jeunes et peu matures, les CASB restent peu déployés. Au vu de la démocratisation (déjà bien avancée) des services Cloud, les CASB ont cependant un bel avenir devant eux, et permettront aux équipes SOC d’étendre leur surveillance sur ce périmètre, voué à représenter une partie importante du SI.

Exemples d’éditeurs CASB :

Détection et réaction, le nouveau couteau suisse pour sécuriser les terminaux : EDR (Endpoint Detection and Response)

Les solutions EDR (pour Endpoint Detection and Response) viennent compléter les capacités de détection et de réaction des SOC sur les terminaux (PC, serveurs…).

Comme leur nom l’indique, les EDR participent à la détection d’attaques. Ceux-ci viennent en effet combler les faiblesses des anti-virus (et autres HIPS) s’appuyant sur des signatures d’attaques précises, et donc inadaptées pour détecter certains types d’attaques, notamment les attaques avancées (APT). Les EDR se basent donc sur d’autres méthodes de détection, les éditeurs proposant généralement une combinaison de techniques habituellement utilisées sur d’autres périmètres.

Parmi ces techniques, la détection d’exploitation de vulnérabilités connues ou de patterns d’attaque (ouverture de port suspects vers des adresses douteuses…), l’analyse de fichiers par une sandbox (émulation locale, soumission dans le Cloud…), et des approches comportementales basées sur du Machine Learning (en particulier les solutions UEBA, cf. partie dédiée) sont utilisées par bon nombre de solutions. Selon les besoins du SOC, les alertes remontées peuvent être intégrées comme sources du SIEM, ou disponibles directement depuis la console de management de la solution.

En plus de ces capacités de détection avancées, les solutions EDR apportent aussi un important gain en visibilité sur les terminaux : liste des processus et services lancés, liste de fichiers dans certains répertoires systèmes… et toute autre information permettant de faciliter l’investigation en cas d’alerte. Certaines solutions ne se limitent pas à récupérer l’état du terminal au moment de la demande, mais permettent aussi de récupérer son historique : génération de logs, récupération de fichiers supprimés…

Mais les fonctionnalités des EDR ne s’arrêtent pas aux étapes de détection et d’analyse. En effet, ces solutions permettent d’effectuer des actions de remédiation à distance, dont la complexité dépend des éditeurs : suppression ou mise en quarantaine de fichiers, arrêt de processus, mise en quarantaine réseau de postes, modification de clés de registre…

Les EDR sont donc des solutions très complètes intervenant à toutes les étapes du processus : de la détection, à l’analyse, jusqu’à la réaction. Elles n’ont cependant pas vocation à remplacer les solutions anti-virus, toujours plus efficaces pour bloquer les attaques connues ; même si l’on observe de plus en plus d’éditeurs proposant des solutions unissant les deux types de fonctionnalités.

Pour plus de détails sur les solutions EDR, vous pouvez consulter notre article dédié au sujet ici !

Exemples d’éditeurs EDR :

Protection des clés du royaume : supervision Active Directory

Les annuaires comptent parmi les composants les plus critiques du SI. En effet, ceux-ci fournissent les fonctionnalités d’authentification et d’habilitation pour la quasi-totalité des ressources du SI, aussi bien techniques que métiers, y compris les plus critiques. Il n’est donc pas étonnant que la compromission d’AD figure parmi les méthodes d’attaque les plus utilisées, car ouvrant de nombreuses portes aux attaquants.

Malgré cette criticité, et bien que les architectures AD soient bien connues et aient peu évolué depuis plusieurs années, leur sécurisation reste perfectible. Cela est en particulier dû à leur mode de fonctionnement spécifique (OU, domaines, arbres, forêts, utilisateurs…), rendant les moyens de protection et de surveillance classiques peu efficaces, en particulier lorsque toute vulnérabilité peut représenter un risque majeur pour le reste du SI.

Les solutions de surveillance AD visent à pallier ce problème en supervisant (en temps réel, ou lors d’audit) les spécificités des annuaires (configuration, état des comptes…), et en y détectant des vulnérabilités susceptibles de causer leur compromission. Pour cela, les solutions de supervision AD possèdent une connaissance très pointue du fonctionnement des AD, et tout particulièrement des enjeux de sécurité liés.

Lorsqu’une vulnérabilité est détectée, une alerte est remontée (par le biais du SIEM, ou directement dans la solution) et des conseils de remédiation peuvent être fournis afin de faciliter le travail des équipes en charge de la correction.

Les outils de supervision AD permettent par ailleurs au SOC de détecter toute modification de configuration (légitime, accidentelle ou malveillante) et de s’assurer en continu du niveau de sécurité de ces composants critiques, compliquant d’autant la tâche de nombreux attaquants.

En complément du renforcement direct du niveau de sécurité de l’AD, ces solutions peuvent aussi être utilisés pour s’assurer de la compliance vis-à-vis de normes ou de contraintes réglementaires (LPM, PCI DSS…).

Ces solutions restent assez peu répandues aujourd’hui, et leur utilisation généralement limitée à des audits ponctuels. Cependant, au vu des importants gains de sécurité associés (détection et conseils de remédiation) et de leur simplicité d’utilisation, ces solutions sont prometteuses et devraient réussir à se faire une place parmi les outils du SOC.

Exemples d’éditeurs de supervision AD :

Pour retrouver notre second article de la saga, c’est par ici.

Cet article SOAR, UEBA, CASB, EDR et autres acronymes… suivez la saga de l’été pour comprendre et choisir parmi les nouveaux outils du SOC (1/3) est apparu en premier sur RiskInsight.

Aux origines : les Honeypots

Le principe de Deceptive Security est basé sur l’utilisation de Security Decoys (ou « leurres » en français), inspirés des Honeypots (pots de miel). Le principe est simple : des leurres sont répartis aux points stratégiques du SI et toute activité y est tracée. Ces leurres n’ayant d’autres utilités que d’appâter de potentiels attaquants, toute communication avec l’un d’entre eux est nécessairement suspecte. Leur analyse permet donc de détecter et d’étudier de potentielles menaces.

Aujourd’hui, les Honeypots demeurent peu répandus, les principaux cas d’usage restant cantonnés à des cas de recherche ou de récupération d’informations (notamment de Threat Intel). Ainsi, des « pots de miel » sont exposés publiquement afin d’observer le trafic reçu sur Internet, et d’en extraire des informations : observation de nouvelles menaces (ransomware, chevaux de Troie…), identification d’IP suspectes ou compromises (SPAM, botnet…) … On peut cependant noter le regain d’intérêt pour les honeypots suite à l’attaque WannaCry, pendant laquelle nombre d’entre eux ont été utilisés pour récupérer et analyser le ransomware.

Dans les SI des entreprises, leur utilisation est encore plus marginale, et – en plus des cas cités précédemment – majoritairement limitée à des besoins bien spécifiques de gestion de crise ou de réponse à incident. Dans ces cas, les Honeypots sont utilisés pour contenir la menace dans un périmètre défini (afin de protéger les ressources critiques), étudier son comportement et en déduire son objectif.

Ainsi, aujourd’hui, les Honeypots sont principalement utilisés dans des buts d’observation et de compréhension de la menace.

Les difficultés que les Honeypots rencontrent pour se démocratiser reposent principalement sur deux limites : ceux-ci sont généralement trop facilement détectés par les attaquants, et le passage à l’échelle d’un SI relève de l’impossible, notamment par manque d’industrialisation des solutions.

Suivre le rythme : wider, faster, stealthier

Le principe de Deceptive Security vise justement à adresser ces deux problématiques, et repose sur la capacité à déployer des leurres de manière industrielle et sur des périmètres étendus. Le déploiement de ces honeypots peut être réalisé de deux façons : par le déploiement d’environnements leurres dédiés, ou par l’ajout de leurres (agents…) installés sur des environnements existants (serveurs de production, de transfert de fichier…). La stratégie de certaines solutions de Deceptive Security repose sur le déploiement de leurres à une échelle telle que ceux-ci créent un « second SI » dans le SI (ou une partie de celui-ci), similaire à une toile d’araignée dans laquelle l’attaquant vient s’emmêler.

Même si cette industrialisation représente un progrès majeur en soi, ce qui justifie la création d’une nouvelle catégorie d’outils (plutôt que de parler de simple évolution), c’est surtout la capacité à mieux dissimuler les leurres. Terminés les serveurs vulnérables avec des mots de passe par défaut : le piège est évident, l’attaquant n’y croit plus. Aujourd’hui, les solutions de Deceptive Security les plus avancées racontent une histoire à l’attaquant afin de le guider peu à peu vers leurs pièges.

La recette : remonter les miettes jusqu’au pot de miel

Pour cela, des informations (généralement appelées « miettes ») sont disséminées sur les environnements existants : serveurs de productions, AD… Bien entendu, l’industrialisation du déploiement de ces miettes est lui aussi un des enjeux principaux mis en avant par les solutions les plus avancées. Une miette représente un brin d’information : la mention d’un serveur hébergeant un middleware obsolète, des identifiants de connexion à un serveur, l’existence d’un compte possédant des droits d’administration…

Selon les solutions, ces miettes peuvent poursuivre deux buts distincts. Elles peuvent être utilisées comme un mécanisme de protection, en guidant les attaquants vers de fausses pistes, ralentissant leur progression et les encourageant à jeter l’éponge et à changer de cible.

Mais surtout, elles peuvent aussi permettre la détection des attaquants. Dans ce cas, chacune des miettes représente un indice, que les attaquants peuvent récolter en explorant les différentes ressources du réseau. Une fois récoltés, interprétés et corrélés, ces indices guident petit à petit les attaquants vers des leurres. Et c’est ici qu’est le réel enjeu, et la rupture par rapport au positionnement classique, de la Deceptive Security : comment créer des scénarios plausibles -et variés- pour piéger les attaquants ?

Ainsi, là où les Honeypots se contentent de circonscrire l’attaquant dans un périmètre défini afin de comprendre le fonctionnement et l’objectif de l’attaque, les Security Decoys visent à être déployés sur un maximum de ressources, afin d’augmenter les chances de détection, et doivent donc savoir rester discrets.

Une fois le contact avec le leurre établi, l’attaquant est repéré. Son comportement peut être alors étudié ou son accès bloqué. Dans les cas les plus poussés, de fausses informations peuvent aussi être mises à disposition pour exfiltration, permettant de faire croire à l’attaquant que sa tentative est réussie, ou de le déstabiliser lui ou son employeur : faux secrets de fabrication ou projets de brevets, fausses stratégies de rachat…

Une nouvelle approche aux nombreux avantages

Au vu de son fonctionnement, la Deceptive Security présente certains avantages par rapport aux solutions existantes.

• La transparence pour les utilisateurs et les applications : la mise en place de leurres n’ajoute aucune contrainte aux équipes IT et utilisateurs finaux : pas d’ouverture de flux, de blocage de communication ou de fichiers légitimes… ;
• Un faible taux de fausses alertes: un leurre n’étant pas supposé être utilisé de manière légitime, tout contact a de forte chance d’être lié à une menace ;
• L’absence de connaissance des attaques pour être efficace : la protection apportée par la Deceptive Security n’est pas basée sur une connaissance préalable de la menace à détecter ou bloquer (pas de signatures…). Elle est donc à même de détecter certaines menaces inconnues (0-days sur des dispositifs de sécurité ou des middlewares…) et ne nécessite pas de mise à jour continue pour être efficace. Cependant, pour détecter de cas spécifiques – sur un type d’attaque ou une ressource ciblée par exemple -, une bonne connaissance des vecteurs d’attaques reste une nécessité pour la création de miettes convaincantes et pertinentes pour le scénario souhaité ;
• L’absence de phase d’apprentissage : la détection ou le blocage d’une menace ne repose pas non plus sur l’apprentissage du réseau (seuils, patterns…), même si une connaissance de celui-ci reste nécessaire. L’outil est donc opérationnel dès son déploiement, et n’est pas vulnérable pendant cette phase de définition de la « normalité » du réseau. Ainsi, la Deceptive Security évite les principaux inconvénients des approches par signature et par apprentissage ;
• L’absence de besoin de corrélation avec d’autres ressources: même si la corrélation avec d’autres ressources reste un plus, une simple connexion sur un leurre suffit à lever une alerte nécessitant d’étudier le cas plus en détail ;
• La possibilité de couvrir des périmètres généralement difficiles à protéger: des leurres peuvent être déployés sur de nombreux périmètres (IoT, legacy…) avec une complexité limitée, et donc apporter une nouvelle protection à ces ressources souvent non-couvertes par les dispositifs classiques.

Des cas d’usage bien spécifiques

Si la Deceptive Security permet de détecter certaines attaques classiques (malwares, scans…), le réel intérêt de ce type de solution n’est pas là, ces menaces pouvant être adressées plus efficacement par les dispositifs existants (antivirus…).

Le meilleur cas d’usage de la Deceptive Security est la détection des tentatives d’explorations fines et d’installation au sein du réseau, permettant ainsi -quand le niveau de sophistication des miettes est suffisamment important- de détecter certaines APT. Plus généralement, ce type de solution permet de détecter les mouvements latéraux au sein du réseau, et ce même avec un niveau limité de personnalisation des miettes.

Ce type de dispositif n’est donc pas destiné à remplacer les mesures existantes, mais peut agir comme complément, dans le but de détecter ces types de menaces échappant communément aux dispositifs classiques.

Et pour la suite ?

Concernant l’évolution de ces solutions, certains travaux cherchent à appliquer ce principe (déguiser les leurres en environnements de production) … mais dans l’autre sens ! En faisant passer les environnements de production pour des leurres, cette démarche à contrepied permettrait d’éviter à ces ressources d’être ciblées par les attaquants !

Les éditeurs

Une liste -non exhaustive- d’éditeurs de solution de Deceptive Security est renseignée à titre indicatif ci-dessous.

Cet article Deceptive Security : comment arroser l’arroseur ? est apparu en premier sur RiskInsight.

Cependant, de nouvelles réglementations le soumettent à des contraintes de plus en plus fortes telles que le GDPR (General Data Protection Regulation) visant toutes les données à caractère personnel, ou les différentes lois sur la protection des infrastructures critiques des pays. La France est particulièrement en avance aujourd’hui avec la LPM (Loi de Programmation Militaire [lien EN / lien FR ]) qui s’applique aux organisations les plus critiques pour le fonctionnement de l’Etat.

Comment mettre en place un système de détection de plus en plus fin, tout en s’inscrivant dans un cadre réglementaire toujours plus strict ?

Une standardisation des SOC à l’échelle européenne (et mondiale)

Au milieu des années 2000, la mise en place des premiers SOC consistait, dans la plupart des cas, à déployer un collecteur de logs par plaque géographique et à mettre en place une gestion des alertes en central. Cependant, des évolutions réglementaires récentes peuvent imposer des changements d’architecture. En particulier en France dans le cadre de la LPM, l’obligation de mise en place d’un « système de corrélation et d’analyses de journaux » (autrement dit : SOC outillé par un SIEM) s’est accompagnée d’une structuration règlementaire stricte décrite dans le référentiel d’exigences PDIS (Prestataires de Détection des Incidents de Sécurité [lien FR]).

Trois points sont traités en particulier pour la standardisation :

• D’abord, l’organisation de la surveillance : il existe dorénavant une obligation de détection de certains types d’attaques communes et d’implémentation de contrôles faisant suite à des recommandations réalisées via des audits qualifiés suivant le référentiel PASSI (Prestataires d’Audit de la Sécurité de Systèmes d’information [lien EN / lien FR]). L’entreprise doit également mettre en place une cellule de veille permettant de notifier l’ANSSI en cas de compromission du SI d’importance vitale.
• Le second point concerne la sécurisation des actifs du SOC : de nouvelles mesures de sécurisation décrites dans le référentiel de qualification PDIS imposent notamment un durcissement des postes des opérateurs et des administrateurs du SOC (authentification à deux facteurs, limitations des accès à internet…). Ces mesures de sécurité seront vérifiées par l’ANSSI via des audits ou rétroactivement suite à la notification de compromission du SI.
• L’architecture enfin, avec une complexification de celle-ci : un découpage en zones de confiance cloisonnées ainsi qu’un élargissement du périmètre du réseau surveillé sont imposés (outre les « classiques » équipements de sécurité, les serveurs métiers et les terminaux mobiles doivent maintenant aussi être surveillés). Les informations liées à un incident de sécurité (événements, rapports d’analyses et les notifications associées) doivent également être conservées pendant toute la durée de la prestation.

Sécurisation forte et respect des données personnelles : 2 enjeux incompatibles ?

Afin de pouvoir assurer des analyses a posteriori et notamment d’être capable de déterminer l’origine des cyberattaques, de nombreuses données personnelles et critiques doivent être collectées, conservées et exploitées. Pourtant, ces données sont soumises au GDPR qui tend à l’inverse à limiter leur collecte et leurs usages.

La récente amende de l’AGPD (l’autorité de protection des données à caractère personnel en Espagne) à Google met en lumière des problématiques que pourrait rencontrer le SOC concernant le traitement des données à caractère personnel :

• Le droit à la manipulation des données personnelles et le droit à l’oubli des utilisateurs a été la première cause de condamnation de Google. En effet, le GDPR compte offrir aux citoyens européens la possibilité d’accéder, de modifier ou de supprimer leurs données où qu’elles soient stockées (y compris dans le Cloud). Cela signifie, en pratique, que l’entreprise doit connaître exactement la teneur des données collectées par son SOC pour pouvoir en informer les clients, ses employés… Cela signifie également que ceux-ci devraient pouvoir exiger leur suppression à tout moment. Cependant, le GDPR semble indiquer qu’il est possible de conserver certaines données si celles-ci sont nécessaires à la protection des entreprises. Cette définition est appelée à être discutée dans les années à venir.
• L’obligation de transparence quant à l’exploitation des données est la seconde problématique soulevée par l’AGPD. Cependant, dans le cadre de PDIS, l’obligation de monitorer une grande variété d’équipements va engendrer la récupération d’un grand nombre de données de natures différentes. Un travail sur le contenu des logs collectés va donc être nécessaire afin de s’assurer que seules les données nécessaires à l’activité de surveillance sécurité sont récupérées.
• Enfin, le GDPR impose la justification de la conservation de la donnée. Or PDIS impose de conserver les données sur au moins six mois afin de pouvoir effectuer des analyses sur du long terme ou rétroactivement créant ainsi un flou législatif : jusqu’où peut-on aller pour assurer la protection de son SI ?

Au-delà du cas Espagnol, il est intéressant de noter les approches des différents textes sur la notification des incidents. Ceux dédiés à la protection des données à caractère personnel ciblent une notification rapide pour limiter les impacts sur la vie des citoyens, quand les textes sur la protection des infrastructures critiques eux imposent des notifications limitées et très confidentielles pour prendre le temps de gérer correctement l’incident sans révéler à l’attaquant le fait qu’il a été découvert. GDPR a finalement prévu ce cas de figure mais d’autres textes pourraient également être contradictoires.

Un cadre réglementaire strict mais bénéfique

Le durcissement du cadre réglementaire pour le SOC, que ce soit direct (PDIS) ou indirect (GDPR), va engendrer une transformation de l’écosystème. De nouveaux profils pourraient ainsi s’intégrer aux équipes comme le DPO (Data Privacy Officer) que le SOC pourrait considérer comme un acteur clé pour maintenir sa conformité dans la durée.

De plus, ces réglementations vont tirer vers le haut les niveaux de maturité des acteurs soumis à ces référentiels ainsi que de ceux s’en inspirant. D’ores et déjà on observe de nombreux chantiers de mise en conformité touchant tant à l’architecture du SOC qu’à ses processus et sa gouvernance.

Pour satisfaire aux réglementations, l’outillage compte également, et il faut jouer avec les innovations telle que la surveillance orientée sur les données (avec de l’outillage de type Data Leakage Prevention – DLP), qui peut aider à la mise en conformité sur la protection des données sensibles.

Vers des réglementations plus réalistes…

L’apport des référentiels est indéniable, en tant que standard et en tant que cible à atteindre pour nombre d’organisations.

Si la barre peut sembler haute, ou que l’on trouve encore quelques incohérences entre les différents textes, on peut gager que les prochaines révisions apporteront un cadre solide pour la conception et l’amélioration des SOC.

Cet article Le SOC, un service en pleine mutation réglementaire est apparu en premier sur RiskInsight.

À 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.

Beaucoup ont donc entamé au cours des 18 derniers mois un projet visant à exploiter les logs (ou journaux d’évènements) afin d’anticiper, détecter et diagnostiquer des actes malveillants.

L’objectif est ambitieux : on parle d’abord de log management, puis de corrélation des logs à l’aide d’un SIEM (security information and event management) . Quelle réalité derrière ces principes ? Comment les mettre en place ?

Étape 1 : centraliser les journaux

Une grande majorité de machines (équipements réseau, serveurs, postes de travail), bases de données ou applications d’un SI peuvent aujourd’hui générer des logs. Ces fichiers contiennent, pour chaque machine, la liste de tous évènements qui se sont déroulés : réussite ou échec d’une connexion utilisateur, redémarrage, saturation de la mémoire…

Pour les exploiter, il est possible de se connecter unitairement à chacun des équipements afin d’y observer l’historique. Cette tâche fastidieuse, encore souvent observée sur le terrain, est irréaliste sur des systèmes d’information complexes. Elle est par ailleurs inefficace pour prévenir un incident ou détecter les impacts en temps réel.

La construction d’un « puits de log » est une première brique de réponse : il s’agit de collecter, à l’aide d’un outil automatisé du marché, l’ensemble des journaux d’équipements dans un espace de stockage unique. L’un des critères de sélection de cet outil est justement sa capacité à reconnaître différents formats de logs (syslog, traps SNMP, formats propriétaires…).

Le volume d’information centralisée peut vite exploser : il est important d’éviter la collecte de données inutiles. Par ailleurs, le système peut également être gourmand en puissance de calcul en fonction des périmètres de recherches effectuées.

On parle de log management à partir du moment où les données contenues dans ce puits sont traitées et exploitées, par exemple pour retrouver un élément dangereux (virus, problème de sécurité…), ou un comportement malveillant (fuite d’information, suppression de données…). Il est nécessaire de cadrer en amont les finalités du projet,  qui peuvent être multiples :

• Vérifier que les règles du SI sont appliquées
• Détecter les attaques ou les utilisations frauduleuses du SI
• Permettre les analyses post-incidents (forensics)
• Répondre aux contraintes légales ou de conformité avec la capacité de fournir des éléments de preuve

Pour démarrer, une bonne pratique consiste à s’orienter principalement vers des logs de sécurité et réseau. Certaines applications métiers sensibles pourront ensuite être ajoutées.

Une fois l’espace de stockage cadré, l’archivage amène son lot de contraintes :

• D’un point de vue légal et réglementaire, il faut s’assurer de la licéité des traitements en fonction des informations archivées et de leurs durées de rétention. Une déclaration à la CNIL est à prévoir dans de nombreux cas.  En fonction de leur origine (e-mail, proxy, applications), les périodes de rétention ne sont pas soumises aux mêmes règles. À titre d’exemple, on considère aujourd’hui qu’une durée raisonnable pour l’historique des accès des utilisateurs à internet est de 12 mois.
• En fonction des traitements et du cadre juridique existant dans l’entreprise (par exemple charte incluant la surveillance…), les collaborateurs doivent potentiellement être informés des mesures mises en place. Dans ce cadre la mobilisation des ressources humaines et des instances représentatives du personnel sont à prévoir.
• La gestion des identités et des accès au puits de logs  est, enfin, un sujet crucial. Le volume et la sensibilité des informations qui y sont stockées nécessite d’identifier précisément les personnes habilitées à en faire usage, et de limiter strictement leurs droits au périmètre qui leur incombe. Toute modification des traces doit être interdite (même aux administrateurs),  afin que celles-ci puissent avoir une valeur probante le cas échéant.

Étape 2 : faciliter l’analyse, du SIEM au Big Data

Si des recherches manuelles sont toujours possibles dans un puits de logs, elles ne répondent qu’à un besoin précis et ponctuel.

Pour obtenir une analyse en temps réel avec des remontées d’alertes automatiques, il est nécessaire de passer à l’étape supérieure : le SIEM. Il s’agit à la fois d’une extension et d’une industrialisation de la première étape, souvent offerte par le même outil du marché.

Il s’agit ici de rechercher, à travers les traces, des liens entre des évènements unitaires ayant lieu sur différents éléments du SI, afin d’anticiper, bloquer (en temps réel) ou comprendre une action malveillante.  On parle alors de corrélation de logs.

Pour cela, il est important de définir les types de comportement anormaux à identifier. C’est la principale difficulté : un niveau de sensibilité trop élevé génèrera beaucoup d’alertes sans intérêt, tandis qu’un niveau trop faible ne permettra pas de lever les alertes pertinentes. Cette étape comporte donc une phase d’ajustement et apprentissage qui peut durer plusieurs mois.

Aujourd’hui le marché des SIEM se renouvelle : les solutions sont de plus en plus performantes, utilisent de nouvelles techniques de détection d’attaque, et exploitent de plus en plus la puissance de calcul du Cloud pour la corrélation d’évènements.

Le marché voit également arriver des outils utilisant les principes du Big Data. Plutôt que de rechercher des scénarios connus, l’idée est alors de détecter des anomalies statistiques dans la masse d’information. Cette approche séduisante doit encore être mise à l’épreuve du terrain.

 Ne pas négliger les aspects organisationnels

Enfin, il est nécessaire de s’assurer que les alertes seront traitées par les équipes compétentes. Les procédures et l’organisation associées doivent donc embarquer les équipes sécurité (SOC/CERT), réseau et système et le RSSI. Des réflexions autour de l’externalisation ou de l’internalisation de ces fonctions de surveillance et des liens avec les entités en charge de la gestion des incidents de sécurité sont également essentielles.

Cet article Surveillance sécurité : passer du puits de logs au SIEM (security information and event management) est apparu en premier sur RiskInsight.

Un apport des DLP complémentaire à la lutte contre l’intrusion et au contrôle d’accès

Une fuite d’information peut provenir de trois sources différentes. L’attaquant externe est souvent celui qui vient à l’esprit en premier. Cependant, l’expérience montre que ce sont les utilisateurs internes, autorisés ou non, qui font fuir le plus d’information.

Suivant la position de celui qui fait fuir l’information, trois grandes étapes peuvent être enchaînées : intrusion, accès à l’information, diffusion de l’information – dont la nécessité dépend des accès initiaux de l’acteur à l’origine de la fuite d’information. À chacune de ces étapes, des solutions de sécurité permettant de réduire le risque existent.

Il convient d’agir à toutes les étapes d’une fuite d’information en s’appuyant sur des mesures allant de la sécurité physique aux solutions de Digital Right Management (DRM), en passant par le chiffrement de flux, le cloisonnement, ou encore la gestion des accès et des habilitations…

Si de telles mesures sont déjà mises en œuvre, les outils de DLP permettent alors essentiellement de se prémunir contre des erreurs ou malveillances d’utilisateurs ayant un accès légitime à l’information. En ce sens, ils permettent d’apporter une protection au plus proche de la donnée.

Des solutions fonctionnellement matures

Les mécanismes de contrôle des DLP sont mis en œuvre à travers des règles ou politiques centralisées permettant d’analyser les traitements faits sur la donnée quelle que soit sa nature ou son support.

Grâce à des agents déployés sur le réseau et/ou sur les postes de travail, le DLP va pouvoir empêcher la copie d’un fichier sur un périphérique externe, l’envoi d’un document sensible par email, l’impression d’un document ou encore la publication d’une information confidentielle sur les réseaux sociaux.

Après analyse et filtrage des données par la solution DLP, différentes mesures de prévention peuvent être prises, avec un impact plus ou moins élevé pour l’utilisateur : alertes, demande de justification, blocage…

Enfin, il convient de noter que les acteurs du marché mettent de plus en plus l’accent sur le contexte d’utilisation de la donnée. Certains éditeurs proposent ainsi des fonctionnalités de gouvernance au sein de leur solution de DLP permettant par exemple de savoir exactement où se trouvent les données sensibles et qui y a accès.

Le marché des DLP est donc de plus en plus mature : la couverture fonctionnelle proposée est élevée et évolutive, la gestion de l’impact sur les collaborateurs de plus en plus souple. Néanmoins, les retours d’expérience restent limités par rapport à ce que l’on pourrait attendre.

La raison de ce paradoxe vient du fait que les métiers sont trop souvent insuffisamment impliqués dans les projets de DLP, alors même que ces projets n’ont que peu de chance d’aboutir sans eux, en particulier vu le volet RH nécessairement associé.

Adopter une approche par les résultats pour mobiliser les métiers

Il est illusoire de vouloir protéger toutes ses données dans tous les cas d’usage imaginables. Une approche purement technique visant un périmètre exhaustif n’a que peu de chance de convaincre, particulièrement dans la conjoncture économique actuelle.

Une approche par les résultats mêlant ciblage précis, démarche outillée, accompagnement et visibilité est donc à favoriser dès la sélection de la solution. Une fois les objectifs atteints sur un périmètre prioritaire, on peut envisager de l’élargir.

La première étape, primordiale, est donc la définition du périmètre prioritaire de données à protéger et des cas d’usage fonctionnels à traiter. Identifier les dix données les plus critiques, s’appuyer sur des situations fonctionnelles avérées, commencer par un nombre limités de supports pour réduire les aléas techniques sont autant de facteurs clés de succès.

La définition des processus de surveillance (politiques d’interaction avec les utilisateurs, processus en cas d’alerte…) ne doit également pas être négligée. Sur ce volet, et dès le début du projet, il est important de mobiliser les fonctions RH de l’entreprise pour valider le mode de mise en œuvre de la démarche DLP (alerte, blocage, journalisation…), construire les processus de gouvernance associés et au final envisager un passage devant les instances représentatives du personnel.

Lorsque le cadrage global du périmètre fonctionnel est effectivement achevé, la phase de sélection de la solution peut être entamée. Une démarche outillée impliquant la réalisation d’une maquette est indispensable pour s’assurer de l’adéquation de la solution aux cas d’usages fonctionnels identifiés et évaluer les résultats envisageables.

En cas de résultats satisfaisants, un déploiement progressif est à envisager avec un leitmotiv : la sensibilisation des utilisateurs.

Enfin, en mode récurrent, l’intégration à un SOC (Security Operation Center) peut permettre de bénéficier de la maturité de la gestion opérationnelle de la sécurité pour optimiser la surveillance d’une part et l’accompagnement et la visibilité fournis aux métiers d’autre part.

Cet article Le paradoxe des projets de Data Leak Prevention (DLP) : une problématique clé, des solutions matures… mais une mise en œuvre qui fait encore peur est apparu en premier sur RiskInsight.