PUR

Sichere Software entwickeln mit OWASP SAMM

Sicherheit ist im gesamten Entwicklungsprozess wichtig, und OWASP SAMM bietet ein flexibles Rahmenwerk zur Umsetzung.

Von 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.

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.

Implementierung – das richtige Werkzeug

Wenn es in die Implementierungsphase geht, denken viele zuerst an Secure Coding. Letzteres dürfen Teams zwar nicht vernachlässigen, aber OWASP SAMM legt ein Hauptaugenmerk auf den Einsatz von Werkzeugen, um Security in den Build- und Deployment-Prozess zu integrieren.

Das Automatisieren von Security-Checks in der Build-Pipeline bietet einen Basisschutz, um bestimmte Schwachstellenklassen frühzeitig zu erkennen. Des Weiteren empfiehlt OWASP SAMM Automatismen, die eingebundene externe Bibliotheken und Frameworks hinsichtlich bekannter Schwachstellen überprüfen. Wer sie automatisiert beim Implementieren erkennt, kann sie noch vor der eigentlichen Verifikationsphase beheben. Das erspart dem Security-Testteam Zeit, um sich auf die komplexeren Schwachstellenklassen konzentrieren zu können, die automatisiert nicht auffindbar sind.

Ähnlich verhält es sich im Deployment-Prozess. Der Fokus auf Automatisierung beugt Problemen vor, die durch menschliche Fehlleistungen entstehen. In der Vollausbaustufe ist der Verteilungsprozess nicht nur über alle Phasen hinweg automatisiert, sondern bezieht zusätzliche Security-Checks und Integritätsprüfungen ein – sowohl für die interne Entwicklung als auch für externe Komponenten. Als Spezialthema greift OWASP SAMM zudem das sichere Bereitstellen von Zugangsdaten und Schlüsselmaterial auf, um die menschliche Interaktion sowohl bei der initialen Verteilung als auch bei der späteren Erneuerung der Secrets zu minimieren und auf angemessen sichere Implementierungsmuster aufzubauen.

In welche Phase das Management von Defekten gehört, bleibt der Diskussion überlassen. In der Regel ist es eine querliegende Funktion über den gesamten Entwicklungszyklus. OWASP SAMM ordnet das Vorgehen der Implementierungsphase zu. Erklärtes Ziel ist, einen Prozess zu definieren, der identifizierte Schwachstellen behandelt, Metriken für die Steuerung ableitet und es der Organisation ermöglicht, für die Zukunft zu lernen. Der Prozess zeigt unter anderem auf, welche Schwachstellen regelmäßig auftreten, welche Auswirkungen sie auf den Entwicklungsprozess haben und wie schnell sie sich durchschnittlich beheben lassen. Teams können dadurch eine faktenbasierte Entscheidung darüber treffen, welche Bereiche der Entwicklung sie mit hoher Priorität verbessern müssen, um die wesentlichen Probleme rasch in den Griff zu bekommen.

Verification – ein Balanceakt

Software ohne umfassende Qualitätssicherung produktiv zu stellen, ist inzwischen in vielen Bereichen undenkbar geworden. Das betrifft insbesondere Sicherheitsüberprüfungen, da eine einzelne übersehene kritische Schwachstelle ausreicht, um die Gesamtsicherheit der Anwendung und potenziell der darunterliegenden Infrastruktur massiv zu gefährden.

Viele Organisationen stehen vor der Herausforderung, dass aufgrund schneller Release-Zyklen die Zeitfenster für Sicherheitstests immer schmaler werden. Das zwingt sie zu neuen Strategien, um trotzdem eine angemessene Testabdeckung und Testtiefe zu erreichen. Die richtige Balance zwischen Testautomatisierung und iterativen manuellen Tests durch Experten ermöglicht, sowohl einen initialen Grundschutz zu erreichen als auch laufend die Testabdeckung und Testtiefe zu steigern.

OWASP SAMM legt einen wesentlichen Schwerpunkt auf Sicherheitsüberprüfungen, die auf konkreten Security-Anforderungen aufbauen. Generische Tests haben weiterhin ihre Berechtigung, aber je konkreter die Sicherheitsanforderungen definiert sind, desto fokussierter kann das Testteam vorgehen. Freilich ist es nicht angenehm, wenn jemand den Finger dort in die Wunde legt, wo es besonders weh tut, aber das Ziel einer Sicherheitsüberprüfung muss sein, vor allem die Schwachstellen zu finden, die den größten Schaden verursachen können. Wenn die Analysten im Requirements Engineering einen guten Job erledigt haben, bilden die Sicherheitsanforderungen das Vorgehen entsprechend ab.

Wer dafür einen hohen Reifegrad anstrebt, muss bereit sein, unterschiedliche Testverfahren zu kombinieren. OWASP SAMM empfiehlt unter anderem Fuzz Testing, Denial of Service Benchmarks und Security Stress Tests, Regressionstests für behobene Schwachstellen sowie Testautomatisierung im Build- und Deployment-Prozess. Für den besseren Tiefgang kommen manuelle Security-Tests hinzu, die vorab definierte Abuse-Case-Szenarien und Business-Logik-Schwachstellen abdecken.

Erneut gilt es, die Angemessenheit nicht aus den Augen zu verlieren. Für Anwendungen mit einem sehr hohen Schutzbedarf, beispielsweise im Bereich der kritischen Infrastruktur, ist eine breit angelegte Teststrategie sinnvoll und notwendig. Bei Anwendungen mit einem niedrigeren Schutzbedarf sollten Teams jedoch abwägen, ob wirklich all diese Testverfahren notwendig sind, um eine ausreichende Testabdeckung und Testtiefe zu erreichen, bei der gleichzeitig der Testaufwand angemessen und wirtschaftlich bleibt.

Operations - sichere Betriebsprozesse

Die Grenzen des Softwareentwicklungsprozesses beginnen zunehmend zu verschwimmen – und zwar nicht erst seit der rasanten Ausbreitung von DevOps. Ob der sichere Betrieb noch unter dem Titel "Sichere Softwareentwicklung" zu führen ist, bleibt jedem selbst überlassen. OWASP SAMM hat diesem Bereich jedenfalls einen eigenen Abschnitt im Reifegradmodell gewidmet.

Ein derart umfassendes Thema wie Sicherheit in den Betriebsprozessen lässt sich nicht vollständig in einem einzelnen Kapitel abbilden. Daher hat OWASP einige wesentliche Aktivitäten ausgewählt und in des Reifegradmodell integriert. Wer hierbei punkten will, muss sich vor allem mit dem Erkennen und Behandeln von Sicherheitsvorfällen und dem Härten der Betriebsumgebung befassen. Dem Thema Datenschutz und dem Umgang mit Legacy-Systemen hat OWASP zusätzlich unter der Klammer "Operational Management" Platz eingeräumt.

Die Vorgaben dulden auf einem niedrigen Reifegrad noch Log-Analyse, Basis-Best-Effort und Ad-hoc-Reaktion auf erkannte Angriffe für das Management von Sicherheitsvorfällen. Für eine verbesserte Umsetzung fordert OWASP SAMM den Einsatz eines qualifizierten Incident-Response-Teams und klar definierte Prozesse zum raschen und durch Werkzeuge gestützten Erkennen und Abarbeiten von Vorfällen. In der Praxis hat sich zusätzlich bewährt, regelmäßige Übungen durchzuführen, um auf den Ernstfall vorbereitet zu sein. Idealerweise trainieren Unternehmen dabei nicht nur das eigene Team, sondern binden darüber hinaus alle externen Dienstleister mit ein, die es im Anlassfall hinzuziehen muss.

Deutlich tiefer in den tagtäglichen Betrieb geht es bei den Themen Patch-Management und Härtung der Konfiguration hinein. In den beiden Bereichen ist die klare Empfehlung, mindestens einen Reifegrad von 2 auf der OWASP-SAMM-Skala anzustreben. Dafür müssen Teams die genannten Aktivitäten regelmäßig und systematisch über den gesamten Technologie-Stack durchführen. Das klingt auf den ersten Blick umfangreich, ist aber heutzutage als Grundschutz anzusehen. Wer den höchsten Reifegrad erreichen möchte, muss zusätzlich eine durchgängige Überwachung der Systeme in Bezug auf Konfigurationsänderungen und aktuellen Patch-Stand implementieren.

Das Thema Datenschutz ist seit dem Inkrafttreten der DSGVO ein zentrales Thema in der Security-Szene. Es gibt allerdings keinen guten Grund, hierfür in OWASP SAMM nach einer Anleitung zu suchen. Wer das Thema ernsthaft angeht, orientiert sich direkt an den Vorgaben der DSGVO. Wer sie befolgt und die Einhaltung im Betrieb automatisiert prüft, erhält bei OWASP SAMM die Bestnote in diesem Bereich.

Last, but not least: die Legacy-Systeme. Die Praxis zeigt immer wieder deutlich, dass Firmen Altsysteme häufig vernachlässigen oder gar vergessen. Oft sind es jedoch ebendiese, die kritische Schwachstellen aufweisen und einem Angreifer Tür und Tor zum internen Netzwerk öffnen. Um Legacy-Systeme ausreichend zu schützen, sollten Teams eine klare Roadmap definieren, wie sie deren verbleibenden Lebenszeit gestalten werden. Das Idealszenario eines raschen Abbaus ist oftmals nicht möglich. Daher sollten Unternehmen Strategien entwickeln, um die Systeme bestmöglich abzuschotten und zu überwachen, bis sie in einem geordneten Prozess die Altlasten durch ein modernes und resilientes System ersetzen können. Damit punkten sie schließlich bei OWASP SAMM.

Flexibles Sicherheitskonzept

OWASP SAMM bietet ein Framework zur Verbesserung des Softwareentwicklungsprozesses über alle Phasen hinweg. Dank der unterschiedlichen Reifegrade können Organisationen entscheiden, welches Security-Level sie in welchem Bereich anstreben. Die Entscheidung hängt maßgeblich vom Schutzbedarf der entwickelten Anwendungen ab.

Einige der empfohlenen Maßnahmen mögen nicht nur aufwendig erscheinen, sondern es in vielen Fällen durchaus sein. Der Artikel hat die gesamte Spannweite von OWASP SAMM aus der Vogelperspektive inklusive der höchsten Reifegrade betrachtet. Das richtige Schutzniveau für den eigenen Entwicklungsprozess zu finden, ist eine der ersten Aufgabe, die es bei der Umsetzung von OWASP SAMM zu bewältigen gibt. Hierfür sollten Teams mit einem Reifegrad-Assessment starten und herausfinden, wo sie derzeit stehen. Davon ausgehend können sie eine strukturierte Roadmap erstellen, die die Meilensteine bis zum angestrebten Zielreifegrad vorgibt.

Da es sich bei OWASP SAMM um einen freien Standard handelt, lassen sich alle relevanten Informationen zum Modell auf der offiziellen Webseite beziehen. Des Weiteren setzt sich die OWASP-SAMM-Deep-Dive-Reihe, die der Autor dieses Artikels als Blogreihe geschrieben hat, mit den einzelnen Aktivitäten im Detail auseinander und verprobt sie mit der gelebten Praxis.

Thomas Kerbl
ist seit über 15 Jahren als Security Berater bei SEC Consult tätig. In seiner Rolle als Principal Security Consultant und Teamleiter führt er nicht nur ein Expertenteam, sondern ist nach wie vor selbst in Kundenprojekten maßgeblich involviert. Seine aktuellen Schwerpunkte im Unternehmen sind die Bereiche "Sichere Software Entwicklung" und "Security Architektur".

(rme)