Sicherheit von Industrial Applikationen mit OWASP

Immer wieder hört man von umfangreichen Datensicherheits-Verletzungen bei Unternehmen jeglicher Größe. Die Häufigkeit und Schwere von Cybersecurity-Problemen nimmt kontinuierlich zu. Es stellt sich die Frage: Wer ist als nächstes betroffen und was kann man dagegen tun? Genau hier setzt OWASP an.

Bild: ©metamorworks/Shutterstock.com

Die offene Community mit kostenlosen Informationen und Schulungen zum Thema Applikationssicherheit ist für seine OWASP Top 10 bekannt, eine Liste mit aktuellen gefährlichen Sicherheitsrisiken für Web-Applikationen. Wer in Sachen Applikationssicherheit bisher noch nicht viel unternommen oder sich auf Ad-hoc-Maßnahmen beschränkt hat, für den sind die OWASP Top 10 ein ausgezeichneter Ansatzpunkt.
OWASP hat ausreichende Dokumentation für die Top 10 vorgelegt und eine Website für jede Schwachstelle von A1 bis A10 eingerichtet. Diese erläutert, worum es sich bei jeder Schwachstelle handelt, und gibt einen Risikowert an, der bei der Priorisierung und Selektierung möglicher Schwachstellen hilft.
In den OWASP Top 10 findet sich eine Unmenge an kostenlos verfügbarer und laufend aktualisierten Informationen, Schulungsmaterial und Ratschlägen. Man erfährt etwas über gängige Sicherheitsprobleme sowie über Strategien, um diese Probleme zu detektieren und teils komplett zu umgehen.
t:Konformität bedeutet auch, dass man genau wissen muss, welches spezielle Element des Toolkits welchen Teil des Standards unterstützt. Im Fall der statischen Analyse weiß man also, welche(r) Checker welche Elemente des Standards unterstützen, und ob es Elemente im Standard gibt, die mehr als die statische Analyse erfordern (z.B. Peer Code Review oder Software Composition Analysis).

Am Ende beginnen
Am einfachsten geht man an das Thema Security heran, indem man am Ende anfängt und externe, in einer späten Phase des Zyklus ansetzende und das gesamte System erfassende Tests einsetzt, wie etwa Penetration-Tests: Diese sind ideal für den Nachweis, dass die Applikation bzw. das System keine der vom OWASP aufgezählten Schwachstellen enthält. Allerdings ist dieses Testen nach dem Blackbox-Prinzip keineswegs die effizienteste Methode zum Produzieren eines Codes, der sicherer ist. Besser ist es also, sich nicht auf Blackbox-Tests zu verlassen, um die Software abzusichern, Bugs aufzudecken oder den Nachweis zu erbringen, dass die Software sicher ist.
Findet man mit Penetration-Tests eine Sicherheitslücke, sollte man sich fragen, warum das so ist, um anschließend der Ursache des Problems auf den Grund zu gehen. Anstatt durch Testen für Sicherheit zu sorgen, sollten Sicherheitskomponenten beim Design gleich mit eingebaut werden.
Hierfür gibt es SAST-Tools mit Support für OWASP, wie zum Beispiel die statische Codeanalyse.

Aber ist SAST nicht ein Ärgernis?
Die Eleganz der statischen Analyse liegt darin, dass man in einer sehr frühen Phase des Zyklus mit der Überprüfung auf Sicherheitsprobleme beginnen kann, etwa durch eine zeitliche Vorverlegung der Sicherheitstests. Befasst man sich mit dem Thema Security erst spät oder ganz am Ende der Entwicklung (DevOpsSec), lässt sich die statische Analyse dafür nutzen, das Thema Security früher zu behandeln, noch bevor die Tests beginnen und während der Code gerade erst geschrieben wird (DevSecOps).
Nachteilig an der statischen Analyse ist ihr Ruf, sehr viel ‚Noise‘ zu produzieren, beispielsweise Hunderte oder gar Tausende Regelverletzungen, obwohl man gerade dachte, man wäre fertig für die Freigabe. Zum Glück gibt es einige gute Strategien, um hiermit umzugehen:
1  Sicherheitstests nicht bis zum Schluss aufsparen. Es empfiehlt sich, mit den statischen Analysen zu starten sobald man mit dem Coding anfängt. Wartet man dagegen ab und führt die statischen Analysen nur im Rahmen der CI/CD-Pipeline aus, so summieren sich zu viele Meldungen und überfordern das Entwicklungsteam. Man sollte also die Analyse am Desktop laufen lassen, um Probleme zu finden, und sie im CI/CD-Kontext ausführen, um einfach zu verifizieren, dass der Code korrekt erstellt wurde.
2  Feinabstimmung an der Konfiguration. Einige statische Analyse-Checker sind im Kontext des Codes vielleicht gar nicht erforderlich. Man sollte die Applikation prüfen und entscheiden, welche Sicherheitsrisiken relevant sind. Es macht Sinn, sich nur mit diesen zu befassen und niemals Ausschau nach Problemen zu halten, deren Beseitigung ohnehin nicht geplant ist.
3

Das Alter des Codes. Der mittlerweile uralte Grundsatz ‚If it ain’t broken, don’t fix it‘ sollte auch auf Bestandscode angewandt werden. Das heißt: Ältere Codes nur mit den wichtigsten Security-Scannern prüfen. Kleinere Probleme bedeuten nur Zeitverschwendung, und die damit einhergehenden Änderungen bergen ihrerseits Risiken. Ein Code, den man nicht zu reparieren beabsichtigt, sollte auch nicht geprüft werden.
Es geht um die Risiken. SAST-Tools decken sowohl reale als auch potenzielle Schwachstellen auf, allerdings ist nicht mit allen Resultaten das gleiche potenzielle Risiko verbunden. OWASP hat hier geholfen, indem für jeden Eintrag in der Top-10-Liste das Risiko im Hinblick darauf definiert wurde, wie einfach sich eine Schwachstelle ausnutzen lässt, wie leicht die Schwachstelle zu entdecken ist und welche tatsächlichen Folgewirkungen ein Exploit haben kann.

Bild: Parasoft Deutschland GmbH

Vermeidung ist wirkungsvoll
Möchte man seine Applikation wirklich abhärten, kommt hier ein wichtiger Hinweis: Auf Sicherheit zu testen, ist wesentlich einfacher als Sicherheit mit einzubauen. Zum Glück werden statische Analyse-Checker in den verschiedensten Varianten angeboten. Einige halten Ausschau nach typischen Problemen wie etwa ‚tainted data‘ und versuchen herauszufinden, ob die Applikation einen Ablauf enthält, bei dem dieses Problem vorkommen kann. Dies sind die gängigsten Checker vieler SAST-Tools. Der größere Nutzen von statischen Codeanalysen liegt jedoch in Checkern, die zwei ganz besondere Dinge durchsetzen:
1  Ein Muster, mit dem es in der Vergangenheit wiederholt Probleme gab. Dies mag zwar nicht so interessant aussehen wie ein bestimmter, zu einem Exploit hinführender Stack-Trace. Aber es kann wesentlich gründlicher sein, einfach alles zu reparieren, das schwächer ist als es sein sollte, anstatt sich bei der Reparatur auf solche Probleme zu beschränken, für die es einen erwiesenen Angriffsvektor gibt.
2  Anforderungen bestimmter Codierungsweisen, um eine einwandfreie Funktion zu gewährleisten. Automobil- und Luftfahrt-Normen wie MISRA oder JSF bedienen sich dieser Technik, um die funktionale Sicherheit zu gewährleisten. Die gleiche Technik, nicht nur einen schlechten Code zu melden, sondern einen guten Code zu verlangen, ist beim Erstellen sichererer Applikationen hilfreich.
Hat man sich nie mit dem Thema Security auseinandergesetzt, wird die Umsetzung der OWASP Top 10 nicht einfach, aber möglich ist sie. DAST ist eine einfache Möglichkeit, mit den Top 10 anzufangen, und SAST hilft anschließend bei der zeitlichen Vorverlegung der Security-Tests. Richtig implementiert, kann SAST sogar Probleme vermeiden und nicht nur detektieren. Es ist also sinnvoll nach Tools Ausschau zu halten, die den Standard mit Detektierung und präventiven Checkern vollständig abdecken. Es lohnt sich, die richtige Nutzung der OWASP-Risikobewertung zu lernen, denn sie liefert wertvolle Hilfestellung bei der Priorisierung der Ergebnisse und um sicherzustellen, dass die Tools diese Risikoinformationen zusammen mit den Resultaten ausgeben. Dies hilft, um sich auf das Wesentliche zu konzentrieren, und ist entscheidend für eine erfolgreiche OWASP-Implementierung. Mit diesen Tipps sollte man in der Lage sein, sofort mit der Beseitigung der verbreitetsten und gefährlichsten Sicherheitsrisiken für Web-/Industrial-Applikationen zu beginnen.