Grundschutz++ Modellierung: vom Asset zum Anforderungspaket

Im zweiten Prozessschritt, der Anforderungsanalyse, werden die identifizierten Assets des Informationsverbunds Zielobjektkategorien zugeordnet. Kapitel 3 beschreibt Zielobjektkategorien als „standardisierte Klassen (z. B. Anwendungen, IT-Systeme) zu den im GS++ beschriebenen Anforderungen“. Kapitel 3.4.2 regelt die Zuordnung: Sie ordnen jedem Asset mindestens eine Kategorie zu und nehmen alle darüberliegenden Kategorien mit; an jeder dieser Kategorien hängen Anforderungen.

Der Anwenderkatalog führt diese Schritte als Methodik-Anforderungen der Praktik Strukturmodellierung. STM.2.1.3 verlangt: „Strukturmodellierung MUSS allen relevanten Assets eine oder mehrere Zielobjektkategorien zuweisen.“ Die Erläuterung dazu verlangt eine funktionsorientierte Zuordnung: Es zählt, wie das Asset im Geschäftsprozess wirkt, technische Merkmale allein genügen nicht. Schwer zuordenbare Assets werden in der Risikobetrachtung analysiert. STM.2.1.4.1 regelt die Vererbung: Die in der Hierarchie übergeordneten Kategorien werden dem Asset ebenfalls zugewiesen. Laut Erläuterung werden dabei alle Elternknoten bis zur Wurzel einbezogen; die Vererbung ist deterministisch und lässt sich automatisieren.

Anforderungen, die über mehrere Assets oder mehrere Kategorien mehrfach auftreten, sind nach Kapitel 3.4 nur einmal im Anforderungspaket zu berücksichtigen. Im Katalog steht dafür STM.2.1.4.2 „Konsolidierung und Redundanzprüfung“. Wir empfehlen, im Paket die Zuordnung zu allen betroffenen Assets zu behalten, damit Sie bei der späteren Prüfung des Umsetzungsstatus wissen, wo Sie nachsehen müssen.

Kapitel 3.4 unterscheidet drei Arten von Anforderungen. Die Zahlen in der Tabelle stammen aus unserer eigenen Zählung im Anwenderkatalog Grundschutz++, Build vom 29.10.2026, rekursiv über alle Ebenen verschachtelter Anforderungen. Sie ändern sich mit jedem Build.

Anhang 1 von 300-1 definiert 39 Zielobjektkategorien, Abbildung 6 zeigt ihre Hierarchie: sieben Wurzelknoten, bis zu vier Ebenen. Die Tabelle gibt je Kategorie den Pfad bis zur Wurzel und die Zahl der Anforderungen an, die im Katalog direkt dieser Kategorie zugeordnet sind. Über die Vererbung erhält ein Asset zusätzlich die Anforderungen aller übergeordneten Kategorien. Drei Namen weichen zwischen Standard und Katalog ab: Datenträgerarchiv heißt im Katalog „Archiv“, Fax(-anwendungen) „Faxanwendungen“, Interpersonelle Kommunikationsanwendungen „Interpersonelle Kommunikation“. Abbildung 6 nennt die Mobilen Endgeräte verkürzt „Endgeräte“.

Fiktives Beispiel: Die Förderstelle eines Landes modelliert den Geschäftsprozess GP-01 „Förderanträge bearbeiten“ mit hohem Schutzbedarf. Die Assets A-01 bis A-12 stammen aus dem Mini-Inventar auf der Seite zur Strukturanalyse. Die Spalte „Anforderungen je Asset“ zählt die Anforderungen aller zugeordneten und vererbten Kategorien, jeweils für dieses Asset allein. Alle Zahlen sind mit dem Katalog-Build vom 29.10.2026 gerechnet.

Nach der ersten Runde lohnt ein Blick auf die Kategorien, denen weder direkt noch über Vererbung ein Asset zugeordnet ist. Im Beispiel waren das 14 von 39. Für jede wird entschieden, ob ein Asset fehlt oder ob die Kategorie im Verbund tatsächlich nicht vorkommt. Diese Prüfung schreibt 300-1 nicht als eigenen Schritt vor; sie ist ein Vorschlag, um vergessene Assets zu finden, bevor ein Audit sie findet.

Zu den 611 Anforderungen aus der Modellierung kommen die 364 Anforderungen ohne Zielobjektkategorie. Das Paket für GP-01 umfasst damit 975 der 1.000 Anforderungen des Builds. Für die Umsetzung zählt die Aufteilung nach Sicherheitsniveau und Modalverb.

An einer Stelle widersprechen sich Standard und Katalog im aktuellen Build. 300-1 sagt in Kapitel 3.4.1: „Alle weiteren Anforderungen ohne zugewiesene Zielobjektkategorie sind verpflichtend in das Anforderungspaket aufzunehmen.“ Die Erläuterung zur Katalog-Anforderung STM.2.1.5 beschreibt dagegen eine Relevanzentscheidung je Anforderung; nicht relevante Anforderungen werden mit Begründung aus dem Paket gestrichen. Auch der Umsetzungsstatus weicht ab: Der Standard kennt in Kapitel 4.1.1 „erfüllt“, „nicht erfüllt“ und „nicht anwendbar“, die Erläuterung zu UMS.1.1 im Katalog nur „umgesetzt“ und „nicht umgesetzt“.

Wir empfehlen, dem Standard zu folgen: alle Anforderungen ohne Zielobjektkategorie ins Paket aufnehmen und ihren Status nach Kapitel 4.1.1 erheben. Existiert die zugrunde liegende Komponente nicht im Informationsverbund oder lässt sich die Anforderung funktional nicht erfüllen, wird sie mit Begründung als „nicht anwendbar“ geführt; sonst ist sie „erfüllt“ oder „nicht erfüllt“. Eine bloß fehlende Relevanz ist keiner dieser Fälle. So steht die Begründung dort, wo ein Audit sie sucht, und das Paket bleibt mit dem Katalog vergleichbar, wenn das BSI ihn angleicht.

Nach BSI-Standard 200-2 Kapitel 8.3 wird der Informationsverbund mit den Bausteinen des IT-Grundschutz-Kompendiums nachgebildet. Die Zuordnung von Bausteinen zu Zielobjekten wird in einer Tabelle mit Baustein, Relevanz, Zielobjekt, Begründung und Ansprechpartner dokumentiert (Kapitel 8.3.4). Laut BSI-Themenseite löst die Stand-der-Technik-Bibliothek das Kompendium ab, und der Anwenderkatalog beschreibt nur noch Anforderungen, die nicht auf spezifische IT-Lösungen abzielen. Produktbezogene Bausteine wie im Kompendium kennt er nicht; an ihre Stelle treten Zielobjektkategorien mit Vererbung.

Für die Arbeit heißt das: Gefragt wird nach der Funktion eines Assets im Prozess, die Suche nach dem passenden Baustein entfällt. Eine alte Modellierungstabelle bleibt trotzdem nützlich. Die Spalte „Zielobjekt“ liefert die Asset-Liste, die Spalte „Begründung“ bei nicht relevanten Bausteinen liefert Material für die Vollständigkeitsprüfung oben. Für den Abgleich alter Baustein-Anforderungen mit Grundschutz++-Anforderungen gibt es im BSI-Repository eine Zuordnungstabelle, die noch den Status Entwurf hat; was sie leistet, beschreibt die Seite zur Migration.