Exploiter Sophos XDR Custom Detection et Suppression Rules

Sous Security Operations > Rules, on exploite des règles de detection personnalisées et des Suppression Rules. Les premières créent des detections à partir d’événements normalisés ; les secondes marquent tôt les detections correspondantes comme supprimées. Les deux modifient le processus d’investigation et exigent une condition approuvée, étroitement définie et un responsable.

Le guide des Cases et règles Classic explique la vue Classic qui reste différente. Ses contraintes Super Admin, de quantité ou de 20 minutes ne sont pas transposées à Security Operations.

Avant de créer une règle

Définir d’abord but, source, schéma, correspondances attendues et cas volontairement exclus. Vérifier avec des événements historiques adaptés dans Data Lake Search que la condition est pertinente. Un test autorisé emploie un compte dédié ou d’autres données de test approuvées ; aucune activité malveillante réelle n’est générée.

Un résultat dans une recherche historique ne prouve pas le même effet dans une règle active. Moteurs de recherche et de règles diffèrent ; certains champs enrichis n’apparaissent que plus tard. L’acceptation doit donc couvrir une correspondance attendue et une non-correspondance attendue. Avant changement, documenter requête, nom, description, severity, état d’activation et résultats antérieurs.

Créer une Custom Detection Rule

Pour une règle de detection, créer d’abord une requête Advanced Search adaptée sous Security Operations > Data Lake Search. Elle doit viser des événements normalisés d’un schéma approprié. Ensuite :

1. Copier le texte validé et ouvrir Security Operations > Rules.
2. Choisir Create Rule au-dessus de Custom Rules.
3. Coller la requête dans Rule Criteria.
4. Saisir un Name explicite, des Mitre Attack Categories pertinentes et une Description compréhensible.
5. Choisir une severity justifiée puis créer avec Create Rule.

Une nouvelle Custom Rule est activée dès sa création. Autorisation et responsable doivent donc être établis au préalable. Ce défaut diffère d’un nouveau Custom Parser. Ne pas activer en production une condition sans limite simplement pour l’essayer.

Le streaming n’est pas une recherche enregistrée

Les Custom Rules traitent des données en streaming. Les champs primitifs n’y reçoivent pas automatiquement les valeurs par défaut présentes ensuite dans le Data Lake. Les conditions NULL doivent donc prendre en compte les valeurs réellement absentes. Les motifs glob ne sont pas pris en charge ; les constructions regex comme backreferences, motifs récursifs, assertions arbitraires de largeur nulle de type look-around et code intégré sont aussi limitées. Une expression Search fonctionnelle n’est pas vendue comme une règle garantie sans vérification.

Des champs logiques comme @user peuvent se développer dans les champs du schéma sélectionné. Une règle ne correspond qu’à un schéma. Certains champs ajoutés ultérieurement sont indisponibles : hostname, enrichissements géographiques/blacklist pour auth/netflow/dns_query et WHOIS du schéma DNS, par exemple. Vérifier les champs exacts dans le contexte de la règle, sans les remplacer par des champs Search au nom similaire.

Circuit breaker et responsabilité du client

Les Custom Rules peuvent créer au maximum 5 000 detections par heure ou 100 000 sur 24 heures. Au-delà, le circuit breaker désactive la règle et Sophos en informe l’auteur par e-mail. Réduire ensuite son périmètre ; ne pas réactiver la règle inchangée. Un flux d’alertes interrompu peut donc signaler une règle désactivée, pas la résolution des risques.

Les Cases créés automatiquement par les règles client sont customer-managed et ne déclenchent pas d’investigation MDR automatique. Les schémas Antivirus, Email, NIDS et Thirdparty décrivent aussi is_custom_alert=true : ces Custom Alerts sont traités par le tenant plutôt que par la file du service MDR ; leur severity ne change pas. Cela n’exclut pas globalement chaque enregistrement de Custom Parser du MDR. Créer et valider les parsers explique la normalisation préalable.

Limiter délibérément la suppression

La suppression vise les répétitions légitimes confirmées, pas à masquer une activité inexpliquée. Les règles du tenant n’agissent que dans celui-ci ; les règles Global sont gérées par Sophos et en lecture seule. Documenter toute question sur une règle globale et la clarifier par le support normal.

Une detection supprimée reçoit tôt ce statut, avant de pouvoir déclencher des réponses automatisées en aval. Des playbooks ou l’isolation d’un hôte peuvent ainsi ne pas s’exécuter. Avant approbation, préciser quelle activité légitime sera reconnue et quelle réaction de sécurité sera volontairement empêchée.

Créer une suppression par requête

1. Vérifier la condition sur des detections existantes dans Data Lake Search.
2. Choisir Create Rule sous Security Operations > Rules > Suppression Rules.
3. Saisir la condition dans Rule Criteria.
4. Utiliser See potential matches with current data comme aperçu de plausibilité.
5. Définir nom, description et statut de résolution, puis créer avec Create Rule.

Les nouvelles règles de suppression sont elles aussi activées par défaut. Périmètre, autorisation et retour arrière doivent donc précéder Create Rule.

On peut aussi ouvrir une detection précise puis Actions > Create Suppression Rule. Choisir délibérément les entities préremplies ; plusieurs conditions sont liées par AND. Échapper correctement les caractères spéciaux regex saisis manuellement. Ne pas déduire une suppression universelle d’un seul résultat attendu.

Pourquoi aperçu et règle active peuvent diverger

L’aperçu utilise Advanced Search sur des detections terminées et enrichies. La suppression s’exécute pendant leur création. enrichment_details, status et case sont indisponibles ; utiliser le schéma événementiel thirdparty plutôt que third_party_details pour les valeurs tierces. Tous les critères doivent être vrais ensemble au moment de la suppression. Un enregistrement final peut rassembler des conditions qui n’étaient vraies que séparément auparavant.

See potential matches n’est donc pas une garantie d’effet. Après création, modification, activation ou désactivation d’une règle, attendre au moins dix minutes avant de juger le résultat. Les detections apparues juste après le changement ne constituent pas un test fiable du nouvel état.

IPv4-CIDR est possible en suppression, bien que Detection Search ne prenne pas en charge la recherche CIDR. Vérifier d’abord la requête sans plage puis l’adapter à la règle. Les adresses IPv6 peuvent être comparées après normalisation ; IPv6-CIDR et IPv4-mapped IPv6 ne sont actuellement pas pris en charge en suppression. Ne pas transposer sans contrôle une syntaxe de réseau de pare-feu.

Contrôler, documenter et revenir en arrière

Un clic sur le nom affiche critères et détails. En présence de résultats sur sept jours, nombre, dernier résultat et graphique apparaissent. Pour la suppression, History affiche aussi les changements. L’absence de graphique peut simplement signifier que l’événement attendu n’est pas survenu.

Inclure les detections de Custom Rules via Custom Detections dans la liste. Les detections supprimées déjà triagées deviennent visibles avec Triaged Detections ; une recherche adaptée s’ouvre depuis les détails de la règle. Contrôler correspondances et non-correspondances attendues, schéma/source et réponse souhaitée ou volontairement absente.

Enabled active ou désactive une règle. Archive la désactive et la retire de la liste par défaut. Showing Archived Rules permet de l’ouvrir ; Restore la rétablit désactivée. Ne pas activer une règle restaurée sans nouvelle acceptation. La latence documentée de suppression reste à considérer lors de sa désactivation.

Si l’acceptation échoue, ne désactiver que sa propre règle concernée et vérifier l’état précédemment documenté. Cases, exports ou detections supprimées déjà créés ne disparaissent pas automatiquement. Les detections supprimées peuvent être ajoutées à des Cases et leur étiquette modifiée si nécessaire. Ne pas désactiver une protection globale ou la règle d’un tiers pour faire réussir son test.

La transmission au support opérationnel comprend source/schéma, critères et version, auteur, autorisation, preuves de correspondance/non-correspondance, severity/résolution, activation, surveillance du circuit breaker et date de revue. L’acceptation des intégrations reste un préalable : une règle silencieuse ne répare pas une source manquante.