Suivre Les opérations de détection multi-locataires consistent à gérer une source unique de logique de détection indépendante des fournisseurs, traduite et ajustée par locataire, de sorte qu’un livre de clients utilisant différentes plateformes SIEM reste cohérent, ajustable et rapportable à partir d’une source unique gouvernée.
Un MSSP exécutant la détection pour des dizaines de locataires fait face à une question structurelle : chaque client obtient-il sa propre dérivation de chaque règle de détection, ou une source unique gouvernée est-elle traduite et ajustée par locataire ? La réponse détermine le coût d’exploitation, la précision des rapports de couverture et si une modification de la logique partagée se propage immédiatement ou reste en attente de correctifs manuels.
Cette page couvre la couche de contenu de détection de ce modèle : une source unique de logique de détection indépendante des fournisseurs, gérée de manière centralisée, traduite et ajustée par locataire. Hunters opère à la couche analyse et opérations, une plateforme alternative aux SOC et SIEM pour les MSSP et les fournisseurs MDR. ContraForce opère à la couche gestion des cas et flux de livraison, orientée vers la pile de sécurité Microsoft (Microsoft Sentinel et Defender XDR). La source de contenu de détection décrite ici se situe en amont, fournissant la logique de détection indépendante des fournisseurs que les couches d’exécution, d’investigation et de reporting consomment.
Portée : plateformes SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike). L’EDR comme cible de déploiement est hors de portée jusqu’à ce que le support par plateforme soit vérifié.
Un MSSP est également une entité réglementée à part entière. Règlement d’exécution (UE) 2024/2690, en vigueur depuis le 7 novembre 2024, établit des exigences de surveillance et de journalisation (section 3.2 de l’annexe) pour les fournisseurs de services de sécurité gérés sous NIS2. L’obligation de preuve du MSSP, non seulement celle de ses locataires, détermine la manière dont le contenu de détection est gouverné et rapporté.
Comment un SOC multi-locataires peut-il maintenir la logique de détection cohérente à travers des environnements clients utilisant différentes plateformes SIEM ?
Écrire la logique de détection une seule fois dans un format indépendant des fournisseurs (Sigma). La traduire par SIEM de chaque locataire. Gérer la source de manière centralisée.
L’artefact de base partagé
La base est un artefact de logique de détection unique. Sa condition de logique est évaluée par rapport à un schéma normalisé commun plutôt que par rapport aux champs de journal brut de chaque locataire. C’est ce qui rend la même règle portable entre Splunk, Microsoft Sentinel, Google SecOps, Elastic, et CrowdStrike sans réécrire la logique de détection elle-même.
La normalisation mappe les champs spécifiques à la source à ce schéma partagé tout en préservant leur sémantique. Une règle écrite contre le champ normalisé auth.result signifie la même chose quel que soit le fournisseur d’identité qui a produit l’événement : auth.result se résout en {succès, échec, défi} selon un contrat sémantique nommé, pas selon ce que l’IdP du client appelle le champ.
La superposition par locataire
Chaque locataire obtient une superposition. La superposition transporte le mappage des champs qui traduit les champs sources bruts de ce locataire dans le schéma normalisé partagé, et les paramètres d’ajustement (seuils, fenêtres temporelles, exclusions de bruit) adaptés à l’environnement de ce locataire. La base et la superposition sont versionnées séparément.
Une mise à jour logique de la base se propage à chaque locataire dont la superposition mappe les champs requis. Un changement d’ajustement à la superposition d’un locataire ne touche que ce locataire.
Partagé versus spécifique au locataire
Ce qui reste partagé : la condition de logique de détection, les définitions du contrat sémantique dont dépend la logique, la norme MITRE ATT&CK étiquette technique, et l’historique de version et de changement.
Ce qui est spécifique au locataire : le mappage champ brut à normalisé, le statut de validation du contrat à l’exécution (évalué comme réussi ou échoué selon le flux d’événements réel du locataire, pas une propriété statique de la règle), la traduction de la plateforme cible, et les paramètres de réglage.
Comment gérez-vous le contenu de détection à travers des dizaines d’environnements clients sans le dériver par client ?
Un artefact gouverné par détection, pas une dérivation par client.
Dériver le fichier de règle par client signifie maintenir des copies indépendantes de ce qui devrait être un artefact gouverné. Une correction logique ou une nouvelle mise à jour technique d’évasion doit être réappliquée manuellement à chaque dérivation. Les dérivations dérivent, et l’unique historique de changements versionné disparaît.
Lorsque un auditeur ou un client demande qui a changé cette règle, quand et pourquoi, la réponse doit pouvoir être tracée à une seule chronologie. Des copies divergentes qui ne reflètent pas nécessairement la même correction rendent cette question inapplicable. C’est un échec de gouvernance et de contrôle des changements, et cela sape directement la trace de preuve sur laquelle dépendent les auditeurs.
Le modèle base-plus-superposition garde un artefact gouverné :
| Couche | Contient | Portée |
|---|---|---|
| Base (partagée) | Condition de logique de détection, définitions de contrat sémantique/temporel/corrélation, étiquette de technique MITRE ATT&CK, historique de version et de changement | Tous les locataires |
| Superposition (par locataire) | Mappage champ brut à normalisé, traduction de la plateforme cible, seuils, fenêtres temporelles, exclusions de bruit | Un locataire |
Un changement à la logique de base se propage par construction. Seuls le mappage et l’ajustement restent locaux. C’est la Détection-comme-Code discipline appliquée aux opérations multi-locataires : les changements de règle sont versionnés, révisés, et suivis en tant qu’artefacts de code. L’automatisation du déploiement transporte la base mise à jour à chaque locataire dont la superposition la prend en charge.
La version du contrat gouverne la base. Les modifications doivent être versionnées, et les modifications fondamentales nécessitent un nouvel ID de contrat, de sorte que chaque locataire obtienne un chemin de mise à niveau conciliable plutôt qu’une rupture silencieuse.
SOC Prime travaille avec les MDRs pour concevoir des opérations d’ingénierie de détection depuis les détections SIEM jusqu’à la réduction du volume SIEM avec Prime Detect.
Comment ajuster par client sans casser la règle partagée ?
Ajuster à la superposition. La règle de base reste fixe.
La superposition transporte la configuration spécifique au locataire en deux parties.
Mappage des champs. Les produits sources de chaque locataire nomment le même fait différemment dans le journal brut, donc la superposition traduit ces champs bruts en schéma normalisé partagé. Le mappage doit satisfaire indépendamment le même contrat sémantique que tout autre locataire partage.
Un échec concret montre pourquoi cela compte. La superposition d’un locataire mappe le résultat « MFA en attente » de son fournisseur d’identité à la valeur normalisée « échec » plutôt que « défi ». La logique de détection de contournement MFA partagée, qui recherche une connexion réussie sans événement de défi préalable, ne voit jamais une valeur « défi » pour ce locataire. Chaque connexion réussie est signalée comme un contournement : un faux positif de masse pour ce locataire, alors que la règle identique est correcte pour chaque autre locataire dont la superposition mappe correctement l’énum.
La règle n’a jamais changé. L’échec est entièrement dans la superposition, une erreur de superposition se faisant passer pour un bogue de règle.
Paramètres d’ajustement. p serré, elle joint des événements non reliés. Ces fenêtres peuvent nécessiter un ajustement par locataire pour les caractéristiques de synchronisation d’horloge et de latence de ce locataire.
La condition de logique de détection de la règle de base, évaluée contre les champs normalisés, ne change jamais pour un seul locataire. Le statut de validation du contrat doit être évalué par locataire à l’exécution, et non supposé à partir de la règle ou du type de source.
Comment puis-je rapporter la couverture de détection MITRE ATT&CK à chaque client alors que chaque client nous envoie différentes sources de journaux ?
Calculer la couverture par locataire selon le propre ensemble de techniques priorisées de ce locataire. Ne jamais rapporter un seul chiffre biblique à travers les locataires. La méthode de mesure complète est décrite dans la page complémentaire sur la mesure de la couverture de détection MITRE ATT&CK.
Modèle de couverture :
Couverture (locataire) = techniques où [télémétrie valide ET règle déployée ET règle prouvée pour déclencher] divisé par le nombre de techniques prioritaires de ce locataire.
Quand une technique est comptée comme couverte
Une technique est comptée comme couverte uniquement lorsque toutes ces conditions sont réunies :
- Télémétrie valide pour ce locataire. La source de données requise est collectée, ingérée activement, passant les contrats sémantique, temporel, et de corrélation, et atteignant les SLO de qualité (taux de nullité, fraîcheur). Toutes ces conditions sont évaluées par rapport au flux d’événements réel de ce locataire, pas une valeur par défaut du type de source.
- Règle déployée et mappée à la technique. Un fait d’inventaire de la Détection-comme-Code : quelle règle existe, quelle étiquette MITRE ATT&CK elle porte, sa version.
- La règle a une preuve de déclenchement. Étallonage du taux de déclenchement, événements canari, ou validation par test atomique prouvant que la règle produit des alertes sur une activité réelle ou simulée. Une étiquette de technique sans enregistrement de déclenchement est une étiquette, pas une preuve.
Le dénominateur est le propre sous-ensemble nommé et priorisé de ce locataire de techniques ATT&CK. Jamais la matrice complète ATT&CK . Jamais la taille de la bibliothèque de règles du fournisseur.
Rapport des états de lacune
Rapportez les états de lacune distinctement, jamais comme un seul chiffre collapsé :
| État | Signification | Remédiation |
|---|---|---|
| VALIDE | Tous les portiques passent, règle déployée, preuve de déclenchement en dossier | Couverte à la date du rapport |
| INVALIDE | Source requise non collectée ou non ingérée | Activation de la source ou réparation de l’ingestion |
| DÉGRADÉ | Source collectée mais contrat ou SLO de qualité échouant | Réparation de mappage, analyseur ou schéma |
| Lacune de contenu | Télémétrie valide, aucune règle mappée à la technique | Développement de contenu |
Ne pas fusionner INVALIDE et DÉGRADÉ en un seul chiffre de « lacune ». Différents modes d’échec nécessitent des remédiations différentes et produisent des dialogues différents avec les clients.
Rapportez avec une date. La couverture est ponctuelle.
Quel impact la réutilisation du contenu a-t-elle sur la marge et la charge de formation des analystes ?
La réutilisation du contenu à travers les locataires convertit le coût d’ingénierie de détection par client en un coût partagé et amorti. Quand la logique de détection de base est écrite une fois et traduite par locataire, le coût d’ingénierie se répartit sur le livre de clients.
Marge. Chaque locataire utilisant la base partagée évite des heures supplémentaires d’ingénierie de détection. L’amélioration de la marge est structurelle. Le programme partenaire MDR de SOC Prime estime l’économie à 4 000 heures par an sur la recherche de menaces et le codage du contenu de détection. puts the saving at 4K hours per year on threat research and detection content coding.
Charge de formation. Une méthodologie Détection-comme-Code. Un schéma normalisé. Un ensemble de sémantiques de contrat. Les analystes s’intègrent dans le modèle partagé plutôt que dans des bibliothèques de règles par client avec des noms, des structures et des intentions divergents. Lorsqu’un analyste passe de la file d’attente d’un locataire à celle d’un autre, la logique de détection, le schéma, et les contrats sont déjà familiers.
L’objection honnête. Le contenu de détection partagé n’efface pas la différenciation du MSSP. La différenciation se déplace vers l’ajustement, la réponse, et le reporting. Les superpositions spécifiques au locataire, les manuels de réponse et le reporting face au client montrent la valeur du MSSP. Un prospect qui entend « contenu partagé » et pense « marchandise » doit voir exactement où réside le travail personnalisé.
Moteur réglementaire. L’obligation de preuve du MSSP sous NIS2, via le Règlement d’exécution (UE) 2024/2690, nécessite des preuves de surveillance et de journalisation par le MSSP lui-même, non seulement par ses locataires. Le modèle partagé amortit cette production de preuve.
Où cela ne tient pas
Le modèle base-plus-superposition suppose que la règle de base est écrite contre un schéma normalisé que le produit source de chaque locataire peut satisfaire. Le modèle échoue dans les conditions suivantes.
- Produits sources qui n’émettent pas les données requises. Différents produits sources, ou différentes versions du même produit, peuvent ne pas émettre un composant de données requis du tout. Aucun overlay ne peut corriger un champ structurellement absent. C’est une lacune INVALIDE, remédiée par l’activation ou la mise à niveau de la source.
- Disponibilité des sources. Un locataire n’a pas intégré une source de journal requise, ou son ingestion s’est arrêtée. La règle, le mappage et l’ajustement peuvent tous être corrects, et les techniques affectées restent découvertes jusqu’à ce que la source recommence à circuler.
- Non-concordance des tolérances de corrélation. La tolérance temporelle par défaut partagée peut manquer de corrélations réelles pour un locataire avec une synchronisation d’horloge ou une latence inhabituelles. L’ajustement par locataire des fenêtres de corrélation est nécessaire, non facultatif.
- Modèles de menaces uniques ou contraintes de résidence des données. Un locataire avec un profil de menace réellement unique peut avoir besoin d’une logique de détection personnalisée que la base partagée ne contient pas. Une contrainte interdisant le partage d’artefacts de logique de détection à travers les frontières organisationnelles a le même effet.
- L’isolation du locataire n’est pas négociable. Le modèle partage la LOGIQUE de détection à travers les locataires (texte de règle, définitions de contrat). Il ne partage jamais les données du locataire, le cache d’enrichissement, l’état d’alerte ou les résultats de validation à travers une frontière de locataire. Toute architecture où les recherches d’enrichissement d’un locataire ou la file d’attente d’alerte fuient dans celle d’un autre est un incident prioritaire par conception. Le partage de logique et le partage de données sont des affirmations différentes.
Modèle d’opération multi-locataire – Check-list
Rédiger et gouverner la règle de base
- Logique de détection rédigée dans un format indépendant du fournisseur (Sigma) basé sur un schéma défini par un contrat normalisé
- Règle de base séparée de la superposition du locataire : logique de détection, définitions de contrat, étiquette MITRE ATT&CK et historique de version restent partagés
- Superposition par locataire transporte le mappage des champs, la traduction de la plateforme, et les paramètres d’ajustement seulement, versionnés séparément de la base
- Les changements à la règle de base se propagent à chaque locataire par construction
- L’historique des changements peut être retracé à une chronologie gouvernée unique par règle de base, avec les changements de superposition suivis par locataire
- Versionnement du contrat inforcé : les modifications fondamentales portent un nouvel identifiant de contrat
Valider le mappage et la traduction de la plateforme
- Les mappages de champs satisfont le même contrat sémantique par locataire, avec la validation du contrat exécutée à l’exécution contre le flux d’événements réel de chaque locataire
- Traduction de la plateforme validée par cible SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike)
Calculer la couverture par locataire
- Couverture calculée par locataire selon le propre ensemble de techniques ATT&CK priorisées de ce locataire
- Le numérateur de couverture nécessite que la télémétrie soit valide, la règle déployée, et que la règle ait une preuve de déclenchement, le tout ensemble
- Les états de lacune sont distingués : VALIDE, INVALIDE (source manquante), DÉGRADÉE (source présente, validation échouante), et Lacune de contenu (télémétrie valide, aucune règle mappée)
Ajuster, isoler, et rapporter
- Les tolérances temporelles de corrélation examinées par locataire pour l’ajustement à la synchronisation et la latence de l’horloge
- Ajustement fait dans la superposition, jamais en dérivant la règle de base
- Isolation du locataire appliquée : aucune donnée partagée, cache d’enrichissement, état d’alerte, ou résultats de validation entre des frontières de locataire
- Couverture rapportée avec une date, par locataire, jamais comme un chiffre de la bibliothèque à travers le livre
- Obligation de preuve réglementaire propre au MSSP (Règlement d’implémentation NIS2 2024/2690) adressée aux côtés des obligations du locataire
- Formation des analystes alignée sur la méthodologie partagée Détection-comme-Code, le schéma normalisé, et les sémantiques de contrat
FAQ
Comment un SOC multi-locataires peut-il maintenir la logique de détection cohérente à travers des environnements clients utilisant différentes plateformes SIEM ?
Écrire la logique de détection une fois dans Sigma, un format indépendant des fournisseurs, et la traduire par SIEM de chaque locataire. Un modèle base-plus-superposition conserve la logique de détection partagée et le mappage de techniques MITRE ATT&CK dans un artefact gouverné, tandis que la superposition de chaque locataire transporte le mappage des champs, la traduction de la plateforme et les paramètres d’ajustement pour cet environnement. Cela s’étend aux plateformes SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic, CrowdStrike). L’EDR comme cible de déploiement est hors de portée jusqu’à ce que le support par plateforme soit vérifié.
Comment dois-je rapporter la couverture de détection MITRE ATT&CK à chaque client alors que chaque client nous envoie différentes sources de journaux ?
Calculer la couverture par locataire selon le propre ensemble de techniques ATT&CK priorisées de ce locataire, jamais comme un chiffre de la bibliothèque à travers le livre. Une technique est considérée comme couverte uniquement lorsque la télémétrie est valide pour ce locataire, une règle est déployée et mappée à la technique, et la règle a une preuve de déclenchement. Rapporter quatre états de lacune distincts : VALIDE, INVALIDE (source manquante), DÉGRADÉE (source collectée mais validation échouante), et Lacune de contenu (télémétrie valide, aucune règle mappée). Chaque rapport de couverture porte une date.
Le contenu de détection partagé efface-t-il la différenciation d’un MSSP ?
Le contenu de détection partagé déplace l’endroit où la différenciation réside. La valeur distincte du MSSP se déplace vers l’ajustement spécifique au locataire, les manuels de réponse et la notification de couverture face au client. Les superpositions par locataire, les playbooks de réponse et l’analyse de couverture par locataire sont là où l’expertise du MSSP se manifeste pour chaque client.
