Vorwort

Ich schreibe diesen Artikel, weil es immer noch eine verbreitete Ansicht ist, dass es irgendwie nur eine einzige Art der Steuerung von Informationssicherheitsaspekten gibt, wie sie im Anhang A der ISO 270001, NIST CSF, CSA, SOC2 usw. definiert wird. Diese Herangehensweise ist meiner Ansicht nach nicht die beste Art das Thema Informationssicherheit zu etablieren. Denn Sicherheitsanforderungen und deren Umsetzungsmaßnahmen können auf allen Ebenen angesiedelt sein beispielsweise auf einer sehr hohen Ebene mit der Anforderung "Implementierung und Betrieb eines ISMS" oder auf einer sehr niedrigen Ebene "Ein Wachmann geht fünfmal am Tag um das Gebäude herum“.

Aus meiner Sicht hat das BSI mit den Standards 200-1, 200-2 und 200-3 sowie den jährlich aktualisierten BSI IT-Grundschutz Kompendien die Möglichkeiten geschaffen, dass selbst die Geschäftsführung eines KMU die Herausforderung komplexe Themen durch praxisnahe Sicherheitsmaßnahmen beim Aufbau eines Informationssicherheitsmanagementsystems meistern kann. Warum aus meiner Sicht der BSI IT-Grundschutz auch oder gerade deswegen optimal zu einem KMU passt, habe ich aus der originalen Darstellung seitens des BSI hier nochmal hervorgehoben. Insofern vertiefende Informationen gewünscht sind, empfehle ich diese beiden Links 1 und 2

Die BSI-Standards und das IT-Grundschutz-Kompendium bilden die Hauptwerke im IT-Grundschutz. Die BSI-Standards 200-1 bis 200-3 erläutern, wie ein ISMS in einer Institution aufgebaut werden kann und Geschäftsprozesse bzw. Fachaufgaben abgesichert werden können. Im IT-Grundschutz-Kompendium beschreiben Fachtexte, die sogenannten IT-Grundschutz-Bausteine, was ein Anwender tun muss, um einen bestimmten Bereich besser abzusichern. In Kombination angewandt, bilden diese beiden Komponenten des IT-Grundschutzes die Grundlage für eine solide Informationssicherheit.

Die rund 100 IT-Grundschutz-Bausteine erläutern neben technischen Aspekten auch solche, die Infrastruktur, Organisation und Personal betreffen. Anwender können sich gezielt die IT- Grundschutz-Bausteine heraussuchen, die für ihre aktuellen Sicherheitsfragen relevant sind.

Die BSI IT-Grundschutz Standards 200-1, 200-2, 200-3 umfassen auch das Management von Risiken und der Standard 200-4 integriert ebenfalls das Notfallmanagement. Der wichtigste Aspekt bei der Anwendung des BSI IT-Grundschutzes ist jedoch, dieser ist ISO/IEC 27001- bzw. ISO/IEC 22301 kompatibel.

In den nachfolgend aufgezeigten Schritten bei der Anwendung des BSI IT-Grundschutzes fokussiere ich stets auf kleine und mittlere Unternehmen (KMU). Für ein einheitliches Verständnis, möchte ich am Anfang dieses Artikels kurz die Definition für ein KMU aufzeigen. Kleinstunternehmen, kleine und mittlere Unternehmen (KMU) werden in der EU-Empfehlung 2003/361 definiert. Danach zählt ein Unternehmen zu den KMU, wenn es nicht mehr als 249 Beschäftigte hat und einen Jahresumsatz von höchstens 50 Millionen € erwirtschaftet oder eine Bilanzsumme von maximal 43 Millionen € aufweist.

Mein Wunsch wäre, wenn ich am Ende dieses Artikels das an sich sehr komplexe Thema einwenig entzerren und anschaulicher darstellen konnte.

Schritt 1 - Übernahme der Gesamtverantwortung

Stellen Sie sich vor, Sie sind der Geschäftsführer eines aufstrebenden KMUs und sind ein Dienstleister (SaaS) für einen großen nationale Kunden. Die SaaS Lösung von Ihnen ist ein essentieller Bestandteil des Kunden bei der vollständigen Digitalisierung der Workflows. Im Rahmen des Abschlusses einer Cybersecurity Versicherung und eines Kurzaudit durch den Kunden werden die beiden hier aufgeführten Beispiele erkannt und aufgezeigt.

• Es besteht das Risiko, dass die Informationen der Institution und des Kunden nicht ausreichend gegen Manipulationen und gegen einem Ransomware-Angriff abgesichert sind.
• Im Vertrag mit dem Kunden wurde der Betrieb eines ISMS vereinbart. Dieses konnte jedoch zum Zeitpunkt der Auditierung durch den Kunden nicht dargestellt werden.

Welchen Schritt sollte die Geschäftsführung idealerweise initiieren, um die aufgezeigten Unternehmensrisiken mit einer gezielten Maßnahme zu begegnen? Insofern diese beiden Unternehmensrisiken so leicht identifizierbar waren, schlummern bestimmt noch ein paar weitere. Daher wäre der wahrscheinlich erste Schritt seitens der Geschäftsführung der folgende. Durch die Geschäftsführung wird die Einstellung eines erfahrenen und kompetenten Informationssicherheitsbeauftragten eingeleitet und aktiv unterstützt.

Schritt 2 - Abstimmen der Absicherungsmethodik

Stellen Sie sich nun vor, dass Sie als Informationssicherheitsbeauftragter des KMU eingestellt worden sind. Durch die Geschäftsführung wurde die Bewertung und Empfehlung zur Behandlung jetzt an Sie weiterdelegiert. Somit bleibt noch immer die Frage offen, wie wäre das weitere Vorgehen, um die aufgezeigten Risiken zu bewältigen. Da gibt es viele Dinge, aber ein guter Anfang da sie als Informationssicherheitsbeauftragter in einem KMU arbeiten wäre. Die Implementierung eines ISMS und in diesem Beispiel auf Basis des BSI IT-Grundschutzes. Jetzt kommt schon die nächste wichtige und grundsätzliche Frage. Denn der IT-Grundschutz vom BSI bietet drei verschiedene Vorgehensweisen (Basis-, Standard- und Kern-Absicherung) an. Die Vorgehensweisen richten sich in erster Linie an die unterschiedlichen Anwend­ergruppen und deren Ziele. Wie unterscheiden sich die drei Vorgehensweisen von einander?

• Bei der Basis-Absicherung handelt es sich um eine grundlegende Absicherung der Geschäftsprozesse und Ressourcen einer Institution. Diese Vorgehensweise ermöglicht einen ersten Einstieg in den Sicherheitsprozess, um schnellstmöglich die größten Risiken zu senken. Im nächsten Schritt können die tatsächlichen Sicher­heitsanforderungen im Detail analysiert werden. Diese Vorgehensweise ist daher besonders für kleinere Institutionen geeignet, die noch am Anfang ihres Sicherheitsprozesses stehen.
• Die Kern-Absicherung dient als weitere Vorgehensweise um einen möglichst einfachen Einstieg zum Schutz der essenziellen Ge­schäftsprozesse und Ressourcen einer Institution aufzuzeigen. Diese Vorgehensweise unterscheidet sich vom klas­sischen BSI IT-Grundschutz durch die Fokussierung auf einen kleinen, aber sehr wichtigen Teil eines Informationsverbunds, die sogenannten „Kronjuwelen“. Die Kern-Absicherung ist vor allem für Institutio­nen geeignet, die einige wenige Geschäftsprozesse identifiziert haben, die wesentlich für den Fortbestand der Institution sind und vorrangig abgesichert werden müssen.
• Mit der Standard-Absicherung kann eine Institution umfassend und tief gehend abgesichert werden. Dies sollte grundsätzlich das Ziel jeglicher Anwendung des IT-Grundschutzes sein. Ein direkter Einstieg in den Sicherheitsprozess mit der Standard-Absicherung ist empfehlenswert, wenn für die Institution die folgenden Punkte überwiegend zutreffen:
  • Die Institution arbeitet bereits mit dem IT-Grundschutz.
  • Es wurden schon Sicherheitskonzepte nach IT-Grundschutz oder ISO 27001 erstellt.
  • Die Umsetzung von Informationssicherheit hat in der Institution bereits einen ausreichenden Rei­fegrad erreicht, sodass in wesentlichen Bereichen bereits Sicherheitsmaßnahmen vorhanden sind und keine grundlegende Erst-Absicherung mehr notwendig ist.
  • Es besteht kein Handlungsbedarf, einzelne Geschäftsprozesse vordringlich abzusichern, die ein deutlich höheres Gefährdungspotenzial bezüglich der Informationssicherheit besitzen.
  • Die Institution hat wenige Assets, deren Diebstahl, Zerstörung oder Kompromittierung einen unmittelbar existenzbedrohenden Schaden nach sich ziehen könnte und die daher vorrangig abgesichert werden sollten.
  • Sicherheitsvorfälle, die wahrnehmbar die Aufgabenerfüllung beeinträchtigen, Geld kosten oder anderweitig erkennbaren Schaden verursachen, sind für die Institution nicht akzeptabel, auch wenn sie noch keinen existenzbedrohenden Schaden verursachen.

Als Informationssicherheitsbeauftragter des KMU würde ich mich für die Methodik der Kernabsicherung auf Basis der aktuellen Informationslage entscheiden und diese zusammen mit der Geschäftsführung in die Leitlinie zur Informationssicherheit aufnehmen.

Schritt 3 - Übersicht der Bausteine des BSI

Stellen Sie sich als Informationssicherheitsbeauftragter nun vor, was alles auf Grund der aufgezeigten Risiken alles schief gehen könnte und bewerten was zu tun ist, um dies zu bewältigen (darum geht es eigentlich bei der Erstellung eines Sicherheitskonzeptes mit der inkludierten Risikoanalyse). Das BSI unterstützt bei der Beurteilung des Grades der technischen und organisatorischen Umsetzung der Anforderungen an die Informationssicherheit mit den jährlich aktualisierten Versionen des BSI IT-Grundschutz Kompendiums. Die im Kompendium aufgeführten Bausteine können generell in prozessuale und technische Bausteine unterschieden werden. Die prozessualen Bausteine haben fast alle eine Gemeinsamkeit, sie müssen nur einmal übergreifend auf den Verbund bezogen angewandt werden. Hingegen die technisch orientierten Bausteine pro zu betrachtenden Zielobjekt oder Gruppe von Zielobjekten. Die nachfolgenden Abbildungen listen die Bausteine pro Schicht noch einmal gruppiert nach Prozessual oder Technisch auf.

Als Informationssicherheitsbeauftragter eines KMU ist man schnell erschlagen von der Fülle der zu erfüllenden Anforderungen aus den Bausteinen. Aber auch hier hilft das BSI mit einer Priorisierung, welche Bausteine mit welcher Dringlichkeit implementiert werden sollten. Um grundlegende Risiken abzudecken und eine ganzheitliche Informationssicherheit aufzubauen, müssen die essenziellen Sicherheitsanforderungen frühzeitig erfüllt und entsprechende Sicherheits­maßnahmen umgesetzt werden. Daher sind die Bausteine danach gekennzeichnet, ob sie vor- oder nachrangig umgesetzt werden sollten.

• R1: Das BSI empfiehlt diese Bausteine vorrangig umzusetzen, da sie die Grundlage für einen effektiven Sicherheitsprozess bilden.
• R2: Als nächstes empfiehlt das BSI alle Bausteine mit der Kennzeichnung R2 umzusetzen, da sie in wesentlichen Teilen des In­formationsverbunds (festgelegte Geltungsbereich) für nachhaltige Sicherheit erforderlich sind.
• R3: Alle Bausteine mit der Kennzeichnung R3 werden zur Erreichung des angestrebten Sicherheitsniveaus ebenfalls benötigt und müssen umgesetzt werden, es wird aber vom BSI empfohlen, diese erst nach den anderen Bausteinen zu betrachten.

In den vorherigen Abbildungen wurden bereits die Bausteine und deren Zuordnung pro Schicht dargestellt. Diese Informationen angereichert um die Priorität der Baustein-Implementierung im Sicherheitsprozesses ermöglicht den neuen Informationssicherheitsbeauftragten eine Roadmap für die Einführung von thematischen Sicherheitsrichtlinien zu skizzieren.

In den vorherigen Abbildungen wurden bereits die Bausteine und deren Zuordnung pro Schicht dargestellt. Diese Informationen angereichert um die Priorität der Baustein-Implementierung im Sicherheitsprozesses ermöglicht dem Informationssicherheitsbeauftragten eine Roadmap für die Einführung von thematisch relevanten Sicherheitsrichtlinien zu skizzieren.

Eine kleine Zusammenfassung bevor es mit Schritt 4 weitergeht. Die Geschäftsführung hat einen internen Informationssicherheitsbeauftragten eingestellt und bestellt (dies ist ganz wichtig für später). Der Informationssicherheitsbeauftragte hat zusammen mit der Geschäftsführung sich für die Etablierung eines ISMS auf Basis des BSI IT-Grundschutzes und der Methodik der Kernabsicherung entschieden. Dies bedeutet die grundlegenden Eckpfeiler sind abgestimmt jetzt startet mit Schritt 4 die erfolgreiche Reise.

Schritt 4 - Festlegung des Geltungsbereichs

Der BSI IT-Grundschutz ermöglicht einen ganzheitlichen Schutz aller geschäftsrelevanten Informatio­nen einer Institution. Für ein KMU, welches erst am Anfang der Etablierung der Informati­onssicherheit steht, ist es zielführender, sich anfangs auf die Absicherung der essenziellen As­sets zu beschränken und erst nachfolgend im Rahmen der kontinuierlichen Verbesserung eine stetige Vergrößerung des Geltungsbereiches umzusetzen. Dieser Abschnitt zeigt auf welche Teilschritte notwendig sind, wenn als Vorgehensweise Kern-Absicherung von der Geschäftsführung und dem Informationssicherheitsbeauftragten ausgewählt wurde. Beim weiteren Vorgehen ist von besonderer Wichtigkeit, die Vorgehensweise Kern-Absicherung konzentriert sich auf den Schutz von besonders schützenswerten Assets. Hier wird auch gerne von den „Kronjuwelen“ gesprochen. Bei der Anwendung der Kern-Absicherung erfolgt somit ein Soll-Ist-Vergleich (IT-GrundschutzCheck) zwischen den im BSI IT-Grundschutz-Kompendium definierten Anforderungen und den bereits in der KMU erfüllten Anforderungen für die Absicherung dieser Kronju­welen. Dabei nicht oder nur unzureichend erfüllte Anforderungen zeigen die Sicherheitsdefizite auf, die es durch entsprechende Maßnahmen in mit den Verantwortlichen zuvor abgestimmten Zeitintervallen zu beheben gilt. Da sich die Kern-Absicherung auf die besonders schützenswerten Assets des KMU konzentriert, empfiehlt es sich hier grunds­ätzlich von einem erhöhten Schutzbedarf auszugehen. Daher müssen die in den als relevant gekennzeichneten Baustei­nen des BSI IT-Grundschutz-Kompendiums aufgeführten Basis- und Standard-Anforderungen komplett umgesetzt werden. Darauf aufbauend muss bei erhöhtem Schutzbedarf eine Risikoanalyse unter Be­rücksichtigung von Kosten- und Wirksamkeitsaspekten durchgeführt werden, damit die relevanten Risiken im Bereich der Kronjuwelen ganzheitlich behandelt werden können.

Die Erstellung einer Sicherheitsbetrachtung (Sicherheitskonzeption) glie­dert sich grob in folgende Bereiche:

• Festlegung des Geltungsbereichs für die Kern-Absicherung
• Identifikation und Festlegung der kritischen Assets (Kronjuwelen)
• Strukturanalyse
• Schutzbedarfsfeststellung
• Modellierung: Auswahl und Anpassung von Anforderungen
• IT-Grundschutz-Check
• Risikoanalyse und weiterführende Sicherheitsmaßnahmen
• Umsetzung und weitere Schritte

Zunächst muss daher der Geltungsbereich festgelegt werden, für den das Sicherheitskonzeption erstellt und umgesetzt werden soll. Der Geltungsbereich umfasst unter anderem alle (Teil-)Geschäftsprozesse, Anwendungen, IT-Systeme, Infrastrukturen, die für die Bearbeitung der besonders kritischen Geschäftsprozesse und Informationen benötigt werden. Bei der Kern-Absicherung ist es besonders wichtig, den Informationsverbund nicht nur klar abzugren­zen, sondern ihn auch möglichst klein zu halten.

Als Kronjuwelen werden diejenigen Geschäftsprozesse und Informationen innerhalb des KMU bezeichnet, die am wichtigsten für den Erhalt der Geschäftsfähigkeit sind. Zu den kritischen Assets gehören üblicherweise:

• Informationen, die wesentlich zur erfolgreichen Durchführung von essenziellen Geschäftsprozes­sen sind.
• Informationen und Geschäftsprozesse, die ein deutlich erhöhtes Gefährdungspotenzial bezüglich der Informationssicherheit innehaben. Dies betrifft insbesondere die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit.
• Informationen und Geschäftsprozesse, deren Diebstahl, Zerstörung, Kompromittierung oder Be­einträchtigung einen existenzbedrohenden Schaden für das KMU bedeuten und die vorrangig geschützt werden sollten.
• Die Menge der Informationen und Geschäftsprozesse mit deutlich erhöhtem Schutzbedarf ist über­ schaubar bzw. umfasst nur einen kleinen Anteil aller Geschäftsprozesse. Nur wenige Assets ragen in ihrer Bedeutung für die Fachaufgaben bzw. Geschäftstätigkeit deutlich aus der Masse heraus und können einen großen Schaden verursachen.
• Es sind alle elementaren Gefährdungen des IT-Grundschutz-Kompendiums relevant, häufig liegt ein besonderer Fokus auf den Angreifern. Darüber dürfen aber Ursachen wie Umwelteinflüsse oder menschliche Fehlhandlungen nicht vergessen werden.

Schritt 5 - Strukturanalyse

Für die Erstellung eines Sicherheitskonzepts ist es erforderlich, das Zusammenspiel der Geschäftsprozesse, der Anwendun­gen und der vorliegenden Informationstechnik zu analysieren und zu dokumentieren. Die Strukturanalyse liefert wichtige Grunddaten für den gesamten Sicherheitsprozess des KMU. Der Informati­onsverbund setzt sich normalerweise aus vielen Assets zusammen. Wenn alle logischen und technischen Assets einzeln erfasst werden, besteht jedoch die Gefahr, dass die Ergebnisse der Strukturanalyse aufgrund der Datenmenge und der Kom­plexität nicht mehr handhabbar sind. Ähnliche Assets sollten deshalb sinnvoll zu Gruppen (Betrachtungsgruppen - Zielobjektgruppen) zusammenge­fasst werden.

Bei technischen Assets bringt eine konsequente Gruppenbildung zudem den Vorteil, dass die Administration wesentlich vereinfacht wird, wenn es nur wenige Grundkonfigurationen gibt. Häufig wird dies auch mit der Bildung von Buildingblocks bei der Erstellung von Architekturen adressiert. Durch eine möglichst hohe Standardisierung wird außerdem die Zahl potenzieller Sicherheitslücken reduziert und die Sicherheitsmaßnahmen können ohne Unterscheidung verschiedenster Schwachstellen umgesetzt werden. Dies kommt nicht nur der Informationssicherheit zugute, sondern spart auch mittel und langfristig Betriebskosten (Return in Investment bzw. Return on Security Investment).

Unter welchen Aspekten bietet sich eine Gruppierung von Assets zu einer Zielobjektgruppen an? Assets können dann ein und derselben Zielobjektgruppe zugeordnet werden, wenn diese

• vom gleichen Typ sind,
• ähnliche Aufgaben haben,
• ähnlichen Rahmenbedingungen unterliegen,
• den gleichen Schutzbedarf aufweisen,
• ähnlich konfiguriert sind,
• ähnlich in das Netz eingebunden sind (z. B. im gleichen Netzsegment bzw. Mikrosegement),
• ähnlichen administrativen und infrastrukturellen Rahmenbedingungen unterliegen sowie
• ähnliche Anwendungen bedienen.

Um das ganze bisher beschriebene Vorgehen ein bisschen mehr in das praktische zu überführen, bietet es sich an die Informationen der Strukturanalyse wie in den nachfolgenden Tabellen aufgezeigt zu organisieren.

Geschäftsprozesse

Durch die Fokussierung auf die Methodik der Kern-Absicherung dürften die meisten der benannten Geschäftsprozesse eher komplexer Art sein. Bei komplexen Geschäftsprozessen in Kombination mit hohen oder sehr hohen Schutzbedarf empfiehlt es sich, diese in Teilprozesse zu zerlegen. Denn, wenn der Bereich mit einer späteren Zuordnung von einem hohen oder sehr hohen Schutzbedarf auf wenige Teilprozesse eingegrenzt werden kann, hat das den Vorteil, dass sich der hohe bzw. sehr hohe Schutzbedarf auf wenige Zielobjekte der Sicherheitsbetrachtung vererbt und eine Risikoanalyse auf Prozessebene sich auch ebenfalls vom Umfang her vereinfachen dürfte. Insofern eine Reduzierung der Komplexität durch Bildung von Teilprozessen vorgenommen wird, empfiehlt es sich dies übergreifend für das KMU abzustimmen. Denn die Ergebnisse aus der späteren Schutzbedarfsfeststellung für die Prozesse mit dem Schutzziel Verfügbarkeit können im Idealfall 1:1 für die Bussines Impact Analyse (BIA) nachgenutzt werden.

Anwendungen

IT-System

Industrielle IT

Netze und Kommunikation

In der nachfolgenden Tabelle werden die Kommunikationsverbindungen, eingesetzten Protokolle sowie etwaige Authentisierungsverfahren benannt.

Räume und Gebäude

Schritt 6 - Schutzbedarfsfeststellung

Zweck der Schutzbedarfsfeststellung ist es, zusammen mit den Prozess- und Fachverantwortlichen zu ermitteln, welcher Schutz für die Geschäftsprozesse und deren verarbeiteten Informationen ausreichend und an­ gemessen ist. Hierzu werden für jede Anwendung und die verarbeiteten Informationen die zu erwar­tenden Schäden betrachtet, die bei einer Beeinträchtigung der Schutzziele Vertraulichkeit, Integrität oder Ver­fügbarkeit entstehen könnten.

Da der Schutzbedarf durch alle Beteiligten (Informationssicherheitsbeauftragter, Prozessverantwortlicher, Fachverantwortlicher) meist nicht quantifizierbar ist, beschränkt sich der BSI IT-Grundschutz somit auf eine qualitative Aussage, indem der Schutzbedarf in drei Kategorien (normal, hoch und sehr hoch) unterteilt wird.

Die nachfolgenden Schritte erläutern, wie für Geschäftsprozesse und die mit diesen verbundenen Prozesse bzw. Anwendungen jeweils die adäquate Schutzbedarfskategorie ermittelt werden kann. Die Schäden, die beim Verlust der Vertraulichkeit, Integrität oder Verfügbarkeit für einen Ge­schäftsprozess bzw. eine Anwendung einschließlich ihrer Daten entstehen können, lassen sich typi­scherweise den folgenden Schadensszenarien zuordnen:

• Verstoß gegen Gesetze/Vorschriften/Verträge,
• Beeinträchtigung des informationellen Selbstbestimmungsrechts,
• Beeinträchtigung der persönlichen Unversehrtheit,
• Beeinträchtigung der Aufgabenerfüllung,
• negative Innen- oder Außenwirkung und
• finanzielle Auswirkungen.

Für eine spätere Bewertung des derzeitigen Sicherheitsniveaus ist es wichtig seitens aller Beteiligten die möglichen Folgeschäden realistisch ein­ zu schätzen. Im allgemeinen wird der Informationssicherheitsbeauftragte­ auf Grund der Kern-Absicherung von einem Schutzbedarf der Kategorien „hoch“ eventuell „sehr hoch“ für mindestens eines der Schutzziele Verfügbarkeit, Vertraulichkeit und Integrität auszugehen. Als Hilfestellung für die dedizierte Einschätzung des benötigten Schutzbedarfes für die Schutzziele Verfügbarkeit, Vertraulichkeit und Integrität kann die drei nachfolgenden Tabellen herangezogen werden.

Schutzziel - Verfügbarkeit

Schutzziel - Vertraulichkeit

Schutzziel - Integrität

Schutzbedarfserhebung und deren Vererbung

Als Informationssicherheitsbeauftragter sind sie stets aufgefordert ihre Aktivitäten für Dritte nachvollziehbar zu dokumentieren. Für die spätere Anwendung der Schutzbedarfsvererbung durch den Informationssicherheitsbeauftragten habe ich hier noch einmal kurz die drei möglichen Arten der Vererbung aufgeführt.

Maximumprinzip - Um den Schutzbedarf von einem Objekt zu bewerten, müssen alle Teilobjekte betrachtet werden. Bei IT-Systemen wären das dann beispielsweise die möglichen Folgen, die Schäden für darauf betriebene Anwendungen und den damit verarbeiteten Informationen haben. Hier bestimmt der Schaden bzw. die Summe der Schäden den endgültigen Schutzbedarf des Objekts.

Kumulationseffekt - Wenn beispielsweise auf einem IT-System mehrere Anwendungen laufen, ist es wichtig zu überprüfen, ob durch die Kumulation von mehreren kleinen Schäden auf einem IT-System ein insgesamt höherer Gesamtschaden zu erwarten wäre. Sollte dies der Fall sein, würde sich der Schutzbedarf des IT-Systems erhöhen.

Verteilungseffekt - Andersherum ist dies genauso möglich. So kann es sein, dass eine hoch bewertete Anwendung ihren Schutzbedarf nicht auf das betrachtete IT-System überträgt. Das liegt dann beispielsweise daran, dass auf diesem IT-System nur die unwesentlichen Teilbereiche der Anwendung laufen. Daher ist der Schutzbedarf in diesem Fall zu relativieren. Achtung: Vergessen Sie bei der Betrachtung nicht die Abhängigkeiten von Anwendungen in Ihre Bewertung mit einzubeziehen! Wenn beispielsweise eine für sich betrachtete Anwendung einen normalen Schutzbedarf aufweist, aber ihre Ergebnisse wichtig für den Ablauf von einer weiteren sehr hoch bewerteten Anwendung sind, so erhöht sich natürlich auch der Schutzbedarf der ersten.

Schutzbedarfserhebung für die Prozesse

Bei komplexen Geschäftsprozessen, insbesondere wenn diese hohen oder sehr hohen Schutzbedarf haben, kann es sinnvoll sein, diese in Teilprozesse zu zerlegen. Wenn dabei der Bereich mit einem hohen oder sehr hohen Schutzbedarf auf wenige Teilprozesse eingegrenzt werden kann, hat das den Vorteil, dass sich der hohe bzw. sehr hohe Schutzbedarf auf wenige Objekte vererbt.

Als Informationssicherheitsbeauftragter würde ich mich bei der initialen Erstellung eines Sicherheitskonzeptes auf Basis der Kern-Absicherung für die Erhebung und Vererbung des Schutzbedarfes nach dem Maximalprinzip entscheiden.

Prozess P-0001

Prozess P-000n

Zusammenfassung der Schutzbedarfserhebung für die Prozesse

Die nachfolgende Tabelle ermöglicht es gerade bei vielen Prozessen noch einmal die ermittelten Werte losgelöst von den Begründungen zusammen zu fassen. Insofern bereits in der Strukturanalyse die entsprechenden Verknüpfungspunkte mit dokumentiert wurden, kann diese Tabelle bei der späteren Vererbung des Schutzbedarfes auf die Anwendungen nachgenutzt werden.

Abgeleiteter Schutzbedarf für die Anwendungen

Als Informationssicherheitsbeauftragter hatte ich mich für die Verwendung des Maximal-Prinzips bei der Vererbung des Schutzbedarfes entschieden. Dies bedeutet die Herleitung des Schutzbedarfes der einzelnen Anwendung ist primär davon abhängig, welche Anwendung welchen Prozess unterstützt.

Anwendung APP-0001

Anwendung APP-000n

Zusammenfassung der Schutzbedarfsvererbung für die Anwendungen

Die nachfolgende Tabelle ermöglicht es gerade bei vielen Anwendungen noch einmal die ermittelten Werte losgelöst von den Begründungen zusammen zu fassen. Insofern bereits in der Strukturanalyse die entsprechenden Verknüpfungspunkte mit dokumentiert wurden, kann diese Tabelle bei der späteren Vererbung des Schutzbedarfes auf die IT-Systeme nachgenutzt werden.

Abgeleiteter Schutzbedarf für die IT-Systeme

Als Informationssicherheitsbeauftragter hatte ich mich für die Verwendung des Maximal-Prinzips bei der Vererbung des Schutzbedarfes entschieden. Dies bedeutet die Herleitung des Schutzbedarfes der einzelnen IT-Systeme ist primär davon abhängig, welches IT-System welche Anwendung unterstützt.

IT-System SYS-0001

IT-System SYS-000n

Zusammenfassung der Schutzbedarfsvererbung für die IT-System

Die nachfolgende Tabelle ermöglicht es gerade bei vielen IT-Systemen noch einmal die ermittelten Werte losgelöst von den Begründungen zusammen zu fassen. Insofern bereits in der Strukturanalyse die entsprechenden Verknüpfungspunkte mit dokumentiert wurden, kann diese Tabelle bei der späteren Vererbung des Schutzbedarfes auf die industrielle IT, die Netz-Komponenten oder die Infrastruktur (Gebäude und Räume) nachgenutzt werden.

Abgeleiteter Schutzbedarf für die industriellen IT-Systeme

Als Informationssicherheitsbeauftragter hatte ich mich für die Verwendung des Maximal-Prinzips bei der Vererbung des Schutzbedarfes entschieden. Dies bedeutet die Herleitung des Schutzbedarfes der einzelnen industriellen IT-Systeme ist primär davon abhängig, welches System welchen Prozess, welche Anwendung bzw. welches IT-System unterstützt.

Industrielle IT-System IND-0001

Industrielle IT-System IND-000n

Zusammenfassung der Schutzbedarfsvererbung für die industrielle IT-System

Die nachfolgende Tabelle ermöglicht es gerade bei vielen industriellen IT-Systemen noch einmal die ermittelten Werte losgelöst von den Begründungen zusammenzufassen. Insofern bereits in der Strukturanalyse die entsprechenden Verknüpfungspunkte mit dokumentiert wurden, kann diese Tabelle bei der späteren Vererbung des Schutzbedarfes auf die Netz-Komponenten oder die Infrastruktur (Gebäude und Räume) nachgenutzt werden.

Abgeleiteter Schutzbedarf für die Netzkomponenten

Als Informationssicherheitsbeauftragter hatte ich mich für die Verwendung des Maximal-Prinzips bei der Vererbung des Schutzbedarfes entschieden. Dies bedeutet die Herleitung des Schutzbedarfes der einzelnen Netzkomponenten ist primär davon abhängig, welches IT-System bzw. Industriellen IT-Systeme an diese angebunden sind.

Netzkomponente NET-0001

Netzkomponente NET-000n

Zusammenfassung der Schutzbedarfsvererbung für die Netzkomponenten

Die nachfolgende Tabelle ermöglicht es gerade bei vielen Netzkomponenten noch einmal die ermittelten Werte losgelöst von den Begründungen zusammenzufassen. Insofern bereits in der Strukturanalyse die entsprechenden Verknüpfungspunkte mit dokumentiert wurden, kann diese Tabelle bei der späteren Vererbung des Schutzbedarfes auf die Infrastruktur (Gebäude und Räume) nachgenutzt werden.

Abgeleiteter Schutzbedarf – Kommunikationsverbindungen

Der Schutzbedarf für die Kommunikationsverbindungen ergibt sich aus dem Schutzbedarf der jeweils abhängigen Anwendungen bzw. der übertragenen Daten.

Verbindungsstart- oder -endpunkte, die außerhalb der in der Sicherheitsbetrachtung festgelegten Geltungsbereiches sind, stellen entsprechende Kommunikationsverbindungen mit Außenverbindungen im Sinne eines BSI orientierten Sicherheitskonzeptes dar. Um eine bessere Lesbarkeit der Schutzbedarfe zu ermöglichen, wird die Verwendung der folgenden Kürzel vorgeschlagen.

• Ja - Ein Kommunikationsverbindung startet oder terminiert außerhalb des Geltungsbereiches
• Nein - die Kommunikationsverbindung startet oder terminiert nur innerhalb des Geltungsbereiches
• N - Normal
• H - Hoch
• SH - Sehr hoch

Abgeleiteter Schutzbedarf für die Infrastruktur

Als Informationssicherheitsbeauftragter hatte ich mich für die Verwendung des Maximal-Prinzips bei der Vererbung des Schutzbedarfes entschieden. Dies bedeutet die Herleitung des Schutzbedarfes der einzelnen Gebäude und Räume ist primär davon abhängig, welches IT-System, industriellen IT-Systeme oder Netzkomponenten in diesen betrieben werden.

Gebäude/Raum INF-0001

Gebäude/Raum INF-000n

Zusammenfassung der Schutzbedarfsvererbung für die Gebäude/Räume

Die nachfolgende Tabelle ermöglicht es gerade bei vielen Gebäuden und Räumen noch einmal die ermittelten Werte losgelöst von den Begründungen zusammenzufassen.

Schritt 7 - Modellierung

Als Informationssicherheitsbeauftragter haben sie in den vorherigen Schritten die notwendigen Informationen für die jetzt anstehende Auswahl der relevanten BSI Bausteine aus dem IT-Grundschutz Kompendium im Rahmen der Strukturanalyse ermittelt. Um zukünftige Innovationen vor allem im IT-Bereich zu berücksichtigen, ist das BSI IT-Grundschutz-Kompendium modular aufgebaut und konzentriert sich auf die Definition der wesentlichen Sicherheitsanforderungen für die jeweiligen Bausteine. Die aktuelle Fassung des BSI IT-Grundschutz-Kompendiums kann von der BSI-Webseite selektiv pro Baustein oder als gesamt Paket im PDF Format heruntergeladen (siehe Link 3).

Das Ziel dieses Schrittes ist es, idealerweise alle Zielobjekte aus der Strukturanalyse mit denen vom BSI bereitgestellten technischen Bausteine aus dem IT-Grundschutz-Kompendium zu verknüpfen sowie alle relevanten prozessualen Bausteine übergreifend an den Informationsverbund zu binden. Das Ergebnis ist ein BSI IT-Grundschutz-Modell, welches aus verschiedenen teilweise auch mehrfach verwendeten Bausteinen besteht.

Im Schritt 1 dieses Artikel hatte ich kurz aufgezeigt, dass dies hier dargestellte KMU ein Dienstleister (SaaS) für einen großen nationale Kunden ist. Welche Besonderheiten bei der Modellierung von Cloud-Services bestehen könnten, möchte ich daher hier noch kurz umreißen.

Modellierung bei Virtualisierung

Grundsätzlich erfolgt die Modellierung virtueller IT-Systeme nach den gleichen Regeln wie bei eigen­ ständigen physischen IT-Systemen. Die Zuordnung der IT-Grundschutz-Bausteine richtet sich bei IT-Komponenten in erster Linie nach der Funktion des IT-Systems (Server, Client, usw.), nach dem verwendeten Betriebs­ system (Linux, Windows usw.) und nach den darauf betriebenen Applikationen (Datenbank, Webser­ver usw.). Bei Virtualisierungssoftware gibt es Produkte, die ein unterliegendes Betriebssystem benötigen (host­ basierte Virtualisierungslösungen), und andere, die direkt auf der physischen Hardware laufen (Bare Metal Virtualisierung), ohne unterliegendes Betriebssystem. Falls unterhalb der Virtualisierungs­schicht ein vollwertiges und eigenständiges Betriebssystem eingesetzt wird, muss der dazu passende Baustein ebenfalls zugeordnet werden (z. B. aus SYS.1.2 Windows-Server), unabhängig von den vir­tuellen IT-Systemen. Wurde der Hypervisor direkt auf der physischen Hardware installiert (Bare Metal Virtualisierung) han­delt es sich hierbei um ein Zielobjekt, das im IT-Grundschutz-Kompendium nicht enthalten ist. Daher muss eine Risikoanalyse für das entspre­chende Zielobjekt durchgeführt und die Ergebnisse sollten anschließend mit den Anforderungen des Bausteins SYS.1.5 Virtualisierung konsolidiert werden.

Modellierung beim Cloud-Computing

Um eine angemessene Gesamtsicherheit für den IT-Betrieb von Cloud-Diensten zu erreichen, müssen alle Cloud-Dienste (mit ihren zugeordneten virtuellen IT-Systemen, Netzen und weiteren Cloud-Kom­ponenten) systematisch in der Sicherheitskonzeption berücksichtigt werden. Alle über Cloud-Dienste bereitgestellten IT-Systeme, Netze und Anwendungen, die sich einerseits in der Betriebsverantwor­tung und andererseits im Geltungsbereich des ISMS des Cloud-Diensteanbieters befinden, müssen in der Modellierung gemäß der IT-Grundschutz-Vorgehensweise berücksichtigt werden. Hierbei kann der Geltungsbereich des Informationsverbunds gleichzeitig als Grenze der Verantwortlichkeitverstan­den werden: An der Grenze des Informationsverbunds endet die Verantwortung des Cloud-Dienste­anbieters und beginnt die Verantwortung des Cloud-Anwenders. Der Umfang des Informationsver­bunds unterscheidet sich dabei je nach dem Servicemodell.

Modellierung von IaaS-Angeboten

Bei IaaS (Infrastructure as a Service) ist der Cloud-Diensteanbieter für den Verwaltungsserver für die Cloud und den Virtualisierungsserver verantwortlich. Deshalb kommen bei IaaS aus den Schichten APP (Anwendungen) und SYS (IT-Systeme) nur die Verwaltungs- und die Virtualisierungssoftware als Zielobjekte vor. Für diese müssen somit die zugehörigen Bausteine ausgewählt werden. Nach der IT-Grundschutz-Vorgehensweise sind dies die Bausteine für IT-Systeme als Server (Schicht SYS.1). Für den Cloud-Verwaltungsserver müssen die Bausteine SYS 1.5 Virtualisierung und OPS.3.2 Cloud-Anbieter umgesetzt werden. Für IaaS stellt der Cloud-Diensteanbieter nicht mehr als eine virtuelle „Hülle“ über ein virtuelles Netz bereit. Die Absicherung des Netzes nach IT-Grundschutz verantwortet bei IaaS der Cloud-Dienstean­bieter, wohingegen die Cloud-Anwender die IT-Systeme des Cloud-Angebotes verantworten. Für das Netz sind die passenden Bausteine aus der Schicht Netze und Kommunikation zu modellieren (z. B. NET.1.1 Netzarchitektur und -design). In der Regel wird dem virtuellen Server ein Speicherkontingent aus einem Speichernetz zugeordnet, hierfür ist der Baustein SYS.1.8 Speicherlösungen/Cloud Storage ebenfalls vom Cloud-Diensteanbieter umzusetzen. Ein virtueller Server aus der Cloud, der per IaaS angeboten wird, wird durch den Cloud-Anwender konfiguriert. Die Umsetzungsverantwortung für seine Sicherheitsmaßnahmen liegt somit ebenfalls beim Cloud-Anwender. Im Hinblick auf die Abgrenzung des Informationsverbunds des Cloud-Diens­teanbieters befindet sich also dieser virtuelle Server außerhalb des Informationsverbunds des Cloud-Diensteanbieters. Die Schnittstelle zur Bereitstellung von IaaS-Cloud-Diensten (Self-Service-Portal) ist durch geeignete Mechanismen zur Netztrennung (z. B. über Netze, virtuelle Firewalls, Routing) vom Cloud-Dienstean­bieter abzusichern und gegebenenfalls der Baustein APP.3.1 Webanwendungen umzusetzen. Eine Modellierung der IaaS-Server als IT-Systeme im Sicherheitskonzept des Cloud-Diensteanbieters ist möglich, allerdings nicht notwendig, da die Cloud-Anwender diese IT-Systeme verwalten.

Modellierung von PaaS-Angeboten

Bei PaaS (Platform as a Service) ist der Cloud-Diensteanbieter zusätzlich zu IaaS für die sichere Bereit­stellung eines virtuellen Servers und einer angebotenen Plattform verantwortlich (z. B. einer Daten­bank oder eines Webservers). Zu diesem IT-System ist je nach Cloud-Dienst auf Anwendungsschicht eine Daten­bank oder ein Webserver zu modellieren. Das PaaS-IT-System mit den verbundenen Cloud-Anwendungen muss für jeden Cloud-Mandanten modelliert werden, wobei Mandanten mit gleichen Plattformen, gleichen Anwendungen und glei­chem Schutzbedarf gemäß den Vorgaben Komplexitätsreduktion durch Gruppenbil­dung in einer Gruppe zusammengefasst werden können. In der Praxis werden Cloud-Dienste des Servicemodells PaaS über virtuelle Profile bereitgestellt, die für mehrere Cloud-Anwender bzw. Mandanten eingesetzt werden können. Es bietet sich daher in der IT-Grundschutz-Modellierung an, diese Kombinationen in Form von Musterservern zu modellieren und pro Mandant zu verknüpfen bzw. zu vervielfachen.

Modellierung von SaaS-Angeboten

Bei SaaS (Software as a Service) müssen zunächst die für die unterliegende Cloud-Infrastruktur rele­vanten Zielobjekte wie bei IaaS und PaaS identifiziert und entsprechenden Bausteinen zugeordnet werden. Im Vergleich zu PaaS werden bei SaaS weitere Anwendungen auf den Cloud-IT-Systemen modelliert (z. B. ein Webservice, eine Webanwendung). Bei SaaS ist der Cloud-Dienstean­bieter praktisch für den gesamten Cloud-Computing-Stack (Server, Netze, Storage, Management und Anwendungen) verantwortlich.

Die IT-Grundschutz-Modellierung, also die Zuordnung von Bausteinen zu Zielobjekten, sollte in Form einer Tabelle mit folgenden Spalten dokumentiert werden, sofern nicht ein dediziertes ISMS-Tool hierfür verwendet wird. Die Tabelle sollte mindestens die vier hier aufgeführten Inhalte beinhalten:

• Nummer und Titel des Bausteins: herausgezogen aus dem aktuell angewandten Kompendium
• Relevanz: Diese Spalte dient der Entscheidung, ob ein Baustein für den zu modellierenden Infor­ mationsverbund relevant ist oder nicht. Sie liefert einen schnellen Überblick darüber, ob kein Bau­ stein vergessen wurde.
• Zielobjekt: Wenn ein Baustein für den Informationsverbund relevant ist, erfolgt über diese Spalte die Zuordnung zum Zielobjekt bzw. einer Zielobjektgruppe
• Begründung: In dieser Spalte können Randinformationen und Begründungen für die Modellierung dokumentiert werden. Sind Bausteine für den betrachteten Informationsverbund nicht relevant, sollte dies hier explizit begründet werden.

Die Modellierung nach dem BSI IT-Grundschutz besteht nun für sie als Informationssicherheitsbeauftragter darin, für die Bausteine einer jeden Schicht zu entscheiden, ob und wie sie zur Abbildung des Informationsverbunds herangezogen werden können. Lassen Sie uns also mit der Schicht 1 - ISMS: Sicherheitsmanagement starten.

Modellierung Schicht 1 - ISMS: Sicherheitsmanagement

Modellierung Schicht 2 - ORP: Organisation und Personal

Modellierung Schicht 3 - CON: Konzeption und Vorgehensweise

Modellierung Schicht 4 - OPS: Betrieb

Modellierung Schicht 5 - DER: Detektion und Reaktion

Modellierung Schicht 6 - APP: Anwendungen

Modellierung Schicht 7 - SYS: IT-Systeme

Modellierung Schicht 8 - IND: Industrielle IT

Modellierung Schicht 9 - NET: Netze und Kommunikation

Modellierung Schicht 10 - INF: Infrastruktur

Schritt 8 - IT-Grundschutz-Check

Bevor der Informationssicherheitsbeauftragte zusammen mit den fachlich Verantwortlichen die IT-Grundschutz-Checks durchführen kann, müssen ein paar Voraussetzungen erfüllt sein, die ich an dieser Stelle noch einmal kurz zusammenfasse. Aufbauend auf der Strukturanalyse für den mit der Geschäftsführung abgestimmten Informationsverbunds (Geltungsbereich der Sicherheitsanalyse) wurde eine Übersicht über die kritischen Geschäftsprozesse, die mit den Geschäftsprozessen verknüpften IT und deren Vernetzung, die unterstützten Anwendungen sowie die Gebäude und deren Räum­lichkeiten erstellt. Basierend auf den Informationen aus der Strukturanalyse wurde anschließend die Schutzbedarfsfeststellung durchge­führt, deren Ergebnis eine Übersicht über den Schutzbedarf der Geschäftsprozesse, Anwendungen, IT-Systeme, der genutzten Gebäude und Räume sowie der Kommunikationsverbindungen ist. Des Weiteren wird mit Hilfe der Strukturanalyse die Modellierung des Informationsverbunds nach IT-Grundschutz durchgeführt. Das Ergebnis war eine Abbildung des betrachteten Informationsverbunds auf Bausteine des BSI IT-Grundschutzes.

Als Informationssicherheitsbeauftragter liefern mir die Ergebnisse der Modellierung des Informationsverbundes eine Grundlage für die Erstellung der Sicherheitsrichtlinien. Da die Sicherheitsrichtlinien die Möglichkeit offerieren die Bausteine des BSI IT-Grundschutzes an die Bedürfnisse des KMU anzupassen, lassen sie mich noch einmal kurz auf das Thema Sicherheitsrichtlinien abschweifen. Als erstes lassen Sie uns den Begriff der Sicherheitsrichtlinie kurz definieren. Eine Sicherheitsrichtlinie beschreibt den erstrebten Informationssicherheitsanspruch des KMU. Alle Anforderungen an die Informationssicherheit sollten idealerweise über eine vierstufige Dokumentenpyramide fokussiert auf den Anwender ausgerichtet sein.

• Die Ebene 1 wird durch die „Leitlinie zur Informationssicherheit“ repräsentiert. Die Leitlinie zur Informationssicherheit wird von der Geschäftsführung freigegeben und delegiert an den Informationssicherheitsbeauftragten die Aufgabe ein ISMS auf Basis des BSI IT-Grundschutzes unter Verwendung der Standards 200-1, 200-2 und 200-3 zu etablieren. Die Leitlinie muss von allen Mitarbeitenden des KMU zur Kenntnis genommen, verstanden und beachtet werden. Zuwiderhandlungen werden soweit möglich sanktioniert. Über den folgenden Link 4 steht ein Beispiel für eine Leitlinie zur Informationssicherheit zur Verfügung.
• Die Ebene 2 beinhaltet eigene Standards des KMU, mit denen die Anforderungen an die Umsetzung der Informationssicherheit festgelegt werden. Aus der Praxis heraus bietet es sich an die folgenden Dokumente zu erstellen:
  • „Standard - Rollen und Gremien“,
  • „Standard - Sicherheitsorganisation“,
  • „Standard - Benutzer“,
  • „Standard - IT-Administration“,
  • „Standard - Sensibilisieren“,
  • „Standard - Klassifizierung von Informationen“,
  • „Standard - externe Dienstleistungen“ und
  • „Standard - physische Sicherheit“
• Über den folgenden Link 5 stehen Beispiele für die zuvor aufgezeigten Dokumente zur Verfügung.
• Mit den internen Sicherheitsrichtlinien auf der Ebene 3 werden die bisherigen Anforderungen (aus der Ebene 1 und 2) hinsichtlich ihrer gewünschten Umsetzung weiter detailliert. Die Inhalte der Sicherheitsrichtlinien sollten dabei den Endanwender im Fokus haben und der vom BSI vorgeschlagenen Gewichtung folgen. Dies bedeutet, dass das Kapitel „Basisanforderungen“ die zwingend umzusetzenden Anforderungen enthält. Das Kapitel „Standardanforderungen“ beinhaltet Anforderungen zur Erreichung eines vollumfänglichen Schutzniveaus für einen Schutzbedarf von „Normal“ in den Informationssicherheitsschutzzielen Vertraulichkeit, Integrität und Verfügbarkeit. Im Kapitel „bei erhöhtem Schutzbedarf“ sind Anforderungen für die Gewährleistung eines Schutzbedarfs von „Hoch“ und „Sehr hoch“ eingruppiert. Die Umsetzung der Anforderungen sollte je Anwendungsfall im Rahmen einer kurzen Verhältnismäßigkeitsprüfung abgewogen werden. Über den folgenden Link 6 stehen Beispiele für Sicherheitsrichtlinien auf Grundlage des BSI IT Grundschutz Kompendiums 2020 zur Verfügung.
• Die Ebene 4 wird durch die Konzepte, Vorlagen, technische Richtlinien und Dokumentationen der internen oder externen Dienstleistungserbringer anhand der steuernden Vorgaben der übergeordneten Ebenen gebildet und durch das Informationssicherheitsmanagement regelmäßig kontrolliert.

Aber jetzt zurück zum eigentlichen Thema dem BSI IT-Grundschutz-Check. In diesem Schritt wird die Modellierung nach BSI IT-Grundschutz nun zur Ableitung des Prüfplans nachgenutzt, um anhand eines Soll-Ist-Ver­gleichs herauszufinden, welche Anforderungen aus den BSI Bausteinen und den internen Vorgaben ausreichend oder nur unzureichend erfüllt wurden. Zu jeder Anforderung aus dem zu prüfenden BSI Baustein wird erhoben, ob die Anforderung durch die vorhandenen Umsetzungen vollständig („ja“), in Teilen („teilweise“) oder nicht („nein“) erfüllt wurden oder ob die Anforderung auf den betrachteten Informationsverbund aus bestimmten Gründen nicht anwendbar ist („entbehrlich“). Durch die Identifizierung von noch nicht oder nur teilweise erfüllten Anforderungen werden im Rahmen des IT-Grundschutz-Checks potenzielle Verbesserungsmöglichkeiten aufgezeigt.

Die eigentliche Durchführung des IT-Grundschutz-Checks besteht aus drei unterschiedlichen Schritten.

1. die organisatorischen Vorbereitungen, insbesondere die Auswahl der relevanten Ansprech­partner für den Soll-Ist-Vergleich
2. Durchführung des Soll-Ist-Vergleichs mittels Interviews und stichprobenartiger Kontrolle
3. Dokumentation der erzielten Ergebnisse des Soll-Ist-Vergleichs einschließlich der erhobenen Begründungen pro Anforderung

Organisatorische Vorarbeiten für den IT-Grundschutz-Check

Für die optimale Durchführung des IT-Grundschutz-Checks sind einige Vorbereitungen seitens des Informationssicherheitsbeauftragten und den fachlich Verantwortlichen erforderlich. Zu­ nächst sollten alle vorhandenen Dokumentationen bspw. organisatorische oder technische Arbeitsanweisungen, Arbeitshinweise, Handbücher die die Abläufe für die in der Strukturanalyse hinterlegten Prozesse, Anwendungen und IT-Systeme regeln auf Relevanz für die Sicherheitsbeurteilung gesichtet werden. Aus wirtschaftlichen Gründen sind einige Aufgaben an einen Dienstleister für die optimale Betreuung übergeben worden, daher sollte als Nächstes durch den Informationssicherheitsbeauftragten festgestellt werden, ob und in welchem Umfang Dienstleister bei der Ermittlung des Umsetzungsstatus der Sicherheitsanforderungen beteiligt werden müssen.

Ein wichtiger Schritt vor der Durchführung des eigentlichen Soll-Ist-Vergleichs ist die Ermittlung ge­eigneter Interview-Partner.

Hierzu sollte zunächst für jeden einzelnen mit „ja“ gekennzeichneten Baustein im Schritt Modellierung ein Hauptansprechpartner fest­gelegt werden. Einen Anhaltspunkt für die Festlegung des Hauptansprechpartners wird bereits mit den Bausteinen des BSI mit jeder Anforderung und der benannten Rollen aufgezeigt. Die nachfolgende Abbildung benennt die Institutionsleitung als Hauptansprechpartner für die Anforderung ISMS.1.A1 aus dem Baustein ISMS.1 Sicherheitsmanagement.

Für die anstehenden Interviews sollte zusammen mit den Hauptansprechpartnern ein Terminplan erstellt werden. Ein besonderes Augenmerk gilt hier der Termin­koordination mit Dienstleistern. Um mögliche Verzögerungen oder Terminüberschneidungen bereits im Vorfeld so weit wie möglich zu verhindern, sollten bereits im Vorhinein Ausweichtermine mit allen Beteiligten abgestimmt werden. Die Planung der Interviews kann bspw. mit Hilfe der folgenden Tabellenstruktur organisiert und dokumentiert werden.

Je nach Größe der Interviewgruppe hat es sich bewährt, zwei Personen für die Durchführung des Interviews und pro Baustein und Zielobjekt 4 Stunden für die Interviews selbst einzuplanen. Wichtig für die optimale Dokumentation der Interviewergebnisse ist, eine Person stellt die notwendigen Fragen und die andere Person notiert die Ergebnisse und Anmerkungen, die durch den Interview-Partner gegeben werden. Durch dieses vorgeschlagene Vorgehen kann in der Nachbereitung der Interviews viel Zeit gespart und Missverständnisse vermieden werden.

Durchführung des Soll-Ist-Vergleichs

Als Informationssicherheitsbeauftragter ist mir wichtig eine angenehme und vertrauensvolle Atmosphäre für alle Beteiligten aufzubauen. Um dieses zu erreichen, ist es sinnvoll nicht nur die reinen BSI IT-Grundschutz Bausteintexte, sondern auch die internen Sicherheitsrichtlinien, die Formulare zur Dokumentation der BSI IT-Grundschutz-Checks sowie ergänzende Materialien wie Konzepte, Handbücher, Checklisten, Organigramme oder Prozessvisualisierungen griffbereit zu haben. Ein weiterer Aspekt für eine optimale Vorbereitung ist auch den Interview-Partnern im Vorfeld bereits zu signalisieren, dass auch stichprobenartig auf vereinzelte Systeme oder Anwendungen geschaut wird. Denn nicht immer ist es möglich auf die Management-Systeme von jedem Platz innerhalb des KMU aus zu greifen zu können.

Von besonderer Wichtigkeit ist es für mich zu Beginn der Interviews allen Befragten den Grund für die Interviews, den Zweck sowie das anschließende Vorgehen kurz vorzustellen.

Gerade in einem KMU sind die Interview-Partner häufig noch nicht so sehr erprobt mit der Durchführung von BSI IT-Grundschutz-Checks, daher bietet es sich an, die Anforderungsüberschriften kurz vorzulesen und die Anforderungen seitens des Informationssicherheitsbeauftragten kurz zu erläutern. Durch dieses Vorgehen, besteht zu gleich die Chance den Interview-Partnern die Möglichkeit zu geben, auf die bereits umgesetzten Anforderungen und Maßnahmen einzugehen, Rückfragen zu stellen und die getätigten Antworten frühzeitig pro Anforderungsaspekt zu dokumentieren. Falls der Bedarf besteht, die in den Interviews gemachten Aussagen zu verifizieren, bietet es sich an, stichprobenartig die entsprechenden Regelungen und Konzepte zu sichten, im Bereich Infrastruktur gemeinsam mit dem Ansprechpartner die zu untersuchenden Objekte vor Ort zu besichtigen sowie Konfigurationen an ausgewähl­ten IT-Systemen zu überprüfen. Zum Abschluss jedes IT-Grundschutz-Checks sollte den Befragten das Ergebnis (Umsetzungsstatus der Anforderun­gen: entbehrlich/ja/teilweise/nein) mitgeteilt und diese Entscheidung erläutert werden. Für die Eingruppierung des aktuellen Umsetzungsstatus der einzelnen Anforderungen stehen dem Informationssicherheitsbeauftragten die folgenden Bewertungsstufen zur Verfügung.

Der BSI Standard 200-2 empfiehlt, dass aus dem betrachteten BSI Baustein zunächst nur die Anforderungen aus den Abschnitten Basis- und Standard-Anforderungen im Rahmen des IT-Grundschutz-Checks geprüft und die Anforderungen bei erhöhtem Schutzbedarf erst nach Ab­schluss des initialen IT-Grundschutz-Checks und der Risikoanalyse in einem anschließenden erneuten IT-Grundschutz-Check betrachtet werden. Da wir uns als KMU für die Kern-Absicherung entschieden haben und somit stets von einem hohen bzw. sehr hohen Schutzbedarf ausgehen dürfen, sollten wir an dieser Stelle von der Empfehlung des BSI abweichen und im Rahmen der BSI IT-Grundschutz-Checks alle Anforderungen eines Bausteines dessen Umsetzungsgrades abfragen und dokumentieren. Insofern alle Interview-Partner der kleinen Abweichung folgen, hilft dieses auch bei der späteren Risikoanalyse. Denn die bereits aufgenommen Ergebnisse können bereits in die Betrachtung der Risikobegegnung mit einfliessen.

Dokumentation der Ergebnisse

Die Antworten der Interview-Partner sind so zu dokumentieren, dass sie für alle Beteilig­ten nachvollziehbar sind, als Grundlage für spätere Analysen oder einer erneuten Überprüfung genutzt werden können.

Zur Ergebnisdokumentation des BSI IT-Grundschutz-Checks gehört mindestens:

• die Bezeichnung des betrachteten Zielobjektes bzw. der Gruppe von Zielobjekten
• die Version des angewandten BSI Kompendiums
• die Namen der Interview-Partner
• der Name des Auditors
• der Tag an dem der IT-Grundschutz-Check durchgeführt wurde
• Kommentare zur Umsetzung
• den Grad der Umsetzung
• offene Maßnahmen, sofern vorhanden
• bis wann die offenen Maßnahmen umgesetzt werden
• Wer Verantwortlich für die Umsetzung ist
• geschätzte Kosten seitens den fachlich Verantwortlichen

Die nachfolgende Abbildung zeigt ein teilweise ausgefülltes IT-Grundschutz Formular für den Baustein ISMS.1 Sicherheitsmanagement.

Die original Vorlage steht über diesen Link 7 allen interessierten zur Verfügung. Als Informationssicherheitsbeauftragter kann ich auf der Basis der Vorlage und den im Schritt Modellierung mit „Ja“ gekennzeichneten Bausteinen individuelle IT-Grundschutz-Check Formulare für das KMU erstellen. Sollte mir die Zeit oder zusätzliche Unterstützung fehlen, stellt ebenfalls das BSI entsprechende Formulare für die Grundschutz-Checks zur Verfügung. Die vom BSI bereitgestellten Formulare sind im ODT-Format gespeichert und über diesen Link 8 für das aktuelle Kompendium 2021 verfügbar.

Zum Abschluss dieses Schrittes noch ein paar Tipps für das optimale Ausfüllen und Dokumentieren der geplanten IT-Grundschutz-Checks.

Schritt 9 - Risikoanalyse und weiterführende Sicherheitsmaßnahmen

Im Normalfall ermöglicht die vollumfängliche Erfüllung aller relevanten Bausteine einen angemes­senen und ausreichenden Schutz. Ab einem hohen Schutzbedarf, wie er im Rahmen der Kern-Absicherung regelmäßig auftritt, ist dies jedoch nicht mehr garantiert. Daher ist zu prüfen, ob auf Basis des Umsetzungsgrades der Anforderungen aus dem Abschnitt „Anforderungen bei erhöhtem Schutzbedarf“ noch weitere zusätzliche Sicherheitsanforderungen benötigt werden. Insofern im Rahmen der Modellierung nicht alle Zielobjekte der Strukturanalyse mit einem Baustein verknüpft werden konnten oder der verknüpfte Baustein nicht richtig zum Zielobjekt passt, muss überprüft werden, ob zur Begegnung der elementaren Gefährdungen sowie spezifischen Gefährdungen auf Grund des Einsatzzweckes oder Umgebung zusätzliche Sicherheitsanforderungen benötigt werden.

Bevor in den nächsten Absätzen genauer auf die Durchführung der Risikoanalyse eingegangen wird, sei noch einmal kurz erlaubt die benötigten Elemente einer Risikoanalyse aufzuzeigen. Dieses wären,

• die Erstellung einer Gefährdungsübersicht
  • Zusammenstellung einer Liste von möglichen elementaren Gefährdungen
  • Ermittlung zusätzlicher Gefährdungen, die über die elementaren Gefährdungen hinausgehen und sich aus dem spezifischen Einsatzszenario ergeben
• die Risikoeinstufung
  • Risikoeinschätzung
  • Risikobewertung
• die Risikobehandlung
  • Risikovermeidung
  • Risikoreduktion
  • Risikotransfer
  • Risikoakzeptanz

Die Erstellung einer Gefährdungsübersicht

Für die Durchführung einer effizienten Risikoanalyse stellt das BSI 47 elementare Gefährdungen zusammen mit den Bausteinen im jeweils aktuellen BSI IT-Grundschutz Kompendium zur Verfügung. Hierbei ist zu beachten, dass Gefährdun­gen, die überwiegend die fehlende oder unzureichende Umsetzung von Sicherheitsmaßnahmen innerhalb des KMU adressieren und somit auf indirekte Gefahren verweisen, sind durch die 47 elementare Gefährdungen nicht abgedeckt. Bei der Erstellung der Übersicht der elementaren Gefährdungen wurde seitens dem BSI mit betrachtet, welcher Grundwert der Informationssicherheit (Vertraulichkeit, Integrität, Verfügbarkeit) durch die jeweilige Gefährdung gemindert würde. Nicht alle 47 elementaren Gefährdungen in der Tabelle lassen sich auf genau einen Grundwert der Informationssicherheit abbilden. Dies führt im Ergebnis dazu, dass einzelne Gefährdungen auch mehr als einen Grundwert der Informationssicherheit adressieren und die jeweilige Gefährdung die dazu aufgeführten Grundwerte direkt beeinträchtigt. Bei einigen Gefährdungen wird wahrscheinlich im Vorfeld der Risikoanalyse darüber diskutiert, inwieweit alle drei Grundwerte betroffen sein könnten, weil sich auch indirekte Auswirkungen ableiten lassen. 
Eine Übersicht über die elementaren Gefährdungen sowie die Nennung der hauptsächlich betroffenen Grundwerte wird über die nachfolgende Tabelle visualisiert. In der Spalte Grundwert, referenziert das C die Confidentiality (Vertraulichkeit), das I die Integrity (Integrität) und das A die Availability (Verfügbarkeit).

Im ersten Schritt erstellt der Informationssicherheitsbeauftragte eine Übersicht der Gefährdungen. Wie der Informationssicherheitsbeauftragte bei der Ermittlung von elementaren Gefährdungen vorgeht, ist davon abhängig, ob auf bereits modellierte BSI Bausteine zurückgegriffen werden kann oder ob einzelne Zielobjekte aus der Strukturanalyse nicht mit einem Baustein verknüpft werden konnten. Insofern das betrachtete Zielobjekt hinreichend mit bestehenden Bausteinen des IT-Grundschutz-Kompendiums ab­ gebildet werden konnte, wurde im Rahmen der Bausteinerstellung seitens des BSI bereits vorab die relevanten elementaren Gefährdungen ermittelt, die als Ausgangspunkt der Gefährdungsanalyse verwendet werden können. Die Ergebnisse dieser Ermittlung sind in der Kreuzreferenztabelle für jeden Baustein hinterlegt. Die nachfolgende Abbildung zeigt eine beispielhafte Kreuzreferenztabelle für den Baustein ISMS.1 und ist aus dem BSI IT-Grundschutz Kompendium 2021 entnommen worden.

Sollten hingegen einzelne oder mehrere Zielobjekte aus der Strukturanalyse im Rahmen der Modellierung nicht mit einen Baustein verknüpft worden sein, ist jede elementare Gefährdung dahingehend zu bewerten, ob diese direkt, indirekt oder gar nicht auf das Zielobjekt einwirken kann:

• „Direkt relevant“ bedeutet, dass die jeweilige Gefährdung auf das betrachtete Zielobjekt ein­ wirken kann und deshalb im Rahmen der Risikoanalyse behandelt werden muss.
• „Indirekt relevant“ bedeutet, dass die jeweilige Gefährdung zwar auf das betrachtete Zielobjekt einwirken kann, in ihrer potenziellen Wirkung aber nicht über andere elementare Gefährdun­gen hinausgeht. In diesem Fall muss die jeweilige Gefährdung für dieses Zielobjekt nicht gesondert im Rahmen der Risikoanalyse behandelt werden.
• „Nicht relevant“ bedeutet, dass die jeweilige Gefährdung nicht auf das betrachtete Zielobjekt ein­ wirken kann und deshalb im Rahmen der Risikoanalyse nicht behandelt wer­den muss.

Für die vom Informationssicherheitsbeauftragten betrachteten Zielobjekte gibt es unter Umständen (spezifischen Einsatzszenario oder Anwendungsfall) einzelne zusätzliche Gefährdungen, die über die vom BSI benannten elementaren Gefährdungen hinausgehen und ebenfalls berücksichtigt werden müssen. Bei der Ausarbeitung von spezifischen Gefährdungen sollten die beiden folgenden Kriterien herangezogen werden.

• Die Gefährdung führt zu einem nennenswerten Schaden und
• die Gefährdung ist im vorliegenden Anwendungsfall und Einsatzumfeld realistisch.

Die Risikoeinstufung

Nachdem alle relevanten Gefährdungen durch den Informationssicherheitsbeauftragten identifiziert worden sind, wird im nächsten Schritt ermittelt, welches Risiko von jeder als relevant gekennzeichneten Gefährdung ausgeht. Wie hoch dieses Risiko ist, hängt sowohl von der Eintrittseinschätzung der Gefährdung als auch von der Höhe des Schadens ab, der dabei droht. An dieser Stelle noch einen kleinen Hinweis, es gibt kein einfaches und alpgemeingültiges Konzept um mit einem angemessenen Aufwand ein Risiko einzuschätzen. Dank der Vorbereitungen im Schritt Schutzbedarfsanalyse und den Ergebnissen des IT-Grundschutz Checks können wir ein paar Abkürzungen nehmen ohne gegen den Standard des BSI zu verstoßen.

Betrachten wir zu erst die Eintrittshäufigkeit. Diese sollte zusammen mit dem Informationssicherheitsbeauftragten, den Verantwortlichen für den Betrieb und durch geeignete Sicherheitsexperten (Security Incident Responder, Security Investigator, Advanced Security Analyst) eingeschätzt werden und sollte zusätzlich durch Statis­tiken aus Threat-Reports und eigene Erfahrungen unterstützt werden. Bei der zur Hilfenahme von Statistiken muss allerdings beachtet werden, unter welchen Randbedingungen die Statistik entstanden ist. Das BSI wünscht sich hier häufig eine vierstufige Bewertungsskala (Eintrittshäufigkeit: selten, mittel, häufig, sehr häufig). Nachfolgend die vom BSI im Standard vorgeschlagenen Werte für die Bewertung der Eintrittshäufigkeit.

Wenn ich jetzt als Informationssicherheitsbeauftragter vor meinem inneren Auge mir die 47 Gefährdungen des BSI Grundschutzes aufliste, kann ich für einzelne Gefährdungen wie bspw. Missbrauch von Berechtigungen oder Schadprogramme oder Identitätsdiebstahl nicht wirklich sagen wie häufig dies eintreten wird und mit hoher Wahrscheinlichkeit bereitet die vierstufige Bewertungsskala noch an anderer Stelle Probleme. Aber zum Glück erlaubt uns das BSI die Anzahl der Stufen als auch die Kriterien selbst festzulegen (siehe BSI Standard 200-3 Seite 26). Persönlich bin ich mit einer zweistufigen Bewertungsskala in der Vergangenheit sehr gut gefahren. Die beiden Stufen unterscheiden sich wie folgt.

Im vorherigen Schritt wurden mittels der zweistufigen Bewertungsskala die Eintrittswahrscheinlichkeit aller Risiken ermittelt. Für alle Risiken, welche wahrscheinlich eintreten, wird in diesem Prozessabschnitt die potenzielle Schadenshöhe ermittelt. Bei der Betrachtung der Schadenshöhe geht es darum, mit welche Schäden finanzieller und anderer Art kalkuliert werden sollten. Bei der Betrachtung der Schadenshöhe sollte auch berücksichtigt werden, welche direkten Schäden und welche Folgeschäden entstehen könnten sowie mit welchem Aufwand und in welcher Zeit der potentielle Schaden zu beheben wäre.

Das BSI wünscht sich auch hier häufig eine vierstufige Bewertungsskala (potenzielle Schadenshöhe: vernachlässigbar, begrenzt, beträchtlich, existenzbedrohend). Nachfolgend die vom BSI im Standard vorgeschlagenen Werte für die Bewertung der Schadenshöhe.

Auch bei der Bewertung der Schadenshöhe erlaubt das BSI die Anzahl der Stufen als auch die Kriterien selbst festzulegen (siehe BSI Standard 200-3 Seite 26). Persönlich bin ich mit einer Bewertungsskala aufbauend auf den bereits definierten Schadenshöhen der Schutzbedarfskategorien in der Vergangenheit sehr gut gefahren. Als kleine Erinnerung, wie der Schutzbedarf ermittelt wurde, habe ich die entsprechende Passage hier noch einmal aufgeführt. Der Schutzbedarf ist meist nicht quantifizierbar, daher beschränkt sich der BSI IT-Grundschutz somit auf eine qualitative Aussage, indem der Schutzbedarf in drei Kategorien unterteilt wird. Die nachfolgenden Schritte erläutern, wie für Geschäftsprozesse und die mit diesen verbundenen Anwendungen jeweils die adäquate Schutzbedarfskategorien ermittelt werden können. Die Schäden, die bei dem Verlust der Vertraulichkeit, Integrität oder Verfügbarkeit für einen Ge­schäftsprozess bzw. eine Anwendung einschließlich ihrer Daten entstehen können, lassen sich typi­scherweise folgenden Schadensszenarien zuordnen:

• Verstoß gegen Gesetze/Vorschriften/Verträge,
• Beeinträchtigung des informationellen Selbstbestimmungsrechts,
• Beeinträchtigung der persönlichen Unversehrtheit,
• Beeinträchtigung der Aufgabenerfüllung,
• negative Innen- oder Außenwirkung und
• finanzielle Auswirkungen.

Persönlich bin ich bei der Bewertung der Auswirkungen mit einer zweistufigen Bewertungsskala in der Vergangenheit sehr gut gefahren. Die beiden Stufen haben sich wie folgt unterschieden.

Anhand der zuvor definierten Kategorien für die potenzielle Schadenshöhe und deren Auswirkungen sowie der Klassifikation für Eintrittshäufigkeiten von Gefährdungen ist eine Risikomatrix fest zu legen. Auch hier wünscht sich das BSI häufig eine vierstufige Bewertung und stellt das folgende Beispiel im Standard 200-3 auf Seite 28 zur Verfügung.

Aus rein pragmatischen Aspekten kann bei einer ordentlichen Umsetzung der Anforderungen aus den BSI Bausteinen und entsprechender bedarfsgerechter Anreicherung der organisatorischen und technischen Anforderungen in den internen Sicherheitsrichtlinien eine Zusammenfassung der Risikokategorien vorgenommen werden. Persönlich bin ich bei der Unterscheidung der Risikokategorien mit einer zweistufigen Bewertungsskala in der Vergangenheit sehr gut gefahren. Die beiden Stufen haben sich wie folgt unterschieden.

Um die Mehrwerte aus der Schutzbedarfsfeststellung für die Risikoanalyse zu heben, wird somit die Bewertungsskala der Schutzbedarfsfeststellung in Relation mit den bereits verknüpften Höchstgrenzen für finanzielle Schäden pro Schutzbedarfskategorie und mit der Bewertung der Auswirkungen kombiniert. In der Praxis wird somit größtenteils mit einer 2x2 Matrix bzw. einer 2x3 Matrix die Risikoanalyse durchgeführt. In welchen Situationen, welcher Matrixtyp angewandt wird visualisieren die nachfolgenden Abbildungen.

Bisher wurden nur die theoretischen Grundlagen für die eigentliche Risikoanalyse definiert und vieles klingt komplizierter als es in Wirklichkeit ist. Aus diesem Grunde widmet sich der Artikel wieder der pragmatischen und praktischen Anwendung der bisher definierten Bewertungsskalen. In der nachfolgenden Abbildung werden alle bisherigen Parameter in einer zu befüllenden Tabelle zusammengefasst und beispielhaft für die Gefährdung G.01 Feuer dargestellt.

Im Rahmen der Risikobewertung wird in der Zeile Beschreibung eine kurze aber präzise Beschreibung der Gefährdung G.0.1 unter Berücksichtigung des zu betrachtenden Zielobjektes. Als Anhaltspunkt für die Beschreibung bietet das BSI bereits eine Formulierung im jeweiligen IT-Grundschutz Kompendium an. Um so vollumfänglicher die Anforderungen aus den jeweiligen BSI Bausteinen umgesetzt wurden, um so einfacher gestaltet sich die Aufzählung der bereits getätigten Maßnahmen zur Begegnung der Gefährdung G.0.1. Auch hier unterstützt das BSI uns als Anwender mit der Kreuzreferenztabelle, so ist z. B. die Gefährdung G.0.1 im IT-Grundschutz Kompendium mit den folgenden Anforderungen verknüpft:

• CON.3 Datensicherungskonzept
  • CON.3.A12 Sichere Aufbewahrung der Speichermedien für die Datensicherungen
• INF.1 Allgemeines Gebäude
  • INF.1.A1 Planung der Gebäudeabsicherung
  • INF.1.A3 Einhaltung von Brandschutzvorschriften
  • INF.1.A4 Branderkennung in Gebäuden
  • INF.1.A5 Handfeuerlöscher
  • INF.1.A8 Rauchverbot
  • INF.1.A12 Schlüsselverwaltung
  • INF.1.A14 Blitzschutzeinrichtungen
  • INF.1.A17 Baulicher Rauchschutz
  • INF.1.A18 Brandschutzbegehungen
  • INF.1.A19 Information des Brandschutzbeauftragten
  • INF.1.A20 Alarmierungsplan und Brandschutzübungen
  • INF.1.A22 Sichere Türen und Fenster
  • INF.1.A34 Gefahrenmeldeanlage
  • INF.1.A36 Regelmäßige Aktualisierungen der Dokumentation
• INF.2 Rechenzentrum sowie Serverraum
  • INF.2.A2 Bildung von Brandabschnitten
  • INF.2.A4 Notabschaltung der Stromversorgung
  • INF.2.A8 Einsatz einer Brandmeldeanlage
  • INF.2.A9 Einsatz einer Lösch- oder Brandvermeidungsanlage
  • INF.2.A10 Inspektion und Wartung der Infrastruktur
  • INF.2.A13 Planung und Installation von Gefahrenmeldeanlagen
  • INF.2.A15 Überspannungsschutzeinrichtung
  • INF.2.A17 Brandfrüherkennung
  • INF.2.A28 Einsatz von höherwertigen Gefahrenmeldeanlagen
  • INF.2.A30 Anlagen zur Erkennung
• INF.5 Raum sowie Schrank für technische Infrastruktur
  • INF.5.A2 Lage und Größe des Raumes für technische Infrastruktur
  • INF.5.A6 Minimierung von Brandlasten
  • INF.5.A7 Verhinderung von Zweckentfremdung
  • INF.5.A9 Stromversorgung
  • INF.5.A11 Vermeidung von Leitungen mit gefährdenden Flüssigkeiten und Gasen
  • INF.5.A13 Schutz vor Schädigung durch Brand und Rauchgase
  • INF.5.A14 Minimierung von Brandgefahren aus Nachbarbereichen
  • INF.5.A18 Lage des Raumes für technische Infrastruktur
  • INF.5.A25 Erhöhter Schutz vor Schädigung durch Brand und Rauchgase
• INF.6 Datenträgerarchiv
  • INF.6.A1 Handfeuerlöscher
  • INF.6.A3 Schutz vor Staub und anderer Verschmutzung
  • INF.6.A4 Geschlossene Fenster und abgeschlossene Türen
  • INF.6.A8 Sichere Türen und Fenster
  • INF.6.A9 Gefahrenmeldeanlage
• INF.8 Häuslicher Arbeitsplatz
  • INF.8.A4 Geeignete Einrichtung des häuslichen Arbeitsplatzes
  • INF.8.A6 Umgang mit dienstlichen Unterlagen bei erhöhtem Schutzbedarf am häuslichen Arbeitsplatz
• INF.11 Allgemeines Fahrzeug
  • INF.11.A16 Brandlöschanlage
• INF.12 Verkabelung
  • INF.12.A2 Planung der Kabelführung
  • INF.12.A3 Fachgerechte Installation
  • INF.12.A5 Anforderungsanalyse für die Verkabelung
  • INF.12.A13 Vermeidung elektrischer Zündquellen
  • INF.12.A17 Redundanzen für die IT-Verkabelung

Im Rahmen der Modellierung wurden die relevanten Bausteine den Zielobjekten zu geordnet und genau diese Zuordnung hilft uns im Rahmen der Risikoanalyse beim Selektieren der zu betrachtenden Anforderungen aus den Bausteinen und deren Status der Umsetzung. Alle zu 100% vollumfänglich umgesetzten Anforderungen reduzieren die Gefährdung G.0.1 und werden als vollumfänglich umgesetzt aufgelistet. Alle lediglich teilweise umgesetzten Anforderungen werden im Anschluss auch aufgeführt, denn auch diese helfen bei der Reduzierung der Gefährdung. Hier muss jedoch geschaut werden, ob dieses ausreichend genug ist.

Nun heißt es die Bewertung des Risikos für die jeweilige Gefährdung vorzunehmen. Grundsätzlich sollte mit der Eintrittshäufigkeit gestartet werden. Wichtig ist hierbei, die Bewertung der Eintrittswahrscheinlichkeit erfolgt unabhängig, ob bereits Maßnahmen zur Abwehr des Risikos ergriffen wurden. Im Anschluss erfolgt die Bewertung der Auswirkungen, auch hier gilt die Bewertung erfolgt unabhängig, ob Maßnahmen bereits ergriffen wurden oder nicht. Jetzt kommt der alles entscheidende Aspekt, kann das Risiko getragen werden oder nicht. Bei der abschließenden Bewertung sollten jetzt alle zuvor bereits benannten vorhandenen Maßnahmen in die Bewertung mit einfliessen. Für eine bessere Nachvollziehbarkeit der Bewertung sollte eine kurze Zusammenfassung hinterlegt werden. Idealerweise wird in die Dokumentation der Risikobewertung auch ein Ausblick auf das Risiko mit aufgenommen, sofern zusätzliche Maßnahmen vorgeschlagen werden. Sollte ein Audit anstehen oder durch eine veränderte Sachlage eine erneute Bewertung notwendig sein, kann die Zusammenfassung der Bewertung super nachgenutzt werden. Insofern bei der Bewertung des Risikos ein untragbar gewährt wurde, muss entschieden werden, wie weiterverfahren wird (Risikoakzeptanz, Risikoreduzierung oder Risikotransfer). Hierzu dient die Zeile Risikobehandlung und leitet so in den Maßnahmenbehandlungsplan über.

Schritt 10 - Maßnahmenbehandlungsplan

Transfers näher betrachtet. Darauf aufbauend, muss ein KMU Kriterien für die Risikoakzeptanz festlegen und basierend auf dieser Festlegung die Risikobehandlung aufbauen. Bei der Entscheidung, wie mit den identifizierten Risiken umge­gangen wird, muss auf jeden Fall die Geschäftsführung durch den Informationssicherheitsbeauftragten involviert werden, da sich aus der getroffenen Entscheidung unter Umständen erhebliche Schäden ergeben oder zusätzliche Kosten entstehen können.

Für jede Gefährdung mit Risikoeinstufung „untragbar“ müssen folgende Fragen beantwortet werden:

1. Ist es sinnvoll, das Risiko durch eine Umstrukturierung des Geschäftsprozesses zu vermeiden? Gründe für diesen Ansatz können beispielsweise sein:
   1. Alle wirksamen Gegenmaßnahmen sind mit hohem Aufwand verbunden und damit sehr teuer, die verbleibende Gefährdung kann aber trotzdem nicht hingenommen werden.
   2. Die Umstrukturierung bietet sich ohnehin aus anderen Gründen an, z. B. zur Kostensenkung.
   3. Es kann einfacher und eleganter sein, die vorhandenen Abläufe zu ändern, als sie durch Hinzufü­gen von Sicherheitsmaßnahmen komplexer zu machen.
   4. Alle wirksamen Gegenmaßnahmen würden erhebliche Einschränkungen für die Funktion oder den Komfort des Systems mit sich bringen.
2. Ist es sinnvoll und möglich, das Risiko durch weitere Sicher­heitsmaßnahmen zu reduzieren? Das Risiko durch die verbleibende Gefährdung kann möglicherweise gesenkt werden, indem eine oder mehrere ergänzende Sicherheitsmaßnahmen erarbeitet und umgesetzt werden oder noch nicht vollumfänglich umgesetzte Anforderungen aus den BSI Bausteinen mit in die Roadmap aufgenommen werden. Als Quellen für potenzielle ergänzende Sicherheitsmaßnahmen kommen infrage:
   1. die Dokumentation und der Service des Herstellers und Dienstleister und
   2. Standards und Best Practices, wie sie beispielsweise von Gremien im Bereich der Informationssi­cherheit erarbeitet werden.
3. Ist es sinnvoll, das Risiko beispielsweise durch den Abschluss eines Versicherungsvertrags oder durch Outsourcing an andere zu übertragen? Gründe für diesen Ansatz können beispielsweise sein:
   1. Die möglichen Schäden sind rein finanzieller Art.
   2. Es ist ohnehin aus anderen Gründen geplant, Teile der Geschäftsprozesse auszulagern.
   3. Der Vertragspartner ist aus wirtschaftlichen oder technischen Gründen besser in der Lage, mit dem Risiko umzugehen.

So wie bereits zuvor die Bewertung der Risiken dokumentiert wurde, müssen auch die ergänzenden Sicherheitsmaßnahmen für die spätere Planung und Beobachtung dokumentiert werden. Bei der Dokumentation der ergänzenden Maßnahmen sollte unterschieden werden in noch offene Maßnahmen aus dem BSI IT-Grundschutz und tatsächlich zusätzlichen Maßnahmen. Um diese übergreifend katalogisieren zu können, bittet sich das folgende Schema an. Für die Behandlung offener Risiken wird einerseits auf die noch offenen Grundschutzmaßnahmen „oGM [Schicht].[Nr.]“ verwiesen, sofern diese ausreichen, um das Risiko geeignet zu behandeln. Sollte dies nicht möglich sein, wird ergänzend eine zusätzliche Maßnahme „ZM [Schicht].[Nr.]“ evaluiert. Dabei bezeichnet [Schicht] die entsprechende Themengruppe und [Nr.] eine fortlaufende Nummer pro Schicht. Die Schichten sind:

• 01 - ISMS
• 02 – ORP
• 03 – CON
• 04 – OPS
• 05 – DER
• 06 – APP
• 07 – SYS
• 08 – IND
• 09 – NET
• 10 – INF

Auflistung aller Zusatzmaßnahmen zur Reduzierung des Risikos

Dieser Abschnitt fasst die in der Risikoanalyse beschriebenen Zusatzmaßnahmen nach den Schichten des BSI-IT-Grundschutz Kompendiums zusammen und benennt jeweils den aktuellen Umsetzungsstatus.

Schicht ISMS

Schicht ORP (Organisation und Personal)

Schicht CON (Konzepte und Vorgehensweisen)

Schicht OPS (Betrieb)

Schicht DER (Detektion und Reaktion)

Schicht APP (Anwendungen)

Schicht SYS (IT-Systeme)

Schicht IND (Industrielle IT)

Schicht NET (Netze und Kommunikation)

Schicht INF (Infrastruktur)

Auflistung aller besonderen Restrisiken

In der Risikoanalyse wurden die folgenden verbleibenden Restrisiken (RR) identifiziert, die von der Geschäftsführung bewusst übernommen werden.

Literaturverzeichnis