SOC als Service: Warum kein Angebot dem anderen gleicht

Es ist Sonntag, 03:12 Uhr, als beim IT-Leiter das Telefon klingelt. Er steht im Playbook als Kontaktperson. Der Security-Dienstleister meldet verdächtige Verschlüsselungsaktivität auf einem Steuerungsrechner der Fertigung und erwartet, dass der Host sofort isoliert wird. Nur: Der Dienst alarmiert, eingreifen muss der Kunde. Und eine Pikett-Organisation, die das nachts übernimmt, gibt es nicht. Drei Dinge fallen dem IT-Leiter auf. Der zugesagte 24/7-Service bedeutet Alarmierung, nicht Eingriff. Die eigentliche Arbeit bleibt bei ihm. Die Isolation dieses Hosts würde in diesem Fall zudem die Fertigungslinie stoppen. Das kostet Zehntausende Franken pro Stunde, und diese Entscheidung darf er nicht allein treffen. Und ob der Anrufer wirklich sein Dienstleister ist, kann er im Stress nicht sicher sagen. Keine dieser Fragen ist rein technisch, und alle drei entscheiden sich nicht in der Nacht, sondern bei der Wahl des Services. Genau dort werden sie aber selten gestellt.

Ein eigenes SOC braucht gute Gründe

Ein Security Operations Center (SOC) hält rund um die Uhr ein Auge auf die eigene IT. Es erkennt Angriffe früh, ordnet sie ein und stösst die Reaktion an, bevor aus einem Alarm ein Schaden wird. Dass diese Überwachung zunehmend als Service bezogen wird, hat einen einfachen Grund: Angreifer breiten sich nach dem Erstzugriff oft innert Minuten im Netz aus; viele beobachtete Vorfälle kommen ohne klassische Schadsoftware aus und missbrauchen legitime Zugänge und Werkzeuge. Laut dem Bundesamt für Sicherheit in der Informationstechnik (BSI) verschärft sich damit eine Asymmetrie. Angreifer profitieren sofort von Automatisierung und Künstlicher Intelligenz (KI), während Verteidiger an Freigabeprozesse und Wartungsfenster gebunden und durch begrenztes Personal eingeschränkt sind.


Ein eigenes Team rund um die Uhr zu betreiben, ist ein grosser Budgetposten und scheitert bei vielen Unternehmen nicht nur am Geld, sondern ebenso an Personal, aktuellem Know-how und ausreichender Fallpraxis. Ein eigenes SOC gehört für die meisten Betriebe darüber hinaus nicht zu ihrem Kerngeschäft. Externe Anbieter bringen hier Skaleneffekte und Erfahrung aus vielen Umgebungen ein, also Angriffsmuster, die einem einzelnen Betrieb nie begegnen. Das macht den Bezug als Service für viele attraktiv.

Vom Geschäftsprozess zum Sicherheitsdispositiv

Bevor man Angebote vergleicht, braucht es aber eine ehrliche Bestandsaufnahme. Welche Geschäftsabläufe sind kritisch? Und wie nutzen die Menschen im Betrieb die IT wirklich? Daraus ergibt sich eine Vorlage, welche Erkennungs-Disziplinen man überhaupt abdecken muss. Denn Sicherheit hat viele Blickwinkel, und jede Disziplin deckt einen anderen Angriffsweg ab. Wer stark in der Cloud und über mobile Identitäten arbeitet, kommt an Identity Threat Detection and Response (ITDR) und Cloud-Überwachung nicht vorbei; wer ein weitreichendes Netzwerk betreibt, braucht Network Detection and Response (NDR); wer Produktions- oder IoT-Geräte (Internet of Things) im Einsatz hat, muss deren Angriffswege mitdenken. Klassische Endpoint-Sensoren sehen diese oft gar nicht. Jede Disziplin für sich hat einen blinden Fleck; erst im richtigen Zusammenspiel entsteht ein breiteres und belastbareres Lagebild.


Diese Einstufung, welche Systeme und Abläufe kritisch sind, ist Aufgabe des Unternehmens. Der IT-Grundschutz des BSI (Schutzbedarfsfeststellung), ISO/IEC 27005 und das NIST Cybersecurity Framework (ID.AM-05) verlangen übereinstimmend, Werte und Geschäftsleistungen nach Kritikalität, Schutzbedarf und Business Impact einzustufen. Der Dienstleister kann diese Bewertung unterstützen. Die geschäftliche Einordnung und die Akzeptanz des Restrisikos müssen aber aus dem eigenen Unternehmen kommen. Alles auf einmal muss dabei niemand abdecken. Ein stufenweiser Aufbau schützt aber früh und lässt den Dienstleister Prozesse und Strukturen im kleinen Rahmen kennenlernen, bevor man diese ausweitet. Ein häufiger Einstieg sind EDR und ITDR. Welche Reihenfolge sinnvoll ist, bestimmt aber die eigene Angriffsfläche. Wichtig ist vor allem, überhaupt zu starten.

So werden zwei SOCs vergleichbar

Auf dem Tisch liegen zwei Angebote für Managed Detection and Response (MDR). Im Text steht «SOC als Service» als Oberbegriff, die konkret verglichenen Leistungen sind meist MDR oder ein Managed SOC (verwandt, aber nicht dasselbe). Beide versprechen «Managed SOC, 24/7, alles inklusive», beide Angebote kosten etwa gleich viel – und beide meinen etwas völlig anderes. Anhand des Deckblatts lässt sich das nicht vergleichen. Was im Ernstfall zählt, steht nicht in der Offerte. Man muss gezielt danach fragen, und die Antworten einordnen können. Beides fehlt in der Praxis oft. Man fragt nicht nach, oder es fehlt das Wissen, um die Antwort zu bewerten. Und so vergleicht man am Ende Äpfel mit Birnen. Genau hier setzt ein Raster an. Es liefert die richtigen Fragen und einen Massstab, um sie zu deuten. Vergleichbar werden die Angebote auf zwei Ebenen: die Technologie dahinter und, viel wichtiger, der Dienstleister davor.

Die Technologie: Abdeckung, Qualität, Aufbewahrung

Die Technologie ist der besser messbare Aspekt. Drei Fragen strukturieren den Vergleich: Was deckt der Stack ab? Wie gut und aktuell erkennt er Bedrohungen? Und wie weit reicht der Blick zurück? Und weil kaum ein Betrieb mit einem einzigen Werkzeug auskommt, sondern mehrere kombiniert, lautet die entscheidende Frage: Welche Angriffswege sind am Ende wirklich abgedeckt, und in welchem Bereich (Cloud, Endpoint, Netzwerk, Identität und Operational Technology, OT)?

Wo hat der Stack blinde Flecken? «Wir haben XDR» klingt nach Rundumsicht, deckt aber nicht jeden Angriffsweg ab. Angriffe auf Identitäten erkennen viele XDR-Stacks gar nicht oder nur über ein zusätzliches Modul (ITDR).


Halten Stack und SOC mit den Angreifern Schritt? Eine Erkennung ist nur so gut wie ihr Nachschub. Der Stack muss laufend mit neuem Wissen über Angriffswege und Schwachstellen versorgt werden, sonst erkennt er nur die Angriffsmuster von gestern. Und weil sich die Technologie-Stacks laufend weiterentwickeln, heisst SOC-Betrieb nicht nur, bekannte Muster zu suchen, sondern neue zu erkennen und neue Technologien zu beherrschen. Das ist eine Leistung der ganzen SOC-Organisation, nicht eines einzelnen Analysten.

Und auch der Markt bewegt sich. Grosse Sicherheitsanbieter kaufen Firmen zu und schliessen Partnerschaften, der Funktionsumfang eines Stacks verschiebt sich binnen Monaten. Eine Einschätzung von vor einem Jahr ist womöglich überholt. Prüfen Sie den aktuellen Stand, nicht den jeweiligen Ruf. Die Detektionsqualität selbst zu beurteilen, ist schwierig: Analystenberichte (Gartner, Forrester etc.) geben Orientierung zu Marktposition und Produktreife, MITRE-ATT&CK-Evaluationen zeigen, wie ausgewählte Angriffstechniken in einem definierten Testszenario erkannt werden. Die Prüfung gegen die eigene Umgebung und die benötigten Use Cases ersetzt aber keines dieser Instrumente.

Wie weit reicht der Blick zurück? Manche Werkzeuge speichern Logs nur wenige Tage. Bei langfristig angelegten Angriffen kann der relevante Erstzugriff aber Monate zurückliegen (Mandiant weist für Cyberespionage einen Median von 122 Tagen aus). Wer nur eine Woche zurückblickt, sieht den tatsächlichen Startpunkt somit nicht. Für regulierte Umgebungen gelten zusätzliche Vorgaben: PCI DSS, der Sicherheitsstandard für die Verarbeitung von Kreditkartendaten, verlangt für Audit-Protokolle mindestens zwölf Monate Aufbewahrung, davon drei Monate mit unmittelbarer Verfügbarkeit.

Wie sich zwei SOC-Anbieter wirklich unterscheiden

Zwei SOCs mit derselben Technologie können sich dennoch wie Tag und Nacht unterscheiden. Denn ein SOC ist kein Produkt, sondern besteht aus Menschen, Prozessen und der Frage, ob am Ende jemand handelt. Sieben Fragen machen Unterschiede sichtbar.

Senior oder Junior: Wer stuft die tiefen und mittleren Alarme richtig ein? Entscheidend ist nicht die Zahl der Analysten, sondern wer die Alarme zuerst sichtet. Das gilt gerade für die unscheinbaren tiefen und mittleren Alarme, die je nach Betriebsmodell zunächst meist von weniger erfahrenen Analysten beurteilt werden. Genau dort trennt sich Routine von Erfahrung. Klären Sie die Eskalationslogik: Ab wann wird ein Senior beigezogen, und wie wird das belegt? Lassen Sie sich die Nachtbesetzung mit Senioritätsstufe zeigen.


Wie bestimmt der Dienstleister, was kritisch ist? Nach nachvollziehbarer, regelbasierter Methodik oder nach Bauchgefühl? Die Definition der Schweregrade sollte zwischen Ihnen, Plattform und Anbieter abgestimmt sein, damit Eskalation, die Messung des Service-Level-Agreements (SLA) und die Kosten nicht durch unterschiedliche Kritikalitätslogiken verzerrt werden.

Zugesicherte oder tatsächlich erbrachte Service-Levels? Verlangen Sie die gemessenen Reaktionszeiten je Kategorie (Critical bis Low), nicht die zugesagten (als Median und SLA-Einhaltungsquote, nicht als Durchschnitt, der schlechte Einzelfälle verschleiert), und definieren Sie, von welchem Ereignis bis zu welcher Handlung gemessen wird. Bestätigung, qualifizierte Einschätzung, Benachrichtigung und Eindämmung sind vier verschiedene Dinge, die in der Praxis aber kaum einzeln erfasst werden. Gerade deshalb sollten Sie festlegen, welche Grösse für Sie zählt. Klären Sie zugleich, ob nachts überhaupt jemand in der vertraglich vereinbarten Sprache abnimmt.

Reporting: Rohdaten aus dem Stack oder eine qualifizierte Aussage? Ein Dash­board-Auszug ist noch kein Bericht. Wertvoll wird das Reporting erst, wenn ein Analyst einordnet, was die Zahlen für Ihren Betrieb bedeuten: welche Risiken sich abzeichnen, was zu tun ist und wie sich die Lage über die Zeit entwickelt. Verlangen Sie ein Muster-Reporting und prüfen Sie, ob es Einordnung, Handlungsempfehlungen und Trends enthält, oder nur weiterreicht, was der Stack ohnehin anzeigt.

Wie tief greift der Dienst im Ernstfall ein? «Wir informieren Sie umgehend» heisst im Klartext: Sie machen die Arbeit. Wie tief ein Dienst eingreift, ist eine Vertragswahl (Kasten), und wer im Ernstfall was tut, gehört Schritt für Schritt geklärt (Abbildung).

Reicht die Anbindung für den Eingriff oder bleibt es beim Melden? Aktiv handeln kann ein SOC nur, wenn ein technisch und organisatorisch autorisierter Zugriff auf die relevanten Systeme besteht, etwa über die angebundene Plattform, eine SOAR-Automatisierung oder definierte administrative Schnittstellen. Fehlt ein solcher Zugriff, kann der Dienst zwar warnen, aber nicht selbst eindämmen. Dann muss jemand bei Ihnen eingreifen, und im Ernstfall zählt jede Minute. Automatisierung heisst dabei nicht, dass nicht mehr gemeldet wird: Ein guter Dienst greift ein und informiert Sie zugleich.

Wie gewinnen IT-Leiter und Chief Information Security Officer (CISO) Budget-Sicherheit? Indem sie wissen, was nicht im Preis steckt: Log-Anbindung, echte Response, alles ausserhalb des Scopes. Hier verstecken sich die Rechnungen von morgen. Man plant ein Budget, und gerade die nicht abgedeckten Posten überziehen es später womöglich. Wer sie vorab benennt, kann sie einpreisen und verhandeln, statt im Ernstfall vor vollendeten Tatsachen zu stehen. Ein praktischer Hebel ist ein vertraglich vereinbarter Stundenpool für ausserplanmässige Leistungen, von Beginn an im Budget berücksichtigt. So bleibt der Aufwand planbar, und es muss später kein zusätzliches Budget beantragt werden.

Den Preis vergleichbar machen

Auch beim Preis steckt der Unterschied im Detail. Ein Anbieter rechnet pro Datenvolumen (etwa GB pro Tag, roh oder komprimiert), der nächste pro Endpunkt, der dritte pro Nutzer, der vierte pauschal. Schon die Einheiten passen nicht zusammen. Vergleichbar wird der Preis erst, wenn man für alle Angebote dieselbe Rechnung aufmacht: Anbindung der Log-Quellen, Incident Response (inbegriffen, teilweise inbegriffen, oder selbst zu stemmen?) und alles ausserhalb des Scopes. Genau dort, in den nicht abgedeckten Punkten, entsteht im Ernstfall die teuerste Rechnung.

Und auch bei der Response lohnt ein genauer Blick: Ein umfassender Response-Scope bindet Aufwand, der sich vorab schwer beziffern lässt, und muss deshalb wirtschaftlich im Preis abgebildet sein. Klären Sie darum, welche Szenarien, Stundenkontingente, Obergrenzen und Ausschlüsse hinter «alles inklusive» stehen, damit klar ist, was der Preis wirklich abdeckt.


Gehen zwei Preise weit auseinander, liegt der Unterschied meist im Detail. Der Preis hat zwei Schichten: die Technologie (Lizenzen) und den Service (SOC-Betrieb). Was ein Anbieter breiter abdeckt, aktueller erkennt und länger aufbewahrt, wie tief er als Service eingreift, schlägt auf beide Schichten durch. Auch die Lizenzen kosten nicht überall gleich viel. Je nach Partnerstatus und Abnahmevolumen des SOC-Anbieters beim Hersteller unterscheiden sich die Konditionen. Die Beziehung des Anbieters zum Technologie-Hersteller ist also nicht nur eine Qualitäts-, sondern auch eine Preisfrage. Daneben spielen Personalmodell, Vertragsrisiko und Leistungsort mit.

Dazu kommt der Posten, den keine Offerte ausweisen kann: Auch mit einem Dienstleister bleiben interne Kapazitäten erforderlich, etwa für Steuerung, Risk Ownership, Architektur, Eskalationen und interne Kommunikation, dazu je nach Fall Personen vor Ort für Handgriffe, die ein Remote-SOC nicht leisten kann. Das ist der Retained-Block, also die Aufgaben, die der Betrieb bewusst intern stemmt. Ihr Umfang hängt von Grösse, Regulatorik, Scope und Service-Tiefe ab. Wer die günstigste Offerte gegen die eigene Lizenzrechnung stellt und diesen Block vergisst, riskiert einen teuren Fehlentscheid. Auch die Anlaufphase kostet. In den ersten Wochen muss der Dienst das normale Rauschen Ihres Netzwerks erst lernen (Baselining). Klären Sie, wer den Tuning-Aufwand der Fehlalarme trägt.

Ist der Entscheid für den externen Bezug grundsätzlich gefallen, ist die nächste ehrliche Frage nicht die nach dem günstigsten Anbieter, sondern die nach dem passenden Provider zum vollen Gesamtpreis. Gerechnet wird über die ganze Vertragslaufzeit (oft drei Jahre), damit einmalige Posten wie Onboarding, Baselining und Integration nicht ein einzelnes Jahr verzerren. Gemessen wird der Erfolg am Ende nicht am Ticket-Tempo, sondern an den tatsächlichen Zeiten bis zur Erkennung, qualifizierten Beurteilung, Benachrichtigung, Eindämmung und Wiederherstellung, dazu an der Alarmqualität und am internen Aufwand für die Übergaben. Das sind operative Steuerungsgrössen.

Entscheidend ist zudem, ob der Dienstleister mitwächst. Nichts bleibt statisch. Neue Angriffswege, neue Use Cases, veränderte Geschäftsprozesse verlangen einen Anbieter, der sich weiterentwickelt, statt beim Stand des Vertragsabschlusses zu verharren. Das Board will davon keine Details, sondern Antworten auf drei Fragen: Sind wir im Visier, und wie exponiert? Können wir im Ernstfall reagieren? Und müssen wir etwas entscheiden oder anpassen: mehr investieren, ein Restrisiko bewusst tragen, eine Lücke schliessen?

Wer entscheidet, wenn es ernst wird?

So gut man vergleicht und wen man auch wählt, kein Vertrag verschiebt eine Grenze. Der Provider kann erkennen, einordnen und in definierten Grenzen handeln. Ob aber eine Produktionslinie stoppt und welches Restrisiko wegen fehlender Budgets bleibt, ist eine Geschäftsentscheidung. Entscheidungs-, Eskalations- und Freigaberollen für Notfallmassnahmen sollte man deshalb vorab definieren.

Wird eine priorisierte Massnahme zudem nicht finanziert, braucht es ebenfalls einen dokumentierten Entscheid: welche Lücke, welcher Impact (potenzieller Tagesverlust), welche Kosten, wer akzeptiert das Restrisiko. Das macht die Verantwortung teilbar, statt sie zur stillen Last des IT-Leiters zu machen. Dieselbe Abwägung beginnt schon bei der Auswahl. Ein niedrigerer Preis kann auf einen engeren Scope oder weniger Service-Tiefe zurückgehen. Bleibt dadurch ein wichtiger Angriffsweg unüberwacht, kostet ein einziger Vorfall rasch ein Vielfaches der Ersparnis.


Die Auslagerung entbindet Verwaltungsrat und Geschäftsleitung zudem nicht von ihren Leitungs- und Oberaufsichtspflichten. Ob im Einzelfall eine persönliche Haftung entsteht, hängt von den konkreten Umständen ab. Die Oberaufsicht über die Risiken zählt zu den unübertragbaren Aufgaben des Verwaltungsrats (OR 716a), bei pflichtwidriger und schuldhafter Verletzung der Sorgfalts- oder Aufsichtspflichten kann eine persönliche Haftung der Organe entstehen (OR 754).

Den potenziellen Tagesverlust beziffert man grob über den Wert der betroffenen Geschäftsleistung pro Ausfalltag: Trägt sie beispielsweise 200’000 Franken Deckungsbeitrag pro Tag bei (oder verursacht ein Ausfall Kosten in dieser Grössenordnung), ist das eine erste wirtschaftliche Vergleichsgrösse, gegen die man Massnahmenkosten und akzeptiertes Restrisiko abwägt (hinzu kommen Wiederherstellungskosten, Vertragsfolgen, Reputationsschäden).

Auslagern verschiebt das Risiko, beseitigt es aber nicht

Wer eine Fähigkeit abgibt, holt sich neue Anforderungen ins Haus: Anbieter-Abhängigkeit, Aufwand für einen sauberen Ausstieg, Konzentrationsrisiko und die Frage, wie viel eigenes Wissen man abgibt. Den oft zitierten Daten-Lock-in kann man dabei relativieren. Rohdaten lassen sich häufig in Standardformaten (JSON, Syslog) exportieren. Zu prüfen sind aber Umfang, Kosten, Geschwindigkeit und die Frage, ob auch Fallhistorie, Kontext, Detektionsregeln und Playbooks übertragbar sind. Der kritische Lock-in ist nicht das JSON, sondern das aufgebaute Wissen. Wer die massgeschneiderten Detektionsregeln und Playbooks beim Wechsel verliert, beginnt beim nächsten Anbieter wieder bei null.


Ein guter Service muss zudem echten Mehrwert schaffen. Er macht Fähigkeiten dauerhaft verfügbar, die intern kaum rund um die Uhr bereitstehen. Das ist keine Kapitulation, sondern eine Arbeitsteilung, die man steuert. Dazu behält der Kunde Einblick, je nach Betriebs- und Lizenzmodell über direkten Zugang zum Tenant der Technologie oder über vertraglich geregelte Einsichts-, Export- und Auditrechte. Und es ist klar geregelt, wer Änderungen vornimmt, Kunde oder SOC.

Mit Struktur vergleichen

Ein SOC ist kein Produkt aus dem Regal. Zwei Angebote können identisch klingen, im Ernstfall aber Welten auseinanderliegen. Wer mit Struktur an die Sache geht, vergleicht Gleiches mit Gleichem und wählt nicht das billigste, sondern das passende Angebot. Dann entscheidet sich der Anruf um 03:12 Uhr nicht erst in der Nacht, sondern ist längst vorbereitet. Es ist geregelt, wer den betroffenen Host nachts wirklich isoliert, wer den Produktionsstopp freigibt, und dass der Kanal, über den gewarnt wird, verifiziert ist. Keine dieser drei Fragen beantwortet die Detection-Technologie allein. Und alle drei entscheiden sich bei der Wahl des Services, nicht im Ernstfall.