safety versus security gegenüberstellung und … · any finite behavior can be extended into the...
TRANSCRIPT
Safety versus SecurityGegenüberstellung und Einordnung
Felix Freiling
25.6.2010Vortrag bei Siemens, München
Sicherheit
● Seltene Vorteile für deutschen Sprachraum● Seltene Vorteile für deutschen Sprachraum
● Übersetzung Deutsch ↔ Englisch
● Vergleiche: Fachbereich „Sicherheit“ der GI
– verbindet alle Fachgruppen mit Bezug zu Safety und/oder Security
Safety
● Oft auch als technische Sicherheit● Oft auch als technische Sicherheitbezeichnet
● Stichworte?
Safety
● Oft auch als technische Sicherheit● Oft auch als technische Sicherheitbezeichnet
● Stichworte:
– Fehlertolerante Systeme
– Hardwarefehler
(Hoch-)Verfügbarkeit– (Hoch-)Verfügbarkeit
– RAID, redundante Systeme
– Kernkraftwerke, Verkehrsflugzeuge, ...
Bus-Architektur im Space Shuttle, Quelle: James E. Tomayko: Computers in Spaceflight. The NASA Experience. NASA Contracor Report 182505, 1988
Security
● Oft auch als IT-Sicherheit oder ● Oft auch als IT-Sicherheit oder Informationssicherheit bezeichnet
● Stichworte?
Security
● Oft auch als IT-Sicherheit oder ● Oft auch als IT-Sicherheit oder Informationssicherheit bezeichnet
● Stichworte:
– Hacker, Cybercrime, Malware
– Programmierfehler, Exploits
Firewalls, Intrusion Detection Systeme– Firewalls, Intrusion Detection Systeme
– Passwörter, Kryptographie
– Ausspähen von Daten
– CERT
Safety und Security
● Größe Ähnlichkeiten bei den Anforderungen● Größe Ähnlichkeiten bei den Anforderungen(Requirements) und Annahmen
– Safety-Anforderungen sind in der Regel auch Security-Anforderungen und umgekehrt
● Große Unterschiede bei den Mechanismen
– Um Safety-Anforderungen umzusetzen braucht – Um Safety-Anforderungen umzusetzen braucht man andere Konzepte als bei Security-Anforderungen und umgekehrt
Asynchrone verteilte Systeme mit Fehlern
� Set of processes that communicate via messages over reliable� Set of processes that communicate via messages over reliablechannels
� Asynchronous = no upper bounds on message delivery delays andrelative process speeds
� Processes can crash (stop executing steps of their algorithm)
Anforderungen: Safety and Liveness
� Safety: "something bad will never happen"
� Violated in finite time� Violated in finite time
� Cannot be "made good" again (catastrophic behaviorprefixes)
� Beispiele: mutual exclusion, partial correctness
� Liveness: "something good will eventually happen"
� Violated in infinite time
Any finite behavior can be extended into the property� Any finite behavior can be extended into the property
� Beispiele: termination, starvation freedom
� Beide Eigenschaftsklassen sind fundamental[Lamport 1977, Alpern and Schneider 1985]
Anforderungen im Bereich Safety
● Vermeiden von katastrophalen Auswirkungen ● Vermeiden von katastrophalen Auswirkungen auf die Umgebung
● „Es ist niemals der Fall, dass X“ für X =
– „das Atomkraftwerk fliegt in die Luft“
– „das Steuerungssystem im Flugzeug stürzt ab“– „das Steuerungssystem im Flugzeug stürzt ab“
● Anforderungen sind immer als Kombination von Safety- und Liveness-Anforderungen formulierbar
Anforderungen im Bereich Security
● Vermeiden von katastrophalen Auswirkungen ● Vermeiden von katastrophalen Auswirkungen auf die Umgebung
● Jede Safety-Anforderungen ist auch eine Security-Anforderung
– Beispiel: Denial-of-Service
Aber auch: Schutz des Systems vor der ● Aber auch: Schutz des Systems vor der Umgebung ...
Beispiel: Vertraulicher Kanal
send(m) receive(m)m
� Anforderung: Angreifer soll Inhalt der Nachricht nicht kennenlernen
Nicht spezifizierbar als Safety-Anforderung
eavesdropper
� Nicht spezifizierbar als Safety-Anforderung oder Liveness-Anforderung� „Höhere“ Anforderung, kann nur auf
Verhaltensmengen definiert werden, nicht auf einem einzelnen Verhalten
Safety, Liveness, Information Flow
� Safety-Anforderungen und Liveness-Anforderungen bestimmen den „funktionalen“ Anteil des VerhaltensAnteil des Verhaltens
� Was soll schlussendlich passieren?� Was soll nicht passieren?
� Vertraulichkeitsanforderungen durch Information Flow bestimmen� Wer darf welche Informationen lernen?
� Anforderungen sind komplett beschreibbar mittels Safety, Liveness, Information Flow
� Information Flow braucht man, um Geheimnisse zu spezifizieren
Annahmen im Bereich Safety: endliche Fehlerannahme
● Fehler dürfen nicht beliebig auftreten● Fehler dürfen nicht beliebig auftreten
● Beispiele für Fehlerannahmen:
– Maximal 2 aus 5 Rechnern gehen während der Mission kaputt
– Kosmische Strahlung tritt maximal mit einer Dosis x aufDosis x auf
– Fehlfunktionen in einem bestimmten Rechner hören nach einer Zeit x auf
● Angst vor Hardwarefehlern!
Annahme im Bereich Security: beschränkter Angreifer
● Beschränkung der Handlungsoptionen pro kompromittiertem Rechnerkompromittiertem Rechner
– Denial-of-Service (Rechnerabsturz)– Auslesen von Speicher– Veränderung des Programms
● Beschränkung der Ausdehnung– kann nicht überall gleichzeitig mithören– kann nicht überall gleichzeitig mithören– kann nur maximal t aus n Rechner kontrollieren
● Laufzeitbeschränkung – z.B. kein exponentielles Brute Force möglich
Zentraler Unterschied
● Existenz eines intelligenten, strategischenGegenspielers im Bereich SecurityGegenspielers im Bereich Security
● Im Bereich Safety: zufälliger Gegenspieler● Grenzfall: Byzantinische Fehler
– Ursprünglich als Modell für Komponenten, die “ausser Kontrolle” geraten
– Heute oft missverstanden als bösartiger Angreifer– Heute oft missverstanden als bösartiger Angreifer
● Aber: bösartig/beliebig ist nicht zufällig– und auch nicht (statistisch) unabhängig– “Faults don’t log in”
Strukturierung des Universums von Anforderungen und Annahmen
● Anforderungen: Funktional (Safety/Liveness) vs. Informationsfluss (Information Flow)
● Annahmen: gutartig/zufällig vs bösartig/beliebig
non-functional security
functional
benign/random severe/worst case
fault-tolerance
Zentraler Mechanismus im Bereich Safety: Redundanz
● Schaffung von Fehlerbereichen, die ● Schaffung von Fehlerbereichen, die unabhängig voneinander fehlerhaft sein können: Zustandsredundanz
– Schaffung von Zuständen, die nie eingenommen werden, wenn keine Fehler auftreten
● Schaffung von Fehlerbehebungsroutinen: ● Schaffung von Fehlerbehebungsroutinen: Zustandsübergangsredundanz
– Schaffung von Zustandsübergängen, die nie ausgeführt werden, wenn keine Fehler auftreten
Redundanz im Bereich Security?
● Überall, wo es um funktionale Anforderungen ● Überall, wo es um funktionale Anforderungen geht
– Hochverfügbarkeit
– Integritätschecks
● Für Annahme der unabhängigen Fehler muss individuell argumentiert werdenmuss individuell argumentiert werden
– z.B.: Entweder fallen alle Linux-Rechner aus oder alle Microsoft-Rechner, aber nicht alle gleichzeitig
Zentraler Mechanismus im Bereich Security: Kryptographie
● Verschlüsselung, Hashfunktionen● Verschlüsselung, Hashfunktionen
– Besondere Form der Redundanz (z.T. mit Geheimnissen)
– Kann verwendet werden, um Geheimnisse zu schützen
● Macht ohne einen intelligenten Gegenspieler keinen Sinn
Ähnlichkeiten
● Sowohl in Safety als auch in Security muss ● Sowohl in Safety als auch in Security muss ein System Anforderungen erfüllen, wenn “unangenehme” Ereignisse auftreten
– Fehler/Angriffe
● Um die Anforderungen umzusetzen, muss man sehr genau und vorsichtig vorgehenman sehr genau und vorsichtig vorgehen
● Man muss den Tradeoff zwischen Pessimismus und Kosten lösen
Unterschiede
● Existenz eines intelligenten, strategischenGegenspielersGegenspielers
– Gegenspieler verhält sich optimal, also nichtnotwendigerweise zufällig
– Gegenspieler möchte ggf. Daten ausspähen, hat also imBereich Security mehr Ziele als im Bereich Safety
– Vorfälle sind auch nicht (notwendigerweise) statistischunabhängig
Erzeugt im Bereich Security zwei neue Problemfelder● Erzeugt im Bereich Security zwei neue Problemfelderim Vergleich zu Safety:
– Vertraulichkeitsproblem– Das Coverage-Problem (Mangel an guten Metriken)
Das Vertraulichkeitsproblem
● Welche Daten sind wertvoll für den Angreifer?
● Vertraulichkeitseigenschaften sind nicht gut zusammensetzbar (Komposition)
– Die Komposition zwei sicherer Systeme ist nichtnotwendigerweise Sicher
● Krypto als neues (magisches) WerkzeugKrypto kann fehlererkennende Codes ersetzen– Krypto kann fehlererkennende Codes ersetzen(message digests), aber nicht fehlerkorrigierendeCodes
– Schlechtes Beispiel: CRC in 802.11 standard
Das Coverage-Problem
● Man kann das Verhalten des Gegenspielers ● Man kann das Verhalten des Gegenspielers modellieren, aber man weiss nicht, wie wahrscheinlich das ist
– Coverage = Wahrscheinlichkeit, dass die Annahmen über den Angreifer in der Praxis gelten
– Kein Problem im Bereich Safety
● Lange Debatte über die Frage, ob Angriffe statistischen Regeln unterliegen
Safety und Security
● Größe Ähnlichkeiten bei den Anforderungen● Größe Ähnlichkeiten bei den Anforderungen(Requirements) und Annahmen
– Safety-Anforderungen sind in der Regel auch Security-Anforderungen und umgekehrt
● Große Unterschiede bei den Mechanismen
– Um Safety-Anforderungen umzusetzen braucht – Um Safety-Anforderungen umzusetzen braucht man andere Konzepte als bei Security-Anforderungen und umgekehrt
Abstract
● Der Vortrag stellt (aus persönlicher Sicht) die ● Der Vortrag stellt (aus persönlicher Sicht) die Bereiche „Safety“ (grob übersetzt mit technischer-funktionaler Sicherheit) und „Security“ (Informations- oder IT-Sicherheit) gegenüber und versucht sie inhaltlich (nicht terminologisch) abzugrenzen. Dabei zeigen sich vielfältige Querbeziehungen, die in den sich vielfältige Querbeziehungen, die in den bisher recht getrennten Forschungs-communities genutzt werden können.