Security Requirements Engineering – Optimiertes Vorgehen

SSDLC

Nachdem wir die Grundlagen des Security Requirements Engineering besprochen haben, ist es Zeit, die nächsten Schritte in Angriff zu nehmen.

Werbebanner für SSDLC Deepdive zeigt Menschen am Computer

Wenn sie es mit der sicheren Softwareentwicklung ernst meinen, sollten sie unbedingt das Security Requirements Engineering als Rückgrat Ihres SSDLC etablieren. Sobald sie diese Disziplin beherrschen, entstehen viele der Vorteile organisch aus dem zugrunde liegenden Prozess, und die kontinuierliche Verbesserung ergibt sich fast von selbst. Sind Sie bereit, auf den Grundlagen aufzubauen?

Ein Artikel von Thomas Kerbl, Principal Security Consultant (SEC Consult Vienna). Folgen sie ihm auf Twitter: @dementophobia für Updates zum Thema Sicherheit. Dieser Artikel ist Teil der Secure Software Development Deep Dive Serie.

Motivation

Sobald sie erste Erfahrungen im Security Requirements Engineering gesammelt haben, sind Sie wahrscheinlich bestrebt, die nächsten Schritte zu unternehmen, um das volle Potenzial dieser wichtigen Aktivität auszuschöpfen. Die Steuerung ihrer Entwicklungsaktivitäten anhand von Sicherheitsanforderungen ist ein eleganter Ansatz, um Konsistenz und Zuverlässigkeit in ihren Softwareentwicklungszyklus in Bezug auf Security zu gewährleisten.

In diesem Artikel werde ich zeigen, wie sie auf dem bereits errichteten Fundament aufbauen und die Vorteile eines ausgereiften Security Requirements Engineering Prozesses nutzen können. Ich werde auch meine auf Security Requirements Engineering zugeschnittene Qualitätsstufenmatrix mit ihnen teilen, damit sie einen ersten Eindruck davon bekommen, wo sie gerade stehen.

Dieser Artikel ist die Fortsetzung des vorangegangenen Artikels in dieser Reihe, den sie zuerst lesen sollten. Wenn sie jedoch bereits mit den Grundlagen des Sicherheitsanforderungs-Engineerings Erfahrung gesammelt haben, können Sie natürlich auch direkt hier einsteigen!

Security Requirements Engineering in der Vollausbaustufe

Ihr initialer Security Requirements Engineering Prozess ist etabliert? Ihre ersten Projekte verwendeten bereits wohldefinierte Sicherheitsanforderungen? Sie haben sogar ihre ersten Sicherheitstests basierend auf diesen Anforderungen durchgeführt? Und die aktuelle OWASP SAMM Bewertung hat gezeigt, dass die Reife ihres Security Requirements Engineering Prozesses zum ersten Mal über Stufe 1 hinausgeht?

Sieht so aus, als wären sie bereit für die nächsten Schritte! Die folgenden bewährten Tipps und Tricks helfen ihnen auf dem bevorstehenden Weg.

Berücksichtigen Sie Ihre Sicherheitsanforderungen in allen Entwicklungsphasen

Wenn ich über Security Requirements Engineering als Rückgrat des SSDLC spreche, bin ich mir über die Tragweite meiner Worte im Klaren. Ich diskutiere regelmäßig die Nuancen verschiedener Sicherheitsaktivitäten mit meinen Kunden, und einer der Sätze, die ich am häufigsten wiederhole, lautet: „Nun, es kommt darauf an. Schauen wir uns unsere definierten Sicherheitsanforderungen an, um uns danach auszurichten.“

Dieser Ansatz ist so wirkungsvoll, weil die meisten Sicherheitsanforderungen in vielen nachfolgenden Entwicklungsphasen berücksichtigt werden müssen. Nehmen wir ein einfaches Beispiel:

„Die im Internet exponierte API muss einen DDoS-Resiliency Score von mindestens 5 aufweisen.“

Was bedeutet dies für unsere nachfolgenden Sicherheitsaktivitäten?

Bei der Definition ihrer Sicherheitsarchitektur berücksichtigen sie unterschiedliche Anti-DDoS-Konzepte und zugrundeliegende Technologien. Während der Bedrohungsmodellierung analysieren sie, ob diese Maßnahmen von einem Angreifer umgangen werden können oder ob spezifische Angriffsmethoden ihre DDoS-Ausfallsicherheit beeinträchtigen würden. Wenn Sie ein externes Anti-DDoS-Service integrieren, nehmen Sie die relevanten Sicherheitsanforderungen in ihre Lieferantenverträge und SLAs auf. Während der Überprüfungsphase benötigen sie DDoS-Benchmark-Tests, um zu verifizieren, dass sie den angestrebten Resiliency Score tatsächlich erreichen. Um einen sicheren Betrieb zu gewährleisten, müssen sie eine Überwachung mit geeigneten Grenzwerten etablieren, um Last-Niveaus zu erkennen, die möglicherweise die Kapazität ihrer Infrastruktur überschreiten.

Das sind nur einige Beispiele, aber diese illustrieren das Konzept bereits recht gut. Sie wissen nicht, worauf es bei den nachfolgenden Sicherheitsaktivitäten wirklich ankommt, ohne sich regelmäßig auf die definierten Sicherheitsanforderungen zu beziehen.

Wohldefinierte Sicherheitsanforderungen stellen das Rückgrat einer sicheren Software Entwicklungsmethodik dar.
Thomas Kerbl, SEC Consult Group

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.

Es gibt keinen guten Grund, Sicherheitsanforderungen vor ihrem Test Team zu verbergen.
Thomas Kerbl, SEC Consult Group

Quick-assessment Ihres Security Requirements Engineering Prozesses

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:

Tabellarischer Vergleich der OWASP SAMM Assessment Level - SEC Consult

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ührenzu 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.

Mehr zum Thema

Über den Autor

[Translate to German:] Thomas Kerbl
Thomas Kerbl
SEC Consult Group
Principal Security Consultant

Thomas Kerbl ist bereits seit über 15 Jahren für SEC Consult als Security Consultant tätig. In seiner Rolle als Principal Security Consultant und Teamleiter führt er nicht nur ein Team von Experten, sondern setzt auch nach wie vor Kundenprojekt selbst um. Seit einigen Jahren liegt sein Fokus auf den Themen „Sichere Softwareentwicklung“ und „Security Architektur“, in denen er seine Expertise als ehemaliger Penetration Tester und Security Requirements Engineer einfließen lassen kann.