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 (§ 32 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 bis 60
Eingeführt hat die Pflicht das IT-Sicherheitsgesetz 2.0 (IT-SiG 2.0) in § 8a Abs. 1a BSIG alter Fassung: Seit dem 1. Mai 2023 müssen KRITIS-Betreiber Systeme zur Angriffserkennung einsetzen. Seit dem 6. Dezember 2025 gilt das neue BSI-Gesetz, mit dem Deutschland die NIS-2-Richtlinie umgesetzt hat. Die Pflicht steht jetzt in § 31 Abs. 2 BSIG und gilt für Betreiber kritischer Anlagen, den Nachweis gegenüber dem BSI regelt § 39 BSIG (alle drei Jahre). Für Betreiber von Energieversorgungsnetzen und Energieanlagen ist der Einsatz Teil des IT-Sicherheitskatalogs nach § 5c EnWG. Besonders wichtige und wichtige Einrichtungen ohne kritische Anlage trifft keine ausdrückliche SzA-Pflicht, wohl aber Risikomanagementmaßnahmen einschließlich der Bewältigung von Sicherheitsvorfällen (§ 30 BSIG) und die Meldepflicht für erhebliche Sicherheitsvorfälle (§ 32 BSIG).
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: Ein SzA erfüllt viele Funktionen eines 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 Detektionsabdeckung und ohne dokumentierte Meldeketten nach § 32 BSIG 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: Bei der Nachweisprüfung zählt 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 maßgebliche fachliche Referenz für die inhaltliche Ausgestaltung dieser Erkennungsleistung ist die Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung, Version 1.1 (BSI, 18.11.2024). Sie ist nach eigener Aussage keine verbindliche Vorgabe, sondern ein Rahmen, der gleichwertige Alternativen zulässt. Ihre Anforderungen gliedert sie in Protokollierung, Detektion und Reaktion und kennzeichnet sie mit MUSS, SOLLTE und KANN. Unser Mapping-Katalog schlüsselt sie in 217 Einzelanforderungen in sechs Kategorien auf. Alle nachfolgenden Abschnitte beziehen sich auf diese Fassung.
BSI-Umsetzungsgrad und Verbindlichkeitsstufen
Die BSI-OH verwendet kein 3-stufiges Reifegrad-Modell, sondern ein 6-stufiges Umsetzungsgradmodell (Stufen 0 bis 5). Auditoren und Prüfer nutzen es bei der Nachweisprüfung (früher nach § 8a Abs. 3 BSIG, heute nach § 39 BSIG). Entscheidend für KRITIS-Betreiber: Nach der Orientierungshilfe sollte grundsätzlich mindestens Stufe 3 erreicht werden, um die gesetzlichen Anforderungen zu erfüllen. Abweichungen nach unten sind nur mit Angabe von Gründen zulässig.
Neben dem Umsetzungsgrad verwendet die BSI-OH die Modalverben MUSS, SOLLTE (im Katalog unten kurz SOLL) und KANN. Sie bestimmen, für welchen Umsetzungsgrad eine Anforderung zählt (Anzahl jeweils nach unserem Mapping-Katalog):
| MUSS (129 Anforderungen) | Unbedingt zu erfüllen, um Umsetzungsgrad 3 zu erreichen. Nach der OH-SzA sollte mindestens dieser Grad erreicht werden. |
| SOLLTE (82 Anforderungen) | Normalerweise umzusetzen. Wer davon abweicht, muss das sorgfältig abwägen und stichhaltig begründen, um Umsetzungsgrad 4 zu erreichen. Im LV lässt sich festlegen, bis wann der Auftragnehmer welche SOLLTE-Anforderungen abdeckt. |
| KANN (6 Anforderungen) | Nicht zwingend, aber sinnvolle Ergänzungen, wenn Umsetzungsgrad 5 angestrebt wird. |
Der angestrebte Umsetzungsgrad muss in der Bedarfsbeschreibung explizit ausgewiesen werden. Wird er nicht genannt, interpretieren Bieter die Anforderungen unterschiedlich: Die Angebote werden schwer vergleichbar, und nach Zuschlag drohen Streitigkeiten über den Leistungsumfang.
Die BSI-Daten zeigen: Mehr als zwei Jahre nach der gesetzlichen Frist vom 1. Mai 2023 lagen in sechs von sieben ausgewiesenen Sektoren 40 bis 73 Prozent der ausgewerteten Nachweise unter Umsetzungsgrad 3 (Stichtag 31.12.2025). Im Sektor Transport und Verkehr betraf das drei von vier Nachweisen, im Energiesektor gut die Hälfte. Das ist kein theoretisches Risiko: Staatlich gesteuerte Angreifergruppen richten ihre Kampagnen seit Jahren gezielt auf kritische Infrastrukturen aus. Angriffe auf Energieversorger in der Ukraine (2015, 2016), auf Krankenhäuser und auf Hafenbetreiber haben konkrete Folgen gezeigt. Stufe 3 ist nach der Orientierungshilfe der Regelfall, kein Kür-Ziel. Wer als Vergabestelle ein LV erstellt, beschafft genau diese Grundfähigkeit zur Angriffserkennung, oder eben nicht.
Anforderungsübersicht nach BSI OH-SzA v1.1
Unser Mapping-Katalog teilt die Anforderungen der OH-SzA in 217 Einzelanforderungen und sechs Kategorien, die sich den drei Kernbereichen zuordnen lassen. Dazu kommen fünf übergreifende Anforderungen als technisch-organisatorisches Fundament. Die Zählung ist eine eigene redaktionelle Aufschlüsselung, maßgeblich bleibt der Wortlaut der Orientierungshilfe.
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. Im Katalog mit 101 Einzelanforderungen der umfangreichste Bereich, davon 47 SOLLTE-Anforderungen (relevant für Umsetzungsgrad 4).
Prozesse nach einem erkannten Angriff: Vorfallklassifizierung, definierte Reaktionsverfahren, Eskalationspfade, Personaleinsatz und forensische Dokumentation. Das System soll die Meldung erheblicher Sicherheitsvorfälle nach § 32 BSIG unterstützen. Die Reaktion fließt wie Protokollierung und Detektion in den Umsetzungsgrad ein und gehört deshalb ausdrücklich ins LV.
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 hat der Ansatz Grenzen, die Vergabestellen kennen sollten, um ein LV zu schreiben, das über die bloße Erfüllung der Mindestanforderungen hinausgeht.
Was wir an der OH-SzA als echten Mehrwert sehen: Erstmals gibt es für KRITIS-Betreiber einen prüfbaren Rahmen, der Governance, technische Umsetzung und operativen Betrieb in einer Anforderungsstruktur verbindet. Die Unterscheidung von MUSS, SOLLTE und KANN gibt eine klare Grundlage für die Priorisierung von LV-Positionen. Wie eine Vergabestelle daraus Mindestanforderungen, Eignungs- oder Zuschlagskriterien ableitet, entscheidet sie selbst. Die Gliederung in Protokollierung, Detektion und Reaktion lässt sich direkt in die Gliederung eines Leistungsverzeichnisses überführen und macht Angebote vergleichbar.
Reaktiver Grundansatz. Das Gesetz beschreibt Angriffserkennung als Abgleich der verarbeiteten Daten mit Informationen und technischen Mustern, die auf Angriffe hindeuten (§ 2 Nr. 41 BSIG). Die OH-SzA lässt Missbrauchs- und Anomalieerkennung zu, schreibt aber keine bestimmte Methode vor. Neuartige Angriffe, etwa über Zero-Day-Exploits, und Techniken, die noch in keiner Signaturdatenbank und keinem Threat-Intelligence-Feed stehen, erkennt ein rein signaturbasiertes System nicht. Wer das abdecken will, sollte Anomalieerkennung und aktive Suche nach Angriffsspuren (Threat Hunting) im LV ausdrücklich fordern.
OT-Lücke in der Detektionstiefe. Die OH-SzA bezieht OT ausdrücklich ein und nennt MITRE ATT&CK for ICS als mögliche Methode. Einzelne Industrieprotokolle wie Modbus, OPC UA oder Profinet nennt sie aber nicht. Betreiber dezentraler OT-Netze, etwa in der Energie- und Wasserversorgung, sollten die OT-Anforderungen ihrer Umgebung im LV zusätzlich festlegen.
Erfüllte Anforderungen sind nicht gleich Wirksamkeit. Ein System, das alle MUSS-Anforderungen erfüllt, kann im Betrieb dennoch wenig bewirken, wenn die Alarmqualität zu niedrig ist. Wer täglich tausende Fehlalarme erhält, kann das System kaum sinnvoll nutzen. Auch die OH-SzA verlangt, die Detektion so zu kalibrieren, dass im Normalbetrieb eine vertretbare Zahl falsch positiver Meldungen entsteht. 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.
Sinnvoll ist es, die Anforderungen der OH-SzA im Leistungsverzeichnis als technische Mindestanforderungen aufzunehmen und sie durch prüfbare Qualitätskennzahlen zu ergänzen, die darüber hinausgehen.
Typische Vergabesituationen in KRITIS-Sektoren
Ausschreibungen für Systeme zur Angriffserkennung scheitern nicht nur am Budget, sondern auch an unklar formulierten Leistungsverzeichnissen. Zwei typische Szenarien zeigen, wie eine Lücke im LV zu einer Lücke in der Überwachung wird. Die Beispiele sind verallgemeinert und beschreiben keinen bestimmten Einzelfall.
Ein Krankenhaus schreibt den Netzwerkschutz über Standard-IT-Protokolle aus. Nach Zuschlag zeigt sich, dass die Medizintechnik über herstellerspezifische Protokolle kommuniziert, die das beschaffte NDR-System nicht erkennt. Bildgebungssysteme, Infusionspumpen und OP-Steuerungssoftware bleiben unüberwacht. Das LV hat lediglich „vollständige Netzwerküberwachung“ gefordert, ohne die konkreten Segmente und Protokolle zu benennen. Der Auftragnehmer hat geliefert, was das LV verlangt.
Ein ÖPNV-Betreiber schreibt ausschließlich eine On-Premises-Lösung aus, weil die Leitstelle aus Datenschutzgründen keine Cloud-Anbindung vorsieht. Erst im Vergabeverfahren zeigt sich, dass die SCADA-Systeme zur Netzsteuerung teilweise über einen Cloud-basierten Fernwartungszugang des Herstellers erreichbar sind. Den Zuschlag erhält ein Angebot ohne Cloud-Connector. Der kritischste Angriffspfad bleibt außerhalb des Überwachungsbereichs, weil das LV die Deployment-Architektur nicht vollständig beschreibt.
Pflichtpositionen im Leistungsverzeichnis
Die folgenden Positionen orientieren sich an den Bereichen der OH-SzA und gehören in jedes SzA-Leistungsverzeichnis. Fehlen sie, bleibt offen, was der Auftragnehmer technisch schuldet:
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: Die OH-SzA nennt keine festen Speicherdauern. Sie verlangt, gesetzliche Lösch- und Speicherfristen einzuhalten, und lässt eine befristete Speicherung der unbearbeiteten Protokolldaten zu [BSI OH-SzA v1.1, Kap. 3.1, Nov. 2024]. Die Aufbewahrungsdauer für Rohdaten und aufbereitete Ereignisdaten legt der Auftraggeber deshalb selbst als Mindestanforderung im LV fest, abgestimmt mit dem Datenschutz. Fehlt sie, kauft man womöglich 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: § 32 BSIG verpflichtet besonders wichtige und wichtige Einrichtungen, erhebliche Sicherheitsvorfälle zu melden: eine frühe Erstmeldung spätestens nach 24 Stunden, eine Meldung spätestens nach 72 Stunden und eine Abschlussmeldung spätestens einen Monat danach. Betreiber kritischer Anlagen machen zusätzlich Angaben zur betroffenen Anlage und zur kritischen Dienstleistung (§ 32 Abs. 3 BSIG). Das SzA muss Ereignisse so aufbereiten, dass diese Angaben (etwa Art, Schweregrad, Auswirkungen, Kompromittierungsindikatoren) rechtzeitig an die Meldestelle gehen 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.
Anbieterbeispiele je Lösungsklasse
Für eine Markterkundung hilft es, die Lösungsklassen und einige Anbieter zu kennen. Die folgende Übersicht nennt beispielhaft Hersteller und Dienstleister, gegliedert nach den drei Kernbereichen Protokollierung, Detektion und Reaktion sowie OT-spezifischen Lösungen. Sie ist keine Empfehlung und keine Marktübersicht.
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. Manche Leistungsverzeichnisse machen den Systemdurchsatz in Gbit/s zum Hauptmerkmal. 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. Ohne ausdrückliche Angabe des angestrebten Umsetzungsgrads (Stufe 0 bis 5 nach BSI OH-SzA) bleibt offen, welche MUSS- und SOLLTE-Anforderungen das Angebot abdecken muss. Das Ergebnis kann unter Stufe 3 liegen, obwohl die Orientierungshilfe grundsätzlich mindestens Stufe 3 (alle MUSS-Anforderungen erfüllt) vorsieht. Bei der Nachweisprüfung wird der erreichte Umsetzungsgrad bewertet, 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, drohen nach Zuschlag teure Nachverhandlungen.
Fehler 5: Zuschlagskriterien preisorientiert. Bei sehr hoher Preisgewichtung kann bei sicherheitskritischen Systemen wie SzA das günstigste statt des technisch stärksten Angebots den Zuschlag erhalten. Die Kriterien und ihre Gewichtung legt Ihre Vergabestelle fest.
Fehler 6: Verantwortlichkeiten zwischen IT, Security und SOC nicht geregelt. Ein SzA verbindet zentrale Auswertung (SOC/SIEM-Ebene) mit dezentraler Umsetzung im laufenden Betrieb (Logs, Systeme, lokale Prozesse). Die OH-SzA verlangt, Zuständige für Auswertung und Reaktion zu benennen, eigene oder solche eines Dienstleisters. 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 7: Kategorie 6 (Reaktion) nicht ausgeschrieben. Manche LVs decken Protokollierung und Detektion ab, übergehen aber die Reaktion 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 Reaktion zählt beim Umsetzungsgrad ebenso wie Protokollierung und Detektion.
Vorlagen und Vergleichsverfahren für Ihre SzA-Ausschreibung.
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.
- BSI-Gesetz (BSIG) vom 2. Dezember 2025, BGBl. 2025 I Nr. 301: „§ 31 Besondere Anforderungen an die Risikomanagementmaßnahmen von Betreibern kritischer Anlagen“, ebenso § 32 (Meldepflichten) und § 39 (Nachweispflichten), gesetze-im-internet.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 bis 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, Historie: Umsetzungsgrade der Systeme zur Angriffserkennung nach Sektoren", bsi.bund.de, Stichtag 31.12.2025.
