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.