Application Security Testing – was gilt es zu beachten?

Das Ausnutzen von Schwachstellen in Applikationen und APIs ist nach wie vor ein Hauptgrund für viele Breaches. Es gibt jedoch gute Methoden, um Schwachstellen frühzeitig zu erkennen und ein solches Szenario zu verhindern.

In diesem Artikel werde ich das Thema Application Security Testing etwas genauer beleuchten und darauf eingehen, wie diese bereits vor einem «Go-live» im «Software Development Life Cycle» (SDLC) integriert werden können. Das Testing sollte grundsätzlich so früh wie möglich im Entwicklungsprozess beginnen und nicht erst kurz vor der Produktivnahme, umso wichtiger wird dieser Aspekt mit moderneren Entwicklungsansätzen wie «continuous integration/continuous delivery (CI/CD)».

Application Security Testing Methoden

Folgende Test-Methoden haben sich in den letzten Jahren bewährt und sind in Unternehmen in verschiedenen Ausprägungen im Einsatz.

- Static Application Security Testing (SAST)
  - Statische Analyse des Quellcodes einer Applikation auf Basis von Techniken wie Execution Flow, Expression Matching etc.
- Dynamic Application Security Testing (DAST)
  - Dynamische Analyse der Applikation zur Laufzeit, die ein böswilliges Verhalten eines Angreifers simulieren
- Interactive Application Security Testing (IAST)
  - Interaktives Testing kombiniert die Analyse-Techniken von statischem und dynamischem Testing, häufig werden Agenten auf den Applikationsservern vorausgesetzt
- Software Composition Analysis (SCA)
  - Automatisierte Identifikation von Open Source/Drittanbieter-Bibliotheken und deren Schwachstellen
- Penetration Testing (Pentesting)
  - Manuelle Analyse der Applikation mit vergleichbaren Methoden, die auch ein Angreifer einsetzen würde

Welche Testing-Methoden optimalerweise zum Einsatz kommen, wird u.a. durch folgende Faktoren massgeblich beeinflusst:

- Zu erreichender Sicherheitslevel – Individueller Risikoappetit
- Unterstützung der eingesetzten Programmiersprachen und Laufzeitumgebungen
- Integrationsmöglichkeiten in die Entwicklungsprozesse und CI/CD Pipeline
- Spezifische Compliance Anforderungen
- Budget

In der Praxis sieht man oft eine Kombination von SAST, DAST, IAST, SCA und Pentesting, um eine gute Abdeckung zu erreichen.

Einordnung der Testing-Methoden im Lebenszyklus der Applikation

Der Lebenzyklus einer Applikation kann grob in drei Phasen aufgeteilt werden, die nachfolgende Tabelle zeigt dabei welche Testing-Methoden sich zu welchem Zeitpunkt eignen:

Phase	Testing-Methode
In Entwicklung	SAST (IDE integriert) SAST (regelmässig und/oder im Build Prozess) SCA (regelmässig und/oder im Build Prozess) DAST/IAST (optional; ggf. im System Testing)
Vor der Produktivnahme	SAST (Überprüfung der finalen Version) SCA (Überprüfung der finalen Version) DAST/IAST (im Quality Testing) Penetration Testing (vor dem Release)
In Produktion	SAST (mindestens einmal jährlich) DAST (regelmässig) SCA (regelmässig) Penetration Testing (mindestens einmal jährlich)

Im Prinzip gibt es keine richtige oder falsche Variante und jedes Unternehmen wird dies etwas anders, dem eigenen Risikoappetit entsprechend, handhaben. Wichtig ist aus meiner Sicht, dass das Testing für die Entwickler transparent bzw. automatisiert stattfindet und die Abläufe so wenig wie möglich verkompliziert werden. Agile Teams sind heute darauf ausgelegt, in kurzen Iterationen neue Funktionen (Code) in die Produktion zu bringen und das Security Testing sollte hier ein selbstverständlicher, integraler Bestandteil sein.

Reicht das Budget für ein breiter angelegtes Application Security Testing nicht aus, empfiehlt es sich, risikobasiert zumindest kritische sowie im Internet exponierte Applikationen vor der Inbetriebnahme und danach sporadisch, z.B. bei grösseren Änderungen, ausführlich zu testen.

Secure Coding Standards

Besser als Schwachstellen zu beheben, wenn sie im Security Testing erkannt werden, ist es, diese gar nicht erst entstehen zu lassen. Standards zur sicheren Entwicklung sollten deshalb in jedem Unternehmen, welches Applikationen selbst entwickelt, definiert und trainiert werden. Es gibt in diesem Bereich Publikationen von OWASP wie der OWASP Secure Coding Practices-Quick Reference Guide, der BSI Leitfaden zur Entwicklung sicherer Webanwendungen oder die NIST Standards der 800er Reihe. Zusätzlich stellen viele Hersteller spezifischere Checklisten und Guidelines, wie z.B. von Apple die Apple Security Development Checkliste oder von Oracle die Secure Coding Guidelines for Java, zur Verfügung.

Vergleichbarkeit und Aggregation der Schwachstellen

Alle identifizierten Schwachstellen sollten eine systematische Einstufung erhalten, damit sie auch über die verschiedenen Testing-Methoden hinweg vergleichbar sind. Diesbezüglich hat sich das CVSS (Common Vulnerability Scoring System), welches auf Basis von verschiedenen Faktoren einen Schweregrad von 0.0 bis 10.0 ermittelt, in der Praxis bewährt und sich mittlerweile als de-facto Standard etabliert. Anschliessend kann z.B. auf Basis der qualitativen Risiko Levels von NIST (National Institute of Standards and Technologie) eine erste Risikoeinschätzung entlang folgender Stufen vorgenommen werden; 10.0 – critical, 7.0-9.9 – high, 4.0-6.9 – medium und 0.0-3.9 – low.

Führt man ein Application Security Testing ein, muss zu Beginn mit einer höheren Anzahl an identifizierten Schwachstellen gerechnet werden. Redundante Findings sind, wenn möglich, durch eine Aggregation pro Applikation zu vermeiden.

Umgang mit eingekaufter Software

Ein besonderes Augenmerk gilt es auch beim Einkauf von Software auf die Sicherheit zu legen. Eingekaufte Software sollte dem Application Security Framework genauso unterliegen, es gibt jedoch einige Einschränkungen. Es ist in den seltensten Fällen möglich auf den Source Code zuzugreifen.

Es lohnt sich frühzeitig im Evaluationsprozess einer neuen Applikation den Software Anbieter anzufragen und entsprechende Evidenzen (Reports etc.) einzufordern.

Mögliche Fragen an den Software Anbieter:

- Existieren Richtlinien für sichere Software-Entwicklung
- Welche Application-Security-Testing-Methoden (z.B. der oben genannten) werden eingesetzt
- Sind Third Party Libraries (z.B. mittels SCA Scans) berücksichtigt
- Werden High- und Critical-Schwachstellen (Minimum) vor einem neuen Software Release behoben
- Ist es möglich die Test-Resultate oder zumindest eine Zusammenfassung davon zu erhalten
- Wie sehen die Prozesse aus bei neu identifizierten Schwachstellen
- Wie werden Kunden über neue Schwachstellen in der Software informiert
- In welchem Zeitraum wird den Kunden ein Patch zur Verfügung gestellt, nach Bekanntwerden einer Schwachstelle

Als Kunde stellt man leider häufig fest, dass die Bereitschaft hinsichtlich Transparenz an diesen Themen nicht bei allen Software Anbietern gleich gut ist. Eine gewisse Hartnäckigkeit zahlt sich oft aus.

Fazit zum Application Security Framework

Praktisch kein Unternehmen kann heutzutage ohne Applikationen den Geschäftsbetrieb aufrechterhalten. Schwachstellen sind vielfältig und sollten keineswegs unterschätzt werden. Ohne die Applikationen regelmässig zu prüfen, befindet man sich in einem Blindflug was die Schwachstellen Situation angeht und kennt somit seine Geschäftsrisiken nicht. Es empfiehlt sich daher das Thema systematisch mit einem Application Security Framework anzugehen und klare Vorgaben zu schaffen, in welchem Umfang und zu welchem Zeitpunkt die Sicherheit getestet werden muss. Die Vorgaben diesbezüglich sind vorzugsweise auf Weisungsebene verankert und werden durch Prozesse mit sogenannten «toll-gates» sichergestellt. Sind die Regelungen zur Behebung der Schwachstellen zu lasch, besteht das Risiko einer «Alibi-Übung». Nicht selten wundert man sich dann, warum Schwachstellen ein Jahr nach der Identifikation bei einem Re-test immer noch vorhanden sind und vielleicht in der Zwischenzeit bereits ausgenutzt wurden.