SOC 24/7 im Jahr 2026: Arbeitsweise, rechtliche Anforderungen und Wirksamkeitsprüfung

Ein SOC beobachtet laufend die Umgebung, qualifiziert Alarme, untersucht und begrenzt Vorfälle und eskaliert Fälle an Systemverantwortliche, Leitung und zuständige Reaktionsteams. Es verbindet technische Arbeit mit Entscheidungen. Ein Analyst muss nicht nur wissen, dass ein Konto eine ungewöhnliche Operation ausgeführt hat, sondern auch, ob es privilegiert ist, welchen Geschäftsprozess es unterstützt und welche Folgen eine Sperrung hätte.

Die Begriffe für diese Dienste sind nicht austauschbar:

• SIEM sammelt und korreliert Daten; es ist ein Werkzeug, kein Reaktionsteam.
• SOAR (Security Orchestration, Automation and Response) verbindet Sicherheitswerkzeuge, führt genehmigte Playbooks aus und dokumentiert deren Ausführung. Es kann Alarmanreicherung, Fallerstellung, Geräteisolation oder Kontosperrung automatisieren, ersetzt aber weder das SOC noch die menschliche Verantwortung für Entscheidungen mit großer Wirkung.
• SOC bezeichnet die organisatorische Fähigkeit zu Erkennung, Analyse und Reaktion.
• CSIRT/CERT ist ein Reaktionsteam mit festgelegtem Zuständigkeitsbereich. Es kann in derselben Organisation wie das SOC tätig sein, hat aber meist eine breitere Koordinations- und Kommunikationsfunktion.
• MDR ist ein verwalteter Erkennungs- und Reaktionsdienst. Er kann nur Endgeräte oder wesentlich mehr Telemetrie umfassen; der Name sagt nichts über die tatsächliche Abdeckung aus.

Ein eigenes SOAR ist für Datensouveränität und Vertraulichkeit besonders wichtig. Die Plattform erhält häufig nicht nur Zugriff auf Alarme, sondern auch auf Logs, Identitätsdaten, Sicherheitskonfigurationen, API-Token und Beweismaterial aus Vorfällen. 4crypto.eu entwickelt ein eigenes SOAR, das für den Betrieb ohne Kommunikation mit externen Automatisierungs- oder KI-Anbietern in den USA oder Asien ausgelegt ist. So können Daten und Playbook-Ausführung in einer kontrollierten Umgebung in Polen oder im EWR verbleiben, unnötige Übermittlungen aus dem EWR begrenzt und Abhängigkeiten von weiteren Unterauftragnehmern reduziert werden.

Ein Serverstandort in Europa allein belegt jedoch keine Souveränität. Zu prüfen sind Eigentümer der Infrastruktur, Jurisdiktion der Anbieter, Auftragsverarbeiter, administrativer Fernzugriff, Produkttelemetrie, Backups, Schlüsselverwaltung und sämtliche ausgehenden Verbindungen. Übermittlungen personenbezogener Daten außerhalb des EWR unterliegen Kapitel V der DSGVO ^[12]; das KSC-Gesetz verlangt zudem, Sicherheit und Kontinuität der Lieferkette im Risikomanagement zu berücksichtigen ^[7]. Die Aussage, dass keine Verbindungen zu externen Diensten bestehen, sollte durch Architektur, Vertrag, Unterauftragnehmerverzeichnis und Netzverkehrstests bestätigt werden.

Das Betriebsmodell kann intern, extern oder gemeinsam verwaltet sein. Die Wahl sollte sich aus Risiko, vorhandenen Kompetenzen, erforderlicher Reaktionszeit, Datenjurisdiktion und der sicheren Übertragung von Befugnissen ergeben. SOC-Forschung zeigt, dass die Abstimmung von Organisation, Prozessen und Werkzeugen wichtiger ist als die Bezeichnung des Modells ^[19].

Ein 24/7-Betrieb ist sinnvoll, wenn ein kritischer Dienst ununterbrochen läuft, Verzögerungsschäden schnell wachsen oder kurze Eskalationsfristen gelten. Dafür muss nicht jede Rolle jederzeit voll besetzt sein. Automatisierte Überwachung mit einem rund um die Uhr verfügbaren Analysten der ersten Linie und Bereitschaftsdienst für Spezialisten kann angemessen sein. Voraussetzung sind eine tatsächlich erreichbare entscheidungsbefugte Person auf Kundenseite und ein vorab vereinbarter Handlungsspielraum.

Die SOC-Arbeit bildet einen geschlossenen Kreislauf. Jede Stufe hängt von der Qualität der vorherigen ab; mangelhafte Sichtbarkeit lässt sich daher nicht allein durch Automatisierung beheben.

1. Umfang und Prioritäten. Zuerst sind kritische Dienste, Ressourcen, Identitäten und Datenflüsse festzulegen. Daraus folgen Missbrauchsszenarien und Telemetriequellen. Eine Geräteliste ohne Bezug zu Geschäftsdiensten reicht nicht aus.
2. Zuverlässige Datenerfassung. Nützlich sind unter anderem Identitäts- und Authentifizierungslogs, EDR, Netzsysteme, E-Mail, Cloud, Anwendungen, Edge-Geräte, Hypervisoren und Administrationswerkzeuge. Das SOC sollte Vollständigkeit, Verzögerung, Zeitsynchronisierung, Integrität und Aufbewahrung kontrollieren. Ein fehlendes Log muss wie ein ausgefallener Sensor erkannt werden.
3. Normalisierung und Kontext. Ein Ereignis wird erst nützlich, wenn es mit Verantwortlichem, Kritikalität, Schwachstellen, Nutzerrolle und früherer Aktivität verknüpft ist. IP-Geolokalisierung oder ein einzelner Reputationsindikator sind nur Indizien, kein Angriffsnachweis.
4. Erkennung. Regeln, Verhaltensanalyse und Threat Intelligence sollten konkrete Hypothesen beantworten. MITRE ATT&CK ordnet Wissen über Angreiferverhalten und hilft, Abdeckung zu beschreiben, ist aber kein Wirksamkeitszertifikat. Version 19.2 ist ein fortentwickelter Katalog aus Taktiken, Techniken, Detektionsstrategien und Analysen ^[16].
5. Bewertung und Untersuchung. Der Analyst klärt, ob der Alarm tatsächliche Aktivität beschreibt, welchen Umfang und Einfluss sie hat und was noch unbekannt ist. Die Schlussfolgerung sollte anhand von Zeitachse, Belegen, Datenquellen und Konfidenzniveau nachvollziehbar sein.
6. Reaktion. Geräteisolation, Sitzungsentzug oder die Sperrung eines Kontos beziehungsweise einer Adresse können Schaden begrenzen, aber auch Dienste unterbrechen. Automatische Aktionen sollten vorab genehmigt, auf gut verstandene Fälle begrenzt, protokolliert und umkehrbar sein. NIST SP 800-61 Rev. 3 behandelt Incident Response als Teil des Risikomanagements und nicht als isolierte Phase nach einem Alarm ^[14].
7. Rückkopplung. Nach einem Vorfall müssen Regeln, Konfiguration, Architektur, Anweisungen und Schulungen verbessert werden. Sonst bearbeitet das SOC wiederholt dasselbe Problem, statt das Risiko zu senken.

Ein SOC sieht nicht alles. Verschlüsselung beschränkt die Inhaltsanalyse, Edge-Geräte und SaaS-Systeme liefern möglicherweise unzureichende Telemetrie, und Angreifer können Sensoren deaktivieren oder Logs löschen. Zustand der Datenquellen, Beweiskopien und unabhängige Kontrollen gehören deshalb zur Detektionsarchitektur.

Jahresberichte beschreiben unterschiedliche Datensätze. Ihre Zahlen dürfen weder wie Messungen derselben Grundgesamtheit verglichen noch als Wirksamkeitsversprechen für ein bestimmtes SOC verwendet werden.

• Mandiant M-Trends 2026. Der Bericht basiert auf mehr als 500.000 Untersuchungsstunden aus dem Jahr 2025. Die globale mediane Verweildauer des Angreifers betrug 14 Tage, nach 11 Tagen im Vorjahr; bei Cyberspionage und nordkoreanischen IT-Worker-Fällen lag sie bei 122 Tagen. Schwachstellenausnutzung machte 32% der beobachteten Erstzugangsvektoren aus ^[3]. Dwell Time ist nicht dasselbe wie ein internes MTTD ab Eingang eines Alarms.
• Verizon DBIR 2026. Der Datensatz umfasst mehr als 31.000 Vorfälle und über 22.000 bestätigte Datenschutzverletzungen in 145 Ländern, erfasst von November 2024 bis Oktober 2025. Schwachstellenausnutzung war bei 31% der Verletzungen der anfängliche Vektor; Ransomware kam bei 48% vor ^[4]. Operativ folgt daraus mehr als der Kauf von EDR: Das SOC benötigt Sichtbarkeit auf Edge-Geräte, einen Schwachstellenprozess und Daten zu Abhängigkeiten von Dritten.
• ENISA Threat Landscape 2025. Die Analyse umfasst 4.875 Vorfälle vom 1. Juli 2024 bis 30. Juni 2025. DDoS stellte 77% der erfassten Ereignisse, häufig im Zusammenhang mit Hacktivismus; Ransomware wurde dagegen als Bedrohung mit der größten Wirkung bewertet ^[5]. Ereignismenge ist folglich kein Maß für Schwere.
• CERT Polska für 2025. Das Team erhielt 658.320 Meldungen und registrierte daraus 260.783 eindeutige Vorfälle. Computerbetrug machte 97% der bearbeiteten Vorfälle aus ^[6]. Der Anstieg kann sowohl Angreiferaktivität als auch bessere Erkennung, mehr Bewusstsein und neue Meldekanäle widerspiegeln.

Die Quellen führen zu einem gemeinsamen Schluss: Endpoint-Monitoring bleibt notwendig, reicht aber nicht aus. Ein Detektionsprogramm sollte Identitäten, Webanwendungen, Edge-Infrastruktur, Cloud-Dienste, Backups und Abhängigkeiten von Dritten einbeziehen.

Alarmüberlastung ist nicht nur ein Mengenproblem. Alahmadi, Axon und Martinovic befragten 20 Praktiker schriftlich und interviewten 21 Personen aus sieben SOCs. Sie zeigten, dass "False Positive" sowohl einen fehlerhaften Alarm als auch die korrekte Erkennung legitimer Aktivität bezeichnen kann. Alarme benötigen Kontext, Erklärbarkeit und nachvollziehbare Begründungen ^[2]. Der Titel "99% False Positives" beweist nicht, dass 99% der Alarme eines typischen SOC falsch sind.

Abdeckungslücken sind gefährlicher als das Fehlen eines weiteren Werkzeugs. Eine Organisation kann sehr viele Ereignisse sammeln und dennoch Änderungen an Cloud-Konfigurationen, Administratoraktivität, Vorgänge auf VPN-Geräten oder die Nutzung von Anwendungstoken nicht erfassen. Abdeckung ist anhand von Bedrohungsszenarien und kritischen Ressourcen zu messen und durch kontrollierte Simulationen zu prüfen ^[17][3].

Automatisierung kann gute wie schlechte Entscheidungen beschleunigen. Eine Regel zur Geräteisolation ist wertvoll, wenn das Signal zuverlässig und die Wirkung bekannt ist. Auf einen Domänencontroller oder eine OT-Komponente angewandt, kann derselbe Mechanismus einen schweren Ausfall verursachen. Erforderlich sind Befugnisstufen, vorab genehmigte Aktionen, manuelle Bestätigung und eine Auditspur ^[14].

Kennzahlen sollten Fähigkeit und Ergebnis beschreiben, nicht Aktivität um ihrer selbst willen:

• Anteil kritischer Ressourcen und Szenarien mit geprüfter Telemetrie und funktionierenden Detektionen;
• Zeit bis Bestätigung, Erkennung, Eindämmung und Wiederherstellung, jeweils mit eindeutigem Start und Ende;
• Alarmpräzision, auf anderem Weg entdeckte Übersehungen und Fehlerursachen;
• Zeit zum Schließen von Telemetrie- und Detektionslücken sowie Anteil fristgerecht umgesetzter Maßnahmen nach Vorfällen;
• Fallrückstand, Bereitschaftsbelastung und Qualität der Schichtübergabe.

MTTD allein kann irreführen. Eine Messung ab Alarmerzeugung lässt den Zeitraum zwischen Kompromittierung und Signal unberücksichtigt. Sie darf daher nicht direkt mit Dwell Time aus Mandiant-Untersuchungen oder anders definierten Reaktionszeiten eines Anbieters verglichen werden.

Das polnische KSC-Gesetz in der Fassung vom 23. Januar 2026 trat am 3. April 2026 in Kraft. Einrichtungen, die an diesem Tag die Kriterien einer wesentlichen oder wichtigen Einrichtung erfüllten, haben grundsätzlich zwölf Monate zur Umsetzung der Pflichten aus Kapitel 3, also bis 3. April 2027. Artikel 8 verlangt unter anderem systematisches Risikomanagement, kontinuierliches Monitoring der zur Dienstleistung eingesetzten Systeme und Incident Management. Für einen schwerwiegenden Vorfall sieht Artikel 11 eine unverzügliche Frühwarnung spätestens 24 Stunden nach Erkennung, eine Meldung binnen 72 Stunden und einen Abschlussbericht binnen eines Monats nach der Meldung vor ^[7]. Die Pflichten treffen Einrichtungen, die gesetzliche Kriterien erfüllen und in den Anhängen genannte Tätigkeiten ausüben; sie gelten nicht automatisch für jedes Unternehmen.

NIS2 ist eine Richtlinie, die Polen durch die KSC-Novelle umgesetzt hat. Artikel 21 und 23 sind für die Auslegung des gemeinsamen EU-Modells wichtig; eine polnische Einrichtung sollte ihre konkreten Pflichten jedoch vorrangig anhand des geltenden nationalen Rechts bestimmen ^[8].

DORA gilt seit 17. Januar 2025 für die in der Verordnung aufgeführten Finanzunternehmen. Sie verlangt Mechanismen zur Anomalieerkennung und einen Prozess für das Management IKT-bezogener Vorfälle ^[9]. Die Delegierte Verordnung 2024/1774 konkretisiert unter anderem Sammlung, Überwachung und Analyse von Logs, Alarmpriorisierung und Bearbeitung außerhalb der Arbeitszeit ^[10]. Bei einem schwerwiegenden IKT-bezogenen Vorfall ist die Erstmeldung so früh wie möglich, spätestens vier Stunden nach der Einstufung als schwerwiegend und grundsätzlich spätestens 24 Stunden nach Kenntnis des Vorfalls einzureichen; weitere Fristen regelt Artikel 5 der Delegierten Verordnung 2025/301 ^[11].

Die DSGVO begründet keine allgemeine Pflicht zum Betrieb eines SOC. Artikel 32 verlangt risikogerechte Sicherheitsmaßnahmen. Artikel 33 betrifft Verletzungen des Schutzes personenbezogener Daten, nicht jeden Cybersicherheitsvorfall; der Verantwortliche meldet eine solche Verletzung unverzüglich und möglichst binnen 72 Stunden nach Kenntniserlangung an die Aufsichtsbehörde, es sei denn, dass die Verletzung voraussichtlich kein Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Ein Auftragsverarbeiter informiert den Verantwortlichen unverzüglich ^[12].

Der polnische nationale Interoperabilitätsrahmen (KRI) verlangt von Stellen, die öffentliche Aufgaben erfüllen, ein Informationssicherheitsmanagementsystem und mindestens ein internes Audit pro Jahr. § 19 Abs. 3 verweist ausdrücklich auf PN-ISO/IEC 27001, PN-ISO/IEC 27002 und PN-ISO/IEC 27005. Dies sind Polnische Normen im formalen Sinn-nationale Übernahmen internationaler ISO/IEC-Normen und keine ausschließlich in Polen entwickelten Normen. Die Vorschrift beschreibt einen Weg, die Anforderungen aus § 19 Abs. 1 und 2 als erfüllt anzusehen, verlangt aber weder Zertifizierung noch den Kauf eines SOC. Der gesonderte § 20 betrifft die verpflichtende Protokollierung ausgewählter Handlungen und Aufbewahrungsfristen für Logs ^[13].

Normen und Rahmenwerke haben eine andere Rolle als Gesetze. ISO/IEC 27001:2022 mit Amendment 1:2024 legt Anforderungen an Informationssicherheitsmanagementsysteme fest ^[18]; ISO/IEC 27035-1:2023 beschreibt Grundsätze und Prozesse des Incident Managements ^[15]; NIST CSF 2.0 und SP 800-61 Rev. 3 stellen freiwillige Rahmen für Risiko- und Incident-Management bereit ^[17][14]. Sie können vertraglich verbindlich oder Teil eines gewählten Compliance-Wegs werden, sind aber selbst kein polnisches Recht.

LLM/KI (Sprachmodelle) können Fälle zusammenfassen, Abfragen vorschlagen, Zeitachsen ordnen und beim Erstellen von Regeln helfen. Sie sind jedoch keine unabhängige Beweisquelle. Ergebnisse müssen anhand der Rohtelemetrie geprüft, erzeugte Abfragen oder Skripte vor dem produktiven Einsatz getestet werden.

Die Hauptrisiken sind die Offenlegung von Logs und Kundendaten gegenüber dem Modellanbieter, selbstsicher formulierte Fehlurteile, bösartige Anweisungen in analysierten Inhalten sowie die automatische Ausführung einer Aktion mit zu großer Wirkung. Eine sichere Einführung verlangt Datenminimierung, Mandantentrennung, Zugriffskontrolle, Protokollierung von Eingaben und Antworten, Resilienztests und menschliche Freigabe weitreichender Aktionen.

Aktualisierungen von ATT&CK beeinflussen auch die Gestaltung von Detektionen. In Version 19.2 baut MITRE Detektionsstrategien und Analysen aus, sodass Angreiferverhalten leichter mit benötigter Telemetrie verknüpft werden kann ^[16]. Der Prozentanteil durch ein Produkt "abgedeckter" Techniken bleibt eine schwache Kennzahl: Eine Technik kann viele Varianten haben, und eine Regel ohne geeignete Daten und Tests schafft keine echte Detektionsfähigkeit.

Ein reifes SOC wird daher weniger an der Zahl von Bildschirmen und Alarmen gemessen, sondern an Belegen dafür, dass es relevante Szenarien erkennt, verhältnismäßig reagiert und den Schutz nach einem Ereignis verbessert.