Protection de la marque - lutte contre le typo-squatting

Protection de la marque - lutte contre le typo-squatting
Pour l’annotation « ShortDescription », l’analyseur n’a pas pu déterminer un code de langue (par ex. « foo@en »).
Statut	Développé
	Catégorie : Cas d'usage

Descriptif du use case[modifier | modifier le wikicode]

L’objectif du use case est de détecter les noms de domaine approchant celui d’un site qu’on souhaite protéger pouvant contribuer à diverses fins malveillantes : impact d’image, réalisation de campagnes de phishing à destination du grand public ou à destination de salariés, utilisation du domaine dans des fraudes via du MITitM (Man-in-the-middle), vente de produits contrefaits, etc. · Fournir des outils de détection des sites malveillants copiés · Fournir des outils de classification à base d’IA permettant d’identifier la proximité du site malveillant copié avec le site initial et son niveau de danger afin de donner au SOC les outils de priorisation permettant d’identifier les domaines typo-squattés prioritaires. Ce use case a la de particularité de peu utiliser les données classiques du corpus Cyber (trame réseau, etc.) mais plus sur des outils traditionnels du traitement automatique du langage.

Approche[modifier | modifier le wikicode]

L’approche sélectionnée passe par trois étapes :

Etape 1 : génération des noms de domaines cibles à partir d’un nom de domaine maitre via une distance de levenshtein (1, 2 ou 3) notamment via l’outil dnstwist https://github.com/elceef/dnstwist (ou son implémentation en ligne https://dnstwist.it/)
Etape 2 : classer les sites comme suspects si l’une des conditions suivantes est valide

- Le « name server » est different du « name server » initial (« l’original »)

- Le MX (Mail eXchanger) n’est pas défini ou n’est pas le MX « original »

- L’IP ne correspond au site initial, ou n’est pas white-listé (y compris pour le MX)

- S’il n’y a pas d’IP & pas de MX : le site est classé dans « à surveiller plus tard »

- S’il n’y a pas d’IP & mais un MX : segment à part à traiter par ailleurs, potentiellement dangereux

- Note : l’analyse du Registrar est une option à traiter plus tard

- Un passage vers Virustotal pourra aider à classifier

Etape 3 : Pour chaque site suspect, générer une représentation via un outil de NLP (thèmes / entités/ émotions ), puis calculer la similarité de la représentation avec celle du site initial (distance). Une forte similarité augmente le danger de phishing.

Données[modifier | modifier le wikicode]

Les datasets kaggle identifiés :

- https://www.kaggle.com/xwolf12/malicious-and-benign-websites

- https://www.kaggle.com/dmrickert3/malicious-and-benign-websites-learning/notebook

Un article utilisant une génération de domaine et le site VirusTotal explique une partie de la démarche et fournit sa méthodologie :

- https://towardsdatascience.com/predicting-the-maliciousness-of-urls-24e12067be5

- https://eneyi.github.io/2020/04/01/predicting-the-maliciousness-of-urls.html

- Les données sont là : https://github.com/eneyi/dataarchive/tree/master/pmurls/data/featurized

Les bases seront générées en temps réel à chaque nouveau « run » de l’algorithme, mais le parsing peut potentiellement être fortement consommateur de CPU.

Catégories d'algorithmes utilisés[modifier | modifier le wikicode]

Traitement automatique du langage.

Besoin en temps de calcul[modifier | modifier le wikicode]

Moyen s’il n’y a pas de ré-apprentissage des modèles NLP. Dans le cas où les corpus de texte du site initial sont loin du langage courant (domaine très technique), ces ré-apprentissages (fine tuning) peuvent être nécessaires.