Module T7 — SIEM & Elastic Stack

🧠 T7.1 — Le SIEM : cerveau du SOC

Un SIEM (Security Information and Event Management) est la plateforme centrale de surveillance et d'analyse de securite dans un SOC. Il collecte les logs de toute l'infrastructure, les normalise, les correle et genere des alertes lorsqu'un comportement suspect est detecte.

Le SIEM, c'est le centre de controle du trafic aerien de la cybersecurite. Imagine un aeroport : des centaines d'avions (evenements) arrivent de partout, chacun avec ses propres instruments et protocoles. Le controleur aerien (le SIEM) recoit toutes les informations radar (logs), les affiche sur un ecran unifie (dashboard), detecte les trajectoires anormales (correlation) et declenche une alerte si deux avions risquent d'entrer en collision (incident). Sans lui, c'est le chaos. Avec lui, chaque mouvement est suivi et controle en temps reel.

Les 5 fonctions fondamentales d'un SIEM

Fonction	Description	Exemple concret
Collecter	Ingerer les logs de toutes les sources (serveurs, firewalls, endpoints, applications, cloud)	Recevoir les logs Windows Event, Syslog, CloudTrail, firewall Palo Alto
Normaliser	Uniformiser les formats heterogenes en un schema commun (ECS, CIM)	Transformer un log Syslog et un log Windows en un format identique avec les memes champs
Correler	Croiser les evenements de sources differentes pour detecter des patterns complexes	5 echecs de connexion suivis d'un succes depuis la meme IP = brute force reussi
Alerter	Generer des notifications lorsqu'une regle de detection est declenchee	Alerte Slack + ticket JIRA quand un comportement de lateral movement est detecte
Stocker	Archiver les logs pour la conformite, le forensique et les investigations retroactives	Conserver 90 jours de logs en ligne + 1 an en stockage froid pour la conformite RGPD

SIEM vs SOAR

Le SIEM et le SOAR (Security Orchestration, Automation and Response) sont complementaires mais distincts :

Critere	SIEM	SOAR
Role principal	Detection et analyse	Automatisation et reponse
Focus	Collecter, correler, alerter	Orchestrer, automatiser, repondre
Input	Logs et evenements bruts	Alertes du SIEM + flux de menaces
Output	Alertes et dashboards	Actions automatisees (bloquer IP, isoler machine, creer ticket)
Intervention humaine	Analyse manuelle des alertes	Playbooks automatises (reduction du travail manuel)
Exemples	Elastic SIEM, Splunk, QRadar	Cortex XSOAR, Splunk SOAR, TheHive

SIEM + SOAR = SOC moderne

Le SIEM detecte les menaces, le SOAR y repond automatiquement. Dans un SOC mature, les deux travaillent ensemble : le SIEM genere une alerte, le SOAR execute un playbook de reponse (enrichissement IOC, isolation de l'endpoint, notification de l'equipe).

Panorama des solutions SIEM

Solution	Editeur	Type	Points forts	Points faibles
Splunk Enterprise Security	Cisco (Splunk)	Commercial	Puissant SPL, ecosysteme riche, marketplace d'apps	Tres couteux (licence au volume de donnees)
Elastic Security	Elastic	Open Source / Commercial	Gratuit (base), performant, ECS, detection rules incluses	Complexite d'administration du cluster
IBM QRadar	IBM	Commercial	Correlation avancee, QRadar Advisor (IA), integration Watson	Interface vieillissante, cout eleve
Microsoft Sentinel	Microsoft	Cloud (Azure)	Integration native Azure/M365, KQL puissant, SOAR integre	Verrouille dans l'ecosysteme Azure
LogRhythm	LogRhythm	Commercial	SOAR integre, SmartResponse, UEBA	Moins flexible que Elastic/Splunk
Wazuh	Wazuh Inc.	Open Source	100% open source, HIDS integre, compliance	Interface moins mature, communaute plus petite
Google SecOps (Chronicle)	Google	Cloud (GCP)	Stockage massif, YARA-L, vitesse de recherche	Ecosysteme Google requis

Pourquoi Elastic pour ce module ?

Elastic Stack est choisi pour ce module car il est open source, gratuit pour les fonctionnalites de base, largement utilise en production, et permet de comprendre les concepts SIEM de facon pratique. Les concepts appris (KQL, regles de detection, dashboards) sont transposables a n'importe quel SIEM.

🛠 T7.2 — Elastic Stack : architecture

L'Elastic Stack (anciennement ELK Stack) est compose de quatre briques principales qui forment un pipeline complet de collecte, traitement, stockage et visualisation des donnees.

Architecture globale

Pipeline Elastic Stack

📊 Kibana — Visualisation & Interface

Interface web pour visualiser, explorer et administrer les donnees. Dashboards, SIEM, alertes, Machine Learning.

↑

🔍 Elasticsearch — Moteur de recherche & Stockage

Base de donnees distribuee pour l'indexation, la recherche et l'analyse en temps reel. Coeur du stack.

↑

⚙ Logstash — Traitement & Enrichissement

Pipeline de traitement des donnees : parsing, filtrage, transformation, enrichissement (GeoIP, DNS, etc.).

↑

📡 Beats — Collecte legere

Agents legers deploys sur les machines pour collecter les donnees a la source. Filebeat, Winlogbeat, Packetbeat, etc.

Composants en detail

Elasticsearch — Le moteur

Elasticsearch est un moteur de recherche et d'analyse distribue base sur Apache Lucene. Il est le coeur de l'Elastic Stack.

Indexation — Les donnees sont stockees dans des index (equivalent de tables en SQL). Chaque document est un JSON indexe et recherchable.
Shards & Replicas — Les index sont divises en shards (fragments) distribues sur plusieurs noeuds. Les replicas assurent la haute disponibilite.
Cluster — Ensemble de noeuds (master, data, ingest, coordinating) qui travaillent ensemble.
Mapping — Schema definissant le type de chaque champ (keyword, text, date, ip, geo_point).
ILM (Index Lifecycle Management) — Gestion automatique du cycle de vie : hot → warm → cold → delete.

Exemple : structure d'un index

# Verifier la sante du cluster
GET _cluster/health

# Lister les index
GET _cat/indices?v

# Structure d'un document dans logs-*
{
  "@timestamp": "2026-02-24T14:30:22.000Z",
  "event.category": "authentication",
  "event.outcome": "failure",
  "source.ip": "192.168.1.105",
  "user.name": "admin",
  "host.name": "DC01",
  "agent.type": "winlogbeat"
}

Logstash — Le transformateur

Logstash est un pipeline de traitement de donnees qui ingere, transforme et envoie les donnees vers Elasticsearch.

Input — Sources de donnees : fichiers, syslog, Beats, Kafka, S3, JDBC, etc.
Filter — Parsing et transformation : Grok (regex nommees), mutate, date, geoip, dns, translate.
Output — Destinations : Elasticsearch, fichiers, email, Slack, S3, stdout.

Pipeline Logstash — Parsing de logs auth

input {
  beats {
    port => 5044
  }
}

filter {
  # Parser les logs SSH
  if [fileset][name] == "auth" {
    grok {
      match => {
        "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} sshd\[%{POSINT:pid}\]: %{GREEDYDATA:ssh_message}"
      }
    }

    # Extraire les IP des tentatives de connexion
    if "Failed password" in [ssh_message] {
      grok {
        match => {
          "ssh_message" => "Failed password for %{USER:username} from %{IP:src_ip} port %{INT:src_port}"
        }
      }
      mutate {
        add_tag => ["auth_failure"]
        add_field => { "event.outcome" => "failure" }
      }
    }

    # Enrichissement GeoIP
    if [src_ip] {
      geoip {
        source => "src_ip"
        target => "source.geo"
      }
    }
  }

  # Convertir le timestamp
  date {
    match => ["timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss"]
    target => "@timestamp"
  }
}

output {
  elasticsearch {
    hosts => ["https://elasticsearch:9200"]
    index => "logs-auth-%{+YYYY.MM.dd}"
    user => "elastic"
    password => "${ES_PASSWORD}"
  }
}

Kibana — L'interface

Kibana est l'interface web de l'Elastic Stack. Elle permet de visualiser, explorer et administrer les donnees.

Discover — Explorer les logs bruts avec KQL, filtres et timerange.
Dashboard — Creer des tableaux de bord interactifs avec des visualisations multiples.
Security (SIEM) — Interface dediee : alertes, timeline d'investigation, gestion des cas.
Observability — Monitoring applicatif, APM, uptime, metriques.
Machine Learning — Detection d'anomalies automatique sur les series temporelles.
Dev Tools — Console pour executer des requetes Elasticsearch directement.
Fleet — Gestion centralisee des agents Elastic (deploiement, configuration, mise a jour).

Beats — Les collecteurs

Les Beats sont des agents legers deploys sur les machines pour collecter les donnees a la source et les envoyer vers Logstash ou Elasticsearch.

Beat	Role	Cas d'usage SOC
Filebeat	Collecte de fichiers de logs	Syslog, Apache, Nginx, logs applicatifs, auth.log
Winlogbeat	Collecte des Windows Event Logs	Security (4624/4625), Sysmon, PowerShell, AppLocker
Packetbeat	Capture et analyse du trafic reseau	DNS, HTTP, TLS, flux reseau, detection d'anomalies
Metricbeat	Collecte des metriques systeme et services	CPU, RAM, disque, Docker, Kubernetes, MySQL, Redis
Auditbeat	Audit du systeme (fichiers, processus, sockets)	Surveillance d'integrite (FIM), detection de rootkits, audit processus
Heartbeat	Monitoring de disponibilite (uptime)	Verification que les services critiques repondent (HTTP, TCP, ICMP)

Configuration Winlogbeat — Collecte d'evenements securite

# winlogbeat.yml
winlogbeat.event_logs:
  - name: Security
    event_id: 4624, 4625, 4648, 4672, 4688, 4697, 4720, 4732
  - name: Microsoft-Windows-Sysmon/Operational
  - name: Microsoft-Windows-PowerShell/Operational
    event_id: 4103, 4104
  - name: Windows PowerShell
    event_id: 400, 403, 600, 800

output.elasticsearch:
  hosts: ["https://elasticsearch:9200"]
  username: "elastic"
  password: "${ES_PASSWORD}"

setup.kibana:
  host: "https://kibana:5601"

# Enrichissement avec les processors
processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - community_id: ~

Elastic Common Schema (ECS)

L'ECS est le schema de normalisation d'Elastic. Il definit des noms de champs standardises pour que toutes les sources de donnees utilisent le meme vocabulaire.

Categorie ECS	Champs principaux	Description
event.*	event.category, event.action, event.outcome	Nature de l'evenement (authentication, process, network)
source.*	source.ip, source.port, source.geo	Origine de la connexion
destination.*	destination.ip, destination.port	Destination de la connexion
user.*	user.name, user.domain, user.id	Compte utilisateur implique
host.*	host.name, host.os.name, host.ip	Machine source de l'evenement
process.*	process.name, process.pid, process.command_line	Processus en cours d'execution
file.*	file.path, file.hash.sha256, file.name	Fichier implique dans l'evenement
agent.*	agent.type, agent.version	Agent ayant collecte l'evenement (Filebeat, Winlogbeat)

Pourquoi ECS est crucial

Sans normalisation, un meme evenement (connexion echouee) aurait des noms de champs differents selon la source : src_ip (firewall), IpAddress (Windows), remote_addr (Nginx). ECS unifie tout sous source.ip. Cela rend les requetes et les regles de detection portables entre sources.

🔎 T7.3 — Kibana Query Language (KQL)

KQL (Kibana Query Language) est le langage de recherche natif de Kibana. Il permet de filtrer les donnees dans Discover, les dashboards et les regles de detection. C'est l'outil quotidien de l'analyste SOC.

Syntaxe de base

Syntaxe	Description	Exemple
`champ:valeur`	Egalite exacte	`user.name:admin`
`champ:*`	Le champ existe (non vide)	`source.ip:*`
`and`	ET logique	`event.outcome:failure and user.name:admin`
`or`	OU logique	`source.ip:10.0.0.1 or source.ip:10.0.0.2`
`not`	Negation	`not event.outcome:success`
`champ:val*`	Wildcard (commence par)	`process.name:power*`
`champ >= valeur`	Comparaison numerique / date	`event.severity >= 3`
`champ <= valeur`	Inferieur ou egal	`source.port <= 1024`
`()`	Regroupement	`(user.name:admin or user.name:root) and event.outcome:failure`
`champ.nested:valeur`	Champ imbrique	`source.geo.country_name:China`

Requetes KQL essentielles pour le SOC

Voici les requetes que tout analyste SOC doit maitriser. Chacune correspond a un cas d'usage operationnel reel.

1. Echecs de connexion (brute force)

KQL — Echecs d'authentification

# Tous les echecs de connexion
event.category:authentication and event.outcome:failure

# Echecs de connexion sur un compte specifique
event.category:authentication and event.outcome:failure and user.name:administrator

# Echecs de connexion depuis une IP externe
event.category:authentication and event.outcome:failure and not source.ip:10.0.0.0/8

# Echecs sur Windows (Event ID 4625)
event.code:4625

# Brute force : echecs suivis d'un succes sur le meme compte
event.category:authentication and user.name:admin

2. Creation de processus suspects

KQL — Detection de processus suspects

# Toute creation de processus (Sysmon Event ID 1 ou Windows 4688)
event.category:process and event.action:start

# Processus avec des noms suspects
process.name:(cmd.exe or powershell.exe or wscript.exe or cscript.exe or mshta.exe or rundll32.exe or regsvr32.exe or certutil.exe)

# Processus lances depuis des repertoires suspects
process.executable:(*\\Temp\\* or *\\AppData\\* or *\\Downloads\\* or *\\ProgramData\\*)

# Processus enfant suspect d'un processus parent Office
process.parent.name:(winword.exe or excel.exe or outlook.exe) and process.name:(cmd.exe or powershell.exe)

# Processus avec des arguments de ligne de commande suspects
process.command_line:(*-enc* or *-encodedcommand* or *bypass* or *hidden* or *downloadstring* or *invoke-expression*)

3. Connexions reseau suspectes

KQL — Analyse reseau

# Connexions sortantes vers des ports non standards
event.category:network and destination.port:(4444 or 5555 or 8443 or 8888 or 9001)

# Connexions vers des IP connues comme malveillantes (a adapter avec vos IOC)
destination.ip:(185.220.101.* or 45.33.32.156)

# Requetes DNS suspectes (domaines DGA ou exfiltration)
dns.question.name:*.xyz or dns.question.name:*.tk or dns.question.name:*.top

# Connexions sortantes volumineuses (exfiltration potentielle)
event.category:network and network.bytes >= 10000000

# Trafic sur des ports inhabituels pour le protocole
destination.port:443 and not network.protocol:tls
destination.port:80 and not network.protocol:http

4. Execution PowerShell

KQL — Surveillance PowerShell

# Tout evenement PowerShell
event.provider:Microsoft-Windows-PowerShell or event.provider:PowerShell

# Scripts PowerShell executes (Script Block Logging — Event ID 4104)
event.code:4104

# PowerShell avec encodage Base64 (technique d'obfuscation classique)
event.code:4104 and powershell.file.script_block_text:*FromBase64String*

# PowerShell telechargeant du contenu distant
process.command_line:(*Net.WebClient* or *Invoke-WebRequest* or *wget* or *curl* or *DownloadFile* or *DownloadString* or *IEX*)

# PowerShell executant du code en memoire
process.command_line:(*Invoke-Expression* or *IEX* or *-ep bypass* or *-ExecutionPolicy bypass*)

5. Installation de services et persistance

KQL — Detection de persistance

# Nouveaux services installes (Event ID 4697 ou 7045)
event.code:4697 or event.code:7045

# Taches planifiees creees
event.code:4698 or process.name:schtasks.exe

# Modifications de registre (cles de demarrage)
registry.path:(*\\Run\\* or *\\RunOnce\\* or *\\Services\\*)

# Creation de comptes utilisateurs (Event ID 4720)
event.code:4720

# Ajout d'un utilisateur au groupe Administrateurs (Event ID 4732)
event.code:4732 and group.name:Administrators

6. Elevation de privileges

KQL — Privilege escalation

# Attribution de privileges speciaux (Event ID 4672)
event.code:4672

# Utilisation de runas ou credentials alternatives (Event ID 4648)
event.code:4648

# Processus eleves via UAC bypass
process.name:(fodhelper.exe or computerdefaults.exe or sdclt.exe or eventvwr.exe) and process.parent.name:cmd.exe

# sudo ou su sur Linux
process.name:sudo or process.name:su and event.outcome:success

Table de reference rapide KQL

#	Objectif	Requete KQL
1	Echecs de connexion	`event.category:authentication and event.outcome:failure`
2	Connexion reussie sur compte privilegie	`event.code:4624 and user.name:(admin* or root)`
3	Creation de processus	`event.category:process and event.action:start`
4	Execution PowerShell	`process.name:powershell.exe or event.code:4104`
5	Connexion reseau sortante	`event.category:network and network.direction:outbound`
6	Requete DNS	`dns.question.name:* and event.category:network`
7	Modification de fichier	`event.category:file and event.action:(creation or modification)`
8	Nouveau service installe	`event.code:7045 or event.code:4697`
9	Tache planifiee creee	`event.code:4698 or process.name:schtasks.exe`
10	Mouvement lateral (PsExec)	`process.name:psexec* or event.code:5145`
11	Montee en privileges	`event.code:4672 or event.code:4648`
12	Compte utilisateur cree	`event.code:4720`
13	Groupe modifie	`event.code:4732 or event.code:4733`
14	Logs effaces	`event.code:1102 or event.code:104`
15	Connexions depuis pays inhabituels	`source.geo.country_name:* and not source.geo.country_name:(France or Belgium)`

🚨 T7.4 — Regles de detection et alertes

Les regles de detection transforment le SIEM d'un simple outil de recherche en un systeme de detection active. Elles surveillent en continu les donnees entrantes et generent des alertes quand un pattern suspect est identifie.

Types de regles de detection

Type	Principe	Exemple	Faux positifs
Seuil (Threshold)	Alerte quand un nombre d'evenements depasse un seuil dans une fenetre de temps	Plus de 10 echecs de connexion en 5 minutes	Moyen — utilisateurs qui oublient leur mot de passe
Correlation	Alerte quand une sequence d'evenements est detectee dans un ordre specifique	Echec de connexion → succes → elevation de privileges depuis la meme IP	Faible — sequence specifique
Anomalie (ML)	Alerte quand un comportement devie du profil normal etabli par Machine Learning	Un utilisateur se connecte a 3h du matin alors qu'il ne travaille jamais la nuit	Variable — necessite un bon baseline
IOC Matching	Alerte quand un indicateur de compromission (IP, hash, domaine) est detecte	Connexion vers une IP presente dans un feed de threat intelligence	Faible — indicateurs specifiques
EQL (Event Query Language)	Alerte basee sur des sequences et correlations d'evenements avancees	Processus A cree processus B qui modifie un fichier C — le tout en 30 secondes	Faible — logique sequentielle

Elastic Detection Rules

Elastic Security inclut des centaines de regles de detection preconstruites mappees sur le framework MITRE ATT&CK. Elles couvrent les techniques les plus courantes.

Exemple : Regle de detection — Brute Force (Threshold)

# Regle Elastic Security — Detection de brute force
{
  "name": "Brute Force — Multiple Authentication Failures",
  "description": "Detecte plus de 10 echecs d'authentification sur un meme compte en 5 minutes",
  "risk_score": 47,
  "severity": "medium",
  "type": "threshold",
  "query": "event.category:authentication and event.outcome:failure",
  "threshold": {
    "field": ["user.name", "source.ip"],
    "value": 10
  },
  "from": "now-5m",
  "interval": "5m",
  "tags": ["Brute Force", "Credential Access", "T1110"],
  "threat": [
    {
      "framework": "MITRE ATT&CK",
      "tactic": {
        "id": "TA0006",
        "name": "Credential Access"
      },
      "technique": [
        {
          "id": "T1110",
          "name": "Brute Force"
        }
      ]
    }
  ]
}

Exemple : Regle EQL — Sequence d'attaque (Credential Access → Lateral Movement)

# Regle EQL — Sequence : echecs de connexion → succes → PsExec
sequence by source.ip with maxspan=10m
  [authentication where event.outcome == "failure"] with runs=5
  [authentication where event.outcome == "success"]
  [process where process.name == "psexesvc.exe"]

Sigma Rules : standard universel

Sigma est un format de regles de detection generique et open source. L'equivalent des regles YARA pour les logs. Une regle Sigma peut etre convertie en KQL, SPL (Splunk), ou n'importe quel langage SIEM.

Regle Sigma — Detection PowerShell encode

# sigma_rule_powershell_encoded.yml
title: Suspicious Encoded PowerShell Command Line
id: f3a98ce4-6a2d-4c7b-b5d3-e8a1f2b3c4d5
status: stable
description: Detecte l'execution de PowerShell avec des commandes encodees en Base64
author: SOC Analyst
date: 2026/02/24
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    process.name:
      - powershell.exe
      - pwsh.exe
    process.command_line|contains:
      - '-encodedcommand'
      - '-enc '
      - '-e '
      - 'FromBase64String'
  condition: selection
falsepositives:
  - Scripts d'administration legitimes utilisant l'encodage
level: high
tags:
  - attack.execution
  - attack.t1059.001

Conversion Sigma → KQL (avec sigmac)

# Installer sigma-cli
pip install sigma-cli pySigma-backend-elasticsearch

# Convertir une regle Sigma en KQL
sigma convert -t elasticsearch -p ecs_windows sigma_rule_powershell_encoded.yml

# Resultat KQL genere :
# process.name:(powershell.exe or pwsh.exe) and process.command_line:(*-encodedcommand* or *-enc * or *-e * or *FromBase64String*)

Ecrire une regle de detection personnalisee

Regle custom — Exfiltration DNS (tunneling)

# Regle Elastic Security — DNS Tunneling Detection
{
  "name": "Potential DNS Tunneling — High Volume Unique Subdomains",
  "description": "Detecte un nombre anormalement eleve de sous-domaines uniques vers un meme domaine parent, indicateur de DNS tunneling (exfiltration)",
  "risk_score": 73,
  "severity": "high",
  "type": "threshold",
  "query": "event.category:network and dns.question.type:TXT and dns.question.name:*",
  "threshold": {
    "field": ["dns.question.registered_domain"],
    "value": 50
  },
  "from": "now-15m",
  "interval": "5m",
  "note": "Verifier si le domaine parent est un service legitime (Google, Microsoft). Verifier la taille moyenne des sous-domaines (long = encodage Base64 = exfiltration probable).",
  "tags": ["DNS", "Exfiltration", "T1048.003"]
}

Severite et triage des alertes

Severite	Risk Score	Exemples	SLA de triage
Critical	75-100	Ransomware detecte, exfiltration confirmee, compromission de compte admin	Immediat (< 15 min)
High	50-74	Brute force reussi, lateral movement, malware execute	< 1 heure
Medium	25-49	Tentatives de brute force, scan de ports, PowerShell encode	< 4 heures
Low	0-24	Echec de connexion isole, politique de mot de passe, anomalie mineure	< 24 heures

Le defi du tuning

Une regle qui genere trop de faux positifs sera ignoree (alert fatigue). Une regle trop stricte laissera passer des vrais incidents. Le tuning continu des regles est un travail permanent de l'equipe SOC : ajuster les seuils, ajouter des exceptions, affiner les requetes.

📊 T7.5 — Dashboards et visualisations

Les dashboards Kibana transforment des millions de logs bruts en informations exploitables. Un bon dashboard permet a l'analyste SOC de comprendre la situation en un coup d'oeil.

Types de visualisations

Type	Usage SOC	Exemple
Time series (Line/Area)	Evolution temporelle des evenements	Volume d'alertes par heure sur 7 jours
Bar chart	Comparaison entre categories	Top 10 des IP sources d'echecs de connexion
Pie / Donut	Repartition proportionnelle	Repartition des alertes par severite
Heatmap	Identification de patterns temporels	Echecs de connexion par heure et jour de la semaine
Data table	Details et investigations	Liste des derniers comptes crees avec details
Metric	KPI en temps reel	Nombre total d'alertes critiques actives
Geo Map	Localisation geographique des connexions	Carte des pays sources des connexions entrantes
Treemap	Hierarchie et proportions	Repartition des evenements par source et categorie

Dashboard SOC essentiel — Les 8 panels incontournables

#	Panel	Visualisation	Requete KQL / Metric
1	Alertes par severite	Donut chart	Comptage des alertes groupees par `kibana.alert.severity`
2	Timeline des alertes	Area chart	Alertes par intervalle de temps, colorees par severite
3	Top sources d'echecs	Horizontal bar	`event.outcome:failure` groupe par `source.ip`
4	Top destinations	Horizontal bar	`event.category:network` groupe par `destination.ip`
5	Heatmap authentification	Heatmap	Echecs de connexion par heure (X) et jour (Y)
6	Carte geographique	Geo Map	Connexions entrantes mappees par `source.geo.location`
7	Processus suspects	Data table	Derniers `event.category:process` avec noms de processus suspects
8	KPI — Metriques temps reel	Metric	Alertes critiques / Events/sec / Sources actives / Uptime

Bonnes pratiques pour les dashboards

Hierarchie visuelle — Placer les metriques critiques en haut, les details en bas. L'analyste doit comprendre la situation en 5 secondes.
Time range dynamique — Utiliser le time picker de Kibana plutot que des timeranges hardcodes dans les requetes.
Filtres interactifs — Permettre le clic pour filtrer (cliquer sur une IP pour filtrer tout le dashboard sur cette IP).
Couleurs significatives — Rouge = critique, orange = attention, vert = normal. Ne jamais utiliser les couleurs de facon decorative.
Pas de surcharge — Maximum 8-10 panels par dashboard. Creer des dashboards specialises plutot qu'un seul surcharge.
Drilldown — Chaque visualisation doit permettre de creuser plus profondement (lien vers Discover ou un sous-dashboard).
Rafraichissement automatique — Configurer un intervalle de rafraichissement (30s-5min) pour les dashboards operationnels.
Annotations — Ajouter des annotations temporelles pour marquer les incidents connus, les maintenances, les deploiements.

Dashboard ≠ Rapport

Un dashboard est un outil operationnel en temps reel. Un rapport est un document retrospectif periodique. Ne confonds pas les deux : le dashboard aide a detecter et reagir, le rapport aide a mesurer et ameliorer.

🛡 T7.6 — Operations SOC avec Elastic

Au-dela de la configuration, un analyste SOC passe la majorite de son temps a trier des alertes et mener des investigations. Cette section couvre les workflows operationnels concrets avec Elastic.

Workflow de triage d'alerte

Processus de triage en 5 etapes

1. Reception — Evaluer la severite et la source de l'alerte

Lire le nom de la regle, la severite, le risk score. Identifier la source (quel host, quel user, quelle IP).

2. Contextualisation — Enrichir l'alerte avec du contexte

Chercher l'IP source dans les bases de reputation (VirusTotal, AbuseIPDB). Verifier si l'utilisateur est un VIP. Consulter les alertes precedentes sur ce host.

3. Investigation — Creuser les evenements associes

Pivoter dans Discover : que s'est-il passe avant et apres l'alerte ? Y a-t-il d'autres alertes sur le meme host ? Quelle est la timeline complete ?

4. Decision — Classifier l'alerte

True Positive (incident confirme), False Positive (fausse alerte, tuner la regle), ou Benign True Positive (comportement attendu mais detecte).

5. Action — Repondre ou escalader

True Positive → creer un incident, escalader au Tier 2/3, isoler la machine. False Positive → fermer l'alerte, ajouter une exception a la regle.

Use case 1 : Investigation d'une attaque par brute force

Scenario : Une alerte "Multiple Authentication Failures" est declenchee. L'IP source 203.0.113.42 a genere 87 echecs de connexion en 3 minutes sur le compte svc_backup.

Etape 1 — Confirmer l'activite

# Voir tous les echecs de connexion de cette IP
source.ip:203.0.113.42 and event.outcome:failure

# Compter les comptes cibles
source.ip:203.0.113.42 and event.outcome:failure
→ Agréger par user.name dans Discover

# Verifier si un succes a suivi
source.ip:203.0.113.42 and event.outcome:success

Etape 2 — Enrichir l'IP source

# Verifier l'origine geographique de l'IP
source.ip:203.0.113.42
→ Regarder source.geo.country_name, source.geo.city_name

# Verifier toute l'activite de cette IP (pas seulement les echecs)
source.ip:203.0.113.42
→ Filtrer par event.category pour voir : authentication, network, process

# Autres alertes sur cette IP ?
source.ip:203.0.113.42 and kibana.alert.rule.name:*

Etape 3 — Verifier si le brute force a reussi

# Connexion reussie APRES les echecs sur le meme compte
event.category:authentication and event.outcome:success and user.name:svc_backup
→ Verifier le timestamp : la connexion est-elle posterieure aux echecs ?

# Si succes : verifier l'activite post-connexion
user.name:svc_backup and event.category:process
user.name:svc_backup and event.category:network

# Verifier les modifications de compte
user.name:svc_backup and (event.code:4738 or event.code:4724)

Etape 4 — Verifier le mouvement lateral

# L'attaquant s'est-il deplace vers d'autres machines ?
source.ip:203.0.113.42 and event.category:network and destination.port:(445 or 135 or 3389 or 5985)

# Utilisation de PsExec ou WMI depuis la machine compromise
process.name:(psexec* or wmic.exe or winrm*) and host.name:TARGET_HOST

# Nouvelles connexions depuis le compte compromis vers d'autres hosts
user.name:svc_backup and event.code:4624 and not host.name:ORIGINAL_HOST

Use case 2 : Investigation d'une exfiltration de donnees

Scenario : Une alerte "Unusual Outbound Data Transfer" est declenchee. Le host WKS-FINANCE-03 a envoye 2.3 GB de donnees vers une IP externe en 45 minutes.

Investigation exfiltration — Requetes KQL

# 1. Confirmer le volume de donnees sortantes
host.name:WKS-FINANCE-03 and event.category:network and network.direction:outbound
→ Agreger par destination.ip et sum(network.bytes)

# 2. Identifier la destination
host.name:WKS-FINANCE-03 and destination.ip:SUSPICIOUS_IP
→ Verifier destination.geo, destination.domain

# 3. Quel processus a genere le trafic ?
host.name:WKS-FINANCE-03 and event.category:network and destination.ip:SUSPICIOUS_IP
→ Regarder process.name, process.executable

# 4. Que s'est-il passe avant le transfert ?
host.name:WKS-FINANCE-03 and event.category:process
→ Timeline des processus crees dans l'heure precedant le transfert

# 5. Y a-t-il eu des acces fichiers suspects ?
host.name:WKS-FINANCE-03 and event.category:file and event.action:access
→ Quels fichiers ont ete lus avant le transfert ?

# 6. Verifier les acces PowerShell ou outils de compression
host.name:WKS-FINANCE-03 and process.name:(powershell.exe or 7z.exe or rar.exe or zip.exe or tar.exe)

# 7. Verifier les requetes DNS (C2 ou staging)
host.name:WKS-FINANCE-03 and event.category:network and dns.question.name:*
→ Domaines inhabituels ? Requetes TXT en volume ?

Escalation : quand et comment

Situation	Action	Escalader vers
Brute force sans succes, IP externe	Bloquer l'IP au firewall, fermer l'alerte	Pas d'escalade (Tier 1 gere)
Brute force avec succes confirme	Isoler le host, reset du mot de passe, creer un incident	Tier 2 + Manager SOC
Malware detecte et execute	Isoler le host, collecter les artefacts	Tier 2 (analyse malware)
Exfiltration de donnees confirmee	Isoler le host, preserver les logs, notifier la direction	Tier 3 + CISO + Legal
Ransomware detecte	Isoler le segment reseau, activer le plan de continuite	Tier 3 + CISO + Direction + CERT externe

Regle d'or de l'investigation

Ne jamais modifier les preuves. Lors d'une investigation, tu observes et documentes. Ne redemarres pas la machine compromise, ne supprimes pas les fichiers suspects, ne te connectes pas dessus avec un compte admin. Chaque action laisse des traces et peut detruire des preuves forensiques.

🔨 T7.7 — Lab : Terminal KQL

Exercice 1 : Simule des requetes dans Kibana Discover

Utilise le terminal ci-dessous pour pratiquer les requetes KQL. Tape help pour voir les commandes disponibles.

Kibana Discover — Lab KQL Investigation

# Bienvenue dans le lab Kibana KQL !

# Scenario : un SOC fictif avec des evenements suspects

# Objectif : identifier les menaces en utilisant KQL

# Tape 'help' pour voir les requetes disponibles

KQL >

Exercice 2 : Associe chaque composant Elastic a son role

Glisse chaque composant dans la zone correspondant a sa fonction.

Filebeat

Logstash

Elasticsearch

Kibana

Winlogbeat

Packetbeat

Grok Filter

Dashboard

Index

Auditbeat

📡 Collecte (Beats)

⚙ Traitement (Logstash)

🔍 Stockage (Elasticsearch)

📊 Visualisation (Kibana)

✅ T7.8 — Quiz SIEM & Elastic Stack

Teste tes connaissances sur le SIEM et l'Elastic Stack. 15 questions pour valider ta maitrise du module.

SIEM & Elastic Stack