Déroulé du cours 

3 Séances prévus :

• Fondamentaux et concepts 
• Méthodologie de détection et triage 
• Analyse et réponse au incidents

Plusieurs TP : 

• Découverte des logs 
• Analyse de logs et détection + Utilisation d'un SIEM 
• Investigation d'un incident complet

Evaluation

QCM à chaque séance (sauf la première) 

Format -> 20 questions 1 point par question et pas de point négatif

Restitution écrite ou orale des TP : 

Exemple -> Réalisation d'un compte rendu d'investigation d'une alerte SOC 

Des questions ?/Des attentes ? 

Introduction au SOC

• Comprendre ce qu'est un SOC et pourquoi il existe
• Identifier les rôles L1/L2/L3 et leurs responsabilités
• Distinguer les modèles d'organisation d'un SOC
• Appréhender les métriques clés de performance (MTTD, MTTR)
• Visualiser le flux de travail d'un analyste au quotidien

Objectifs de cette séance 

Le monde sous menace cyber

• En 2024 il y a eu une progression de 14% des cyberattaques 
• L'ANSSI a traité 4386 évènements de sécurité +15% par rapport à 2023 (ANSSI)
• Le coût moyen mondial d'une violation de données atteint 4,44 M $ en 2025 (IBM Cost of a Data Breach)

T-pot Honeypot map 

Définition du SOC

Un Security Operations Center (SOC) est une unité centralisée, composée de personnes, de processus et de technologies, dont la mission est de surveiller en continu (24h/24, 7j/7) l'environnement informatique d'une organisation afin de détecter, analyser, répondre et prévenir les incidents de sécurité.

Rôle du SOC dans une organisation

Le SOC travaille dans un écosystème de sécurité 

Architecture d'un SOC : N1/N2/N3

Structure en différent niveaux, comme dans une équipe médicale 

Détails des différents niveaux SOC

Modèle d'organisation d'un SOC

Il existe différents modèles selon les besoins et ressources 

Journée d'un analyste SOC N1

Prise de poste : Briefing par l'analyste sortant 

• Statut du dernier shift ?
• Incidents en cours 
• Point d'attention particuliers ? 

Monitoring en continue du Dasbhoard SOC 

• Surveillance des alertes en temps réel 
• Vérification des dashboards réseau

🚨Réception d'une alerte 

1. Lire l'alerte (quoi, où, quand)
2. Enrichir (contexte user, asset, IP)
3. Classer : vrai ou faux positif ?
4. Si vrai positif → escalader à L2 + ticket
5. Documenter dans le SIEM/ticketing

Journée d'un analyste SOC N2 chez Airbus Protect

• Traitement des alertes N2 de Nuit
• Traitement du triage (Signaux faibles en provenance des capteurs
• Préparation des Comités opérationnels
• Monitoring des alertes N2 Critiques
• Travaux de build SOC/Améliorations continue
• Threat Hunting/Threat intelligence

Présentation d'un dashboard SOC

Métriques clés de performance d'un SOC

 KPI (Key Performance Indicator) : indicateur chiffré permettant de mesurer la performance d'une équipe SOC.

Cas d'usage concrets traités par un SOC

Cas 1 - Phishing + Credential Stuffing

Email phishing reçu par 50 employés
    → Clic sur le lien par 3 personnes
    → Saisie identifiants sur faux portail
    → Connexion malveillante depuis IP roumaine
    → Alertes SIEM : connexion hors zone géographique

Quel Réaction du SOC ? 

Cas d'usage concrets traités par un SOC

Cas 2 - Ransomware

Macro Excel malveillante ouverte par un comptable
    → PowerShell lancé en arrière-plan
    → Tentative de connexion vers C2 externe
    → EDR détecte et bloque un comportement anormal

Quel Réaction du SOC ? 

Cas d'usage concrets traités par un SOC

Cas 3 - Insider Threat

Employé sur le départ exfiltre 2 Go de données client
    → DLP détecte upload massif vers Dropbox personnel

Quel Réaction du SOC ? 

Le cycle de vie d'un incident

Présentation de consoles EDR

Paysage des menaces et frameworks

• Identifier les principales menaces qui arrivent dans un SOC
• Comprendre la logique d'une attaque grâce à la Cyber Kill Chain
• Utiliser le framework MITRE ATT&CK pour contextualiser les menaces
• Maîtriser les types d'IOCs et leur utilité opérationnelle
• Comprendre la Pyramid of Pain et son impact défensif
• Avoir une vision de la réglementation applicable (NIS2, RGPD, ISO 27001)

Objectifs de cette séance 

Paysage des menaces

Ce que les SOC voient arriver chaque jour :

Zoom : Le Phishing 

De : support@miicrosoft.com

À  : john.doe@entreprise.fr
Sujet : ⚠️ Action requise – Votre compte va expirer

Bonjour John Doe,
Votre compte Microsoft 365 sera désactivé dans 24h.
Cliquez ici pour confirmer vos identifiants :

  [ https://login.micros0ft-secure.com/verify ]
                   

Cordialement,

L'équipe Microsoft Support

Anatomie d'un email de phishing typique :

Zoom : Le Phishing 

Ce qu'il faut voir côté SOC :

• Domaine expéditeur suspect (miicrosoft.com)
• URL de destination non-officielle
• Urgence artificielle (technique de pression)
• Demande de credentials par email 

Variants à connaître :

• Spear-phishing : ciblé (nom, poste, contexte réel de la victime)
• Whaling : phishing visant les dirigeants (PDG, CFO)
• Vishing : phishing vocal (appel téléphonique frauduleux)
• Smishing : phishing par SMS

Zoom : Le Ransomware

Cycle de vie d'une attaque ransomware

Pourquoi le ransomware est redouté ? :
 

Temps de détection critique : si le chiffrement démarre, il faut stopper immédiatement

Double extorsion : les données sont exfiltrées avant chiffrement → menace de publication

RaaS (Ransomware-as-a-Service) : accessible à des attaquants peu techniques

 

En 2021, l'hôpital de Dax (France) a été touché par le ransomware Ryuk. Résultat : 3 semaines de retour au papier, des opérations reportées, un coût de remédiation de 2,5M€

Zoom : APT, Malware, DOOS

APT (Advanced Persistent Threat) :

Définition : Acteur (souvent étatique) qui s'infiltre discrètement dans un réseau pour y rester longtemps, voler des données ou préparer un sabotage. Priorité à la furtivité, pas à la rapidité.

• Caractéristiques : discret, patient, multi-vecteurs, ressources importantes
• Exemples : APT28 (Fancy Bear / Russie), APT41 (Chine), Lazarus (Corée du Nord)
• Ce que voit le SOC : connexions inhabituelles, mouvements latéraux lents, outils légitimes détournés (Living-off-the-Land)

Zoom : APT, Malware, DOOS

Malware - Taxonomie simplifiée :

DDoS (Distributed Denial of Service) :

• Inonde un service de trafic jusqu'à indisponibilité
• Peut être une diversion pendant une vraie intrusion
• Détection SOC : pics de trafic anormaux, alertes WAF/firewall

La Cyber Kill Chain (Lockheed Martin)

Modèle développé par Lockheed Martin en 2011 décrivant les 7 étapes séquentielles qu'un attaquant doit franchir pour atteindre son objectif. 

La Cyber Kill Chain (Lockheed Martin)

Vision défensive de la cyberkillchain 

MITRE ATT&CK : Introduction

Base de connaissances mondiale, maintenue par MITRE Corporation, documentant les tactiques, techniques et procédures (TTPs) utilisées par des attaquants réels, observées sur des incidents authentiques.

MITRE ATT&CK : Introduction

Les 3 concepts clé : 

TACTIQUE  →  "Pourquoi ?"                        L'objectif tactique de l'attaquant
                                                                       ex: Initial Access, Persistence, Lateral Movement

TECHNIQUE →  "Comment ?"                   La méthode utilisée
                                                                       ex: T1078 - Valid Accounts

PROCÉDURE →  "Dans les détails ?"       L'implémentation spécifique d'un groupe
                                                                      ex: APT28 utilise T1078 via RDP

MITRE ATT&CK : Les 14 Tactiques Enterprise

MITRE ATT&CK Navigator : Démonstration

Indicateurs de Compromission (IOCs)

Les IOCs (Indicators of Compromise) sont des artefacts techniques observables qui indiquent qu'un système a potentiellement été compromis ou est ciblé par une menace.

Indicateurs de Compromission (IOCs)

Où vérifier un IOC en opérationnel :

•  VirusTotal (virustotal.com) — Hash, IP, domaine, URL
• AbuseIPDB (abuseipdb.com) — Réputation IP
• URLhaus (urlhaus.abuse.ch) — URLs malveillantes connues
• Shodan (shodan.io) — Contexte d'une IP/service
• MalwareBazaar (bazaar.abuse.ch) — Hashes de malwares connus

Pyramid of Pain

Modèle créé par David J. Bianco (2013) qui classe les IOCs selon la difficulté que leur détection impose à l'attaquant.

Pyramid of Pain

Implication pratique pour le SOC : 

De l'IOC à l'alerte : Flux opérationnel

Comment un IOC devient une alerte dans le SIEM : 

De l'IOC à l'alerte : Flux opérationnel

Les 3 natures d'IOCs à retenir opérationnellement :

Introduction aux cadres réglementaires 

NIS2 (Network and Information Security Directive 2)

• Directive européenne de cybersécurité adoptée en 2022 qui oblige un grand nombre d'organisations à atteindre un niveau minimum de sécurité informatique.

Introduction aux cadres réglementaires 

RGPD (Règlement Général sur la Protection des Données)

• Règlement européen entré en vigueur en mai 2018 qui encadre la collecte, le traitement et le stockage des données personnelles.

Introduction aux cadres réglementaires 

L'ISO/IEC 27001

• Norme internationale de référence pour la gestion de la sécurité de l'information. Publiée par l'ISO (Organisation internationale de normalisation), Contrairement au RGPD ou NIS2, c'est une certification volontaire, non une obligation légale.

Synthèse : Connecter tous les frameworks

TP - Analyse de logs web 

Nous avons récemment découvert qu’une partie de nos données privées a été publiée sur internet. Cette fuite a eu lieu le 14 octobre 2024 à 4h30 du matin. Nous soupçonnons que les attaquants ont utilisé notre serveur web comme point d’entrée dans leur attaque. Nous avons extrait les logs de ce serveur, couvrant une période de quelques jours avant l’attaque, afin que vous puissiez les analyser et découvrir ce qui s’est passé.

Objectif : 

• Trouver la chaîne de caractère utilisée pour déclencher la backdoor 
• IP renseigné comme argument de la backdoor

Awk

 Un fichier auth.log de 500 000 lignes.
  Trouver : toutes les IPs qui ont échoué > 100 fois.
  Temps avec un éditeur texte : 45 minutes
  Temps avec awk            : 3 secondes

Problème pour un analyste

Awk

awk en une phrase : un outil de traitement de texte ligne par ligne qui découpe chaque ligne en champs ($1, $2, $3...) et permet d'y appliquer des filtres et calculs.

Les 3 outils complémentaires à connaître :

La syntaxe de base

awk 'condition { action }' fichier

$0      → la ligne entière
$1      → le 1er champ (séparateur = espace par défaut)
$2      → le 2ème champ
$NF     → le DERNIER champ (NF = Number of Fields)
$(NF-1) → l'avant-dernier champ
NR      → numéro de la ligne courante (Number of Records)
NF      → nombre de champs dans la ligne courante
FS      → séparateur d'entrée (Field Separator)
OFS     → séparateur de sortie (Output Field Separator)

Les variables automatiques essentielles :

La syntaxe de base

Exemple sur une ligne de log 

# Extraire juste l'IP source

• awk '{print $12}' auth.log

# Extraire timestamp + IP

• awk '{print $1, $2, $3, $12}' auth.log

# Extraire le dernier champ (protocole ssh2)

• awk '{print $NF}' auth.log

Mar  9 03:22:10 srv-ssh-01 sshd[2200]: Failed password for invalid user root from 103.89.235.14 port 63695 ssh2
 $1   $2    $3         $4                $5                 $6         $7          $8   $9       $10  $11    $12       $13              $14   $15

Filtrer avec des conditions

# Syntaxe : awk '/regex/ { action }' ou awk '$champ == "valeur" { action }'

# Lignes contenant "Failed"
awk '/Failed/' auth.log

# Lignes où le champ $6 vaut "Failed"
awk '$6 == "Failed"' auth.log

# Lignes où l'IP ($12) est précise
awk '$12 == "103.89.235.14"' auth.log

# Combiner plusieurs conditions (ET logique)
awk '/Failed/ && /103.89.235.14/' auth.log

# Combiner plusieurs conditions (OU logique)
awk '/Failed/ || /Accepted/' auth.log

# Lignes où NF > 14 (lignes assez longues)
awk 'NF > 14' auth.log

# Première et dernière ligne
awk 'NR == 1 || NR == NF' auth.log

Compter et agréger

# Compter les lignes qui matchent un pattern
awk '/Failed password/{count++} END{print count}' auth.log

# Compter les occurrences par IP (compteur associatif)
awk '/Failed password/{count[$12]++}
     END{for (ip in count) print count[ip], ip}' auth.log

# Trier le résultat (pipe vers sort)
awk '/Failed password/{count[$12]++}
     END{for (ip in count) print count[ip], ip}' auth.log \
     | sort -rn

# Résultat attendu sur notre auth.log :
# 220 103.89.235.14     ← l'attaquant !
#   3 192.168.1.22
#   1 192.168.1.10

Changer le séparateur (CSV, Apache logs, proxy)

# Séparateur virgule (CSV)
awk -F',' '{print $1, $3}' proxy_logs.csv

# Séparateur tabulation
awk -F'\t' '{print $2}' fichier.tsv

# Séparateur multi-caractères (ex: " - " dans Apache logs)
awk -F'" "' '{print $1}' apache_access.log

# Combiner plusieurs séparateurs avec regex
awk -F'[,;:]' '{print $2}' fichier.txt

Par défaut, awk sépare sur les espaces. Pour les CSV :

Changer le séparateur (CSV, Apache logs, proxy)

# Lister toutes les destinations uniques
awk -F',' 'NR>1 {print $3}' proxy_logs.csv | sort -u

# Compter les connexions par destination
awk -F',' 'NR>1 {count[$3]++}
           END{for (d in count) print count[d], d}' proxy_logs.csv \
     | sort -rn | head 10

# Filtrer uniquement la machine suspecte (192.168.1.33)
awk -F',' 'NR>1 && $2=="192.168.1.33" {print $1, $3, $5, $6}' proxy_logs.csv

Par défaut, awk sépare sur les espaces. Pour les CSV :

Blocs BEGIN et END

# BEGIN → s'exécute UNE FOIS avant la lecture du fichier
# END   → s'exécute UNE FOIS après la lecture complète

awk '
BEGIN {
    print "=== Analyse du fichier auth.log ==="
    print "IP\t\t\tTentatives"
    print "─────────────────────────────────"
    FS = " "        # définir le séparateur dans BEGIN
}

/Failed password/ {
    count[$12]++
    total++
}

END {
    for (ip in count) {
        print ip "\t\t" count[ip]
    }
    print "─────────────────────────────────"
    print "TOTAL tentatives échouées:", total
}
' auth.log

Blocs BEGIN et END

=== Analyse du fichier auth.log ===
IP                  Tentatives
─────────────────────────────────
103.89.235.14       220
192.168.1.22        3
192.168.1.10        1
─────────────────────────────────
TOTAL tentatives échouées: 224

Cas 1 : Détecter un brute force dans auth.log

# IPs avec plus de 10 tentatives = brute force probable
awk '/Failed password/ {count[$12]++}
     END {
       for (ip in count)
         if (count[ip] > 10)
           print "⚠️  BRUTE FORCE:", ip, "→", count[ip], "tentatives"
     }' auth.log

Cas 2 : Extraire la timeline d'une IP dans auth.log

# Toutes les actions de l'IP attaquante avec horodatage
awk '$0 ~ "103.89.235.14" {print $1, $2, $3, "→", $0}' auth.log \
    | head -20

Cas 3 : Analyser les codes HTTP dans apache_access.log

# Compter les codes de retour HTTP
awk '{print $9}' apache_access.log \
    | sort | uniq -c | sort -rn

# Lister toutes les requêtes avec code 500 (erreurs serveur)
awk '$9 == "500" {print $1, $7, $9}' apache_access.log

# Détecter les scanners (beaucoup de 404 depuis même IP)
awk '$9 == "404" {count[$1]++}
     END {for (ip in count) if (count[ip] > 20)
           print "SCAN potentiel:", ip, count[ip], "erreurs 404"}' \
     apache_access.log

Cas 4 : Calculer l'intervalle de beaconing sur proxy_logs.csv

# Isoler uniquement les connexions vers le domaine C2 et afficher les timestamps pour calculer l'intervalle

awk -F',' 'NR>1 && $3=="updates-cdn-delivery.com" {print $1}' \
     proxy_logs.csv | head -10

# Compter le nombre total de beacons
awk -F',' 'NR>1 && $3=="updates-cdn-delivery.com" {count++}
           END {print "Total beacons C2:", count}' proxy_logs.csv

Cas 5 : Extraire tous les IOCs (IPs uniques suspectes)

# Dans auth.log : toutes les IPs sources des Failed password
awk '/Failed password/ {print $12}' auth.log | sort -u

# Dans apache : toutes les IPs avec des requêtes SQL injection
awk '/UNION|SELECT|DROP|INSERT/ {print $1}' apache_access.log | sort -u

# Dans proxy : toutes les IPs de destination uniques
awk -F',' 'NR>1 {print $4}' proxy_logs.csv | sort -u

One-liners à retenir pour l'analyse de logs

# Les 10 IPs les plus actives dans n'importe quel log
awk '{print $1}' fichier.log | sort | uniq -c | sort -rn | head 10

# Filtrer une plage horaire (ex: entre 02:00 et 04:00)
awk '$3 >= "02:00:00" && $3 <= "04:00:00"' auth.log

# Extraire les URLs d'un access.log Apache
awk '{print $7}' apache_access.log | sort -u

# Compter les connexions par heure
awk '{print substr($3,1,2)}' auth.log | sort | uniq -c

# Trouver les lignes trop longues (ex: payload SQLi)
awk 'length($0) > 500' apache_access.log

# Afficher la ligne N (ex: ligne 42)
awk 'NR==42' auth.log

# Afficher les lignes entre N et M
awk 'NR>=100 && NR<=150' auth.log

# Reformater une sortie (CSV → lisible)
awk -F',' '{printf "%-20s %-30s %s\n", $2, $3, $6}' proxy_logs.csv

One-liners à retenir pour l'analyse de logs

# Les 10 IPs les plus actives dans n'importe quel log
awk '{print $1}' fichier.log | sort | uniq -c | sort -rn | head 10

# Filtrer une plage horaire (ex: entre 02:00 et 04:00)
awk '$3 >= "02:00:00" && $3 <= "04:00:00"' auth.log

# Extraire les URLs d'un access.log Apache
awk '{print $7}' apache_access.log | sort -u

# Compter les connexions par heure
awk '{print substr($3,1,2)}' auth.log | sort | uniq -c

# Trouver les lignes trop longues (ex: payload SQLi)
awk 'length($0) > 500' apache_access.log

# Afficher la ligne N (ex: ligne 42)
awk 'NR==42' auth.log

# Afficher les lignes entre N et M
awk 'NR>=100 && NR<=150' auth.log

# Reformater une sortie (CSV → lisible)
awk -F',' '{printf "%-20s %-30s %s\n", $2, $3, $6}' proxy_logs.csv

Exercices pratiques

• Exercice 1 : Affichez uniquement les lignes de auth.log qui contiennent "Accepted", en n'affichant que le timestamp ($1 $2 $3), le nom d'utilisateur ($9) et l'IP source ($11).

• Exercice 2 : Trouvez dans auth.log toutes les IPs qui ont eu au moins 5 tentatives échouées, et affichez-les triées par nombre de tentatives décroissant.

• Exercice 3 : Dans apache_access.log, comptez le nombre de requêtes par code HTTP (200, 301, 302, 403, 404, 500...) et affichez un résumé propre avec BEGIN/END.

• Exercice 4  : Dans proxy_logs.csv, calculez pour chaque IP source le total de bytes envoyés ($5) et le total de bytes reçus ($6), triés par bytes envoyés décroissant.

• Exercice 5 : Dans auth.log, identifiez les IPs qui ont eu des tentatives échouées puis une connexion réussie — signe d'une compromission par brute force abouti.

Outils SOC - SIEM et EDR  

• Comprendre ce qu'est un SIEM et comment il fonctionne

• Distinguer les principaux SIEM du marché (ELK, Splunk, Sentinel)

• Comprendre la différence entre antivirus, EDR et XDR

• Visualiser le pipeline complet de données d'un SOC

• Identifier l'écosystème d'outils complémentaires (SOAR, TIP, ticketing)

Objectifs de cette séance 

Pourquoi les outils sont indispensables

La réalité du volume de données dans un SOC :

Le SIEM : définition et rôle

SIEM (Security Information and Event Management) : Plateforme centralisée qui collecte, normalise, corrèle et alerte sur des événements de sécurité provenant de sources hétérogènes (endpoints, réseau, applications, cloud), avec conservation des logs pour investigation et conformité.

Le SIEM : définition et rôle

Les 4 fonctions clés d'un SIEM : 

Pipeline de données SIEM : de la source à l'alerte

Le voyage d'un log dans un SIEM :

Pipeline de données SIEM : de la source à l'alerte

Les concepts clés :

• Agent / Forwarder : logiciel léger installé sur la source pour envoyer les logs
• Parsing : découper un log brut en champs structurés (IP source, timestamp, action…)
• Normalisation : mettre en format commun (ex : ECS pour ELK)
• Corrélation : croiser plusieurs événements pour détecter un pattern d'attaque
• Index : base de données optimisée pour la recherche dans les logs

Règle de corrélation SIEM : anatomie

Exemple concret d'une règle de détection brute-force :

# Règle SIEM - Détection brute-force sur Windows
Nom      : Brute Force - Multiples échecs d'authentification
Logique  :
    IF Event ID = 4625 (Failed Logon)
    AND même compte cible (TargetUserName)
    AND même IP source (IpAddress)
    AND COUNT > 10
    WITHIN 5 minutes
   
THEN :
    → Créer alerte : SEVERITY = HIGH
    → Enrichissement automatique : réputation IP (TIP)
    → Ouvrir ticket dans TheHive

Règle de corrélation SIEM : anatomie

Types de règles classiques en SOC :

• Threshold : seuil dépassé (>10 échecs en 5 min)
• Whitelist/Blacklist : IOC connu dans une liste
• Sequence : événements dans un ordre précis (logon → recon → lateral move)
• Anomalie : déviation statistique du comportement normal (UEBA)

Les SIEM du marché : panorama

Les 3 SIEM les plus rencontrés en SOC :

Architecture ELK Stack détaillée

Les 4 composants de l'ELK Stack :

• Beats : agents légers qui collectent et envoient les logs depuis les sources
• Logstash : pipeline de traitement (filtre, enrichit, route les logs)
• Elasticsearch : moteur de stockage et de recherche distribué 
• Kibana : interface web pour visualiser, requêter et alerter

De l'antivirus à l'EDR : évolution

L'évolution des outils de protection endpoint :

EDR vs XDR : comparaison détaillée

Ce que voit un EDR vs XDR :

EDR vs XDR : comparaison détaillée

Ce que télémètre un EDR sur un endpoint :

L'écosystème complet d'un SOC

Un SOC mature ne fonctionne pas avec un seul outil :

L'écosystème complet d'un SOC

Les outils complémentaires à connaître :

Interface SIEM Kibana avec alertes réelles

Focus : Sysmon, l'EDR gratuit de Microsoft

Sysmon (System Monitor) : Outil gratuit de Microsoft Sysinternals qui enrichit considérablement la télémétrie Windows en loggant des événements critiques absents des logs natifs.

Synthèse : Quelle brique pour quel besoin ?

Matrice des outils selon les cas d'usage SOC :

Ce que l'IA change dans le SIEM moderne (2025)

L'évolution majeure des SIEM en 2025 :
 

• Réduction du bruit : Les SIEM modernes (Elastic 8.x, Sentinel) intègrent des modèles ML pour regrouper les alertes similaires et réduire la fatigue des analystes
• UEBA (User and Entity Behavior Analytics) : Détection d'anomalies comportementales (ex : un utilisateur qui télécharge 100x plus que d'habitude)
• AI-assisted triage : Suggestion automatique de classification (faux/vrai positif) avec score de confiance
• Generative AI : Certains SIEM proposent des explications en langage naturel des alertes