Une fiche SOC pour relier identité, appels API, ressource, IP source et changement de configuration, puis décider (clôturer, révoquer, restaurer, contenir).
Objectif : ne pas valider une modification à l’aveugle. Sortie attendue : une décision expliquée, appuyée par des preuves collectées.
##Le mécanisme central
Une alerte « policy changed » ne dit pas si le changement est attendu, ni ce que vous avez perdu comme couverture.
Le risque principal est l’angle mort. Une règle peut être assouplie pour ouvrir une fenêtre d’accès, puis refermée ensuite.
Pour décider proprement, vous reconstruisez une chronologie commune. Vous reliez l’identité, l’appel API, la ressource touchée, l’IP source, et le avant/après de la config.
Cadrage (recommandation) : appliquez une démarche d’incident response basée sur des preuves et une timeline. Repère : https://docs.aws.amazon.com/security-ir/latest/userguide/what-is-security-ir.html
##Ce que vous devez relier (sinon vous décidez à l’aveugle)
- -Qui : acteur, compte, rôle, et contexte de session
- -Quoi : règle / policy et champs modifiés (conditions, exclusions, contrôles)
- -Comment : appel API / opération d’admin qui a produit le changement
- -Où : ressource ciblée et tenant concerné
- -Depuis où : IP source et type de client (navigateur, outil, script)
- -Quand : avant / pendant / après sur une même timeline
- -Et ensuite : actions préparatoires et consécutives autour du changement
##Chemin d’investigation (pivots dans l’ordre)
##Worksheet preuves à collecter (minimum viable)
Groupe 1 : Identité et session (pivot 1)
- ->Identifier l'acteur et les identifiants de session
- ->Identifiant de l’acteur (UPN, ID objet, compte invité vs interne)
- ->Rôle / privilèges au moment du changement (admin, rôle temporaire)
- ->Période exacte : première apparition et dernière action liée à la session
Groupe 2 : Appel API, ressource, région (pivot 2)
- ->Comparer appel API ressource et région
- ->Opération exacte (nom de l’action d’admin) qui modifie la policy
- ->Ressource touchée (policy, scope, groupe ciblé, exclusions)
- ->Client et user-agent si disponible (portail, CLI, script)
Groupe 3 : Adresse source et signaux réseau
- ->IP source et éventuels proxys connus (sortants d’entreprise, CASB, VPN)
- ->Géolocalisation à vérifier (cohérence avec l’utilisateur)
- ->Écart d’empreinte : nouvelle IP, nouveau device, nouveau navigateur
- ->Tout signal de détection lié (ex : finding corrélé)
Groupe 4 : Avant / après + actions autour du changement (pivot 3)
- ->Diff exact du avant/après (conditions, exclusions, contrôles)
- ->Chercher les actions préparatoires et consécutives
- ->Actions consécutives (ex : connexions, création d’apps, règles, boîtes)
- ->Fenêtre d’exposition : durée entre assouplissement et remise en place
##Flux opérationnel : de l’alerte à la décision
Vue d’ensemble pour éviter les enquêtes en silo. Objectif : une seule histoire, puis une seule action.
- ├─Recevoir l’alerte « Conditional Access modifiée »
- ├─Geler l’heure de référence (T0)
- └─Ouvrir un espace de timeline unique (T0-Δ à T0+Δ)
- ├─Relier journaux Azure + Microsoft 365 Unified Audit Log à l’identité
- ├─Relier CloudTrail + GuardDuty aux appels API et à l’IP source
- └─Aligner tous les événements sur la timeline (mêmes champs, mêmes IDs)
- ├─Nommer ce qui a été assoupli (ce qui ne bloque plus)
- ├─Identifier qui en a profité ou aurait pu en profiter (sessions connexes)
- └─Vérifier si la policy est revenue à l’état attendu, et quand
- ├─Clôturer : changement attendu et cohérent, preuves complètes
- ├─Révoquer : doute sur session/identité, mais policy remise en place
- ├─Restaurer : config incorrecte ou dérive non validée
- └─Contenir : activité malveillante probable, privilèges ou sessions à couper
##Erreurs fréquentes et questions de décision
Erreur la plus dangereuse ?
Traiter l’alerte isolément. Sans revenir à l’identité et aux appels API, vous validez une modification sans contexte.
Qu’est-ce qui permet de clôturer rapidement ?
Une identité attendue, une session cohérente (IP, device, horaire), un appel API attendu, et un diff avant/après conforme à un changement planifié.
Quand révoquer des identifiants au lieu de restaurer seulement la policy ?
Quand la session ou l’acteur est douteux. Restaurer la config ne coupe pas une session déjà ouverte ni un jeton déjà émis.
Quel signal fait basculer vers “contenir” ?
Un acteur non attendu avec privilèges, des changements en chaîne (élévation de droits, nouvelles apps, nouvelles règles), ou une exploitation visible pendant la fenêtre d’exposition.
Quel minimum documenter dans le ticket ?
La timeline, l’acteur, l’opération d’admin, l’IP source, le diff de policy, et la justification courte de la décision finale.
Repère méthodologique (incident response)
À utiliser comme cadre général pour structurer la collecte de preuves et la timeline.