Splunk vs ELK : implémenter des règles d’alerte pour le SOC

Splunk vs ELK : implémenter des règles d’alerte pour le SOC

Sommaire

1. Introduction — objectif et public visé

Ce guide opérationnel décrit pas-à-pas la conception, l’implémentation et le tuning d’un système d’alerting de sécurité basé sur Splunk ou Elastic Stack (ELK). Le contenu est rédigé pour les RSSI, SOC, ingénieurs sécurité, administrateurs SIEM et équipes d’opérations. Toutes les étapes sont claires, reproduisibles, et comprennent des exemples concrets (requêtes SPL, KQL/DSL, règles ElastAlert, Watcher JSON), des scripts et des procédures pas à pas pour la console Splunk et Kibana.

2. Pourquoi des alertes de sécurité ? Principes et stratégie

Les alertes traduisent des règles de détection en notifications exploitables par le SOC. Objectifs :

  • Détecter rapidement incidents (bruteforce, exfiltration, lateral movement).
  • Prioriser et enrichir automatiquement pour accélérer la réponse.
  • Réduire le bruit (false positives) par tuning, corrélation et suppression adaptative.

Principes à respecter :

  • Détection centrée sur le risque : couvrir d’abord actifs critiques.
  • Simplicité & actionabilité : chaque alerte doit déclencher une action précise (enquête, blocage).
  • Mesurabilité : définir KPIs (MTTA, MTTR, taux FP).
  • Automatisation prudente : actions automatiques seulement si fiable (ex : blocage IP si score > seuil).

3. Architecture et prérequis (Splunk & ELK)

Splunk (Enterprise / Cloud)

  • Collecteurs/forwarders (Universal Forwarder) entêtes : logs endpoints, logs réseau, proxies, IDM, cloud logs.
  • Indexeurs et Search Heads (single sign-on, rôle SOC).
  • Apps recommandées : Splunk Security Essentials, Splunk Enterprise Security (ES) si disponible.
  • Privilèges : compte admin Splunk, rôle pour création d’alertes.

Documentation Splunk officielle : https://docs.splunk.com/Documentation/Splunk

Elastic Stack (ELK)

  • Components : Beats (Filebeat, Winlogbeat), Logstash / Ingest pipelines, Elasticsearch, Kibana.
  • Licence : alerting via Watcher nécessite X-Pack (licence commerciale) ; Kibana propose Alerting (stack >=7.x) ; ElastAlert est opensource alternative.
  • Compte : accès Kibana avec rôle suffisamment élevé pour créer watchers/alerts.

Documentation Elastic : https://www.elastic.co/guide/index.html

4. Cas d’usage prioritaires (liste de détections indispensables)

Prioriser ces cas pour démarrer un SOC opérationnel :

  1. Brute force SSH / RDP / VPN (nombre d’échecs > N en T minutes).
  2. Connexion admin en dehors des heures normales / pays inhabituels.
  3. Détection d’exfiltration : volumétrie upload inhabituellement élevée vers cloud / IP externe.
  4. DNS tunneling patterns (longues sous-domaines, high entropy).
  5. Processus inhabituels lançant connexions réseau vers IP Internet (endpoint telemetry).
  6. Création de comptes administrateurs locaux / modification des policies.
  7. Détection de ransomware (nombres rapides de fichiers renommés/chiffrés).
  8. Intégrité des logs (log deletion / truncation).

5. Splunk — configuration pas-à-pas pour alertes

5.1 Préparation : inputs, sourcetypes et index

Avant d’écrire des recherches SPL, s’assurer que :

  • Les sources sont envoyées au forwarder (Universal Forwarder).
  • Les sourcetypes sont correctement normalisés (ex : wineventlog:security, syslog, pan:traffic).
  • Les logs critiques indexés dans index=security ou index=syslog selon politique.

Vérification rapide (GUI) :

  1. Ouvrez Splunk Web (https://<splunk-host>:8000).
  2. Authentifiez-vous (compte admin).
  3. Menu Settings → Data inputs → vérifier Universal Forwarders actifs.
  4. Menu Search & Reporting → exécuter recherche test :
index=security sourcetype=wineventlog:security | head 10

5.2 Exemple de requêtes SPL (detections)

Fournir des requêtes réutilisables. Chaque exemple inclut paramètres à ajuster.

A. Brute force RDP (Windows EventID 4625)

index=security sourcetype=wineventlog:security EventCode=4625
| stats count by src_ip, Account_Name
| where count > 10
  • count > 10 et fenêtre par défaut (ajuster search window, ex : Last 15 minutes).

B. Connexion admin hors horaire

index=security sourcetype=wineventlog:security EventCode=4624 Logon_Type=2
| eval hour=strftime(_time,"%H")
| where Account_Name="DOMAIN\\Administrator" AND (hour<8 OR hour>19)
| table _time, host, Account_Name, src_ip

C. Upload volumineux (proxy / firewall logs)

index=proxy sourcetype=proxy:access
| bin _time span=1h
| stats sum(bytes_sent) as bytes_sent by src_ip, _time
| where bytes_sent > 500000000   # > 500MB per hour
| table _time, src_ip, bytes_sent

D. DNS high entropy (suspicious domains)

index=dns sourcetype=dns
| eval domain=tolower(query)
| eval entropy=len(domain)    # example placeholder; better compute Shannon
| where len(domain) > 50
| stats count by domain

(implémenter fonction de calcul d’entropie via eval+rex ou script)

5.3 Créer une Saved Search et la transformer en Alert (pas à pas)

Procédure GUI (Splunk Web) :

  1. Ouvrez Search & Reporting.
  2. Collez la requête SPL désirée et ajustez la période (ex : Last 15 minutes).
  3. Cliquez sur Save As → Alert.
  4. Remplissez le formulaire :
    • Title : RDP Brute Force High
    • Description : courte, actionnable.
    • Alert type : Scheduled (run every 5 minutes) ou Real-time (continuous) selon criticité.
    • Trigger conditions : if number of results > 0 ou if result matches ....
    • Throttle : définir suppression (ex : suppress for 60 minutes for same src_ip).
    • Severity : High / Medium / Low.
  5. Actions : cochez Send Email, Webhook, Run a script etc.
  6. Cliquez Save.

Notes pratiques :

  • Préférer Scheduled every N minutes for heavy queries to reduce load.
  • Use throttle to avoid alert flooding.

5.4 Configurer les actions d’alerte : email, webhook, script, alert manager

Email :

  • Parametres SMTP → Settings → Server settings → renseigner SMTP server, port, credentials (StartTLS) ; puis configurer dans alert action.

Webhook (HTTP POST) :

  • Dans alert actions → Add new → Webhook → URL (ex : https://hooks.slack.com/services/...) → payload JSON (utiliser tokens).
  • Exemple payload :
{
  "title":"Splunk Alert: RDP Brute Force",
  "host":"$host$",
  "results_link":"$result.link$",
  "events":"$results$"
}

Script (Run a Script) :

  • Sur Search Head, placer script dans $SPLUNK_HOME/bin/scripts/alert_rdp_bruteforce.sh ; donner exec permissions.
  • Exemple script (bash) :
#!/bin/bash
# $1 is results file path passed by Splunk
curl -X POST -H "Content-Type: application/json" -d @"$1" https://your-orchestration/api/incident
  • Lors de la création d’alerte, ajouter Run a script action et sélectionner le script.

Intégration avec Phantom / SOAR : utiliser webhook pour créer incidents et enrichir automatiquement (GeoIP, ThreatIntel).

5.5 Tester, tuning et gestion des faux positifs

  • Test initial sur environnement miroir/POC.
  • Définir baseline en mesurant activités normales (1–4 semaines).
  • Appliquer allowlist (whitelist) pour IP internes légitimes et services de monitoring.
  • Ajuster threshold et window (N in T minutes).
  • Documenter chaque changement (who, why).

6. Elastic Stack (ELK) — configuration pas-à-pas pour alertes

6.1 Préparation : ingestion, mappings, index patterns

  • Installer Beats (Filebeat, Winlogbeat) sur endpoints, configurer outputs → Elasticsearch.
  • Créer index pattern dans Kibana (ex : logs-*).
  • Vérifier @timestamp, host.name, source.ip, user.name fields.

Kibana URL example: https://<kibana-host>:5601

6.2 Requêtes exemples (KQL / DSL) pour détection

A. Brute force SSH (KQL)

event.dataset: "ssh" AND event.action: "failed" | stats count() by source.ip

(En Kibana Discover ou Lens puis convertir en alert)

B. Large upload (Elasticsearch DSL aggregate)

{
  "query": {
    "bool": { "filter": [ { "term": { "event.action": "upload" } } ] }
  },
  "aggs": {
    "by_src": {
      "terms": { "field": "source.ip" },
      "aggs": { "bytes": { "sum": { "field": "file.size" } } }
    }
  }
}

6.3 Configurer une Alert dans Kibana (UI) — pas-à-pas

Kibana (Alerting) — UI steps :

  1. Ouvrez Kibana → Stack Management → Rules & Connectors.
  2. Cliquez Create rule → choisir rule type (e.g., Elasticsearch query / Threshold / Log threshold).
  3. Exemple : Log threshold
    • Define rule : Select index pattern logs-*, set query (KQL) event.action: "failed_login" and set threshold count > 10 for by source.ip over 5m.
    • Schedule : set run every 1m.
    • Actions : add connector (Email / Slack / Webhook). If no connector exists → create connector: Email connector: smtp server, from, to; Slack: webhook URL.
  4. Set name, severity, tags.
  5. Save rule.

Kibana will evaluate the rule and trigger actions when condition met.

6.4 Configurer un Watcher (Elasticsearch X-Pack) — JSON example & steps

Watcher allows flexible alerting via Elasticsearch API.

Steps (Kibana Dev Tools or CURL):

  1. Prepare watch JSON:
PUT _watcher/watch/rule_bruteforce_ssh
{
  "trigger": { "schedule": { "interval": "1m" } },
  "input": {
    "search": {
      "request": {
        "indices": ["logs-*"],
        "body": {
          "query": {
            "bool": { "filter": [ { "term": { "event.action": "failed_login" } } ] }
          },
          "aggs": {
            "by_ip": { "terms": { "field": "source.ip", "size": 100 },
              "aggs": { "fail_count": { "value_count": { "field": "event.action" } } }
            }
          }
        }
      }
    }
  },
  "condition": {
    "script": {
      "source": "for (int i=0; i<ctx.payload.aggregations.by_ip.buckets.length; i++) { if (ctx.payload.aggregations.by_ip.buckets[i].doc_count > params.threshold) return true } return false",
      "params": { "threshold": 10 }
    }
  },
  "actions": {
    "notify_slack": {
      "webhook": {
        "method": "POST",
        "host": "hooks.slack.com",
        "port": 443,
        "path": "/services/XXX/YYY/ZZZ",
        "body": "{{ctx.payload}}"
      }
    }
  }
}
  1. Deploy via Kibana Dev Tools or curl:
curl -XPUT "http://<es-host>:9200/_watcher/watch/rule_bruteforce_ssh" -H 'Content-Type: application/json' -d @watch.json -u user:pass

6.5 ElastAlert (opensource) — installation et règle YAML complète

ElastAlert from Yelp is an opensource alerting engine that queries ES and triggers alerts.

Installation (Ubuntu example):

sudo apt update
sudo apt install python3-pip
pip3 install elastalert
pip3 install "elastalert[optional]"

Configuration (config.yaml sample):

# config.yaml
es_host: <elasticsearch-host>
es_port: 9200
writeback_index: elastalert_status
buffer_time:
  minutes: 15

Example rule (brute force) rules/ssh_bruteforce.yaml:

name: SSH brute force detection
type: frequency
index: logs-*
num_events: 10
timeframe:
  minutes: 5
filter:
- term:
    event.action: "failed_login"
alert:
- "email"
email:
- "soc@example.com"
alert_text: "SSH brute force detected from {0}, {1} failures in {2}"
alert_text_args: ["match[0]['source.ip']", "num_events", "timeframe"]

Start ElastAlert:

elastalert --config config.yaml

ElastAlert will create alerts with configured actions.

6.6 Actions d’alerte : email, webhook, Slack, PagerDuty

Kibana connectors : Stack Management → Rules & Connectors → Create connector (Email, Slack, PagerDuty, ServiceNow).

Webhook action : configure JSON payload, authentication (Bearer token) and test.

PagerDuty : create integration key in PagerDuty and use HTTP Event API v2.

7. Orchestration d’alertes : centralisation, suppression d’excès, étiquetage, priorisation

Pour éviter la fatigue d’alerte (alert fatigue) :

  • Centraliser les alertes via un bus (Kafka / RabbitMQ) ou via SOAR (Phantom, Demisto, TheHive + Cortex).
  • Correlation : combinez plusieurs signaux (ex : failed login + new process + outbound traffic) avant alerte.
  • Deduplication : throttle identical alerts per entity (IP/user) with sliding window.
  • Enrichissement : GeoIP, WHOIS, ASN, threat intel (abuse.ch, MISP) pour prioriser.
  • Severity mapping : map severity to automatic actions (High → create incident in SOAR, Medium → email SOC, Low → dashboard only).

8. Automatisation post-alerte : playbook d’escalade, enrichissement contextuel, ticketing (exemples)

Chaque alerte doit déclencher un playbook décrivant actions. Exemple : Brute force RDP.

Playbook (simple) :

  1. Alert received in SOAR (Splunk/Phantom or TheHive).
  2. Enrich : GeoIP lookup for source IP, check passive DNS, check threat intel blacklists.
  3. Verify : query Splunk/ELK for related events (successful logons, privilege escalation).
  4. Containment (automated only if high confidence) : block IP at firewall via API (Palo Alto/Checkpoint) — script example provided.
  5. Create ticket in ITSM (ServiceNow) and assign to Tier1.
  6. Notify stakeholders (security director, affected system owners).
  7. Post-incident report template generation and retention.

Example API call to block IP (Palo Alto) — Bash sample:

curl -k -X POST "https://<fw-host>/api/?type=config&action=set&key=$API_KEY&xpath=/config/devices/entry/vsys/entry/rulebase/security&element=<entry name='block-malicious'>...</entry>"

(Chaque vendor a son API — préférer SDK officiel.)

9. Mesures de qualité des alertes : KPIs, tuning, revue périodique

Mesurer :

  • MTTA (Mean Time to Acknowledge)
  • MTTR (Mean Time to Remediate)
  • FP rate (false positive %) par règle
  • Alert volume per day
  • Coverage % (pour principaux use cases)

Processus : revue mensuelle des règles (owner, rational, threshold), tuning et suppression des règles obsolètes.

10. Sécurité opérationnelle et gouvernance des alertes (accès, audit, conformité)

  • RBAC : restreindre qui peut éditer rules/alerts (Splunk roles, Kibana spaces + roles).
  • Audit : activer logs d’audit (Splunk internal logs, Elasticsearch audit logger).
  • Change control : toute modification des règles passe par PR / ticket.
  • Retention : conserver alert data conforme à politique (logs sensibles).
  • Privacy : éviter inclusion des données personnelles non nécessaires dans alert payloads (conformité RGPD).

11. Templates & scripts prêts à déployer

11.1 Splunk savedsearch.conf example (local/$SPLUNK_HOME/etc/apps/search/local/savedsearches.conf)

[High_RDP_BruteForce]
action.email = 1
action.email.to = soc@example.com
action.email.subject = Splunk Alert: High RDP Brute Force
action.email.command = /opt/splunk/bin/scripts/alert_rdp_bruteforce.sh
dispatch.earliest_time = -15m@m
dispatch.latest_time = now
cron_schedule = */5 * * * *
alert_type = number of events
alert_threshold = 1
alert.suppress = true
alert.suppress.period = 1h
description = Detects more than 10 failed RDP logins in 15 minutes.
search = index=windows sourcetype=wineventlog:security EventCode=4625 | stats count by src_ip Account_Name | where count>10

11.2 ElastAlert rule YAML (as earlier) — save as rules/ssh_bruteforce.yaml

(see ElastAlert section)

11.3 Watcher JSON (as earlier) — save as watch_bruteforce.json

(see Watcher section)

11.4 Example Splunk alert action script (alert_rdp_bruteforce.sh)

#!/bin/bash
# $SPLUNK_ARG_0 contains path to results file
RESULTS_FILE="$SPLUNK_ARG_0"
API_URL="https://soar.example.com/api/incidents"
API_TOKEN="REPLACE_WITH_TOKEN"

curl -s -X POST "$API_URL" -H "Authorization: Bearer $API_TOKEN" -H "Content-Type: application/json" --data-binary @"$RESULTS_FILE"
  • Déployer en $SPLUNK_HOME/bin/scripts/ et rendre exécutable chmod +x.

12. Checklist déployable (POC → production)

  • Inventaire des sources de logs prioritaires (auth, endpoints, network, proxy, cloud).
  • Déployer forwarders / beats correctement.
  • Créer index/security indices et mappings.
  • Implémenter 10 règles initiales (les cas d’usage prioritaires).
  • Configurer actions (email, webhook, Slack, SOAR).
  • Tester avec jeu de données (simulate attacks).
  • Tuning 2–4 semaines, révision seuils.
  • RBAC et audits activés.
  • Documenter playbooks & SLA d’escalade.

13. Etude de cas complète — Brute force RDP (du detect à la remediation)

Contexte

Entreprise X reçoit alertes de logins RDP échoués depuis une IP publique inconnue.

Détection (Splunk)

  • Règle Splunk : index=windows EventCode=4625 | stats count by src_ip, Account_Name | where count > 10
  • Alert triggers, Splunk sends webhook to SOAR.

Enrichissement automatique (SOAR)

  1. GeoIP lookup → Source IP originates from country Y (suspicious).
  2. Passive DNS lookup → associated with known botnet ASN.
  3. Query firewall logs → confirm multiple connection attempts.

Containment

  • Automated: block IP via firewall API (if policy allows auto block on high severity).
  • Manual: SOC analyst confirms and escalates to infra team to enforce ACL.

Investigation

  • Check successful logons from IP; verify no lateral movement.
  • Check endpoint EDR (processes spawned) — if evidence of compromise, isolate host.

Remediation

  • If brute force succeeded: reset credentials, force password change, rotate keys, reimage compromised host.
  • Post-incident report including artifacts (Splunk search exports, pcap if any, firewall logs).

Lessons & tuning

  • Increase threshold to reduce false positives specific to service accounts used by monitoring.
  • Add allowlist for known monitors.

Conclusion

La mise en place d’un système d’alertes de sécurité efficace repose sur une qualité de logs, des règles actionnables, et un processus de remédiation intégré. Splunk et Elastic offrent des capacités robustes ; le choix dépend du contexte operationnel (licence, compétences, intégration SOAR).

Pour un déploiement rapide et sécurisé (POC, tuning, playbooks SOAR, intégration firewall/ITSM), nous proposons :

  • POC 2 semaines (10 règles + dashboards) ;
  • Pack déploiement (ElastAlert or Watcher / Splunk SavedSearches) ;
  • Formation SOC & runbook d’escalade.
Contactez nos experts

Liens externes recommandés

  • Splunk Documentation — https://docs.splunk.com/Documentation/Splunk
  • Splunk Security Essentials — https://splunkbase.splunk.com/app/3435/
  • Elastic Stack — Getting Started — https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html
  • Kibana Alerting — https://www.elastic.co/guide/en/kibana/current/alerting-getting-started.html
  • Watcher (Elasticsearch) — https://www.elastic.co/guide/en/elasticsearch/reference/current/watcher-api.html
  • ElastAlert (Yelp) — https://github.com/Yelp/elastalert
  • TheHive Project (open SOAR) — https://thehive-project.org/
  • MISP Threat Intel — https://www.misp-project.org/

Lectures recommandées

Sommaire

→ Index