Figure 1 : L’exemple d’une fuite de données personnelles dans ChatGPT (décembre 2023)

Des scandales de ce type révèlent une réalité plus profonde : l’architecture même des grands modèles de langage (LLMs ) comme ChatGPT-4  ou Gemini de Google est, par nature, sujette aux fuites de données. Ces fuites peuvent concerner des informations personnelles identifiables (PII) ou des données confidentielles d’entreprise.

Si les techniques employées par les attaquants continueront d’évoluer en réponse aux défenses renforcées des géants technologiques, les vecteurs sous-jacents, eux, restent inchangés.

Aujourd’hui, trois vecteurs principaux permettent aux PII (informations personnelles identifiables) ou aux données sensibles d’être exposées à ce type d’attaques :

• L’utilisation de contenus web accessibles au public dans les jeux de données d’entraînement
• Le réentraînement continu des modèles à partir des requêtes et conversations des utilisateurs
• L’introduction de fonctionnalités de mémoire persistante dans les chatbots

Fuites de données de pré-entraînement des LLM 

La plupart des modèles disponibles aujourd’hui sont fondés sur des architecturesfuite transformers, en particulier les GPT (Generative Pre-Trained Transformers). Le terme pré-entraîné dans GPT fait référence à la phase initiale d’entraînement, durant laquelle le modèle est exposé à un corpus massif et diversifié de données, sans lien direct avec son application finale. Cette étape permet au modèle d’apprendre des bases essentielles comme la grammaire, le vocabulaire et des faits généraux.

Lorsque les premiers GPT ont été lancés, les entreprises communiquaient de manière transparente sur la provenance des données d’entraînement. Mais aujourd’hui, les plus grands modèles disponibles sur le web s’appuient sur des jeux de données devenus trop vastes et trop variés, souvent gardés confidentiels.

Une source majeure des données utilisées pour le pré-entraînement des GPT provient des forums en ligne tels que Reddit (pour les modèles de Google), Stack Overflow, et d’autres plateformes sociales. Cela représente un risque important, car ces forums contiennent souvent des informations personnelles identifiables (PII). Bien que les entreprises affirment filtrer ces données sensibles durant l’entraînement, de nombreux exemples ont montré que les LLM peuvent malgré tout divulguer des données personnelles issues de leur corpus d’entraînement, notamment lorsqu’ils sont soumis à des techniques de prompt engineering* ou de jailbreaking* .  Ce risque ne fera que croître, à mesure que les entreprises accélèreront la collecte de données par web scraping pour entrainer des modèles toujours plus grands et plus sophistiqués.

Les fuites connues de ce type sont pour la plupart découvertes par des chercheurs, qui conçoivent des méthodes toujours plus créatives pour contourner les défenses des chatbots. L’exemple mentionné plus tôt en est une illustration: en demandant au chatbot de répéter indéfiniment un mot, celui-ci « oublie » sa tâche initiale et adopte un comportement connu sous le nom de mémorisation. Dans cet état, le chatbot régurgite des données issues de son ensemble d’entraînement. Bien que cette attaque ait été corrigée, de nouvelles techniques de prompt continuent d’émerger pour modifier le comportement des chatbots.

Réexploitation des saisies utilisateur pour le réentraînement

Le réentraînement à partir des saisies utilisateur est le processus qui consiste à améliorer en continu le LLM en l’entraînant sur les entrées fournies par les utilisateurs. Cela peut se faire de plusieurs manières. La plus répandue étant le RLHF (Reinforcement Learning from Human Feedback), ou apprentissage par renforcement à partir de retours humains.

Figure 2:  Le bouton de retour utilisé pour le RHLF 

Cette méthode repose sur la collecte de retours utilisateurs concernant les réponses générées par le LLM. De nombreux utilisateurs de LLM ont probablement vu les boutons « Pouce en haut » ou « Pouce en bas » dans ChatGPT ou d’autres plateformes de LLM. Ces boutons permettent de collecter les avis des utilisateurs qui seront utilisés pour réentraîner le modèle.  Si l’utilisateur indique que la réponse est positive, la plateforme prend le couple entrée utilisateur / sortie du modèle et encourage le modèle à reproduire ce comportement. De même, si l’utilisateur indique que la performance du modèle est insatisfaisante, ce couple entrée utilisateur / sortie du modèle sera utilisé pour décourager le modèle de reproduire ce comportement.

Cependant, le réentraînement continu peut également avoir lieu sans aucune interaction utilisateur. Les modèles peuvent parfois utiliser les entrées des utilisateurs et les sorties des modèles pour se réentraîner de manière aléatoire. Le manque de transparence de la part des fournisseurs et développeurs de modèles rend difficile la détermination exacte du processus. Toutefois, de nombreux utilisateurs sur internet ont rapporté que les modèles acquéraient de nouvelles connaissances à travers le réentraînement à partir des discussions d’autres utilisateurs, remontant jusqu’en 2022. Par exemple, le GPT 3.5 d’OpenAI ne devrait pas être capable de connaître des informations après septembre 2021 (date du contenu le plus récent utilisé pour son entrainement). Pourtant, en lui demandant des informations récentes, telles que la nouvelle position d’Elon Musk en tant que PDG de Twitter (maintenant X), vous obtiendrez une réponse différente.

Essentiellement, cela signifie pour les utilisateurs finaux que leurs discussions ne sont absolument pas confidentielles, et toute information donnée au LLM via des documents internes, des comptes rendus de réunions ou des lignes de code de développement  pourrait apparaître dans les discussions d’autres utilisateurs, entraînant ainsi des fuites. Cela pose des risques importants pour la confidentialité, non seulement pour les individus, mais aussi pour les entreprises. Un exemple notable s’est produit en avril 2023, lorsque Samsung a interdit l’utilisation de ChatGPT et d’autres chatbots similaires après qu’un groupe d’employés avait  utilisé l’outil pour ecrire des lignes de code et pour résumer des notes de réunion. Bien que Samsung ne dispose d’aucune preuve concrète que les données aient été utilisées par OpenAI, le risque a été jugé trop élevé pour permettre aux employés de continuer à utiliser l’outil. Il s’agit d’un exemple classique de Shadow AI*,  où l’utilisation non autorisée des outils d’IA pourrait entrainer une fuite d’informations confidentielles ou propriétaires. 

De nombreuses entreprises à l’échelle mondiale attendent des régulations plus strictes sur l’IA et les données avant d’utiliser les LLM à des fins commerciales. Certaines industries, comme le conseil, commencent à s’ouvrir, mais de manière encore très progressive.  D’autres entreprises, en revanche, renforcent  leur contrôle sur l’utilisation interne des LLM pour éviter les fuites de données confidentielles et d’informations sur leurs clients.

Mémoire persistante

Bien que les deux risques précédents soient connus  depuis quelques années, une nouvelle menace est apparue avec l’introduction d’une fonctionnalité par ChatGPT en septembre 2024. Cette fonctionnalité permet au modèle de conserver une mémoire à long terme des conversations utilisateurs. L’idée est de réduire la redondance en permettant au chatbot de se souvenir des préférences de l’utilisateur, du contexte et des interactions précédentes, améliorant ainsi la pertinence et la personnalisation des réponses.

Cependant, cette commodité comporte un risque de sécurité important. Contrairement aux failles précédentes, où les informations divulguées étaient plus ou moins aléatoires, la mémoire persistante introduit un ciblage du compte . Désormais, les attaquants pourraient potentiellement exploiter cette mémoire pour extraire des détails spécifiques de l’historique d’un utilisateur particulier, augmentant ainsi considérablement les risques.

Le chercheur en sécurité Johannes Rehberger a démontré comment cette vulnérabilité pourrait être exploitée via une technique appelée empoisonnement de contexte (context poisoning). Dans sa démonstration, il a créé un site avec une image malveillante contenant des instructions. Une fois que le chatbot ciblé consulte l’URL, sa mémoire persistante est « empoisonnée ». Le chatbot peut ainsi être manipulé et des informations sensibles de l’historique de conversation de la victime peuvent être extraites et transmises à une URL externe.

Cette attaque est particulièrement dangereuse car elle combine persistance et discrétion. Une fois implantée  dans le chatbot, elle reste active indéfiniment, exfiltrant continuellement les données de l’utilisateur jusqu’à ce que la mémoire soit nettoyée. En même temps, elle est suffisamment subtile pour passer inaperçue, nécessitant une analyse minutieuse  de la mémoire pour être détectée.

Confidentialité des données des LLM et stratégies de mitigation

Les développeurs de LLM rendent souvent difficile la désactivation du réentraînement, car cela profite au développement de leurs modèles. Si vos informations personnelles sont déjà publiques, elles ont probablement été récupérées par des processus de scraping et utilisées pour le pré-entraînement d’un LLM. De plus, si vous avez donné un document confidentiel à ChatGPT ou à un autre LLM dans votre prompt (sans avoir désactivé manuellement le réentraînement), il a potentiellement déjà été utilisé pour le réentraînement.

Actuellement, il n’existe pas de technique fiable permettant à un individu de demander la suppression de ses données une fois qu’elles ont été utilisées pour l’entraînement d’un modèle. Il existe un domaine de recherche émergent appelé Machine Unlearning qui tente de répondre à ce défi.  Ce domaine se concentre sur le développement de méthodes permettant de supprimer sélectivement l’influence de données spécifiques d’un modèle entraîné, effaçant ainsi ces données de la mémoire du modèle. Ce domaine évolue rapidement, notamment en réponse aux réglementations RGPD qui imposent le droit à l’effacement. Pour cette raison, il est important de minimiser ces risques à l’avenir en contrôlant les données que les individus et les organisations diffusent sur internet et les informations que les employés ajoutent dans leurs prompts.

Il est essentiel pour de nombreuses opérations commerciales que la confidentialité des données soit maintenue. Cependant, l’augmentation de la productivité que les LLM apportent au   travail des employés ne peut être ignorée. Pour cette raison, nous avons élaboré un cadre en trois étapes pour garantir que les organisations puissent exploiter la puissance des LLM sans perdre le contrôle de leurs données.

Choisir le modèle, l’environnement et la configuration les plus optimaux

Assurez-vous que l’environnement et le modèle que vous utilisez sont bien sécurisés. Vérifiez la période de rétention des données du modèle et la politique du fournisseur concernant le réentraînement sur les conversations des utilisateurs. Assurez-vous que l’option « Suppression automatique » est activée et que « Historique des discussions » est désactivé.

Chez Wavestone, nous avons développé un outil qui compare les 3 modèles propriétaires et open-source principaux en termes de tarification, période de rétention des données, garde-fous et confidentialité pour aider les organisations dans leur parcours en IA.

Sensibiliser les employés aux bonnes pratiques lors de l’utilisation des LLM

Assurez-vous que vos employés comprennent le danger de fournir des informations confidentielles  aux LLM et ce qu’ils peuvent faire pour minimiser l’ajout  d’informations confidentielles ou personnelles dans le corpus de données de pré-entraînement et de réentraînement du LLM.

Mettre en place une politique interne solide sur l’IA

Pour anticiper les challenges à venir, les entreprises devraient mettre en place une politique interne robuste sur l’IA qui spécifie :

• Quelles informations peuvent et ne peuvent pas être partagées avec les LLM en interne
• La surveillance du comportement de l’IA
• La limitation de leur présence en ligne
• L’anonymisation des données  
• Limiter l’utilisation aux outils d’IA sécurisés

En suivant ces étapes, les organisations peuvent minimiser les risques numériques auxquels elles sont confrontées en utilisant les derniers outils GenAI tout en bénéficiant des augmentations de productivité qu’ils apportent.

Perspectives… 

Les vulnérabilités en matière de confidentialité des données mentionnées dans cet article affectent des individus comme vous et moi. Leurs origines résident dans l’appétit insatiable des développeurs de LLM pour les données.  Cet appétit pour les données assure des produits finis de meilleure qualité, mais au prix de la confidentialité des données et de l’autonomie.
De nouvelles réglementations et technologies ont été mises en place pour lutter contre ce problème, comme le règlement européen sur l’IA (EU AI Act) et la liste des 10 meilleures pratiques LLM d’OWASP. Cependant, se fier uniquement à une gouvernance responsable ne suffit pas. Les individus et les organisations doivent activement reconnaître le rôle critique que jouent les informations personnellement identifiables dans le paysage numérique actuel et prendre des mesures proactives pour les protéger. Cela est d’autant plus important à mesure que nous avançons vers des systèmes d’IA plus agentiques, qui interagissent de manière autonome avec plusieurs services tiers. Ces systèmes traiteront non seulement une quantité croissante de données personnelles et sensibles, mais ces données seront également transmises et manipulées par de nombreux services différents, compliquant ainsi la surveillance et le contrôle. 

Références 

[1] D. Goodin, “OpenAI says mysterious chat histories resulted from account takeover,” Ars Technica, https://arstechnica.com/security/2024/01/ars-reader-reports-chatgpt-is-sending-him-conversations-from-unrelated-ai-users/ (accessed Jul. 13, 2024).  

[2] M. Nasr et al., “Extracting Training Data from ChatGPT,” not-just-memorization , Nov. 28, 2023. Available: https://not-just-memorization.github.io/extracting-training-data-from-chatgpt.html  

[3] “What Is Confidential Computing? Defined and Explained,” Fortinet. Available: https://www.fortinet.com/resources/cyberglossary/confidential-computing#:~:text=Confidential%20computing%20refers%20to%20cloud  

[4] S. Wilson, “OWASP Top 10 for Large Language Model Applications | OWASP Foundation,” owasp.org, Oct. 18, 2023. Available: https://owasp.org/www-project-top-10-for-large-language-model-applications/  

[5] “Explaining the Einstein Trust Layer,” Salesforce. Available: https://www.salesforce.com/news/stories/video/explaining-the-einstein-gpt-trust-layer/  

[6] “Hacker plants false memories in ChatGPT to steal user data in perpetuity” Ars Technica , 24 sept. 2024 Available: https://arstechnica.com/security/2024/09/false-memories-planted-in-chatgpt-give-hacker-persistent-exfiltration-channel/ 

[7] “Why we’re teaching LLMs to forget things” IBM, 07 Oct 2024 Available: https://research.ibm.com/blog/llm-unlearning 

Cet article Fuite de données : comment les chatbots d’IA peuvent faire fuiter vos informations est apparu en premier sur RiskInsight.

L’intelligence artificielle (IA) occupe désormais une place centrale dans les produits et services offerts par les entreprises et les services publics, en grande partie grâce à l’essor de l’IA générative. Pour soutenir cette croissance et favoriser l’adoption de l’IA, il a été nécessaire d’industrialiser la conception des systèmes d’IA en adaptant les méthodes et procédures de développement de modèles. 

C’est ainsi qu’est né le MLOps, une contraction de “Machine Learning” (le cœur des systèmes d’IA) et “Operations”. À l’instar du DevOps, le MLOps facilite la réussite des projets de Machine Learning tout en assurant la production de modèles performants. 

Cependant, il est crucial de garantir la sécurité des algorithmes pour qu’ils demeurent performants et fiables dans le temps. Pour ce faire, il est nécessaire de faire évoluer le MLOps vers le MLSecOps, en intégrant la sécurité dans les processus, à l’image du DevSecOps. Peu d’entités ont adopté et déployé un processus MLSecOps complet. Dans cet article, nous explorerons en détail la forme que pourrait prendre le MLSecOps. 

Le MLOps, les fondamentaux de développement de modèle d’IA 

Rapprochement avec le DevOps 

Le DevOps est une approche qui combine le développement logiciel (Dev) et les opérations informatiques (Ops). Son objectif est de raccourcir le cycle de vie du développement tout en assurant des livraisons continues de haute qualité. Les principes clés incluent l’automatisation des processus (développement, test et mise en production), la livraison continue (CI/CD) et des boucles de rétroaction rapides. 

MLOps, quant à lui, est une extension des principes DevOps appliqués spécifiquement aux projets de Machine Learning (ML). Les flux de travail sont simplifiés et automatisés au maximum, de la préparation des données d’entraînement à la gestion des modèles en production. Le MLOps se distingue du DevOps sur plusieurs points : 

• Importance des données et des modèles : Dans le Machine Learning, les données et les modèles sont cruciaux. Le MLOps va plus loin en automatisant toutes les étapes du Machine Learning, de la préparation des données aux phases d’entraînement. De plus, un volume de données plus important est souvent utilisé dans les projets de Machine Learning. 
• Nature expérimentale du développement : Le développement en Machine Learning est expérimental et implique de tester et d’ajuster continuellement les modèles pour trouver les meilleurs algorithmes, paramètres et données pertinentes pour l’apprentissage. Cela pose des défis pour l’adaptation du DevOps au Machine Learning, car le DevOps se concentre sur l’automatisation et la stabilité des processus. 
• Complexité des tests et de la recette : La nature évolutive des modèles et la complexité des données rendent les phases de test et de recette plus délicates en Machine Learning. De plus, la surveillance des performances est essentielle pour garantir le bon fonctionnement des modèles en production. Ainsi, en Machine Learning, il faut adapter les procédures de Maintenance en Conditions Opérationnelles pour maintenir la stabilité et la fiabilité des systèmes. 

En somme, une chaîne MLOps partage des éléments communs avec une chaîne DevOps, mais introduit des étapes supplémentaires et accorde une importance particulière à la gestion et à l’utilisation des données. Le graphique suivant souligne en jaune toutes les étapes supplémentaires que le MLOps introduit : 

• Accès et utilisation des données : Cette étape inclut toutes les phases du Data Engineering (collecte, transformation et versionnement des données utilisées pour l’entraînement). L’enjeu est d’assurer l’intégrité des données et la reproductibilité des tests. 
• Recette du modèle : Les recettes et les tests d’intégration en ML sont plus complexes et se déroulent sur trois couches différentes : la pipeline des données, la pipeline du modèle de ML et la pipeline applicative. 
• Monitoring en production : Il s’agit de garantir la performance du modèle dans le temps et d’éviter le “model drifting” (déclin de la performance dans le temps). Pour cela, toutes les déviations (changement instantané, changement graduel, changement récurrent) doivent être détectées, analysées et corrigées si nécessaire. 

 Figure 1 – Adaptation des étapes du DevOps au Machine Learning 

Mettre en place le MLOps nécessite de créer un dialogue entre ingénieur des données et les opérateurs de DevOps 

Le passage au MLOps implique de créer de nouvelles étapes organisationnelles spécifiquement adaptée à la gestion des données. Cela inclut notamment la collecte et la transformation des données d’entrainement, ainsi que les processus de suivi des différentes versions de données.  

En ce sens, la collaboration entre les experts en MLOps, Data Scientists et les Data Engineers est essentielle pour réussir dans ce domaine en constante évolution. L’enjeu principal d’une mise en place d’une chaine MLOps réside donc dans l’intégration des Data Engineers dans les processus DevOps. Ces derniers sont responsables de préparer les données dont les ingénieurs MLOps ont besoin pour entraîner et exécuter des modèles.  

Et la sécurité dans tout ça ? 

L’adoption massive des IA génératives en 2024 nous a fourni une variété d’exemples de compromissions de terme de sécurité. En effet, la surface d’attaque est grande : un acteur malveillant peut à la fois attaquer le modèle en lui-même (vol de modèle, reconstruction de modèle, détournement de l’usage initial) mais également attaquer ses données (extraire des données d’entraînement, modifier le comportement en ajoutant des fausses données, etc.). Pour illustrer ces derniers, nous avons simulé deux attaques réalistes dans de précédents articles : Attaquer une IA ? Un exemple concret ! ou Quand les mots deviennent des armes : prompt injection. 

En parallèle, le MLOps, introduit une automatisation qui accélère la mise en production. Bien que cela puisse réduire le time to market (délais de mise sur le marché), cela augmente également les risques (attaque par supply chain, massification). Il est donc crucial de s’assurer que les risques liés à la cybersécurité et à l’IA sont correctement gérés. 

Comme le fait le DevSecOps pour le DevOps, la chaine de production du MLOps doit être sécurisée. Voici un panorama des principaux risques sur la chaine MLOps : 

Adopter le MLSECOPS 

Intégrer la sécurité dans les équipes MLOPS et renforcer la culture sécurité 

Les principes du MLSecOps doivent être compris par les Data Scientists et les Data Engineers. Pour cela, il est crucial que les équipes de sécurité soient intégrées dès le début du projet. Cela peut se faire de deux manières : 

• Lors de la création d’un nouveau projet, un membre de l’équipe de sécurité est assigné en tant que responsable de la sécurité. Il supervise les avancées et répond aux questions des équipes du projet. 
• Une approche plus agile, similaire au DevSecOps, consiste à désigner un membre de l’équipe comme “Security Champion”. Ce référent cybersécurité au sein de l’équipe projet devient l’interlocuteur privilégié des équipes cyber. Cette méthode permet une intégration plus réaliste de la sécurité dans le projet, mais nécessite une formation adéquate pour le Security Champion. 

Pour que ce changement soit efficace, il est également nécessaire de modifier la perception de la cybersécurité par les équipes projets : 

• En fournissant une formation de base aux équipes pour mieux comprendre les enjeux de la cybersécurité. 
• En intégrant la cybersécurité dans les plateformes de collaboration et de connaissances. 
• En organisant régulièrement des campagnes de sensibilisation. 

Sécuriser les outils de la chaîne MLOPS 

Pour garantir la sécurité des produits, il est essentiel de sécuriser la chaîne de production. Dans le cadre du MLOps, cela signifie s’assurer que tous les outils sont correctement utilisés avec des pratiques intégrant la cybersécurité, qu’il s’agisse du traitement et de la gestion des données (comme MongoDB, SQL, etc.), des outils de surveillance (tel que Prometheus), ou des outils de développement plus ou moins spécifiques (comme MLFlow ou GitHub). 

Par exemple, il est crucial que les équipes restent vigilantes sur des thématiques telles que l’identification et la gestion des identités, la continuité d’activité, la surveillance, et la gestion des données. Les possibilités offertes par les différents outils utilisés tout au long du cycle de vie, ainsi que leurs spécificités, doivent être examinées en lien avec ces enjeux. Idéalement, les caractéristiques de cybersécurité devraient servir de critères de sélection pour choisir l’outil le plus adapté. 

Définir des pratiques en matière de sécurité de l’IA 

Au-delà de la sécurité des outils qui permettent de construire les systèmes d’IA, il convient d’intégrer des mesures de sécurité permettant de prévenir les vulnérabilités spécifiques aux systèmes d’IA. Ces mesures doivent être incorporées dès la conception et tout au long du cycle de vie de l’application, suivant une approche MLSecOps. De la collecte des données à la surveillance du système, il existe de nombreuses mesures de sécurité à intégrer : 

Figure 2 – Les mesures de sécurité applicables tout au long du cycle de vie 

Trois mesures de sécurité à implémenter dans vos processus MLSecOps 

Selon la stratégie de sécurité adoptée, diverses mesures de sécurité peuvent être intégrées tout au long du cycle de vie du MLOps. Nous avons détaillé les principaux mécanismes de défenses pour sécuriser l’IA dans l’article suivant : Sécuriser l’IA : Les Nouveaux Enjeux de Cybersécurité.  

Dans cette partie, nous allons nous attarder sur 3 mesures spécifiques qui peuvent être mises en œuvre pour renforcer la sécurité du MLOps : 

 Figure 3 – Mesures de sécurité sélectionnées 

Contrôler la pertinence des données et les risques d’empoisonnement 

Dans le cadre du Machine Learning, la sécurité des données est primordiale pour prévenir les risques d’empoisonnement et garantir l’intégrité des données traitées.  

Avant de procéder au traitement des données collectées, un contrôle continu de l’origine des données est essentiel afin d’en garantir leur qualité et leur pertinence. Cela est d’autant plus complexe lors de l’utilisation de flux de données externes, dont la provenance et la véracité peut parfois être incertain. Ainsi, le risque majeur réside dans l’intégration de données utilisateurs lors d’un apprentissage en continu. Cela peut conduire à des résultats imprévisibles, comme illustré par l’exemple du ChatBot TAY de Microsoft en 2016. Ce dernier, était conçu pour apprendre à travers les interactions utilisateurs. Cependant, sans une modération adéquate, il a rapidement adopté des comportements inappropriés, reflétant les entrées négatives reçues. Cet incident souligne l’importance d’une surveillance et d’une modération constantes des données d’entrée, en particulier lorsqu’elles proviennent d’interactions humaines en temps réel. 

Diverses techniques d’analyse peuvent être utilisées pour nettoyer un ensemble de données. L’objectif étant de vérifier l’intégrité des données et de supprimer toute données pouvant avoir un impact négatif sur les performances du modèle. Deux méthodes principales sont possibles :  

• D’une part, nous pouvons vérifier individuellement l’intégrité de chacune des données par contrôle des valeurs aberrantes, validation du format ou de métriques caractéristiques… 
• D’autre part, avec une analyse globale, des approches comme la validation croisée et le clustering statistique sont efficaces pour identifier et éliminer les éléments inappropriés de l’ensemble de données. 

Introduire des exemples contradictoires 

Les exemples contradictoires sont des entrées corrompues, modifiées pour induire en erreur les prédictions d’un algorithme de Machine Learning. Ces modifications sont construites pour être indétectables à l’œil humain mais suffisantes pour tromper l’algorithme. Ce type d’attaque exploite les vulnérabilités ou failles présentes dans l’entrainement du modèle pour provoquer des erreurs de prédiction. Pour les réduire, il est alors possible d’apprendre au modèle à identifier et ignorer ce type d’entrée. 

Pour cela, nous pouvons délibérément ajouter des exemples contradictoires aux données d’entraînements. L’objectif est de présenter au modèle des données légèrement altérées, afin de le préparer à identifier et gérer correctement les erreurs potentielles. La création de ce type de données dégradée est complexe. La génération de ces exemples contradictoires, devra être adapté au problème et aux menaces identifiées. Il est crucial de surveiller attentivement la phase d’entraînement afin de s’assurer que le modèle reconnaît efficacement ces entrées incorrectes et sache réagir correctement.  

Modifier les entrées utilisateurs 

La sécurisation des entrées est essentielle pour minimiser les risques liés aux manipulations malveillantes. Une faiblesse importante des LLM (Large Language Models) est leur manque de compréhension contextuelle approfondie et leur sensibilité à la formulation précise des prompts. Une des techniques les plus connue pour exploiter cette vulnérabilité est l’attaque par prompt injection. Il est donc nécessaire d’introduire une étape intermédiaire de transformation des données utilisateur avant leur traitement par le modèle. 

Il est possible de modifier légèrement l’entrée afin de contrer ce type d’attaque, tout en préservant la précision du modèle. Cette transformation peut se faire via diverses techniques (e.g. codage, ajout de bruit, reformulation, compression des caractéristiques, etc.). L’objectif est de conserver uniquement ce qui est essentiel à la réponse. Ainsi, toute information superflue potentiellement malicieuse est écartée. De plus, cette méthode prive l’attaquant de la possibilité d’accéder à la véritable entrée du système. Ce qui empêche toute analyse approfondie des relations entre entrées et sorties et complique ainsi la conception de futures attaques. Il reste toutefois essentiel de tester les différentes mesures implémentées, pour s’assurer qu’elles ne dégradent pas les performances du modèle, garantissant ainsi une sécurité renforcée sans compromettre l’efficacité. 

Avec l’industrialisation de la production d’applications basées sur le Machine Learning et l’IA, la sécurité à grande échelle devient une question organisationnelle cruciale pour le marché. Il est impératif d’entreprendre une transition vers le MLSecOps. Cette transformation repose sur trois piliers principaux : 

• Renforcer la culture de sécurité des équipes de Data Scientists : Il est essentiel que les Data Scientists comprennent et intègrent les principes de sécurité dans leur travail quotidien. Cela permet de créer une culture de sécurité partagée et de renforcer la collaboration entre les différents acteurs. 
• Sécuriser les outils qui produisent les algorithmes de Machine Learning : Il est essentiel de sélectionner des outils de MLOps sécurisés et d’appliquer des bonnes pratiques au sein de outils (gestion des droits, etc.) pour sécuriser « l’usine » à algorithmes de Machine Learning et ainsi réduire la surface de compromission. 
• Intégrer des mesures de sécurité spécifiques à l’IA : Adapter les mesures de sécurité aux particularités des systèmes d’IA est crucial pour prévenir les attaques potentielles et assurer la fiabilité des modèles dans le temps. Il convient donc d’intégrer ces mesures de sécurité dans la chaîne de MLOps à l’aide du MLSecOps. 

Engagez-vous dès aujourd’hui dans la transition vers le MLSecOps. Formez vos équipes, sécurisez vos outils et intégrez des mesures de sécurité spécifiques à l’IA. A ce titre, vous pourrez bénéficier de systèmes d’IA produits industriellement et sécurisés by design.  

Remerciements à Louis FAY et Hortense SOULIER qui ont également contribué à la rédaction de cet article. 

Cet article Adopter le MLSecOps : la clé pour des modèles d’IA fiables et sécurisés  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.

Nous ouvrons désormais les contributions à ce blog aux start-ups accélérées par notre dispositif Shake’Up. Hazy est un générateur de données synthétiques, combinant confidentialité différentielle, et intégrité référentielle, proposant un support de base de données multi-tableaux et avec un déploiement possible sur des systèmes critiques.

Qu’ont en commun les organisations tenant le choc de la crise sanitaire ? Des plans d’urgence particulièrement efficaces.

Pour ces quelques cas de réussite, cette planification a commencé par la prise en compte de l’aspect RH. PDG et directeur technique, en totale collaboration, se sont demandé : et si un de nos employés tombait malade, qui serait le suivant ? Que se passerait-il si plusieurs acteurs clés de l’entreprise étaient hospitalisés en même temps ? Ces entreprises ont créé une base comprenant l’ensemble des fournisseurs d’accès à Internet et les régions associées, ils l’ont communiquée à tous les ingénieurs d’astreinte et ont créé une chaîne de remplacement en cas de panne. Ces organisations ont veillé à ce que non seulement leurs systèmes internes et ceux destinés aux clients soient sauvegardés, mais aussi ceux de leur chaîne logistique.

Mais certains diraient que tout cela est une réaction, et non une planification, ou simplement de la chance. Après tout, chaque organisation et chaque industrie a ses propres obstacles à surmonter. Comment une entreprise pourrait-elle vraiment se préparer à l’inconnu ?

Comment une organisation pourrait-elle se préparer à une pandémie mondiale s’il n’y en a pas eu de cette ampleur depuis une centaine d’années ?

C’est là que les données synthétiques offrent une opportunité intéressante d’espérer le meilleur, mais de se préparer au pire. Les données synthétiques – qui sont des données très précises mais anonymes, et totalement artificielles – peuvent permettre à toute organisation de simuler des événements imprévus comme des pandémies et des catastrophes naturelles.

Les données synthétiques peuvent permettre de définir des plans d’urgence, même pour les plus grands imprévus.

Qu’est-ce que les données synthétiques et comment sont-elles utilisées ?

Comme leur nom l’indique, les données synthétiques sont totalement artificielles. Dans le cas de Hazy, les données synthétiques sont générées par des algorithmes de Machine Learning de pointe, qui offrent certaines garanties mathématiques d’utilité et de confidentialité. Cela est essentiel car aucune donnée sur les clients n’est réellement utilisée, alors que les courbes ou les modèles de leurs profils et comportements collectifs sont préservés.

C’est incroyablement utile pour faire tomber les barrières à l’innovation et aux essais. Cela permet d’obtenir toutes les informations nécessaires sur ses clients, leurs caractéristiques démographiques et leurs habitudes tout en réduisant considérablement le risque de réidentification. Il est ensuite possible de transférer facilement et en toute sécurité ces données synthétiques et ces informations entre différentes divisions, agences gouvernementales, entreprises et zones géographiques, avec la possibilité d’évaluer rapidement des partenaires tiers.

Comme les données synthétiques conservent à la fois leur valeur et leur conformité, leur potentiel est presque illimité. Elles peuvent être appliquées à la résolution de certains des plus grands problèmes du monde, de l’intensification de la recherche et du traçage des pandémies internationales à un accès plus équitable aux services bancaires, en passant par la détection de la fraude et du blanchiment d’argent à une échelle transfrontalière et inter-organisationnelle. Elle peut être utilisée pour faire tomber les frontières et optimiser la collaboration intergouvernementale, jusqu’à présent entravée par des bases de données divergentes coincées derrière des murs réglementaires.

Les données synthétiques permettent aux organisations et aux gouvernements de surmonter les barrières géographiques et les obstacles liés aux ressources.

Ces données synthétiques peuvent même être appliquées à des événements qui n’ont pas encore eu lieu.

Les principales organisations mondiales commencent à exploiter les données synthétiques pour élaborer des scénarios prédictifs afin de mieux répondre aux futures crises économiques, sanitaires, politiques et environnementales.

Il convient de noter que les données synthétiques ne sont pas aussi avancées et courantes que les autres outils d’entreprise. Comme chaque organisation possède des ensembles de données très complexes et variés, il faut les transformer, les pré-traiter et les configurer pour les rendre accessibles aux modèles de Machine Learning. Cela signifie que si n’importe qui dans une organisation peut bénéficier de données synthétiques, les data scientists doivent néanmoins être impliqués dans la préparation de ces données.

Des données synthétiques pour simuler des événements imprévus

Les données synthétiques sont créées par des modèles de Machine Learning qui, d’une certaine manière, peuvent être considérées comme des simulateurs du monde.

Les données synthétiques de Hazy sont déjà utilisées dans les grandes institutions financières pour permettre aux développeurs d’applications de simuler des modèles de comportement réalistes de clients avant même que l’application n’ait d’utilisateurs. Ce sont les ingénieurs en Machine Learning qui peuvent le mieux modéliser ce genre de scénarios de la demande future.

Nos clients les plus innovants commencent à étendre les cas d’utilisation de cette technologie d’avant-garde à des événements pour la plupart imprévisibles.

Cette possibilité n’a été rendue possible qu’assez récemment grâce à la génération de données synthétiques conditionnelles, qui permet d’explorer comment certaines relations dans un ensemble de données peuvent jouer avec d’autres relations lorsque leurs effets sont amplifiés ou diminués.

En ce moment, cela est d’une importance majeure, notamment lorsqu’on évoque le sujet des deepfakes. Quelqu’un pourrait demander à un générateur conditionnel de trouver des visages qui ont des cheveux roses, des lunettes et un piercing au nez. Maintenant, le générateur n’a peut-être jamais vu quelqu’un avec toutes ces caractéristiques combinées, mais il sait approximativement comment chacune de ces entités se combine logiquement à un niveau supérieur. Le modèle de Machine Learning a appris comment les entités de niveau inférieur se combinent pour construire des méta-entités – par exemple, il sait qu’un nez a une relation assez prévisible avec les yeux et la bouche. Cela permet au générateur de prendre ce qu’il sait et de combler avec précision les lacunes et de prédire à quoi ressembleraient ces punks rockers.

Cela fonctionne un peu différemment avec les données clients comme les données financières séquentielles, car ces tableaux comprennent souvent des milliers de colonnes et ont beaucoup de valeurs catégorielles – chaque colonne peut être considérée comme une dimension. Il est souvent plus difficile de déterminer comment les valeurs catégorielles d’un tableau s’imbriquent dans un ensemble de données que de travailler avec un ensemble de données composé des dimensions en pixels d’un ensemble de données de visages humains.

Le point positif est que les banques ont incontestablement beaucoup de données avec lesquelles travailler. Elles ont également souvent accès à des ensembles de données supplémentaires, comme les mesures des actions, les taux d’intérêt et les taux de change. Les interrelations entre les différents ensembles de données peuvent potentiellement être combinées pour mieux modéliser les relations et explorer des scénarios et des compromis. Grâce à ces modèles de Machine Learning, il est possible d’étudier le comportement d’un produit financier lorsque vous avez une combinaison de taux d’intérêt élevés et de faible chômage.

Bien que certains événements n’ont peut-être jamais eu lieu dans la vie réelle, les générateurs peuvent être utilisés pour extrapoler et remplir les blancs, puisqu’ils savent généralement comment certains événements évoluent ensemble.

Les compagnies d’assurance vivent dans le monde du « si cela, alors ceci », mais une grande partie de leurs prévisions actuarielles sont basées sur des données passées. Que pouvez-vous faire si vous n’avez pas de données parce que ces événements ne se sont pas encore produits ? Les données synthétiques sont un bon moyen de construire des scénarios prédictifs qui peuvent aider les organisations à évaluer correctement le risque d’événements imprévus.

Et cette boule de cristal ne doit pas seulement être appliquée aux événements qui changent le monde. Vous pouvez utiliser des générateurs de données synthétiques pour comprendre comment un nouveau marché réagirait à votre lancement d’un nouveau produit.

Supposons que vous ayez un million de clients au Royaume-Uni et seulement 50 000 en France. Et vous connaissez la variabilité des revenus, les zones géographiques dans lesquelles ils vivent, ainsi que l’âge, le revenu et le niveau d’éducation de chaque client. Vous créez d’abord des données synthétiques qui protègent toutes les informations personnelles identifiables dans deux régions géographiques distinctes. Le modèle apprend ensuite à la fois la manière prévisible dont le produit s’est vendu au Royaume-Uni et il connaît les différences de comportement entre les deux pays. Ce modèle peut même apprendre à extrapoler intelligemment le comportement des consommateurs britanniques au comportement des consommateurs français afin de prédire la meilleure façon dont une expansion sur le marché français pourrait se dérouler. Ces aperçus disparates se transforment en un solide prédicteur pour atteindre des objectifs d’expansion internationale.

Ces résultats peuvent à nouveau être combinés avec d’autres probabilités, comme la façon dont les clients ou les marchés locaux réagiront en fonction du nombre de points de chute de la bourse ou de l’impact des températures estivales sur les ventes. Toutefois, si l’on souhaite prédire des événements très rares ou une combinaison d’événements rares avec des données limitées, faire des prédictions reste très difficile sans disposer de suffisamment de données pour extrapoler de manière significative les tendances et les relations dans les données.

Le potentiel illimité des données synthétiques sécurisées

Les données synthétiques sont le meilleur moyen de débloquer en toute sécurité le potentiel de l’économie des données. Parce que les données synthétiques – en étant complètement artificielles – peuvent résoudre le problème essentiel de la vie privée, elles peuvent réduire considérablement les fuites de données et protéger les informations personnelles de vos clients, tout en conservant leur utilité.

Les données synthétiques deviennent le meilleur moyen pour les organisations multinationales de rester aussi compétitives, réactives et innovantes que les start-ups, car elles permettent de planifier l’avenir et ses capacités, en se basant sur l’inconnu.

Parce que les grandes institutions financières disposent d’une telle richesse de données, elles sont parfaitement positionnées pour tirer parti du potentiel unique des données et donc des données synthétiques. Les organisations peuvent désormais limiter la prise de risques en prévoyant des réponses pour un avenir imprévisible.

Le monde change rapidement. Votre entreprise doit être prête à y faire face.

Cet article Hazy | Shake’Up – Comment des données synthétiques auraient pu nous permettre de nous préparer à cette pandémie ? est apparu en premier sur RiskInsight.

Je suis en mesure d’envoyer toutes mes données à un algorithme de Machine Learning, va-t-il m’en sortir de la valeur ?

Non, absolument pas. #GarbageInGarbageOut

C’est même la meilleure manière d’être déçu par le Machine Learning ! Ce n’est pas un outil magique : si n’importe quoi lui est donné en entrée, il n’en sortira pas magiquement des résultats pertinents.

Il est non seulement nécessaire de définir précisément son cas d’usage avant de se lancer, mais également de choisir intelligemment les données qui vont nourrir le modèle.

Justement, quel cas d’usage choisir ?

Le problème est pris à l’envers !

La question est plutôt de savoir si :

• Aujourd’hui, des cas d’usages vous posent problème (e.g. chronophages parce que les alertes levées nécessitent beaucoup de retraitement et finalement remontent beaucoup de faux positifs).
• Le Machine Learning pourrait permettre d’apporter des solutions à certains d’entre eux (e.g. levée d’alerte sur un comportement « normal » plutôt que sur des seuils de détection fixes complexes à configurer et maintenir à jour).
• Et les solutions classiques pour y répondre semblent arrivées à la limite de leurs capacités. #JeNeRéinventePasLaRoue

En cybersécurité, devant un problème complexe à décrire explicitement (e.g. qu’est-ce qu’une communication suspecte ?) qui en plus a de fortes chances d’évoluer dans le temps (e.g. les seuils de détections sont constamment à ajuster), il est très difficile de trouver le bon compromis entre détection des cas suspects et faux positifs avec des règles statiques. Dans ce genre de situation il est intéressant d’explorer la piste du Machine Learning.

Qui mène le projet : l’équipe cyber ou l’équipe data ?

Les deux et avec de nombreux échanges ! #OneTeam

Ces deux équipes ont des expertises différentes, technique pour les data scientists, métier pour l’équipe cybersécurité. L’une sans l’autre ne permet pas de conduire un projet de Machine Learning pour la cybersécurité correctement.

Sans data scientists, l’équipe cybersécurité risque par exemple de :

• Se lancer en ayant trop peu de données (e.g. le volume de données ne permet pas à l’algorithme de définir une norme de comportement, il interprète donc des situations normales comme anormales).
• Ne pas penser à combiner certaines données (e.g. chaque première connexion d’un utilisateur à une nouvelle application remonte en anomalie parce qu’on ne lui a pas ajouté de variable lui permettant de comparer ce comportement à celui de la masse des utilisateurs (qui utilisent déjà l’application)).
• Ne pas savoir interpréter les alertes remontées par l’algorithme, et a fortiori ne pouvoir l’optimiser (e.g. l’algorithme remonte des anomalies qui n’en sont pas, l’équipe cybersécurité ne comprend pas sur quoi il base son analyse et ne sait donc pas les réorienter).

Et sans l’équipe cybersécurité, les data scientists risquent de :

• Ne pas pouvoir évaluer si l’algorithme remonte des anomalies pertinentes (e.g. l’algorithme remonte un log en anomalie mais les data scientists ne peuvent pas évaluer s’il s’agit d’un vrai problème de cybersécurité ou non).
• Ne pas pouvoir sélectionner finement les données à communiquer à l’algorithme (e.g. la cybersécurité a donné les logs de ses proxys aux data scientists mais n’a pas trié les champs les plus pertinents pour le cas d’usage : les résultats de l’algorithme sont confus).
• Passer à côté d’éléments cruciaux à intégrer dans le calcul de l’algorithme pour répondre au besoin métier (e.g. voulant optimiser un algorithme, un champ nécessaire à la catégorisation d’une anomalie de cybersécurité est supprimé du jeu de données, les résultats de l’algorithme perdent toute leur valeur cybersécurité).

Combiner les expertises de ces deux équipes est clé pour garantir que les ressources du Machine Learning seront utilisées efficacement pour apporter une réponse à haute valeur ajoutée pour la cybersécurité.

Quels sont les prérequis ?

Les données !

Sans données, fin de l’histoire avant même qu’elle n’ait commencée.

Pour rappel, le Machine Learning est l’ensemble des techniques permettant aux machines d’apprendre, sans avoir été explicitement programmées pour. Et pour cela, nos algorithmes apprennent en se nourrissant de données que nous allons pouvoir leur fournir.

• Il les leur faudra en quantité pour qu’ils puissent tirer une « norme » la plus affutée possible, car définie et confrontée à des volumes importants de cas réels. A noter que « quantité » ne veut pas forcément dire « diversité » : il est important de sélectionner uniquement les données pertinentes pour le cas d’usage.
• Il les leur faudra également en qualité pour ne pas tromper l’apprentissage de l’algorithme, n’introduisant pas de biais par exemple.

Il sera donc nécessaire d’identifier les types de données intéressantes à analyser (e.g. logs de sécurité), les sources où elles seront collectées (e.g. proxy web) et les ressources qui permettront de les enrichir (e.g. CMDB pour faire le lien entre IP et nom de machine), si nécessaire.

J’ai peu de données disponibles pour mon cas d’usage, le Machine Learning n’est donc pas pour moi ?

Pas forcément !

Si les données disponibles sont particulièrement pertinentes pour le cas d’usage à adresser et bien réparties (e.g. représentatives d’une situation habituelle sur une période de temps pour qu’un algorithme non supervisé puisse apprendre la situation « normale ») il est possible d’avoir des résultats intéressants.

A titre indicatif, avec un cas d’usage est bien défini (e.g. cible d’une population d’utilisateurs spécifique) et des logs adéquats collectés, des comportements suspects peuvent être détectés dans des logs proxy avec seulement deux semaines de trafic (suivant la verbosité des logs, cela ne représente que quelques centaines de Go).

Quel algorithme j’utilise ?

En fait, « peu importe » !

L’élément déterminant qui permettra de répondre de manière plus ou moins adaptée à un cas d’usage est plutôt le type d’apprentissage : supervisé ou non.

Le choix d’un algorithme non supervisé plutôt qu’un autre a ensuite peu d’importance : il existe plusieurs algorithmes adaptés à un même cas d’usage, dont la performance dépendra plutôt du contexte (e.g. besoin d’interpréter les résultats, volume de données d’entrainement…).

Les data scientists orientent le choix sur la base de leur veille, pour proposer des algorithmes plus reconnus pour être performants sur un cas d’usage et dans un contexte défini.

Je fais moi-même ou je sous-traite ?

Ça dépend, et ça peut évoluer dans le temps !

Notre premier article détaille un exemple d’implémentation : le développement avec ses propres outils, en partant de zéro. Mais dans les faits, trois possibilités d’implémentations sont possibles. Le choix dépend des cas d’usages envisagés, des ressources disponibles et de ses ambitions.

Chacun de ses scénarios présente ses avantages et ses contraintes, et il est possible de les utiliser de concert. Par ailleurs, il est essentiel de resonder régulièrement le marché afin d’étudier si de nouvelles solutions innovantes et plus performantes ne sont pas apparues depuis le déploiement de la solution initiale.

#TakeAStepBack

Est-ce facile à tester ?

Si le cadrage est bien fait, oui ! #Test&Learn

Une fois le cas d’usage sélectionné, la disponibilité des données vérifiée et le choix d’une implémentation en fonction de son contexte faite, il est plutôt simple de réaliser un test de l’apport du Machine Learning avant d’investir davantage.

Ce type de projet se prête très bien à des démarches itératives ou par sprints. Cela permet d’éprouver rapidement les solutions retenues et d’en démontrer la pertinence par la valeur apportée, ou au contraire mettre en évidence que pour ce cas d’usage les résultats ne sont pas suffisamment satisfaisants pour poursuivre.

Dans tous les cas, une démarche par PoC à la suite d’une étude d’opportunité permet de se faire rapidement une idée. Cette étape, avant de se lancer à grande échelle permet également de prendre de la hauteur pour évaluer les gains potentiels (e.g. gains de temps car moins de faux positifs à traiter, meilleure réactivité globale car les alertes levées sont plus pertinentes) par rapport aux investissements à réaliser (e.g. infrastructures de calcul spécifiques, compétences à recruter) avant de se lancer.

Une fois que j’ai fait mon PoC comment je passe à l’échelle ?

Encore une fois, pas à pas !

Une fois les premiers résultats concluants obtenus sur un cas d’usage, il est possible d’envisager son passage en production. Attention toutefois à ne pas aller trop vite : le passage en production amène de nouvelles questions auxquelles il est nécessaire de répondre avant de poursuivre, par exemple :

• Quels volumes de données seront à analyser ? Quelles opérations de pre-processing (préparation des données) seront à réaliser ? A quelle fréquence ? (Temps réel, différé…)
• A quelle fréquence l’algorithme devra-t-il refaire son apprentissage ? Sur quels volumes de données ?
• Quelles infrastructures seront donc nécessaires ?
• Quelles compétences et ressources permettront de maintenir la solution dans le temps ?

Il sera alors le moment de prendre un pas de recul et de faire des choix opérationnels, en ayant en tête une vision long terme.

Combien ça coûte ?

Tout dépend du stade de réflexion et de ses ambitions.

Pour un PoC, un cadrage permet de limiter l’investissement tant que l’apport du Machine Learning n’est pas démontré (e.g. activation d’une option sur un outil de sécurité le temps de tester, pas d’investissement en infrastructures).

Une fois la valeur ajoutée démontrée, se pose la question des coûts à engager pour la mise en production et le maintien dans le temps. Plusieurs éléments sont à considérer pour évaluer l’investissement total qui sera nécessaire :

• Investissements matériels (e.g. boîtiers pour les solutions du marché, infrastructures et ressources pour gagner en puissance de calcul pour les développements internes) et logiciels (licences, activation des fonctionnalités Machine Learning sur les SIEM, outils de Big Data pour la data science…). Il est clé de ne pas négliger la puissance de calcul nécessaire au fonctionnement de certains modèles. C’est une raison en plus de la qualité des résultats pour cibler au maximum les données les plus pertinentes pour répondre à un cas d’usage.
• Acquisition des compétences : tant les nouveaux profils à intégrer (e.g. data scientists, data engineers) que les profils métiers et experts pertinents, qui seront sollicités non seulement en phase projet mais également dans la durée (traitement des alertes, réapprentissage, tests de non-déviation de la solution, etc.)

En synthèse, quels sont les principaux pièges à éviter ?

#Reminder

Cet article Booster sa cybersécurité grâce à du Machine Learning ? Partie 2 – « Oui, mais pas n’importe comment ! » est apparu en premier sur RiskInsight.

Nous allons au travers de deux articles explorer les capacités de l’IA, en particulier celles du Machine Learning, pour la cybersécurité. Dans ce premier article, nous allons parcourir pas à pas les étapes d’un projet de Machine Learning focalisé sur un cas d’usage cybersécurité : l’exfiltration de données depuis le SI, sur un cas très simplifié. Nous en avons choisi un, mais les concepts de cet article sont applicables à tous les projets de Machine Learning et peuvent être transposés à tout autre cas d’usage, notamment cyber. 

Avant toute chose, de quoi parle-t-on ? 

Le terme d’Intelligence Artificielle (IA) regroupe toutes les techniques permettant aux machines de simuler l’intelligence. Aujourd’hui toutefois, lorsqu’on parle d’IA on parle très souvent de Machine Learning, l’un de ses sous-domaines. Il s’agit des techniques permettant aux machines d’apprendre une tâche, sans avoir été explicitement programmées pour. 

Pour nous professionnels de la cybersécurité, cela tombe bien : nous avons bien souvent du mal à décrire explicitement ce que nous voulons détecter ! Le Machine Learning nous offre alors de nouvelles perspectives, avec déjà de nombreux cas d’application, dont les principaux sont illustrés ci-dessous:

L’exemple d’un cas d’usage pour la cybersécurité ML-augmenté : le DLP 

Pour illustrer l’apport du Machine Learning à la cybersécurité, nous avons choisi de nous intéresser à l’extraction frauduleuse de données depuis le système d’information d’une entreprise. Autrement dit, le cas du DLP (Data Leakage Prevention), problématique rencontrée par un grand nombre d’entreprises. Nous souhaitons détecter les communications suspectes vers l’extérieur afin de pouvoir les empêcher. 

« Très bien mais… comment caractériser une communication suspecte ? » 

Par des volumes échangés importants ? Par une destination étrange ? Par une heure de connexion inhabituelle ?  

En réalité, notre problème est complexe à expliciter et ce que nous devons évaluer a de fortes chances d’évoluer dans le temps. C’est pourquoi, en utilisant uniquement des règles de détection statiques, nos équipes sécurité ont du mal à être exhaustives. Elles peuvent jouer sur les seuils de ces règles pour affiner les éléments détectés, mais se retrouvent malheureusement encore avec un nombre important de faux positifs à traiter. 

On comprend que le Machine Learning tel que nous l’avons défini précédemment peut nous être utile ici. Et si on essayait ? 

Etape 1 : Clarifier le besoin 

C’est ce que nous venons de faire ! 

Etape 2 : Choisir les données 

Quand on entend les mots Machine Learning, il faut généralement comprendre « données » pour alimenter les algorithmes. Beaucoup de données, et de qualité ! 

En demandant où aller chercher des données utiles pour notre cas d’exfiltration des données à notre métier demandeur (qui pour une fois est la cybersécurité !), le proxy web ressort comme grand gagnant : il voit passer quasiment tout le trafic sortant du SI. Nous récupérons donc ses logs, ils ressemblent à ça. 

« Ca m’a l’air bien compliqué tout ça… » 

Les data scientists ont en effet de quoi être perdus : d’une part l’ensemble est peu digeste, de l’autre, après consultation du métier-cybersécurité, tous les champs ne sont pas vraiment utiles pour notre cas d’usage. Nous en sélectionnons donc quelques-uns avec lui avant de poursuivre. 

Le résultat est plus exploitable par les data scientists ! 

Etape 3 : préparer les données 

Les data scientists peuvent maintenant « explorer les données » afin de garantir un apprentissage optimal de l’algorithme. Ici, ils nous remontent un élément surprenant dans la répartition de nos requêtes suivant leur volume d’upload. Puisqu’on souhaite détecter des exfiltrations de données, cette variable nous intéresse en effet particulièrement. 

La valeur de notre variable n’est pas distribuée, nous avons même un très fort volume à 0. 

« Mais, elles sont quand même nombreuses ces requêtes avec un volume d’upload nul, est-ce que c’est vraiment pertinent de les garder dans notre cas ? ».  

Effectivement, après discussion avec le métier-cybersécurité, il ressort que ces données n’apportent pas grand-chose pour notre cas d’usage. Nous décidons donc de les retirer, notre jeu est alors distribué comme suit : 

Après plusieurs allers-retours entre les data scientists challengeant les données avec un point de vue statistique et les équipes cybersécurité répondant avec leur œil métier, les données sont simplifiées au maximum. Elles sont ensuite : 

• Enrichies en créant de nouvelles variables plus denses en information utile. Nous avons introduit un volume d’upload relatif vers chaque site, mesurant l’écart entre le volume d’upload d’une requête et sa valeur moyenne observée sur les 90 derniers jours. Nous pourrions également ajouter la durée de connexion par exemple. 
• Normalisées en réduisant l’amplitude de chaque variable pour diminuer une sur ou sous-pondération de certaines variables.
• Numérisées, la plupart des algorithmes ne pouvant interpréter que des variables numériques.  

Nous pouvons maintenant séparer notre jeu de données en deux : un jeu allant servir à l’entraînement de notre modèle, un jeu qui nous permettra de tester sa performance. Plusieurs méthodes de séparation existent, permettant de conserver certaines caractéristiques des données (e.g. la saisonnalité), mais l’objectif reste le même : garantir une mesure d’évaluation au plus proche des performances réelles du modèle, en présentant au modèle des données qu’il n’a pas eu a disposition durant l’entraînement. 

Etape 4 : Choisir la méthode d’apprentissage et entrainer le modèle 

Certains algorithmes sont plus performants que d’autres pour une problématique donnée, il convient donc de faire un choix raisonné. 

Il existe deux principales catégories d’algorithmes de Machine Learning :  

• Supervisés, lorsque l’on a des données labelisées comme référence à donner en exemple à notre algorithme. Ces algorithmes sont par exemple utilisés en cybersécurité par les solutions anti-spam : ils peuvent apprendre via la classification des emails comme spam par les utilisateurs par exemple. 
• Non supervisés, lorsque l’on ne sait pas précisément ce qu’on souhaite détecter ou que l’on manque d’exemples à fournir à l’algorithme pour son apprentissage (i.e. nous manquons données labélisées). 

Comme expliqué plus haut, le contexte de notre cas d’usage nous oriente plutôt vers la deuxième option. C’est d’ailleurs pour les mêmes raisons que nous avions initialement pensé au Machine Learning. Nous choisissons ensuite notre algorithme d’apprentissage non supervisé (Isolation Forest ici, mais nous aurions pu en choisir un autre) et entrainons notre modèle. 

Etape 5 : Analyser les résultats 

Nous utilisons notre jeu de données de test pour évaluer l’efficacité de notre modèle pour détecter les cas d’exfiltration.  

Le modèle conçu permet de détecter des patterns dans les données (requêtes), pour ensuite comparer les nouvelles données (requêtes) avec ces patterns et mettre en lumière celles qui s’éloignent de ce qu’il considère comme la norme de par son apprentissage (score d’anomalie).  

Voici nos résultats :  

« Ok, mais comment j’interprète tout ça ? » 

Le graphique à gauche représente les scores d’anomalie associés à chaque requête du jeu de test, triés par ordre chronologique. A droite se trouvent les logs présentant les scores d’anomalie les plus importants. 

Après investigation avec le métier-cybersécurité : 

• Le pic en jaune, correspond à un upload de volume beaucoup plus important que les autres, d’un utilisateur qui extrait un large volume de données. Cette anomalie est légitime. Toutefois, une alerte sur la base d’une règle statique sur le volume par requête aurait également permis de détecter cette communication suspecte. 

• Plus intéressant maintenant, les pics en rouge, correspondent à des requêtes de faibles volumes d’upload régulières vers des sites inconnus depuis le même utilisateur. Ces anomalies sont plus difficiles à détecter avec des moyens classiques, pourtant notre algorithme leur a attribué le même score d’anomalie que pour un large volume. Elles deviennent donc tout aussi prioritaires à qualifier pour nos équipes de gestion des alertes de cybersécurité. 

Maintenant, focalisons-nous sur le large paquet au centre du graphique (en orange). Le premier jour, on observe un score d’anomalie important, il s’agit d’un envoi soudain de données par de nombreux utilisateurs vers le site web de transport en commun de la ville. Après investigation on se rend compte qu’il ne s’agit pas d’un vrai incident de sécurité, mais de l’envoi annuel de justificatifs pour poursuite des abonnements de transport (nous sommes début septembre…). On observe par la suite que l’algorithme « comprend » que ces flux reviennent chez plusieurs utilisateurs et les intègre progressivement comme une habitude. Le score de risques décroit donc jour après jour. 

Le modèle détecte donc ce qui sort de la norme, quelle que soit la norme et s’autocorrige avec l’expérience. C’est en cela que le Machine Learning tient une vraie valeur ajoutée par rapport aux méthodes classiques de détection. 

Si la performance du modèle sur ce premier cas d’usage simplifié permet d’attester de la valeur potentielle du Machine Learning, il peut être temps de passer à l’étape 6 – le déploiement à l’échelle !  

Dans un second article nous reviendrons sur ces étapes pour mettre en lumière les facteurs de réussite et pièges à éviter lorsqu’on souhaite étudier les possibilités du Machine Learning en cybersécurité. 

Cet article Booster sa cybersécurité grâce à du Machine Learning ?  Partie 1 – « Absolument, voici comment! » est apparu en premier sur RiskInsight.

L’intelligence artificielle est un sujet à la mode et la cybersécurité fait partie des cas d’usages phare de développement. Est-ce aussi le cas pour les startups françaises en cybersécurité ? Qu’en est-il de son utilisation ? Quelles sont les tendances du marché concernant cette technologie ?

« Intelligence Artificielle », « Machine Learning », « Deep Learning » : trois termes trop souvent confondus

Avant de rentrer dans le vif du sujet, commençons par clarifier le vocabulaire qui sera employé dans la suite de l’article :

• Intelligence Artificielle: ensemble des techniques mises en œuvre pour que des machines simulent l’intelligence ;
• Machine Learning: technique reposant sur des modèles statistiques qui permettent à l’ordinateur « d’apprendre » à partir d’un grand nombre de données ;
• Deep Learning: méthode de Machine Learning basée sur un réseau de neurones profonds. D’autres méthodes existent : Support Vector Machines, Random Forests, K-Nearest Neighbors, …

La confusion entre ces trois termes est fréquente. Bien souvent l’utilisation du terme « Intelligence Artificielle » en cybersécurité désigne l’utilisation du Machine Learning, sous toutes ses formes.

La cybersécurité, un terreau fertile pour les technologies de Machine Learning

Sur les 134 startups recensées dans notre radar 2019 des startups françaises en cybersécurité, 19% proposent des solutions basées sur du Machine Learning. Interrogées, 70% de ces startups déclarent que développer ce type de technologie dans leurs solutions fait partie de leur stratégie.

De plus, l’utilisation du Machine Learning dans certains domaines de la cybersécurité devient quasi incontournable et la majorité des startups de ces domaines envisagent de baser les futures évolutions de leur solution sur cette technologie.

Le Machine Learning en cybersécurité est en pleine progression et son utilisation, déjà implanté dans l’écosystème des startups françaises, démontre une forte volonté d’innovation du marché. On pressent que ce rythme d’adoption va continuer à s’accélérer dans les années à venir, la même « photo » de l’état des lieux dans un an devrait le prouver.

Le Machine Learning utilisé dans un but d’amélioration de performances

Les startups qui ont choisi d’utiliser le Machine Learning le font principalement afin de :

• Obtenir des temps de réponses courts: réduire le temps de réponse de la prise de décision en utilisation nominale. En effet, dans certains cas où le nombre de données est particulièrement important, il faudrait des mois à un algorithme n’utilisant pas de Machine Learning pour fournir un résultat ;
• Améliorer la fiabilité des détections: réduire le nombre d’erreurs, c’est-à-dire diminuer le taux de faux positif et faux négatifs. Les solutions anti-phishing sont une bonne illustration car celles reposant sur du Machine Learning filtrent avec moins d’erreur qu’une solution dite « classique ».

Une adoption hétérogène selon le thème du radar…

L’adoption du Machine Learning varie de manière importante d’une thématique du radar à l’autre. Les thématiques où l’utilisation du Machine Learning est la plus répandue sont : « Application Security », « Endpoint », « Industrial Security » et « Web Security ». On note également quelques cas d’usages particuliers dans d’autres thèmes du radar tel DPO Consulting utilisant du Machine Learning pour aider à la prise de décisions dans le cas d’une évaluation des risques.

…expliqué par la nature même du Machine Learning.

Le Machine Learning nécessite un certain nombre de prérequis et de conditions pour fonctionner efficacement. Toute la performance des modèles de Machine Learning repose sur la phase d’entrainement où le modèle « apprend » grâce aux données qu’on lui fournit. Ces données, que nous allons illustrer par le cas d’une solution anti-phishing pour boite mail, doivent être :

• Pertinentes: c’est-à-dire porteuses d’informations utiles. Dans notre exemple de solution anti-phishing, une information utile est par exemple la présence de certains mots souvent utilisés dans des mails de phishing ; une image ou la taille du fichier mail sont moins utiles ;
• En nombre suffisant: ce nombre varie selon le cas d’usage et le niveau de précision souhaité. Dans notre exemple de solution anti-phishing, il faudrait probablement entrainer l’algorithme avec quelques dizaines de milliers de mails ;
• Variées: si possible de sources différentes pour plus de résilience de l’algorithme. Dans notre exemple de solution anti-phishing, il serait bon que la base de données d’entrainement contienne des mails issus de différentes campagnes de phishing, reçus par différents entreprises/particuliers, des mails ciblés ou non…, et qu’elle puisse traiter à la fois le contenu du mail mais également les headers, etc. ;
• Représentatives : c’est-à-dire ne pas introduire de biais et être à jour. Dans notre exemple de solution anti-phishing, il convient par exemple de ré-entrainer régulièrement le modèle afin de prendre en compte les dernières tendances en matière de phishing.

Schéma de fonctionnement d’une solution basée sur du Machine Learning

Dans les domaines où le Machine Learning est le plus utilisé, il s’avère que ces conditions sont plus facilement réunies. En effet, les données nécessaires à l’entrainement sont souvent déjà disponibles dans les équipements en place (log applicatifs, log système, log réseau, alerte anti-virus, …), voire déjà consolidées dans des équipements de sécurité centraux (SIEM, Data Lake…).

« Intelligence Artificielle » : Gare à l’effet de mode !

Si le Machine Learning offre de nouvelles possibilités permettant de grandement améliorer les capacités cybersécurité des entreprises, cette technologie n’est pas en soi une solution miracle. Il est important de bien comprendre ces algorithmes et de garder certains points d’attention en tête avant de se lancer dans l’acquisition d’une telle solution.

Tout d’abord, comme la phase d’entrainement est clé pour la performance du Machine Learning, il faut s’interroger sur sa capacité à fournir à la solution les données nécessaires et suffisantes pour l’apprentissage. Le principal frein remonté par les startups proposant des solutions entrainées avec des données clients est d’ailleurs la difficulté d’obtenir des données en qualité et quantité suffisante pour faire tourner leur solution.

Il est également important de réussir à lire au-delà du discours commercial pour comprendre l’apport réel du Machine Learning à la solution, au risque de payer plus cher un outil qui ne serait pas forcément justifié. Et surtout, il faut être conscient que le Machine Learning ne signifie pas ne plus avoir de risques. Ces solutions, comme toute solution de sécurité, répondent à un cas d’usage précis et viennent compléter un ensemble de mesures de sécurité.

Cette mise en garde nous semble nécessaire même si nous avons constaté une utilisation pertinente et justifiée de ces technologies par les startups françaises en cybersécurité dans le cadre de notre analyse.

Cet article L’utilisation du Machine Learning par les startups françaises dans le domaine de la cybersécurité 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.

Le dilemme de l’évolution des dispositifs antifraude : quels leviers pour intégrer ces technologies ?

Faisant écho à ces problématiques, l’écosystème des éditeurs s’est organisé pour proposer des solutions antifraude s’appuyant sur ces technologies. Ainsi éditeurs et start-ups se sont très largement développés, partout dans le monde (plus de 150 fournisseurs ont été recensés au sein du radar « Antifraude » Wavestone). Le besoin de lutte antifraude a en effet par nature une dimension internationale, notamment dans la protection des flux monétaires qui sont rarement limités à un seul pays.

Figure 2 :Exemple du radar des éditeurs antifraude Wavestone (extrait non exhaustif)

Même si la lutte contre la fraude apparait comme un use case de choix pour démontrer le ROI du Machine Learning (réduction du nombre de fraudes, automatisation de la détection…) et au-delà du choix de la stratégie d’outillage de lutte contre la fraude au regard de la maturité du marché, les questions à se poser doivent rester celles d’une solution SI « standard » (exploitation, maintenance, évolutivité…).

Si les coûts d’infrastructures nécessaires à la mise en place d’outils basés sur le Machine Learning et le big data ne sont pas négligeables, ils permettent de créer un environnement favorable à l’exploitation de la richesse des données pour divers usages (maintenance prédictive des serveurs, connaissance client, etc.) en gardant à l’esprit les garde-fous mis en place par le RGPD.

Figure 3 : Où peut-on agir avec le Machine Learning : exemple d’une banque

Une nouvelle cible à atteindre : une approche « sans couture » technologique et métier

Face aux nouveaux enjeux et l’apport des technologies émergentes, une nouvelle stratégie antifraude doit être désormais définie.

La mise en place d’un dispositif de détection globale de confiance qui devra respecter 5 grands principes.

• L’efficience et l’automatisation : il bénéficiera d’une détection à plusieurs critères (moteur de règles et Machine Learning) et d’une efficacité opérationnelle optimisée par l’automatisation de mesures allant de l’augmentation du niveau d’authentification demandé au gel d’un virement.
• L’évolutivité et l’omnicanal : il intègrera plusieurs périmètres dans la détection avec une logique « sans couture » entre le monde cyber et le monde « hors cyber » et sera conçu pour permettre l’intégration de nouvelles données disponibles (ex : données de biométrie comportementale).
• La visibilité et l’exploitabilité : il fournira la visibilité (reporting) et l’explication des résultats de détection, aux équipes antifraude, aux clients et également aux régulateurs.
• La conformité et la sécurisation : il respectera les obligations en matière de détection ainsi que les réglementations (RGPD), et traitera les risques inhérents au Machine Learning (tentatives de poisoning, compréhension par l’attaquant du modèle…).
• La gouvernance transverse cybersécurité et métier : une collaboration étroite des équipes de détection de menaces cyber et métier antifraude, dépassant les silos encore trop présents, permettra une réponse globale avec une vision 360 des menaces et fera le meilleur usage des données disponibles.

Pour bénéficier de tous les atouts apportés par cette nouvelle stratégie de détection, il conviendra également de ne pas négliger les systèmes d’investigation et de réaction.

Une décentralisation partielle de la lutte contre la fraude, impliquant les conseiller bancaires, permettra une plus grande capacité d’investigation. Ayant la connaissance la plus fine de leurs clients, ces derniers représentent un atout dans le processus d’investigation.

De plus, la biométrie comportementale et le machine learning permettent de fournir une meilleure visibilité sur le niveau de confiance qu’on peut accorder à l’utilisateur. Une fois le niveau de confiance défini, il est donc possible d’adapter les niveaux d’authentification demandés en conséquence. Une contribution adaptée et graduée de l’utilisateur permettra ainsi de réduire le nombre d’alertes émises.

La mise en place d’une nouvelle cible antifraude n’est pas seulement pour assurer une réponse adaptée à un changement de contexte mais aussi pour anticiper une vague de fond qui s’amorce aujourd’hui. La détection de fraudes deviendra à l’avenir de plus en plus complexe compte tenu d’une digitalisation qui va continuer à s’accélérer, en particulier sur les moyens de paiement. L’émergence de nouveaux acteurs, comme les Fintechs, et la désintermédiation grandissante des banques vont notamment entraîner un appauvrissement de la donnée disponible. Les dispositifs antifraude sont donc voués à évoluer en profondeur afin de garder et développer leur efficacité.

Cet article Revolution technologique : quelle perspective pour la lutte contre la fraude ? (2/2) est apparu en premier sur RiskInsight.

Les expériences et expérimentations du secteur bancaire, en avance sur ces problématiques, permettent d’envisager les perspectives à venir et fournit donc un prisme d’analyse utile aussi pour les autres secteurs.

Menaces, usages, réglementations : trois évolutions majeures qui impliquent des adaptations des dispositifs antifraude

Les transformations business et technologiques dans l’ensemble des secteurs d’activité font apparaitre des évolutions impactant directement les dispositifs antifraude historiques.

Les menaces évoluent, les pratiques de fraude se sont professionnalisées avec de nouveaux outils et de nouvelles pratiques. Prenons l’exemple du phishing : même sans connaissances informatiques, une cellule de fraudeurs entrainée peut désormais acheter un kit de phishing prêt à l’emploi et met en moyenne seulement trois minutes entre une connexion frauduleuse et une sortie d’argent. Les tentatives de fraude se sont donc démultipliées ces dernières années.

En parallèle, les usages évoluent vers une plus forte digitalisation, parfois dictés directement par des évolutions réglementaires, à la fois à destination des clients ou à destination des collaborateurs. Par exemple la mise en place de l’Instant Payment en France ou de la directive européenne sur les services de paiement 2ème version (DSP2) prévoient des virements instantanés. Ces nouveaux usages accélèrent les transactions financières entre les acteurs entrainant par la même occasion des besoins d’évaluation instantanée des risques de fraude. De plus, cette multiplication des canaux de paiement entraîne une augmentation de la surface d’attaque avec notamment une diversification des malwares bancaires aux applications mobiles ainsi que l’apparition de pratiques d’ingénierie sociale complexes multicanales et appuyées sur une compréhension des processus métier.

La diversification des fraudes, la volumétrie associée et l’augmentation des besoins de traitement instantané rend le traitement manuel presque impossible. La création de règles d’alertes plus restrictives pour minimiser les volumes ferait cependant courir le risque de manquer un grand nombre de fraudes.

Dans ce nouveau paysage, où la fraude devient de plus en plus technologique et peut avoir de multiples origines (clients, donneurs d’ordres, sous-traitants, fournisseurs, administrateurs…), les stratégies de détection doivent évoluer et passer d’une détection réactive des fraudes connues à une détection proactive des menaces encore inconnues.

Les nouvelles technologies, l’avenir de l’antifraude pour faire face à ce nouveau paradigme

L’approche historique de la détection de fraude est fondée principalement sur la définition de règles unitaires générant une alerte en cas de non-respect d’un des critères et sur la corrélation d’événements, consistant à mettre en œuvre des règles métiers plus avancées prenant en compte plusieurs types de données, afin de générer une alerte lorsque apparaissent des indices du déroulement d’un scénario de fraude connu.

Cette approche tout en demeurant efficace pour la détection de fraudes connues, par exemple dans la lutte contre le phishing, n’est plus suffisante pour faire face aux évolutions en cours. Une approche hybride doit être enrichie sur la base des nouvelles technologies présentes sur le marché (intelligence artificielle / Machine Learning, biométrie comportementale…) qui offrent deux grandes perspectives d’enrichissement des dispositifs actuels.

1.  Passer d’une détection de masse à une détection individualisée beaucoup plus fine qui va se concentrer sur les changements de comportement.

Le Machine Learning a la possibilité de créer des profils individuels à chaque client. Ces profils, composés de variables construites à l’aide des données collectées, vont permettre de modéliser le comportement. Ainsi, les algorithmes utilisés vont comparer le profil du client (et donc son habitude) avec un événement donné et, de fait, remonter une anomalie lorsqu’une divergence apparait. A noter que le nombre de variables manipulées peut facilement dépasser plusieurs dizaines, là où des règles statiques n’intègreront que quelques paramètres, permettant ainsi de démultiplier le potentiel de détection ou de réduire le nombre de faux positif.

2. Diversifier les périmètres à couvrir en bénéficiant des économies d’échelle apportées par ces technologies (mutualisation des infrastructures big data, massification des données, automatisation permettant un gain de temps pour les analystes…)

Ces technologies ont la capacité d’intégrer et corréler, grâce à des Data Lake sur lesquels elles s’appuient, des volumétries importantes de données brutes, techniques ou métiers (logs applicatifs, connaissances clients, opérations financières…) et d’apporter un potentiel d’enrichissement par des données extérieures (liste de surveillance, transformation d’adresses IP en localisations physiques…). Pour tirer le maximum de bénéfices des systèmes antifraudes, le Data Lake doit disposer d’un historique de données pertinentes et conformes, à savoir 13 mois pour des personnes physiques et 6 mois pour des personnes morales.

Pour autant ces technologies ne sont pas « magiques », elles nécessitent d’avoir à disposition des données en qualité et en quantité afin de réaliser un important travail préparatoire sur la construction des variables qui portent les capacités de détection des algorithmes. Cette phase de construction nécessite un apport d’expertise à la fois métier mais aussi technologique (datascience, développeurs, etc.).

Figure 1 – les principales méthodes de détection

Le choix des algorithmes n’est également pas à négliger, notamment d’un point de vue de la transparence. En effet, certains outils sont basés sur des algorithmes où les résultats sont difficilement justifiables. Le manque de visibilité sur les critères d’établissement des résultats entraine une remontée d’alertes en « boîte noire » et ne permet pas toujours de justifier les blocages aux clients. Une trop grande opacité peut également avoir des conséquences juridiques, voir être illégale, lorsque ces alertes ont des conséquences directes sur des clients.

Si ce premier article présente quelles sont les technologies d’avenir dans la lutte contre la fraude, un deuxième article viendra détailler comment les intégrer au mieux.

Cet article Revolution technologique : quelle perspective pour la lutte contre la fraude ? (1/2) est apparu en premier sur RiskInsight.

Améliorer la connaissances des menaces et des attaquants : plateformes CTI (-Cyber-Threat Intelligence)

La Cyber Threat Intelligence (CTI ou Threat Intel’) est une discipline regroupant la récolte, la consolidation et l’exploitation de toutes les informations sur les cyber-menaces. “Connais ton ennemi” indique Sun Tzu dans l’Art de la Guerre. Bien que cette citation fasse référence aux guerres « physique », le principe reste vrai… et l’est sans doute même davantage pour les luttes « cyber ».

En effet, aujourd’hui, un nombre important de dispositifs de sécurité s’appuient sur une connaissance des attaques : approche par signature des anti-virus et IDS, scénarios de détection ciblés… Même si la tendance s’inverse (notamment avec la détection d’anomalies), la grande majorité des produits de sécurité s’appuient toujours -et continueront de s’appuyer- sur des principes de Threat Intelligence.

Les besoins des entreprises étant de plus en plus spécifiques, et les attaquants de plus en plus spécialisés, les solutions de Threat Intel’ se démocratisent et proposent directement leurs services aux entreprises. En complément des offres commerciales, de plus en plus de plateformes d’échanges et de partenariats permettent de collaborer directement avec d’autres entreprises (de même secteur, zone géographique…).

Les services rendus par la Threat Intel’ sont multiples. D’une part la Threat Intel’ « stratégique » aide les SOC à mieux connaître le contexte et les menaces spécifiques à leur entreprise. Pour cela, les risques pesant sur chaque écosystème sont étudiés : aspects géographique, politique, idéologique, sectorielle… Ces informations permettent aux équipes sécurités de mieux connaître les menaces les concernant, et d’orienter leurs décisions pour définir leur stratégie « long terme » (solutions à déployer…).

D’autre part, la Threat Intel’ « tactique » donne des informations plus précises sur les méthodes des attaquants et permet notamment au SOC de faciliter la détection et d’adapter les mesures existantes : nouveaux scénarios de menaces à surveiller, ports à bloquer….

En complément de ces approches, la Threat Intel’ « technique » participe grandement à l’analyse des évènements de sécurité en fournissant, sur demande (depuis un SOAR notamment, voir partie suivante), des éléments permettant de juger de la véracité d’une alerte : appartenance d’une IP à un botnet, hash de fichier correspondant à un virus connu…

Les dispositifs de Threat Intelligence figurent donc parmi les outils les plus polyvalents du SOC, en permettant de tirer parti au mieux des dispositifs existant, en restant à jour et priorisant les menaces à détecter, et en orientant vers les prochains outils et mesures à déployer.

Exemples d’éditeurs Threat Intelligence :

Industrialiser et automatiser le processus de réaction : SOAR

Les SOAR (pour Security Orchestration, Automation & Response) sont issus de la combinaison de trois outils du SOC : les SIRP (Security Incident Response Plateform, plus de détails ici), les SOA (Security Orchestration & Automation, les solutions d’industrialisation et d’automatisation) et une partie des fonctionnalités de plateformes de Threat Intelligence. Pour résumer, ce sont des plateformes d’aide et d’automatisation de la réaction aux incidents de sécurité. Ces solutions se rapprochent d’outils de ticketing (ITSM) classiques, mais embarquent des fonctionnalités spécifiques aux problématiques de cybersécurité. Les SOAR offrent principalement trois capacités, chacune liée à l’un des trois types d’outils à leur origine.

Premièrement, comme les SIRP, ils permettent la définition de processus de réaction adaptés à chaque évènement de sécurité. Ceux-ci sont basés sur des playbooks prédéfinis par l’éditeur, publiés par la communauté de la solution, ou créés manuellement pour une meilleure adaptation aux besoins de l’entreprise. Cette tâche impose notamment aux équipes de réaction d’établir un processus clairement défini, les aidant ainsi à se poser les bonnes questions lors de la création de procédures de réaction, et à capitaliser et stocker ces connaissances.

Le gain des SOAR repose cependant davantage sur l’automatisation des différentes étapes suivant la détection. Lors de la phase d’analyse, l’outil va automatiquement enrichir l’évènement de sécurité en allant récupérer des informations de contexte sur le SI (identité dans l’AD, criticité d’une ressource…), et en interrogeant des services de Threat Intelligence externes (via des API) ou proposés avec la solution. Outre l’automatisation de l’enrichissement et des étapes d’analyse, les SOAR facilitent aussi le travail des analystes -investigation de postes, interrogation de VirusTotal… en un clic-  lorsque leur intervention est nécessaire.

Mais l’automatisation ne s’arrête pas là ! Bien que polémique, l’automatisation de la réaction (via la connexion aux équipements de sécurité, héritage du SOA) peut représenter un gain important pour les équipes de sécurité : blocage d’URL, génération de signature de fichier et propagation aux antivirus, blacklisting d’IP…

L’objectif des SOAR est donc clair : faciliter la tâche des équipes en charge de l’analyse et de la réaction, en les aidant à définir des processus et en automatisant les tâches au maximum. Même si les SOAR sont très adaptables, et peuvent donc aider à répondre à toute type d’attaque, ils brillent tout particulièrement pour automatiser le traitement des attaques courantes (ransomware, phishing…), très répétitives et mobilisant les efforts des équipes de réaction.

Une fois ces tâches automatisées, les équipes sécurité en charge de la réaction peuvent se concentrer sur les alertes plus complexes, où leurs connaissances apportent une véritable valeur ajoutée.

À conditions d’être prêt à fournir l’effort initial (formalisation des processus…), les gains en réactivité et en charge attendus sont donc conséquents. Les SOAR sont amenés à changer le mode de travail des équipes SOC, en particulier pour les analystes de premier niveau. Même si ces solutions sont encore peu déployées en France, ils devraient devenir l’un des indispensables du SOC dans les années qui viennent.

Exemples d’éditeurs SOAR :

Même si l’outillage n’est qu’une partie du SOC, chacune de ces solutions présente des avantages certains qui aideront les équipes de détection à rester d’actualité face à l’évolution du SI et des menaces.

Tous ces outils sont prometteurs, et certains arrivent à maturité. Cependant, il est important de garder à l’esprit que l’outillage actuel lève déjà de nombreuses alertes, difficiles à prendre en compte. Il est donc conseillé de finir de déployer et d’industrialiser l’existant (en utilisant un SOAR par exemple), avant de se tourner vers de nouvelles solutions.

Et, comme pour tout produit innovant, il faut savoir garder la tête froide : le déploiement d’une nouvelle solution doit être motivé par des besoins bien définis.

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 (3/3) 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.

Machine Learning, démystification et opportunités

Le Machine Learning est une forme d’intelligence artificielle qui consiste à apprendre et modéliser un phénomène pour mieux le comprendre et le maîtriser. Pour cela, un ou plusieurs algorithmes permettent d’établir des corrélations entre les évènements qui composent ce phénomène. On distingue deux grands types de méthodes :

• Les méthodes supervisées, qui créent des modèles à partir d’une base de données d’exemples (généralement des cas déjà traités et validés).
• Les méthodes non-supervisées, qui n’ont pas besoin d’une base de données d’exemples

Pour illustrer la différence entre les deux méthodes, on peut considérer le cas de la détection de fraude. Pour s’entraîner et créer des modèles précis, les méthodes supervisées utiliseraient en entrée des données déjà traitées et marquées comme étant liées ou non à des cas de fraude (schémas de fraude connus), alors que les méthodes non-supervisées utiliseraient des données brutes issues des applications du SI afin de modéliser les comportements normaux. Conceptuellement, cela revient à modéliser respectivement ce qui est anormal (la fraude – en ayant assez de données pour que cette représentation soit fidèle) ou ce qui est normal (en détectant de facto les fraudes lorsque l’on s’éloigne de cette normalité).

Tous les algorithmes ne se valent pas. Chacun possède des qualités et des défauts qu’il faut savoir peser et qui dépendent en grande partie des données d’entrée, propres à chaque cas métiers. Il est important de choisir des données à la fois pertinentes et disponibles en quantité suffisante pour obtenir des résultats probants. Dans le contexte de la Banque en Ligne, de nombreuses données peuvent faire l’objet de Machine Learning :

• Habitudes de transaction : montants des virements, pays destinataires…
• Habitudes de connexion : heure de connexion, user-agent, device utilisé…
• Habitudes de navigation : parcours client, vélocité de navigation…
• Données comportementales : vitesse de frappe, déplacement de la souris…
• Données marketing : produits consommés, libellés des virements…

Correctement exploitée par des algorithmes de Machine Learning, la conjugaison de ces différentes données, précédée par un traitement tirant le maximum de leur valeur, peut permettre des résultats bien plus significatifs que ne le permettent les méthodes classiques. La connaissance client (KYC), en exploitant par exemple le parcours client type, la détection de fraude, en utilisant les habitudes de virement pour identifier des cas suspects (pays de connexion, distribution des montants…), ou encore le marketing à travers la connaissance des habitudes de consommations (analyse des libellés, regroupements des achats par catégories…) peuvent notamment largement tirer parti de ces données.

Concrètement, quels sont les gains du Machine Learning ?

Tout d’abord, connaître le client et mieux adresser ses besoins

Le Machine Learning permet de tirer le maximum de valeur des données en singularisant les modèles là où les méthodes « classiques » reposent sur un modèle commun à l’ensemble des données d’entrée. Par exemple dans le cas de la détection de fraude, les modèles de règles « classiques » reviennent à élaborer un modèle qui sera commun à tous les clients, sans tenir compte de leur unicité, là où le Machine Learning permettra une détection plus efficace en associant un profil à chaque client et en effectuant une surveillance et une détection propres à ce profil. Ce raisonnement vaut pour tous les autres domaines d’applications, et permet, in fine, une meilleure représentation et une meilleure connaissance non plus « du client » au sens large, mais de chacun des clients.

Le Machine Learning permet également d’offrir de nouveaux services

Au-delà de l’amélioration notable des résultats basés sur les KPI classiques (taux de faux positifs, taux de détection…), le Machine Learning permet une création de valeur en termes de gains financiers en personnalisant les outils dont profite le client. Cela peut parfaitement servir de socle à une offre commerciale qui reposerait par exemple sur la personnalisation de ses seuils par le client ou sur la possibilité d’être alerté en temps réel lorsqu’une information marketing, commerciale ou concernant sa sécurité a particulièrement du sens. Certaines banques ont d’ailleurs déjà franchi le pas, en offrant la possibilité à leurs clients Entreprises d’être alertés en cas de virements qui dépassent des seuils personnalisés préalablement établis.

Finalement, le Machine Learning est aussi une occasion de moderniser les outils et rester à l’état de l’art

Lancer un projet de Machine Learning permet de communiquer sur le sujet et de profiter du buzzword pour générer de la satisfaction chez un certain nombre de client de plus en plus sensible à des problématiques de sécurité ou de confidentialité, tout en s’assurant d’être à l’état de l’art du marché. Cela peut également permettre de moderniser des outils existants en vue des changements qui vont continuer d’opérer dans la Banque en Ligne au gré des nouvelles règlementations et des exigences techniques (temps réel notamment avec Instant Payment) et métiers qui en découlent. Dans ce cadre, on voit par exemple éclore des méthodes de Machine Learning pour la surveillance des marchés et lutter contre les délits d’initiés.

En conclusion, la pleine maîtrise technique du Machine Learning coïncide avec de nouveaux besoins et de nouvelles exigences exprimés dans la Banque en Ligne moderne. Embrasser cette évolution présente de nombreux avantages, de l’amélioration des performances et des résultats à la satisfaction des clients, en passant par une meilleure flexibilité technique. La maîtrise des différentes méthodes doit permettre un renouvellement des traitements et des processus métiers, en les rapprochant du client (aujourd’hui ces méthodes sont plutôt transparentes pour lui). Dans le cas de la lutte contre la fraude, on peut par exemple imaginer de nombreux cas autour de l’alerting et des contre-mesures, comme une vérification par authentification forte en cas de suspicion, ou des informations reçues en temps réel pour mieux impliquer les clients.

Cet article Le Machine Learning, quelles opportunités et quels enjeux dans une Banque en Ligne moderne ? est apparu en premier sur RiskInsight.