1. Elastic Security #
SIEM et protection.
Le périmètre #
Elastic Security réunit un SIEM (détection et investigation sur les logs), la protection des postes (Elastic Defend, intégration d'Elastic Agent) et la sécurité du cloud. Tout repose sur des données au format ECS : c'est ce qui permet à une même règle de fonctionner sur Windows, Linux ou un pare-feu.
| Source | Intégration |
|---|---|
| Authentifications Linux | System, Auditd Manager |
| Événements Windows | Windows, Elastic Defend |
| Réseau | pare-feu, Zeek, Suricata |
| Cloud | AWS CloudTrail, Azure, GCP |
Licence #
| Licence | Ce qui est disponible |
|---|---|
| Basic (gratuite) | SIEM : règles de détection (query, seuil, EQL, ES|QL, indicator match, new terms), règles prêtes à l'emploi, alertes, timelines, cases ; Elastic Defend en protection de base |
| Abonnements supérieurs | règles de type machine learning, connecteurs tiers pour les actions (Slack, Jira, ServiceNow…), actions de réponse avancées d'Elastic Defend, assistant IA |
À savoir : En licence Basic, les actions des règles se limitent aux connecteurs Server log et Index : les alertes restent visibles dans Kibana, mais la notification vers un outil externe demande un abonnement.
2. Les règles de détection #
Six familles.
Types de règles #
| Type | Détecte | Exemple |
|---|---|---|
| Custom query | une requête KQL / Lucene | exécution de mimikatz.exe |
| Threshold | un nombre d'événements par champ | plus de 10 échecs de connexion par IP |
| EQL | une séquence ordonnée d'événements | échecs puis succès pour le même compte |
| ES|QL | une agrégation ES|QL | volume anormal par utilisateur |
| Indicator match | une correspondance avec du renseignement sur les menaces | IP connue comme malveillante |
| New terms | une valeur jamais vue | premier accès d'un utilisateur à un serveur |
| Machine learning | une anomalie d'un job ML | processus rare sur un hôte |
sequence by source.ip, user.name with maxspan=10m
[authentication where event.outcome == "failure"]
[authentication where event.outcome == "success"]FROM logs-*
| WHERE event.category == "authentication" AND event.outcome == "failure"
| STATS echecs = COUNT(*) BY source.ip
| WHERE echecs > 20Règles prêtes à l'emploi #
Elastic maintient plus d'un millier de règles, rattachées aux tactiques et techniques MITRE ATT&CK. On les installe depuis Security › Rules, on active celles qui correspondent aux données collectées, puis on ajoute des exceptions pour le bruit légitime.
Erreur courante : Activer toutes les règles d'un coup : la plupart échouent faute de données ou noient l'équipe sous les faux positifs. Activez par source de données, observez une semaine, puis ajustez.
À savoir : Chaque règle s'exécute à intervalle régulier (interval) sur une fenêtre (from) un peu plus large pour ne rien manquer entre deux exécutions.
3. Investiguer #
Alertes, timelines, cases.
Le cycle de traitement #
- Trier les alertes par sévérité et score de risque ; regrouper par hôte ou utilisateur.
- Investiguer dans une timeline : événements autour de l'alerte, arbre des processus, requêtes EQL.
- Suivre dans un case : commentaires, pièces, export vers un outil de ticketing (connecteur).
- Répondre : isoler un hôte avec Elastic Defend, ajouter une exception, fermer l'alerte.
Selon la version : l'assistant IA et l'Attack Discovery (regroupement d'alertes en attaques) dépendent de la version et de la licence ; ils nécessitent un connecteur vers un modèle de langage.
