Safety versus SecurityGegenüberstellung und Einordnung

Felix Freiling

25.6.2010Vortrag bei Siemens, München

Gute Nachrichten zuerst

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

Persönliche Sichtweise ...

San Francisco, 24. Juni 2003

San Francisco, 24. Juni 2003

Keine Terminologie ...

GI-Arbeitskreis Begriffsbildung aktiv seit 2003

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, ...

STS51 Space Shuttle Discovery, Quelle: http://spaceflight.nasa.gov/

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

Ergebnis vorweg ...

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

Zu den Anforderungen ...

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 ...

28

Hardware Keylogger

29Quelle: http://hardware.keylogger.pl/

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

Zu den Annahmen ...

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

Zu den Mechanismen ...

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

Zusammenfassung

Ä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

Ergebnis

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.