| name | bsi-grundschutz-baustein |
| description | Erstellt und überarbeitet IT-Grundschutz-Bausteine im Format des BSI-IT-Grundschutz-Kompendiums (Edition 2023) sowie für IT-Grundschutz++. Nutze diesen Skill IMMER, wenn ein neuer Baustein, eine Gefährdungslage, Basis-/Standard-Anforderungen oder Anforderungen bei erhöhtem Schutzbedarf, eine Kreuzreferenztabelle, eine Bausteinüberarbeitung für eine neue Edition oder die korrekte BSI-Verbindlichkeitssprache (MUSS/SOLLTE/DARF NICHT) gefragt ist — auch wenn der Begriff "Baustein" nicht ausdrücklich fällt, etwa bei "Grundschutz-Anforderungen formulieren", "Modul fürs Kompendium", "Schicht APP/SYS/NET", "elementare Gefährdungen zuordnen" oder "Sicherheitsanforderungen nach BSI-Systematik". Deckt Struktur, Schicht-/ID-Systematik, Verbindlichkeits-Modalverben, Rollenkatalog, Zuständigkeitsmodell, Schutzziel-Kennzeichnung, Kreuzreferenztabelle und Qualitätssicherung ab. |
IT-Grundschutz-Baustein erstellen
Version 2.0 — Änderungen ggü. 1.0 am Dateiende.
Dieser Skill erzeugt Bausteine, die exakt der Redaktionssystematik des BSI-IT-Grundschutz-Kompendiums (Edition 2023) folgen, damit sie ohne Nacharbeit in das Kompendium, ein Grundschutz-Profil oder ein IT-Grundschutz++-Repository übernommen werden können.
Zielformat und Pipeline
Primärer Output ist Markdown (die übliche Bearbeitungsstufe vor der DOCX-Konvertierung). Für eine formatierte Word-Fassung danach den docx-Skill nutzen (Fließtext in Aptos, sonst Calibri). Tabellen als Markdown-Tabellen; die Kreuzreferenztabelle ggf. zusätzlich als separate Datei, falls sie sehr breit wird.
Vor dem Schreiben klären, sofern nicht aus dem Kontext ableitbar: Schicht und ID des Bausteins, abgegrenztes Zielobjekt und ob es ein neuer Baustein oder eine Editionsüberarbeitung ist. Wenn der Nutzer das Thema klar benennt, nicht mit Rückfragen aufhalten — eine begründete Annahme treffen und inline kenntlich machen.
Markdown-Form: Überschriftenebenen (verbindlich)
Damit der Baustein in der DOCX-/OSCAL-Pipeline sauber navigierbar ist, gilt eine feste Ebenenzuordnung:
| Ebene | Inhalt |
|---|
# (H1) | <ID> <Name des Bausteins> |
## (H2) | Kapitel 1 Beschreibung, 2 Gefährdungslage, 3 Anforderungen, 4 Weiterführende Informationen |
### (H3) | Unterkapitel (1.1, 1.2, 1.3, 3.1, 3.2, 3.3, 4.1), jede Gefährdung (Titel) und jede Anforderung |
Jede Anforderung ist eine eigene, nicht nummerierte H3-Überschrift — kein Fettdruck-Absatz, keine Aufzählungs-/Listennummerierung (1., -). Die Anforderungs-ID (.A<Nr>) steht in der Überschrift, ist aber Teil der ID, keine Listennummer:
### APP.4.10.A1 Richtlinie für den sicheren Einsatz von KI (B) [Fachverantwortliche]
Es MUSS eine Richtlinie existieren, die …
Die Klassenabschnitte 3.1/3.2/3.3 sind ebenfalls H3; die Anforderungen folgen als H3-Geschwister unmittelbar darunter.
Vorgehen: erst recherchieren, dann strukturieren
Schritt 1 — Recherche (verpflichtend, vor dem Schreiben). Zuerst recherchieren, wie das Zielobjekt nach aktuellem Stand der Technik abzusichern ist — nicht aus dem Gedächtnis formulieren. Quellen: Hersteller-Härtungsleitfäden und Security-Baselines, CIS Benchmarks, einschlägige BSI-Dokumente und benachbarte Kompendium-Bausteine, NIST-/ISO-Vorgaben, bekannte Schwachstellen- und Angriffsmuster (CVE/MITRE ATT&CK, bei KI zusätzlich MITRE ATLAS, OWASP-Listen). Websuche nutzen und aktuelle Versionen prüfen. Ergebnis ist eine ungeordnete Sammlung sinnvoller Schutzmaßnahmen samt Quellen — die Rohbasis für Gefährdungslage und Anforderungen. Quellen für 4.1 Wissenswertes festhalten.
Schritt 2 — Gefährdungslage ableiten. Aus den recherchierten Bedrohungen die spezifische Gefährdungslage (Kapitel 2) formulieren und die einschlägigen elementaren Gefährdungen (G 0.x) identifizieren — Nummer und Titel verbatim aus references/elementare-gefaehrdungen übernehmen.
Schritt 3 — Anforderungen klassifizieren und sortieren. Jede recherchierte Schutzmaßnahme in eine prüfbare Anforderung überführen und einer Klasse zuordnen — Basis (B) = unverzichtbares Fundament, Standard (S) = Stand der Technik bei normalem Schutzbedarf, Erhöht (H) = zusätzliche Beispielmaßnahmen bei erhöhtem Schutzbedarf. Einsortierung in der Reihenfolge 3.1 → 3.2 → 3.3.
Schritt 4 — Reihenfolge innerhalb jeder Klasse. In jeder Stufe (B, S, H) stehen Planungs-Anforderungen am Anfang, danach entlang des Lebenszyklus: Planung & Konzeption → Beschaffung → Umsetzung/Konfiguration → Betrieb → Notfallvorsorge/Aussonderung.
Pflichtstruktur eines Bausteins
Diese Reihenfolge ist verbindlich und vollständig zu liefern:
[ID] [Name des Bausteins]
1 Beschreibung
1.1 Einleitung
1.2 Zielsetzung
1.3 Abgrenzung und Modellierung
2 Gefährdungslage
3 Anforderungen
(Einleitung mit Zuständigkeiten)
3.1 Basis-Anforderungen
3.2 Standard-Anforderungen
3.3 Anforderungen bei erhöhtem Schutzbedarf
4 Weiterführende Informationen
4.1 Wissenswertes
Kreuzreferenztabelle zu elementaren Gefährdungen
Befüllbare Vorlage: references/baustein-vorlage — als Gerüst verwenden.
1 Beschreibung
- 1.1 Einleitung: Zielobjekt, Funktion/Technologie, Sicherheitsrelevanz. Sachlich, herstellerneutral, keine Werbung.
- 1.2 Zielsetzung: Welches Sicherheitsziel der Baustein verfolgt (Aspekte von Vertraulichkeit, Integrität, Verfügbarkeit für dieses Zielobjekt).
- 1.3 Abgrenzung und Modellierung: Worauf der Baustein anzuwenden ist, was nicht behandelt wird und auf welche anderen Bausteine verwiesen wird. Querverweise mit korrekter ID UND korrektem Titel angeben und gegen die Schicht-/ID-Referenz prüfen (
references/schichten-und-ids) — z. B. „sichere Softwareentwicklung → CON.8", nicht CON.1. Falsche Querverweise sind ein häufiger und peinlicher Auditbefund.
2 Gefährdungslage
Spezifische Gefährdungen für genau dieses Zielobjekt — keine generischen Aussagen, keine Maßnahmen (nur Bedrohung, nicht Abhilfe). Jede Gefährdung als kurzer, konkreter Absatz mit eigener H3-Überschrift. Typisch 5–12 Gefährdungen. Jede muss sich später mindestens einer elementaren Gefährdung (G 0.x) zuordnen lassen und in eine Anforderung münden (Traceability in beide Richtungen, siehe Kreuzreferenztabelle).
3 Anforderungen
Einleitungsabsatz nennt die grundsätzlich zuständige Rolle und listet die Zuständigkeiten in einer kleinen Tabelle:
| Zuständigkeiten | Rollen |
| Grundsätzlich zuständig | <eine Rolle aus dem Rollenkatalog> |
| Weitere Zuständigkeiten | <weitere Rollen aus dem Rollenkatalog> |
Rollen ausschließlich aus dem normierten Rollenkatalog (references/rollenkatalog). Keine Rollen frei erfinden, keine eigenen Bezeichnungen bilden — das bricht die Mapping-Logik im Grundschutz-Check. Genau eine Rolle ist grundsätzlich zuständig. Weicht eine einzelne Anforderung davon ab, wird die abweichende Rolle direkt in der Anforderungs-Überschrift in eckigen Klammern genannt, z. B. … (B) [Entwickler].
Anforderungsklassen (Modalverb-Logik und Stil in references/modalverben-und-stil):
- 3.1 Basis-Anforderungen (B) — vorrangig zu erfüllen; überwiegend MUSS / MÜSSEN und, wo ein Verbot die natürliche Form ist, DARF NICHT. Das volle Verbindlichkeitsspektrum nutzen, nicht nur MUSS.
- 3.2 Standard-Anforderungen (S) — Stand der Technik bei normalem Schutzbedarf; überwiegend SOLLTE / SOLLTE NICHT. Eine S-Anforderung enthält keinen MUSS-Kern — die Klasse bestimmt das Leitverb.
- 3.3 Anforderungen bei erhöhtem Schutzbedarf (H) — Beispielcharakter, durch gleichwertige Maßnahmen ersetzbar; überwiegend SOLLTE. Pflicht: Am Ende jeder H-Anforderung den Schutzziel-Bezug in Klammern ausweisen —
(C), (I), (A) bzw. die zutreffende Kombination (C = Vertraulichkeit, I = Integrität, A = Verfügbarkeit). Diese Kennzeichnung ist verbindlich (Hausregel/++-Attribut für Maschinenlesbarkeit). Hinweis: Die Basis-Edition transportiert den Schutzziel-Bezug primär über die Kreuzreferenztabelle; bei strenger Basis-Kompendium-Einreichung die Platzierung gegen die Zieledition prüfen.
4 Weiterführende Informationen
- 4.1 Wissenswertes: Verweise auf einschlägige Normen, BSI-Dokumente (Standards 200-x, andere Bausteine, themenspezifische Leitfäden) und Gremien-/Hersteller-Literatur. Belastbare Quellen, keine Pflicht zur Vollständigkeit. Verwendete Quellen müssen zum gewählten Geltungsbereich passen (z. B. OWASP ML Security Top 10 bei klassischem ML, OWASP Top 10 for LLM Applications bei GenAI).
Kreuzreferenztabelle
Matrix Anforderungen × elementare Gefährdungen: Zeilen = Anforderungen (A1 … An mit Klasse B/S/H), Spalten = die einschlägigen G 0.x; „X" markiert, welche Anforderung welche Gefährdung adressiert. Pflichtregeln:
- G-Nummer und -Titel verbatim aus
references/elementare-gefaehrdungen — niemals Titel umformulieren, niemals Nummern aus dem Gedächtnis vergeben. (Typische Fehler: G 0.18 ist Fehlplanung oder fehlende Anpassung, nicht „Diebstahl …" — das ist G 0.16; G 0.20 ist Informationen oder Produkte aus unzuverlässiger Quelle.)
- Jede Zuordnung muss einzeln begründbar sein. Eine Anforderung, die in (fast) allen Spalten ein „X" trägt, ist ein Qualitätswarnsignal (Über-Mapping) und wird ausgedünnt.
- Lückenlos in beide Richtungen: Jede Gefährdungs-Spalte hat ≥ 1 „X"; jede Anforderungs-Zeile hat ≥ 1 „X".
Anforderungen schreiben — die zentralen Regeln
Verbindlichkeit über Großbuchstaben-Modalverben. Vollständige Tabelle in references/modalverben-und-stil; Kurzform:
| Verb | Bedeutung |
|---|
| MUSS / MÜSSEN, IST/SIND … ZU | uneingeschränkt zu erfüllen |
| DARF NICHT / DÜRFEN NICHT | in keinem Fall zulässig |
| SOLLTE / SOLLTEN | normalerweise zu erfüllen; Abweichung nur begründet |
| SOLLTE NICHT / SOLLTEN NICHT | normalerweise zu unterlassen; Ausnahmen begründen |
| KANN / KÖNNEN | optional |
Klasse bestimmt das Leitverb. B → MUSS/DARF NICHT, S → SOLLTE/SOLLTE NICHT, H → SOLLTE (+ Schutzziel-Tag). Verbindlichkeitsgrade nicht in einem Satz mischen; insbesondere kein MUSS in einer S- oder H-Anforderung.
Eine Anforderung = eine prüfbare Aussage. Atomar formulieren, sodass im IT-Grundschutz-Check eindeutig „umgesetzt / teilweise / nicht umgesetzt / entbehrlich" beantwortbar ist. Herstellerneutral, technologie- und lösungsoffen (das Was, nicht das produktspezifische Wie).
Sprachstil/Duktus. Nüchtern, administrativ, präzise, passiv-/normlastig. Keine werblichen Aussagen, keine Begründungen oder Erklärungen, warum eine Maßnahme gut ist, im normativen Satz — die Maßnahme selbst steht im Fokus. Keine Füllwörter, kein „Plaudern". Details und Negativbeispiel in references/modalverben-und-stil.
Reihenfolge je Stufe: Planung zuerst, danach Beschaffung → Umsetzung → Betrieb → Notfall/Aussonderung.
ID- und Nummern-Systematik
Schema: SCHICHT.Gruppe[.Teilbaustein].A<Nr> — z. B. APP.4.4.A1, SYS.1.6.A12. Schichten, Vergaberegeln und häufig verwechselte Baustein-IDs (für korrekte Querverweise) in references/schichten-und-ids.
Durchlaufende Nummerierung: Anforderungen werden über alle drei Klassen hinweg fortlaufend nummeriert (A1, A2, A3 …); kein Neustart je Abschnitt. Die Klasse zeigt sich an (B)/(S)/(H) und der Abschnittszuordnung.
Nummernstabilität bei Editionsüberarbeitung: Gestrichene Anforderungen behalten ihre Nummer als Platzhalter und werden mit „ENTFALLEN" markiert. Neue Anforderungen erhalten die nächste freie Nummer am Ende — bestehende werden nicht umnummeriert.
Überarbeitungsmodus (Editionspflege)
Eine Überarbeitung ist nicht bloßes Umformatieren. Wird ein bestehender Baustein überarbeitet, gilt:
- Recherche neu durchführen (Schritt 1) — aktueller Stand der Technik, neue Angriffsmuster, neue Werkzeuge/Normen.
- Substantiell erweitern: zusätzliche Gefährdungen und Anforderungen aufnehmen, die seit der Vorfassung relevant geworden sind. Neue Anforderungen mit nächster freier Nummer am Ende der jeweiligen Klasse; neue Gefährdungen in Kapitel 2 und in die Kreuzreferenztabelle einarbeiten.
- Stabilität wahren: bestehende IDs nicht umnummerieren; entfallene als ENTFALLEN; Kreuzreferenztabelle vollständig nachziehen.
- Standarderwartung an eine Überarbeitung ist ein inhaltlicher Zuwachs, nicht Parität mit der Vorfassung.
Qualitätssicherung vor Abgabe
Checkliste in references/qualitaetscheck vollständig durchgehen. Kernpunkte:
- Alle Pflichtkapitel (1–4 inkl. Unterkapitel, Zuständigkeiten, Kreuzreferenztabelle) vorhanden.
- Jede Anforderung als nicht nummerierte H3-Überschrift, atomar, prüfbar, mit klassenkonformem Leitverb (kein MUSS in S/H).
- Jede H-Anforderung trägt den Schutzziel-Tag (C/I/A).
- Alle Rollen aus dem Rollenkatalog, korrekt bezeichnet (z. B. Beschaffungsstelle).
- Gefährdungslage enthält nur Bedrohungen, keine Maßnahmen.
- Querverweise mit korrekter ID + Titel; keine Doppelregelung.
- Kreuzreferenztabelle: G-Titel verbatim, Mapping selektiv/begründet, in beide Richtungen lückenlos.
- ID-Systematik korrekt, Nummern fortlaufend, ENTFALLEN-Platzhalter bei Überarbeitung; bei Überarbeitung Inhalt erweitert.
- Herstellerneutral, sachlich, BSI-Duktus.
IT-Grundschutz++ / Maschinenlesbarkeit (optional)
Soll der Baustein zusätzlich maschinenlesbar (OSCAL/Grundschutz++) vorliegen: stabile ID je Anforderung als Schlüssel, Klasse (B/S/H) und Schutzziel-Bezug (C/I/A) als Attribute (der H-Schutzziel-Tag ist hierfür direkt verwertbar), Kreuzreferenz als explizite Relation zu G 0.x. Zielschema projektspezifisch — beim Nutzer erfragen.
Hinweis zur Edition
Struktur und Systematik folgen der Edition 2023. Da das Kompendium fortlaufend gepflegt wird, redaktionelle Detailkonventionen (Rollenbezeichnungen, Schutzziel-Kennzeichnung, neue Schichtbausteine, Kreuzreferenz-Konventionen) gegen die jeweils aktuelle Edition gegenprüfen, bevor ein Baustein final eingereicht wird.
Änderungshistorie
- 2.0 — Rollen nur noch aus normiertem Katalog (
references/rollenkatalog; korrekte Bezeichnung „Beschaffungsstelle"). Schutzziel-Tag (C/I/A) bei jeder H-Anforderung verpflichtend. Jede Anforderung als nicht nummerierte H3-Überschrift. Verbindliche Überschriften-Ebenen ergänzt. Kreuzreferenztabelle: G-Titel/-Nummern verbatim aus Referenz, Über-Mapping verboten. Querverweis-Korrektheit (ID + Titel) erzwungen, häufig verwechselte IDs ergänzt. Cross-Class-Verbindlichkeit (kein MUSS in S/H) geschärft. BSI-Duktus als explizite Stilregel. Überarbeitungsmodus: inhaltliche Erweiterung (zusätzliche Gefährdungen/Anforderungen) verpflichtend.
- 1.0 — Erstfassung.
references/baustein-vorlage
references/baustein-vorlage
Baustein-Vorlage (Gerüst zum Befüllen)
Platzhalter in <…> ersetzen. Struktur 1:1 als Markdown-Gerüst übernehmen. Überschriften-Ebenen beachten: Kapitel = ##, Unterkapitel/Gefährdungen/Anforderungen = ### (Anforderungen sind nicht nummerierte H3-Überschriften, keine Listenpunkte).
1 Beschreibung
1.1 Einleitung
<Zielobjekt, Technologie/Funktion, Sicherheitsrelevanz. Herstellerneutral.>
1.2 Zielsetzung
<Sicherheitsziel des Bausteins; welche Aspekte von Vertraulichkeit, Integrität, Verfügbarkeit im Vordergrund stehen.>
1.3 Abgrenzung und Modellierung
<Worauf der Baustein anzuwenden ist; was NICHT behandelt wird; Querverweise auf angrenzende Bausteine mit korrekter ID UND korrektem Titel, z. B. „sichere Softwareentwicklung → CON.8 Software-Entwicklung", „Cloud-Bezug → OPS.2.2 Cloud-Nutzung", „Betriebssystem-Härtung → SYS.1.1 Allgemeiner Server". IDs gegen references/schichten-und-ids prüfen.>
2 Gefährdungslage
<Einleitungssatz: für dieses Zielobjekt sind folgende spezifische Gefährdungen von besonderer Bedeutung.>
<Gefährdung 1 – Titel>
<Konkrete Bedrohung, keine Maßnahme.>
<Gefährdung 2 – Titel>
<…>
<… 5–12 Gefährdungen; jede muss in mind. eine Anforderung münden und sich einer G 0.x zuordnen lassen …>
3 Anforderungen
Im Folgenden sind die spezifischen Anforderungen des Bausteins aufgeführt. Grundsätzlich ist für die Erfüllung der Anforderungen zuständig. Abweichungen werden in den entsprechenden Anforderungen gesondert genannt.
| Zuständigkeiten | Rollen |
|---|
| Grundsätzlich zuständig | <z. B. IT-Betrieb> |
| Weitere Zuständigkeiten | <z. B. Fachverantwortliche, Entwickler, Beschaffungsstelle> |
3.1 Basis-Anforderungen
Die folgenden Anforderungen MÜSSEN vorrangig erfüllt werden.
.A1 Planung <des Einsatzes / der Separierung / …> (B) [optional: abweichende Rolle]
<Planungs-/Konzeptionsanforderung – steht am Anfang der Stufe. Text mit MUSS.>
.A2 (B)
<Weitere Basis-Anforderung entlang des Lebenszyklus (Beschaffung → Umsetzung → Betrieb → Notfall). MUSS / DARF NICHT.>
3.2 Standard-Anforderungen
Gemeinsam mit den Basis-Anforderungen entsprechen die folgenden Anforderungen dem Stand der Technik bei normalem Schutzbedarf. Sie SOLLTEN grundsätzlich erfüllt werden.
.A Planung / Konzeption <…> (S)
<Sofern auf Standard-Niveau einschlägig: Planung zuerst. Text mit SOLLTE — kein MUSS-Kern.>
.A (S) [optional: abweichende Rolle]
<Text mit SOLLTE / SOLLTE NICHT, Lebenszyklus-Reihenfolge.>
3.3 Anforderungen bei erhöhtem Schutzbedarf
Die folgenden Anforderungen sind exemplarisch und bei erhöhtem Schutzbedarf zu berücksichtigen; die konkrete Festlegung erfolgt im Rahmen einer Risikoanalyse. Der Schutzziel-Bezug ist am Ende jeder Anforderung in Klammern angegeben (C = Vertraulichkeit, I = Integrität, A = Verfügbarkeit).
.A Planung / Konzeption <…> bei erhöhtem Schutzbedarf (H)
<Sofern einschlägig: Planung zuerst. Text SOLLTE … (C, I, A)>
.A (H) [optional: abweichende Rolle]
<Text, überwiegend SOLLTE; am Satzende Schutzziel-Tag, z. B. (C, I)>
4 Weiterführende Informationen
4.1 Wissenswertes
<Verweise auf Normen, BSI-Standards 200-x, themenspezifische BSI-Leitfäden, einschlägige Literatur und angrenzende Bausteine. Quellen passend zum Geltungsbereich.>
Kreuzreferenztabelle zu elementaren Gefährdungen
<Einleitungssatz + Liste der relevanten elementaren Gefährdungen mit Nummer UND Titel, verbatim aus elementare-gefaehrdungen.>
Spalten = relevante elementare Gefährdungen (nur die einschlägigen, in der Praxis meist 8–20); Zeilen = Anforderungen mit Klasse. „X" markiert die Zuordnung — jede Zuordnung einzeln begründbar (keine „X-überall"-Zeile).
| Anforderung | G 0. | G 0. | G 0. | … |
|---|
| .A1 (B) | X | | X | |
| .A2 (B) | | X | | |
| .A (S) | | X | X | |
| .A (H) | X | | | |
Prüfen: Jede Spalte (Gefährdung) hat mindestens ein „X"; jede Zeile (Anforderung) hat mindestens ein „X".
references/elementare-gefaehrdungen
Elementare Gefährdungen (G 0.1 – G 0.47)
Das BSI definiert 47 elementare Gefährdungen. Sie sind herstellerneutral, produkt- und technikunabhängig formuliert und bilden die Bezugsbasis für die Kreuzreferenztabelle jedes Bausteins. In der Gefährdungslage (Kapitel 2) werden die spezifischen Bedrohungen des Zielobjekts beschrieben; in der Kreuzreferenztabelle werden die Anforderungen den hier gelisteten elementaren Gefährdungen zugeordnet.
Stand: Edition 2023. Vor dem finalen Mapping gegen die aktuelle Edition gegenprüfen.
Verbindliche Nutzung (Pflicht). Für die Kreuzreferenztabelle Nummer und Titel jeder elementaren Gefährdung verbatim aus dieser Tabelle übernehmen. Titel niemals umformulieren oder paraphrasieren; Nummern niemals aus dem Gedächtnis vergeben. Typische Fehlerquellen: G 0.16 (Diebstahl …) vs. G 0.18 (Fehlplanung oder fehlende Anpassung); G 0.19 (Offenlegung schützenswerter Informationen) vs. G 0.20 (Informationen oder Produkte aus unzuverlässiger Quelle); für KI/ML häufig einschlägig: G 0.14, G 0.19, G 0.20, G 0.22, G 0.28, G 0.39, G 0.40, G 0.45, G 0.46.
| ID | Elementare Gefährdung |
|---|
| G 0.1 | Feuer |
| G 0.2 | Ungünstige klimatische Bedingungen |
| G 0.3 | Wasser |
| G 0.4 | Verschmutzung, Staub, Korrosion |
| G 0.5 | Naturkatastrophen |
| G 0.6 | Katastrophen im Umfeld |
| G 0.7 | Großereignisse im Umfeld |
| G 0.8 | Ausfall oder Störung der Stromversorgung |
| G 0.9 | Ausfall oder Störung von Kommunikationsnetzen |
| G 0.10 | Ausfall oder Störung von Versorgungsnetzen |
| G 0.11 | Ausfall oder Störung von Dienstleistern |
| G 0.12 | Elektromagnetische Störstrahlung |
| G 0.13 | Abfangen kompromittierender Strahlung |
| G 0.14 | Ausspähen von Informationen (Spionage) |
| G 0.15 | Abhören |
| G 0.16 | Diebstahl von Geräten, Datenträgern oder Dokumenten |
| G 0.17 | Verlust von Geräten, Datenträgern oder Dokumenten |
| G 0.18 | Fehlplanung oder fehlende Anpassung |
| G 0.19 | Offenlegung schützenswerter Informationen |
| G 0.20 | Informationen oder Produkte aus unzuverlässiger Quelle |
| G 0.21 | Manipulation von Hard- oder Software |
| G 0.22 | Manipulation von Informationen |
| G 0.23 | Unbefugtes Eindringen in IT-Systeme |
| G 0.24 | Zerstörung von Geräten oder Datenträgern |
| G 0.25 | Ausfall von Geräten oder Systemen |
| G 0.26 | Fehlfunktion von Geräten oder Systemen |
| G 0.27 | Ressourcenmangel |
| G 0.28 | Software-Schwachstellen oder -Fehler |
| G 0.29 | Verstoß gegen Gesetze oder Regelungen |
| G 0.30 | Unberechtigte Nutzung oder Administration von Geräten und Systemen |
| G 0.31 | Fehlerhafte Nutzung oder Administration von Geräten und Systemen |
| G 0.32 | Missbrauch von Berechtigungen |
| G 0.33 | Personalausfall |
| G 0.34 | Anschlag |
| G 0.35 | Nötigung, Erpressung oder Korruption |
| G 0.36 | Identitätsdiebstahl |
| G 0.37 | Abstreiten von Handlungen |
| G 0.38 | Missbrauch personenbezogener Daten |
| G 0.39 | Schadprogramme |
| G 0.40 | Verhinderung von Diensten (Denial of Service) |
| G 0.41 | Sabotage |
| G 0.42 | Social Engineering |
| G 0.43 | Einspielen von Nachrichten |
| G 0.44 | Unbefugtes Eindringen in Räumlichkeiten |
| G 0.45 | Datenverlust |
| G 0.46 | Integritätsverlust schützenswerter Informationen |
| G 0.47 | Schädliche Seiteneffekte IT-gestützter Angriffe |
Auswahl für einen Baustein
- Nur die elementaren Gefährdungen aufnehmen, die für das Zielobjekt tatsächlich relevant sind (in der Praxis meist 8–20).
- Infrastruktur-/Umweltgefährdungen (G 0.1–G 0.12) sind für reine Anwendungs-/Prozessbausteine oft nicht einschlägig und werden dann an die zuständigen INF-/Prozessbausteine abgegrenzt.
- Jede in Kapitel 2 beschriebene spezifische Gefährdung sollte sich genau einer oder mehreren elementaren Gefährdungen zuordnen lassen; passt nichts, ist die Bedrohung evtl. außerhalb des Geltungsbereichs.
references/modalverben-und-stil
Verbindlichkeit, Modalverben und Redaktionsstil
Verbindlichkeits-Modalverben (Großbuchstaben)
In Großbuchstaben gesetzte Verben zeigen die Verbindlichkeit einer Anforderung. Maßgeblich ist die Schreibung in Versalien — dasselbe Wort in normaler Schreibung trägt keine normative Bedeutung.
| Formulierung | Verbindlichkeit |
|---|
| MUSS / MÜSSEN; IST … ZU / SIND … ZU | Diese Anforderung muss unbedingt erfüllt werden. |
| DARF NICHT / DÜRFEN NICHT | Was hier beschrieben wird, darf in keinem Fall geschehen. |
| SOLLTE / SOLLTEN | Sollte normalerweise erfüllt werden; Abweichung nur in begründeten, dokumentierten Ausnahmefällen (Risikomanagement). |
| SOLLTE NICHT / SOLLTEN NICHT | Normalerweise zu unterlassen; Ausnahmen begründen und dokumentieren. |
| KANN / KÖNNEN | Optionale Empfehlung ohne Verbindlichkeit. |
Zuordnung Modalverb ↔ Anforderungsklasse (Klasse bestimmt das Leitverb)
- 3.1 Basis (B): vorrangig und uneingeschränkt → überwiegend MUSS / MÜSSEN; wo ein Verbot die natürliche Form ist, DARF NICHT. Das volle Spektrum nutzen — nicht reflexhaft nur MUSS. SOLLTE ist hier untypisch.
- 3.2 Standard (S): Stand der Technik bei normalem Schutzbedarf → überwiegend SOLLTE / SOLLTE NICHT. Eine S-Anforderung enthält keinen MUSS-Kern. (Häufiger Fehler: „Es MUSS jederzeit nachvollziehbar sein …" in einer (S)-Anforderung — das ist ein Verbindlichkeitskonflikt. Korrekt: „Es SOLLTE nachvollziehbar dokumentiert sein …".)
- 3.3 Erhöht (H): Beispielcharakter, ersetzbar → überwiegend SOLLTE. Pflicht: am Ende jeder H-Anforderung den Schutzziel-Bezug in Klammern ausweisen:
(C), (I), (A) bzw. Kombination (C = Vertraulichkeit, I = Integrität, A = Verfügbarkeit). Kein MUSS in einer H-Anforderung.
Stilregeln für Anforderungstexte (BSI-Duktus)
- Atomar & prüfbar. Eine Anforderung = eine eindeutig prüfbare Aussage („umgesetzt / teilweise / nicht umgesetzt / entbehrlich" muss eindeutig beantwortbar sein).
- Genau ein Verbindlichkeitsgrad pro Aussage. Nicht MUSS und SOLLTE in einem Satz mischen; mehrere Pflichten auf mehrere Anforderungen aufteilen.
- Lösungsoffen & herstellerneutral. Das Was (Schutzziel/Ergebnis) fordern, nicht ein produktspezifisches Wie. Konfigurationen, Tools und Schritt-für-Schritt-Anleitungen gehören in separate Umsetzungshinweise.
- Nüchtern, administrativ, präzise, normlastig. Sachlicher Verwaltungsduktus, passivische/normative Formulierung. Keine werblichen Aussagen, keine Füllwörter, kein „Plaudern". Im normativen Satz keine Begründung, warum die Maßnahme gut ist — die Maßnahme selbst steht im Fokus (Begründendes ggf. knapp in den erläuternden Abschnittsvorspann, nicht in die Anforderung).
- Aktiv-eindeutiges Pflichtsubjekt. Wer die Pflicht trägt, muss erkennbar sein; vage „und/oder"-Ketten und Schachtelsätze vermeiden.
- Rolle aus dem Katalog. Abweichende Zuständigkeit in eckigen Klammern in der Anforderungsüberschrift, ausschließlich Rollen aus
rollenkatalog.
Beispiele
Gut (Basis, MUSS, atomar, lösungsoffen):
### SYS.1.6.A4 Verwendung sicherer Images (B)
Es MÜSSEN ausschließlich Images verwendet werden, deren Herkunft und
Integrität nachprüfbar sind.
Gut (erhöht, SOLLTE, mit Pflicht-Schutzziel-Tag):
### APP.4.10.A13 Nutzung von Privacy-Enhancing Technologies (H) [Entwickler]
Beim Training mit personenbezogenen Daten oder Geschäftsgeheimnissen SOLLTEN
PETs (z. B. Differential Privacy, Federated Learning) eingesetzt werden. (C)
Schlecht (vermischt zwei Verbindlichkeiten und nennt ein konkretes Produkt):
Es MUSS Docker Content Trust aktiviert und es SOLLTE zusätzlich ein
Scanner eingesetzt werden.
→ aufteilen: eine MUSS-Anforderung „Integrität der Images sicherstellen" (lösungsoffen) und eine SOLLTE-Anforderung „regelmäßiges Schwachstellen-Scanning".
Schlecht (werblicher/erklärender Duktus):
Mit einem modernen, leistungsstarken SIEM lassen sich Angriffe bequem und
zuverlässig erkennen, was die Sicherheit deutlich erhöht.
→ nüchtern und normativ: „Sicherheitsrelevante Ereignisse SOLLTEN zentral protokolliert und auf Angriffsmuster ausgewertet werden."
references/qualitaetscheck
Qualitätssicherung – Checkliste vor Abgabe
Struktur & Form
Anforderungen
Rollen
Nummerierung & ID
Gefährdungslage
Abgrenzung & Querverweise
Kreuzreferenztabelle
Sprache & Form
Mapping/Interoperabilität (falls gefordert)
references/rollenkatalog
Rollenkatalog (verbindliche Allowlist)
Das BSI-IT-Grundschutz-Kompendium arbeitet mit einem normierten Rollenkatalog. In Bausteinen (Zuständigkeitstabelle und abweichende Rollen in eckigen Klammern) dürfen ausschließlich diese standardisierten Rollen verwendet werden. Keine eigenen Rollen erfinden und keine freien Bezeichnungen bilden — sonst bricht die Mapping-/Zuständigkeitslogik im IT-Grundschutz-Check und in nachgelagerten Mappings.
Genau eine Rolle ist je Baustein „Grundsätzlich zuständig"; alles andere sind „Weitere Zuständigkeiten" bzw. anforderungsspezifische Abweichungen.
Häufig in APP-/SYS-/NET-Bausteinen verwendete Rollen
| Rolle | Kurzbeschreibung |
|---|
| Institutionsleitung | Oberste Leitungsebene; trägt Gesamtverantwortung für Informationssicherheit. |
| Informationssicherheitsbeauftragter (ISB) | Steuert das ISMS, erstellt/fortschreibt Richtlinien, sensibilisiert. |
| Fachverantwortliche | Inhaltlich für einen oder mehrere Geschäftsprozesse/Fachverfahren zuständig (fasst weitere Rollen wie Änderungs-/Archivverwaltung zusammen). |
| IT-Betrieb | Plant, konfiguriert, betreibt und wartet IT-Systeme/-Dienste. |
| Entwickler | Konzipiert und implementiert Software/Konfigurationen. |
| Planer | Plant Architektur/Einführung von Systemen und Diensten. |
| Benutzer | Nutzende der Systeme/Anwendungen. |
| Beschaffungsstelle | Initiiert und überwacht Beschaffungen (öffentliche Vergabe inkl.); schließt die zuständige Leitung mit ein. Korrekte Bezeichnung — nicht „Beschaffer". |
Weitere normierte Rollen (je nach Schicht/Thema)
| Rolle | Kurzbeschreibung |
|---|
| Vorgesetzte | Disziplinarische/fachliche Führungsverantwortung. |
| Personalabteilung | Personelle Maßnahmen (Ein-/Austritt, Verpflichtungen). |
| Datenschutzbeauftragte | Wirken auf datenschutzkonformen Umgang mit personenbezogenen Daten hin. |
| Bereichssicherheitsbeauftragte | ISB-Aufgaben für einen abgegrenzten Bereich. |
| Notfallbeauftragte | Verantwortlich für Notfallmanagement/BCM. |
| Auditteam | Führt interne Audits/Revisionen durch. |
| Haustechnik | Infrastruktur eines Gebäudes/Liegenschaft (inkl. zuständiger Leitung). |
| Brandschutzbeauftragte | Alle Fragen des Brandschutzes. |
| Wartungspersonal | Wartung/Instandhaltung von Geräten und Anlagen. |
| ICS-Informationssicherheitsbeauftragte | Informationssicherheit in industriellen Steuerungsumgebungen (IND-Schicht). |
Regeln
- Bezeichnungen exakt wie im Rollenkapitel der Zieledition schreiben (das Kompendium hat in Edition 2023 mehrere Rollenbezeichnungen angepasst und teils geschlechtsneutral formuliert, z. B. „Benutzende", „Entwickelnde", „Planende"). Im Zweifel die Schreibweise/Geschlechtsform gegen das Rollenkapitel der Zieledition prüfen — aber immer aus diesem Katalog wählen.
- Ist keine passende Standardrolle vorhanden, ist meist „Fachverantwortliche" oder „IT-Betrieb" die richtige Sammelrolle — keine Neuschöpfung.
- Abweichende Zuständigkeit einzelner Anforderungen in eckigen Klammern in der H3-Anforderungsüberschrift, z. B.
### …A6 … (B) [ISB].
Maßgebliche Quelle ist das Kapitel „Rollen" des IT-Grundschutz-Kompendiums (Edition 2023). Diese Allowlist ist eine Arbeitsauswahl der gebräuchlichsten Rollen; bei selteneren Rollen dort gegenprüfen.
references/schichten-und-ids
Schichten und ID-Systematik
Die zehn Schichten des IT-Grundschutz-Kompendiums
Prozessbausteine (organisations-/managementnah):
| Präfix | Schicht |
|---|
| ISMS | Sicherheitsmanagement |
| ORP | Organisation und Personal |
| CON | Konzeption und Vorgehensweise |
| OPS | Betrieb |
| DER | Detektion und Reaktion |
Systembausteine (technik-/objektnah):
| Präfix | Schicht |
|---|
| APP | Anwendungen |
| SYS | IT-Systeme |
| IND | Industrielle IT |
| NET | Netze und Kommunikation |
| INF | Infrastruktur |
Aufbau der Baustein-ID
SCHICHT.Gruppe[.Teilbaustein] und je Anforderung .A<Nr>:
SYS.1.6 → Schicht SYS, Gruppe 1 (Server allgemein), Teilbaustein 6 (Containerisierung)APP.4.4 → Schicht APP, Gruppe 4 (Business-Anwendungen), Teilbaustein 4 (Kubernetes)NET.1.1 → Schicht NET, Gruppe 1 (Netzarchitektur), Teilbaustein 1 (Netzarchitektur und -design)
Bei einem neuen Baustein die freie, thematisch passende Position in der Schichtgliederung wählen und mit der BSI-Redaktion bzw. dem Grundschutz++-Vorgehen abstimmen — nicht willkürlich vergeben.
Häufig verwechselte Baustein-IDs (Querverweis-Referenz)
Querverweise in 1.3/4.1 mit korrekter ID UND korrektem Titel angeben. Diese IDs werden besonders oft falsch zitiert (Edition 2023):
| ID | Korrekter Titel | Nicht verwechseln mit |
|---|
| CON.1 | Kryptokonzept | nicht Software-Entwicklung |
| CON.8 | Software-Entwicklung (auftragnehmende Seite) | ≠ CON.1 |
| CON.10 | Entwicklung von Webanwendungen | ≠ APP.1.1, ≠ APP.3.1 |
| APP.1.1 | Office-Produkte | nicht „Webanwendungen"/„Individualsoftware" |
| APP.1.4 | Mobile Anwendung (Apps) | nicht „Individualsoftware" |
| APP.7 | Entwicklung von Individualsoftware (auftraggebende Seite) | ≠ APP.1.4 |
| APP.3.1 | Webanwendungen und Webservices (Betrieb) | ≠ CON.10 (Entwicklung) |
| APP.4.3 | Relationale Datenbanksysteme | — |
| APP.4.4 | Kubernetes | — |
| OPS.2.2 | Cloud-Nutzung | ≠ OPS.2.3 |
| OPS.2.3 | Nutzung von Outsourcing (ersetzt OPS.2.1) | ≠ OPS.2.2 |
| OPS.3.2 | Anbieten von Outsourcing (ersetzt OPS.3.1) | — |
| SYS.1.1 | Allgemeiner Server | — |
| SYS.1.6 | Containerisierung | — |
| NET.1.1 | Netzarchitektur und -design | — |
Im Zweifel die offizielle Baustein-Liste der Zieledition prüfen (BSI: „IT-Grundschutz-Bausteine (Edition 20xx)"). Die APP.4-Untergruppe endet in Edition 2023 bei APP.4.6 — ein „APP.4.10" o. ä. ist dort (noch) nicht vergeben und nur als Entwurf/++-Kandidat zu verstehen.
Anforderungsnummern
Modellierungslogik (für Kapitel 1.3)
- Prozessbausteine werden meist einmal auf den gesamten Informationsverbund angewendet, Systembausteine je Zielobjekt.
- In 1.3 explizit benennen, welche angrenzenden Bausteine ergänzend gelten (z. B. „Betriebssystem-Härtung → SYS.1.1", „Netzseparierung → NET.1.1", „Allgemeiner IT-Betrieb → OPS.1.1.1"), um Doppelregelungen zu vermeiden.
