Security Requirements Engineering – Optimiertes Vorgehen

Verwenden sie identifizierte Sicherheitsprobleme als Quelle für Verbesserungen

Sie sind möglicherweise nicht glücklich über identifizierte Sicherheitsprobleme in ihren Systemen und Anwendungen, aber sie können im Rahmen einer gründlichen Root-Cause Analyse sehr viel von ihnen lernen. Und – sie haben es vielleicht erraten – ihre Sicherheitsanforderungen sind ein wesentlicher Teil eines solchen Prozesses.

Bleiben wir bei unserem Beispiel von oben. Sie führen einen DDoS-Benchmark-Test durch und realisieren; Sie haben Ihr Ziel eindeutig verfehlt. DDoS-Resiliency Score 3.3 (anstatt 5), heißt es im Testbericht. Aber warum, was ist schiefgelaufen? Hier bietet sich eine Traceability-Matrix zur Analyse an. Sie zeigt ihnen von Anfang bis Ende, wie eine bestimmte Anforderung in jeder Phase umgesetzt wurde. Ich empfehle mit der zugrundeliegenden Sicherheitsanforderung zu beginnen und sich von dort aus durch den Lebenszyklus zu arbeiten.

Die Anforderung selbst wurde definiert und dokumentiert – Check.

Relevante Design-Entscheidungen wurden im Rahmen der Erstellung der Sicherheitsarchitektur getroffen und dokumentiert – Check.

Die Bedrohungsmodellierung zeigte zwar einige Probleme auf, diese wurden jedoch anschließend in der Architektur korrigiert. In der zweiten Iteration zeigte die Bedrohungsanalyse keine relevanten Risiken mehr auf – Check.

Teile der Anti-DDoS-Maßnahmen wurden an den Internetdienstanbieter ausgelagert – Moment! Ja, es gibt einen entsprechenden Vertrag. Dieser enthält auch eine Reihe von Metriken. Diese beziehen sich jedoch nicht auf unsere spezifischen Anforderungen. Bingo, wir haben das Problem gefunden!

Das Problem selbst zu beheben ist die eine Sache. Sie verhandeln erneut mit dem Anbieter und definieren das notwendige Schutzniveau. Anschließend stellen sie die korrekte Umsetzung sicher, indem sie einen weiteren DDoS-Benchmark Test durchführen. Aber wie können sie gewährleisten, dass ein ähnliches Problem bei ihrem nächsten Projekt nicht erneut auftritt?

Wir müssen herausfinden, wie es zu dieser Schwachstelle gekommen ist. Ist es ein Problem mit dem Beschaffungsprozess selbst? War die Anforderung für die Verantwortlichen im Einkauf unklar? Wenn ja, warum haben sie sich nicht an die Sicherheitsexperten gewandt? Oder war es ein einfaches Missverständnis? Basierend auf den Antworten auf diese und ähnliche Fragen, die sie an der Stelle stellen möchten, werden sie die Wurzel des Problems aufdecken und in der Lage sein, es entsprechend anzugehen. In unserem Beispiel könnten Maßnahmen z.B. die Anpassung des Beschaffungsprozesses, verstärkte Interaktion zwischen Einkauf und Sicherheitsabteilung oder die Schulung bestimmter Rollen umfassen.

Die Ursachenanalyse kann eine zeitaufwändige Aufgabe sein und wird manchmal als Suche nach Schuldigen missverstanden. In Wahrheit geht es aber lediglich darum, jetzt in die Verbesserung der Prozesse zu investieren, um später deutlich höhere Kosten zu vermeiden. Eine eingehende Analyse kann sie mehrere Stunden ihrer wertvollen Schlüsselressourcen kosten, aber immer wieder denselben Fehler zu machen, wird mit der Zeit viel teurer.

Integrieren sie domänenspezifisches Wissen

Wenn Unternehmen damit beginnen Sicherheitsanforderungen zu definieren, verlassen sie sich zunächst auf generische und oftmals sehr technologieorientierte Anforderungen, um die Resilienz gegen verschiedene Arten von Angriffen zu erhöhen. Dies ist jedoch nur ein Teil des großen Ganzen.

Welche Inspirationsquellen für Sicherheitsanforderungen fallen uns ein, um das Bild abzurunden? Compliance Anforderungen und die Gesetzgebung? Bereits erlebte Sicherheitsvorfälle? Sicherheitsstandards für ihre Branche? Relevante Abhängigkeiten in der Betriebsumgebung? Community-, Kunden- und Partner-Feedback?

Nun, all die genannten Bereiche sind wertvolle Quellen, und wir sollten sie im Rahmen der Anforderungsanalyse zu Rate ziehen. Wenn sie Securit Champions etabliert haben, binden sie sie ein und nutzen sie ihr Wissen. Besprechen sie ihre Sicherheitsanforderungen mit Domain-Experten und berücksichtigen sie deren Feedback. Bitten sie ihre Rechtsberater, die Konformität ihrer Sicherheitsanforderungen mit den relevanten Gesetzen und Vorschriften sicherzustellen.

Lange Rede, kurzer Sinn, erweitern sie ihre Perspektive! Behalten Sie ihre etablierten technischen Anforderungen bei und bereichern sie diese mit domänenspezifischem Wissen.

Verwenden sie ein Security Requirements Engineering Framework

Wenn wir über die Verwendung eines Frameworks für unsere Sicherheitsanforderungen sprechen, bewegen wir uns bereits auf den höchsten in OWASP SAMM definierten Reifegrad zu. Aber denken sie daran, wir tun dies letztendlich nicht für Ruhm und Ehre oder um Punkte auf einem Scoreboard zu sammeln, sondern um sichere und resiliente Anwendungen zu erstellen. Und in diesem speziellen Fall noch zusätzlich, um unsere Effizienz deutlich zu steigern.

Einer der Gründe, warum Security Requirements Engineering in vielen Unternehmen nicht ordnungsgemäß durchgeführt wird, ist der falsch eingeschätzte Aufwand für diese Aktivität. Ich werde ihnen die Predigt ersparen, wie wichtig es ist und wie viel sie langfristig sparen können, wenn sie die Sicherheit frühzeitig in ihrem SDLC berücksichtigen. Sie haben es schon tausendmal gehört und vielleicht hat sie sogar genau diese Überlegung hier auf diese Seite gebracht. Kommen wir also gleich zum Wesentlichen.

Richtig durchgeführtes Security Requirements Engineering kann sehr effizient und effektiv sein. Ein auf ihre Unternehmenskultur zugeschnittenes Framework ist hierfür entscheidend. Ziel eines solchen Frameworks ist es sicherzustellen, dass ihre Sicherheitsanforderungen angemessen und vollständig sind. Der Schlüssel besteht darin, vordefinierte und wiederverwendbare Anforderungen bereitzustellen, sowie eine Reihe von Quellen anzubieten, mit denen diese allgemeinen Anforderungen ergänzt und bereichert werden können. Dies schafft eine Struktur, mit der ein hohes Qualitätsniveau erreicht werden kann.

Ich empfehle, die Struktur der Sicherheitsanforderungen als Teil des Frameworks zu formalisieren. Insbesondere wenn sie in einer agilen Umgebung arbeiten, kann es hilfreich sein zu definieren, wie eine „Evil User Story“ aussieht und wie sie ihre Sicherheitsanforderungen in ihrer DoD (Definition of Done) und DoR (Definition of Ready) berücksichtigen. Ich werde im Abschnitt Q&A am Ende dieses Artikels noch näher auf dieses Thema eingehen.

Klassischer Fehler: Die Security Requirements vor dem Penetrationtest Team verbergen

Wenn sie an meinem Vortrag beim OWASP SAMM User Day teilgenommen oder mich bei unserem letzten Webinar gehört haben, haben sie meinem Ärger über dieses Problem live miterleben dürfen. Als ehemaliger Penetration Tester war ich regelmäßig mit dieser Situation konfrontiert. Aber kommen wir gleich zur Sache.

Es gibt keinen guten Grund, ihre Sicherheitsanforderungen vor ihrem Test Team zu verbergen! Das ist so, als würden sie zu einer Untersuchung zum Arzt gehen und vergessen dabei zu erwähnen, dass sie nächste Woche einen Marathon laufen möchten. Sicher, der Arzt wird eine Standard-Untersuchung durchführen und möglicherweise sogar kritische Probleme finden, die behandelt werden sollten. Er hat aber nur ein begrenztes Zeitfenster für die Untersuchung – schließlich warten bereits andere Patienten im Warteraum. Viele der Checks, die für jemanden mit dem Plan einen Marathon zu laufen relevant sind, werden sich einfach nicht ausgehen, wenn sich der Arzt nicht genau auf diesen für sie wichtigen Teil konzentriert und stattdessen alle Basis-Checks abklappert.

Dasselbe gilt auch für einen Sicherheitstest. Sie haben eine begrenzte Zeit und ein begrenztes Budget. Das Testteam versucht die wichtigsten Probleme innerhalb dieser Limits zu finden. Aber wenn sie ihnen nicht verraten, was für sie am wichtigsten ist – ihre konkreten Sicherheitsanforderungen – wie sollen sie den Fokus auf die richtigen Bereiche legen? Sicher, sie werden alle Standardtests abdecken, aber konnten sie das Beste aus dem Test für ihre konkrete Situation herausholen? Wahrscheinlich nicht.

Tappen sie bitte nicht in diese Falle. Stellen sie ihrem Testteam nicht nur alle Sicherheitsanforderungen zur Verfügung, sondern stellen sie auch sicher, dass aus diesen Anforderungen auch die richtigen Testfälle abgeleitet werden. Nur so ist gewährleistet, dass sich die Tester auf die Bereiche konzentrieren, die wirklich wichtig sind für sie.

Nachdem sie inzwischen so viel über Security Requirements Engineering gelesen haben, fragen sie sich wahrscheinlich, wo sie selbst stehen. Der beste Weg, um ihren aktuellen Reifegrad zu bestimmen, ist die Durchführung einer OWASP SAMM Reifegrad Bewertung. Um jedoch ein erstes Bauchgefühl zu erhalten, habe ich eine Version unserer Qualitätsstufenmatrix für Security Requirements Engineering erstellt:

Falls Sie mit der Rolle des Security Champions noch nicht vertraut sind, stellen sie sich diese Person als versierten Security Coach vor, der in das Entwicklungsteam integriert und in der Regel sogar selbst Entwickler ist. Eventuell gehe ich auf diese wichtige Rolle in einem zukünftigen Artikel näher ein und erläutere, wie man wirkungsvolle Security Champions in einem Unternehmen aufbaut.

Q&A

Ich wurde auf Twitter gefragt, wie man Schwachstellen in der Business Logik in agilen Entwicklungsprozessen im Rahmen des Security Requirements Engineerings adressiert. Das ist eine großartige Frage, die es mir auch erlaubt, Requirements Engineering in agilen Projekten etwas genauer zu beleuchten. Bitte beachten sie, dass nicht alle agilen Prozesse gleich gestaltet sind und es hier keine einheitliche Lösung für alle Unternehmen gibt. Verwenden sie meine Ansätze als Inspiration, aber stellen sie sicher, dass sie diese an ihre spezifischen Bedürfnisse und Prozesse anpassen!

Wenn wir über Requirements Engineering in einem agilen Softwareentwicklungsprozess sprechen, sprechen wir im Wesentlichen über Epics und die zugehörigen User Stories. Dies ist auch der Bereich, in dem unsere Business Logik spezifiziert wird und zugrundeliegende Sicherheitsprobleme angegangen werden müssen.

Nehmen wir als Beispiel eine einfache User Story für eine CRM-Anwendung: „Als Account Manager möchte ich die Liste meiner Accounts inkl. ihre primäre E-Mail-Adresse sehen, damit ich mit meinen Kunden in Kontakt treten kann.“

Suchen wir uns zusätzlich eine konkrete Schwachstelle in Bezug auf die Business Logik aus, die es zu vermeiden gilt: „Ein Account Manager kann nicht nur seine eigenen, sondern alle Konten im CRM auflisten, obwohl dies gegen die Datenschutzanforderungen verstößt.“

Es gibt verschiedene Möglichkeiten, dies aus Sicht der Sicherheitsanforderungen zu behandeln. Schauen wir uns einige Möglichkeiten an.

Fügen sie dem gleichen Epic eine Security User Story hinzu

Unsere User Story ist Teil eines größeren Epics. Das Analysieren und Definieren von Sicherheitsanforderungen als Security User Story desselben Epics ist möglich, obwohl ich kein großer Fan dieses Ansatzes bin. In unserem Fall könnte eine solche Security User Story folgendermaßen lauten: „Als Datenschutzbeauftragter möchte ich sicherstellen, dass Account Manager nur auf Daten ihrer eigenen Kunden zugreifen können, um Compliance-Verstöße zu vermeiden.“

Das Problem bei diesem Ansatz ist die Entkopplung von funktionaler User Story und Security User Story. Beim Priorisieren und Zuweisen von User Storys zu Sprints besteht die Gefahr, dass die funktionale User Story viel früher als die Security User Story implementiert wird und die neue Funktion für mehrere Versionen verwundbar bleibt. Daher bevorzuge ich einen anderen Ansatz – das Hinzufügen von Sicherheitsanforderungen als Subtask zur betroffenen User Story selbst.

Fügen sie der User Story einen Security Subtask hinzu

Während des Requirements Engineerings in einem agilen Entwicklungsprozess werden Subtasks für User Stories definiert, um die zugrunde liegenden technischen Anforderungen zu spezifizieren. Dies funktioniert auch für Sicherheitsanforderungen.

In unserem Fall würde das Team die Notwendigkeit eines serverseitigen Filtermechanismus identifizieren, der sicherstellt, dass nur die Kunden angezeigt werden, die dem Account Manager zugewiesen sind. Diese technische Anforderung wird als Subtask hinzugefügt und als sicherheitsrelevant gekennzeichnet. Und da unsere Definition of Done das Bestehen aller Testfälle für sicherheitsrelevante Subtask beinhaltet, haben wir sichergestellt, dass diese spezifische Sicherheitslücke in der Business Logik nicht in die Produktion gelangen kann.

Erstellen sie Evil User Stories

Die Evil User Story ist ein wirkungsvoller Ansatz, mit dem sie über Sicherheitsanforderungen auch abseits konkreter User Stories und Epics nachdenken können. Sie erstellen bösartige Personas und formulieren Evil User Stories aus deren Sicht: „Als verärgerter Account Manager möchte ich alle E-Mail-Adressen in unserem CRM kopieren, damit ich sie mitnehmen kann, wenn ich zu einem anderen Unternehmen wechsle.“

Sie können diese Evil User Stories entweder wie echte User Stories behandeln und Gegenmaßnahmen implementieren, oder Sie können sie einfach als Hilfsmittel zur Inspiration verwenden, und sie bei der Analyse ihrer echten User Stories berücksichtigen. Wenn sie sie wie normale User Stories behandeln möchten, behalten sie ihre Priorisierung im Auge. Andernfalls werden sie möglicherweise zugunsten funktionaler User Stories zurückgeschoben, obwohl ihre Anwendung dadurch angreifbar wird.

Ich empfehle, mit diesen Ansätzen herumzuspielen und zu sehen, was für ihr Unternehmen am besten funktioniert. Wie gesagt, es gibt keine einheitliche Lösung für alle Entwicklungsmethoden, und sie müssen ihren bevorzugten Ansatz an ihre Prozesse anpassen. Und wenn Sie die beste Lösung für sich gefunden haben, vergessen Sie nicht, sie in ihr Security Requirements Engineering Framework zu integrieren, um das meiste aus ihr herauszuholen!

Zusammenfassung und nächste Schritte

Sie haben bis hierher durchgehalten? Gratulation, das war viel Stoff in kurzer Zeit! Sie haben sich hiermit nun die Grundlagen erarbeitet, um einen soliden Security Requirements Engineering Prozess einzuführen, zu etablieren und zu optimieren.

Eine erfolgreiche Implementierung ist eine große Herausforderung, und was theoretisch einfach klingt, ist in der Praxis oft ein langer und steiniger Weg. Wenn Sie unterwegs professionelle Beratung benötigen, stehen ihnen mein Team und ich gerne zur Seite.

Nach zwei umfassenden Artikeln zum Thema Sicherheitsanforderungen werde ich mich beim nächsten Mal mit einem weiteren wichtigen Aspekt der sicheren Softwareentwicklung befassen: Design einer sicheren Architektur. Wir wechseln im SSDLC somit vom Was auf das Wie.

Wenn sie konkrete Fragen zum Thema Sicherheitsarchitektur haben, lassen Sie es mich auf Twitter wissen und ich werde versuchen, ihr Anliegen im nächsten Artikel mit aufzunehmen bzw. ihre Frage direkt in der nächsten Q&A zu beantworten!

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