Was DET und REA im Katalog abdecken
Eigene Auszählung im Anwenderkatalog Grundschutz++, Build 2026-10-29, rekursiv über alle Verschachtelungsebenen:
| Praktik | Teilpraktiken | Anforderungen | MUSS / SOLLTE / KANN | ohne Zielobjektkategorie | mit Parameter |
|---|---|---|---|---|---|
| DET Detektion | 6 (Grundlagen, Meldung von Ereignissen, Protokollierung, Überwachung von Aktivitäten, Management von Schwachstellen, Vorfallserkennung) | 82 | 5 / 38 / 39 | 43 | 35 |
| REA Sicherheitsvorfallsbehandlung | 3 (Grundlagen, Reaktion, Nachbereitung) | 23 | 5 / 13 / 5 | 23 | 6 |
Drei Eigenschaften prägen die Arbeit. REA hat keine einzige Anforderung mit Zielobjektkategorie; nach Kapitel 3.4.1 von BSI-Standard 300-1 gehören alle 23 ohne Zuordnung zu Assets in das Anforderungspaket. Welche davon anzuwenden sind, richtet sich nach Sicherheitsniveau und Modalverb (Kapitel 3.4.2 und 4.1.2): 17 stehen auf normal-SdT (5 MUSS, 12 SOLLTE), die sechs auf „erhöht“ sind fünf KANN-Anforderungen und REA.2.5 (siehe Katalogbefund unten). In DET ist fast die Hälfte KANN (39 von 82): Ein Security Operations Center (DET.2.2), ein ständiger Bereitschaftsdienst (DET.2.3), Threat Hunting (DET.5.6) oder Red Teaming (DET.5.5) sind bei normalem Schutzbedarf optional. Und DET hat mit 35 Anforderungen mit Parameter viele offene Werte, etwa Fristen, Kriterien, Schwellwerte und den „automatisierten Mechanismus“. Nach Kapitel 3.5 legt die Institution sie fest; ohne festgelegte Kriterien lässt sich DET.6.1 nicht prüfen.
BSI-Standard 300-1 selbst greift das Thema in Kapitel 5.4 auf: „Im Rahmen des Monitorings müssen folgende Verfahren verankert werden“, darunter ein Verfahren zur Erkennung von Sicherheitsvorfällen, das nach Größe und Komplexität der Institution von manuellen Prozessen bis zu automatisierten Erkennungssystemen reichen kann. Kapitel 5.2.1 nennt die Leistungsfähigkeit der Detektion und Sicherheitsvorfallbehandlung als Aspekt, den die Ziele des internen Auditprogramms berücksichtigen sollten, Kapitel 5.3 die Sicherheitsvorfälle als Gegenstand der Managementbewertung.
Der Fall: verdächtige Anmeldungen am Fernzugang (fiktiv)
Das Statistische Amt Westmark (SAW) ist erfunden, ebenso alle Personen, Zeiten, Zahlen und Ergebnisse; Kennungen und Anforderungen stammen aus dem Katalog. Das SAW hat rund 600 Beschäftigte, einen Fernzugang über einen VPN-Verbund aus zwei Knoten mit Mehr-Faktor-Authentisierung per Push-Bestätigung und ein SIEM, das die Protokolle von Fernzugang, Verzeichnisdienst und Dateiservern zusammenführt. Eine Rufbereitschaft für die Vorfallsbehandlung ist werktags von 7 bis 19 Uhr besetzt. Die Geschäftsprozesse des SAW haben in allen Schutzzielen normalen Schutzbedarf.
Vorab festgelegt sind (fiktiv): die Protokollierungsfrist für DET.3.1 auf 180 Tage, abgestimmt mit dem Datenschutz; die Kriterien nach DET.6.1 und DET.6.1.1 in einer Regelliste des SIEM; als zu alarmierende Rolle nach DET.6.1.2 die Rufbereitschaft; für REA.2.5 als Kriterium für eine forensische Analyse „Anzeichen für einen erfolgreichen Zugriff Unbefugter auf schützenswerte Informationen“. Die Triage nach REA.2.1 arbeitet mit drei Prioritäten.
Triage-Kriterien des SAW (fiktiv)
REA.2.1 (SOLLTE) verlangt, Meldungen einer Priorität zuzuweisen. Die Katalogerläuterung beschreibt Triage als Vorgehen, bei dem festgestellt wird, „welche Vorfälle sofortige Aufmerksamkeit benötigen, welche weiter analysiert oder beobachtet werden oder irrelevante Fehlalarme sind“. Das SAW hat dafür festgelegt:
| Priorität | Kriterium (Auswahl) | Reaktion | Eskalation nach REA.2.6.5 |
|---|---|---|---|
| 1 | Anzeichen für erfolgreichen unbefugten Zugriff, Schadcode auf Servern, Ausfall eines Geschäftsprozesses | Erstreaktion sofort, Bearbeitung ohne Unterbrechung | ISB und Leitung IT sofort, Amtsleitung bei Bestätigung |
| 2 | Versuchter Angriff ohne Anzeichen für Erfolg, Schadcode auf einem Client, Ausfall der Protokollierung | Bearbeitung am selben Arbeitstag | ISB am selben Tag |
| 3 | Einzelmeldung ohne erkennbare Auswirkung, vermuteter Fehlalarm | Bearbeitung im Regelbetrieb | keine; Rückmeldung an die meldende Person |
Vorfallsprotokoll: vom Ereignis zur Behandlung
Fiktives Beispiel. Anforderungen aus dem Anwenderkatalog Grundschutz++ (Build 2026-10-29), als Infinitiv gekürzt, Parameter in eckigen Klammern, Modalverb und Zielobjektkategorie in Klammern („ohne“ = ohne Zielobjektkategorie). Zeiten, Prüffragen und Belege sind erfunden.
| Zeit | Schritt | Anforderung | Prüffrage | Beleg im Fall | Übergabe an |
|---|---|---|---|---|---|
| Mo 07:12 bis 07:31 | Protokollierung | DET.3.1.1 Authentifizierungen bei Erfolg und Fehlschlag protokollieren (SOLLTE, IT-Systeme); DET.3.1.7 zu jedem Ereignis mindestens Zeitpunkt, Quelle und Zielobjekt protokollieren (SOLLTE, Anwendungen) | Sind Fehlversuche und Erfolg mit Zeit, Quell-IP und Konto im SIEM? | 38 Fehlversuche am Konto einer Sachbearbeiterin, danach erfolgreiche Anmeldung von einer bisher nicht genutzten Quelladresse mit bestätigter Push-Anfrage | SIEM |
| 07:32 | Beurteilung und Alarm | DET.6.1 Verfahren zur Beurteilung anhand von [Kriterien]; DET.6.1.1 kritische Vorfälle anhand von [Kriterien] durch [einen automatisierten Mechanismus] protokollieren; DET.6.1.2 Alarmierung von [für die Vorfallsbehandlung zuständigen Personen oder Rollen] durch [einen automatisierten Mechanismus] (alle SOLLTE, ohne) | Hat die Regel ausgelöst, und hat der Alarm die Rufbereitschaft erreicht? | SIEM-Alarm der Regel „Erfolg nach mehr als 20 Fehlversuchen“, Zustellbestätigung an die Rufbereitschaft | Rufbereitschaft |
| 07:35 | Meldung | DET.2.1 Meldeverfahren verankern; DET.2.1.1 Regelungen für Sofortmaßnahmen durch Nutzende verankern (SOLLTE, ohne) | Wusste die Sachbearbeiterin, wo und wie sie meldet und was sie sofort tun soll? | Anruf beim Servicedesk: mehrere Push-Anfragen erhalten, eine versehentlich bestätigt; Meldeformular ausgefüllt, Arbeit am Gerät eingestellt | Rufbereitschaft (Zusammenführung mit dem Alarm) |
| 07:41 | Triage | REA.2.1 Meldungen einer Priorität zuweisen (SOLLTE, ohne) | Passt die Priorität zu den festgelegten Kriterien? | Priorität 1 im Vorfallsticket, Begründung „Anmeldung nach Fehlversuchen, Bestätigung durch die Nutzerin unbeabsichtigt“ | ISB und Leitung IT (Eskalation) |
| 07:44 | Erstreaktion | BER.3.9 Zugangskonten ereignisgesteuert deaktivieren; BER.5.14 Sperrung kompromittierter Authentifizierungsmittel verankern; BER.5.3 Vorgehensweise zum Widerruf von Authentifizierungsmitteln verankern (alle SOLLTE, ohne) | Sind Konto, aktive Sitzungen und registrierte MFA-Geräte gesperrt? | Sperrprotokoll aus dem Identitätsdienst; VPN-Sitzung um 07:46 beendet | Berechtigungsverwaltung |
| 08:10 | Dokumentation, Koordinierung | REA.2.3 den Vorfall dokumentieren; REA.2.6.3 die Koordinierung bei Vorfällen verankern; REA.2.6.5 eine Eskalationsleiter verankern (SOLLTE, ohne) | Ist eine Person als Koordinatorin benannt, und läuft alles über ein Ticket? | Vorfallsticket mit Zeitleiste, Koordination durch den ISB, Datenschutz um 08:20 einbezogen | alle Beteiligten |
| 08:30 | Diagnose | REA.2.4 Diagnosemethoden verankern, wenn sich der Vorfall mit den standardisiert erfassten Informationen nicht ausreichend analysieren lässt (SOLLTE, ohne) | Reichen die Standardprotokolle, um zu sagen, was die Gegenseite in 15 Minuten getan hat? | Nein: Dateiserver-Zugriffe nur zusammengefasst; Protokollstufe vorübergehend erhöht, Rohdaten exportiert. Dabei fällt auf, dass Knoten 2 des VPN-Verbunds seit neun Tagen keine Protokolle an das SIEM liefert (Befund 1) | IT-Betrieb |
| 10:00 | Entscheidung Forensik | REA.2.5 forensische Analyse bei Vorfällen ausführen, die [bestimmte Kriterien] erfüllen (SOLLTE, Sicherheitsniveau erhöht, ohne); REA.2.5.1 rechtlich relevante Beweise rechtssicher dokumentieren (SOLLTE, ohne) | Ist das Kriterium erfüllt, und sind Beweise mit Prüfsumme gesichert? | Kriterium erfüllt: 214 Dateinamen aufgelistet, 3 Dateien geöffnet. Beauftragung des vorab vereinbarten Forensik-Dienstleisters (REA.2.5.3, KANN); Sicherungsprotokoll mit Hashwerten und getrennt aufbewahrter Kopie | Forensik-Dienstleister, Rechtsabteilung |
| Di bis Do | Ursachenanalyse und Behandlung | REA.2.6 Vorgehensweise zur Ursachenanalyse und Behandlung verankern; REA.2.6.1 die zur Behandlung durchgeführten Tätigkeiten dokumentieren (SOLLTE, ohne) | Ist die Ursache gefunden, und sind andere Konten mit derselben Schwäche geprüft? | Ursache: Passwort aus einem fremden Datenleck, Push-MFA ohne Schutz gegen ungewollte Bestätigung (Befund 2). Behandlung: neue Zugangsdaten, Prüfung aller Konten gegen bekannte Leaks, keine weiteren Treffer | ISB, Leitung IT |
| Mi | Kommunikation | REA.2.6.2 Vorgehensweise zur Kommunikation bei Vorfällen unter Berücksichtigung von Compliance-Verpflichtungen, Bedürfnissen der interessierten Parteien und der Geschäftsziele verankern; REA.2.6.2.1 die zuständigen Behörden im Einklang mit den Compliance-Verpflichtungen informieren (SOLLTE, ohne) | Hat die zuständige Stelle geprüft, ob und an wen gemeldet werden muss, und ist die Entscheidung dokumentiert? | Vermerk von Rechtsabteilung und Datenschutz mit Entscheidung und Datum; Kommunikation an die betroffene Fachabteilung | Amtsleitung |
| Fr | Rückmeldung | DET.2.1.3 Verfahren für Rückmeldungen verankern (SOLLTE, ohne) | Weiß die meldende Person, was aus ihrer Meldung geworden ist? | Gespräch mit der Sachbearbeiterin, Vermerk im Ticket | Personalentwicklung (Praxisbeispiel für die Unterweisung, siehe Sensibilisierung) |
| Folgewoche | Nachbereitung | REA.3.1 bisherige Maßnahmen anhand von Erkenntnissen aus Vorfällen [regelmäßig] überprüfen; REA.3.1.1 Erkenntnisse einschließlich Art, Umfang und Schäden dokumentieren (SOLLTE, ohne) | Sind Art, Umfang und Schaden festgehalten und die Maßnahmen im Umsetzungsplan? | Abschlussbericht: unbefugter Zugriff, ein Konto, 15 Minuten Sitzung, 3 Dateien geöffnet, kein Abfluss nachweisbar; zwei Maßnahmen im Umsetzungsplan | Managementbericht |
Die Uhrzeiten im Protokoll sind nur vergleichbar, wenn alle Systeme dieselbe Zeit haben. Die Erläuterung zu DET.3.1.7 nennt eine einheitliche Zeitquelle als Voraussetzung, und KONF.4.5 (SOLLTE, IT-Systeme) verlangt, Zeitquellen zu autorisieren; das gehört in die Grundkonfiguration, siehe Konfiguration und Assets.
Was der Vorfall über den Status der Anforderungen sagt
Ein Vorfall ist auch eine Prüfung unter Echtbedingungen. Das SAW überträgt die Erkenntnisse in den Umsetzungsstatus (fiktiv):
| Anforderung | Status nach dem Vorfall | Begründung und Folge |
|---|---|---|
| DET.6.1.2 Alarmierung der zuständigen Rolle durch einen automatisierten Mechanismus (SOLLTE) | erfüllt | Alarm nach einer Minute zugestellt, Zustellbestätigung im SIEM |
| REA.2.1 Meldungen einer Priorität zuweisen (SOLLTE) | erfüllt | Priorität nach den festgelegten Kriterien vergeben und begründet |
| DET.4.1 Funktionsfähigkeit der Protokollierung überwachen (SOLLTE, ohne) | nicht erfüllt, temporär | Befund 1: Ausfall der Protokollweiterleitung von Knoten 2 neun Tage unbemerkt. Die Erläuterung nennt als mögliche Kriterien die Aktivierung oder Deaktivierung des Loggings und die Datenmenge eingehender Logs in einem Zeitraum. Maßnahme: SIEM-Regel auf ausbleibende Protokolle je Quelle, Frist zwei Wochen |
| BER.5.8 phishing-resistente Mehr-Faktor-Authentisierung für alle von extern erreichbaren Schnittstellen aktivieren (SOLLTE, Anwendungen und Externe Netzanschlüsse) | nicht erfüllt, temporär | Befund 2: Push-Bestätigung ist nicht phishing-resistent. Maßnahme: Umstellung des Fernzugangs auf phishing-resistente Verfahren mit Frist im Umsetzungsplan; Übergabe an die Berechtigungsverwaltung |
| BER.6.6 Zugangsdaten durch [einen automatisierten Mechanismus] auf Kompromittierung überwachen (SOLLTE, ohne) | vorher nicht erfüllt, jetzt erfüllt | Abgleich gegen bekannte Leaks war bisher nicht eingerichtet; seit der Behandlung als wöchentlicher Lauf |
Für die temporär nicht erfüllten SOLLTE-Anforderungen gilt die bekannte offene Auslegungsfrage: Nach Kapitel 4.1.2 löst eine temporäre Nichterfüllung keine Risikobetrachtung aus, nach Kapitel 2.11 ist für SOLLTE-Anforderungen in der Umsetzungsplanung eine Restrisikobetrachtung durchzuführen und das Risiko von der Institutionsleitung freizugeben, und Kapitel 4.1.1 verlangt, das Risiko zu identifizieren und der Leitung mitzuteilen. Das SAW beschreibt das Restrisiko bis zur Umstellung des Fernzugangs, teilt es mit und lässt es befristet freigeben. Würde die Umstellung auf absehbare Zeit nicht erfolgen, wäre die Nichterfüllung dauerhaft und eine Risikobetrachtung nach Kapitel 2.11 fällig; siehe Risikoanalyse.
Wie die Status mit Datum, prüfender Person und Nachweis nach Kapitel 4.3 festgehalten werden, zeigt der Nachweisplan; die Regeln für Status und Abweichungen stehen unter Anforderungen bewerten, Abweichungen dokumentieren.
Katalogbefund: REA.2.5 und DET.4.12.1
Nach Kapitel 3.4.2 von 300-1 enthalten Anforderungen mit Sicherheitsniveau „erhöht“ das Modalverb KANN und sind optional. Im Build vom 29. Oktober 2026 trifft das auf drei Anforderungen nicht zu, die SOLLTE mit „erhöht“ verbinden (eigene Auszählung): REA.2.5 „IT-Forensik“, DET.4.12.1 „Auslastung des Netzes“ und BES.1.4 „Outsourcing-Strategie“. Zwei davon gehören zu diesem Praxisbündel.
Der Standard sagt nicht, wie diese Kombination zu behandeln ist. REA.2.5 hat keine Zielobjektkategorie und stünde nach Kapitel 3.4.1 verpflichtend im Paket; sie ist aber dem Sicherheitsniveau „erhöht“ zugeordnet, das bei normalem Schutzbedarf nach Kapitel 3.4.2 nicht ausgewählt wird. Das SAW nimmt REA.2.5 trotzdem auf, weil ihre Unteranforderung REA.2.5.1 (rechtssichere Beweissicherung) auf normal-SdT steht und ohne Kriterien für eine Forensik schwer zu erfüllen ist. Halten Sie Ihre Entscheidung mit Begründung und Katalogstand fest und prüfen Sie sie bei jedem neuen Build.
Übergaben zwischen Detektion, Behandlung und ISMS
- DET an REA: Die Übergabe ist der Alarm oder die Meldung, die bei der für die Vorfallsbehandlung zuständigen Rolle ankommt (DET.6.1.2, DET.2.1). Legen Sie fest, wer sie annimmt, auch außerhalb der Bereitschaftszeiten. Ein ständiger Bereitschaftsdienst ist mit DET.2.3 eine KANN-Anforderung; ohne ihn gehört in die Regelung, was mit Alarmen in der Nacht geschieht.
- Dienstleister an REA: Meldet ein Anbieter einen Vorfall, der das SAW betrifft, kommt die Meldung über den vertraglich vereinbarten Meldeweg (BES.5.10.2) und läuft dann durch dieselbe Triage. Den Beschaffungsteil zeigt Beschaffung und Dienstleister.
- REA an die Berechtigungsverwaltung: Sperren, Widerruf und Neuausgabe von Authentifizierungsmitteln. Den Regelablauf für Konten zeigt Berechtigungen und Personal.
- REA an die Rechtsabteilung und den Datenschutz: die Frage nach Meldepflichten. Die Katalogerläuterung zu REA.2.6.2 verweist auf Meldepflichten gegenüber Aufsichts- oder Ermittlungsbehörden und auf die Information Betroffener, und empfiehlt im Zweifel interne oder externe Rechtsberatung. Wir ordnen die Vorgaben ein, die Sie nennen oder die in Ihren Unterlagen stehen; ob sie rechtlich gelten, prüft Ihre Rechtsabteilung. Fragen zur NIS2-Umsetzung behandelt die Firmenseite https://www.blackfort-tec.de.
- REA an das ISMS: Nach Kapitel 6.2 von 300-1 gehört die Auswertung von Sicherheitsvorfällen zu den Wegen, Verbesserungspotenziale zu erkennen; nach Kapitel 6.3 wird der Korrektur- und Verbesserungsplan in den Umsetzungsplan aufgenommen. Die Sicherheitsvorfälle gehen in die Managementbewertung (Kapitel 5.3); siehe Managementbewertung und Kennzahlen.
- Vorfall an die Sensibilisierung: Ein echter Fall wie die versehentlich bestätigte Push-Anfrage eignet sich als Beispiel in der Unterweisung; wie Sie Unterweisungen planen und ihre Wirkung prüfen, zeigt Sensibilisierung.
- Vorfall an die Notfallplanung: Fällt ein Geschäftsprozess länger aus, greift die Praktik NOT. BSI-Standard 200-4 zum Business Continuity Management ist durch 300-1 nicht abgelöst.
Prüffragen zu Detektion und Vorfallsbearbeitung
- Sind die Parameter in DET und REA festgelegt: Protokollierungsfrist (DET.3.1), Beurteilungskriterien (DET.6.1, DET.6.1.1), alarmierte Rolle (DET.6.1.2), Kriterien für Forensik (REA.2.5)?
- Wird überwacht, ob jede Protokollquelle liefert, und ist festgelegt, nach welcher Zeit ein Ausfall auffallen muss (DET.4.1)?
- Kennen Nutzende den Meldeweg und die Sofortmaßnahmen, und bekommen sie eine Rückmeldung (DET.2.1, DET.2.1.1, DET.2.1.3)?
- Gibt es Triage-Kriterien mit Prioritäten und eine Eskalationsleiter, die bis zur Leitung reicht (REA.2.1, REA.2.6.5)?
- Ist die Erstreaktion für die vorab festgelegten Fallarten vorbereitet, etwa Konto sperren, Sitzungen beenden, Authentifizierungsmittel widerrufen (BER.3.9, BER.5.3, BER.5.14)?
- Gibt es Diagnosemethoden für den Fall, dass die Standardprotokolle nicht reichen (REA.2.4)?
- Sind Beweise so gesichert, dass nachvollziehbar ist, wie sie erhoben wurden, und sind sie gegen Einsicht und Veränderung geschützt (REA.2.5.1)? Die Erläuterung nennt kryptografische Signaturen oder getrennt aufbewahrte Checksummen als Mittel.
- Ist die Kommunikation geregelt, einschließlich der Prüfung möglicher Meldepflichten durch die zuständige Stelle (REA.2.6.2, REA.2.6.2.1)?
- Fließen Art, Umfang und Schaden jedes Vorfalls in die Überprüfung der Maßnahmen und in den Managementbericht (REA.3.1, REA.3.1.1)?
Blackfort Technology unterstützt Sie dabei mit Paket C der Umsetzung nach Grundschutz++: Statusermittlung je Anforderung, darunter DET und REA, Festlegung der Parameter mit Ihnen und ein Nachweisplan, der Protokollierung, Alarmierung und Vorfallstickets den Anforderungen zuordnet.