BSI/200-3/Vorarbeiten: Unterschied zwischen den Versionen

Aus Foxwiki
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 Sicherheitskon­zeption muss definiert worden sein.  
| [[IT-Grundschutz/Geltungsbereich]] || Geltungsbereich für die Sicherheitskon­zeption 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 Insti­tutionsleitung vorgegeben werden.
Zu den Vorarbeiten gehört auch, dass die Grundvoraussetzungen für die Risikoanalyse von der Insti­tutionsleitung vorgegeben werden.


; Richtlinie zum Umgang mit Risiken
=== 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.
  • Aktivitäten im Bereich der Informationssicherheit strukturiert steuern und abarbeiten.
  • Beispielsweise müssen geeignete Rollen und Aufgaben definiert werden.
IT-Grundschutz/Geltungsbereich Geltungsbereich für die Sicherheitskon­zeption muss definiert worden sein.
  • Dieser Geltungsbereich wird im Folgenden als Informationsverbund bezeichnet.
Strukturanalyse Für den Informationsverbund sollte eine Strukturanalyse gemäß Kapitel 8.1 der IT-Grund­schutz-Methodik durchgeführt worden sein.
  • Dadurch werden die wichtigsten Informationen über den Informationsverbund ermittelt, z. B. Geschäftsprozesse, der Netzplan sowie eine Liste der wichtigsten Anwendungen mit Abhängigkeit von den IT-Systemen.
Schutzbedarfsfeststellung Anschließend sollte eine Schutzbedarfsfeststellung gemäß Kapitel 8.2 der IT-Grundschutz-Metho­dik durchgeführt worden sein.
  • Als Ergebnis liegen der Schutzbedarf der Geschäftsprozesse, An­wendungen, IT-Systeme, genutzten Räume sowie eine Liste der kritischen Kommunikationsverbin­dungen vor.
  • Der Schutzbedarf bezieht sich jeweils auf die Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit und wird nach IT-Grundschutz normalerweise in den Stufen normal, hoch und sehr hoch festgelegt.
Modellierung Es sollte eine Modellierung gemäß Kapitel 8.3 der IT-Grundschutz-Methodik und Kapitel 2 des IT-Grundschutz/Kompendiums durchgeführt worden sein.
  • Dabei wird für jedes Zielobjekt im Infor­mationsverbund festgelegt, ob es passende IT-Grundschutz-Bausteine gibt und wie diese anzu­wenden sind.
  • Die in den einzelnen Bausteinen genannten Sicherheitsanforderungen und die dar­aus abgeleiteten Sicherheitsmaßnahmen bilden die Basis für das IT-Grundschutz-Sicherheitskon­zept des betrachteten Informationsverbundes.
IT-Grundschutz-Check Es sollte vor der Risikoanalyse ein IT-Grundschutz-Check gemäß Kapitel 8.4 der IT-Grund­schutz-Methodik durchgeführt werden.
  • Dadurch wird festgestellt, welche Basis- und Standard-Si­cherheitsanforderungen für den vorliegenden Informationsverbund bereits erfüllt sind und wo noch Defizite bestehen.
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-Anforde­rungen 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 wel­chem 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 Zielob­jekte (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 Insti­tutionsleitung 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 bei­spielsweise 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 Richt­linie zu beschreiben.
  • Möglicherweise ist sich eine Institution ihrer eigenen Risikoneigung nicht be­wusst 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 konse­quent 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 re­gelmäß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 darge­stellt, 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 illustrie­ren. Die RECPLAST GmbH ist eine fiktive Institution mit ca. 500 Mitarbeitern, von denen 130 an Bild­schirmarbeitsplätzen arbeiten.

  • Räumlich ist die RECPLAST GmbH aufgeteilt in zwei Standorte in­nerhalb Bonns, wo unter anderem die administrativen und produzierenden Aufgaben wahrge­nommen 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 vir­tuellen 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 Infrastruk­tur (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 Ge­rä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 teil­weise 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.