Ein Framework zur Integration von Anwendungssicherheit in die Softwareentwicklung (FIASSE)

Hinweis: Dieses Repository ist eine fortlaufende Arbeit. Beiträge sind willkommen!

Überblick

TL;DR: Bitte lesen Sie die DOKUMENTATION. Erkunden Sie die FIASSE-Website. Besuchen Sie die GitHub Discussions, um beizutragen.

Dieses Repository enthält Ressourcen und Materialien für das OWASP Framework zur Integration von Anwendungssicherheit in die Softwareentwicklung (FIASSE). FIASSE (ausgesprochen /feiz/ wie „phase") ist ein herstellerunabhängiges Framework, das einen entwicklerzentrierten, prinzipienbasierten Ansatz für die Entwicklung sicherbarer Software fördert. Es erkennt an, dass Sicherheit ein dynamischer, fortlaufender Prozess ist – wie die Entwicklung selbst. Es führt das Securable Software Engineering Model (SSEM) als gemeinsame Designsprache ein, die etablierte Begriffe der Softwareentwicklung nutzt, um Sicherheit in Softwarearchitektur, Design und Engineering zu integrieren, indem Sicherheit in die Prinzipien eingebettet wird, die den Code selbst formen. Das Framework ermöglicht Entwicklungsteams, widerstandsfähig Rechenwert zu schaffen und dabei die Wahrscheinlichkeit materieller Auswirkungen durch Cyber-Ereignisse über die gesamte Lebensdauer des Codes hinweg zu verringern.

FIASSE ist ein kreationales Framework. Es befasst sich damit, wie Sicherheit in Software implementiert wird, und verbindet Engineering-Entscheidungen direkt mit sicherbaren Ergebnissen. Es ist kein Assurance-Framework, kein Reifegradmodell und kein Ersatz für Kontrollkataloge oder Schwachstellenmetriken. Es ergänzt diese Ansätze und verringert den nachgelagerten Druck auf Assurance und Compliance.

Zweck

Praktische Leitlinien bereitzustellen, die Entwickler befähigen, sicherbare Software zu erstellen, ohne tiefgehende Sicherheitsexpertise zu benötigen, und Sicherheitsfachleute anzuleiten, ihre Sicherheitserfahrung effektiv in die Softwareentwicklung einzubringen. FIASSE erreicht dies durch eine Software-Engineering-Perspektive, wodurch die kognitive Belastung reduziert und die Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams gefördert wird.

Wie unterscheidet es sich?

Während assurance-orientierte Projekte wie die OWASP Top 10 hervorheben, was zu vermeiden ist (eine Blockliste), bietet OWASP FIASSE eine Reihe positiver Attribute und Praktiken, denen zu folgen ist (eine Allowlist). Dieser Ansatz nutzt vorhandene Software-Engineering-Fähigkeiten, um sicherbare Software zu entwickeln, anstatt von Entwicklern zu verlangen, Exploit-Techniken zu erlernen oder eine schwächenzentrierte Denkweise anzunehmen. Der Schwerpunkt liegt darauf, praktisches, sicheres Codieren durch vertraute Engineering-Prinzipien zu ermöglichen.

Durch die klare Definition der praktischen Rolle von Sicherheit innerhalb des Entwicklungsprozesses stellt dieses Framework sicher, dass Geschäftswert effektiv erfasst wird. Die Festlegung expliziter Sicherheitserwartungen, bevor Code geschrieben wird, verringert die Wahrscheinlichkeit, dass Sicherheitsmängel später entdeckt und behoben werden müssen. Eine effektive Einführung sollte bestehende Assurance-Metriken verbessern, den Wechsel von Befunden reduzieren, dauerhaftere Korrekturen hervorbringen und die Behebungszeit verkürzen.

Grundwerte

FIASSE orientiert sich an vier Grundwerten. Jeder drückt eine relative Präferenz aus: Beide Seiten haben Wert, aber wenn Entscheidungen getroffen werden müssen, bevorzugt FIASSE die linke.

• Sicherbare Attribute vor Sicherheitskontrollen: Bevorzugen Sie die Engineering-Qualitäten, die es ermöglichen, ein System zu bauen und verteidigungsfähig zu halten, gegenüber Sicherheitskontrollen, die nachträglich eingefügt werden, um Schwächen auszugleichen.
• Beteiligung vor Bewertung: Bevorzugen Sie strukturierte Zusammenarbeit zwischen Sicherheit und Entwicklung über den gesamten Lebenszyklus hinweg gegenüber einer Bewertung, die nach Abschluss der Arbeit durchgeführt wird.
• Engineering-Grundprinzipien vor Sicherheitsjargon: Bevorzugen Sie die Verankerung in etablierten Software-Engineering-Grundprinzipien gegenüber sicherheitsspezifischem Jargon oder gegnerischen Heuristiken.
• Geschäftswert vor Sicherheitsaktivität: Bevorzugen Sie Sicherheit, die die Wertschöpfung der Organisation aufrechterhält, gegenüber Sicherheit, die als Selbstzweck verfolgt wird.

Schlüsselprinzipien

• Das Paradigma der Absicherbarkeit: Es gibt keinen statischen Zustand „sicher“. Ein System, das heute als sicher erklärt wird, kann morgen verwundbar sein. FIASSE lenkt das Engineering-Ziel von „Ist es sicher?“ hin zu „Ist es so gebaut, dass Sicherheit aufrechterhalten werden kann?“ – durch adaptive Resilienz, evolutionäre Sicherheit und kontinuierliche Verbesserung.
• Resiliente Bereitstellung von Rechenwert: Die primäre Direktive der Softwareentwicklung im geschäftlichen Kontext. Software muss funktionale Anforderungen erfüllen und zugleich die absicherbaren Qualitäten aufrechterhalten, die es ihr ermöglichen, der Veränderung, Belastung und den Angriffen standzuhalten, die auf jede Veränderung folgen.
• Sicherheitsmission: Reduzierung materieller Auswirkungen: Die Mission der Sicherheit ist es, die Wahrscheinlichkeit materieller Auswirkungen eines Cyber-Ereignisses zu reduzieren. Die vollständige Eliminierung von Sicherheitsverletzungen ist kein praktikables Geschäftsziel, daher müssen Sicherheitsstrategien mit Geschäftszielen und Risikobereitschaft übereinstimmen.
• Die Beziehung zwischen Qualität und Sicherheit: Sicherheit kann die Softwarequalität nicht übersteigen. Die Qualitäten, die Software leicht verständlich, veränderbar, testbar und beobachtbar machen, sind dieselben Qualitäten, die es ermöglichen, sie abzusichern. Investitionen in Engineering-Qualität sind Investitionen in Sicherheit.
• Entwicklerzentrierte Sicherheit: Softwareentwickler befähigen, absicherbare Systeme mit vertrauten Software-Engineering-Prinzipien zu bauen, anstatt von ihnen zu verlangen, die Denkweise eines Penetrationstesters zu übernehmen.
• SSEM als gemeinsame Designsprache: Verwendung etablierter Software-Engineering-Begriffe (z. B. Analysierbarkeit, Modifizierbarkeit, Testbarkeit) zur Definition und Diskussion von Sicherheitsattributen. Dies macht Sicherheit für Entwickler zugänglich und gibt Sicherheitsfachleuten eine gemeinsame Grundlage für die Bewertung.
• Ausrichtung der Sicherheit an Entwicklungs- und Geschäftszielen: Sicherheit und Entwicklung sind komplementär, nicht gegnerisch. AppSec beteiligt sich früh im SDLC, insbesondere während der Anforderungserhebung und Feature-Planung, damit Erwartungen explizit sind, bevor Code geschrieben wird.
• Das Transparenzprinzip: Systeme werden so gestaltet, dass autorisierte Parteien den internen Zustand und das Verhalten verstehen können. Strukturiertes Logging, Instrumentierung und Audit-Trails sind in den Code integriert und werden nicht allein durch externe Tooling bereitgestellt.
• Das Prinzip der geringsten Überraschung: Systeme verhalten sich auf eine Weise, die für Benutzer, Entwickler und Administratoren intuitiv und vorhersehbar ist. Vorhersehbarkeit unterstützt die Analyse, reduziert die kognitive Belastung und macht Vertrauensgrenzen klar.
• Anforderungen als erstklassiger Bürger in AppSec: Sicherheitsfunktionen, Bedrohungsszenarien und Sicherheitsakzeptanzkriterien werden über den Anforderungsprozess geliefert. Schwachstellen lassen sich häufig auf eine Erwartung zurückführen, die nie spezifiziert wurde, daher gehört diese Lücke in den Anforderungsprozess.

Engineering-Prinzipien