Die elementaren Gefährdungen des BSI und ENISAs Threat Landscape sind ein solider Ausgangspunkt für ein Risikoregister. Zu Ihrem eigenen wird das Ergebnis durch die Entscheidung, die Sie zu jedem Eintrag festhalten, auch zu denen, die Sie weglassen.
Die elementaren Gefährdungen des BSI und ENISAs Threat Landscape sind ein solider Ausgangspunkt für ein Risikoregister. Zu Ihrem eigenen wird das Ergebnis durch die Entscheidung, die Sie zu jedem Eintrag festhalten, auch zu denen, die Sie weglassen.
Am 22. September 2026 hat ENISA eine neue Ausgabe ihrer Threat Landscape veröffentlicht. Sie erfasst Vorfälle und Ereignisse, „observed from 1 January to 31 December 2025" (ENISA publiziert nur auf Englisch; sinngemäss: beobachtet vom 1. Januar bis 31. Dezember 2025). Die Ausgabe 2025 deckte den 1. Juli 2024 bis 30. Juni 2025 ab, die Ausgabe 2024 Juli 2023 bis Juni 2024.
Jede Ausgabe beschreibt, was anderen Organisationen in einem Zeitfenster passiert ist, das bereits geschlossen ist. Ein Katalog hält fest, was anderen passiert ist; ein Register hält fest, was Sie dazu entschieden haben. Deshalb ist ein Katalog ein guter Ort, um mit einem Register anzufangen, und ein schlechter Ort, um damit aufzuhören. Ohne diese Entscheidungen übernommen, erbt ein Register das Datum des Katalogs und die Welt von jemand anderem. Die Arbeit, die es zu Ihrem macht, ist klein, und sie ist der Teil, den ein Auditor liest.
Vorab eine Offenlegung. ISO/IEC 27001:2022 und ISO/IEC 27005:2022 sind kostenpflichtig, und ich habe aus keiner der beiden zitiert. Was folgt, stützt sich auf Dokumente, die jeder lesen kann: die veröffentlichte Zuordnung des BSI zur Norm, das Zertifizierungsschema des BSI und eine Zusammenfassung des American National Standards Institute (ANSI). ANSI-Zitate stehen im englischen Original, jeweils mit sinngemässer deutscher Wiedergabe.
Abschnitt 6.1.2 der ISO/IEC 27001:2022 regelt die Informationssicherheitsrisikobeurteilung, und er überlässt Ihnen die Methode der Identifikation. ANSI beschreibt die Norm als „a nonprescriptive framework" (sinngemäss: ein nicht präskriptives Rahmenwerk) und merkt an, dass die Identifikationsmethode über Assets, Bedrohungen und Schwachstellen „was once a part of ISO/IEC 27001" (sinngemäss: einmal Teil der ISO/IEC 27001 war). Heute steht diese Methode in der Leitfadennorm ISO/IEC 27005, nicht in den Anforderungen.
Ein Katalog ist also ein legitimer Input. Das BSI sagt das in seiner eigenen Zuordnungstabelle vom IT-Grundschutz zur ISO/IEC 27001:2022. Bei Abschnitt 6.1.2 führt sie den BSI-Standard 200-3 auf und die „Elementare Gefährdungen (G0-Gefährdungen) des IT-Grundschutz-Kompendiums".
Die Freiheit hat eine Bedingung. Die Hinweise zur Bereitstellung der Referenzdokumente für die Zertifizierung verlangen eine dokumentierte Richtlinie zur Risikoanalyse. Danach heisst es: „Die Risikoanalyse ist entsprechend der selbst definierten Richtlinie zur Risikoanalyse durchzuführen und zu dokumentieren." Als Beispielmodelle nennen die Hinweise den BSI-Standard 200-3 und ISO/IEC 27005. Sie wählen die Methode. Danach werden Sie an ihr gemessen.
ISO/IEC 27005:2022 beschreibt zwei Wege, Risiken zu identifizieren. ANSIs Zusammenfassung bringt es in einer Zeile unter: „The event-based approach was contrasted with the asset-based approach to risk identification." (Sinngemäss: Der ereignisbasierte Ansatz wurde dem assetbasierten Ansatz zur Risikoidentifikation gegenübergestellt.) Dieselbe Ausgabe hat Konzepte für Risikoszenarien eingeführt. Den Normtext kann ich nicht lesen, ohne ihn zu kaufen, also werde ich nicht im Detail wiedergeben, was die beiden Ansätze sagen.
Sagen kann ich, wo ein Gefährdungskatalog hineinpasst. Die assetbasierte Methode arbeitet sich durch Assets, Bedrohungen und Schwachstellen. Ein Katalog liefert Ihnen die Bedrohungsspalte, vorausgefüllt. Er weiss nichts über Ihre Assets, Ihren Geltungsbereich oder darüber, welche Ereignisse Ihrem Management tatsächlich Sorgen machen.
Das BSI sagt ausdrücklich, was sein Katalog ist. Laut BSI-Standard 200-3 hat das BSI die Gefährdungen aus seinen Bausteinen verdichtet und „in 47 elementare Gefährdungen überführt". Er nennt die Ziele: Die elementaren Gefährdungen sind „für die Verwendung bei der Risikoanalyse optimiert", „produktneutral (immer)" und „kompatibel mit vergleichbaren internationalen Katalogen und Standards". Er sagt auch, was mit Absicht fehlt. Gefährdungen, „die überwiegend die fehlende oder unzureichende Umsetzung von Sicherheitsmaßnahmen thematisieren", „wurden bewusst nicht benannt". Der Katalog benennt Dinge, die passieren, etwa G 0.1 Feuer, G 0.8 Ausfall oder Störung der Stromversorgung oder G 0.28 Software-Schwachstellen oder -Fehler. Ihre Schwachstellen tragen Sie selbst ein.
Der BSI-Standard 200-3 wendet den Katalog nicht pauschal an, sondern je Zielobjekt. Ein Zielobjekt ist das, was Sie gerade analysieren: eine Anwendung, ein IT-System, ein Raum oder ein ganzer Geschäftsprozess. Für jedes Objekt und jede elementare Gefährdung entscheiden Sie eines von drei Dingen (Kapitel 4.1):
Das Beispiel des Standards selbst ist ein Server-Betriebssystem. G 0.25 Ausfall von Geräten oder Systemen ist relevant. G 0.1 Feuer ist es nicht: „Ein Betriebssystem bietet keine spezifischen Schutzmaßnahmen gegen Feuer". Nach derselben Logik gehört das Feuer zu dem Raum, in dem der Server steht. Derselbe Katalogeintrag bekommt auf verschiedenen Objekten verschiedene Antworten, und genau darum geht es bei der Übung.
Das Ergebnis ist „eine Tabelle …, in der jedem Zielobjekt eine Liste mit relevanten elementaren Gefährdungen zugeordnet ist". Danach folgt ein zweiter Durchgang für zusätzliche Gefährdungen, die sich aus Ihrer konkreten Umgebung ergeben. Kapitel 4.2 behält diejenigen, „die zu einem nennenswerten Schaden führen können" und „die im vorliegenden Anwendungsfall und Einsatzumfeld realistisch sind". Und es fügt eine Warnung an, die ich über jedes aus einem Katalog befüllte Register drucken würde: „Wenn relevante Gefährdungen nicht berücksichtigt werden, kann dies zu Lücken im resultierenden Sicherheitskonzept führen."
Der Standard 200-3 bewertet jedes Risiko ausserdem zweimal. Die erste Bewertung geht davon aus, dass „bereits Sicherheitsmaßnahmen umgesetzt oder geplant worden sind". Die zweite betrachtet die Massnahmen, die zur Behandlung hinzukommen. „Durch einen Vorher-Nachher-Vergleich lässt sich die Wirksamkeit der Sicherheitsmaßnahmen prüfen, die zur Risikobehandlung eingesetzt worden sind." Behalten Sie das im Kopf, wenn Ihnen ein Katalog fertige Bewertungen liefert. Eine vorausgefüllte „Nachher"-Bewertung beschreibt die Vorstellung von jemandem über eine Behandlung, und das muss nicht Ihre sein.
Es gibt einen veröffentlichten Satz von Anweisungen an Auditoren, auf den ich verweisen kann. Es ist das Auditierungsschema des BSI für ISO 27001-Zertifizierungen auf der Basis von IT-Grundschutz, Version 2.5. Es gilt nur für dieses Schema, nicht für jede akkreditierte Zertifizierungsstelle. Trotzdem halte ich es für die konkreteste öffentliche Aussage darüber, was angeschaut wird. Drei Passagen zählen hier:
Lesen Sie das gegen ein Register, das aus einem Katalog befüllt wurde. Der Auditor zieht Stichproben aus den Massnahmen, also braucht jeder behaltene Eintrag eine Behandlung, für die jemand verantwortlich ist. Ausschlüsse werden gelesen, also braucht jedes „nicht relevant" einen Satz Begründung. Übernommene Risiken brauchen eine namentlich genannte freigebende Person. Die Richtlinien-Checkliste in 200-3 stellt dieselbe Frage in schlichteren Worten: „Sind Risiken den jeweiligen Risikoeigentümern zugeordnet?"
Das ist das Protokoll, das ich führen würde: eine Zeile pro Katalogeintrag und Geltungsbereich, verworfene Einträge eingeschlossen. Die Zeilen sind illustrativ, nicht aus einem echten Register.
| Katalogeintrag | Ausgabe | Geltungsbereich / Objekt | Relevanz | Begründung | Verantwortlich | Eigene Bewertung (Anfangs- → Restrisiko) |
|---|---|---|---|---|---|---|
| BSI G 0.1 Feuer | Kompendium 2023 | Kunden-Webanwendung | Nicht relevant | Die Anwendung bietet keine Schutzmassnahmen gegen Feuer; stattdessen am Hosting-Standort bewertet | Leitung IT | n/a |
| BSI G 0.1 Feuer | Kompendium 2023 | Colocation-Rack | Direkt relevant | Raum des Anbieters; die Löschanlage ist seine Sache, die Backups sind unsere | Leitung IT | 2×9 → 2×5 |
| ENISA Ransomware | ETL 2024 (Juli 2023 bis Juni 2024) | Dateifreigaben | Direkt relevant | Freigegebene Laufwerke auf jedem Client eingebunden | Leitung IT | 6×8 → 3×6 |
Die Spalte „Ausgabe" ist wichtiger, als sie aussieht. Wenn ENISA ihr Berichtsfenster verschiebt, sagt Ihnen eine Zeile, die ihre Ausgabe nennt, welche Einträge Sie neu lesen müssen. Eine Zeile ohne diese Angabe lässt Sie raten. Halten Sie auch die „nicht relevant"-Zeilen fest. Sie sind die Antwort, wenn jemand fragt, warum Feuer in Ihrem Register fehlt.
Mit App 2.3.0 hat devguard einen Risikokatalog bekommen. Er kann „create risks from the BSI IT-Grundschutz elementary threats, the ENISA Threat Landscape, CSA Top Threats, the OWASP Top 10 and the NIS2 and DORA operational risk areas" (sinngemäss: Risiken aus den elementaren Gefährdungen des BSI IT-Grundschutzes, der ENISA Threat Landscape, den CSA Top Threats, den OWASP Top 10 sowie den operationellen Risikobereichen von NIS2 und DORA anlegen). So verhält er sich zum Protokoll oben.
Die Auswahl gruppiert die Einträge nach Quelle und nennt die Ausgabe, der jede folgt. Die BSI-Einträge folgen dem Kompendium 2023 und decken eine Auswahl der elementaren Gefährdungen ab, nicht alle 47. Die ENISA-Einträge folgen der Threat Landscape 2024. Jeder Eintrag zeigt die Referenz der Quelle selbst, etwa G 0.1. Sie können nichts anlegen, bevor Sie eine verantwortliche Rolle gewählt haben, und jeder Eintrag in einem Durchgang bekommt diese Rolle. Jeder Eintrag bringt eine Beschreibung mit, eine Beschreibung der Auswirkung, eine Behandlungsstrategie samt Beschreibung der Behandlung sowie eine Anfangs- und eine Restrisikobewertung. Die Restrisikobewertung setzt voraus, dass die beschriebene Behandlung umgesetzt ist, also bewerten Sie sie gegen die Behandlung neu, die Sie tatsächlich haben. Der Einrichtungsassistent wählt Einträge vor, die zu Ihren Antworten über Ihren Betrieb passen, etwa Cloud oder On-Premises. Entfernen Sie das Häkchen bei denen, die nicht passen.
Drei Dinge tut er bewusst nicht:
Das Urteil bleibt bei Ihnen. Der Katalog erspart Ihnen das Abtippen; die Entscheidung, die zu jedem Eintrag festgehalten ist, mit einem Namen und einem Datum daneben, ist das, was ein Auditor liest.
Der Risikokatalog ist mit devguard App 2.3.0 erschienen.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.