Cybersécurité

SOC et SIEM : détecter les incidents de sécurité

11 دقائق للقراءة

Ce que vous saurez faire à la fin

  1. Monter un SOC minimal avec Wazuh
  2. Collecter logs de vos sources
  3. Écrire des règles de détection Sigma
  4. Automatiser la réponse avec un SOAR
  5. Mesurer MTTD et MTTR

Étape 1 — Concepts

SOC   équipe surveillance 24/7
SIEM  plateforme logs corrélés
SOAR  playbooks auto
XDR   SIEM + EDR + NDR intégrés
MTTD  temps moyen détection
MTTR  temps moyen réponse

Étape 2 — Sources logs

Identité:   Azure AD, Google Workspace
Endpoints:  Windows Event, Linux auditd
Réseau:     firewall, VPN, DNS
Cloud:      CloudTrail, Activity Log
Apps:       PostgreSQL, Gitlab audit
Email:      O365 audit

Étape 3 — Déployer Wazuh

git clone https://github.com/wazuh/wazuh-docker.git -b v4.8.0
cd wazuh-docker/single-node
docker compose up -d

# Accès: https://localhost (admin/SecretPassword)

Étape 4 — Agent

curl -so wazuh-agent.deb \
  "https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.8.0-1_amd64.deb"
sudo WAZUH_MANAGER='siem.example.sn' dpkg -i wazuh-agent.deb
sudo systemctl enable --now wazuh-agent

Étape 5 — Règle custom

<rule id="100010" level="10">
  <if_sid>5716</if_sid>
  <srcip>!192.168.0.0/16</srcip>
  <description>Brute-force SSH depuis IP externe</description>
  <mitre><id>T1110</id></mitre>
</rule>

Étape 6 — Sigma

title: Suspicious PowerShell
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'DownloadString'
      - 'IEX '
      - 'FromBase64String'
  condition: selection
level: high
tags:
  - attack.t1059.001
pip install pysigma pysigma-backend-elasticsearch
sigma convert -t es-qs rule.yml

Étape 7 — Alertes Elastic Watcher

{
  "trigger": { "schedule": { "interval": "1m" } },
  "input": {
    "search": {
      "request": {
        "indices": ["logs-auth-*"],
        "body": {
          "query": { "bool": { "filter": [
            { "match": { "event.outcome": "failure" } },
            { "range": { "@timestamp": { "gte": "now-5m" } } }
          ]}},
          "aggs": { "per_user": { "terms": { "field": "user.name" }}}
        }
      }
    }
  },
  "condition": { "script": "return ctx.payload.aggregations.per_user.buckets.stream().anyMatch(b -> b.doc_count > 20)" },
  "actions": { "slack": { "webhook": { "url": "..." }}}
}

Étape 8 — SOAR avec Shuffle

docker run -d -p 3001:3001 frikky/shuffle:latest
Workflow SOAR:
1. Trigger: Wazuh alert "Brute force SSH"
2. GeoIP lookup
3. VirusTotal réputation IP
4. Si abuse_score > 70:
   - Bloquer IP dans AWS SG
   - Créer ticket Jira
   - Slack #soc
5. Sinon: assigner L1 pour validation

Étape 9 — KPIs

MTTD         cible < 1h critical
MTTR         cible < 4h
False Positive cible < 20%
Coverage MITRE cible > 60%
Auto-playbook  cible > 40%

Étape 10 — Checklist démarrage SOC

✓ Wazuh/Elastic déployé
✓ Agents sur endpoints critiques
✓ Sources cloud intégrées
✓ 20+ règles custom
✓ Alertes Slack fonctionnelles
✓ SOAR pour playbooks basiques
✓ Runbooks écrits et testés
✓ Threat intel (OTX, Abuse.ch)
✓ Dashboard exec MTTD/MTTR
✓ Post-mortem après incident
✓ Exercice tabletop trimestriel

Solution d’hébergement pour ce tutoriel

Hostinger accueille un site WordPress, un VPS Linux ou une boutique en ligne sans configuration complexe.

Démarrer chez Hostinger →

Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.

Etape 1 : comprendre la difference SOC vs SIEM en 2026

Un SOC (Security Operations Center) est une equipe humaine de 3 a 12 analystes qui surveillent 24/7 les alertes de securite. Un SIEM (Security Information and Event Management) est l’outil logiciel qui centralise les logs, applique des regles de correlation et genere les alertes. Sans SIEM, les analystes du SOC perdent 80 % de leur temps a chercher les logs. Sans SOC, le SIEM crie dans le vide.

En Afrique de l’Ouest, peu de PME peuvent payer un SOC commercial Orange Cyberdefense ou IBM (a partir de 6500 EUR / mois soit environ 4 264 000 FCFA). Construire un mini-SOC interne avec Wazuh 4.10 + OpenSearch 2.18 sur un VPS, plus 2 analystes formes, ramene la facture mensuelle sous 800 000 FCFA tout compris.

Etape 2 : choisir Wazuh comme SIEM open-source

Wazuh 4.10 (octobre 2025) est un fork ameliore d’OSSEC qui combine HIDS, FIM, detection d’intrusion, vulnerability scanning et conformite PCI-DSS / HIPAA. Il s’integre nativement avec OpenSearch 2.18 (le fork AWS d’Elasticsearch) pour le stockage et la recherche, et avec Wazuh Dashboard pour la visualisation. La pile entiere est Apache 2.0, donc gratuite meme en commercial.

L’alternative Splunk Enterprise demarre a 1800 USD / Go / an soit environ 1 180 000 FCFA, totalement hors budget pour une banque mutualiste a Thies ou Bouake. Wazuh donne 80 % des features de Splunk pour 0 FCFA de licence, juste le cout VPS.

Etape 3 : provisionner l’infrastructure Wazuh manager + indexer + dashboard

Pour 100 endpoints surveilles, prevois un VPS Hetzner CCX23 (8 vCPU, 16 Go RAM, 320 Go SSD, 25,90 EUR HT soit environ 17 000 FCFA / mois). Installe Ubuntu 24.04 LTS et lance le script all-in-one officiel.

curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh && sudo bash wazuh-install.sh -a

Le script deploie Wazuh Indexer (OpenSearch), Wazuh Manager et Wazuh Dashboard avec certificats auto-signes. Comptez 8 minutes. Le signal de reussite : le script affiche les credentials admin et tu peux te connecter sur https://IP_VPS/ avec admin / mot_de_passe_genere.

Etape 4 : enroler les endpoints Linux et Windows

Sur chaque serveur ou poste a surveiller, installe l’agent Wazuh 4.10. Pour Linux Ubuntu / Debian via le repository officiel, pour Windows via le MSI signe. Pointe l’agent vers WAZUH_MANAGER=IP_VPS et redemarre le service wazuh-agent.

WAZUH_MANAGER="10.0.0.10" apt install wazuh-agent && systemctl enable --now wazuh-agent

Dans le dashboard Wazuh, va sur Agents : tu dois voir l’hote en statut Active dans les 60 secondes. Si l’agent reste Disconnected, verifie le firewall TCP 1514 + 1515 entre l’agent et le manager, et synchronise les horloges via chrony.

Etape 5 : activer File Integrity Monitoring sur les chemins critiques

FIM detecte la modification non autorisee de /etc/passwd, /etc/shadow, /var/www, ou des registres Windows. Edite /var/ossec/etc/ossec.conf sur le manager pour ajouter les chemins surveilles avec frequency=21600 (toutes les 6 heures) et realtime=yes pour les plus critiques.

<syscheck>
  <directories realtime="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories realtime="yes" check_all="yes">/var/www</directories>
</syscheck>

Test : touche /etc/passwd. Dans le dashboard, l’evenement 550 (Integrity checksum changed) doit apparaitre en moins de 30 secondes avec le hash avant / apres et l’utilisateur responsable.

Etape 6 : ecrire des regles de correlation MITRE ATT&CK

Wazuh est livre avec 3500 regles par defaut mappees sur le framework MITRE ATT&CK. Active les groupes les plus pertinents pour ton contexte : authentication_failed (T1110 brute force), shellshock (T1190 exploit), suspicious_command (T1059 command and scripting). Cree ensuite des regles custom dans /var/ossec/etc/rules/local_rules.xml.

<rule id="100200" level="12">
  <if_matched_sid>5712</if_matched_sid>
  <same_source_ip />
  <different_user />
  <description>SSH brute force depuis $(srcip)</description>
  <mitre><id>T1110</id></mitre>
</rule>

Test avec hydra ou un script qui lance 10 tentatives SSH en 1 minute depuis une IP externe. Tu dois recevoir une alerte niveau 12 dans le dashboard avec le tag mitre.id=T1110 et l’IP source bannie automatiquement par active-response si tu l’as configuree.

Etape 7 : configurer les notifications Slack et email

Edite ossec.conf dans la section global pour ajouter un email_notification yes et un smtp_server, ou pour Slack utilise le module integration avec un webhook Incoming. Filtre les notifications a level >= 10 pour eviter le spam, sinon tes analystes desactiveront le canal apres 2 jours.

Le signal de reussite : declenche manuellement une regle de niveau 12 (cat /etc/shadow par un utilisateur non-root) et tu dois recevoir le message Slack dans la minute avec contexte hostname, user, command et MITRE ID.

Etape 8 : retention longue duree avec OpenSearch ISM

OpenSearch Index State Management compresse automatiquement les indices wazuh-alerts plus vieux que 7 jours, les bascule en cold storage apres 30 jours et les supprime apres 365 jours pour respecter la directive CEDEAO. Cree une politique ISM via le dashboard Index Management qui execute ces transitions sans intervention manuelle.

Pour étoffer le tableau : observabilite Grafana Loki Prometheus et durcissement VPS Linux.

Etape 9 : automatiser le triage avec TheHive 5 et Cortex 3.1

Wazuh genere des alertes mais ne gere pas leur cycle de vie : qui les analyse, qui les ferme, quel temps moyen de resolution. TheHive 5.4 est une plateforme open-source de Security Incident Response qui ingere les alertes Wazuh via webhook, les transforme en cases avec ticket, assignee, severity, et joue automatiquement des analyzers Cortex (VirusTotal, AbuseIPDB, MISP) pour enrichir l’IP, le hash ou l’URL suspects.

Sur le meme VPS, deploie TheHive et Cortex avec docker compose. Configure ensuite l’integration Wazuh > TheHive : chaque alerte de niveau 12+ cree un case avec template SOC-L1. L’analyste de Dakar voit toute la file dans un kanban, traite, ferme avec resolution true positive ou false positive et le SLA p95 passe de 4 heures a 35 minutes.

Etape 10 : connecter MISP pour le partage de threat intelligence regional

MISP est la plateforme de reference pour l’echange d’IOCs (Indicators of Compromise) entre CSIRT. Le SENCERT (Senegal Computer Emergency Response Team) et le CI-CERT (Cote d’Ivoire) maintiennent des feeds publiques d’IOCs lies a des campagnes phishing visant les banques mobiles et les cooperatives microfinance ouest-africaines.

./modules/cortex/analyzers/MISP/MISP_run.py --url https://misp.sencert.sn --key TON_API_KEY

Configure Cortex pour interroger ce feed regional sur chaque IP ou hash detecte par Wazuh. Si l’IOC est connu, l’alerte saute en severity=critical et tu coupes la connexion avec un active-response iptables drop dans la seconde. Cette integration locale donne un avantage decisif sur les campagnes ciblant Wave, Mixx by Yas ou Orange Money.

Etape 11 : tester avec Atomic Red Team et Caldera

Une regle non testee est une regle morte. Atomic Red Team est une bibliotheque open-source de 1700 tests d’attaque mappes sur MITRE ATT&CK. Lance un test T1059.001 (PowerShell exec) sur un endpoint Windows, verifie que Wazuh leve l’alerte et que TheHive cree le case en moins de 2 minutes.

Pour des scenarios complets, deploie MITRE Caldera 5.0 sur un VPS isole. Caldera execute des chaines d’attaque automatisees (initial access, execution, lateral movement, exfiltration) et te donne un score de detection par tactique. Vise 80 % de detection sur les tactiques Initial Access et Execution avant de passer en production.

Etape 12 : recruter et former les analystes L1 et L2

Un mini-SOC tourne minimum avec 3 analystes pour assurer une astreinte 24/7 (8h x 3 + roulement weekend). A Dakar, le profil L1 (junior, BAC+3 securite reseau) est paye 350 000 a 500 000 FCFA brut mensuels, le profil L2 (5 ans d’experience, certifie BTL1 Security ou eJPT) entre 700 000 et 1 200 000 FCFA. La certification SecurityBlue Team Level 1 a 545 USD soit environ 358 000 FCFA est un excellent investissement de formation initiale, plus rentable que SOC Analyst Splunk a 2700 USD.

Mets en place un runbook ecrit pour chaque type d’alerte : brute force SSH, FIM critique, scan de port, beacon C2 suspect. Un L1 doit pouvoir conclure 80 % des alertes en moins de 10 minutes en suivant le runbook, et n’escalader vers L2 que les cas ambigus. Sans runbook, le ROI du SIEM s’effondre car les analystes ferment des cases au hasard.

Etape 13 : KPIs de SOC a suivre mensuellement

Cinq metriques mesurent la sante de ton SOC : MTTD (Mean Time To Detect, vise sous 5 minutes), MTTR (Mean Time To Respond, vise sous 30 minutes), false positive rate (vise sous 15 %), coverage MITRE ATT&CK (vise plus de 60 % des sous-tactiques), et nombre de cases traites par analyste par jour (entre 8 et 15 selon le mix).

Construis un dashboard Grafana branche sur l’API TheHive qui affiche ces 5 KPIs sur 30 jours glissants. Presente-les en comite securite mensuel. Si MTTD depasse 15 minutes, c’est probablement un probleme de regles trop bruyantes qui noient les vraies alertes : audite et desactive les regles avec false positive rate >50 %.

Etape 14 : conformite directive CEDEAO et reporting CDP

La directive CEDEAO de 2010 sur la cybersecurite et la loi senegalaise 2008-11 imposent la notification des incidents majeurs sous 72 heures aux autorites competentes. Documente chaque case TheHive avec timeline, IOCs, mesures prises et impact. Exporte en PDF signe quand un case atteint le seuil « donnees personnelles compromises » et envoie via courrier recommande au regulateur sectoriel (BCEAO pour les banques, ARTP pour telecoms, CDP pour le reste).

Le signal de reussite : un audit BCEAO peut consulter en moins de 30 minutes les logs et l’analyse d’un incident vieux de 6 mois, avec preuve d’integrite (hash SHA-256 des indices OpenSearch versionnes). Cette capacite est la difference entre une amende et une mention de bonnes pratiques.

Etape 15 : checklist de mise en production du SOC interne

Avant d’annoncer le SOC interne en comite executif, valide ces dix points : Wazuh manager redondant en HA active-passive, OpenSearch en cluster 3 nodes pour resilience, sauvegarde S3 quotidienne des indices wazuh-alerts, certificats TLS valides plus de 60 jours, MFA obligatoire sur le dashboard pour tous les analystes, runbooks ecrits pour les 12 alertes les plus frequentes, integration TheHive plus Cortex plus MISP testee de bout en bout, simulation Atomic Red Team avec 80 % de detection minimum, formation de tous les analystes a BTL1 ou equivalent, et procedure documentee de notification CDP plus BCEAO sous 72h. Chaque point manquant = un risque operationnel ou reglementaire significatif.

مشاركة