Sicherheitsanforderungen im Kontext sicherer Softwareentwicklung
Zu Beginn eines Softwareprojekts steht die Anforderungsanalyse. In diesem Kontext ist es von Bedeutung, von Anfang an die Sicherheitsanforderungen (SA) mitzuberücksichtigen. Ein frühes Mitdenken an dieser Stelle kann helfen, spätere kostspielige und aufwendige Nacharbeiten und Änderungen zu verhindern. Sicherheitsanforderungen sind nicht-funktionale (teilweise auch funktionale) Anforderungen, die Sicherheitsziele formalisieren, ohne jedoch vorzugeben, wie diese Ziele erreicht werden sollen.
Eine wichtige Bezugsquelle für SA ist der ISO-15408 Standard, auch „Common Criteria (CC)“ genannt. Der Standard definiert Sicherheitseigenschaften und deren Prüfung von IT-Systemen. Auch gesetzliche Rahmenbedingungen können als Quelle für SA dienen. Sicherheitsanforderungen können durch folgende Prozessschritte erhoben werden:
- Identifikation von Schutzzielen: Im Allgemeinen handelt es sich hierbei um die Ziele Vertraulichkeit, Integrität und Verfügbarkeit. Diese sind sehr pauschal und müssen für den konkreten Anwendungsfall noch spezifiziert werden.
- Funktionale Anforderungen definieren: Zu Beginn der Security Requirements Engineering (SRE) werden zunächst die funktionalen Anforderungen an ein System erhoben. Dieser Schritt wird im Rahmen des „normalen“ Requirements Engineerings durchgeführt. Die funktionalen Anforderungen werden als Grundlage für die weiteren Schritte benötigt.
- Abstraktes (High Level) Architekturdiagramm erstellen: Dieses erweist sich bei der Identifizierung von Misuse Cases als hilfreich. So können Schwachstellen auf Architekturebene leichter erkannt werden. Außerdem wird dadurch das System in seinem Anwendungsbereich bzw. Kontext betrachtet. Dadurch wird die Wahrscheinlichkeit gesenkt, dass einige bedeutende Misuse Cases nicht identifiziert werden.
- Assets und Ressourcen identifizieren und bewerten/gewichten: Damit Schutzmaßnahmen implementiert werden können, muss zunächst klar sein, was in welchem Maße geschützt werden muss. Hierzu werden die schützenswerten Assets identifiziert und priorisiert. Assets können bspw. Nutzerdaten, geheime Konstruktionspläne oder auch der Ruf eines Unternehmens sein.
- Nutzer und Angreifer identifizieren: Durch die Identifikation der rechtmäßigen Nutzer der Software oder des Systems können im weiteren Vorgehen leichter die potenziellen Angreifer verifiziert werden. Hierbei können zum Beispiel für die Nutzer jeweils äquivalente Missbrauchsnutzer identifiziert werden. Dabei wird auch über die potenziellen Interessen und Fähigkeiten der Angreifer nachgedacht.
- Bedrohungen identifizieren/Risikoanalyse: Nachdem die schützenswerten Assets und Angreifer gefunden sind, werden mögliche Angriffe auf diese Güter verifiziert. Dabei spielen das Risiko eines Angriffs und das erwartete Schadensausmaß eine wichtige Rolle bei der Implementierung von Gegenmaßnahmen.
- Misuse Cases: Äquivalent zur Identifikation von Use Cases werden Misuse Cases identifiziert, welche das Verhalten des Systems im Angriffsfall beschreiben. Aus den Misuse Cases lassen sich dann Anforderungen an das System ableiten, deren Erfüllung die Durchführung der Misuse Cases verhindert oder zumindest stark erschwert.
Sichere Softwarearchitektur
Nachdem die Sicherheitsanforderungen erhoben wurden, kann mit der nächsten Phase der sicheren Softwareentwicklung begonnen werden, nämlich mit der Planung des Designs. Da hierbei die zuvor definierten Sicherheitsanforderungen berücksichtigt werden müssen, erfolgt dieser Prozessschritt nach dem Security Requirements Engineering. Überlegungen zur Sicherheit in der Entwurfsphase sind wichtig, da die Wahl eines Architekturansatzes die Erfüllung der Sicherheitsanforderungen erleichtern, aber auch erschweren oder gar verhindern kann. Sicherheitslücken, die aufgrund von fehlerhaftem Design entstehen, können in den seltensten Fällen durch kleinere Programmieränderungen behoben werden. Stattdessen muss das Design geändert werden, was wiederum größere Softwareänderungen nach sich ziehen kann. Wichtige Hilfsmittel für sicheres Design sind Secure Design Patterns und Secure Design Principles.
Secure Design Patterns sind Muster, um häufig wiederkehrende Sicherheitsprobleme auf ähnliche Art zu lösen. Neben Security Patterns gibt es die etwas allgemeineren und abstrakteren Secure Design Principles, die Denkansätze zu sicherer Softwarearchitektur darstellen.
Sicheres Design - Security Pattern: Beispiel
Ein Beispiel für ein Security Pattern ist das "föderierte Identitätsmanagement".
Die Benutzerverwaltung wird in vielen Anwendungen benötigt, um bspw. Berechtigungen zu realisieren. Bei der Realisierung der Benutzerverwaltung ist es empfehlenswert, in Bezug auf die Benutzerverwaltung nicht auf ein selbstentwickeltes Konzept zu bauen. Stattdessen können Identitätsprovider wie Google (“Föderation”) eingebunden werden, sofern keine maßgeschneiderte und individuelle Nutzerverwaltung benötigt wird. Der Fokus kann vollständig auf die Funktionalität gelegt werden, während das Identitätsmanagement ausgelagert wird.
Sicheres Design - Security Principle: Beispiel
Dieses Prinzip fordert die Ausstattung einer Programmfunktionalität mit nur den Rechten, die für die Erledigung der Aufgaben zwingend notwendig sind. So werden die Missbrauchsmöglichkeiten und deren Auswirkungen begrenzt.
Bedrohungsmodellierung
Sobald eine erste, grobe Architekturskizze existiert, kann mit der Bedrohungsmodellierung, im Englischen „Threat Modelling“, gestartet werden. Sie sollte deshalb möglichst früh durchgeführt werden, da die Ergebnisse unter anderem weitere Sicherheitsanforderungen sein können, die bei der Architekturplanung berücksichtigt werden müssen. Dabei handelt es sich nicht um eine scharf abtrennbare Phase. Stattdessen finden sich einzelne Aktionen des Threat Modelling auch in anderen Phasen der sicheren Softwareentwicklung wieder. Das Ziel der Methode ist es, mögliche Angriffsvektoren zu finden, zu gewichten, zu priorisieren und anschließend Gegenmaßnahmen zu identifizieren.
Threat Modelling sollte in einem Team aus Architekten, Entwicklern und Stakeholdern durchgeführt werden, um somit ein gemeinsames Verständnis der schützenswerten Assets und Risiken zu erreichen. Durch Threat Modelling werden die besonders schwerwiegenden und in der Beseitigung kostspieligen Designfehler einer Software aufgedeckt. Die folgende Abbildung zeigt die einzelnen Phasen der Bedrohungsmodellierung.
