In der Praxis ist es für Hersteller keine leichte Aufgabe, einen ausgeprägten Sicherheitsgedanken kontinuierlich in komplexe Softwareprojekte zu integrieren. Stephan Neumann, Head of usd HeroLab, und Torsten Schlotmann, Head of PCI Security Services, sprechen in unserer Blogserie über praktikable Ansatzpunkte und Möglichkeiten, die Sicherheit von Software dennoch wirksam zu verbessern.
- Teil 1: Gründe für mehr Sicherheit
- Teil 2: Sicherheit in die Unternehmenskultur verankern
- Teil 3: Anforderungs- und Bedrohungsanalyse
- Teil 4: Statische Codeanalyse
- Teil 5: Dynamische Codeanalyse und Vulnerability Management
Nachdem in Teil 2 das Konzept der Security Champions beschrieben wurde, sprechen unsere Experten in Teil 3 über die Anforderungs- und Bedrohungsanalyse, ihre Vorteile und warum ein Perspektivenwechsel so wichtig sein kann.
Torsten Schlotmann: „Das Thema Sicherheit sollte von Anfang an im Software Development Lifecycle betrachtet und integriert werden – noch bevor die erste Zeile Code geschrieben wird. In der Design-Phase spielt beispielsweise das Threat Modelling, auch Bedrohungsanalyse genannt, eine wichtige Rolle. Es handelt sich dabei um eine konzeptionelle Analysetechnik, die sich bewährt hat, um frühzeitig potenzielle Bedrohungen und Risiken in der Entwicklung zu identifizieren und dementsprechend Maßnahmen abzuleiten. Daraus ergeben sich folgende Vorteile: Ungünstige oder falsche Architekturentscheidungen können von Anfang an vermieden werden. Sicherheitsanforderungen an das System oder die Software können im Vorfeld verstanden werden. Und diese Anforderungen können dann frühzeitig in den Code integriert werden.
Um eine Bedrohungsanalyse erfolgreich umzusetzen, ist ein Asset Management zu Beginn die erste Voraussetzung. Man muss sich fragen: Was sind meine schützenswerten Daten? Wo befinden sich diese in der Software? Und vor allem welche Schutzziele habe ich dafür? Diese können sich hinsichtlich der Vertraulichkeit, Verfügbarkeit oder Integrität stark unterscheiden. Nach der Identifizierung aller schützenswerten Daten, geht es als nächstes unter anderem darum, Ein- und Ausgabeschnittstellen, Vertrauensgrenzen („Trust Boundaries“) sowie die beteiligten Akteure zu ermitteln: Welche Art von User arbeitet mit den Daten und welche Operationen sollen durch diese erfolgen dürfen? Die Beantwortung dieser Frage sollte sowohl den „normalen“ Benutzer als auch Administratoren, andere Systeme und Applikationen sowie potenzielle Angreifer beinhalten. Mit diesen gesammelten Informationen können anschließend Datenflussdiagramme erstellt werden. Diese ermöglichen es, sicherheitsrelevante Datenflüsse zu visualisieren, und helfen, zu verstehen, wie und wo sensitive Daten von der Software verarbeitet werden und was mit diesen geschieht. Durch die systematische Analyse der Diagramme lassen sich mögliche Bedrohungen identifizieren.
Hierbei können definierte Methodiken zur Einordnung bzw. Kategorisierung der Bedrohungen hilfreich sein. Ein Modell, welches ich unseren Kunden dabei empfehle, ist das STRIDE-Modell, welches ursprünglich von Microsoft entwickelt wurde und insgesamt sechs verschiedene Bedrohungskategorien vorgibt:
- Spoofing (Identitätsverschleierung)
- Tampering (Manipulation)
- Repudiation (Verleugnung/Nichtanerkennung)
- Information disclosure (Veröffentlichung von Informationen)
- Denial of service (Ausfall des Dienstes)
- Elevation of privilege (Rechteausweitung)
Hat man sich einen Überblick über die potenziellen Bedrohungen verschafft, geht es im nächsten Schritt darum, die Bedrohungen bzw. ihre entsprechenden Gegenmaßnahmen zu priorisieren. Wir erhalten oft die Frage wie eine solche Bewertung erfolgen soll. Auch hier gibt es viele unterschiedliche Ansätze. Ich empfehle jedoch gerade zu Beginn, dies möglichst simpel zu halten und beispielsweise sowohl Eintrittswahrscheinlichkeit als auch mögliche Auswirkungen in die Kategorien „Niedrig“, „Mittel“, „Hoch“ und „Kritisch“ einzuordnen und so das Risiko zu bestimmen. Diese arbeitet man dann von oben, ausgehend von dem größten potenziellen Risiko, nach unten ab.
Mein abschließender Tipp ist, eine Bedrohungsanalyse nicht nur initial zu Beginn eines Projektes durchzuführen, sondern auch bei Änderungen an der bestehenden Architektur sowie größeren Änderungen und neuen Funktionen innerhalb anstehender Releases. So kann sichergestellt werden, dass gegebenenfalls neu auftretende Risiken identifiziert und entsprechend adressiert werden können bzw. das Bedrohungsmodell stets aktuell gehalten wird.“
Stephan Neumann: „Wie Torsten bereits sagte, stellt man uns oft die Frage, woher man als Entwickler weiß, was alles schiefgehen kann und wo man am besten anfängt. Hier möchte ich noch ergänzen, dass es nicht darum geht, alles perfekt zu machen und jede potenzielle Schwachstelle zu identifizieren - denn das ist nicht möglich. Es geht darum, sich Zeit zu nehmen und die Software aus einer anderen Perspektive zu betrachten. Nämlich aus der eines Angreifers. Dazu habe ich eine schöne Analogie: In der Regel fühlen sich alle zuhause sicher. Doch schließt man sich aus und steht vor verschlossener Tür, muss man kreativ werden und überlegen, wie man wieder hineingelangen kann. Es werden „Schwachstellen“ wie beispielsweise ein offen gelassenes Fenster sichtbar, die ein „Eindringen“ in das Haus ermöglichen. Und genau diesen Perspektivenwechsel empfehle ich jedem, um mögliche Schwachstellen zu entdecken und Maßnahmen ableiten zu können.
Um auf die Frage zurückzukommen, was mögliche Ansatzpunkte für Software Security sein können, würde ich gerne auf die Anforderungsanalyse zu sprechen kommen. Das ist für mich persönlich ein sehr wichtiges Thema, denn als Pentester sehen wir nach der Identifizierung von Schwachstellen ganz häufig, dass dies im Vorfeld nicht geschehen ist. Bei einer Anforderungsanalyse geht man folgendermaßen vor: Zunächst sollten alle funktionalen Anforderungen explizit dokumentiert werden. Beispielsweise möchte ein Kunde, dass seine Nutzer ihre jeweilige Profilseite bearbeiten können. Nun gilt es, diese Anforderungen in einem Security Kontext zu analysieren. An unserem Beispiel würde das bedeuten, dass wir sicherstellen müssen, dass jeder lediglich seine eigene Seite bearbeiten kann. Auch diese Anforderung muss explizit als Anforderung definiert werden, denn sonst kann sie schnell in weiteren Prozessen vergessen werden. Wenn es später zu einer Gegenprüfung der Anforderungen kommt, kann sich vielleicht keiner mehr an den initialen Gedanken erinnern. Deswegen ist es wichtig, neben den funktionalen Zielen auch nicht-funktionale IT-Security-Ziele zu definieren. In diesem Fall würde ich das funktionale Ziel ‚Ein User soll seine Profilseite ändern können‘ und das nicht-funktionale IT-Security-Ziel ‚Ein User sollte ausschließlich seine Profilseite ändern können‘ schriftlich festhalten.
Das heißt zusammenfassend: Nehmen Sie sich die Zeit, erinnern Sie sich an mein Beispiel mit dem Haus, gehen Sie einen Schritt zurück und überlegen Sie, was schiefgehen kann und dokumentieren Sie das entsprechend.“
