Construire un SIEM Cloud avec Sentinel
Quand l'utiliser
- Lors de la mise en place d'un centre d'opérations de sécurité centralisé pour des environnements multi-cloud
- Lors de la migration depuis des plateformes SIEM legacy (Splunk, QRadar) vers une architecture cloud-native
- Lors de la construction de workflows de réponse automatisée aux incidents pour des menaces spécifiques au cloud
- Lors de la réalisation de chasses aux menaces à grande échelle sur des pétaoctets de télémétrie de sécurité
- Lors de l'intégration de flux de renseignement sur les menaces avec l'analyse des logs de sécurité cloud
Ne pas utiliser pour les environnements purement AWS où Security Hub et GuardDuty suffisent, pour la détection sur les endpoints nécessitant des capacités EDR (utiliser Defender for Endpoint), ou pour la surveillance de la conformité (voir building-cloud-security-posture-management).
Prérequis
- Abonnement Azure avec Microsoft Sentinel activé sur un espace de travail Log Analytics
- Permissions de connecteur de données pour les sources de logs cibles (AWS CloudTrail, Azure Activity, GCP)
- Logic Apps ou Azure Functions pour les playbooks de réponse automatisée
- Maîtrise de KQL (Kusto Query Language) pour l'écriture de règles de détection et de requêtes de chasse
Workflow
Étape 1 : Provisionner l'espace de travail Sentinel et les connecteurs de données
Créez un espace de travail Log Analytics optimisé pour les données de sécurité et activez les connecteurs de données pour l'ingestion multi-cloud.
# Créer l'espace de travail Log Analytics
az monitor log-analytics workspace create \
--resource-group security-rg \
--workspace-name sentinel-workspace \
--location eastus \
--retention-time 365 \
--sku PerGB2018
# Activer Microsoft Sentinel sur l'espace de travail
az sentinel onboarding-state create \
--resource-group security-rg \
--workspace-name sentinel-workspace
# Activer le connecteur AWS CloudTrail
az sentinel data-connector create \
--resource-group security-rg \
--workspace-name sentinel-workspace \
--data-connector-id aws-cloudtrail \
--kind AmazonWebServicesCloudTrail \
--aws-cloud-trail-data-connector '{
"awsRoleArn": "arn:aws:iam::123456789012:role/SentinelCloudTrailRole",
"dataTypes": {"logs": {"state": "Enabled"}}
}'
# Activer les logs de connexion et d'audit Azure AD
az sentinel data-connector create \
--resource-group security-rg \
--workspace-name sentinel-workspace \
--data-connector-id azure-ad \
--kind AzureActiveDirectory \
--azure-active-directory '{
"dataTypes": {
"alerts": {"state": "Enabled"},
"signinLogs": {"state": "Enabled"},
"auditLogs": {"state": "Enabled"}
}
}'
Étape 2 : Écrire des règles de détection KQL
Créez des règles d'analyse avec Kusto Query Language pour détecter les menaces spécifiques au cloud. Mappez chaque règle aux techniques MITRE ATT&CK.
// Détecter les impossible travel - connexions depuis des localisations géographiquement éloignées
let timeframe = 1h;
let distance_threshold = 500; // km
SigninLogs
| where TimeGenerated > ago(timeframe)
| where ResultType == 0 // Connexions réussies uniquement
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
Latitude = toreal(LocationDetails.geoCoordinates.latitude),
Longitude = toreal(LocationDetails.geoCoordinates.longitude)
| sort by UserPrincipalName asc, TimeGenerated asc
| extend PrevLatitude = prev(Latitude, 1), PrevLongitude = prev(Longitude, 1),
PrevTime = prev(TimeGenerated, 1), PrevUser = prev(UserPrincipalName, 1)
| where UserPrincipalName == PrevUser
| extend TimeDiff = datetime_diff('minute', TimeGenerated, PrevTime)
| where TimeDiff < 60
| extend Distance = geo_distance_2points(Longitude, Latitude, PrevLongitude, PrevLatitude) / 1000
| where Distance > distance_threshold
| project TimeGenerated, UserPrincipalName, IPAddress, Location, Distance, TimeDiff
// Détecter l'abus d'identifiants IAM AWS depuis CloudTrail
AWSCloudTrail
| where TimeGenerated > ago(24h)
| where EventName in ("ConsoleLogin", "AssumeRole", "GetSessionToken")
| where ErrorCode == ""
| summarize LoginCount = count(), DistinctIPs = dcount(SourceIpAddress),
IPList = make_set(SourceIpAddress, 10)
by UserIdentityArn, bin(TimeGenerated, 1h)
| where DistinctIPs > 3
| project TimeGenerated, UserIdentityArn, LoginCount, DistinctIPs, IPList
// Détecter la suppression massive d'objets S3 (rançongiciel potentiel)
AWSCloudTrail
| where TimeGenerated > ago(1h)
| where EventName == "DeleteObject" or EventName == "DeleteObjects"
| summarize DeleteCount = count(), BucketsAffected = dcount(RequestParameters_bucketName)
by UserIdentityArn, bin(TimeGenerated, 10m)
| where DeleteCount > 100
| project TimeGenerated, UserIdentityArn, DeleteCount, BucketsAffected
Étape 3 : Construire des playbooks SOAR avec Logic Apps
Créez des playbooks de réponse automatisée qui s'exécutent lorsque des règles d'analyse déclenchent des incidents. Les actions courantes incluent le blocage d'utilisateurs, l'isolation de ressources et l'enrichissement des alertes avec du renseignement sur les menaces.
{
"definition": {
"triggers": {
"Microsoft_Sentinel_incident": {
"type": "ApiConnectionWebhook",
"inputs": {
"body": {"incidentArmId": "subscriptions/@{triggerBody()?['workspaceInfo']?['SubscriptionId']}/resourceGroups/@{triggerBody()?['workspaceInfo']?['ResourceGroupName']}/providers/Microsoft.OperationalInsights/workspaces/@{triggerBody()?['workspaceInfo']?['WorkspaceName']}/providers/Microsoft.SecurityInsights/Incidents/@{triggerBody()?['object']?['properties']?['incidentNumber']}"},
"host": {"connection": {"name": "@parameters('$connections')['microsoftsentinel']['connectionId']"}}
}
}
},
"actions": {
"Get_incident_entities": {
"type": "ApiConnection",
"inputs": {"method": "post", "path": "/Incidents/entities"}
},
"For_each_account_entity": {
"type": "Foreach",
"foreach": "@body('Get_incident_entities')?['Accounts']",
"actions": {
"Disable_Azure_AD_user": {
"type": "ApiConnection",
"inputs": {
"method": "PATCH",
"path": "/v1.0/users/@{items('For_each_account_entity')?['AadUserId']}",
"body": {"accountEnabled": false}
}
},
"Add_comment_to_incident": {
"type": "ApiConnection",
"inputs": {
"body": {"message": "Utilisateur @{items('For_each_account_entity')?['Name']} désactivé par le playbook automatisé"}
}
}
}
}
}
}
}
Étape 4 : Configurer le data lake Sentinel pour la chasse à long terme
Activez le data lake Sentinel pour une rétention de logs à l'échelle du pétaoctet et une chasse avancée aux menaces en utilisant les points de terminaison KQL et SQL.
// Requête de chasse aux menaces : détecter le mouvement latéral entre comptes AWS
let suspicious_roles = AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName == "AssumeRole"
| extend AssumedRoleArn = tostring(parse_json(RequestParameters).roleArn)
| where AssumedRoleArn contains "cross-account" or AssumedRoleArn contains "admin"
| summarize AssumeCount = count(), UniqueSourceAccounts = dcount(RecipientAccountId)
by UserIdentityArn, AssumedRoleArn
| where AssumeCount > 10 and UniqueSourceAccounts > 2;
suspicious_roles
| join kind=inner (
AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName in ("RunInstances", "CreateFunction", "PutBucketPolicy")
) on UserIdentityArn
| project TimeGenerated, UserIdentityArn, AssumedRoleArn, EventName, SourceIpAddress
Étape 5 : Intégrer le renseignement sur les menaces
Connectez les fournisseurs de renseignement sur les menaces et créez des règles de correspondance basées sur des indicateurs pour détecter les communications avec une infrastructure malveillante connue.
# Activer le connecteur Microsoft Threat Intelligence
az sentinel data-connector create \
--resource-group security-rg \
--workspace-name sentinel-workspace \
--data-connector-id microsoft-ti \
--kind MicrosoftThreatIntelligence \
--microsoft-threat-intelligence '{
"dataTypes": {"microsoftEmergingThreatFeed": {"lookbackPeriod": "2025-01-01T00:00:00Z", "state": "Enabled"}}
}'
// Faire correspondre les indicateurs réseau avec les logs de flux cloud
let TI_IPs = ThreatIntelligenceIndicator
| where TimeGenerated > ago(30d)
| where isnotempty(NetworkIP)
| distinct NetworkIP;
AzureNetworkAnalytics_CL
| where TimeGenerated > ago(24h)
| where DestIP_s in (TI_IPs)
| project TimeGenerated, SrcIP_s, DestIP_s, DestPort_d, FlowType_s
Concepts clés
| Terme | Définition |
|---|---|
| KQL | Kusto Query Language, le langage de requête principal de Microsoft Sentinel utilisé pour rechercher, analyser et visualiser les données de sécurité |
| Règle d'analyse | Logique de détection dans Sentinel qui évalue les données de logs selon un calendrier et crée des incidents lorsque les conditions correspondent |
| Playbook SOAR | Workflow automatisé déclenché par des incidents qui exécute des actions de réponse telles que le blocage de comptes, l'enrichissement des alertes ou la notification des équipes |
| Connecteur de données | Module d'intégration qui ingère les logs de sécurité des services cloud, des fournisseurs d'identité et des outils tiers dans Sentinel |
| Data lake Sentinel | Couche de stockage à l'échelle du pétaoctet offrant une rétention à long terme des logs avec des interfaces de requête KQL et SQL pour la chasse avancée |
| Workbook | Tableau de bord interactif dans Sentinel affichant des visualisations des données de sécurité, des tendances et des métriques opérationnelles |
| Watchlist | Tables de données de référence dans Sentinel utilisées pour enrichir les alertes avec du contexte, telles que des listes d'utilisateurs VIP ou des plages IP approuvées |
| Détection Fusion | Moteur de corrélation basé sur l'apprentissage automatique qui détecte automatiquement les attaques multi-étapes à travers plusieurs sources de données |
Outils & Systèmes
- Microsoft Sentinel : Plateforme SIEM/SOAR cloud-native construite sur Azure Log Analytics avec détection des menaces basée sur l'IA
- Azure Logic Apps : Plateforme d'automatisation low-code pour construire des playbooks SOAR déclenchés par des incidents Sentinel
- Microsoft Threat Intelligence : Flux de renseignement intégrés fournissant des indicateurs IP, de domaine et d'URL pour la correspondance avec les logs de sécurité
- Azure Data Explorer : Moteur d'analyse haute performance sous-jacent aux requêtes KQL Sentinel pour l'exploration de données à grande échelle
- MITRE ATT&CK Navigator : Cadre pour mapper les règles de détection Sentinel aux tactiques et techniques des adversaires
Scénarios courants
Scénario : Détection d'une campagne de vol d'identifiants cross-cloud
Contexte : Un attaquant compromet un compte Azure AD via hameçonnage, puis utilise le compte pour accéder aux ressources AWS via une identité fédérée. Sentinel doit corréler l'anomalie de connexion Azure AD avec une activité AWS API inhabituelle.
Approche :
- Créer une règle d'analyse détectant les impossible travel Azure AD ou le risque de connexion anormal
- Écrire une requête KQL corrélant l'identité Azure AD compromise avec les événements AWS CloudTrail AssumeRoleWithSAML
- Construire une règle de détection Fusion liant les événements de risque Azure AD avec l'activité d'escalade de privilèges AWS subséquente
- Déployer un playbook SOAR qui désactive automatiquement le compte Azure AD et révoque les sessions STS AWS
- Créer un workbook montrant la chronologie depuis la compromission initiale jusqu'au mouvement latéral vers AWS
- Exécuter une requête de chasse sur le data lake pour rechercher des modèles similaires affectant d'autres comptes
Pièges : Ne pas corréler l'identité entre les fournisseurs cloud manque la chaîne d'attaque complète. Définir une fréquence de règle d'analyse trop basse (ex. 24 heures) laisse aux attaquants des heures d'accès non détecté.
Format de sortie
Rapport des opérations SOC Microsoft Sentinel
=============================================
Espace de travail : sentinel-workspace
Sources de données : 14 connecteurs actifs
Période du rapport : 2025-02-01 au 2025-02-23
INGESTION DE DONNÉES :
Logs de connexion Azure AD : 2,3 To (23 jours)
AWS CloudTrail : 1,8 To (23 jours)
Azure Activity : 0,9 To (23 jours)
Alertes Defender pour le Cloud : 45 Go (23 jours)
Ingestion totale : 5,1 To
RÉSUMÉ DE LA DÉTECTION :
Règles d'analyse actives : 87
Incidents créés : 234
Critique : 8 | Élevé : 34 | Moyen : 89 | Faible : 103
Délai moyen de détection (MTTD) : 4,2 minutes
Délai moyen de réponse (MTTR) : 18 minutes
PRINCIPAUX TYPES D'INCIDENTS :
Impossible travel détecté : 42 incidents
Schéma d'appel API AWS non autorisé : 28 incidents
Suppression massive de fichiers dans S3 : 3 incidents
Enregistrement suspect d'application Azure AD : 12 incidents
AUTOMATISATION :
Playbooks exécutés : 156
Comptes auto-désactivés : 23
Incidents auto-enrichis : 198
Taux de faux positifs : 12 %