A06:2025 Unsicheres Design

Hintergrund.

Unsicheres Design rutscht zwei Plätze von #4 auf #6 im Ranking ab, da A02:2025-Sicherheitsrelevante Fehlkonfiguration und A03:2025-Schwachstellen in der Software-Lieferkette es überholt haben. Diese Kategorie wurde 2021 eingeführt, und wir haben beachtliche Verbesserungen in der Branche im Zusammenhang mit Bedrohungsmodellierung und einer stärkeren Gewichtung auf sicheres Design beobachtet. Diese Kategorie konzentriert sich auf Risiken im Zusammenhang mit Design- und Architekturfehlern, mit einem Aufruf zu häufigerem Gebrauch von Bedrohungsmodellierung, sicheren Designmustern und Referenzarchitekturen. Dies umfasst Fehler in der Geschäftslogik einer Anwendung, z. B. das Fehlen der Definition unerwünschter oder unerwarteter Zustandsänderungen innerhalb einer Anwendung. Als Community müssen wir über “Shift-Left” im Coding-Bereich hinausgehen und uns auf Aktivitäten vor dem Coding konzentrieren, wie das Verfassen von Anforderungen und das Anwendungsdesign, die für die Prinzipien von Secure by Design entscheidend sind (siehe z. B. Aufbau eines modernen Programms zur Anwendungssicherheit)

Punktetabelle.

Zugeordnete CWEs	Max. Häufigkeit	Durchschn. Häufigkeit	Max. Abdeckung	Durchschn. Abdeckung	Durchschn. gewichtete Ausnutzbarkeit	Durchschn. gewichtete Auswirkung	Gesamtanzahl	Summe CVEs
39	22.18%	1.86%	88.76%	35.18%	6.96	4.05	729,882	7,647

Beschreibung.

Unsicheres Design ist eine umfassende Kategorie, die verschiedene Schwachstellen umfasst und als „fehlendes oder ineffektives Design von Schutzmechanismen” beschrieben wird. Unsicheres Anwendungsdesign ist nicht die Ursache für alle anderen Top-10-Risikokategorien. Es gilt zu beachten, dass es einen Unterschied zwischen unsicherem Design und unsicherer Implementierung gibt. Designfehler und Implementierungsfehler unterscheiden sich aus gutem Grund, da sie unterschiedliche Ursachen haben, zu unterschiedlichen Zeitpunkten im Entwicklungsprozess stattfinden und unterschiedliche Abhilfemaßnahmen erfordern. Ein sicheres Design kann immer noch Implementierungsfehler enthalten, die zu ausnutzbaren Schwachstellen führen. Ein unsicheres Design lässt sich nicht durch eine perfekte Implementierung beheben, da die notwendigen Sicherheitskontrollen von vornherein nicht zur Abwehr bestimmter Angriffe vorgesehen waren. Ein Faktor, der zu einem unsicheren Design beiträgt, ist das Fehlen eines Geschäftsrisikoprofils, das der entwickelten Software oder dem System zugrunde liegt, was dazu führt, dass das erforderliche Maß an Sicherheitsdesign nicht bestimmt wird.

Anforderungs- und Ressourcenmanagement

Legen Sie zusammen mit den Geschäftseinheiten die fachlichen Anforderungen an die Anwendung fest, einschließlich des Schutzbedarfs hinsichtlich Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität aller Datenbestände, sowie die vorgesehene Geschäftslogik. Berücksichtigen Sie, wie exponiert Ihre Anwendung sein wird und ob sie eine Mandantentrennung benötigt (zusätzlich zu der, die für die Zugriffskontrolle notwendig ist). Stellen Sie die technischen Anforderungen zusammen, einschließlich funktionaler und nicht funktionaler Sicherheitsanforderungen. Planen Sie das Budget für alle Design-, Entwicklungs-, Test- und Betriebsaktivitäten, unter Berücksichtigung der Sicherheit.

Sicheres Design

Sicheres Design ist sowohl eine Denkweise als auch eine Vorgehensweise, die kontinuierlich Bedrohungen analysiert und sicherstellt, dass der Code robust entwickelt und getestet wird, um bekannte Angriffsmethoden zu verhindern. Die Bedrohungsmodellierung sollte in Backlog Refinement Terminen oder vergleichbaren Aktivitäten integriert werden. Dabei sollten Änderungen im Datenfluss, in der Zugriffskontrolle und anderen Sicherheitsmaßnahmen überprüft werden. Bestimmen Sie in der Story-Entwicklung den korrekten Ablauf und die Fehlerzustände, stellen Sie sicher, dass diese von den verantwortlichen und betroffenen Parteien gut verstanden und vereinbart werden. Analysieren Sie Annahmen und Bedingungen für erwartete sowie fehlgeschlagene Prozesse, um sicherzustellen, dass diese angemessen und die erwünschten sind. Bestimmen Sie, wie Annahmen überprüft und Bedingungen erzwungen werden können, die für das korrekte Verhalten erforderlich sind. Stellen Sie sicher, dass die Ergebnisse in der Story dokumentiert sind. Lernen Sie aus Fehlern und bieten Sie positive Anreize, um kontinuierliche Verbesserungen voranzutreiben. Sicheres Design ist weder ein Add-on noch ein Werkzeug, das Sie einer Anwendung hinzufügen können.

Sicherer Entwicklungslebenszyklus

Sichere Software erfordert einen sicheren Entwicklungslebenszyklus, ein sicheres Designmuster, eine Paved-Road-Methodik, eine sichere Komponentenbibliothek, geeignete Werkzeuge, Bedrohungsmodellierung und Incident-Post-Mortems, die zur Verbesserung des Prozesses genutzt werden. Kontaktieren Sie Ihre Sicherheitsspezialist:innen zu Beginn eines Softwareprojekts, während des gesamten Projekts und für die laufende Softwarewartung. Erwägen Sie die Nutzung des OWASP Software Assurance Maturity Model (SAMM), um Ihre Bemühungen zur sicheren Softwareentwicklung zu strukturieren.

Oft wird die Eigenverantwortung von Entwickler:innen nicht ausreichend gewürdigt. Fördern Sie eine Kultur des Bewusstseins, der Verantwortung und der proaktiven Risikominderung. Regelmäßiger Austausch über Sicherheit (z. B. während Bedrohungsmodellierungs-Sitzungen) kann eine Denkweise erzeugen, die Sicherheit in alle wichtigen Designentscheidungen einbezieht.

Prävention und Gegenmaßnahmen.

Entwickeln und nutzen Sie einen sicheren Entwicklungslebenszyklus mit Unterstützung durch AppSec-Expert:innen bei der Bewertung und Gestaltung von Sicherheits- und Datenschutzkontrollen.
Erstellen und verwenden Sie eine Bibliothek mit sicheren Entwurfsmustern und bewährten, erprobten Komponenten.
Verwenden Sie Bedrohungsmodellierung für kritische Bereiche wie Authentifizierung, Zugriffskontrolle, Geschäftslogik und wichtige Abläufe.
Verwenden Sie Bedrohungsmodellierung als Schulungswerkzeug, um ein Sicherheitsbewusstsein zu schaffen
Integrieren Sie Sicherheitsvorgaben und -kontrollen in den User Stories.
Implementieren Sie Plausibilitätsprüfungen auf allen Ebenen Ihrer Anwendung, vom Frontend bis zum Backend.
Schreiben Sie Unit- und Integrationstests, um zu validieren, dass alle kritischen Abläufe resistent gegen das Bedrohungsmodell sind. Stellen Sie Anwendungs- und Missbrauchsfälle für jede Ebene Ihrer Anwendung zusammen.
Trennen Sie die Ebenen basierend auf Gefährdungs- und Schutzbedarf auf System- und Netzwerkebene.
Stellen Sie sicher, dass die Trennung der Mandanten konsequent auf allen Ebenen erfolgt.

Beispielhafte Angriffsszenarien.

Szenario Nr. 1: Ein Workflow zur Wiederherstellung von Zugangsdaten kann „Fragen und Antworten” enthalten, was jedoch gemäß NIST 800-63b, dem OWASP ASVS und den OWASP Top 10 nicht zulässig ist. Fragen und Antworten können nicht als vertrauenswürdiger Identitätsnachweis betrachtet werden, als mehr als eine Person die Antworten kennen kann. Diese Funktionalität sollte entfernt und durch ein sichereres Design ersetzt werden.

Szenario Nr. 2: Eine Kinokette bietet Gruppenbuchungsrabatte an und verlangt erst bei mehr als fünfzehn Besucher:innen eine Anzahlung. Angreifer:innen könnten dieses System ausnutzen und testen, ob sie einen Angriffsvektor in der Geschäftslogik der Anwendung finden könne, z. B. indem sie versuchen, mit wenigen Anfragen sechshundert Sitzplätze in allen Kinos gleichzeitig zu reservieren, was zu erheblichen Einnahmeverlusten führen könnte.

Szenario Nr. 3: Die E-Commerce-Website einer Einzelhandelskette ist nicht vor Bots geschützt, die von Scalpern betrieben werden, die High-End-Grafikkarten kaufen, um sie auf Auktionsplattformen weiterzuverkaufen. Dies sorgt für schreckliche Publicity bei den Grafikkartenherstellern und Besitzer:innen von Einzelhandelsketten und sorgt für anhaltende Frustration bei Enthusiast:innen, die diese Karten nicht erwerben können. Sorgfältiges Anti-Bot-Design sowie Automatismen, die z. B. Käufe ablehnen, die innerhalb weniger Sekunden nach Verfügbarkeit getätigt werden, können helfen, unechte Käufe zu identifizieren und solche Transaktionen zu verhindern.