Startseite > Embedded > Hardware > Sicherheit mit OWASP

Für Industrie-Applikationen

Sicherheit mit OWASP

17. Juli 2019, 10:34 Uhr | Von Arthur Hicken, Chief Evangelist von Parasoft

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Dependency Check

Zu beachten ist: Der Eintrag A9 in den OWASP Top 10 unterscheidet sich grundlegend von den anderen und eignet sich nicht für SAST oder DAST (Dynamic Application-Security-Testing), denn hier geht es um die Suche nach bekannten Schwachstellen im Open-Source-Bereich und nicht um das Aufdecken neuer Sicherheitslücken. Hierfür hält OWASP glücklicherweise ein kostenloses Tool namens OWASP Dependency Check bereit. Dieses Tool ist ein Hilfsmittel, das Projektabhängigkeiten entdeckt und überprüft, ob es irgendwelche bekannten, öffentlich publizierten Schwachstellen gibt. Dependency Check kann derzeit genutzt werden, um Applikationen (und ihre abhängigen Bibliotheken) abzuscannen und so zu überprüfen, ob sie irgendwelche bekanntermaßen anfälligen Komponenten enthalten.

Die Eleganz der statischen Analyse liegt darin, dass nicht die gesamte Applikation oder das ganze System fertiggestellt sein muss, sodass man in einer wesentlich früheren Phase des Zyklus mit der Überprüfung auf Sicherheitsprobleme beginnen kann (zeitliche Vorverlegung der Sicherheitstests). Befasst man sich mit dem Thema Security erst spät oder ganz am Ende der Entwicklung (DevOpsSec), so 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 Aufsehen zu erregen, indem sie beispielsweise hunderte oder gar tausende Regelverletzungen aufzeigt, obwohl man gerade gedacht hat, man wäre fertig für die Freigabe. Zum Glück gibt es einige richtig gute Strategien, um hiermit umzugehen. Diese Dinge sollte man im Kopf behalten:

Sicherheitstests nicht bis zum Schluss aufsparen – es empfiehlt sich, mit den statischen Analysen zu starten, sobald man mit dem Codieren 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. Darum sollte man 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.
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 ist sinnvoll, sich nur mit diesen zu befassen und niemals Ausschau nach Problemen zu halten, deren Beseitigung ohnehin nicht geplant ist.
Das Alter des Codes – der mittlerweile uralte Grundsatz „If it ain’t broken, don’t fix it” (Nichts reparieren, was nicht kaputt ist) sollte auch auf Bestands-Code angewandt werden. Das heißt: Älteren Code nur mit den wichtigsten Security-Scannern prüfen. Kleinere Probleme bedeuten nur eine Zeitverschwendung, und die damit einhergehenden Änderungen bergen ihrerseits Risiken. 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.