Illustration: Absmeier Geralt

In der allgemeinen Informationssicherheit sind Risiko-gestützte Vorgehensweisen mit entsprechend priorisierten und dosierten Einzelmaßnahmen längst »State of the Art«. In der Software-Entwicklung dagegen gilt nach wie vor meist der Grundsatz: »Alle Fehler sind auszumerzen«. Vor dem Hintergrund der Komplexität und notwendigen Agilität heutiger Projekte sollte diese Maxime überdacht werden.

Von der Maxime, »absolute Sicherheit« in der IT herstellen zu müssen, hat sich die moderne Cyber-Security schon vor langer Zeit verabschiedet. Man geht davon aus, dass jede Unternehmensumgebung unbekannte Schwachstellen hat, die ausgenutzt werden können, und verstärkt deshalb die Aktivitäten im Bereich der Erkennung und Abwehr bereits angelaufener Attacken.

Aber auch die Prävention wird anders gehandhabt als in der Frühzeit der IT-Sicherheit. So gehört es ganz selbstverständlich zum Kern von Informationssicherheits-Management-Normen wie der ISO 2700x, dem Grundschutz und PCI DSS und zur Basis der gängigen Best Practices, jeder Strategie- und Maßnahmenentwicklung zyklisch wiederholte Risiko-Assessments und Prüfungen auf tatsächlich vorhandene Verwundbarkeiten voranzustellen. Danach werden die zu treffenden Maßnahmen priorisiert und auch diese Priorisierung nach Bedarf immer wieder nachjustiert. Die Fachwelt weiß zu genau, dass eine Absicherung auf Top-Level für jedes System in einer IT-Umgebung die meisten Anwender überfordert, gleich ob es sich dabei um mittelständische Unternehmen, große Konzerne oder öffentlich Institutionen handelt.

»Angemessene« Sicherheit als Ziel

Wenn immer mal wieder Klagen darüber zu hören sind, dass manche Normen oder die Vorschriften von Kunden an ihre Lieferanten zu sehr ins Detail gehen und sich vom Prinzip der Risikoeinschätzung lösen, zeigt dies nur um so mehr, wie stark das Modell der an reale Risiken angelehnten Security-Bewertung in allen Branchen bereits akzeptiert und in die Praxis übergegangen ist.

Ein Sektor, der dabei seltsamerweise immer weitgehend außen vor geblieben ist, ist der der Software-Entwicklung. In diesem Bereich wird nach wie vor davon ausgegangen, dass die Teams auch unter Sicherheitsgesichtspunkten grundsätzlich fehlerfreie Produkte abliefern. Aber während die Security-Seite diesen Anspruch formuliert, fordern die Business-Strategen schnell einsatzfähige Applikationen, die rein vom Zeithorizont her oft nur unter Verwendung frei verfügbarer oder in anderen Projekten schon eingesetzter Module hergestellt werden können. Das bringt die Entwickler in Zielkonflikte: Sie werden dafür honoriert, dass sie schnell und preiswert liefern, aber auch dafür gescholten, dass die Ergebnisse dann Sicherheitslücken aufweisen.

Die große Herausforderung liegt darin, Entwicklungsteams genau das Security-Know-how zu vermitteln, um Sicherheitsrisiken im Kontext der betreffenden Software zu bewerten und entsprechend zu behandeln. Als Folge davon werden häufig eher starre Regelwerke eingesetzt. Sie sind augenscheinlich für Entwickler einfacher und ohne umfangreiches Fachwissen umsetzbar, wie etwa »es muss ein Security-Scanner eingesetzt werden und alle Schwachstellen mit einem CVSS-Score größer N behoben werden«.

Damit wird aber quasi im Vorbeigehen das primäre Ziel durch die Regelkonformität ausgehebelt, und die Entwickler implizit davon befreit, sich mit den tatsächlichen Risiken auseinanderzusetzen.

Ein Beispiel: potenzielle SQL-Injection-Schwachstellen werden von den meisten Security-Scannern mit höchster Priorität eingestuft. Das durchaus zu Recht, denn SQL-Injections führen schon seit Jahren die Liste der OWASP Top 10 an. Wenn die Applikation später eingesetzt wird, ist möglicherweise aber nur ein kleiner Teil dieser Schwachstellen relevant. Entweder, weil sie in diesem Kontext schlicht nicht ausnutzbar sind oder Assets betreffen, die als nicht business-relevant eingestuft wurden. Die Forderung, alle gefundenen Schwachstellen mit gleicher Perfektion auszumerzen, setzt also eine Vorgabe, die den realen Schutzbedarf häufig übersteigt.

Schwerwiegender ist noch ein anderer Effekt, der sich mittlerweile bei vielen Entwicklungsteams beobachten lässt: Ist ein Softwarestand erst einmal konform, d.h. alle gefundenen Schwachstellen wurden behoben, dann werden sogar Updates des Scan-Tools seitens der Entwicklung ganz bewusst vermieden, da sie weitere Schwachstellen finden könnten. Das ist einigermaßen absurd, denn hier verhindert das Ziel der Konformität, dass sich die Sicherheit verbessern kann.

Man könnte nun argumentieren, dass Software mit Fehlern grundsätzlich eine Schwachstellenebene in die Organisationen trägt, die man dort lieber nicht akzeptieren will. Dann allerdings müsste man auch zugestehen, dass das derzeit immer häufiger geforderte »agile« Vorgehen bei der Software-Entwicklung nicht funktioniert und wieder verabschiedet werden muss. Hält das Business dagegen, dass die Organisation damit an Konkurrenzfähigkeit verliert, gibt es nur einen Ausweg: Das anderswo praktizierte, Risiko-orientierte Vorgehen eben doch auch auf die Applikationsherstellung anzuwenden und einzuräumen. Und dass auch beim Development mit der Trias aus komplett auszumerzenden, zu senkenden und eben zu akzeptierenden Schwachstellen und Risiken zu operieren ist.

Vielleicht fällt die Entscheidung für diesen Ansatz leichter, wenn man sich vergegenwärtigt, wie gut die Softwareentwicklung bereits Risiko-gestützt arbeiten kann, wenn sie es denn darf. Der erste Schritt besteht auch dort darin, jene Assets zu identifizieren, auf die Security-Mängel in der Applikation überhaupt einen sicherheitsbezogenen Einfluss haben können. Um es stark vereinfacht zu sagen: Eine Schwachstelle, die das Unterwandern von Datenbanken eines bestimmten Typs in einer Unternehmensumgebung betrifft, ist zunächst irrelevant, wenn es derartige Datenbanken dort nicht gibt und auch in absehbarer Zeit nicht geben wird. In diesem Fall würde es reichen, das Faktum zu dokumentieren. Was also benötigt wird, ist ein »Threat Model«, ein Bild der überhaupt vorhandenen Bedrohungen.

Bedrohungsanalyse im Entwicklungsprozess

Existiert dieses Bild, kann ein gezielteres, orchestriertes und Kontext-bezogenes Testen der Software erfolgen. Methoden, die dabei zum Zuge kommen sind:

• SAST: Die Abkürzung steht für »Static Application Security Testing«, übersetzt etwa »statische Software-Tests.« Dabei wird der Code als Text untersucht, also nicht während der Laufzeit. Analysen dieser Art können sehr frühzeitig im Entwicklungsprojekt erfolgen, so dass aufgefundene Verwundbarkeiten nicht später mit dann bereits erhöhtem Aufwand und unabsehbaren Folgeaktivitäten beseitigt werden müssen. Typische Punkte, nach denen SAST fahndet, sind Einschleusungspunkte für Malware oder Fehler, die ein vom Programmierer nicht erwünschtes Kommunikationsverhalten des Codes möglich machen. Kennt man dabei bereits die denkbaren Interaktionspartner des Codes in der Ziel-Umgebung, lässt sich die Zahl der relevanten und damit zu beseitigenden Fehler nach der Analyse signifikant einschränken.
• DAST: Dieses Akronym steht für »Dynamic Application Security Testing«. Es beschreibt dynamische Tests, bei denen ein Prüfungswerkzeug mit der Software interagiert und dabei Angriffe simuliert. Für den Scanner ist die Software selbst dabei nicht offen, er betrachtet sie als »Black Box« und richtet sein Augenmerk auf das Verhalten seines Untersuchungsgegenstands. Somit ist dem Testsystem auch gleichgültig, in welcher Sprache und nach welchen Modellen die jeweilige Software entwickelt wird. Auch hier lässt sich unmittelbar erkennen, wie sich irrelevante Ergebnisse reduzieren lassen: Angriffe, die in der Zielumgebung keinen Sinn ergeben, müssen auch nicht simuliert werden.
• SCA: Die »Software Composition Analysis« (Analyse der Software-Zusammensetzung) zielt primär auf Open-Source-Module, die in Entwicklungsprojekten zur Beschleunigung des Herstellungsverfahrens verwendet werden. SCA findet entsprechende Module auf, zeigt eventuelle Lizenzen, listet bekannte Verwundbarkeiten und macht die Abhängigkeiten sichtbar, die zwischen den Modulen und anderen Code-Bestandteilen existieren. Auch hier lässt sich gut aussortieren, was im jeweiligen Kontext von Bedeutung ist und was nicht.

Kombiniert man die aufgelisteten Test-Ansätze geschickt und integriert sie in den Entwicklungsprozess so, dass sie nicht disruptiv wirken, sondern den Programmierern in der jeweiligen Projektphase tatsächlich helfen, kann Software zugleich schnell und hinreichend, weil am tatsächlichen Risikolevel orientiert erfolgen.

Inzwischen gibt es spezialisierte Werkzeuge, die das entsprechende, in den Entwicklungsvorgang integrierte Vorgehen unterstützen und praxisgerecht »orchestrieren«. Die Toolsets sorgen dafür, dass die jeweils richtige Testmethode zur jeweils richtigen Zeit zum Einsatz kommt, um unerwünschte Projektrückschritte so weit wie möglich auszuschließen. Außerdem fördern die kombinierten Werkzeuge das risiko- und kontext-orientierte Vorgehen bei der Priorisierung und Behebung von Schwachstellen. Damit bieten die Tools die Möglichkeit, echtes »Informations-Sicherheits-Management« mit dem Ziel umsetzbarer, angemessener und ausreichender Maßnahmen auch auf den Sektor der Software-Entwicklung auszudehnen. Den Schritt, auch die entsprechende Praxis durchzusetzen, müssen die Anwender allerdings selbst gehen.

Gunnar Braun, Synopsys