SOC Managed SOC MSSP

Security Operations Center (SOC): Definition, Aufgaben, Team und Aufbau

Was ist ein Security Operations Center (SOC)?

Ein Security Operations Center (SOC) ist eine zentrale Einheit aus Team, Prozessen und Technologie, die IT-Systeme kontinuierlich auf Sicherheitsbedrohungen überwacht, Vorfälle analysiert und darauf reagiert. Ein SOC ist häufig rund um die Uhr aktiv, muss aber nicht zwingend im 24/7-Betrieb organisiert sein.

Damit bündelt das SOC die operative Cybersicherheit eines Unternehmens: Es sammelt und bewertet sicherheitsrelevante Informationen, untersucht auffällige Aktivitäten und koordiniert notwendige Reaktionen. NIST beschreibt das SOC entsprechend als zentralen Anlaufpunkt für Security Operations und Cyber Defense, der Systeme und Netzwerke fortlaufend überwacht sowie Cyber Security Incidents erkennt, analysiert und beantwortet.

Kurz gesagt: Ein SOC soll sicherstellen, dass ein Unternehmen relevante Cyberbedrohungen nicht nur technisch erkennen kann, sondern daraus möglichst schnell die richtigen Entscheidungen und Maßnahmen ableitet.

 

Wofür steht die Abkürzung SOC?

SOC steht in der IT-Sicherheit für Security Operations Center. Damit ist eine organisatorische Funktion gemeint, in der spezialisierte Mitarbeitende, definierte Prozesse und Security-Technologien zusammenarbeiten.

Es handelt sich also nicht lediglich um einen Raum voller Bildschirme und auch nicht um ein einzelnes Security-Tool. Im SOC kommen Rollen, Prozesse und Technologien zusammen. Zu den beteiligten Funktionen können unter anderem Security-Analysten, IT-Sicherheitsingenieure und SOC-Manager gehören.

Was macht ein SOC? Die Aufgaben im Überblick

Die zentrale Aufgabe eines SOC besteht darin, sicherheitsrelevante Ereignisse kontinuierlich zu überwachen, mögliche Bedrohungen zu erkennen, zu untersuchen und angemessen darauf zu reagieren.

Dabei ist das SOC keine isolierte technische Plattform. Menschen, Prozesse und Technologien müssen ineinandergreifen.

Kontinuierliches Monitoring

Ein SOC überwacht relevante Sicherheitssignale aus angebundenen Systemen und Datenquellen. Dazu können Perimeter-Systeme, Netzwerkgeräte, Endpoints sowie Identitäts-, Cloud-, Applikations- und E-Mail-Systeme gehören.

Entscheidend ist nicht, möglichst viele Daten zu sammeln. Die Daten müssen für definierte Detection Use Cases nutzbar sein.

Bedrohungserkennung und Analyse

Ein ausgelöster Alarm ist zunächst ein technischer Hinweis, noch kein abschließend bewerteter Sicherheitsvorfall. Das SOC muss den Kontext prüfen und den tatsächlichen Handlungsbedarf bewerten.

Incident Response und Eskalation

Wird aus einem Alarm ein relevanter Sicherheitsvorfall, muss eine passende Reaktion eingeleitet werden. Abhängig vom Betriebs- und Verantwortungsmodell kann dies von der Alarmierung zuständiger Stellen bis zu abgestimmten technischen Gegenmaßnahmen reichen.

Detection allein stoppt keinen Angriff. NIST ordnet Incident Response heute übergeordnet in Detect, Respond und Recover ein und verbindet diese Funktionen mit vorbereitenden Risikomanagement-Aktivitäten sowie kontinuierlicher Verbesserung.

Threat Intelligence und Detection Engineering

Moderne SOCs verlassen sich nicht ausschließlich auf vorkonfigurierte Alarmregeln. Threat Intelligence liefert Kontext über Bedrohungen, Angreifer und bekannte Indikatoren. Detection Engineering entwickelt, testet und verbessert Erkennungslogiken gezielt.

Reporting und Kennzahlen

Ein SOC muss seine Arbeit messbar machen. Dafür können unter anderem Zeiten für Erkennung, Annahme und Reaktion betrachtet werden. Kennzahlen dürfen jedoch nie isoliert bewertet werden. Eine kurze Reaktionszeit hilft wenig, wenn relevante Angriffe nicht erkannt werden.

Typische Analysefragen

  • Was ist passiert?
  • Welche Systeme oder Konten sind betroffen?
  • Handelt es sich um legitimes oder verdächtiges Verhalten?
  • Welche Auswirkungen sind möglich?
  • Besteht konkreter Handlungsbedarf?

Wie lassen sich Erkennungs-, Reaktions- und Behebungszeiten im Security Operations Center (SOC) konkret bewerten? Vertiefen Sie das Thema in unserem Blog und erfahren Sie, was MTTD, MTTA und MTTR über die Leistungsfähigkeit eines SOC aussagen. 

Wie läuft die Bearbeitung eines Alarms im SOC ab?

Die 6 Phasen

Die Bearbeitung eines Alarms kann sechs Phasen umfassen: Erkennung, Triage, Qualifizierung, Untersuchung, Reaktion und Wiederherstellung. Nicht jeder Alarm durchläuft alle Phasen, da sich viele Hinweise bereits während der Triage oder Qualifizierung abschließend bewerten lassen.

Dieses Modell ist eine praxisorientierte Prozessdarstellung und nicht mit dem aktuellen NIST-Lifecycle gleichzusetzen. NIST SP 800-61 Rev. 3 strukturiert Incident Response übergeordnet über Detect, Respond und Recover. Vorbereitung und kontinuierliche Verbesserung sind dabei in das übergreifende Cyber-Security-Risikomanagement eingebettet.

  1. Erkennung

    Ein Security-System oder eine Detection-Regel erkennt auffälliges Verhalten und erzeugt einen Alarm.

  2. 2

    Triage

    Der Alarm wird priorisiert. Analysten prüfen den grundlegenden Kontext und bewerten, ob eine weitere Untersuchung erforderlich ist.

  3. 3

    Qualifizierung

    Es wird beurteilt, ob ein Fehlalarm, ein erklärbares Ereignis oder ein potenzieller Security Incident vorliegt.

  4. 4

    Untersuchung

    Bei einem relevanten Verdacht folgt eine detailliertere Analyse. Zusammenhänge zwischen Ereignissen, Identitäten, Endpoints und weiteren Datenquellen werden untersucht.

  5. 5

    Reaktion

    Erforderliche Maßnahmen erfolgen entsprechend vorher definierter Verantwortlichkeiten, Kommunikationswege und Prozesse. Dies kann Alarmierung, Eskalation und zuvor freigegebene technische Maßnahmen umfassen.

    Ist ein bestätigter Sicherheitsvorfall mit Auswirkungen auf Systeme oder Geschäftsprozesse eingetreten, muss nach der Eindämmung ein sicherer Betriebszustand hergestellt werden. Bei Fehlalarmen oder frühzeitig abgewehrten Ereignissen ist keine Wiederherstellung erforderlich. Erkenntnisse aus relevanten Fällen sollten in die Verbesserung von Security Controls, Detection und Prozessen zurückfließen.

Wer arbeitet im SOC?

Team und Rollen

Ein SOC-Team kombiniert unterschiedliche technische und organisatorische Fähigkeiten. Welche Rollen benötigt werden, hängt von Größe, Betriebsmodell, Automatisierungsgrad, technischen Verantwortlichkeiten und dem definierten Scope ab.

Tier 1, Tier 2 und Tier 3: Wer macht was?

RolleTypische AufgabeTypischer Übergabepunkt
Tier 1 / L1 AnalystErstbewertung und Triage eingehender AlarmeWeiterführende Analyse erforderlich
Tier 2 / L2 AnalystVertiefte technische UntersuchungKomplexer oder spezialisierter Untersuchungsbedarf
Tier 3 / L3 AnalystKomplexe Analysen und tiefergehende technische UnterstützungÜbergang in Spezialdisziplinen oder umfassende Incident Response

Wichtig: Diese Tier-Struktur ist kein verpflichtender Standard. Moderne SOCs können Aufgaben nach Fähigkeiten statt nach festen Hierarchiestufen organisieren.

Weitere typische Rollen

SOC-Manager

koordiniert den operativen Security-Betrieb und dessen Weiterentwicklung.

Threat Hunter

sucht proaktiv nach möglichen Bedrohungen, die bislang keinen eindeutigen Alarm ausgelöst haben.

Incident Responder

konzentriert sich auf Analyse, Eindämmung und Bewältigung bestätigter Sicherheitsvorfälle.

Detection Engineer / Security Engineer

entwickelt und optimiert Detection Content sowie die dafür erforderlichen technischen Grundlagen.

Service Delivery Manager

koordiniert Serviceerbringung, Kommunikation, Reporting und kontinuierliche Verbesserung.

Wie viele Personen braucht ein SOC im 24/7-Betrieb?

Darauf gibt es keine seriöse allgemeingültige Zahl. Der tatsächliche Personalbedarf hängt vom konkreten Betriebsmodell ab, unter anderem von:

  • erforderlicher Besetzung pro Schicht
  • Alert-Volumen und Komplexität
  • Automatisierungsgrad
  • Anzahl und Kritikalität der Systeme
  • Bereitschaftsregelungen
  • Urlaubs- und Krankheitsvertretung
  • Aufgaben außerhalb der Alert-Bearbeitung

Unternehmen sollten den Personalbedarf aus dem eigenen Betriebsmodell ableiten, statt mit einer pauschalen Anzahl von SOC-Analysten zu planen. Was immer bedacht werden sollte: Wie decke ich Nebenzeiten wie Nachtschichten oder Wochenenden ab? Das ist die problematischste Zeit, wo Personalmangel am sichtbarsten wird.

Welche Technologien nutzt ein SOC?

Ein SOC verwendet typischerweise mehrere Security-Technologien, um Daten zu sammeln, Bedrohungen zu erkennen, Untersuchungen durchzuführen und Reaktionen zu unterstützen. Kein einzelnes Werkzeug bildet automatisch ein vollständiges SOC.

SIEM

Zentrale Sammlung, Korrelation und Analyse sicherheitsrelevanter Daten.

Mehr erfahren

EDR/XDR

Erkennung und Untersuchung verdächtiger Aktivitäten auf Endpoints beziehungsweise über mehrere Security-Domänen hinweg.

Mehr erfahren

SOAR

Orchestrierung und Automatisierung definierter Security-Abläufe.

Mehr erfahren

NDR

Analyse verdächtiger Aktivitäten im Netzwerk.

Threat Intelligence

Kontextinformationen zur Bewertung von Bedrohungen und Indikatoren.

ITSM/Ticketing

Dokumentation, Übergabe und Nachverfolgung von Fällen und Maßnahmen.

Die konkrete Kombination richtet sich nach Infrastruktur, Risikoexposition und definierten Use Cases.

Mit wachsendem Datenvolumen wird die Steuerung der Telemetrie selbst zur SOC-Aufgabe. Security Data Pipelines können Daten filtern, normalisieren und an geeignete Analyseplattformen weiterleiten. Ziel ist nicht maximale Datenmenge, sondern eine belastbare, wirtschaftlich vertretbare Datengrundlage für priorisierte Detection- und Investigation-Anforderungen.

Security Data Pipelines und Telemetrie-Management

Automatisierung kann wiederkehrende Arbeitsschritte wie Datenanreicherung, Ticketanlage und definierte Eskalationen beschleunigen. KI-gestützte Funktionen können Analysten bei Recherche, Zusammenfassung und Priorisierung unterstützen. Entscheidungen mit potenziellen Auswirkungen auf produktive Systeme benötigen jedoch klare Verantwortlichkeiten, Freigaben und nachvollziehbare Kontrollmechanismen.

Automatisierung und KI-Unterstützung

Unternehmen mit Produktions- oder Betriebstechnik müssen IT- und OT-Security gemeinsam betrachten, ohne beide Bereiche gleichzusetzen. OT-Umgebungen haben häufig andere Verfügbarkeitsanforderungen, Protokolle und Freigabeprozesse. Response-Maßnahmen müssen deshalb besonders eng mit Betrieb, Engineering und Anlagenverantwortlichen abgestimmt werden.

IT- und OT-Umgebungen

Cloud-Dienste, SaaS-Anwendungen und Identitätsplattformen erzeugen sicherheitsrelevante Signale, die in viele SOC-Betriebsmodelle einbezogen werden müssen. Dabei geht es nicht nur um klassische Logdaten, sondern auch um Anmeldeereignisse, Berechtigungsänderungen, administrative Aktivitäten und auffällige Nutzungsmuster. Welche Daten angebunden werden, sollte sich an Risiken und Detection Use Cases orientieren.

SOC, SIEM, NOC und MDR: die Begriffe im Überblick

Die Begriffe werden häufig miteinander vermischt, beschreiben aber unterschiedliche Dinge.

BegriffBedeutungVereinfacht gesagt
SOCSecurity Operations CenterOrganisatorische Security-Funktion aus Menschen, Prozessen und Technologie
SIEMSecurity Information and Event ManagementTechnologie zur Sammlung und Analyse sicherheitsrelevanter Daten
NOCNetwork Operations CenterFunktion mit Fokus auf Verfügbarkeit und Betrieb der IT- und Netzwerkinfrastruktur
MDRManaged Detection and ResponseManaged Service, bei dem ein externer Anbieter Bedrohungen überwacht und analysiert sowie gemäß vereinbartem Verantwortungsmodell Reaktionsmaßnahmen empfiehlt, koordiniert oder durchführt.

Ein SIEM ist eine Technologie. Ein SOC ist eine organisatorische Fähigkeit.

Ein SOC kann ein SIEM als zentrale Komponente nutzen. Das SIEM ersetzt jedoch nicht Analysten, Prozesse, Verantwortlichkeiten und Incident Response.

Wie baut man ein eigenes SOC auf?

Ein eigenes SOC aufzubauen bedeutet mehr, als SIEM- oder EDR-Technologie einzuführen. Zuerst müssen Ziele, Scope, Verantwortlichkeiten und relevante Detection Use Cases definiert werden. Erst danach sollten Technologie und Betriebsorganisation daraus abgeleitet werden.

  1. Voraussetzungen und Reifegrad prüfen

    Am Anfang steht eine ehrliche Bestandsaufnahme. Zu klären sind vorhandene Security-Prozesse, relevante Systeme und Datenquellen, internes Know-how, erforderliche Betriebszeiten, regulatorische Anforderungen und der bestehende Incident-Response-Prozess.

  2. 2

    Scope, Use Cases und Datenquellen festlegen

    Nicht jede denkbare Datenquelle muss sofort angebunden werden. Zunächst sollte festgelegt werden, welche Risiken und Angriffsszenarien erkannt werden sollen. Daraus lassen sich Use Cases und benötigte Telemetrie ableiten.

  3. 3

    Technologie, Personal und Prozesse aufsetzen

    Menschen, Prozesse und Technologie werden zu einem belastbaren Betriebsmodell verbunden. Verantwortlichkeiten, Triage, Eskalation, Untersuchung, Reaktion, Plattformen und Datenquellen müssen zueinander passen.

  4. 4

    Detection testen und kontinuierlich verbessern

    Tests sollten prüfen, ob die erforderliche Telemetrie vollständig und rechtzeitig verfügbar ist, Detection-Regeln wie vorgesehen auslösen, Alarme mit ausreichendem Kontext angereichert werden, die Triage reproduzierbar funktioniert und vereinbarte Reaktionswege tatsächlich greifen.

     

    Die Wirksamkeit entsteht damit als zusammenhängende Qualitätskette: Datenqualität und Telemetrie schaffen die Grundlage, Detection erzeugt verwertbare Hinweise, Triage und Untersuchung bewerten den Kontext, Response begrenzt die Auswirkungen und Lessons Learned verbessern den Betrieb.

  5. 5

    Eigenbetrieb, Hybrid oder Managed?

    Nicht jedes Unternehmen muss alle SOC-Funktionen selbst betreiben. Entscheidend sind Kontrolle, internes Know-how, Betriebszeiten, vorhandene Technologien und verfügbare Security-Ressourcen.

     

    Für die Entscheidung sollten Unternehmen mindestens fünf Fragen beantworten: Welche Betriebszeiten werden benötigt? Welche Fähigkeiten müssen intern verbleiben? Wer darf technische Reaktionen freigeben? Welche Daten dürfen eine externe Plattform erreichen? Und wer trägt im Incident die operative Verantwortung?

     

    Managed SOC oder eigenes SOC? Lesen Sie im Blog, welche Kosten und Betriebsmodelle Sie bei der Entscheidung berücksichtigen sollten.

Für welche Unternehmen lohnt sich ein SOC?

Eine SOC-Fähigkeit wird insbesondere dann relevant, wenn ein Unternehmen sicherheitskritische Systeme kontinuierlich überwachen sowie relevante Vorfälle strukturiert analysieren und behandeln muss. Dafür muss nicht zwangsläufig ein komplettes eigenes SOC aufgebaut werden.

Ob ein eigenes, hybrides oder extern betriebenes Modell geeigneter ist, hängt unter anderem von Unternehmensgröße, Risikoexposition, regulatorischen Anforderungen, eigener Security-Expertise, gewünschter Betriebszeit und den vorhandenen Security-Technologien ab. 

Ein SOC ist insbesondere dann sinnvoll, wenn Sicherheitsereignisse aus mehreren Systemen korreliert, außerhalb regulärer Arbeitszeiten bewertet oder nach verbindlichen Eskalations- und Response-Prozessen behandelt werden müssen. Wer externe Unterstützung erwägt, sollte neben den technischen Leistungen insbesondere Verantwortlichkeiten, Betriebszeiten, Eskalationsprozesse, Response-Befugnisse, Datenstandort und Integrationsmöglichkeiten betrachten.

Wie misst man, ob ein SOC wirkt?

Die Wirksamkeit eines SOC sollte nicht allein an der Anzahl erzeugter oder geschlossener Alarme gemessen werden. Entscheidend ist, ob relevante Angriffe zuverlässig erkannt, richtig bewertet und angemessen behandelt werden.

Operative Kennzahlen wie MTTD, MTTA und MTTR können diese Bewertung unterstützen. Ebenso wichtig sind Datenqualität, Detection Coverage, Fehlalarmquote, Eskalationsqualität und die Wirksamkeit der Reaktionsprozesse. Ergänzend sollte betrachtet werden, ob kritische Datenquellen verfügbar sind, Detection Use Cases regelmäßig getestet werden, Fälle nachvollziehbar dokumentiert sind und Verbesserungsmaßnahmen nach Incidents tatsächlich umgesetzt werden.

Häufige Fragen zum Security Operations Center

Was ist ein SOC und was macht es?

Ein Security Operations Center ist eine zentrale Security-Funktion aus Menschen, Prozessen und Technologien. Es überwacht sicherheitsrelevante Systeme und Daten, analysiert mögliche Bedrohungen und unterstützt oder steuert die Reaktion auf Sicherheitsvorfälle.

Was ist der Unterschied zwischen SOC und NOC?

Ein SOC konzentriert sich auf Cyber Security und Sicherheitsvorfälle. Ein Network Operations Center fokussiert sich primär auf Betrieb und Verfügbarkeit der Infrastruktur.

Braucht jedes Unternehmen ein eigenes SOC?

Nein. Entscheidend ist das benötigte Security-Niveau, nicht ob alle erforderlichen Personen und Technologien intern betrieben werden.

Was kostet ein SOC?

Das lässt sich nicht pauschal beantworten. Die Kosten hängen von Betriebsmodell, Personalbedarf, Technologien, Datenvolumen, Betriebszeiten und Scope ab.

Arbeitet ein SOC nur reaktiv oder auch proaktiv?

Ein modernes SOC kann reaktive und proaktive Aufgaben übernehmen. Neben Monitoring und Incident Response gehören je nach Scope auch Detection Engineering, Threat Intelligence und Threat Hunting dazu.

Wie viele Alarme bearbeitet ein SOC pro Tag?

Dafür gibt es keine belastbare allgemeingültige Zahl. Das Volumen hängt von Unternehmensgröße, Telemetrie, Detection Content, Tooling und der Definition eines Alarms ab.

SOC-Readiness-Assessment
Welches SOC-Modell passt zu Ihrer Organisation?

Im SOC-Readiness-Assessment klären wir Ressourcen, Betriebszeiten, Datenquellen, regulatorische Anforderungen und Verantwortlichkeiten. Im Gespräch ordnen wir ein, ob ein eigenes, hybrides oder Managed SOC zu Ihrem Zielbild passt.

SOC-Readiness-Assessment anfragen
< Zurück zur Übersicht
SOC Managed SOC MSSP
axians-secure.de | Insights | Blog | Security Operations Center (SOC): Definition, Aufgaben, Team und Aufbau