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.

A quoi ressemble l’outil « Jitsuin Archivist » ?

La start-up Jitsuin a développé un outil appelé « Jitsuin Archivist » qui repose sur la technologie de registres distribués (DLT : Distributed Ledger Technology). Le but de cet outil est de savoir : « Who did what to a Thing and When » qui lorsque traduit en français donne : « Qui a fait quoi à un Objet et quand ».

Pour le moment, 5 types d’utilisateurs peuvent interagir avec l’outil : Archivist Administrator, System Administrator, Maintenance Operator, Auditor, Custom (actuellement en version bêta).

Figure 1 – Les 5 rôles au sein de Jitsuin Archivist

Sur cet outil l’utilisateur a accès aux « Security Twins » de ses objets connectés. En effet, après s’être connecté, l’utilisateur accède à un dashboard au travers duquel il a une vue globale de l’ensemble des objets connectés reliés à l’outil. Il peut y voir des statistiques pertinentes en lien avec son déploiement IoT comme par exemple le nombre d’incidents critiques, l’activité des objets connectés etc.

L’utilisateur peut également accéder à la page « Manage Assets » où il va retrouver une carte avec la localisation de l’ensemble des objets connectés reliés à l’outil et une liste de ces derniers (où il pourra également voir plus en détails les évènements en lien avec un objet connecté en particulier).

Figure 2 – Les différentes vues de l’outil « Jitsuin Archivist » : 1. Dashboard avec une vue globale, 2. L’ensemble des objets et leur localisation, 3. La vue détaillée d’un objet, 4. L’ensemble des actions de l’objet utile lors d’audits de sécurité

Le PoC : Une maison disposant d’une serrure connectée

Wavestone s’est donc appuyé sur l’outil de la startup Jitsuin pour d’une part répondre à la problématique de gestion des identités et des accès dans les bâtiments à l’ère de la transformation digitale et d’autre part illustrer l’utilité des « Security Twins ».

Pour ce faire, Wavestone a utilisé la maison en lego appelée « Smart House».

Figure 3 – La Smarthouse

Equipée d’un lecteur de cartes RFID, d’un microcontrôleur Raspberry Pi et d’un servomoteur, la porte d’entrée de la « SmartHouse » ne s’ouvre qu’aux utilisateurs qui possèdent un badge avec les bons accès. Toutes les actions en lien avec l’ouverture, fermeture, attribution de droit d’entrée, etc. sont enregistrées sur l’outil « Jitsuin Archivist » (c.f. figure 4).

Figure 4 – Schéma fonctionnel de la SmartHouse

Afin de faciliter l’interaction avec la serrure connectée de la SmartHouse, une plateforme permettant de simuler les différentes opérations faites par des acteurs du cycle de vie d’un objet connecté a été créée en utilisant le framework web Django ainsi que Bootstrap. Cette plateforme permet entre autres de :

• Envoyer de patchs de sécurité à la serrure connectée (en utilisant Azure IoTHub)
• Attribuer des droits d’accès à la SmartHouse
• Visualiser l’historique des demandes de droits d’accès effectuées et celles en attente de validation, etc.

Voici à quoi ressemble la plateforme :

Figure 5 – La plateforme de gestion de la SmartHouse

L’utilisation de Jitsuin Archivist dans ce PoC est très intéressante d’un point de vue des audits de sécurité des objets connectés. En effet, comme l’outil Jitsuin Archivist repose sur la technologie de registres distribués (DLT), ce système peut être considéré comme « secure by design » puisqu’un(e) auditeur/auditrice a une garantie technique sur la non-compromission des données (à condition que l’envoi de ces données soit sécurisé).

Voici la « Auditor View » sur Jitsuin Archivist où il est possible de voir toutes les informations des objets connectés et savoir qui a fait quelle action :

Figure 6 – La « Auditor View » de Jitsuin Archivist

Le scénario du PoC : WaveHouse loue des SmartHouses sur le terriroire français …

Voici donc l’architecture générale du PoC :

Figure 7 – L’architecture générale du PoC

Comme vous pouvez le remarquer la serrure connectée (représentée par le lecteur de carte RFID, le microcontrôleur Raspberry Pi et le servomoteur) interagit également avec Azure IoTHub afin de faciliter la gestion des mises à jour de son micrologiciel.

Les principaux cas d’usage étudiées par Wavestone et Jitsuin

Les principaux cas d’usage étudiés par Wavestone et Jitsuin sont explicités dans la vidéo ci-dessous :

Conclusion

Les équipes de Wavestone et Jitsuin ont pu démontrer avec les différents cas d’usage illustrés ci-dessus dans la vidéo comment améliorer la sécurité des objets connectés :

• Tout d’abord, tous les acteurs du cycle de vie de la serrure connectée de la « SmartHouse » avaient accès au « Security Twin » de la serrure connecté. En effet chacun d’entre eux avait accès à un registre décentralisé et immuable fourni par l’outil Jitsuin Archivist avec toutes les informations en lien avec la sécurité de la serrure connectée
• Ensuite, comme évoqué précédemment, cette architecture est « secure by design » puisque comme Jitsuin Archivist repose sur la technologie de registres distribués (DLT), on a une garantie technique sur la non-compromission des données
• Le « Security Twin » de la serrure connectée permettait d’assurer la sécurité physique puisqu’il a été alimenté par les informations de gestion des droits permettant ainsi à l’ensemble des acteurs de savoir qui avait accès à la « SmartHouse ».

Cet article Les « Security Twins » : Le nouveau gage de sécurité des objets connectés (2/2) est apparu en premier sur RiskInsight.

Différentes contraintes à prendre en compte pour assurer le succès d’un projet

Tout au long de la vie du projet, la prise en compte des contraintes du run doit tendre à s’affiner au fur et à mesure que se précise la vision de la cible attendue. De cette analyse doit alors découler un plan d’actions permettant d’anticiper la future arrivée en production du projet et d’y préparer les équipes de run.

Cette attention est déterminante dans le succès d’un projet informatique et surtout dans la pérennité de son exploitation car c’est un prérequis indispensable :

• Dans l’identification des sujets centraux du transfert de connaissance vers les équipes de run ;
• A l’acquisition de toutes les compétences requises pour la bonne exploitation du futur système par ces mêmes équipes ;
• A la définition de modalités de « service management » claires et partagées.

Impliquer les équipes de run : clé de réussite du passage du build au run

Bien sûr, le passage du build au run se prépare à travers une bonne documentation du projet – et de préférence une documentation validée par les équipes d’exploitation –, par la définition et/ou la contractualisation de services auprès de l’exploitant, par l’implémentation d’une matrice de rôles et responsabilités claire et complète et enfin par la mise en œuvre progressive de processus de gestion des incidents, des demandes et des changements.

Cependant, le véritable succès de ce transfert des équipes de build vers les équipes de run réside aussi – et surtout – dans l’implication des équipes de run dès la phase de design du projet afin d’influer sur l’architecture du système, d’améliorer le coût de son cycle de vie et de prévenir les risques liés à son exploitation.

Mais comment impliquer les interlocuteurs du run dans le projet ? Sachant que les équipes de build et celles de run sont généralement issues de direction différentes. Qui est supposé diriger qui ? Qui est force de décision sur le projet ? À quel moment se fait la bascule du pouvoir de décision ?

Quelques bonnes pratiques de DSI pour mobiliser les équipes de run

Autrefois, la réponse d’une DSI à l’implication du run dans le projet passait par la désignation d’un ou plusieurs interlocuteurs privilégiés au sein de ces équipes de run. Ces « référents » avaient en charge d’assurer la coordination avec les équipes de build et d’acquérir dans le même temps toute la connaissance projet. Mais très vite, ces collaborateurs devenaient des points de contention, leur implication créant un problème de gouvernance récurrent : qui les pilote ?

Aujourd’hui, d’autres réponses émergent. Parmi les plus judicieuses, résident notamment :

• La création d’équipes projet « mixtes », composées autant de personnes venues du build que de personnes venues du run  et détachées sous une direction unique ;
• La création d’instances de gouvernance autour de l’architecture impliquant à la fois les responsables de run et du build pour assurer la prise en compte des contraintes d’exploitation dès la phase de design du système ;
• La réalisation de Proof of concept (POC) pour éprouver les modalités de service management : l’ensemble de mon processus est-il clairement maîtrisé et connu de tous ? Les différentes parties prenantes sont-elles bien définies et en capacité de réaliser leurs actions ?. Ce POC permet également de faciliter la montée en compétences des interlocuteurs de run sur la prise de décision : quoi faire et dans quel cas ?
• La mise en œuvre de périodes probatoires à l’issue de la mise en production pendant lesquelles les équipes de run prennent progressivement la responsabilité du système tout en conservant un support des équipes de build ;
• La mise à disposition de socles normalisés portés par des offres de services standardisées permettant d’inverser le problème : il n’appartient plus au run de répondre aux exigences du build. Au contraire, il devient de la responsabilité du projet de s’inscrire dans les standards d’exploitation définis.

Quelles que soient les approches adoptées, celles-ci visent toutes le même eldorado : trouver le parfait équilibre entre objectifs du build et contraintes du run… et ainsi assurer la réussite totale du projet !

Cet article Le passage du build au run : un sujet trop souvent négligé ? est apparu en premier sur RiskInsight.