Security Operation Center SOC Strategie: Make or Buy?

/Blog
Erstellt von Oliver Locher

Der Aufbau eines Security Operation Center ist für viele Unternehmen ein wesentlicher Schritt, das Gesamtgebilde, einzelne Abteilungen oder bestimmte Geschäftsprozesse abzusichern und Transparenz zu schaffen. Die wesentlichen Anforderungen an das SOC, seine Stellung, die Aufgaben und alle Einflussfaktoren müssen sorgsam beschrieben und definiert werden. Darauf aufbauend sind die Erwartungen an das SOC (Mission) und seine gewünschte Entwicklung (Vision) herauszuarbeiten. Schliesslich ist die wichtige Entscheidung zu treffen, entweder das SOC selbst aufzubauen und intern zu betreiben (Make), oder die Dienste zum Teil oder ganz bei einem geeigneten Provider zuzukaufen (Buy). Einiges spricht dafür, mit einer Buy-Strategie zu beginnen. Sie entschärft wesentliche Problemstellen wie Mitarbeiterrekrutierung, insbesondere im Bereich der Analysten, den Zeitdruck und die Installierung geeigneter Technologien und Prozesse. Dabei bleibt die Möglichkeit, zu gegebener Zeit einen sanften Übergang zum Eigenbetrieb zu gewährleisten. Sowohl der Aufbau als auch der Betrieb eines SOC sind sich immer wieder wandelnder Prozess. Was heute Standard ist, muss ständig überprüft werden.

Angesichts vielfältiger und zunehmender Bedrohungen, z. B. durch Advanced Persistent Threats, sind viele Firmen gezwungen, ihr Unternehmen und ihre Geschäftsprozesse über ein Security Operation Center (SOC) abzusichern. Eine wichtige Entscheidung ist zu treffen: Wird das SOC intern betrieben (Make), oder ist es besser, es als Outsourcing Komponente bei einem vertrauten Managed Security Service Provider (MSSP) einzukaufen (Buy). Die hierfür relevanten Überlegungen betreffen langfristige Investitionen und verlangen differenzierte Abwägung der verschiedenen Möglichkeiten. Zudem nimmt das SOC eine wesentliche Position im Unternehmen ein. Eine fundamentale Veränderung eines SOCs oder gar die Dekommissionierung dieser Einheit bringt grosse Herausforderungen mit sich – sie ist aufgrund des getätigten Aufwandes und der zusätzlich anfallenden Kosten meistens keine lohnende Alternative.

Grundlegend ist, dass ein SOC Anomalien nur dann gut erkennen kann, wenn es als zentrale Einheit für sämtliche Informationen im Unternehmen etabliert wird. Daher nimmt es die wichtigste Schlüsselrolle in Bezug auf korrekte wie auch inkorrekte Informationsflüsse ein. Jedoch beinhaltet ein SOC nicht nur Technologie, sondern – und dies ist weit wichtiger – es lebt von einem Team erfahrener Analysten.

Zweiseitiger Informationsfluss

Eine solche Einheit muss sehr viele Schnittstellen für den Informationsfluss aus anderen Abteilungen bereitstellen, um ihre Hauptaufgabe zu erfüllen: Die Überprüfung auftretender Abweichungen vom Normalzustand. Über diese Schnittstellen kommen nicht nur Informationen ins SOC, sondern über sie fliessen auch eine Fülle wichtiger Informationen, die das SOC generiert Dies sind Erkenntnisse zur Sicherheitslage des Unternehmens, zur Situation einzelner Abteilungen oder zu bestimmten Geschäftsprozessen. Diese Erkenntnisse werden vom SOC jeweiligen Unternehmensbereichen, die die empfohlenen Maßnahmen realisieren müssen, als Report oder Dashboard zur Verfügung gestellt.

 

Klare Aufgabendefinition ist notwendig

In erster Linie muss exakt definiert werden, was von einem SOC erwartet wird (Mission), und wohin es sich entwickeln soll (Vision). Deshalb ist empfehlenswert, sich über das grössere Ziel (Vision) bzw. dessen Auftrag (Mission) Klarheit zu verschaffen. Zum einen kann nur so allen Stakeholdern unmissverständlich der Umfang eines SOCs klar gemacht werden. Zum anderen ist nur auf diese Weise möglich, einen Business Case bzw. die Budgetierung für die gesamten Langfristinvestitionen (2-3 Jahre) realitätsnah zu berechnen.

Anforderungen, Randbedingungen und Einflussfaktoren

Folgende Grundüberlegungen, zu denen je nach Gegebenheiten noch weitere kommen können, sind für eine SOC Mission und Vision essenziell:

  • SOC Mission Statement: Was ist der Hauptauftrag des SOCs? Warum bzw. wofür braucht es ein SOC? Was sind mögliche Nebenaufgaben, die ein SOC ausführen muss? Wofür ist ein SOC nicht gedacht bzw. geplant?
  • SOC Organisationsform: Wird das SOC alleinig intern betrieben (Make) oder werden nur Business-nahe Disziplinen intern produziert und andere extern eingekauft (Hybrid) oder wird alles von extern bezogen (Buy)?
  • SOC Cyber Defense Service: Welche Dienstleistungen muss das SOC realisieren, z. B. Anomalie Detektion (SIEM), Incident Response (CSIRT), aktuelle Sicherheitsinformationen (CERT), Brand- und Reputations-Exponierung (Threat Intelligence), Sicherheits-Architektur Beratung, Vulnerability- und Assessment Dienstleistungen, Software-Compliance Überprüfungen etc.? Wer definiert und berechnet neue Services (Service Development)? Wer erstellt und bearbeitet Service-Beschreibungen, Service Kataloge? Wer macht die Service Kalkulation?
  • SOC Go-to-Market-Modell: Tritt das SOC intern als Cost- oder Profit Center auf, wird eine Mischform realisiert, oder werden auch externe Kunden akquiriert? Wer verkauft die Services (Verkauf; PreSales; intern; extern)? Wer ist für das Marketing zuständig (eigene Rolle im SOC oder durch die Marketing Abteilung)? Wer erstellt und bearbeitet Service Präsentationen, Flyers, etc.?
  • SOC Standards: Welche Standards werden für das SOC gelten (z.B. ISO 27001/2, NIST Cyberframework, ISAE 3402, PCI-DSS, etc.)?
  • SOC Operationsmodelle: Wird das SOC 24x7 betrieben oder nur während der Firmenbetriebszeiten? Gibt es einen Bereitschaftsdienst (in der Nacht, während Feiertagen oder an Wochenenden)?
  • SOC Rollen: Welche Aufgaben/Rollen sollen durch das SOC abgedeckt werden (z.B. Threat Analysten/Responder, Threat Intelligence Experten, Incident Responder, Security Entwickler, Service Architekten, Threat Hunter)? Wer ist für die Rekrutierung zuständig? Wer macht Karrierepläne, und wie werden Karrierepläne bzw. Weiterbildungspläne der Mitarbeiter entwickelt und gelebt? Welche Mitarbeiterzertifizierungen werden in einem SOC benötigt?
  • SOC Sprachen: Welche Sprachen sollen durch das SOC unterstützt werden? Welche zu Firmenbetriebszeiten, in der Nacht, während Feiertagen und an Wochenenden?
  • SOC Betriebsform: Wird das SOC national oder international betrieben? Im Schichtbetrieb oder Follow-the-Sun? Welche Handover-Zeiten? Bei Schichtbetrieb: Genügen 3 Schichten oder müssen 4 Schichten für Handover-Zeiten in Betracht gezogen werden, um die lokal geltenden Arbeitsgesetze von z. B. 8 Stunden pro Tag einzuhalten?
  • SOC Organisation: Wo wird das SOC in der Linie etabliert? Bei der IT, der IT Security, bei RISK, Internal Audit, unter CIO, unter CISO, bei CDO, etc.? Wie ist die interne Organisation im SOC geregelt? Wird es einen SOC Manager geben, oder wird diese Aufgabe durch den CISO übernommen? Wird es einen SOC Duty Manager geben für die Schichtregelung, oder gibt es lokal verantwortliche SOC Leiter? Welche Levels (Tiers) werden im SOC etabliert? (Tier 1 für Analysten/Responder, Tier 2 für Threat Hunter und Tier 3 für Incident Responder (CSIRT), Threat Intelligence Experten, etc.)?
  • SOC Prozesse: Welche Prozesse sind für ein SOC notwendig (z.B. Service Prozesse (ITIL), Incident Response Prozesse, SIEM Use Case Strategie, Konfigurations-Management)? Wie werden von wem zu welcher Zeit welche Reports vom SOC an die Stakeholder präsentiert (z.B. wöchentlich, monatlich, quartalsweise, in Person oder automatisch)? Welche KPIs (z.B. Anzahl Alerts in welcher Zeiteinheit; was konnte gestoppt werden, was nicht; was wäre passiert, wenn man es nicht gestoppt hätte, etc.)?
  • SOC Technologie Stack: Welche Technologien/Tools sind für ein SOC essenziell? Welche sind optional? Welche sind kommerziell zu erwerben? Welche sind OpenSource? Welche Threat Feeds sollen zur Anreicherung der Alarme genutzt werden? Wo und wie werden die SOC Tools betrieben (z.B. geteilte Umgebung mit anderen Geschäftsbereichen oder physikalisch dediziert)?
  • SOC Facility: Wo wird das SOC bzw. das Cyber Defense Center (CDC) gebaut? Wie ist der Zugang zum CDC gestaltet (z.B. Retinascanner, Venenscanner, Vereinzelungsschleuse, etc.)? Wie wird der Zugang geregelt? Wer darf bzw. muss ins CDC und warum? Welche Räume braucht ein CDC zusätzlich (z.B. Malware Lab, Incident Rooms, etc.)? Welche Informationen will man bzw. kann man auf Dashboards präsentieren?
  • SOC Verträge: Müssen SLA Definition bzw. OLAs erstellt und definiert werden und wenn ja, was ist inhaltlich festzulegen (z.B. Verfügbarkeit, Reaktionszeit, Bonus-Malus, RACI, etc.)?
  • SOC Schnittstellen: Neben den Stakeholder-Schnittstellen existieren einige technische Schnittstellen wie Kunde-Firma oder auch Firma-Firma. Welche Schnittstellen werden somit benötigt? Wer muss mit welchem Zugriff von ausserhalb des SOCs auf Informationen des SOCs zugreifen? Wie werden diese Zugreifenden geschult bzw. wer erstellt und bearbeitet die Unterlagen dazu?

Intensive Vorarbeit für gelungene Realisierung

Um eine Vision in den nächsten 2-3 Jahren zu realisieren, muss geklärt werden, wo man heute steht und welche Elemente bzw. Meilensteine in welcher Zeit zu erreichen sind. Eine IST-Analyse der aktuellen Situation ist deshalb unumgänglich. Sie klärt, ob Teilbereiche bereits partiell oder komplett existieren. Gerade in Bezug auf die Rekrutierung der neuen Mitarbeiterrollen ist die Erkenntnis wichtig, ob sich Unternehmensmitarbeiter in diese neuen Rollen einarbeiten können bzw. sich dorthin entwickeln möchten.

Nach der Klärung der Vision und der Aufnahme der IST-Analyse können über Vergleiche wichtige Bereiche identifiziert werden. Zum einen diejenigen, welche für die SOC Vision noch zu entwickeln sind, zum anderen die Bereiche, die zum Teil bereits existieren und daher noch einer Teil-Entwicklung bedürfen. Schliesslich jene, welche bereits komplett realisiert sind, jedoch u. U. in der Organisation verändert werden müssen. Dies gilt vor allem bezüglich der Berichterstattung.

Neuaufbau eines SOC als Herausforderung

Ein SOC ist kein Projekt mit definiertem Anfang und Ende, sondern es ist der Weg zu einer transparenten und somit realen Einschätzung der Bedrohungslage. Daher sind für die Realisierung der SOC Vision Meilensteine bzw. Strategie-Ziele über die Jahre zu definieren. Dies ist wesentlich, um Leistung und Mehrwerte unterjährig zu messen und zu berichten. Sind keine Strategie-Ziele definiert, besteht die Gefahr, dass ein SOC nicht mehr fokussiert zur SOC Vision entwickelt wird. Dadurch entstehen eventuell Mehrkosten durch nicht aufeinander abgestimmte Veränderungen, welche nicht budgetiert sind und deren Investitionen somit nur schwer begründbar sind. Dennoch muss es möglich sein, dass sich das SOC stetig an die Entwicklung des Unternehmens, der Kunden und an die allgemeine Bedrohungslage anpasst. Hierfür ist sehr wichtig, die SOC Vision und die abgeleiteten Strategie-Ziele regelmässig zu überprüfen und bei Notwendigkeit offiziell zu modifizieren.

Ein Neuaufbau eines SOC verlangt die Evaluation der Technologie und die Definition und Realisation der Prozesse. Eine weitere wichtige Aufgabe ist die Rekrutierung der neuen Rollen. Diese können entweder durch Entwicklung interner Mitarbeiter oder durch externe Rekrutierung erreicht werden. Bei beiden Möglichkeiten ergibt sich jedoch ein längerer Vorlaufprozess, bis die Personen geschult bzw. gefunden und eingestellt sind. Die relevanten Rollen sind im Cyber Defense Umfeld stark nachgefragt, und Mitarbeiter sind somit schwer zu finden und zu halten. Weiterhin ist zu berücksichtigen, dass hinsichtlich der Qualifikation der Mitarbeiter jahrelange Erfahrung zählt – und diese kann nicht alleinig durch Schulung oder Weiterbildung erreicht werden.

SOC Realisations-Projekte werden oftmals aufgrund von besonderen Ereignissen realisiert. Vielfach sind es nicht erfüllte Compliance Richtlinien, die durch ein Audit entdeckt wurden, oder aufgrund von geänderten Kundenanforderungen, oder es liegen neue Bedrohungssituationen vor bzw. ein erfolgreich getätigter Angriff auf das Unternehmen wurde entdeckt. Somit stehen SOC Realisations-Projekte häufig unter starkem Zeitdruck. Gerade deswegen ist eine Vorlaufphase von ein bis zwei Jahren vor dem GoLive, um die benötigte Mannschaft einzustellen, möglicherweise schwer zu vermitteln. Problematisch ist dabei auch, dass es häufig den Wunsch gibt, das SOC solle bereits vom ersten Tag an produktiv arbeiten.

Vorteile der Buy-Strategie

Natürlich will man den Bedürfnissen nach umgehender Handlungsfähigkeit des SOC nahekommen. Daher empfiehlt es sich, auch wenn die SOC Vision eine reine Make-Strategie verfolgt, in einem Hybrid-Modell oder zu Beginn mit einer reinen Buy-Strategie zu starten. Die Buy-Strategie hat den grossen Vorteil, dass sämtliche Themenpunkte der SOC Vision bereits definiert  und realisiert sind. Beispielsweise stehen die Spezialisten bereits zur Verfügung und sämtliche SOC Dienstleistungen können aus einem bereits existierenden Service Katalog ausgewählt werden usw. Die Buy-Strategie nimmt also den Zeitdruck und der SOC Aufbau kann über eine realistische Zeitspanne hinweg erfolgen.

Ein weiterer wichtiger Vorteil einer anfänglichen Buy-Strategie ergibt sich zusätzlich: Über eine angemessene Zeit hinweg können die SOC Dienstleistungen vom Service Erbringer zum Service Bezieher transformiert werden.

Ergänzend zeigt sich ein Vorteil dieser Strategie bei Aufgaben, die in der ersten SOC Vision als eigens zu schaffende Elemente definiert wurden. Wenn sich der Fokus dieser Aufgaben über die Zeit verändert, kann man sie weiterhin beim Service Erbringer einkaufen. Das erlaubt dem Unternehmen, den Fokus mehr auf die businessnahen Disziplinen zu richten.

Faktor Zeit als wesentliches Element

Nicht zu vergessen ist der Mindest-Zeitbedarf, den ein SOC Neuaufbau verlangt, um ohne Buy-Strategie zumindest teilweise produktiv zu werden. Selbst um ein Teil-SOC zu etablieren, ist allein für die Rekrutierung eine Zeitspanne von einem halben bis zu einem Jahr zu kalkulieren. In diesem Fall entsteht jedoch kein 24x7 SOC, sondern lediglich eine Verfügbarkeit zu firmenüblichen Tageszeiten ohne Pufferkalkulation aufgrund von Ferien und Krankheit. Erfahrungsgemäss rechnet man mit zwei Jahren, bis eine SOC Mannschaft für einen 24x7 Betrieb verfügbar ist. Neben der Rekrutierung müssen die Evaluation und Realisation der adäquaten Technologien sowie die Definition und Etablierung aller notwendigen Prozesse vorgenommen werden.

SOC Mehrwerte über Servicebezug realisieren

Der Aufbau eines SOC bietet bestechende Mehrwerte für das Unternehmensbusiness. Daher ist der Wunsch verständlich, die SOC Mehrwerte umgehend nach dem Projektstart zur Verfügung zu stellen. Daraus ergibt sich für solche Projekte in der Regel erheblicher Zeitdruck. Jedoch verlangt der SOC Aufbau, komplexe Technologien und Prozesse neu zu evaluieren, zu entwickeln und zu realisieren, wofür wiederum ein realistischer Zeitraum einzuplanen ist. Für die Probleme im Recruiting-Sektor gilt gleiches. Sie verlangen sachlich und zeitlich erheblichen Einsatz. Weiterhin sollte man gerade über die SOC-Aufbaujahre dynamisch auf die sich verändernden Anforderungen reagieren können. Schliesslich ist die gesamte SOC Vision regelmässig zu prüfen: Gegebenenfalls gilt es, Änderungen vorzunehmen, ohne den Aufbau des SOC zu stark zu kompromittieren.

Zweifellos zeigen sich hier bestimmte, schwer aufzulösende Widersprüche. Die Lösung besteht in einer zumindest anfangs zu wählenden Buy-Strategie: Die belastenden und zeitkritischen Problemstellen greifen nicht, da der Service Erbringer die Leistungen unmittelbar bereitstellt. Dies entlastet enorm und ermöglicht Fokussierung auf das Kerngeschäft. Zugleich hält sich das Unternehmen in einem sehr vielschichtigen Umfeld alle Wege offen, baut Erfahrungen auf und kann im Zeitverlauf ohne Druck die eigene Vision weiterverfolgen.