U2 – CybcareV2 : architecture réseau, SIEM et sondes de cybersurveillance

1.

U2 - CybcareV2
« Augmenter les forces aériennes et spatiales par le numérique »

2.

U2 - CybcareV2
0 – Compréhension globale
1 – RÉSEAU
2 – SIEM
3 - SONDE
2

3.

U2 - CybcareV2
0 – Compréhension
Globale
3

4.

Compréhension globale : Récupérer un log sur une machine
Etape 1 : Les Elastic Agents s’enrôlent auprès du Fleet Server avec le
certificat SSL pour sécuriser la communication ainsi que l’ID de la policy qu’ils
doivent récupérer pour collecter les logs.
SI / SAS
Je veut m’enrôler sur la
policy Linux
SONDE
Je veut m’enrôler sur la
policy SONDE
Je veut m’enrôler sur la
policy Windows
Je veut m’enrôler sur la
policy WEC
4

5.

Compréhension globale : Récupérer un log sur une machine
Etape 2 : Le Fleet Server attribue la policy demandée (via son ID) et déploie
les intégrations associées aux Elastic Agents.
SI / SAS
Je veut m’enrôler sur la
policy SONDE
Voici la policy ainsi que les
Je
Jeveut
veut m’enrôler
m’enrôler sur
surlala
intégrations pour la policy
policy
policy
Windows
Linux
WEC
SONDE
5

6.

Compréhension globale : Récupérer un log sur une machine
Etape 3 : Les Elastic Agents envoient les logs de la machine sur laquelle ils
sont installés vers le Logstash.
SI / SAS
SONDE
6

7.

Compréhension globale : Récupérer un log sur une machine
SI / SAS
Etape 4 : Les logs sont dupliqués par logstash pour être écrit à plat dans une
archive puis envoyés dans la base de donnée Elasticsearch dans l’index
correspondant.
SONDE
7

8.

Compréhension globale : Récupérer un log sur une machine
SI / SAS
Etape 4 : Les logs sont dupliqués par logstash pour être écrit à plat dans une
archive puis envoyés dans la base de donnée Elasticsearch dans l’index
correspondant.
SONDE
ElasticSearch
Index Windows
Index Linux
Index Elastalert2
Index ElasticSecurity
Index Suricata
Index MISP
8

9.

Compréhension globale : Détection IOC
IOC :
IP les
Etape 1 : Via l’intégration MISP, l’ElasticAgent de la sonde récupère les IOC sur le MISP pour
HASH
écrire dans l’index MISP de la sonde.
URL
SOC
EXE
SI / SAS
SONDE
Nouveau
IOC ?
ElasticSearch
Index Windows
Index Linux
Index Elastalert2
Index ElasticSecurity
Index Suricata
Index MISP
9

10.

Compréhension globale : Détection IOC
Etape 2 : ElasticSecurity, via ses règles de détection IOC, va comparer l’index MISP avec les indexes
Windows, Linux, Suricata, les alertes seront écrite dans son index caché ElasticSecurity et visible sur l’app.
SOC
SI / SAS
SONDE
ElasticSearch
Index Windows
Index Linux
Index Elastalert2
LISTE
IOC
LISTE
Index Suricata IOC
Index ElasticSecurity
Index MISP
10

11.

Compréhension globale : Détection HIDS
Etape 1 : Le Bureau Détection créer une stratégie de détection sur Arpege-LID contenant les règles de
détection. Cette nouvelle stratégie sera stockée sur Gitlab.
SOC
STRATEGIE 1
SI / SAS
SONDE
ElasticSearch
Index Windows
Index Linux
Index Elastalert2
Index ElasticSecurity
Index Suricata
Index MISP
11

12.

Compréhension globale : Détection HIDS
Etape 2 : Lorsque Semaphore détecte un commit dans le dépôt des stratégies, il lance un playbook qui
déploie la stratégie dans l’Elastalert2 de la sonde.
Nouveau
Playbook
déploiement
SOC
Commit
?
stratégie
OUI
STRATEGIE 1
SI / SAS
SONDE
ElasticSearch
Index Windows
Index Linux
Index Elastalert2
Index ElasticSecurity
Index Suricata
Index MISP
STRATEGIE 1
12

13.

Compréhension globale : Détection HIDS
Etape 3 : Elastalert2 fait tourner les règles contenus dans la stratégie sur les logs,
si une règle match, l’alerte est écrite dans l’index Elastalert2.
SOC
SI / SAS
SONDE
ElasticSearch
Index Windows
Index Linux
Index Elastalert2
Index ElasticSecurity
Index Suricata
Index MISP
Règle
STRATEGIE 1
13

14.

Compréhension globale : Consultation des alertes
L’ElasticSecurity du SOC contient 3 règles qui viennent récupérer les alertes IOC,
Elastalert2 et Suricata de la Sonde pour les inscrire dans son propre index caché.
Nouvelles alertes ? SOC
SI / SAS
SONDE
ElasticSearch
Index Windows
Index Linux
Index Elastalert2
Index ElasticSecurity
Index Suricata
Index MISP
14

15.

Compréhension globale : Consultation des alertes
Arpege-LID récupère les alertes de Elastalert2, cela permet aux analystes de faire des
exceptions sur les règles qui seraient en faux positifs en fonction des stratégies.
SOC
SI / SAS
Nouvelles alertes ?
SONDE
ElasticSearch
Index Windows
Index Linux
Index Elastalert2
Index ElasticSecurity
Index Suricata
Index MISP
15

16.

Compréhension globale : Consultation des logs
Afin de qualifier une alertes en vrai ou faux positif, les analystes peuvent consulter les indexes
de la sonde via Kibana grâce aux Elasticsearch des sonde connectés en Remote Cluster.
Je veut voir l’index
Windows
SOC
SI / SAS
SONDE
ElasticSearch
Index Windows
Index Linux
Index Elastalert2
Index ElasticSecurity
Index Suricata
Index MISP
16

17.

U2 - CybcareV2
1 – RÉSEAU
17

18.

RÉSEAU
STORMSHIELD - C’est quoi ?
Pare-feu :
- Filtrage
- Nattage
- VPN
- etc...
18

19.

Un tunnel VPN permet une connexion entre deux sites de manière
chiffrée, isolée et sécurisée.
RÉSEAU
Tunnel VPN IPSEC
LAN
Les deux réseaux locaux communiquent de façon transparente à
travers le WAN, le chiffrement du tunnel protégeant l'intégralité
des échanges entre les deux sites.
L'encapsulation IPsec ESP ajoute environ 74 octets à chaque
paquet.
Cela réduit le MTU effectif à 1426 octets (sur une base de 1500).
WAN
LAN
19

20.

RÉSEAU
Tunnel VPN IPSEC
Phase 1 : Établissement du canal sécurisé (IKE_SA_INIT)
Initialisation + Clés (IKE_SA_INIT) ➔ On sécurise le dialogue.
Ce qu'on y fait : Négociation des algorithmes et échange de clés (Diffie-Hellman + Nonces).
But : Créer un premier canal chiffré sécurisé entre les deux équipements VPN.
Aucune donnée utilisateur ne passe encore ici.
Phase 2 : Authentification et création des SAs enfants (IKE_AUTH / CHILD_SA)
Authentification + Tunnel Data (IKE_AUTH) ➔ On valide qui parle et on ouvre le tunnel.
Ce qu'on y fait : Authentification mutuelle des routeurs/pare-feux (mots de passe PSK ou certificats)
à l'intérieur du canal chiffré créé en Phase 1, et négociation des règles du trafic IPsec réel.
But : Valider les identités et créer la convention de sécurité (Child SA) pour le réseau.
Transit des données utiles (ESP / AH)
Flux utile (ESP) ➔ Le trafic réseau circule.
Ce qu'on y fait : Une fois les deux phases IKE terminées, le tunnel de contrôle s'efface en arrière-plan.
But : Les données de vos utilisateurs/serveurs sont chiffrées, encapsulées et transmises
directement via le protocole ESP.
20

21.

Ports :
RÉSEAU
Tunnel VPN IPSEC
- UDP 500 :
LAN
Utilisé pour la Phase 1 (ISAKMP).
Il gère l'authentification des pairs
et la négociation des clés de chiffrement.
- UDP 4500 :
S'active automatiquement lorsque la Phase 1 est réussie
Il encapsule les données pour traverser les routeurs domestiques.
WAN
LAN
Protocole :
- ESP :
Protocole de couche 3 (pas de port).
C'est le conteneur sécurisé qui transporte vos données chiffrées.
Hors du tunnel (réseau WAN) :
Les données transitent de manière chiffrée sur le WAN.
Depuis le WAN, on ne voit que les adresses IP publiques communiquer avec le protocole ESP..
Celui-ci encapsule et chiffre les communications entre les LAN.et communique via le port 4500.
21

22.

RÉSEAU
Tunnel VPN IPSEC
LAN2
VTI (Virtual Tunnel Interface) :
Interfaces virtuelles à l’extrémité de l’entrée de chaque tunnels
permettant le routage à l’intérieur du tunnel (next hop).
Exemple :
Pour que le LAN1 communique avec le LAN2 en passant par le tunnel,
elle doit passer par la VTI LAN2.
Inversement, pour que le LAN2 communique avec le LAN1 en passant par le tunnel,
elle doit passer par la VTI LAN1.
WAN
Il faudra donc créer des routes en fonctions
Chiffrement :
Pour communiquer, les 2 extrémités du tunnel doivent parler le même langage.
Authentification :
- Identifiants (pas obligatoire) : ID local et ID du correspondant
- Méthode d’authentifiaction : clé pré partagé PSK ou certificat x.509
IKE Phase 1 (Négociation du canal de contrôle) :
- Algorithme de chiffrement (encryption) : Par exemple, AES-GCM-256
- Algorithme de hachage : Par exemple : SHA-256
- Le groupe Diffie-Hellman (DH) : Par exemple, DH19
LAN1
Dans le tunnel :
Les données transitent en clair comme sur le LAN.
Les adresses privées (ex: 192.168.1.0) sont parfaitement lisibles.
Les VTI (interfaces virtuels) permettent le routage à l’intérieur du tunnel des différents LAN.
22

23.

RÉSEAU
Tunnel VPN IPSEC
LAN
WAN
LAN
Hors du tunnel (réseau locale) :
Les données transitent en clair sur les LANs.
Les réseaux privées (ex: 192.168.1.0 et 192.168.2.0) sont parfaitement lisibles.
23

24.

RÉSEAU
Tcpdump
Tcpdump est un outil d'analyse réseau en ligne de commande qui capture et décode les paquets de données transitant sur une interface.
Il permet aux administrateurs d’écouter le trafic en temps réel pour diagnostiquer les pannes.
Il est disponible nativement sur stormshield mais il existe également sur Linux. Son équivalent sur Windows est Wireshark.
option
tcpdump -i [interface] → permet l’écoute de tout ce qu’il se passe sur une interface avec résolution de nom et de ports
action
(sans)
Résolution DNS & Ports complète (dns.google.com:dns)
-n
Désactive la résolution IP (8.8.8.8:dns)
-nn
Désactive la résolution IP et Ports (8.8.8.8:53)
-v ou -vv
Ajoute de la verbositée
host 8.8.8.8
Filtre sur l’IP 1.2.3.4 (par exemple)
port 53
Filtre sur le port 53 (par exemple)
net 10.0.0.0/24
Filtre sur un réseau entier
and
Permet un et logique entre 2 options (host, port, net, protocoles)
or
Permet un ou logique entre 2 options (host, port, net, protocoles)
not
Permet d’omettre une option (host, port, net, protocoles)
Exemple : tcpdump -i eth0 -nn host 5.6.7.8 and (port 80 or port 443)
→ J’écoute sur mon interface eth0, en désactivant la résolution IP et ports, je filtre sur le host 5.6.7.8 pour voir si cette IP reçoit ou envois des paquets sur les port 80 ou 443.
Exemple : tcpdump -i eth0 -nn net 192.168.1.0/24 and not host 192.168.1.118 and not port 22
→ J’écoute sur mon interface eth0, en désactivant la résolution IP et ports, je filtre sur le réseau 192.168.1.0/24 mais je ne veut pas voir ni le host 192. 168.1.118 ni le port 22
24

25.

U2 - CybcareV2
1.1 – RÉSEAU - TP
25

26.

RÉSEAU
Mise en place des SN dans l’architecture
Voir schema draw.io
26

27.

RÉSEAU
Mise en place des SN dans l’architecture
Etapes :
- Préconfiguration des IPs des interfaces des SN SIEM (alterné1) et SN SONDE (alterné2).
- Préconfiguration du tunnel avec réseau WAN simulé via un troisième SN FORMATEUR
- Mise en place des postes analystes via Terraform.
- Mise en place en baie
- Prise en main des SN via postes analystes présents dans la zone SIEM.
27

28.

RÉSEAU
Mise en place des SN dans l’architecture
Objectif final :
- Mise en place des SN d’extrémité dans votre architecture.
- Être capable de se connecter en web sur le SN SONDE en 192.123.1.6
depuis les postes analystes via le tunnel crée.
- Prouver que les échanges de paquets se font bien via le tunnel.
28

29.

RÉSEAU
Mise en place des SN dans l’architecture
1.2 – RÉSEAU - TD
Tunnel VPN SSL
29

30.

U2 - CybcareV2
2 – SIEM : Admin
30

31.

CybcareV2
SIEM - Admin
Ensemble, la Toolbox-siem, le
Semaphore et le Gitlab permettent le
déploiement de tout le SIEM et de
toute la SONDE
Voir schema draw.io
31

32.

CybcareV2
SIEM - Admin
La VM TOOLBOX-SIEM embarque
les services :
- ACS
- NTP
- DNS
Il génère les certificats pour les
machines a la demande de
Semaphore via playbook ansible,
fournis l’heure, ainsi que la résolution
de noms de domaine.
Voir schema draw.io
32

33.

CybcareV2
SIEM - Admin
GITLAB :
- Héberge les playbook Ansible
- Héberge les dockers
- Héberge les règles de détection HIDS
- Héberge les règles de détection NIDS
Voir schema draw.io
33

34.

CybcareV2
SIEM - Admin
SEMAPHORE :
- https://@IP:3000
- Interface graphique pour
playbook Ansible
- Déploie toute l’infra SIEM et SONDE
- Déploie les règles de détection HIDS
- Déploie les règles détection NIDS
Voir schema draw.io
34

35.

U2 - CybcareV2
2 – SIEM - TP1
35

36.

CybcareV2
SIEM - Admin
Etapes :
- Récupérer les timelines 01, 02, 03.
- Lire et comprendre entièrement les
timelines
- Se partager le travail qui peut-être
partagé.
- Suivre les timelines.
Le réseau n’est pas inclus dans les
timelines, il doit être fait à la main.
(SN, ESX, etc)
Vos VMs doivent être accessible depuis
les postes analystes.
Voir schema draw.io
36

37.

CybcareV2
SIEM - Admin
Objectif final :
- Accéder aux pages web de
Gitlab et Semaphore
Voir schema draw.io
37

38.

U2 - CybcareV2
2 – SIEM : SOC
38

39.

CybcareV2
SIEM - SOC
Les analystes SOC (System Operational Center)
ont accès à 4 Vms :
- SIEM
(Security Information & Event Management)
- SIRP
(Security Incident Response Platform)
- MISP
(Malware Information Sharing Platform)
Voir schema draw.io
- ARPEGE-LID
39

40.

CybcareV2
SIEM - SOC
- SIEM (Security Information & Event Management) :
Kibana se connecte aux bases de donnés
Elasticsearch des Sondes via les Remote Cluster.
Il permet de visualiser les logs du SI (Systèmes
d’information) qui est raccordé à la SONDE via sa
base de donnée Elasticsearch.
Les analystes SOC peuvent voir les logs brut
(Discover) ou créer des dashboards sur Kibana pour
faciliter la visualisation.
Il permet également la visualisation des alertes dans
Elastic-Security.
40

41.

CybcareV2
SIEM - SOC
Comme vu précédemment, le Kibana du SIEM permet de requêter
les Elasticsearch des SONDES via Remote Cluster (port 9300).
Il permet également d’accéder à l’Elastic-Security du SIEM.
L’Elastic-Security du SIEM remontent les alertes suricata, elastalert2
et IOC des sondes via 3 règles de détection dédié par sonde.
Il requête les ElasticSearch des Sondes via les Remote Cluster.
C’est le point de vision essentiel du SOC.
Metricbeat renvoie ses données au NOC (Network Operations
Center), il est présent sur toute les VMs afin de permettre aux
admins de vérifier que les VMs du SIEM et les VMs des SONDES
fonctionnent correctement.
Chaque VMs ont un Elastic Agent installé afin de remonter les logs
dans la sonde-infra.
CyberChef est un « couteau suisse de l’analyste » permettant de
manipuler, décoder et analyser des données chiffrer. Il simplifie des
taches essentielles comme le décodage de Base64 par exemple.
41

42.

CybcareV2
SIEM - SOC
Le proxy Traefik permet de redirigé les requêtes Web vers le
frontend-sonde, le kibana ou cyberchef .
Frontend-sonde, c’est la page par défaut envoyée par traefik
lorsqu’on se connecte en web à l’IP du SIEM.
Il propose un lien vers Kibana et Cyberchef.
Chrony_client synchronise le NTP pour que toute les VMs soient à
l’heure UTC. Cela évite un décallage temporelle dans les logs
générés.
DNS_Client requête le DNS de la toolbox afin de pouvoir
interconnecter les différentes VMs. Toutes les briques communique
via résolution de nom DNS et non via IP.
42

43.

CybcareV2
SIEM - SOC
- SIRP (Security Incident Response Platform) :
TheHive est l’outil de suivi d’incident.
Il permet de centraliser les informations liés à une
alerte de sécurité.
L’analyste SOC ouvre un case lié à une alertes afin
d’y centraliser toute les informations que l’équipe
trouvera pour caractériser une alertes comme vrai ou
faux positif.
Il s’interconnecte avec le MISP pour vérifier qu’un
évènement lié à une alerte ne contient pas un IOC
déjà connu et y transférer les nouveaux IOCs
découverts.
43

44.

CybcareV2
SIEM - SOC
Comme dit précédemment, TheHive permet la
centralisation des infos liés à une alerte.
Un case peut-être également ouvert via ArpegeLID.
Elasticsearch, Minio et Cassandra sont trois base de
données permettant a TheHive de fonctionner.
Elasticsearch : moteur de recherche ultra-rapide pour
retrouver un mot clé parmi des milliers d’incidents
Minio : stocke les pièces jointes liés aux cases.
Cassandra : Fonctionnement interne de TheHive
(Utilisateurs, permissions, liste des incidents, etc)
Cortex est une brique amenée à disparaître.
Elle permettait le Hunting sur les différentes sondes. Via
des listes d’IOCs demandés par le CALID sur une période
donnée. Le Hunting est remplacée par n8n.
44

45.

CybcareV2
SIEM - SOC
Le proxy Traefik permet de redirigé les requêtes Web vers
le frontend-sonde, TheHive ou Cortex .
Frontend-sonde, c’est la page par défaut envoyée par
traefik lorsqu’on se connecte en web à l’IP du SIEM.
Il propose un lien vers TheHive et Cortex.
Chrony_client synchronise le NTP pour que toute les VMs
soient à l’heure UTC. Cela évite un décallage temporelle
dans les logs générés.
DNS_Client requête le DNS de la toolbox afin de pouvoir
interconnecter les différentes VMs. Toutes les briques
communique via résolution de nom DNS et non via IP.
45

46.

CybcareV2
SIEM - SOC
- MISP (Malware Information Sharing Platform) :
Plateforme de stockage des IOCs (Indicators of Compromise)
Les analystes SOC y centralisent tout les indicateurs de compromission qu’ils trouvent
ou qui sont partagés par d’autres entités des armées (Exemple : CALID)
IOC : IP, Executable, Hash, URL
46

47.

CybcareV2
SIEM - SOC
Comme dit précédemment, MISP est la plateforme
regroupant tout les indicateurs de compromissions
(IOC).
Il est requêté par l’Elastic-Agent de la sonde-infra et
celui de la VM2 de la sonde sur son port 443 afin de
récupérer les IOCs dans leurs bdd respectives.
Il intègre 2 base de donnée, Redis et MariaDB.
MariaDB : stocke durablement les IOC, les
utilisateurs et leurs droits.
Redis : bdd ultra-rapide gérant le cache temporaire.
47

48.

CybcareV2
SIEM - SOC
Metricbeat renvoie ses données au NOC (Network
Operations Center), il est présent sur toute les VMs
afin de permettre aux admins de vérifier que les VMs
du SIEM et les VMs des SONDES fonctionnent
correctement.
Chaque VMs ont un Elastic Agent installé afin de
remonter les logs dans la sonde-infra.
Chrony_client synchronise le NTP pour que toute les
VMs soient à l’heure UTC. Cela évite un décallage
temporelle dans les logs générés.
DNS_Client requête le DNS de la toolbox afin de
pouvoir interconnecter les différentes VMs. Toutes
les briques communique via résolution de nom DNS
et non via IP.
48

49.

CybcareV2
SIEM - SOC
- Arpege-LID :
Arpege-LID est la plateforme de gestion des règles de détection systèmes.
Chaques sondes ont une stratégie de détection et des rêgles qui lui sont associés.
Lorsqu’un faux positif est trouvé le soc peut ajouter une exception à la rêgle associé.
Il s’interconnecte avec le Gitlab pour y héberger les stratégies et leurs règles associés.
49

50.

CybcareV2
SIEM - SOC
ARPEGE-LID :
- Gestion des stratégies de détection des sondes.
- Gestion des règles et des exceptions.
- Récupère les alertes sur les sondes (port 9200)
Il communique avec :
- GITLAB pour l’hébergement des stratégies de
détection.
- L’index Elastalert2 présent dans l’Elasticsearch
des sondes pour la récupération des alertes
- TheHive pour l’ouverture de case liés aux alertes.
50

51.

CybcareV2
SIEM - SOC
Metricbeat renvoie ses données au NOC (Network
Operations Center), il est présent sur toute les VMs
afin de permettre aux admins de vérifier que les VMs
du SIEM et les VMs des SONDES fonctionnent
correctement.
Chaque VMs ont un Elastic Agent installé afin de
remonter les logs dans la sonde-infra.
Chrony_client synchronise le NTP pour que toute les
VMs soient à l’heure UTC. Cela évite un décallage
temporelle dans les logs générés.
DNS_Client requête le DNS de la toolbox afin de
pouvoir interconnecter les différentes VMs. Toutes
les briques communique via résolution de nom DNS
et non via IP.
51

52.

U2 - CybcareV2
2 – SIEM - TP2
52

53.

CybcareV2
SIEM - Déploiement
Etapes :
- Récupérer la timeline 04.
- Lire et comprendre entièrement la
timelines
- Se partager le travail qui peut-être
partagé.
- Suivre la timeline.
- Prendre en main l’environnement du
SIEM
Le réseau n’est pas inclus dans les
timelines, il doit être fait à la main.
(SN, ESX, etc)
Vos VMs doivent être accessible depuis
les postes analystes.
Voir schema draw.io
53

54.

CybcareV2
SIEM - Déploiement
Objectif final :
- Accéder aux pages web du
SIEM, SIRP, MISP, ARPEGE-LID, NOC
- Interconnecter ARPEGE-LID avec le SIRP.
- Vérifier que les ELASTIC-AGENTS des
VMs sont connectés
- Vérifier que les logs des Vms remontent
dans la SONDE-INFRA.
- Vérifier que les logs présents dans la
SONDE-INFRA sont accessibles
depuis le SIEM
- Demander au SOC la base de
connaissance pour créer
la stratégie
SONDE-INFRA
sur Arpege-LID
- Demander au SOC une publication MISP
Voir schema draw.io
54

55.

U2 - CybcareV2
3 – SONDE
55

56.

U2 - CybcareV2
3 – SONDE - INFRA
56

57.

CybcareV2
SIEM - SONDE-INFRA
La SONDE-INFRA, est la sonde qui
supervise le SI SIEM.
C’est une version compacte sur une seule
VM de la SONDE destinée aux SAS.
Elle embarque donc toute les briques d’une
vrai sonde.
57

58.

CybcareV2
SIEM - SONDE-INFRA
Le SIEM dispose de sa propre SONDE-INFRA.
Cette sonde légère permet la cybersurveillance du SI
SIEM. C’est une sonde légère qui regroupe tout les
éléments principaux d’une sonde en une seule VM.
Chaque VMs ont un Elastic Agent installé afin de
remonter les logs dans la sonde.
Les policy de remontée de logs sont crées et
appliqués depuis le fleet-server.
Les intégrations se trouvent dans l’EPR.
L’Elastic-Agent se met à jour via l’EAR.
L’Elastic-Agent se connecte au Logstash afin que
celui-ci puisse archiver les logs à plat.
Après archivage, Logstash indexe les logs dans la
base de donnée Elasticsearch.
Le Kibana de la sonde sert aux admins pour accéder
au Fleet pour le raccordement des Elastic-Agent, la
gestion des policy, vérifier la bonne remontée des
logs du SI supervisé dans l’Elasticsearch de la sonde
vérifier que les IOCs du MISP sont bien récupérés
par l’intégration MISP de l’Elastic-Agent de la sondeinfra et accéder a Elastic-Security.
58

59.

CybcareV2
SIEM - SONDE-INFRA
Elastalert2 est le moteur de détection de la sonde, il
fait tourner en permanence les règles de détections
de la stratégie SONDE-INFRA. Il écrit les alertes
dans l’index Elastalert2 de l’Elasticsearch.
L’Elastic-Agent de la Sonde-infra possède
l’intégration MISP. Cette intégration permet de
récuperer les IOCs présents dans le MISP et de les
inscrire dans un index Elasticsearch dédié.
L’Elastic-Security de la sonde permet de faire la
corrélation entre les logs envoyés par les différents
Elastic-Agents et les IOCs présents dans l’index
MISP. 4 règles : Hash, IP, Executable, URL.
59

60.

CybcareV2
SIEM - SONDE-INFRA
Semaphore déploie les différentes briques de la
sonde mais il dépose aussi les règles de détections à
chaque fois qu’il détecte un changement dans le
dossier GIT de la stratégie.
Metricbeat renvoie ses données au NOC (Network
Operations Center), il est présent sur toute les VMs
afin de permettre aux admins de vérifier que les VMs
du SIEM et les VMs des SONDES fonctionnent
correctement.
Chrony_client synchronise le NTP pour que toute les
VMs soient à l’heure UTC. Cela évite un décallage
temporelle dans les logs générés.
DNS_Client requête le DNS de la toolbox afin de
pouvoir interconnecter les différentes VMs. Toutes les
briques communique via résolution de nom DNS et
non via IP.
60

61.

U2 - CybcareV2
3 – SONDE - SAS
61

62.

CybcareV2
SONDE
Voir schema draw.io
La Sonde est composé de 6 Vms :
VM1 : OPNSENSE :
→ Pare-feu en coupure avec le SI supervisé
VM2 : LOGSTASH :
→ Point d’entrée des logs
VM3 : ELASTICSEARCH + ELASTALERT/ElasticSecurity :
→ Base de donnée des logs + moteurs de détection
VM4 : TOOLBOX-SONDE :
→ DNS SONDE, FLEET-SERVER SONDE
VM5 : SURICATA :
→ Détection réseau
VM6 : NOC SONDE
→ Supervision fonctionnement sonde
62

63.

CybcareV2
SONDE - Réseau
Chaques VMs possèdent deux pattes :
- Une interface d’interconnexion avec le
SIEM via le tunnel stormshield
- Une interface pour le fonctionnement
interne à la SONDE.
- Exception :
- VM1 possède une troisième
interface pour l’interconnexion
avec le SI à supervisé.
- VM5 possède une troisième
interface pour recevoir la recopie
de paquets réseaux.
Voir schema draw.io
63

64.

CybcareV2
SONDE – Interconnexions
SI
Voir schema draw.io
64

65.

U2 - CybcareV2
3 – SONDE : HIDS
65

66.

CybcareV2
SONDE – Enrôlement de l’Agent
SI
Un ElasticAgent est installé sur chaques machines du SI.
Il s’enrôle au fleet à vm4.nommission.mdm.local:8220
afin de récupérer la policy qui lui est associé.
Dans le DNS du SI il faudra renseigner:
vm4.nommission.mdm.local → @IP Public OPNSENSE
L’OPNSense NAT toute les requêtes du SI vers les differentes VMs
pour ne jamais exposer le réseau interne de la SONDE
Il récupère ses intégrations demandé par sa policy et ses mises à jours
sur l’EAR via le port 9080. Il utilisera le même enregistrement DNS que
pour l’enrôlement des agents au fleet-server.
Voir schema draw.io
66

67.

CybcareV2
SONDE – Chemin d’un LOG
L’OPNsense NAT vers le LOGSTASH
SI
Un ElasticAgent est installé sur chaques machines du SI.
Il envoie ses logs à vm2.nommission.mdm.local:5044
Dans le DNS du SI il faudra renseigner:
vm2.nommission.mdm.local → @IP Public OPNSENSE
LOGSTASH archive les logs à plat puis les
envois à l’ELASTICSEARCH
ELASTICSEARCH stocke les logs reçu dans
sa base de donnée pour qu’ils puissent être
requêté ultérieurement
Voir schema draw.io
67

68.

CybcareV2
SONDE – Moteurs de détection
L’Elastic-Agent de la VM2, via son
intégration MISP, récupère les IOC
du MISP pour les inscrire dans un
index associé dans Elasticsearch
Fait tourner en permanence les règles définis dans la stratégie de détection
de la SONDE sur les index de logs, inscrit les résultat positifs dans l’index
Elastalert2 d’Elasticsearch
Via ses 4 rêgles (IP, HASH, EXECUTABLE et URL),
ElasticSecurity fait la correlation entre l’index MISP et les index de
logs pour vérifier s’il y’a des IOCs présents.
Si oui, il inscrit le résultat dans un index caché
et l’affiche dans son application.
68

69.

U2 - CybcareV2
3 – SONDE : NIDS
69

70.

CybcareV2
SONDE – Capture réseau
Un boitier TAP (Terminal Access Point) se met en
coupure d’un cable réseau afin de recopier le réseau
de manière transparente.
Network
Monitor
A
A’
B
B’
Le câble réseau « coupé » est branché sur la partie
NETWORK (A & B).
Le câble de transmission (TX) est recopié sur A’
Le câble de reception (RX) est recopié sur B’
Suricata, via sa carte réseau en promisc, écoute les
recopie du réseau sur la partie MONITOR
70

71.

CybcareV2
SONDE – VM5
Suricata écoute le réseau venant de la copie du boitier TAP.
Les règles de détection réseau tourne directement dans son propre
moteur de détection. (Les règles de détection sont déposés
via un playbook semaphore).
L’Elastic-Agent récupère les alertes suricata via son intégration
Suricata pour les inscrire dans l’index Elasticsearch correspondant.
71

72.

U2 - CybcareV2
3 – SONDE : to SIEM
72

73.

CybcareV2
SONDE – Récupération des Alertes
Lors du déploiement d’une sonde, 3 règles sont créés sur l’ElasticSecurity du SIEM :
- NOMDEMISSION-suricata : récupère les alertes suricata dans l’index suricata de la sonde
- NOMDEMISSION-elastalert2 : récupère les alertes elastalert2 dans l’index elastalert2 de la sonde
- NOMDEMISSION-alerts : récupère les alertes présente dans l’index caché de l’ElasticSecurity de la sonde (IOC)
Ces règles inscrivent leurs alertes dans l’index caché d’ElasticSecurity du SIEM.
73

74.

U2 - CybcareV2
3 – SONDE - TP
74

75.

CybcareV2
SONDE
Etapes :
- Récupérer la timeline 05 et 06.
- Lire et comprendre entièrement les
timelines
- Se partager le travail qui peut-être
partagé.
- Suivre les timelines.
- Installer l’agent sur le WEC si terminé,
sinon installer les
agents sur toute les
machines.
Voir schema draw.io
Le réseau n’est pas inclus dans les
timelines, il doit être fait à la main.
(SN, ESX, etc)
Vos VMs doivent être accessible depuis
les postes analystes.
75

76.

CybcareV2
SONDE
Objectif final :
- Faire remonter les logs de TOUTE
les machines
présentent
sur le SAS.
- Faire remonter les logs suricata.
- Vérifier que les analystes peuvent
voir les logs.
- Déclencher une alerte
Voir schema draw.io
76

77.

Fin de l’U2 – Merci pour votre travail et attention.
« Augmenter les forces aériennes et spatiales par le numérique »