Aller au contenu
Avanet
Connexion

Sophos SIEM : choisir un transport et configurer HTTP Ingest

Sophos Fusion Admin Sophos SIEM

HTTP Ingest reçoit des messages de journal via un point de terminaison HTTPS fourni par Sophos. La source doit savoir envoyer des requêtes HTTP POST à un webhook ou un point HTTP avec authentification par jeton Bearer. Une souscription Sophos Next-Gen SIEM est nécessaire ; une licence XDR existante ne suffit pas.

Trois tâches sont distinctes : choisir le transport, connecter la source, puis vérifier les événements réellement reçus. La création réussie du connecteur ne prouve ni la normalisation ni la détection. Les principes SIEM et contrôles de licence précèdent donc le pilote.

Quel transport personnalisé convient à la source ?

Custom concerne les sources sans intégration optimisée Sophos adaptée. Vérifier d’abord dans Marketplace l’intégration produit et ses catégories d’événements réelles. Un nom de fournisseur connu ne signifie pas que tous ses types de journaux sont pris en charge.

Six possibilités existent :

  • HTTP Ingest : envoi direct par HTTPS POST avec jeton Bearer, sans infrastructure cloud à exploiter soi-même.
  • Customer-Managed S3 : journaux dans un bucket de son propre compte AWS, transmis par la configuration Lambda/CloudFormation fournie.
  • S3 Ingest – Sophos-Managed (with token) : destination gérée par Sophos, avec preuve de propriété exigée par le fournisseur.
  • S3 Ingest – Sophos-Managed (without token) : même modèle de propriété, sans cette vérification.
  • Azure Event Hubs : flux d’événements fourni dans un Event Hub accessible.
  • Azure Storage Account : fichiers dans Blob Storage, transmis par une Azure Function.

Le guide S3 distingue les trois variantes de bucket. Le guide Azure sépare Event Hubs de Storage/Azure Function. Un équipement syslog peut plutôt nécessiter un XDR Data Collector ; son adresse IP ne remplace pas le point HTTP Ingest.

Préparer le pilote et les identifiants

Consigner tenant, droits SIEM, source, catégorie de journaux et responsable. La configuration générale des intégrations exige un rôle Admin ou Super Admin approprié ainsi que l’accès à l’export de la source. Sa documentation doit expliquer URL, jeton Bearer, format et comportement de transmission. Aucun format JSON universel n’est supposé ici.

Choisir une source de test autorisée et un événement inoffensif identifiable. Noter heure source avec fuseau, identifiant de test et champs attendus. Conserver les chemins existants jusqu’à validation ; l’envoi supplémentaire ne doit créer ni doublons involontaires ni transfert non autorisé de données personnelles.

Integration Key et URL ne sont affichés qu’une fois. Préparer le coffre de secrets approuvé avant la création. Ne pas laisser les clés dans captures, tickets, dépôts publics ou commandes conservées dans l’historique du shell. Documenter responsable et procédure de rotation contrôlée. L’Integration Credential Manager accepte certains types seulement, pas toute clé d’ingestion.

Créer HTTP Ingest dans Sophos Fusion

  1. Ouvrir Security Operations > Integrations > Marketplace, puis Custom.
  2. Sous HTTP Ingest, cliquer sur Set Up.
  3. Saisir un nom unique, par exemple ApplicationMetier-Test-HTTP, puis Done. Ce libellé libre doit identifier source et environnement.
  4. Enregistrer immédiatement Integration Key et URL dans le coffre prévu. Les deux valeurs ne seront plus affichées. Si elles ne sont pas sauvegardées correctement, suspendre le raccordement et clarifier la procédure de remplacement prise en charge ; aucune récupération ultérieure n’est promise.
  5. Configurer l’export HTTPS documenté de la source avec ces valeurs exactes. Vérifier Bearer, format et éventuels mécanismes de nouvelle tentative ou tampon selon la documentation source. Ne pas reprendre une charge utile inventée ou un modèle d’une autre API.
  6. Retrouver la connexion dans Configured integrations sur la page Custom, envoyer l’événement prévu et vérifier séparément son ingestion.

Une source synthétique avec une définition complète de parser et des requêtes de recherche est décrite dans l’exemple pratique HTTP/parser.

Valider transport, normalisation et analyse

Une Custom Integration assure d’abord le transport vers XDR. Les types de journaux pris en charge utilisent leur normalisation existante ; les formats inconnus ou personnalisés peuvent arriver dans le schéma generic. Le modèle des parsers du guide SIEM explique pourquoi un parser personnalisé et les champs requis peuvent aussi être nécessaires.

Pour la validation, ouvrir Security Operations > Integrations > Configured Data Sources et sélectionner la source concernée. Dans ses détails, Advanced Search affiche une recherche préparée pour son ID de capteur sur les dernières 24 heures. Limiter la période au moment du test et comparer le tenant, l’identifiant source, l’heure de l’événement, l’action et les champs requis avec l’événement envoyé. Valider les intégrations explique le point d’entrée, et Data Lake Search le filtrage plus précis.

Un statut vert indique la connexion, pas l’exhaustivité des données ni le bon schéma. Trouver du texte brut générique ne démontre pas qu’un detector souhaité peut l’exploiter. L’absence de résultat en recherche simple n’exclut pas des données generic.

Valider le pilote seulement lorsque transport, correspondance des champs exploitable et recherche souhaitée sont chacun démontrés. Tester une détection uniquement si une détection adaptée et prise en charge est prévue. Un événement d’audit ou de connexion ordinaire ne doit pas nécessairement déclencher d’alerte.

Isoler les erreurs et préparer le retrait

En cas de données manquantes, vérifier d’abord l’émission réelle, le bon point de terminaison et l’utilisation de la clé comme identifiant Bearer prévu. Examiner ensuite erreurs source, réseau, plage horaire et statut. Une réponse HTTP positive ne remplace pas le contrôle de l’événement. Si les données arrivent mais sont mal associées, examiner format et parser plutôt que créer préventivement un second connecteur.

Pour une pause, arrêter l’export par la procédure documentée de la source. Avant retrait, clarifier dépendances, preuves historiques et obligations de conservation. Arrêter seulement cet envoi et vérifier le chemin précédent encore nécessaire. Suppression d’intégration, révocation d’une clé et suppression des données historiques sont distinctes ; aucun bouton universel n’est promis. Pour une clé perdue ou compromise, clarifier avec Sophos la procédure de remplacement/révocation plutôt qu’improviser une rotation non testée.