A Pattern- and Component-Based Method to Develop Secure Software

Transkript

1 A Pattern- and Component-Based Method to Develop Secure Software Holger Universität Duisburg-Essen, Fakultät Ingenieurwissenschaften, Abteilung Informatik und Angewandte Kognitionswissenschaft, Arbeitsgruppe Software Engineering 31. Mai / 19

2 Sichere Systeme System Maschine Hardware Software Daten Feindliche (z. B. Angreifer) kein erfolgreicher Angriff 2/ 19 System = Maschine + (nach Zave und Jackson [ZJ97]) Hier: Sicherheit = Security Sicherheit ist eine Eigenschaft des Systems (und nicht nur der Software). CIA Vertraulichkeit, Integrität, Verfügbarkeit

3 Security Engineering Motivation und Ziel Sicherheit ist ein Qualitätsmerkmal das stark nachgefragt wird durch Stakeholders (z. B. Gesetzgeber, Kunden, Benutzer). wird häufig vernachlässigt und wie eine funktionale Eigenschaft behandelt. Security Engineering = Software Engineering + Security Ziel des Security Engineering Konstruktion von Software, sodass die Maschine vor der geschützt ist. 3/ 19

4 : Security Engineering Process using Patterns Vorgestellt auf SPatterns 2007 [HHS07b], AReS 2008 [HHS08a], ARES 2010 [Sch10b] und in Software Engineering for Secure Systems [SHH11] Umfassende Security Engineering Methodik mit Fokus auf frühe Phasen der Softwareentwicklung Modellierung und Analyse der steht im Mittelpunkt Organisiert als Agenda [Hei98] (3 Phasen, jeweils mehrere Schritte) Verschiedene Typen von Mustern zur Analyse, Spezifikation und Realisierung von Sicherheitsanforderungen 4/ 19

5 Analyse von Sicherheitsanforderungen Entwicklung von Sicherheitsspezifikationen Konstruktion sicherer Softwarearchitekturen 5/ 19

6 Security Problem Frames Vorgestellt auf ETRICS 2006 [HHS06] und AReS 2007 [HHS07a] Security Problem Frames (SPF) basieren auf Problem Frames von Jackson [Jac01]. sind Muster zur Analyse von Sicherheitsproblemen. beschreiben Sicherheitsanforderungen ohne auf Lösungsmechanismen einzugehen. unterstützen eine systematische Beschreibung von Domänenwissen, d. h., Fakten und Annahmen. werden grafisch dargestellt durch Frame Diagramme. beschreiben Sicherheitsanforderungen formal als Effekte. 6/ 19

7 Schritt I.1: Beschreibe Kontextdiagramm Schnittstelle Domäne 7/ Malicious environment Y4, E5 Operating Y Malicious user system B C E3, Y Y E3 = {OpenCommandMU} Maschinendomäne (zu entwickelnde Software) Secure text editor E1, Y2 Text file Author Maschinendomäne soll entwickelt werden Weitere Domänen beschreiben die Verbindungslinien repräsentieren gemeinsame Phänomene Sicherheitsrelevantes Domänenwissen Betriebssystem (Operating system) ermöglicht den Inhalt und die Größe von Dateien herauszufinden. Fakt X B

8 Schritt I.2: Wähle SPF aus und instantiiere SPF Instanz des SPF Confidential Data Storage Malicious environment Malicious user B MU!E6 MUD!C8 STE!E7 Malicious user display D Schnittstelle mit Kontrollrichtung Secure text editor STE!E4 STE!E2 TF!Y3 A!E1 AD!C5 Author display D Text file Author E6 X B C5 C8 Y3 E1 Sicherheits anforderung SR1 8/ 19 Sicherheitsanforderung (SR1) Erhalte die Vertraulichkeit der Textdateien (Text file) der Autoren (Author) abgesehen von der Größe der Textdateien und verhindere den Zugriff durch die feindliche (Malicious environment).

9 Concretized Security Problem Frames Vorgestellt auf ETRICS 2006 [HHS06] und AReS 2007 [HHS07a] Concretized Security Problem Frames (CSPF) beschreiben Ansätze zur Lösung von Sicherheitsproblemen. gibt es für jeden SPF. betrachten konkretisierte Sicherheitsanforderungen basierend auf generischen Sicherheitsmechanismen. beschreiben Anforderungen an die formal als Bedingungen. 9/ 19

10 Schritt I.3: Wähle CSPF aus und instantiiere CSPF Instanz des CSPF Confidential Data Storage Using Password-Based Symmetric Encryption 10/ 19 Passworteingabe E6, E Malicious environment Malicious user MU!E9 Operating system ETF!Y10 Encrypted OS!Y11 text file B C STE!E MU!E ETF!Y Secure MUD!C8 text A!E1 Author editor STE!E STE!E4 AD!C Malicious user Author display display D D Konkretisierte Sicherheitsanforderung (CSR1) Symmetrische Verschlüsselung X B C5 C8 Y11 Y3, Y10 E1 Konkretisierte Sicherheits anforderung Wenn die Bedingungen erfüllt sind, dann wird die Vertraulichkeit der Textdateien (Text file) der Autoren (Author) abgesehen von der Größe der Textdateien gewährleistet und der Zugriff durch die feindliche (Malicious environment) verhindert. CSR1

11 Metamodel und Bedingungen Vorgestellt auf AReS 2007 [HHS07a] und MODELS 2008 [HHS08b] Formales Metamodel für (C) Effekte und Bedingungen sind prädikatenlogische Formeln in Z Notation [Spi01] ausgedrückt basierend auf Metamodel für (C) Bedingung B1 PasswordA, PasswordMU : P Password PasswordA PasswordMU = 11/ 19

12 Mustersystem Vorgestellt auf AReS 2007 [HHS07a] und AReS 2008 [HHS08a] 12/ 19 C = is concretized by (read from column to row) D = depends on (read from row to column) R = is related to (read from row to column) SPF Confidential Data Transmission SPF Confidential Data Storage SPF Integrity-preserving Data Transmission CSPF Confidential Data Transmission Using Cryptographic Key-Based Symmetric Encryption C, D D, R D, R D, R D CSPF Confidential Data Storage Using Password-Based Symmetric Encryption D C D R CSPF Confidential Data Storage Using Access Control D C D, R D D CSPF Confidential Data Storage Using Cryptographic Key-Based Symmetric Encryption D C, D D D, R D CSPF Integrity-Preserving Data Transmission Using Keyed Hash Functions R R C, D R CSPF Integrity-Preserving Data Storage Using Non- Keyed Hash Functions R D C,D CSPF Authentication Using Secrets D D D D C D CSPF Distributing Secrets Using Secure Channels D D, R D D, R R C, D CSPF Distributing Secrets Using Negotiation R D R D C SPF Integrity-preserving Data Storage SPF Authentication SPF Distributing Secrets

13 Schritte I.4 und 5: Überprüfe I Vorgestellt auf ARES 2010 [Sch10b] Sicherheitsrelevantes Domänenwissen Detaillierte Betrachtung der Bedingungen basierend auf Risikound Bedrohungsanalysen zur Entscheidung über Gegenmaßnahmen C = is concretized by (read from column to row) D = depends on (read from row to column) R = is related to (read from row to column) CSPF Confidential Data Storage Using Password-Based Symmetric Encryption SPF Confidential Data Transmission SPF Confidential Data Storage SPF Integrity-preserving Data Transmission SPF Integrity-preserving Data Storage D C D R SPF Authentication SPF Distributing Secrets 13/ 19

14 Schritte I.4 und 5: Überprüfe II Vorgestellt auf ARES 2010 [Sch10b] Bedrohung für B1 Feindliche bestimmt durch Brute Force das korrekte Passwort. Verschlüsselte Textdateien werden so gespeichert, dass öffentlicher Zugriff leicht möglich ist. Fakt nicht tolerierbares Risiko Gegenmaßnahme: Hilfsmechanismus der die Passworteingabe blockiert nachdem eine bestimmte Anzahl falscher Passwörter eingegeben wurde. Risiko tolerierbar 14/ 19

15 Analyse von Sicherheitsanforderungen Entwicklung von Sicherheitsspezifikationen Konstruktion sicherer Softwarearchitekturen 15/ 19

16 Formale Sicherheitsspezifikationen und Vertraulichkeitserhaltende Verfeinerung Vorgestellt auf ESSoS 2009 [Sch09] und Dagstuhl 2009 [Sch10a] (C)SPF Model Templates: Mit der formalen Sprache CSP (Communicating Sequential Processes) [Hoa86] ausgedrückte Muster für (C) Funktionale Verfeinerung zwischen Model Templates verifiziert mit Model-Checker FDR2 [For09] Instanzen von Model Templates zur Spezifikation von probabilistischen und possibilistischen Vertraulichkeitsanforderungen nach Framework von Santen [San08] Verifikation vertraulichkeitserhaltender Verfeinerung 16/ 19 Ziel der vertraulichkeitserhaltenden Verfeinerung Realisiert ein ausgewählter Sicherheitsmechanismus tatsächlich die Sicherheitsanforderung in der gegebenen?

17 Analyse von Sicherheitsanforderungen Entwicklung von Sicherheitsspezifikationen Konstruktion sicherer Softwarearchitekturen 17/ 19

18 Generische Sicherheitskomponenten und Sicherheitsarchitekturen Vorzustellen auf CAiSE 2011 [SJ11] und in SE for Secure Systems [SHH11] Generische Sicherheitskomponenten (GSC) sind Muster für konkrete Sicherheitskomponenten Generische Sicherheitsarchitekturen (GSA) sind Muster zur Strukturierung von Maschinen von bestehen aus generischen Sicherheitskomponenten und weiteren Komponenten GSCs und GSAs werden durch UML Composite Structure Diagramme sowie sowie Schnittstellenspezifikationen als UML Klassendiagramme und Sequenzdiagramme beschrieben 18/ 19

19 und Vorteile von Verknüpfung von Software Engineering und Security Reduktion des Entwicklungsaufwands durch Verwendung von Mustern und Komponenten Verknüpfung von Problemmustern und Lösungsmustern Auffinden initial unbekannter Sicherheitsanforderungen Intensive Einbeziehung der Integration informeller, semi-formaler und formaler Notationen (wichtig für Zertifizierung!) Durchgehend methodische Unterstützung nach Agendenkonzept 19/ 19

20 I [For09] [Hei98] [HHS06] Formal Systems (Europe) Limited. Failures-divergence refinement (FDR2) 2.83, Maritta Heisel. Agendas - a concept to guide software development activities. In Proceedings of the IFIP TC2 WG2.4 working Conference on Systems Implementation: Languages, Methods and Tools, pages Chapman & Hall London, Denis Hatebur, Maritta Heisel, and Holger. Security engineering using problem frames. In G. Müller, editor, Proceedings of the International Conference on Emerging Trends in Information and Communication Security (ETRICS) (LNCS 3995), LNCS 3995, pages Springer, / 19

21 II 21/ 19 [HHS07a] Denis Hatebur, Maritta Heisel, and Holger. A pattern system for security requirements engineering. In Proceedings of the International Conference on Availability, Reliability and Security (AReS), pages IEEE Computer Society, [HHS07b] Denis Hatebur, Maritta Heisel, and Holger. A security engineering process based on patterns. In Proceedings of the International Workshop on Secure Systems Methodologies using Patterns (SPatterns), pages IEEE Computer Society, [HHS08a] Denis Hatebur, Maritta Heisel, and Holger. Analysis and component-based realization of security requirements. In Proceedings of the International Conference on Availability, Reliability and Security (AReS), pages IEEE Computer Society, 2008.

22 III [HHS08b] Denis Hatebur, Maritta Heisel, and Holger. A formal metamodel for problem frames. In Proceedings of the International Conference on Model Driven Engineering Languages and Systems (MODELS) (LNCS 5301), LNCS 5301, pages Springer, [Hoa86] [Jac01] Charles Antony Richard Hoare. Communicating Sequential Processes. Prentice Hall PTR, Michael Jackson. Problem Frames. Analyzing and structuring software development problems. Addison-Wesley, / 19

23 IV 23/ 19 [San08] [Sch09] [Sch10a] Thomas Santen. Preservation of probabilistic information flow under refinement. Information and Computation, 206(2-4): , April Holger. Pattern-based confidentiality-preserving refinement. In Proceedings of the International Symposium on Engineering Secure Software and Systems (ESSoS) (LNCS 5429), LNCS 5429, pages Springer, Holger. Pattern-based refinement of confidentiality requirements. In Jean-Raymond Abrial, Michael Butler, Rajeev Joshi, Elena Troubitsyna, and Jim C. P. Woodcock, editors, Extended Abstracts Collection Refinement Based Methods for the Construction of Dependable Systems, number in Dagstuhl Seminar Proceedings, Dagstuhl, Germany, Schloss Dagstuhl - Leibniz-Zentrum fuer Informatik, Germany.

24 V [Sch10b] [SHH11] Holger. Threat- and risk-analysis during early security requirements engineering. In Proceedings of the International Conference on Availability, Reliability and Security (AReS). IEEE Computer Society, to appear in Holger, Denis Hatebur, and Maritta Heisel. Software Engineering for Secure Systems: Academic and Industrial Perspectives, chapter A Pattern-Based Method to Develop Secure Software, pages IGI Global, / 19

25 VI [SJ11] [Spi01] [ZJ97] Holger and Jan Jürjens. Connecting security requirements analysis and secure design using patterns and UMLsec. In Proceedings of the International Conference on Advanced Information Systems Engineering (CAiSE), Lecture Notes in Computer Science. Springer, to appear in J. M. Spivey. The Z Notation: a reference manual, Pamela Zave and Michael Jackson. Four dark corners of requirements engineering. ACM Transactions on Software Engineering and Methodology, 6(1):1 30, / 19