C&ESAR 2017 - J3
La Cyber Threat Intelligence.
La CTI consiste à comprendre les comportements de l’attaquant (TTP, killchain, toussa…) en se basant sur un ensemble de sources d’informations. A partir de ces sources d’informations, on va pouvoir partir à la chasse aux attaquant et en liant nos découvertes techniques à nos sources d’information externe on va pouvoir dresser un profil complet de ceux qui nous attaquent.
Pour modéliser l’ensemble de ces information et leurs relations avec les attaquant on dispose de modèles comme STIX. On peut simplifier ce modèle bien évidement. A partir des traces laissés par les attaquants sur le système (les IOC ou Artifacts), on va dégager un modus operandi et essayer d’identifier quels sont leurs intentions, et leur niveau de ressources. On structure les actions de l’attaquant sur un SI autour de la notion de campagne. Une campagne est bornée dans le temps parcequ’un attaquant fait évoluer sa façon de procéder. On parle alors de TTP: Tactiques, Techniques et Procédures.
La Threat Intelligence est trop souvent pensée autour des Indicateurs de Compromission (IoC). On peut travailler sur 4 niveaux lorsqu’on apporte des informations de Threat Intelligence. Au niveau Stratégique lorsqu’on s’addresse au top management. Au niveau Conception pour les architectes des SI afins qu’il prennent en compte les modus-operandi des attaquant afin de mieux faire évoluer la sécurité du SI. Au niveau Tactique pour les équipes d’ingéniérie de la sécurité, qui vont concevoir de nouveaux moyens de détection et de défense. Enfin au niveau Opérationnel, ou les SOC doivent lutter au quotidien contre ces menaces.
Les IoC sont souvent bêtement consommés lorsqu’elles sont fournies dans un format standard. Il vaut mieux fournir un flux de marquants très riche dans un format très basique comme CSV (perso je préfère JSON). L’opérateur peut en suite simplement les intégrer dans son SIEM / IDS / Whatever et avec un peu de chance il va trouver des choses… ou pas, parcequ’en fait, tout les attaquants ne vont pas forcément venir taper sur notre SI. Dans ce cas, on va pouvoir se baser sur la killchain pour stratégiquement venir détecter les comportement de l’attaquant.
Exemple de positionnement pour la détection: partir du principe qu’il est déjà dans le réseau, et venir identifier/détecter les résultat des actions de reconnaissance et de mouvement latéral en interne. Pour se faire l’attaquant se repose sur les outils d’administration régulièrement déployés. On va donc élargir le périmètre de supervision sur la base de ces éléments. Souvent les outils d’admins ne sont pas forcément loggués, et ne remontent donc pas dans le SIEM. Ex; l’eventID 4688 qui log le lancement d’un programme.
Une fois la détection faite, il serais de bon ton de venir rendre le travail de l’attaquant galère et bien plus lent. En se basant sur un grand nombre de rapports sur les attaquants, on peut se rendre compte que l’attaquant à souvent une boite à outils majoritairement orienté sur windows. Souvent il va essayer d’atteindre l’Active Directory, obtenir les privilèges d’administrateur de domaine puis il va exfiltrer ses données. Du coup ça va se traduire en des traces & actions sur le SI qu’on va pouvoir durcir afin de donner l’avantage à la Blue Team. Par exemple en utilisant un modèle par couches de sécurité (avec les techniques de cloisonnement présenté à SSTIC par l’ANSSI). Le cloisonnement va forcer l’attaquant à faire des efforts pour se propager dans le réseau.
Par contre transformer un AD, ça coûte super cher, et on peu se poser la question du ROI de ces actions de durcissement. Plus les attaques sont sophistiqués, plus elles sont rares. La mise en oeuvre d’un cloisonnement à l’état de l’art place la barre assez haut pour les attaquants même de type APT, et ça vaut le coup.
Leak, Data Privacy and Hacking.
Les personnes sont de plus en plus connectés, avec de plus en plus d’IoT autour d’eux. Ces communications ne représentent pas des gros volumes, mais une grande fréquence de communication. L’empreinte numérique des individus est de plus en plus grande. A partir d’un ensemble de leaks de bases de données sur l’internet, on se retrouve avec un grand nombre de mail, n° de cartes de crédit, n° de sécurité sociale, passwords, etc… A l’aide d’algorithmique des graphs, on va venir corréler les informations issues de ces leaks. Cette corrélation va se faire par exemple sur les indications de mot de passe, ou la valeur du hash du mot de passe non salé, etc… Du fait des pratiques de changement de mails ou d’emploie d’e-mails jetables, l’intersection entre les bases est plutôt faible.
Du coup en utilisant des fonctions de mot de passe oublié, une mauvaise pratique de ces dernières années consistait à montrer une partie de l’e-mail ou du n° de téléphone, et grâce à ça on peut venir reconstruire tout ou partie de ces information et les corréler.
Autre méthode de corrélation entre les e-mails: les données de signature des bases PGP disponibles publiquement. Pareil avec les données DNS / FQDN / Whois ou ceux qui enregistrent ou administrent sont regroupées sur un même enregistrement Whois. Etc…
La RGPD et les problématiques de vie privée en CTI.
Pérégrination de deux techniciens face à des problèmes juridiques. La rencontre d’un expert CTI et d’un spécialiste RGPD ont éclairé un paradoxe intéressant: en CTI on collecte des données sur des attaquant qui n’ont pas donné leur consentement tel que l’exige la RGPD. Lorsqu’une adresse IP est collectée, elle est à caractère personnel si elle permet d’identifier un individus avec des données additionnelles et que l’identité derrière cette IP est exigibles légalement. Si cette relation IP-Personne n’est pas « levable » par une entité, elle n’est pas considérée comme à caractère personnel.
En CTI on traite souvent des adresses e-mail, des wallet bitcoin, et si l’on peut faire le lien entre cet élément et l’individu, la donnée est à caractère personnel. La CTI peut être conduite par des personnes privés, mais aussi par l’état. Du coup les entreprises techniquement en avance ont toute légitimité à travailler sur la CTI et ont une pierre à apporter à l’édifice de la protection, mais elles ne disposent pas des protections juridiques pour les sécuriser vis à vis de la RGPD.
Du coup la RGPD à un gros impact sur le fonctionnement d’une architecture de CTI. La durée de conservation, la licéité de tels traitements, le consentement du cyber-attaquant, quid des leaks de bdd ? Heureusement que la LPM viens mettre en place pour les SOC/CSIRT les dégageant des obligations de collecte de consentement. Il existe des pistes légales pour résoudre certains de ces problèmes, mais pour d’autres éléments c’est loin d’être évident. Coté technique, on peut venir apporter des solutions issues du projet Virtuoso européen.
Exemple de problème: la pseudonymisation qui viens casser la distance informationnelle entre les donnée. Le chiffrement homomorphe viens apporter des réponse, mais l’industrie est loin d’être mature sur le sujet. Du coup une vraie question se pose entre Etat et acteur privés pour que la CTI puisse s’épanouir dans un environnement legislatif adapté.
