Basiswissen Sicherheitstests E-Book

Frank Simon

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: Basiswissen
• Sprache: Deutsch
• Veröffentlichungsjahr: 2019

Seitenzahl: 534

Beschreibung

Die Sicherheit von IT-Systemen ist heute eine der wichtigsten Qualitätseigenschaften. Wie für andere Eigenschaften gilt auch hier das Ziel, fortwährend sicherzustellen, dass ein IT-System den nötigen Sicherheitsanforderungen genügt, dass diese in einem Kontext effektiv sind und etwaige Fehlerzustände in Form von Sicherheitsproblemen bekannt sind.Die Autoren geben einen fundierten, praxisorientierten Überblick über die technischen, organisatorischen, prozessoralen, aber auch menschlichen Aspekte des Sicherheitstestens und vermitteln das notwendige Praxiswissen, um für IT-Anwendungen die Sicherheit zu erreichen, die für eine wirtschaftlich sinnvolle und regulationskonforme Inbetriebnahme von Softwaresystemen notwendig ist.Aus dem Inhalt:- Grundlagen des Testens der Sicherheit- Sicherheitsanforderungen und -risiken- Ziele und Strategien von Sicherheitstests- Sicherheitstestprozesse im Softwarelebenszyklus- Testen von Sicherheitsmechanismen- Auswertung von Sicherheitstests- Auswahl von Werkzeugen und Standards- Menschliche Faktoren, SicherheitstrendsDabei orientiert sich das Buch am Lehrplan "ISTQB® Advanced Level Specialist – Certified Security Tester" und eignet sich mit vielen erläuternden Beispielen und weiterführenden Literaturverweisen und Exkursen gleichermaßen für das Selbststudium wie als Begleitliteratur zur entsprechenden Schulung und folgender Prüfung zum ISTQB® Certified Tester – Sicherheitstester.

Leseprobe

Dr. Frank Simon ist in der Zurich Gruppe Deutschland für die IT-Security verantwortlich. Das Aufgabenfeld reicht dabei von der sicheren Softwareentwicklung, über prozessorale, technische und organisatorische Sicherheitsvorgaben bis hin zu gesamtheitlichen Bedrohungsanalysen. Dabei bringt er 30 Jahre Erfahrung im Bereich der holistischen Qualitätssicherung verschiedener Qualitätseigenschaften ein und berücksichtigt hier insgesamt besonders technische Aspekte wie Architekturen und Bad Smells. Darüber hinaus ist er Mitglied des German Testing Boards (GTB), in dem er die Leitung des Business Development und der Security AG inne hat.

Dr.-Ing. Jürgen Großmann ist Teamleiter im Geschäftsbereich System Quality Center (SQC) am Fraunhofer-Institut FOKUS. Er ist verantwortlich für die Durchführung von Forschungsprojekten zur Validierung und Verifikation von vernetzten und eingebetteten Softwaresystemen im Spannungsfeld zwischen Wissenschaft und Industrie. Seine Schwerpunkte sind modellbasierte Softwareentwicklung, modellbasiertes Testen sowie Testautomatisierung. Ergänzend dazu arbeitet er als Experte für IT-Sicherheit im Bereich kritischer Anwendungen der Automobilindustrie und im Finanzsektor.

Dipl.-Math. Christian Alexander Graf ist freiberuflich tätiger Berater und Trainer. Seit mehr als 17 Jahren beschäftigt er sich beruflich mit Themen rund um Datenanalyse, Planungssysteme, Kennzahlen, Qualitätssicherung, Prozessanalyse und -optimierung, Softwaretest und Validierung. An der Dualen Hochschule Baden-Württemberg in Mannheim unterrichtet er in den Fächern Mathematik, Operations Research und Informatik und im Studiengang technische Informatik das Fach IT-Security. Er ist aktives Mitglied in der American Statistical Association und im Verein Deutscher Ingenieure.

Prof. Dr. Jürgen Mottok (ZD.B-Forschungsprofessor) lehrt Informatik an der OTH Regensburg und ist wiss. Leiter des Laboratory for Safe and Secure Systems (LaS3). Seine Lehr- und Forschungsgebiete sind Software Engineering, Real-Time Systems, Functional Safety und IT-Security. Er ist Träger des Preises für herausragende Lehre, der vom Bayerischen Staatsministerium für Wissenschaft, Forschung und Kunst vergeben wird.

Prof. Mottok ist in Programmkomitees zahlreicher wiss. Konferenzen vertreten, Vorstandsmitglied des Bayerischen IT-Sicherheitscluster e.V. und Vorstand des Lehren von Software Engineering e.V.

Dipl.-Inform. Martin A. Schneider ist wissenschaftlicher Mitarbeiter (Senior) am Fraunhofer-Institut FOKUS. Er beschäftigt sich mit analytischen Methoden zur Qualitätssicherung von nichtfunktionalen Qualitätseigenschaften und fortgeschrittenen Testmethoden und -techniken, insbesondere modellbasierte Testtechniken zur Prüfung von IT-Sicherheitsaspekten, basierend auf verschiedenen Fuzzing-Techniken, IT-Sicherheitstestmustern und -metriken im Rahmen unterschiedlicher industrieller Domänen mit speziellem Fokus auf komplexe vernetzte Systeme, cyber-physische Systeme und dienstorientierte Architekturen.

Frank Simon · Jürgen Grossmann · Christian Alexander Graf · Jürgen Mottok · Martin A. Schneider

BasiswissenSicherheitstests

Aus- und Weiterbildung zumISTQB® Advanced Level Specialist –Certified Security Tester

Frank Simon · [email protected]

Jürgen Grossmann · [email protected]

Christian Alexander Graf · [email protected]

Jürgen Mottok · [email protected]

Martin A. Schneider · [email protected]

Lektorat: Christa PreisendanzCopy-Editing: Ursula Zimpfer, HerrenbergSatz: Birgit BäuerleinHerstellung: Stefanie WeidnerUmschlaggestaltung: Helmut Kraus, www.exclam.de

Fachliche Beratung und Herausgabe von dpunkt.büchern zum Thema »ISTQB® Certified Tester«: Prof. Dr. Andreas Spillner · [email protected]

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print978-3-86490-618-3

PDF978-3-96088-617-4

ePub978-3-96088-618-1

mobi978-3-96088-619-8

1. Auflage 2019

Copyright © 2019 dpunkt.verlag GmbHWieblinger Weg 1769123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Herausgeber können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Vorwort

»Mit dem Wissen wächst der Zweifel.«

Johann Wolfgang von Goethe, Maximen und Reflexionen

Bereits im Herbst 2015 waren mit dem Start des Beta-Reviews des ISTQB® Security-Tester-Lehrplans die Weichen gestellt: »ISTQB goes Security.« Im Sommer 2016 wurde dann der Syllabus in der finalen Version veröffentlicht. Im German Testing Board (GTB), dem deutschen Repräsentanten des ISTQB®, war bereits nach der Bekanntgabe der Kursankündigung schnell klar, dass dies ein höchst logischer Schritt zur bedarfsgerechten Erweiterung des gesamten Schulungsportfolios war. Als dann der finale Syllabus mit 86 Seiten erschien, kamen die ersten Zweifel: Was für eine umfangreiche Themensammlung! Wie aufwendig wird eine Lokalisierung für den deutschen Markt sein?

Und doch: Das German Testing Board hat sehr bald eine eigene Security-Arbeitsgruppe gegründet, um initial erst einmal die entsprechenden Experten zusammenzubringen. Sie sollten den Inhalt verstehen, in einen deutschen Lehrplan überführen, für spätere Zertifizierungen die entsprechenden Fragen erstellen und ggf. sogar ein begleitendes Buch verfassen. Als dann die ersten Einladungen verschickt waren, kamen die nächsten Zweifel: Jeder Security-Experte ertrinkt seit Jahren in Arbeit, kann hervorragende Tagessätze abrufen und hat darüber hinaus noch fortwährend die Aufgabe, sein Wissen kontinuierlich irgendwie aktuell zu halten. Und dann kommt noch die Einladung, sich innerhalb eines »Testing-Vereins« ehrenamtlich zu engagieren? An Abenden und Wochenenden? Für Ruhm und Ehre?

Und doch: Es hat sich eine schlagkräftige Gruppe gefunden, die sich der Übersetzung angenommen hat. Schnell wurde klar, dass das mehr als eine einfache Übersetzung ist und die Lokalisierung im Vordergrund steht: Schon über die Frage, wie denn »Security-Tester« übersetzt werden kann, lässt sich trefflich streiten. Ebenso wie über die Vielzahl nationaler/europäischer Normen und Vorgaben, die gerade für den Sicherheitstester in Deutschland relevant werden würden. Erneut kamen Zweifel auf, ob das »Cross-Site-Scripting« tatsächlich mit »webseitenübergreifenden Skripten« übersetzt werden sollte? Ob das »Salting« tatsächlich mit »Salzen« übersetzt werden kann? Ob »Social Engineering« tatsächlich dasselbe ist wie »soziale Manipulation«?

Und doch: Im Oktober 2018 konnte nach einem umfangreichen Beta-Review mit vielen späteren Trainingsanbietern der finale, übersetzte und lokalisierte Syllabus zum »Sicherheitstester« veröffentlicht werden. Er lässt sich seitdem kostenlos über die Internetseite des German Testing Board herunterladen. Doch mit 104 Seiten Umfang wuchsen wiederum die Zweifel daran, ob dieser Kurs, dessen Thema allgegenwärtig in der Presse präsent ist, mit seinem enorm breiten Themenspektrum von den Interessenten akzeptiert wird? Einem Spektrum, das von Risikomanagement über Testprozesse und Sicherheitsprozesse bis hin zu spezifischen Sicherheitstesttechniken, entsprechenden Werkzeugen und regulatorischen Vorgaben reicht?

Und doch: Bereits Mitte 2018 fanden sich fünf Security-Begeisterte, die genau diese Herausforderung annahmen: Das extrem umfangreiche Sicherheitstester-Material so weit in einem entsprechenden Buch aufzubereiten, dass sowohl der Prüfungsinteressierte sich hiernach vorbereiten kann als auch der nur Themeninteressierte in diesem Werk ein gutes Kompendium rund um dieses Thema findet. Viele Beispiele sollten es sein, mit einer hohen Praxisrelevanz. Je konkreter die ersten Seiten wurden, desto mehr Zweifel kamen abermals auf: Wie viel Wissen kann beim Leser vorausgesetzt werden? Ist der ISTQB®-Testprozess bereits bekannt? Darf angenommen werden, dass der Leser C oder Java beherrscht? Dass dem Interessierten die Institution BSI und das IT-Grundschutz-Kompendium wenigstens grob bekannt sind? Wie viele tausend Seiten würde das Buch benötigen?

Und doch: Nach unzähligen Telefonkonferenzen, Wochenendmeetings, E-Mail-Schlachten und Sharepoint-Versionsabenteuern ist es im Januar 2019 so weit: Über 400 Seiten geballtes Wissen rund um das Sicherheitstesten stehen bereit, angereichert mit unzähligen Beispielen, fachlichen Exkursen, Referenzen und Erläuterungen. Komplexen Themengebieten wird man nicht dadurch gerecht, dass man sie kleinredet, sondern ihnen angemessen begegnet. Erneut kamen Zweifel, ist der Leser nach der Lektüre nun ausgewiesener Sicherheitstester? Kann er die heute immer schnelllebigeren IT-Systeme wirkungsvoll absichern? Wohlwissend, dass die Hacker vermutlich schon einen Schritt weiter sind?

Und doch: Mit dem Wissen in diesem Buch wird hoffentlich auch Ihr Zweifel wachsen: 100%ige Sicherheit? Vollständiges Beseitigen aller Schwachstellen? Keine Risiken mehr? Zweifel! Aber die werden nicht dadurch ausgeräumt, dass man etwas nicht weiß, sondern dadurch, dass man lernt und fortwährend besser wird.

Viel Spaß beim Sicherheitstesten wünschen die fünf Autoren!

Danksagung

Ein Buch zu schreiben bedeutet für nicht hauptberuflich tätige Autoren wie uns, einen großen Teil der Freizeit zu opfern.

An allererster Stelle möchten wir uns daher bei unseren Partnern und Familien für ihr Verständnis und ihre wundervolle Unterstützung und Ausdauer bedanken. Ohne diese wäre dieses Buch nicht möglich gewesen, denn unsere Freizeit ist eigentlich die Zeit mit ihnen.

Unser Dank gilt ebenfalls dem German Testing Board (GTB), das durch die Gründung der AG Security auch die Autorengruppe selbst zusammengebracht und bei ihrer Arbeit unterstützt hat. Unser Dank gilt ganz besonders den weiteren Mitgliedern der AG Security und den Reviewern des deutschen Sicherheitstester-Lehrplans.

Beim dpunkt.verlag bedanken wir uns herzlich für die umfangreiche Unterstützung in allen organisatorischen und technischen Fragen rund um das Buch und insbesondere, dass der Verlag uns die Gelegenheit gab, dieses Buch überhaupt zu schreiben.

An Professor Dr. Andreas Spillner sei an dieser Stelle ein herzliches Dankeschön gerichtet und ein großes Lob für seine hilfreichen Anmerkungen und Verbesserungsvorschläge bei der Entstehung des Buches.

Frank Simon, Jürgen Großmann, Christian Alexander Graf,Jürgen Mottok, Martin A. Schneider

P.S.:

Zu guter Letzt bedanken sich Christian Alexander Graf, Jürgen Mottok, Martin Schneider und Jürgen Großmann ausdrücklich bei Frank Simon für die hervorragende Projektleitung, die vielen Reviews und die professionelle Organisation und Moderation von Telkos und Autorentreffen. Ohne dich, Frank, wäre dieses Buch wahrscheinlich auch 2020 noch nicht fertig.

Inhaltsübersicht

Einleitung

1Grundlagen des Testens der Sicherheit

2Zweck, Ziele und Strategien von Sicherheitstests

3Sicherheitstestprozesse

4Sicherheitstesten im Softwarelebenszyklus

5Testen von Sicherheitsmechanismen

6Menschliche Faktoren beim Test der IT-Sicherheit

7Auswertung von Sicherheitstests und Abschlussberichte

8Sicherheitstestwerkzeuge

9Standards und Branchentrends

Anhang

AAbkürzungen

BLiteraturverzeichnis

Index

Inhaltsverzeichnis

Einleitung

1Grundlagen des Testens der Sicherheit

1.1Sicherheitsrisiken

1.1.1Die Rolle der Risikobewertung beim Testen der Sicherheit

1.1.1.1ISO 31000

1.1.1.2Das Risiko im Detail

1.1.1.3Grenzen der Risikobewertung

1.1.2Ermittlung der Assets

1.1.2.1Wert eines Assets

1.1.2.2Der Ort eines Assets

1.1.2.3Der Zugriff auf ein Asset

1.1.2.4Der Schutz von einem Asset

1.1.3Analyse von Verfahren der Risikobewertung

1.2Informationssicherheitsrichtlinien und -verfahren

1.2.1Verstehen von Informationssicherheitsrichtlinien und -verfahren

1.2.2Analyse von Sicherheitsrichtlinien und -verfahren

1.3Sicherheitsaudits und ihre Rolle beim Testen der Sicherheit

1.3.1Zweck und Beispiele eines Sicherheitsaudits

1.3.2Risikomodelle für den praktischen Umgang mit Sicherheitsrisiken

1.3.3Mensch, Prozess und Technik

1.4Was Sie in diesem Kapitel gelernt haben

2Zweck, Ziele und Strategien von Sicherheitstests

2.1Einleitung

2.1.1Unbefugtes Kopieren von Anwendungen oder Dateien

2.1.2Fehler in der Zugangskontrolle

2.1.3Cross-Site Scripting (XSS)

2.1.4Pufferüberläufe

2.1.5Dienstblockade (Denial of Service)

2.1.6Man-in-the-Middle-Angriffe und Brechen von Verschlüsselungen

2.1.7Logische Bombe

2.1.8Code Injection (CI)

2.2Der Zweck von Sicherheitstests

2.3Der Unternehmenskontext

2.4Ziele von Sicherheitstests

2.4.1Informationsschutz und Sicherheitstests

2.4.2Ermittlung von Sicherheitstestzielen

2.4.2.1Betrachtung am Beispiel eines mittelständischen Unternehmens

2.5Der Umfang von Sicherheitstests und die Überdeckung von Sicherheitstestzielen

2.5.1Typische Phasen eines Sicherheitstests

2.5.2Umfang von Sicherheitstests

2.6Vorgehensweisen im Sicherheitstest

2.6.1Bestandteile der Vorgehensweise im Sicherheitstest

2.6.2Ursachen mangelhafter Sicherheitstests

2.6.2.1Mangelndes Engagement der Führungsebene und fehlende Bereitstellung von Ressourcen

2.6.2.2Mangelhafte Implementierung der Sicherheitstestvorgehensweise, fehlende Kompetenzen oder Werkzeuge

2.6.2.3Fehlende Unterstützung seitens des Unternehmens oder der Stakeholder

2.6.2.4Fehlendes Verständnis für Sicherheitsrisiken

2.6.2.5Testvorgehensweise, Teststrategie und übergeordnete Richtlinien passen nicht zusammen

2.6.2.6Fehlendes Verständnis für den Zweck des Systems und fehlende technische Informationen

2.6.3Der Sicherheitstest als Business Case aus Sicht der Stakeholder

2.6.3.1Sicherheitstest als Business Case

2.6.3.2Stakeholder

2.7Optimierung der Sicherheitstestpraktiken

2.7.1Überdeckungsgrade für Sicherheitsrisiken

2.7.2Überdeckungsgrade von Sicherheitsrichtlinien und Strategien für den Test

2.7.3Überdeckungsgrade von Sicherheitsanforderungen für den Test

2.7.4KPIs für die Wirksamkeit von Sicherheitstests

2.8Was Sie in diesem Kapitel gelernt haben

3Sicherheitstestprozesse

3.1Einleitung

3.1.1Der Sicherheitstestprozess basierend auf dem Testprozess nach ISTQB®

3.1.2Ausrichtung des Sicherheitstestprozesses an einem bestimmten Entwicklungslebenszyklusmodell

3.2Planung von Sicherheitstests

3.2.1Ziele der Sicherheitstestplanung

3.2.2Das Sicherheitstestkonzept

3.3Entwurf von Sicherheitstests

3.3.1Entwurf von Sicherheitstests für Anwendungen

3.3.1.1Sicherheitsmechanismen, -risiken und Schwachstellen

3.3.1.2Dokumentation von Sicherheitstests

3.3.2Entwurf von Sicherheitstests gestützt auf Richtlinien und Verfahren

3.4Ausführung von Sicherheitstests

3.4.1Schlüsselelemente und Merkmale einer effektiven Sicherheitstestumgebung

3.4.2Bedeutung von Planung und Genehmigungen für Sicherheitstests

3.5Bewertung von Sicherheitstests

3.6Wartung von Sicherheitstests

3.7Was Sie in diesem Kapitel gelernt haben

4Sicherheitstesten im Softwarelebenszyklus

4.1Die Rolle der Sicherheit im Softwarelebenszyklus

4.1.1Der Softwarelebenszyklus und Lebenszyklusmodelle

4.1.2Sicherheit in den Phasen des Softwarelebenszyklus

4.1.3Die Ermittlung von Sicherheitsanforderungen

4.1.4Der Entwurf sicherer Software

4.1.5Die Implementierung sicherer Software

4.1.6Die Integration und Verifikation sicherer Software

4.1.7Die Transition sicherer Software

4.1.8Die Aufrechterhaltung der Sicherheit während des Betriebs

4.1.9Sicherheitstesten im Softwarelebenszyklus

4.2Die Rolle des Sicherheitstestens in der Anforderungsermittlung

4.3Die Rolle des Sicherheitstestens beim Entwurf

4.4Die Rolle des Sicherheitstestens während der Implementierung

4.4.1Der statische Test von Softwarekomponenten

4.4.2Der dynamische Test von Softwarekomponenten

4.4.2.1Whitebox- und Glassbox-Sicherheitstests

4.4.2.2Anforderungsbasierte und risikobasierte Sicherheitstests

4.4.2.3Abdeckungsmaße zur Bewertung von Sicherheitstests

4.5Die Rolle des Sicherheitstestens während der Integration & Verifikation

4.5.1Sicherheitstests während der Komponentenintegration

4.5.2Sicherheitstesten während des Systemtests

4.6Die Rolle des Sicherheitstestens in der Transitionsphase

4.6.1Sicherheitstesten im Abnahmetest

4.6.2Definition und Pflege sicherheitsbezogener Abnahmekriterien

4.6.3Zusätzliche Umfänge betrieblicher Abnahmetests

4.7Die Rolle des Sicherheitstestens während Betrieb & Wartung

4.7.1Sicherheitstesten als Regressions- und Fehlernachtest

4.7.2Penetrationstest

4.8Was Sie in diesem Kapitel gelernt haben

5Testen von Sicherheitsmechanismen

5.1Systemhärtung

5.1.1Das Konzept der Systemhärtung

5.1.2Testen der Wirksamkeit der Mechanismen der Systemhärtung

5.2Authentifizierung und Autorisierung

5.2.1Authentizität und Authentisierung

5.2.2Der Zusammenhang zwischen Authentifizierung und Autorisierung

5.2.3Testen der Wirksamkeit von Authentifizierungs- und Autorisierungsmechanismen

5.3Verschlüsselung

5.3.1Das Konzept der Verschlüsselung

5.3.1.1Kryptografische Grundprinzipien

5.3.1.2Symmetrische Verschlüsselungen

5.3.1.3Asymmetrische Verschlüsselungen

5.3.1.4Hashverfahren

5.3.1.5Transport Layer Security (TLS)

5.3.2Testen der Wirksamkeit gängiger Verschlüsselungsmechanismen

5.3.2.1Tests auf Designschwächen der Verschlüsselung

5.3.2.2Tests auf Schwachstellen in der Implementierung

5.3.2.3Prüfung auf Schwachstellen in der Konfiguration von Verschlüsselungssystemen

5.4Firewalls und Netzwerkzonen

5.4.1Konzepte von Firewalls

5.4.1.1Paketfilterung

5.4.1.2Proxy-Firewall (Vermittler)

5.4.1.3Applikationsfilter

5.4.1.4Dual-Homed Bastion

5.4.2Testen der Wirksamkeit von Firewalls

5.4.2.1Testen der Konfiguration einer Firewall

5.4.2.2Portscans

5.4.2.3Fehlerhafte Netzwerkpakete und Netzwerk-Fuzzing

5.4.2.4Fragmentierungsangriffe

5.4.2.5IT-Grundschutz einer Firewall

5.5Angriffserkennung

5.5.1Verstehen des Konzepts von Werkzeugen zur Angriffserkennung

5.5.2Testen der Wirksamkeit von Werkzeugen der Angriffserkennung

5.5.3Verfahren für die Anomalieerkennung zur Identifikation von Angriffen

5.6Schadprogrammscans

5.6.1Konzepte der Schadprogrammscanner

5.6.2Testen der Wirksamkeit von Schadprogrammscannern

5.7Datenmaskierung

5.7.1Konzept der Datenmaskierung

5.7.1.1Techniken der Datenmaskierung

5.7.1.2Diskussion ausgewählter Techniken der Datenmaskierung

5.7.2Testen der Wirksamkeit von Datenmaskierungsverfahren sowie maskierter Daten

5.8Schulungen

5.8.1Bedeutung von Sicherheitsschulungen

5.8.2Testen der Wirksamkeit von Sicherheitsschulungen

5.8.2.1Der Schulungsprozess

5.8.2.2Szenarien während der Schulung

5.8.2.3Wirksamkeit von Übungen und Prüfungen im Sicherheitstesten

5.9Was Sie in diesem Kapitel gelernt haben

6Menschliche Faktoren beim Test der IT-Sicherheit

6.1Motivation

6.2Kommunikationsmodelle für Social Engineers

6.2.1Kanalmodell nach Berlo

6.2.2Kommunikationsquadrat nach Friedemann Schulz von Thun

6.2.3Feedback nach den logischen Ebenen nach Dilts

6.2.4Wertemodell nach Graves/Falter/Mottok

6.3Verstehen der Angreifer

6.3.1Der Einfluss des menschlichen Verhaltens auf Sicherheitsrisiken

6.3.2Verstehen der Mentalität von Angreifern

6.3.3Allgemeine Motive und Quellen für Angriffe auf Computersysteme

6.3.4Angriffsszenarien und -motive

6.3.4.1Erfassung und Authentifizierung

6.3.4.2Reaktion bei Sicherheitsstörfällen

6.3.4.3Analyse und Beweissicherung

6.4Social Engineering

6.5Sicherheitsbewusstsein

6.5.1Die Bedeutung des Sicherheitsbewusstseins

6.5.2Schärfung des Sicherheitsbewusstseins

6.6Zwei Fallbeispiele

6.7Reverse Social Engineering

6.8Social Engineering Pentests

6.9Was Sie in diesem Kapitel gelernt haben

7Auswertung von Sicherheitstests und Abschlussberichte

7.1Auswertung von Sicherheitstests

7.2Berichterstattung für Sicherheitstests

7.2.1Abschlussbericht für Sicherheitstests

7.2.2Sicherheitstestzwischenberichte

7.3Wirksamkeit von Sicherheitstestberichten

7.4Vertraulichkeit von Sicherheitstestergebnissen

7.5Was Sie in diesem Kapitel gelernt haben

8Sicherheitstestwerkzeuge

8.1Typen und Funktionen von Sicherheitstestwerkzeugen

8.1.1Werkzeuge für dynamische Sicherheitstests

8.1.2Statische und dynamische Sicherheitstestwerkzeuge

8.2Werkzeugauswahl

8.2.1Analysieren und Dokumentieren von Sicherheitstesterfordernissen

8.2.2Open-Source-Werkzeuge und kommerzielle Produkte

8.3Was Sie in diesem Kapitel gelernt haben

9Standards und Branchentrends

9.1Sicherheitsteststandards und Sicherheitsnormen

9.1.1Die Vor- und Nachteile der Verwendung von Standards und Normen

9.1.2Anwendungsszenarien von Standards und Normen

9.1.2.1BSI-Gesetz

9.1.2.2DSGVO

9.1.2.3BAIT/VAIT

9.1.3Auswahl von Sicherheitsstandards und -normen

9.2Anwenden von Sicherheitsstandards

9.3Branchen- und andere Trends

9.4Was Sie in diesem Kapitel gelernt haben

Anhang

AAbkürzungen

BLiteraturverzeichnis

Index

Einleitung

»The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards – and even then I have my doubts.«

Gene Spafford

»Und um genau in solchen Zweifelsfällen maximale Transparenz zu bekommen, bedarf es der Sicherheitstests.«

Die Autoren

Was ist heute der mit Abstand wichtigste Aspekt einer IT-Strategie? Eine verbesserte User Experience? Eine bessere funktionale Qualität? Die Nutzung von Cloud? Die Einführung neuer Vorgehensweisen wie »Agile« oder »DevOps«?

Es ist die IT-Sicherheit!

Der World-Quality-Report 2018/2019 [CapGemini et al. 18] hebt deutlich hervor, dass die IT-Sicherheit heute das entscheidende Qualitätsmerkmal schlechthin ist und über eine entsprechende IT-Strategie gefördert werden muss. Gute Gründe dafür sind:

Der eigene Schutz und der Schutz der Kunden sowie die damit verbundene Fähigkeit, am Markt nachhaltig bestehen zu können.

Die Außenwahrnehmung, um als verantwortungsbewusster und professioneller Anbieter angesehen zu werden und darüber Wettbewerbsvorteile darstellen zu können.

Die Notwendigkeit, gesetzliche Vorgaben zu erfüllen.

Unabhängig von den konkreten Gründen zeigt sich jeweils schnell, dass die Sicherheit kein reines Technikthema ist: Sicher kennt jeder die Hacker-Sessions auf Konferenzen und Ausstellungen, in denen meist junge Hacker eindrucksvoll demonstrieren, wie technische Schwachstellen in IT-Systemen leichtgewichtig und live ausgehebelt werden können. Aber ebenso sollte heute klar sein, dass die beste Technik kaum hilft, wenn sie nicht in die entsprechenden Prozesse eingewoben ist, die von Organisationen mit geschulten Menschen genutzt wird. Sicherheit ist ein extrem vielschichtiges Qualitätsmerkmal, dessen Gesamtstatus durch das schwächste Glied der Kette definiert ist, das häufig wiederum beim Menschen selbst liegt. Das auch heute immer noch weltweit meistgenutzte Passwort als Zeichenfolge »123456« belegt dies eindrucksvoll (vgl. z.B. [HPI 18]).

Eine bisher wenig im Rampenlicht stehende Teildisziplin ist hier das Sicherheitstesten, also das systematische Prüfen, inwieweit die Sicherheit eines Systems angemessen ist und durch entsprechende Konzepte nachhaltig garantiert werden kann. Oder andersherum das Aufzeigen, wo eben die schwächsten Glieder in einer gesamten Organisation liegen und wie diese abgesichert werden können.

Dieses Buch ist genau diesem Thema gewidmet. Als inhaltlicher Leitfaden dient hierbei der Syllabus »Sicherheitstester« des German Testing Board (GTB), der seinerseits die Lokalisierung des Syllabus »Security Tester« des International Software Testing Qualifications Board (ISTQB®) darstellt. Dass eine Lokalisierung mehr als eine reine Übersetzung ist, zeigt bereits die Schwierigkeit des Begriffs Security: Während im englischsprachigen Raum eine klare Abtrennung zur Safety, also dem Schutz der physischen Unversehrtheit, existiert, subsumiert der deutsche Begriff Sicherheit umgangssprachlich meist beide Facetten. In diesem Buch möchten die Autoren trotzdem den Begriff des Sicherheitstesters alias Security Tester etablieren, auch um sich nicht zu weit vom De-facto-ISTQB®-Standard zu entfernen.

Der Vorteil dieser inhaltlichen Nähe ist dann auch die Möglichkeit, sich mit diesem Buch aktiv auf die entsprechenden Prüfungen zum »ISTQB® Certified Tester – Advanced Level Specialist – Security Tester« vorzubereiten. Der Nachteil ist, dass es kaum Möglichkeiten gibt, bestimmte Aspekte wegzulassen, neue Aspekte hinzuzufügen oder ggf. in einem ganz anderen Kontext zu erläutern: Die Struktur des Buches ist eng am Syllabus angelegt, die durch klar definierte Rollen der Autoren beleuchtet und letztlich angereichert wurde:

Die wissenschaftliche Seite, vertreten durch Prof. Dr. Jürgen Mottok, Professor für sichere und zuverlässige Systeme an der Ostbayerischen Technischen Hochschule Regenburg, zeigt auf, was heute als Stand der Wissenschaft grundsätzlich überhaupt möglich ist (und was nicht).

Die forschende Anwendungsseite, vertreten durch Dr. Jürgen Großmann und Martin Schneider des Fraunhofer-Instituts FOKUS, bringt die Praktikabilität wissenschaftlicher Techniken als Stand der Technik ein.

Die Anwendungsseite, vertreten durch Dr. Frank Simon von der Zurich Versicherungsgruppe Deutschland, steuert den Stand der Praxis und die typischen Herausforderungen existierender Systeme für die Gegenwart und die Zukunft bei.

Die pädagogisch-didaktische Seite, vertreten durch Christian Graf als langjährigen Trainer unterschiedlicher Schulungen, trägt Best Practices im Bereich der Vermittlung nicht trivialer Inhalte wie Sicherheitstesten bei.

Trotz dieser vielschichtigen Expertise und gerade wegen des speziellen Themas kann dieses Buch nur einen Impuls geben, sich mit dem Thema Sicherheitstesten intensiv zu beschäftigen. Es wäre fahrlässig zu behaupten, nach der Lektüre ausgewiesener Sicherheitstester zu sein. Nicht ohne Grund verlangen die GTB/ISTQB®-Statuten für den Sicherheitstester, dass als Vorbedingung einer entsprechenden Prüfung mindestens zwei Jahre Praxiserfahrung im Bereich des Testens vorgewiesen werden müssen. Und selbst dann sorgt die extrem hohe Dynamik im Bereich der Sicherheit dafür, dass einmal erlerntes Wissen jederzeit obsolet werden kann, ggf. modifiziert werden muss oder durch vollständig neue Aspekte erweitert werden sollte. Dieses Buch will und kann hier nur einen initialen Anstoß für eine hochspannende Reise in viele einzelne tiefe Bereiche des Sicherheitstestens geben.

Konkret nähert sich dieses Buch dem Thema Sicherheitstesten über neun Kapitel:

Kapitel 1

beginnt mit der grundlegenden Notwendigkeit für das Sicherheitstesten, den Sicherheitsrisiken. Außerdem wird hier das Konzept der Informationssicherheitsrichtlinien vorgestellt, das sich in der Praxis diesen Sicherheitsrisiken entgegenstellt. Das Sicherheitsaudit, dem der Sicherheitstest zuarbeiten kann, analysiert letztlich das nach Bereinigung der Wirkung der Richtlinien verbliebene Sicherheitsrisiko.

Kapitel 2

wendet sich dann konkret dem Sicherheitstest zu: Neben einem Überblick über typische Sicherheitslücken werden Zweck und Ziele von Sicherheitstests an Beispielen erläutert und deren notwendige Verknüpfung mit Unternehmenszielen aufgezeigt. Außerdem werden hier erste Ideen zu Vorgehensweisen von Sicherheitstests sowie deren Erfolgsmessung aufgezeigt.

Kapitel 3

fokussiert dann genau diese Vorgehensweisen über die Beschreibung konkreter Sicherheitstestprozesse. Hierbei wird die Nähe zum klassischen ISTQB®-Testen und zum Testprozess begründet und auf die jeweiligen Folgeschritte Planung, Entwurf, Ausführung und Bewertung für den Sicherheitstest wird ausführlich eingegangen.

Kapitel 4

projiziert den Sicherheitstest und den zugrunde liegenden Prozess dann auf den Softwareentwicklungsprozess. Die dortigen Phasen Anforderungsermittlung, Entwurf, Implementierung, Test und Betrieb werden hier um wichtige Aspekte des Sicherheitstestens angereichert.

Kapitel 5

beschäftigt sich mit den Kernthemen des Sicherheitstestens, der Überprüfung klassischer Sicherheitstechniken: Wie können IT-Systeme bezüglich der Sicherheit getestet werden, wie können Authentifizierungs-, Autorisierungs- und Verschlüsselungsmethoden geprüft werden, wie sehen effektive Infrastrukturen wie Firewalls und Netzwerkzonen aus? Kontrastiert wird dies durch das Testen mittels aufdeckender Technologien wie Angriffserkennungen, Malware-Scans und Datenmaskierungen sowie durch die Erläuterung der Wichtigkeit präventiver Arbeit in Form von Schulungen.

Kapitel 6

untersucht die menschlichen Faktoren beim IT-Sicherheitstest: Warum und wie denken und arbeiten Angreifer? Wie funktioniert Social Engineering und welche Rolle spielt das allgemeine Sicherheitsbewusstsein von Mitarbeitern für eine möglichst hohe IT-Gesamtsicherheit?

Kapitel 7

beschreibt, wie Sicherheitstests ausgewertet und die Ergebnisse in Abschlussberichten aufbereitet sein sollten und welche besonderen Anforderungen an die Sicherheitstestergebnisse bezüglich der Berichterstattung gestellt werden.

Kapitel 8

zeigt einige typische Beispiele von Sicherheitstestwerkzeugen und beschreibt praxiserprobte Methoden zur Werkzeugauswahl.

Kapitel 9

beschließt dieses Buch mit einer Einführung in für den Sicherheitstester besonders relevante Standards und Branchentrends. Es gibt darüber hinaus eine Übersicht, über welche Informationskanäle welche Arten von Informationen ein Sicherheitstester erlangen kann und sollte.

Nach dem Lesen und Durcharbeiten dieser Kapitel sollte es möglich sein, sowohl eine Prüfung zum Certified Sicherheitstester erfolgreich abzulegen als auch nur einen guten Überblick über den Themenbereich Sicherheitstester insgesamt zu bekommen. Das umfangreiche Quellenverzeichnis sowie der Index erlauben zudem auch das punktuelle Einarbeiten und Nachschlagen, wenn es um den aktuellen Stand der Technik im Bereich des Sicherheitstestens für bestimmte Themenblöcke geht.

1Grundlagen des Testens der Sicherheit

»Man kann und darf wohl sein eigenes Leben für eine Sache riskieren, aber nie das Leben eines anderen.«

Sir Karl Raimund Popper

Eine maximale Sicherheit ist in den heutigen IT-Systemen wirtschaftlich sinnvoll nicht möglich und technisch höchst anspruchsvoll. Für das Abwägen, wie viel Sicherheit dennoch nötig ist und wie viel Restrisiko akzeptabel ist, spielt die Risikobewertung der wesentlichen Business-Assets eine fundamentale Rolle: In diese fließen unterschiedliche, möglichst alle Risiken abdeckende Parameter im Vorfeld von Sicherheitstests ein. Sie bestimmt nach Festlegen von Sicherheitsstufen pro Asset die Planung von Sicherheitsmaßnahmen und Sicherheitstests. Hierunter fallen auch proaktive Maßnahmen in Form von Sicherheitsrichtlinien, die klare Handlungsanweisungen vorgeben, um inhärent sichere Systeme zu erstellen. Die Wirksamkeit solcher Richtlinien muss allerdings alleine aufgrund stetig ändernder Sicherheitsgefährdungen regelmäßig mittels Sicherheitsaudits geprüft und bei Bedarf durch aktuelle Sicherheitstests nachgeschärft werden. Das gesamte prozessorale und technische Zusammenspiel aus Richtlinien, Sicherheitstests sowie dem Berücksichtigen zukünftiger möglicher Gefährdungen bei fortwährender Wirksamkeitsoptimierung wird durch Sicherheitsaudits analysiert und systematisch verbessert.

1.1Sicherheitsrisiken

1.1.1Die Rolle der Risikobewertung beim Testen der Sicherheit

Schon das klassische funktionale Testen basiert auf einer Vielzahl von projekt- und unternehmensspezifischen Elementen: So sind z.B. Anforderungen, Anwendungsfälle und mögliche Risiken hinter identifizierten Abweichungen von einem Soll individuell zu berücksichtigen: Eine angepasste Testplanung wird ihren Fokus meist auf solche Anwendungsfälle legen, deren Ausfall massiven Schaden (z.B. wirtschaftlicher Schaden durch entgangenen Umsatz) hervorrufen kann, oder auf solche, die besonders häufig genutzt werden (und bei denen eine Abweichung eher effektiv wird). Die Testtiefe wird dann jeweils entsprechend diesem Fokus festgelegt.

Sicherheitstests verfolgen einen ähnlich risikobasierten Ansatz, fokussieren aber pro Anwendungsfall deren Sicherheitsaspekte und mögliche Gefährdungen: Diese müssen nicht nur technisch sein, sondern berücksichtigen auch

Verhaltensmuster von Angreifern, wenn sich etwa Angriffshäufungen für bestimmte Industrien, Regionen oder Techniken abzeichnen,

prozessorale Lücken, wenn etwa eingerichtete Zutrittskontrollen aus Bequemlichkeit umgangen werden, und

organisatorische Unstimmigkeiten, wenn Anweisungen für z.B. Passwortrücksetzungen nicht zentral verantwortet werden.

Die Ziele von Sicherheitstests richten sich nach bestehenden Sicherheitsrisiken, also Risiken, die durch eine ungenügende Sicherheit auftreten können. Kann keinerlei direkter oder indirekter Schaden hervorgerufen werden, so sind Sicherheitstests aus wirtschaftlichen Gründen nicht angezeigt.

Sicherheitstests folgen einer Risikoanalyse, nicht umgekehrt.

Existierende Risiken sind also eine notwendige Vorbedingung für Sicherheitstests. Diese Risiken werden üblicherweise im Rahmen einer Sicherheitsrisikobewertung ermittelt. Allgemeine Risikomanagementtechniken werden bereits aus dem normalen, meist funktionalen Kontext heraus in [GTB CTFL 18] und [GTB CTAL TM 12] beschrieben: Denn auch dort gilt, dass ein Testen einer Funktionalität, deren Fehlverhalten oder vollständiges Ausfallen keinen Schaden anrichtet, wirtschaftlich nicht angezeigt ist.

International weit verbreitet sind die Risikomanagementtechniken der Standards ISO 31000 [ISO 31000] und ISO 27005 [ISO 27005] sowie der Richtlinie NIST 800-30 [NIST SP 800-30 02]. Während die ISO 31000 den allgemeinen Ablauf des Risikomanagements beschreibt, und damit auch außerhalb der IT angewendet wird, fokussiert die ISO 27005 speziell Informationssicherheitsrisiken. NIST 800-30 hat insbesondere für den nordamerikanischen Markt eine große Bedeutung.

1.1.1.1ISO 31000

Die ISO 31000 (vgl. [ISO 31000]) bietet eine übersichtliche und gut verständliche Risikomanagementtechnik, die wie in Abbildung 1–1 dargestellt werden kann.

Abb. 1–1Schematische Darstellung der ISO 31000

Die ISO 31000 beschreibt einen eingängigen, universell einsetzbaren Risikomanagementprozess.

Sie ist dabei hinreichend generisch, um auch in tagtäglichen Situationen risikobasiert vorzugehen. Dies soll anhand eines Szenarios verdeutlicht werden.

Beispiel: Risikomanagement

Beispiel: Risikomanagement

Das folgende Beispiel ist bewusst dem Nicht-IT-Bereich entnommen und soll den universellen Charakter des Risikomanagements aufzeigen. Im konkreten Beispiel geht es um die Abschätzung, ob man abends ein Bier trinken sollte, wenn man anschließend noch mit dem Auto selbst nach Hause fahren muss.

Eine allgemeingültige Sicht auf eine solche Risikoanalyse ist in Abschnitt 1.1.3 weiter unten beschrieben. Das konkrete Beispiel wird im Folgenden entlang des beschriebenen Risikomanagementprozesses betrachtet:

Zusammenhangerstellung

Auch wenn die schädliche Wirkung der Zutat Bier außer Frage steht, gibt es weitere Parameter aus einem konkreten Kontext, die für die Folgeabschätzung relevant sind: Handelt es sich beim potenziellen Trinker um eine Schwangere, muss anschließend noch Auto gefahren werden, gibt es gruppendynamische Effekte und Einflüsse usw.

Risikoidentifikation

In diesem Abschnitt werden für den konkreten Kontext (vgl. vorheriger Schritt) die einzelnen Risiken identifiziert. Die Abhängigkeit zum Kontext ist hier wichtig: Erzeugt eine Schwangere z.B. Risiken für sich und das ungeborene Kind, so gefährdet ein Mann ggf. nur sich (aber Achtung: Straßenverkehr).

Risikoanalyse

In diesem Schritt werden die einzelnen Risiken detailliert analysiert: Wie groß ist der mögliche Schaden, welche Art ist der Schaden (monetär, gesundheitlich, reputationsbezogen usw.), wie wahrscheinlich ist er usw. Im konkreten Fall könnten medizinische Studien herangezogen werden, Verkehrsstatistiken oder auch soziologische Studien für den Fall, dass ein Nicht-Trinken zur Gruppenisolation führt.

Risikobewertung

In diesem Schritt findet ein Abgleich der Ergebnisse der Risikoanalyse mit dem eigenen Risikoappetit statt: So können zwei Menschen in einem sehr ähnlichen Kontext trotz sehr ähnlicher Risikoanalysen immer noch völlig unterschiedliche Bewertungen erzeugen; äußern kann sich das im nächsten Schritt der Risikobehandlung als ein unbekümmertes Trinken oder ein entsetztes Ablehnen des Getränkeangebotes.

Risikobehandlung

Dieser Schritt bedeutet die eingeleitete Aktivität auf Basis der Bewertung. Die ISO sieht hier vier verschiedene Arten vor:

Das Risiko akzeptieren, was in dem konkreten Beispiel zum Trinken des Bieres führen würde.Das Risiko vermeiden, was zum Ablehnen des Getränkes führen würde.Das Risiko vermindern, was durch eine Reduktion der Trinkmenge oder des Alkoholgehaltes (Radler) erreicht werden kann.Das Risiko delegieren, was im Falle des Autofahrers bedeuten könnte, den Autoschlüssel seinem ebenfalls mittrinkenden Kollegen zu geben.

Auch wenn dieser Prozess wenig komplex ist und damit evtl. eine einfache Anwendbarkeit suggeriert, so soll bereits hier nicht unerwähnt bleiben, dass eine Risikoanalyse eine höchst anspruchsvolle Aufgabe ist. Häufig werden hier bekannte Risiken vergessen, oder es dominieren eigene Gewohnheiten (»ich trinke immer ein Bier vor dem Nach-Hause-Fahren«) und eigene Risikobereiche (»nachts fahre ich sehr ungern«), oder die Risiken basieren auf unreflektierten Expertenmeinungen. Es benötigt meist sehr viel Erfahrung, wirklich vollständige und objektive Risikoanalysen durchzuführen.

Ohne Risiken bedarf es keiner Risikoanalyse.

Der Sicherheitstest, bei dem geprüft wird, wie sicher ein IT-System ist, lässt sich entlang dieses Standards im Bereich der Risikoidentifikation und der Risikoanalyse verorten. Der Sicherheitstest hilft also, existierende Risiken weiter zu analysieren, und zeigt ggf. weitere auf.

1.1.1.2Das Risiko im Detail

Um eine detaillierte Risikoanalyse durchführen zu können, muss der Begriff Risiko weiter präzisiert werden:

Definition: Risiko

Ein Risiko ist ein Faktor, der zu negativen Konsequenzen in der Zukunft führen könnte, gewöhnlich ausgedrückt durch das Schadensausmaß und die Eintrittswahrscheinlichkeit. [GTB Glossar 18]

Beide Faktoren werden in der Praxis häufig quantifiziert (s. hierzu u.a. weiter unten Abschnitt 1.3.2) und für die Risikokalkulation multipliziert. So kann ein Risiko, das mit einer 1 %igen Wahrscheinlichkeit einen Schaden von 1.000 Euro bedeuten kann, als identisch zu einem anderen Risiko angesehen werden, bei dem mit einer 10%igen Wahrscheinlichkeit ein Schaden von 100 Euro erzeugt werden kann. Das kalkulierte Risiko ist in beiden Fällen 10 Euro.

Beide Faktoren sind in der Praxis häufig nicht leicht und nachvollziehbar analysierbar:

Eintrittswahrscheinlichkeit

Häufig fehlen entsprechende Analysen, sie sind zueinander nicht konsistent oder lassen sich nur bedingt auf einen konkreten Kontext anwenden.

Schaden

Wie lassen sich Reputation, Marktdominanz oder auch gesundheitliche Schäden und Tod quantifizieren? Wie viel ist eine Beziehung »wert«, die z.B. aufgrund einer falsch zugestellten E-Mail zerbricht?

CIA der Security: Vertraulichkeit (Confidentiality=C), Integrität (Integrity=I) und Verfügbarkeit (Availability=A)

Um dennoch die Ermittlung von Eintrittswahrscheinlichkeit und Schaden durchführen zu können, existieren für den Bereich der IT-Sicherheit spezielle Risikomodelle (vgl. hierzu Abschnitt 1.3.2).

Informationssicherheitsrisiken sind nun solche Risiken, die die Sicherheit von Informationen eines Systems gefährden. Diese Definition ist eine Vereinfachung der Definition innerhalb der ISO 27001 [ISO 27001]:

Definition: Informationssicherheitsrisiko

»Als Informationssicherheitsrisiko wird das Potential bezeichnet, dass eine Bedrohung ausgenutzt werden kann und der Organisation so Schaden zugefügt wird.« [Klipper 15]

IT-Sicherheit ist folglich der Zustand, in dem Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und Informationstechnik durch angemessene Maßnahmen geschützt sind (vgl. [BSI Glossar 13]).

Abb. 1–2CIA-Dreieck der Sicherheit

Der Verlust der IT-Sicherheit bedeutet folglich den Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen oder Informationssystemen. Die Risiken hängen ganz wesentlich von den potenziellen schädlichen Auswirkungen auf betriebliche Vorgänge (z.B. Ziele, Funktionen, Image oder Reputation), betriebliche Assets, Individuen, andere Unternehmen sowie ein gesamtes Land ab [NIST SP 800-30 02]. Der Schaden wird dabei wiederum stark vom Kontext des Systems bestimmt:

Schadenshöhen hängen vom Kontext ab.

Ist die Vertraulichkeit eines einfachen, öffentlichen Webservers verletzt, so ist der Schaden gering, da die Informationen per se für jeden gedacht waren. Bei einem internen Schadenssystem einer Versicherung ist ein solcher Verlust dagegen verheerend.

Ist die Verfügbarkeit eines öffentlichen Warenbestellsystems nicht mehr gewährleistet, so beginnt direkt nach der ersten Sekunde der Nichtverfügbarkeit der Schaden durch Umsatzausfall zu wachsen. Die Nichtverfügbarkeit eines Druckers kann dabei bei Ausfällen von einigen Sekunden meist ignoriert werden.

Ist die Integrität eines Wahrsageportals nicht gewährleistet, so kann dies – je nach Grad der Integritätsverletzung und der subjektiven Einstellung zu Wahrsagungen – durchaus vernachlässigt werden. Die Nichtintegrität von Systemen im medizinischen Bereich kann dagegen tödliche Folgen haben.

Im Rahmen einer Sicherheitsrisikobeurteilung, bestehend aus den drei Schritten der ISO 31000 – Risikoidentifikation, Risikoanalyse und Risikobewertung –, kann ein Unternehmen systematisch ermitteln, welche Bereiche und Assets einem Risiko ausgesetzt sind und welchen Schweregrad die einzelnen Risiken haben. Für Sicherheitstester kann eine Sicherheitsrisikobewertung eine ergiebige Informationsquelle sein, auf deren Grundlage sich Sicherheitstests planen und konzipieren lassen. Idealerweise fokussieren Sicherheitstests dabei die besonders großen Risiken. Je größer ein Risiko, desto tiefer die Sicherheitstesttiefe. Die Sicherheitsrisikobewertung hilft also bei der Priorisierung von Sicherheitstests.

Ergebnisse der Sicherheitstests fließen dabei in eine verbesserte Sicherheitsrisikobewertung wieder ein. Sicherheitstests liefern also weitere wichtige Informationen, die für die Bewertung relevant sind.

Einen guten Überblick über die verschiedenen Möglichkeiten, wie Sicherheitsrisikobewertung und Sicherheitstesten sich im Rahmen einer umfassenden Sicherheitsbewertung ergänzen, erlauben die Norm ETSI 203-251 [ETSI 203-251 15] sowie ein technischer Bericht der ETSI mit einigen konkreten Fallbeispielen [ETSI TR 101 582 14].

1.1.1.3Grenzen der Risikobewertung

Risikobewertung als eine fortwährende Aufgabe

Jede Risikobewertung (ob sicherheitsbezogen oder nicht) ist nur eine Momentaufnahme der berücksichtigten Parameter und fußt auf limitierten Informationen.

Beispiel: Geänderte Parameter einer Risikobewertung

Beispiel: Geänderte Parameter einer Risikobewertung

Geänderte Gesetze

Die Neufassung der Datenschutz-Grundverordnung kann dazu führen, dass eine Vielzahl von Risikobewertungen ungültig geworden ist.

Neue Nutzungsszenarien

Der zunehmende Einzug von meist unverschlüsselten Messenger-Diensten in kommerzielle Prozesse führt zu einer Neubewertung der Risiken.

Neue Marktanforderungen

Die zunehmende Sensibilisierung der Gesellschaft für Datenmissbrauch und die mit einem Sicherheitsvorfall aktuell verbundene negative Presse kann zu neuen Risikobewertungen führen.

Daher müssen Sicherheitsrisikobewertungen in regelmäßigen Abständen wiederholt werden. Das genaue Zeitintervall für die Durchführung von Sicherheitsrisikobewertungen variiert in Abhängigkeit vom Unternehmen und vom Grad der Veränderungen der Parameter. Manche Unternehmen führen alle drei bis sechs Monate Sicherheitsrisikobewertungen durch, andere einmal jährlich. Besondere Ereignisse wie z.B. die Einführung neuer Gesetze (vgl. die neue DSGVO 2016 [DSGVO 16]) sollte in jedem Fall zu einer flächendeckenden Neubewertung führen.

Die Anwendung und meist auch Dokumentation systematischer Risikobewertungen hat entgegen subjektiver Ad-hoc-Maßnahmen viele Vorteile:

Nachvollziehbarkeit einer Entscheidung

Bessere Vollständigkeit der Risiken sowie das Erkennen von Zusammenhängen zwischen Risiken. Grundsätzlich gilt, dass die gefährlichsten Risiken diejenigen sein können, die übersehen werden. Systematiken liefern hiergegen Hilfestellungen.

Systematische Vorgehen lassen sich lernen und können zu Expertentum führen. Subjektivität wird dadurch reduziert, dass Hilfsmittel der Systematik wie Checklisten, Brainstorming, Modellierung oder Stakeholder-Management angewendet werden. Auch die bedarfsgerechte Verwendung formalisierter und formaler Techniken wie Fehlerbäume, Ursache-Wirkungs-Analysen oder Monte-Carlo-Simulationen zählen hierzu. Eine ausführliche Liste von Techniken zur Risikobewertung findet sich in der ISO 31010 [

ISO 31010

].

1.1.2Ermittlung der Assets

Assets: wesentliche Güter in einem Unternehmen

Sicherheit bezieht sich vor allen Dingen auf die relevanten Güter eines Unternehmens, die sogenannten Assets: Diese Güter kommen heute im Wesentlichen in zwei Ausprägungen vor [Clement & Schreiber 13, S. 46]:

Non-digitale Güter

Hierzu zählen vor allen Dingen klassische physische Assets wie Maschinen, Gebäude oder IT-Hardware. Allerdings liegen auch viele informationsbasierte Assets heute non-digital vor: Beispiele hierfür sind kopierte Unterlagen, Verträge, Pläne, schriftliche Notizen, notierte Anmeldedaten und Passwörter. Da ihr Wert allerdings primär durch den Informationsgehalt der Träger (z.B. Papier, Mikrofilm) geprägt ist, werden sie auch als semiphysische Assets bezeichnet.

Digitale Güter

Diese Güter lassen sich vollständig »mit Hilfe von Informationssystemen entwickeln, vertreiben oder anwenden« (vgl. [Clement & Schreiber 13, S. 44]). Beispiele sind Dateien in der Cloud, Musikstücke auf dem Smartphone oder Wirtschaftspläne in Excel.

Ohne Assets keine systematische Risikoanalyse

Für eine Risikoanalyse gilt es, in einem ersten Schritt die relevanten Assets zu ermitteln, um dann jeweils anschließend festzustellen, welche davon in digitaler Form vorliegen und damit im Fokus eines möglichen Sicherheitstests liegen. Diese Gesamtsicht auf die Assets ist aber in jedem Fall wichtig, um überhaupt IT-Sicherheitstests zu motivieren: Liegen die besonders relevanten Assets physisch vor (z.B. Maschinen und Materialien), so führt ein Risikomanagement zuerst zu physischen Maßnahmen wie Zutrittsschutz, bevor IT-Sicherheit betrachtet wird.

Es ist offenkundig, dass mit jeder Änderung der Menge betrachteter Assets auch die Risikoanalyse wiederholt werden muss. Aktuell verändert sich in der Industrie die Menge digitaler Assets am schnellsten, sodass diese Änderungen gleichzeitig Haupttreiber regelmäßiger Risikoanalysen sind:

»[…] für die einzelne Bank bringt die Digitalisierung neue Risiken. Denn die Zahl der schützenswerten Güter ist gewachsen; neben Geldvermögen sind inzwischen auch persönliche Daten und damit der Zugang zu Dienstleistungen im Cyberspace gespeichert.« [Bundesbank 15]

Beispiele für digitale Güter sind:

Kundendaten

Businesspläne

Proprietäre Software, die vom Unternehmen entwickelt wurde

Systemdokumentation

Bilder und Diagramme, die Eigentum des Unternehmens sind

Geistiges Eigentum (z.B. Prozesse, Geschäftsgeheimnisse)

Mitarbeiterdatensätze

Steuererklärungen

Beispiel: Datenschutz-Grundverordnung

Beispiel: Datenschutz-Grundverordnung

Auch die aktuelle Datenschutz-Grundverordnung (DSGVO) legt für die dort mit dem Fokus auf personenbezogene Daten beschriebenen Sicherheitsrisiken einen Fokus auf Assets als ersten Schritt: Dabei wird dort angenommen, dass die wesentlichen Werte in heutigen Unternehmen durch die Kernprozesse gegeben sind. Dort heißt es konkret: »Jeder Auftragsverarbeiter und gegebenenfalls sein Vertreter führen ein Verzeichnis zu allen Kategorien von im Auftrag eines Verantwortlichen durchgeführten Tätigkeiten der Verarbeitung.« Das geforderte Verfahrensverzeichnis (Artikel 30 der DSGVO) ist also eine besondere Sicht auf digitale Assets, die im weiteren dann noch um die eigentlichen Daten-Assets, also insbesondere »Kategorien personenbezogener Daten«, verfeinert werden. Die DSGVO fordert für dieses Verfahrensverzeichnis eine Vollständigkeit, da dies die Ausgangsbasis für eine strukturierte Risikoanalyse darstellt [DSGVO 16].

Abb. 1–3Relevante Aspekte eines Assets für die Risikoanalyse

Für beide Arten von Assets, hier aber vor allen Dingen für digitale Assets, müssen grundsätzlich als Teil einer Risikobewertung folgende Fragen beantwortet werden:

Wert

Wie wertvoll ist das Asset?

Ort

Wo liegen die Assets?

Zugriff

Wie erfolgt der Zugriff auf die Assets?

Schutz

Wie sind die Assets geschützt?

1.1.2.1Wert eines Assets

Assets: Je wertvoller, desto mehr Sicherheitsschutz ist notwendig.

Der Wert eines Assets entscheidet später ganz wesentlich, wie sicherheitsbedürftig es ist: Kaum werthaltige Assets stehen daher für einen Sicherheitstester meist viel weniger im Fokus als solche, die sehr wertvoll sind, zumindest, solange die Eintrittswahrscheinlichkeit eines Schadens ähnlich ist. Die Wertermittlung ist dabei häufig nicht leicht: Am einfachsten zu bestimmen sind hier noch materielle Werte, die vor allen Dingen für non-digitale Güter relevant sind: So hat eine Maschine einen Wert, der dadurch gekennzeichnet ist, wie teuer ihre Beschaffung war (häufig abzüglich eines Abnutzungsfaktors).

Schwieriger sind solche Assets zu beurteilen, deren Wert sich primär an den Kosten und Folgen ihres Verlustes orientiert. Dies gilt für manche non-digitalen Güter (z.B. Prototypen) und für alle digitalen Güter.

Beispiel: Ein digitales Angebot als Asset

Beispiel: Ein digitales Angebot als Asset

Ein schriftliches Angebot in Form eines PDF-Dokumentes hat keinen materiellen Wert, wohl aber einen Wert, der sich darin bemessen lässt, wie viel Umsatz möglicherweise verloren ginge, wenn das Angebot nicht pünktlich zum Ausschreibungsende vorhanden wäre. Ein anderer Wert für dasselbe Asset könnte dadurch bestimmt werden, was ein Mitbewerber für einen wirtschaftlichen Vorteil hätte, wenn er das Angebot bekäme.

Digitale Assets: schwierig in der Werteermittlung

Der Wert gerade für viele digitale Güter lässt sich meist nicht präzise bestimmen, sodass häufig grobe Abschätzungen oder vergleichbare Erfahrungswerte herangezogen werden.

Beispiel: Ermitteln des Wertes digitaler Assets

Beispiel: Ermitteln des Wertes digitaler Assets

Typische Fragen zu Informationen, im Folgenden wiederum bezogen auf den Verlust des digitalen Assets eines Angebotes – z.B. durch das Nutzen unverschlüsselter E-Mail-Kommunikation –, können bei der Wertermittlung des Assets helfen.

Der zukünftige Umsatz, den das Asset verspricht, für das Angebot also der hinterlegte Angebotswert.Der Wert für einen Mitbewerber, der Kenntnis des Assets erhält und damit wirtschaftliche Vorteile gegenüber dem ursprünglichen Asset-Inhaber bekommt. Im Fall des Angebotes ist dies für Standardangebote entlang wohldefinierter Preistafeln (z.B. Kfz-Versicherungen) irrelevant. Im Fall von Angeboten, in denen individuelle Preisabsprachen, ggf. Umsetzungsdetails und Planungsdetails enthalten sind, kann diese Wertdimension durchaus erheblich sein.Der für die Erstellung oder die Neuerstellung des Assets aufgewendete bzw. nötige Zeit- und Aufwandsrahmen. Ein Angebot, für dessen Erstellung z.B. teure Experten hinzugezogen wurden, zeigt in dieser Wertedimension einen deutlichen Ausschlag.Strafen, die im Falle des Unvermögens, das Asset bei Bedarf vorweisen zu können, anfallen. Im Beispiel des Angebotes kann dies relevant werden, falls es – z.B. aufgrund des Verdachtes von Preisabsprachen oder datenschutzrechtlichen Befunden – nicht möglich ist, das Originalangebot für ein Audit oder Gerichtsverfahren vorzuzeigen.Strafen für den Verlust und vor allen Dingen die Weitergabe von datenschutzrechtlichen Daten. Sind im Angebot z.B. hochsensible Daten enthalten, kann die Offenlegung dieses Assets zu sensiblen Strafen führen, die letztlich auch als möglicher Wert des Assets herangezogen werden können.

1.1.2.2Der Ort eines Assets

Nur bekannte Orte können geschützt werden.

Der Schutz eines Assets bedarf der Kenntnis, wo das Asset liegt. Dies gilt auch für digitale Assets, die klassischerweise auf Servern, Computern oder Speichermedien wie externen Festplatten oder CDs gespeichert werden. Es ist gerade für digitale Assets wichtig zu erkennen, dass ein Asset durchaus mehrere Orte haben kann. So hat jedes wertvolle Asset üblicherweise wenigstens zwei Orte: Einmal im produktiven Rechenzentrum und einmal in einem angeschlossenen Backup-System. Und selbst innerhalb des produktiven Rechenzentrums haben Assets meist mehrere Orte, da z.B. hochverfügbare Systeme in der Regel Daten fortwährend auf mehrere Festplatten und Systeme verteilen.

Die Menge von Orten nimmt aktuell aufgrund der Verbreitung von USB-Laufwerken, Smartphones und Tablets kontinuierlich zu. Wird einer der Orte im Kontext der Sicherheitsherstellung vergessen, besteht das Risiko, dass für diesen Ort das Sicherheitsniveau ungenügend ist. In der Vergangenheit haben sich gerade portable Orte alias Medien wie USB-Sticks und Speicherkarten als höchst riskant erwiesen. Als »Ort« von kritischen Assets werden sie zu schnell vergessen, obwohl der Wert ggf. außerordentlich hoch ist.

In 2018 wurden hochvertrauliche Daten des sächsischen Verfassungsschutzes, also einer Institution, der ein hohes Risikobewusstsein zugesprochen wird, auf einen USB-Stick kopiert. Dieser Stick als neuer Ort des Assets wurde von einem Mitarbeiter »aus Neugierde« mit nach Hause genommen und unterlag damit nicht mehr dem nötigen Schutz. [Leipziger Volkszeitung 18]

Der Ort von Assets, die in der Cloud abgelegt werden, ist je nach Cloud-Typ unterschiedlich schwer zu bestimmen. In öffentlichen Clouds obliegt der Ort häufig dem Cloud-Anbieter selbst und der konkrete Ort ist dem Asset-Besitzer nicht transparent. Hier kann dann nur die gesamte Cloud als Ort betrachtet (und später abgesichert) werden.

1.1.2.3Der Zugriff auf ein Asset

Neben dem Wert und dem Ort ist eine weitere wichtige Frage, wie der Zugriff auf das Asset erfolgt. Grundsätzlich gilt hier, dass hierfür jeder Ort eines Assets betrachtet werden muss, da hier der Zugriff erfolgen muss. Während dies bei non-digitalen Gütern fast immer eine physische Präsenz voraussetzt – z.B. um Aktenordner einzusehen –, können digitale Assets deutlich mehr Zugriffsmöglichkeiten bieten:

Am verbreitetsten sind hierfür die folgenden Zugriffsmethoden:

Zugriff per Computer über ein LAN- (Local Area Network), über ein Wi-Fi-Netz oder lokale Netze (Personal Area Network, PAN, z.B. via Bluetooth). Hierbei müssen sich der Zugriffsinitiator und der Asset-Ort im selben physischen Netz befinden.

Zugriff aus der Ferne auf einen Asset-Ort, entweder über ein VPN-(Virtual Private Network) oder ein Cloud-Laufwerk. Der Zugriffsinitiator und der Asset-Ort befinden sich hierbei in unterschiedlichen physischen Netzen.

Direkte Weitergabe physischer Datenspeicher (CDs, DVDs, USB-Laufwerke) von Person zu Person.

Verschicken oder Teilen von Assets über unterschiedliche Plattformen (via E-Mail, WhatsApp, SnapChat usw.).

1.1.2.4Der Schutz von einem Asset

Jeder Zugriff auf einen oder mehrere Orte eines Assets kann unterschiedlich geschützt sein. So kann der Zugriff auf ein digitales Asset auf einem USB-Stick dadurch erschwert werden, dass der Stick in einem Tresor eingeschlossen ist. Für die Zugriffsart des Auslesens des USB-Sticks kann wiederum Verschlüsselung eine wichtige Schutzrolle übernehmen.

Assets können durch eine angemessene Authentifizierung, Autorisierung und Verschlüsselung geschützt werden.

Der Schutz von Assets und ihren Zugriffen im Allgemeinen kann vor allen Dingen über drei Aspekte erfolgen (vgl. hierzu auch Kap. 5):

Authentifizierung

Jeder Zugriff ist nur nach einer Identifikation des Asset-Interessenten erlaubt. Der Fingerabdrucksensor eines modernen Smartphones ist eine typische Authentifizierungsmaßnahme, um den Anwender eindeutig zu identifizieren.

Autorisierung

Welche Berechtigungen hat ein authentifizierter Nutzer für das Asset? Darf er es nur lesen oder auch schreiben und löschen.

Verschlüsselung

Die Verschlüsselung bezieht sich vor allen Dingen auf die Form der Abspeicherung sowie die Form der Übertragung.

1.1.3Analyse von Verfahren der Risikobewertung

Sicherheitsrisikobewertungen ähneln sehr stark einer standardmäßigen Risikobewertung.

Die Bewertung der speziellen Sicherheitsrisiken ähnelt sehr stark einer standardmäßigen Risikobewertung. Ergebnisse einer Sicherheitsbewertung fließen gerade in größeren Unternehmen in eine allgemeinere Risikobewertung ein. Beispiele allgemeinerer und damit nicht mehr in den Bereich der IT-Sicherheit fallender Risikobewertungen sind Währungsrisiken, Unwetterrisiken und politisch-gesellschaftliche Risiken.

Eine Sicherheitsrisikobewertung sollte die Perspektiven möglichst vieler interner und externer Stakeholder (Schlüsselpersonen) einnehmen. Je ganzheitlicher diese Perspektiven ausgewählt werden, desto vollständiger wird die Risikoidentifikation und -beurteilung sein.

Je mehr Perspektiven eine Sicherheitsbewertung berücksichtigt, desto ganzheitlicher ist sie.

Zu typischen Stakeholdern für eine Sicherheitsbewertung zählen neben der Organisation selbst, die die Assets verwaltet:

Kunden und Benutzer

Aus dieser Perspektive können typische Anwendungsfälle betrachtet werden, insbesondere IT-Infrastruktur (da z.B. gerade Privatkunden nicht die modernste IT verwenden) und fahrlässige Verhaltensweisen (z.B. ein und dasselbe Passwort für verschiedene Systeme). Diese Perspektive hilft auch bei der Risikobewertung, da gerade Kundendaten häufig im Fokus von Risikoanalysen stehen.

Öffentlichkeit und Gesellschaft

Auch die Öffentlichkeit und Gesellschaft kann für eine Analyse herangezogen werden. So sind z.B. regelmäßig geänderte Datenschutzbestimmungen technisch und juristisch problemlos möglich, werden aber von der Öffentlichkeit in der Regel als störend wahrgenommen. Hilfreich sind hier repräsentative Studien, die einen guten Eindruck über die Gesamtstimmung vermitteln. Ein plakatives Beispiel ist die teilweise sehr ernüchternde Wahrnehmung der Sinnhaftigkeit der neuen DSGVO (vgl. [Woll 18]). Auch die Planung von Kommunikation z.B. im Falle von Sicherheitsvorfällen muss diese Stakeholder berücksichtigen, da ansonsten trotz aller technischen und legalen Konformität die Reputation gefährdet sein kann.

Aufsichtsbehörden

Diese Stakeholder sind durch Vorgabe von Mindestanforderungen an das Sicherheitsmanagement ganz wesentlich. In Deutschland ist hier z.B. für den Bereich der Banken und Versicherungen die Bundesanstalt für Finanzdienstleistungen (BaFin) ein wichtiger Stakeholder, für kritische Infrastruktur ist das Bundesamt für Informationssicherheit (BSI) zuständig. Aufsichtsbehörden sind notwendig für die Gewährleistung der Konformität mit geltenden Gesetzen bezüglich der Informationssicherheit.

Der gesamte Prozess einer Risikobewertung und damit auch einer spezielleren Sicherheitsbewertung erfolgt in der Regel in drei Schritten, wie in Abbildung 1–4 dargestellt.

Abb. 1–4Drei Schritte einer Risikobewertung

Diese High-Level-Darstellung lässt sich ebenfalls problemlos auf die ISO 31000 abbilden (vgl. Abb. 1–1): Die Planung wird dort als Zusammenhangerstellung, die Durchführung als Risikobeurteilung und der Schritt Kommunikation und Maßnahmen als Kommunikation und Beratung beschrieben.

Risikobewertung bedarf einer klaren Planung.

Die Planung (bzw. eben die Zusammenhangerstellung) besteht hierbei vor allen Dingen aus folgenden Aktivitäten und orientiert sich meist am organisatorischen Gesamtrahmen (in der Norm NIST 800-30 selbst als »Organizational Risk Frame« bezeichnet; für Deutschland ist hier häufig der sehr ähnliche BSI-Standard 200-3 maßgeblich [BSI 200-3 17]):

Ermittlung des Zwecks der Bewertung: Erfolgt die Bewertung proaktiv, um das gesamte Gefährdungspotenzial abzuschätzen, oder reaktiv, um z.B. bei Bekanntwerden einer Sicherheitslücke das spezifische von dieser Lücke für ein Unternehmen ausgehende Risiko zu ermitteln.

Ermittlung des Umfangs der Bewertung: Dies kann von einigen wenigen Stunden für einen Mitarbeiter bis hin zu Monaten und Jahren für ganze Teams reichen. Ein gutes Beispiel für einen großen Umfang ist z.B. das vom neuen Regulativ der Datenschutz-Grundverordnung [

DSGVO 16

] ausgehende Risiko im Falle der Nichteinhaltung. Hier haben einige Unternehmen mehrköpfige Teams über mehrere Jahre eingesetzt.

Ermittlung der Annahmen und Randbedingungen im Zusammenhang mit der Bewertung. Möglich sind hier z.B. die Nennung von gültigen Gesetzen oder Annahmen über Nutzerprofile.

Ermittlung der Informationsquellen, die als Eingangsquelle für die Bewertung genutzt werden. Möglich sind hier z.B. öffentliche Informationsquellen wie das BSI oder auch Analystenreports wie von Gartner und Forrester.

Ermittlung des Risikomodells und der analytischen Konzepte (d.h. Bewertungs- und Analysekonzepte), die bei der Bewertung zu nutzen sind. Hier sind vor allen Dingen Angaben darüber zu machen, wie die Werte der digitalen Assets ermittelt werden, wie die Risikowahrscheinlichkeiten abgeschätzt wurden, wie Aussagen über mögliche Schadensauswirkungen abgeleitet wurden und welche Risikotoleranz bzw. welchen Risikoappetit ein Unternehmen hat, wie also »

Ertrag und Risiko in der Vorbereitung unternehmerischer Entscheidungen gegeneinander abgewogen werden sollen

« [

Gleißner & Wolfrum 17

].

Die Durchführung von Risikobewertungen umfasst folgende spezifische Aufgaben und orientiert sich sehr eng an der ISO 31000 und den dort formulierten Schritten (vgl. Abschnitt 1.1.1.1, [NIST SP 800-30 02] und [BSI 200-3 17]):

Ermittlung der Gefährdungsquellen, die für das Unternehmen relevant sind. Hierzu zählen grundsätzlich alle Quellen, die eine mögliche Gefährdung auf Assets darstellen. Möglich sind hier z.B. Eingangsbereiche, elektronische Zugänge (WLAN, VPN) oder auch Spionage eigener Mitarbeiter.

Ermittlung der Gefährdungsereignisse, die von diesen Quellen ausgehen können. Der Eingangsbereich kann z.B. blockiert oder für Diebstähle missbraucht werden. Ein elektronischer Zugang kann z.B. gekappt oder abgehört werden.

Ermittlung von Schwachstellen im Unternehmen, die von Gefährdungsquellen mittels konkreter Gefährdungsereignisse ausgenutzt werden könnten. Nicht jedes Gefährdungsereignis jeder Gefährdungsquelle kann tatsächlich zu einer Ausnutzung verwendet werden. Gibt es z.B. ein elektronisches Zutrittssystem, so kann ein unbefugter Zutritt je nach konkreter Umsetzung verhindert oder wenigstens gemindert werden. Auch eine Kappung des elektronischen Zugangs kann nur dann ausgenutzt werden, wenn keine Notfall-Stromversorgung existiert. In diesem Schritt geht es darum, solche Schwachstellen zu identifizieren, für die es konkrete Gefährdungsereignisse über bestimmte Gefährdungsquellen gibt.

Ermittlung der Wahrscheinlichkeit, mit der ermittelte Gefährdungsquellen spezielle Gefährdungsereignisse initiieren, sowie der Erfolgswahrscheinlichkeit von Gefährdungsereignissen.

Ermittlung von schädlichen Folgen (Auswirkungsanalyse, Impact-Analyse) für betriebliche Vorgänge und Assets, Einzelpersonen (z.B. auf ihre körperliche Unversehrtheit), andere Unternehmen/Organisationen und ggf. das gesamte Land, die aus der Ausnutzung von Schwachstellen durch die Gefährdung herrühren.

Die Kommunikation und der Informationsaustausch stellen in die eine Richtung sicher, dass die Ergebnisse der Risikobeurteilung auch entsprechend bekannt gemacht werden, um ggf. notwendige Maßnahmen zur Risikobewältigung abzuleiten. In die andere Richtung liefert sie wichtige Informationen für die Risikobewertung selbst.

Der konkrete Kommunikationsplan orientiert sich dabei eng an den Festlegungen des ersten Schrittes »Planung«. Erfolgt die Risikobeurteilung für den Zweck eines Gutachtens einer außenstehenden Instanz (z.B. im Kontext von Due-Diligence-Analysen oder zum Beleg bestimmter Compliance-Anforderungen), so beschränkt sich die Kommunikation ggf. auf den Informationsaustausch mit der außenstehenden Instanz. Erfolgt die Risikobeurteilung vor dem Hintergrund einer effektiven Ist-Stand-Erhebung mit anschließender Toleranzprüfung (im Sinne eines »ist dieses Gesamtrisiko für ein Unternehmen noch tragbar«), so wird dem Informationsaustausch ein konkreter Schritt folgen, um Maßnahmen zur Risikoreduktion abzuleiten.

1.2Informationssicherheitsrichtlinien und -verfahren

Die Informationssicherheitsrichtlinien: ähnlich zur klassischen Testrichtlinie

1.2.1Verstehen von Informationssicherheitsrichtlinien und -verfahren

Der Begriff der Richtlinie ist bereits aus dem klassischen funktionalen Testen bekannt:

Testrichtlinie

Ein Dokument, das auf hohem Abstraktionsniveau die Prinzipien, Vorgehensweisen und wichtigsten Ziele einer Organisation in Bezug auf das Testen zusammenfasst. [GTB Glossar 18]

Eine solche Richtlinie ist üblicherweise deutlich mehr als eine Sammlung von solchen Prinzipien und Vorgehensweisen: Anders als eine Leitlinie, die grundsätzlich eher empfehlenden Charakter hat, fordert eine Richtlinie normativ etwas. Während eine Leitlinie durchaus in begründeten Fällen explizit nicht angewendet wird, ist dies für Richtlinien in der Regel nicht möglich (vgl. [Huber 13]). Richtlinien sollten daher auch Aussagen darüber enthalten, was passiert, wenn sie nicht eingehalten werden.

Sicherheitsrichtlinien sind in Organisationen ähnlich positioniert: Sie geben für unterschiedliche Schlüsselrollen (z.B. IT-Nutzer, Administratoren oder Manager) verbindliche Prinzipien, Vorgehensweisen und die wichtigsten Ziele der Organisation hinsichtlich der Sicherheit vor.

Genauso vielschichtig, wie Sicherheit in den Unternehmen wirkt (vgl. z.B. oben die Vielfalt schützenswerter Assets, die Vielfalt möglicher Risiken und auch die Vielfalt möglicher Angriffe), genauso vielschichtig sind auch die Sicherheitsrichtlinien, die in Unternehmen gültig sind und damit im Idealfall von allen angesprochenen Personenkreisen eingehalten werden müssen.

Richtlinien basieren auf einer Sicherheitsrisikobewertung.

Die Grundlage von Sicherheitsrichtlinien sollte eine Sicherheitsrisikobeurteilung sein: Da Sicherheitsrichtlinien präventiv wirken, indem sie ex ante per Vorgabe bestimmte risikobehaftete Aktionen verbieten, das Risiko also vermieden wird, sind sie am effektivsten dort einzusetzen, wo die größten Sicherheitsrisiken in einem Unternehmen identifiziert werden können.

Besitzt ein Unternehmen primär schützenswerte digitale Assets (vgl. Abschnitt 1.1.2), so sind Richtlinien zum Zutrittsschutz nicht sehr wirksam. Demgegenüber existieren gerade in diesem Bereich für militärische oder reaktortechnische Gebäude besonders strenge Sicherheitsrichtlinien.

Richtlinien müssen regelmäßig aktualisiert und kommuniziert werden.

In jedem Fall ist eine wichtige Vorbedingung jeder Richtlinie, dass sie dem intendierten Kreis gegenüber bekannt, verstehbar und praktikabel sein muss. Da sich gerade Sicherheitsrichtlinien fortwährend ändern – z.B. um Verfahren zum Schutz neuer Asset-Orte vorzugeben, vgl. Cloud oder Smartphone –, muss diese Kommunikation gegenüber den Personen, für die sie gedacht sind, regelmäßig wiederholt werden.

Im Folgenden werden einige typische Klassen von Sicherheitsrichtlinien aufgeführt [Jackson 10]. In der Praxis müssen für eine Organisation nicht für alle Klassen Sicherheitsrichtlinien realisiert werden. Außerdem können aufgrund besonderer Risiken weitere Klassen existieren.

IT-Nutzungsrichtlinie

IT-Nutzungsrichtlinie: Was darf ein normaler Nutzer in IT-Systemen machen?

In einer IT-Nutzungsrichtlinie werden Vorgaben gemacht, wie ein typischer Nutzer von Computersystemen mit diesen zu arbeiten hat, um ein akzeptables Sicherheitsniveau zu erreichen und es zu halten. In ihr wird üblicherweise geregelt, wie ein Nutzer mit digitalen Ressourcen wie Netzwerk, Websites und Daten akzeptabel umgeht.

Die heutigen IT-Nutzungsrichtlinien geben in den meisten Fällen vor:

ob und in welchem Maße das Internet für private Zwecke verwendet werden darf,

wo relevante Unternehmensdaten abgelegt werden dürfen (häufig z.B. nicht auf tragbaren USB-Geräten oder in öffentlichen Clouds),

wie sensible Daten verarbeitet, weitergegeben und gedruckt werden dürfen,

wie und ob individuelle Software auf der Firmeninfrastruktur betrieben werden darf.

Sie werden heute häufig bereits am ersten Tag einer Einstellung einem neuen Mitarbeiter übergeben und gehören damit zu den wichtigsten Sicherheitsrichtlinien.

Berechtigungsrichtlinie

Berechtigungsrichtlinie: Wer benötigt was wirklich für seine Arbeit?

In einer Berechtigungsrichtlinie werden für Administratoren, aber auch für Nutzer Vorgaben gemacht, wie Zugriffsrechte vergeben und welchen grundlegenden Zielen sie gehorchen müssen. Meist fußt der grundlegende Charakter solcher Berechtigungsrichtlinien auf dem Mindestmaß an Zugriffsrechten (need-to-know): Dieses ist definiert als die kleinste mögliche Menge von Zugriffsrechten, die für die Ausführung der einer Person zugeordneten Aufgaben nötig sind. In dieser Richtlinie sind auf der einen Seite für den Administrator Verfahren beschrieben, nach denen eingehende Änderungen dieser Berechtigungen umgesetzt werden dürfen (z.B. in Form einer inhaltlichen Freigabe eines Vorgesetzten). Auf der anderen Seite werden hier für den Anwender auch die Wege dargestellt, die für anstehende Änderungen von Berechtigungen zu beschreiten sind.

Beispiel: Kumulative Rechte bei einzelnen Personen

Beispiel: Kumulative Rechte bei einzelnen Personen

Auszubildende, die meist Einblicke in mehrere Einheiten bekommen, und »alte Hasen« haben in einer Organisation ohne Berechtigungsrichtlinien häufig die meisten Berechtigungen. Sie bekommen in jeder Abteilung neue Rechte und sammeln diese über die Zeit, da es häufig keine entsprechenden Rechterücknahmen gibt.

Netzwerkrichtlinie

Netzwerkrichtlinie: Wie ist mit den unterschiedlichen Netzwerken und den jeweils enthaltenen Geräten umzugehen?

Eine Netzwerkrichtlinie definiert Kriterien für den Zugriff auf verschiedene Arten von Netzwerken wie z.B. LANs oder WLANs. Hier wird vorgegeben, welche Geräte grundsätzlich an welche Netze angeschlossen werden dürfen (z.B. ausschließlich von der Firma bereitgestellte Laptops oder eben auch private, wie dies entlang des Bring-your-own-Device-Konzeptes üblich ist), welche Vorbedingungen zu erfüllen sind (z.B. Mindestanforderungen an den Softwarestand) und was der Nutzer jeweils zu tun hat, um ein Netzwerk zu nutzen (z.B. Eingaben bestimmter Authentifizierungsdaten).

Des Weiteren kann diese Netzwerkrichtlinie Vorgaben machen, was während der Nutzung eines speziellen Netzwerkes zulässig ist und was nicht.

Typische normative Forderungen von Netzwerkrichtlinien verbieten heute Folgendes:

Das Verbinden von privater Netzwerkhardware (z.B. Router, Hotspots) via LAN

Die Nutzung von Sniffern, also spezieller Software zum Ausspähen einer stattfindenden Kommunikation, im firmeneigenen WLAN

Die Nutzung von Smart-Home- bzw. intelligenten persönlichen Assistenzgeräten im Firmennetz (wie z.B. Amazons Alexa auf den Echo-Geräten).

Fernzugriffsrichtlinie

Fernzugriffsrichtlinie: Wie darf von außen mit den internen Systemen gearbeitet werden?

In einer Fernzugriffsrichtlinie wird geregelt, ob ein Fernzugriff auf firmeninterne Systeme möglich ist, welche Funktionalitäten jeweils von außen anwendbar sind und welche Voraussetzungen für die Gewährung des Fernzugriffs für bestimmte Nutzerkreise (z.B. eigene Mitarbeiter und externe Berater) erfüllt sein müssen.

Sie regelt heute meist die Nutzung von VPN als De-facto-Standard des Fernzugriffs auf firmeninterne Systeme:

Wer darf es nutzen (interne Mitarbeiter, externe Berater)?

Von wo aus darf es aufgerufen werden (z.B. häufig nicht von außerhalb der EU)?

Welche Hardware- und Softwarevorbedingungen müssen erfüllt sein (z.B. ist es meist nicht erlaubt, VPN-Verbindungen von öffentlich verfügbaren Rechnern wie in Internetcafés oder Hotellobbys zu initiieren)?

Internetrichtlinie

Internetrichtlinie: Wie darf sich ein Nutzer im Internet bewegen?

Die Internetrichtlinie, die häufig auch Teil der allgemeinen IT-Nutzungsrichtlinie ist, definiert die zulässige Nutzung des Internets durch verschiedene Mitarbeiter und Gäste eines Unternehmens. Das umfasst meist klare Vorgaben, welche Internetseiten und -services nicht genutzt werden dürfen. In größeren Organisationen werden diese Vorgaben der Internetrichtlinie meist automatisch erzwungen, indem zentrale Blacklists gepflegt werden, auf die grundsätzlich kein Zugriff vom Firmennetz aus möglich ist.

Darüber hinaus werden in der Internetrichtlinie auch immer häufiger sogenannte Netiquette-Vorgaben gemacht:

»Darunter versteht man die unverbindlichen Regeln, die die Nutzung des Internets für alle Menschen angenehm machen sollen: Die guten Umgangsformen im Ausdruck, das Bemühen, Inhalte für alle gewünschten Adressaten technisch zugänglich zu halten, die Einhaltung von Sicherheitsstandards bei der Übertragung vertraulicher Daten, die Respektierung des Urheberrechts u. v. a. m.« (Definition Netiquette im [BSI Glossar 13]).

In Unternehmen dient die Internetrichtlinie im weitesten Sinne dazu, auf der einen Seite einen fairen Umgang der Ressource Internet zu gewährleisten, auf der anderen Seite aber gleichzeitig sicherzustellen, dass die Reputation des Unternehmens niemals gefährdet sein darf.

Eine Internetrichtlinie umfasst diesbezüglich häufig folgende Punkte:

Erläuterungen zum korrekten Umgang mit Internetinhalten (z.B. Lizenzbestimmungen von Bildern)

Das Verbot, sich über das Firmenkonto auf fachfremden Social-Media-Kanälen anzumelden oder etwa den Firmennamen im eigenen auch privaten XING-Profil zu verwenden.

Das Verbot, über das Internet das Darknet zu betreten oder Internetservices über das eigene Intranet anzubieten.

Benutzerkontenrichtlinie

Benutzerkontenrichtlinie: Über welche Verfahren werden Benutzerkonten systematisch verwaltet?

Die Benutzerkontenrichtlinie definiert meist gerade für die Administration die Vorgaben, wie mit der Erstellung, Pflege und Löschung von Benutzerkonten unternehmenskonform umzugehen ist. Grundsätzlich gilt, dass jedes Benutzerkonto einer realen, dem Unternehmen angehörenden oder wenigstens über Verträge verbundenen Person zuzuordnen ist. Die Benutzerkontenrichtlinie beschreibt die Verfahren, die zum Erreichen dieses Zieles notwendig sind.

Häufig wird in dieser Richtlinie daher auch das Verfahren einer regelmäßigen Benutzerkontenrezertifizierung beschrieben, also die Prüfung der Gültigkeit der Zuordnung natürlicher Personen zu Benutzerkonten.

Auch die Verwaltung von sogenannten privilegierten Benutzerkonten, das sind solche Konten, die für privilegierte Berechtigungen verwendet werden, ist in dieser Richtlinie meist geregelt. »Privilegierte Berechtigungen umfassen weitergehende Zugriffsmöglichkeiten auf IT-Systeme oder Software-Komponenten, als für normale Benutzer erforderlich sind« [BSI Glossar 13].

Datenklassifizierungsrichtlinie

Datenklassifizierungsrichtlinie: Wie können Schutzbedarfe von Daten klassifiziert werden?

Daten sind eine sehr allgemeine Form physischer oder digitaler Assets. Jede Art von Daten wird entlang der Risikobewertung einen besonderen Schutzbedarf haben. Im ISTQB®-Syllabus Sicherheitstester wird auf oberster Ebene dann von sensiblen Daten gesprochen, wenn Daten in irgendeiner Weise schutzbedürftig sind.

Eine Richtlinie zur Datenklassifizierung geht meist noch einen Schritt weiter, indem gefordert wird, dass alle Arten von Daten nicht nur dahingehend bewertet werden müssen, ob sie sensibel sind oder nicht, sondern auch, wie stark der Schutz für sensible Daten auszufallen hat. Das Hauptschutzziel dieser Daten liegt entlang des CIA-Konzeptes hierbei meist auf der Vertraulichkeit, d.h. der Frage, welche Personenkreise die Daten einsehen dürfen und wie streng diese Erlaubnis eingefordert wird.

Damit hier nicht jeder Autor von Daten seine eigene Skala entwirft und anwendet, wird in der Datenklassifikationsrichtlinie eine feste Klassifikation vorgegeben. Jede Klasse repräsentiert hierbei eine bestimmte Schutzklasse. Letztere regelt dann operativ ganz konkret, ob ein Dokument mit den entsprechenden Daten z.B. ausgedruckt, per E-Mail verschickt oder im Internet veröffentlicht werden darf.

Eine typische Datenklassifikation ist in Abbildung 1–5 dargestellt.

Abb. 1–5Datenklassifikation mit vier Schutzklassen

Diese Datenklassifikation lässt sich wie folgt jeweils mit Beispielen veranschaulichen:

Öffentlich

Daten dieser Klasse bedürfen keines besonderen Schutzes (hier in Bezug auf Vertraulichkeit). Öffentliche Daten sind folglich solche, die jeder einsehen darf. Typische Beispiele solcher Daten sind Pressemitteilungen, Webauftritte und Beiträge auf öffentlichen Konferenzen. Auch öffentliche Produktkataloge (z.B. Amazon, Ebay) haben diese Datenklassifikation.

Intern

Informationen mit dieser Datenklassifikation sind für einen Mitarbeiterkreis innerhalb einer Organisation gedacht. Jeder im Unternehmen, unabhängig von seiner Rolle, soll diese internen Informationen einsehen dürfen. Bei sehr großen Organisationen wird diese Stufe intern gelegentlich um einen Organisationbereich erweitert, z.B. »Intern Sales« oder »Intern Produktentwicklung«. In jedem Fall dürfen solche Informationen den Organisationsrahmen nicht verlassen, da sich hieraus mögliche Nachteile für die Organisation ergeben können.

Vertraulich

Informationen dieser Klasse sollen nur einem ausgesuchten Kreis von Personen zugänglich sein, da ansonsten ein nicht unerheblicher Schaden eintreten kann. Ein typisches Beispiel sind Gehaltsdaten oder interne Geschäftsberichte: Gelangen solche Dokumente in die falschen Hände, so können ggf. externe Personen daraus Vorteile ziehen oder es können datenschutzrechtliche Verfahren eingeleitet werden.

Streng vertraulich

Informationen dieser Klasse benötigen den höchsten Schutzbedarf, da im Falle einer Nichtbefolgung ein großer oder kritischer Schaden droht. Typische Informationen dieser Klasse sind Gesundheitsdaten von Personen oder auch Jahresabschlussberichte, die erst zu einem klar definierten Zeitpunkt veröffentlicht werden, um für alle Aktionäre einen gleichen Wissensstand zu ermöglichen. Der Verlust von streng vertraulichen Daten geht neben juristischen Folgen häufig eng einher mit einem großen Reputationsverlust: Kunden einer Firma, der streng vertrauliche Daten abhandengekommen sind, ziehen sich häufig direkt nach Bekanntwerden des Vorfalls aus dem Business dieser Firma zurück.

Beispiel: Equifax Datenleck

Beispiel: Equifax Datenleck