Security Requirements Engineering – Das Rückgrat Ihres SSDLC

Rein auf dem Papier stimme ich zu. Bei näherer Betrachtung wird jedoch deutlich, wie weit der Einfluss von Sicherheitsanforderungen reicht. Die meisten Aktivitäten in späteren Entwicklungsstadien referenzieren auf die zuvor definierten Sicherheitsanforderungen. Wie robust muss meine Sicherheitsarchitektur sein? Was muss ich beim Build- und Deploy-Prozess meiner Anwendung beachten? Welche Sicherheitstests muss ich durchführen? Welche Parameter sind relevant für einen sicheren Betrieb? Soll ich umgehend patchen oder neue Patches sorgfältiger testen, bevor ich sie anwende?

Wenn Sie Ihre Sicherheitsanforderungen im Voraus gut definiert haben, können Sie diese und viele weitere Fragen einfach und konsistent beantworten, sobald sie auftreten. Es schmerzt mich zu sehen, dass Organisationen massive Schwierigkeiten haben, die richtige Entscheidung zu treffen, weil sie die Bedeutung von Sicherheitsanforderungen vernachlässigen.

Aber wir sollten auch nichts überstürzen. Dieses Idealszenario, das ich hier beschreibe, zeigt das Potenzial eines vollständig integrierten Engineering-Prozesses mit einem hohen Reifegrad. Wenn sie gerade erst am Anfang stehen, müssen sie zuerst eine solide Grundlage schaffen, bevor Sie dieses Potenzial auf ausschöpfen können.

Quick Wins für die Einführung von Security Requirements Engineering

Für diejenigen unter ihnen, die am Anfang dieser Reise stehen, habe ich vier Tipps und Tricks zusammengestellt, die anderen Organisationen bereits geholfen haben, erfolgreich mit der Definition von Sicherheitsanforderungen zu beginnen.

1) Respektieren sie die Grundprinzipien von gutem Requirements Engineering

Requirements Engineering ist ein etabliertes Handwerk. Dennoch scheinen viele Organisationen die Grundprinzipien zu vergessen, sobald es um Sicherheitsanforderungen geht. Ich befürworte die enge Integration aller Sicherheitsaktivitäten in bereits etablierte Entwicklungsprozesse. Dies gilt auch für das Security Requirements Engineering. Die Sicherheitsanforderungen müssen denselben strengen Richtlinien entsprechen, die auch alle anderen definierten Anforderungen einhalten müssen.

Anforderung definieren, was zu tun ist, nicht wie es zu tun ist. Sie müssen spezifisch, messbar und nachvollziehbar sein. Ich könnte nach viele weitere Kriterien ins Spiel bringen, aber diese Grundlagen finden sie in jedem guten Buch über Requirements Engineering. Werfen sie diese Grundlagen nicht über Bord, wenn sie ihre Sicherheitsanforderungen definieren. Schlecht formulierte Sicherheitsanforderungen werden später oft ignoriert oder falsch interpretiert. Vermeiden Sie diese Falle und halten sie sich an etablierte Best Practices.

2) Verwenden sie den OWASP ASVS als Inspiration für ihre ersten Sicherheitsanforderungen

„Bitte, wie? Den Application Security Verification Standard? Aber das ist doch eine Richtlinie für Sicherheitstests, nicht für das Anforderungsmanagement!“

Gut erkannt, da haben sie vollkommen recht. Der ASVS ist jedoch trotzdem eines der besten Tools, um rasch in das Security Requirements Engineering einzusteigen. Beim ASVS handelt es sich um ein sehr umfassendes und auch gut strukturiertes Dokument, eine hervorragende Informationsquelle.

Der hier beschriebene Tipp funktioniert, weil wir uns eines kleinen Tricks bedienen, um den Prozess an unsere Bedürfnisse anzupassen. In einer perfekten Welt sollten Sicherheitsanforderungen die Quelle für Sicherheitstestfälle sein. Aber denken sie daran, dass wir gerade erst am Anfang stehen und nach vernünftigen Abkürzungen suchen. Der ASVS ist eine Sammlung gut recherchierter und etablierter Sicherheitstestfälle. Warum drehen wir den Prozess nicht einfach um und versuchen, aus den Testfällen nützliche Sicherheitsanforderungen abzuleiten?

Schauen wir uns ein konkretes Beispiel an. Der ASVS liegt derzeit in Version 4.0.1 vor. Die Sicherheitsanforderung mit der ID 3.1.1 lautet wie folgt:

Verifiziere, dass die Anwendung niemals Sitzungstoken in URL-Parametern oder Fehlermeldungen anzeigt.

Zuerst stellen wir uns die Frage, ob dieser Testfall überhaupt anwendbar ist. Entwickeln wir eine Anwendung, die URLs verwendet? Und verwendet diese Anwendung Sitzungstoken? Wenn wir annehmen, es handelt sich um eine Webanwendung mit unterschiedlichen Benutzern, dann ist die Wahrscheinlichkeit hoch, dass dieser Testfall relevant ist. Formulieren wir ihn also so um, dass er als Sicherheitsanforderung verwendet werden kann:

Die Anwendung darf keine Sitzungstoken an Stellen einbetten, bei denen das Risiko besteht, dass sie an unberechtigte Dritte preisgegeben werden (z. B. in URL-Parametern oder Fehlermeldungen).

Ich habe mir die Freiheit genommen, die Anforderung etwas allgemeiner zu formulieren, um so ein breiteres Spektrum von Fällen zu erfassen. Im einfachsten Fall kann man aber auch einfach „Verifiziere, …“ durch „Stelle sicher, …“ ersetzen. Denken sie dabei daran, dass Testfälle in der Regel etwas spezifischer als Anforderungen sind und man daher eine etwas breitere Definition suchen sollte.

Die Ursache hierfür wird klar, wenn wir uns nochmals vor Augen führen, dass wir den normalen Prozess auf den Kopf stellen. Im Normalfall würden wir mit breiter ausgelegten Sicherheitsanforderungen starten und mehrere spezifischere Testfälle davon ableiten.

Bitte vergessen sie nicht, dass wir hier von einer Abkürzung sprechen, um das Security Requirements Engineering initial in Gang zu bringen. Es werden daher viele wichtige Aspekte fehlen, die später ergänzt werden müssen, um einen angemessenen Reifegrad zu erreichen. Sie werden sehr wahrscheinlich keine anwendungsspezifischen sowie auf Richtlinien und Compliance basierende Sicherheitsanforderungen definieren. Des Weiteren werden sie kein domänenspezifisches Wissen in die Sicherheitsanforderungen einfließen lassen. Aber zumindest haben sie einmal die Zehen ins Wasser getaucht und den Ball ins Rollen gebracht.

3) Stellen sie die Verifikation aller Sicherheitsanforderungen sicher

Wie bereits erwähnt, müssen Sicherheitsanforderungen in allen Entwicklungsphasen berücksichtigt werden. Zu Beginn der Integration mag dies jedoch überwältigend erscheinen – vor allem, wenn Sie in ihrer Organisation auf Widerstand stoßen. Anstatt die Integration bei allen anderen Sicherheitsaktivitäten von Anfang an zu erzwingen, empfehle ich, mit einer Methode zur Verifikation zu starten. Sobald das Entwicklungsteam sieht, wie es dazu beitragen kann, ein solches Quality Gate zu passieren, ist es normalerweise offener für die notwendigen Veränderungen.

Ich habe dieses Phänomen viel zu oft gesehen. Klassische Anforderungen werden als strenge Vorgaben verstanden, die befolgt werden müssen. Aber nenne sie „Sicherheitsanforderungen“ und jeder beginnt sie als optional zu betrachten. Sobald dieses Verhalten Wurzeln schlägt, wird der gesamte Aufwand für die Definition guter Sicherheitsanforderungen mehr oder weniger verpuffen. Lassen sie dies nicht zu!

Stellen Sie sicher, dass mindestens ein Quality Gate etabliert wird, das die Überprüfung der Implementierung ihrer Sicherheitsanforderungen umfasst. Eine wichtige Eigenschaft einer Sicherheitsanforderung ist ihre Testbarkeit. Nutzen Sie dies zu Ihrem Vorteil! Die richtige Art und Weise, eine ordnungsgemäße Überprüfung durchzuführen, hängt von der Unternehmenskultur ab. Für manche Unternehmen mag ein formaler und verbindlicher Abnahmetest der richtige Weg sein. Für andere funktioniert es deutlich besser, regelmäßige Teambesprechungen abzuhalten, in denen der Umsetzungsgrad der Sicherheitsanforderungen gemeinsam besprochen wird. Was auch immer für ihr Unternehmen funktioniert – Ziel ist es, den Verantwortlichen klar zu vermitteln, dass Sicherheitsanforderungen denselben Stellenwert haben, den auch alle anderen Anforderungen genießen.

Später, wenn sie einen höheren Reifegrad erreichen wollen, ist dieser Prozess entsprechend zu formalisieren. Ein solcher Prozess kann zu Beginn jedoch auch ohne Formalisierung bereits eine gute Methode sein, um die Bedeutung von Sicherheit in den Köpfen des Teams zu verankern. Ich habe gesehen, dass Unternehmen im gesamten SSDLC solide Verbesserungen erzielt haben, allein indem sie regelmäßige Meetings zur Diskussion von Sicherheitsanforderungen und deren Umsetzung etabliert haben. Diese Art von organischem Wachstum ist genau das, was sie sich für ihr Vorhaben wünschen.

4) Stellen sie sicher, dass Anbieter dieselben Sicherheitsrichtlinien befolgen, denen sie selbst verpflichtet sind

Die Steuerung ihrer Lieferanten ist ein so wichtiges Thema in Bezug auf Sicherheit, dass ich ihm später in dieser Serie einen eigenen Artikel widmen werde. Dennoch muss es auch im Zusammenhang mit Security Requirements Engineering zumindest kurz gestreift werden.

Ihre Sicherheitsanforderungen definieren Mindestkriterien für die Anwendung, die Sie entwickeln. Aber was passiert, wenn Teile ihrer Anwendung von einem Lieferanten entwickelt werden? Sei es ein Framework eines Drittanbieters, ein Microservice oder eine andere Softwarekomponente, auf die sich ihre Anwendung stützt. Sollten sie nicht denselben Richtlinien folgen?

Natürlich sollten sie das! Einem Angreifer ist es egal, ob der fehlerhafte Teil ihrer Anwendung intern entwickelt wurde oder nicht. Eine Sicherheitslücke ist eine Sicherheitslücke, unabhängig davon, wer für dieses Qualitätsproblem verantwortlich ist.

Aus diesem Grund müssen sie sicherstellen, dass ihre Zulieferer dieselben Sicherheitsrichtlinien wie sie befolgen. Wenn Sie dies nicht tun, erhalten sie mit hoher Wahrscheinlichkeit unsichere Software von Drittanbietern, die nicht nur ihre Anwendung gefährdet, sondern auch ihre Compliance-Verpflichtungen verletzt.

In einem zukünftigen Artikel werde ich mich mit den Best Practices des Lieferantenmanagements hinsichtlich Security befassen. Verpassen sie diesen Beitrag nicht, wenn sie Software von Drittherstellern beziehen!

Klassischer Fehler: Einzig auf die Vermeidung gängiger Schwachstellenklassen vertrauen

Es gibt viele Fehler, auf die sie achten sollten, wenn Sie mit Securit Requirements Engineering beginnen. Der wohl am häufigsten angetroffene Fehler ist es, diese Disziplin auf die Vermeidung gängiger Schwachstellenklassen zu reduzieren. Dies ist der Dunning-Kruger-Effekt in Aktion.

Eine der ersten Ressourcen, auf die man bei der Suche nach Sicherheitsstandards stößt, sind die OWASP Top 10. Und das ist gut so, denn die OWASP Top 10 sind ein großartiges Werkzeug, wenn sie richtig verwendet werden. Sie stellen einen breiten Konsens hinsichtlich der kritischsten Sicherheitsrisiken für Webanwendungen dar. Diese bei der Entwicklung von Software zu berücksichtigen ist auf alle Fälle empfehlenswert.

Dies bedeutet jedoch nicht, dass das Einfügen eines Links zu den OWASP Top 10 (oder einer ähnlichen Liste von Schwachstellenklassen) in ihr Anforderungsdokument ein ordentliches Security Requirements Engineering ersetzen kann. Aus diesem Grund habe ich auch ein wenig gezögert, den OWASP ASVS als Inspiration für Sicherheitsanforderungen im Abschnitt „Quick Wins“ mit aufzunehmen. Die Verwendung generischer Quellen für Anforderungen kann hilfreich sein, aber viele Unternehmen bleiben in der „illusory superiority zone“ des Dunning-Kruger-Effekts hängen und schaffen es nie über diese Anfangsphase hinaus, wodurch viel Potenzial ungenutzt bleibt.

Zusammenfassung und nächste Schritte

Wir haben in diesem Artikel viele Themen behandelt. Wir haben gelernt, wie wichtig ein ordentliches Security Requirements Engineering ist und einige Tipps und Tricks kennengelernt, um diese Sicherheitsaktivität im Softwareentwicklungszyklus zu integrieren. Wir haben auch einen häufig gemachten Fehler besprochen, den Unternehmen machen, der sie auf einem niedrigen Reifegrad hält, ohne dabei das verlorene Potenzial zu erkennen.

Nachdem die Grundlagen des Requirements Engineering etabliert sind und dessen Bedeutung im Unternehmen verstanden wurde, bauen wir im nächsten Schritt auf diesen Erfolgen auf und streben einen höheren Reifegrad an. Dies wird das Hauptthema des nächsten Artikels in dieser Serie sein. Darüber hinaus werden wir unsere Qualitätsstufenmatrix verwenden, um ihnen bei der Bewertung zu helfen, ob ihr Security Requirements Engineering Prozess für das Schutzprofil ihrer Anwendungen angemessen ist oder ob sie hier noch etwas nachlegen müssen.

War dieser Artikel hilfreich für sie? Gibt es spezielle Fragen, die im nächsten Artikel beantwortet werden sollen? Lassen sie es mich auf Twitter wissen und ich werde versuchen, ihr bevorzugtes Thema in die nächste Version zu integrieren!

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