feed MISP ANSSI - OpenCTI

Dates des modifications :	Intervenants :	Modifications apportées :
-	Matthieu BILLAUX @_euzebius	Nhammmber One Mentor !
Lundi 11 Juillet 2022	Mudsor MASOOD mudpak	Mise à jour vers blog (v1.0.1)
Dimanche 3 Juillet 2022	mudpak	Finalisation du document (v1.0.0)
Samedi 3 Juillet 2022	mudpak	Ajout de la partie MISP et OpenCTI (v0.0.5)
Samedi 2 Juillet 2022	Thomas ROCCIA @fr0gger_	Aide Technique (v0.0.4)
Vendredi 1er Juillet 2022	CERT-FR ANSSI	Aide Technique (v0.0.3)
Jeudi 30 Juin 2022	mudpak	Mise en place du Lab (v0.0.2)
Mercredi 29 Juin 2022	mudpak	Création du document (v0.0.1)

0. Avant-propos

Cet article a pour but de guider l’utilisateur dans la mise en place:

de la réception du feed MISP ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information)
d'une instance MISP locale
d'une instance OpenCTI locale et de l'interconnecter avec le MISP local

Disclaimer :

Il est important de préciser que l'ANSSI a apporté son aide sur son feed MISP.
L'ANSSI n'est absolument pas garante ni des choix d'implémentations et ni de la sécurité proposée dans cet article, car ce sont des choix totalement personnels.

0.1 Remerciements

Je tiens particulièrement à remercier les équipes ANSSI pour la rapidité et clarté des réponses apportées.
En effet j’ai tenté de mettre en place le projet mais il me manquait une information cruciale qu’ils m’ont fourni et sans laquelle il m’était impossible de continuer.

Merci également aux comrades :

qui m’ont aidé à comprendre certaines commandes et trouvé des solutions aux blocages.

0.2 Annonce ANSSI

Suite à l’annonce via Twitter de l’ANSSI le Mardi 28 Juin 2022, il est désormais possible de recevoir un feed public qu’ils fournissent via leur instance MISP.

Remarque :

C'est bien un "feed" MISP qui est mis à dispostion et non une instance MISP.

Important :

Au moment de la rédaction de cet article il faut obligatoirement une instance MISP locale également pour recevoir les données.

Il n’est donc pas possible de recevoir les données depuis le feed MISP ANSSI vers une instance OpenCTI directement.

Nous allons voir comment outrepasser cette limite car l’objectif est tout de même d’intégrer ces données à notre instance OpenCTI.

Voici à quoi ressemble le feed public en accès web :

https://misp.cert.ssi.gouv.fr/feed-misp/

1. Prérequis

Pour la mise en place du lab nous allons avoir besoin :

Des accès administrateur / root sur les machines
- Ou tout du moins des accès avec des privilèges élevés
D’un accès internet pour télécharger les différents paquets et outils
D’une machine qui servira d’hôte
- Dans notre cas nous avons choisi un serveur Ubuntu 22.04 LTS
- Vous pouvez choisir un autre système puisque les installations seront faites via des containers Docker
De l’adresse du MISP de l’ANSSI
D’un compte dédié pour le connecteur MISP dans OpenCTI
- Pour des raisons de sécurité nous allons appliquer la bonne pratique qui consiste à dédier un compte de type « connecteur »

2. Feed MISP ANSSI -> MISP local -> OpenCTI local

Comme expliqué précédemment le but est donc de récupérer les informations du feed MISP public de l’ANSSI pour les intégrer à notre instance locale OpenCTI, or à cet instant il n’est pas possible de faire cette opération directement.
Pour pallier ce « problème » nous allons simplement mettre un serveur intermédiaire (MISP local) qui va d’une part récupérer les informations du feed MISP ANSSI et d’autre part envoyer ces mêmes données vers notre instance OpenCTI locale.
D’un point de vue sécurité cela rajoute une contrainte, mais d’un autre côté dans un contexte professionnel il est très probable que vous utilisiez déjà une instance MISP depuis laquelle d’autres instances CTI viennent s’alimenter.

Expliqué autrement voici le raisonnement suivi :

feed MISP ANSSI :

L’instance envoie des données
Nous n’avons aucun droit utilisateur sur cette instance

MISP local :

Cette instance reçoit les données du feed MISP ANSSI
Cette instance envoie les données vers OpenCTI local
Nous avons tous les droits sur cette instance puisque nous la gérons
Ainsi nous pouvons générer des accès spécifiques pour que l’instance OpenCTI puisse venir requêter
La notion de « clé MISP » ou « Auth key » dans le connecteur OpenCTI sera vue par la suite

OpenCTI local :

Cette instance reçoit les données du MISP local
Nous avons tous les droits utilisateurs sur cette instance
Nous allons configurer un connecteur pour recevoir les données depuis le MISP local

3. Ubuntu Server 22.04 LTS

L’hôte qui va héberger toute l’infrastructure est une distribution Ubuntu Server dans sa version 22.04 LTS (Long Term Support).

Avant d’aller plus loin nous allons effectuer quelques opérations de base pour pouvoir travailler dans les meilleures conditions.

3.1 Nom du serveur

Pour qu’il soit plus aisé pour se repérer et aussi puisque j’utilise un template d’une machine préinstallée, je vais modifier le nom de la machine pour l’adapter au projet.

3.1.1 Affichage du nom actuel

Pour afficher le nom de la machine, saisir la commande suivante :

1	`hostname`

Détails de la commande :

hostname
  > permet d’afficher le nom de l’hôte

Nous pouvons observer les informations suivantes : - 1 : la commande saisie - 2 : le nom actuel de la machine

3.1.2 Changement du nom du serveur

Pour changer le nom de la machine nous allons modifier le fichier de configuration « /etc/hostname », pour cela saisir la commande suivante :

sudo nano /etc/hostname

Détails de la commande :

sudo
  > pour exécuter la commande avec des privilèges élevés

nano
  > un éditeur de texte simple

/etc/hostname
  > le fichier de configuration à modifier

1 : la commande saisie
2 : avant de pouvoir modifier le fichier il nous est demandé de renseigner le mot de passe de notre compte

3.1.3 Affichage du nouveau nom

Lorsque le fichier a été modifié, nous pouvons afficher le nom de l’hôte via la commande suivante :

cat /etc/hostname

Détails de la commande :

cat
  > permet d’afficher le contenu du fichier dans le cas présent

1 : la commande exécutée

2 : le nom qui a été renseigné dans le fichier de configuration, cependant ce n’est pas pour autant que le nom de la machine a changé

3.1.4 Redémarrage du serveur

Pour prendre en compte les changements, nous allons redémarrer la machine, saisir la commande suivante :

1	`sudo reboot`

Détails de la commande :

reboot
  > permet de demander un redémarrage de la machine

3.2 Mise à jour du système

Un nouveau nom a été défini pour refléter du projet, mais notre distribution n’est pas forcément à jour.

3.2.1 Récupération de la liste des paquets et mise à jour

Saisir la commande suivante :

sudo apt update -y && sudo apt upgrade -y

Détails de la commande :

apt update -y
  > pour demander une mise à jour de la liste des paquets sans confirmation

&&
  > pour demander d’exécuter la commande suivante lorsque la commande précédente est terminée

apt upgrade -y
  > pour demander l’installation des mises à jour sans confirmation

1 : la commande
2 : demande de mot de passe, car cette opération requiert des droits élevés pour être exécutée

3.2.2 Réception des paquets

Les différentes étapes se succèdent et peuvent prendre un certain temps en fonction de votre connexion internet :

1 : récupération de la liste des paquets
2 : téléchargement des paquets
3 : taille totale des paquets et temps écoulé pour les récupérer

3.2.3 Installation des nouveaux paquets

Une fois que la récupération est terminée la phase d’installation commence :

1 : lecture des paquets récupérés
2 : pour afficher les paquets qui peuvent être mis à jour
3 : les paquets qui seront mis à jour
4 : la place que prendront les paquets
5 : l’espace disque qui sera occupé par les paquets

3.2.4 Finalisation de la mise à jour et redémarrage des services

A la fin des différentes phases d’installations, si nécessaires certains services vont redémarrer pour appliquer des mises à jour :

1 : dans le cas présent le kernel est à jour
2 : tous les services qui ont redémarrés
3 : les services qui vont redémarrés en différé
4 : d’autres informations plus générales

Docker Il est possible d’installer les instances de différentes manières, dans notre cas nous allons privilégier l’utilisation de Docker et de Docker-compose.

4.1 Installation

Par défaut docker n’est pas installé, nous allons procéder à son installation.

4.1.1 Récupération et exécution du script

Saisir la commande suivante :

curl -fsSL https://get.docker.com -o get-docker.sh

Détails de la commande :

curl
  > utilitaire qui permet de transférer les données d’n serveur à un autre via différents protocoles (http, https, ftp …)

-f
  > pour «--fail »
  > permet de mieux gérer les tentatives infructueuses dans le script

-s
  > pour «--silent»
  > afin de ne pas afficher les barres de progression  et ni les messages d’erreurs

S
  > pour «--show error»
  > pour afficher les messages d’erreurs

L
  > URL à spécifier

https://get.docker.com
  > l’URL depuis laquelle le contenu doit être récupéré

-o
  > pour «--output»
  > pour demander un fichier de sortie

get-docker.sh
  > le nom du fichier de sortie

4.1.2 Vérification de la récupération

Pour vérifier que nous avons bien reçu le fichier, saisir la commande suivante :

ls -al | grep get-docker.sh

Détails de la commande :

ls 
  > pour « LiSt »
  > pour lister le contenu d’un répertoire

-a 
  > pour afficher les fichiers et dossiers cachés

l
  > pour afficher en format long

|
  > symbole « pipe » pour envoyer les résultats à la commande suivante

grep
  > pour afficher uniquement le contenu qui correspond à nos critères

get-docker.sh
  > élément sur lequel filtrer

1 : la commande utilisée
2 : nous voyons bien le fichier qui a été récupéré

4.1.3 Exécution du script

Pour lancer l’installation de docker, saisir la commande suivante :

sh get-docker.sh

Détails de la commande :

sh 
  > équivalent de « ./ »

get-docker.sh
  > script à exécuter

1 : la commande utilisée
2 : la version du script exécuté
3 : mot de passe à renseigner

4.1.4 Processus d’installation

Voici les différentes étapes de l’installation :

4.1.5 Docker Client et Docker Server

Lorsque l’installation est terminée nous obtenons un affichage similaire à ci-dessous :

1 : informations sur le client Docker
2 : informations sur le serveur Docker

4.1.6 Docker rootless

Remarque :

Pour des raisons de sécurité il est recommandé d’utiliser le mode « docker rootless ».
Nous n’allons pas l’utiliser car nous sommes dans un environnement de lab.

4.2 Gestion des droits

Avant de créer des containers nous allons vérifier et mettre à jour les droits.

4.2.1 Vérification des droits

Nous allons saisir deux commandes distinctes pour voir si nous pouvons les exécuter :

docker ps

docker images

Détails des commandes :

docker
  > programme à utiliser

ps
  > pour lister les processus

images
  > pour lister les images

1 : le résultat de la commande nous informe clairement que nous n’avons pas les droits pour l’exécuter
2 : une autre commande affiche un résultat similaire

4.2.2 Changement des droits

Nous allons ajouter notre compte utilisateur pour pouvoir utiliser docker, pour cela saisir la commande suivante :

sudo usermod -aG docker mudpak

Détails de la commande :

usermod
  > commande pour modifier un compte utilisateur

-a
  > pour ajouter un utilisateur à un nouveau supplémentaire

G
  > pour spécifier un groupe auquel ajouter l’utilisateur

docker
  > nom du groupe auquel nous souhaitons ajout l’utilisateur

mudpak
  > l’utilisateur a ajouter au groupe « docker »

1 : commande utilisée
2 : commande pour se déconnecter de la session

4.2.3 Vérification de l’application des changements

Nous pouvons à nouveau lancer les mêmes commandes et cette fois-ci il n’y a pas de message d’erreur.
Il est tout à fait normal qu’il n’y ait pas de processus en cours ou d’images car nous n’avons lancé aucun container ou utilisé aucune image à ce stade.

5. Docker-compose

Nous avons installé docker dans le chapitre précédent, mais pour gérer des nombreux containers et les interconnecter il est plus facile de le faire avec Docker-compose.

5.1 Installation

Pour installer docker-compose il est possible de le faire via les dépôts officiels ou manuellement, dans notre cas nous allons utiliser les dépôts officiels, saisir la commande suivante :

sudo apt install docker-compose

Détails de la commande :

docker-compose
  > paquet à installer

1 : commande utilisée
2 : mot de passe à renseigner

Différentes étapes se succèdent lors de l’installation :

1 : lecture des paquets
2 : les nouveaux paquets qui seront installés
3 : confirmation avant leur installation

5.2 Vérification de l’installation

Lorsque l’installation est terminée, nous pouvons saisir par exemple la commande suivante pour voir la version installée :

docker-compose - - version

Détails de la commande :

docker-compose
  > programme à utiliser

--version
  > paramètre pour afficher la version

1 : commande utilisée
2 : version de docker-compose

MISP Maintenant que docker et docker-compose sont installés, nous allons pouvoir passer à la partie la plus longue qui est dédiée à la mise en place et configuration du MISP en vue de la réception mais aussi envoie des données.

6.1 Récupération du script

Saisir la commande suivante :

git clone https://github.com/MISP/misp-docker

Détails de la commande :

git
  > programme à utiliser

clone
  > paramètre, ici pour créer une copie locale d’un répertoire distant

https://github.com/MISP/misp-docker
  > adresse du répertoire à copier

1 : commande utilisée
2 : un nouveau répertoire nommé « misp-docker » a été créé contenant la copie du répertoire distant

6.2 Contenu du répertoire

Pour la suite nous allons nous déplacer dans le répertoire, saisir la commande suivante :

cd misp-docker

Détails de la commande :

cd
  > Change Directory
  > pour se déplacer dans un répertoire

misp-docker
  > le répertoire dans lequel nous souhaitons nous déplacer

1 : commande pour se déplacer dans le répertoire
2 : commande pour afficher le contenu du répertoire

6.3 Création d’une copie du fichier « .env »

Nous allons créer une copie du fichier « template.env » pour l’adapter à notre configuration.

Saisir la commande suivante :

cp template.env .env

Détails de la commande :

cp
  > pour "CoPy"
  > commande qui permet de faire une copie

template.env
  > élément à copier
  > ici un fichier par défaut

.env
  > le nom que portera la copie du fichier
  > ici « .env » comme « environment »

6.4 Contenu par défaut du fichier «.env »

Voici le contenu par défaut du fichier de configuration «.env » :

1 : commande pour afficher le contenu du fichier
2 : informations relatives à la base de données MySQL qui va stocker les données
3 : adresse email du compte administrateur de la plateforme
4 : mot de passe de connexion par défaut à l’interface web
5 : l’URL du serveur, ici c’est localhost ce qui signifie que seulement le serveur qui héberge la solution peut y accéder, ce qui peut être problématique car souvent les serveurs Linux ne disposent pas d’un environnement graphique
6 : le fuseau horaire

6.5 Mise à jour du fichier «.env »

Nous allons modifier un certain nombre de paramètre pour les adapter à nos besoins :

1 : l’URL du serveur remplacée par l’adresse IP du serveur
2 : fuseau horaire pour notre format, ici Europe/Paris

Remarques :

J’avais modifié les champs « MISP_ADMIN_EMAIL » et « MISP_ADMIN_PASSPHRASE » mais ce changement ne semblait pas avoir été pris en compte donc je laisse ici ces paramètres par défaut.

Si vous souhaitez modifier absolument ces deux informations, vous pouvez le faire via une solution de contournement en modifiant les champs directement dans le container une fois démarré (solution dans les sources).

6.6 Construction de l’image docker MISP

Le fichier « .env » étant modifié, nous n’avons pas besoin d’apporter des modifications sur d’autres fichiers.
Cependant il faut construire l’image docker du MISP.

Notez que les étapes ci-dessous bien qu’elles soient totalement automatisées, elles peuvent néanmoins prendre beaucoup de temps !
Nous allons tenter des fournir des détails sur certaines des étapes pour mieux comprendre les actions réalisées.

6.6.1 Step 1/26

C’est le début du processus :

1 : commande utilisée pour démarrer la construction des images
2 : la construction du container « web » est basée sur une distribution Ubuntu « Focal » (Ubuntu 20.04 LTS)
3 : c’est la première étape d’un processus contenant 26 étapes

6.6.2 Step 2/26

Le paramètre « ENV DEBIAN_FRONTEND non interactive » est équivalent à « export DEBIAN_FRONTEND="noninteractive" »

6.6.3 Step 3/26

Différentes commandes sont exécutées pour mettre à jour le système et installer des paquets :

6.6.4 Step 4/24

Un dépôt est ajouté à la liste, ainsi si des paquets spécifiques sont à installer depuis celui-ci il sera désormais possible :

6.6.5 Step 5/26

Mise à jour du système et installation de paquets :

6.6.6 Step 6/26

Mise à jour de « pip3 » :

6.6.7 Step 7/26

La commande « locale-gen » permet de générer des fichiers de paramètres régionaux à partir de modèles, ici le modèle utilisé est « en_US.UTF-8 » :

6.6.8 Step 8/26

Mise à jour des préférences linguistiques et de l’encodage :

6.6.9 Step 9/26

Création du compte utilisateur « misp » et ajout de ce même compte au groupe « sudo » :

6.6.10 Step 10/26

6.6.11 Step 11/26

Modification des droits du fichier « INSTALL_NODB.sh » pour le rendre exécutable :

6.6.12 Step 12/26

Ajout de la configuration dans le fichier « /etc/sudoers » :

6.6.13 Step 13/26

Exécuter une action en tant qu’utilisateur « misp » :

6.6.14 Step 14/26

Exécution du script en tant qu’utilisateur « misp » :

6.6.15 Step 15/26

Exécution d’une action en tant qu’utilisateur « root » :

6.6.16 Step 16/26

Mise à jour des modules python3 qui ne sont pas à jour :

6.6.17 Step 17/26

Ecriture des paramètres à la fin du fichier « /etc/supervisor/conf.d/supervisord.conf » :

6.6.18 Step 18/26

Ajout du script à la racine du système :

6.6.19 Step 19/26

Renommage du fichier « misp-ssl.conf » avec le nouveau nom « misp-ssl.conf.bak » pour avoir une copie du fichier initial :

6.6.20 Step 20/26

Ajout du fichier « misp-ssl.conf » dans le répertoire « /etc/apache2/sites-available/ » :

6.6.21 Step 21/26

Modification des droits du script « run.sh » et création du fichier « .firstboot.tmp » à la racine du système :

6.6.22 Step 22/26

Modification du répertoire de travail :

6.6.23 Step 23/26

Création d’une archive au format « tgz » en conservant les permissions des fichiers :

6.6.24 Step 24/26

Création d’un volume :

6.6.25 Step 25/26

Exposition du port 80 :

6.6.26 Step 26/26

Exécution du script « run.sh ».
Nous pouvons également noter qu’à l’issue de cette dernière étape le container a été créée :

6.7 Lancement de la stack MISP

Maintenant que les images ont été construites nous pouvons désormais lancer la stack MISP via la commande suivante :

docker-compose up -d

Détails de la commande :

docker-compose
  > programme à utiliser

up
  > pour démarrer la stack

-d
  > pour (--detach)
  > afin de lancer la stack en arrière-plan et reprendre la main sur le terminal

1 : commande utilisée 2 : un réseau spécial est créé pour la stack 3 : les containers sont téléchargés s’ils ne l’étaient pas depuis les étapes précédentes 4 : confirmation de la création du container « misp_db » qui va contenir la base de données 5 : confirmation de la création du container « misp_web » qui va héberger la partie web 6 : un lien est réalisé entre les deux containers puisque l’interface web va enregistrer les données dans la base de données

6.8 Vérification du lancement

Nous pouvons vérifier si la stack est bien lancée via la commande suivante :

1	`docker ps`

Dans le cas présent nous pouvons noter les informations suivantes :

1 : la commande utilisée
2 : la version du container misp lancée
3 : la version du container MySQL lancée
4 : le container MySQL est en status « starting » et n’a donc pas fini son démarrage

Quelques temps plus tard nous pouvons noter :

1 : le container misp « web » est bien démarré
2 : le container MySQL a terminé son démarrage et est passé en status « healthy »

6.9 Accès à l’interface web

Pour se connecter à l’interface web de MISP il faut se rendre à l’adresse suivante via un navigateur web:

https://IP-Instance-MISP

Remarque :

Il est également possible de se connecter en « http » puisque le port 80 est exposé, mais pour des raisons de sécurité ce n'est pas recommandé.

Puisque c’est un certificat auto-signé et non approuvé par une autorité de confiance un message d’avertissement s’affiche, cliquer sur

Paramètres avancés

Cliquer sur

Continuer vers le site IP-Instance-MISP (dangereux)

6.10 Connexion à l’interface

Remplir les champs suivants

Email
Password

Cliquer sur

Login

Remarques :

1 : si vous avez personnalisé l’adresse email de connexion et qu’elle ne fonctionne pas il est possible de réinitialiser les identifiants en se connectant au container, l’adresse email par défaut est « admin@admin.test »

2 : le mot de passe par défaut est « admin »

6.11 Changement du mot de passe

Lors de la première connexion nous sommes invités à changer de mot de passe :

1 : saisir le nouveau mot de passe
2 : confirmation le nouveau mot de passe
3 : saisir l’ancien mot de passe
4 : cliquer sur « Submit » pour confirmer l’action

Note :

Le nouveau mot de passe doit faire au moins 12 caractères et répondre aux caractères d’exigences de sécurités suivantes :

Lorsque le mot de passe a été changé le message ci-dessous s’affiche dans la zone supérieure gauche de la fenêtre :

Si votre mot de passe ne respecte pas les exigences de sécurité le message ci-dessous sera affiché :

6.12 Feeds

Maintenant que nous avons accès à l’interface web du MISP, nous allons pouvoir voir et configurer les feeds.

6.12.1 Liste des Feeds

Pour accéder aux feeds, cliquer sur

Sync Actions
List Feeds

La fenêtre ci-dessous s’affiche avec les informations suivantes :

1 : un identifiant unique est attribué à chaque feed
2 : est-ce que le feed est activé ou non ?
3 : est-ce que le contenu du feed a été mis en cache (dans le contexte actuel copié sur notre instance MISP)
4 : quel est le nom donné au feed, généralement on donne le même nom que le fournisseur du feed
5 : sous quel format sont reçues les informations
6 : quel est le fournisseur du feed
7 : quel type de feed c’est ? (Network = réception depuis internet, local = réception via le réseau local)
8 : quel est le lien source du feed
9 : différentes actions qu’il est possible de réaliser (nous les verrons par la suite)

6.12.2 Ajout d’un nouveau feed

Nous allons ajouter le feed de l’ANSSI, pour faire cela cliquer sur

Add Feed

6.12.3 Configuration du nouveau feed

Voici les différents éléments qu’il est possible de renseigner pour l’ajout d’un nouveau feed :

1 : Ici nous souhaitons ajouter un feed
2 : est-ce que le feed sera actif ou non ?
3 : est-ce que le contenu du feed sera copié sur notre instance ?
4 : le nom d’affichage du feed qu’on souhaite donner
5 : qui est le fournisseur du feed ?
6 : quel type de feed c’est ? entre « Network » et « Local »
7 : l’URL du feed
8 : sous quel format seront envoyées les données
9 : est-ce que nous souhaitons distribuer ce feed à toutes les communautés ou à certaines uniquement ?
10 : paramètre très important, il permet d’attribuer un tag aux évènements
11 : pour appliquer les changements

Dans notre cas nous allons simplement modifier les paramètres suivants :

1 : nous allons activer le feed
2 : le contenu sera copié sur notre instance
3 : le nom à afficher sera « MISP-ANSSI »
4 : puisque c’est l’ANSSI qui fournit les données nous allons mettre les informations
5 : les données proviennent d’internet donc il s’agit d’un feed de type « Network »
6 : l’URL du feed de l’ANSSI, il est également disponible dans leur tweet

Cliquer sur

Submit

Remarques :

Le tag automatique aux events n’est pas activé car il n’a pas fonctionné de mon côté, donc à la place je tag les évènements manuellement (ce qui est fastidieux !) mais pour le lab c’est amplement suffisant.

6.12.4 Statut du nouveau feed

Nous pouvons voir que notre Feed a bien été ajouté, à ce stade nous pouvons activer l’import des données mais avant de faire cela nous allons voir quelques fonctionnalités assez pratiques du MISP.

6.12.5 Exploration distance du feed

Fait intéréssant :

Il est possible d’explorer les données du MISP distant sans pour autant les récupérer en local !

Pour faire cela il faut cliquer sur le logo de la loupe situé à l’extrémité droite du feed en question :

Voici un exemple :

1 : comme son nom l’index le « PreviewIndex » permet d’avoir un aperçu des Events avant de potentiellement les importer
2 : puisqu’il peut y avoir plusieurs feed ici nous savons qu’il s’agit de l’instance de l’ANSSI
3 : qui est le fournisseur de l’Event
4 : différents tags associés à l’Event
5 : date de la création de l’Event
6 : informations générales sur l’Event
7 : horodatage précis
8 : il est possible de voir chaque indicateur en détails ou de le télécharger

6.12.6 Récupération d’un évènement en local

Il est possible de télécharger « unitairement » l’Event en cliquant sur le logo de téléchargement situé dans la zone droite de celui-ci :

6.12.7 Aperçu d’un évènement distant

Il est également possible de consulter en détails l’Event en cliquant sur l’œil situé dans la zone droite de celui-ci :

Voici un exemple de rapport et les informations présentes :

1 : nous sommes toujours dans la partie « PreviewIndex »
2 : entité qui fournit les informations
3 : le nom donné à l’event
4 : identifiant unique généré ainsi même si le nom de l’event change nous pouvons l’identifier, ce qui évite des confusions
5 : l’organisation à l’origine de la création de l’event
6 : les différents tags associés
7 : la date de création de l’event
8 : dates de différents artefacts
9 : types d’artefacts (nom de domaine, adresse ip. . .)
10 : les valeurs des artefacts
11 : commentaires laissés par les analystes

6.12.8 Téléchargement du feed distant

Pour télécharger le feed distant, cliquer sur le logo de mise en cache :

Un « job » sera créée pour effectuer cette tâche :

6.12.9 Récupération des évènements en local (dans la base de données)

Pour ajouter les informations dans le moteur d’ingestion cliquer sur le logo de téléchargement :

Ce qui donnera également lieu à un « job » :

Remarque :

Pour l’instant nous avons lancés des tâches mais la notion de « Workers » n’a pas été abordée et donc il ne se passe rien, les tâches sont simplement mises en file d’attente.

Il y a deux méthodes pour lancer les tâches et nous allons les voir par la suite en détails :

Méthode automatique : activer la planification pour que les tâches s’exécutent selon nos préférences
Méthode manuelle : activer le worker nécessaire pour faire une tâche

6.13 Scheduled Tasks

Des tâches planifiées sont préconfigurées dans le MISP, pour y accéder, cliquer sur

Administration
Scheduled Tasks

Voici quelques informations que nous pouvons observer :

1 : nous sommes dans la partie planification des tâches
2 : il y a différents types de tâches, celle qui nous intéresse porte l’id « 5 » et se nomme « fetch_feeds »
3 : il y a déjà une heure planifiée pour le lancement
4 : la prochaine date de planification est préconfigurée également, pour la modifier il suffit de cliquer dessus
5 : une description est disponible pour chaque tâche
6 : nous pouvons voir si la tâche a déjà été exécutée ou non
7 : pour prendre en compte les changements il faut cliquer sur « Update all »

Dans notre cas nous n’allons pas passer par cette méthode et opter pour la seconde solution « manuelle », notez bien qu’ici nous sommes dans un cadre d’un lab.

En milieu professionnel il sera plus utile d’utiliser le planificateur de tâches pour ne pas avoir à effectuer les opérations manuellement.

6.14 Server Settings & Maintenance

Pour activer les worker manuellement, cliquer sur

Administration
Server Settings & Maintenance

6.14.1 Workers

La liste des différents workers s’affiche, nous allons nous intéresser au worker « defaut » :

1 : le type et nom du worker
2 : nombre de tâches en attentes, dans le cas présent il y a une tâche c’est celle du téléchargement des données du MISP de l’ANSSI qui est en attente
3 : il faut double-cliquer sur « Start a worker » pour le démarrer

Remarque :

Nous allons activer les autres workers de la même manière, sauf celui qui se nomme « email » car nous n’allons pas utiliser cette fonctionnalité dans notre cas.

6.14.2 Activation du worker default

Lorsque le worker est démarré, voici un exemple de résultat.

Il est possible de démarrer d’autres worker du même type en cliquant à nouveau sur « Start a worker », cependant il faut avoir suffisamment de ressources sur la machine pour pouvoir les exécuter dans les meilleures conditions.

6.14.3 Vérification des Jobs

Pour vérifier l’avancement des tâches en attentes, cliquer sur

Administration
Jobs

Nous pouvons observer :

1 : le type de job « fetch_feeds » que nous avons lancé via le worker
2 : le tâche est en status « Completed »

6.15 Vérification de la réception des Events

Nous pouvons confirmer la bonne réception des Events en cliquant sur

Event Actions
List Events

Nous voyons bien que des Events ont été téléchargés sur notre instance et qu’elles proviennent bien du CERT-FR (ANSSI) :

6.16 Génération d’une clé d’accès pour l’instance OpenCTI

Maintenant que notre MISP est fonctionnel, reçoit les données du MISP de l’ANSSI et que nos workers sont fonctionnels.

Nous allons générer une clé qui va permettre au connecteur MISP de OpenCTI d’interroger notre instance MISP et de recevoir les données.

Cliquer sur

Administration
List Auth Keys

6.16.1 Authentication key index

Voici quelques informations déjà présentes :

1 : nous sommes au menu de gestion des clés
2 : un utilisateur « admin@admin.test » (=le compte administrateur par défaut de la plateforme) a une clé déjà générée
3 : la clé n’est pas complétement visible pour des raisons de confidentialité, il est possible de la consulter via une option (8)
4 : la clé actuelle n’a pas de date d’expiration
5 : la clé n’a jamais été utilisée
6 : un commentaire qui a été laissé lors de la création de la clé
7 : liste d’adresses IP autorisées à requêter via cette clé, cela peut être des IP privées ou publiques
8 : différentes options (visionner la clé complète, éditeur les paramètres de la clé, suppression de la clé)

6.16.2 +Add authentication key

Pour créer une nouvelle clé, cliquer sur

+Add authentication key

6.16.3 Add auth key

Voici les différents champs à remplir, ils sont identiques aux champs précédemment détaillés, un champ supplémentaire fait son apparition « 6 » qui permet d’avoir une clé en lecture seule uniquement.

Dans notre cas voici les différents éléments que nous avons renseigné pour la création de la clé :

1 : compte utilisateur par défaut, d’un point de vue de sécurité c’est une très mauvaise pratique ! Mais pour notre lab cela n’est pas impactant
2 : commentaire laissé pour connaitre la raison de la création / utilité de la clé
3 : o Adresses IP autorisées à requêter o J’ai essayé de n’autoriser que l’adresse ip d’un poste, cela n’a pas fonctionné donc j’ai autorisé toutes les IP . . . (mauvaise pratique)
4 : pour être certain que la clé ne soit pas utilisée indéfiniment et surtout pour nos besoins nous n’avons pas besoin d’une clé sans expiration nous avons défini une date d’expiration, ainsi même en cas d’oubli de suppression elle ne sera plus valide
5 : cliquer sur « Submit » pour confirmer la création de la clé

6.16.4 Auth key created

Un message d’affiche pour nous informer de la création de la clé :

1 : la clé en question, pensez à la copier nous allons en avoir besoin par la suite
2 : il faut sauvegarder la clé dans un endroit sûr (par exemple un gestionnaire de mot de passe) et le confirmer

6.16.5 Authentication key index

Notre clé s’affiche bien dans la liste :

6.17 Ajout d’un Tag

Il reste une dernière étape à faire avant de passer à la partie OpenCTI, en effet le connecteur MISP de OpenCTI se base sur différents critères pour importer les données et l’un d’entre eux est le « tag ».

Nous allons créer un tag spécifique et l’associer à un événement et mettre ce tag dans le fichier du connecteur pour que OpenCTI importe les évents à qui il est associé.

Cliquer sur

Event Actions
Add Tag

6.17.1 Création d’un Tag

Voici les différents champs qui ont été renseignés pour la création du tag :

1 : le nom que portera le tag, ici « opencti :import »
2 : nous pouvons choisir une couleur qui sera associée à ce tag, une palette de couleur s’affiche pour la sélection
3 : cliquer sur « Submit » pour confirmer la création

6.17.2 Attribution d’un tag à un Event

Voici un exemple d’Event, pour lui ajouter un tag, cliquer sur le logo qui représente un globe :

Voici les différentes étapes pour ajouter le tag :

1 : cliquer sur « All Tags » pour afficher la liste de tous les tags
2 : rechercher et sélectionner le tag récemment crée, ici « opencti :import »
3 : cliquer sur « Submit » pour confirmer l’ajout du tag

Une fois que le tag a été ajouté il s’affiche a côté des autres tags associés à l’Event :

Du côté de notre instance MISP nous avons terminé les différentes étapes, maintenant nous allons passer à la partie OpenCTI.

7. OpenCTI

Nous allons procéder en deux grandes phases :

Première phase : qui consiste à démarrer la stack OpenCTI « à vide » pour s’assurer qu’elle fonctionne correctement
Seconde phase : après avoir mis à jour la configuration de OpenCTI (=en ajoutant et configurant le connecteur MISP)

Cela rajoute donc une étape mais il est préférable de procéder en plusieurs phrases par précaution.

7.1 Préparation de l’installation

7.1.1 Configuration de la gestion de la mémoire

Saisir la commande suivante :

sudo sysctl -w vm.max_map_count=1048575

Détails de la commande :

sysctl
  > outil pour configurer les paramètres kernels

-w
  > pour «--write»
  > pour écriture une valeur

vm.max_map_count=1048575
  > la valeur à écrire

1 : commande utilisée
2 : retour de la commande

Pour rendre permanent ce changement, nous allons mettre le paramètre à la fin du fichier de configuration « sysctl.conf », saisir la commande suivante :

sudo echo "vm.max_map_count = 1048575" >> /etc/sysctl.conf

Détails de la commande :

echo
  > programme pour afficher un élément

"vm.max_map_count = 1048575"
  > élément à afficher

>>
  > double chevrons pour demander d’envoyer l’affichage du résultat à la fin d’un fichier

/etc/sysctl.conf
  > fichier dans laquel nous souhaitons ajouter l’élément de sortie de la commande précédente

Nous pouvons vérifier que le paramètre est bien présent dans le fichier via la commande suivante :

tail -3 /etc/sysctl.conf

Détails de la commande :

tail
  > programme pour afficher la fin d’un élément

-3
  > nous souhaitons n’afficher que les 3 dernières lignes

/etc/sysctl.conf
  > fichier dont nous souhaitons afficher le contenu

Ici nous pouvons bien voir la présence du paramètre précédemment inséré :

7.1.2 Récupération du script

Nous allons récupérer le script d’installation de OpenCTI et vérifier sa présence, saisir les commandes suivantes :

git clone https://github.com/OpenCTI-Platform/docker.git

ls -al | grep docker

1 : commande utilisée pour récupérer le script 2 : un dossier nommé « docker » est crée 3 : commande utilisée pour afficher les fichiers et dossier et filtrer le résultat uniquement sur ce qui nous intéresse, dans le cas présent l’élément « docker » 4 : le dossier a bien été crée 5 : le script qui a permis l’installation de docker au début du document

7.1.3 Contenu du répertoire

Pour la suite des opérations nous allons nous déplacer dans le répertoire « docker » et vérifier les éléments présents, saisir les commandes suivantes :

cd docker/

pwd

ls -al 

1 : commande pour se déplacer dans le dossier « docker »
2 : commande pour afficher le répertoire courant « Print Working Directory »
3 : nous sommes bien dans le répertoire « docker »
4 : commande pour afficher les fichiers et dossiers en format liste détaillée, même ceux qui sont cachés
5 : « docker-compose.yml » : fichier de configuration que nous modifierons par la suite pour ajouter le connecteur MISP OpenCTI
6 : « .env.sample » : fichier de configuration que nous allons copier et modifier pour mettre nos préférences

7.1.4 Copie du fichier « .env.sample »

Nous allons copier le fichier « .env.sample » pour garder l’original et modifier la copie, saisir la commande suivante :

cp .env.sample .env

1 : commande utilisée 2 : afficher les éléments et appliquer le filtre pour n’afficher que les éléments en « .env » 3 : la copie qui a été crée 4 : le fichier original

7.1.5 Génération d’un UUID v4 aléatoire

Pour la suite nous allons avoir besoin d’un UUID v4 aléatoire, il est possible d’en générer via la commande suivante :

cat /proc/sys/kernel/random/uuid

1 : commande utilisée pour générer un UUID v4 aléatoire 2 : exemple d’uuid v4 aléatoire 3 : commande utilisée pour générer un UUID v4 aléatoire 4 : exemple d’uuid v4 aléatoire

Nous pouvons noter ces uuid car ils seront utiles par la suite :

7.1.6 Fichier de configuration « .env »

7.1.6.1 Contenu par défaut

Voici le contenu par défaut du fichier :

1 : commande utilisée pour afficher le contenu du fichier
2 : l’adresse email utilisée comme identifiant de connexion à la plateforme
3 : mot de passe à définir
4 : UUID v4 à renseigner, comme nous avons précédemment générés nous pouvons en utiliser un ici
5 : url et port de l’interface web OpenCTI
6 : mot de passe à définir
7 : mot de passe à définir

7.1.6.2 Fichier mis à jour

Voici les différents champs qui ont été mis à jour dans notre cas :

1 : adresse email pour le compte Admin
2 : mot de passe pour le compte Admin
3 : ajout d’un UUID v4 pour le compte Admin
4 : mot de passe pour MINIO
5 : mot de passe pour RabbitMQ

7.1.7 Exportation des variables

Saisir la commande suivante :

set -a ; source .env

Détails de la commande :

set
  > permet de définir un paramètre

-a;
  > permet d’exporter un paramètre

source
  > permet d’exécuter une commande depuis un fichier

.env
  > fichier depuis lequel exécuter la commande

7.2 Lancement de la plateforme

Maintenant que les différentes configurations ont été effectuées nous pouvons lancer la plateforme.

7.2.1 Démarrage de la stack OpenCTI

Saisir la commande suivante :

sudo docker-compose up -d

1 : commande utilisée
2 : un réseau spécial est créé pour cette stack
3 : des volumes sont montés pour le stockage des données
4 : de nombreux containers sont téléchargés localement en vue du déploiement
5 : le nom et version de chaque container est affiché

Cette étape peut prendre un certain temps en fonction de votre connexion internet.

7.2.2 Création des containers et lancement

Lorsque le téléchargement des containers est terminé, leur déploiement commence :

7.3 Vérification de l’état des containers

Pour vérifier que les containers sont bien lancés nous pouvons utiliser la commande « docker ps » pour voir leur état :

7.4 Vérification des images récupérées

En parallèle à cela nous pouvons lister les différentes images qui ont été téléchargées localement via la commande « docker images » :

7.5 Accès à l’interface web

Pour accéder à l’interface web de OpenCTI il faut se rendre à l’adresse suivante :

http://IP-Instance-OpenCTI:8080

7.6 Connexion à l’interface

Remplir les champs suivants par les informations fournies dans le fichier « .env » :

Login
Password

Cliquer sur

SIGN IN

7.7 Interface web OpenCTI

Par défaut l’instance OpenCTI est un peu vide, c’est normal puisqu’aucun import de données n’a été configuré.

8. Connecteur MISP OpenCTI

Maintenant que notre plateforme conforme nous allons pouvoir passer à la seconde phase qui consiste à configurer le connecteur MISP de OpenCTI et importer les Events.

8.1 Arrêt de la stack OpenCTI

Pour arrêter la stack, saisir la commande suivante :

sudo docker-compose stop

8.2 Mise à jour du fichier de configuration « docker-compose.yml »

Les informations du connecteur MISP sont disponibles à l’adresse suivante :

https://github.com/OpenCTI-Platform/connectors/blob/master/external-import/misp/docker-compose.yml

Dans le fichier de configuration « docker-compose.yml » nous avons ajouté les informations du connecteur MISP :

1 : pour ne pas afficher du contenu non pertinent avons afficher uniquement les dernières lignes du fichier de configuration hormis la partie « volumes »
2 : il s’agit du connecteur MISP
3 : la version du connecteur qui est utilisée
4 : nous avons mis à jour l’URL par « http://opencti:8080 »
5 : nous allons utiliser le token du compte admin pour le lab, mais il est fortement recommandé de créer un compte de type « Connecteur » et d’utiliser son token
6 : nous allons utiliser un UUID v4 aléatoire pour ce connecteur
7 : ici le type d’import est bien « externe »
8 : nous avons renseigné l’adresse IP de notre instance MISP, cas particulier ici les instances MISP et OpenCTI sont sur le même poste (merci docker !) mais n’utilisent pas les mêmes ports.
9 : la clé que nous avons crée dans MISP et sauvegardée précieusement dans un gestionnaire de mot de passe
10 : les éléments qui seront téléchargés auront les tags suivants, dans notre cas nous avons crée le tag « opencti :import » dans misp et attribué ce tag à au moins un Event
11 : j’ai rajouté le paramètre pour que le connecteur se lance uniquement après que la plateforme OpenCTI soit lancée

8.3 Mise à jour du fichier de configuration «.env »

Dans le fichier de configuration « docker-compose.yml » nous avons prédéfinis une nouvelle variable pour le connecteur MISP, ici nous avons renseigné la valeur de celle-ci (2) :

8.4 Mise à jour de la stack OpenCTI

Pour que docker prenne en compte les changements effectués dans les fichiers de configurations, saisir la commande suivante :

sudo docker-compose pull

Nous pouvons observer que le connecteur MISP a été rajouté à la stack :

8.5 Démarrage de la stack OpenCTI

Nous allons de nouveau démarrer la stack OpenCTI via la commande suivante :

sudo docker-compose up -d

Et nous pouvons observer que les autres containers existent déjà et sont simplement démarrés mais quant au container MISP il a été créée :

8.6 Vérification de la réception des données

Une fois que la stack est démarrée nous pouvons aller voir dans l’interface web si les données sont bien reçues sur notre plateforme.

8.6.1 Données

Dans le menu situé à gauche de la fenêtre, cliquer sur

Données

8.6.2 Connecteurs

Cliquer sur

Connecteurs

8.6.3 Connecteur MISP

A la dernière ligne nous pouvons déjà observer qu’un connecteur nommé « MISP » est présent :

8.6.4 Détails du connecteur

En cliquant sur le connecteur nous obtenons des informations détaillées sur celui-ci :

1 : il est en status « actif »
2 : comme défini dans le fichier « docker-compose.yml » c’est un connecteur de type « external import »
3 : la date et heure du dernier lancement du connecteur
4 : une exécution est en cours
5 : le status de l’exécution
6 : nombre d’éléments importés
7 : nombre d’éléments à importer au total
8 : une barre de progression pour avoir un aperçu plus visuel sur l’avancement des imports

8.6.5 Exemple de récupération terminée

Voici un exemple de résultat qu’on peut obtenir lorsque l’exécution est terminée :

8.6.6 Analyses

Pour voir les Events importés, cliquer sur

Analyses

8.6.7 Entités

Nous pouvons voir les artefacts en allant dans

Données
Entités

8.6.8 Historique des lancements du connecteur

Si d’autres éléments sont importés un historique sera crée sur le connecteur comme ci-dessous :

8.6.9 Analyses récupérées

Voici un exemple d’analyses qui ont été récupérées via le connecteur MISP OpenCTI :

A ce stade :

Nous recevons les données du MISP de l’ANSSI
Notre MISP interne a reçu les données de l’ANSSI
- Cependant comme nous n’avons pas activé le planificateur de tâches il faut lancer la réception manuelle des données !
OpenCTI requête vers notre MISP interne pour importer les données
Les données sont bien présentes dans notre instance OpenCTI puisque c’était l’objectif initial du projet

9. Conclusion

C’est une excellente nouvelle que l’ANSSI mette à disposition un feed MISP cela permettra aux entreprises d’alimenter leur CTI d’informations fiables.

Comme vous avez pu le voir la récupération du feed MISP ANSSI vers une autre instance MISP est relativement simple, mais si nous souhaitons absolument faire comme moi cela rajoute des étapes supplémentaires et de la complexité dans le projet.

C’est l’un des projets où j’ai rencontré le plus de blocages, mais fini par trouver rapidement des solutions temporaires (puisque c’est un environnement de lab) soit des solutions permanentes.

Note :

Si vous êtes menés à consulter le man d’une commande, il faut prioriser celui qui est sur la distribution à la place d’une page web qui n’est plus forcément à jour.

10. Erreurs courantes

Je n’ai jamais rencontré autant d’erreurs ou blocages sur un de mes précédents projets que sur celui-ci.

Voici les différents cas de figures auxquelles j’ai été confronté et :

Leurs solutions
Leurs solutions temporaires / de contournement
Des pistes de réflexions

10.1 MISP

Problème :

La connexion à l’interface web est impossible car les identifiants sont incorrects.

Solution :

Si vous avez modifié le fichier « .env », il faut penser à renseigner un mot de passe fort (au moins 12 caractères selon les critères MISP et contenant des chiffres, lettres, majuscules, minuscules et caractères spéciaux).

Si cela ne fonctionne pas essayez simple les identifiants et mot de passe par défaut :

Identifiant : admin@admin.test
Mot de passe : admin

Par exemple ci-dessous bien que j’ai défini mes identifiants, une fois l’instance lancée je ne peux pas me connecter car le mot de passe ne respecte pas les critères de sécurité :

Si cela ne fonctionne toujours pas, vous pouvez entrer dans le container et réinitialiser manuellement le mot de passe :

Comment entrer dans un container ? : https://stackoverflow.com/questions/20932357/how-to-enter-in-a-docker-container-already-running-with-a-new-tty
Réinitialisation mot de passe via Container : https://www.circl.lu/doc/misp/quick-start/

Problème :

Le Feed est consultable à distance mais pas importé sur l'instance MISP.

Solution :

Il y a plusieurs choses à vérifier
- Est-ce que le feed a été activé ?
- Est-ce que la mise en caché a été activée ?
- Est-ce que le téléchargement a été activé ?
- Est-ce que le worker est fonctionnel ? (worker « default)
- Est-ce que le worker est fonctionnel et libre ? Sinon vous pouvez en lancer un autre si le premier est occupé

Problème :

Le Feed est configuré, consultable, téléchargeable manuellement mais n’est pas importé automatiquement dans le MISP.

Solution :

Est-ce que le worker est activé ?
Est-ce que les Scheduled Tasks sont configurés ?

10.2 OpenCTI

Problème :

Le fichier « .env » signale un caractère étrange dans les mots de passe.

Solution :

Le mot de passe que vous avez défini contient très certainement des caractères qui sont interprétés.
Vos mots de passe ne doivent pas contenir de caractères avec de simples ou double guillemet car ils sont interprétés comme des symboles de fin de commande et non comme du simple texte

La configuration ci-dessous par exemple pose problème car les mots de passe contiennent ces caractères :

Même situation ici :

Pour résoudre le problème il faut utiliser des mots de passe qui ne contiennent pas ces caractères.

Problème :

Le container du connecteur MISP est en status « restart » sans arrêt

Solution :

Dans le fichier « docker-compose.yml », il faut remplacer l'url "http//localhost" par http://opencti:8080"

Voici la configuration qui devrait fonctionner :

Problème :

Le connecteur MISP ne s’affiche pas l'interface OpenCTI.

Solution :

Dans le fichier de configuration « docker-compose.yml », remplacer l'url "http//localhost" par http://opencti:8080"

Problème :

Le connecteur MISP n'importe pas de données.

Solution :

Est-ce que l’adresse IP du serveur MISP distant a été renseignée ?
Est-ce que la clé MISP a été renseignée ?
Est-ce que votre machine est autorisée à requêter sur le MISP distant ? Vérifier dans les IP autorisées dans les paramètres de la clé
Est-ce que les tags définis dans le fichier « docker-compose.yml » sont existants sur le MISP distant ?

Problème :

Le connecteur est en statut restart ET sur l’interface web son exécution est en cours mais avec 0 évènements :

Ici une exécution a bien lieu mais il n’y a pas d’import d’évènements :

Explications :

Ici une adresse IP a été précisée et elle n’a pas fonctionné :

Solution :

Il faut modifier le champ « Allowed IPs » pour autoriser dans un premier temps toutes les adresses IP en attendant de trouver la cause réelle.

Dès ce changement nous pouvons voir que le container n’est plus en status « restart »

Et dans OpenCTI nous pouvons voir que l’import de données a repris :

11. Sources

De nombreuses sources ont été utilisées tout au long du projet, vous trouverez les liens ci-dessous.