Grundschutz++ Beispiel, Teil 2: Anforderungsanalyse für das Bürgerportal

Der IZM hat innerhalb des Anwendungsbereichs einen Informationsverbund gebildet, IV-PORTAL. Er umfasst die Portalplattform, die Teams, die sie betreiben und pflegen, den Serverraum RZ-1 und das Technikgebäude. Im ersten Zyklus enthält er die Assets, die GP-A braucht. Das deckt sich mit der Erläuterung zur Katalog-Anforderung STM.2.1.2: Im ersten Durchgang genügt es, die Assets des wichtigsten Geschäftsprozesses zu erfassen; weitere Prozesse kommen in späteren Zyklen dazu.

Kapitel 3.1 verlangt, die Schnittstellen zu externen Prozessen, Systemen und anderen Verbünden organisatorisch, technisch und infrastrukturell zu dokumentieren; im Katalog steht dafür STM.1.2. Die Tabelle zeigt die sechs Schnittstellen der Akte. Die allgemeine Abgrenzung erklärt die Seite Informationsverbund abgrenzen.

Die 24 Assets stammen aus der CMDB des IT-Betriebs, aus dem Vertragsverzeichnis und aus Gesprächen mit dem Portalbetrieb. Personen sind als Gruppen erfasst, gleichartige Server als VM-Gruppe; 300-1 erlaubt die Gruppierung, wenn Eigenschaften und Einsatzzweck ähnlich sind (Kap. 3.2). Jedes Asset hat eine verantwortliche Rolle in der Inventarliste, die hier aus Platzgründen fehlt.

Die Spalte „je Asset“ zählt alle Anforderungen, die über die zugeordneten und die vererbten Kategorien auf das Asset fallen. Die Spalte „neu“ zählt, wie viele davon in der Reihenfolge der Tabelle erstmals ins Paket kommen. Gerechnet ist mit dem Build vom 29.10.2026 und derselben Zählweise wie auf der Seite zur Modellierung: Eine Anforderung mit zwei Kategorien zählt für ein Asset, sobald eine davon zugeordnet ist.

Weil GP-A hohen Schutzbedarf hat, dokumentiert der IZM die Zugehörigkeit der Assets zum Prozess und ihre Abhängigkeiten (Kap. 3.2). Die Form ist frei; der IZM hat sieben Ressourcenpfade gebildet, weil die Risikobetrachtung nach Kapitel 3.2 entlang des Ressourcenpfads läuft. Zwei Befunde aus dieser Arbeit gehen direkt in Teil 3.

Nach der Zuordnung waren zehn der 39 Zielobjektkategorien weder direkt noch über Vererbung belegt. Der IZM hat für jede eine Begründung festgehalten. Eine leere Kategorie ist erlaubt, wenn sie im Verbund für GP-A tatsächlich nicht vorkommt. Die Begründung muss dann einer Prüfung standhalten, denn an ihr hängen die Anforderungen, die nicht ins Paket kommen: im Build vom 29.10.2026 sind das 72.

Der Formularbaukasten AS-02 erlaubt den Redaktionen, Prüf- und Berechnungslogik in einer Skriptsprache zu hinterlegen, die im Portal bei jedem Antrag ausgeführt wird. Der ISB fand in den Anforderungen der Kategorien Webanwendungen, Webserver und Anwendungen nichts, was die Freigabe solcher Logik vor ihrer Veröffentlichung regelt. Der IZM hat AS-02 deshalb als nicht hinreichend abgedeckt eingestuft. Daraus folgen zwei Pflichten: eine explizite Risikobetrachtung (300-1 Kap. 2.11; Anhang 3, Kriterium 33) und eine ergänzende eigene Anforderung (Kap. 3.4.3; im Katalog STM.2.1.6). Die Erläuterung zu STM.2.1.6 beschreibt die Schritte: Asset benennen, begründen, warum die Katalog-Anforderungen nicht ausreichen, eigene Anforderung formulieren, Paket erweitern.

Eine zweite eigene Anforderung kommt aus der Compliance-Liste. Die Leistungsvereinbarungen CP-01 verlangen, dass übergebene Anträge verschlüsselt und signiert ankommen. Vor einer eigenen Anforderung empfiehlt die Erläuterung zu STM.2.1.7 einen Blick in die Stand-der-Technik-Bibliothek. Der IZM fand für die Verschlüsselung KONF.14.1 („Konfiguration für Anwendungen SOLLTE Kommunikation beim Transport über Netze nach [einem anerkannten Standard] verschlüsseln“), die über die Kategorie Anwendungen schon im Paket ist. Eine Anforderung zur Signatur übergebener Daten fand er im Build nicht. Nur dafür entstand EIG-02.

Blaupausen sind vorgefertigte Kataloge von Anforderungen für bestimmte Anwendungsszenarien, in denen auch die Parameter vorgegeben sind (Kap. 3.3). Der IZM hat für IV-PORTAL keine Blaupause verwendet und das mit Datum und Begründung festgehalten: Für den Zuschnitt des Portalbetriebs lag ihm keine passende vor. Weil Kapitel 3.3 verlangt, die Auswahl bei Änderungen des Verbunds oder der verfügbaren Blaupausen zu prüfen, steht die Frage auf der Liste für jede Validierung in Teil 4.

Ohne Blaupause legt der IZM die Parameter selbst fest, soweit der Katalog keine Werte vorgibt (Kap. 3.5; im Katalog STM.5.1, MUSS). Von den 928 Anforderungen im Paket enthalten 200 mindestens einen Parameter. Bei 199 legt der IZM mindestens einen Wert selbst fest; nur bei GC.1.1 gibt der Katalog den Wert vollständig vor, bei NOT.1.1.4 einen von zwei Parametern (eigene Zählung). Die Tabelle zeigt sechs Festlegungen, die in den folgenden Teilen eine Rolle spielen.

Zu den 564 Anforderungen aus der Modellierung kommen die 364 Anforderungen ohne Zielobjektkategorie, die nach Kapitel 3.4.1 immer ins Paket gehören: 95 Methodik-Anforderungen, 265 technische und organisatorische Anforderungen und 4 Anforderungen der Praktik Risikomanagement. Das Paket umfasst 928 der 1.000 Anforderungen des Builds, dazu die beiden eigenen Anforderungen.

In Teil 3 erhebt der IZM für alle 930 Einträge den Umsetzungsstatus, ordnet nicht erfüllte Anforderungen nach Modalverb ein, führt die Risikobetrachtung für GP-A und AS-02 durch und stellt den Umsetzungsplan auf.