LF-Grundschutzcheck
Der Leitfaden für BSI IT-Grundschutzchecks (GSC) beschreibt den Prozess zur Überprüfung der Umsetzung von Sicherheitsanforderungen gemäß den BSI-Standards. Er umfasst die Anwendung der Bausteine des IT-Grundschutz-Kompendiums, die Dokumentation der Umsetzung, und die Bewertung des Umsetzungsstatus. Ziel ist es, eine einheitliche Qualität der Grundschutzchecks zu gewährleisten und den aktuellen Stand der Informationssicherheit in einer Organisation nachvollziehbar zu dokumentieren.
Einleitung
Die BSI IT-Grundschutzchecks basieren auf dem IT-Grundschutz-Kompendium. und sind im BSI Standard 200-2: IT-Grundschutz-Methodik beschrieben.
Die BSI IT-Grundschutzchecks helfen Unternehmen und Organisationen dabei, ihre IT-Sicherheit zu verbessern und Risiken zu minimieren. Durch regelmäßige (jährliche) Durchführung dieser Checks und der Dokumentation der Sicherheitsmaßnahmen verschaffen die Grundschutzchecks einen Überblick über den Stand der Informationssicherheit in der Organisation.
Zielsetzung
Ein Grundschutzcheck (GSC) ist ein Abgleich der Anforderungen aus den Bausteinen des Grundschutz-Kompendium mit den tatsächlich umgesetzten Maßnahmen zur Erfüllung dieser Anforderungen auf den betriebenen Komponenten oder der gesamten Organisation.
Ziel dieses Dokuments ist es, in der Organisation eine einheitliche Qualität der Grundschutzchecks (GSC’s) und eine nachvollziehbare und auditierbare Dokumentation des Umsetzungsstandes zu gewährleisten.
Geltungsbereich
Dieser Leitfaden gilt für das Sicherheitsmanagement der Organisation und für die Durchführung aller Grudschutzchecks in der Organisation.
Durchführung von GSC‘s
Grundschutzchecks sollten in der Organisation nach folgenden Empfehlungen durchgeführt werden:
Anwendung der Bausteine
Die Bausteine des Grundschutz Kompendiums haben alle eine einheitliche Struktur.
In Kapitel 1 Beschreibung findet ihr eine einleitende Beschreibung des Bausteins und der Prozesse bzw. Komponenten die der Baustein behandelt.
Kapitel 1.3 Abgrenzung und Modellierung beschreibt den Geltungsbereichs des Bausteins und wann er (nicht) anzuwenden ist.
In Kapitel 2 Gefährdungslage werden die betrachteten Gefährdungen beschrieben. Auch hier sollte kurz geprüft werden, ob die vom BSI im Baustein berücksichtigten Gefährdungen für den eigenen Geltungsbereich zutreffend und ausreichend sind.
Der entscheidende Teil für den GSC ist jedoch das Kapitel 3 Anforderungen.
in der Einleitung sind die Zuständigkeiten beschrieben und die jeweiligen Rollen in der Organisation die üblicherweise Interviewpartner für die GSC's sind.
Darauf folgt die Beschreibung der eigentlichen Anforderungen unterteilt in
- 3.1 Basis-Anforderungen: Basis-Anforderungen entsprechen den Mindestanforderungen für einen ordnungsgemäßen IT-Betrieb und müssen grundsätzlich umgesetzt werden. Sie sind auch nach Möglichkeit prioritär vor anderen Anforderungen Umzusetzen.
- 3.2 Standard-Anforderungen: Standard Anforderungen sind zusammen mit den Basis-Anforderungen, die Anforderungen die für eine Umsetzung bei normalem Schutzbedarf und für eine mögliche Zertifizierung erforderlich sind.
- 3.3 Anforderungen bei erhöhtem Schutzbedarf: Diese Anforderungen sind optional bei erhöhtem Schutzbedarf zu erfüllen. Im Rahmen einer Risikoanalyse wird festgestellt, welche dieser Anforderungen bei erhöhtem Schutzbedarf zusätzlich erfüllt werden müssen.
Zusätzlich kann es zu den Bausteinen auch Umsetzungshinweise geben, die konkrete Handlungsempfehlungen zur Umsetzung der Anforderungen geben. Umsetzungshinweise sind nicht verpflichtend umzusetzen, sie stellen eine optionale Arbeitshilfe dar, sie können als Maßnahmen zur Umsetzung der Anforderungen genutzt werden, es können aber auch andere/eigene Maßnahmen umgesetzt werden, die die Anforderungen erfüllen.
Es ist zu berücksichtigen, dass durch eine vorangegangene Gruppierung von Komponenten, häufig eine Vielzahl ähnlicher aber nicht immer völlig gleicher Komponenten zusammengefasst wurden.
Beim GSC ist darauf zu achten, dass alle betroffenen Komponenten eine Gruppierung und deren unterschiedliche Ausprägung zu berücksichtigen sind! Ggf. ist auf eine geringfügig abweichende Umsetzung einzelner Komponenten im GSC und der Umsetzungserläuterung zu den Anforderungen hinzuweisen.
Werden im Laufe des GSC’s größere Abweichungen von einzelnen Komponenten festgestellt, ist die Gruppierung ggf. anzupassen.
Verwendete Modalverben (MUSS SOLLTE)
Die meisten Anforderungen bestehen aus einzelnen Teil-Anforderungen, die jeweils an einem MUSS oder SOLLTE im Text zu erkennen sind.
MUSS Teil-Anforderungen müssen erfüllt werden. Diese können nur in Ausnahmefällen entbehrlich sein, wenn diese Teil-Anforderung im Informationsverbund nicht zutreffend ist. Die Entbehlichkeit muss nachvollziehbar begründet sein.
SOLLTE Teil-Anforderungen müssen grundsätzlich auch erfüllt werden, hier kann aber ggf. eine Entbehrlichkeit oder eine Nichtumsetzung möglich sein, wenn die Umsetzung nicht möglich oder nicht sinnvoll ist oder die Kosten der Umsetzung den Nutzen übersteigt. Entbehrlichkeit oder Nichtumsetzung müssen hinreichend begründet werden.
Im Falle einer Nichtunsetzung muss das daraus resultierende Risiko bewertet und durch alternative Maßnahmen behandelt oder von der Organisationsleitung explizit (schriftlich dokumentiert) getragen werden.
Dokumentation der Durchführung
Die Durchführung der GSC erfolgt i.d.R. durch einen Mitarbeiter des Sicherheitsmanagements (ggf. auch Auditor / Innenrevision) als Befrager und (mindestens) einen zum jeweiligen Baustein aussagekräftigen Mitarbeiter des Fachbereichs (Administrator) als Befragter.
Die Durchführung des GSC ist je Baustein mit dem Datum (Erfasst am:) und den Namen der Beteiligten (Erfasst durch: / Befragter:) im Deckblatt des Bausteins zu dokumentieren.
In den Erläuterungen zum Baustein können Besonderheiten wie spezifische Einsatzszenarien beschrieben werden, die sich auf die Anwendbarkeit des Bausteins oder einzelner Anforderungen auswirken können.
Erläuterung der Umsetzung der Anforderungen
Zu jeder Anforderung ist die adäquate Umsetzung aller (Teil-)Anforderungen bzw. deren nicht Umsetzung oder nicht Anwendbarkeit zu dokumentieren.
Für die Dokumentation sollten folgende Grundsätze berücksichtigt werden:
- Die Dokumentation sollte in kurzen, sachlichen und verständlichen Sätzen ohne persönliche Wertung oder überflüssige Prosa erfolgen.
- Alle Teil-Anforderungen (Jedes MUSS und SOLLTE) der Anforderung sollten sich in der Erläuterung wiederfinden.
- Die Erläuterung zur Umsetzung einer Anforderung sollte in wenigen Sätzen je Anforderung knapp beschrieben werden. Für Detailinformationen kann auf weiterführende Dokumente (Richtlinien, Konzepte, Betriebshandbücher) verwiesen werden.
- Es ist stets die tatsächliche IST-Umsetzung zu beschreiben (kein sollte, müsste, könnte). Eine wiederholte Beschreibung der Anforderungen ist nicht sinnvoll.
- Betriebliche Details (IP-Adressen, Logins, Passworte, Konfigurationsparameter) gehören nicht in die Erläuterung, hierzu sollte auf die jeweilige Betriebsdokumentation verwiesen werden.
- Die Entbehrlichkeit einer Anforderung ist schlüssig zu begründen.
- Bei teilweiser Umsetzung sollten die offenen (Teil-)Anforderungen am Anfang der Erläuterung als „offen:“ oder "todo:" kurz beschrieben werden. Die Umsetzung der offenen Teile muss geplant werden („Umsetzung bis:“ und „Umsetzung durch:“ ausfüllen).
- Bei teilweiser oder vollständiger Nichtumsetzung einer Maßnahme, sind die nicht umzusetzenden Anforderungen zu benennen und die Nichtumsetzung ist zu begründen (parallel Aufnahme in den Risikobehandlungsplan).
Dokumentation des Umsetzungsstatus
Für jede Anforderung muss der Umsetzungsstatus dokumentiert werden. Der Status hat immer einen der folgenden fünf Status:
| Ja | Alle Aspekte der Anforderung sind vollständig und wirksam umgesetzt, oder es gibt geeignete alternative Umsetzungen, die das Schutzziel gleichermaßen erreichen. |
|---|---|
| Teilweise | Es gibt einzelne Aspekte der Anforderung, die nicht oder nicht vollständig umgesetzt sind. Für die nicht oder nicht vollständig umgesetzten Aspekte sind die offenen Punkte klar zu beschreiben. Die fehlenden Aspekte der Umsetzung müssen entweder mit einem Zieltermin geplant werden oder die Nichtumsetzung muss begründet werden. Im Falle einer Nichtumsetzung, sind die offenen Punkte im Risikobehandlungsplan aufzunehmen. |
| Nein | Die Anforderung ist nicht oder zum überwiegenden Teil nicht umgesetzt. Die Umsetzung der Anforderung muss mit einem Zieltermin geplant werden oder die Nichtumsetzung ist zu begründen. Die Anforderung ist im Risikobehandlungsplan aufzunehmen. |
| Entbehlich | Die Anforderung ist für die betrachteten Komponenten oder den jeweiligen Anwendungsfall nicht einschlägig/anwendbar, z.B. weil der Dienst/die Funktion nicht genutzt wird oder die Schutzziele der Maßnahme werden durch alternative Maßnahmen an anderer Stelle erfüllt. Die Nichtanwendbarkeit oder alternative Umsetzung ist zu beschreiben. |
| Unbearbeitet | Die Anforderung ist noch nicht bearbeitet. |
Die Abbildung beschreibt den Entscheidungsbaum für die Feststellung des Umsetzungsstatus.
Voraussetzungen für eine Testierbarkeit / Zertifizierbarkeit
BASIS Anforderungen müssen grundsätzlich vollständig umgesetzt sein. Eine im Einzelfall gegebene Entbehrlichkeit muss nachvollziehbar und hinreichend begründet sein.
STANDARD Anforderungen sollten grundsätzlich umgesetzt sein. Teilweise Umsetzung oder Nichtumsetzung ist mit Umsetzungsplanung oder einer Risikoanalyse zu behandeln.
Anforderungen für erhöhten Schutzbedarf müssen bearbeitet werden, wenn diese im Rahmen einer Risikoanalyse zum Einsatz kommen. Anderenfalls sind sie entbehrlich.
