IT-Security: Wie gehe ich mit hunderten von Security-Anforderungen um?

Ungeachtet möglicher Restrisiken, wie beispielsweise Zero-Days, verfügen unsere adesso-Expertinnen und -Experten und generell die weltweite Security-Community über ein sehr umfangreiches Wissen darüber, was für die IT-Sicherheit getan werden sollte, sei es für die Infrastruktur, die Anwendungen oder andere Themen. Bekannte Quellen (wie OWASP, NIST oder BSI-Grundschutz) enthalten sicherlich mehrere hundert Sicherheitsanforderungen. Eine sorgfältige Bearbeitung all dieser Anforderungen inklusive einer entsprechenden Umsetzung ist allein aufgrund der großen Anzahl eine Herausforderung.

In diesem Blog-Beitrag möchte ich daher zwei mögliche Herangehensweisen diskutieren und meine persönliche Meinung auf Basis meiner bisherigen Erfahrungen mitteilen. Stark vereinfacht werde ich hier zwei polare Ansätze beschreiben, zum einen das eher klassische Requirements Engineering und zum anderen einen iterativen Ansatz.

Ansatz 1: Klassisches Requirements Engineering

Beim klassischen Requirements Engineering werden in sehr frühen Projektphasen alle nichtfunktionalen Anforderungen erhoben und dokumentiert. Die Planung der Umsetzung dieser Anforderungen kann dann auf unterschiedliche Weise erfolgen - beispielsweise priorisiert über das Backlog oder mittels einer dedizierten Roadmap.

In der meist agilen Welt, in der wir uns bewegen, scheint dieser Ansatz nicht mehr so recht zu passen, da sehr viel Vorarbeit notwendig ist. Wer will schon mit hunderten von Security Backlog Items starten.

Das ist zugegebenermaßen eine sehr kurze Beschreibung des Problems, aber wie man in meinen bisherigen Blog-Beiträgen sehen kann, bevorzuge ich einen anderen Ansatz.

Das Ziel dieses Ansatzes ist definitiv sehr ähnlich zum voll strukturierten Requirements Engineering. Ich möchte eine möglichst vollständige Abdeckung von Sicherheitsfragen, so dass ein Produkt, das ich ausliefere, nur akzeptable Risiken enthält. Der Hauptunterschied ist, dass ich

• a) anders vorgehe, um das Ziel zu erreichen und
• b) die Risikodimension berücksichtige.

Ansatz 2: Der iterativer Ansatz

Ausgangspunkt für den zweiten Ansatz ist ein initiales Bedrohungsmodell, in dem ohne Anspruch auf Vollständigkeit eine idealerweise nicht zu detaillierte Architektur top-down analysiert wird. Das Ergebnis ist eine „Security Map“ mit Markierung der kritischen Elemente (Risikobewertung) und Definition und Entscheidung der nächsten Schritte. Ein typisches Beispiel ist die Identifikation einer öffentlichen Schnittstelle und die Ableitung von High-Level-Maßnahmen wie Input-Validierung oder http-Security.

Mit dieser initialen Aktivität beginnt dann der iterative Prozess der Verfeinerung. Das bedeutet, dass aus dem initialen Finding Maßnahmen als Backlog Items definiert werden (wenn das Risiko nicht akzeptiert werden kann). Häufig ist ein Backlog Item aus dem ersten Durchlauf sehr allgemein formuliert und die Aufgabe besteht darin, es in den ersten Sprints zu verfeinern und konkrete Umsetzungsmaßnahmen abzuleiten. Das passt sehr gut zu der dir vielleicht bekannten Aussage, dass Security ein fraktales Problem ist. Fraktal deshalb, weil beim Hineinzoomen in das „Bild“ immer neue Details auftauchen, die sich wiederum in weitere Details unterteilen lassen. Leider weiß ich nicht mehr, von wem diese Aussage stammt.

Im Umkehrschluss bedeutet dies aber auch, dass ständig neue Analysen durchgeführt werden müssen, insbesondere bei eventuellen Änderungen des Designs. Sicherheit wird damit zu einem Thema, das ständige Aufmerksamkeit erfordert. Ich persönlich würde diese Aufgabe immer einem Security Engineer anvertrauen, der genau diese Aufgabe im Projekt hat (er muss ja nicht Vollzeit im Projekt sein). Um die Zielqualität (oder Vollständigkeit) zu erreichen, nutzt der Security Engineer natürlich im Hintergrund das oben genannte Wissensrepertoire. Dazu gehört beispielsweise auch der Abgleich mit vorhandenen generischen Anforderungslisten.

Meine Projekterfahrungen

In einem Projekt bin ich vor einiger Zeit genauso vorgegangen. Die Entwicklung der Anforderungen lief parallel, aber das Projekt stand unter Zeitdruck. Das Feedback des Kunden nach zwei Workshops und einem Bericht über die Ergebnisse der ersten Iteration war: „Super schnell und super schmutzig, aber ein galaktisches Ergebnis“.

Das heißt nicht, dass man Security „quick and dirty“ erledigen kann, aber man kann ohne Anspruch auf Vollständigkeit beginnen und auf Basis der Risikobewertungen einen schnellen und zielgerichteten Einstieg in die komplexe Security-Thematik ermöglichen. Dass damit nicht das Ende der Fahnenstange erreicht ist, sollte klar sein, aber ist es nicht viel besser, die Security-Themen von Anfang an im Blick zu haben und gegebenenfalls mit besseren Informationen neu zu priorisieren?

Dieser eher design- und anforderungslastige Einstieg sollte natürlich nach dem Shift-Left-Prinzip so früh wie möglich durch geeignete Tools in der Entwicklung kompensiert werden. Auch hier gilt es einfach zu vermeiden, dass man kurz vor dem Deployment eine riesige Menge an offenen Sicherheitsfragen hat. Ist es nicht viel besser, den Entscheider frühzeitig über den Status und mögliche offene Risiken zum Go-Live zu informieren, als bei einem Release-Quality-Gate mit roten Ampeln aufzuwarten?

Fazit

Eine kurze Frage zum Schluss: Ist es sinnvoller, schnell in die Sicherheitsdiskussion einzusteigen und im Laufe der Zeit „Vollständigkeit“ zu erreichen oder zuerst eine vollständige Liste aller Anforderungen zu definieren? Wie wir gesehen haben, bevorzuge ich den iterativen Ansatz, der eine schnellere Integration von Sicherheitsaspekten ermöglicht und Risikobewertungen zur Priorisierung nutzt. Das Ziel ist meiner Meinung nach nicht die sofortige Vollständigkeit, sondern die frühzeitige Behandlung von Sicherheitsfragen, um schrittweise Verbesserungen vornehmen zu können. Der Einsatz geeigneter Tools und ein kontinuierliches Monitoring minimieren die Risiken vor der Implementierung.