Folgen Multi-Mandanten-Erkennungsoperationen sind die Praxis, eine Quelle von herstellerneutraler Erkennungslogik zu verwalten, die pro Mandant übersetzt und abgestimmt wird, sodass ein Kundenbuch, das verschiedene SIEM-Plattformen betreibt, konsistent, anpassbar und aus einer einzigen verwalteten Quelle berichtsfähig bleibt.
Ein MSSP, der die Erkennung für Dutzende von Mandanten betreibt, steht vor einer strukturellen Frage: Soll jeder Kunde seine eigene Abzweigung jeder Erkennungsregel erhalten, oder übersetzt und stimmt eine einzige verwaltete Quelle pro Mandant ab? Die Antwort bestimmt die Betriebskosten, die Genauigkeit der Abdeckungsberichte und ob eine Änderung der gemeinsamen Logik sofort verbreitet wird oder in einem Rückstand manueller Patches feststeckt.
Diese Seite deckt die Erkennungsinhalts-Ebene dieses Modells ab: eine Quelle von herstellerneutraler Erkennungslogik, die zentral verwaltet, übersetzt und pro Mandant abgestimmt wird. Hunters operiert auf der Ebene der Analyse und des Betriebs, eine SOC- und SIEM-Alternative für MSSPs und MDR-Anbieter. ContraForce operiert auf der Ebene des Fallmanagements und der Liefer-Workflows, ausgerichtet auf den Microsoft-Sicherheitsstack (Microsoft Sentinel und Defender XDR). Die hier beschriebene Quelle des Erkennungsinhalts befindet sich upstream und liefert die herstellerneutrale Erkennungslogik, die von den Schichten für Ausführung, Untersuchung und Berichterstattung verbraucht wird.
Umfang: SIEM-Plattformen (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike). EDR als Einsatzziel ist bis zur Bestätigung der pro Plattform Unterstützung nicht im Umfang.
Ein MSSP ist auch eine regulierte Einheit in eigener Hinsicht. Durchführungsverordnung (EU) 2024/2690, in Kraft seit dem 7. November 2024, legt Überwachungs- und Protokollanforderungen fest (Anhang Abschnitt 3.2) für Anbieter von Managed Security Services gemäß NIS2. Die eigene Nachweispflicht des MSSP, nicht nur die seiner Mandanten, treibt an, wie Erkennungsinhalte verwaltet und berichtet werden.
Wie kann ein Multi-Mandanten-SOC die Erkennungslogik in Kundenumgebungen konsistent halten, die unterschiedliche SIEM-Plattformen betreiben?
Schreiben Sie die Erkennungslogik einmal in einem herstellerneutralen Format (Sigma). Übersetzen Sie es pro SIEM des Mandanten. Verwalten Sie die Quelle zentral.
Das gemeinsame Grundartefakt
Die Basis ist ein einzelnes Erkennungslogik-Artefakt. Sein logischer Zustand wird gegen ein gemeinsames, normalisiertes Schema ausgewertet, anstatt gegen die Rohdatenfelder eines Mandanten. Dies macht dieselbe Regel ohne Neuschreibung der Erkennungslogik selbst portabel über Splunk, Microsoft Sentinel, Google SecOps, Elastic und CrowdStrike.
Normalisierung kartiert quellenspezifische Felder auf das gemeinsame Schema, während ihre Semantik erhalten bleibt. Eine Regel, die gegen das normalisierte Feld auth.result geschrieben ist, bedeutet dasselbe, unabhängig davon, welcher Identitätsanbieter das Ereignis erzeugt hat: auth.result löst sich auf {erfolgreich, fehlgeschlagen, Herausforderung} gemäß einem benannten semantischen Vertrag, nicht gemäß dem, was der IdP des Kunden das Feld nennt.
Das per-Mandanten-Overlay
Jeder Mandant erhält ein Overlay. Das Overlay trägt die Feldzuordnung, die die Rohquellenfelder des Mandanten in das gemeinsame normalisierte Schema übersetzt, und die Abstimmungsparameter (Schwellenwerte, Zeitfenster, Geräuschausschlüsse), die an die Umgebung des Mandanten angepasst sind. Basis und Overlay werden separat versioniert.
Eine Logikänderung in der Basis verbreitet sich an jeden Mandanten, dessen Overlay die erforderlichen Felder kartiert. Eine Abstimmungsänderung in einem Overlay eines Mandanten betrifft nur diesen Mandanten.
Gemeinsam vs. mandantenspezifisch
Was bleibt gemeinsam: der Erkennungslogik-Zustand, die Definitionen der semantischen Verträge, auf die die Logik angewiesen ist, das MITRE ATT&CK Technik-Tag, und die Versions- und Änderungshistorie.
Was ist mandantenspezifisch: die Zuordnung der Roh-zu-normalisierten Felder, der Status der Vertragserfüllung zur Laufzeit (Erfolg oder Fehlschlag, bewertet nach dem tatsächlichen Ereignisstrom des Mandanten, nicht eine statische Eigenschaft der Regel), Plattform-Ziel-Übersetzung und Abstimmungsparameter.
Wie verwaltet man Erkennungsinhalte über Dutzende von Kundenumgebungen, ohne sie pro Kunde zu verzweigen?
Ein verwaltetes Artefakt pro Erkennung, nicht ein Fork pro Kunde.
Das Verzweigen der Regeldatei pro Kunde bedeutet, unabhängige Kopien dessen zu pflegen, was ein verwaltetes Artefakt sein sollte. Eine Logikreparatur oder ein neues Update der Ausweichtechnik muss manuell auf jeden Fork erneut angewendet werden. Forks driften, und die einzige versionsgesteuerte Änderungshistorie verschwindet.
Wenn ein Prüfer oder ein Kunde fragt, wer diese Regel geändert hat, wann und warum, muss die Antwort auf eine Zeitlinie zurückverfolgt werden. Abweichende Kopien, die möglicherweise oder möglicherweise nicht denselben Fix widerspiegeln, lassen diese Frage unbeantwortbar. Das ist ein Versagen der Governance und der Änderungssteuerung und beeinträchtigt direkt die Beweiskette, auf die Prüfer angewiesen sind.
Das Modell der Basis-plus-Overlay hält ein regiertes Artefakt:
| Ebene | Beinhaltet | Umfang |
|---|---|---|
| Basis (gemeinsam) | Erkennungslogik-Zustand, Definitionen von semantischen/zeitlichen/Korrelationsverträgen, MITRE ATT&CK Technik-Tag, Versions- und Änderungshistorie | Alle Mandanten |
| Overlay (pro Mandant) | Roh-zu-normalisierte Feldzuordnung, Plattform-Ziel-Übersetzung, Schwellenwerte, Zeitfenster, Geräuschausschlüsse | Ein Mandant |
Eine Änderung der Basislogik verbreitet sich durch Konstruktion. Nur die Zuordnung und die Abstimmung bleiben lokal. Das ist Detection-as-Code Disziplin, angewendet auf Multi-Mandanten-Betrieb: Regeländerungen werden versioniert, geprüft und als Code-Artefakte nachverfolgt. Die Bereitstellungsautomatisierung überträgt die aktualisierte Basis an jeden Mandanten, dessen Overlay sie unterstützt.
Vertragsversionierung regiert die Basis. Änderungen müssen versioniert werden, und Änderung, die den Vertrag bricht, erfordern eine neue Vertrags-ID, sodass jeder Mandant einen versöhnlichen Aktualisierungspfad erhält, anstatt eines stillen Bruchs.
SOC Prime arbeitet mit MDRs zusammen, um Erkennungsingenieur-Operationen vom SIEM-Erkennungen bis zur Reduzierung des SIEM-Volumens mit Prime Detect zu gestalten.
Wie stimmen Sie pro Kunde ab, ohne die gemeinsame Regel zu brechen?
Stimmen Sie im Overlay ab. Die Basisregel bleibt fest.
Das Overlay trägt die mandantenspezifische Konfiguration in zwei Teilen.
Feldzuordnung. Die Quellprodukte jedes Mandanten benennen dieselbe Tatsache unterschiedlich im Rohprotokoll, sodass das Overlay diese Rohfelder in das gemeinsame normalisierte Schema übersetzt. Die Zuordnung muss unabhängig denselben semantischen Vertrag erfüllen, den jeder andere Mandant teilt.
Ein konkreter Fehler zeigt, warum dies wichtig ist. Das Overlay eines Mandanten ordnet das Ergebnis „MFA ausstehend“ seines Identitätsanbieters dem normalisierten Wert „Fehler“ anstelle von „Herausforderung“ zu. Die gemeinsame MFA-Umgehungserkennungslogik, die nach einer erfolgreichen Anmeldung ohne vorhergehende Herausforderung sucht, sieht nie einen „Herausforderungswer“ für diesen Mandanten. Jede erfolgreiche Anmeldung wird als Umgehung gekennzeichnet: ein massenhaftes Fehlalarm für diesen einen Mandanten, während für jeden anderen Mandanten, dessen Overlay den Enum korrekt abbildet, die identische Regel korrekt ist.
Die Regel hat sich nie geändert. Der Fehler liegt vollständig im Overlay, ein Overlay-Fehler, der als Regel-Fehler verkleidet ist.
Abstimmungsparameter. Zeitliche Toleranzen für die Korrelation verknüpfter Ereignisse, Timeout- und Kulanzzeitfenster für Authentifizierungssequenzen und Geräuschausschlüsse. Eine zu eng gesetzte Toleranz übersieht echte Korrelationen. Wenn sie zu lose gesetzt ist, verbindet sie nicht zugehörige Ereignisse. Diese Fenster können pro Mandant angepasst werden müssen, je nach dessen Uhrenabgleich und Latenzmerkmalen.
Der Erkennungslogik-Zustand der Basisregel, bewertet gegen normalisierte Felder, ändert sich nie für einen einzelnen Mandanten. Der Vertragsvalidierungsstatus muss pro Mandant zur Laufzeit ausgewertet werden, nicht vom Regel- oder Quellen-Typ angenommen werden.
Wie melde ich MITRE ATT&CK-Abdeckungserkennung für jeden Kunden, wenn jeder Kunde uns unterschiedliche Protokollquellen sendet?
Berechnen Sie die Abdeckung pro Mandant gegen den eigenen priorisierten Technikensatz dieses Mandanten. Melden Sie niemals eine Bibliotheksnummer über die Mandanten. Die vollständige Messmethode wird auf der Begleitseite zur Messung der MITRE ATT&CK-Abdeckungserkennung beschrieben.
Abdeckungsvorlage:
Abdeckung (Mandant) = Techniken, bei denen [Telemetrie gültig UND Regel bereitgestellt UND Regel nachweislich ausgelöst] geteilt durch die priorisierte Technikanzahl dieses Mandanten.
Wann eine Technik als abgedeckt gilt
Eine Technik zählt nur dann als abgedeckt, wenn alle diese Bedingungen gemeinsam erfüllt sind:
- Telemetrie gültig für diesen Mandanten. Die erforderliche Datenquelle wird gesammelt, aktiv eingespeist, besteht die semantischen, zeitlichen und Korrelationsverträge und erfüllt Qualität-SLOs (Null-Rate, Frische). All dies wird gegen den tatsächlichen Ereignisstrom dieses Mandanten bewertet, nicht gegen einen Standard des Quellentyps.
- Regel bereitgestellt und der Technik zugeordnet. Ein Detection-as-Code-Inventarisierungsfakt: Welche Regel existiert, welches MITRE ATT&CK-Tag sie trägt, ihre Version.
- Regel hat Beweis der Auslösung. Feuerraten-Baselining, Canary-Events oder atomare Testvalidierung, die zeigen, dass die Regel Alarme bei realer oder emulierter Aktivität auslöst. Ein Technik-Tag ohne Auslösungsnachweis ist ein Etikett, kein Beweis.
Der Nenner ist der eigene benannte, priorisierte Unterbestand von ATT&CK-Technikendes Mandanten, niemals die vollständige ATT&CK Matrix. Niemals die Regelbibliotheksgröße des Anbieters.
Melde Lückenstatus
Melden Sie Lückenstatus klar, niemals als eine zusammengefasste Zahl:
| Zustand | Bedeutung | Behebung |
|---|---|---|
| GÜLTIG | Alle Tore passieren, Regel bereitgestellt, ausgelöster Beweis in der Datei | Abgedeckt am Berichtsdatum |
| UNGÜLTIG | Erforderliche Quelle nicht gesammelt oder nicht eingespeist | Quellenaktivierung oder Einspeisungsreparatur |
| DEGRADIERT | Quelle gesammelt, aber Vertrag oder Qualitäts-SLO fehlerhaft | Zuordnung, Parser oder Schema-Fehler |
| Inhaltslücke | Telemetrie gültig, keine Regel auf Technik abgebildet | Inhaltsentwicklung |
Kollabieren Sie UNGÜLTIG und DEGRADIERT nicht in eine „Lücken“-Nummer. Unterschiedliche Fehlerzustände erfordern unterschiedliche Behebungen und führen zu unterschiedlichen Kundengesprächen.
Bericht mit einem Datum. Abdeckung ist zeitpunktbezogen.
Was bewirkt die Wiederverwendung von Inhalten für die Marge und die Analystenschulungslast?
Die Wiederverwendung von Inhalten über Mandanten hinweg wandelt per-Kunden-Kosten der Erkennungsingenieurarbeit in geteilte, amortisierte Kosten um. Wenn Basiserkennungslogik einmal erstellt und pro Mandant übersetzt wird, verteilt sich die Ingenieurkostenquote über das Kundenbuch.
Marge. Jeder Mandant, der die geteilte Basis betreibt, vermeidet zusätzliche Stunden der Erkennungsarbeit. Die Margenverbesserung ist strukturell. Das MDR-Partnerprogramm von SOC Prime schätzt die jährliche Einsparung auf 4.000 Stunden für Bedrohungsforschung und Erkennungscodierung.
Schulungslast. Eine Detection-as-Code-Methodik. Ein normalisiertes Schema. Ein Satz von Vertragssemantiken. Analysten steigen in das geteilte Modell ein, anstatt sich mit divergenten, namhaften und strukturierten Regelbibliotheken pro Kunde vertraut zu machen. Wenn ein Analyst von der Warteschlange eines Mandanten zu einer anderen wechselt, sind die Erkennungslogik, das Schema und die Verträge bereits vertraut.
Der ehrliche Einwand. Geteilter Erkennungsinhalt löscht nicht die Differenzierung eines MSSP. Die Differenzierung verlagert sich auf Abstimmung, Response und Berichterstattung. Mandantenspezifische Overlays, Antworthandbücher und kundenorientierte Berichterstattung zeigen den Wert des MSSP. Ein Interessent, der „geteilter Inhalt“ hört und an „Ware“ denkt, muss genau sehen, wo die kundenorientierte Arbeit lebt.
Regulatorischer Treiber. Die eigene Nachweispflicht des MSSP gemäß NIS2, über die Durchführungsverordnung (EU) 2024/2690, erfordert Überwachungs- und Protokollierungsevidenz vom MSSP selbst, nicht nur von seinen Mandanten. Das geteilte Modell amortisiert die Erzeugung dieser Nachweise.
Wo das nicht zutrifft
Das Modell der Basis-plus-Overlay setzt voraus, dass die Basisregel gegen ein normalisiertes Schema geschrieben ist, das das Quellprodukt jedes Mandanten erfüllen kann. Das Modell bricht unter folgenden Bedingungen zusammen.
- Quellprodukte, die erforderliche Daten nicht ausgeben. Unterschiedliche Quellprodukte oder verschiedene Versionen desselben Produkts geben möglicherweise überhaupt keine erforderliche Datenkomponente aus. Kein Overlay behebt ein strukturell fehlendes Feld. Dies ist eine UNGÜLTIGE Lücke, behoben durch Quellenaktivierung oder Upgrade.
- Quelleverfügbarkeit. Ein Mandant hat eine erforderliche Protokollquelle nicht eingebunden, oder sein Einzug ist dunkel geworden. Die Regel, Mapping und Abstimmung können alle korrekt sein, und die betroffenen Techniken bleiben unbedeckt, bis die Quelle wieder fließt.
- Korrelations-Toleranz-Mismatch. Die geteilte Standard-Zeittoleranz kann echte Korrelationen für einen Mandanten mit ungewöhnlichem Uhrenabgleich oder Latenz übersehen. Eine Abstimmung der Korrelationfenster pro Mandant ist erforderlich, nicht optional.
- Einzigartige Bedrohungsmodelle oder Datenresidenzbeschränkungen. Ein Mandant mit einem wirklich einzigartigen Bedrohungsprofil benötigt möglicherweise maßgeschneiderte Erkennungslogik, die die geteilte Basis nicht enthält. Eine Beschränkung, die das Teilen von Erkennungslogik-Artefakten über organisatorische Grenzen hinweg verbietet, hat denselben Effekt.
- Mandantenisolation ist nicht verhandelbar. Das Modell teilt ErkennungsLOGIK zwischen Mandanten (Regeltext, Vertragsdefinitionen). Es teilt niemals Mandantendaten, Anreicherungscaches, Alarmstatus oder Validierungsergebnisse über eine Mandantengrenze hinweg. Jede Architektur, in der die Anreicherungssuchen oder Alert-Warteschlange eines Mandanten in die eines anderen fließen, ist von Design her ein Vorfall der Priorität eins. Logikteilung und Datenteilung sind unterschiedliche Ansprüche.
Checkliste zum Betrieb im Multi-Mandanten-Modell
Erstellen und verwalten Sie die Basisregel
- Erkennungslogik in einem herstellerneutralen Format (Sigma) gegen ein normalisiertes, vertragsdefiniertes Schema verfasst
- Basisregel von Mandanten-Overlay getrennt: Erkennungslogik, Vertragsdefinitionen, MITRE ATT&CK-Tag und Versionsgeschichte bleiben geteilt
- Overlay pro Mandant trägt nur Feldmapping, Plattform-Übersetzung und Abstimmungsparameter, getrennt von der Basis versioniert
- Änderungen der Basisregel verbreiten sich durch Konstruktion an jeden Mandanten
- Änderungshistorie verfolgt sich auf eine regulierte Zeitlinie pro Basisregel, mit Overlay-Änderungen pro Mandant verfolgt
- Vertragsversionierung durchgesetzt: Änderungen, die den Vertrag brechen, tragen eine neue Vertrags-ID
Mapping und Plattformübersetzung validieren
- Feldmappings erfüllen denselben semantischen Vertrag pro Mandant, mit Vertragsvalidation zur Laufzeit gegen den tatsächlichen Ereignisstrom des Mandanten ausgeführt
- Plattformübersetzung pro Ziel-SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike) validiert
Abdeckung pro Mandant berechnen
- Abdeckung wird pro Mandant gegen den priorisierten ATT&CK-Technikensatz dieses Mandanten berechnet
- Abdeckungs-Zähler erfordert gültige Telemetrie, bereitgestellte Regel und nachweislich auslösende Regel, alle zusammen als wahr
- Lückenstatus unterschieden: GÜLTIG, UNGÜLTIG (Quelle fehlt), DEGRADIERT (Quelle vorhanden, Validierung fehlerhaft) und Inhaltslücke (Telemetrie gültig, keine Regel abgebildet)
Abstimmen, isolieren und berichten
- Korrelations-Zeittoleranzen pro Mandant auf Uhrenabgleich und Latenz-Anpassung überprüft
- Abstimmung im Overlay angepasst, niemals durch Abzweigen der Basisregel
- Mandantenisolation durchgesetzt: keine geteilten Daten, Anreicherungscache, Alarmstatus oder Validierungsergebnisse über Mandantengrenzen
- Abdeckung wird mit einem Datum gemeldet, pro Mandant, niemals als eine Bibliotheksnummer über das Buch
- Regulatorische Nachweispflicht des MSSP (NIS2 Durchführungsverordnung 2024/2690) neben den Verpflichtungen der Mandanten adressiert
- Analystentraining auf die gemeinsame Detection-as-Code-Methodologie, das normalisierte Schema und die Vertragssemantik abgestimmt
FAQ
Wie kann ein Multi-Mandanten-SOC die Erkennungslogik in Kundenumgebungen konsistent halten, die unterschiedliche SIEM-Plattformen betreiben?
Schreiben Sie die Erkennungslogik einmal in Sigma, einem herstellerneutralen Format, und übersetzen Sie sie pro SIEM des Mandanten. Ein Basis-plus-Overlay-Modell hält die geteilte Erkennungslogik und die MITRE ATT&CK-Technikzuordnung in einem verwalteten Artefakt, während das Overlay jedes Mandanten die Feldzuordnung, Plattformübersetzung und Abstimmungsparameter für diese Umgebung trägt. Das gilt für SIEM-Plattformen (Splunk, Microsoft Sentinel, Google SecOps, Elastic, CrowdStrike). EDR als Einsatzziel ist bis zur Bestätigung der Plattformunterstützung nicht im Umfang.
Wie melde ich MITRE ATT&CK-Abdeckungserkennung für jeden Kunden, wenn jeder Kunde uns unterschiedliche Protokollquellen sendet?
Berechnen Sie die Abdeckung pro Mandant gegen den eigenen priorisierten ATT&CK-Technikensatz dieses Mandanten, niemals als eine Bibliotheksnummer über das Buch. Eine Technik zählt nur dann als abgedeckt, wenn die Telemetrie für diesen Mandanten gültig ist, eine Regel bereitgestellt und der Technik zugeordnet ist und die Regel einen Auslösungsnachweis hat. Melden Sie vier unterschiedliche Lückenstatus: GÜLTIG, UNGÜLTIG (Quelle fehlt), DEGRADIERT (Quelle gesammelt, Validierung fehlerhaft) und Inhaltslücke (Telemetrie gültig, keine Regel abgebildet). Jeder Abdeckungsbericht trägt ein Datum.
Löscht geteilte Erkennungsinhalte die Differenzierung eines MSSP aus?
Geteilter Erkennungsinhalt verlagert, wo die Differenzierung stattfindet. Der spezifische Wert des MSSP verschiebt sich auf mandantenspezifische Abstimmung, Antworthandbücher und kundenorientierte Abdeckungsberichte. Mandantenoverlays, Antwortspielbücher und pro Mandant Abdeckungsanalysen zeigen dem Kunden die Expertise des MSSP.
