Das Prüfergebnis in Zahlen
231
Geprüfte Anforderungen
126
Durch ZephSense/Service adressiert
53
Technisch durch die Plattform erfüllt
21
Durch den SOC-/MDR-Service
52
Mit Plattform-Bausteinen unterstützt
105
Organisatorisch beim Betreiber
Ehrliche Einordnung: Ein Produkt kann die technischen Anforderungen erfüllen und die organisatorischen unterstützen. Richtlinien, Personal und Prozesse bleiben Betreiberpflicht.
Was ZephSense zum Umsetzungsgrad beiträgt
Der Umsetzungsgrad nach OH SzA ist eine Eigenschaft der Gesamtumsetzung beim Betreiber. ZephSense liefert dafür die technische Grundlage.
- Erfüllt technisch: zentrale Protokollierung, Korrelation, manipulationsgeschützte Speicherung, Netz- und Host-Detektion mit aktuellen Signaturen, automatisierte Reaktion.
- Ermöglicht Stufe 3: die technischen MUSS-Anforderungen aller drei Bereiche sind abgedeckt.
- Zielniveau Stufe 4: mit unterstützten SOLL-Anforderungen und optionalem inducio-SOC-/MDR-Service.
Das Umsetzungsgradmodell (BSI)
MUSS entspricht Stufe 3, SOLL Stufe 4, KANN Stufe 5. Für den Nachweis wird mindestens Stufe 3 erwartet, angestrebt wird Stufe 4.
| Stufe | Definition |
|---|---|
| 0 | Keine Maßnahmen, keine Planung. |
| 1 | Planung vorhanden, noch keine konkrete Umsetzung in mind. einem Bereich. |
| 2 | Umsetzung begonnen, noch nicht alle MUSS erfüllt. |
| 3 | Alle MUSS erfüllt, KVP etabliert oder geplant. Mindestniveau für den Nachweis. |
| 4 | Zusätzlich alle SOLL erfüllt oder begründet ausgeschlossen. Angestrebtes Niveau. |
| 5 | Zusätzlich alle KANN erfüllt, risikobasierte Zusatzmaßnahmen. |
Ergebnis nach Stufe und Bereich
| Stufe | Erfüllt | SOC/MDR | Unterstützt | Betreiber | Summe |
|---|---|---|---|---|---|
| MUSS | 38 | 15 | 30 | 61 | 144 |
| SOLL | 11 | 6 | 22 | 42 | 81 |
| KANN | 4 | 0 | 0 | 2 | 6 |
| Bereich | Erfüllt | SOC/MDR | Unterstützt | Betreiber | Summe |
|---|---|---|---|---|---|
| Übergreifend | 3 | 1 | 1 | 0 | 5 |
| Protokollierung | 12 | 0 | 16 | 22 | 50 |
| Detektion | 23 | 14 | 11 | 22 | 70 |
| Reaktion | 15 | 6 | 24 | 61 | 106 |
Was davon ohne SOC-Team läuft
53 der 74 operativen Anforderungen (72 %) erfüllt ZephSense vollautomatisch, ohne manuelles Eingreifen. Die übrigen 157 Anforderungen sind organisatorische Betreiberpflichten (Richtlinien, Rollen, Prozesse), keine SOC-Arbeit. Nur 21 operative Aufgaben brauchen laufendes SOC-Personal, das der optionale MDR-Service übernimmt.
In der Tabelle unten ist jede Zeile entsprechend markiert. So funktioniert das autonome SOC →
Die von ZephSense adressierten Anforderungen (126 von 231)
Wir zeigen hier die 126 Anforderungen, die ZephSense oder der inducio-Service abdeckt. Legende: Erfüllt Erfüllt · SOC/MDR SOC/MDR · Unterstützt Unterstützt · Betreiber Betreiber · In der Funktions-Spalte: ⚙ auto = vollautomatisch, ⚙ auto* = automatisch mit Freigabe, MDR = SOC-Personal..
| Ref | Anforderung | Stufe | Abdeckung | ZephSense-Funktion |
|---|---|---|---|---|
| Übergreifend | ||||
| BSI OH SzA (Kapitel 3) | ||||
| UE-1 | Die notwendigen technischen, organisatorischen und personellen Rahmenbedingungen für die Angriffserkennung müssen geschaffen werden. (OH-SzA 3) | MUSS | Unterstützt | 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) | MUSS | Erfüllt | ⚙ auto Threat Intelligence |
| UE-3 | Alle zur effektiven Angriffserkennung erforderliche Hard- und Software muss durchgängig auf aktuellem Stand gehalten werden. (OH-SzA 3) | MUSS | SOC/MDR | MDR Betrieb/Wartung |
| UE-4 | Die Signaturen von Detektionssystemen müssen immer aktuell sein. (OH-SzA 3) | MUSS | Erfüllt | ⚙ auto Signaturpflege |
| UE-5 | Alle relevanten Systeme müssen so konfiguriert sein, dass Versuche, bekannte Schwachstellen auszunutzen, erkannt werden können. (OH-SzA 3) | MUSS | Erfüllt | ⚙ auto NIDS/Signatur-Detektion |
| Protokollierung | ||||
| BSI OH SzA (Kapitel 3) | ||||
| P-P2 | Der Betreiber muss alle zur wirksamen Angriffserkennung notwendigen Protokoll- und Protokollierungsdaten erheben. (OH-SzA 3.1.1) | MUSS | Erfüllt | ⚙ auto Log-Erfassung |
| P-P3 | Diese Daten müssen gespeichert werden. (OH-SzA 3.1.1) | MUSS | Erfüllt | ⚙ 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) | MUSS | Erfüllt | ⚙ 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) | KANN | Erfüllt | ⚙ 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) | MUSS | Unterstützt | zentrale Speicherung |
| P-P8 | Gesetzlich vorgeschriebene Lösch- und Speicherfristen müssen eingehalten werden (ggf. Anonymisierung/Pseudonymisierung). (OH-SzA 3.1.1) | MUSS | Unterstützt | 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) | SOLL | Unterstützt | Log-Erfassung |
| P-P13 | Die Dokumentation muss alle Netzbereiche, Datenquellen, deren Beziehungen und den Datenfluss umfassen. (OH-SzA 3.1.1) | MUSS | Unterstützt | Flow-Visualisierung |
| P-P15 | Für jedes System bzw. jede Systemgruppe muss dokumentiert werden, welche Ereignisse es protokolliert. (OH-SzA 3.1.1) | MUSS | Unterstützt | Datenquellen-Transparenz |
| IT-Grundschutz OPS.1.1.5 - Protokollierung (Basis) | ||||
| OPS.1.1.5.A1.4 | Dabei SOLLTEN sich Art und Umfang der Protokollierung am Schutzbedarf der Informationen orientieren. (OPS.1.1.5 (Basis)) | SOLL | Unterstützt | 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)) | MUSS | Unterstützt | GRC-Reporting |
| OPS.1.1.5.A1.9 | Die Ergebnisse der Überprüfung MÜSSEN dokumentiert werden. (OPS.1.1.5 (Basis)) | MUSS | Unterstützt | 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)) | MUSS | Erfüllt | ⚙ 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)) | MUSS | Unterstützt | 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)) | MUSS | Unterstützt | 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)) | MUSS | Erfüllt | ⚙ 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)) | MUSS | Erfüllt | ⚙ auto Normalisierung |
| OPS.1.1.5.A5.4 | Protokollierungsdaten MÜSSEN nach einem festgelegten Prozess gelöscht werden. (OPS.1.1.5 (Basis)) | MUSS | Unterstützt | 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)) | MUSS | Erfüllt | ⚙ auto Integritaetssicherung |
| BSI OH SzA (Kapitel 3) | ||||
| P-U1 | Alle gesammelten sicherheitsrelevanten Protokolldaten müssen an für den Netzbereich zentralen Stellen gespeichert werden. (OH-SzA 3.1.2) | MUSS | Erfüllt | ⚙ 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) | SOLL | Unterstützt | Architektur |
| P-U3 | Die Protokollierungsinfrastruktur muss ausreichend dimensioniert sein. (OH-SzA 3.1.2) | MUSS | Unterstützt | Skalierbarkeit |
| P-U5 | Die gesammelten Protokolldaten müssen gefiltert, normalisiert, aggregiert und korreliert werden. (OH-SzA 3.1.2) | MUSS | Erfüllt | ⚙ auto SIEM-Korrelation |
| P-U6 | Die bearbeiteten Protokolldaten müssen für die Auswertung geeignet verfügbar gemacht werden. (OH-SzA 3.1.2) | MUSS | Erfüllt | ⚙ auto SIEM-Datenbereitstellung |
| P-U7 | Eine zeitlich befristete Speicherung der unbearbeiteten Rohdaten kann den Detektionsprozess unterstützen. (OH-SzA 3.1.2) | KANN | Erfüllt | ⚙ auto Log-Speicherung/Retention |
| P-U8 | Die Datenquellen auf Netzebene sollten von außen (Netzgrenzen) nach innen erschlossen werden. (OH-SzA 3.1.2) | SOLL | Unterstützt | NDR/Datenquellen-Anbindung |
| P-U9 | Die Systemebene sollte ausgehend von den zentralen, kritischen Systemen erschlossen werden. (OH-SzA 3.1.2) | SOLL | Unterstützt | EDR/Datenquellen-Anbindung |
| P-U11 | Nach der Umsetzung muss geprüft werden, ob alle geplanten Protokollierungsdatenquellen umgesetzt wurden. (OH-SzA 3.1.2) | MUSS | Unterstützt | Datenquellen-Uebersicht |
| Detektion | ||||
| BSI OH SzA (Kapitel 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) | MUSS | Erfüllt | ⚙ 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) | KANN | Erfüllt | ⚙ auto MITRE-ATT&CK-Mapping |
| IT-Grundschutz DER.1 - Detektion (Basis) | ||||
| DER.1.A1.5 | Es MUSS regelmäßig überprüft werden, ob die spezifische Sicherheitsrichtlinie noch korrekt umgesetzt ist. (DER.1 (Basis)) | MUSS | Unterstützt | GRC-Reporting |
| DER.1.A1.6 | Die Ergebnisse der Überprüfung MÜSSEN sinnvoll dokumentiert werden. (DER.1 (Basis)) | MUSS | Unterstützt | 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)) | MUSS | Unterstützt | Datenschutz-Kontrollen |
| DER.1.A3.1 | Für sicherheitsrelevante Ereignisse MÜSSEN geeignete Melde- und Alarmierungswege festgelegt und dokumentiert werden. (DER.1 (Basis)) | MUSS | Unterstützt | Alarmierung |
| DER.1.A3.4 | Je nach Dringlichkeit MUSS ein sicherheitsrelevantes Ereignis über verschiedene Kommunikationswege gemeldet werden. (DER.1 (Basis)) | MUSS | Unterstützt | 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)) | MUSS | Erfüllt | ⚙ 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)) | MUSS | Erfüllt | ⚙ auto SIEM-Korrelation |
| DER.1.A5.3 | Zusätzlich MÜSSEN die protokollierten Ereignisse anderer IT-Systeme überprüft werden. (DER.1 (Basis)) | MUSS | Erfüllt | ⚙ auto SIEM-Korrelation |
| DER.1.A5.4 | Auch SOLLTEN die gesammelten Meldungen in verbindlich festgelegten Zeiträumen stichpunktartig kontrolliert werden. (DER.1 (Basis)) | SOLL | 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)) | MUSS | Erfüllt | ⚙ 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)) | MUSS | Erfüllt | ⚙ auto Automatische Alarmierung |
| DER.1.A5.8 | Die Zuständigen MÜSSEN die Meldungen auswerten und untersuchen. (DER.1 (Basis)) | MUSS | SOC/MDR | MDR Manuelle Triage |
| BSI OH SzA (Kapitel 3) | ||||
| D-U1 | Alle Protokoll- und Protokollierungsdaten müssen kontinuierlich überwacht und ausgewertet werden. (OH-SzA 3.2.2) | MUSS | 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) | KANN | Erfüllt | ⚙ 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) | MUSS | SOC/MDR | MDR Zeitnahe Qualifizierung |
| D-U5 | Aktives Suchen nach SRE muss in Verfahrensanleitungen dokumentiert sein. (OH-SzA 3.2.2) | MUSS | Unterstützt | Retro-Detektion |
| D-U7 | Es müssen Schadcodedetektionssysteme eingesetzt und zentral verwaltet werden. (OH-SzA 3.2.2) | MUSS | Erfüllt | ⚙ 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) | MUSS | Unterstützt | 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) | MUSS | Erfüllt | ⚙ auto NIDS |
| D-U10 | Zur Korrelation und zum Abgleich sollten alle Protokolldaten zeitlich synchronisiert werden. (OH-SzA 3.2.2) | SOLL | Unterstützt | Zeitnormalisierung |
| D-U11 | Die gesammelten Ereignismeldungen müssen regelmäßig auf Auffälligkeiten kontrolliert werden. (OH-SzA 3.2.2) | MUSS | 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) | MUSS | Erfüllt | ⚙ 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) | MUSS | SOC/MDR | MDR Triage/Qualifizierung |
| D-U14 | Informationen aus zuverlässigen Quellen müssen grundsätzlich ausgewertet werden. (OH-SzA 3.2.2) | MUSS | Erfüllt | ⚙ auto Threat Intelligence |
| D-U15 | Alle gelieferten Informationen müssen auf Relevanz für den eigenen Informationsverbund bewertet werden. (OH-SzA 3.2.2) | MUSS | Unterstützt | Relevanzbewertung |
| D-U16 | Relevante Informationen müssen entsprechend der Sicherheitsvorfallbehandlung eskaliert werden. (OH-SzA 3.2.2) | MUSS | Erfüllt | ⚙ auto SOAR/Eskalation |
| D-U17 | Es müssen Mitarbeitende bzw. Dienstleister speziell mit der Auswertung aller Protokolldaten beauftragt werden. (OH-SzA 3.2.2) | MUSS | 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) | MUSS | Erfüllt | ⚙ 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) | MUSS | Erfüllt | ⚙ auto SIEM-Korrelation |
| D-U23 | Alle eingelieferten Protokolldaten müssen lückenlos in der Protokollverwaltung einsehbar und auswertbar sein. (OH-SzA 3.2.2) | MUSS | Erfüllt | ⚙ auto SIEM-Speicherung |
| D-U24 | Die Daten müssen kontinuierlich ausgewertet werden. (OH-SzA 3.2.2) | MUSS | Erfüllt | ⚙ auto SIEM-Korrelation |
| D-U25 | Bei Überschreiten definierter Schwellenwerte muss automatisch alarmiert werden. (OH-SzA 3.2.2) | MUSS | Erfüllt | ⚙ 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) | MUSS | SOC/MDR | MDR SOC-Reaktion |
| D-U27 | Die Systemverantwortlichen müssen die Analyseparameter regelmäßig auditieren und anpassen. (OH-SzA 3.2.2) | MUSS | 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) | MUSS | Erfüllt | ⚙ auto Retro-Detektion |
| D-U29 | Informationen zu aktuellen Angriffsmustern müssen fortlaufend eingeholt werden. (OH-SzA 3.2.2) | MUSS | Erfüllt | ⚙ 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) | MUSS | 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) | SOLL | Erfüllt | ⚙ 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) | SOLL | 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) | SOLL | Unterstützt | 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) | MUSS | 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) | SOLL | Erfüllt | ⚙ auto Auto-Qualifizierung |
| D-U36 | Nur qualifizierte SRE sollten den Reaktionsprozess auslösen. (OH-SzA 3.2.2) | SOLL | Erfüllt | ⚙ auto SOAR-Playbook |
| D-U37 | Die Qualifizierung sollte in nicht eindeutig zuordenbaren Fällen manuell durch festgelegte Verantwortliche erfolgen. (OH-SzA 3.2.2) | SOLL | SOC/MDR | MDR manuelle Triage |
| D-U38 | Basierend auf den Erkenntnissen der Qualifizierung müssen die Detektionsmechanismen nachjustiert werden. (OH-SzA 3.2.2) | MUSS | 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) | MUSS | Unterstützt | GRC-Reporting |
| Reaktion | ||||
| IT-Grundschutz DER.2.1 - Behandlung von Sicherheitsvorfällen (Basis + Standard) | ||||
| DER.2.1.A4.1 | Von einem Sicherheitsvorfall MÜSSEN alle betroffenen internen und externen Stellen zeitnah informiert werden. (DER.2.1 (Basis)) | MUSS | Unterstützt | 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)) | MUSS | Unterstützt | 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)) | MUSS | 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)) | MUSS | Unterstützt | SOAR-Playbook |
| DER.2.1.A5.4 | Anschließend MUSS die Ursache beseitigt und ein sicherer Zustand hergestellt werden. (DER.2.1 (Basis)) | MUSS | Unterstützt | SOAR-Response/IR |
| DER.2.1.A6.1 | Nach einem Sicherheitsvorfall MÜSSEN die betroffenen Komponenten vom Netz genommen werden. (DER.2.1 (Basis)) | MUSS | Erfüllt | ⚙ 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)) | MUSS | Erfüllt | ⚙ 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)) | MUSS | Erfüllt | ⚙ 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)) | MUSS | Unterstützt | 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)) | MUSS | Erfüllt | ⚙ 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)) | SOLL | Unterstützt | 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)) | SOLL | Unterstützt | 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)) | SOLL | Unterstützt | 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)) | SOLL | Unterstützt | 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)) | SOLL | 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)) | SOLL | Unterstützt | Incident Response |
| DER.2.1.A11.1 | Ein einheitliches Verfahren SOLLTE festgelegt werden, um Sicherheitsvorfälle und Störungen einzustufen. (DER.2.1 (Standard)) | SOLL | Unterstützt | Incident Response |
| DER.2.1.A12.4 | Das Sicherheitsmanagement SOLLTE lesenden Zugriff auf eingesetzte Incident-Management-Werkzeuge haben. (DER.2.1 (Standard)) | SOLL | Erfüllt | ⚙ 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)) | SOLL | Unterstützt | 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)) | SOLL | Erfüllt | ⚙ auto Case-Management |
| DER.2.1.A14.6 | Diese SOLLTEN sich auch dafür eignen, vertrauliche Informationen zu verarbeiten. (DER.2.1 (Standard)) | SOLL | Erfüllt | ⚙ 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)) | SOLL | Unterstützt | 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)) | SOLL | Erfüllt | ⚙ auto SIEM-Korrelation |
| DER.2.1.A16.1 | Die Behebung von Sicherheitsvorfällen SOLLTE nach einem standardisierten Verfahren dokumentiert werden. (DER.2.1 (Standard)) | SOLL | Unterstützt | 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)) | SOLL | Erfüllt | ⚙ 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)) | SOLL | Erfüllt | ⚙ 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)) | SOLL | Unterstützt | IR-Dokumentation |
| DER.2.1.A17.1 | Sicherheitsvorfälle SOLLTEN standardisiert nachbereitet werden. (DER.2.1 (Standard)) | SOLL | 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)) | SOLL | Unterstützt | 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)) | SOLL | Unterstützt | 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)) | SOLL | Unterstützt | 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)) | SOLL | 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)) | SOLL | Unterstützt | GRC-Reporting |
| DER.2.1.A17.8 | Besteht sofortiger Handlungsbedarf, MUSS die Institutionsleitung umgehend informiert werden. (DER.2.1 (Standard)) | MUSS | Unterstützt | 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)) | SOLL | Unterstützt | Nachbereitung/Lessons Learned |
| BSI OH SzA (Kapitel 3) | ||||
| R-1 | Bei einem SRE müssen die Detektionssysteme das Ereignis automatisch melden. (OH-SzA 3.3) | MUSS | Erfüllt | ⚙ 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) | MUSS | Erfüllt | ⚙ 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) | MUSS | Erfüllt | ⚙ 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) | MUSS | 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) | MUSS | Unterstützt | Reaktions-Scoping/Konfiguration |
| R-6 | Festgestellte Sicherheitsvorfälle im vermeintlichen Zusammenhang mit Angriffen müssen behandelt werden. (OH-SzA 3.3) | MUSS | 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) | MUSS | Unterstützt | 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) | SOLL | Erfüllt | ⚙ 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) | MUSS | Unterstützt | SOAR-Scoping |
| R-10 | Die eingesetzten SzA sollten auch eine nicht-automatisierte Qualifizierung und Behandlung von Ereignissen unterstützen. (OH-SzA 3.3) | SOLL | Erfüllt | ⚙ auto Case-Management |
Die übrigen 105 Anforderungen sind rein organisatorische Betreiberpflichten (Richtlinien, Rollen, Prozesse). Diese führen wir bewusst nicht öffentlich auf: Die vollständige, aus den amtlichen Quellen erarbeitete Prüfmatrix stellen wir im Rahmen unserer Beratung als Handout bereit, damit Sie sie für Ihren eigenen Aufbau nutzen können. Vollständige Matrix anfragen →
Selbsteinschätzung des Herstellers zur technischen und serviceseitigen Abdeckung. Ersetzt keine Prüfung durch eine prüfende Stelle nach OH SzA. Kontakt: vertrieb@inducio.de.
SzA-Readiness besprechen
Wir ordnen Ihre BSI-SzA- und NIS2-Anforderungen strukturiert ein und zeigen, wie ZephSense Ihren Umsetzungsgrad hebt.