Sophos SIEM : connecter des sources S3 propres ou gérées

Sophos Next-Gen SIEM propose trois transports S3 : bucket dans son propre compte AWS, ou destination gérée par Sophos avec ou sans jeton de propriété. Le choix dépend de l’exporteur et du modèle d’exploitation. Un bucket seul ne produit pas des événements XDR normalisés et exploitables.

Il faut une souscription Next-Gen SIEM, accès à la configuration des intégrations et les droits AWS ou fournisseur propres à la méthode. Le choix des transports personnalisés présente les alternatives. Transférer seulement les journaux autorisés ; garder les destinations existantes jusqu’à validation.

Choisir la variante et les responsabilités

Customer-Managed S3 convient lorsque les fichiers restent dans un bucket du compte AWS de l’entreprise. L’exploitant fournit bucket, ressources CloudFormation/Lambda et déclencheur, avec responsabilité des coûts et modèle IAM vérifié.

Avec Sophos-Managed S3, Sophos gère la destination. La source doit connaître alias, chemin et éventuels paramètres de rôle. Si le fournisseur exige un fichier ou jeton prouvant la propriété avant export, choisir with token ; sinon without token. Ce jeton n’est ni un identifiant API général ni la preuve que les journaux suivants arrivent intégralement.

Avant le pilote, documenter source, compte/région AWS, préfixe, format, identité et responsables. Les ARN IAM et jetons réels proviennent de la configuration fournisseur/AWS, jamais d’exemples tiers. Protéger secrets et paramètres donnant accès.

Bucket propre : intégration et transmission Lambda

1. Préparer Sophos Fusion

Ouvrir Security Operations > Integrations > Marketplace > Custom.
Sous Customer-Managed S3, cliquer sur Set Up.
Lire les indications S3, choisir Next, saisir un nom unique et terminer par Done.
Télécharger en lieu sûr le modèle CloudFormation généré pour Lambda. Il appartient à cette intégration, pas à un collector ou à NDR.

2. Exécuter CloudFormation dans le bon compte AWS

Le bucket doit déjà contenir les journaux à ingérer. Déployer dans sa région, avec droits CloudFormation, Lambda, IAM et autres ressources du modèle. Vérifier le modèle généré selon les règles de sécurité et de coûts avant exécution.

Dans la bonne région AWS, ouvrir CloudFormation > Create stack ; depuis une liste de stacks, choisir With new resources (standard).
Sous Prepare template, sélectionner un modèle existant, puis charger le YAML téléchargé sous Specify template. Une URL S3 autorisée du modèle est une alternative ; aucun bucket ne doit devenir public.
Saisir un nom sans espaces. Choisir IntegrationType adapté. Pour plusieurs types ou une correspondance incertaine, Sophos indique generic, sans garantie de détection.
Dans NotificationBucket, saisir uniquement le nom du bucket, sans URL ni URI S3. Si SNS remplace volontairement les notifications S3, renseigner son ARN dans SNSNotificationarn. Ne modifier les autres valeurs que selon les besoins vérifiés du modèle.
Vérifier les ressources IAM, confirmer explicitement leur création et lancer avec Submit après contrôle des paramètres.
Contrôler les événements et CREATE_COMPLETE. Un stack terminé ne prouve ni le bon déclencheur ni la qualité des événements.

Ce parcours standard place bucket, stack et Lambda dans le même compte et la même région. Il ne valide pas d’autres architectures.

3. Ajouter le bucket comme déclencheur

Dans Lambda, ouvrir la fonction réellement créée. Sophos indique le modèle {STACKNAME}-sophos-xdr-lambda-{INTEGRATIONTYPE}.
Ouvrir Function overview > Add Trigger, puis S3. Une variante SNS exige un topic préparé séparément.
Choisir le bucket des journaux et All Object Create Events sous Event Type.
Renseigner seulement le préfixe voulu dans Prefix, ou laisser vide sans préfixe. Laisser Suffix vide. Un préfixe trop étroit exclut des fichiers ; trop large, il peut transférer des données indésirables et accroître les coûts.
Lire l’avertissement de coût Lambda, terminer par Add, puis contrôler l’association et un nouvel objet de test.

Le déclencheur Object Create ne prouve pas l’ingestion rétroactive de tout le contenu existant. Confirmer séparément l’historique souhaité sans réécrire sans contrôle les fichiers existants.

Destination Sophos sans jeton de propriété

Ouvrir Security Operations > Integrations > Marketplace > Custom, puis Set Up pour S3 Ingest – Sophos-Managed (without Ownership token).
Choisir IAM User, Canonical User ID ou IAM Role, selon le fournisseur, saisir sa valeur et créer avec Done.
Ouvrir l’intégration et Details, puis conserver les paramètres de façon protégée.
Dans l’exporteur, utiliser AccessPointAlias comme nom de bucket, LogFolderPath comme chemin et AWSRegion si requis. L’identité doit correspondre à celle de création. Avec un rôle, utiliser aussi IAMAssumeRole comme ARN du rôle à assumer côté source.
Démarrer l’export avec un nouvel événement et valider l’ingestion. Aucune Ownership-Challenge n’est ajoutée à cette variante.

Destination Sophos avec jeton de propriété

Même point d’entrée, mais choisir S3 Ingest – Sophos-Managed (with token). Après Set Up, saisir type d’identité et valeur fournisseur, puis ouvrir l’intégration et Details.

La source utilise AccessPointAlias, AWSRegion, LogFolderPath et l’identité correspondante ; IAM Role ajoute IAMAssumeRole. Utiliser également OwnershipToken suivant la procédure de vérification du fournisseur.

Plusieurs étapes peuvent être nécessaires : le fournisseur écrit un fichier de challenge ou objet équivalent dans la destination. Recharger ensuite Details dans Sophos, récupérer le nouveau OwnershipToken et le transmettre au fournisseur pour achever la vérification. Respecter sa procédure, sans jeton inventé ni objet de test improvisé. Valider les journaux après cette vérification.

Valider les variantes et retirer proprement

L’intégration apparaît dans Configured integrations. Vérifier un événement nouveau et inoffensif côté source, puis tenant, source, horodatage et champs dans Sophos. Pour S3 propre, contrôler objet, trigger et erreurs Lambda/stack ; pour S3 géré, vérifier d’abord identité, alias, chemin et éventuelle preuve de propriété.

Custom S3 assure d’abord le transport. Les types pris en charge sont normalisés selon leur intégration produit ; d’autres arrivent éventuellement dans generic. Le guide SIEM sépare transport, parser et détection. Un statut vert ou fichier écrit ne garantit ni historique complet ni détection.

Pour le retrait, arrêter d’abord l’export ou le déclencheur dédié et vérifier l’ancien chemin nécessaire. Ne pas supprimer indistinctement buckets, identités IAM, topics ou dépendances Lambda partagés. Avant suppression de l’intégration ou ressources cloud, clarifier conservation, coûts résiduels, dépendances et procédure prise en charge. Supprimer l’intégration ne prouve ni l’effacement des données SIEM historiques ni l’arrêt de tous les coûts AWS.