BSI/200-3/Vorarbeiten: Unterschied zwischen den Versionen
K Textersetzung - „BSI//“ durch „BSI/“ |
K Textersetzung - „[[Grundschutz“ durch „[[IT-Grundschutz“ |
||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 9: | Zeile 9: | ||
* Beispielsweise müssen geeignete Rollen und Aufgaben definiert werden. | * Beispielsweise müssen geeignete Rollen und Aufgaben definiert werden. | ||
|- | |- | ||
| [[Grundschutz/Geltungsbereich]] || Geltungsbereich für die Sicherheitskonzeption muss definiert worden sein. | | [[IT-Grundschutz/Geltungsbereich]] || Geltungsbereich für die Sicherheitskonzeption muss definiert worden sein. | ||
* Dieser Geltungsbereich wird im Folgenden als Informationsverbund bezeichnet. | * Dieser Geltungsbereich wird im Folgenden als Informationsverbund bezeichnet. | ||
|- | |- | ||
Zeile 52: | Zeile 52: | ||
Zu den Vorarbeiten gehört auch, dass die Grundvoraussetzungen für die Risikoanalyse von der Institutionsleitung vorgegeben werden. | Zu den Vorarbeiten gehört auch, dass die Grundvoraussetzungen für die Risikoanalyse von der Institutionsleitung vorgegeben werden. | ||
=== Richtlinie zum Umgang mit Risiken === | |||
Hierzu muss die Leitungsebene eine Richtlinie zum Umgang mit Risiken verabschieden. Diese sollte unter anderem folgende Aspekte umfassen: | Hierzu muss die Leitungsebene eine Richtlinie zum Umgang mit Risiken verabschieden. Diese sollte unter anderem folgende Aspekte umfassen: | ||
* Unter welchen Voraussetzungen muss in jedem Fall eine Risikoanalyse durchgeführt werden? | * Unter welchen Voraussetzungen muss in jedem Fall eine Risikoanalyse durchgeführt werden? |
Aktuelle Version vom 31. Oktober 2024, 13:37 Uhr
Vorarbeiten zur Risikoanalyse
BSI-Standard 200-2
Arbeitsschitt | Beschreibung |
---|---|
Informationssicherheitsprozess | Systematischer Informationssicherheitsprozess muss initiiert worden sein.
|
IT-Grundschutz/Geltungsbereich | Geltungsbereich für die Sicherheitskonzeption muss definiert worden sein.
|
Strukturanalyse | Für den Informationsverbund sollte eine Strukturanalyse gemäß Kapitel 8.1 der IT-Grundschutz-Methodik durchgeführt worden sein.
|
Schutzbedarfsfeststellung | Anschließend sollte eine Schutzbedarfsfeststellung gemäß Kapitel 8.2 der IT-Grundschutz-Methodik durchgeführt worden sein.
|
Modellierung | Es sollte eine Modellierung gemäß Kapitel 8.3 der IT-Grundschutz-Methodik und Kapitel 2 des IT-Grundschutz/Kompendiums durchgeführt worden sein.
|
IT-Grundschutz-Check | Es sollte vor der Risikoanalyse ein IT-Grundschutz-Check gemäß Kapitel 8.4 der IT-Grundschutz-Methodik durchgeführt werden.
|
- Ergebnis
Liste der Zielobjekte, für die eine Risikoanalyse durchgeführt werden sollte („betrachtete Zielobjekte“)
Priorisierung
- Viele Zielobjekte
Falls trotz Gruppenbildung viele Zielobjekte einer Risikoanalyse unterzogen werden müssen, sollte eine geeignete Priorisierung vorgenommen werden:
- Falls für den IT-Grundschutz die Vorgehensweise „Standard-Absicherung“ gewählt wurde, sollten vorrangig die übergeordneten Zielobjekte bearbeitet werden (insbesondere Geschäftsprozesse, Teilverbünde und gesamter Informationsverbund).
- Aus diesen Arbeiten ergeben sich oft wertvolle Anhaltspunkte für die Risikoanalysen der untergeordneten technischen Zielobjekte.
- Falls für den IT-Grundschutz die Vorgehensweise „Kern-Absicherung“ gewählt wurde, sollten vorrangig die Zielobjekte mit dem höchsten Schutzbedarf bearbeitet werden.
- Falls für den IT-Grundschutz die Vorgehensweise „Basis-Absicherung“ gewählt wurde, werden zunächst keine Risikoanalysen durchgeführt, sondern es werden als Erstes nur die Basis-Anforderungen umgesetzt.
- Abweichende Vorgehensweisen
Von der beschriebenen Vorgehensweise kann abgewichen werden
- Unter Umständen bietet es sich an, eine Risikoanalyse erst nach Erfüllung der IT-Grundschutz-Anforderungen durchzuführen.
- Dies kann beispielsweise bei Zielobjekten sinnvoll sein, die bereits im Einsatz sind und die hinreichend durch IT-Grundschutz-Bausteine dargestellt werden können.
- Als Entscheidungshilfe dazu, nach welchem Schritt eine Risikoanalyse sinnvoll ist, findet sich eine Zusammenstellung der Vor- und Nachteile der möglichen Zeitpunkte in Kapitel 8.5 der IT-Grundschutz-Methodik im BSI-Standard 200-2.
- Risikoanalyse auf Geschäftsprozessebene
- Bei den betrachteten Zielobjekten muss es sich nicht zwangsläufig um systemorientierte Zielobjekte (z. B. Anwendungen, IT-Systeme oder -Räume) handeln.
- Vielmehr kann die Risikoanalyse auch auf Geschäftsprozessebene durchgeführt werden.
Voraussetzungen
Zu den Vorarbeiten gehört auch, dass die Grundvoraussetzungen für die Risikoanalyse von der Institutionsleitung vorgegeben werden.
Richtlinie zum Umgang mit Risiken
Hierzu muss die Leitungsebene eine Richtlinie zum Umgang mit Risiken verabschieden. Diese sollte unter anderem folgende Aspekte umfassen:
- Unter welchen Voraussetzungen muss in jedem Fall eine Risikoanalyse durchgeführt werden?
- Welche Methodik beziehungsweise welcher Standard wird dazu eingesetzt, um die Risiken zu identifizieren, einzuschätzen, zu bewerten und zu behandeln?
- Wie wird die gewählte Methodik auf die speziellen Belange der Institution angepasst?
- Was sind die Risikoakzeptanzkriterien?
- Welche Organisationseinheiten sind für welche Teilaufgaben der Risikoanalyse verantwortlich? Sind Risiken den jeweiligen Risikoeigentümern zugeordnet?
- Auf welche Weise werden Risikoanalysen in den Sicherheitsprozess integriert, geschieht dies beispielsweise vor oder nach Umsetzung der IT-Grundschutz-Anforderungen?
- Welche Berichtspflichten bestehen im Rahmen von Risikoanalysen?
- In welchem Zeitrahmen muss die Risikoanalyse vollständig aktualisiert werden?
- Risikoakzeptanzkriterien
- Da die Risikoakzeptanzkriterien einer Institution in entscheidendem Maße von deren Risikoneigung (Risikoappetit) abhängen, kann es sinnvoll sein, auch die Risikoneigung (siehe Kapitel 9) in der Richtlinie zu beschreiben.
- Möglicherweise ist sich eine Institution ihrer eigenen Risikoneigung nicht bewusst oder hat ungenaue Vorstellungen von diesem Begriff. In diesem Fall sollte die Leitungsebene eine Klärung und Entscheidung herbeiführen, gegebenenfalls sollte die Institution hierfür auf externe Experten zurückgreifen.
- Richtlinie zur Risikoanalyse
- Die in der Richtlinie zur Risikoanalyse beschriebenen Vorgaben der Leitungsebene müssen konsequent umgesetzt werden, wenn Risiken bewertet und behandelt werden.
- Zweifelsfälle können auftreten, beispielsweise wenn es bei einem bestimmten Risiko nicht sinnvoll erscheint, die festgelegte Risikoneigung anzuwenden.
- Solche Ausnahmefälle sollten abgestimmt und dokumentiert werden.
Die Richtlinie zur Risikoanalyse sollte gemäß den Vorgaben des Informationssicherheitsmanagementsystems (siehe BSI-Standard 200-2 IT-Grundschutz Methodik [BSI2]) erstellt werden.
- Sie muss in regelmäßigen Abständen oder anlassbezogen auf ihre Aktualität hin überprüft und gegebenenfalls orientiert an den Zielen der Institution angepasst werden.
- Insbesondere sollte auch die eingesetzte Vorgehensweise zur Risikoanalyse regelmäßig überprüft werden.
- Die Richtlinie zur Risikoanalyse muss durch die Institutionsleitung freigegeben werden.
Zielobjekte
- Voraussetzung für die Durchführung von Risikoanalysen im Rahmen der Standard-Absicherung
bei der Strukturanalyse die Zielobjekte des Informationsverbundes
- zusammengestellt sind
- deren Schutzbedarf festgestellt ist und
- ihnen bei der Modellierung soweit möglich passende Grundschutz-Bausteine zugeordnet wurden.
- Risikoanalyse für Zielobjekte
- Hoher oder sehr hoher Schutzbedarf
- In einem der drei Grundwerte (Vertraulichkeit, Integrität, Verfügbarkeit)
- Für die es keinen passenden Grundschutz-Baustein gibt
- Die in Einsatzszenarien betrieben werden, die für den Grundschutz untypisch sind.
- Priorisierung
Bei einer großen Zahl an Zielobjekten, die eines diese Kriterien erfüllen, sollten Sie eine geeignete Priorisierung vornehmen.
- Bei der Vorgehensweise Standard-Absicherung bietet es sich an, zunächst übergeordnete Zielobjekte zu betrachten, etwa den gesamten Informationsverbund, bestimmte Teile des Informationsverbundes oder wichtige Geschäftsprozesse.
- Bei der Kern-Absicherung sollten Sie vorrangig diejenigen Zielobjekte mit dem höchsten Schutzbedarf untersuchen.
Betrachteten Zielobjekte
Beispiel
- Bei der RECPLAST wurde aufgrund der Schutzbedarfsfeststellung und der Modellierung eine Reihe von Zielobjekten ermittelt, für die eine Risikoanalyse durchzuführen ist.
- Dazu gehören unter anderem die folgenden Komponenten
- die Anwendung A002 Lotus Notes, die einen hohen Bedarf an Vertraulichkeit und einen sehr hohen Bedarf an Verfügbarkeit hat,
- die Netzkopplungselemente N001 Router Internet-Anbindung und N002 Firewall Internet-Eingang, beide wegen der Vertraulichkeit der über sie übertragenen Daten,
- der Virtualisierungsserver S007, der in allen drei Grundwerten aufgrund der auf ihm betriebenen virtuellen Systeme einen hohen Schutzbedarf hat,
- die Alarmanlagen S200 an beiden Standorten in Bonn, deren korrektes Funktionieren als sehr wichtig eingestuft und deren Schutzbedarf bezüglich Integrität und Verfügbarkeit folglich mit „sehr hoch“ bewertet wurde.
Nachfolgend werden die einzelnen Schritte der Risikoanalyse am Beispiel des über beide Standorte hinweg redundant ausgelegten Virtualisierungsservers S007 veranschaulicht.
Richtlinie
- Richtlinie zum Umgang mit Risiken
Bevor Sie mit der Durchführung von Risikoanalysen beginnen, sollte die Leitung Ihrer Institution grundlegende Aspekte hierfür in einer Richtlinie zum Umgang mit Risiken festlegen:
- Unter welchen Voraussetzungen ist eine Risikoanalyse erforderlich?
- Mit welchem Verfahren werden Risiken identifiziert, eingeschätzt, bewertet und behandelt und wie ist dieses Verfahren an die Gegebenheiten der Institution angepasst und in den Sicherheitsprozess integriert?
- Welche Organisationseinheiten sind für die verschiedenen Teilaufgaben des Risikomanagements zuständig?
- Wie sind die Berichtspflichten geregelt?
- Welche Kriterien müssen erfüllt sein, damit Risiken akzeptiert werden?
- In welchen zeitlichen Intervallen und bei welchen Ereignissen müssen Risikoanalysen aktualisiert werden?
Diese Richtlinie und die zugehörigen organisatorischen Umsetzungen sollten regelmäßig auf ihre Aktualität und Angemessenheit geprüft werden.
Anhang
Siehe auch
Links
Projekt
Weblinks
Beispiele
Beispiel 1
Im Folgenden wird anhand einer fiktiven Institution, der RECPLAST GmbH, beispielhaft dargestellt, wie Risiken eingeschätzt, bewertet und behandelt werden können.
- Zu beachten ist, dass die Struktur der RECPLAST GmbH im Hinblick auf Informationssicherheit keineswegs optimal ist.
Sie dient lediglich dazu, die Vorgehensweise bei der Durchführung von Risikoanalysen zu illustrieren. Die RECPLAST GmbH ist eine fiktive Institution mit ca. 500 Mitarbeitern, von denen 130 an Bildschirmarbeitsplätzen arbeiten.
- Räumlich ist die RECPLAST GmbH aufgeteilt in zwei Standorte innerhalb Bonns, wo unter anderem die administrativen und produzierenden Aufgaben wahrgenommen werden, und drei Vertriebsstandorte in Deutschland.
Das IT-Netz ist in mehrere Teilbereiche aufgeteilt.
- Für die Beispiele in dieser Risikoanalyse wird das Teilnetz A (vergleiche Abbildung 2 in Kapitel 4) näher betrachtet.
- Der Zugang zum Teilnetz A ist durch die Firewall N1 abgesichert.
- Die Server S1 (Virtualisierungsserver) und S5 werden durch einzelne Switches angebunden.
Der Virtualisierungsserver S1 stellt verschiedene Dienste zur Verfügung, z. B. werden dort in virtuellen Maschinen File- und E-Mail-Server betrieben.
- Diese Anwendungen haben teilweise einen hohen Schutzbedarf in mindestens einem der drei Grundwerte Vertraulichkeit, Integrität oder Verfügbarkeit.
- Durch das Maximumprinzip gilt für den Virtualisierungsserver S1 der höchste Schutzbedarf der zur Verfügung gestellten virtuellen Maschinen bzw. IT-Anwendungen.
- Um die Stunden der Mitarbeiter zu erfassen, verwendet die RECPLAST GmbH eine Softwarelösung, die als Webanwendung implementiert ist.
- Für die Datenhaltung nutzt diese eine Datenbank, die im
Datenbankmanagementsystem (A1) auf dem Server S5 betrieben wird.
Darüber hinaus betreibt die RECPLAST GmbH eine Reihe von Servern, die dazu eingesetzt wer den, alle IT-Systeme und darauf betriebenen Anwendungen kontinuierlich zu überwachen.
Beispiel 2
Das fiktive Unternehmen MUSTERENERGIE GmbH betreibt eine Smart Meter Gateway Infrastruktur (intelligentes Netz).
- Kernbausteine einer solchen Infrastruktur sind intelligente Messsysteme, auch „Smart Metering Systems“ genannt.
- Das Smart Meter Gateway (SMGW) stellt dabei die zentrale Kommunikationseinheit dar.
- Es kommuniziert im lokalen Bereich beim Endkunden mit den elektronischen Zählern (Local Metrological Network, LMN-Bereich), mit Geräten aus dem Home Area Network (HAN-Bereich) und im Wide Area Network (WAN-Bereich) mit autorisierten Marktteilnehmern.
- Außerdem ermöglicht das SMGW die Verbindungsaufnahme von lokalen Geräten des HAN über das WAN mit autorisierten Marktteilnehmern.
Für die Installation, Inbetriebnahme, den Betrieb, die Wartung und Konfiguration des SMGW ist der Smart-Meter-Gateway-Administrator (SMGW-Admin) verantwortlich.
- Da es sich hierbei teilweise um sensible Informationen handelt, ist der Schutz dieser Informationen wichtig.
- Daher muss sichergestellt sein, dass der IT-Betrieb beim SMGW-Admin sicher erfolgt.
- Für die Beispiele in dieser Risikoanalyse wird neben Teilnetz A der RECPLAST GmbH auch die Smart-Meter-Gateway-Administration der MUSTERENERGIE GmbH näher betrachtet.