Connecter les journaux de flux cloud à Sophos XDR et SIEM

Les journaux de flux cloud décrivent les connexions réseau, et non le contenu complet des paquets. Sophos XDR peut les recevoir depuis AWS VPC Flow Logs, Azure Network Watcher, Google Cloud Platform (GCP) et Oracle Cloud Infrastructure (OCI). Le chemin dépend de la source : S3 et Lambda pour AWS, Azure Storage et une Function pour Network Watcher, Pub/Sub pour GCP et Streaming pour OCI.

La télémétrie netflow de ces intégrations nécessite Sophos Next-Gen SIEM. GCP et OCI fournissent également d’autres schémas par les mêmes intégrations ; cela ne rend pas toutes leurs données d’audit ou de sécurité dépendantes de SIEM. Vérifier d’abord les catégories nécessaires, le tenant, la mise à niveau Fusion et les droits de licence. L’article sur SIEM et la planification de la rétention explique le périmètre commercial.

Ces connexions cloud directes diffèrent d’un collecteur syslog hébergé dans le cloud. Pour ce dernier, consulter le runbook du collecteur XDR.

Avant la première modification cloud

Il faut la tuile produit correspondant au tenant cible sous Security Operations > Integrations > Marketplace, les autorisations d’administration cloud approuvées pour les ressources concernées et une équipe responsable des coûts récurrents, des clés et de la qualité des données. Vérifier la disponibilité et les champs dans le tenant ; ne pas remplacer une tuile absente par une intégration au nom similaire.

Pour chaque source, documenter compte ou abonnement cloud, région, catégories requises, intégration cible et début de collecte. Limiter les autorisations au chemin prévu. Un rôle d’administration nécessaire au déploiement ne justifie pas l’utilisation permanente d’un compte administrateur personnel comme identité d’intégration. Lambda, Storage et Pub/Sub peuvent entraîner des coûts cloud distincts.

Un état vert confirme la communication, pas la réception complète. La validation nécessite un événement de test autorisé, sa preuve côté source et son horodatage, puis l’enregistrement normalisé correspondant. Le guide des intégrations explique droits, flux et distinction avec les actions de réponse.

AWS VPC Flow Logs via son propre compartiment S3

AWS VPC Flow Logs est collecté depuis son propre compartiment Amazon S3. Sophos fournit un modèle CloudFormation créant une fonction Lambda de transmission. Il faut un compte AWS, un compartiment contenant les journaux et les droits de création des ressources Lambda, CloudFormation et IAM requises.

Ouvrir AWS VPC Flow Logs dans le Marketplace Sophos. Sous Configured integrations > Add new, lire les informations S3, choisir Next, donner un nom identifiable et sélectionner Done. Télécharger le modèle CloudFormation généré après provisionnement et en restreindre l’accès.
Dans AWS, diriger l’export VPC prévu vers ce compartiment. La destination doit être Amazon S3. Utiliser uniquement le format AWS par défaut ; un format personnalisé peut dégrader normalisation et détection.
Dans la même région AWS que le compartiment de journaux, ouvrir CloudFormation > Create stack, charger le modèle et choisir un nom sans espaces. Définir IntegrationType sur awsvpcflow. Dans NotificationBucket, saisir le nom du compartiment, ni URL ni URI S3. Si SNS est utilisé délibérément à la place des notifications S3, saisir son ARN dans SNSNotificationarn. Vérifier les autres paramètres selon le chemin prévu.
Vérifier et accepter la création des ressources IAM, créer la pile et attendre CREATE_COMPLETE. Un compartiment séparé contenant le modèle n’a pas besoin d’être rendu public.
Dans Lambda, ouvrir la fonction créée par la pile. Sous Function overview > Add Trigger, ajouter le compartiment de journaux comme source S3. Choisir Event Type: All Object Create Events. Prefix contient uniquement le préfixe réel des journaux ; le laisser vide si aucun préfixe n’est utilisé. Laisser Suffix vide. Vérifier les coûts, puis ajouter le déclencheur.
Produire un flux réseau adapté et inoffensif dans le périmètre VPC choisi. Vérifier d’abord son enregistrement dans le compartiment, puis comparer la période et les caractéristiques de connexion dans le schéma Sophos netflow.

Le format par défaut requis est :

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

Si rien n’arrive, comparer destination d’export, nouveaux objets, région et préfixe du déclencheur. Le modèle fixe Reserved Concurrency à 5 par défaut ; ce n’est pas une garantie de dimensionnement. Évaluer la charge et les métriques CloudWatch. Rate Exceeded peut concerner un quota de concurrence AWS ; recréer l’intégration Sophos à répétition ne résout pas cette limite.

Azure Network Watcher via Storage et Azure Function

Network Watcher écrit les NSG Flow Logs ou les VNet Flow Logs dans un Azure Storage Account. Il n’est plus possible de créer de nouveaux NSG Flow Logs. Prévoir des VNet Flow Logs pour les nouvelles sources. Les NSG Flow Logs existants peuvent être raccordés jusqu’à leur remplacement ; Microsoft supprimera la fonction le 30 septembre 2027. Prévoir leur migration vers VNet Flow Logs avant cette date. Les deux types nécessitent des intégrations Sophos séparées, car ils utilisent des conteneurs Blob ou Data Source Keys différents.

Il faut un abonnement Azure actif, le Storage Account avec son conteneur Blob et les journaux de flux activés, ainsi qu’un plan de service Azure Function pris en charge. Les options documentées sont Basic avec B1, B2 ou B3, Dynamic avec Y1 et certains codes Premium. Isolated n’est pas pris en charge. Choisir un code Premium dans la liste actuellement proposée, sans déduire sa compatibilité d’un nom de plan ressemblant.

Dans Network Watcher, envoyer les VNet Flow Logs d’une nouvelle source vers le Storage Account prévu ; n’utiliser les NSG Flow Logs existants qu’en transition jusqu’à la migration. Noter les noms du compte et du conteneur et vérifier l’arrivée effective de nouveaux objets.
Dans le Marketplace Sophos, ouvrir Microsoft Azure Network Watcher - Azure Storage Account, puis créer l’intégration sous Azure Storage Accounts > Set Up.
Recopier exactement Storage Account Name. Function App Name est une désignation descriptive libre, par exemple NSGFlowLogsForwarder, et non une valeur produit imposée. Définir Data Source Key sur insights-logs-networksecuritygroupflowevent pour NSG ou insights-logs-flowlogflowevent pour VNet.
Choisir Azure Function Service Plan Type, le Service Plan Code correspondant et Num Workers. La valeur par défaut est un worker. Basic B2 et B3 ont un maximum documenté de trois workers ; ne pas généraliser cette limite aux autres plans.
Avec Done, générer et télécharger AzureFunction.json. Dans Azure, charger le fichier via Deploy a custom template > Build your own template in the editor. Vérifier Resource Group et paramètres, puis choisir Review + Create et Create.
Storage Account et Function peuvent appartenir à des Subscription IDs ou Resource Groups différents. Dans ce cas, définir explicitement Storage Account Subscription ID et Storage Account Resource Group pour identifier la véritable source.
Après déploiement, retrouver un flux attendu dans le bon conteneur, puis dans netflow chez Sophos. Valider séparément les deux intégrations si les deux types sont utilisés.

Si la Function existe mais que les données manquent, comparer conteneur, Data Source Key, association Subscription/Resource Group et plan. Une deuxième intégration pour le même flux peut créer des doublons ; ce n’est pas une réparation générale.

GCP via Pub/Sub

GCP fournit cloudaudit, thirdpartyalert et, avec SIEM, netflow. Les sources prises en charge incluent Cloud Audit Logs, Security Command Center Findings, VPC Flow Logs et GKE Dataplane V2. N’inclure que les catégories volontairement sélectionnées.

Dans le bon projet GCP, créer un topic sous Pub/Sub > Topics, puis un abonnement à ce topic sous Subscriptions. Fixer Acknowledgement deadline à 300 secondes.
Sous Logging > Log router > Create Sink, créer un sink ciblant ce Cloud Pub/Sub topic. Limiter les filtres d’inclusion aux sources nécessaires. Les journaux d’organisation et de dossier nécessitent un sink agrégé adapté ; un sink de projet ne les couvre pas automatiquement.
Créer un compte de service dédié. Sous Add Principal dans l’abonnement Pub/Sub, attribuer à son identifiant le rôle Pub/Sub Subscriber.
Créer également un rôle personnalisé contenant monitoring.timeSeries.list et l’attribuer au compte. Un compte déjà utilisé pour Sophos XDR peut être réutilisé si cette autorisation requise est également approuvée.
Générer une clé JSON et la protéger. Dans le Marketplace Sophos, ouvrir GCP > Configured integrations > Add new. Saisir nom, Project ID et Subscription ID Pub/Sub, puis charger le bon JSON via Upload Key File.
Activer réellement les sources choisies : les journaux Data Access nécessitent de sélectionner les services sous IAM & Admin > Audit Logs. Les findings SCC passent par l’export Pub/Sub correspondant. Activer VPC Flow Logs au niveau des sous-réseaux ; l’échantillonnage limite leur portée par rapport à une capture complète des paquets.
GKE Dataplane V2 doit être sélectionné lors de la création du cluster. Vérifier ensuite Network Policy Logging et le filtre du sink. Ne pas remplacer sans planification un cluster existant pour un simple pilote de journalisation.
Produire un événement adapté pour chaque catégorie activée. Vérifier séparément preuve source, chemin Pub/Sub et schéma normalisé.

Lors d’une rotation, créer d’abord la nouvelle clé JSON et mettre à jour l’intégration Sophos existante. Dans API Query Log, secrets cache invalidated. Integration was updated. Restarting. indique l’actualisation. Supprimer l’ancienne clé GCP seulement après avoir à nouveau vérifié la collecte. Le chargement du fichier ne suffit pas.

OCI via Streaming

OCI fournit cloudaudit, http, nids et, avec SIEM, netflow. Il faut un stream OCI, les journaux souhaités et un service connector. L’identité d’intégration a besoin de stream-pull pour lire le stream ; des droits d’administration généraux ne sont pas nécessaires à la collecte régulière.

Préparer un utilisateur dédié et la structure groupe/compartiment approuvée. Accorder uniquement la lecture nécessaire sur le stream prévu.
Sous OCI Streams > Create Stream, choisir le Stream Pool voulu. Noter la Stream Pool OCID, qui n’est pas interchangeable avec un identifiant quelconque de stream ou de compartiment.
Via Connector Hub, router les journaux d’audit, de flux, de load balancer, WAF ou firewall approuvés vers ce stream. Avant Sophos, vérifier leur livraison au bon destinataire Streaming. Une autre cible du connector ne remplit pas automatiquement ce stream.
Dans le Marketplace Sophos, ouvrir OCI > Configured integrations > Add new. Saisir Name, Username dédié, son Auth token, Stream Pool ID, Tenant Name, Topic Name correspondant au stream et Region.
Pour des compartiments imbriqués, Tenant Name est le nom de la tenancy sans chaîne de compartiments. Pour des utilisateurs fédérés dans le cas documenté OracleIdentityCloudService, utiliser par exemple acme/OracleIdentityCloudService, où acme représente sa propre tenancy. Ne pas mélanger ces situations.
Choisir Done, puis vérifier un événement adapté dans OCI, sur le chemin Streaming et dans le schéma Sophos attendu. Un événement cloud audit ne teste pas le flux netflow supplémentaire.

En cas d’échec, vérifier d’abord Stream Pool, nom du stream, région, jeton et stream-pull. Si une seule catégorie manque, vérifier sa sélection et le routage du connector avant de recréer toute l’intégration.

Contrôler la qualité et le retrait

Documenter pour chaque catégorie source, début de collecte, période, schéma normalisé et exemple reproductible. Comparer heure et fuseau à la preuve source. Un flux ordinaire ou une trace d’audit ne doit pas nécessairement créer une détection ou un case MDR. Une connexion verte ou un enregistrement retrouvé ne prouve pas non plus plusieurs années de rétention.

Avant retrait, identifier chemin et ressources partagées. Arrêter uniquement l’export, le sink, le déclencheur ou le connector approuvé ; ne pas supprimer indistinctement un compartiment, topic, Storage Account ou stream partagé. Après vérification de l’arrêt des nouvelles données, retirer la configuration Sophos concernée et les clés ou ressources exclusivement dédiées selon les décisions de changement et de conservation. Supprimer une connexion ne prouve pas la suppression de la télémétrie historique.

Pendant un pilote en échec, conserver les anciens chemins nécessaires. Le retour arrière consiste à annuler la modification documentée de routage ou d’export et à la vérifier. Il n’annule pas automatiquement les données déjà transmises, les coûts cloud ou les événements perdus.