Modifier Cas d'usage : Protection de la marque - lutte contre le typo-squatting

Description free text : Enregistrez pour pouvoir passer à l'éditeur visuel.

== Descriptif du use case == 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 == 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 == 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 == Traitement automatique du langage. == Besoin en temps de calcul == 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. == Cloud ou On Premise == Les deux sont possibles. == Autres logiciels nécessaires == ETL, qualité, sécurité, crypto, anonymisation En local deux outils seront nécessaires : ::- uUn crawler (par exemple Nutch https://nutch.apache.org/) ::- Stockage des sites et indicateurs : principalement elasticsearch == Mitre Att@ck == * Reconnaissance : ::- T1593 : Search Open Websites / Domains ::- T1598 : Phishing for Information * Initial Access : ::- T1566 : Phishing == Mitre Defend == N/A == Cyber Kill Chain == Suppression des accès pour les clients compromis (déjà en place), dépendance avec la capacité à faire tomber les sites « copies ».

Catégories liées[modifier | modifier le wikicode]