Co-Managed SIEM: Wer macht was, und was im Vertrag stehen sollte

Zwischen „wir bauen alles selbst“ und „wir geben alles ab“ liegt das Modell, das für die meisten Unternehmen tatsächlich funktioniert: Co-Managed SIEM. Die Plattform gehört Ihnen, der Betrieb und die Erkennungsarbeit liegen beim Dienstleister.

Das Problem am Begriff: Er beschreibt eine Aufgabenteilung und genau die steht in Angeboten selten konkret drin. Dieser Artikel schreibt sie auf, so wie wir sie in unseren Engagements tatsächlich handhaben.

Die Lizenzfrage: Wem gehört die Plattform?

Das ist die erste Weiche, und sie hat Konsequenzen weit über den Preis hinaus.

Bei uns kauft der Kunde die Subscription selbst. Wir arbeiten über einen MSSP-Tenant, aus dem heraus wir den Kunden-Tenant managen. Der Kunde behält dabei durchgehend eigenständigen Zugriff. Er sieht dieselben Daten, dieselben Regeln, dieselben Alarme, und er kommt auch ohne uns an alles heran.

Warum das wichtig ist, merkt man erst an drei Stellen:

• Beim Ausstieg. Wenn der Dienstleister die Lizenz hält, endet mit dem Vertrag auch der Zugang zur Plattform und häufig zu den historischen Logdaten darin. Wer die Subscription selbst besitzt, wechselt den Dienstleister, nicht das System.
• Bei eigenen Untersuchungen. Ihr Team muss nicht warten, bis jemand ein Ticket bearbeitet, um in die Rohdaten zu sehen.
• Bei Nachweispflichten. Aufsicht und Wirtschaftsprüfer fragen nach Daten, nicht nach Berichten über Daten. Direkter Zugriff ist die einfachste Antwort.

Das Gegenmodell (Dienstleister besitzt Lizenz, Tenant und Daten) ist nicht per se falsch, aber es ist eine Abhängigkeit, die man bewusst eingehen sollte statt versehentlich. Die Prüffrage lautet: Was genau haben wir am Tag nach Vertragsende noch in der Hand?

Wer schreibt die Detection-Regeln?

Wir. Und in der Regel ohne einen dedizierten Freigabeprozess auf Kundenseite. Wir entscheiden nach fachlichem Ermessen, welche Regel scharf geschaltet, angepasst oder wieder entfernt wird.

Das klingt zunächst nach weniger Kontrolle. In der Praxis ist es der Grund, warum das Modell überhaupt schneller ist als der Eigenbau: Eine Detection-Regel, die vier Wochen auf ein Change-Advisory-Board wartet, hat vier Wochen lang nichts erkannt. Erkennungsarbeit ist ein kontinuierlicher Zyklus aus Schreiben, Beobachten, Nachschärfen und Verwerfen: mit einem Freigabegremium in jedem Schritt kommt dieser Zyklus zum Erliegen.

Was an die Stelle der Freigabe tritt, ist Transparenz: Sie sehen die Regeln in Ihrer eigenen Plattform. Wenn Sie eine davon anders wollen, ist das ein Gespräch, kein Formular.

Wie ein Alarm bei Ihnen ankommt

Hier entscheidet sich, ob ein SOC-Service im Ernstfall funktioniert. Zwei Dinge müssen vorher definiert sein, nicht während des Vorfalls.

Priorisierung: Severity mal Confidence

Wir bewerten jeden Befund auf zwei Achsen:

• Severity: wie schwerwiegend wäre es, wenn der Befund zutrifft?
• Confidence: wie sicher sind wir, dass er zutrifft?

Aus der Kombination ergibt sich die Priorität P1, P2 oder P3. Der Unterschied ist praktisch relevant: Ein hochkritischer Befund mit schwacher Konfidenz ist etwas anderes als ein bestätigter Befund mittlerer Schwere und beide verdienen eine andere Behandlung als ein Alarm, der beides ist.

Diese Trennung ist der Grund, warum Sie um drei Uhr nachts nicht für jeden theoretisch kritischen Treffer angerufen werden.

Die Kommunikationsmatrix

Vor dem Go-live legen wir mit Ihnen eine Kommunikationsmatrix fest: Welche Priorität geht über welchen Kanal an wen, in welcher Reihenfolge, mit welcher Ausweichoption. In der Regel sind das Mail und Telefon: Mail für alles, was dokumentiert werden muss, Telefon für alles, was nicht warten kann.

Das ist unspektakulär und genau deshalb wichtig. Der häufigste Grund, warum ein verifizierter kritischer Alarm ins Leere läuft, ist nicht fehlende Erkennung. Es ist eine Telefonnummer, die seit dem letzten Rollenwechsel niemand aktualisiert hat.

Was Sie selbst liefern müssen

Co-Managed heißt: Es bleiben Pflichten bei Ihnen. Zwei davon sind nicht verhandelbar.

Erreichbarkeit. Ein P1-Alarm braucht auf Ihrer Seite jemanden, der ihn annimmt und entscheiden darf. Wer diese Rolle besetzt und wie die Vertretung geregelt ist, gehört in die Kommunikationsmatrix, nicht in die Köpfe einzelner Personen.

Meldung von Veränderungen. Neue Systeme, geänderte Netzsegmente, migrierte Workloads, ein zusätzlicher Cloud-Dienst: Alles, was den Scope berührt, muss uns erreichen, damit wir die Logquellen mit aufnehmen können.

Der zweite Punkt wird regelmäßig unterschätzt. Der gefährlichste blinde Fleck eines SIEM ist nicht die Quelle, die schlecht konfiguriert ist. Es ist die Quelle, von der niemand erzählt hat. Ein Server, der seit drei Monaten produktiv läuft und in keiner Ingestion-Konfiguration auftaucht, erzeugt keine Alarme. Er erzeugt auch keine Fehlermeldung. Er ist einfach unsichtbar, und das fällt erst auf, wenn er kompromittiert ist.

Wie lange das Onboarding dauert

Wenige Wochen bis zum produktiven Betrieb: deutlich schneller als der Aufbau einer eigenen Plattform, weil Deployment, Quellenanbindung und die initiale Regelbibliothek eingespielte Arbeit sind und nicht bei null beginnen.

Realistisch bleibt danach eine Tuning-Phase. Die ersten Wochen im Echtbetrieb produzieren immer Befunde, die in der Theorie sinnvoll waren und in Ihrer konkreten Umgebung Rauschen sind. Das ist kein Mangel, sondern der Teil der Arbeit, der sich nicht vorab erledigen lässt.

Was „mediane Reaktionszeit unter einer Stunde“ tatsächlich misst

Wir nennen diese Kennzahl auf unserer Managed SIEM / SOC-Seite, deshalb hier präzise, was sie bedeutet und was nicht.

Gemessen wird vom Alarm bis zur ersten Analystenaktion. Also: Wie lange dauert es im Median, bis ein Mensch den Befund tatsächlich in die Hand nimmt?

Was die Zahl nicht aussagt: dass ein Vorfall binnen einer Stunde eingedämmt ist. Wie lange Eindämmung dauert, hängt vom Vorfall ab, von der betroffenen Infrastruktur und von Entscheidungen, die auf Ihrer Seite fallen. Jede Kennzahl, die pauschal eine Eindämmungszeit verspricht, sollten Sie hinterfragen.

Wir veröffentlichen bewusst die Übernahmezeit, weil sie das misst, was der Dienstleister allein in der Hand hat. Fragen Sie Anbieter im Vergleich immer nach den Messpunkten: „unter einer Stunde“ bedeutet ohne Anfangs- und Endpunkt gar nichts.

Was die Wahl zwischen einer Cloud-Plattform und einer Installation im eigenen Rechenzentrum konkret bedeutet, steht in Cloud SIEM vs. On-Premises.

Wann Co-Managed nicht das richtige Modell ist

• Wenn keine Plattform existiert und keine gewollt ist. Wer bewusst gar keine eigene SIEM-Subscription halten will, ist mit einem vollständig ausgelagerten Modell besser bedient.
• Wenn intern niemand ansprechbar ist. Das Modell setzt eine Gegenstelle voraus. Ohne benannte, erreichbare Rolle läuft auch der beste P1-Alarm ins Leere.
• Wenn Sie ein eigenes 24/7-SOC halten können. Dann brauchen Sie höchstens punktuelle Unterstützung, kein Co-Management.

Wie sich Technologie, Funktion und Liefermodell grundsätzlich zueinander verhalten, haben wir in SIEM, SOC, MDR aufgeschlüsselt.

Fazit

Co-Managed SIEM funktioniert, wenn die Trennlinie explizit ist. Kurzfassung unserer:

Was in einem Angebot fehlt, ist am Ende wichtiger als das, was drinsteht. Fragen Sie nach Lizenzeigentum, Datenzugriff nach Vertragsende, Regelhoheit, Priorisierungslogik und den Messpunkten hinter jeder Zeitangabe. Wer diese fünf Punkte klar beantwortet, hat ein Betriebsmodell. Wer ausweicht, verkauft ein Dashboard.