Über diesen Leitfaden

Die kontinuierliche und ganzheitliche Überwachung der IT-Sicherheit ist ein essentieller Bestandteil einer Gesamtstrategie, um Ihr Unternehmen vor Angriffen, Datenexfiltration und Betriebsstörungen zu schützen. Notwendig sind:

  • Hard- und Softwarewerkzeuge,
  • hochqualifizierte Experten und
  • im Notfall perfekt funktionierende Prozesse.

All dies muss bis zu 24 Stunden an 7 Tagen in der Woche verfügbar und „state of the art“ sein.
Der Aufbau dieser umfassenden Struktur bedarf finanzieller und personeller Ressourcen. Die Entscheidung zwischen einem internen Aufbau oder einer Inanspruchnahme eines Managed Services muss aus strategischer und organisatorischer Sicht ebenso wie aus der finanziellen Perspektive gesehen werden.
Der vorliegende Leitfaden soll Sie unterstützen, die richtige Entscheidung zwischen „make or buy“ zu treffen.

Das SOC (Security Operations Centre) – was es ist und was es nicht ist

Im Bereich IT-Sicherheit findet seit einigen Jahren ein Paradigmenwechsel statt: Der Aufbau hoher Mauern schützt die IT nicht mehr wirksam. Es stehen zu viele Einfallstore für Angreifer zur Verfügung. Der heutige Ansatz stellt die zeitnahe Erkennung von IT-Sicherheitsrisiken in den Vordergrund. Sie ist der Ausgangspunkt für die richtigen Reaktionsmaßnahmen, das Vorhersagen und das Verhindern von potentiellen Schäden. Die Aufgabe der Risikoerkennung ist zentraler Bestandteil eines Security Operations Centres (SOC), teils auch als Cyber Defence Centre bezeichnet.

Ein „SOC“ kann unterschiedliche Ausprägungen annehmen. Es besteht jedoch nie aus nur einem Werkzeug. Es umfasst auch immer mehr als ein Security Information & Event Management (SIEM). Und es leistet auch wesentlich mehr als Security Audits und Compliance Checks. Diese „hartnäckigen Gerüchte“ halten sich, erfassen jedoch den ganzheitlichen Ansatz eines SOCs nicht.

Eine gängige Definition eines SOCs umfasst dessen Kombination aus Experten, Werkzeugen und Prozessen mit dem Ziel, IT Sicherheitsrisiken zu verhindern, entdecken, analysieren, bewerten, deren Behebung zu beschreiben und zu kontrollieren sowie im Bedarfsfall bei der Umsetzung von Maßnahmen zu unterstützen und Beweissicherung einzuleiten.

 Die Werkzeuge für die Risikoerkennung und –management

Zu den Werkzeugen für die Risikoerkennung und –management gehören die Schwachstellenanalyse, die Netzwerk-Risiko-Erkennung basierend auf Signaturen und Verhaltensanalyse, Logdaten-Analyse (SIEM), Sandboxing (APT), Threat Intelligence, Wissensdatenbank (Risiken und Lösungen) und ein Workflow-Management-System.

Korrelationssystem

Verhaltensanalyse
Big Data
Machine Learning
Inputabhängig
Schwachstellenanalyse
Netzwerk-Risiko-Erkennung (Signatur)
Netzwerk-Risiko-Erkennung (Verhalten)
Logdaten-Analyse (SIEM)
Sandboxing (APT)
Threat Intelligence
Wissensdatenbank (Risiken und Lösungen)
Workflow-Management-System

Die Werkzeuge umfassen

  • Data exfiltration
  • Unwanted remote control software
  • DNS tunnels – control channels
  • ICMP tunnels – control channels
  • Creation of new suspicious services on Windows endpoints
  • Common windows utilities used during lateral movement
  • WebShells (PHP, ASP; embedded GIF files)
  • P2P protocol detection
  • DNS anomalies
  • Attacks – exploits against SQL services
  • Attacks against SCADA
  • Services scanning / fingerprint – vulnerability checks
  • (TCP-UDP) Shellcode
  • DGA domains generation
  • Botnet detection
  • General communications via domain, IP, to malware CnC
  • VoIP exploit – attacks
  • Vulnerability (system, application, middle-ware)
  • Authentication systems user brute force attempts
  • Outdated software / services
  • Ransomware detection
  • Malicious – suspicious VBScript
  • Malicious – suspicious PowerShell
  • General software – services exploits
  • TOR traffic
  • Attacks – exploits against POP3,SMTP,IMAP
  • Different known Trojan families (network behaviors)
  • Firewall drop burst – outbound
  • Attacks – anomalies regarding IPv4 / IPv6 protocol
  • Unusual – fake User Agents

Die benötigten Experten und ihre Aufgaben im SOC-Betrieb

Die Risikoerkennungswerkzeuge liefern Ergebnisse, die von Experten analysiert und bewertet werden müssen.
Auch die Werkzeuge an sich müssen ständig an aktuelle Gegebenheiten angepasst werden.
Zu den Aufgaben der Security Analysten im SOC gehören besonders:

  • die Kontextualisierung von Security Events in wirkliche Incidents,
  • das Entwickeln, implementieren und optimieren von Risk Detection Usecases,
  • die Integration von bereits existierenden Risk Detection Solutions,
  • das Führen der IT Risk Management Prozessen und Workflows und
  • das Identifizieren, Sammeln und Zusammenführen von Threat Intelligence Daten.

Die Aufgaben der Security Analysten, des Operations Teams und des Computer Security Incident Response Teams im Überblick

Die Anzahl der benötigten Experten hängt von mehreren Faktoren ab. Für einen 5*12 Betrieb sind in einem Mindestszenario 4 Personen einzuplanen. Für 24*7 Betrieb mindestens 8 Personen.
Wichtig ist: nicht jeder Experte beherrscht jedes Werkzeug. Vielmehr ist unterschiedlichstes Expertenwissen notwendig.
Zudem ist eine Mischung aus Juniors und Seniors empfehlenswert. Und: Kommunikationsgeschick und Grundlagen der Psychologie sind von großem Vorteil.

Vom Security Event zum bewerteten Incident

Security Events können, müssen aber nicht sicherheitsrelevant sein. Die Kunst besteht darin, diese sicherheitsrelevanten Events aus der großen Masse an Daten herauszufiltern und verschiedene Informationen so zu verdichten, dass sie zu bewerteten Incidents werden.

Im Mittelpunkt der Expertenarbeit steht also: Die richtigen Schlüsse ziehen. Sie lassen sich als Kombinationen aus verschiedenen Informationsquellen erkennen:

Funktionierende Prozesse als dritter zentraler Baustein eines effektiven SOCs

Die Erkennung ist die Basis für alle weiteren Schritte, die im Endeffekt zum Verhindern von Vorfällen führen. Ist ein mögliches Problem erkannt, so muss es fachmännisch bewertet werden. Gegebenenfalls kann es danach behoben werden. Wichtig ist dann, zu verifizieren, ob die Behebung tatsächlich geschehen ist bzw. ob das Problem damit tatsächlich behoben wurde.
Nur auf der Basis von funktionierenden Prozessen ist es möglich, Angriffe vorherzusagen und sie zu verhindern.

Die Phasen beim Aufbau eines eigenen SOCs

Phase 1 – Anforderungsmanagement, Konzeption und Sizing

In dieser Phase geht es um die Auswahl und Sichtung notwendiger Produkte/Lösungen. Ein Teilbereich ist die Evaluierung, ob vorhandene Systeme eventuell eingesetzt werden können.
Es geht daneben um die Auswahl der Art der Überwachung. Auch die Analyse der zu überwachenden Systeme/Standorte muss vorgenommen werden. Die notwendigen Use-Cases als auch Compliance Anforderungen müssen bestimmt werden. Zudem spielen die zu erwartenden Datenmengen und die sicherheitsrelevanten Quellen (u.a. Anzahl Logs, Logquellen, Berechnung EPS) eine Rolle, die das weitere Vorgehen bestimmt. Auch die notwendigen Redundanzen, die einzubeziehenden Organisationseinheiten und der Aufwand für diese Organisationseinheiten müssen bestimmt werden.

Phase 2 – Angebotseinholung / Ausschreibung / Bieterauswahl

Im Mittelpunkt dieser Phase steht die Angebotseinholung für die einzelnen Produkte für den SOC-Betrieb. Hierunter sind Produktlizenzen, Datenbanken, Betriebssystem und Hardwarekosten zu verstehen. Ein Vergleich der unterschiedlichen Spezifika (Featurevergleiche, Product Roadmaps etc.) ist vorzunehmen.
Daneben werden die Stellenausschreibungen für die zukünftigen Mitarbeiter des SOC – sowohl für Junior als auch Seniorlevel –verfasst.
Kann das bestehende Workflow-System verwendet werden? Auch diese Frage gilt es zu klären. Das Gesamtvorhaben muss schlussendlich in einen Business Case, also eine Gesamtinvestitionsrechnung, münden.
Sind Angebote – zum Beispiel im Rahmen einer Ausschreibung – von verschiedenen Anbietern eingetroffen, werden sie im Detail gesichtet und auf der Basis aller vorab bestimmten Rahmenfaktoren verhandelt. Unter anderem werden die Anzahl der Logs, Logquellen und die Berechnung der EPS eine tragende Rolle spielen. Schlussendlich müssen die einzelnen Verträge erstellt und geschlossen werden.

Phase 3 – Implementierung und Konfiguration

Die angeschaffte Hard- und Software wird nun installiert. Die SOC-Mitarbeiter werden eingearbeitet und geschult. Prozesse für die Behebung der Incidents werden festgelegt. Ein Risiko-Workflow/Ticket System wird implementiert. Das gesamte Set muss an die Unternehmensgegebenheiten angepasst werden. Es folgt die technische Implementierung und der Probebetrieb (u.a. die Weiterleitung von Logs, Spiegelung des Netzwerkverkehrs und die Credentials für Scans).
Nun können die ersten Ergebnisse analysiert werden. Normalwerte werden dokumentiert, Schwellenwerte werden definiert. Use Cases werden erstellt und getestet, Testszenarien werden aufgebaut, Hacking und Penetrationstests von externen Spezialisten folgen.

Phase 4 – der laufende Betrieb

Die regelmäßige Analyse durch die Experten umfasst u.a. das Durchgehen der automatisiert erlangten Ergebnisse, das Aussortieren von False Positives/False Negatives, die Ergebniskorrelation und die Gewichtung der Incidents.
Um immer auf dem aktuellen Stand zu bleiben, müssen die Experten ständig weitergebildet werden. Allem voran in den Themen Threat Landscape, neue Angriffsmethoden, neue Produktfeatures und Releases gibt es laufend Neuerungen.
Auch die funktionierende Zusammenarbeit mit anderen Organisationseinheiten gilt es zu pflegen und gegebenenfalls zu optimieren. U.a. stehen hier das Erstellen von Tickets, das Verfassen von Behebungsanleitungen, die Behebung an sich und das laufende Reporting im Mittelpunkt.
Regeln und die Erkennung müssen kontinuierlich adaptiert werden und Erkenntnisse umgesetzt werden. Es muss gepatched werden und auch Forensics und Dokumentationen müssen funktionieren.
Hinzu kommen externe Audits und eine „Endkontrolle“ der tatsächlichen Behebung, um den gesamten Kreis für eine effektive Erhöhung der IT-Sicherheit zu schließen.
Ein Fortschrittscontrolling und ein Reporting dienen dem Informationsaustausch in einem SOC und zwischen einem SOC und den Stakeholdern. Unter anderem sind die Kontrolle des Behebungsfortschritts, die Aufbereitung des Risikoreportings für Organisationseinheiten und das Management sowie die laufende Durchführung sowie Vor- und Nachbereitung von Kontrollmeetings und Jour Fixes umfasst.

Eigenbetrieb eines SOCs versus SOC as a Service – eine Kostenschätzung

Die Kosten eines eigenbetriebenen SOCs und auch die eines Managed SOCs hängen von mehreren Faktoren ab. Hier kann nur eine ungefähre Schätzung erläutert werden. Sie ersetzt kein maßgeschneidertes Angebot unter Berücksichtigung der jeweiligen Rahmenfaktoren und auf der Basis eines vorgenommenen Sizings. Die Basis dieser Beispielrechnung sind 5.000 EPS und 5.000 IPs.

Interner Aufbau eines SOC, inkl. Anschaffung der notwendigen Technologien

Vorab eines tatsächlichen Aufbaus sind die Phase 1 (Anforderungsmanagement, Konzeption und Sizing) und Phase 2 (Angebotseinholung / Ausschreibung / Bieterauswahl) zu berücksichtigen.
Für die Phase 1 sollten erfahrungsgemäß mindestens 2 bis 3 Monate Planung und gegebenenfalls auch ungefähr EUR 20.000 Aufwand für externes Consulting eingeplant werden.
Für Phase 2 sollten mindestens 6 bis 9 Monate interner Aufwand eingeplant werden.

In diesem Szenario würde der finanzielle Aufwand im ersten Jahr also EUR 710.000 und im zweiten Jahr EUR 410.000 betragen.

SOC as a Service – Werkzeuge, Experten und Prozesse aus einer Hand

Bei der Wahl eines Managed SOCs sind Werkzeuge und Experten inkludiert und Prozesse etabliert. Damit ist der vollständige SOC-Betrieb abgedeckt. Neben der Auswahl aus verschiedenen Risikoerkennungsmodulen ist auch die Wahl des Intervalls in dem die Expertenarbeit geleistet wird, möglich. In diesem Beispiel werden tägliche und wöchentliche Intervalle für die Expertenarbeit präsentiert.
Es gibt im Regelfall keine Anschaffungskosten. Mit den initialen Kosten für einen POC und das darauffolgende Set Up werden bereits die ersten Arbeitsresultate des SOCs geliefert.
Die Geschäftsbeziehung zu einem Managed SOC-Betreiber ist in der Regel sehr langfristig, sodass ein sehr vertrauensvolles Arbeitsverhältnis mit den Experten entsteht und eine tiefe Integration in die IT-Betriebsorganisation des Kunden möglich ist.

In diesem Szenario würde der finanzielle Aufwand im ersten Jahr also EUR 290.000 bei der Wahl eines täglichen Intervalls, in dem die Experten analysieren, und EUR 240.000 bei der Wahl eines wöchentlichen Intervalls für die Expertenarbeit, betragen. Im zweiten Jahr ist mit EUR 190.000 bei täglichem Intervall und EUR 140.000 bei wöchentlichem Intervall zu rechnen. Inkludiert sie die Kosten für Experten, Maintenance und Threat Intelligence, exkludiert ist möglicher Consultingaufwand.

Conclusio: Empfehlungen für Ihren SOC Aufbau

Der Eigenbetrieb eines SOCs und die Alternative „SOC as a Service“ sind zwei Möglichkeiten für die Umsetzung für mehr effektive und effiziente IT-Sicherheit in einer Organisation. Die Entscheidung zwischen diesen Möglichkeiten hängt nicht nur von der Größe einer Organisation ab, sondern auch vor allem von einer Orientierung am eigenen Organisationsziel. Denn: ein SOC hat keinen „Selbstzweck“, sondern soll sich optimal in seine Umgebung integrieren. Das eigene SOC, die langfristige Zusammenarbeit mit einem Managed SOC-Betreiber oder der Aufbau eines Mischbetriebs – hier muss eine Grundsatzentscheidung getroffen werden.

Den Varianten ist gemein, dass sie den generellen Paradigmenwechsel in der IT-Sicherheit verkörpern: die kontinuierliche Erkennung von Risiken steht im Vordergrund, nicht der Abwehrgedanke.

Dabei müssen Werkzeuge, Experten und Prozesse detailliert betrachtet werden. „A fool with a tool is still a fool“ – ein Sprichwort, das besonders im Bereich Sicherheit bedacht werden kann, um sich nicht in falscher Sicherheit zu wiegen. Struktur, die Ressource „Zeit“ und der tatsächliche Fokus auf den SOC-Aufbau und -Betrieb gehören zu den entscheidenden Erfolgsfaktoren. Die Personalsuche, die Prozessplanung, die Strukturierung, der sukzessive Aufbau und die Integration des Werkzeugportfolios – die zahlreichen Aufgaben benötigen Zeit und Fokus. Deshalb sollte bei einem Eigenbetrieb nicht damit gerechnet werden, in einem halben Jahr zu 100% „up and running“ zu sein.