Sichere Software entwickeln mit OWASP SAMM
Sicherheit ist im gesamten Entwicklungsprozess wichtig, und OWASP SAMM bietet ein flexibles Rahmenwerk zur Umsetzung.
- Thomas Kerbl
Sicherheitsaktivitäten in den Softwareentwicklungsprozess einzuführen, ist eine interessante Aufgabe. Um erfolgreich zu sein, ist eine enge Integration mit bestehenden Prozessen unabdingbar, um die neuen Aufgaben reibungsfrei in die erprobten Abläufe einzubetten. Darüber hinaus sollten Teams die Angemessenheit der hinzukommenden Aktivitäten im Blick behalten, damit sie nicht über das Ziel hinausschießen. Nur auf die Weise können sie langfristig Sicherheit im gesamten Entwicklungsprozess berücksichtigen und somit resiliente Produkte erzeugen.
Das Open Web Application Security Project (OWASP) hat hierfür mit dem Software Assurance Maturity Model (OWASP SAMM) ein wertvolles Rahmenwerk geschaffen. Damit können Unternehmen nicht nur den Reifegrad ihrer Softwareentwicklungsprozesse hinsichtlich Security messen, sondern sie iterativ verbessern.
Ein Modell für den Reifegrad
Die derzeit aktuelle Version OWASP SAMM v2 definiert insgesamt 30 Security-Aktivitäten für die Kernbereiche Governance, Design, Implementierung, Verification und Operations. Basierend auf einem detaillierten Fragenkatalog können Unternehmen damit ihren individuellen Reifegrad nicht nur pro Einzelaktivität, sondern auch aggregiert auf die jeweiligen Bereiche sowie den gesamten Entwicklungsprozess ermitteln.
Ein Reifegrad von 0 zeigt an, dass noch keine Sicherheitsaktivitäten implementiert sind. Wer den höchsten Reifegrad 3 erreicht hat, hat alle von OWASP SAMM definierten Vorgaben vollständig umgesetzt. Das ist jedoch in der Regel nur für die Entwicklung von Anwendungen wirtschaftlich sinnvoll, die einen hohen Schutzbedarf aufweisen. Ein Reifegrad von 2 erscheint für Anwendungen mit normalem Schutzbedarf in den meisten Bereichen angemessen.
Zusätzlich zur Bewertung der Ist-Situation lässt sich eine Auswertung der Reifegradeentwicklung über die Zeit darstellen, die eine Visualisierung des Projektfortschritts und einen Abgleich mit den angestrebten Meilensteinen ermöglicht. Das Reifegradmodell ist agnostisch in Bezug auf Techniken und Entwicklungsmethodik, eine Affinität zu agilen Entwicklungsmethoden und DevOps-Prozessen lässt sich in der aktuellen Version jedoch nicht leugnen. Das ist aber kein Problem, wenn es darum geht, klassische Entwicklungsmethoden mit OWASP SAMM zu bewerten und zu verbessern.
Die folgenden Abschnitte stellen die fünf Kernbereiche von OWASP SAMM vor und beleuchten die jeweiligen Schwerpunkte.
Governance – das Cockpit
Sichere Software entsteht nicht durch Zufall. Es bedarf einer zentralen Steuerung, die nicht nur ein ganzheitliches Konzept vorgibt, sondern dessen erfolgreiche Umsetzung kontinuierlich misst und im Bedarfsfall adaptiert.
Mit gut gewählte Metriken und Leistungskennzahlen (Key Performance Indicators, KPIs) erkennen Teams zeitnah, ob sie die angestrebten Fortschritte erreicht haben und in welchen Bereichen ein steuernder Eingriff erforderlich ist. Ein wesentlicher Erfolgsfaktor ist, dabei nicht mit Gewalt alles zu messen, sondern vorab die wichtigsten Bereiche zu identifizieren und die wirklich bedeutenden Kennzahlen für die aktuelle Zielsetzung zu erheben.
Zusätzlich deckt OWASP SAMM die Themen Policy und Compliance in Bezug auf Governance ab. Dabei geht es nicht nur darum, den eigenen Compliance-Status zu kennen, sondern projektübergreifende Anforderungen zu definieren, um das Einhalten von Vorgaben und rechtlichen Auflagen sicherzustellen. Wichtig ist, nicht nur die eigene Entwicklung im Auge zu behalten, sondern auch die Zulieferer von Third-Party-Komponenten einzubeziehen.
Um sichere Software zu entwickeln, ist ein hohes Maß an Expertenwissen in unterschiedlichen Disziplinen erforderlich, da sonst die besten Prozesse zum Scheitern verurteilt sind. Gut ausgebildete und aus eigenem Antrieb motivierte Mitarbeiter sind Schlüsselfaktoren für ein erfolgreiches Security-Programm. Insbesondere die Rolle der üblicherweise aus dem Entwicklerteam ernannten Security-Champions ist essenziell: Sie zeichnen sich nicht nur durch ihr Interesse und Wissen im Security-Bereich aus, sondern sind darüber hinaus kommunikativ und tragen aktiv zu einer positiven Security-Kultur bei. Sie sind Ansprechpartner bei alltäglichen Security-Fragen und bei komplexen Entscheidungen eingebunden.
Design – Grundstein für Resilienz
Die Sicherheitsaktivitäten in der Designphase hängen stark voneinander ab und bereichern sich gegenseitig. Konkret geht es dabei um die Definition von Sicherheitsanforderungen, das Erstellung einer Security-Architektur sowie das Durchführen einer Bedrohungsmodellierung.
In der Praxis empfiehlt es sich, mit der Definition der Sicherheitsanforderungen zu beginnen. Neben den technischen Security-Anforderungen gilt es dabei, Compliance- sowie branchenspezifische und auf der implementierten Business-Logik basierten Sicherheitsanforderungen zu erheben und zu dokumentieren. Die Summe dieser Vorgaben legt den Grundstein für viele der weiteren Aktivitäten.
Nach dem Entwurf der Sicherheitsanforderung ist das Architekturteam am Zug. Die Anforderungen beschreiben, was und die Security-Architektur, wie es zu tun ist. Dabei fällen Teams grundsätzliche Technologieentscheidungen und entwerfen Architekturmuster, die den Sicherheitsanforderungen gerecht werden.
Auf Basis der Gesamtarchitektur lässt sich eine Bedrohungsmodellierung mit unterschiedlichen Ansätzen durchführen. Ziel ist dabei immer herauszufinden, welche konkreten Bedrohungen auf die zu entwickelnde Anwendung wirken und ob eine angemessene Behandlung erfolgt. Analysten ziehen dazu unter anderem Techniken zum Bestimmen der exponierten Angriffsfläche, Datenflussanalysen (Data at Rest und Data in Transit) sowie die bereits definierten Security-Mechanismen in Betracht. Das Ergebnis enthält in der Regel eine Liste möglicher Bedrohungen, die nach bestimmten Kriterien, wie Eintrittswahrscheinlichkeit und Auswirkung, klassifiziert sind. Basierend auf den Ergebnissen können die Verantwortlichen entscheiden, welche Risiken sie tragen und welche sie gezielt adressieren müssen.
Die Konferenz zur sicheren Softwareentwicklung heise devSec findet dieses Jahr als Online-Veranstaltung statt. Am 21. und 22. Oktober bietet sie insgesamt 24 Vorträge und zwei Keynotes in zwei parallelen Videostreams.
Der Autor dieses Artikels berichtet auf der heise devSec in seinem Vortrag "Sichere Software agil entwickeln mit OWASP SAMM 2.0" von seinen langjährigen Erfahrungen mit dem Software Assurance Maturity Model von OWASP.
Sofern die Risikolage nicht akzeptabel ist, beginnt an dieser Stelle ein neuer Design-Zyklus. Teams müssen basierend auf den Erkenntnissen Anforderungen ändern oder ergänzen. Auf jeden Fall muss das Architekturteam nochmals ans Reißbrett treten, um Maßnahmen gegen die nicht akzeptierten Risiken zu entwerfen. Anschließend folgt ein Update der Bedrohungsanalyse und im besten Falle verbleiben anschließend nur noch Risiken, die das Management akzeptieren kann. Sobald dieser Punkt erreicht ist, kann die Implementierung beginnen.
