The assessment in numbers
231
Requirements checked
126
Addressed by ZephSense/service
53
Met technically by the platform
21
Via the SOC/MDR service
52
Supported with platform building blocks
105
Organizational, with the operator
Honest framing: a product can meet the technical requirements and support the organizational ones. Policies, staff and processes remain the operator's duty.
What ZephSense contributes to the implementation level
The implementation level per OH SzA is a property of the operator's overall implementation. ZephSense provides the technical foundation.
- Met technically: central logging, correlation, tamper-protected storage, network and host detection with current signatures, automated response.
- Enables level 3: the technical MUST requirements of all three areas are covered.
- Target level 4: with supported SHOULD requirements and the optional inducio SOC/MDR service.
The implementation-level model (BSI)
MUST equals level 3, SHOULD level 4, CAN level 5. At least level 3 is expected for the proof; level 4 is the target.
| Level | Definition |
|---|---|
| 0 | No measures, no planning. |
| 1 | Planning in place, no concrete implementation in at least one area. |
| 2 | Implementation started, not all MUST met yet. |
| 3 | All MUST met, continual improvement established or planned. Minimum level for the proof. |
| 4 | Additionally all SHOULD met or justifiably excluded. Target level. |
| 5 | Additionally all CAN met, risk-based additional measures. |
Result by level and area
| Level | Met | SOC/MDR | Supported | Operator | Total |
|---|---|---|---|---|---|
| MUST | 38 | 15 | 30 | 61 | 144 |
| SHOULD | 11 | 6 | 22 | 42 | 81 |
| CAN | 4 | 0 | 0 | 2 | 6 |
| Area | Met | SOC/MDR | Supported | Operator | Total |
|---|---|---|---|---|---|
| Overarching | 3 | 1 | 1 | 0 | 5 |
| Logging | 12 | 0 | 16 | 22 | 50 |
| Detection | 23 | 14 | 11 | 22 | 70 |
| Response | 15 | 6 | 24 | 61 | 106 |
What runs without a SOC team
ZephSense fulfils 53 of the 74 operational requirements (72%) fully automatically, without manual intervention. The remaining 157 requirements are organizational operator duties (policies, roles, processes), not SOC work. Only 21 operational tasks need ongoing SOC staff, covered by the optional MDR service.
Each row in the table below is marked accordingly. How the autonomous SOC works →
The requirements addressed by ZephSense (126 of 231)
We show the 126 requirements covered by ZephSense or the inducio service. Legend: Met Met · SOC/MDR SOC/MDR · Supported Supported · Operator Operator · In the function column: ⚙ auto = fully automated, ⚙ auto* = automated with approval, MDR = SOC staff..
| Ref | Requirement | Level | Coverage | ZephSense function |
|---|---|---|---|---|
| Overarching | ||||
| BSI OH SzA (chapter 3) | ||||
| UE-1 | Die notwendigen technischen, organisatorischen und personellen Rahmenbedingungen für die Angriffserkennung müssen geschaffen werden. (OH-SzA 3) | MUST | Supported | organisatorisch |
| UE-2 | Informationen zu aktuellen Angriffsmustern für technische Vulnerabilitäten müssen fortlaufend für die eingesetzten Systeme eingeholt werden. (OH-SzA 3) | MUST | Met | ⚙ auto Threat Intelligence |
| UE-3 | Alle zur effektiven Angriffserkennung erforderliche Hard- und Software muss durchgängig auf aktuellem Stand gehalten werden. (OH-SzA 3) | MUST | SOC/MDR | MDR Betrieb/Wartung |
| UE-4 | Die Signaturen von Detektionssystemen müssen immer aktuell sein. (OH-SzA 3) | MUST | Met | ⚙ auto Signaturpflege |
| UE-5 | Alle relevanten Systeme müssen so konfiguriert sein, dass Versuche, bekannte Schwachstellen auszunutzen, erkannt werden können. (OH-SzA 3) | MUST | Met | ⚙ auto NIDS/Signatur-Detektion |
| Logging | ||||
| BSI OH SzA (chapter 3) | ||||
| P-P2 | Der Betreiber muss alle zur wirksamen Angriffserkennung notwendigen Protokoll- und Protokollierungsdaten erheben. (OH-SzA 3.1.1) | MUST | Met | ⚙ auto Log-Erfassung |
| P-P3 | Diese Daten müssen gespeichert werden. (OH-SzA 3.1.1) | MUST | Met | ⚙ auto zentrale Speicherung |
| P-P4 | Diese Daten müssen für die Auswertung bereitgestellt werden, um SRE erkennen und bewerten zu können. (OH-SzA 3.1.1) | MUST | Met | ⚙ auto SIEM-Analyse |
| P-P5 | Es können zusätzliche Systeme zur Protokollierung eingesetzt werden, damit nicht jedes Gerät selbst protokollieren muss und die Verfügbarkeit gewährleistet bleibt. (OH-SzA 3.1.1) | CAN | Met | ⚙ auto zentrale Log-Erfassung |
| P-P6 | Die zur Speicherung notwendigen Systeme und deren IT-Sicherheitsvorkehrungen müssen bereits in der Planung bedacht werden. (OH-SzA 3.1.1) | MUST | Supported | zentrale Speicherung |
| P-P8 | Gesetzlich vorgeschriebene Lösch- und Speicherfristen müssen eingehalten werden (ggf. Anonymisierung/Pseudonymisierung). (OH-SzA 3.1.1) | MUST | Supported | Retention/Loeschfristen |
| P-P10 | Können bestehende Systeme die erforderlichen Protokolldaten nicht bereitstellen, sollte die Protokollierungsinfrastruktur angepasst und/oder ergänzt werden. (OH-SzA 3.1.1) | SHOULD | Supported | Log-Erfassung |
| P-P13 | Die Dokumentation muss alle Netzbereiche, Datenquellen, deren Beziehungen und den Datenfluss umfassen. (OH-SzA 3.1.1) | MUST | Supported | Flow-Visualisierung |
| P-P15 | Für jedes System bzw. jede Systemgruppe muss dokumentiert werden, welche Ereignisse es protokolliert. (OH-SzA 3.1.1) | MUST | Supported | Datenquellen-Transparenz |
| IT-Grundschutz OPS.1.1.5 - Logging (basic) | ||||
| OPS.1.1.5.A1.4 | Dabei SOLLTEN sich Art und Umfang der Protokollierung am Schutzbedarf der Informationen orientieren. (OPS.1.1.5 (Basis)) | SHOULD | Supported | SIEM-Konfiguration |
| OPS.1.1.5.A1.8 | Es MUSS regelmäßig überprüft werden, ob die spezifische Sicherheitsrichtlinie noch korrekt umgesetzt ist. (OPS.1.1.5 (Basis)) | MUST | Supported | GRC-Reporting |
| OPS.1.1.5.A1.9 | Die Ergebnisse der Überprüfung MÜSSEN dokumentiert werden. (OPS.1.1.5 (Basis)) | MUST | Supported | GRC-Reporting |
| OPS.1.1.5.A3.1 | Alle sicherheitsrelevanten Ereignisse von IT-Systemen und Anwendungen MÜSSEN protokolliert werden. (OPS.1.1.5 (Basis)) | MUST | Met | ⚙ auto SIEM-Protokollierung |
| OPS.1.1.5.A3.2 | Sofern die in der Protokollierungsrichtlinie als relevant definierten IT-Systeme und Anwendungen über eine Protokollierungsfunktion verfügen, MUSS diese benutzt werden. (OPS.1.1.5 (Basis)) | MUST | Supported | SIEM-Log-Erfassung |
| OPS.1.1.5.A3.4 | In angemessenen Intervallen MUSS stichpunktartig überprüft werden, ob die Protokollierung noch korrekt funktioniert. (OPS.1.1.5 (Basis)) | MUST | Supported | SIEM-Monitoring |
| OPS.1.1.5.A3.6 | Falls betriebs- und sicherheitsrelevante Ereignisse nicht auf einem IT-System protokolliert werden können, MÜSSEN zusätzliche IT-Systeme zur Protokollierung (z. B. von Ereignissen auf Netzebene) integriert werden. (OPS.1.1.5 (Basis)) | MUST | Met | ⚙ auto NDR/Netzwerk |
| OPS.1.1.5.A4.2 | Es MUSS sichergestellt sein, dass das Datums- und Zeitformat der Protokolldateien einheitlich ist. (OPS.1.1.5 (Basis)) | MUST | Met | ⚙ auto Normalisierung |
| OPS.1.1.5.A5.4 | Protokollierungsdaten MÜSSEN nach einem festgelegten Prozess gelöscht werden. (OPS.1.1.5 (Basis)) | MUST | Supported | Retention-Management |
| OPS.1.1.5.A5.5 | Es MUSS technisch unterbunden werden, dass Protokollierungsdaten unkontrolliert gelöscht oder verändert werden. (OPS.1.1.5 (Basis)) | MUST | Met | ⚙ auto Integritaetssicherung |
| BSI OH SzA (chapter 3) | ||||
| P-U1 | Alle gesammelten sicherheitsrelevanten Protokolldaten müssen an für den Netzbereich zentralen Stellen gespeichert werden. (OH-SzA 3.1.2) | MUST | Met | ⚙ auto Zentrale Log-Speicherung |
| P-U2 | Die Zahl zentraler Speicherstellen sollte gering gehalten werden und sich an funktionalen Einheiten orientieren. (OH-SzA 3.1.2) | SHOULD | Supported | Architektur |
| P-U3 | Die Protokollierungsinfrastruktur muss ausreichend dimensioniert sein. (OH-SzA 3.1.2) | MUST | Supported | Skalierbarkeit |
| P-U5 | Die gesammelten Protokolldaten müssen gefiltert, normalisiert, aggregiert und korreliert werden. (OH-SzA 3.1.2) | MUST | Met | ⚙ auto SIEM-Korrelation |
| P-U6 | Die bearbeiteten Protokolldaten müssen für die Auswertung geeignet verfügbar gemacht werden. (OH-SzA 3.1.2) | MUST | Met | ⚙ auto SIEM-Datenbereitstellung |
| P-U7 | Eine zeitlich befristete Speicherung der unbearbeiteten Rohdaten kann den Detektionsprozess unterstützen. (OH-SzA 3.1.2) | CAN | Met | ⚙ auto Log-Speicherung/Retention |
| P-U8 | Die Datenquellen auf Netzebene sollten von außen (Netzgrenzen) nach innen erschlossen werden. (OH-SzA 3.1.2) | SHOULD | Supported | NDR/Datenquellen-Anbindung |
| P-U9 | Die Systemebene sollte ausgehend von den zentralen, kritischen Systemen erschlossen werden. (OH-SzA 3.1.2) | SHOULD | Supported | EDR/Datenquellen-Anbindung |
| P-U11 | Nach der Umsetzung muss geprüft werden, ob alle geplanten Protokollierungsdatenquellen umgesetzt wurden. (OH-SzA 3.1.2) | MUST | Supported | Datenquellen-Uebersicht |
| Detection | ||||
| BSI OH SzA (chapter 3) | ||||
| D-P1 | Bei Auswahl und Einsatz der Detektionsmaßnahmen muss eine umfassende und effiziente Abdeckung der Bedrohungslandschaft erzielt werden. (OH-SzA 3.2.1) | MUST | Met | ⚙ auto Detection-Abdeckung |
| D-P3 | Zur Bestimmung der Abdeckung kann eine standardisierte Methode (z. B. MITRE ATT&CK / ATT&CK for ICS) angewendet werden. (OH-SzA 3.2.1) | CAN | Met | ⚙ auto MITRE-ATT&CK-Mapping |
| IT-Grundschutz DER.1 - Detection (basic) | ||||
| DER.1.A1.5 | Es MUSS regelmäßig überprüft werden, ob die spezifische Sicherheitsrichtlinie noch korrekt umgesetzt ist. (DER.1 (Basis)) | MUST | Supported | GRC-Reporting |
| DER.1.A1.6 | Die Ergebnisse der Überprüfung MÜSSEN sinnvoll dokumentiert werden. (DER.1 (Basis)) | MUST | Supported | GRC-Reporting |
| DER.1.A2.1 | Wenn Protokollierungsdaten ausgewertet werden, dann MÜSSEN dabei die Bestimmungen aus den aktuellen Gesetzen zum Bundes- und Landesdatenschutz eingehalten werden. (DER.1 (Basis)) | MUST | Supported | Datenschutz-Kontrollen |
| DER.1.A3.1 | Für sicherheitsrelevante Ereignisse MÜSSEN geeignete Melde- und Alarmierungswege festgelegt und dokumentiert werden. (DER.1 (Basis)) | MUST | Supported | Alarmierung |
| DER.1.A3.4 | Je nach Dringlichkeit MUSS ein sicherheitsrelevantes Ereignis über verschiedene Kommunikationswege gemeldet werden. (DER.1 (Basis)) | MUST | Supported | Alarmierung |
| DER.1.A5.1 | Falls eingesetzte IT-Systeme oder Anwendungen über Funktionen verfügen, mit denen sich sicherheitsrelevante Ereignisse detektieren lassen, dann MÜSSEN diese aktiviert und benutzt werden. (DER.1 (Basis)) | MUST | Met | ⚙ auto SIEM-Detektion |
| DER.1.A5.2 | Falls ein sicherheitsrelevanter Vorfall vorliegt, dann MÜSSEN die Meldungen der betroffenen IT-Systeme ausgewertet werden. (DER.1 (Basis)) | MUST | Met | ⚙ auto SIEM-Korrelation |
| DER.1.A5.3 | Zusätzlich MÜSSEN die protokollierten Ereignisse anderer IT-Systeme überprüft werden. (DER.1 (Basis)) | MUST | Met | ⚙ auto SIEM-Korrelation |
| DER.1.A5.4 | Auch SOLLTEN die gesammelten Meldungen in verbindlich festgelegten Zeiträumen stichpunktartig kontrolliert werden. (DER.1 (Basis)) | SHOULD | SOC/MDR | MDR SOC-Kontrolle |
| DER.1.A5.6 | Falls zusätzliche Schadcodescanner eingesetzt werden, dann MÜSSEN diese es über einen zentralen Zugriff ermöglichen, ihre Meldungen und Protokolle auszuwerten. (DER.1 (Basis)) | MUST | Met | ⚙ auto SIEM-Korrelation |
| DER.1.A5.7 | Es MUSS sichergestellt sein, dass die Schadcodescanner sicherheitsrelevante Ereignisse automatisch an die Zuständigen melden. (DER.1 (Basis)) | MUST | Met | ⚙ auto Automatische Alarmierung |
| DER.1.A5.8 | Die Zuständigen MÜSSEN die Meldungen auswerten und untersuchen. (DER.1 (Basis)) | MUST | SOC/MDR | MDR Manuelle Triage |
| BSI OH SzA (chapter 3) | ||||
| D-U1 | Alle Protokoll- und Protokollierungsdaten müssen kontinuierlich überwacht und ausgewertet werden. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR Kontinuierliche Auswertung |
| D-U2 | Die Überwachung kann automatisiert werden, wenn bei relevanten Ereignissen eine unmittelbare Alarmierung gewährleistet ist. (OH-SzA 3.2.2) | CAN | Met | ⚙ auto SIEM-Automatisierung |
| D-U3 | Die Prüfung des Ereignisses und ggf. die Reaktion muss innerhalb einer geringen Zeitspanne erfolgen. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR Zeitnahe Qualifizierung |
| D-U5 | Aktives Suchen nach SRE muss in Verfahrensanleitungen dokumentiert sein. (OH-SzA 3.2.2) | MUST | Supported | Retro-Detektion |
| D-U7 | Es müssen Schadcodedetektionssysteme eingesetzt und zentral verwaltet werden. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto EDR-Endpointdetektion |
| D-U8 | Anhand des Netzplans muss festgelegt werden, welche Netzsegmente durch zusätzliche Detektionssysteme geschützt werden. (OH-SzA 3.2.2) | MUST | Supported | NDR-Bausteine |
| D-U9 | Die Übergänge zwischen internen und externen Netzen müssen um netzbasierte Intrusion Detection Systeme (NIDS) ergänzt werden. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto NIDS |
| D-U10 | Zur Korrelation und zum Abgleich sollten alle Protokolldaten zeitlich synchronisiert werden. (OH-SzA 3.2.2) | SHOULD | Supported | Zeitnormalisierung |
| D-U11 | Die gesammelten Ereignismeldungen müssen regelmäßig auf Auffälligkeiten kontrolliert werden. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR SOC-Monitoring |
| D-U12 | Externe Quellen müssen herangezogen werden, um neue Erkenntnisse über SRE zu gewinnen. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto Threat Intelligence |
| D-U13 | Es muss sichergestellt sein, dass über verschiedene Kanäle eingehende Meldungen als relevant erkannt und weitergeleitet werden. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR Triage/Qualifizierung |
| D-U14 | Informationen aus zuverlässigen Quellen müssen grundsätzlich ausgewertet werden. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto Threat Intelligence |
| D-U15 | Alle gelieferten Informationen müssen auf Relevanz für den eigenen Informationsverbund bewertet werden. (OH-SzA 3.2.2) | MUST | Supported | Relevanzbewertung |
| D-U16 | Relevante Informationen müssen entsprechend der Sicherheitsvorfallbehandlung eskaliert werden. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto SOAR/Eskalation |
| D-U17 | Es müssen Mitarbeitende bzw. Dienstleister speziell mit der Auswertung aller Protokolldaten beauftragt werden. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR SOC-Personal |
| D-U21 | Es müssen zentrale Komponenten eingesetzt werden, um SRE zu erkennen und auszuwerten. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto SIEM-Kern |
| D-U22 | Zentrale automatisierte Analysen müssen alle Protokolldaten aufzeichnen, in Bezug zueinander setzen und sicherheitsrelevante Vorgänge sichtbar machen. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto SIEM-Korrelation |
| D-U23 | Alle eingelieferten Protokolldaten müssen lückenlos in der Protokollverwaltung einsehbar und auswertbar sein. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto SIEM-Speicherung |
| D-U24 | Die Daten müssen kontinuierlich ausgewertet werden. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto SIEM-Korrelation |
| D-U25 | Bei Überschreiten definierter Schwellenwerte muss automatisch alarmiert werden. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto SIEM-Alarmierung |
| D-U26 | Das zuständige Personal muss bei einem Alarm nach fachlicher Bewertung binnen geringer Zeitspanne eine qualifizierte Reaktion einleiten. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR SOC-Reaktion |
| D-U27 | Die Systemverantwortlichen müssen die Analyseparameter regelmäßig auditieren und anpassen. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR Detection Engineering |
| D-U28 | Bereits überprüfte Protokolldaten müssen regelmäßig automatisch erneut hinsichtlich SRE untersucht werden. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto Retro-Detektion |
| D-U29 | Informationen zu aktuellen Angriffsmustern müssen fortlaufend eingeholt werden. (OH-SzA 3.2.2) | MUST | Met | ⚙ auto Threat Intelligence |
| D-U30 | Meldungen von Herstellern, Behörden und Medien müssen geprüft werden und in das Schwachstellenmanagement einfließen. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR Threat Intelligence |
| D-U31 | Bei der Umsetzung der Detektionsmechanismen sollte initial eine Kalibrierung (Baselining) durchgeführt werden. (OH-SzA 3.2.2) | SHOULD | Met | ⚙ auto Baselining |
| D-U32 | Es sollte bewertet werden, ob Kalibrierungsmeldungen auf Schwachstellen hindeuten und ob die Falsch-Positiv-Rate vertretbar ist. (OH-SzA 3.2.2) | SHOULD | SOC/MDR | MDR Baselining-Bewertung |
| D-U33 | Die Kalibrierung sollte bei Änderungen des Anwendungsbereichs oder der Bedrohungslage erneut durchgeführt werden. (OH-SzA 3.2.2) | SHOULD | Supported | Baselining |
| D-U34 | Auftretende SRE müssen überprüft und bewertet werden, ob sie auf einen Sicherheitsvorfall (qualifizierter SRE) hindeuten. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR SOC-Triage |
| D-U35 | Die eingesetzten Systeme sollten in eindeutig zuordenbaren Fällen eine automatisierte Qualifizierung der SRE ermöglichen. (OH-SzA 3.2.2) | SHOULD | Met | ⚙ auto Auto-Qualifizierung |
| D-U36 | Nur qualifizierte SRE sollten den Reaktionsprozess auslösen. (OH-SzA 3.2.2) | SHOULD | Met | ⚙ auto SOAR-Playbook |
| D-U37 | Die Qualifizierung sollte in nicht eindeutig zuordenbaren Fällen manuell durch festgelegte Verantwortliche erfolgen. (OH-SzA 3.2.2) | SHOULD | SOC/MDR | MDR manuelle Triage |
| D-U38 | Basierend auf den Erkenntnissen der Qualifizierung müssen die Detektionsmechanismen nachjustiert werden. (OH-SzA 3.2.2) | MUST | SOC/MDR | MDR Detection Engineering |
| D-U39 | Branchenspezifische weitergehende gesetzliche oder regulatorische Anforderungen an die Detektion müssen ebenfalls umgesetzt werden. (OH-SzA 3.2.2) | MUST | Supported | GRC-Reporting |
| Response | ||||
| IT-Grundschutz DER.2.1 - Incident handling (basic + standard) | ||||
| DER.2.1.A4.1 | Von einem Sicherheitsvorfall MÜSSEN alle betroffenen internen und externen Stellen zeitnah informiert werden. (DER.2.1 (Basis)) | MUST | Supported | GRC-Reporting |
| DER.2.1.A4.3 | Ebenso MÜSSEN die Meldepflichten für Behörden und regulierte Branchen berücksichtigt werden. (DER.2.1 (Basis)) | MUST | Supported | Meldewesen/GRC-Reporting |
| DER.2.1.A5.1 | Damit ein Sicherheitsvorfall erfolgreich behoben werden kann, MUSS der Zuständige zunächst das Problem eingrenzen und die Ursache finden. (DER.2.1 (Basis)) | MUST | SOC/MDR | MDR Incident-Analyse/Triage |
| DER.2.1.A5.2 | Danach MUSS er die erforderlichen Maßnahmen auswählen, um das Problem zu beheben. (DER.2.1 (Basis)) | MUST | Supported | SOAR-Playbook |
| DER.2.1.A5.4 | Anschließend MUSS die Ursache beseitigt und ein sicherer Zustand hergestellt werden. (DER.2.1 (Basis)) | MUST | Supported | SOAR-Response/IR |
| DER.2.1.A6.1 | Nach einem Sicherheitsvorfall MÜSSEN die betroffenen Komponenten vom Netz genommen werden. (DER.2.1 (Basis)) | MUST | Met | ⚙ auto* SOAR-Isolation/Firewall |
| DER.2.1.A6.2 | Zudem MÜSSEN alle erforderlichen Daten gesichert werden, die Aufschluss über die Art und Ursache des Problems geben könnten. (DER.2.1 (Basis)) | MUST | Met | ⚙ auto EDR-Forensik |
| DER.2.1.A6.3 | Auf allen betroffenen Komponenten MÜSSEN das Betriebssystem und alle Applikationen auf Veränderungen untersucht werden. (DER.2.1 (Basis)) | MUST | Met | ⚙ auto EDR/Integritaetspruefung |
| DER.2.1.A6.6 | Wenn Daten aus Datensicherungen wieder eingespielt werden, MUSS sichergestellt sein, dass diese vom Sicherheitsvorfall nicht betroffen waren. (DER.2.1 (Basis)) | MUST | Supported | Retro-Detektion/IR-Timeline |
| DER.2.1.A6.10 | Nachdem alles wiederhergestellt wurde, MÜSSEN die Komponenten inklusive der Netzübergänge gezielt überwacht werden. (DER.2.1 (Basis)) | MUST | Met | ⚙ auto SIEM/NDR-Monitoring |
| DER.2.1.A7.1 | Es SOLLTE eine geeignete Vorgehensweise zur Behandlung von Sicherheitsvorfällen definiert werden. (DER.2.1 (Standard)) | SHOULD | Supported | SOAR-Playbook/IR |
| DER.2.1.A7.2 | Die Abläufe, Prozesse und Vorgaben für die verschiedenen Sicherheitsvorfälle SOLLTEN dabei eindeutig geregelt und geeignet dokumentiert werden. (DER.2.1 (Standard)) | SHOULD | Supported | SOAR-Playbook/Case-Management |
| DER.2.1.A9.1 | Für die verschiedenen Arten von Sicherheitsvorfällen SOLLTEN die jeweils passenden Meldewege aufgebaut sein. (DER.2.1 (Standard)) | SHOULD | Supported | Case-Management/Reporting |
| DER.2.1.A9.7 | Ebenso SOLLTE sichergestellt sein, dass keine unautorisierten Personen Informationen über den Sicherheitsvorfall weitergeben. (DER.2.1 (Standard)) | SHOULD | Supported | RBAC/Zugriffskontrolle |
| DER.2.1.A10.1 | Parallel zur Ursachenanalyse eines Sicherheitsvorfalls SOLLTE entschieden werden, ob es wichtiger ist, den entstandenen Schaden einzudämmen oder den Vorfall aufzuklären. (DER.2.1 (Standard)) | SHOULD | SOC/MDR | MDR Incident Response |
| DER.2.1.A10.2 | Um die Auswirkung eines Sicherheitsvorfalls abschätzen zu können, SOLLTEN ausreichend Informationen vorliegen. (DER.2.1 (Standard)) | SHOULD | Supported | Incident Response |
| DER.2.1.A11.1 | Ein einheitliches Verfahren SOLLTE festgelegt werden, um Sicherheitsvorfälle und Störungen einzustufen. (DER.2.1 (Standard)) | SHOULD | Supported | Incident Response |
| DER.2.1.A12.4 | Das Sicherheitsmanagement SOLLTE lesenden Zugriff auf eingesetzte Incident-Management-Werkzeuge haben. (DER.2.1 (Standard)) | SHOULD | Met | ⚙ auto RBAC |
| DER.2.1.A14.4 | Es SOLLTE geregelt sein, zu welchen Maßnahmen eine Eskalation führt und wie reagiert werden soll. (DER.2.1 (Standard)) | SHOULD | Supported | SOAR-Playbook |
| DER.2.1.A14.5 | Für die festgelegte Eskalationsstrategie SOLLTEN geeignete Werkzeuge wie z. B. Ticket-Systeme ausgewählt werden. (DER.2.1 (Standard)) | SHOULD | Met | ⚙ auto Case-Management |
| DER.2.1.A14.6 | Diese SOLLTEN sich auch dafür eignen, vertrauliche Informationen zu verarbeiten. (DER.2.1 (Standard)) | SHOULD | Met | ⚙ auto RBAC |
| DER.2.1.A14.7 | Es SOLLTE sichergestellt sein, dass die Werkzeuge auch während eines Sicherheitsvorfalls bzw. Notfalls verfügbar sind. (DER.2.1 (Standard)) | SHOULD | Supported | Verfuegbarkeit |
| DER.2.1.A15.1 | Den Mitarbeitern des Service Desk SOLLTEN geeignete Hilfsmittel zur Verfügung stehen, damit sie Sicherheitsvorfälle erkennen können. (DER.2.1 (Standard)) | SHOULD | Met | ⚙ auto SIEM-Korrelation |
| DER.2.1.A16.1 | Die Behebung von Sicherheitsvorfällen SOLLTE nach einem standardisierten Verfahren dokumentiert werden. (DER.2.1 (Standard)) | SHOULD | Supported | IR-Dokumentation |
| DER.2.1.A16.2 | Es SOLLTEN alle durchgeführten Aktionen inklusive der Zeitpunkte sowie die Protokolldaten der betroffenen Komponenten dokumentiert werden. (DER.2.1 (Standard)) | SHOULD | Met | ⚙ auto IR-Dokumentation |
| DER.2.1.A16.3 | Dabei SOLLTE die Vertraulichkeit bei der Dokumentation und Archivierung der Berichte gewährleistet sein. (DER.2.1 (Standard)) | SHOULD | Met | ⚙ auto Zugriffsschutz |
| DER.2.1.A16.4 | Die benötigten Informationen SOLLTEN in die jeweiligen Dokumentationssysteme eingepflegt werden, bevor die Störung als beendet und als abgeschlossen markiert wird. (DER.2.1 (Standard)) | SHOULD | Supported | IR-Dokumentation |
| DER.2.1.A17.1 | Sicherheitsvorfälle SOLLTEN standardisiert nachbereitet werden. (DER.2.1 (Standard)) | SHOULD | SOC/MDR | MDR IR-Nachbereitung |
| DER.2.1.A17.2 | Dabei SOLLTE untersucht werden, wie schnell die Sicherheitsvorfälle erkannt und behoben wurden. (DER.2.1 (Standard)) | SHOULD | Supported | IR-Metriken |
| DER.2.1.A17.3 | Weiterhin SOLLTE untersucht werden, ob die Meldewege funktionierten, ausreichend Informationen für die Bewertung verfügbar und ob die Detektionsmaßnahmen wirksam waren. (DER.2.1 (Standard)) | SHOULD | Supported | IR-Nachbereitung |
| DER.2.1.A17.4 | Ebenso SOLLTE geprüft werden, ob die ergriffenen Maßnahmen und Aktivitäten wirksam und effizient waren. (DER.2.1 (Standard)) | SHOULD | Supported | IR-Nachbereitung |
| DER.2.1.A17.5 | Die Erfahrungen aus vergangenen Sicherheitsvorfällen SOLLTEN genutzt werden, um daraus Handlungsanweisungen für vergleichbare Sicherheitsvorfälle zu erstellen. (DER.2.1 (Standard)) | SHOULD | SOC/MDR | MDR IR-Playbook |
| DER.2.1.A17.7 | Die Institutionsleitung SOLLTE jährlich über die Sicherheitsvorfälle unterrichtet werden. (DER.2.1 (Standard)) | SHOULD | Supported | GRC-Reporting |
| DER.2.1.A17.8 | Besteht sofortiger Handlungsbedarf, MUSS die Institutionsleitung umgehend informiert werden. (DER.2.1 (Standard)) | MUST | Supported | Alarmierung/Eskalation |
| DER.2.1.A18.1 | Nachdem ein Sicherheitsvorfall analysiert wurde, SOLLTE untersucht werden, ob die Prozesse und Abläufe im Rahmen der Behandlung von Sicherheitsvorfällen geändert oder weiterentwickelt werden müssen. (DER.2.1 (Standard)) | SHOULD | Supported | Nachbereitung/Lessons Learned |
| BSI OH SzA (chapter 3) | ||||
| R-1 | Bei einem SRE müssen die Detektionssysteme das Ereignis automatisch melden. (OH-SzA 3.3) | MUST | Met | ⚙ auto SIEM-Alarmierung/Auto-Incident |
| R-2 | Wo die kritische Dienstleistung nicht gefährdet wird, müssen die Detektionssysteme mit geeigneten Schutzmaßnahmen reagieren. (OH-SzA 3.3) | MUST | Met | ⚙ auto* Active Response/SOAR |
| R-3 | In Netzen, wo die kritische Dienstleistung nicht gefährdet wird, muss automatisch in den Datenstrom eingegriffen werden können, um einen Vorfall zu unterbinden. (OH-SzA 3.3) | MUST | Met | ⚙ auto* Inline-NIDS/Firewall-Block |
| R-4 | Ist eine automatische Reaktion nicht möglich, muss über manuelle Prozesse sichergestellt werden, dass der Vorfall unterbunden wird. (OH-SzA 3.3) | MUST | SOC/MDR | MDR manuelle Reaktion/Runbook |
| R-5 | Der Ausschluss von Netzen oder Netzsegmenten von einer automatischen Reaktion muss schlüssig begründet sein. (OH-SzA 3.3) | MUST | Supported | Reaktions-Scoping/Konfiguration |
| R-6 | Festgestellte Sicherheitsvorfälle im vermeintlichen Zusammenhang mit Angriffen müssen behandelt werden. (OH-SzA 3.3) | MUST | SOC/MDR | MDR Incident Handling |
| R-7 | Bei Vorfällen im Angriffszusammenhang muss geprüft werden, ob eine Meldepflicht (§ 8b BSIG bzw. § 11 EnWG, § 168 TKG) besteht und eine Meldung an BSI/BNetzA erforderlich ist. (OH-SzA 3.3) | MUST | Supported | Meldepflicht/BSI-Meldebericht |
| R-8 | Die eingesetzten Systeme sollten automatisiert Maßnahmen zur Vermeidung und Beseitigung angriffsbedingter Störungen ergreifen, sofern das SRE eindeutig qualifizierbar ist. (OH-SzA 3.3) | SHOULD | Met | ⚙ auto SOAR-Playbook |
| R-9 | Es muss gewährleistet sein, dass rein automatisiert ergriffene Maßnahmen die kritische Dienstleistung nicht relevant beeinträchtigen. (OH-SzA 3.3) | MUST | Supported | SOAR-Scoping |
| R-10 | Die eingesetzten SzA sollten auch eine nicht-automatisierte Qualifizierung und Behandlung von Ereignissen unterstützen. (OH-SzA 3.3) | SHOULD | Met | ⚙ auto Case-Management |
The remaining 105 requirements are purely organizational operator duties (policies, roles, processes). We deliberately do not list them publicly: the complete requirement matrix derived from the official sources is provided as a handout within our consulting, so you can use it for your own implementation. Request the full matrix →
Vendor self-assessment of technical and service-side coverage. Does not replace an audit by a qualified body per OH SzA. Contact: vertrieb@inducio.de.
Discuss your SzA readiness
We structure your BSI SzA and NIS2 requirements and show how ZephSense raises your implementation level.