SIEM & SOAR – Rapport d’Analyse

1. Définir les concepts

Qu’est-ce qu’un système SIEM et quel est son rôle principal dans la sécurité informatique ?

Un système SIEM (Security Information and Event Management) est une solution technologique qui collecte, normalise, corrèle et analyse en temps réel les journaux de sécurité provenant de divers systèmes du réseau (serveurs, pare-feux, postes clients, applications). Son rôle principal est de détecter les activités suspectes ou malveillantes, d’alerter les équipes de sécurité, et de fournir une vue centralisée pour l’investigation forensique et la conformité réglementaire (lois 25, ISO 27001, etc.).

Qu’est-ce qu’un système SOAR et comment complète-t-il un système SIEM ?

Un système SOAR (Security Orchestration, Automation, and Response) est une plateforme qui automatise et orchestre les processus de réponse aux incidents détectés par le SIEM. Il complète le SIEM en transformant les alertes en actions concrètes : blocage d’IP, isolation d’hôte, notification d’équipe, ouverture de ticket. Le SIEM détecte, le SOAR réagit.

2. Fonctionnalités principales

Trois fonctionnalités principales du SIEM :

• Collecte centralisée des journaux : Rassemble les logs de toutes les sources du réseau.
• Corrélation d’événements en temps réel : Identifie des schémas d’attaque complexes (ex. : plusieurs échecs SSH suivis d’une connexion réussie).
• Visualisation et reporting : Fournit des tableaux de bord et rapports pour l’analyse et la conformité.

Trois fonctionnalités principales du SOAR :

• Automatisation des playbooks : Exécution automatique d’actions pré-définies en réponse à une alerte.
• Intégration avec les outils de sécurité : Connexion aux pare-feux, EDR, SIEM, outils de ticketing (Jira, ServiceNow).
• Gestion des cas (Case Management) : Suivi complet d’un incident de sa détection à sa résolution.

3. Intégration et avantages

Comment SIEM et SOAR peuvent-ils être intégrés pour améliorer la gestion des incidents de sécurité ?

Le SIEM détecte une anomalie (ex. : 5 échecs de connexion SSH en 2 minutes) et envoie une alerte au SOAR. Ce dernier enrichit l’alerte avec des données de menace externe (threat intelligence), puis déclenche un playbook automatisé : blocage de l’IP au firewall, notification par email, ouverture d’un ticket dans Jira. Ainsi, la réponse passe de manuelle (minutes/heures) à automatisée (secondes).

Quels sont les avantages de cette intégration pour une entreprise ?

• Réduction du temps de réponse (de heures à secondes)
• Diminution des erreurs humaines
• Meilleure scalabilité face à un volume élevé d’incidents
• Traçabilité complète des actions, conformité renforcée
• Libération des analystes pour des tâches à plus forte valeur ajoutée

Détection et Réponse à une Tentative de Compromission

Objectif : Utiliser Splunk (SIEM) pour analyser les logs, détecter une activité suspecte, et créer une alerte déclenchable par le SOAR.

1. Analyse des Journaux avec le SIEM (Splunk)

Journaux examinés

• /var/log/auth.log : Contient les tentatives de connexion SSH (réussies ou échouées).
• sourcetype=secure : Filtre Splunk pour les logs d’authentification système.
• index=main : Index par défaut où Splunk stocke les événements.

Comportement anormal détecté

• Plusieurs tentatives en moins de 5 secondes → signe de force brute automatisée.
• Origine : ::1 (localhost) → soit un script malveillant local, soit un test interne non autorisé.
• Cible : le compte utilisateur kali.

Il s’agit d’une tentative de compromission active par force brute SSH.

2. Création d’une Alerte dans Splunk (SIEM)

Il s’agit d’une tentative de compromission active par force brute SSH :

Des tentatives de connexion SSH échouées via la commande :

Les logs correspondants dans /var/log/auth.log avec :

J’ai créé une alerte dans Splunk pour détecter automatiquement ce genre d’attaque à l’avenir.

• Nom de l’alerte : SSH Brute Force Detection - Kali Host
• Requête d’alerte :

• Fréquence : Toutes les heures
• Action déclenchée : Envoyer un email

Playbook SOAR : Réponse à une tentative de force brute SSH

1. Confirmation de la menace : L’alerte Splunk indique 4 tentatives d’authentification échouées en moins de 5 secondes depuis ::1 (localhost) pour le compte kali. Ce comportement est caractéristique d’une attaque automatisée → menace confirmée.
2. Action corrective : Blocage temporaire des connexions SSH pour le compte kali via modification de /etc/ssh/sshd_config (DenyUsers) + rechargement du service SSH.
3. Notification : Email envoyé à l’équipe sécurité + ticket créé dans Jira avec les détails de l’incident.
4. Post-action :
   • Le SOAR exécute automatiquement le blocage de l’IP.
   • Le compte compromis est désactivé.
   • L’équipe SOC est notifiée immédiatement.
   • L’incident est documenté dans un rapport.

Réflexion Critique

Ce que j’ai trouvé le plus utile :

• Le SIEM m’a permis de voir clairement ce qui se passait sur le serveur. Sans lui, j’aurais dû fouiller manuellement dans les logs.
• Grâce à la requête et à l’alerte, j’ai détecté l’attaque en quelques secondes.

Le SOAR (Playbook) :

• Le SOAR permet d’automatiser la réponse, ce qui réduit le stress et le temps de réaction lors d’un incident. Il garantit aussi la cohérence des actions et la traçabilité pour l’audit.

Je pourrais faire ces améliorations :

• Ajouter une étape de vérification humaine pour les actions importantes (ex: bloquer un compte), demander une validation à un analyste avant d’exécuter pour éviter les erreurs si c’est juste un utilisateur qui a oublié son mot de passe.
• Surveiller plus de sources : Ajouter les logs de cron, .bash_history ou les connexions réseau pour détecter d’autres signes de compromission (ex: un script malveillant qui tourne en arrière-plan).
• Améliorer l’alerte : Passer de “toutes les heures” à “toutes les 5 minutes” pour réagir plus vite. Et ajouter un webhook vers le SOAR pour montrer l’intégration complète.