Was 300-1 unter Blaupause und Parameter versteht
Kapitel 3.3 definiert: „Eine Blaupause ist ein vorgefertigter Katalog von Anforderungen.“ Anders als der Anwenderkatalog ist sie auf bestimmte Anwendungsszenarien zugeschnitten und trifft eine Vorauswahl von Anforderungen; zusätzlich gibt sie die Parameter vor. Für die Arbeit mit Blaupausen legt der Standard vier Regeln fest:
- Zuordnung zu einzelnen Assets oder Asset-Gruppen ist möglich; zu dokumentieren sind laut Kap. 3.3 „Die Auswahl (inkl. Version), Zuordnung und gegebenenfalls vorgenommene Anpassung der Blaupausen“.
- Deckt eine Blaupause den Sachverhalt nicht vollständig ab, ergänzen Sie sie durch weitere Blaupausen oder eigene Anforderungen.
- Ändert sich der Informationsverbund oder das Angebot an Blaupausen, prüfen Sie die Auswahl erneut.
- Für bestimmte Institutionen kann es verpflichtende Blaupausen geben; sonst ist eine individuelle Auswahl zu prüfen. Aus mehreren Blaupausen erstellt die Institution ihr eigenes Anforderungspaket.
Parameter erklärt Kapitel 3.5 als „variabel gestaltbare Elemente innerhalb einer Anforderung“, die Auditoren und Anwendern Spielräume aufzeigen und für automatisierte Prüfungen genutzt werden können. Sie werden bei oder nach der Erstellung des Anforderungspakets konkretisiert. Kapitel 3.4 regelt den Vorrang: Die Institution legt die Parameter fest, „sofern keine festgeschriebenen Parameter (z. B. durch eine Blaupause) vorliegen“. Im Anwenderkatalog steht dazu die Methodik-Anforderung STM.5.1 „Setzen von Parametern“: Die Strukturmodellierung MUSS bei Anforderungen mit Parametern konkrete Werte zuweisen.
Was am 1. November 2026 veröffentlicht ist
Wir haben die Stand-der-Technik-Bibliothek des BSI im Stand von Commit c3f37859 (30.10.2026) durchgesehen. Das Wort „Blaupause“ steht dort nur in der Beschreibung der Praktik Strukturmodellierung (STM): „Blaupausen unterstützen die Filterung der Anforderungen.“ Keine Datei ist als Blaupause bezeichnet, keine als verpflichtend. Die Tabelle zeigt die Kandidaten und ihren Status nach den Angaben der Dateien selbst und unserer Auszählung.
| Artefakt im Repository | Herausgeber und Stand laut Metadaten | Inhalt (eigene Auszählung) | Parameter | Status als Blaupause |
|---|---|---|---|---|
Anwenderkatalog Grundschutz++ (control_layer/Grundschutz++/) | BSI; Version und Build 29.10.2026 | 1.000 Anforderungen in 20 Praktiken | 224 Parameter in 211 Anforderungen; im Profil festgeschrieben sind zwei Werte: GC.1.1 „BSI Grundschutz++“ und ein Parameter von NOT.1.1.4 „BSI-Standard 200-4“ | Keine Blaupause: 300-1 grenzt Blaupausen ausdrücklich vom Anwenderkatalog ab |
„Stand der Technik WLAN“ (control_layer/WLAN/) | BSI, Referat Stand der Technik; Version 29.10.2026 | 48 Anforderungen in sechs Gruppen von „Planung und Bestand“ bis „Betriebsumgebung und Sensibilisierung“; 37 mit Sicherheitsniveau normal-SdT, 11 erhöht; alle 48 Kennungen stehen auch im Anwenderkatalog | Drei Werte gesetzt: ARCH.2.6 „kontinuierlich“, ARCH.3.4 „WPA3“, DET.4.19 „Wireless Intrusion Detection System (WIDS)“; Umsetzungshinweise (guidance) aller 48 Anforderungen ersetzt | Erfüllt die Merkmale aus Kap. 3.3 (Szenario, Vorauswahl, vorgegebene Parameter); als Blaupause bezeichnet ist er nicht |
„Supply Chain Security“ (control_layer/Lieferkettensicherheit/) | BSI, Referat Stand der Technik; Version 29.10.2026; Beschreibung „Anforderungskatalog Lieferkettensicherheit“ | 146 Anforderungen aus ASST, BES, DLS, GEB, NOT, KONF und DEV; 105 normal-SdT, 41 erhöht; alle Kennungen im Anwenderkatalog | Keine Werte gesetzt; 24 Anforderungen mit offenen Parametern | Thematische Vorauswahl ohne vorgegebene Parameter; erfüllt das Merkmal „Parameter vorgegeben“ aus Kap. 3.3 damit nicht |
„BSI Anforderungen zum Risikomanagement“ (control_layer/Risikomanagement/) | BSI, Referat Stand der Technik; Version 22.10.2026 | 10 Anforderungen der Praktik RISK, alle normal-SdT; sechs Kennungen (RISK.1.2, RISK.1.4, RISK.1.6 bis RISK.1.9) stehen nicht im Anwenderkatalog vom 29.10.2026 | ein offener Parameter (RISK.1.1), keine Werte gesetzt | Keine Blaupause: thematischer Katalog ohne Anwendungsszenario und ohne vorgegebene Parameter; das Profil des Anwenderkatalogs übernimmt daraus nur RISK.1.1, RISK.1.3, RISK.1.5 und RISK.1.10 |
Entwurf Mindeststandard TLS (control_layer/Mindeststandard-TLS/) | laut Dateiname Entwurf | nicht ausgewertet | nicht ausgewertet | Entwurf, nicht für das Anforderungspaket |
Komponentendefinitionen (implementation_layer/, etwa Passwortrichtlinie, Netzarchitektur, Keycloak) | BSI | Beschreibungen, wie eine Implementierung Anforderungen umsetzen kann | nicht ausgewertet | Keine Blaupause: Das README nennt sie Referenzen, die „nicht das Handeln der für die Informationssicherheit verantwortlichen Stelle“ ersetzen |
Methodik-Katalog (control_layer/Grundschutz++/sources/catalogs/), Kernel (control_layer/Kernel/) und Risikomanagement-Katalog (control_layer/Risikomanagement/) sind die Quellkataloge, aus denen das Profil den Anwenderkatalog zusammensetzt.
Die Folgerung für Ihr Paket: Eine Blaupause im Sinne von 300-1 mit Verbindlichkeit gibt es im ausgewerteten Stand nicht, und welche Institutionen künftig verpflichtende Blaupausen anwenden müssen, sagen die hier ausgewerteten Quellen nicht. Den WLAN-Katalog können Sie als Vorlage für WLAN-Assets nutzen. Dann dokumentieren Sie ihn wie eine Blaupause, mit Version, Zuordnung und Anpassungen, und halten fest, dass das BSI ihn nicht als Blaupause bezeichnet. Wie sich das Repository insgesamt gliedert, zeigt Anwenderkatalog Grundschutz++.
Prüfliste: Herkunft und Status eines Katalogs vor der Verwendung
Bevor ein Katalog als Blaupause in Ihr Paket geht, beantworten Sie diese Fragen schriftlich. Die Antworten gehören in die Dokumentation, die Kapitel 3.3 verlangt.
| Prüffrage | Wo Sie nachsehen | Beispiel WLAN (Commit c3f37859) |
|---|---|---|
| Wer gibt den Katalog heraus? | Metadaten parties und responsible-parties | BSI, Referat Stand der Technik |
| Welche Version, welcher Stand? | Metadaten version und last-modified, dazu der Commit | Version 2026-10-29T08:05:59, Commit c3f37859 |
| Ist er als Entwurf oder als verpflichtend gekennzeichnet? | Dateiname, Metadaten, Begleittexte | keine Kennzeichnung |
| Wofür gilt er, wofür nicht? | Metadaten remarks | professionell betriebene WLAN-Infrastrukturen; private Heimnetze und öffentliche Mobilfunknetze ausgeschlossen |
| Aus welchen Quellen werden Anforderungen übernommen? | Profil: imports und back-matter | 48 Anforderungen aus der Kernel-Datei des Repositorys; als Referenz zusätzlich eine Kernel-Fassung vom 13.08.2026 und Normen wie IEEE 802.11-2024 genannt |
| Welche Parameter sind festgeschrieben? | Profil: modify.set-parameters | drei (ARCH.2.6, ARCH.3.4, DET.4.19) |
| Was wurde am Anforderungstext geändert? | Profil: modify.alters | Anforderungstexte unverändert; Umsetzungshinweise aller 48 Anforderungen ersetzt |
| Passen die Kennungen zum Anwenderkatalog, den Sie verwenden? | Abgleich der Kennungen gegen den Build Ihres Pakets | alle 48 im Build vom 29.10.2026 enthalten |
| Unter welcher Lizenz? | Repository | CC BY-SA 4.0 |
Fällt eine Antwort unklar aus, verwenden Sie den Katalog nur als Arbeitshilfe und legen die Parameter selbst fest. Dann gilt für sie dasselbe wie für jeden anderen eigenen Wert: begründen und protokollieren.
Welche Parameter der Anwenderkatalog enthält
Im Build vom 29. Oktober 2026 haben 211 der 1.000 Anforderungen zusammen 224 Parameter (eigene Auszählung über alle Ebenen). Jeder Parameter hat eine Bezeichnung, die im Anforderungstext an seiner Stelle steht. Werte enthält der Katalog nur bei den zwei oben genannten Parametern; alle übrigen legen Sie fest.
Am häufigsten ist „regelmäßig“ mit 68 Vorkommen; sieben weitere Bezeichnungen enthalten das Wort, je einmal, etwa „regelmäßige“, „regelmäßig oder bei Änderungen“ und „regelmäßig oder prädiktiv“. Es folgen „zuständigen Personen oder Rollen“ (16), „eine zuständige Person oder Rolle“ (13), „einem anerkannten Standard“ (13), „Schwellwerten“ (13), „Kriterien“ (12) und „einen automatisierten Mechanismus“ (12). Daraus ergeben sich vier Arten von Festlegungen: Turnus, Zuständigkeit, Bezugsstandard und Schwelle oder Kriterium. Jede Art braucht eine andere Begründung. Ein Turnus richtet sich nach Änderungshäufigkeit und Schutzbedarf, eine Zuständigkeit nach Ihrer Sicherheitsorganisation, ein Bezugsstandard nach einer zitierbaren Quelle mit Version.
Parameter sind auch Prüfmaßstab. 300-1 sagt, sie zeigen Auditoren Spielräume auf (Kap. 3.5). Ein Auditor prüft also, ob Sie den festgelegten Wert einhalten, und kann fragen, warum Sie ihn so gewählt haben. Ein Wert ohne Begründung lässt sich in dieser Situation schwer verteidigen.
Parametrierungsprotokoll mit Beispielzeilen
Das Protokoll ist eine Tabelle mit einer Zeile je Parameter im Paket. Kennzeichnung: Anforderung, Parameter-Kennung, Bezeichnung und die Werte aus Anwenderkatalog und WLAN-Katalog stammen aus der Stand-der-Technik-Bibliothek (Commit c3f37859). Alle Werte in der Spalte „Festgelegt“ ohne Herkunft „Katalog“ oder „WLAN-Katalog“ sind eigene, fiktive Beispiele und keine Empfehlung des BSI.
| Anforderung (Auszug) | Parameter: Bezeichnung im Katalog | Festgelegt | Herkunft | Begründung | Entschieden von, am | Nächste Prüfung |
|---|---|---|---|---|---|---|
| GC.1.1 Verfahren zur Errichtung eines ISMS nach [Parameter] verankern (MUSS) | gc.1.1-prm1: „BSI Grundschutz++“ | BSI Grundschutz++ | Katalog (Profil) | vom Profil festgeschrieben | übernommen, ISB, 15.12.2026 | bei neuem Build |
| NOT.1.1.4 BCMS nach [Parameter] verankern (KANN, erhöht) | not.1.1.4-prm2: „BSI-Standard 200-4“ | BSI-Standard 200-4 | Katalog (Profil) | vom Profil festgeschrieben; Anforderung optional | übernommen, ISB, 15.12.2026 | bei neuem Build |
| UMS.1.1 Umsetzungsstatus vollständig [Parameter] überprüfen (MUSS) | ums.1.1-prm1: „regelmäßig“ | vierteljährlich | eigenes Beispiel | passt zum Berichtsrhythmus an die Leitung | Institutionsleitung, 15.12.2026 | Managementbewertung |
| PERF.4.2 Institutionsleitung [Parameter] anhand des Managementberichts informieren (MUSS) | perf.4.2-prm1: „regelmäßig“ | halbjährlich, zusätzlich anlassbezogen | eigenes Beispiel | zwei Sitzungstermine der Leitung im Jahr | Institutionsleitung, 15.12.2026 | Managementbewertung |
| GC.9.1.1.1 Zuständigkeit für Informationssicherheit [Parameter], unmittelbar der Institutionsleitung unterstellt, zuweisen (MUSS) | gc.9.1.1.1-prm1: „einer unabhängigen Person“ | Stelle ISB in der Stabsstelle der Geschäftsführung, ohne Linienverantwortung für den IT-Betrieb | eigenes Beispiel | Vermeidung des Konflikts IT-Leitung und ISB (300-1, Kap. 2.8) | Institutionsleitung, 15.12.2026 | bei Organisationsänderung |
| UMS.5.1 Ausnahmegenehmigungen durch [Parameter] autorisieren (MUSS) | ums.5.1-prm1: „eine zuständige Person oder Rolle“ | Institutionsleitung | eigenes Beispiel | gleiche Stelle wie für Ausnahmen nach Anhang 3, Kriterium 27 | Institutionsleitung, 15.12.2026 | jährlich |
| GC.10.1.2 Beteiligung [Parameter] bei sicherheitsrelevanten Projekten verankern (MUSS) | gc.10.1.2-prm1: „der relevanten Sicherheitsorgane“ | ISB bei Projektstart und vor Inbetriebnahme; DSB bei Verarbeitung personenbezogener Daten | eigenes Beispiel | 300-1, Kap. 2.8: festlegen, wann der ISB beteiligt wird | ISB, 15.12.2026 | jährlich |
| NOT.4.16.1 Wiederherstellung anhand repräsentativer Stichproben [Parameter] überprüfen (SOLLTE) | not.4.16.1-prm1: „regelmäßig“ | halbjährlich je Datenbestand mit Schutzbedarf hoch, jährlich sonst | eigenes Beispiel | Abstufung nach Schutzbedarf der Geschäftsprozesse | IT-Betrieb mit ISB, 15.12.2026 | nach jedem Test |
| ARCH.3.4 Netzanbindung [Parameter] verschlüsseln (SOLLTE, WLANs) | arch.3.4-prm1: „nach einem anerkannten Standard“ | WPA3 | WLAN-Katalog, Version 2026-10-29 | WLAN-Katalog für alle WLAN-Assets übernommen | ISB, 15.12.2026 | bei neuer Version des WLAN-Katalogs |
| ARCH.2.6 Einhaltung der Netzarchitektur [Parameter] überprüfen (SOLLTE, Netze) | arch.2.6-prm1: „regelmäßig“ | kontinuierlich für WLAN-Netze; monatlich für die übrigen Netze | WLAN-Katalog für WLAN-Netze; eigenes Beispiel für die übrigen | zwei Werte für zwei Asset-Gruppen, Zuordnung im Paket vermerkt | ISB, 15.12.2026 | bei neuer Version des WLAN-Katalogs |
Drei Hinweise zum Ausfüllen. Erstens: Gilt eine Anforderung für mehrere Asset-Gruppen mit unterschiedlichen Werten wie bei ARCH.2.6, schreiben Sie je Gruppe eine Zeile oder vermerken die Zuordnung ausdrücklich. Zweitens: „Entschieden von“ ist keine Formalie. Werte, die Ressourcen binden oder Zuständigkeiten festlegen, gehören nach 300-1, Kap. 2.10 und 4.4, vor die Institutionsleitung. Drittens: Verweist ein Parameter auf einen Standard, nennen Sie Titel und Fassung, damit eine spätere Prüfung den Wert nachvollziehen kann.
Blaupausen und Parameter im Betrieb pflegen
Beide Festlegungen veralten. 300-1 verlangt, die Auswahl der Blaupausen bei Änderungen des Informationsverbunds oder der verfügbaren Blaupausen zu überprüfen (Kap. 3.3), und nennt Anpassungen an verwendeten Blaupausen und an den Anforderungen der Stand-der-Technik-Bibliothek als Gegenstand der regelmäßigen Validierung (Kap. 5.5). Die Methodik-Anforderung PERF.1.3 verlangt, die Aktualität der Anforderungen mit dem Parameter „regelmäßig“ zu überprüfen; auch diesen Wert legen Sie selbst fest.
Praktisch heißt das: Notieren Sie im Protokoll zu jedem übernommenen Katalog den Commit. Erscheint ein neuer Build, vergleichen Sie die gesetzten Werte und die Kennungen und vermerken das Ergebnis, auch wenn sich nichts ändert. Wie Validierung und Neubewertung in den Jahreslauf passen, zeigt die Seite Grundschutz im Betrieb.
Wie aus Assets und Zielobjektkategorien überhaupt ein Paket entsteht, beschreibt die Seite Modellierung und Zielobjektkategorien; das durchgerechnete Beispiel dort zeigt die Vererbung, diese Seite die Konkretisierung danach.
Weiter: Grundschutz im Betrieb · Modellierung und Zielobjektkategorien · Fallbeispiel: Anforderungsanalyse. Blaupausenwahl und Parametrierung sind Teil der Umsetzung, bei der Blackfort Technology unterstützt, siehe Umsetzung und Migration.