Comment développer une Cyber Threat Intelligence dans le cadre d’un SOC moderne ?

Qu'est-ce que la cyber threat intelligence ? Comment l'utiliser comme support opérationnel dans votre organisation ? Réponse dans cet article par Frédéric Boissel.

Sommaire

Découvrez comment utiliser la CTI comme Support Opérationnel (partie 1)

Introduction à la Cyber Threat Intelligence :

La Cyber Threat Intelligence est une discipline du renseignement appliquée au domaine cyber. Selon la doctrine analytique de Kent[1], le rôle des (Cyber) Intelligence Analysts est de fournir «des informations et des idées pour les décideurs politiques et les acteurs». Dans le contexte d’une entité complexe, qu’il s’agisse d’une institution ou d’une grande entreprise, de nombreuses fonctions différentes peuvent agir en tant que décideurs politiques et acteurs :

Gestion de la sécurité de l’information,
Analyse de risque,
Architecture sécurisée,
Réponse aux incidents,
SOC,
etc.

Toutes ces interfaces, et les informations à apporter, font de la Cyber Threat Intelligence une fonction transversale mais centrale. Dans cet article de blog, nous allons approfondir la manière dont la CTI peut adapter ses processus et outils pour fournir un soutien opérationnel à un acteur spécifique, le Security Operations Center (SOC). Le deuxième article de blog de la série expliquera comment la CTI peut prendre en charge une capacité plus spécifique du SOC : la chasse aux menaces.

On pourrait revenir sur les dernières années où le SOC a intégré les nouvelles technologies (SIEM / UEBA, IDS/IPS, NextGen Firewalls, DLP, EDR, NDR, xDR, SOAR, migration cloud, etc.)[2] nouvelles capacités (Réponse aux incidents, CTI, Threat Hunting, Vulnerability / Extended Threat Management…), a amélioré ses processus (automatisation, orchestration, machine learning, analytique…) et adapté à des événements disruptifs comme la pandémie de COVID-19 (nouvelles menaces, travail à distance , collaboration virtuelle…). Des structures héritées principalement impliquées dans le mode de détection passive, les SOC modernes sont désormais des centres d’opérations de cybersécurité hautement intégrés offrant une surveillance proactive et des mesures correctives réactives avec de nombreux processus automatisés, combinés à une expertise humaine.

Dans ce contexte, la CTI doit également adapter ses méthodes de travail aux nouveaux besoins en matière de renseignement, et doit adapter l’architecture de sa plateforme, la Cyber Threat Intelligence Platform (CTIP), pour assurer la diffusion du bon produit de renseignement à la bonne action, preneur ou décideur. Dans cet article de blog, nous allons parcourir les différentes étapes du cycle de production du renseignement et tenter de déterminer ce qui doit être anticipé et pris en compte pour combler les lacunes en matière de renseignement du SOC.

Le cycle de production du renseignement :

Les institutions de renseignement « traditionnelles » décrivent souvent le processus de production de renseignements dans un cycle appelé cycle du renseignement, ou cycle de production du renseignement. Bien que des variantes existent, il est généralement représenté comme un processus cyclique en 5 étapes, avec une évaluation et un feedback continus :

Fig. 1: Le processus de production du renseignement

Il ne s’agit peut-être pas du processus de production de renseignement le plus récent et le plus optimisé, même s’il peut servir de base et sera utile pour illustrer cet article.

Planification et exigence

Cette étape du processus décrit la gestion de l’ensemble des efforts de renseignement, depuis l’identification du besoin de données jusqu’à la fourniture d’un produit de renseignement pertinent à un consommateur pour combler un manque de connaissances. Il est temps d’identifier les acteurs (par exemple les analystes SOC, les chasseurs de menaces, les intervenants en cas d’incidents…), les décideurs (DSI, RSSI, gestionnaire d’incidents…) et les cas d’utilisation associés que vous allez soutenir avec la livraison de l’Intelligence. Les meilleures pratiques incluent :

Co-définir les besoins en matière d’intelligence avec le consommateur d’intelligence,
Garder l’exigence de renseignement simple (une seule question par exigence),
Définir le format du produit final d’Intelligence,
Planifier toutes les étapes du cycle de production du renseignement, y compris les étapes de validation et de retour d’information.

Des exemples d’exigences en matière de renseignement pourraient être :

Pour les opérations de sécurité proactives :
- « Quels sont les attaquants qui peuvent être considérés comme une menace pour mon entreprise (modèles de menace) ?»
- « Quels indicateurs (IoCs, IoAs…) peuvent être utilisés pour détecter des Adversaires spécifiques sur le périmètre que je dois défendre ?»

Pour la chasse aux menaces :
- « Quelles requêtes doivent être effectuées sur mes systèmes d’information pour détecter des adversaires spécifiques tentant de contourner les moyens de sécurité lors des activités de Threat Hunting ?»

Pour les enrichissements des alertes de sécurité SOC :
- « Quels enrichissements CTI peut-il apporter aux artefacts contenus dans une alerte de sécurité SOC? »

De nombreuses exigences différentes en matière de renseignement pourraient être définies avec les acteurs du SOC ou même avec les décideurs (par exemple, CIO, RSSI…). De premières synergies pourraient commencer à apparaître. Par exemple, différents acteurs ou décideurs peuvent partager des exigences en matière de renseignement, redouter des impacts similaires ou même montrer des chevauchements dans leurs modèles de menaces.

Collection

L’étape de collecte est le processus d’acquisition des données brutes provenant de toutes les sources identifiées comme nécessaires pour répondre à une exigence de renseignement au cours de l’étape de planification et d’orientation. Il existe une infinité de sources pouvant être collectées :

Données internes : données provenant de l’intérieur de mes systèmes d’information :
- Journaux système et réseau,
- Alertes de sécurité SOC, incidents de sécurité,
- Télémétrie ou requêtes directes (EDR, NDR, SIEM…),
- Journaux d’applications,
- Rapports de réponse aux incidents,
- Rapports de chasse aux menaces,
- etc.

Les sources de données internes sont particulièrement précieuses dans un environnement SOC. Chaque information collectée ou tout comportement malveillant observé sur un périmètre peut apporter des informations précieuses et permettre une augmentation globale du niveau de sécurité en ajustant la posture de sécurité en conséquence. Avoir accès aux sources de données internes pertinentes devrait être une priorité pour une équipe CTI, car cela permettrait une contextualisation précise de chaque détection remontée par le SOC.

Données Externes : données provenant de sources extérieures à mes Systèmes d’Information :
- Rapports de menaces (OSINT, community, commercial),
- Flux (OSINT, Community, Commercial),
- Bases de données de logiciels malveillants (OSINT, Community, commercial),
- etc.

Dans une perspective d’intégration CTI, il est important de pouvoir collecter toutes les sources au niveau CTIP, permettant de capitaliser toutes les connaissances dans une seule base de données, avec un modèle de données structuré cohérent et uniforme. Cet objectif sera atteint grâce à la prochaine étape du processus.

Traitement et exploitation

L’étape Traitement & Exploitation consiste à synthétiser les données brutes dans un état utilisable. Dans notre cas, il s’agit d’extraire les informations nécessaires à vos analyses à partir des sources collectées, et de les stocker dans un modèle de données cohérent et structuré. Comme cette étape n’apporte pas vraiment de valeur ajoutée pour les sources de données externes, des efforts d’automatisation pourraient être pertinents (ex : connecteurs de flux).

Le CTIP commercial et open source est livré avec différents modèles de données structurés. Mais il peut être intéressant d’opter pour un standard dans un environnement système d’information qui peut être hétérogène en termes de solutions technologiques. Le “Structured Threat Information Expression”[3] (STIX™) est un langage et un format de sérialisation utilisés pour échanger des CTI. Il s’agit d’un standard ouvert produit par le comité technique OASIS Cyber Threat Intelligence.[4].

En plus d’être pertinent pour tous les processus CTI, il intègre des fonctionnalités très intéressantes qui peuvent être exploitées pour le support opérationnel du SOC, telles que l’objet relationnel Sighting STIX.[5], indiquant la croyance que quelque chose a été vu (indicateur, logiciel malveillant, campagne…) ou l’objet de domaine STIX du plan d’action[6], décrivant une action à entreprendre soit pour prévenir une attaque, soit pour répondre à une attaque en cours. Un objet STIX central dans le contexte d’un SOC est l’objet de domaine indicateur STIX. Il contient un modèle qui peut être utilisé pour détecter une cyberactivité suspecte ou malveillante. Le STIX™ prend en charge différents modèles pour exprimer les indicateurs (modèle STIX, expressions régulières compatibles Perl, Sigma, SNORT, Suricata, YARA) dans le cadre de son vocabulaire ouvert de type de motif.[7], et cela ne limite pas l’utilisateur à cette liste définie. Ce vocabulaire peut être complété par l’utilisateur avec d’autres modèles d’Indicateurs. Les formats supportés nativement par le standard STIX™ permettent un échange d’informations fluide, tandis que sa flexibilité permet l’intégration de cas d’usage plus spécifiques.

Une fois l’information captée, elle peut être enrichie. Le but de l’enrichissement est d’ajouter des informations à vos informations, c’est-à-dire d’ajouter un contexte qui soutient l’analyse et la prise de décision. Différents services web, commerciaux ou non, peuvent être utilisés pour ajouter du contexte (recherche WHOIS, géolocalisation, réputation…). Des investigations et des pivots peuvent également être effectués, afin de découvrir de nouvelles informations connexes. Une fois de plus, les services Web peuvent être exploités pour soutenir cet effort (enregistrements DNS/pDNS, algorithmes de hachage Portable Executable, certificats de signature de code, certificats SSL, bases de données de logiciels malveillants, etc.). Comme les Enrichissements et les Pivots peuvent être fournis en tant que services à d’autres fonctions que CTI, il pourrait être intéressant de garder ces capacités disponibles au niveau SOAR, et de les appeler via des playbooks pertinents.

Analyse & Production

L’analyse et la production de renseignements sont la conversion de vos informations collectées et traitées en renseignements. Cela comprend l’analyse, l’évaluation et l’analyse de toutes les données disponibles, ainsi que la préparation des produits de renseignement finaux, depuis les informations diffusées séparément (par exemple, les IoC), jusqu’aux rapports finaux qui rassemblent des informations distinctes pour identifier des modèles et tirer des conclusions. Il est temps d’utiliser vos techniques d’analyse structurée pour atténuer les biais cognitifs et les erreurs logiques, et pour évaluer la fiabilité, la validité, l’actualité et la pertinence des renseignements produits, ce qui doit inclure une évaluation et des jugements sur l’implication pour les acteurs et les décideurs.

En termes d’outils techniques, certaines capacités pourraient s’avérer utiles pour fournir un renseignement tactique et opérationnel adéquat. A titre d’exemple, on peut penser à un Malware Sandbox pour observer en toute sécurité le comportement des malwares dans un environnement contrôlé. Certains Malware Sandbox disposent de moteurs d’analyse supplémentaires basés sur la détection antivirus ou l’analyse statique. Une telle technologie pourrait nous permettre d’extraire rapidement les IoC des logiciels malveillants et de donner quelques idées sur les actions effectuées par les logiciels malveillants sur l’environnement de la victime, et ainsi d’élaborer des requêtes de chasse aux menaces pertinentes pour vérifier l’infection des systèmes d’information surveillés.

Comme ces capacités pourraient également être fournies en tant que services à d’autres fonctions que CTI, il est possible de les maintenir disponibles au niveau SOAR et de les appeler via des playbooks pertinents.

Dissémination

Maintenant que les renseignements sur les cybermenaces sont produits dans le bon format, ils doivent être envoyés au bon preneur d’action ou au bon décideur pour combler son manque de connaissances. Encore une fois, dans un environnement informatique hétérogène, opter pour un standard est souvent le bon choix. En parallèle du STIX, le comité technique OASIS Cyber Threat Intelligence précise le Trusted Automated Exchange of Intelligence Information (TAXII™)[8], un protocole d’application pour l’échange de CTI sur HTTPS. TAXII™ définit une API RESTful et un ensemble d’exigences pour les clients et serveurs TAXII.

D’un autre côté, TAXII ne définit pas l’accord de confiance, la gouvernance et d’autres aspects non techniques du travail collaboratif. Il est important de définir ces éléments pour gérer les limites du partage de renseignements potentiellement sensibles. Le protocole des feux de circulation (TLP)[9] est couramment utilisé dans ce contexte d’échange d’informations.

La diffusion proprement dite peut se faire selon ce qui a été défini avec les acteurs et les décideurs lors de l’étape de planification et d’exigence, via un playbook dédié et adéquat au niveau SOAR. Cela garantirait que les solutions de sécurité reçoivent automatiquement les renseignements qu’elles sont capables de traiter et que les humains impliqués reçoivent les renseignements attendus dans le format approprié. Les CTIP intègrent généralement un système de marquage qui peut être exploité par les playbooks pour garantir une diffusion appropriée.

Architecture fonctionnelle et technique proposée par CTI

Afin de résumer le contenu de cet article de blog, voici une proposition d’architecture CTIP dans le contexte d’un SOC moderne, incluant les étapes du processus CTI du cycle de production du renseignement :

Fig. 2: Architecture CTIP proposée

Dans le prochain épisode de cette série d’articles de blog, nous discuterons de la manière dont CTI peut soutenir les activités de Threat Hunting, y compris les exigences, les processus et les outils.

Bibliographie