Kochbuch ISMS E-Book

Thomas Ili

• Herausgeber: Books on Demand
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch

Seitenzahl: 492

Veröffentlichungsjahr: 2022

Beschreibung

Dieses Buch führt in umgänglicher, leicht verständlicher Sprache in dieses weitläufige Thema der Informationssicherheit und insbesondere in die Umsetzung der ISO 27001 ein. Es liefert konkrete und praxisorientierte Hinweise, die einzelnen Anforderungen aus der ISO 27001 und seinem internen Kontrollsystem (ISO 27002) umzusetzen, ohne den kritischen Blick auf die Branche 'Informationssicherheit' auszusparen. Aufgrund seiner Vielseitigkeit, ist dieses Buch nicht nur für Beginner und Manager, sondern auch für verantwortliche Personen der Informationssicherheit sowie für Berater und Auditoren geeignet. Die Anforderungen der ISO 27001 sind mit Audithinweisen und gegebenenfalls mit Messzielen versehen, um die kontinuierlichen Verbesserungen der eigenen Leistung bewerten zu können. Darüber hinaus wagt der Auditor auch den Blick über den Tellerrand und liefert, wenn es angebracht scheint, den Zugang zu weiteren Technologien und Standards. Ein weiteres Alleinstellungsmerkmal ist der abschließende Blick auf die IT-Sicherheit und Cybersecurity sowie alternative Rahmenwerke und die Anpassung der Organisationskultur auf eine optimierte Informationssicherheit.

Leseprobe

INHALTSVERZEICHNIS

INHALTSVERZEICHNIS

EINLEITUNG

1.1 Definitionen

1.2 Kurzbeschreibung informationssicherheits-Managementsystem

(ISMS)

1.3 Kurzbeschreibung ISO 27001

1.4 Auditprozess

1.5 Machbarkeitsanalyse ISMS

ISO 27001 RAHMENWERK

. ISO 27001 PLAN-PHASE

2.1 Kapitel 4 „Verstehen der Organisation und ihres Kontextes”

2.2 Kapitel 5 „Führung”

2.3 Kapitel 6 „Planung”

. ISO 27001 DO-PHASE

2.4 Kapitel 7 „Support”

2.5 Kapitel 8 „Betrieb”

. ISO 27001 CHECK-PHASE

2.6 Kapitel 9 „Bewertung der Leistung”

. ISO 27001 ACT-PHASE

2.7 Kapitel 10 „Verbesserung”

RISIKO MANAGEMENT

3.1 ISO 31000

3.2 ISO 27005

3.3 BILI Risiko Management

INTERNES KONTROLLSYSTEM

4.1 „A 5 - Informationssicherheitsrichtlinien”

4.2 „A 6 - Organisation der Informationssicherheit”

4.3 „A 7 - Personalsicherheit”

4.4 „A 8 - Verwaltung der Werte”

4.5 „A 9 - Access Control”

4.6 „A10 - Cryptography”

4.7 „A11 - Physical and Environmental Security”

4.8 „A12 -Betriebssicherheit”

4.9 „A13 - Communications Security”

4.10 „A14 - System Acquisition, Development and Maintenance”

4.11 „A15 - Supplier Relationships”

4.12 „A16 - Handhabung von Informationssicherheitsvorfällen”

4.13 „A17 - Informationssicherheitsaspekte beim Business Continuity Management”

4.14 „A 18 - Compliance”

IT-SICHERHEIT

5.1 Vorgehen des Hackers

5.2 Geläufige IT-Attacken

WEITERE RAHMENWERKE DER INFORMATIONSSICHERHEIT

6.1 ISO 27001 auf der Basis von IT-Grundschutz

(IT-Grundschutz)

6.2 CISIS12

6.3 MaRisk&BAIT

6.4 ISAE 3402 & SSAE 18

6.5 PCI-DSS

(Payment Card Industry Data Security Standards)

6.6 NIST 800

6.7 FISMA & FedRAMP

6.8 ISF

(Information Security Forum)

KULTUR DER INFORMATIONSSICHERHEIT

7.1 Versuchsaufbau “Kultur der Informationssicherheit”

7.2 Anpassung der Informationssicherheitskultur

7.3 Informationssicherheitskulturkonzept

7.4 Regelbetrieb

ZUM SCHLUSS: DAS ZERTIFIZIERUNGSVERFAHREN

8.1 ISO 17011

8.2 ISO 17021

8.3 ISO 27006

8.4 Der Zertifizierungsprozess, unverblümt

ANHANG „ABBILDUNGSVERZEICHNIS“

ANHANG „PRAXIS-BEISPIELE“

1. EINLEITUNG

1.1 Definitionen

1.2 Kurzbeschreibung Informationssicherheits-Managementsystem (

ISMS

)

1.3 Kurzbeschreibung ISO 27001

1.4 Auditprozess

1.5 Machbarkeitsanalyse ISMS

Einleitend möchte ich erwähnen, dass ich versucht habe eine möglichst deutsche Sprachführung zu verwenden. Manch englische Begriffe haben sich jedoch derart eingedeutscht, dass es schwerfällt, diese durchgängig in Deutsch zu verwenden.

Die Informationssicherheit wird immer bedeutender. Das ist im Zeitalter der Informationen sicher nicht verwunderlich.

Das Zeitalter der Informationen wurde nicht eingeleitet, weil wir plötzlich alle angefangen haben zu lesen. Vielmehr liegt es an der Verarbeitung der Informationen. Wenn ich ein Buch verschicken möchte, muss das nicht erst zum Buchdrucker geliefert, gesetzt, gedruckt und anschließend verschickt werden, sondern es kann einfach elektronisch per eMail verschickt werden. In weniger als einer Minute ist dieses Buch beim Empfänger.

Wenn ich früher einen Vertrag vereinbaren musste, musste ich diesen per Hand schreiben und verschicken. Nur selten bin ich mit dem ersten Versuch fertig geworden und musste mehrere Exemplare erstellen.

Die Verarbeitung der Informationen findet in schwindelerregender Geschwindigkeit statt. Das führt nicht nur zum schnellen Austausch, sondern auch zum besonderen Nutzen. Maschinen werden nicht mehr handgesteuert und Rezeptbestandteile nicht mehr handgewogen und handgemischt.

Diese Verarbeitungsgeschwindigkeit führt auch zu mehr Vielfalt. Wenn ein Schneider früher froh war, sobald er den Schnitt für eine Jacke fertiggestellt hatte, kann eine Maschine mit einem Knopfdruck einfach ein neues Schnittmuster umsetzen.

Diese Beispiele zeigen, dass die Informationsverarbeitung nicht nur für mehr Geschwindigkeiten sorgt, sondern auch der Umfang der Verarbeitung steigt. Die Informationen nehmen eine immer bedeutendere Rolle ein.

Mit der größeren Bedeutung erhöht sich auch der Schutzbedarf dieser Informationen. Die Sicherheit der Informationen muss gewährleistet werden, da sonst die Maschinen still stehen oder die Konkurrenz schneller ist.

Früher hatte ich das Rezept im Kopf und zur Sicherung im Tresor. Heute liegt es auf dem Computer, in der SPS-Anlage und zur Sicherheit im Backup. Und alle Systeme sind mit dem Internet verbunden.

Mit der Bedeutung der Informationen wächst auch der Neid darauf und das Bedürfnis anderer, sich diese Informationen anzueignen. Die Zahl der Angreifer ist größer geworden, die Möglichkeiten durch die Vergrößerung der Schnittstellen vervielfacht.

Es wird deutlich, dass die Informationen geschützt werden müssen. Die zugehörige Disziplin ist die Informationssicherheit.

Die Informationssicherheit betrachtet die Risiken, die auf die Informationen wirken und schafft Maßnahmen, die diese Risiken verringern oder gar vermeiden sollen. Sie betrachtet dabei alle Organisationsbereiche und Abteilungen.

Wenn sich eine Organisation das erste Mal mit der Informationssicherheit beschäftigt, entsteht meist die Erwartungshaltung, dass es bereits ein Standardrezept für alles gibt. „Alles eine Soße“ scheinen die Verantwortlichen zu denken. Doch dem ist nicht so!

Das sollte schon beim Lesen dieser voranliegenden Zeilen klar sein. Doch es gibt noch weitere Aspekte, die zu berücksichtigen sind. Ein Zwei-Personen Unternehmen muss sicher andere Maßnahmen ergreifen, als ein zwanzigtausend mitarbeiterstarkes Unternehmen.

Und selbst im Vergleich zweier gleichgroßen Unternehmen gibt es Unterschiede. Sicherlich geht man in einem Maschinenbauunternehmen anders mit der Sicherheit von Informationen um, als in einem Software Entwicklungsunternehmen.

Selbst der Vergleich zwischen gleichgroßen Unternehmen in derselben Branche hinkt. Die Kultur in den zwei Unternehmen kann komplett unterschiedlich sein. Ein Unternehmen ist vielleicht eher prozessorientiert, während das andere Unternehmen nach „best practice” arbeitet. Jeder Mitarbeiter ist dann vielleicht mit maximalen Freiheiten ausgestattet und selbstverantwortlich, die best practices umzusetzen.

Wie sagte mir doch einmal ein „Vice President” eines Software Entwicklungsunternehmens: „Wir sind alles Künstler, Regeln schränken uns ein.”

So kleinkariert das auch klingen mag, dann ist dieses Unternehmen nicht für gängige Standardprozesse geeignet und nach meiner Einschätzung von Professionalität weit entfernt.

Ein Unternehmen oder eine Organisation, wie ich die allgemeine Bezeichnung in dem Buch synonym verwende, arbeitet nach Möglichkeit nach Zertifizierungsstandard. Das hat zum einen den Vorteil, dass diese Standards bereits nach „Best Practice” entstanden sind und zum anderen macht man sich damit vergleichbar.

Die Best Practices dieser Standards beruhen allerdings nicht auf die Erfahrungen der begrenzten Zahl an Mitarbeitern, sondern auf die Best Practices der ganzen Industrie. Eine Organisation kann sich zudem mit einem zertifizierten Standard seinen Kunden gegenüber rühmen und damit werben. Der Kunde weiß, dass diese Organisation gute Qualität abliefert, die Umwelt schützt oder die Informationen sichert. Je nachdem, welchen Mehrwert die Organisation für ihre Kunde liefert.

Dennoch: Informationssicherheit als Einheitsbrei, ist wie das Essen einer schlechten Großküche. Jedes Gericht ist verkocht und schmeckt irgendwie immer gleich.

Die Informationssicherheit erfordert für jede Organisation ihre eigene Menükarte und individuell abgeschmeckte Menüs.

In der Informationssicherheit wird die Menükarte in einem Managementsystem abgebildet.

Wie in jeder guten Menükarte werden zunächst einmal die Inhaltsstoffe vorgestellt. So beginnt dieses Buch nach der Einleitung auch mit der Definition vielleicht unbekannter oder widersprüchlicher Begrifflichkeiten. Damit die Inhalte dieses Buches auch für jeden interessierten Leser verständlich sind, möchte ich also die missverständlichen Begriffe kurz erläutern, sofern sie nicht ohnehin an geeigneter Stelle im Buch erklärt werden. Bitte stellen Sie sicher, dass Sie die hier genannten Definitionen kennen. Sie stellen das Verständnis im Buch sicher.

1.1 Definitionen

Audit & Auditor, Review & Revisor

Möchte eine Organisation die Einhaltung ihres ISMS auf einen Standard nachweisen, lässt sie sich auditieren. Ein Auditor überprüft auf Standard-Kompatibilität und kann dabei auf Reviews zurückgreifen.

Ein Review ist auf Arbeitsergebnisse begrenzt. Wie beim Audit können dazu Dokumente eingesehen, Mitarbeiter befragt oder Stichproben genommen werden.

Die Revision „reviewed” einzelne Arbeitsergebnisse, um die Wirtschaftlichkeit, die Zweck- und Ordnungsmäßigkeit sowie die Sicherheit einzelner Geschäftsprozesse und des internen Kontrollsystems zu überprüfen. Die interne Revision ist aus dem englischen Begriff „Internal Auditing” entstanden, weshalb die Abgrenzung zum standardprüfenden Auditor nicht konsequent stattfindet.

Best Practices

Sie beruhen auf Erfahrungen und stellen die vermeintlich besten Lösungen der Personen dar, die diese best practices auswählen. Standards beruhen auf best practices einer ganzen Industrie, sind jedoch nicht auf eine individuelle Organisation zugeschnitten.

BSI

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) untersteht dem Bundesministerium des Inneren und ist für den Schutz der Informationen in der Verwaltung, Wirtschaft und Gesellschaft sowie für die IT-Systeme des Bundes zuständig. Verwechslungsgefahr besteht zum britisch standard institute, das maßgeblich an der Entwicklung vieler Standards des Schweizer Normungsgremiums ISO beteiligt ist und dieselbe Abkürzung verwendet.

Clauses, Controls und Kapitel

Das interne Kontrollsystem enthält Controls. Warum unterschiedliche Sprachquellen verwendet werden, ist in der „Kurzbeschreibung Informationssicherheits-Managementsystem” beschrieben.

Die Controls sind jedenfalls in Clauses zusammengefasst. Diese Clauses sind unter Umständen noch einmal in Sub-Clauses unterteilt.

Das Ergebnis eines zentralen Risiko Management sind die Controls, um die Risiken zu verringern oder ganz auszuschalten. Das Rahmenwerk der ISO 27001 ist selbst nicht auf Controls aufgebaut. Seine Anforderungen sind in den Kapiteln der ISO 27001 formuliert. Die Mindestanforderung an Controls findet sich im Anhang A der ISO 27001.

Client / Server

Ein Server liefert den Service - den Dienst, den ein Client (Deutsch: Kunde) anfragt und anschließend erhält.

Wenn in der IT ein Dienst von einem anderen IT-System angenommen wird, handelt sich immer um eine Client-/Server-Beziehung. Das Dienst-anfragende IT-System ist der Client, das Dienst-Iiefernde IT-System ist der Server. Das gilt zum Beispiel auch in Peer-to-Peer Netzwerken, die eben gerade nicht eine Client-/Server-Beziehung darstellen. Das liegt daran, dass beide Partner abwechselnd als Client oder Server fungieren. Eine eindeutige Client-/Server-Beziehung lässt sich daraus nicht ableiten.

Hacker

Grundsätzlich bezeichnet ein Hacker jemanden, der sich systemnahe Kenntnisse der IT angeeignet hat. Der Begriff „Hacker” entstand in den Achtzigern für die Leute, die den ganzen Tag in die Tastaturen der damaligen Home-Computer „gehackt” haben. Sie sind die Nerds der Achtziger.

Als aus dieser Szene heraus die böswilligen Aktivitäten erfolgten, entwickelte sich die negative Assoziation für den Blackhat Hacker. Der ethisch gute Hacker ist der mit dem Whitehat. Der Greyhat Hacker hat zwar auch gute Absichten, nimmt es mit der Ethik jedoch nicht so genau.

laaS / PaaS / SaaS

Die Angebotspalette eines Cloud-Anbieters kann die Infrastructure-as-a-Service (laaS), die Platform-as-a-Service (PaaS) oder die Software-as-a-Service (SaaS) umfassen. Das Angebot geht dabei von einer reinen virtuellen Hardware-Infrastruktur aus, in der ein Kunde seine eigenen Systeme installiert (laaS), eine vorinstallierte Betriebssystem-Plattform (PaaS) erhält oder eine vollwertige Anwendungsumgebung (SaaS) nutzen kann. Der Kunde benötigt nur noch einen Teil an technischer Expertise, bis zu dem Punkt, an dem in der SaaS-Umgebung keine technische Kompetenz mehr erforderlich ist. Da diese „as-a-Service” Angebote aus Marketinggründen verschiedene Auswüchse genommen haben, wurde der Begriff „XaaS” geschaffen, um eine gemeinsame Bezeichnung aller Services zu schaffen.

IT-Sicherheit & Informationssicherheit in einem ISMS

Beiden Sparten der IT-Sicherheit und Informationssicherheit geht es um die Vertraulichkeit, Verfügbarkeit und Integrität der Informationen. Während die IT-Sicherheit dabei den Schutz der Informationen in der technischen Verarbeitung sicherstellen möchte, nimmt sich die Informationssicherheit der kompletten Verarbeitung innerhalb einer Organisation an. Eben auch dem Umgang mit Papierware oder dem persönlichen Zutritt sowie der Einhaltung juristischer Anforderungen und der technischen Informationssicherheit. Die IT-Sicherheit ist somit ein Teilbereich der Informationssicherheit.

Idealerweise setzt man dafür ein Informationssicherheits-Managementsystem (ISMS) ein. Ich stelle weitere Alternativen vor, jedoch ist das ISMS der ISO 27001 das Hauptthema dieses Buches.

Information Asset (IT-Asset)

Zusammengefasst aus der ISO 27005: „Ein IT-Asset ist alles, was für das Unternehmen von Wert ist und daher geschützt werden muss. Für jedes IT-Asset sollte ein Owner identifiziert werden, um die Verantwortung und Rechenschaftspflicht dafür zu übernehmen.”

Die ISO 27005 betrachtet „primäre Assets” als sensible Kernprozesse und sensible Informationen sowie „unterstützende Assets”, die bedroht werden können, um die primären Assets zu beeinträchtigen.

IT-Asset Owner & IT-Risk Owner

Beide Owner haben in der Regel keine Eigentumsrechte. Die „Ownerschaft” bezieht sich auf die Zuständigkeit und fachliche Verantwortung für das IT-Asset oder das IT-Risiko.

Neben der fachlichen Verantwortung gibt es immer auch reine rechtliche und damit wirtschaftliche Verantwortung, die bei der Geschäftsführung liegt. Insbesondere im Zusammenhang mit der „IT-Risk Ownerschaft” kann es dabei zu Verwechslungen kommen. In der Regel ist jedoch der fachliche Owner gemeint.

Key IT-Risk Indicator (KIRI)

Sie messen und zeigen die Wirksamkeit der Sicherheitsmaßnahmen auf. Generell sind sie vor allem für die Messung von Controls geeignet, können jedoch auch für die Messung von Maßnahmen aus dem Rahmenwerk verwendet werden.

Organisationen & Unternehmen

In dem Buch wird möglichst der weitläufigere Begriff Organisation statt Unternehmen verwendet, um non-Profit oder andere Organisationen in der Beschreibung nicht auszuschließen.

Wenn explizit gewinnorientierte Unternehmen gemeint sind, wird jedoch der Begriff „Unternehmen” synonym verwendet.

Risiko Management

Das Management ist die Verwaltung des Risikos. Dazu gehört die Risikoermittlung und das Risiko Assessment sowie die Risikoverfolgung und die Aktualisierung der Risikoeinschätzungen.

Die Risikoermittlung erfolgt über die Erhebung der IT-Assets sowie die Priorisierung über die Schutzbedarfsfeststellung und dann der Risikoanalyse. Da die Risikoanalyse bereits Teil des Risiko Assessment ist, lässt sich die Risikoermittlung nicht konsequent abgrenzen.

Ein Risiko Assessment ergänzt die Risikoanalyse durch die anschließende Bewertung des Risikos.

Für das Risiko Management ergibt sich daher folgendes Bild.

Abbildung 1: Risiko Management

Die Risikoanalyse hängt vom ausgewählten Risiko Management ab.

Sie enthält immer eine Bedrohungsanalyse aus der Kombination Bedrohung x Schwachstelle x Schutzbedarf. Sie kann jedoch noch eine Konsequenzanalyse beinhalten. Mehr dazu im Kapitel „Risiko Management”.

Management Informationssicherheitsereignis & Informationssicherheitsvorfall

Alles, was die Vertraulichkeit, Verfügbarkeit oder Integrität von Informationen beeinträchtigen kann, ist erst einmal ein Informationssicherheitsereignis. Sobald eines der Sicherheitskriterien (Vertraulichkeit, Verfügbarkeit, Integrität) verletzt wird, wird aus einem Ereignis ein Informationssicherheitsvorfall – im Englischen ein „information security incident”.

Um diesen Vorfall zu beherrschen, muss er „gemanaged” werden.

Stakeholder & Shareholder

Ein Stakeholder ist jeder Interessent der Organisation oder dessen Informationen. Es sind sowohl die Mitarbeiter als auch die Kunden, Lieferanten, Behörden oder sonstige Einheiten, die ein Interesse haben könnten.

Auch Shareholder gehören dazu. Sie sind die Anteilseigner und haben ein besonderes Interesse, das sich zumeist an einem ordentlichen Gewinn orientiert.

Zero-Day Attacke [0-Day Attacke)

Eine Schwachstelle, die noch niemand kennt, ist keine Bedrohung. Sie kann von niemanden ausgenutzt werden und stellt kein Risiko dar.

Kennt ein Angreifer jedoch eine Schwachstelle, die beim Betreiber noch unbekannt ist, ist der Angreifer im Vorteil. Für das Opfer beginnt der „Tag 0” für diese Schwachstelle. Dieser „Zero-Day” läuft erst ab, wenn es eine Maßnahme (in der Regel ein Patch) gegen diese Schwachstelle gibt.

Dieses Patch muss das Opfer nun noch installieren, um sich gegen diese Attacke zu schützen.

1.2 Kurzbeschreibung Informationssicherheits-Managementsystem (ISMS)

Wenn die Menükarte das Informationssicherheits-Managementsystem ist, ist das Risiko Management eine Beschreibung der Inhaltsstoffe. Die Controls wären dann die Preise für die jeweiligen Gerichte. Doch dazu nun mehr.

Wenn man nach Amerika guckt und die Unternehmen sieht, die sich auch in unseren Gefilden breitmachen, bekommen die Meisten Bauchschmerzen, beim Gedanken, wie diese mit unseren Informationen und personenbezogenen Daten umgehen. Oft haben die Amerikaner einen eher ökonomischen Blick auf die Dinge.

Irgendein Professor hatte mir mal eine passende Anekdote dazu geliefert.

„Zwei Flugzeuge fliegen unverhinderbar aufeinander zu. Die einzige Möglichkeit, die Besatzung zu retten, wäre der Absturz eines der Flugzeuge. Der Amerikaner würde fragen, in welchem Flugzeug weniger Menschen sitzen und würde dieses Flugzeug abschießen, um das Andere zu retten.

Ein Europäer würde es als ethisch verwerflich halten, überhaupt ein Flugzeug abzuschießen und würde beide verlieren.”

Ehrlich gesagt, fühle ich mich der europäischen Version näher. Und vielleicht würde ein Amerikaner sogar nur fragen, welches Flugzeug weniger Wert hat?!

Was ich mit dieser kleinen Anekdote deutlich machen wollte, dass die Amerikaner einen anderen Blick auf die Sicherheit und auch auf die Informationssicherheit haben. Man kann sich ihre guten Absichten nicht immer gleich erschließen, dennoch sind die Amerikaner auch in der Informationssicherheit oftmals der Vorreiter.

So hat der amerikanische Verband der Buch- und Wirtschaftsprüfer, AICPA (American Institute of Certified Public Accountants), bereits 1949 ein internal control system (ics) als notwendig erachtet.

Das ics (Deutsch: Internes Kontrollsystem) sollte die Zuverlässigkeit der Buchhaltung und Effizienz der prozessualen Abläufe sicherstellen. Maßnahmen, um die Finanzbuchführung zu optimieren. 1985 wurde dazu das COSO1 Modell für den Aufbau eines angemessenen internal control system entwickelt.

Dieses COSO Modell und weitere Bestrebungen von internal controls hatten auch Einfluss auf die deutsche Wirtschaftsprüfung. Obwohl sich das Prinzip eines internal control systems in verschiedenen Gesetzgebungen wiederfand, beschrieb das Institut der Wirtschaftsprüfer (IDW e.V.) erst im Jahre 2001 ein internes Kontrollsystem mit seinem Prüfungsstand IDW PS 260.

In Deutschland herrschte bis dahin und weitgehend heute noch die Auffassung, dass ein internes Kontrollsystem eher Prüf- und Überwachungsaufgaben hat. Darin unterscheidet sich die Betrachtung eines internen Kontrollsystems von einem internal control system, das auf risikobasierte Sicherheitsmaßnahmen setzt.

Und das hat seine nachvollziehbaren Gründe.

Wenn ich etwas kontrolliere, kontrolliere ich zum Beispiel, ob die Hausaufgaben gemacht wurden, die Tür abgeschlossen ist oder ich kontrolliere den Verlauf der Sonne. Wenn man in Deutschland etwas kontrolliert, ist es somit meist die Prüfung oder Überwachung von technischen oder persönlichen Leistungsergebnissen.

Wir können jedoch auch ein Modellauto über eine Fernbedienung oder einen Roboter kontrollieren. In dem Fall würden wir allerdings eher sagen, dass wir das Modellauto oder den Roboter steuern.

Und genau so wird das Wort „control” in der englischsprachigen Welt verendet. Wenn ein Engländer oder Amerikaner etwas „controls”, dann steuert er etwas. „I control you” heißt nicht, dass ich Deine Arbeitsleistung überprüfe, sondern, dass ich Dich steuere.

Bei allem Verständnis für die auftretenden Missverständnisse, geht es in einem internen Kontrollsystem eines ISMS um Sicherheitsmaßnahmen. Es geht um Maßnahmen zur Steuerung der Informationssicherheit. Der Begriff „Kontrolle” ist für die Sicherheitsmaßnahmen irreführend. Daher sollte in der Informationssicherheit immer der Begriff „Control” für Sicherheitsmaßnahmen gewählt werden!

So halten wir es auch in diesem Buch. Wir verwenden das Wort „Control” für die Sicherheitsmaßnahmen, für das interne Kontrollsystem verwenden wir jedoch die deutsche Übersetzung.

Ein internes Kontrollsystem ist zumindest in der Informationssicherheit risikobasiert angelegt. Das heißt, ich habe Risiken erkannt und möchte diese mit Sicherheitsmaßnahmen verringern. Diese Maßnahmen sind dann die „controls” in einem internen Kontrollsystem.

In der Informationssicherheit entstehen diese Risiken auf die Vertraulichkeit, Verfügbarkeit und Integrität der Informationen innerhalb eines verwalteten Bereichs – innerhalb des Geltungsbereichs eines Managementsystems.

Abbildung 2: Vertraulichkeit, Verfügbarkeit, Integrität

Das heißt, ich muss meinen verwalteten Bereich bestimmen, in dem ich meine Controls zur Verringerung der Risiken einsetzen möchte. Das ist der Geltungsbereich meines Informationssicherheits-Managementsystems.

Es gibt jedoch auch eine Prüf- und Überwachungsfunktionen innerhalb eines Informationssicherheits-Managementsystems. Das sind unter anderem die Key IT-Risk Indicator(KIRI). Sie werden erstellt, um die Wirksamkeit des internen Kontrollsystems messen. In anderen Rahmenwerken heißen sie Key Performance Indicator (KPI) und in der alten ISO 27001 waren es die Measurements of Effectiveness (MoE).

Bei den Key IT-Risk Indicators handelt es sich um ausgewählte Indikatoren. Wenn es sich nicht um die Schlüssel-Indikatoren handelt, kann auch eine Bezeichnung „IT-Risk Indicator” ausreichen.

Nun geht man hin, benennt den Geltungsbereich seines Informationssicherheits-Managementsystems, führt das Risiko Management aus und misst die Wirksamkeit.

In der Entwicklung der Informationssicherheit hat sich jedoch gezeigt, dass das nicht ausreicht.

Man hat um dieses Risiko Management und das dazugehörige interne Kontrollsystem herum, ein anerkanntes Managementsystem geschnallt: den Management Kreislauf „Deming Wheel”.

Die Entstehungsgeschichte ist nicht ganz klar. Er ist in Anlehnung an den Shewhart Cycle entstanden und abschließend in einem japanischen Prozess-Workshop, den W. Edwards Deming leitete, entwickelt worden.

Dieses Managementsystem sichert den kontinuierlichen Verbesserungsprozess über die Phasen „Plan”, „Do”, „Check” und „Act” vor.

Abbildung 3: Deming Wheel

Dieser Plan-Do-Check-Act Kreislauf stellt nun den Rahmen um das Risiko Management und das sich daraus ergebene interne Kontrollsystem.

Mit diesem Managementkreislauf ist auch die Entstehungsgeschichte der ISO 27001 verbunden.

1.3 Kurzbeschreibung ISO 27001

Die ISO 27001 ist die Beschreibung eines Informationssicherheits-Managementsystems.

Sie hatte ihre Anfänge mit einem Vorschlag aus „Best Practices”.

Best Practices waren und sind Praktiken, die sich im Laufe der Zeit bewährt haben. Sie stellen Maßnahmen dar, die Informationssicherheit in den Organisationen gewährleisten sollen.

Der Ursprung dieser Best Practices der Informationssicherheit war ein Zusammenschluss niederländischer Berater, die sich mit britischen Unternehmensberatern zusammengetan haben, um diese zu einem Standard zu etablieren. Die Ergebnisse sind zunächst an das british standard institute gelangt und wurden 1995 zum BS 7799 erhoben. Dieser Standard wurde 1998 in BS 7799-1 umbenannt, da im selben Jahr das Rahmenwerk für diese Best Practices, die BS 7799-2 veröffentlicht wurde.

Im Jahre 2000 wurde die BS 7799-1 schließlich von der International Standard Organisation zur ISO 17799 erhoben. Die BS 7799-2 folgte dann 2005 als ISO 27001, worauf die ISO 17799 im Jahre 2007 zur ISO 27002 umbenannt wurde.

Beide Standards werden immer wieder einmal angepasst. Die bedeutendste Anpassung gab es zuletzt im Jahre 2013, als die ISO 27001 in der sogenannten High Level Structure angelegt wurde. Diese High Level Structure bildet den Plan-Do-Check-Act Kreislauf in ihrer Verzeichnisstruktur sichtbar ab und findet mehr und mehr auch in anderen Management Rahmenwerken Einzug.

Dadurch lassen sich unterschiedliche Managementsysteme viel besser einander integrieren. Als Beispiel sei die ISO 9001 des Qualitäts-Managements genannt, die oftmals auch ohne die High Level Structure gemeinsam mit der ISO 27001 implementiert wurde. Beide Standards haben nun eine einheitliche Struktur, mit ähnlichen Inhalten. Die Aktivitäten lassen sich dadurch unkompliziert parallel nutzen oder zumindest parallel abarbeiten.

Die ISO 27001 stellt einige Forderungen, auf welchen Füßen der Schutz der Vertraulichkeit, Verfügbarkeit und Integrität die Informationssicherheit zu stehen hat. Anhand der verschiedenen Interessengruppen und des Kontextes, in dem die Organisation steht, wird eine übergreifende Informationssicherheitsrichtlinie erstellt, die dem Mitarbeiter aufzeigen soll, wo die Organisation ihre Schmerzen der Informationssicherheit sieht.

Auf Basis dessen ist dann ein Risiko Assessment erst einmal zu planen und später durchzuführen.

Das Risiko Assessment unterscheidet sich von der Risikoanalyse, da es den ganzen Bewertungsprozess betrachtet.

Das Risiko Management beinhaltet dann wieder die Plan-Do-Check-Act Phasen, um sich als ganzheitliches Managementsystem zu präsentieren.

Die ISO 27001 fordert zudem einige Zugeständnisse von der Geschäftsführung, um das Funktionieren eines Informationssicherheits-Managementsystems sicherzustellen. Da sind selbstverständlich die Ressourcen, Kompetenz der Informationssicherheit sowie Maßnahmen zur Sensibilisierung der Mitarbeiter zu nennen. Darüber hinaus fordert der Standard einen geordneten Kommunikationsprozess und eine einheitliche Dokumentation.

Das Beste bietet der Standard mit dem kontinuierlichen Verbesserungsprozess zum Schluss. Die ISO 27001 fordert hier einige Prüf-, Überwachungs- und Berichtsmaßnahmen, um entscheidende Maßnahmen zur Verbesserung in der Act-Phase auf den Weg zu bringen.

Der Anhang A wartet dann mit einer Liste an Controls auf, die im Laufe des Erstellungsprozesses des internen Kontrollsystems zumindest berücksichtigt werden sollten. Diese Controls sind in sogenannten Clauses unterteilt, in denen einige Control Objectives (Deutsch: Kontrollziele) vermerkt sind. Um diese Kontrollziele zu erreichen, sind einige Controls definiert, die zur Erreichung dieser Kontrollziele beitragen.

Und da kommen wir dann endlich auch zur ISO 27002.

Sie gibt Umsetzungshinweise, wie die Controls aus dem Anhang A umgesetzt werden können. Die Auditoren bedienen sich in ihrer Argumentation oft der ISO 27002. Diese ist jedoch nicht zertifizierungsrelevant. Das heißt, die Organisation kann sich danach richten, muss sie jedoch nicht.

Sollte ein Auditor Vorhaltungen über die Umsetzung eines Controls machen und dann auf die ISO 27002 verweisen, kann man ihm gern antworten, dass „die ISO 27002 nicht zertifizierungsrelevant ist”. Dann bekommt er große Augen und wird in aller Regel still. Zertifizierungsrelevant ist die ISO 27001. Dazu gehört auch der Anhang A. Der ist allerdings so abstrakt geschrieben, dass er erhebliche Freiheiten in der Umsetzung bietet.

Um es noch einmal zu verdeutlichen:

Das saftige Filet-Steak liegt in der Mitte des Tellers. Es ist das Risiko Management, inklusive der Controls, die fein säuberlich mit den Vorgaben aus dem Anhang A abgeschmeckt werden.

Drum herum liegt das liebevoll angerichtete Gemüse und die Kohlenhydrate, sei es Reis, Nudeln oder Kartoffeln. So angerichtet, wird jeder Auditor genussvoll schmatzen und ein positives Zeugnis ausstellen. Sollte der Auditor ein Vegetarier oder Veganer sein, kann es natürlich gern auch ein Tofu Steak sein.

1.4 Auditprozess

Wie in jeder Menükarte die Getränke ganz hinten stehen, sollten auch die Audit- und Zertifizierungsfragen in den Managementsystemen der Informationssicherheit ganz hinten stehen. Schließlich folgt das Audit und das Zertifikat dem ganzen Prozess zum Schluss.

Jedoch sind die Getränke die leichte Kost. Wer hat sich nicht schon einmal selbst dabei entdeckt, die Menükarte von hinten zu lesen, um zuerst die Getränke zu bestellen. In der Hoffnung, die Getränke kommen damit umso schneller.

Ähnlich ist es mit dem Auditprozess. Viele Fragen ergeben sich, wenn man weiß, wie der Auditprozess verläuft. Danach folgt dann noch der Zertifizierungsprozess, der uns allerdings an dieser Stelle noch nicht helfen kann. Daher bleibt er an letzter Stelle - ebenso wie die harten Getränke, die immer auch erst nach dem Essen kommen.

An dieser Stelle beschreibe ich den Auditprozess, weniger aus der Sicht des Standards heraus, sondern viel mehr aus der Praxis. Wie ein Auditor das Audit erlebt und wie die auditierte Organisation das nutzen kann.

Man sollte sich dabei vor Augen führen, dass hinter dem Auditprozess immer auch eine Dienstleistung steckt. Auf der einen Seite zahlen die Kunden und auf der anderen Seite verdienen die Dienstleister daran. Machen die Auditoren ihre Sache nicht im Sinne des zahlenden Kunden, werden sie zum nächsten Audit nicht mehr eingeladen und müssen sich einen neuen Kunden suchen.

Der zahlende Kunde will letztendlich das Zertifikat.

Ein „guter” Auditor findet daher am Ende immer einen Weg, das Zertifikat auszustellen.

Viele Auditoren treiben es dabei allerdings auf die Spitze.

Ich musste beispielsweise zu einem Überwachungsaudit, bei dem der Kunde keine Key IT-Risk Indicators erstellt hat. Die Key IT-Risk Indicator sind Teil des Rahmenwerkes der ISO 27001 und müssen für ein Zertifikat immer eingerichtet werden!

In dem Fall war es wohl so, dass der Auditor des vorjährigen Zertifikataudits sich mit dem Kunden gestritten hatte. Die Welt ist klein, ich kenne den Auditor persönlich und habe immer gern mit ihm zusammengearbeitet. Er war eigentlich sehr formell, ließ es allerdings manchmal an Empathie vermissen.

Jedenfalls stehe ich vor dem Kunden und frage nach den Key IT-Risk Indicators. „Hamwanich” war die lapidare Antwort.

„Wieso haben Sie dann ein Zertifikat?” fragte ich. Das konnten sie mir nicht beantworten.

Dieses Unternehmen hätte das Zertifikat niemals erhalten dürfen!

Die Key IT-Risk Indicators (KIRIs) sind oft ein Problem.

In den Fällen, in denen ich der Lead Auditor war, hatten die Kunden jedoch auch ein Qualitäts-Managementsystem implementiert und konnten mir Key Performance Indicator vorlegen, die sich auch mit der Informationssicherheit befassen. So auch in diesem Fall.

Ich gab ihnen einen Tag Zeit, um die Indikatoren der Informationssicherheit zusammenzustellen. Für das kommende Audit gab ich ihnen dann mit, die KIRIs auf die größten Risiken der Informationssicherheit auszurichten und bot ihnen somit die Möglichkeit, sich zu verbessern.

In einem anderen Audit war ich als Dienstleister für das auditierte Unternehmen, dem Auditee tätig.

Es handelte sich dabei um ein Tochterunternehmen eines weltweiten Software-Herstellers. Von Anbeginn unserer Zusammenarbeit erklärte ich seinen Mitarbeitern, dass deren Risiko Assessment nicht angemessen sei. Sie ließen sogar extra einen Mitarbeiter aus Amerika einfliegen, der mir versicherte: „Das machen wir immer so und ist ausreichend.”

Richtiger Weise nahm der Auditor das Risiko Management im anschließenden Zertifizierungsaudit auseinander. Das zentrale Instrument eines Informationssicherheits-Managementsystems hatte nichts mit dem zu tun, was wir da gerade betreuten!

Das hätte nach meinem Empfinden zum Abbruch des Audits führen müssen.

Doch es ging weiter.

Dann verbissen sich die Auditoren in die Gesellschafter dieses Tochterunternehmens.

Der Mutterkonzern hätte zu viel Einfluss und könnte das Unternehmen steuern. Vollkommener Quatsch, da jedes Unternehmen seinen Eigentümer hat, der die Geschicke letztlich lenkt. Aber der Auditor hielt daran fest und hätte das Zertifikat mit dieser Auffassung abermals nicht erteilen dürfen!

Tat er aber, da er nicht der Auditor sein wollte, der eines der weltweit größten Unternehmen das Zertifikat versagte. Man schmückt sich eben gern mit diesen Federn. Außerdem wären Folgeaufträge so nicht denkbar gewesen.

Man sieht an diesen Beispielen, dass die Auditoren zum einen auch nur Menschen und nicht immer in Höchstform sind und zum anderen, dass Geld und Namen eine wesentliche Rolle spielen. Derlei Beispiele gibt es noch viele andere.

Man kann sich jedoch vorstellen, dass die meisten Auditoren auch bereit sind, ein Zertifikat notfalls zu entsagen, wenn der Kunde sich gar nicht bewegt. Es ist immer ein Geben und Nehmen. Jeder Auditor hat da seine eigene Schmerzgrenze und kein Auditor will sich offensichtlich auf der Nase herumtanzen lassen.

Der Auditor bekommt von dem Auditee zunächst einen Satz an Dokumenten des Informationssicherheits-Managementsystems. Dazu gehört der Auditbericht und die Beanstandungen des letzten Jahres. Hinzu kommen das Statement of Applicability, der Risk Treatment Plan, das Scope Dokument, ein Organigramm und weitere Dokumente, die die Organisation und das Informationssicherheits-Managementsystem beschreiben. Das sind dann meist die Richtlinien und Prozessbeschreibungen der Organisation. Vertrauliche Dokumente werden dabei nur selten herausgegeben. Sie werden vor Ort besichtigt und besprochen.

Dennoch ist es ein umfangreicher Satz an Dokumenten, mit denen sich der Auditor vorbereiten soll.

Es gibt vom Standard festgelegte Zeiten zur Vorbereitung. Die Einhaltung dieser Zeiten prüft die jeweilige Akkreditierungsgesellschaft. Jedoch gibt es erhebliche Variationsmöglichkeiten, mit denen die Auditzeiten heruntergerechnet werden können.

Ich hatte in keinem meiner Audits mehr als zwei Tage für die Vor- und Nachbereitung, inklusive der Erstellung des Auditreports. Zu einem speziellen Auditauftrag wollte man mir einen halben Tag für die Vor- und Nachbereitung zugestehen. Ich habe dankend abgelehnt.

Letztlich bleibt den Auditoren nicht genügend Zeit, sich in das ISMS der Organisation einzuarbeiten. Das kann den auditierten Organisationen zum Vorteil gereichen.

Die Zusammenhänge sind in einigen komplexen Organisationen kaum zu verstehen. Schon gar nicht in der zur Verfügung gestellten Zeit.

Hinterfragt der Auditor einen Prozess, verweist man als Auditee einfach auf einen alternativen Prozess und verwirrt den Auditor am Ende komplett. Sollte der Auditor unerwartet darauf herumreiten, bis er die Zusammenhänge versteht, mag es vielleicht eine Abweichung geben. Die Abweichung wird abgestellt, der Auditor hat jedoch weniger Zeit zur Prüfung anderer Dinge.

Für den Auditee ist es somit ein willkommenes Szenario, wenn sich der Auditor an einem Thema verbeißt.

Wenn die Mitarbeiter die Interviews in den Audits zudem in die Länge ziehen, kommt der Auditor vollends aus dem Zeitplan.

Bei Zertifizierungsaudits gibt es zunächst ein Dokumentenaudit.

Dort bespricht der Auditor die ISMS-Dokumente mit dem Kunden. In diesen Sitzungen bekommt er dann auch die vertraulichen Dokumente zu sehen. Auch das kostet wieder Zeit. Schließlich sieht der Auditor die Dokumente das erste Mal.

Mehrfach konnte ich beobachten, dass an dieser Stelle das erste Mal über den Geltungsbereich gesprochen wird. Die Auditoren, teilweise auch die Zertifizierungsgesellschaften, wussten an dieser Stelle nicht, welche Informationen das Informationssicherheits-Managementsystem eigentlich schützen soll.

Damit sind dann eigentlich auch die Dokumente, die der Auditor zur Vorbereitung erhalten hat, für die Katz. Schließlich ist nicht klar, ob diese Dokumente zum Geltungsbereich gehören.

Natürlich steht man als auditierte Organisation während des Audits am Pranger und muss liefern.

Auch wenn die Auditoren am Ende eindreiviertel Augen zudrücken, werden sie jetzt die Inhalte der Dokumente hinterfragen. Und nicht nur das. Es geht bereits um Metadaten der Dokumente, Versionskontrolle und die Einhaltung regelmäßiger Dokumentenprüfungen — den Reviews.

Doch das ist nur die Pflicht. Die Kür folgt dann mit dem Vor-Ort Audit.

Jetzt fragt man sich vielleicht, warum es ein Vor-Ort Audit gibt, wenn das vorgelagerte Dokumentenaudit bereits vor Ort stattfindet. Das habe ich mich zunächst auch gefragt. Es ist aber so vorgesehen und macht auch Sinn.

Die Dokumente erfordern oftmals Erklärungen und der Auditor soll sich einen ersten Eindruck verschaffen, ob die Organisation ein funktionierendes Informationssicherheits-Managementsystems betreibt. Er guckt, ob die Zutrittskontrollen greifen, die Mitarbeiter eine etwaige Clean Desk Policy einhalten und sich generell angemessen zur Informationssicherheit verhalten.

Die Zertifizierungsgesellschaften handhaben es unterschiedlich, wieviel Zeit zwischen Dokumentenaudit, auch Stufe 1 Audit, und dem Vor-Ort Audit, dem Stufe 2 Audit liegen muss.

Mit dem Stufe 1 Audit hat der Auditor sich jedenfalls schon einmal einen ersten Eindruck verschafft.

Im Vor-Ort Audit (Stufe 2) geht es ans Eingemachte. Nun prüft der Auditor die Prozesse, die Richtlinien und gegebenenfalls die Einhaltung der Sicherheitsmaßnahmen. Anders als in einem Zertifizierungsaudit und Rezertifizierungsaudit, wird ein Überwachungsaudit nicht in zwei Stufen aufgeteilt. Dort werden alle Aspekte in einem Vor-Ort Audit geprüft.

Technisch prüft der Auditor nichts. Jedenfalls legt er selbst keine Hand an. Audits der Informationssicherheit sind keine technischen Audits!

Durchaus kann er mal verlangen, dass man das zuletzt installierte Update zeigt oder er lässt sich die Einstellungen in den System zeigen. Hand sollte er selbst jedoch nicht anlegen. Auch sollte er wissen, was er tut, wenn er dem Mitarbeiter die Eingabe von Befehlen vorgibt. Das wird daher nur selten vorkommen.

Abbildung 4: Zertifizierungszyklus

1.5 Machbarkeitsanalyse ISMS

Ein Koch mit asiatischem Erscheinungsbild sollte sich gut überlegen, ob er ein Restaurant mit deutscher Küche eröffnet. Umgekehrt mag das gerade noch gehen. Ein deutscher Koch der zum Beispiel ein italienisches Restaurant eröffnet, ist in Deutschland aufgrund der geografischen Nähe vielleicht noch angemessen.

Vertrauen auf eine gute Küche schafft jedoch auch das nicht.

Genauso ist es mit dem gewählten Standard. Man muss sich fragen, ob dieser Standard zur Organisation passt.

Oft kommen die Anforderungen zur Umsetzung eines Informationssicherheits-Managementsystems vom Staat oder vom Kunden einer Organisation. Diese aufgeforderten Organisationen nötigen ihren Lieferanten dann ebenfalls die ISO 27001 ab, um die komplette Kette der Informationssicherheit abzudecken.

Die Krux an dieser Sache ist, dass der Standard die Umsetzung der ISO 27001 von den Lieferanten überhaupt nicht fordert. Dagegen stellt der Standard diverse Forderungen an die vertraglichen und technischen Vereinbarungen, deren Einhaltung überwacht und geprüft werden soll.

Der Lieferant hat dann auf Kundenforderung die ISO 27001 umzusetzen, sich entsprechend auditieren und zertifizieren zu lassen, um sich dann noch einmal vom Kunden überprüfen zu lassen. Kaum eine Organisation gibt sich damit zufrieden, dass sein Lieferant mit der ISO 27001 zertifiziert ist. Der Lieferant muss sich den festgeschriebenen Forderungen seines Kunden trotzdem stellen.

Daher sollte sich der Lieferant überlegen, ob der Kunde diesen Aufwand wert ist. Allerdings erfüllt dieses Zertifikat weitere Werbezwecke, sofern sich weitere Kunden damit werben lassen. Insofern sollte auch dieser Punkt in die Abwägung einbezogen werden.

Ein weiterer Punkt ist die Konkurrenzfähigkeit.

Wenn sich jeder Konkurrent nach ISO 27001 zertifizieren lässt, hat man selbst das Nachsehen.

Wenn man unter den Konkurrenten der Erste mit dem Zertifikat ist, hat man einen Vorsprung.

Hat man sich zur Einführung eines Informationssicherheits-Managementsystems entschlossen, muss man tatsächlich konstatieren, dass er den Geschäftsbetrieb in aller Regel professionalisiert.

Sicher, das kann man auch mit einer ISO 9001 erreichen. Darum ist sie auch wesentlich weiterverbreitet, als die ISO 27001.

Lässt man beide Standards gemeinsam zertifizieren, können einige Synergien erreicht werden. Dennoch darf man nicht vergessen, dass der Gesamtaufwand noch einmal steigt. Das trifft sicherlich besonders auf das Qualitäts-Management der ISO 9001 zu.

Sind die Beweggründe für ein Zertifikat die Informationssicherheit, wählt man die ISO 27001. Dazu wird zunächst ein Verantwortlicher für das Informationssicherheits-Managementsystems benötigt. Das Gehalt eines Informationssicherheitsbeauftragten oder Chief Information Security Officers (CISO) variiert je nach Komplexität der Organisation und Kompetenz des Informationssicherheitsbeauftragten. Auch die Zeiten vor, während und nach der Pandemie spielen eine Rolle. Man kann jedoch sagen, dass der Bedarf an Informationssicherheitsbeauftragten steigt. Damit auch das durchschnittliche Gehalt.

Nehmen wir heute einfach mal eine Spanne von 90 – 150.000,- € Jahresgehalt für einen Informationssicherheitsbeauftragten an. Dann dürften das einen jährlichen Aufwand von circa 250.000,- € allein für diese Rolle betragen. Die Arbeitgeberanteile, weitere Sozialleistungen und ein eingerichtetes Büro mit einberechnet.

Hat man sich für ein Informationssicherheits-Managementsystem entschieden, kommt man um diese Position nicht herum. Da diese Position exponiert ist, wird man sich auch schwertun, sie mit anderen Aufgaben zu teilen. Eine angemessene Pflichtentrennung wäre in den meisten Fällen problematisch.

Auch eine Teilzeitbeschäftigung ist mir bislang noch nicht untergekommen. Selbst bei einem IT-Dienstleister mit 120 Mitarbeitern, war ich als CISO ausreichend gefordert. Ein anderer IT-Dienstleister für Finanzdienstleistungsinstitute mit circa 100 Mitarbeitern, hatte bereits drei feste Mitarbeiter und zwei studentische Hilfskräfte.

Doch ich habe auch ein Entwicklungsunternehmen mit 1.000 Mitarbeitern als CISO allein betreut und hatte dennoch genügend Freiraum.

Viele Faktoren führen zu unterschiedlichen Personalbedarfen, die gegebenenfalls mit externen Beratern gedeckt werden.

Wer dieses Buch in den Händen hält, benötigt selbstverständlich keine externe Beratung.

Dennoch ist der Informationssicherheitsbeauftragte vielleicht mal zeitlich oder auch fachlich überfordert und benötigt Unterstützung. Dann beauftragt er einen externen Berater.

Externe Berater haben den Vorteil, dass sie bereits unterschiedliche Lösungen und Prozesse gesehen haben. Sie blicken über den Tellerrand hinaus und haben auch mal alternative Lösungsvorschläge, die aus der eigenen Suppe heraus nicht entwickelt worden wären.

Tatsächlich habe ich jedoch oft auch unbedarfte Berater kennengelernt, die bestenfalls große Töne gespuckt haben und von Informationssicherheit wenig verstanden. Das trifft sowohl für große Beratungsunternehmen zu, als auch für Freiberufler. Eine Vorhersage, wo die guten Berater agieren, lässt sich da leider nicht treffen.

Ob unerfahren oder nicht, müssen die Berater im Bedarfsfall jedoch für zeitliche oder fachliche Unterstützung herhalten.

Dann kommt der Berater allerdings nicht nur für eine Stunde und fährt wieder nach Hause. Der bleibt ein viertel Jahr oder länger und fordert für seine Leistung vielleicht 100,- € die Stunde. Größere Unternehmen können auch gern mal das Doppelte verlangen.

Rechnen wir 100,- für einen Freiberufler, sind das mehr als 16.000,- € im Monat, 96.000,- € im halben Jahr.

Weitere Aufwände entstehen, wenn die Mitarbeiter notwendigerweise in die Prozesse der Informationssicherheit eingebunden werden oder das Risiko Assessment die Anschaffung weiterer Geräte, Software oder Stellen erkannt hat.

Für die Umsetzung eines Informationssicherheits-Managementsystems sollte man mindestens ein Jahr einplanen.

Selbst für ein Unternehmen mit drei Mitarbeitern habe ich einmal vierzehn Monate bis zur erfolgreichen Zertifizierung benötigt. Tatsächlich lag es in dem Fall an der Priorisierung der produktiven Aktivitäten. Selbstverständlich ging der Tagesbetrieb vor. Auch mein Aufwand war nicht vergleichbar, mit dem eines angestellten Informationssicherheitsbeauftragten.

Dennoch zeigt gerade dieses Beispiel, dass der Zeitraum für die Einführung eines Informationssicherheits-Managementsystems kaum unter einem Jahr möglich ist. Selbst wenn es das Unternehmen an Komplexität vermissen lässt, müssen die Strukturen geschaffen und etabliert werden.

Zum Abschluss dieser Überlegungen darf man dann die Kosten der Zertifizierung nicht außer Acht lassen. Das sind auch noch einmal circa 2.000,- € Zertifizierungsgebühren und Tagessätze zwischen 1.200,- € und 1.500,-€ für den Auditor. Das sind für das initiale Audit auch mal wieder mindestens 8.000,- €, die sich mit zunehmender Unternehmensgröße durchaus erhöhen.

Die Überwachungsaudits schlagen anschließend noch einmal mit einem Drittel des Aufwandes für das initiale Zertifizierungsaudit zu Buche.

Ich möchte mit meinen Ausführungen keine Angst machen. Ohnehin bleibt zum einen oftmals keine Alternative und zum anderen sollte klar sein, dass ein Verlust der Informationssicherheit deutlich teurer werden kann.

Dennoch zeigt diese kurze Aufstellung, dass mit der Einführung eines Informationssicherheits-Managementsystems schon gern einmal 400.000,- € aufgerufen werden müssen.

Das von mir skizzierte Entwicklungsunternehmen mit drei Mitarbeitern, kam dagegen kaum auf zehn Prozent dieser Summe. Es geht somit auch anders. Dennoch werden die meisten Organisationen, die mehr als 100 Mitarbeitern haben, eher mehr investieren müssen.

1 Committee of Sponsoring Organizations of the Treadway Commission (COSO)

2. ISO 27001 RAHMENWERK

. ISO 27001 PLAN-PHASE

2.1 Kapitel 4 „Verstehen der Organisation und ihres Kontextes”

2.1.a Kapitel 4.1 „Verstehen der Organisation und ihres Kontextes”

2.1.b Kapitel 4.2 „Verstehen der Erfordernisse und Erwartungen interessierter Parteien”

2.1.c Kapitel 4.3 „Festlegen des Geltungsbereichs des Informationssicherheits-Managementsystems”

2.1.d Kapitel 4.4 „Informationssicherheitsmanagementsystem”

2.2 Kapitel 5 „Führung”

2.2.a Kapitel 5.1 „Führung und Verpflichtung”

2.2.b Kapitel 5.2 „Policy”

2.2.c Kapitel 5.3 „Rollen, Verantwortlichkeiten und Befugnisse in der Organisation”

2.3 Kapitel 6 „Planung”

2.3.a Kapitel 6.1 “Maßnahmen zum Umgang mit Risiken und Chancen”

2.3.b Kapitel 6.2 „Informationssicherheitsziele und Planung zu deren Erreichung”

. ISO 27001 DO-PHASE

2.4 Kapitel 7 „Support”

2.4.a Kapitel 7.1 „Ressourcen”

2.4.b Kapitel 7.2 „Kompetenz”

2.4.c Kapitel 7.3 „Bewusstsein”

2.4.d Kapitel 7.4 „Kommunikation”

2.4.e Kapitel 7.5 „Dokumentierte Information”

2.5 Kapitel 8 „Betrieb”

2.5.a Kapitel 8.1 „Betriebliche Planung und Steuerung”

2.5.b Kapitel 8.2 „Informationssicherheitsrisikobeurteilung”

2.5.c Kapitel 8.3 „Informationssicherheitsrisikobehandlung”

. ISO 27001 CHECK-PHASE

2.6 Kapitel 9 „Bewertung der Leistung”

2.6.a Kapitel 9.1 „Überwachung, Messung, Analyse und Bewertung”

2.6.b Kapitel 9.2 „Internes Audit”

2.6.c Kapitel 9.3 „Managementbewertung”

. ISO 27001 ACT-PHASE

2.7 Kapitel 10 „Verbesserung”

2.7.a Kapitel 10.1 Nichtkonformität und Korrekturmaßnahmen

2.7.b Kapitel 10.2 Fortlaufende Verbesserung

Ich mag es an den Franzosen, dass sie den Tisch mit Vorspeise, Salat, Hauptspeise, Nachspeise und dann noch ein Baguette decken. Meine persönliche Beobachtung am gedeckten Tisch in Frankreich war, dass sie alles durcheinander essen.

Das Baguette in die Zwiebelsuppe tauchen, ein wenig flämische Karbonade, um dann vom Dessert zu naschen und anschließend wieder einen Löffel Zwiebelsuppe zu schlürfen. Ein Traum für die Geschmacksnerven.

In der ISO 27001 macht es Sinn, erst einmal mit dem Rahmenwerk zu beginnen. Ganz klassisch, erst die Vorsuppe, danach das Hauptgericht und dann das Dessert. Eines der ersten Schritte des Rahmenwerkes, ist die Festlegung des Geltungsbereichs. Er bestimmt, wo die Informationssicherheit umgesetzt werden soll.

Schließlich kann man viel Zeit und Geld verlieren, wenn man das Risiko Assessment in einem Bereich beginnt, der überhaupt nicht zum Informationssicherheits-Managementsystem gehört.

Das Rahmenwerk führt die Organisation daher auf den richtigen Weg.

Man muss nicht unbedingt den Standard komplett in der vorgegebenen Reihenfolge durchführen. Das ist an anderer Stelle sicher eher Kontraproduktiv. Der Standard beginnt jedoch damit, die eigene Organisation kennenzulernen: den internen und externen Kontext, die Stakeholder und ihre Interessen.

Als Berater kommt man oft in Umgebungen, in denen bereits Vorarbeit geleistet wurde.

Manchmal wurde Software eingekauft, die einen durch den Prozess geleitet, meistens werden jedoch Excel-Tabellen und Word-Dokumente vorgelegt. Als Berater muss ich mich mit dem befassen, was mir zur Verfügung gestellt wird. Mir war es immer recht, wenn der Organisation ein Office-Paket ausreichte.

Eines meiner Kunden hatte mir beispielsweise ein Verzeichnis zur Verfügung gestellt, in dem die Arbeiten für das Zertifizierungsaudit abgelegt waren. Alles feinsäuberlich nach Kapiteln des Standards und den Clauses aus dem Anhang A sortiert.

In der Vergangenheit hatte ich bereits einige ISMS-Handbücher angelegt, die mir immer einen guten Überblick ermöglichten, was ich zu tun habe und was noch offen steht. Diese Verzeichnisse ergänzten meine Arbeit mit dem ISMS-Handbuch.

In den Verzeichnissen „Kapitel 4” bis „Kapitel 10” und „Anhang A5” bis „Anhang A18” hatte der Kunde die jeweiligen Arbeitsdokumente und im Hauptverzeichnis die erarbeiteten Ergebnisse aufbewahrt. In diese Unterverzeichnisse habe ich dann ein jeweiliges „ISMS-Handbuch_KapitelX.docx” oder „ISMS-Handbuch_AnhangAX.docx” abgelegt, um diese am Ende zu einem großen ISMS-Handbuch zusammenzufügen.

Den Aufbau der ISMS-Handbücher möchte ich im Folgenden kurz vorstellen, um Ihnen gleich zu Beginn ein sinnvolles und übersichtliches Konzept an die Hand zu geben:

PRAXIS-BEISPIEL „ISMS-Handbuch”:

Für eine offizielle Dokumentation habe ich mir generell angewöhnt, folgende zwei Inhalte zu formulieren:

Ziel des Dokuments: Was will das Dokument dem Leser sagen? Für die Informationssicherheit will das jeweilige Dokument sicherlich mindestens eines der drei Kriterien der Vertraulichkeit, Verfügbarkeit oder Integrität schützen.

Geltungsbereich des Dokuments: Ist es eine Direktive, wie zum Beispiel eine Richtlinie, müssen sich die Mitarbeiter nach dem Inhalt richten. Für ein anderes Dokument kann es andere Belange geben. Welche Bereiche betroffen sind, ist hier anzugeben. Oft ist es die gesamte Organisation oder eine Abteilung.

Die Ziele und der Geltungsbereich können sicher einheitlich für das gesamte ISMS-Handbuch festgelegt werden. Dann muss das nicht immer in jedes Clause und zu jedem Control wiederholt werden.

Folgende Inhalte sind jedoch individuell in den einzelnen Teil-Handbüchern, je für die Clauses beziehungsweise die Controls aus dem Anhang A der ISO 27001 festzulegen:

Ansprechpartner: Wer sind hier die Hauptansprechpartner? Das vereinfacht nicht nur den Auditplan, sondern schafft auch Verantwortlichkeit. Bei den Controls kommen manchmal zu viele Ansprechpartner in Betracht. Man sollte nicht mehr als drei oder vier Hauptansprechpartner vermerken.

Anforderungen: Woher kommen die Anforderungen für dieses Clause oder das Control? In jedem Fall kommen sie aus dem Standard und gegebenenfalls weitere aus dem Risiko Assessment. Die Kapitel des Standards beziehungsweise die Controls aus seinem Anhang sollten dort aufgeführt werden.

Gibt es noch weitere Stakeholder, die klare Anforderungen stellen, sind auch sie hier zu vermerken. Ich habe immer einen Absatz für regulatorische / juristische Anforderungen eingefügt und es gegebenenfalls mit „Keine” vermerkt.

Umsetzung: Hier werden die Kapitel aus den Anforderungen noch einmal wiederholt. Diesmal jedoch in kurzer Prosa die Umsetzung beschreibend. Die Inhalte sollten nicht zu detailliert sein und möglichst auf andere Dokumente verweisen, um das ISMS-Handbuch auch Externen vorlegen zu können.

Aufrechterhaltung: Wir wird die Umsetzung aktualisiert? Systeme werden in das Update-Management eingebunden, Dokumente werden reviewed und Mitarbeiter geschult. Weitere Aktualisierungsmaßnahmen sind möglich.

Beteiligung der Stakeholder: Diesen Punkt habe ich eingefügt, um die Informationssicherheit in die Organisationskultur einzubinden. Hier sind spezielle Awareness-Maßnahmen zu benennen, die jedoch hauptsächlich Sinn machen, wenn man ein Konzept für die Organisationskultur hat.

Ziel des internen Audits / Key IT-Risk Indicator: Wie messe ich den Erfolg der Umsetzung aus dem Rahmenwerk (Kapitel aus der ISO 27001) respektive der Controls (aus dem Risiko Management)? Um keine Begehrlichkeiten bei dem Auditor zu wecken, sollten hier nur Auditziele und Key IT-Risk Indicator eingetragen werden, die auch tatsächlich gemessen werden.

Die Ziele des internen Audits können selbstverständlich auch für ein externes Audit verwendet werden.

Anhang „Dokumenten-Review”: Alle die Dokumente, die in der Umsetzung aufgeführt wurden, habe ich im Anhang noch einmal in einer Tabelle mit Datum aufgeführt, wann diese das letzte Mal reviewed wurden. Vor dem nächsten Zertifikats-Audit war das meine Checkliste zum Abarbeiten der Dokumente.

Praxis-Beispiel 1: ISMS-Handbuch

In den folgenden Beschreibungen der ISO 27001 Kapitel und der Controls aus dem Anhang A stelle ich zunächst einmal gängige Umsetzungen vor. Am Ende des jeweiligen Kapitels finden sich Vorschläge für das interne Audit beziehungsweise für die KIRIs.

. ISO 27001 PLAN-PHASE

Zu einem guten Koch gehört eine gute Planung.

Die Menüs müssen zu seinem Klientel passen und außerdem muss der Preis variable und fixe Kosten sowie etwaige Ausfälle abdecken.

Der Informationssicherheitsbeauftragte ist da wie ein Chefkoch. Seine Informationssicherheit muss die Anforderungen seiner Stakeholder erfüllen. Das heißt, er muss ein Managementsystem kredenzen, das bestehende und zukünftige Risiken der Stakeholder auf ein akzeptables Maß reduziert und die Gesamtkosten möglichst gering hält. Ein Koch hat zur Planung die vergangenen Umsätze als Richtwert. Zum Monatsanfang fallen sie meistens besser aus und wenn die Sonne scheint, fallen sie richtig gut aus. Schwenkt die Laune seiner Gäste jedoch aus irgendeinem Grund um, wirft das seine Planungen komplett durcheinander.

An solch ein Horrorszenario, wie die Pandemie, wollen wir dabei gar nicht erst denken. Wirklich verlässliche Zahlen hat der Koch dennoch nicht.

Doch so volatil geht es dem Informationssicherheitsbeauftragten auch. Die Organisation könnte neue Geräte anschaffen oder alte austauschen, neue Mitarbeiter einstellen, Geschäftsprozesse verändern oder neue Lieferanten beauftragen. Vielleicht nimmt die Organisation auch mal ein neues Zertifikat in Anlauf. Die Anforderungen an die Informationssicherheit schwanken stetig.

Für einen Informationssicherheitsbeauftragten gleicht kein Jahr dem Anderen!

Die Stakeholder bestimmen die Ausrichtung und stellen ihre Forderungen anhand derer der Koch seine Menüs oder der Informationssicherheitsbeauftragte das Risiko Assessment gestaltet. Ändert sich deren Zusammensetzung, kann es eine komplette Umgestaltung bedeuten. Doch glücklicher Weise gibt es derlei Umgestaltung nur selten, die Anforderungen der Stakeholder verschieben sich meist im zu bewerkstelligenden Rahmen.

Allen können wir es dennoch nicht recht machen. Unsere Leistungserbringung richten wir daher nach den Stakeholdern aus, die den meisten Einfluss haben.

Wir können festhalten, dass die Stakeholder die Ziele der Informationssicherheit in der Organisation bestimmen.

Doch es ist nicht immer ganz klar, wer die Stakeholder in der Organisation sind und welcher Stakeholder die größte Priorität besitzt. Das gilt es herauszufinden.

An diese Stakeholder richten wir dann unsere Ziele aus, die wir SMART in einer übergreifenden Informationssicherheitsrichtlinie formulieren. Diese Informationssicherheitsrichtlinie darf dann auch Informationssicherheitsleitlinie, Information Security Policy oder ganz anders heißen. Wichtig ist, dass sie den Mitarbeitern die Richtung zeigt, welche Informationen zu schützen sind und wie die Organisation dabei vorgehen will.

Die Ziele sollen möglichst smart formuliert sein:

(S)

Spezifisch

(M)

Messbar

(A)

Attraktiv

(R)

Realistisch

(T)

Terminiert

Was nichts anderes heißt, als eindeutig formuliert, mit Zieldatum, einem motivierenden Ziel und dennoch realistisch sowie mit einem messbaren Ergebnis formuliert. Nehmen wir folgendes „smartes” Ziel als Beispiel:

„Die Risikobewertungen für die Vertraulichkeit, Verfügbarkeit und Integrität der Produktivserver werden im dritten Quartal jeden Jahres durch die IT-Asset Owner und IT-Risk Owner aktualisiert und führen zu angepassten Kontrollzielen.”

Es sind keine übertriebenen Ziele definiert (R), die Risikobewertung dürfte ein interessantes Vorhaben (A) sein. Es ist mit einem Zieldatum (T) versehen und mit der Risikobewertung der Vertraulichkeit, Verfügbarkeit und Integrität sind spezifische Anforderungen für die IT-Asset Owner und IT-Risk Owner (S) definiert worden. Die angepassten Kontrollziele machen die erfolgreiche Leistung messbar (M).

2.1 Kapitel 4 „Verstehen der Organisation und ihres Kontextes”

Dies ist ein Kapitel, das oft vergessen wird. Und das ist auch verständlich.

Ich übernehme ein Restaurant und dann gucke ich, was ich kochen kann. Wenn ich in Asien aufgewachsen bin, werde ich eher asiatisch kochen können, wenn ich in Griechenland aufgewachsen bin, gibt es Gyros. Und wenn es eher die kleinen Gerichte sind, die möglichst außer Haus verkauft werden, mache ich daraus vielleicht einen Imbiss. Die Umstände bestimmen das Geschäft.

Ähnlich ist es in anderen Organisationen auch. Da wird zum Beispiel eine Software programmiert und verkauft. Anschließend entwickelt sich daraus ein neues Geschäftsfeld und die Organisation vergrößert sich, bis sie auf die Idee kommt, ein Informationssicherheits-Managementsystem zu errichten.

An eine Ermittlung des Kontextes hat bis dahin noch niemand gedacht. Wenn sie das erste Mal mit dieser Aufgabe konfrontiert werden, fühlen sich die Organisationen oft überfordert.

Man muss sich darunter keine Jahresarbeit vorstellen. Es geht dabei um die internen und externen Einflüsse.

Die ISO 27001 verweist dabei auf die ISO 31000, die das ein wenig genauer beschreibt. Die Organisation soll sich um die internen und externen Zusammenhänge, den Kontext in dem die Organisation steht, Gedanken machen.

Aus dem internen Kontext:

Wer ist die Triebkraft in der Organisation?

Mit welchen Zielen?

Was sind die Gründe, ein Informationssicherheits-Managementsystem zu implementieren?

Sind die Mitarbeiter der Organisation gegenüber loyal und Änderungen gegenüber aufgeschlossen?

Wie gut ist die Organisation organisiert und wie gut greifen die Führungsaktivitäten des Managements?

Aus dem externen Kontext:

Welche juristischen Einschränkungen und Anforderungen gibt es?

Wie ist das kulturelle Umfeld in Bezug auf die Informationssicherheit?

Wie sind die politischen Strömungen?

Wird die Informationssicherheit eher unterstützt?

Erfährt die Organisation Unterstützung von außerhalb?

Wie ist das Image?

Daraus können sich schon die ersten Risiken ergeben, die man in der Folge berücksichtigen könnte. Da die Auditoren jedoch um die Schwierigkeit dieses Kapitels wissen, ist man an dieser Stelle mit einer Stakeholder Analyse schon sehr weit vorn.

Auch hier würde ich den Aufwand nicht übertreiben. Es ist sicherlich nicht die bedeutendste Aufgabe in einem Informationssicherheits-Managementsystem, da sich die kritischen Aspekte auch ohne Kontext über die Schutzbedarfsanalyse ergeben sollten. Dennoch sollte man sich schon einmal Gedanken machen, wer Einfluss und vor allem wer Interesse an das Informationssicherheits-Managementsystem hat, um die Kenntnisse über die kritischen Aspekte zu festigen.

Daher kann der Kontext ein wichtiger Bestandteil in dem Risiko Management Prozess werden.

Dazu werden die Personen ermittelt, die Interesse an das Informationssicherheits-Managementsystem haben. Dann beurteilt man dessen Beziehungsnetzwerk und seinen Einfluss, den er oder sie geltend machen kann.

Aus dem internen Kontext ragen erst einmal die Inhaber und die Geschäftsführer bei den Stakeholdern heraus. Sie haben vor allem zwei Interessen an das Informationssicherheits-Managementsystem. Auf der einen Seite müssen sie die Risiken erkennen und verringern, auf der anderen Seite soll das ISMS möglichst wenig kosten. Schließlich haben diese Interessengruppen ein übergreifendes Ziel: Gewinn erzielen!

Eine andere Gruppe sind die Mitarbeiter. Wenn sie kein Interesse an einem Informationssicherheits-Managementsystem haben, wird es mit der Umsetzung schwierig. Sie brauchen die Vorgabe von der Geschäftsführung und müssen unbedingt sensibilisiert werden.

An dieser Stelle sollte bereits klar sein, warum das Informationssicherheits-Managementsystem die Unterstützung der Geschäftsführung benötigt.

Für die Stakeholder aus dem externen Kontext kann man die Pestei-Umfeldanalyse verwenden. Die Umsetzung ist erst einmal denkbar einfach. Man sucht einfach in den unter Pestel definierten Bereichen nach möglichen Einflüssen auf das Informationssicherheits-Managementsystem:

(P)

Politische Einflüsse

Z.B. Steuern / Zölle, Subventionen, Pandemie-Lockdown, Behörden

(E)

Economy

(Ökonomie)

Z.B. Kunden, Lieferanten, Konjunktur, Inflation, Arbeitslosigkeit, Rohstoffkosten

(S)

Sozio-kulturelle Einflüsse

Z.B. demografischer Wandel, Kaufverhalten, Mobilität, Bildung, Freizeitverhalten

(T)

Technologie

Z.B. Berater, Energieversorgung, Digitalisierung, Sicherheitstechnologien, Patente

(E)

Ecology

(Ökologie)

Z.B. Umweltauflagen, Verbrauch, Recycling, Rohstoffe

(L)

Legal

(Gesetzgebung)

Z.B. Handelsgesetz/Aktiengesetz, Arbeitsrecht, Steuerrecht, Datenschutz, Telekommunikation, IT-Sicherheitsgesetz, BaFin, Juristen

Daraus sind nun die Stakeholder aus den Pestel-Bereichen zu extrahieren, die ihre Ansprüche formulieren.

Der nächste Schritt wäre die Einschätzung, wieviel Einfluss der jeweilige Stakeholder auf das Informationssicherheits-Managementsystem hat. Da das die nachgelagerte Stakeholder Analyse erledigen soll, muss der Einfluss nicht mit der Pestel-Analyse ermittelt werden.

Für jeden der Stakeholder werden nun also folgende Relevanzen ermittelt:

Beziehungsnetzwerk

und der mögliche Einfluss, den der Stakeholder nehmen kann.

Interesse an der Informationssicherheit

, um als Treiber und Unterstützer zu fungieren.

Diese Stakeholder bewertet man anschließend in einem Koordinatenfeld. Als Beispiel nehmen wir hier die Koordinaten von sieben fiktiven Stakeholdern.

Abbildung 5: Stakeholder Analyse

Die Stakeholder im Quadrant „Priorität 1”, besitzen selbstverständlich die höchste Priorität. Für den Stakeholder 6 wurde beispielsweise die Bereitschaft zu Unterstützung mit „8” bewertet und seine Einflussmöglichkeit mit „9”.

Diese Stakeholder gilt es zufriedenzustellen, damit sie gleichzeitig ihren Einfluss positiv einsetzen.

Auch die Stakeholder, die in den zwei Quadranten der mittleren Priorität liegen, sollten zufrieden gestellt werden. Dabei sollte man berücksichtigen, dass die Stakeholder mit dem größeren Einfluss, zwar ein geringeres Interesse an Informationssicherheit haben, jedoch mit über das wohl und weh entscheiden.

Doch auch die Stakeholder, die in dem Quadranten mit der geringsten Priorität liegen, sollte man nicht vergessen. Sie sorgen für eine Grundstimmung in der Organisation, die insgesamt wichtig für die Akzeptanz der Informationssicherheit ist.

Wer die Stakeholder Analyse dann noch auf die Spitze treiben will, der sei auf das Stakeholder Management von Dr. David Krips verwiesen. Mit diesem Tool werden die Stakeholder über folgende neun Stufen betrachtet und analysiert:

Datenerhebung

STUFE 1: Identifikation der StakeholderSTUFE 2: Identifikation der Ziele und Interessen der StakeholderSTUFE 3: Identifikation der Eigenschaften der Stakeholder

Analyse

STUFE 4: Analyse der Stakeholder und PriorisierungSTUFE 5: Analyse von möglichen KoalitionenSTUFE 6: Analyse der Strategien der Stakeholder

Bewertung

STUFE 7: Festlegung von Strategien und Auswertung

Aufrechterhaltung

STUFE 8: MonitoringSTUFE 9: Überprüfung der Zielerreichung

Haben wir die Stakeholder ermittelt, wissen wir, wo unsere Schmerzen liegen. Wir wissen, wen wir zufriedenstellen müssen und welche Informationen wir schützen müssen.

Damit können wir um den Bereich eine Grenze ziehen und den Geltungsbereich des Informationssicherheits-Managementsystems bestimmen. Für den Begriff „Geltungsbereich” kann auch „Anwendungsbereich” oder der englische Begriff „Scope” verwendet werden.

PRAXIS-BEISPIEL „Scope”:

SUN Microsystems Inc. wurde 2010 von Oracle Corp. übernommen.

SUN hatte weltweit fast 30.000 Mitarbeiter und warb im Jahre 2007 mit einem ISO 27001 Zertifikat des „Sun Remote Operations Management”, eine Abteilung in den USA mit vielleicht 50 Mitarbeitern.

Das zeigt die Möglichkeiten, den Aufwand für das Informationssicherheits-Managementsystem zu steuern. Der Scope ist, neben dem Risikomanagement, eine große Möglichkeit der Einflussnahme auf den Aufwand eines ISMS.

Man muss allerdings ergänzen, dass SUN im Folgejahr ihre Zertifizierungsbereiche auf die „Sun Remote Operations Management” Stationen in Deutschland (München), Schottland und Indien ausweitete.

Das ist ein gangbarer Weg, wie man sich langsam in der Informationssicherheit vortastet.

Praxis-Beispiel 2: Scope (Geltungsbereich)

Der Standard fordert einen dokumentierten Geltungsbereich, der die internen und externen Stakeholder berücksichtigt. Insbesondere die Schnittstellen zu Bereichen außerhalb des Informationssicherheits-Managementsystems und die Abhängigkeiten zu externen Bereichen sind zu dokumentieren.

Idealerweise benennt man die Bereiche des Geltungsbereichs anhand der unterstützenden IT-Assets aus dem Asset Management der ISO 27005. Sie kennt dazu folgende Assets:

Hardware und Software

Kommunikationssysteme

Personal und Standorte

Organisationsstruktur und -prozesse

Die Beschreibung des Geltungsbereichs könnte beispielsweise so aussehen:

Der Geltungsbereich umfasst alle Mitarbeiter und IT-Systeme der Abteilung XYZ im Standort A. Die Kommunikationssysteme und das Rechenzentrum des Standortes A sind Bestandteil des Geltungsbereichs.

Nicht zu vergessen, sind nun die Bereiche, die nicht zum Informationssicherheits-Managementsystem gehören. Die Bereiche, die explizit ausgeschlossen werden.

Dort sind dann auch die Schnittstellen und Abhängigkeiten zu nennen, um deutlich zu machen, welche Informationen das Informationssicherheits-Managementsystem verlassen oder dort Einzug halten.

Als Beispiel könnte die Abteilung ABC im Standort Z dienen, die über das Internet an das Rechenzentrum angeschlossen ist:

Die Server der Abteilung ABC sind durch Segmentierung von den IT-Systemen der Abteilung XYZ abgegrenzt und sind nicht Bestandteil des Geltungsbereichs. Die Mailboxen der Benutzer aus der Abteilung ABC liegen dagegen innerhalb des Geltungsbereichs des Informationssicherheits-Managementsystems. Die Richtlinien für die Arbeitsstationen und Benutzer gelten somit ebenfalls für die eMail Nutzung der Abteilung ABC und sind in die Prozesse zur „Bewertung der Leistung” (ISO 27001, Kapitel 9) eingebunden.

Für das Zertifikat wird nur ein kurzer Satz gewählt, der sich auf die eingebundene Abteilung(en) und Standort(e) beschränkt. Das könnte zum Beispiel folgender „Scope” sein:

Der Geltungsbereich umfasst den Standort Z sowie die Mitarbeiter und Systeme der Geschäftsprozesse, die mit diesem Standort verbunden sind.

Im Detail ist das bei der Antragstellung mit der Zertifizierungsstelle zu vereinbaren.

Im Folgenden werden die Anforderungen der einzelnen Unterkapitel des Standards noch einmal durchleuchtet.

2.1.a Kapitel 4.1 „Verstehen der Organisation und ihres Kontextes”

Dieses Kapitel verlangt, die Anforderungen zu ermitteln, die an die Organisation und insbesondere an die Informationssicherheit gestellt werden. Das sichert ein fokussiertes Vorgehen in allen Phasen des Lebenszyklus eines Informationssicherheits-Managementsystems.

In der Praxis scheinen die Anforderungen klar, wenn zum Beispiel ein Kunde oder ein Gesetz ein Informationssicherheits-Managementsystem einfordert. Oft wird dieses Kapitel dann vernachlässigt.

Im internen oder externen Audit kann geprüft werden, ob eine Stakeholder Analyse durchgeführt wurde. Sie muss nicht zwingend nach vorgestelltem Muster erfolgen. In der Beurteilung sollte zumindest jedoch Eingang finden, ob dabei die Ziele der Informationssicherheit angemessen berücksichtigt wurden. Es sollte zudem sichergestellt werden, dass diese Analyse gemäß Dokumentationsrichtlinie aktualisiert wurde.

Es mag einige Auditoren geben, die eine jährliche Überprüfung erwarten. Jedoch handelt es sich dabei um einen strategischen Prozess, der vielleicht nur alle drei Jahre oder in einem längeren Zeitraum überprüft werden muss. Ich würde gegebenenfalls auf eine Aktualisierung zum Rezertifizierungsaudit bestehen und in den Überwachungsaudits fragen, ob sich etwas an den Stakeholdern geändert hat.

2.1.b Kapitel 4.2 „Verstehen der Erfordernisse und Erwartungen interessierter Parteien”

Hier werden schließlich die Ergebnisse der Stakeholder Analyse gefordert.

Habe ich eine Stakeholder Analyse durchgeführt, kann ich die Umsetzung der Kapitel 4.1 und 4.2 als erfüllt betrachten.

2.1.c Kapitel 4.3 „Festlegen des Geltungsbereichs des Informationssicherheits-Managementsystems”

Wie der Geltungsbereich definiert wird, habe ich weiter oben in diesem Kapitel bereits beschrieben.

Als Nachweis sollte eine Beschreibung verfügbar sein, die mindestens die Standorte und Abteilungen umreißt. Darüber hinaus sollte sie die Bereiche kennzeichnen, die missverständlich als Teil des Geltungsbereichs betrachtet werden könnten. Wenn zum Beispiel eine bestimmte Abteilung aus dem Standort nicht zum Geltungsbereich gehört, sollte dies eindeutig vermerkt sein.

Unbedingt sollten auch die Schnittstellen beschrieben werden, an denen Informationen in das Informationssicherheits-Managementsystem eingebracht werden und wieder hinausgehen könnten. Es geht dabei nur um die gewünschten Schnittstellen, wie Internetverbindung, Lieferanten oder ausgelagerte Service-Bereiche.

Die Schnittstellen, die nicht gewollt sind und trotzdem vorhanden sein können, werden im Risiko Assessment betrachtet.

2.1.d Kapitel 4.4 „Informationssicherheitsmanagementsystem“

Der Standard fordert für eine erfolgreiche Zertifizierung, ein Informationssicherheits-Managementsystem zu errichten, aufrechtzuerhalten und fortlaufend zu verbessern.

Ziemlich kühn zu behaupten, dass eine Organisation das nicht selbst weiß, wenn sie nach einem Standard für Informationssicherheits-Managementsysteme zertifiziert werden möchte.

Dieses Kapitel zeigt aber auch, dass nicht alle Kapitel eine echte Herausforderung darstellen. Dennoch sollten die verbleibenden Anforderungen grundsätzlich ernst genommen werden, wenn man ein effektives Informationssicherheits-Managementsystem betreiben möchte.

2.2 Kapitel 5 „Führung“

Ein Restaurant braucht Hilfe und beauftragt Frank Rosin, den Fernsehkoch.

Der guckt sich das zunächst an und übernimmt, um den Inhaber anzuweisen, die Bedienung zurecht zu weisen und die Speisekarte umzuschmeißen. Anschließend erklärt er den Mitarbeitern, wie sie den Laden zu führen haben.

Eine Küche braucht Führung. Frank Rosin übernimmt die Führung und verpasst dem Restaurant ein Konzept, wie sie die schwierige Zeit überstehen können. Er geht voran und lebt Leidenschaft vor.

Das ist genau, was dieses Kapitel von der Geschäftsführung fordert: Vorangehen und die Mitarbeiter mitnehmen.

Zentrales Instrument zur Einstimmung der Mitarbeiter ist die Information Security Policy.

Die Information Security Policy ist für die Informationssicherheit das, was das Konzept für das angeschlagene Restaurant ist. Sie zeigt den Mitarbeitern, wie sie die Informationssicherheit herstellen und ist für den Erfolg des Informationssicherheits-Managementsystems unabdingbar.

Sie ist kein Konzept. Sie ist ein Regelwerk, eine Direktive, an die sich die Mitarbeiter zu halten haben.

Der deutsche Standard übersetzt diese „Policy” mit Politik.

Das hat bereits einige Organisation auf die falsche Fährte gelockt, die daraus ein Gedankenspiel gemacht haben, wie sie Informationssicherheit sehen. Ein Regelwerk entsteht daraus meist nicht.

Kurzer Hinweis: Der Begriff „Politik” kommt vom Griechischen „Polis” und beschreibt Entscheidungen und Tätigkeiten, die das Gemeinwesen betreffen.

Im Anhang A der ISO 27001 werden die verschiedenen Policies allerdings richtigerweise mit Richtlinie übersetzt. Was sich der deutsche Standard dabei gedacht hat, weiß nur die entsprechende Arbeitsgruppe.

Für den Anwender muss klar sein, dass nur die englische Version prüfungsrelevant ist.