03200 Aufbau und Einführung eines Informationssicherheitsprozesses
|
Der Beitrag beschreibt einen Weg, die Informationssicherheit für eine eigenständige Organisations- oder Unternehmenseinheit systematisch zu analysieren und nachhaltig zu verbessern. Die Informationssicherheit wird dabei als kontinuierlicher Prozess verstanden, der als Teil eines bestehenden Managementsystems implementiert werden kann. Die beschriebenen Prozessschritte harmonieren sowohl mit der Qualitätsmanagementnorm ISO 9001 als auch mit der ISO/IEC 27001 für Informationssicherheitsmanagementsysteme. Sie haben insofern Mustercharakter, als sich spezifische Ausprägungen an ihnen orientieren können. Ihre Dokumentation führt im Verlauf der Umsetzung schrittweise zu einem Informationssicherheitshandbuch. Voraussetzung für die erfolgreiche Einführung des Prozesses ist, dass die Initiative dafür von der jeweiligen Leitungs- und Managementebene der Organisations- oder Unternehmenseinheit ausgeht, die Informationssicherheit von dieser getragen und vorgelebt wird. Arbeitshilfen: von: |
1 Der Informationssicherheitsprozess (ISP)
Warum Prozess?
Will eine Behörde, Organisation oder ein Unternehmen (im Folgenden unter dem Begriff Institution zusammengefasst) ihre Arbeits- respektive Wettbewerbsfähigkeit erhalten und in Richtung Digitalisierung ausbauen, muss die Infrastruktur entsprechend den Möglichkeiten der rasant fortschreitenden Informationstechnologie kontinuierlich modernisiert und an die sich ändernden Anforderungen angepasst werden. Die Informationssicherheit als zunehmend wichtiger Erfolgsfaktor muss dabei Schritt halten.
Will eine Behörde, Organisation oder ein Unternehmen (im Folgenden unter dem Begriff Institution zusammengefasst) ihre Arbeits- respektive Wettbewerbsfähigkeit erhalten und in Richtung Digitalisierung ausbauen, muss die Infrastruktur entsprechend den Möglichkeiten der rasant fortschreitenden Informationstechnologie kontinuierlich modernisiert und an die sich ändernden Anforderungen angepasst werden. Die Informationssicherheit als zunehmend wichtiger Erfolgsfaktor muss dabei Schritt halten.
In immer mehr Branchen und Bereichen wird zudem von Unternehmen und Organisationen (z. B. Betreiber kritischer Infrastrukturen, Automobilzulieferer, Bahnsystemhersteller) erwartet oder sogar regulativ oder vertraglich verlangt, dass sie für Informationssicherheit (häufig auch als IT-Sicherheit, Informationsschutz oder Cyber Security bezeichnet) einen angemessenen Sicherheitsprozess implementiert haben und nachhaltig betreiben sowie dies ggf. auch gegenüber Dritten nachweisen können.
Die Informationssicherheit darf nicht wie vielerorts angenommen als einmalige Anstrengung aufgefasst werden, sondern muss als kontinuierlicher Prozess implementiert werden. Ein solcher Prozess bildet die Grundlage für die systematische und regelmäßige Analyse von Bedrohungen und Risiken und fördert die Planung, Umsetzung und Überprüfung angemessener Sicherheitsmaßnahmen. Richtig eingeführt und vorangetrieben, beeinflusst er die Kultur einer Institution derart, dass alle Mitarbeiter und Beteiligten
| • | die Sensitivität von Informationen bewusster wahrnehmen, |
| • | die informationstechnischen Einrichtungen sicher(er) und verantwortungsvoll(er) nutzen sowie |
| • | Verständnis entwickeln für proaktive Maßnahmen in Bezug auf Risiken für Mitarbeiter, Vermögenswerte und die Fortführung der Geschäftstätigkeit. |
Teil des Managementsystems
Im Beitrag verwenden wir den Begriff Prozess und nicht Managementsystem, um deutlich zu machen, dass der Informationssicherheitsprozess als Teil eines bestehenden Managementsystems aufgefasst wird. Bei einem Managementsystem wird davon ausgegangen, dass es Politik, organisatorische Struktur, Verantwortlichkeiten, Planungsaktivitäten, Praktiken, Prozeduren, Prozesse und Ressourcen in einem gemeinsamen Rahmen miteinander verknüpft.
Im Beitrag verwenden wir den Begriff Prozess und nicht Managementsystem, um deutlich zu machen, dass der Informationssicherheitsprozess als Teil eines bestehenden Managementsystems aufgefasst wird. Bei einem Managementsystem wird davon ausgegangen, dass es Politik, organisatorische Struktur, Verantwortlichkeiten, Planungsaktivitäten, Praktiken, Prozeduren, Prozesse und Ressourcen in einem gemeinsamen Rahmen miteinander verknüpft.
Für den Aufbau und die Einführung eines Informationssicherheitsprozesses kann auf bewährte Vorgehensweisen zurückgegriffen werden. Überträgt man die recht weit verbreiteten Erfahrungen im Bereich der Qualitätsmanagementsysteme auf einen Informationssicherheitsprozess, lassen sich für dessen Aufbau und Betrieb folgende wesentliche Schritte ableiten (s. Abbildung 1):
| Prozessschritte | |
| • | Festlegen der Sicherheitsziele, |
| • | Ermitteln des Schutzbedarfs, |
| • | Analyse der Bedrohungen und Risiken, |
| • | Festlegen und Implementieren der Sicherheitsmaßnahmen sowie |
| • | Prüfen der Wirksamkeit der Maßnahmen. |
Auch für die Schaffung der organisatorischen und personellen Voraussetzungen sollte auf Erfahrungen aus dem Qualitätsmanagementbereich zurückgegriffen werden. Bei kleinen Institutionen reicht häufig schon ein fachlich weisungsfreier und von der zu überwachenden Tätigkeit unabhängiger Informationssicherheitsbeauftragter. Größere Institutionen sollten einen entscheidungsbefugten Lenkungsausschuss installieren mit Schnittstellen zu lokal organisierten Sicherheitsteams.
1.1 Voraussetzungen
KonTraG
Laut Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) obliegt die allgemeine Verantwortung für den Fortbestand eines Unternehmens (Kapitalgesellschaften wie AGs und größere GmbHs) und damit auch die Gewährleistung der Informationssicherheit seiner Führung. Sie muss den Sicherheitsprozess initiieren, steuern und überwachen.
Laut Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) obliegt die allgemeine Verantwortung für den Fortbestand eines Unternehmens (Kapitalgesellschaften wie AGs und größere GmbHs) und damit auch die Gewährleistung der Informationssicherheit seiner Führung. Sie muss den Sicherheitsprozess initiieren, steuern und überwachen.
ITSiG
Laut dem IT-Sicherheitsgesetz (ITSiG) – es gilt seit Mai 2021 in einer erweiterten novellierten Form als IT-Sicherheitsgesetz 2.0 – gelten für die Betreiber kritischer Infrastrukturen (z. B. Verkehrsinfrastruktur, Energiewirtschaft, Telekommunikationsnetze) besondere Anforderungen zum Schutz der Komponenten, Systeme, Elemente und Prozesse zum Betrieb der kritischen Infrastruktur in der Bundesrepublik Deutschland. Auch diese Anforderungen lassen sich von den betroffenen Institutionen nur durch einen von der Führungsebene initiierten, gesteuerten und überwachten Sicherheitsprozess erfüllen.
Laut dem IT-Sicherheitsgesetz (ITSiG) – es gilt seit Mai 2021 in einer erweiterten novellierten Form als IT-Sicherheitsgesetz 2.0 – gelten für die Betreiber kritischer Infrastrukturen (z. B. Verkehrsinfrastruktur, Energiewirtschaft, Telekommunikationsnetze) besondere Anforderungen zum Schutz der Komponenten, Systeme, Elemente und Prozesse zum Betrieb der kritischen Infrastruktur in der Bundesrepublik Deutschland. Auch diese Anforderungen lassen sich von den betroffenen Institutionen nur durch einen von der Führungsebene initiierten, gesteuerten und überwachten Sicherheitsprozess erfüllen.
Management ergreift Initiative
Idealerweise muss von der Führungsebene
Idealerweise muss von der Führungsebene
| • | die Initiative für die Informationssicherheit ausgehen, |
| • | die Verantwortung für die Informationssicherheit übernommen werden, |
| • | die notwendigen Ressourcen (Personal, Zeit, Geld) müssen bereitgestellt werden und |
| • | die Herausforderung Informationssicherheit müssen aktiv unterstützt werden. |
Management ist Vorbild
Die Leitung der Institution übernimmt damit gewissermaßen eine Vorbildfunktion. Wenn diese Randbedingungen in der konkreten Situation nicht gegeben sind, sollte zunächst versucht werden, auf operativer Ebene fehlende Sicherheitsmaßnahmen umzusetzten. In jedem Fall sollte aber darauf hingewirkt werden, das Management für die Belange der Informationssicherheit und sein Haftungsrisiko (vgl. KonTraG) bei verletzter Sorgfaltspflicht zu sensibilisieren, sodass es zukünftig seiner Verantwortung Rechnung trägt. Gelingt dies nicht, ist erfahrungsgemäß kein nachhaltiger Informationssicherheitsprozess in einer Institution einzuführen.
Die Leitung der Institution übernimmt damit gewissermaßen eine Vorbildfunktion. Wenn diese Randbedingungen in der konkreten Situation nicht gegeben sind, sollte zunächst versucht werden, auf operativer Ebene fehlende Sicherheitsmaßnahmen umzusetzten. In jedem Fall sollte aber darauf hingewirkt werden, das Management für die Belange der Informationssicherheit und sein Haftungsrisiko (vgl. KonTraG) bei verletzter Sorgfaltspflicht zu sensibilisieren, sodass es zukünftig seiner Verantwortung Rechnung trägt. Gelingt dies nicht, ist erfahrungsgemäß kein nachhaltiger Informationssicherheitsprozess in einer Institution einzuführen.
Pilotprojekt starten
Nicht nur in schwierigen Entscheidungssituationen hat es sich bewährt, zunächst ausgewählte Geschäftsprozesse oder gut abgrenzbare technische Einheiten als Pilotprojekt einem Informationssicherheitsprozess zu unterwerfen. Dabei gesammelte Erfahrungen beim Aufbau, bei der Implementierung und im Betrieb sind nicht nur lehrreich, sondern können auch überzeugend auf Entscheidungsträger wirken.
Nicht nur in schwierigen Entscheidungssituationen hat es sich bewährt, zunächst ausgewählte Geschäftsprozesse oder gut abgrenzbare technische Einheiten als Pilotprojekt einem Informationssicherheitsprozess zu unterwerfen. Dabei gesammelte Erfahrungen beim Aufbau, bei der Implementierung und im Betrieb sind nicht nur lehrreich, sondern können auch überzeugend auf Entscheidungsträger wirken.
1.2 ISP – Stellgröße im Managementsystem
Aus Managementsicht ist es hilfreich, den Informationssicherheitsprozess als Stellgröße zu betrachten, die wie in einem Regelkreis nachgeführt wird (s. Abbildung 2).
Mit dem Festlegen der Sicherheitspolitik und den nachgeordneten Sicherheitszielen wird das angestrebte Sicherheitsniveau als Sollgröße festgelegt. Sie bestimmen den Schutzbedarf der einzelnen (manuellen) Verfahren und informationstechnischen Netzwerke, Systeme oder Komponenten.
Ausschlaggebend ist Geschäftsprozess
Ausschlaggebend ist dabei die Bedeutung des Geschäftsprozesses, den das jeweilige Verfahren oder das informationstechnische (IT) System unterstützt. Entsprechend der Natur eines Regelkreises werden
Ausschlaggebend ist dabei die Bedeutung des Geschäftsprozesses, den das jeweilige Verfahren oder das informationstechnische (IT) System unterstützt. Entsprechend der Natur eines Regelkreises werden
| • | Störgrößen (Bedrohungen/Risiken) analysiert, |
| • | ein Soll/Ist-Vergleich wird durchgeführt (Sicherheitsdefizite identifizieren), |
| • | die Stellgröße ermittelt (Sicherheitsmaßnahmen definieren) und |
| • | deren Umsetzung überwacht (wiederholt Soll und Ist vergleichen). |
Die dafür zu treffenden Regelungen und das zugrunde liegende Konzept sollten entsprechend einem prozessorientierten Qualitätsmanagementsystem (z. B. ISO 9001 [1]) selbst diesem Prozess unterworfen sein. Sie sollten kontinuierlich den Erkenntnissen aus der Praxis angepasst werden.
1.3 Von Einzelregelungen über das Konzept zum Informationssicherheitshandbuch
Die Festlegungen zum Sicherheitsprozess sollten in die vorhandene Dokumentationsstruktur (z. B. in die vom QM-System vorgegebene) der Institution passen (s. Abbildung 3).
Bewährte Dokumentationsstrukturen
Die Dokumentation legt nicht nur Anwendungsbereich, Konzept, Abläufe usw. fest. Die Nutzung eines vorhandenen Dokumentationssystems erhöht auch die Übersichtlichkeit und Akzeptanz des Informationssicherheitsprozesses und verschafft Klarheit über die Verantwortlichkeiten. Sie vereinfacht die Pflege der einzelnen Dokumente, verknüpft alte und neu zu erstellende sicherheitsrelevante Einzelregelungen mit vorhandenen Organisations-, Verfahrens- oder Arbeitsanweisungen und minimiert den zusätzlichen Dokumentationsaufwand.
Die Dokumentation legt nicht nur Anwendungsbereich, Konzept, Abläufe usw. fest. Die Nutzung eines vorhandenen Dokumentationssystems erhöht auch die Übersichtlichkeit und Akzeptanz des Informationssicherheitsprozesses und verschafft Klarheit über die Verantwortlichkeiten. Sie vereinfacht die Pflege der einzelnen Dokumente, verknüpft alte und neu zu erstellende sicherheitsrelevante Einzelregelungen mit vorhandenen Organisations-, Verfahrens- oder Arbeitsanweisungen und minimiert den zusätzlichen Dokumentationsaufwand.
Auch ohne QM-System existieren in vielen Institutionen auf Arbeitsebene Regelungen zur Datensicherheit, häufig in Form von Regelungen zur Passwortvergabe, von Merkblättern für den PC-Arbeitsplatz, von Festlegungen zur Serverkonfiguration oder von Netzwerkplänen u. Ä. Solche Regelungen bieten eine Grundlage zur (Neu-)Ordnung der Dokumentation des Informationssicherheitsprozesses.
Best Practice finden
Hat sich eine Methode oder eine Regelung in der Praxis bewährt (sogenannte Best Practice), sollte sie für alle Betroffenen dokumentiert, vermittelt und für verbindlich erklärt werden. Nach und nach werden die Einzelregelungen zu einem Sicherheitskonzept zusammengefügt, das sich in einer „Einschwingphase” zum Informationssicherheitshandbuch entwickelt.
Hat sich eine Methode oder eine Regelung in der Praxis bewährt (sogenannte Best Practice), sollte sie für alle Betroffenen dokumentiert, vermittelt und für verbindlich erklärt werden. Nach und nach werden die Einzelregelungen zu einem Sicherheitskonzept zusammengefügt, das sich in einer „Einschwingphase” zum Informationssicherheitshandbuch entwickelt.
Soll das Sicherheitskonzept/Informationssicherheitshandbuch in ein bestehendes Dokumentationssystem (des QM-Systems) integriert werden, ist mit den zuständigen Personen vorab abzuwägen, in welchem Dokument (Sicherheits- oder QM-Handbuch) welche Festlegungen getroffen werden. Insbesondere zu Aspekten der Organisationsstruktur und des Personals sind Überschneidungen unausweichlich. Grundsätzlich sollten redundante Festlegungen vermieden werden. Diese erhöhen die Gefahr von missverständlicher Auslegung oder widersprüchlichen Regelungen. Häufig können Konflikte durch Verwendung von Verweisen aufgelöst werden.
2 Sicherheitsziele
Die Leitungs- bzw. Managementebene muss sich im Klaren darüber sein bzw. werden, was ihr ihre Informationen und Daten bedeuten.
Eine Aufgabe des Managements
Ist es das Know-how, das zu schützen ist? Ist es die Verfügbarkeit von Informationen, welche die Grundlage für intakte Geschäfts-/Produktionsprozesse oder schnelle Entscheidungen bilden? Ist es das Persönlichkeitsrecht jener, deren Daten automatisiert verarbeitet werden? Oder ist es die Integrität der Daten, die über die Unversehrtheit von Leib und Leben entscheiden kann? ... Wenn das Management die Initiative für die Informationssicherheit ergriffen hat, wird es diese Fragen bereits beantwortet haben.
Ist es das Know-how, das zu schützen ist? Ist es die Verfügbarkeit von Informationen, welche die Grundlage für intakte Geschäfts-/Produktionsprozesse oder schnelle Entscheidungen bilden? Ist es das Persönlichkeitsrecht jener, deren Daten automatisiert verarbeitet werden? Oder ist es die Integrität der Daten, die über die Unversehrtheit von Leib und Leben entscheiden kann? ... Wenn das Management die Initiative für die Informationssicherheit ergriffen hat, wird es diese Fragen bereits beantwortet haben.
Jedenfalls sollten aus diesen Überlegungen heraus die institutionsspezifischen Sicherheitsziele formuliert werden (Beispiel s. Tabelle 1). Diese Ziele werden nicht geheim gehalten, sondern institutionsweit bekannt gegeben und allen Mitarbeitern vermittelt. Dies kann beispielsweise im Rahmen der Einarbeitung neuer Mitarbeiter, von Abteilungsbesprechungen oder von Mitarbeitergesprächen geschehen.[
03200_a.docx]
03200_a.docx]Tabelle 1: Beispiel für Sicherheitsziele
Informationssicherheit bedeutet für uns, dass unsere Kernprozesse, deren Wirksamkeit wir durch Einsatz modernster Mittel der Informations- und Kommunikationstechnik ständig weiterentwickeln, unter Minimierung der unvermeidbaren Restrisiken | ||||||||||||||
| ||||||||||||||
Konkret verfolgen wir im Rahmen unseres Informationssicherheitsprozesses folgende Sicherheitsziele: | ||||||||||||||
| ||||||||||||||
Um diese Ziele zu erreichen, praktizieren wir umfangreiche Maßnahmen, deren Vollständigkeit, Wirksamkeit und Angemessenheit kontinuierlich überprüft werden. |
3 Feststellung des Schutzbedarfs
Keine Sicherheitsmaßnahme sollte getroffen werden, ohne dass vorher geklärt worden ist, was sie wie wirksam schützen soll. Eine systematische Planung von Sicherheitsmaßnahmen erfordert für jeden Geschäftsprozess und für die zugehörigen Verfahren, Daten, IT-Anwendungen und -Systeme, den Schutzbedarf bezüglich Vertraulichkeit, Integrität und Verfügbarkeit festzustellen. Im Allgemeinen ist dies nicht mit größeren Schwierigkeiten verbunden, weil Management und Mitarbeiter eines Unternehmens sehr genau die Bedeutung ihrer Geschäftsprozesse – auch wenn diese oft nicht so genannt werden – und die Schwachstellen der IT-Anwendungen und Verfahren kennen, gegeneinander abwägen und einordnen können.
Systematisch das Wesentliche finden
Mit einer systematischen Schutzbedarfsfeststellung wird erreicht, dass sich die weiteren Sicherheitsbetrachtungen gezielt auf die wirklich schützenswerten Verfahren, Daten und informationstechnischen Systeme beschränken können. Denn auch bei der Planung und Realisierung von Sicherheitsmaßnahmen ist darauf zu achten, dass Nutzen und Aufwand (monetärer und nichtmonetärer) in einem angemessenen Verhältnis zum Schutzzweck stehen. Die Angemessenheit der Maßnahmen stellt sicher, dass weder durch lückenhaften Schutz die Schutzziele gefährdet werden noch ein überdimensionierter Schutz die Wirtschaftlichkeit infrage stellt und bei den betroffenen Anwendern zu Akzeptanzproblemen führt. Bei fehlender Differenzierung der Sicherheitsmaßnahmen ist zu befürchten, dass tendenziell höherwertige und damit oftmals zu aufwendige Maßnahmen getroffen werden.
Mit einer systematischen Schutzbedarfsfeststellung wird erreicht, dass sich die weiteren Sicherheitsbetrachtungen gezielt auf die wirklich schützenswerten Verfahren, Daten und informationstechnischen Systeme beschränken können. Denn auch bei der Planung und Realisierung von Sicherheitsmaßnahmen ist darauf zu achten, dass Nutzen und Aufwand (monetärer und nichtmonetärer) in einem angemessenen Verhältnis zum Schutzzweck stehen. Die Angemessenheit der Maßnahmen stellt sicher, dass weder durch lückenhaften Schutz die Schutzziele gefährdet werden noch ein überdimensionierter Schutz die Wirtschaftlichkeit infrage stellt und bei den betroffenen Anwendern zu Akzeptanzproblemen führt. Bei fehlender Differenzierung der Sicherheitsmaßnahmen ist zu befürchten, dass tendenziell höherwertige und damit oftmals zu aufwendige Maßnahmen getroffen werden.
Die Schutzbedarfsanalyse gliedert sich in drei Schritte:
| • | Festlegen von Schutzbedarfskategorien, |
| • | Zuordnen des Schutzbedarfs von Geschäftsprozessen, Verfahren und IT-Anwendungen, |
| • | Ableiten des Schutzbedarfs einzelner IT-Systeme und -Infrastrukturkomponenten. |
3.1 Schritt 1: Einstufung des Schutzbedarfs
Ausgehend von der Möglichkeit, dass Vertraulichkeit, Integrität oder Verfügbarkeit eines Geschäftsprozesses bzw. der zugehörigen Daten verloren gehen, werden maximale potenzielle Schäden abgeschätzt, die aus einer solchen Situation entstehen können. Weil der daraus abzuleitende Schutzbedarf nur schwer quantifizierbar ist, haben sich qualitative Aussagen in Form von Schutzkategorien für die weitere Betrachtung durchgesetzt. Dafür können abhängig vom Untersuchungsobjekt verschiedene Kriterien herangezogen werden. Das Beispiel in Tabelle 2 zeigt eine denkbare Klassifizierung.
Tabelle 2: Beispiel zur Klassifizierung des Schutzbedarfs
Schutzbedarfsstufe | Schadensauswirkung | Schadenswert in Euro | Grad der einzuhaltenden Vertraulichkeit | Zeit-/Mittelaufwand zur Schadensbehebung |
1 | Unbedeutend | bis 1.000 | Offen | Geringfügig |
2 | Gering | > 1.000 | Nur für den Dienstgebrauch | Vertretbar |
3 | Mittel | > 10.000 | Vertraulich | Erheblich |
4 | Groß | > 100.000 | Geheim | Sehr umfangreich, nicht kalkulierbar |
5 | Existenzgefährdend | > 1 Mio. | Streng geheim | Nicht leistbar |
Aus Gründen der Praktikabilität ist es nicht sinnvoll, eine zu weit gehende Differenzierung vorzunehmen. In der Praxis hat es sich bewährt, drei bis fünf Schutzkategorien festzulegen.
Eine weitere Möglichkeit, eine Einstufung vorzunehmen, zeigt die folgende Kriterientabelle (s. Tabelle 3). Der Geschäftsprozess inkl. der zugehörigen IT-Anwendungen und Daten wird einer der Schutzbedarfsstufen zugeordnet, wenn mindestens eines der aufgelisteten Kriterien zutrifft.[ 03200_b.docx]
03200_b.docx]Tabelle 3: Dreistufige Kriterientabelle als Checkliste
Stufe | Kriterien | |
|---|---|---|
1 | □ | Finanzielle Verluste sind begrenzt und überschaubar. |
□ | Entsprechende Daten werden als nur für den Dienstgebrauch eingestuft. | |
□ | Die tolerierbare Ausfallzeit kann bis zu 48 Stunden betragen. | |
□ | Ein Einzelsystem mit wenigen Anwendern ist betroffen. | |
□ | Verstöße gegen Verträge, Vorschriften oder Gesetze haben keine oder nur geringfügige Konsequenzen. | |
□ | Der Missbrauch der Daten hat nur geringfügige wirtschaftliche Auswirkungen. | |
□ | Eine geringe/nur interne Ansehens- oder Vertrauensbeeinträchtigung. | |
□ | Eine Beeinträchtigung persönlicher Unversehrtheit erscheint nicht möglich. | |
2 | □ | Beträchtliche finanzielle Verluste. |
□ | Entsprechende Daten werden als vertraulich eingestuft. | |
□ | Die tolerierbare Ausfallzeit liegt bei maximal 12 Stunden. | |
□ | Eine noch überschaubare Zahl von Systemen/Anwendern ist betroffen. | |
□ | Verstöße gegen Verträge, Vorschriften oder Gesetze haben nicht unerhebliche Konsequenzen (z. B. Konventionalstrafen). | |
□ | Der Missbrauch der Daten hat große Auswirkungen auf die gesellschaftliche Stellung und/oder die wirtschaftlichen Verhältnisse des Standorts. | |
□ | Eine breite Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten. | |
□ | Eine Beeinträchtigung der persönlichen Unversehrtheit kann nicht absolut ausgeschlossen werden. | |
3 | □ | Finanzielle Verluste können existenzbedrohende Ausmaße erreichen. |
□ | Entsprechende Daten werden als streng vertraulich eingestuft. | |
□ | Die maximal tolerierbare Ausfallzeit ist kleiner als eine Stunde. | |
□ | Alle wichtigen Systeme mit sehr vielen Anwendern sind betroffen. | |
□ | Verstöße gegen Verträge, Vorschriften oder Gesetze haben fundamentale Auswirkungen (z. B. ruinöse Haftungsschäden). | |
□ | Der Missbrauch der Daten hat existenzgefährdende Auswirkungen auf die gesellschaftliche Stellung und/oder die wirtschaftlichen Verhältnisse. | |
□ | Eine totale Ansehens- oder Vertrauensbeeinträchtigung. | |
□ | Gravierende Beeinträchtigungen der persönlichen Unversehrtheit sind möglich: Gefahr für Leib und Leben. | |
Datenschutz einbeziehen
Generell ist es sinnvoll, bei der Schutzbedarfsfeststellung nicht nur die Anforderungen der Datensicherheit (Schutz der Informationen) zu berücksichtigen, sondern gleichgewichtig auch die Belange des Datenschutzes (Schutz der Personen) zu beachten. Um Abgrenzungsprobleme zu vermeiden, sollte in Kenntnis, dass i. d. R. der Datenschutz eine Untermenge der Datensicherheit darstellt, eine unabhängige Bewertung und Einstufung für beide Bereiche vorgenommen werden. Die jeweils höherwertige Einstufung bestimmt dann letztlich die Sicherheitsanforderungen einer Anwendung oder eines Verfahrens.
Generell ist es sinnvoll, bei der Schutzbedarfsfeststellung nicht nur die Anforderungen der Datensicherheit (Schutz der Informationen) zu berücksichtigen, sondern gleichgewichtig auch die Belange des Datenschutzes (Schutz der Personen) zu beachten. Um Abgrenzungsprobleme zu vermeiden, sollte in Kenntnis, dass i. d. R. der Datenschutz eine Untermenge der Datensicherheit darstellt, eine unabhängige Bewertung und Einstufung für beide Bereiche vorgenommen werden. Die jeweils höherwertige Einstufung bestimmt dann letztlich die Sicherheitsanforderungen einer Anwendung oder eines Verfahrens.
Die Tabelle 4 enthält ein weiteres Beispiel möglicher Schutzbedarfskategorien, zusätzlich getrennt nach den Gesichtspunkten des Datenschutzes (s. a. DSGVO – Datenschutz-Grundverordnung und BDSG – Bundesdatenschutzgesetz) und der Datensicherheit.
Tabelle 4: Schutzbedarfskategorien getrennt nach Datenschutz und der Datensicherheit
Schutzbedarf | Datensicherheit | Datenschutz |
|---|---|---|
Niedrig | Daten, deren Modifizierung, Verlust oder Missbrauch keine besondere Beeinträchtigung der Geschäftsprozesse erwarten lässt | Frei zugängliche Daten, in die Einsicht gewährt wird, ohne dass der Einsichtnehmende ein berechtigtes Interesse geltend machen muss |
Mittel | Daten, deren Modifizierung, Verlust oder Missbrauch Geschäftsprozesse beeinträchtigt | Personenbezogene Daten, deren Missbrauch zwar keine besondere Beeinträchtigung erwarten lässt, deren Kenntnisnahme jedoch an ein berechtigtes Interesse des Einsichtnehmenden gebunden ist |
Hoch | Daten, deren Modifizierung, Verlust oder Missbrauch Geschäftsprozesse erheblich beeinträchtigt | Personenbezogene Daten, deren Missbrauch den Betroffenen in seiner rechtlichen sowie beruflichen Stellung innerhalb und außerhalb der Institution beeinträchtigen kann |
Sehr hoch | Daten, deren Modifizierung, Verlust oder Missbrauch die Handlungsfähigkeit der Institution gefährdet | Personenbezogene Daten, deren Missbrauch den Betroffenen in seiner rechtlichen sowie beruflichen Stellung innerhalb und außerhalb der Institution erheblich beeinträchtigen kann |
3.2 Schritt 2: Zuordnen des Schutzbedarfs
Ausgehend von der Möglichkeit, dass Vertraulichkeit, Integrität oder Verfügbarkeit eines Geschäftsprozesses bzw. der zugehörigen Daten verloren gehen, werden nach Definition der Schutzkategorien die maximalen Schäden und Folgeschäden, die daraus entstehen können, abgeschätzt. Unter der Fragestellung „Was wäre, wenn ... ?” werden dafür realistische Schadensszenarien durchgespielt und die betrachteten Prozesse dann den oben angegebenen zu erwartenden materiellen oder ideellen Schäden zugeordnet. Die Systematik dieses Schemas spiegelt der Auszug einer Ergebnistabelle eines kleineren Unternehmens wider (s. Tabelle 5).
Tabelle 5: Ergebnistabelle
Schutzbedarf | Geschäftsprozess | IT-Anwendung/Daten | Bemerkung |
Niedrig | Standard-, Büro- und Kommunikationssoftware, insbesondere Textverarbeitung ... | PCs, WORD, EXCEL, ACCESS, Fileserver im LAN,Cloud-Daten | Sofern nicht vertraulichen und/oder aufbewahrungswürdigen Inhalts (dann mittel bis hoch) |
Mittel | Kundenverwaltung | KUVA Plus | Einplatzversion |
Finanzbuchhaltung
Rechnungsprüfung, Kostenrechnung
Verwaltung
Rechnungsausgang
Projekt-Controlling | WORD, EXCEL, ACCESS-Anwendung Windows Server, Windows Clients,Cloud-Anwendungen | Datenträger an externe Steuerberater | |
Personalverwaltung
Lohnbuchhaltung, Kostenrechnung,
Arbeitszeitverwaltg. | ACCESS-Applikationen, Fileserver im Office-LAN | ||
Lagerverwaltung | EasyStock IV | ||
... | ... | ||
Hoch | Produktionsplanung | P-Composer, P-Retriever (Power 550 Express) (Produktionsdaten) | Kernprozess, Datenverlust oder -verfälschung haben Produktionsausfall zur Folge |
Produktionssteuerung | Snap Ultimate (Prozessdaten), SPS Siemens S7 | Bei Ausfall, Maschinen- und Produktionsstillstand | |
... | ... |
3.3 Schritt 3: Ableiten des Schutzbedarfs einzelner IT-Systeme und -Infrastrukturkomponenten
Aus den zugeordneten IT-Anwendungen lassen sich in einem weiteren Detaillierungsschritt (quasi als vierte Spalte) die beteiligten IT-Systeme und Infrastrukturkomponenten ableiten. Zu diesem Schritt zählt auch die Zuordnung des Schutzbedarfs einzelner Infrastrukturkomponenten wie Netzwerkkomponenten, Übertragungsstrecken oder Räumlichkeiten.
Ansatz über Bestandslisten
Besteht nicht die Chance, Geschäftsprozesse zu definieren, kann der Schutzbedarf grundsätzlich auch auf der Basis der erfassten IT-Systeme und Infrastrukturkomponenten festgestellt werden. Die Bedeutung oder Kritikalität des jeweiligen IT-Systems bestimmt dann dessen Schutzbedarf. Das Ergebnis ist dasselbe. Nur wird die Spalte Geschäftsprozesse durch eine Beschreibung oder Begründung der Einordnung des Systems ersetzt. Und jedem IT-System (abzuleiten aus der IT-Anwendung) ist eine Schutzkategorie zugeordnet, d. h., auch die Reihenfolge in der Tabelle wird anders.
Besteht nicht die Chance, Geschäftsprozesse zu definieren, kann der Schutzbedarf grundsätzlich auch auf der Basis der erfassten IT-Systeme und Infrastrukturkomponenten festgestellt werden. Die Bedeutung oder Kritikalität des jeweiligen IT-Systems bestimmt dann dessen Schutzbedarf. Das Ergebnis ist dasselbe. Nur wird die Spalte Geschäftsprozesse durch eine Beschreibung oder Begründung der Einordnung des Systems ersetzt. Und jedem IT-System (abzuleiten aus der IT-Anwendung) ist eine Schutzkategorie zugeordnet, d. h., auch die Reihenfolge in der Tabelle wird anders.
Inventur der IT-Systeme
Der Ansatz über die IT-Systeme bietet sich auch dann an, wenn die IT-Systeme bereits inventarisiert sind. Es ist ratsam, dafür eine Datenbank zu nutzen, weil damit eine vollständige bzw. vervollständigbare Bestandsliste aller bestehenden IT-Systeme (Hardware, Software, Netzkomponenten, ...) erstellt werden kann. Eine elektronische Bestandsaufnahme erleichtert erfahrungsgemäß die Verwaltung der Systempflege und schafft u. a. die Voraussetzung für ein Software-Lizenzmanagement.
Der Ansatz über die IT-Systeme bietet sich auch dann an, wenn die IT-Systeme bereits inventarisiert sind. Es ist ratsam, dafür eine Datenbank zu nutzen, weil damit eine vollständige bzw. vervollständigbare Bestandsliste aller bestehenden IT-Systeme (Hardware, Software, Netzkomponenten, ...) erstellt werden kann. Eine elektronische Bestandsaufnahme erleichtert erfahrungsgemäß die Verwaltung der Systempflege und schafft u. a. die Voraussetzung für ein Software-Lizenzmanagement.
Best Practice festhalten
Hat sich eine Methode der Schutzbedarfsfeststellung in der Praxis bewährt, sollte sie in das Sicherheitskonzept/Informationssicherheitshandbuch aufgenommen werden. Zu verwendende Hilfsmittel zur systematischen Ergebnisaufzeichnung (Tabelle, Formulare, Datenbank, ...) sollten darin nicht fehlen.
Hat sich eine Methode der Schutzbedarfsfeststellung in der Praxis bewährt, sollte sie in das Sicherheitskonzept/Informationssicherheitshandbuch aufgenommen werden. Zu verwendende Hilfsmittel zur systematischen Ergebnisaufzeichnung (Tabelle, Formulare, Datenbank, ...) sollten darin nicht fehlen.
4 Bedrohungsanalyse
Jene Objekte, die einen hohen oder mittleren Schutzbedarf besitzen, werden einer Bedrohungsanalyse unterzogen. Dies ist ein notwendiger Schritt, um den Schwerpunkt der Sicherheitsmaßnahmen festzulegen. Dafür werden Szenarien wie z. B. die nachfolgend aufgelisteten in geeignet zusammengesetzten Arbeitsgruppen durchgespielt:
| Szenarien vorwegnehmen | |
| • | Ausfall von Hardwarekomponenten, |
| • | Versagen der Software, |
| • | unsicher konfigurierte Systeme, |
| • | Fehlhandlungen/fehlerhafte Eingaben durch Administratoren, Anwender oder Kunden, |
| • | unzureichende/verlorene personelle Ressourcen (Qualifikation, Reaktionszeit, Erreichbarkeit, ...), |
| • | juristische Konsequenzen aus Verstoß gegen Gesetze oder Vorschriften (KontraG, IT-Sicherheitsgesetz, DSGVO, BDSG, GOBS, Urheberrechtsschutz, Brandschutzvorschriften, ...), |
| • | Angriffe durch Hacker, |
| • | Viren, Trojaner u. Ä., |
| • | Spionage, Verrat von Betriebsgeheimnissen und Firmen- Know-how durch Mitarbeiter usw. |
Eine sehr umfangreiche Zusammenstellung von möglichen Bedrohungen, dort Elementare Gefährdungen genannt liefert das IT-Grundschutz-Kompendium des BSI [2].
Für die Einstufung ist es erforderlich, Benutzer und Verantwortliche der betrachteten IT-Anwendung und Daten nach ihrer Einschätzung zu befragen bzw. einzubinden. Sie haben im Allgemeinen eine gute Vorstellung davon, welche Schäden entstehen können. Das Ergebnis dieser Analyse könnte sich wie in Tabelle 6 darstellen (Auszug).
Tabelle 6: Beispiel: Ergebnis aus Bedrohungsanalyse
P-Retriever (Schutzbedarf hoch) | ||
Bedrohung | Vorbeugungsmaßnahmen | Bemerkung/Handlungsbedarf |
Ausfall der Hardware | Bewährtes System, USV, RAID-System, tägliches Back-up, Servicevertrag, innerhalb 12 h Ersatz | In den letzten zwei Betriebsjahren keine HW-Ausfälle; System-Shutdown zu geplanten Wartungsintervallen |
Versagen der Software (Softwarefehler) | Vertrauenswürdige QS des Lieferanten, bewährtes Produkt, Service-Hotline, erprobte Restarts, Back-up and Restore-Routinen (s. VA Back-up and Restore) | Nur ein Ansprechpartner, Know-how-Transfer, Urlaubsplanung |
Fehlende Plausibilitätsabfrage bei Eingaben (Designfehler) | Gründliche Validationsprozeduren, u. a. durch vertraglich festgelegte Abnahmebedingungen (Tests durch AN und AG, s. VA ...) Erprobungsphase | Know-how-Transfer, Bedienpersonal schulen (s. mitgeltende Anlage x) |
Virenbefall | Keine direkte Anbindung an öffentliches Netz, Power 550 Express unempfindlich für Virenbefall | – |
Manipulierte Produktionsparameter | Zugangs- und Zugriffsberechtigung/Rechteprüfung, Systemadministration | Hash-Code zu jedem Datensatz (s. mitgeltende Anlage y), Audit Trail |
Urheber einer Eingabe nicht eindeutig | Eingabe nur nach Authentisierung, Verknüpfung von Passwort, Datum/Zeit zur elektronischen Signatur (s. VA Passwort-Management) | Audit Trail nachrüsten |
... | ||
Die Analysen sollten fester Bestandteil des Informationssicherheitsprozesses werden, die immer dann durchzuführen sind, wenn nennenswerte Änderungen der Geschäftsprozesse und der IT-Infrastruktur anstehen. Auf diese Weise werden systematisch konkrete, nicht mehr tolerierbare Sicherheitsdefizite der (geplanten) IT-Anwendungen und -Objekte identifiziert, denen frühzeitig durch geeignete Maßnahmen begegnet werden kann.
Folgenabschätzung für Datenschutz
Auf ähnliche Weise kann der Datenschutzbeauftragte im Rahmen seiner Datenschutz-Folgenabschätzung (nach BDSG bzw. DSGVO, s. Kap. 07103) vorgehen. Seine Analysen beschränken sich auf die personenbezogenen Daten. Er orientiert sich vornehmlich an dem Schutzziel des informationellen Selbstbestimmungsrechts von Personen (z. B. der Mitarbeiter, Kunden, Patienten, Mitglieder oder Geschäftspartner).
Auf ähnliche Weise kann der Datenschutzbeauftragte im Rahmen seiner Datenschutz-Folgenabschätzung (nach BDSG bzw. DSGVO, s. Kap. 07103) vorgehen. Seine Analysen beschränken sich auf die personenbezogenen Daten. Er orientiert sich vornehmlich an dem Schutzziel des informationellen Selbstbestimmungsrechts von Personen (z. B. der Mitarbeiter, Kunden, Patienten, Mitglieder oder Geschäftspartner).
Detailtiefe festlegen
Die Gefahr, dass sich die Arbeitsgruppen bei der Diskussion der Bedrohungen und Maßnahmen in Einzelheiten verlieren und vom Thema abkommen, ist nicht zu vernachlässigen. Deshalb sollten die Bedrohungen konsequent nur bis zu einer festgelegten Detaillierungstiefe erörtert und festgehalten werden (Beispiele s. Tabelle 6). Es ist ratsam, gerade zu Anfang die Arbeitsgruppen von möglichst unabhängiger Seite moderieren zu lassen. Die Analysen können zu einem späteren Zeitpunkt, ggf. mit anders besetzten Arbeitskreisen auf nachgeordneten Ebenen (z. B. für einzelne Anwendungsprogramme, Regeln für Passwortvergabe oder für die Erstellung von Berechtigungsprofilen), fortgeführt werden.
Die Gefahr, dass sich die Arbeitsgruppen bei der Diskussion der Bedrohungen und Maßnahmen in Einzelheiten verlieren und vom Thema abkommen, ist nicht zu vernachlässigen. Deshalb sollten die Bedrohungen konsequent nur bis zu einer festgelegten Detaillierungstiefe erörtert und festgehalten werden (Beispiele s. Tabelle 6). Es ist ratsam, gerade zu Anfang die Arbeitsgruppen von möglichst unabhängiger Seite moderieren zu lassen. Die Analysen können zu einem späteren Zeitpunkt, ggf. mit anders besetzten Arbeitskreisen auf nachgeordneten Ebenen (z. B. für einzelne Anwendungsprogramme, Regeln für Passwortvergabe oder für die Erstellung von Berechtigungsprofilen), fortgeführt werden.
Risikobetrachtung
Im Verlauf der Bedrohungsanalyse stoßen die Arbeitsgruppen erfahrungsgemäß auf Handlungsbedarf. Betrachtet man Sicherheit nach der ursprünglichen Definition des BSI als
Im Verlauf der Bedrohungsanalyse stoßen die Arbeitsgruppen erfahrungsgemäß auf Handlungsbedarf. Betrachtet man Sicherheit nach der ursprünglichen Definition des BSI als
„IT-Sicherheit bezeichnet einen Zustand, in dem die Risiken, die beim Einsatz von Informationstechnik aufgrund von Bedrohungen und Schwachstellen vorhanden sind, durch angemessene Maßnahmen auf ein tragbares Maß reduziert sind”,
ist dieser Bedarf nichts anderes als das intuitive Streben, ein identifiziertes Risiko auf ein akzeptables Maß (Restrisiko) zu bringen. Bei überschaubaren Größenordnungen (kleine Organisationseinheiten, eingeschränkter Anwendungsbereich, einfache IT-Strukturen, ...) reicht die Bedrohungsanalyse zur Einleitung von Sicherheitsmaßnahmen in der oben beschriebenen Form i. d. R. aus. Häufig verlangen aber die Komplexität der organisatorischen/informationstechnischen Strukturen, die Kritikalität der Anwendungen oder auch einzuhaltende Richtlinien eine weitergehende Risikoabschätzung. Eine Risikoabschätzung, wie beispielsweise in der ISO/IEC 27005 [3] gefordert (vgl. Kap. 02515), lässt sich wie in Abbildung 5 gezeigt darstellen.
Das Grundkonzept bei der Risikoabschätzung ist: je größer das vorhersehbare Risiko, desto genauer die Analyse und desto höher die Qualität der risikobeherrschenden Maßnahmen.
Gegenüber der Bedrohungsanalyse kommen bei der Risikoabschätzung zwei Dimensionen hinzu (vgl. Abbildung 6):
| Dimensionen der Risikoabschätzung | |
| 1. | die Wahrscheinlichkeit eines bedrohenden Ereignisses (Eintrittswahrscheinlichkeit) und |
| 2. | das Schadensausmaß als Folge des eingetretenen bedrohenden Ereignisses. |
Zwar impliziert die oben dargestellte Ergebnistabelle der Bedrohungsanalyse diese beiden Dimensionen, indem Handlungsbedarf konstatiert wird oder nicht, jedoch kommen die Bewertungen aus dem „Bauch” heraus und sind im Zweifelsfall wenig belastbar. Eine systematische Herleitung bzw. ein Nachweis der Abwesenheit von Risiken ist darin nicht enthalten.
Das Schadensausmaß kann in ähnlicher Weise definiert werden wie die oben vorgeschlagenen Schutzbedarfskategorien. Die Tabelle 7 liefert ein entsprechendes Beispiel.
Tabelle 7: Beispielkategorien für das Schadensausmaß
Schadensausmaß | Schadensauswirkung | Schadenswert in Euro | Zeit-/Mittelaufwand zur Schadensbehebung |
1 | Existenzgefährdend | > 50.000 | Sehr umfangreich, nicht kalkulierbar |
2 | Mittel | > 10.000 | Erheblich |
3 | Unbedeutend | bis 1.000 | Geringfügig |
Eintrittswahrscheinlichkeit
Für die Eintrittswahrscheinlichkeit sind Kategorien definierbar wie z. B.:
Für die Eintrittswahrscheinlichkeit sind Kategorien definierbar wie z. B.:
| 1 = häufig | (Wahrscheinlichkeit > 75 %) |
| 2 = vorstellbar | (Wahrscheinlichkeit > 25 %) |
| 3 = selten | (Wahrscheinlichkeit ≤ 25 %) |
| 4 = unvorstellbar | (Wahrscheinlichkeit ˜ 0) |
Das Risiko ergibt sich aus der Multiplikation der Eintrittswahrscheinlichkeit und des Schadensausmaßes. Den Zusammenhang zeigt beispielhaft die Abbildung 6.
Für Risiken im Grenzbereich bei 2 (in der Abbildung durch „x” markiert) und 3 (in der Abbildung durch „o” markiert) ist abzuwägen, ob der praktische oder wirtschaftliche Nutzen das Restrisiko überwiegt und damit akzeptabel ist oder nicht. Die Entscheidung über akzeptable Risiken obliegt dabei der Arbeitsgruppe. In Zweifelsfällen, bei denen aufwendige Sicherheitsmaßnahmen oder große Restrisiken abzuwägen sind, sollte das Management zur Entscheidung hinzugezogen werden.
Das praktische Vorgehen bei der Risikoabschätzung unterscheidet sich unwesentlich von dem der Bedrohungsanalyse; derselbe Arbeitskreis wird aktiv, dieselben Mittel kommen zum Einsatz. Nur werden zusätzlich die risikomindernden Maßnahmen und das akzeptierte Restrisiko systematischer hergeleitet. Abbildung 7 zeigt, wie die Ergebnisse der Risikoabschätzung strukturiert und dokumentiert werden können.
Risikoabschätzung – eine kontinuierliche Sache
Wesentlich für den Informationssicherheitsprozess ist auch hier: Bedrohungsanalyse und Risikoabschätzung sind nicht als einmalige Anstrengung zu verstehen. Es ist ein kontinuierlicher Prozess, der im Rahmen von Neuentwicklungen, bei Änderungen in der IT-Infrastruktur, den Abläufen oder bei neuen Erkenntnissen zu wiederholen ist (vgl. Abbildung 1). Die ISO/IEC 27001 [4] (vgl. Kap. 02511) verdeutlicht dies an den Forderungen an den Prozess zur Risikoeinschätzung. Durch Risikoeinschätzungen in geplanten Intervallen muss dieser sicherstellen, dass das Restrisiko auch nach Änderungen (z. B. in Organisation, Technologie, Bedrohungen, Wirksamkeit von Maßnahmen) auf einem akzeptablen Niveau bleibt.
Wesentlich für den Informationssicherheitsprozess ist auch hier: Bedrohungsanalyse und Risikoabschätzung sind nicht als einmalige Anstrengung zu verstehen. Es ist ein kontinuierlicher Prozess, der im Rahmen von Neuentwicklungen, bei Änderungen in der IT-Infrastruktur, den Abläufen oder bei neuen Erkenntnissen zu wiederholen ist (vgl. Abbildung 1). Die ISO/IEC 27001 [4] (vgl. Kap. 02511) verdeutlicht dies an den Forderungen an den Prozess zur Risikoeinschätzung. Durch Risikoeinschätzungen in geplanten Intervallen muss dieser sicherstellen, dass das Restrisiko auch nach Änderungen (z. B. in Organisation, Technologie, Bedrohungen, Wirksamkeit von Maßnahmen) auf einem akzeptablen Niveau bleibt.
Best Practice festhalten
Hat sich eine Methode der Bedrohungsanalyse und Risikoabschätzung in der Praxis bewährt, sollte sie in das Sicherheitskonzept/Informationssicherheitshandbuch und ggf. in eine separate Verfahrensanweisung aufgenommen werden. Vorgaben zur Ergebnisaufzeichnung (Tabellen, Formulare, Datenbank, ...) dürfen darin nicht fehlen.
Hat sich eine Methode der Bedrohungsanalyse und Risikoabschätzung in der Praxis bewährt, sollte sie in das Sicherheitskonzept/Informationssicherheitshandbuch und ggf. in eine separate Verfahrensanweisung aufgenommen werden. Vorgaben zur Ergebnisaufzeichnung (Tabellen, Formulare, Datenbank, ...) dürfen darin nicht fehlen.
5 Festlegen von Sicherheitsmaßnahmen
Nachdem feststeht, welche Maßnahmen umgesetzt werden sollen, werden diese im Sinne des ISP
| • | dokumentiert, |
| • | geplant, |
| • | vom Management einschließlich entsprechender Ressourcen freigegeben, |
| • | erprobt, |
| • | vermittelt und eingeführt, |
| • | überwacht und ggf. korrigiert. |
Zu beachten sind Maßnahmen, die Interaktionen des Kunden, eines Partners oder eines externen Mitarbeiters erfordern und gegebenenfalls vertraglich abgestimmt werden müssen.
Festlegungen fürs Sicherheitshandbuch
Die Maßnahmen (sowie auch deren spätere Korrektur/Anpassung/Optimierung) sollten zeitnah, spätestens nach deren Erprobung, dokumentiert werden. Auf diese Weise können im Laufe der Maßnahmenumsetzung bzw. der Prozesseinführung einzelne sicherheitsbezogene Festlegungen im Sicherheitskonzept zum Sicherheitshandbuch „reifen”.
Die Maßnahmen (sowie auch deren spätere Korrektur/Anpassung/Optimierung) sollten zeitnah, spätestens nach deren Erprobung, dokumentiert werden. Auf diese Weise können im Laufe der Maßnahmenumsetzung bzw. der Prozesseinführung einzelne sicherheitsbezogene Festlegungen im Sicherheitskonzept zum Sicherheitshandbuch „reifen”.
Die Möglichkeiten, die getroffenen Maßnahmen in Form von Regelungen in einem Handbuch zu strukturieren und zu dokumentieren, sind vielfältig. Normen und Standards sind in diesem Punkt uneinheitlich und sehr umfassend. Sehr leicht führt die Übernahme ihrer Struktur zum Übermaß an Regelungen, was wiederum den ganzen Informationssicherheitsprozess gefährden kann. Ausgangsbasis sollte die eigene gewachsene Struktur sein. Wegen ihrer Allgemeingültigkeit wird hier folgende Gliederung vorgeschlagen:
| Eigene Struktur finden | |
| • | Informationssicherheitsprozess |
| • | Organisation und Personal |
| • | Bautechnische Infrastruktur |
| • | Informations- und kommunikationstechnische Infrastruktur |
| • | IT-Systemadministration |
| • | Arbeitsplatz und Benutzerverantwortung |
Hinter Informationssicherheitsprozess verbirgt sich die Beschreibung des auf die Institution zugeschnittenen Informationssicherheitsprozesses unter ablauforientierten Gesichtspunkten: beginnend mit Sicherheitszielen bis hin zur Überwachung des Prozesses.
In Organisation und Personal werden die für den Sicherheitsprozess relevante organisatorische Struktur, Verantwortlichkeiten und die Ressourcen beschrieben.
Die Kapitel Bautechnische Infrastruktur, Informations- und kommunikationstechnische Infrastruktur, IT-Systemadministration sowie Arbeitsplatz und Benutzerverantwortung stellen eine grobe Gliederung der Sicherheitsmaßnahmen dar.
Details zu den Inhalten der einzelnen Kapitel sind in den jeweiligen vertiefenden Kapiteln des ISM weiter ausgeführt.
6 Überwachung der Maßnahmen
Kontrolle notwendig
Die Erfahrung zeigt, dass ohne Kontrolle Regelungen nicht nachhaltig umgesetzt werden können bzw. eingehalten werden. Dies gilt insbesondere für „unbequeme” Sicherheitsmaßnahmen, deren Effekt nicht unmittelbar (sondern i. d. R. erst dann, wenn es zu spät ist) spürbar ist. Die Überwachung ist also entscheidend für einen wirksamen und andauernden Informationssicherheitsprozess.
Die Erfahrung zeigt, dass ohne Kontrolle Regelungen nicht nachhaltig umgesetzt werden können bzw. eingehalten werden. Dies gilt insbesondere für „unbequeme” Sicherheitsmaßnahmen, deren Effekt nicht unmittelbar (sondern i. d. R. erst dann, wenn es zu spät ist) spürbar ist. Die Überwachung ist also entscheidend für einen wirksamen und andauernden Informationssicherheitsprozess.
Überwachung durch Auditierung
Die Überwachung des ISP hat viel mit der Auditierung eines Qualitätsmanagementsystems gemeinsam. Sie dient der internen Prüfung der Einhaltung und Effektivität der Sicherheitsmaßnahmen und ist erforderlich für die Durchsetzung, Erweiterung und Verbesserung der Maßnahmen. Spätestens hier wird deutlich, warum die Dokumentation als Vorgabe so wesentlich ist. Wogegen will man sonst prüfen? Was ist das Soll? ... Aus seiner Verantwortung heraus sollte das Management eines Unternehmens ein starkes Interesse an der Wirksamkeit und Wirtschaftlichkeit des Gesamtprozesses besitzen und entsprechende Ressourcen dafür schaffen.
Die Überwachung des ISP hat viel mit der Auditierung eines Qualitätsmanagementsystems gemeinsam. Sie dient der internen Prüfung der Einhaltung und Effektivität der Sicherheitsmaßnahmen und ist erforderlich für die Durchsetzung, Erweiterung und Verbesserung der Maßnahmen. Spätestens hier wird deutlich, warum die Dokumentation als Vorgabe so wesentlich ist. Wogegen will man sonst prüfen? Was ist das Soll? ... Aus seiner Verantwortung heraus sollte das Management eines Unternehmens ein starkes Interesse an der Wirksamkeit und Wirtschaftlichkeit des Gesamtprozesses besitzen und entsprechende Ressourcen dafür schaffen.
Zeigt sich, dass Lücken oder Mängel im Prozess bestehen, müssen Korrekturen vorgenommen werden. Häufig sind derartige Korrekturen im Bereich der Schulung oder der Motivation (z. B. bei fehlender Akzeptanz) anzusiedeln. Sind Wirksamkeit und Wirtschaftlichkeit nicht zufriedenstellend, müssen die betroffenen Verfahren, Methoden, Einrichtungen oder Werkzeuge überdacht werden.
Korrekturmaßnahmen sind grundsätzlich nicht negativ zu bewerten. Fortschritte in der Technik, unzureichende Information, Organisationsänderungen, neue Erkenntnisse können Anlässe für Korrekturen oder Veränderungen sein. Es sollte stets der Grundsatz gelten: „Es gibt keine Fehler, sondern lediglich Feedback.”
Wichtig: Regelmäßige Überprüfungen
Zeitpunkt und Häufigkeit der Überprüfungen richten sich nach der Art des Prüfobjekts. Für automatisierte Sicherheits- Checks (z. B. bestimmte Installationsprozeduren, Auswertungen oder Ereignisse) mag eine sofortige Prüfung sinnvoll sein. Für andere Verfahren kann es genügen, sie erst nach Sicherheitsvorfällen, Änderungen, Modernisierungen, neuen Erkenntnissen zu überprüfen. Vom Grundsatz her sollte jedoch die Gesamtheit der Sicherheitsmaßnahmen verteilt über ein Jahr überprüft werden.
Zeitpunkt und Häufigkeit der Überprüfungen richten sich nach der Art des Prüfobjekts. Für automatisierte Sicherheits- Checks (z. B. bestimmte Installationsprozeduren, Auswertungen oder Ereignisse) mag eine sofortige Prüfung sinnvoll sein. Für andere Verfahren kann es genügen, sie erst nach Sicherheitsvorfällen, Änderungen, Modernisierungen, neuen Erkenntnissen zu überprüfen. Vom Grundsatz her sollte jedoch die Gesamtheit der Sicherheitsmaßnahmen verteilt über ein Jahr überprüft werden.
Interne QM-Audits nutzen
Wie bei einem QM-System sollten die Überprüfungen langfristig geplant und vorbereitet werden. Sie können mit den internen Audits des QM-Systems kombiniert werden. Die Überprüfungen bzw. Audits sollten vom zuständigen Information-Security-Beauftragten – ggf. mit externer Unterstützung – durchgeführt/begleitet werden. Die Überprüfungsobjekte ergeben sich aus den festgelegten Maßnahmen. Ihre Umsetzung sollte möglichst mittels Checklisten hinterfragt werden. Sie können z. B. umfassen:
Wie bei einem QM-System sollten die Überprüfungen langfristig geplant und vorbereitet werden. Sie können mit den internen Audits des QM-Systems kombiniert werden. Die Überprüfungen bzw. Audits sollten vom zuständigen Information-Security-Beauftragten – ggf. mit externer Unterstützung – durchgeführt/begleitet werden. Die Überprüfungsobjekte ergeben sich aus den festgelegten Maßnahmen. Ihre Umsetzung sollte möglichst mittels Checklisten hinterfragt werden. Sie können z. B. umfassen:
| Beispiele für Checklisten | |
| • | Nutzung und Aktualität sicherheitsgerichteter Werkzeuge (Virenscanner, Verschlüsselungstools, Zugangssoftware ...), |
| • | Konfiguration sicherheitswirksamer Hardware und Software, |
| • | Aufzeichnungen über Sicherheitsverletzungen (Security Logs), |
| • | Aufbewahrungsort vertraulicher Unterlagen, |
| • | Ablage/Speicherung sensitiver Daten am Arbeitsplatz-PC |
| • | Aktualität von Back-up-Datenträgern, |
| • | Zutrittsschutz zu bestimmten Gebäudebereichen (z. B. Rechenzentren und Serverräumen), |
| • | Security-Policy der Firewall, |
| • | Auswertung relevanter Stellungnahmen von Kunden oder |
| • | Aufzeichnung und Verfolgung von Sicherheitsvorfällen. |
Korrekturmaßnahmen verfolgen
Festgestellte Abweichungen und Korrekturmaßnahmen müssen dokumentiert und verfolgt werden. Zur Bewertung der Wirksamkeit des Sicherheitsprozesses in seiner Gesamtheit sollten die Ergebnisse im Hinblick auf die Sicherheitsziele aufbereitet und mit der Unternehmensleitung erörtert werden.
Festgestellte Abweichungen und Korrekturmaßnahmen müssen dokumentiert und verfolgt werden. Zur Bewertung der Wirksamkeit des Sicherheitsprozesses in seiner Gesamtheit sollten die Ergebnisse im Hinblick auf die Sicherheitsziele aufbereitet und mit der Unternehmensleitung erörtert werden.
Quellen
1
DIN EN ISO 9001:2015, Qualitätsmanagementsysteme – Anforderungen; englischer Titel: Quality management systems – Requirements (ISO 9001:2015)
2
Bundesamt für Sicherheit in der Informationstechnik (BSI), IT-Grundschutz-Kompendium, www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/it-grundschutz-kompendium_node.html
3
ISO/IEC 27005:2018, Informationstechnik – IT-Sicherheitsverfahren – Informationssicherheits-Risikomanagement
4
ISO/IEC 27001:2013, Informationstechnik – IT-Sicherheitsverfahren – Informationssicherheits-Managementsysteme – Anforderungen
