Glossar zum Grundschutz++

Zentrales Glossar zum Grundschutz++.
Diese Seite kann mit {{:Glossar zum Grundschutz++}} in andere Artikel zum Grundschutz++ eingebunden werden.

Grundschutz++ Glossar

Zentrale Begriffe aus dem Grundschutz++ und ihre Bedeutung:

Begriff	Kurzbeschreibung
Asset	Objekt, das für einen Geschäftsprozess relevant ist (z.B. Anwendung, Server, Netzkomponente, Daten, Raum, Dienstleistung, Rolle). Assets sind die konkreten Zielobjekte, auf die Anforderungen aus Praktiken über Zielobjektkategorien vererbt werden.
Anforderung	Erwartung an Organisation, Prozesse oder Technik, die erfüllt sein muss oder sollte, um ein angemessenes Sicherheitsniveau zu erreichen. Wird überwiegend aus Praktiken abgeleitet, mit Zielobjektkategorien und Assets verknüpft und im Anforderungspaket konsolidiert.
Anforderungspaket	Gesamtheit aller für einen Informationsverbund modellierten Anforderungen (ISMS‑Anforderungen, objektbezogene Anforderungen aus Praktiken, zusätzliche gesetzliche/vertragliche und risikobasierte Anforderungen). Entsteht in Schritt 2 und ist Basis für Realisierung, Überwachung und Verbesserung.
Bausteine (alt)	Frühere Bauelemente des IT‑Grundschutzes mit Anforderungen und Maßnahmen für bestimmte IT‑Systeme, Anwendungen, Infrastrukturen oder Prozesse. Inhalte werden in GS++ in ein Modell aus Praktiken und Zielobjektkategorien überführt.
Compliance	Einhaltung gesetzlicher, regulatorischer, vertraglicher und interner Vorgaben im Rahmen des ISMS.
Ereignis	In Satzschablonen der sicherheitsrelevante Zustand oder Auslöser, der eine Handlung notwendig macht (z.B. Inbetriebnahme, Änderung, Vorfall). Zusammen mit Handlungswort und Ergebnis bildet es den situativen Kontext einer Anforderung.
Geltungsbereich (Scope)	Beschreibt, für welche Teile der Organisation das ISMS gilt (Organisationseinheiten, Standorte, Prozesse, Systeme). Wird in Schritt 1 festgelegt und ist Grundlage für Auswahl der Geschäftsprozesse und Definition des Informationsverbunds.
Geschäftsprozess	Fachliche Abfolge von Tätigkeiten zur Erbringung von Leistungen oder Erfüllung gesetzlicher Aufgaben. In GS++ prozessorientierter Ausgangspunkt für Informationssicherheitseinstufung, Schutzbedarf und Modellierung.
Grundschutz++	Objektorientierte Weiterentwicklung des IT‑Grundschutzes. Transformiert das Bausteinmodell in ein digitales Modell aus Praktiken, Zielobjektkategorien und Assets, eingebettet in einen fünfstufigen PDCA‑basierten Sicherheitsprozess.
Handlungswort	Verb in Satzschablonen, das die Art der geforderten Aktion beschreibt (z.B. protokollieren, prüfen, freigeben). Definiert gemeinsam mit Ereignis und Ergebnis den Handlungstyp einer Anforderung und erleichtert clustering/filtering von Anforderungen.
Informationssicherheitsleitlinie	Grundlegendes Steuerungsdokument des ISMS. Beschreibt Ziele und Bedeutung der Informationssicherheit, Verantwortung der Leitung sowie Rahmen für Rollen, Sicherheitsniveau und kontinuierliche Verbesserung.
Informationssicherheitseinstufung	Prozess zur Bestimmung des Schutzbedarfs von Informationen und Geschäftsprozessen. In GS++ zweistufig: Schutzbedarf von Informationen bestimmen, auf Geschäftsprozesse übertragen und daraus Sicherheitsniveau ableiten.
Informationsverbund	Fachlich und organisatorisch abgegrenzte Menge von Geschäftsprozessen, Assets und Strukturen, für die das ISMS konkret aufgebaut wird. Liegt innerhalb des Geltungsbereichs und dient der handhabbaren Modellierung.
Interessierte Parteien	Interne und externe Personen oder Organisationen (z.B. Leitung, Mitarbeitende, Kunden, Aufsichtsstellen), die Anforderungen oder Erwartungen an die Informationssicherheit haben.
ISMS	Informationssicherheitsmanagementsystem zur Planung, Umsetzung, Überwachung und Verbesserung von Informationssicherheit. GS++ beschreibt eine ISO‑kompatible, aber eigenständig modellierte ISMS‑Methodik.
IT‑Grundschutz (alt)	Klassischer, bausteinbasierter IT‑Grundschutz. wird aktuell durch GS++ ersetzt. Im Grundschutz++ entfällt die Vorsilbe "IT-". Zukünftig wird nur noch von "Grundschutz" gesprochen.
Kontinuierliche Verbesserung	Fünfter Prozessschritt (ACT). Behandlung von Nicht‑Konformitäten, Compliance‑Verstößen und Verbesserungspotenzialen, Planung/Umsetzung von Korrektur‑ und Verbesserungsmaßnahmen, Wirksamkeitsprüfung und Neubewertung des Sicherheitsniveaus.
Managementbewertung	Formale Bewertung des ISMS durch die Leitung (Eignung, Angemessenheit, Wirksamkeit). Führt zu Entscheidungen über Ressourcen, Prioritäten und ggf. Anpassung des Sicherheitsniveaus; Input für kontinuierliche Verbesserung.
Modalverb	Verbindlichkeitsstufe einer Anforderung („MUSS“, „SOLLTE“, „KANN“). In GS++ bewusst dosiert eingesetzt, um zwischen zwingenden Vorgaben und risikobasiert gestaltbaren Anforderungen zu unterscheiden.
Nicht‑Konformität	Festgestellte Abweichung zwischen geforderter/vereinbarter ISMS‑Vorgabe und der tatsächlichen Umsetzung (z.B. aus Audit, Review oder Überwachung).
OSCAL	Open Security Controls Assessment Language, standardisiertes Datenformat (JSON/XML/YAML) zur Beschreibung von Kontrollen, Systemimplementierungen und Assessments. Basis für die maschinenlesbare Repräsentation des GS++‑Regelwerks.
PDCA‑Zyklus	Plan–Do–Check–Act‑Zyklus als übergeordnetes Steuerungsmodell. Die fünf Prozessschritte (Erhebung/Planung, Anforderungsanalyse, Realisierung, Überwachung, kontinuierliche Verbesserung) sind den PDCA‑Phasen zugeordnet und laufen zyklisch.
Praktik	Thematisches Bündel von Anforderungen zu einem Sicherheitsbereich (z.B. Berechtigungsmanagement, Patchmanagement). Liefert den inhaltlichen Anforderungskern; Anforderungen werden je Zielobjektkategorie formuliert und auf Assets vererbt, oft mit führender Zuständigkeit.
Realisierung	Dritter Prozessschritt (DO). Überführt das Anforderungspaket in konkrete Maßnahmen: Umsetzungsstatus, Bewertung offener Anforderungen, Priorisierung, Maßnahmenplan, Zuständigkeiten, Fristen, Ausnahmen, Nachverfolgung und Compliance in der Umsetzung.
Risikobetrachtung	Analyse, Bewertung und Behandlung von Risiken, die über den Standardumfang hinausgehen oder aus besonderen Schutzbedarfen, zusätzlichen Anforderungen oder Ausnahmen resultieren. Wird meist nach BSI‑Standard 200‑3 dokumentiert und eng mit Anforderungsanalyse/Realisierung verzahnt.
Satzschablone	Vordefinierte sprachliche Struktur für Anforderungen (z.B. Praktik + Zielobjektkategorie + Modalverb + Ereignis + Handlungswort + Ergebnis). Soll klare, atomare und konsistente Formulierungen sicherstellen und die Abbildung in ein OSCAL‑Modell erleichtern.
Schutzbedarf / Schutzbedarfskategorien	Maß für die Kritikalität der Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und Prozessen. Es gibt hier nur noch zwei Stufen: normal und hoch. Der Schutzbedarf ist Grundlage für Sicherheitsniveau und zusätzliche Anforderungen.
Sicherheitsniveau	Beschreibt, wie weit die Sicherheitsziele durch Maßnahmen erreicht werden (Erfüllungsgrad). Wird aus Schutzbedarf, Risiken und tatsächlich erfüllten Anforderungen abgeleitet und im Rahmen der Überwachung und Verbesserung regelmäßig bewertet. Es wird zwischen zwei Sicherheitsniveaus unterschieden: normal (SdT) und erhöht.
Stufe	In GS++ beschreibt „Stufe“ den Umsetzungsaufwand einer Anforderung (Stufe 0: nicht definiert, aber muss als erstes umgesetzt werden, Stufe 1-4: geschätzter Aufwand: 1 gering, 4 sehr hoch; Stufe 5: Anforderung für erhöhten Schutzbedarf.
Technik‑Layer / Beispiel‑Layer / Audit‑Layer	Ergänzende Dokumente zum GS++: Technik‑Layer beschreibt Datenmodell, Techniken, Werkzeugunterstützung; Beispiel‑Layer liefert Praxisbeispiele, typische Ausprägungen; Audit‑Layer (geplant) beschreibt die Prüf-/Auditperspektive.
Überwachung	Vierter Prozessschritt (CHECK). Bewertet Wirksamkeit und Compliance des ISMS durch Leistungsbewertung, Monitoring, Audits, Compliance‑Überwachung, Managementbewertung und Validierung des Anforderungspakets.
Validierung der Anforderungen	Prüfung, ob das Anforderungspaket noch angemessen ist (Passung zu Kontext, Schutzbedarf, Technikstand, Prozessen). Kann dazu führen, Teile der Anforderungsanalyse neu zu durchlaufen und das Paket anzupassen.
Zielobjekt (alt)	Früher generischer Begriff für (gruppierte) Objekte, auf die Anforderungen wirken. Im G++ gibt es keine Zielobjekte mehr, hier gibt es nur noch → Assets.
Zielobjektkategorie	„Klasse“ bzw. Typ von Objekten (z.B. Gebäude, Endgeräte, Webserver, Daten), für die Anforderungen definiert werden. Anforderungen werden pro Zielobjektkategorie formuliert und über die Zuordnung Asset → Zielobjektkategorie auf konkrete Assets vererbt.