A.6 Design
Objective: Sicheres Design ist die Grundlage sicherer Software. Das Adressieren von Sicherheit bei der Planung der Architektur und das methodische Identifizieren spezifischer Bedrohungen ermöglicht die proaktive Implementierung von Sicherheit und vermeidet die aufwendige Beseitigung von Sicherheitslücken im Nachhinein.
Control 6.1: Anwenden von Sicherheitsprinzipien
Es sollten grundsätzlich gängige Anforderungsprinzipien (wie Attack Surface Reduction, Defense in Depth, Least Privilege etc.) genutzt werden. Die zu berücksichtigenden Prinzipien sind schriftlich dokumentiert und allen am Design Beteiligten bekannt.
Control 6.2: Anwendung von Trust-Modellen
Der Zugriff auf Daten sollte grundsätzlich über Trust-Modelle abgebildet werden.
Control 6.3: Threat Modeling
Die spezifischen Bedrohungen für ein System sollten über ein Threat Model ermittelt und klassifiziert werden. Das Threat Model muss bei jeder Änderung der Software auf Vollständigkeit überprüft und ggf. erweitert werden. Dies gilt insbesondere bei agiler Entwicklung.
Control 6.4: Bewertung von Bedrohungen
Den im Threat Model ermittelten Bedrohungen sollte durch angemessene Maßnahmen begegnet werden. Alternativ ist das Akzeptieren von Bedrohungen möglich. Diese Entscheidung ist vom Security Advisor mit dem Management zu treffen und dokumentieren.
Control 6.5: Katalogisieren von Maßnahmen
Umzusetzende Gegenmaßnahmen zu den im Threat Model identifizierten Bedrohungen sollten in den Projektplan aufgenommen und entsprechend dokumentiert bzw. katalogisiert werden.
Control 6.6: Begleitung durch Security-Expertise
Das Threat Modeling sollte durch einen geschulten Sicherheitsfachmann geleitet oder begleitet werden, um sicherzustellen, dass aktuelles Know-how bezüglich möglicher Bedrohungen in das Threat Model einfließt.
Control 6.7: Bedrohungsdatenbank
Die im Threat Model ermittelten Bedrohungen sollten in generischer Form in einer speziellen Datenbank katalogisiert werden, um den Aufbau einer Bedrohungsdatenbank zu ermöglichen.
Control 6.8: Teilnahme am Threat Model
Am Threat Model sollten neben Architekten und Entwicklern auch Projektleiter teilnehmen, um sicherheitsrelevante Informationen in die Entscheider-Ebene zu transportieren.
Control 6.9: Tools
Das Threat Modeling sollte mit geeigneten Tools durchgeführt werden, um eine systematische Bearbeitung aller Bedrohungen sicherzustellen.
Control 6.10: Bedrohungsmodell
Die im Threat Model ermittelten Bedrohungen sollten anhand eines feststehenden Modells kategorisiert werden (z. B. STRIDE; siehe Abschnitt 7.3.2).
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
