In der ersten Phase werden Security Problem Frames und Concretized Security Problem Frames verwendet, welche Muster für das Security Requirements Engineering darstellen. Security Problem Frames sind Muster zur Strukturierung, Charakterisierung und Analyse von Problemen, die häufig im Security Engineering auftreten. Concretized Security Problem Frames beinhalten erste Lösungsansätze für Probleme, die durch Security Problem Frames beschrieben sind. Beide Arten von Frames sind in einem Muster-System organisiert, das Abhängigkeiten zwischen den Frames explizit macht. Wir beschreiben Schritt für Schritt, wie das Muster-System verwendet werden kann, um ein gegebenes Security-relevantes Softwareentwicklungsproblem zu analysieren und wie systematisch Lösungsansätze bestimmt werden können. Darüber hinaus präsentieren wir eine formale Grundlage für (Concretized) Security Problem Frames, auf deren Basis Werkzeugunterstützung für SEPP zur Verfügung gestellt wird.

In der zweiten Phase von SEPP wird der Übergang von Security Requirements zu ersten Elementen des Software-Designs im Detail betrachtet. Hier entwickeln wir semi-formale Spezifikationen, welche die Interaktion der Software mit ihrer Einsatzumgebung beschreiben. Weiterhin präsentieren wir formale Muster für diejenigen (Concretized) Security Problem Frames, die sich mit Vertraulichkeitsanforderungen beschäftigen. Die formalen Modelle sind basierend auf der Prozess-Algebra CSP erstellt und dienen dazu, nachzuweisen, dass die Lösungsansätze tatsächlich korrekte Lösungen für die Security-Probleme sind. Darüber hinaus stellen die formalen Modelle der Lösungsansätze eine formale Spezifikation der Software dar.

In der dritten Phase von SEPP werden die zuvor identifizierten und analysierten Security Requirements mit Hilfe von Architekturmustern, die wir Generic Security Architectures nennen, realisiert. Jedem Concretized Security Problem Frame ist eine Generic Security Architecture zugeordnet, welche aus Komponentenmustern besteht. Dabei unterscheiden wir zwischen Generic Security Components und Generic Non-Security Components. Nachdem man für jeden instantiierten Concretized Security Problem Frame eine Generic Security Architecture instantiiert hat, müssen die verschiedenen Unter-Architekturen zusammengesetzt werden, um eine globale Architektur zu erhalten. Schließlich wird diese globale Architektur verfeinert, und das Ergebnis ist ein Software-Produkt, das die zuvor ausführlich analysierten Security Requirements erfüllt und aus vorhandenen und / oder speziell entwickelten Security-Komponenten besteht.

The post A Pattern and Component-Based Method to Develop Secure Software first appeared on Deutscher Wissenschafts-Verlag (DWV).