Model-based Security Security: ganzheitliche Engineering - - PDF document

model based security
SMART_READER_LITE
LIVE PREVIEW

Model-based Security Security: ganzheitliche Engineering - - PDF document

2 Herausforderung: Security Model-based Security Security: ganzheitliche Engineering Eigenschaft: Jan Jrjens Sicherheits-Mechanismen umgehen statt brechen. Sichere Systems aus Computing Department unsicheren Komponenten ? The


slide-1
SLIDE 1

2 1

Model-based Security Engineering

Jan Jürjens

Computing Department The Open University http://www.umlsec.org

Jan Jürjens, Open University: Model-based Security Engineering 2

Security: ganzheitliche Eigenschaft:

  • Sicherheits-Mechanismen

umgehen statt brechen.

  • Sichere Systems aus

unsicheren Komponenten ?

„Those who think that their problem can be solved by simply applying cryptography don`t understand cryptography and don`t understand their problem“ (B. Lampson / R. Needham).

Herausforderung: Security

Jan Jürjens, Open University: Model-based Security Engineering 3

(UML) Modelle Anforderungen Programm

Ein- fügen Code-/ Testgen. Reverse Engin. Analy- sieren Konfigurationsdaten

Gener. Verif. Konfigur.

Automatisch unterstützte und theoretisch fundierte Security Design & Analyse. Idee: Modelle aus Artefakten in Entwicklung und Gebrauch von Software.

Modellbasiertes Security Engineering

Jan Jürjens, Open University: Model-based Security Engineering 4

Requirements and use cases Abuse cases Security requirements Risk analysis External review Design Test plans Code Test results Field feedback Risk-based Security tests Static analysis (tools) Risk analysis Penetration testing Security breaks

[McGraw 2003]

MBSE vs. Entwicklungsphasen

Model-based Security Engineering

Design: Security Engineering Lösungen als Pattern. Analyse: Automatisch, formal fundierte Werkzeuge. Anm.: Schwerpunkt auf „abstrakten“ Anforderungen

Jan Jürjens, Open University: Model-based Security Engineering 5

UMLsec

Häufige Sicherheits-Anforderungen und Mechanismen und Angreiferszenarien als vordefinierte Markierungen einfügen. Damit verbundene logische Bedingungen verifizieren mit Modell-Checkern und Automatischen Theorembeweisern auf Basis einer formalen Semantik. Stellt sicher, dass UML- Modell die Sicherheits- Anforderungen erfüllt.

[FASE01,UML02, FOSAD05,ICSE05]

Jan Jürjens, Open University: Model-based Security Engineering 6

Beispiel: Kryptobasiertes Verteiltes System

A B Angreifer m(x) Angreifer- Wissen: m(x) return({z}k)

[argb,1,1 = x]

k-1, y, x {z}k, z return({y::x}z)

Angreifer kann …

  • Systemteile kontrollieren,
  • Vorwissen haben,
  • Nachrichten lesen,

löschen, einfügen.

(vgl. [Dolev, Yao 1982])

slide-2
SLIDE 2

2 2

Jan Jürjens, Open University: Model-based Security Engineering 7

Sicherheitsanalyse

Angreiferwissen von oben approximieren: Prädikat knows(E) bedeutet: Angreifer kann E ggf. während Ausführung des Systems lernen. Z.B. für Vertraulichkeit: Für vertrauliche Daten s: überprüfen, ob knows(s) von den vom Modell erzeugten Formeln abgeleitet werden kann.

[ICSE05]

Jan Jürjens, Open University: Model-based Security Engineering 8

Logische Axiome

Definiere knows(E) für jedes E im Vorwissen des Angreifers. Definiere Kryptosystem. Z.B.: DecK-1({E}K)=E Für evolvierendes Angreiferwissen: ∀ E1,E2.(knows(E1)∧ knows(E2) ⇒ knows({E1}E2) ∧ knows(DecE2(E1)) ∧ …)

Jan Jürjens, Open University: Model-based Security Engineering 9

Interaktionen des Angreifers

Protokoll-Interaktion TR1=(in(msg_in),cond(msg_in),out(msg_out)) gefolgt von TR2 gibt Prädikat PRED(TR1)= ∀ msg_in. [knows(msg_in)∧ cond(msg_in) ⇒knows(msg_out) ∧ PRED(TR2)]

Abstraktion (z.B. von Sender, Empfänger) zwecks Effizienz: findet alle hier betrachteten Angreifer, es gibt aber auch false positives. Forall-Quantifizierung über Iterationszähler.

Jan Jürjens, Open University: Model-based Security Engineering 10

Beispiel: TLS Variante

Siehe IEEE Infocom 1999. Ziel: geheime Daten übertragen, mit Sitzungs- schlüssel verschlüsselt.

Jan Jürjens, Open University: Model-based Security Engineering 11

Logische Formeln

knows(N)∧ knows(KC)∧ knows(SignKC-1(C::KC)) ∧ ∀ init1,init2,init3.[knows(init1)∧ knows(init2)∧ knows(init3) ∧ snd(Extinit2(init3)) = init2 ⇒ knows({SignKS-1(…)}…)∧ [knows(Sign…)] ∧ ∀ resp1,resp2. […⇒...]]

Jan Jürjens, Open University: Model-based Security Engineering 12

Analyse

Überprüfen, ob knows(s) ableitbar (z.B. mit e-Setheo). Überraschung: Ja ! Vertraulichkeit von s nicht bewahrt. Warum ? Prolog-basierter Angriffsgenerator.

slide-3
SLIDE 3

2 3

Jan Jürjens, Open University: Model-based Security Engineering 13

Man-in-the-Middle Angriff

Jan Jürjens, Open University: Model-based Security Engineering 14

e-Setheo: Beweis: knows(s) nicht ableitbar. Logik 1. Stufe vollständig (aber auch unentscheidbar).

Korrektur

Jan Jürjens, Open University: Model-based Security Engineering 15

Verfeinerung und Modularität

„Verfeinerungsparadox“: Sicherheits- eigenschaften durch manche Verfeinerungsbegriffe nicht bewahrt. Problem: muss jeweils neu verifizieren. Theorem: Unser Begriff der Verfeinerung (vgl. Broy: Focus) bewahrt unsere Sicherheitsanforderunge. Analog: Sicherheitseigenschaften bewahrt durch Komposition von Komponenten (unter gegebenen Voraussetzungen).

[FME01] [Concur01]

Jan Jürjens, Open University: Model-based Security Engineering 16

Sicherheits-Schichten

Systemebene oben benutzt Sicherheit von unten.

confidentiality, integrity, server authenticity client authenticity confidentiality, … + client authenticity =

?

Sicherheitseigenschaften additiv ? Theorem: Ja, unter gegebenen Voraussetzungen.

[Safecomp03]

Jan Jürjens, Open University: Model-based Security Engineering 17

Analyse: Modell vs. Programm

Modell: + früher (weniger Kosten bei Korrektur) + abstrakter effizienter

  • abstrakter Fokus auf bestimmte Angriffe
  • Programmierer können Schwachstellen

einfügen

  • Codegeneratoren auch (wenn nicht verifiziert)

Programm: + „the real thing“ (das ausgeführt wird) Beides verifizieren (wenn möglich).

Jan Jürjens, Open University: Model-based Security Engineering 18

Erfahrungen

Kann Verhaltensmodelle vom Programm generieren (z.B. CFGs). Problem: zu wenig Abstraktion Verständnis und Verifikation schwierig. Annahme: Textuelle Spezifikation gegeben. Dann:

  • Schnittstellenspezifikation erstellen
  • Sicherheitsanalyse (s.o.)
  • Verifizieren, dass Software

Schnittstellenspezifikation erfüllt.

slide-4
SLIDE 4

2 4

Jan Jürjens, Open University: Model-based Security Engineering 19

Modell vs. Implementierung

Implement- ation Implement- ation

.java

Elements of connections Sent and received data „meaning“ „meaning“

compare meaning! Backtrace assignments Defined during model creation Find Has

Abstract model Equal?

Jan Jürjens, Open University: Model-based Security Engineering 20

p q g

Schnittstellen Spec: SSL

I) Programmpunkte identifizieren: value (r), receive (p), guard (g), send (q) II) Überprüfen dass Bedingungen umgesetzt. r

Jan Jürjens, Open University: Model-based Security Engineering 21

Bedingung g umgesetzt ? a) Runtime Check für g bei q from Diagramm generieren: einfach + effectiv (aber Performanz). b) Testen gegen Checks (aber Verwendung von Krypto). c) Automatische formale lokale Verifikation: Bedingungen zwischen p und q implizieren g (mit automatischem Beweiser).

Bedingungen Prüfen

[ICFEM02] [ASE05,ASE06]

p q g

Jan Jürjens, Open University: Model-based Security Engineering 22

msg = Handshake.read(din, certType); session.trustManager.checkServerTrusted (peerCerts,suite.getAuthType()); msg = new Handshake(Handshake.Type.CLIENT_KEY_EXCHANGE, ckex); msg.write (dout, version); p q g try catch

  • nly possible way

without throwing exception

Jan Jürjens, Open University: Model-based Security Engineering 23

Werk- zeuge

[UML04, FASE05,ICSE06]

Jan Jürjens, Open University: Model-based Security Engineering 24

Anwendungen von MBSE

Designs / Implementierung / Konfiguration für

  • Biometrie-, smart-card

basierte Identifizierung

  • Authentisierung
  • Authorisierung (Benutzerberechti-

gungen, z.B. in SAP Systemen) Analyse von Security Policies.

[ICSE07]

slide-5
SLIDE 5

2 5

Jan Jürjens, Open University: Model-based Security Engineering 25

Common Electronic Purse Specifications

Globaler Standard für eGeldbörsen (Visa et al.). Smart card enthält Kontostand, sichert Transaktionen mithilfe Krypto. Formale Analyse von Load und Purchase Protokollen: signifikante Schwachstellen: Kauf- Umleitung, Betrug Ladegerätbetreiber vs. Bank.

[ASE01]

Jan Jürjens, Open University: Model-based Security Engineering 26 Jan Jürjens, Open University: Model-based Security Engineering 27

Schwachstelle I

mln: „Beweis“ für Bank dass Lade- gerät Geld erhielt. Aber: rn geteilt zwischen Bank und Ladegerät.

Jan Jürjens, Open University: Model-based Security Engineering 28

Schwachstelle II

rcnt: „Beweis“ für LSAM dass Ladegerät nur mn erhalten. Aber: LSAM kann Validität nicht prüfen.

Jan Jürjens, Open University: Model-based Security Engineering 29

Biometrische Authentisierung

Smart card basiertes System. Analysiert parallel zur Entwicklung. Entdeckten drei signifikante Schwachstellen in verschiedenen Versionen (Fehlbedienungszähler umgangen durch löschen / wiederholen von Nachrichten; Smart-card unzureichend authentisiert durch Mischen von Sitzungen).

Jan Jürjens, Open University: Model-based Security Engineering 30

Bankanwendung

Sicherheitsanalyse von webbasierter Bankanwendung (“digitaler Formularschrank”). Geschichtete Architektur (SSL Protokoll, darauf Client Authentisierungs-Protokoll) Anforderungen:

  • Vertraulichkeit
  • Authentisierung
slide-6
SLIDE 6

2 6

Jan Jürjens, Open University: Model-based Security Engineering 31

Einige Verwandte Ansätze

  • UML & Security, z.B.:
  • D. Basin, R. Breu, R.B. France, K. Stoelen, S.

Houmb, E.B. Fernandez, E. Fernandez, F. Parisi- Presicce, M. Koch, D. Haneberg, … (et al. …)

  • Formale Verifikation von Spezifikationen
  • Formale Verifikation von Programmen (T. Nipkow,
  • G. Snelting, …)
  • Kryptoprotokollverifikation auf Programmebene ?
  • Secure Software Engineering im Allgemeinen (z.B.
  • B. Nuseibeh, M. Jackson, K.-P. Löhr, M. Heisel, …)

Jan Jürjens, Open University: Model-based Security Engineering 32 IT Security

Überblick

Jan Jürjens, Open University: Model-based Security Engineering 33

Zusammenfassung

Model-based Security Engineering:

  • Formal basierte Sicherheitsanalyse auf

Design Modellen und Quellcode.

  • Verwendung von Artifakten, die während des

Software Lebenszyklus entstehen.

– UML Modelle – Java Programme – Konfigurationsdaten (Benutzerberechtigungen)

  • Erfolgreiche Anwendungen in Industrie.

Jan Jürjens, Open University: Model-based Security Engineering 34

Acknowledgements

Security Requirements @ Open University: Bashar Nuseibeh, Michael Jackson, Charles Haley, T. Thun, A. Bandara, … IT Security @ Software & Systems Engineering, TUM: Guido Wimmel, Gerhard Popp, Johannes Grünbauer, Jorge Fox, Bo Zhang, Thomas Kuhn, Daniel Ratiu. Alumni: Sebastian Höhn (U Freiburg), Pasha Shabalin (TUM), Gianna Ioshpe (TUM/BMW), Bastian Best (TUM/BMW), Ali Sunyaev (TUM), Peter Bartmann (U Augsburg), … Collaborators: Martin Abadi (UCSC), Ruth Breu (U Innsbruck), Robert France et al. (CSU), Siv Houmb (NTNU), Volkmar Lotz (SAP Research), Bran Selic (IBM-Rational), …

Jan Jürjens, Open University: Model-based Security Engineering 35

Questions ?

More information (papers, slides, tool etc.): http://www.umlsec.org