SIEM / XDR (EGID – ELK)

Contexte & cadrage

  • Établissement : ESIEA

  • Période : avril → juin 2024 (≈ 10–12 semaines)

  • Équipe : 3 personnes — rôle : chef de projet (coordination, agents, dashboards, runbook)

  • Objectif : présenter un SIEM fonctionnel à un jury mixte (pros & non-tech), avec démo d’incident

TL;DR

  • Infra Elastic Cloud (Elasticsearch/Kibana managés)

  • 2 endpoints Debian 11 reliés via Fleet / Elastic Agent

  • 3 dashboards (SSH, sudo, système) + alertes email

  • Démo “brute force → succès”, “sudo hors horaires”, “fichier critique modifié”

  • KPI : détection ≈ 15 s · 4 alertes déclenchées · 2 endpoints · 3 dashboards

Architecture 

  • Plateforme : Elastic Cloud (Elasticsearch + Kibana)

  • Collecte : Elastic Agent (Fleet) sur 2× Debian 11

  • Intégrations : System (syslog/auth), Auditd (événements sensibles)

  • Alerting : email (Kibana rules)

 Ce que j’ai fait 

  • Déploiement des Elastic Agents (Fleet) sur 2 hôtes Debian 11

  • Conception de 3 dashboards Kibana :

    • Authentifications & SSH (échecs, IP sources, comptes)

    • Élévation & sudo (commandes sensibles, horaires)

    • Vue système (reboots, services, noyau/Auditd)

  • Runbook & doc de soutenance (scénario, pas-à-pas, preuves à montrer)

Démo d’incident (lab contrôlé)

  1. Multiples échecs SSH depuis l’endpoint B vers A → alerte “brute force SSH”

  2. Connexion réussie juste après la rafale d’échecs → alerte “succès après échecs”

  3. Commande sudo hors 22h–06h → alerte “sudo sensible hors horaires”

  4. Modification d’un fichier critique (/etc/ssh/sshd_config) → alerte “fichier critique modifié”

Résultats & KPI

  • Détection ~15 s (du log à l’alerte visible)

  • 4 alertes déclenchées pendant la démo

  • 2 endpoints Debian 11 couverts

  • 3 dashboards opérationnels (SSH, sudo, système)

Difficultés & leçons

  • Qualité des données > quantité : mieux vaut 2 sources propres (System + Auditd) que 6 mal normalisées

  • Bruit d’alerte : limiter les faux positifs avant d’ajouter des règles “avancées”

  • Pédagogie jury : traduire le signal technique en scénarios compréhensibles (qui/quoi/quand/impact)

Amélioration prioritaire

  • Automatiser le déploiement des agents (Ansible) 

Stack & compétences mobilisées

  • Elastic Cloud (Elasticsearch, Kibana) · Fleet/Elastic Agent · Auditd

  • Debian 11 · SSH/Journalctl · notions réseau L2/L3

  • Alerting email (Kibana), dashboards orientés investigation

  • Gestion de projet (cadence, répartition, runbook)

Réception du jury

  • Curiosité et intérêt : démo lisible, bons échanges

  • Point d’attention : vulgariser les notions (logs → détection → alerte → décision)

En quoi ce projet m’a été utile

  • Capacité à mettre en place un socle SIEM simple et exploitable rapidement

  • Réflexe d’hygiène sécu (SSH, sudo, fichiers critiques) et observabilité de base

  • Documentation et scénarisation prêtes pour l’opérationnel

Retour en haut