Beyond One-Shot Security: Keeping Software Secure during Evolution

Save this PDF as:

WORD PNG TXT JPG

Größe: px

Ab Seite anzeigen:

Download "Beyond One-Shot Security: Keeping Software Secure during Evolution"

Christina Schmitt
vor 2 Jahren
Abrufe

Transkript

1 Beyond One-Shot Security: Keeping Software Secure during Evolution Jan Jürjens TU Dortmund

2 Was ist Softwareevolution? Software heute oft sehr langlebig (vgl. Jahr-2000-Fehler). Nutzt sich nicht ab. Aber: Software fortlaufend Änderungen unterworfen: Änderungen der Anforderungen Änderungen der Softwareumgebung Fehlerkorrektur Softwareevolution Jan Jürjens Einführung: Evolution Modellbasierte Sicherheit 2/18

3 Wie können wir dieses Problem lösen? Ziel: Sicherheitszertifizierung mit Evolution integriert: QS-Resultate soweit möglich wiederverwenden. Unter welchen Bedingungen Anforderungen bewahrt? Nur erneut überprüfen, wenn Bedingungen nicht erfüllt. Und nur Software-Teile, für die notwendig. Analyse auf Modellebene vor Ausführung der Evolution. Jan Jürjens Einführung: Evolution Modellbasierte Sicherheit 3/18

4 Grundlage: Modellbasierte Sicherheitszertifizierung Anforderungen Modelle Statische Analyse Implementierung Generieren Verifizieren Ausführen Evolution Konfiguration Einfügen Testgenerierung Verifizieren Konfigurieren Laufzeitsystem Jan Jürjens Einführung: Evolution Modellbasierte Sicherheit 4/18

5 Beispielanforderung: Sicherer Informationsfluss Beispiel sicherer Informationsfluss : Kein Informationsfluss von vertraulich zu nicht-vertraulich (insbes. indirekt oder partiell!). Analyse: Systemzustände unterscheiden sich nur in vertraulichen Variablen Auswirkungen auf nicht-vertrauliche Variablen nicht unterscheidbar Beispiel: Web-basiertes Kundenkonto. Sicher? [money+x>=1000] [money+x<1000] Jan Jürjens Einführung: Evolution Modellbasierte Sicherheit 5/18

6 Beispiel: Sicherer Informationsfluss Unsicher: vertrauliches Attribut money beeinflusst Rückgabewert der nicht-vertraulichen Methode rx(). [money+x>=1000] [money+x<1000] Wie kann man diese Anforderung automatisch und in Gegenwart von Evolution verifizieren? Jan Jürjens Einführung: Evolution Modellbasierte Sicherheit 6/18

7 Evolution vs. Design- / Architekturprinzipien: Wann Anforderungen bewahrt? Verfeinerung: Ansatz entwickelt, der Sicherheit bewahrt. Bedingungen für Bewahrung von Sicherheit bei Refactoring: Eclipse Refactoring Scripts Einsatz von Design Patterns: Gang of Four Patterns Modularisierung: Schichtung von Architekturebenen Komponenten-orientierte Architekturen Service-orientierte Architekturen Aspekt-orientierte Entwicklung Experimente: in 57% des Codes relevant. [Felderer, Katt, Kalb, Jürjens et al.: Evolution of Security Engineering Artifacts. International Journal of Secure Software Engineering (IJSSE), 2014 Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 7/18

8 Evolutions-basierte Rezertifizierung Erstmalige Analyse: Registrieren, welche Modellelemente relevant. Teilresultate in Modell speichern ( proof-carrying models ). Differenz: altes zu neues Modell berechnen (z.b. mit SiDiff [Kelter]). Nur die Modellteile reverifizieren, die 1) in der initialen Analyse relevant, 2) geändert wurden, sodass 3) o.g. Bedingungen nicht erfüllt. Erheblich weniger Aufwand als komplette Reverifikation. [Wenzel, Warzecha, Jürjens, Ochoa. Specifying Model Changes with UMLchange to Support Security Verification of Potential Evolution. Journal of Computer Standards & Interfaces, 2014] Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 8/18

9 Nachverfolgbarkeit Anforderungen vs. Implementierung bei Evolution Ziel: Nachverfolgbarkeit von Anforderungen vs. Implementierung bei Evolution. Lösung: Änderungen reduzieren auf: Hinzufügen / Entfernen von Systemteilen. Grundlegende Refactoring- Operationen. Automatische Nachverfolgbarkeit der Änderungen zwischen Modell und Implementierung mit Refactoring Scripts (Eclipse). Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 9/18

Sicherheitsanalyse auf Implementierungs-Ebene Sicherheitsschwachstelle in OpenSSL: (CVE-2008-5077, 7.1.2009, http://www.openssl.org/news/vulnerabilities.

10 Sicherheitsanalyse auf Implementierungs-Ebene Sicherheitsschwachstelle in OpenSSL: (CVE , , ) Several functions inside OpenSSL incorrectly checked the result after calling the EVP_VerifyFinal function, allowing a malformed signature to be treated as a good signature rather than as an error. Feb/März 2014: goto fail -Schwachstellen in iphone, GnuTLS Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 10/18 10

11 Sicherheitsanalyse mittels symbolischer Ausführung Übersetzung von C in symbolisches Modell für Sicherheitsanalyse. Beispiel-Nachricht: C-Code: Modell nach symbolischer Ausführung: Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 11/18 11

12 Evolutions-basierte Verifikation auf Implementierungs-Ebene Automatische statische Analyse der Implementierung gegenüber Modell (z.b. Bedingungen in Sequenzdiagramm korrekt in Implementierung umgesetzt). Projekt Csec mit Microsoft Research Cambridge: Werkzeug erfolgreich eingesetzt, mehrere Schwachstellen gefunden. Evolutions-basierte Verifikation mittels Nachverfolgbarkeit. p g Einziger Pfad von p nach q geht durch g. q [Dupressoir, Gordon, Jürjens, Naumann: Guiding a General-Purpose C Verifier to Prove Cryptographic Protocols. Journal of Computer Security 2014] g Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 12/18 p q 12

13 Evolutions-basierte Laufzeitverifikation Quellcode nicht verfügbar Laufzeitüberwachung. Möglicher Ansatz für Monitoring: Security Automata [F.B. Schneider 2000]. Problem: keine Evolution; nur Safety -Eigenschaften. Neuer Ansatz auf Basis von Runtime-Verification 1. Sicherheitsanforderung in LTL. Generierung von Monitoren; Evolution: automatische Anpassung. Auch Nicht-Safety-Eigenschaften (3-wertige LTL-Semantik). Runtime verification in a nutshell System Property Monitor Actions automatic generation of Property fulfilled? t 1 Havelund, Grosu 2002 Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 13/18

Für Monitoring: 3-wertige LTL-Semantik Ziel beim Monitoring: So früh wie möglich feststellen, dass Anforderung verletzt werden wird. Verwende 3-wertige Semantik.

14 Für Monitoring: 3-wertige LTL-Semantik Ziel beim Monitoring: So früh wie möglich feststellen, dass Anforderung verletzt werden wird. Verwende 3-wertige Semantik. Endlicher Zustandsautomat, um minimale Präfixe für unsicheren Zustand zu finden. Auch Nicht-Safety- Eigenschaften: Boolesche Kombinationen aus Safety und Co-Safety. false inconclusive i 0 j 1... k true l true inconclusive Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 14/18

15 Beispiel-Anforderung: Server Finished Server schickt Nachricht Finished nicht (Ereignis finished ), bevor Nachricht Finished vom Client erhalten und enthaltener MD5- Wert gleich MD5 auf Seiten des Servers (Ereignis equal ). Dann wird sie herausgeschickt. Formalisiert in LTL: φ 2 = ( finished W equal F equal F finished ) (F phi: eventually phi ; phi1 W phi2: phi1 weak-until phi2 ) Keine Safety-Eigenschaft (d.h. nicht mit Schneider s Security Automata). Erzeugter Monitor: Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 15/18

16 Validierung: Anwendungen Verschiedene Versionen der Java-Bibliothek Java Secure Sockets Extension (JSSE) ; open-source Re-Implementierung (Jessie). Mehrere Schwachstellen identifiziert. Auch größere Evolution (Re-Implementierung)! Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 16/18 16

17 Validierung: Ergebnisse Korrektheit: mittels formaler Semantik Vollständigkeit: jede Systemänderung reduzierbar auf Folge von Löschen, Ändern und Hinzufügen von Systemelementen Performanzgewinn am größten, wenn Differenz << Software. Beispiel-Resultat: Komplette Re-Verifikation: Laufzeit exponentiell in Softwaregröße Evolutions-basierte Verifikation: Laufzeit linear in Softwaregröße (jeweils gleichbleibende Differenzgröße). Ist erfüllt: Wartung stabiler Software-Versionen änderungsbegleitende QS (nightly builds) Zusatzaufwand: ca. 2,3-fach kompensiert. Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 17/18

Zusammenfassung: Sicherheitszertifizierung bei Systemänderungen Evolution: Herausforderung für Zertifizierung. Lösung: Integration Zertifizierung mit Evolution.

Damit Evolutions-basierte Re-Zertifizierung: Modellanalyse Statische Code-Analyse / Run-time Verification. Erhebliche Performanzverbesserung.

18 Zusammenfassung: Sicherheitszertifizierung bei Systemänderungen Evolution: Herausforderung für Zertifizierung. Lösung: Integration Zertifizierung mit Evolution. Resultate: Bewahrung von Anforderungen bei Design-/Architektur-Prinzipien (Verfeinerung, Refactoring, Design Patterns, Modularisierung). Damit Evolutions-basierte Re-Zertifizierung: Modellanalyse Statische Code-Analyse / Run-time Verification. Erhebliche Performanzverbesserung. Validierung: Erfolgreicher Einsatz in der Praxis. Aktuell: SPP Design 4 Future Kooperation mit: J. Bürger, T. Ruhroth, J. Zweihoff (TUD), S. Gärtner, K. Schneider (Univ. Hannover) Jan Jürjens Sichere Evolution: Ansatz Resultate Validierung 18/18

Ähnliche Dokumente

Evolution vs. semantische Konsistenz

Evolution vs. semantische Konsistenz Workshop des GI-AK Traceability, Dortmund J. Jürjens Das Forschungsprojekt ClouDAT (Förderkennzeichen 300267102) wird/wurde durch das Land NRW und Europäischen Fonds