Grundschutz++ Strukturmodellierung: das Anforderungspaket erstellen (STM)
Grundschutz++ Strukturmodellierung erklärt: wie aus Assets und Zielobjektkategorien das Anforderungspaket entsteht und was die Praktik STM verlangt.
Die Grundschutz++ Strukturmodellierung beantwortet die Frage, welche der 1000 Anforderungen des neuen IT-Grundschutzes für Ihren Betrieb tatsächlich gelten. Die Praktik «Strukturmodellierung» (Kürzel STM) beschreibt, wie aus Ihren Geschäftsprozessen, Daten, Systemen und Räumen eine passende Liste von Anforderungen entsteht, das sogenannte Anforderungspaket.
Warum das wichtig ist
Niemand muss den ganzen Katalog abarbeiten. Ein Büro ohne eigenen Serverraum braucht keine Anforderungen für Serverräume, ein Betrieb ohne Cloud-Dienste keine für Cloud-Dienste. Die Strukturmodellierung sorgt dafür, dass nichts Wichtiges fehlt und nichts Überflüssiges dabei ist.
Wie das funktioniert
Zuerst wird festgelegt, welcher Bereich betrachtet wird. Dann werden die Dinge erfasst, die für den wichtigsten Geschäftsprozess nötig sind, etwa Kundendaten, Laptops, die Buchhaltungssoftware oder das Büro. Jedes davon wird einer Kategorie des BSI zugeordnet, und jede Kategorie bringt ihre Anforderungen mit. Wo der Katalog nichts Passendes enthält oder Gesetze und Verträge mehr verlangen, kommen eigene Anforderungen hinzu.
Was verbindlich ist
Fast alle Anforderungen dieser Praktik sind Pflicht. Sie beschreiben die einzelnen Schritte der Modellierung, die Sie nachvollziehbar durchlaufen und dokumentieren müssen.
Der erste Schritt
Wählen Sie den Geschäftsprozess, ohne den Ihr Betrieb nicht arbeiten kann, und schreiben Sie auf, welche Daten, Programme, Geräte, Dienstleister und Räume er braucht. Diese Liste ist die Grundlage für alles Weitere.
Die Praktik «Strukturmodellierung» (STM) ist die zweite ISMS-Praktik im Anwenderkatalog Grundschutz++. Sie entspricht in der Methodik dem Prozessschritt 2 «Anforderungsanalyse». Dieser Artikel erklärt die Grundschutz++ Strukturmodellierung anhand des Katalogstands vom 22. Oktober 2026 und des Leitfadens zur Methodik.
Ziel der Praktik
Laut Katalog ist es Ziel der Strukturmodellierung, ein individuelles Anforderungspaket für die Institution zu generieren. Über die Zuordnung von Praktiken und Zielobjekten werden Anforderungen ausgewählt. Die Anforderungen lassen sich über Auswahlmöglichkeiten anpassen und um spezifische Anforderungen erweitern, für die eine Risikobetrachtung erforderlich ist. Die Ergebnisse sind Eingangsdaten für die Praktiken Umsetzung und Monitoring-Evaluation.
Aufbau: fünf Gruppen, 15 Anforderungen
| Gruppe | Inhalt |
|---|---|
| STM.1 Informationsverbund | Informationsverbund abgrenzen, externe Schnittstellen festlegen |
| STM.2 Anforderungspaket | Assets erfassen, Zielobjektkategorien zuweisen, Anforderungen modellieren, vererben, konsolidieren und ergänzen |
| STM.3 Sicherheitsniveau | initiales Sicherheitsniveau bei abweichendem Kontext überprüfen |
| STM.4 Risiko | Risikobetrachtung, wo die Methodik sie verlangt |
| STM.5 Parametrisierung | Parameter in Anforderungen mit konkreten Werten belegen |
Die MUSS-Anforderungen Schritt für Schritt
14 der 15 Anforderungen sind MUSS-Anforderungen. Sie bilden zusammen den Ablauf der Modellierung.
Informationsverbund abgrenzen
STM.1.1 «Strukturmodellierung MUSS den nachvollziehbar abgegrenzten Informationsverbund auf Basis des Geltungsbereichs festlegen.»
STM.1.2 «Strukturmodellierung MUSS Schnittstellen des Informationsverbunds zu externen Prozessen festlegen.»
Zur Abgrenzung gehört nach der Erläuterung zu STM.1.1 auch die Frage, welche Anteile intern betrieben und welche an externe Parteien ausgelagert werden und welche Cloud-Dienste genutzt werden.
Anforderungspaket modellieren
STM.2.1.1 «Strukturmodellierung MUSS alle Anforderungen der ISMS-Praktiken auf den vorliegenden Informationsverbund modellieren.»
STM.2.1.2 «Strukturmodellierung MUSS alle relevanten Assets für die betrachteten Geschäftsprozesse festlegen.»
STM.2.1.3 «Strukturmodellierung MUSS allen relevanten Assets eine oder mehrere Zielobjektkategorien zuweisen.»
STM.2.1.4 «Strukturmodellierung MUSS die den Zielobjektkategorien zugehörigen Anforderungen auf die zugewiesenen Assets modellieren.»
STM.2.1.4.1 «Strukturmodellierung MUSS die in der Hierarchie übergeordneten Zielobjektkategorien ebenfalls dem jeweiligen Asset die in der Zielobjekthierarchie übergeordnet sind zuweisen.»
Die Anforderungen der ISMS-Praktiken GC, STM, UMS, PERF und VRB werden laut Erläuterung zu STM.2.1.1 ohne weitere Auswahl als verbundweite Anforderungen übernommen. Beim Erfassen der Assets genügt es im ersten Durchgang des PDCA-Zyklus, die Assets des wichtigsten Geschäftsprozesses zu berücksichtigen. Die Zuordnung zu Zielobjektkategorien erfolgt funktionsorientiert, also danach, wie ein Asset im Geschäftsprozess wirkt, und ein Asset kann mehreren Kategorien angehören.
Konsolidieren und ergänzen
STM.2.1.4.2 «Strukturmodellierung MUSS eine Konsolidierung und Redundanzprüfung des Anforderungspakets ausführen.»
STM.2.1.5 «Strukturmodellierung MUSS alle weiteren Anforderungen denen keine Zielobjektkategorie zugeordnet ist modellieren.»
STM.2.1.6 «Strukturmodellierung MUSS für Assets, für die es noch keine passenden GS++-Anforderungen gibt, zusätzliche Anforderungen dem Anforderungspaket zuweisen.»
STM.2.1.7 «Strukturmodellierung MUSS für das individuelle Compliance-Umfeld der Institution zusätzliche Anforderungen dem Anforderungspaket zuweisen.»
Anforderungen ohne Zielobjektkategorie erhalten eine Relevanzentscheidung je Geschäftsprozess. Streichen Sie eine solche Anforderung, verlangt die Methodik eine Begründung, damit sie in einem späteren Audit nachvollziehbar ist. Vor eigenen Anforderungen empfiehlt der Katalog einen Blick in die Stand-der-Technik-Bibliothek.
Risiko und Parameter
STM.4.1 «Strukturmodellierung MUSS eine Risikobetrachtung bei durch die GS++-Methodik festgeleger Notwendigkeit ausführen.»
STM.5.1 «Strukturmodellierung MUSS bei Anforderungen mit Parametern konkrete Werte zuweisen.»
Eine Risikobetrachtung ist laut Erläuterung insbesondere nötig bei hohem Schutzbedarf, bei Herabstufung des Sicherheitsniveaus von erhöht auf normal-SdT, bei Nicht-Umsetzung von Anforderungen und bei Ergänzungen des Anforderungspakets. Zu den Parametern gehören zum Beispiel Rollen: Jede technische oder organisatorische Praktik enthält in ihren Grundlagen eine Anforderung, mit der Sie die führende Zuständigkeit festlegen.
Sicherheitsniveau normal und erhöht
Die einzige SOLLTE-Anforderung der Praktik betrifft das Sicherheitsniveau:
STM.3.1 «Strukturmodellierung SOLLTE die initiale Einstufung der Sicherheitsniveaus der Anforderungen im Anforderungspaket bei Abweichungen des Kontextes der Institution überprüfen.»
Alle Anforderungen der Praktik selbst gehören zum Niveau normal (Stand der Technik). Wichtig ist STM.3.1 für das Anforderungspaket insgesamt: Nach der Methodik wirkt sich eine Erhöhung von normal auf erhöht nur auf die Reihenfolge der Umsetzung aus, eine Absenkung von erhöht auf normal ist mit einer Risikobetrachtung zu begründen. Die Erläuterung nennt die Prüfung besonders dann erforderlich, wenn Geschäftsprozesse oder Informationen einen hohen Schutzbedarf haben.
Typische Nachweise
Zehn Anforderungen nennen das Anforderungspaket als Dokumentation, zwei den Informationsverbund. Für die Risikobetrachtung, die Überprüfung des Sicherheitsniveaus und die Parametrisierung nennt der Katalog keine eigene Dokumentation. In der Praxis gehören dazu eine Assetliste mit Zuordnung zu Geschäftsprozessen und Verantwortlichen, die Zuordnung zu Zielobjektkategorien mit kurzer Begründung bei manueller Zuordnung und die Begründungen für gestrichene Anforderungen.
Zielobjektkategorien
Die Anforderungen dieser Praktik haben selbst keine Zielobjektkategorie. Sie arbeiten aber mit den 39 Kategorien der Stand-der-Technik-Bibliothek. Diese hängen in einer festen Hierarchie unter sieben Wurzeln: Anwendungen, Einkäufe, Informationen, IT-Systeme, Netze, Nutzende und Standorte. Ein Beispiel für die Vererbung: Ein Asset in der Kategorie Serverräume erhält auch die Anforderungen für Räume für technische Infrastruktur, Räume und Standorte.
Unterschied zur bisherigen Modellierung
Im Kompendium Edition 2023 werden Bausteine auf Zielobjekte modelliert, getrennt nach Prozess- und System-Bausteinen. In Grundschutz++ entfällt der Baustein als Zwischenschicht. Sie ordnen Assets Kategorien zu, die Anforderungen ergeben sich aus Kategorie und Vererbung. Bisherige Ergebnisse der Strukturanalyse bleiben dabei als Assetliste nutzbar.
Umsetzungstipps für kleine und mittlere Unternehmen
- Klein anfangen: Ein Geschäftsprozess, etwa Auftragsabwicklung, reicht für den ersten Durchlauf. Weitere Prozesse folgen in späteren Zyklen.
- Tabelle statt Werkzeug: Asset, Beschreibung, Geschäftsprozess, Verantwortlicher, Standort, Abhängigkeiten und Zielobjektkategorie lassen sich zunächst in einer Tabelle führen. Langfristig empfiehlt die Methodik eine toolgestützte Umsetzung.
- Nachnutzen: Die Methodik hält es ausdrücklich für sinnvoll, bereits erfasste Assets in weiteren Geschäftsprozessen und Informationsverbünden wiederzuverwenden.
- Den Katalog filtern: Da der Katalog maschinenlesbar ist, lassen sich die Anforderungen je Kategorie mit einfachen Mitteln oder einem ISMS-Werkzeug herausfiltern.
- Begründungen sofort notieren: Wer eine Anforderung als nicht relevant streicht, schreibt den Grund gleich dazu.
Häufige Fragen
Was ist ein Anforderungspaket?
Die Liste aller Anforderungen, die für Ihren Informationsverbund und die betrachteten Geschäftsprozesse gelten. Es besteht aus den ISMS-Anforderungen, den Anforderungen der zugeordneten Zielobjektkategorien, relevanten Anforderungen ohne Kategorie und eigenen Ergänzungen.
Muss ich gleich alle Assets erfassen?
Nein. Laut Methodik und Katalog genügt im ersten Durchgang des PDCA-Zyklus die Erfassung der Assets für den wichtigsten Geschäftsprozess. Weitere Prozesse werden in den folgenden Zyklen oder parallel ergänzt.
Was passiert, wenn es für ein Asset keine passenden Anforderungen gibt?
Dann müssen Sie nach STM.2.1.6 zusätzliche Anforderungen in das Anforderungspaket aufnehmen. Die Methodik verlangt eine Begründung, warum der Katalog nicht ausreicht, und eine Betrachtung der Risiken.
Darf ich das Sicherheitsniveau einer Anforderung absenken?
Ja, aber nur mit Begründung durch eine Risikobetrachtung. Eine Erhöhung von normal auf erhöht beeinflusst nach der Methodik dagegen nur die Reihenfolge der Umsetzung.