8. Security Engineering

Transcription

1
Ziel
Entwickeln eines Systems, welches geforderte Sicherheitsanforderungen erfüllt und auf Angriffe geeignet reagiert.
Bisher
Allgemeine Sicherheitswerkzeuge werden auf fertige Softwaresysteme gesetzt
Keine Integration von Sicherheit in den (UML)-Softwareentwicklungsprozess
Problem
Sicherheitsanforderungen werden nicht ausreichend erfüllt,
unsichere Software.
Sicherheit ist ein wichtiger Aspekt heutiger IT-Systeme, wird jedoch nicht dementsprechend
bei der Entwicklung von IT-Systemen berücksichtigt. Es werden auf fertige IT-Systeme
allgemeine Sicherheitswerkzeuge gesetzt, die die speziellen Sicherheitsanforderungen
individueller Anwendungen nur unzureichend realisieren. Dadurch entstehen Sicherheitslücken
und unsichere Systeme. Security Engineering befasst sich mit dem Entwicklungsprozess zur
Konstruktion sicherer Systeme. Security Engineering ist eine methodisch noch nicht
ausgearbeitete Disziplin, die im Fokus aktueller Forschungsarbeiten liegt. Wir stellen im
folgenden
einige
Konzepte
vor,
die
Sicherheitsanforderungen
in
den
Softwareentwicklungsprozess integrieren.
2
Methoden zur Konstruktion sicherer Systeme sind bisher kaum
entwickelt, da
Sicherheit eine nicht-funktionale Anforderung ist und schwer
zu spezifizieren und bewerten ist.
Designer von Softwaresystemen keine Sicherheitsexperten
sind
Kunde bezahlt lieber für Funktionalität, da das Bewusstsein
für Sicherheit noch nicht richtig ausgeprägt ist.
Durch Termindruck bei der Softwareentwicklung werden
Sicherheitsmechanismen vernachlässigt.
Es gibt mehrere Gründe, warum Methoden zur Konstruktion sicherer Systeme bisher kaum
entwickelt wurden. Einige dieser Gründe zeigt die Folie.
3
Allgemeine Prinzipien beim Design sicherer Systeme
Principle of Least Privilege (minimale Rechte)
Principle of Fail-Safe Default (Verbote sind Standard)
Principle of Economy of Mechanism (möglichst einfach)
Principle of Complete Mediation (alle Zugriffe werden geprüft)
Principle of Open Design
(Sicherheit hängt nicht von Geheimhaltung ab)
Principle of Separation of Privelege
(Rechte werden aufgrund mehrerer Bedingungen
gewährt)
Principle of Psychological Acceptability
(Sicherheit soll keine Arbeit erschweren)
Es lassen sich allgemeine Prinzipien aufstellen, die bei der Konstruktion und Implementierung
von sicheren Anwendungen zu beachten sind. Die Folie zeigt die Prinzipien im Überblick, auf
den nächsten Folien diskutieren wir sie im Detail.
4
Principle of Least Privilege
Einem Subjekt soll nur die Privilegien bekommen, welche für die
Ausführung einer Aufgabe notwendig sind.
Müssen einem Subjekt für eine Aufgabe zusätzlich Rechte
gewährt werden, sollen diese sofort nach der Aufgabe wieder
entzogen werden.
Beispiel:
Wenn ein Subjekt etwas an eine Datei anhängen soll, so sollte
das append-Recht und nicht das write-Recht auf die Datei
gegeben werden.
Beispiel:
Benutzer nicht unter root laufen lassen.
Das Principle of Least Privilege verlangt, dass einem Subjekt nur die Privilegien gegeben
werden sollen, die das Subjekt zur Ausführung seiner Aufgabe benötigt. Wenn das Subjekt
Privilegien nicht benötigt, sollten ihm diese auch nicht gegeben werden. Wenn eine bestimmte
Aktion es erfordert, dem Subjekt zusätzliche Privilegien zu gewähren, so sollten diese
zusätzlichen Rechte sofort wieder entzogen werden, nachdem das Subjekt die Aktion
durchgeführt hat. Wenn ein Subjekt beispielsweise Daten an Dateien hängen soll, so reicht das
append-Recht und es muss nicht das write-Recht gewährt werden, mit dem er die Datei
beliebig modifizieren könnte.
5
Principle of Fail-Safe Defaults
Wenn ein Subjekt nicht explizit Zugriff auf ein Objekt bekommt,
ist der Zugriff auf das Objekt verboten.
Damit ist der Default-Zugriff auf Objekte eine Verbot.
Beispiel:
Auf neu erzeugte Dateien eines Benutzers kann zunächst nur
der Benutzer selbst zugreifen. Nur wenn der Benutzer explizit
Zugriffsrechte für andere Benutzer gibt, ist der Zugriff für diese
Benutzer erlaubt.
Das Principle of Fail-Safe Defaults besagt, wie Privilegien an neu erzeugte Objekte bzw.
Subjekte vergeben werden sollten. Es besagt, dass einem Subjekt keine Privilegien an einem
Objekt gewährt werden sollten, bis dies nicht explizit für das Subjekt und das Objekt geschieht.
Damit erfordert das Prinzip, dass auf Objekte standardmäßig nicht zugegriffen werden kann.
6
Principle of Economy of Mechanism
Sicherheitsmechanismen sollen so einfach wie möglich sein.
Einfaches Design und Implementierung minimiert Fehler und
vereinfacht das Testen.
Annahmen über komplexe Systeme und ihre Umgebung können
bei Nicht-Erfüllung zu Sicherheitsproblemen führen.
Beispiel:
finger liefert Informationen über einen Benutzer im System.
Client-Systeme nehmen an, dass die Antwort des finger-Servers
ein bestimmtes Format hat.
Angreifer schreibt Server, der einen unendlichen Antwortstrom
liefert, um einen Denial-of-Service Angriff durchzuführen.
Das Principle of Economy of Mechanism vereinfacht das Design und die
Implementierung
von
Sicherheitsmechanismen.
Es
fordert,
dass
Sicherheitsmechanismen so einfach wie möglich sein sollten. Wenn das Design und
die Implementierung des Mechanismus einfach sind, verringert dies die Möglichkeiten
von Fehlern. Außerdem wird der Testprozess weniger komplex, da weniger Testfälle
benötigt werden. Komplexe Mechanismen machen oft Annahmen über das System
und die Umgebung, in der sie eingesetzt werden. Wenn diese Annahmen verletzt
werden, kann dies zu Sicherheitsproblemen führen. Ein Beispiel ist das fingerProtokoll zur Abfrage von Informationen über Benutzer. Client Programme nehmen an,
dass die Antwort des finger-Programms ein bestimmtes Format hat, z.B. das die
Antwort endlich ist. Diese falsche Annahme des Clients könnte ein Angreifer
ausnutzen und einen unendlichen Antwortstrom erzeugen, um beispielsweise LogDateien und Platten zu füllen. Dies ist ein Beispiel für eine falsche Annahme bzgl. der
Eingabe das Clients.
7
Principle of Complete Mediation
Alle Zugriffe auf Objekte werden geprüft bevor sie erlaubt
werden.
Beispiel:
Bevor ein Lese-Zugriff auf eine Datei erfolgt, prüft das
Betriebssystem, ob das Subjekt das Leserecht hat.
Bei jedem weiteren Lese-Zugriff muss das Betriebsystem wieder
prüfen, ob die Rechte immer noch existieren.
Wird in vielen Systemen nicht durchgeführt, z.B. das Access
Token in Windows XP, File-Deskriptor in UNIX.
Das Principle of Complete Mediation erfordert, dass alle Zugriffe auf Objekte geprüft werden
müssen. Wenn ein Subjekt beispielsweise eine Datei lesen möchte, muss das Betriebssystem
diesen Zugriff prüfen. Dazu ermittelt es, ob das Subjekt die Leserechte auf der Datei hat. Ist
dies der Fall, kann das Subjekt die Datei lesen. Möchte das Subjekt die Datei erneut lesen,
muss das System (dem Prinzip folgend) erneut überprüfen ob der Lesezugriff immer noch
erlaubt ist. Die meisten Systeme machen diese Prüfung aus Performanzgründen jedoch nicht
(z.B. UNIX und Windows). Sie merken sich das Ergebnis der ersten Prüfung und erlauben den
Zugriff basierend auf diesem Ergebnis.
8
Principle of Open Design
Sicherheit eines Mechanismus sollte nicht von der
Geheimhaltung der Funktionsweise des Mechanismus oder
seiner Implementierung abhängen
(also keine security through obscurity)
Beispiel:
Kryptographie-Software: Algorithmen zur Ver- und
Entschlüsselung sollten öffentlich sein, nur die Schlüssel
müssen geheim gehalten werden.
Das Principle of Open Design hat den Hintergrund, dass Komplexität nicht die Sicherheit
erhöht. Das Prinzip fordert daher, dass die Sicherheit des Mechanismus nicht von der
Geheimhaltung des Designs oder der Implementierung des Sicherheitsmechanismus abhängen
soll. Es besteht immer die Gefahr, dass Angreifer auf bestimmten Wegen an diese
Informationen kommen und somit der Mechanismus unbrauchbar wird. Dieses Prinzip trifft
insbesondere auf kryptographische Software und Systeme zu. Die Erfahrung hat gezeigt, dass
die Geheimhaltung von kryptographsichen Algorithmen keineswegs die Sicherheit erhöht. Die
Geheimhaltung von kryptographsichen Schlüsseln oder Passwörtern verletzt das Prinzip nicht,
da dies keine Algorithmen sind. Kommerzielle Software und Urheberrechte komplizieren die
Einhaltung dieses Prinzips, da Firmen nicht wollen, dass ihre Produkte einfach von
Konkurrenten benutzt und kopiert werden können.
9
Beispiel:
Content Scrambling System (CSS) ist ein kryptographischer
Algorithmus zum Kopierschutz für DVDs.
Mit lizenziertem DVD-Player und lizenzierter DVD lassen sich
die Filme ansehen.
DVD-Player hat ein CSS-Entschlüsselungs-Modul und
lizenzierte Player-Schlüssel.
Mit einem Player-Schlüssel authentifiziert sich der Player
gegenüber der eingelegten DVD und erhält den DiscSchlüssel mit die Titel-Schlüssel zum decodieren der DVD
entschlüsselt werden können.
Ein Beispiel, bei dem die Geheimhaltung eines Verschlüsselungsalgorithmus nicht verhindert
hat, dass Verschlüsselungen geknackt wurden, ist das Content Scrambling System (CSS). Das
CSS ist ein kryptographischer Algorithmus, der zum Kopierschutz bei DVDs verwendet
werden kann. Damit ein DVD-Player dem CSS-Standard genügt, muss er ein CSSEntschlüsselungs-Modul und lizenzierte Player-Keys enthalten. Mit einem Player-Key (es gibt
insgesamt 408 davon, die alle zu unterschiedlichen Playern gehören) "identifiziert" sich der
Player gegenüber der eingelegten DVD und erhält im Erfolgsfall den (bei jeder CSS-DVD
verschiedenen) Disc-Key, um mit dessen Hilfe wiederum die Title-Keys zum decodieren der
CSS-geschützten Bereiche zu erlangen.
10
DVD hat Authentifizierungs-, Disk- und TitelSchlüssel (KA, KD bzw. KT).
Mit dem Titel-Schlüssel wird der Film
verschlüsselt.
KA
hash(KD)
E(KD,KP1)
Der Titel-Schlüssel wird mit dem bei jeder DVD
verschiedenen Disk-Schlüssel verschlüsselt.
Ein Block der DVD erhält Kopien von KD,
verschlüsselt mit den Player-Schlüsseln KPi und
einen Hash des Disk-Schlüssels.
...
E(KD,KPn)
E(KT,KD)
Es gibt 408 Player-Schlüssel für unterschiedliche
Player.
Eine DVD hat einen Authentifizierungs-, einen Disk- und einen Titel-Schlüssel. Ein Block auf
der DVD enthält mehrere Kopien des Disk-Schlüssels, jede mit einem anderen PlayerSchlüssel verschlüsselt. Außerdem enthält der Block einen Hash-Wert des Disk-Schlüssels.
11
Abspielen einer DVD
1. DVD wird in DVD-Spieler eingelegt
2. CCS-Modul liest Authentifizierungsschlüssel
3. Entschlüsselung des Disk-Schlüssels mit dem PlayerSchlüssel.
4. Vergleichen mit dem Hash-Wert.
5. Entschlüsseln des Titel-Schlüssels mit dem DiskSchlüssel.
6. Entschlüsseln des Films mit dem Titel-Schlüssel.
Wenn eine DVD in den DVD-Player gelegt wird, liest der CSS-Algorithmus zunächst den
Authentifizierungsschlüssel. Danach wird der Disk-Schlüssel mit dem Player-Schlüssel des
DVD-Players entschlüsselt. Wenn der entschlüsselte Disk-Schlüssel den richtigen Hash-Wert
ergibt, wird der Disk-Schlüssel zum Entschlüsseln des Titel-Schlüssels verwendet. Der TitelSchlüssel kann dann zur Entschlüsselung des DVD-Films verwendet werden.
12
1999 gelang es einen Player-Key aus dem Software-DVD-Player
der Firma Xing zu extrahierten und einen zum CCS kompatiblen
Algorithmus zu entwickeln (DeCSS).
6. Oktober 1999 Veröffentlichung von DeCSS über eine
Mailingliste (u.a. Jon Johanson)
26. Oktober 1999 Analyse der CCS-Player-Schlüsselgenerierung
30. Oktober 1999 Alle Player-Schlüssel auf der Mailingliste
Im Jahr 1999 gelang es den CSS-Algorithmus zu knacken und einen kompatiblen Algorithmus
zu veröffentlichen. Durch eine Analyse des Schlüsselgenerierungsalgorithmus konnten auch
alle PLayer-Schlüssel generiert und auf einer Mailingliste veröffentlicht werden. Damit war
der CSS-Kopierschutz nutzlos geworden.
13
Juristisches Nachspiel:
Jon Johanson (damals 15 Jahre) wurde von der
Staatsanwaltschaft und der amerikanischen MPAA (Motion
Picture Association of America) auf zwei Jahre Gefängnis und
Geldstrafe verklagt.
2002 Freispruch, da
1. er nur die Benutzeroberfläche zu DeCSS geschrieben
hatte (der eigentliche Algorithmus kam von einem
unbekannten Hacke aus Deutschland) und
2. das Umgehen von Kopierschutzmaßnahmen für private
Zwecke in Norwegen nicht strafbar ist.
14
Principle of Separation of Privilege
Rechte werden nicht aufgrund einer einzelnen Bedingung erfüllt.
Beispiel:
Bank-Checks ab einer Summe von 75.000 Euro müssen von
zwei Mitarbeitern genehmigt werden.
Beispiel:
Im Berkely UNIX-System kann ein Benutzer nur zu root
wechseln, wenn er das root-Passwort kennt und in einer
speziellen Gruppe (wheel) ist.
Das Principle of Speparation of Privilege besagt, dass ein Recht nicht aufgrund der Erfüllung
einer einzelnen Bedingung gewährt werden darf. Die Gewährung von Rechten muss somit von
mindestens zwei Bedingungen abhängen.
15
Principle of Least Psychological Acceptability
Der Zugriff auf Ressourcen soll mit Sicherheitsmechanismen
nicht schwerer sein als ohne die Mechanismen.
In der Praxis heißt das, dass der Aufwand minimal und
angemessen sein sollte.
Sicherheitswerkzeuge sollten einfach und intuitiv sein. Die
Ausgaben sollten klar, verständlich und hilfreich sein.
 Ansonsten werden die Werkzeuge nicht oder falsch benutzt.
Aber: Ausgaben dürfen keine Sicherheitsinformationen geben.
Beispiel ist die Passwortabfrage.
Das Principle of Psychological Acceptability betrachtet den menschlichen Benutzer. Das
Prinzip fordert, dass Sicherheitsmechanismen den (erlaubten) Zugriff auf Ressourcen nicht
erschweren sollen. Sicherheitswerkzeuge sollten so einfach und intuitiv wie möglich sein und
Ausgaben sollten klar und hilfreich sein. Wenn Sicherheitswerkzeuge zu kompliziert sind,
werden sie von Administratoren entweder gar nicht oder fehlerhaft eingesetzt. In beiden Fällen
wird die Sicherheit des Systems geschwächt. Die Ausgaben der Sicherheitswerkzeuge sollen
zwar klar und hilfreich sein, sie dürfen jedoch nicht unerwünschterweise
Sicherheitsinformationen an Angreifer liefern. Wenn ein Benutzer beispielsweise das falsche
Passwort eingibt, sollte der Zugang mit einer Nachricht abgebrochen werden, in der das
Fehlschlagen der Anmeldung berichtet wird. Es sollte nicht gemeldet werden, dass das
Passwort falsch ist, da damit die Existenz des Benutzer-Accounts bestätigt wird.
16
Entwickeln sicherer Systeme soll mit den StandardSoftwareprozessen zusammenwirken.
Softwareentwicklungsprozessmodelle
Wasserfallmodell
Spiral-Modell
Prototyp-Modell
V-Modell
Rational Unified Process
Extreme Programming
etc.
Die
Entwicklung
von
sicherer
Systeme
soll
Softwareentwicklungsprozessmodelle integriert werden. Es
Entwicklungsprozess geben.
in
die
soll keinen
üblichen
getrennten
17
Analyse
funktionale
Anforderungen
Design
Bedrohungsanalyse
Risikoanalyse
Sicherheitsstrategie
Systemmodell
Sicherheitsmodell
Architektur
Anwendungsarchitektur
modellieren
Sicherheitsarchitektur
modellieren
Wir betrachten hier ein sehr einfaches und grobes Vorgehensmodell des Softwareengineering,
bestehend aus Analyse, Design und Architektur. Dieses einfache Wasserfallmodell kann durch
beliebige andere Vorgehensmodelle (V-Modell, evolutionäre Modelle, Rational Unified
Process, etc.) ersetzt werden. Wir möchten uns hier auf die Entwicklungsphasen konzentrieren,
die sich auf die Sicherheit des Systems beziehen.
In der Analyse-Phase sind dies die Bedrohungsanalyse und die Risikoanalyse. Die
Bedrohungen des Systems basieren auf den funktionalen Anforderungen, da diese beschreiben,
was die zu entwickelnde Software leisten soll. Basierend auf der Risikoanalyse wird eine
Sicherheitsstrategie entwickelt und ein Sicherheitsmodell, dass die Strategie umsetzt.
Getroffene Entscheidungen im Sicherheitsmodell beeinflussen das Systemmodell. Basierend
auf dem Sicherheitsmodell wird eine Sicherheitsarchitektur entwickelt, die auch Einfluss auf
die Anwendungsarchitektur hat. Wir werden im folgenden die einzelnen Phasen des
Sicherheitsentwurfes genauer betrachten.
18
8.1 Bedrohungsanalyse
In der Bedrohungsanalyse werden organisatorische, technische
und benutzerbedingte Bedrohungen ermittelt.
Vollständige Erfassung aller Bedrohungen ist schwierig.
Unterstützung durch Bedrohungsmatrix oder Bedrohungsbaum.
Bedrohungsmatrix
Zeilen: Gefährdungsbereiche
Spalten: potentielle Auslöser von Bedrohungen
Bedrohungsbaum
Wurzel: mögliches Angriffsziel
Knoten: Zwischenziele zum Erreichen des Ziels des
Vaterknotens
In der Bedrohungsanalyse werden die potentiellen organisatorischen, technischen und
benutzerbedingten Ursachen für Bedrohungen, die Schäden hervorrufen können, systematisch
ermittelt. Zur Unterstützung einer methodischen Erfassung der relevanten Bedrohungen kann
man einen matrix- oder einen baumorientierten Analyseansatz wählen.
19
Bedrohungsmatrix
Klassifikation der Gefährdungsbereiche als Zeilen der Matrix.
Mögliche Gefährdungsbereiche sind
1. Bedrohungen durch externe Angriffe
Aktionen eines Angreifers ohne Hilfe des bedrohten
technischen Systems.
Dazu zählen die physische Zerstörung oder Diebstahl
(z.B. von Notebooks, Festplatten etc.)
In einer Bedrohungsmatrix sind die Zeilen die Gefährdungsbereiche und die Spalten sind
die potentiellen Auslöser von Bedrohungen. Eine mögliche Klassifikation von
Gefährdungsbereichen stellt C. Eckert in ihrem Buch IT-Sicherheit vor:
1.
Bedrohungen durch externe Angriffe: Aktionen eines Angreifers, die er ohne die Hilfe des
bedrohten technischen Systems durchführt. Beispiele sind die Zerstörung von
Systemkomponenten sowie Diebstahl von Ressourcen wie Festplatte, Notebook etc.
20
2.
Bedrohungen der Datenintegrität und der
Informationsvertraulichkeit
Angriffe, die gezielt versuchen, interne Kontrollen zu
umgehen oder Schutzmechanismen unwirksam zu
machen.
Beispiele sind die Umgehung von Zugriffskontrollen des
Betriebsystems oder die Verwendung verdeckter Kanäle.
3.
Bedrohungen der Verfügbarkeit und der Ressourcennutzung
Betrifft die unautorisierte Ressourcennutzung bzw.
die über die erlaubte Ressourcenbelegung
übersteigende Nutzung.
Beispiele sind teure Ein-/Ausgabegeräte oder die
Nutzung von Rechenkapazität.
2.
Bedrohungen der Datenintegrität und der Informationsvertraulichkeit: Angriffe, die
gezielt versuchen, interne Kontrollen zu umgehen oder Schutzmechanismen unwirksam zu
machen. Beispiele sind die Umgehung von Zugriffskontrollen oder verdeckte Kanäle.
3.
Bedrohungen der Verfügbarkeit und Ressourcennutzung: Betreffen die unautorisierte
Ressourcennutzung bzw. die eine „normale“ Ressourcenbelegung übersteigende Nutzung
von Betriebsmitteln.
21
4.
Abstreiten durchgeführter Aktionen
Betrifft die Abrechnung genutzter Ressourcen und
in Anspruch genommener Dienste und die daraus
resultierenden rechtlichen bzw. vertraglichen
Folgen.
5.
Missbrauch erteilter Berechtigungen
Betrifft autorisierte Benutzer, die ihnen erteilte
Berechtigungen missbrauchen.
4.
Abstreiten durchgeführter Aktionen: Betreffen den Bereich der Abrechnung genutzter
Ressourcen (z.B. Speicher, CPU-Zeit), zum anderen die Abrechnung in Anspruch
genommener Dienste und die daraus resultierenden rechtsverbindlichen, vertraglichen
Folgen (z.B. Banktransaktion oder elektronischer Einkauf).
5.
Missbrauch erteilter Berechtigungen: Ein autorisierter Benutzer missbraucht die ihm
erteilten Berechtigungen.
22
Zeilen der Bedrohungsmatrix definieren die
Gefährdungsbereiche.
Spalten definieren die potenziellen Auslöser von Bedrohungen:
Programmierer,
Systemadministratoren,
Benutzer (mit internem oder externem Zugriff),
Dienste (z.B. E-Mail),
Protokolle (z.B. TCP/IP),
Ausführungsumgebungen (z.B. Java Virtual Machine),
etc.
Matrixeinträge enthalten potentielle Angriffsszenarien.
Während die Zeilen der Bedrohungsmatrix die Gefährdungsbereiche enthält, sind in den
Spalten der Bedrohungsmatrix die potenziellen Auslöser von Bedrohungen aufgelistet. Die
Folie zeigt einige Beispiele für Auslöser. Die Matrixeinträge enthalten dann potenzielle
Angriffszenarien, die die Auslöser bzgl. des Gefährdungsbereiches ausführen könnten.
23
Beispiel: keine Szenarien, nur Beispiele für Bedrohungen
Programmierer
Interner
Benutzer
Externer
Benutzer
Externe
Angriffe
Beobachten der Vandalismus
Passworteingabe
Interne Direkter
Angriffe Speicherzugriff
Trojanisches
Pferd
Passwort
knacken
Verfügbarkeit
Prozesse
erzeugen
Netzlast
erzeugen
Speicherbelegung
Mobiler
Code
Viren
Diese Folie zeigt ein kleines Beispiel einer Bedrohungsmatrix. Die Spalten der
Bedrohungsmatrix enthalten die potentiellen Auslöser von Bedrohungen. Beispiele sind
Systemadministratoren, Programmierer, Benutzer die einen internen oder externen Zugriff auf
das System haben, verwendete Dienste wie E-Mail, Protokolle wie TCP/IP oder
Ausführungsumgebungen wie die Java VM zur Ausführung von Java-Applets sein. Die Zeilen
sind die Gefährdungsbereiche Externe Angriffe , Interne Angriffe und Verfügbarkeit. Im
Beispiel könnte ein Programmierer beispielsweise durch übermäßige Speicherbelegung die
Verfügbarkeit des Systems bedrohen, mobiler Code könnte Viren enthalten oder externe
Benutzer könnten durch das Knacken von Passwörtern Zugriff aufs System bekommen.
24
Bedrohungsbaum bzw. Angriffsbaum erfasst potentielle
Bedrohungen.
Bedrohungen werden schrittweise von der Wurzel zu den
Blättern verfeinert und konkretisiert.
Wurzel des Bedrohungsbaums:
Beschreibt allgemeine Bedrohung des Systems.
Kinderknoten:
Repräsentieren Zwischenziele, um die Bedrohung des
Vaterknoten zu erreichen.
Bedrohungen können auch in einem Bedrohungsbaum beschrieben werden. Die generelle
Vorgehensweise zum Erstellen eines Bedrohungsbaumes lässt sich wie folgt zusammenfassen:
Die Wurzel definiert ein Angriffsziel, d.h. eine mögliche Bedrohung des Systems. Die Kinder
eines Knotens im Baum repräsentieren Zwischenziele, die zur Erreichung des Ziels des
Vaterknotens beitragen.
25
Zwischenziele können mit UND bzw. ODER verknüpft werden:
UND erfordert das Eintreten aller Bedrohungen, damit die
Bedrohung des Vaterknotens auftritt.
ODER erfordert nur eine Bedrohung zum Auftreten der
Bedrohung des Vaterknotens.
Der Pfad von einem Blatt zur Wurzel zeigt die Schritte, um das
in der Wurzel definierte Angriffsziel zu erreichen.
Zur Verknüpfung der Zwischenziele können UND- bzw. ODER-Knoten verwendet werden:
Die Äste eines UND-Knotens beschreiben die Bedrohungen, die gemeinsam erfüllt sein
müssen, um das Ziel des Vaters zu erreichen. Bei einem ODER-Knoten reicht dazu eines der
Zwischenziele aus. Die Pfade von den Blättern zur Wurzel beschreiben Angriffsschritte zum
Erreichen des globalen Angriffziels.
26
Beispiel 1:
Geld aus EC-Automat
Ohne Konto
Fremdes Konto
eigenes Konto
UND
Brich Automat
vor Ort auf
Klaue
Automat
mit echter mit falscher
Karte
Karte
UND
entwende
Karte
ermittle
PIN
hebe Geld
ab
UND
fälsche/kopiere
Karte
ermittle
PIN
Bestreite
Transaktion
Als Beispiel betrachten wir einen Angriff auf einen EC-Automaten. Wenn kein UND an den
Kanten steht, handelt es sich um eine ODER-Verknüpfung. In diesem Beispiel ist das
Angriffsziel eine EC-Automat, aus dem Geld entwendet werden soll. Diese Angriffsziel wird
im Baum immer weiter zu Zwischenzielen verfeinert.
27
Beispiel 2:
öffne Safe
knacke Schloss
erfahre
Kombination
Kombination
aufgeschrieben
Bedrohung
Erpressung
schneide durch
Panzerstahl
Kombination
mündlich
unbeabsichtigt
Bestechung
UND
Belausche Inhaber
der Kombination
Inhaber erzählt
Kombination
Dieses zweite Beispiel hat das Ziel, einen Safe zu öffnen. Der Baum zeigt die einzelnen Ziele,
die zur Erfüllung des Hauptziels auszuführen sind.
28
8.2. Risikoanalyse
Die Risikoanalyse (risk assessment) bewertet die Relevanz der
einzelnen Bedrohungen, d.h.
– mit welcher Wahrscheinlichkeit tritt eine Bedrohung ein und
– wie schwer ist der Schaden
Die Wahrscheinlichkeit einer Bedrohung hängt ab
– vom geschätzten Aufwand zur Durchführung eines Angriffs,
– vom möglichen Nutzen eines Angriffs,
– vom Ausmaß möglicher Schäden, die durch den Angriff
entstehen,
– vom Angreifertypen, d.h. von den Fähigkeiten und
Kenntnissen der Angreifer, von ihrer Risikobereitschaft, ihrer
Motivation, etc.
Zur Bewertung der Bedrohungsrisiken werden die Wahrscheinlichkeiten für das Eintreten der
verschiedenen Bedrohungen ermittelt und ihr potentieller Schaden abgeschätzt. Die
Wahrscheinlichkeiten ergeben sich aus dem geschätzten Aufwand, den der Angreifer zur
Durchführung des Angriffs treiben muss, und einer Einschätzung des Nutzens, den der
Angreifer vom Angriff hat. Wenn ein Angriff unwahrscheinlich ist, ist die Priorität zum
Verhindern dieses Angriffs geringer, als bei einem wahrscheinlichen Angriff. Wenn der
unwahrscheinliche Angriff jedoch einen höheren Schaden nach sich ziehen würde, als der
wahrscheinliche (der nur eine geringes Ärgernis darstellen würde), so wird die Priorität eher
beim unwahrscheinlichen liegen.
29
8.2. Risikoanalyse
Bedrohungsbaum kann zur Risikoanalyse verwendet werden.
Attributierung der Kanten mit den Risiken.
Bedrohung der
Vertraulichkeit des
Benutzer-Passwortes
Risiko:
niedrig
Ausspähen der
Terminaleingabe
Risiko:
hoch
Unverschlüsselte
Übertragung über
das Netz
Risiko:
hoch
Benutzer hat isolierten Arbeitsplatz und arbeitet oft übers Netz.
Sind die Bedrohungen durch einen Baum erfasst, so können die Risiken als Attributierungen
der Kanten des Baumes angegeben werden. Das Beispiel der Folie zeigt einen
Bedrohungsbaum für die Vertraulichkeit von Passwortdateien, falls ein Ausspähen über das
Netz erfolgt. Arbeitet der Benutzer isoliert, so tritt ein Ausspähen nur mit geringer
Wahrscheinlichkeit auf. Falls ein Benutzer sich häufig auf anderen Rechnern einloggt und
dabei das Passwort übers Netz übertragen wird, ist ein Ausspähen schon wahrscheinlicher.
30
8.2. Risikoanalyse
Bedrohungsmatrizen und –bäume sind nur ein Hilfsmittel.
Bedrohungs- und Risikoanalyse sind schwierige kreative
Prozesse, die sich kaum formalisieren oder automatisieren
lassen.
Sicherheitsdesigner muss noch erfinderischer als der Angreifer
sein.
31
8.3. Sicherheitsstrategie und -modell
Aus den Ergebnissen der Risikoanalyse wird die
Sicherheitsstrategie abgeleitet.
Sicherheitsstrategien können informell oder formal erfasst
werden und spezifizieren die Sicherheitsanforderungen.
Außerdem sind Maßnahmen zur Abwehr von Bedrohungen zu
ermitteln.
Beinhaltet auch die Kosten und den Aufwand zur Realisierung
der Schutzmaßnahmen (z.B. Kosten für neue Hardware zum
Sicherstellen von Verfügbarkeit etc.).
Aus der Sicherheitsstrategie wird ein Sicherheitsmodell
konstruiert.
Aus der Risikoanalyse ist abzuleiten, welche Maßnahmen zur Abwehr der Bedrohungen
erforderlich sind. Die erforderlichen Maßnahmen werden in einer Sicherheitsstrategie
informell oder formal erfasst. Das Aufstellen der Sicherheitsstrategie erfordert Fachwissen im
Bereich IT-Sicherheit um die geeigneten Maßnahmen zur Abwehr der Bedrohungen zu
ergreifen. Da die meisten Softwareentwickler jedoch keine Sicherheitsexperten sind und
Sprachen zur Spezifikation von Sicherheitsstrategien oft sehr speziell sind, werden in der
aktuellen Forschung zum Security Engineering zum einen Security Patterns (angelehnt an
Design Patterns) entwickelt, zum anderen wird versucht die dem Designer bekannte UML zur
Modellierung von Sicherheit zu verwenden.
32
8.3. Sicherheitsstrategie und -modell
Klassen von Anwendungen haben ähnliche Sicherheitsanforderungen.
Design Patterns sind ein Konzept, um immer wieder auftretende
Probleme sowie bewährte Lösungen schriftlich zu
dokumentieren.
Design Patterns halten fest,
• in welchen Kontext das Problem auftritt
• welche Anforderungen zu beachten sind
• welche Lösungen sich anbieten.
Nicht-Experten können vom Wissen der Experten profitieren, die
die Patterns geschrieben haben.
Design Patterns sind ein Konzept, um immer wieder auftretende Probleme und bewährte
Lösungen schriftlich zu dokumentieren. Patterns werden von Experten geschrieben, so dass
Laien von deren Expertenwissen profitieren. Dieser Ansatz der Design Patterns wird daher auf
den Problembereich der Sicherheit übertragen.
33
8.3.1 Security Patterns
Übertragen der Idee der Design Patterns auf Sicherheit 
Security Patterns
Security Patterns dokumentieren immer wieder auftretende
Sicherheitsprobleme und bewährte Lösungen.
Von Sicherheitsexperten geschrieben.
Struktur von Security Patterns ist vergleichbar mit der Struktur
von Design Patterns:
– Kontext
– Problem
– Anforderungen
– Lösung
Die Struktur von Security Patterns ist mit der von Design Patterns vergleichbar und unterteilt
sich in Kontext, Problem, Anforderungen und Lösung. Diese Aspekte werden auf den
folgenden Folien kurz vorgestellt.
34
Struktur von Security Patterns
Kontext
Beschreibt den Kontext des Sicherheitsproblems.
Kann mit einem Beispielszenario illustriert werden.
Aspekte der Umgebung des IT-Systems können beschrieben
werden.
Problem
Beschreibung der Bedrohungen bzw. Schutzziele, die durch die
Bedrohungen verletzt werden können.
35
Anforderungen
Beschreiben die Sicherheitsanforderungen, die zu beachten
sind.
Dazu gehören auch Anforderungen, die durch die
Sicherheitsanforderungen beeinflusst werden (z.B.
Performanz oder Benutzbarkeit).
Lösung
Maßnahmen zur Lösung des Problems im Kontext, d.h. die
Risiken auf ein Minimum reduzieren.
Es sollte mindestens eine Maßnahme für jede Bedrohung
geben.
Es können auch Vor- und Nachteile des Security Patterns
beschrieben werden.
36
Verwandte Patterns
Abhängigkeiten zu weiteren Security Patterns.
37
Beispiel: Handhabung von Cookies
(M. Schumacher, Informatik Spektrum, Juni 2002)
Kontext
Cookies zum Speichern und Abfragen für BenutzerInformationen. Server platzieren Cookies beim Klienten.
Problem
Cookies dürfen nur vom Server gelesen werden, der sie erzeugt
hat.
Es dürfen nur Informationen, die entweder vom Klienten oder
dem Server erzeugt werden, ausgetauscht werden.
38
Problem (Fortsetzung)
Bedrohungen:
• Dienstanbieter können Profile von Benutzern erstellen
• Benutzerdaten von verschiedenen Anbietern können
zusammengeführt werden
39
Anforderungen
– Anonymität:
Dienstanbietern und anderen Benutzern soll es nicht
möglich sein, die Identität eines Benutzers abzuleiten.
Ein Dienst darf den richtigen Benutzernamen nicht offen
legen.
– Unverknüpfbarkeit:
Ein Benutzer sollte mehrere Anfragen stellen können, ohne
das diese miteinander in Verbindung gebracht werden
können.
– Benutzbarkeit:
Viele Anwendungen sind nicht nutzbar, wenn Cookies nicht
akzeptiert werden.
Außerdem soll keine zusätzliche Software benötigt werden.
40
Lösung
Die Verwendung von Cookies muss vom Benutzer
eingeschränkt werden.
Benutzer müssen Cookies von Fall zu Fall aktivieren und
entscheiden, ob einem Anbieter vertraut wird.
Periodisches Löschen von Cookies zur Verhinderung von
Profilen.
Maximaler Schutz, wenn Cookies deaktiviert werden.
41
8.3.2 Sicherheit und UML
Integration von Sicherheitsdesign in den UMLSoftwareentwicklungsprozess
UML ist de facto Standard bei der Entwicklung objektorientierter Systeme.
Akzeptiert und beherrscht von vielen Designern und
Entwicklern.
Wie soll integriert werden?
• Verwenden existierender UML-Modelelemente
• Integration in existierende UML-Werkzeuge
• Kein Expertenwissen vom System-Designer erforderlich
• UML-Modelle zur Generierung von Sicherheitspezifikationen
Im folgenden wollen wir betrachten, wie sich die Entwicklung von Sicherheit in den
Softwareenticklungsprozess mit UML integrieren lässt. Die UML bietet sich an, da sie die defacto-Standardsprache bei der Entwicklung objektorientierter Systeme ist und von vielen
Entwicklern beherrscht und verstanden wird. Eine Integration sollte möglichst auf
vorhandenen Modellelementen der UML basieren, da auf diese Weise existierende UMLWerkzeuge benutzt werden können und kein zusätzliches Wissen vom Designer verlangt wird.
Die UML-Modelle sollten möglichst direkt zur automatischen Generierung der
Sicherheitsspezifikation verwendet werden, um den Designer weiter zu entlasten.
42
UMLSec
Erweiterung von UML-Diagrammen um spezielle
Stereotypen, tagged values (Jan Jürjens)
SecureUML
Modell-getriebene Entwicklung von rollenbasiertem
Zugriffsschutz und Generierung von Politiken für EJBs
(ArcStyler, www.io-software.com)
Raccoon
Integration von View-based Access Control und Generierung
der Politik für ein CORBA-Sicherheitsinfrastruktur aus den
UML-Diagrammen.
Es gibt mehrere Ansätze, die Sicherheitsdesign in die UML generieren. Auf den folgenden
Folien wird der Raccoon-Ansatz näher vorgestellt.
43
Funktionale
Anforderungen
Funktionales
Design
+
+
IDL
IDL
VPL
+
Sicherheits
design
Generierung
44
Sicherheitsanalyse
Funktionale Anforderungen
werden in Use Cases
ausgedrückt.
werden diesen Use Cases
zugefügt.
Zugriffsschutzanforderungen
sind schon in den
funktionalen Anforderungen
enthalten und vereinfachen
die Integration.
45
Sicherheitsrollen entsprechen den Aktoren der UML-Use-CaseDiagramme
46
Ermitteln von Zugriffen aus den informellen Zugriffsbeschreibungen.
edit entry: Der Kalenderbesitzer kann seine Einträge lesen
und modifizieren. Änderungen können die Zeit, den Tag,
oder den Raum betreffen. Die Sekretärin des
Kalenderbesitzers kann die Kalendereinträge ebenfalls
einsehen und ändern.
update room: Eine Sekretärin bucht einen Raum für einen
Kalenderbesitzer. Der Besitzer darf den Raum nicht selbst
buchen.
47
48
Zusammenfassung Sicherheitsanalyse
UML-Aktoren = Sicherheitsrollen
Implizite Zugriffsinformationen werden in Notizen explizit
dokumentiert.
Software-Analyst betrachtet und beschreibt Sicherheit früh im
Entwicklungsprozess.
49
Sicherheits-Design
Ausgehend von den Use-Case-Diagrammen werden die
Klassendiagramme für die CORBA-Schnittstellen erstellt.
50
Notizen der Use-Case-Diagramme sind Grundlage der ViewDefinition.
51
Für jede Notiz erzeuge eine View.
View hat alle
Zugriffsrechte einer
Schnittstelle.
Rollen, denen die
View gegeben werden
kann.
52
View Diagram enthält alle Views.
53
Generierung der VPL-Spezifikation.
XMI-Export XML
UML CASE Tool
Role
Server
XSLT VPL
Policy
Server
RACCOON
54
Generierung der Rollen.
UML
VPL
policy Calendar {
roles
Other
Secretary: Other
CalendarOwner: Secretary
}
55
Generierung der Views.
UML
IDL:Room
RoomBooking
Secretary
book
cancel
VPL
View RoomBooking
controls Room
restricted to Secretary
NoRoomBooking {
allow
CalendarOwner
book
_cancel
_book
cancel
}
56
Zusammenfassung
Systematischer Ansatz zur Integration von Zugriffsschutzdesign
in den Entwicklungsprozess mit UML.
Sicherheitsanforderungen werden früh betrachtet.
UML-Diagramme können zur Generierung der Sicherheitspolitk
verwendet werden.
UML-Werkzeuge können benutzt werden.
Kein Sicherheitsexpertenwissen wird benötigt.
57
8.4 Sicherheitsarchitektur
Ein Architektur-Entwurf konkretisiert das Sicherheitsmodell.
Die Systemkomponenten (inklusive der Komponenten zur
Realisierung der sicherheitsspezifischen Funktionen) mit ihren
Schnittstellen und Abhängigkeiten werden festgelegt.
Die Komponenten werden derart verfeinert, dass eine
Implementierung erfolgen kann.
In der Implementierungsphase sind die benötigten
Datenstrukturen und Algorithmen zu wählen.
Hier kann auf kryptographische Verfahren, Passwortschutz,
Schlüsselverteilungsprotokolle, Authentifizierungsdienste etc.
zugegriffen werden.
58
8.5 Sicherheitskriterien
Kriterien für die Bewertung der Sicherheit von IT-Systemen.
Kriterienkataloge stellen ein Bewertungsschema zur Verfügung, mit
denen die Sicherheit unterschiedlicher Systeme verglichen werden
kann.
Evaluierung und Bewertung erfolgt durch unabhängige
Evaluierungsstellen, die Zertifikate ausstellen.
Ziele von Sicherheitskriterien
Richtschnur für die Entwicklung sicherer, vertrauenswürdiger
Systeme
objektive Bewertung dieser Systeme von einer neutralen und
kompetenten Instanz (im Gegensatz zur Herstellererklärung)
Möglichkeit für die Anwender / Benutzer zur Auswahl eines
geeigneten IT-Sicherheitsprodukts
Für die Bewertung der Sicherheit von IT-Systemen werden nationale und internationale
Kriterien-Kataloge entwickelt. Kriterienkataloge stellen ein Bewertungsschema zur Verfügung,
das es erlaubt, die Sicherheit unterschiedlicher Systeme zu vergleichen. Die Evaluierung und
Bewertung erfolgt durch unabhängige Evaluierungsstellen, die Zertifikate ausstellen. Die Ziele
der Entwicklung von Sicherheitskriterien sind:
Richtschnur für die Entwicklung sicherer, vertrauenswürdiger Systeme,
objektive Bewertung dieser Systeme von einer neutralen und kompetenten Instanz (im
Gegensatz zur Herstellererklärung),
Möglichkeit für die Anwender / Benutzer zur Auswahl eines geeigneten IT-Sicherheitsprodukts.
59
8.5 Sicherheitskriterien
Historie der Entwicklung von IT-Sicherheitskriterien
1983
Trusted Computer Security Evaluation
Criteria Orange Book - TCSEC 1989 IT-Sicherheitskriterien (ITS)
1991
Information Technology Security
Evaluation Criteria ITSEC
1998 Common Criteria (CC) Version 2.0
60
8.5.1 TCSEC
Trusted Computer Security Evaluation Criteria Orange Book –
TCSEC
http://www.radium.ncsc.mil/tpep/library/rainbow/index.html
Zuständig ist die US National Security Agency (NSA).
Es gibt sieben Hierarchiestufen (C1, C2, B1, B2, B3, A, D) zur
Klassifikation der Sicherheit.
Für die TCSEC-Kriterien ist die US National Security Agency zuständig. Die Kriterien sind
als das Orange Book bekannt, welches die Farbe des Katalogumschlages ist. Die TCSEC legen
mit den Stufen D, C, B und A sowie deren weiteren Untergliederungen sieben Hierarchiestufen
zur Klassifikation der Sicherheit eines Systems fest.
61
8.5.1 TCSEC
Stufe D (niedrigste Stufe)
Systeme die keinen oder minimalen Schutz gewährleisten.
Stufe C
Benutzerbestimmte Zugriffskontrolle, d.h. Rechte werden
vom Benutzer individuell vergeben.
Stufe C1
- Grobgranulare Festlegung von Rechten (z.B.
Zugriffskontrolle basiert auf Benutzerklassen)
- Maßnahmen zur Authentifizierung und zum Schutz der
Authentifizierungsdaten.
- Geringe Anforderungen an Dokumentation und Systemtests.
Beispiel: Original-Unix-Systeme
Die niedrigste Stufe D gilt für Systeme, die keinen bzw. minimalen Schutz gewährleisten. Eine
Bewertung nach Stufe C erfordert, das Zugriffsrechte durch Benutzer individuell vergeben
werden können. Eine Einstufung gemäß C1 besagt, dass die Rechtefestlegungen nur
grobgranular festgelegt werden können. C1 erfordert Maßnahmen zur Kontrolle der Identität
von Benutzern und zum Schutz dieser Kontrollstrukturen. An die Dokumentation und
durchzuführende Systemtests werden nur geringe Anforderungen gestellt. Es ist lediglich
sicherzustellen, dass keine offensichtlichen Möglichkeiten zur Umgehung der Kontrollen
existieren. Klassische Unix-Systeme erfüllen die C1-Anforderungen.
62
8.5.1 TCSEC
Stufe C2
- Feingranulare Festlegung der Rechte, d.h. Rechte an
einzelne Benutzer und Zugriffsverbote.
- Aktionen von Benutzern müssen abrechenbar sein und
Zugriffe auf zu schützende Objekte muss überwacht
werden (Auditing)
- Tests bzgl. Auditung und Authentifizierung.
Beispiel: Windows NT, IBM AIX 4.3, Novell NetWare 4.11
Bei Stufe C2 müssen Benutzern differenzierte Möglichkeiten zur Rechtefestlegung zur
Verfügung stehen, so dass Zugriffsrechte an einzelne Benutzer vergeben oder Zugriffsverbote
festgelegt werden können. Die Aktionen einzelner Benutzer müssen abrechenbar sein und
Zugriffe auf zu schützende Daten müssen überwacht werden. Zu den C2-Systemen gehört
beispielsweise Windows NT, IBM AIX 4.3 oder Novell NetWare 4.11.
63
8.5.1 TCSEC
Stufe B
Systembestimmte Zugriffskontrolle, Einführen von
Sicherheitsklassen, Informationsflusskontrolle, formale
Modellierung
Stufe B1
- Erfüllen aller Anforderungen der Stufe C2.
- Systembestimmte Zugriffskontrolle durch Sicherheitsklassen für alle Objekte und Subjekte.
- Zugriffe auf Objekte werden durch systemglobale Regeln
beschränkt (z.B. Regeln wie bei Bell-LaPadula).
- Systembestimmte Zugriffsregeln dominieren die
benutzerbestimmten Regeln.
- Informelle Beschreibung eines Sicherheitsmodells.
Beispiel: HP-UX BLS 9.0.9+
In der Stufe B werden zusätzlich Sicherheitsklassen für die Objekte und Subjekte des Systems
eingeführt. Systeme der Stufe B1 umfassen die Anforderungen der Stufe C2 und
gewährleisten systembestimmte Zugriffskontrolle durch eine Menge von Sicherheitsklassen.
Sicherheitsklassen müssen jedem Subjekt und jedem Objekt zugeordnet werden. Zugriffe auf
Objekte werden durch systemglobale Regeln beschränkt (z.B. Regeln des Bell-LaPadulaModells).
Systembestimmte Beschränkungen dominieren die benutzerbestimmten
Rechtevergaben. B1-Systeme erfordern ein informelle Beschreibung eines Sicherheitsmodells.
64
8.5.1 TCSEC
Stufe B2
- Formales Sicherheitsmodell
- Maßnahmen zur Erkennung bzw. Behandlung verdeckter
Kanäle
- Vertrauenswürdige Kommunikation zwischen Benutzer und
Sicherheitskomponenten.
Beispiel: Trusted XENIX 4.0 (Unix-Derivat)
Stufe B3
- Zusätzliche Anforderungen an die Sicherheitskomponenten.
- Sicherheitskomponenten müssen getestet und geschützt
werden.
- Alle sicherheitsrelevanten Aktionen bzgl. der
Sicherheitskomponenten müssen überwacht werden.
Beispiel: XTS-300 STOP 4.4.2
Eine Einstufung in Stufe B2 erfordert ein formales Sicherheitsmodell sowie Maßnahmen zur
Erkennung bzw. Behandlung verdeckter Kanäle. Es muss eine vertrauenswürdige direkte
Kommunikation zwischen dem Benutzer und den Sicherheitskomponenten etabliert werden.
Die Stufe B3 stellt zusätzliche Anforderungen an die Menge der sicherheitsrelevanten
Komponenten und Dienste. Die Komponenten müssen getestet und gegen unbefugte Zugriffe
geschützt sein und alle sicherheitsrelevanten Aktionen sind zu überwachen.
65
8.5.1 TCSEC
Stufe A
Erfordert zusätzlich eine formale Verifikation spezifizierter
Sicherheitseigenschaften.
Beispiel: Kommunikationssoftware MLS LAN V.2.1 der Firma
Boeing.
Berichte über die Evaluierungen von Systemen sind unter
http://www.radium.ncsc.mil/tpep/library/fers/tcsec_fers.htm
einzusehen.
Die Stufe A erfordert keine funktionalen Erweiterungen der Stufe B3, jedoch einen formalen
Nachweis spezifizierter Sicherheitseigenschaften.
66
8.5.1 TCSEC
Kritikpunkte an den TCSEC-Kriterien
- Fokussierung auf Betriebssysteme, so dass z.B.
Anwendungssysteme nur unzureichend erfasst werden.
- Betonung militärischer Einsatzumgebungen zugunsten
kommerzieller Bereiche.
- Herstellerinteressen werden gegenüber benutzerspezifischen
Sicherheitsinteressen stärker betrachtet.
- Trennung zwischen Funktionalität und Qualität
(Sicherheitsfunktion ist da, aber wie gut realisiert sie die
Sicherheitsanforderungen?)
Kritik an den TCSEC-Kriterien betrifft die einseitige Ausrichtung auf Betriebssysteme, so dass
offene Kommunikationssysteme oder spezielle Anwendungssysteme nur unzureichend erfasst
werden. Außerdem werden militärische Einsatzumgebungen betont und Anforderungen des
kommerziellen Bereichs nicht ausreichend berücksichtigt, Herstellerinteressen werden
zugunsten benutzerspezifischen Interessen vernachlässigt und es existiert eine Trennung
zwischen Funktionalität und Qualität. Die TCSEC-Kriterien bewerten nur, dass eine
Funktionalität erbracht wurde, nicht mit welcher Wirksamkeit die Funktionalität die
Sicherheitsanforderungen erfüllt.
67
8.5.2 ITS
Deutsche IT-Sicherheitskriterien (Grünbuch) wurden von der
Zentralstelle für Sicherheit in der Informationstechnik (ZSI)
entwickelt.
Zuständig ist das Bundesamt für Sicherheit in der
Informationstechnik (BSI) mit TÜVs.
Beschreibt zehn Funktionsklassen F1 bis F10 und acht
Qualitätsstufen Q0 bis Q7.
F1-F5 entsprechen den TCSEC-Klassen C1,C2, B1,B2, B3.
F6-F10 sind netzbezogen und anwendungsbezogen
Q0 nicht vertrauenswürdig
Q1 – Q6 wachsende Anforderungen bzgl. Dokumentation, Test,
Verifikation
Die deutschen IT-Sicherheitskriterien (Grünbuch) und deren Methodologie wurden zwischen
1989 und 1990 von der Zentralstelle für Sicherheit in der Informationstechnik (ZSI) entwickelt
und veröffentlicht. Die ZSI ist der Vorgänger des Bundesamtes für Sicherheit in der
Informationstechnik (BSI). In den Kriterien sind 10 Funktionalitätsklassen beschrieben, wobei
die ersten 5 denen des Orange-Book entsprechen. Als ein Maß der Vertrauenswürdigkeit in
die beschriebene Funktionalität wurden 8 hierarchische Qualitätsstufen Q0 – Q7 eingeführt.
68
8.5.2 ITS
ITS-Funktionsklassen
Funktionsklasse F6
Besondere Anforderungen an die Integrität der Daten (z.B. für
Daten in einer Datenbank).
Betrachtet Rollen und Objekttypen und die Protokollierung
sicherheitsrelevanter Zugriffe.
Funktionsklasse F7
Stellt hohe Anforderungen bzgl. Verfügbarkeit.
Fordert Maßnahmen zur Fehlerbehandlung und –überbrückung,
zum Zurücksetzen abgebrochener Berechnungen sowie zur
Verklemmungsfreiheit.
Die Funktionsklasse F6 stellt besondere Anforderungen an die Integrität von Daten, wie sie
z.B. in Datenbanken notwendig sind. Hierzu gehört beispielsweise die Einführung von Rollen
und Objekttypen oder die Protokollierung sicherheitsrelevanter Zugriffe auf Daten. Die Klasse
F7 stellt hohe Anforderungen in Bezug auf Verfügbarkeit. Gefordert werden Maßnahmen zur
Fehlerbehandlung und –überbrückung, zum Zurücksetzen abgebrochener Berechnungen sowie
Berechnungen zur Gewährleistung von Verklemmungsfreiheit.
69
8.5.2 ITS
Funktionsklasse F8
Beziehen sich auf die Datenintegrität während der Kommunikation.
Fordert z.B. Maßnahmen zur Erkennung von
Wiedereinspielungen.
Funktionsklasse F9
Stellt Anforderungen bzgl. der Vertraulichkeit der Daten bei der
Datenübertragung.
Ist beispielsweise für Verschlüsselungssysteme relevant.
Funktionsklasse F10
Umfasst Vertraulichkeits- und Integritätsbedingungen vernetzter
Systeme.
Fordert zum Beispiel die Authentifizierung von
Kommunikationspartnern, Verschlüsselung, Protokollierung.
Die Anforderungen der Klasse F8 beziehen sich auf die Datenintegrität während der
Kommunikation. Es werden beispielsweise Maßnahmen zur Erkennung von
Wiedereinspielungen gefordert. Die Klasse F9 stellt Anforderungen an die Vertraulichkeit der
Daten bei deren Übertragung und ist beispielsweise für Verschlüsselungsgeräte relevant. Die
Funktionsklasse F10 umfasst Vertraulichkeits- und Integritätsanforderungen vernetzter
Systeme.
Die
Klasse
fordert
beispielsweise
die
Authentifizierung
von
Kommunikationspartnern, Verschlüsselung und Protokollierung.
70
8.5.2 ITS
Qualitätsstufen sind ein Maß der Vertrauenswürdigkeit in die
beschriebene Funktionalität.
Konzept der Qualitätsstufen findet sich in den ITSEC-Kriterien und
Common Criteria wieder.
Bewertung der Qualität eines Systems untersucht z.B.:
- Qualität der Darstellung der Sicherheitsanforderungen und deren
Konsistenz
- Qualität der Spezifikation der zu evaluierenden Systemteile und
der Spezifikationswerkzeuge
- Qualität des Herstellungsvorgangs, z.B. verwendete
Entwicklungswerkzeuge, Tests, Fähigkeiten des Personals.
- Korrektheit und Verständlichkeit der Dokumentation.
- Stärke und Eignung der verwendeten Sicherheitsmechanismen
Als ein Maß der Vertrauenswürdigkeit in die beschriebene Funktionalität wurden 8
hierarchische Qualitätsstufen Q0 – Q7 eingeführt. Die Qualitätsstufe Q0 stellt die niedrigste
und Q7 die höchste Qualitätsstufe dar. Dieses in den deutschen IT-Sicherheitskriterien
erstmals eingeführte Konzept der Trennung von Funktionalität und Prüftiefe (Qualitätsstufe)
findet sich sowohl in ITSEC als auch in Common Criteria wieder. Für die Bewertung der
Qualität eines Systems werden unterschiedliche Einzelaspekte untersucht und bewertet. Dazu
gehören die Qualität der Darstellung der Sicherheitsanforderungen sowie deren Konsistenz, die
Qualität der Spezifikation der zu evaluierenden Systemteile und die Qualität der verwendeten
Werkzeuge. Weitere Aspekte betreffen die Stärke der verwendeten Sicherheitsmechanismen
und deren Eignung, die Qualität des Herstellungsvorgangs, einschließlich der verwendeten
Werkzeuge, die Qualität der durchgeführten Tests und die Fähigkeiten des Personals. Auch die
Dokumentation sowie deren Korrektheit und Verständlichkeit wird untersucht.
71
8.5.2 ITS
Bewertung von Sicherheitsmechanismen anhand einer Skala:
ungeeignet Mechanismus ist nicht wirksam
schwach
Abwehr gegen unabsichtliche Verstöße gegen die
Sicherheitsanforderung, jedoch kein Hindernis
gegen
absichtliche Verstöße.
mittelstark Verhindert absichtliche Verstöße, der Mechanismus
kann aber mit mittelgroßem Aufwand von
Personen mit
normalen Kenntnissen
überwunden werden.
stark
Mechanismus kann nur mit großem Aufwand oder mit
aufwendigen Hilfsmitteln überwunden werden.
sehr stark Mechanismus kann beim derzeitigen Stand der Technik
nur mit sehr großem Aufwand und mit sehr
aufwendigen
Hilfsmitteln überwunden werden.
Zur Bewertung von Sicherheitsmechanismen ist eine Skala definiert, die durch die Stufen
ungeeignet, schwach, mittelstark, stark, sehr stark festgelegt ist. Die Bedeutung der einzelnen
Stufen zeigt die Folie.
72
8.5.2 ITS
Beispiel: Authentifizierungsmechanismen
Bewertung über die Wahrscheinlichkeit, mit der eine nicht
korrekte Authentifizierung möglich ist.
schwach
wenn Wahrscheinlichkeit größer 10-2
mittelstark
“
10-4
stark
“
10-6
sehr stark
“
10-8
Die Folie zeigt ein Beispiel anhand von Authentifizierungsmechanismen. Deren Qualität wird
anhand der Wahrscheinlichkeit bewertet, mit der eine nicht korrekte Authentifizierung möglich
ist.
73
8.5.2 ITS
ITS-Qualitätsstufen
Qualitätsstufe Q0
Keine Sicherheitsanforderungen.
Für Systeme, deren Qualität für die anderen Qualitätsstufen
nicht ausreicht.
Qualitätsstufe Q1
System ist grob auf Korrektheit geprüft.
Bietet keinen oder geringen Schutz gegen Manipulation.
Sicherheitsmechanismen mit schwacher Stärke.
Die Qualitätsstufe Q0 stellt keine Qualitätsanforderungen und ist für Systeme, deren Qualität
für keine der höheren Qualitätsstufen ausreicht. Systeme der Stufe Q1 sind nur grob auf
Korrektheit geprüft, bieten keinen oder geringen Schutz vor Manipulationen und verwendet
Sicherheitsmechanismen mit schwacher Stärke.
74
8.5.2 ITS
Qualitätsstufe Q2
System ist eingehend auf Korrektheit geprüft.
Bietet zufriedenstellenden Schutz gegen Manipulationen.
Sicherheitsmechanismen mit mittelstarker Stärke.
Qualitätsstufen Q3-Q5
Erfordern semiformale bzw. formale Techniken zur Erstellung
des Systems.
Konsistenzabgleich zwischen Quellcode und Spezifikation.
Schutzmechanismen mit starker Stärke.
Qualitätsstufen Q6 und Q7
Bieten formal verifizierten Schutz.
Mechanismen mit starker (Q6) und sehr starker (Q7) Stärke.
Systeme der Stufe Q2 wurden eingehend auf Korrektheit geprüft und bieten einen
zufriedenstellenden Schutz gegen Manipulationen. Die Stufe Q2 erfordert, dass mittelstarke
Sicherheitsmechanismen verwendet werden. Die Stufen Q3 bis Q5 erfordern zur Erstellung des
IT-Systems semiformale oder formale Techniken und ein Konsistenzabgleich zwischen
Quellcode und Spezifikation. Es werden starke Mechanismen gefordert. Systeme mit den
Qualitätsstufen Q6 und Q7 bieten einen formal verifizierten Schutz mit Mechanismen die stark
(Q6) bzw. sehr stark (Q7) sind.
75
8.5.3 ITSEC
Europäische Kriterien in den Information Technology Security
Evaluation Criteria (ITSEC)
Analog zu den ITS Unterteilung in Funktionsklassen und
erweiterte Qualitätsklassen.
Qualität wird unterteilt in Korrektheit und Wirksamkeit des
Sicherheitsmechanismus.
Wirksamkeit wird in drei Stufen bewertet: niedrig, mittel und
hoch
Korrektheit wird in sechs Evaluationsstufen E1 (niedrig) bis E6
(hoch).
Auf europäischer Ebene wurden die "Information Technology Security Evaluation Criteria –
ITSEC" am 3. März 1998, im Rahmen des europäischen Abkommens zur gegenseitigen
Anerkennung, der Zertifikate der ITSEC-Evaluation, in Kraft gesetzt. Die ITSEC-Kriterien
legen analog zu den deutschen ITS-Kriterien Funktionsklassen und Qualitätsklassen fest. Die
Qualitätsstufen werden jedoch noch weiter aufgeteilt in Korrektheit und Wirksamkeit des
eingesetzten Mechanismus. Die Wirksamkeit wird durch eine Skala durch die Stufen niedrig,
mittel und hoch bewertet. Zur Bewertung des Vertrauens in die Korrektheit werden sechs
hierarchische Evaluationsstufen E1 bis E6 definiert. E1 bezeichnet die niedrigste, E6 die
höchste Stufe.
76
8.5.3 ITSEC
Wirksamkeitsstufen
Niedrig:
Mechanismen bieten Schutz gegen zufälliges,
unbeabsichtigtes Überwinden der
Sicherheitsmechanismen
Mittel:
Mechanismen bieten Schutz gegen Angreifer mit
beschränkten Gelegenheiten und Betriebsmitteln
Hoch:
Mechanismen können nur von Angreifern
überwunden werden, die über sehr gute
Fachkenntnisse, Gelegenheiten und Betriebsmittel
verfügen, wobei ein solcher erfolgreicher Angriff
normalerweise als nicht durchführbar beurteilt wird.
Die Bedeutung der einzelnen Wirksamkeitsstufen zeigt die Folie.
77
8.5.3 ITSEC
Evaluationsstufen
E1
Informelle Beschreibung der Sicherheitsstrategie und der
Bedrohungen.
Informelle Beschreibung des Architekturentwurfs mit den
einzusetzenden Sicherheitsmechanismen.
Funktionale Tests.
E2
Informelle Beschreibung des Feinentwurfs.
Testdokumentationen und Bewertung der Testergebnisse.
E3
Beschreibung des Zusammenhangs zwischen Quellcode
bzw. Hardware- Konstruktionszeichnungen und den
Komponenten des Feinentwurfs.
Die Bedeutung der Evaluationsstufen ist auf den folgenden zwei Folien beschrieben.
78
8.5.3 ITSEC
E4 Formales Sicherheitsmodell, semiformale Notation der
sicherheitsspezifischen Funktionen, des Architektur- und
des Feinentwurfs.
E5 Feinentwurf muss nachvollziehbar auf Quellcode bzw.
Hardware-Konstruktionszeichnungen abgebildet werden.
E6
Formale Spezifikation der Sicherheitsanforderungen und
des Architekturentwurfs.
79
8.5.3 ITSEC
Qualität eines Systems ist Paar aus
(Evaluationsstufe, Wirksamkeitsstufe)
ITS
ITSEC
Q0
E0
Q1
(E1,niedrig)
Q2
(E2,mittel)
Q3-Q5
(E3-E5,hoch)
Q6,Q7
(E6,hoch)
Die Qualität eines Systems besteht dann aus einem Paar aus Evaluationsstufe und
Wirksamkeitsstufe. Der Zusammenhang zwischen den Qualitätsstufen der ITS-Kriterien und
den Evaluationspaaren der ITSEC sind in der Tabelle der Folie gezeigt.
80
8.5.4 Common Criteria
Die Common Criteria (CC) sind Grundlage für einen
internationalen Standard.
Die CC 2.1 sind ISO-Standard 15408.
Die CC sind eine Weiterentwicklung und Harmonisierung der
ITSEC, der TCSEC und der kanadischen Kriterien CTCPEC.
Common Methodology for Information Security Evaluation
(CEM)
Gemeinsame abgestimmte Evaluationsmethodologie auf
Grundlage der CC.
CC beschreiben, was evaluiert werden soll, die CEM, wie
evaluiert werden soll.
Mit den Common Criteria (CC) wurden Kriterien entwickelt, die als Grundlage für einen
internationalen Standard dienen und damit weltweit anerkannt und gültig sein sollen. Das
Bundesamt für Sicherheit in der Informationstechnik (BSI) hat dabei die Rolle des deutschen
Partners übernommen. Die CC 2.1 sind durch die Internationale Standardisierungsorganisation
(ISO) unter der Nummer 15408 ein internationaler Standard geworden.
Erste Entwürfe einer gemeinsamen Evaluationsmethodologie (Common Methodology for
Information Security Evaluation CEM), die der Entwicklung eines gemeinsamen Konzepts und
einer abgestimmten Methodik für die Evaluierung auf Grundlage der CC dienen, sind
entwickelt und veröffentlicht worden. Die Kriterien beschreiben, was evaluiert und die
Methodologie, wie evaluiert werden soll.
81
Common Criteria besteht aus drei Teilen.
Teil 1: Einführung und allgemeines Modell
- Überblick über die für die Evaluierung erforderlichen
Dokumente
- Schutzprofile (Protection Profile) beschreiben die
- Einsatzumgebung der Sicherheitsmechanismen (Security
Target)
Die Common Criteria bestehen aus drei Teilen.
Teil 1: Einführung und allgemeines Modell
Hier werden die Grundlagen der IT-Sicherheitsevaluation und der allgemeine Geltungsbereich
der CC erläutert. In den Anhängen werden Schutzprofile (Protection Profile) und
Sicherheitsvorgaben (Security Target) für den zu prüfenden Evaluationsgegenstand (EVG)
beschrieben.
82
Teil 2: Funktionale Sicherheitsanforderungen
- Anforderungen an Sicherheitsfunktionen analog zu den
ITSEC-Funktionsklassen
Teil 3: Anforderungen an die Vertrauenswürdigkeit
- Beschreibung der Kriterien zur Evaluierung der Schutzprofile
Funktionsklassen der CC (ca. 150) sind wesentlich konkreter
und detaillierter als ITSEC-Funktionsklassen.
Evaluierungsstufen der CC entsprechen den ITSECEvaluierungsstufen.
Teil 2: Funktionale Sicherheitsanforderungen
Dieser Teil enthält einen umfangreichen Katalog von Funktionalitätsanforderungen. Er stellt
ein empfohlenes Angebot für die Beschreibung der Funktionalität eines Produktes bzw.
Systems dar, von dem jedoch in begründeten Fällen abgewichen werden kann. Im Anhang
finden sich Hintergrundinformationen. Zusätzlich werden Zusammenhänge zwischen
Bedrohungen, Sicherheitszielen und funktionalen Anforderungen aufgezeigt.
Teil 3: Anforderungen an die Vertrauenswürdigkeit
Hier sind die Anforderungen an die Vertrauenswürdigkeit aufgelistet. Wichtig ist, dass ein
Evaluationsergebnis immer auf einer Vertrauenswürdigkeitsstufe (EAL) basieren sollte,
eventuell ergänzt durch weitere Anforderungen. Die CC geben sieben hierarchische
EALStufen vor.
83

8. Security Engineering

Transcription

Similar documents

Digital Rights Management

friedens- und konfliktforschung

Integrity deutsch neu

IT-Sicherheit: Authentisierung, Sicherheitsprotokolle Authentisierung

Diplomarbeit

IT-Sicherheit

die datenschleuder. - Chaosradio

RFID - Radio Frequency Identification

Diplombericht

Penetration Testing

McAfee Data Exchange Layer - Whitepaper

Werra-Salz: Rechtliche Anforderungen an die

Selected Bibliography 2011

itsecurity - IT Management

kombiniertes data mining – klassifikation unter verwendung von

Natriuretisches B-typ- peptid / (BNp)

Sicherheit in Onlinespielen

IT-Risiken - uDoo-Logo (Link zur uDoo-Startseite)

Lebenszyklusorientiertes Risikomanagement in - rt

wartungs- vertrag - JEDV

Rahmenthemen - Alte Kantonsschule Aarau

„Windenergie“ der Stadt Beckum