CompTIA SY0-701: Opérations de sécurité, surveillance et détection — Guide d'étude

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fait partie du CompTIA Security+ SY0-701 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens CompTIA, ou passez des tests chronométrés sur ExamRoll.io.

Les opérations de sécurité modernes reposent sur la capacité à observer, corréler et agir sur les signaux provenant de tous les recoins de l’entreprise : terminaux, équipements réseau, fournisseurs d’identité, workloads cloud et applications. Un programme de détection mature n’est pas un produit unique, mais un écosystème de pipelines de télémétrie, de moteurs d’analyse, d’analystes humains et de flux de travail de réponse automatisée, conçu pour réduire le temps entre la compromission et le confinement.

SIEM et agrégation centralisée des journaux

Une plateforme de gestion des informations et des événements de sécurité (SIEM) est le tissu conjonctif du centre des opérations de sécurité (SOC). Elle ingère les journaux de sources disparates — journaux d’événements Windows, syslog Linux, données de flux de pare-feu, résolveurs DNS, Active Directory, agents de terminaux, pistes d’audit SaaS — les normalise dans un schéma commun et applique des règles de corrélation sur le flux agrégé. La valeur ne réside pas seulement dans le stockage ; elle réside dans la capacité à corréler une authentification VPN échouée dans une source de journaux avec une connexion privilégiée réussie et un accès SMB latéral dans une autre, produisant une seule alerte de haute fidélité là où trois événements isolés n’auraient été que du bruit.

Les plateformes courantes incluent Splunk, Microsoft Sentinel, IBM QRadar, Elastic Security et Chronicle. Dans les environnements cloud, des outils natifs tels que AWS CloudTrail combiné à CloudWatch et GuardDuty, ou Azure Monitor avec les espaces de travail Log Analytics, servent de colonne vertébrale pour la journalisation et alimentent souvent un SIEM en amont.

Une recherche de corrélation Splunk typique illustrant une logique inter-sources :

index=wineventlog EventCode=4625
| stats count by src_ip, user
| where count > 10
| join user [search index=vpn action=success]
| table _time, user, src_ip, count

Le piège ici est subtil : une organisation peut déployer un SIEM, ingérer des téraoctets de données, et tout de même manquer des intrusions parce que des sources de journaux critiques sont absentes. Si les événements de création de processus sur les terminaux (Windows Event ID 4688 ou Sysmon Event ID 1) ne sont pas transférés, ou si les journaux de refus du pare-feu sont tronqués, des phases entières de l’attaque deviennent invisibles. La couverture des sources de journaux — mappée explicitement par rapport à un framework comme MITRE ATT&CK — est une condition préalable à une détection pertinente.

Détection et réponse sur les terminaux (EDR)

L’EDR (Endpoint Detection and Response) étend la visibilité à l’hôte, là où la plupart des activités des attaquants se manifestent finalement. Contrairement aux antivirus traditionnels, qui comparent des hachages de fichiers et des signatures, les plateformes EDR telles que CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint et Carbon Black enregistrent une télémétrie continue : arborescences de processus, arguments de ligne de commande, modifications du registre, connexions réseau et chargements de DLL. Ces données permettent à la fois la détection comportementale en temps réel et la chasse aux menaces (threat hunting) rétrospective.

Une idée fausse courante est de traiter l’EDR comme un contrôle préventif équivalent à un pare-feu. L’EDR détecte et aide à la réponse principalement — il peut bloquer un comportement malveillant connu, mais sa plus grande valeur réside dans la fourniture de la piste d’investigation numérique (forensic) qui permet à un analyste de déterminer ce qu’un processus compromis a fait, à quelles informations d’identification il a accédé et où il s’est déplacé latéralement. Les actions de réponse telles que l’isolement de l’hôte, l’arrêt du processus et la mise en quarantaine des fichiers sont généralement initiées par un analyste ou un playbook SOAR, et non par l’EDR seul.

IDS/IPS, signatures et application de lignes de base

Les systèmes de détection et de prévention d’intrusion réseau (IDS/IPS) inspectent le trafic en le comparant à des signatures et des modèles comportementaux. Un IDS (tel que Snort ou Suricata en mode surveillance) alerte sur les modèles suspects ; un IPS se place en ligne (inline) et bloque le trafic correspondant. Une règle Snort pour détecter un modèle d’exploit spécifique illustre la logique basée sur les signatures :

alert tcp any any -> $HOME_NET 445 (
  msg:"SMB Exploit Attempt";
  content:"|ff|SMB"; offset:4; depth:4;
  content:"|72 00|"; distance:0;
  sid:9000001; rev:1;
)

La détection basée sur les anomalies établit une ligne de base comportementale et alerte sur les écarts — un poste de travail qui commence soudainement à effectuer des requêtes DNS à 10 fois son rythme normal, ou un serveur qui ouvre des connexions sortantes sur le port 4444 pour la première fois, justifient tous deux une enquête, qu’une signature corresponde ou non.

Threat Intelligence et gestion des indicateurs

La Threat Intelligence (renseignement sur les menaces) transforme les données brutes en connaissances exploitables sur les tactiques, techniques et procédures (TTP) des adversaires. STIX (Structured Threat Information eXpression) est le format standard pour représenter les objets de renseignement sur les menaces — indicateurs, campagnes, acteurs de la menace, modèles d’attaque — tandis que TAXII (Trusted Automated eXchange of Indicator Information) est le protocole de transport pour les partager. Les flux commerciaux et open-source (VirusTotal, AlienVault OTX, MISP, Recorded Future) fournissent la réputation des IP, des listes de blocage de domaines, des hachages de fichiers et des règles YARA qui peuvent être ingérés directement dans les plateformes SIEM et les pare-feu.

Les indicateurs de compromission (IoC) — adresses IP malveillantes, hachages de fichiers, noms de domaine, clés de registre — sont les renseignements les plus immédiatement exploitables mais aussi les plus éphémères ; les attaquants renouvellent rapidement leur infrastructure. Les indicateurs d’attaque (IoA) se concentrent sur les comportements plutôt que sur les artefacts : un processus qui génère un shell enfant, une commande PowerShell encodée, ou un service créé avec un nom aléatoire. La détection basée sur les IoA est plus difficile à contourner car elle cible la technique, et non l’outil spécifique.

Scénario pratique : lacune de détection due à des sources de journaux manquantes

Une entreprise de services financiers a déployé un SIEM et a ingéré les journaux du pare-feu de périmètre, les journaux d’événements de sécurité Windows et les journaux de la passerelle de messagerie. Lors d’un exercice de red team, l’équipe a obtenu un accès initial via un e-mail de phishing (détecté), mais a ensuite utilisé WMI pour le mouvement latéral et PowerShell Remoting pour l’exécution de commandes — aucune de ces actions n’a généré d’événements de sécurité Windows dans la configuration par défaut. La red team a atteint le poste de travail de la trésorerie et a exfiltré un fichier de virement bancaire simulé sans déclencher une seule alerte SIEM après la détection initiale du phishing. La lacune : Sysmon n’était pas déployé, la journalisation des blocs de script PowerShell n’était pas activée, et la journalisation de l’activité WMI nécessitait une configuration supplémentaire. L’exercice a démontré que la couverture du SIEM n’est aussi bonne que les sources de journaux qui l’alimentent — une leçon qui doit être validée par des exercices de purple team, et non présumée à partir de la documentation du fournisseur.

← Sécurité et architecture réseau · Tous les domaines · Réponse aux incidents →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →