Une IA hybride pour contrer le Phishing ?

ia hybride phising

Une IA hybride pour contrer le Phishing ?

ia hybride phising

Le phising : une entreprise sur 2 attaquée en 2021

D’après le Baromètre de la cybersécurité en entreprise CESIN 2022, plus d’une entreprise française sur deux a vécu au moins une cyberattaque au cours de l’année 2021 avec parfois des conséquences très graves sur l’entreprise telles que l’interruption du business, la détérioration du business ou encore la fuite des données. Tout cela engendre inévitablement un impact sur la notoriété de l’entreprise.

 De plus, plus de 80 % des événements de cybersécurité impliquent des attaques de phishing. Le phishing, ou hameçonnage en français, est une cyberattaque essentiellement par courriel basée sur l’ingénierie sociale qui est une forme de manipulation psychologique visant à extirper des informations confidentielles d’une personne ou d’une entreprise. Il existe différents types de mails de phishing :

  • Le spearphishing, généralement basé sur l’usurpation d’identité, cible une personne ou un petit groupe de personnes dans le but d’obtenir des informations confidentielles.
  • Le whaling est identique au spearphising sauf qu’il vise exclusivement des personnes d’entreprise de haut rang.
  • Le phishing par URL a pour objectif que la victime clique sur un lien frauduleux, ce qui pourrait entraîner le téléchargement d’un virus ou mener à une page ou des données confidentielles seraient requises.

IA hybride et Deep Learning au service de la cybersécurité

Depuis quelques années, tout le monde en parle. La solution serait de se doter d’une Intelligence Artificielle, plus précisément d’un algorithme d’apprentissage profond (Deep Learning), pour aider à analyser et donc à détecter les cyberattaques. L’IA est en effet en capacité de s’appuyer sur d’énormes volumes de données pour détecter les mails de phishing et donc agir vite (plus vite que l’être humain ?) quant à cette cyberattaque.

Néanmoins et comme toujours avec le Deep Learning, cela nécessite préalablement la constitution d’une base de données regroupant un grand nombre d’emails labellisés de nature « emails de phishing » mais aussi « emails normaux ». De surcroit, cette base de données doit être équilibrée, c’est-à-dire qu’elle ne doit pas avoir une classe surreprésentée par rapport à une autre, pour éviter que lors de l’apprentissage par les algorithmes de Deep Learning, il y ait un surapprentissage, c’est-à-dire qu’un modèle apprenne trop les particularités de la base de données sur laquelle il s’est entraîné.

Par ailleurs, la détection reste d’autant plus complexe que le corps d’un email, même de phishing, peut être vaste. Il est donc nécessaire de mettre en place des prétraitements pour « nettoyer » le contenu de l’email d’informations à la fois non pertinentes et polluantes pour un apprentissage efficace. Par exemple :

  • Passage du corps de l’email en minuscule,
  • Réduction de la ponctuation,
  • Tokenization
  • Lemmatisation,
  • Etc…

Aujourd’hui, de plus en plus de solutions apparaissent sur le marché et revendiquent une capacité de détection fiable et automatisée 24h/24, 7jours/7, des cybermenaces.

Le BRMS au service de la détection du Phishing ?

Malgré tout, il y a sans doute une autre voix consistant à mettre en place une IA hybride qui conserve bien entendu un dispositif d’algorithme d’apprentissage, complété par un dispositif d’inférence cognitive.

Spécialiste de la mise en place de solution de moteurs de règles / BRMS (Business Rules Management System), Pacte Novation travaille depuis de nombreuses années sur la complémentarité du Deep Learning avec des techniques de systèmes expert / moteurs de règles. Ce qui s’appelle l’IA Hybride. Pour rappel, les solutions de BRMS permettent la transposition d’une expertise humaine en règles métier qui pour certaines solutions sont des expressions fonctionnelles écrites en langage naturel.

Dans le contexte de la détection d’emails de phishing, un email, quel qu’il soit, est toujours constitué des mêmes parties : l’expéditeur, l’objet, le corps du mail, l’heure, la date et de liens. Si le corps du mail est traité avec une IA de type algorithme d’apprentissage, on peut aisément constituer des règles de contrôles et de filtres sur l’adresse de l’expéditeur, le domaine utilisé, les plages d’horaires durant lesquelles ces emails sont reçus, l’objet de l’email et potentiellement les liens de l’email.

Ainsi, nous pourrions avoir par exemple :

  • Une table de décision donnant un score de détection d’un email de phishing en fonction du nombre de chiffres dans l’adresse email :
IA hybride
  • Une règle sur le pays d’origine de l’expéditeur :

Si le pays d’origine de l’expéditeur de l’email n’est pas parmi (« fr », « com », « net », « gov », « edu », « org », « info ») alors affecter le score expéditeur à 40.

  • Une table de décision donnant un score de détection selon l’heure d’envoi de l’email :
IA hybride phishing

Une IA hybride convaincante et adaptable

Cette approche hybride conserve donc sa capacité de détection fiable et automatisée tout en laissant la possibilité avec une expertise humaine d’adapter simplement et rapidement les règles de contrôle et de filtrage dans la détection d’une cyberattaque via un email de phishing.

ia hybride cybersecurite

Nous sommes intervenus dans le cadre d’atelier/ soutien au métier, Conception et réalisation des services de décisions. Nous avons également dispensé des formations ODM dans la partie Métier.

Critères d’éligibilité d’un BRMS

moteur de regles brms

Critères d’éligibilité d’un BRMS

brms definition

Aux origines du BRMS (moteur de règles)

La technologie des moteurs de règles / BRMS ne date pas d’hier. Née sous l’impulsion des américains dans les années 70 avec notamment la conception et de l’algorithme de RETE, elle a connu ses premières gloires début des années 80 sous l’appellation des systèmes experts. Le moteur de règle est une technologie ayant considérablement évolué, en traversant des années plus creuses (les années 90) avant de rebondir, au début de la bulle Internet, en solution technologique de Business Rules Management System (BRMS).

Ainsi, aujourd’hui, une vingtaine d’éditeurs postulent sur ce segment technologique, pour la plupart américains. Pour autant, il s’agit pour les clients d’apprécier la pertinence ou non de l’usage d’un BRMS pour répondre à la problématique métier qui est la leur.

Alors, comment apprécier cette pertinence ?

Le BRMS en quelques mots

Tout d’abord, il s’agit de transposer la logique métier, historiquement codée dans le patrimoine informatique des entreprises ou issue de l’expertise humaine, en règles communément appelées règles SI ALORS. Néanmoins, le SI contient les conditions qui doivent être évaluées à VRAI pour que la règle soit éligible au déclenchement. Une règle éligible s’exécute, c’est-à-dire que le moteur de règles exécute les actions contenues dans la partie ALORS de la règle. Une règle exécutée peut permettre potentiellement qu’une autre règle devienne éligible et ainsi de suite.

Ainsi, un raisonnement logique apparait par le déclenchement successif des règles éligibles.

Voici un exemple :

brms comprendre

Par ailleurs, certains éditeurs fournissent en réalité 3 représentations possibles de la logique métier : les règles, les tables de décision (qui s’apparentent à une table de feuille Excel) et des arbres de décision.

Au final, l’objectif d’une technologie BRMS est bien d’améliorer la lisibilité de la logique métier répartie dans les applicatifs du SI et de permettre ainsi une meilleure maintenabilité de cette logique en créant une indépendance entre le contenu d’un ensemble de règles (service de règles) et la manière dont on le consomme au sein du SI.

Comment évaluer la pertinence ou non d’un BRMS ?

Malgré les avantages énoncés du BRMS, son usage n’est pas systématiquement pertinent au regard du contexte et de la problématique des entreprises qui se poseraient la question de l’utiliser.

De ce fait, il s’agit de vérifier un certain nombre de critères d’appréciation qui sont résumés ici :

La démarche de Pacte Novation est axée autour de la réalisation d’ateliers avec les différents acteurs partie prenante dans le futur projet, l’analyse et la retranscription des éléments recueillis durant ces ateliers, la rédaction de notes, et la restitution/présentation des conclusions aux instances de décision du client.

En tout état de cause, la clé du succès d’un projet BRMS est d’abord et avant tout, l’adhésion à cette technologie de toutes les parties prenantes du projet.

Nous vous proposons des solutions autour du système d’information, système expert, embarqué et édition de logiciels,  nous permettant de répondre à la plupart des exigences du marché. 

Pourquoi concevoir une architecture logicielle en microservices ?

architecture microservices

Pourquoi concevoir une architecture logicielle en microservices ?

L’architecture logicielle décrit les différents éléments d’une application et leurs intentions. La conception de l’architecture est donc une étape particulièrement cruciale du développement logiciel. De cette phase, va dépendre non seulement la stabilité, la robustesse ou encore la scalabilité d’une application, mais également le rapport coût /efficacité.

architecture microservices

Les objectifs de la structure en microservices

Depuis toujours, les deux objectifs principaux de toute architecture logicielle sont la réduction des coûts et l’augmentation de la qualité du logiciel ; jusqu’à présent, la réduction des coûts était principalement réalisée par la réutilisation de composants logiciels et par la diminution du temps de maintenance (correction d’erreurs et adaptation du logiciel). Quant à la qualité, cela s’exprimait à travers un ensemble de critères dont l’efficacité, la pérennité, la stabilité et l’interopérabilité. S’ajoutent aujourd’hui 2 nouvelles questions :  Comment réduire les empêchements au changement ? Et comment libérer les développeurs des contraintes de la complexité et du déploiement ?

Principes de l’Architecture microservices

Les applications logicielles étant de plus en plus gourmandes en consommation de ressources physiques des machines sur lesquelles elles s’exécutent, les entreprises utilisatrices doivent faire face à des coûts d’infrastructures plus importants, des problèmes éventuels de performances, ainsi qu’à des coûts de maintenabilité. C’est pourquoi, depuis quelques années, la conception logicielle s’oriente vers une architecture Microservices (évolution de l’architecture SOA – Services Oriented Architecture).

Cette approche propose une solution extrêmement simple : une application logicielle voit son code découpé en modules fonctionnels ou techniques appelés microservices, parfaitement indépendants et donc autonomes, qui exposent une API REST (Application Programming Interface) permettant ainsi aux autres microservices de les consommer si besoin. Cela sous-entend que chaque microservice doit avoir son modèle de données de domaine et sa logique de domaine associés (souveraineté et gestion des données décentralisée). Il peut être basé sur différentes technologies de stockage de données (SQL, NoSQL) et sur différents langages de programmation.

Microservices, que des avantages ?

Les microservices affichent normalement une plus grande maintenabilité dans les systèmes d’informations complexes et hautement scalables, en permettant de créer des applications basées sur de nombreux services qui peuvent être déployés indépendamment, chacun ayant des cycles de vie granulaires et autonomes. On ne déploie plus une application monolithique mais seulement les services modifiés.

Autre avantage, les microservices peuvent monter en charge (scale out) de façon indépendante. Ainsi, vous pouvez effectuer un scale-out ciblé de la zone fonctionnelle qui nécessite plus de puissance de traitement ou plus de bande passante réseau pour satisfaire la demande, au lieu d’effectuer un scale-out d’autres zones de l’application qui n’en ont pas besoin.Par conséquent , les ressources physiques sont ajustables.

Nous vous proposons des solutions autour du système d’information, système expert, embarqué et édition de logiciels,  nous permettant de répondre à la plupart des exigences du marché. 

Apache Kafka, c’est quoi ?

apache kafka

Apache Kafka, c’est quoi ?

Le Framework Kafka a été développé initialement en 2011 chez LinkedIn puis mis à disposition par la fondation Apache depuis 2014. L’éditeur Confluent distribue également ce Framework en lui ajoutant des fonctionnalités intéressantes au sein de sa plateforme.

apache kafka

Qu'apporte le framework Kafka lancé par Apache ?

Kafka peut être défini de façon schématique comme un outil de diffusion de messages destinés à être lus par quiconque intéressé. Avec ce Framework, l’émetteur du message publie ce dernier dans un Broker sans savoir exactement qui va être intéressé par sa lecture. En plus du message originel, l’émetteur va ajouter des propriétés caractérisant ce message au moment de sa publication de façon à le typer. Chaque composant désirant lire des messages s’abonne au Broker en lui indiquant quels types de messages l’intéressent. Ainsi, dès qu’un nouveau message est publié par quiconque dans le Broker avec une typologie particulière, seuls les abonnés ayant souscrits à ce type de message seront notifiés de son arrivée, sans savoir qui l’a posté.

Kafka est donc une plateforme de distribution de messages – d’évènements, ou de logs selon la sémantique que l’on veut donner à l’information publiée – en temps réel, scalable et extrêmement fiable. Apache a constitué ce Framework afin qu’il puisse traiter des millions de messages par seconde en garantissant qu’aucun d’entre eux n’est perdu. L’ensemble des messages sont persistés sur disques dans des fichiers (principe de rétention). Leur suppression n’est effective qu’après l’écoulement d’un délai (par défaut 7 jour) ou si ces fichiers excèdent une taille donnée (1 Go par défaut). Le point essentiel est que la lecture d’un message ne le retire pas du Broker : il peut être lu à volonté par un même abonné ou généralement par plusieurs abonnés.

Apache Kafka peut à ce titre être considéré comme un système hybride entre une messagerie et une base de données.

Les composants de Kafka plus en détail

Faisons un zoom sur les constituants essentiels d’Apache Kafka pour bien fixer les idées.

Le cluster : le cœur du fonctionnement de Kafka

La mise en œuvre d’un serveur Kafka se fait par l’intermédiaire d’un cluster qui va regrouper les composants techniques essentiels, les Brokers. Le Broker est l’élément central par lequel vont transiter tous les messages depuis leur publication jusqu’à leur persistance sur disque, en passant par leur distribution vers les consommateurs. Afin de rendre le plus robuste possible un serveur Kafka, ce Broker est redondé par l’intermédiaire d’un autre Broker, voire plusieurs. Le Broker principal est nommé leader, les autres sont les réplicas. Les producteurs se connectent sur le leader pour publier leurs messages.

En plus de ces Brokers existe également un Broker Controller dont le rôle est d’assumer la gestion technique du cluster dans son ensemble et d’effectuer son monitoring. Chaque cluster Kafka contient donc au moins 3 Brokers : le leader, un réplica et le Controller.

Les messages et Topics

Un message contient la donnée, quelle qu’elle soit, qui va être envoyée par les producteurs dans le Broker. Il est intéressant de noter qu’un producteur peut envoyer des messages par batch, on parlera alors de groupe de messages. Chaque message envoyé concerne un Topic particulier qui a pour vocation de caractériser le message, et ainsi cibler les consommateurs concernés par ce dernier. Kafka autorise une gestion très fine de ces Topics en les découpant en partitions pour une gestion fine de leur redondance et de leur performance. Mais ceci est une autre histoire…

Les producteurs et les consommateurs

Ils n’ont plus de secret pour vous maintenant : un producteur écrit un message dans le Broker concernant un Topic en particulier. Chaque consommateur s’abonne au Broker pour les messages liés aux Topics qui les intéressent. Et lorsque qu’un message est posté, tous les consommateurs concernés par le Topic du message sont notifiés. Pour rappel, la lecture d’un message ne l’enlève pas du Broker, c’est la politique de rétention qui gère la durée de vie des messages au sein du serveur Kafka.

Dans la version Kafka de l’éditeur Confluent, un moteur de requêtes ksqlDB est également présent offrant ainsi aux producteurs et aux consommateurs une interface simple pour toute la manipulation des données dans le Broker. Un formalisme proche du langage SQL est ainsi disponible avec toutes les facilités afférentes.

cluster kafka apache

Kafka pour faire quoi ?

Le champ des possibles est assez vaste, et il serait fastidieux de dresser la liste exhaustive des cas d’usage pour lesquels Kafka se positionne correctement. Sa capacité à traiter sous la forme de flux des millions de messages par seconde peut s’appliquer à de nombreux domaines. Citons quelques exemples.

En tant que producteur, toute sorte d’application peut aller écrire des messages sur un serveur Kafka. En particulier les services ou micro services collectant des données venant du terrain par le biais de capteurs (appareils connectés, matériel médical, lignes de montage), des WebServices interrogeant des Data Center pour diffuser des évènements essentiels pour un domaine métier (finance, assurances, e-commerce), des services générant des logs de supervision, etc.

Du coté des consommateurs, tout applicatif intéressé par l’ingestion de données à la volée et/ou volumineuse est candidat : bases de données devant persister les données intéressantes, applicatif élaborant des rapports/synthèses, BigData, plateformes de traitement ETL, et bien sur tout type d’application métier et temps-réel.

Pour finir, quelques exemples de sociétés ayant mis en œuvre Kafka pour traiter en temps-réel les données en masse qui constituent leur cœur de métier (messages, notations, avis…) : Twitter, Netflix, Paypal, LinkedIn, Tinder, Uber.

Nous vous proposons des solutions autour de l’ingénierie logicielle : systèmes d’information, systèmes embarqués, édition logiciels… Découvrez nos expertises sans plus attendre !