Was ist ein System zur Angriffserkennung?
Das IT-SiG 2.0 definiert Angriffserkennungssysteme als „durch technische Werkzeuge und organisatorische Einbindung unterstützte Prozesse zur Erkennung von Angriffen auf informationstechnische Systeme“.
Ein SzA ist kein fertiges Produkt, das man einkauft und in Betrieb nimmt. Es ist das Zusammenspiel von drei Elementen: technischen Werkzeugen zur Protokollierung und Detektion, definierten Prozessen für Betrieb und Reaktion sowie qualifizierten Spezialisten, die Alarme bewerten und Vorfälle managen. Erst alle drei zusammen ergeben ein wirksames System zur Angriffserkennung.
- ■Systembetrieb
- ■Sicherheitsvorfallprozess (Reaktion)
- ■Notfallmanagement
- ■Meldeprozesse (§8b BSIG)
- ■Betrieb der Werkzeuge
- ■Threat Management
- ■Datenanalyse & Alarmauswertung
- ■Sicherheitsvorfälle managen
In Anlehnung an: Sascha Jäger, vgbe energy journal, Nr. 9/2022, S. 50–60
Gesetzliche Grundlage ist §8a Abs. 1a BSIG in der Fassung des IT-Sicherheitsgesetzes 2.0 (IT-SiG 2.0). Die Umsetzungsfrist endete am 1. Mai 2023: KRITIS-Betreiber, die bis dahin kein geeignetes SzA eingeführt haben, verstoßen gegen eine Rechtspflicht und riskieren Bußgelder sowie Haftungsfolgen im Schadensfall. Durch die NIS2-Richtlinie und deren nationaler Umsetzung (KRITIS-DachG) wird der Betreiberkreis künftig erheblich ausgeweitet: Viele Unternehmen, die bisher nicht als KRITIS galten, werden vergleichbare Anforderungen an Angriffserkennung und Meldepflichten erfüllen müssen.
Technisch umfasst der Begriff SzA verschiedene Produktkategorien, die in der Praxis häufig kombiniert werden: Network Detection and Response (NDR) für netzwerkbasierte Erkennung, Endpoint Detection and Response (EDR) für endpunktbasierte Erkennung, Security Information and Event Management (SIEM) für die Korrelation und Auswertung von Ereignissen sowie Extended Detection and Response (XDR), das mehrere Schichten integriert. Welche Kombination für den jeweiligen Betreiber geeignet ist, hängt vom angestrebten BSI-Umsetzungsgrad und der konkreten Infrastruktur ab.
Eine wichtige Abgrenzung für Vergabeverfahren: Jedes SzA ist funktional ein SOC, aber nicht jedes SOC erfüllt die SzA-Anforderungen. Ein Security Operations Center (SOC) kann Penetrationstests, Red-Team-Betrieb und Compliance-Monitoring umfassen, also Leistungen, die über den SzA-Scope hinausgehen. Umgekehrt genügt ein SOC ohne lückenlose Protokollierung aller KRITIS-relevanten Log-Quellen, ohne nachgewiesene BSI-Detektionsabdeckung und ohne dokumentierte §8b-Meldeketten nicht den Anforderungen der OH-SzA. Das LV muss deshalb die SzA-spezifischen Leistungen explizit benennen statt pauschal ein SOC zu beschaffen.
Für Vergabestellen folgt daraus eine konkrete Anforderung an das Leistungsverzeichnis: Das BSI prüft nicht, ob ein bestimmtes Produkt vorhanden ist, sondern ob die Organisation Angriffe in angemessener Zeit erkennen, dokumentieren und melden kann. Beschafft wird also eine nachgewiesene Erkennungsleistung, kein Tool. Diesen Unterschied muss das LV abbilden.
Die verbindliche Referenz für die inhaltliche Ausgestaltung dieser Erkennungsleistung ist die Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung, Version 1.1 (BSI, November 2024). Sie definiert 217 konkrete Anforderungen in sechs Kategorien und unterscheidet dabei nach Verbindlichkeitsstufen (MUSS, SOLL, KANN). Alle nachfolgenden Abschnitte beziehen sich auf diese aktuelle Fassung.
BSI-Umsetzungsgrad und Verbindlichkeitsstufen
Die BSI-OH verwendet kein 3-stufiges Reifegrad-Modell, sondern ein 6-stufiges Umsetzungsgradmodell (Stufen 0–5). Auditoren nutzen es im Prüfzyklus nach §8a Abs. 3 BSIG. Entscheidend für KRITIS-Betreiber: Unterhalb von Stufe 3 gilt die gesetzliche Pflicht nach §8a Abs. 1a BSIG als nicht erfüllt.
Neben dem Umsetzungsgrad verwendet die BSI-OH die Verbindlichkeitsstufen MUSS, SOLL und KANN. Sie bestimmen, wann eine Anforderung prüfungsrelevant ist:
| MUSS (129 Anforderungen) | Beim ersten BSI-Prüfzyklus vollständig zu erfüllen. Nicht erfüllte MUSS-Kriterien gelten als Compliance-Verstoß nach §8a BSIG. |
| SOLL (82 Anforderungen) | Spätestens ab dem zweiten Prüfzyklus (nach zwei Jahren) zu erfüllen. Im LV sollte der Zeitpunkt der SOLL-Erfüllung als vertragliche Milestone-Position verankert werden. |
| KANN (6 Anforderungen) | Optionale Erweiterungen, die bei angestrebtem Umsetzungsgrad 5 oder erhöhtem Schutzbedarf relevant werden. |
Der angestrebte Umsetzungsgrad muss in der Bedarfsbeschreibung explizit ausgewiesen werden. Wird er nicht genannt, interpretieren Bieter die Anforderungen unterschiedlich: die Angebote werden unvergleichbar, und nach Zuschlag entstehen Nachtragsstreitigkeiten über den Leistungsumfang.
Die BSI-Daten zeigen: Mehr als zwei Jahre nach der gesetzlichen Frist vom 1. Mai 2023 erfüllen in den meisten Sektoren 40 bis 74 Prozent der KRITIS-Betreiber die Mindestanforderungen nicht. Im Sektor Transport & Verkehr sind drei von vier Betreibern unterhalb von Stufe 3, im Energiesektor gilt das für jeden zweiten. Das ist kein theoretisches Risiko: Staatlich gesponserte Angreifergruppen richten ihre Kampagnen seit Jahren gezielt auf kritische Infrastrukturen aus. Angriffe auf Energieversorger in der Ukraine (2015, 2016), auf Krankenhäuser in Deutschland und den USA sowie auf Häfen in Rotterdam (2017) und Antwerpen (2021) haben konkrete Konsequenzen gezeigt. Stufe 3 ist kein Best-Practice-Ziel, sondern gesetzlich vorgeschriebenes Minimum. Wer als Vergabestelle ein LV erstellt, beschafft genau diese Grundfähigkeit zur Angriffserkennung, oder eben nicht.
Anforderungsübersicht nach BSI OH-SzA v1.1
Die 217 Anforderungen sind in sechs Kategorien unterteilt, die sich drei Kernbereichen zuordnen lassen. Zusätzlich gibt es fünf übergreifende Anforderungen als technisch-organisatorisches Fundament.
Risikobasierte Planung der Logsources: Welche IT- und OT-Systeme werden erfasst? Welche Netzbereiche, Datenflüsse und Änderungsprozesse müssen dokumentiert werden? Die Planung bestimmt den tatsächlichen Sichtbarkeitsradius des späteren Systems.
Technische Erfassung aller sicherheitsrelevanten Ereignisse mit Zeitsynchronisation, zentrale Speicherung, Filterung, Normalisierung und Korrelation. Datenschutzkonforme Handhabung personenbezogener Protokolldaten und Einhaltung gesetzlicher Löschfristen.
Konzeption der Detektionslogik: Definition von Detektionsregeln und Use-Case-Bibliothek, Alarm- und Eskalationsverfahren, Zuständigkeiten für die Alarmbearbeitung sowie Abdeckung der Bedrohungslandschaft anhand von Risikoanalyse und MITRE ATT&CK.
Technische Erkennungsmaßnahmen: Netzwerk-IDS (NIDS), Host-IDS (HIDS), Malware-Erkennung, Ereigniskorrelation und Einsatz von Threat Intelligence. Mit 101 Anforderungen der umfangreichste Bereich, davon 47 SOLL erst ab dem zweiten Prüfzyklus fällig.
Prozesse nach einem erkannten Angriff: Vorfallklassifizierung, definierte Reaktionsverfahren, Eskalationspfade, Personaleinsatz und forensische Dokumentation. Meldepflichten nach §8b BSIG müssen das System direkt unterstützen. Der Bereich Reaktion wird in vielen Ausschreibungen vollständig ausgelassen, obwohl alle 44 Anforderungen BSI-prüfungsrelevant sind.
Unsere Einschätzung zur Orientierungshilfe
Wir sehen die BSI OH-SzA als bedeutenden Fortschritt für die strukturierte Umsetzung von Angriffserkennung in KRITIS-Umgebungen. Gleichzeitig haben wir in Projekten, die wir begleitet haben, Grenzen des Ansatzes beobachtet, die Vergabestellen kennen sollten, um ein LV zu schreiben, das über die bloße Compliance-Erfüllung hinausgeht.
Was wir an der OH-SzA als echten Mehrwert sehen: Erstmals existiert für KRITIS-Betreiber ein auditierter Rahmen, der Governance, technische Implementierung und operativen Betrieb in einer einzigen Anforderungsstruktur verbindet. Die MUSS/SOLL/KANN-Unterscheidung gibt Vergabestellen eine klare Grundlage für die Priorisierung von LV-Positionen: MUSS-Kriterien müssen als zwingende Eignungsanforderungen formuliert werden, SOLL-Kriterien eignen sich als Zuschlagskriterien mit einem definierten Erfüllungszeitpunkt. Die Sechs-Kategorien-Struktur lässt sich direkt in die Gliederung eines Leistungsverzeichnisses überführen und macht Angebote vergleichbar.
Reaktiver Grundansatz. Die OH-SzA basiert auf dem Prinzip der Angriffserkennung durch Mustererkennung, also dem Identifizieren bekannter Bedrohungssignaturen und -muster. Neuartige Angriffe, sogenannte Zero-Day-Exploits, sowie Techniken, die noch nicht in Signaturdatenbanken oder Threat-Intelligence-Feeds abgebildet sind, bleiben in einem rein OH-SzA-konformen System unerkannt. Das ist kein Umsetzungsfehler, sondern eine systemimmanente Grenze des Detektionsparadigmas.
OT-Lücke in der Detektionstiefe. Der Schwerpunkt der OH-SzA liegt auf IT-Netzwerkprotokollen. ICS-spezifische Protokolle wie Modbus, OPC UA oder Profinet sind zwar adressiert, aber nicht mit derselben Anforderungstiefe wie IT-Protokolle. Betreiber dezentraler OT-Netze, etwa in der Energie- und Wasserversorgung, sollten prüfen, ob die expliziten OT-Anforderungen ihrer Umgebung im LV zusätzlich spezifiziert werden müssen.
Compliance ist nicht gleich Wirksamkeit. Ein System, das alle 129 MUSS-Kriterien erfüllt, kann im operativen Betrieb dennoch wirkungslos sein, wenn die Alarmqualität zu niedrig ist. Betreiber, die täglich tausende False-Positive-Alarme erhalten, werden das System in der Praxis nicht operativ nutzen. Das LV sollte daher operative Qualitätskennzahlen ergänzen: eine maximale False-Positive-Rate (z.B. unter 1 % im 30-Tage-Mittel), einen MTTD-Zielwert (Mean Time to Detect) für kritische Angriffsklassen und eine jährliche Red-Team-Validation als Vertragsbestandteil.
Wir empfehlen, die BSI-OH-Konformität im Leistungsverzeichnis als Mindestanforderung zu verankern und sie durch prüfbare Qualitätskriterien zu ergänzen, die über die reine Compliance hinausgehen.
Typische Vergabesituationen in KRITIS-Sektoren
In Projekten, die wir begleitet haben, scheitern Ausschreibungen für Systeme zur Angriffserkennung selten an fehlenden Budgets, sondern häufig an mangelhaft formulierten Leistungsverzeichnissen. Wir haben zwei Situationen beobachtet, die als strukturelle Muster in unterschiedlichen KRITIS-Sektoren immer wieder auftreten.
Wir haben in einem Projekt im KRITIS-Sektor Gesundheit folgende Situation erlebt: Das Krankenhaus hatte den Netzwerkschutz über Standard-IT-Protokolle ausgeschrieben. Nach Zuschlag stellte sich heraus, dass die Medizintechnik über herstellerspezifische Protokolle kommuniziert, die das beschaffte NDR-System nicht erkennt. Bildgebungssysteme, Infusionspumpen und OP-Steuerungssoftware blieben vollständig unüberwacht. Das LV hatte lediglich "vollständige Netzwerküberwachung" gefordert, ohne die konkreten Segmente und Protokolle zu benennen. Der Anbieter hatte sich vertragskonform verhalten.
In einem weiteren Fall, den wir begleitet haben, hatte ein ÖPNV-Betreiber ausschließlich eine On-Premises-Lösung ausgeschrieben, da die Leitstelle aus Datenschutzgründen keine Cloud-Anbindung vorsah. Im Vergabeverfahren stellte sich heraus, dass die SCADA-Systeme zur Netzsteuerung teilweise über einen Cloud-basierten Fernwartungszugang des Herstellers erreichbar waren. Der günstigste Bieter ohne Cloud-Connector erhielt den Zuschlag. Der kritischste Angriffspfad blieb dauerhaft außerhalb des Überwachungsbereichs, weil die Deployment-Architektur im LV nicht vollständig beschrieben worden war.
Pflichtpositionen im Leistungsverzeichnis
Die folgenden Positionen entsprechen den sechs BSI-OH-SzA-Anforderungskategorien und sind im LV unverzichtbar. Fehlen sie, schützt das LV den Auftraggeber weder rechtlich noch technisch:
Erkennungsumfang: Netzwerkprotokolle (mindestens TCP/IP, DNS, HTTP/S, SMB, RDP), bei OT-Umgebungen zusätzlich ICS-Protokolle (Modbus, OPC UA, Profinet). Nicht jedes NDR-System unterstützt OT-Protokolle; ohne explizite LV-Position wird das nicht angeboten.
Durchsatz und Skalierung: Netzwerksensoren müssen den tatsächlichen Spitzendurchsatz der zu überwachenden Segmente abdecken. Mengengerüst ist Pflicht: Anzahl Netzwerksegmente, Durchsatz in Gbit/s, Anzahl überwachter Endpunkte. Fehlende Mengenangaben führen zu Angeboten, die die reale Umgebung nicht abdecken.
Protokollierungsumfang nach OH-SzA Kategorie 2 und 3: Das LV muss die Mindest-Logsources benennen: alle sicherheitsrelevanten IT-Systeme, zentrale Anwendungen, Firewall, Proxy, Active Directory sowie die in der Planungsphase identifizierten OT-Systeme. Die zentralisierte Speicherung, Filterung und Korrelation der Protokolldaten ist als technische Leistung explizit zu fordern.
Datenaufbewahrung: Das BSI empfiehlt mindestens 90 Tage für Rohdaten und 12 Monate für aggregierte Ereignisprotokolle [BSI OH-SzA v1.1, Kap. 3.3, Nov. 2024]. Diese Fristen sind als Mindestanforderung ins LV aufzunehmen, anderenfalls kauft man ein System, das im Nachhinein keine forensische Auswertung erlaubt.
Detektionsqualität nach MITRE ATT&CK: Bieter müssen die abgedeckten Taktiken und Techniken des MITRE ATT&CK-Frameworks als messbaren Wert angeben (z.B. Abdeckung von mindestens 70 % der Taktiken TA0001 bis TA0011). Ohne diese Anforderung gibt es nach Zuschlag keine Grundlage für die Bewertung der tatsächlichen Erkennungsleistung.
SIEM-Integration: Offene Schnittstellen (Syslog, CEF, LEEF, REST-API) müssen explizit gefordert werden. Proprietäre Formate ohne Exportmöglichkeit führen zu Vendor-Lock-in und erschweren den späteren Wechsel.
Meldepflicht-Unterstützung: §8b BSIG verpflichtet KRITIS-Betreiber zur Meldung erheblicher IT-Störungen. Das SzA muss Ereignisse so aufbereiten, dass die gesetzlichen Meldeinhalte (Zeitpunkt, Dauer, Art, betroffene Infrastruktur, Auswirkungen) vollständig und fristgerecht an das BSI übermittelt werden können.
Reaktionszeiten und SLA: Alarmierungszeiten nach Erkennung eines Ereignisses müssen als SLA definiert werden, z.B. kritische Alarme innerhalb von 5 Minuten, Standard-Alarme innerhalb von 30 Minuten. Zusätzlich ist eine maximale False-Positive-Rate zu vereinbaren (z.B. unter 1 % im 30-Tage-Mittel). Ohne SLA-Definition gibt es nach Zuschlag keinen vertraglichen Hebel bei unzureichender Alarmierungsqualität.
Häufige Anbieter in SzA-Vergabeverfahren
In der Praxis begegnen Vergabestellen bei SzA-Ausschreibungen immer wieder denselben Anbietern und Lösungsklassen. Die folgende Übersicht zeigt, welche Produkte und Dienstleister typischerweise in KRITIS-Projekten eingesetzt werden, gegliedert nach den drei BSI-Kernbereichen Protokollierung, Detektion und Reaktion sowie OT-spezifischen Lösungen.
Splunk
IBM QRadar
Microsoft Sentinel
CrowdStrike
Exabeam
Darktrace
Vectra AI
ExtraHop
Corelight
Elastic Security
Nozomi Networks
Claroty
Dragos
Rhebo
Cisco Cyber Vision
Arctic Wolf
BlueVoyant
Sophos
InfoGuard
T-Systems SOCDie Auflistung ist exemplarisch und erhebt keinen Anspruch auf Vollständigkeit.
Typische Fehler bei SzA-Ausschreibungen
Fehler 1: Technologie statt Erkennungsleistung ausschreiben. Wir sehen häufig, dass Vergabestellen den Systemdurchsatz in Gbit/s als Hauptmerkmal ausschreiben. Das greift zu kurz: Ein System mit 40 Gbit/s Durchsatz nützt wenig, wenn die Signaturdatenbank veraltet ist oder OT-Protokolle nicht erkannt werden. Besser: Erkennungsleistung funktional beschreiben. Beispiel: "Erkennung von Lateral-Movement-Techniken gemäß MITRE ATT&CK Tactic TA0008 in Echtzeit, Alarmierung innerhalb von 60 Sekunden nach Ereignis, False-Positive-Rate unter 0,5 % im 30-Tage-Mittel." Das ist prüfbar und schützt den Auftraggeber vor teuren Fehlinvestitionen.
Fehler 2: Umsetzungsgrad nicht spezifiziert. In unserer Erfahrung ist das einer der häufigsten Fehler: Ohne explizite Angabe des angestrebten Umsetzungsgrads (Stufe 0 bis 5 nach BSI OH-SzA) beschaffen Auftraggeber faktisch Stufe 2, obwohl für die BSI-Prüfung mindestens Stufe 3 (alle MUSS erfüllt) erforderlich ist. Das BSI kann im Prüfzyklus feststellen, dass die Pflicht nach §8a Abs. 1a BSIG nicht erfüllt ist, auch wenn ein teures System im Einsatz ist.
Fehler 3: OT-Umgebungen nicht berücksichtigt. In Energie-, Wasser- und Produktionsinfrastrukturen laufen OT-Systeme auf Protokollen, die Standard-NDR-Lösungen nicht erkennen. Wer den Netzwerkplan nicht als Grundlage der Ausschreibung heranzieht, beschafft ein System mit blinden Flecken in den kritischsten Netzsegmenten.
Fehler 4: Wartung und Updates nicht im LV. Signaturdatenbanken und Threat-Intelligence-Feeds veralten innerhalb von Wochen. Werden Update-Intervalle, SLA für Signaturaktualisierungen und Incident-Response-Unterstützung nicht als Positionen ausgeschrieben, entstehen nach Zuschlag teure Nachtragsverhandlungen.
Fehler 5: Zuschlagskriterien preisorientiert. Wir empfehlen, bei sicherheitskritischen Systemen wie SzA den Preis nicht höher als 40 % zu gewichten. Eine Preis-Gewichtung von über 60 % führt systematisch zur Auswahl des günstigsten statt des geeignetsten Anbieters. Unsere Empfehlung: technische Erkennungsqualität mindestens 40 %, Preis maximal 40 %, Referenzen und Support 20 %.
Fehler 7: Verantwortlichkeiten zwischen IT, Security und SOC nicht geregelt. Die BSI-Prüfung unterscheidet zwischen zentraler Angriffserkennung (SOC/SIEM-Ebene) und dezentraler Umsetzung im laufenden Betrieb (Logs, Systeme, lokale Prozesse). Ein LV, das diese Trennung nicht abbildet, erzeugt nach Zuschlag ungeklärte Zuständigkeiten: Wer ist verantwortlich, wenn ein dezentrales System keine Logs liefert? Wer konfiguriert neue Detektionsregeln? Wer eskaliert im Nachtbetrieb? Die Leistungsbeschreibung muss Rollen, Schnittstellen und Eskalationspfade zwischen IT, Security-Team und SOC explizit benennen.
Fehler 6: BSI-Kategorie 6 (Reaktion) nicht ausgeschrieben. Viele LVs decken Protokollierung und Detektion ab, übergehen aber die sechste OH-SzA-Kategorie vollständig. Ohne vertragliche Verankerung von Incident-Response-Workflows, Eskalationspfaden, Vorfallklassifizierung und Wiederherstellungsprozessen gibt es nach Zuschlag keine Grundlage, den Dienstleister im Ernstfall zur Reaktion zu verpflichten. Die 44 Anforderungen der Kategorie Reaktion sind ebenso prüfungsrelevant wie die Detektionsanforderungen.
Vom Muster-LV bis zur individuellen Beratung: drei Wege, mit denen wir Vergabestellen bei SzA-Ausschreibungen unterstützen.
Quellen
- Bundesamt für Sicherheit in der Informationstechnik: "Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung (OH-SzA), Version 1.1", November 2024, bsi.bund.de.
- Rhebo GmbH: "OT Security Monitoring: Wie sieht ein System zur Angriffserkennung in der OT nach IT-SiG 2.0 aus?", 2023, rhebo.com.
- MITRE Corporation: "MITRE ATT&CK Enterprise Matrix", 2024, attack.mitre.org.
- Bundesamt für Sicherheit in der Informationstechnik: "Fragen und Antworten zum Einsatz von Systemen zur Angriffserkennung (§ 8a Abs. 1a BSIG)", bsi.bund.de.
- secunet Security Networks AG / VKU KommunalDigital: "Systeme zur Angriffserkennung gemäß IT-Sicherheitsgesetz 2.0", YouTube, Januar 2024.
- Sascha Jäger: "Angriffserkennung in Leit- und Fernwirktechnik als Dienstleistung", vgbe energy journal, Nr. 9/2022, S. 50–60.
- Paul Weissmann / OpenKRITIS: "KRITIS-Betreiber und Systeme zur Angriffserkennung (SzA)", Version 1.1, Mai 2023, openkritis.de.
- Bundesamt für Sicherheit in der Informationstechnik: "KRITIS-in-Zahlen: SzA-Umsetzungsgrade nach Sektor", bsi.bund.de, Datenstand 31.12.2025.