Seite 2: Sicher entwickeln

Inhaltsverzeichnis

Abseits von Tools können Projekte den Entwicklungsprozess anpassen, indem sie "Threat Modeling" einsetzen. Nicht zuletzt wegen der DSGVO ist das ein essenzieller Aspekt der Anforderungsanalyse, auch in agilen Projekten. Dabei versucht man letztlich Sicherheitsziele auf Risiken und Eintrittswahrscheinlichkeiten zu mappen. Ein guter Ausgangspunkt sind die STRIDE-Kategorien:

Angriff	Vorgehen	Verletztes Prinzip
Repudiation	Ablehnung von Fakten	Non-Repudiation
Information disclosure	Unbefugter Zugriff auf Informationen	Confidentiality
Denial of service	Nutzung einschränken oder verhindern	Availability
Elevation of privilege	Erschleichung von höheren Privilegien	Authenticity

Gerade bei Architekturentscheidungen ist es wichtig, das Thema Security auf dem Radar zu haben. Wem Stride zu trocken ist, dem kann Cornucopia von OWASP als Kartenspiel weiterhelfen, um unter dem Aspekt der Gamification dem Thema mehr Schwung zu geben. Ein nächster Schritt, um technische Aspekte bei den Anforderungen sinnvoll zu beleuchten, können die OWASP Top Ten sein: Dieses Awareness-Dokument zeigt, wo Application Security anfängt. Die letzte Aktualisierung von 2017 hat einige interessante Anpassungen erfahren:

Diese zeigen, dass vor allem die Ausnutzung unzureichender Absicherung (A6 auf A3 vorgerückt, sowie A5 und A9) die größten Angriffsvektoren bieten. Der Punkt A10 zum Thema Logging ist neu hinzugekommen und vor allem in Microservice-Architekturen oft vernachlässigt. Mit DSGVO hat das Thema aber in den letzten Monaten mehr Beachtung bekommen.

Die OWASP Top 10 kann man insoweit als Best Practice für den Bereich Websicherheit ansehen, die in der Fachwelt großen Zuspruch bekommt. Ergänzend lässt sich das Proactive-Controls-Dokument nutzen, um ein gewisses Maß an Basiswissen bezüglich Sicherheit zu vermitteln.

Außerdem können die Application Security Verification Standards (ASVS) helfen, Akzeptanzkriterien zu definieren. Dabei legt ASVS drei Stufen fest, wobei der Risiko-Level abnimmt:

ASVS setzt auf den Top Ten auf: Stufe 1 deckt die Top Ten soweit ab. Damit eignet sich dieser Standard bestens, um seine Anforderungen zu verifizieren. Er beschreibt für 19 Kategorien, welche Punkte man abarbeiten muss. Zu den Kategorien gehören zum Beispiel Architektur, Authentifizierung und Zugangskontrolle. Es ist generell zu empfehlen, Stufe 2 umzusetzen. Die dritte Stufe ist eher für kritische Bereiche wie Flughäfen, Medizin oder andere streng regulierte Einsatzgebiete gedacht.

Gerade aufgrund der DSGVO haben Sicherheitsaspekte zunehmend mehr Einfluss auf die Architektur. So gibt es Konzepte wie "Crypto Delete", um die ausufernde Verwendung personenbezogener Daten zu vermeiden.

Security überall

Static Application Security Testing (SAST) lässt sich als erster Schritt gut in eine Build Pipeline einbetten, um eine statische Analyse des Quellcodes durchzuführen. Man muss aber gar nicht mit kommerziellen Tools loslegen, um Security zu implementieren. Es gibt mittlerweile gute Open-Source-Werkzeuge: Das Node Security Project hat beispielsweise seinen Weg direkt in npm (setzt mindestens Version 6 voraus) gefunden, um die Prüfung der Abhängigkeiten auf bekannte Schwachstellen zu automatisieren:

$ npm audit
            === npm audit security report ===

# Run  npm install --save-dev node-mock-server@0.23.5  to resolve 1 vulnerability
???????????????????????????????????????????????????????????
? High          ? Remote Code Execution                   ?
???????????????????????????????????????????????????????????
? Package       ? react-dev-utils                         ?
???????????????????????????????????????????????????????????
? Dependency of ? node-mock-server [dev]                  ?
???????????????????????????????????????????????????????????
? Path          ? node-mock-server > react-dev-utils      ?
???????????????????????????????????????????????????????????
? More info     ? https://nodesecurity.io/advisories/695  ?
???????????????????????????????????????????????????????????
...

In den meisten Fällen genügt ein einfaches npm audit fix, um gepatchte Versionen der Abhängigkeiten zu installieren. Reicht das nicht aus, macht npm direkt Vorschläge (s. o.).

In der Java-Welt bietet sich das OWASP Dependency Check Plugin an. Es ist für Ant, Gradle und Maven verfügbar und prüft alle Abhängigkeiten gegen die CVE-Datenbank:

[ERROR] Failed to execute goal org.owasp:dependency-check-maven:1.4.0:check (default) ...
[ERROR]
[ERROR] Dependency-Check Failure:
[ERROR] One or more dependencies were identified with vulnerabilities
        that have a CVSS score greater then '5.0':
[ERROR] commons-httpclient-3.1.jar: CVE-2014-3577
[ERROR] mysql-connector-java-5.1.37.jar: CVE-2014-0001, CVE-2013-2378,  ....
[ERROR] tomcat-embed-core-8.0.33.jar: CVE-2016-3092, CVE-2013-2185, CVE-2002-0493

Neben Ausnahmen kann man einen Schwellwert (CVSS Score) festlegen, ab dem der Build fehlschlagen soll. Hier bietet es sich an, gegebenenfalls mit höheren Werten zu arbeiten. Zwar ist ein niedriger CVSS Score erstrebenswert, da dann weniger gefährliche Schwachstellen erlaubt sind, aber gerade am Anfang sollte man sich langsam herantasten, um nicht den Frust auf Entwicklungsseite zu hoch zu schaukeln. Gerade in modernen Microservice-Architekturen ist Docker mittlerweile unverzichtbar geworden. Deswegen sollten auch Docker-Images auf Schwachstellen gescannt werden. Dazu lassen sich Werkzeuge wie Clair nutzen. Sie lassen sich auch direkt in Docker Registries integrieren.

In weiteren Schritten können Analysewerkzeuge wie Sonar mit FindBugs beziehungsweise SpotBugs inklusive des Find-Security-Bugs-Plug-ins genutzt werden, um weitere Sicherheitsaspekte zu prüfen:

Im letzten Schritt lässt sich nun Dynamic Application Security Testing (DAST) umsetzen: Dazu wird die Anwendung deployt und mit Tools wie OWASP ZAP im Ganzen auf Schwachstellen geprüft. ZAP kann genutzt werden, um die Anwendung auf Verwundbarkeit durch unter anderem Cross-Site Scripting und SQL-Injection zu testen. Das Tool läuft dabei als Proxy zum Beispiel in Selenium-Tests mit und kann die HTTP-Requests überprüfen. Zusätzlich lassen sich Tools wie Nessus und OpenVAS nutzen, um im Rahmen von Integrations-Tests auf Schwachstellen zu scannen. Um ein einheitliches Reporting aller sicherheitsrelevanten Informationen in JIRA zu ermöglichen, können Entwickler ThreadFix verwenden. Es kann diverse Sicherheitsergebnisse aggregieren, unter anderen OWASP Dependency Check, ZAP, Sonatype Nexus und die BurpSuite.