Grundschutz++ Strukturanalyse
|
Diese Seite ist derzeit noch ein Entwurf. Weitere Informationen sowie Diskussionen über Änderungen an diesem Entwurf gibt es evtl. auf der Diskussion-Seite. |
Die Strukturanalyse nach Grundschutz++ beschreibt den organisatorischen, fachlichen und technischen Rahmen eines Informationsverbundes. Sie konsolidiert alle relevanten Informationen zu Kontext, Prozessen, Assets und Anforderungen und dient als zentrales Referenzdokument für Umsetzung, Audits und kontinuierliche Verbesserung.
Einleitung
Die Strukturanalyse nach Grundschutz++ beschreibt den organisatorischen, fachlichen und technischen Rahmen eines Informationsverbundes und bildet die Grundlage für ein systematisches ISMS nach der GS++‑Methodik. Sie verbindet die Ergebnisse aus Erhebung & Planung (Prozessschritt 1) mit der Anforderungsanalyse (Prozessschritt 2) und stellt alle relevanten Informationen zu Kontext, Stakeholdern, Geschäftsprozessen, Assets und Anforderungen strukturiert dar. Das Dokument dient als zentrales Referenzwerk für Modellierung, Umsetzung, Überwachung und kontinuierliche Verbesserung des ISMS. Es schafft Transparenz, Nachvollziehbarkeit und eine konsistente Basis für Audits, Risikoanalysen und die spätere technische Umsetzung.
Geltungsbereich
Die Organisation betreibt ihr Informationssicherheits-Managementsystem (ISMS) gemäß BSI Grundschutz++.
Die beschriebenen Regelungen sind für alle Mitarbeitenden und Dienstleistenden verbindlich, die im Rahmen des ISMS für die Organisation tätig sind.
Diese Strukturanalyse gilt für den im Titel genannten, im Folgenden beschriebenen und abgegrenzten Informationsverbund der Organisation.
Definition des Geltungsbereichs
Im Folgenden werden der Informationsverbund und seine Abgrenzung innerhalb der Organisation beschrieben.
Beschreibung des Informationsverbunds
Kurze Beschreibung des Informationsverbunds: Was zeichnet ihn aus, welchen Zweck erfüllt er, welche Anwendungen bedient er, welche Nutzergruppen bedient er ...
Eingliederung des Informationsverbunds
Es ist darzustellen, wie der Informationsverbund innerhalb der Organisation aufgebaut ist (organisationsübergreifender Verbund oder Verbund innerhalb einer Abteilung).
Abgrenzung des Informationsverbunds
Beschreibung der Grenzen des Informationsverbunds sowie der Bereiche außerhalb des Verbunds.
Beispiel:
- Entwicklungs-, Test- und Freigabesysteme: Komponenten, die ausschließlich der Entwicklung, dem Test und der Freigabe dienen, werden abgegrenzt.
- Client-Systeme der Benutzer: Alle nicht-administrativen Client-Systeme werden über einen Frontend-Server abgegrenzt.
- Netzinfrastruktur außerhalb der Organisation: Alle Netze außerhalb des Informationsverbundes (Internet, Fremdnetze, Bürokommunikationsnetze) sind über ein Security-Gateway abgegrenzt.
- Gebäudeinfrastruktur für extern betriebenes Rechenzentrum: Das Rechenzentrum des Dienstleisters, in dem der Informationsverbund betrieben wird, ist selbst nach BSI IT-Grundschutz zertifiziert. Der Schutzbedarf entspricht dem des Informationsverbundes. Damit ist der Rechenzentrumsbetrieb abgegrenzt.
- Reine Bürokommunikationssysteme wie Telefonie, Drucker, Smartphones und Tablets sind abgegrenzt.
- …
Für abgegrenzte Bereiche muss die Grenze zum Informationsverbund sowie der Übergang und dessen Absicherung beschrieben sein.
Werden elementare Bestandteile des Informationsverbunds (z.B. ein angemietetes externes Rechenzentrum) abgegrenzt, muss beschrieben sein, wie sichergestellt wird, dass diese Teile dem festgestellten Schutzbedarf des Informationsverbunds in gleichem Maße entsprechen (z.B. in Form einer eigenen Zertifizierung, vertraglicher Regelungen und eigener Audits dieser Teile).
Betrachtete Standorte
- Physische Standorte
- Remote-Arbeitsplätze
- Rechenzentren
Kontext der Organisation
Das folgende Kapitel beschreibt den Kontext der Organisation gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++.
Beschreibung der Organisation
Beschreibung der Organisation und ihrer Ziele.
Rechtliche Rahmenbedingungen
Kurze Darstellung der wesentlichen rechtlichen Rahmenbedingungen der Organisation (Konkretisierung im Kapitel Compliance).
Geschäftsfeld
Beschreibung des Tätigkeitsbereichs der Organisation (Was macht die Organisation wo ist ihr Kerngeschäft?)
Organisationsplan
Darstellung des Geschäftsverteilungsplans der Organisation (Organigramm)
Managementrahmen des ISMS
Ziele, IS-Leitlinien, IS-Strategie, Verantwortlichkeiten, Dokumentationsprinzipien, KVP.
Layer- und Werkzeugkonzept
Eingesetzte GS++-Layer (Basis, Technik, Beispiel, Audit) und verwendete Tools.
Interessierte Parteien (PS 1)
Das folgende Kapitel beschreibt die Interessierten Parteien gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++.
Identifizierte interessierte Parteien
Ein ISMS muss nicht nur auf Vorschriften reagieren, sondern auch auf die Erwartungen derjenigen, die von Informationssicherheit betroffen sind oder ein berechtigtes Interesse daran haben.
Liste der identifizierten interessierten Parteien:
| Interessierte Partei | Typ | Rolle / Beschreibung | Erwartungen an Informationssicherheit | Relevanz | Verbindliche Verpflichtung | Konsequenz für ISMS | Rechtsgrundlage / Quelle | Betroffene Prozesse | Verantwortliche Rolle |
|---|---|---|---|---|---|---|---|---|---|
| Wer ist die Partei? | intern/extern | Warum ist sie relevant? | Was erwartet sie konkret? | Einfluss auf ISMS | Ja/Nein | Welche Anforderungen entstehen? | Gesetz, Vertrag, Richtlinie | Welche Prozesse sind betroffen? | Wer kümmert sich? |
| Beispiele: | |||||||||
| Datenschutz-Aufsichtsbehörde | extern | Regulatorische Überwachung | DSGVO‑Konformität, Nachweise, Meldepflichten | hoch | Ja | Datenschutzanforderungen, TOMs, Meldeprozesse | DSGVO, BDSG | Datenverarbeitung, HR, IT‑Betrieb | Datenschutzbeauftragte |
| Kunden / Auftraggeber | extern | Empfänger von Dienstleistungen | Verfügbarkeit, Integrität, SLA‑Einhaltung | mittel | Ja | SLA‑Monitoring, Incident‑Reporting | Vertrag, SLA | Service‑Prozesse, Support | Service Owner |
| Mitarbeitende | intern | Nutzung von Systemen, Verarbeitung von Daten | Klare Regeln, sichere Systeme, Schulungen | mittel | Ja | Awareness‑Programm, Zugriffsregeln | Arbeitsvertrag, interne Richtlinien | Alle operativen Prozesse | ISB / HR |
| ... |
Erwartungen und Anforderungen
Erwartungen an Verfügbarkeit, Vertraulichkeit, Integrität, Nachweise, Reaktionszeiten.
Bewertung der Relevanz
Priorisierung gemäß GS++.
Verbindliche Verpflichtungen
Welche Erwartungen werden ins ISMS übernommen.
Compliance-Rahmen (PS 1)
Das folgende Kapitel beschreibt den Compliance-Rahmen der Organisation gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++. Dabei unterscheiden wir:
Gesetzliche Verpflichtungen:
DSGVO, HGB, branchenspezifische Vorgaben.
Mögliche rechtliche, regulatorische Rahmenbedingungen sind im Artikel Rechtsgrundlagen aufgelistet.
Vertragliche Verpflichtungen:
SLAs, NDAs, Kundenanforderungen.
Interne Vorgaben:
Richtlinien, Policies, Betriebsvereinbarungen. Liste der rechlichen, vertraglichen und internen Vorgaben:
| Quelle | Referenz | Betroffener Bereich | Relevanz für ISMS / IV |
|---|---|---|---|
| Gesetz | DSGVO (EU‑Datenschutz‑Grundverordnung, z.B. Art. 5, 25, 32) | Verarbeitung personenbezogener Daten in Fachverfahren, Portalen, Logs | Vorgibt Schutzziele und technische/organisatorische Maßnahmen für Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit; fließt in Schutzbedarf, Praktiken (z.B. Berechtigungsmanagement, Logging) und ergänzende Anforderungen ein. |
| Vertrag | Auftragsverarbeitungsvertrag (AVV) nach DSGVO Art. 28 | Outsourcing von IT‑Betrieb, Cloud‑Dienste | Definiert technische und organisatorische Maßnahmen, Audit‑ und Informationsrechte; Anforderungen sind als externe Verpflichtungen in das Anforderungspaket zu übernehmen. |
| Vertrag | Service Level Agreement (SLA) mit Verfügbarkeitszielen | Betrieb von Fachanwendungen, Rechenzentrum | Erhöht Anforderungen an Verfügbarkeit und Wiederanlauf; kann zu höherem Schutzbedarf und strengeren Maßnahmen in den Praktiken (Backup, Notfallmanagement) führen. |
| Intern | Informationssicherheitsleitlinie | gesamte Institution | Setzt interne Mindestanforderungen (z.B. „alle sicherheitsrelevanten Änderungen sind zu dokumentieren“); bildet Grundlage für ISMS‑Anforderungen (Governance, Rollen, Dokumentation). |
| ... | ... | ... | ... |
Sicherheitsorganisation (PS 1)
Das folgende Kapitel beschreibt den den Aufbau der Sicherheitsorganisation im ISMS der Organisation gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++.
Rollen und Verantwortlichkeiten
In der Organisation sind folgende Verantwortliche als Teil der Sicherheitsorganisation benannt:
Organisationsleitung
Die Leitung der Organisation trägt die Gesamtverantwortung für die Informationssicherheit der Organisation und hat klare Ziele für die Informationssicherheit definiert. Diese Leitlinien bilden die Grundlage für alle Maßnahmen im Informationsverbund. Die übergreifenden Aufgaben der Leitung bestehen im Wesentlichen darin:
- Festlegung von messbaren Sicherheitszielen
- Verantwortlichkeiten zu delegieren
- Ressourcen bereitzustellen
- Sicherheitskultur in der Organisation zu fördern
- Bewertung der Risiken für die Organisation
- Compliance und Rechenschaftspflicht erfüllen
- Überwachung und Bewertung der Zielerreichung
Informationssicherheitsbeauftragter
Die Organisation hat einen Informationssicherheitsbeauftragten (ISB) ernannt.
Der Informationssicherheitsbeauftragte ist für den Aufbau und die Koordination des ISMS verantwortlich und untersteht als Stabsstelle direkt der Organisationsleitung.
Seine Aufgaben sind u.a.:
- Berichterstattung und Beratung der Leitung zu Belangen der Informationssicherheit
- Koordination der Schulungen und Sensibilisierung der Mitarbeitenden zur Informationssicherheit
- Entwicklung und Fortschreibung der Sicherheitskonzeption der Organisation
- Begleitung und Auswertung von Sicherheitsvorfällen
- Begleitung der Einführung neuer Verfahren und Anwendungen
Der ISB verfügt über die zur Erfüllung seiner Aufgaben notwendigen Kenntnisse und Ressourcen.
Datenschutzbeauftragter
Die Organisation hat einen Datenschutzbeauftragten (DSB) bestellt. Der DSB ist in die Entwicklung des Informationsverbundes eingebunden und bearbeitet alle Fragen des Datenschutzes in einem eigenen DSMS.
weitere Verantwortliche
Ggf. weitere Verantwortlich und ihre Rollen für die Informationssicherheit im Informationsverbund z.B:
- Fach- und Verfahrensverantwortliche
- Leitung IT-Betrieb / Rechenzentrum
- Notffallbeauftragter
- ...
Entscheidungswege
Freigaben, Eskalationen, Reporting.
Kommunikationswege
Wie wird Informationssicherheit in der Organisation kommuniziert.
Dokumentation und Ablage des ISMS
Dokumentationsform, Ablageorte, Versionierung, Zugriffsregelungen.
Vorgehensweise zur Anwendung von GS++ und Freigabe
Die Organisation betreibt ihr Informationssicherheits-Managementsystem (ISMS) gemäß BSI Grundschutz++.
Beschreibung des Vorgehensmodells, Iterationslogik, Freigabe durch die Leitung.
Informationssicherheitseinstufung (PS 1)
Das folgende Kapitel beschreibt die Informationssicherheitseinstufung der relevanten Geschäftsprozesse der Organisation gemäß Prozessschritt 1 Erhebung und Planung (Governance/Compliance) der Methodik zum Grundschutz++.
Identifizierte Geschäftsprozesse
Ein Geschäftsprozess ist eine systematische Abfolge von Aktivitäten, um ein bestimmtes Geschäftsziel zu erreichen. Die relevanten Geschäftsprozesse des Informationsverbunds sind im folgenden aufgeführt.
Kernprozesse
Kernprozesse sind die zentralen Prozesse der Organisation, die direkt zur Wertschöpfung beitragen und damit essentiell für das Kerngeschäft sind. Sie stellen die Haupttätigkeiten dar, die die Organisation ausführen muss, um seine Produkte oder Dienstleistungen zu erstellen oder bereitzustellen.
| Kürzel | Prozessname | Beschreibung | Verantwortlich |
|---|---|---|---|
| KP-1 | Beispiel | Beispiel | Beispiel |
| KP-2 | Beispiel | Beispiel | Beispiel |
Hilfsprozesse
Hilfsprozesse, oder auch Supportprozesse genannt, sind Prozesse, die nicht direkt zur Wertschöpfung beitragen, sondern die Organisation in seiner Tätigkeit unterstützen und optimieren sollen. Sie stellen damit eine indirekte Unterstützung des Kerngeschäfts dar.
| Kürzel | Prozessname | Beschreibung | Verantwortlich |
|---|---|---|---|
| HP-1 | Beispiel | Beispiel | Beispiel |
Kritikalität / Sicherheitsniveau
Eine angemessene Bestimmung des Sicherheitsniveaus ist wichtig, um die Ressourcen der Organisation effektiv zu nutzen und sicherzustellen, dass die Schutzmaßnahmen den Bedrohungen und Risiken angemessen sind. Das folgende Sicherheitsniveau wurde im Rahmen einer Informationssicherheitseinstufung (siehe Anlage A2) für die genannten Geschäftsprozesse ermittelt:
| Prozess | Vertraulichkeit | Integrität | Verfügbarkeit | Gesamt |
|---|---|---|---|---|
| KP-1 | normal | normal | normal | normal |
| KP-2 | hoch | normal | normal | hoch |
| HP-1 | normal | normal | hoch | hoch |
Priorisierung
Aufgrund eines hohen Sichereitsniveaus, werden die Prozesse KP-2 und HP-1 priorisiert behandelt.
Überprüfung des gesetzten Sicherheitsniveaus
Verfahren und Kriterien zur regelmäßigen Überprüfung der Angemessenheit.
7. Informationsverbund (PS 2)
7.1 Definition des Informationsverbunds
Fachliche und organisatorische Einheit.
7.2 Eingliederung in die Organisation
Einbettung in die Gesamtorganisation.
7.3 Abhängigkeiten
Interne und externe Abhängigkeiten.
8. Geschäftsprozesse (PS 2)
8.1 Kernprozesse
Beschreibung, Ziele, Abhängigkeiten.
8.2 Unterstützungsprozesse
IT-Betrieb, HR, Einkauf etc.
8.3 Schutzbedarf / Sicherheitsniveau
Ergebnis der Einstufung.
9. Asset-Modellierung (PS 2)
9.1 Erfasste Assets
Informationen, Anwendungen, Systeme, Räume, Rollen, Dienste.
9.2 Zuordnung zu Zielobjektkategorien
Gemäß GS++ Abschnitt 3.4.2.
9.3 Vererbung von Zielobjektkategorien
Gemäß GS++ Abschnitt 3.5.1.
9.4 Assets ohne Anforderungen
Identifikation anforderungsloser Assets und Begründung.
10. Anforderungen (PS 2)
10.1 Ableitung aus Praktiken
Welche Praktiken sind relevant.
10.2 Zuordnung zu Zielobjekten
Welche Anforderungen gelten für welche Assets.
10.3 Konsolidierung
Redundanzprüfung, Zusammenführung.
10.4 Ergänzende Anforderungen
- Aufgrund anforderungsloser Assets
- Aufgrund externer Verpflichtungen
10.5 Gestaltungsentscheidungen (Parameter)
Gestaltungsentscheidungen konkretisieren die generischen GS++-Anforderungen für die Institution. Sie legen fest, wie Anforderungen organisatorisch, technisch und prozessual umgesetzt werden sollen. Dazu gehören Rollen, Werte, Fristen, Verfahren und technische Parameter, die für Umsetzung, Überwachung und Auditierbarkeit notwendig sind. Die folgenden Parameter stellen die institutionenspezifischen Festlegungen dar, die im Rahmen der Anforderungsanalyse getroffen wurden.
| Parameter | Beschreibung | Zugehörige Anforderung(en) | Verantwortliche Rolle | Wert / Entscheidung |
|---|---|---|---|---|
| Passwortlänge | Mindestanforderung an Authentisierung | PRA-XXX | IT-Betrieb | 14 Zeichen |
| Backup-Frequenz | Intervall für Datensicherungen | OPS-ZZZ | IT-Betrieb | täglich, 02:00 Uhr |
| Löschfristen | Aufbewahrungs- und Löschregeln | DSGVO, LOG-ABC | Datenschutz | 6 Monate |
| Logging-Level | Umfang der Protokollierung | MON-123 | IT-Security | „Security-relevant“ |
| Rollenmodell | Verantwortlichkeiten im ISMS | GOV-001 | ISB | ISB, IT-Leitung, Prozessowner |
10.6 Verteilung der führenden Zuständigkeiten
Zuordnung führender Verantwortlichkeiten zu Praktiken, Zielobjektkategorien und wesentlichen Anforderungen.
10.7 Wirksamkeitsprüfung der Anforderungen
Verfahren, Kriterien und Dokumentation zur Prüfung der Wirksamkeit.
11. Risikomanagement und Risikobetrachtung (PS 2)
11.1 Risikomanagement-Rahmen
Bewertungsmethode, Risikokriterien, Risikokategorien, Rollen, Umgang mit Restrisiken.
11.2 Identifizierte Risiken
Risiken aus Anforderungen, Prozessen, Assets.
11.3 Bewertung
Eintrittswahrscheinlichkeit, Auswirkung.
11.4 Risikobehandlung
Akzeptieren, reduzieren, vermeiden, übertragen.
12. Infrastruktur (optional)
12.1 Netzplan
Übersicht der Netzsegmente.
12.2 Komponentenlisten
Server, Clients, Netzwerkgeräte.
12.3 Technische Räume
Rechenzentren, Serverräume.
13. Dienstleister / Zulieferer
13.1 Externe Dienstleister
Cloud, Hosting, Support.
13.2 Sicherheitsrelevante Abhängigkeiten
Welche Anforderungen gelten.
14. Schnittstellen zu anderen Managementsystemen
14.1 Datenschutz-Management
Abstimmung mit Datenschutzanforderungen und -prozessen.
14.2 Business Continuity / Notfallmanagement
Schnittstellen zu BCM/Notfallkonzepten.
14.3 Qualitätsmanagement und IT-Service-Management
Abhängigkeiten und gemeinsame Prozesse.
14.4 Audit- und Compliance-Management
Verzahnung mit internen und externen Audits sowie Compliance-Prozessen.
15. Anlagen
- Organigramm
- Prozesslandkarte
- Asset-Listen
- Zielobjektkategorien
- Anforderungspaket
- Risikoanalyse-Matrix
