Begriffsdefinition GS++: Unterschied zwischen den Versionen
Dirk (Diskussion | Beiträge) K (→Praktiken) |
Dirk (Diskussion | Beiträge) K (→Anforderungen) |
||
| Zeile 16: | Zeile 16: | ||
In englischen Standards wird für Anforderungen häufig der Begriff „control“ verwendet. | In englischen Standards wird für Anforderungen häufig der Begriff „control“ verwendet. | ||
Im Grundschutz++ wird der Verbindlichkeitsgrad analog zum klassischen IT-Grundschutz durch das Modalverb der Anforderung festgelegt: | Im Grundschutz++ wird der Verbindlichkeitsgrad analog zum klassischen IT-Grundschutz durch das '''Modalverb''' der Anforderung festgelegt: | ||
* '''MUSS''' → verpflichtend, keine Abweichungen zulässig. | * '''MUSS''' → verpflichtend, keine Abweichungen zulässig. | ||
* '''SOLLTE''' → grundsätzlich verpflichtend, Ausnahmen mit Begründung möglich. | * '''SOLLTE''' → grundsätzlich verpflichtend, Ausnahmen mit Begründung möglich. | ||
* '''KANN''' → optional, je nach Situation sinnvoll. | * '''KANN''' → optional, je nach Situation sinnvoll. | ||
Anforderungen sind in Zielobjektkategorien und ISMS-Praktiken enthalten und über diese mit spezifischen Assets (Zielobjektkategorien) oder dem ISMS übergreifend (ISMS-Praktiken) modelliert. | |||
==== Assets ==== | ==== Assets ==== | ||
| Zeile 49: | Zeile 50: | ||
Grupierte Assets bezeichnet man als Asset-Gruppen, die ihrerseits wie Assets behandelt werden. | Grupierte Assets bezeichnet man als Asset-Gruppen, die ihrerseits wie Assets behandelt werden. | ||
Assets erben ihr Sicherheitsniveau (Schutzbedarf) aus den Geschäftsprozessen, denen sie zugeordnet sind. Anforderungen werden nicht direkt auf Assets gelegt, sondern über Zielobjektkategorien vererbt. | |||
==== Blaupausen ==== | ==== Blaupausen ==== | ||
| Zeile 58: | Zeile 61: | ||
Blaupausen entsprechen damit in etwa den "'''''Profilen'''''" im klassischen IT-Grundschutz. | Blaupausen entsprechen damit in etwa den "'''''Profilen'''''" im klassischen IT-Grundschutz. | ||
Blaupausen sind Einstiegshilfen und ersetzen keine vollständige Modellierung. Sie dienen als Startpunkt und müssen durch eine GAP‑Analyse ergänzt werden. | |||
==== Geltungsbereich ==== | ==== Geltungsbereich ==== | ||
Der Geltungsbereich (Scope) definiert, für welchen organisatorischen und fachlichen Bereich das Informationssicherheitsmanagementsystem (ISMS) gilt. Er legt fest, welche Standorte, Systeme, Prozesse oder Einheiten vom ISMS abgedeckt werden und welche nicht. Damit wird klar abgegrenzt, wo das ISMS anzuwenden ist. | Der Geltungsbereich (Scope) definiert, für welchen organisatorischen und fachlichen Bereich das Informationssicherheitsmanagementsystem (ISMS) gilt. Er legt fest, welche Standorte, Systeme, Prozesse oder Einheiten vom ISMS abgedeckt werden und welche nicht. Damit wird klar abgegrenzt, wo das ISMS anzuwenden ist. | ||
Der Geltungsbereich ist organisatorisch definiert. Erst danach wird der technische Informationsverbund modelliert. | |||
==== Gestaltungsentscheidungen ==== | |||
Gestaltungsentscheidungen umfassen die Festlegung institutionenspezifischer '''Parameter''' (Rollen und Werte innerhalb der Anforderungen). Sie konkretisieren das Anforderungspaket und ermöglichen automatisierte Prüfungen. | |||
==== Informationssicherheitseinstufung ==== | ==== Informationssicherheitseinstufung ==== | ||
| Zeile 71: | Zeile 81: | ||
Die Einstufung bildet die Grundlage für die spätere Auswahl und Modellierung der Anforderungen im Anforderungspaket. | Die Einstufung bildet die Grundlage für die spätere Auswahl und Modellierung der Anforderungen im Anforderungspaket. | ||
Die klassische Pflicht zur CIA‑Einzelbewertung entfällt, sollte aber sinvollerweise weiter genutzt werden. | |||
Die Einstufung ist ein Pflichtschritt und bestimmt das Sicherheitsniveau aller zugehörigen Assets. | |||
==== Informationssicherheitsmanagementsystem (ISMS) ==== | ==== Informationssicherheitsmanagementsystem (ISMS) ==== | ||
| Zeile 76: | Zeile 90: | ||
Es stellt sicher, dass Sicherheitsstrategien und -maßnahmen regelmäßig auf ihre Wirksamkeit überprüft und bei Bedarf angepasst werden. Ziel ist ein dauerhaft wirksamer, ganzheitlicher Schutz von Informationen. | Es stellt sicher, dass Sicherheitsstrategien und -maßnahmen regelmäßig auf ihre Wirksamkeit überprüft und bei Bedarf angepasst werden. Ziel ist ein dauerhaft wirksamer, ganzheitlicher Schutz von Informationen. | ||
Das ISMS im Grundschutz++ basiert auf den ISMS‑Praktiken, die vollständig und verbindlich für den gesamten Informationsverbund gelten. | |||
==== Informationsverbund ==== | ==== Informationsverbund ==== | ||
Ein Informationsverbund umfasst alle technischen, organisatorischen, personellen und infrastrukturellen Komponenten, die gemeinsam Aufgaben der Informationsverarbeitung erfüllen. | Ein Informationsverbund umfasst alle technischen, organisatorischen, personellen und infrastrukturellen Komponenten, die gemeinsam Aufgaben der Informationsverarbeitung erfüllen. Der Informationsverbund bildet die technische und inhaltliche Modellierungseinheit des ISMS und umfasst alle Assets, Zielobjektkategorien und Anforderungen. | ||
Dies kann die gesamte Institution oder abgegrenzte Bereiche (z. | Dies kann die gesamte Institution oder abgegrenzte Bereiche (z.B. einzelne Abteilungen oder IT-Systemgruppen) betreffen, die durch gemeinsame Prozesse oder Strukturen verbunden sind. | ||
==== Maßnahmen ==== | ==== Maßnahmen ==== | ||
Maßnahmen sind konkrete Handlungen, Vorgaben oder technische Umsetzungen, die dazu dienen, erkannte Risiken zu steuern und Anforderungen zu erfüllen. Sie können organisatorischer, personeller, technischer oder infrastruktureller Art sein und sollen die Informationssicherheit (die Umsetzung der Anforderungen) wirksam sicherstellen. | Maßnahmen sind konkrete Handlungen, Vorgaben oder technische Umsetzungen, die dazu dienen, erkannte Risiken zu steuern und Anforderungen zu erfüllen. Sie können organisatorischer, personeller, technischer oder infrastruktureller Art sein und sollen die Informationssicherheit (die Umsetzung der Anforderungen) wirksam sicherstellen. | ||
Maßnahmen sind nicht Bestandteil des Grundschutz++‑Regelwerks. Sie werden von der Institution selbst definiert, um Anforderungen praktisch umzusetzen. | |||
==== Parameter ==== | |||
Parameter sind variabel gestaltbare Elemente innerhalb einer Anforderung des Grundschutz++. Sie ermöglichen es, Anforderungen institutionenspezifisch zu konkretisieren, ohne die allgemeine Formulierung der Anforderung selbst zu verändern. Parameter sind ein zentrales Konzept des Grundschutz++, da sie sowohl '''Flexibilität''' als auch '''Automatisierbarkeit''' unterstützen. | |||
Parameter können organisatorische, technische oder prozessuale Werte enthalten und werden im Rahmen der Anforderungsanalyse (Gestaltungsentscheidungen) festgelegt. Sie sind Bestandteil der maschinenlesbaren Grundschutz++‑Struktur (OSCAL/JSON) und ermöglichen eine präzise, prüfbare Umsetzung. | |||
Parameter dienen dazu: | |||
* Anforderungen an die Gegebenheiten der Institution anzupassen (z. B. Passwortlänge, Rollen, Fristen). | |||
* Verantwortlichkeiten eindeutig festzulegen. | |||
* Technische Werte oder Mindeststandards zu definieren. | |||
* Automatisierte Prüfungen und Tool‑gestützte Auswertungen zu ermöglichen. | |||
* Anforderungen konsistent und nachvollziehbar umzusetzen. | |||
Parameter ersetzen damit die früher oft textuell beschriebenen „institutionenspezifischen Ausprägungen“ im klassischen IT‑Grundschutz. | |||
Es lassen sich drei Haupttypen unterscheiden: | |||
· '''Rollen‑Parameter''' Definieren, welche Rolle für eine Anforderung verantwortlich ist (z. B. ISB, Administrator, Prozess‑Owner). | |||
· '''Wert‑Parameter''' Legen konkrete Werte fest, z. B. Mindestlängen, Fristen, Aufbewahrungszeiten oder technische Standards. | |||
· '''Auswahl‑Parameter''' Definieren Optionen, z. B. verwendete Authentifizierungsverfahren oder Speicherorte. | |||
Beispiel: | |||
'''Anforderung''': „Passwörter müssen eine Mindestlänge von '''<minimale_passwortlänge>''' Zeichen haben.“ | |||
→ Parameter: <code>minimale_passwortlänge = 12</code> | |||
Die Parameter müssen von der Organisation festgelegt, dokumentiert, freigegeben und regelmäßig im Rahmen der Überwachung (Prozessschritt 4) überprüft werden. | |||
==== Praktiken ==== | ==== Praktiken ==== | ||
| Zeile 95: | Zeile 144: | ||
* Technische Praktiken | * Technische Praktiken | ||
Die ISMS-Praktiken bilden den Regelkreis zur laufenden Steuerung und Verbesserung der Informationssicherheit. | Die ISMS-Praktiken bilden den Regelkreis zur laufenden Steuerung und Verbesserung der Informationssicherheit. | ||
Praktiken ersetzen (neben den Zielobjektkategorien) die Bausteine des klassischen IT‑Grundschutzes. Sie enthalten Anforderungen und Parameter und bilden die Grundlage für die Modellierung. | |||
==== Riskobetrachtung ==== | |||
Die Risikobetrachtung im Grundschutz++ ist eine vereinfachte, anlassbezogene Form der Risikoanalyse. | |||
Sie wird nur durchgeführt, wenn: | |||
* ein Geschäftsprozess als „'''hoch'''“ eingestuft wurde | |||
* wenn MUSS‑ oder SOLLTE‑Anforderungen nicht umgesetzt werden können | |||
* wenn zusätzliche Anforderungen ergänzt werden | |||
Im Gegensatz zur früheren Risikoanalyse nach BSI‑Standard 200‑3 ist sie deutlich schlanker und konzentriert sich auf Risiken, die durch das Standard‑Sicherheitsniveau nicht ausreichend abgedeckt sind. Ziel ist es, Bedrohungen, Schwachstellen und mögliche Auswirkungen zu bewerten und daraus geeignete Maßnahmen oder Entscheidungen abzuleiten. Die Ergebnisse werden dokumentiert und fließen in die kontinuierliche Verbesserung des ISMS ein. | |||
==== Schutzbedarf ==== | ==== Schutzbedarf ==== | ||
| Zeile 105: | Zeile 167: | ||
Je nach Bewertung wird der Schutzbedarf als „'''normal'''“ oder „'''hoch'''“ eingestuft und bestimmt das erforderliche Sicherheitsniveau sowie die Auswahl passender Anforderungen. | Je nach Bewertung wird der Schutzbedarf als „'''normal'''“ oder „'''hoch'''“ eingestuft und bestimmt das erforderliche Sicherheitsniveau sowie die Auswahl passender Anforderungen. | ||
Der Schutzbedarf wird nicht mehr pro Asset bestimmt, sondern ergibt sich ausschließlich aus der Informationssicherheitseinstufung der Geschäftsprozesse. | |||
==== Sicherheitsleitlinie ==== | ==== Sicherheitsleitlinie ==== | ||
| Zeile 118: | Zeile 182: | ||
* '''Normales Sicherheitsniveau''': entspricht dem Stand der Technik (kurz: normal SdT) | * '''Normales Sicherheitsniveau''': entspricht dem Stand der Technik (kurz: normal SdT) | ||
* '''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme (kurz: erhöht) | * '''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme (kurz: erhöht) | ||
Das Sicherheitsniveau bestimmt, ob Standard‑ oder erhöhte Anforderungen gelten und ob eine Risikobetrachtung erforderlich ist. | |||
==== Stufen ==== | ==== Stufen ==== | ||
| Zeile 146: | Zeile 211: | ||
[[Datei:Zielobjektkategorien.png|alternativtext=Zielobjektkategorien|mini|286x286px|Zielobjektkategorien]] | [[Datei:Zielobjektkategorien.png|alternativtext=Zielobjektkategorien|mini|286x286px|Zielobjektkategorien]] | ||
Zielobjektkategorien und sind Bestandteile eines Informationsverbunds, denen spezifische Anforderungen zugeordnet sind. Das können sowohl physische Objekte (z.B. Server, Räume) als auch logische Objekte (z.B. Anwendungen, Daten) sein. Die Zielobjekte entsprechen damit ansatzweise den "'''''Bausteinen'''''" im klassischen IT-Grundschutz. In der Modellierung werden Assets den Zielobjektkategorien zugeordnet und erben über diese ihre Anforderungen. | Zielobjektkategorien und sind Bestandteile eines Informationsverbunds, denen spezifische Anforderungen zugeordnet sind. Das können sowohl physische Objekte (z.B. Server, Räume) als auch logische Objekte (z.B. Anwendungen, Daten) sein. Die Zielobjekte entsprechen damit ansatzweise den "'''''Bausteinen'''''" im klassischen IT-Grundschutz. In der Modellierung werden Assets den Zielobjektkategorien zugeordnet und erben über diese ihre Anforderungen. | ||
Zielobjektkategorien bilden einen hierarchischen Kategoriebaum. Assets erben Anforderungen aus ihrer Kategorie und allen übergeordneten Kategorien bis zur Wurzel. Es sind also auch stets alle übergeordneten Zielobjektkategorien bis zur Wurzel des Kategoriebaums mit zu modellieren, um so eine lückenlose Abbildung zu gewährleisten. | |||
</onlyinclude> | </onlyinclude> | ||
Aktuelle Version vom 18. April 2026, 09:41 Uhr
Hier sind typische Begriffe aus dem Grundschutz++ definiert.
Diese Seite kann mit {{:Begriffsdefinition GS++}} in andere Artikel zum Grundschutz++ eingebunden werden.
Anforderungen
Anforderungen beschreiben, was umgesetzt werden muss, um ein bestimmtes Sicherheitsniveau zu erreichen. Sie beziehen sich auf organisatorische, personelle, technische und infrastrukturelle Aspekte der Informationssicherheit.
Wie eine Anforderung praktisch erfüllt wird, wird durch passende Maßnahmen festgelegt.
In englischen Standards wird für Anforderungen häufig der Begriff „control“ verwendet.
Im Grundschutz++ wird der Verbindlichkeitsgrad analog zum klassischen IT-Grundschutz durch das Modalverb der Anforderung festgelegt:
- MUSS → verpflichtend, keine Abweichungen zulässig.
- SOLLTE → grundsätzlich verpflichtend, Ausnahmen mit Begründung möglich.
- KANN → optional, je nach Situation sinnvoll.
Anforderungen sind in Zielobjektkategorien und ISMS-Praktiken enthalten und über diese mit spezifischen Assets (Zielobjektkategorien) oder dem ISMS übergreifend (ISMS-Praktiken) modelliert.
Assets
Assets sind alle materiellen oder immateriellen Werte einer Organisation, die für den Geschäftsbetrieb erforderlich sind. Dazu gehören z. B. Informationen/Daten, Mitarbeitende, IT-Systeme, Software, Gebäude oder Fachwissen. Sie stellen die Grundlage für die Erreichung von Organisations- oder Geschäftsziele dar.
Gleichartige und gleich behandelte Assets sollten sinnvoll zusammen gefasst (gruppiert) und als ein Asset behandet werden.
Assets entsprechen damit weitgehend den "Komponenten" im klassischen IT-Grundschutz, die dort in einer "Komponentenliste" geführt wurden.
Midestanforderungen an Atribute für Assets:
- ASSET-ID: Eindeutiges Kennzeichen des Assets (Inventrnummer)
- Asset-Name: Kurzbeschreibung (was ist das, wofür wird es genutzt?).
- Asset-Typ: z.B. Server, Anwendung, Dokument, Prozess, Dienstleistung.
- Eigentümer/Verantwortliche: Verantwortliche Person / Asset Owner (fachlich, nicht nur IT).
Assets sollten sinnvoll zusammengefasst (gruppiert) werden, um das Register überschaubar zu halten und Risikoanalysen effizient zu gestalten.
Gruppierungskriterien:
- Gleicher Typ/Klasse: z.B. alle „Vertriebs-Laptops“ statt 100 einzelne Geräte.
- Ähnlicher Schutzbedarf: gleiche CIA-Klassifizierung (Vertraulichkeit, Integrität, Verfügbarkeit).
- Gleiche Nutzung/Konfiguration: z.B. identisch konfigurierte Server, dieselben Anwendungen, gleicher Standort/Netzbindung.
- Geschäftsbezug: z.B. Assets pro Abteilung (Vertrieb, HR) oder Prozess (Rechnungsstellung).
- Risikogruppen: Assets mit denselben Bedrohungen/Schwachstellen.
Vorsicht: Nur gruppieren, wenn die auf die Assets wirkenden Risiken homogen sind – sonst riskiert ihr Sicherheitslücken.
Grupierte Assets bezeichnet man als Asset-Gruppen, die ihrerseits wie Assets behandelt werden.
Assets erben ihr Sicherheitsniveau (Schutzbedarf) aus den Geschäftsprozessen, denen sie zugeordnet sind. Anforderungen werden nicht direkt auf Assets gelegt, sondern über Zielobjektkategorien vererbt.
Blaupausen
Eine Blaupause ist eine vordefinierte Vorlage mit einer Auswahl relevanter Zielobjekte und Praktiken und zugehöriger Sicherheitsanforderungen. Sie dient als Einstiegshilfe für Organisationen, um basierend auf dem initialen Schutzbedarf (normal oder erhöht) passende Maßnahmen rasch zu identifizieren und umzusetzen, ohne eine vollständige eigene Modellierung vornehmen zu müssen.
Im Gegensatz zur traditionellen IT-Grundschutz-Methodik, die eine detaillierte Strukturanalyse und Modellierung erfordert, ermöglicht die Blaupause einen effizienten, risikoorientierten Top-down-Ansatz und kann an den Geltungsbereich angepasst werden, um den PDCA-Zyklus eines ISMS zu unterstützen.
Du kannst Blaupausen nutzen, um den Umstieg von älteren Grundschutz-Versionen zu erleichtern oder neu einzusteigen, indem Du den Schutzbedarf deines Informationsverbunds bewertest und die passende Vorlage als Ausgangspunkt wählst. Ergänzende Anpassungen erfolgen durch GAP-Analysen.
Blaupausen entsprechen damit in etwa den "Profilen" im klassischen IT-Grundschutz.
Blaupausen sind Einstiegshilfen und ersetzen keine vollständige Modellierung. Sie dienen als Startpunkt und müssen durch eine GAP‑Analyse ergänzt werden.
Geltungsbereich
Der Geltungsbereich (Scope) definiert, für welchen organisatorischen und fachlichen Bereich das Informationssicherheitsmanagementsystem (ISMS) gilt. Er legt fest, welche Standorte, Systeme, Prozesse oder Einheiten vom ISMS abgedeckt werden und welche nicht. Damit wird klar abgegrenzt, wo das ISMS anzuwenden ist.
Der Geltungsbereich ist organisatorisch definiert. Erst danach wird der technische Informationsverbund modelliert.
Gestaltungsentscheidungen
Gestaltungsentscheidungen umfassen die Festlegung institutionenspezifischer Parameter (Rollen und Werte innerhalb der Anforderungen). Sie konkretisieren das Anforderungspaket und ermöglichen automatisierte Prüfungen.
Informationssicherheitseinstufung
Im Rahmen der Priorisierung der Geschäftsprozesse ist gemäß Grundschutz++ eine Informationssicherheitseinstufung vorzunehmen. Sie ersetzt die klassische Schutzbedarfsfeststellung und erfolgt prozessbezogen.
Jeder Geschäftsprozess wird mindestens einem der beiden Einstufungsniveaus zugeordnet:
- normal – Standardniveau gemäß Stand der Technik
- hoch – erfordert zwingend eine ergänzende Risikobetrachtung
Die Einstufung bildet die Grundlage für die spätere Auswahl und Modellierung der Anforderungen im Anforderungspaket.
Die klassische Pflicht zur CIA‑Einzelbewertung entfällt, sollte aber sinvollerweise weiter genutzt werden.
Die Einstufung ist ein Pflichtschritt und bestimmt das Sicherheitsniveau aller zugehörigen Assets.
Informationssicherheitsmanagementsystem (ISMS)
Das ISMS ist ein systematischer Ansatz, um Informationssicherheit in einer Organisation zu planen, zu steuern, zu überwachen und fortlaufend zu verbessern.
Es stellt sicher, dass Sicherheitsstrategien und -maßnahmen regelmäßig auf ihre Wirksamkeit überprüft und bei Bedarf angepasst werden. Ziel ist ein dauerhaft wirksamer, ganzheitlicher Schutz von Informationen.
Das ISMS im Grundschutz++ basiert auf den ISMS‑Praktiken, die vollständig und verbindlich für den gesamten Informationsverbund gelten.
Informationsverbund
Ein Informationsverbund umfasst alle technischen, organisatorischen, personellen und infrastrukturellen Komponenten, die gemeinsam Aufgaben der Informationsverarbeitung erfüllen. Der Informationsverbund bildet die technische und inhaltliche Modellierungseinheit des ISMS und umfasst alle Assets, Zielobjektkategorien und Anforderungen.
Dies kann die gesamte Institution oder abgegrenzte Bereiche (z.B. einzelne Abteilungen oder IT-Systemgruppen) betreffen, die durch gemeinsame Prozesse oder Strukturen verbunden sind.
Maßnahmen
Maßnahmen sind konkrete Handlungen, Vorgaben oder technische Umsetzungen, die dazu dienen, erkannte Risiken zu steuern und Anforderungen zu erfüllen. Sie können organisatorischer, personeller, technischer oder infrastruktureller Art sein und sollen die Informationssicherheit (die Umsetzung der Anforderungen) wirksam sicherstellen.
Maßnahmen sind nicht Bestandteil des Grundschutz++‑Regelwerks. Sie werden von der Institution selbst definiert, um Anforderungen praktisch umzusetzen.
Parameter
Parameter sind variabel gestaltbare Elemente innerhalb einer Anforderung des Grundschutz++. Sie ermöglichen es, Anforderungen institutionenspezifisch zu konkretisieren, ohne die allgemeine Formulierung der Anforderung selbst zu verändern. Parameter sind ein zentrales Konzept des Grundschutz++, da sie sowohl Flexibilität als auch Automatisierbarkeit unterstützen.
Parameter können organisatorische, technische oder prozessuale Werte enthalten und werden im Rahmen der Anforderungsanalyse (Gestaltungsentscheidungen) festgelegt. Sie sind Bestandteil der maschinenlesbaren Grundschutz++‑Struktur (OSCAL/JSON) und ermöglichen eine präzise, prüfbare Umsetzung.
Parameter dienen dazu:
- Anforderungen an die Gegebenheiten der Institution anzupassen (z. B. Passwortlänge, Rollen, Fristen).
- Verantwortlichkeiten eindeutig festzulegen.
- Technische Werte oder Mindeststandards zu definieren.
- Automatisierte Prüfungen und Tool‑gestützte Auswertungen zu ermöglichen.
- Anforderungen konsistent und nachvollziehbar umzusetzen.
Parameter ersetzen damit die früher oft textuell beschriebenen „institutionenspezifischen Ausprägungen“ im klassischen IT‑Grundschutz.
Es lassen sich drei Haupttypen unterscheiden:
· Rollen‑Parameter Definieren, welche Rolle für eine Anforderung verantwortlich ist (z. B. ISB, Administrator, Prozess‑Owner).
· Wert‑Parameter Legen konkrete Werte fest, z. B. Mindestlängen, Fristen, Aufbewahrungszeiten oder technische Standards.
· Auswahl‑Parameter Definieren Optionen, z. B. verwendete Authentifizierungsverfahren oder Speicherorte.
Beispiel:
Anforderung: „Passwörter müssen eine Mindestlänge von <minimale_passwortlänge> Zeichen haben.“
→ Parameter: minimale_passwortlänge = 12
Die Parameter müssen von der Organisation festgelegt, dokumentiert, freigegeben und regelmäßig im Rahmen der Überwachung (Prozessschritt 4) überprüft werden.
Praktiken
Praktiken fassen Anforderungen zu thematischen Gruppen zusammen, die typischerweise bestimmten Rollen oder Prozessen zugeordnet werden. Dadurch wird klar, wer für die Umsetzung verantwortlich ist.
Es gibt drei Arten von Praktiken:
- ISMS-Praktiken (übergreifendes Management nach dem PDCA-Zyklus)
- Organisatorische Praktiken
- Technische Praktiken
Die ISMS-Praktiken bilden den Regelkreis zur laufenden Steuerung und Verbesserung der Informationssicherheit.
Praktiken ersetzen (neben den Zielobjektkategorien) die Bausteine des klassischen IT‑Grundschutzes. Sie enthalten Anforderungen und Parameter und bilden die Grundlage für die Modellierung.
Riskobetrachtung
Die Risikobetrachtung im Grundschutz++ ist eine vereinfachte, anlassbezogene Form der Risikoanalyse.
Sie wird nur durchgeführt, wenn:
- ein Geschäftsprozess als „hoch“ eingestuft wurde
- wenn MUSS‑ oder SOLLTE‑Anforderungen nicht umgesetzt werden können
- wenn zusätzliche Anforderungen ergänzt werden
Im Gegensatz zur früheren Risikoanalyse nach BSI‑Standard 200‑3 ist sie deutlich schlanker und konzentriert sich auf Risiken, die durch das Standard‑Sicherheitsniveau nicht ausreichend abgedeckt sind. Ziel ist es, Bedrohungen, Schwachstellen und mögliche Auswirkungen zu bewerten und daraus geeignete Maßnahmen oder Entscheidungen abzuleiten. Die Ergebnisse werden dokumentiert und fließen in die kontinuierliche Verbesserung des ISMS ein.
Schutzbedarf
Der Schutzbedarf zeigt, wie stark Informationen, Systeme oder Prozesse geschützt werden müssen. Er ergibt sich aus möglichen Auswirkungen auf die Grundwerte:
- Vertraulichkeit
- Integrität
- Verfügbarkeit
Im Grundschutz++ wird der Schutzbedarf im Rahmen der Informationssicherheitseinstufung festgestellt.
Je nach Bewertung wird der Schutzbedarf als „normal“ oder „hoch“ eingestuft und bestimmt das erforderliche Sicherheitsniveau sowie die Auswahl passender Anforderungen.
Der Schutzbedarf wird nicht mehr pro Asset bestimmt, sondern ergibt sich ausschließlich aus der Informationssicherheitseinstufung der Geschäftsprozesse.
Sicherheitsleitlinie
Die Sicherheitsleitlinie ist das grundlegende Dokument für Informationssicherheit in einer Organisation.
Sie beschreibt Ziele, Prinzipien und Strategien, mit denen Informationssicherheit erreicht werden soll. Sie legt fest, welche Bedeutung Informationssicherheit hat, welche Ziele verfolgt werden und wie Verantwortlichkeiten verteilt sind. Damit definiert sie das angestrebte Sicherheitsniveau.
Sicherheitsniveau
Das Sicherheitsniveau gibt an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.
Unterschieden werden:
- Normales Sicherheitsniveau: entspricht dem Stand der Technik (kurz: normal SdT)
- Erhöhtes Sicherheitsniveau: für besonders schutzbedürftige Informationen oder Systeme (kurz: erhöht)
Das Sicherheitsniveau bestimmt, ob Standard‑ oder erhöhte Anforderungen gelten und ob eine Risikobetrachtung erforderlich ist.
Stufen
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
- Stufe 0: Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
- Stufe 1: Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
- Stufe 2: Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
- Stufe 3: Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
- Stufe 4: Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
- Stufe 5: Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung:
- Welche Anforderungen sind zwingend/priorisiert zu bearbeiten (Stufe 0 - unabhängig vom Aufwand)?
- Wie hoch ist der Umsetzungsaufwand / wo gibt es "QuickWins" (Stufe 1-4)?
- Welche Anforderungen sind optional (Stufe 5 - nur bei hohem Schutzbedarf)?
und ist somit hilfreich bei der Einschätzung des Umsetzungsaufwands, der Priorisierung und hilft bei der effizienten Ressourcenplanung.
Zielobjektkategorien
Zielobjektkategorien und sind Bestandteile eines Informationsverbunds, denen spezifische Anforderungen zugeordnet sind. Das können sowohl physische Objekte (z.B. Server, Räume) als auch logische Objekte (z.B. Anwendungen, Daten) sein. Die Zielobjekte entsprechen damit ansatzweise den "Bausteinen" im klassischen IT-Grundschutz. In der Modellierung werden Assets den Zielobjektkategorien zugeordnet und erben über diese ihre Anforderungen.
Zielobjektkategorien bilden einen hierarchischen Kategoriebaum. Assets erben Anforderungen aus ihrer Kategorie und allen übergeordneten Kategorien bis zur Wurzel. Es sind also auch stets alle übergeordneten Zielobjektkategorien bis zur Wurzel des Kategoriebaums mit zu modellieren, um so eine lückenlose Abbildung zu gewährleisten.