Entwicklung sicherer Software mit Hilfe von OWASP SAMM

Die zugrundeliegende Methodik

Es gibt viele gute Standards für sichere Softwareentwicklung, und ich möchte das Rad nicht neu erfinden. Unser Referenzmodell für diese Serie wird OWASP SAMM v2 sein. Die aktuelle Version wurde Anfang 2020 veröffentlicht und stellt eine signifikante Verbesserung in Bezug auf agile Entwicklungsmethoden und DevOps dar. Darüber hinaus verfügt OWASP SAMM v2 über eine integrierte Methodik, mit der der Reifegrad der einzelnen Sicherheitspraktiken bewertet werden kann.

Um das Intro nicht ausufern zu lassen, werde ich hier nicht auf alle Details von OWASP SAMM eingehen. Alle relevanten Informationen finden sich auf der offiziellen Webseite von OWASP SAMM.

Benchmarking ihres sicheren Softwareentwicklungsprozesses

OWASP SAMM bietet eine Reifegradbewertungsmethode an, mit der jede Sicherheitspraktik auf einer Skala von 0 bis 3 bewertet werden kann. Dies ist jedoch nur ein Teil der Geschichte. In der Praxis stellt sich jedoch vielmehr die Frage, ob die Sicherheitsaktivitäten den Schutzanforderungen der entwickelten Anwendungen genügen. OWASP SAMM kann diese Frage in der aktuellen Version nicht beantworten. Ihr Defect-Management mag einen Reifegrad von 1,47 haben. Aber was bedeutet dies für eine bestimmte Anwendung, für die sie verantwortlich sind? Ist dieser Reifegrad auch angemessen?

Ich rate meinen Kunden in der Regel, nicht auf einen bestimmten Reifegrad – einen abstrakte Wert – abzuzielen. Ein derartiger Ansatz ist natürlich verlockend. Man kann die aktuellen Reifegrade mit den früheren Reifegraden vergleichen und sieht sofort, wo man sich verbessert hat. Aber das geht klar an dem Ziel vorbei, das wir tatsächlich erreichen wollen. Ich freue mich natürlich für jeden, der seinen angestrebten Reifegrad erreicht und solche Meilensteile gilt es auch zu feiern. Am Ende des Tages geht es aber bei der sicheren Softwareentwicklung nicht um Zahlen und schöne Dashboards, sondern um resiliente und robuste Systeme. Wenn ich hierzu etwas beitragen kann, war meine Mission erfolgreich!

Daher habe ich beschlossen, ein möglichst einfaches System für diese Serie zu entwickeln, mit dem wir ohne abstrakt berechnete Metriken über unsere Ziele sprechen können. Dazu benötigen wir lediglich zwei Dinge – eine Methode zur Abschätzung der Qualität unserer Sicherheitsaktivitäten und leicht verständliche Schutzprofile für unsere Anwendungen.

Qualitätsstufen für Sicherheitsaktivitäten

Wenn man genügend Entwicklungsteams in Aktion gesehen hat, wird man feststellen, dass Sicherheit nicht primär durch Methoden und Aktivitäten getrieben wird. 

Das Sicherheitsniveau wird maßgeblich durch das Mindset des Teams bestimmt, insbesondere das Mindset der Stakeholder und der Key-Player im Team. Daher ist es sinnvoll, das Qualitätsniveau der Sicherheitsaktivitäten nicht nur im Hinblick darauf zu beschreiben, was das Entwicklungsteam tut, sondern auch mit welcher zugrundeliegenden Einstellung diese Aktivitäten angegangen werden. Wie dies aussehen kann, wird im nächsten Artikel klarer, wenn wir diese Methode anhand konkreter Aktivitäten einsetzen.

Um die Qualitätsstufen intuitiver zu gestalten, werden wir sie sprechend benennen und unser Verständnis jeder Stufe dokumentieren:

Qualitätsstufe Holz

Wir kümmern uns nicht wirklich um diese Sicherheitsaktivität und wenn wir sie gelegentlich doch in Betracht ziehen, ist dies eher ein Zufall.

Qualitätsstufe Bronze

Wir haben über die Aktivität nachgedacht und setzen sie ad hoc um. Wir folgen gängigen Richtlinien, optimieren sie jedoch nicht für unseren Bedarf.

Qualitätsstufe Silber

Wir sind uns der Bedeutung der Aktivität bewusst und haben eine Grundlage für ihre Umsetzung geschaffen, die an unsere Bedürfnisse angepasst ist.

Qualitätsstufe Gold

Diese Sicherheitsaktivität ist gut etabliert und es fühlt sich falsch an, den etablierten Prozess nicht zu befolgen. Die Aktivität hat einen hohen Reifegrad und wird als normaler Bestandteil unseres Entwicklungsprozesses angesehen.

Qualitätsstufe Diamant

Es ist nicht akzeptabel, eine Anwendung zu entwickeln, ohne diese Security-Aktivität umzusetzen. Eine unzureichende Implementierung würde in Quality Gates identifiziert werden und eine Produktivsetzung verhindern. Der Reifegrad dieser Aktivität hat ein sehr hohes Niveau erreicht. Jeder im Team ist sich der Bedeutung dieser Security-Aktivität bewusst und handelt entsprechend.

Mit diesen Qualitätsstufen können wir beschreiben, wie eine bestimmte Sicherheitsaktivität auf einer bestimmten Stufe aussehen würde. Im nächsten Artikel dieser Reihe werden wir beispielsweise im Vergleich sehen, wie sich ein Unternehmen verhält, das Security Requirements Engineering mit Qualitätsstufe Holz betreibt, und wie dies im Gegensatz bei einem Unternehmen aussieht, das selbiges Thema mit Qualitätsstufe Diamant behandelt.

Schutzprofile

Das Definieren der Qualitätsstufen war nur der erste Schritt. Jetzt müssen wir über die einzelnen Schutzprofile bestimmter Anwendungen sprechen. Wenn wir diese Schutzprofile kennen, können wir entscheiden, welches Qualitätsniveau wir für unsere Sicherheitsaktivitäten benötigen.

Minimales Schutzprofil

Eine Anwendung oder ein System befindet sich in dieser Kategorie, wenn sie keine wesentlichen Sicherheitsanforderungen erfüllen muss. Es macht ihnen nichts aus, wenn das System für ein paar Tage offline geht, und selbst wenn es jemandem gelingt Inhalte zu manipulieren, entsteht kein nennenswerter Schaden. Die Software wird in keiner Umgebung verwendet, in der sie als Einstiegspunkt für kritischere Systeme oder Anwendungen verwendet werden kann. Häufige Beispiele sind private Homepages oder die Fanseite der örtlichen Sportmannschaft. In einem Geschäftskontext findet man normalerweise keine dieser Anwendungen.

Niedriges Schutzprofil

Diese Kategorie repräsentiert Anwendungen mit geringen Schutzanforderungen. Ihre Software hat eine gewisse Relevanz, aber der potenzielle Schaden, der angerichtet werden kann, führt zu keinem dauerhaften finanziellen Verlust oder Schaden für ihre Marke. Informationen, die von einer solchen Anwendung verarbeitet oder gespeichert werden, beinhalten keine vertraulichen Daten. In diesem Schutzprofil finden sich normalerweise Geschäftsanwendungen, die für den Betrieb nicht als kritisch angesehen werden.

Mittleres Schutzprofil

Diese Kategorie bildet die Brücke zwischen den Anwendungen, die hinsichtlich Sicherheit nicht wirklich relevant sind, und denen, deren Kompromittierung eine massive Auswirkung haben kann. Sie sorgen sich um diese Anwendungen und sind bereit, Ressourcen und Arbeitskraft in ihren Schutz zu investieren, aber ein möglicher Schadensfall fühlt sich immer noch beherrschbar an. Eine interne Knowledge-Base wäre ein mögliches Beispiel. Wenn sie offline geht, sind die Mitarbeiter weniger effizient. Wenn der Inhalt manipuliert wird, treffen die Leute schlecht beratene Entscheidungen. Wenn vertrauliche Daten unbefugt abgerufen werden, geraten wertvolle Informationen in die falschen Hände. Abhängig von den tatsächlichen Auswirkungen dieser Szenarien kann natürlich argumentiert werden, ob das Schutzprofil niedriger oder höher angesehen werden sollte. Diese Kategorie ist jedoch ein solider Mittelweg für wichtige Anwendungen, die noch nicht die Anforderungen für ein hohes Schutzprofil erfüllen.

Hohes Schutzprofil

Sobald eine Anwendung diese Kategorie erreicht, muss substanziell in deren Sicherheit investiert werden. Eine solche Anwendung hat möglicherweise nicht das Potenzial, ein Unternehmen im Falle einer Kompromittierung in die Knie zu zwingen, aber ein Angreifer könnte dennoch erheblichen Schaden anrichten. Dies kann z.B. ein VPN-Server sein, der das interne Netzwerk vor unbefugtem Zugriff schützt, ein Nachrichtenportal mit einem breiten Publikum oder eine Applikation, die im Falle einer Kompromittierung als potenzieller Einstiegspunkt für einen Angreifer in kritische Bereiche des Netzwerks fungiert.

Sehr hohes Schutzprofil

Diese Kategorie ist für die kritischsten Anwendungen reserviert, deren Schutz unerlässlich ist. Ein erfolgreicher Angriff auf eine solche Anwendung hat häufig unmittelbare, aber auch dauerhafte Auswirkungen, wie z.B. einen erheblichen finanziellen Verlust, einen Verstoß gegen das Gesetz oder eine nachhaltige Beeinträchtigung der Marke. Im schlimmsten Fall kann ein schwerwiegender Verstoß das Ende des Unternehmens bedeuten. In der Regel handelt es sich bei solchen Anwendungen um Kernsysteme kritischer Infrastrukturen, Systeme zur Abwicklung von hohen Finanztransaktionen, Anwendungen zur Verarbeitung großer Mengen an personenbezogenen Daten, oder Systeme, die in der Lage sind, die Sicherheit und Gesundheit von Personen zu gefährden.

Welches Profil ist das Richtige?

Es ist kein Zufall, dass wir die gleiche Anzahl an Qualitätsstufen und unterschiedlichen Schutzprofilen definiert haben. Diese beiden Definitionen sind aufeinander abgestimmt. Für eine Anwendung mit einem minimalen Schutzprofil ist Qualitätsstufe Holz in der Regel tatsächlich ausreichend. Es steht jedem frei mehr in solche Anwendungen zu investieren, aber aus Sicherheitssicht ist es in Ordnung, das Minimum zu tun. Wenn es sich um Anwendungen mit einem sehr hohen Schutzprofil handelt, gibt es nur allerdings nur einen Weg: Qualitätsstufe Diamant.

Zusammenfassung

Um den Blick auf das große Ganze nicht zu verlieren, habe ich eine Übersicht erstellt, die die wesentlichen Eigenschaften der jeweiligen Qualitätslevel zusammenfasst. Diese Übersicht wird uns auch als Referenz für alle zukünftigen Artikel dieser Serie dienen, um die jeweiligen Security Aktivitäten damit modellieren zu können. Gerne können sie bereits anhand der generischen Übersicht versuchen zu beurteilen, wo sie in ausgewählten Bereichen stehen. Wirklich greifbar und konkret wird es dann aber vor allem auf Basis der jeweils angepassten Versionen der jeweiligen Themengebiete.

Nächste Schritte

Nachdem wir eine einfache, aber effektive Methode als Basis entwickelt haben, um über angemessene Sicherheitsaktivitäten zu sprechen, können wir nun endlich unseren ersten Deep Dive machen. Der nächste Artikel dieser Reihe im SEC Consult Blog lautet Security Requirements Engineering – Das Rückgrat Ihres SSDLC. Wir analysieren darin die Bedeutung des Security Requirement Engineerings und diskutieren, warum Sicherheitsanforderungen als das Rückgrat aller Sicherheitspraktiken, die in einem modernen Softwareentwicklungsprozess implementiert werden, zu verstehen sind. Mit Hilfe unserer Methodik können sie dann auch gleich selbst ihr eigenes Qualitätsniveau in Bezug auf Security Requirements bewerten, um herauszufinden, wo sie gerade stehen.

Soweit der bisherige Plan. Wohin die Reise im Anschluss gehen wird, möchte ich ein Stück weit meinen Lesern überlassen. Ich schreibe natürlich besonders gerne über meine Lieblingsthemen, aber am Ende muss das Ziel sein, dass Sie das Meiste aus diesen Artikeln für sich herausholen können. Wenn Sie das, was Sie in meinen Artikeln gelernt haben, in Ihren eigenen Projekten anwenden können, ist meine Mission erfüllt.

Mein Angebot steht. Wenn Sie konkrete Fragen haben, die ich in den nächsten Artikeln behandeln soll, stellen sie mir diese gerne auf Twitter. Begeben wir uns gemeinsam auf diese Reise!

Klicken Sie hier um zur gesamten SSDLC Deep Dive Blog-Serie zu gelangen.