Die Vorteile automatisierter Software-Tests Security-Testing-Methoden im Vergleich

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Arvato Systems

Moxa Europe GmbH

Manuelle Security- und Penetration-Tests sind den Unmengen an Code, die täglich produziert werden, längst nicht mehr gewachsen. Automatisiertes Software-Testing kann Abhilfe schaffen, dieser Beitrag nennt Vor- und Nachteile der verschiedenen Methoden und Ansätze.

Automatisiertes Security-Testing stellt sicher, dass die ausgelieferten Applikationen den Qualitäts- und Sicherheitsanforderungen der Auftraggeber und User entsprechen. Mit Static, Dynamic, Interactive und Feedback-based Application Security Testing gibt es verschiedene Ansätze, wie sich dies realisieren lässt.

Bevor wir uns näher mit SAST, DAST, IAST und FAST beschäftigen, gehe ich auf die Notwendigkeit der frühen Fehlerentdeckung ein, welche auf der 10er-Regel (Rule-of-ten) basiert: Je weiter sich eine unentdeckte Sicherheitslücke oder ein Bug im Rahmen der Softwareentwicklung in Richtung Release bewegt, desto teurer wird die Beseitigung – und zwar pro „überlebter“ Stufe um den Faktor 10.

Diese exponentielle Zunahme an Kosten- und Programmierungsaufwand multipliziert sich mit der Anzahl der unentdeckten Bugs, die abhängig vom Entwicklungsumfang das gesamte Projekt gefährden können. Dementsprechend ist es kosteneffizient, die Fehlerentdeckung und -beseitigung möglichst in der Development-Phase anzusiedeln.

Auf diese (für moderne Testing-Lösungen entscheidenden) Voraussetzungen gehe ich aber später noch genauer ein. Schauen wir uns zunächst die verschiedenen Methoden und deren Pro- und Contra-Bilanz an.

SAST

„Static Application Security Testing“ blickt bereits auf eine längere Historie im Bereich der Applikationsentwicklung zurück. Ein Analyzer betrachtet dabei den gesamten Quellcode einer Software, ohne ihn tatsächlich auszuführen. Diese „nur anschauen, nicht anfassen“-Vorgehensweise bietet einen wichtigen Vorteil: SAST lässt sich bereits in einem sehr frühen Entwicklungsstadium anwenden, da der zu überprüfende Programmquellcode noch nicht vollständig ausführbar sein muss.

Aus diesem Ansatz speisen sich aber auch drei erhebliche Nachteile: Erstens wird der Code nur angeschaut, nicht aber ausgeführt, und mithilfe von Heuristiken werden potenziell verdächtige Zeilen markiert. Diese Methodik produziert aufgrund des fehlenden logischen Kontextes Hunderte ggf. sogar Tausende von „False Positives”. Diese hohe Anzahl an Falschmeldungen führt entweder zu einem extrem hohen Aufwand für die prüfenden Entwickler oder dazu, dass diese viele Meldungen nicht überprüfen. Somit bleiben viele Fehler unentdeckt.

Dies wiederum hat den zweiten großen Nachteil zur Folge: Durch die hohe Anzahl an Falschmeldungen werden SAST-Lösungen von Entwicklern als lästig angesehen und nur ungern eingesetzt. Oft werden deshalb externe Sicherheitsspezialisten bzw. Pentester engagiert. Diese werden jedoch nur sporadisch eingesetzt, womit der vermeintliche Vorteil, dass SAST während der Entwicklung genutzt wird, verloren geht.

Der dritte Nachteil ist, dass sich SAST mit Libraries und komplexen Frameworks (wie z.B. WebFrameworks inkl. eigener Sanitizer-Funktionen) ziemlich schwer tut. Diese finden sich jedoch gerade in modernen Applikationen immer häufiger. Verfügt das Testing-Team nicht über den direkten Zugriff auf den gesamten Quellcode, lässt sich SAST nur bedingt sinnvoll einsetzen bzw. nur mit viel manuellem Tuning ermöglichen. Insgesamt wird das vergleichsweise unbeliebte SAST also gerne outgesourced, um die eigenen Entwickler für andere Aufgaben verwenden zu können.

DAST

„Dynamic Application Security Testing“ verfolgt einen komplett anderen Ansatz: Der Namensbestandteil „Dynamic“ verrät bereits, dass diese automatisierte Testmethode die Applikation ausführt und durch bestimmte Eingaben prüft, ob sich die Software wie erwartet verhält, abweicht oder sogar abstürzt.

DAST bietet den Vorteil, dass nur vergleichsweise wenige bis gar keine False Positives registriert werden, da sich Fehlermeldungen auf das Programmverhalten beziehen und nicht auf statische Code-Muster. Aus diesem Ansatz ergeben sich dennoch Nachteile: Der Code kann selbst bei vollem Zugriff nicht in seiner Gesamtheit überprüft werden. Die Randomisierung der Eingabeparameter kann zwar intelligent gesteuert werden, aber eine Garantie, dass alle erdenklichen Programmpfade gefunden wurden, gibt es nicht.

Durch die vorherige Festlegung von Eingabegrammatiken kann eine höhere Codeabdeckung erzielt werden. Allerdings verursacht dies, ebenso wie die nicht überprüften Pfade, zusätzlichen manuellen Aufwand. Ferner benötigt man zur Durchführung von DAST-Durchläufen eine eigene Testinfrastruktur und eine entsprechende Customization. Die Interpretation der Fehlermeldungen und die Zuordnung der entsprechenden Codezeilen ist ebenfalls vergleichsweise kompliziert und aufwendig.

IAST

Hinter „Interactive Application Security Testing“ verbirgt sich meiner Einschätzung nach keine wirkliche Innovation oder Weiterentwicklung. Es handelt sich schlichtweg um einen Marketingbegriff. Gemeint ist DAST mit einer Integration in die CI/CD sowie einer Instrumentierung zur Fehlererkennung.

Die Instrumentierung fügt dem getesteten Code Checks hinzu, um bestimmte Arten von Fehlern zur Laufzeit zu erkennen. Diese Checks überprüfen den konkreten Zustand des Programms, während es mit einer bestimmten Eingabe ausgeführt wird. Angeblich soll IAST die Vorteile von SAST und DAST kombinieren und die Nachteile eliminieren.

Aktuelle IAST-Lösungen haben jedoch immer noch einen großen Nachteil: Sie setzen entweder die Definition guter Testfälle voraus oder benutzen Randomisierung, die von der DAST-Engine generiert wird. Dies hat zur Folge, dass entweder nicht genug Eingaben für eine umfangreiche Code Abdeckung generiert werden oder viele False Positives in Kauf genommen werden müssen.

Trotz der Vorteile die IAST verspricht, existiert meines Wissens nach noch keine Lösung, die False Positives eines SAST-Durchlaufs durch eine darauffolgende DAST-Analyse zufriedenstellend und wirtschaftlich realisierbar aussortiert. Vielmehr präsentiert sich IAST lediglich als Unterkategorie von DAST, welche speziell für den Einsatz bei Applikationen geeignet ist, deren Quellcode komplett zur Verfügung steht.

FAST

„Feedback-based Application Security Testing“ stellt hingegen einen echten Fortschritt dar und vereinfacht die effektive Fehlersuche durch den Einsatz automatisierter Software-Tests erheblich. FAST gliedert sich thematisch ebenfalls unter den Oberbegriff DAST ein, umfasst aber wesentliche Verbesserungen.

Wenn es darum ging, möglichst umfassende Informationen zu generierten Bugs zu erhalten, waren bisherige DAST-Ansätze auf Blackbox-Ebene eher unzuverlässig. Da DASTs ohne Quellcode-Zugriff eher eine oberflächliche Codeebene betrachten können, bleiben zahlreiche Bugs auf tieferen Levels unentdeckt. Dadurch leidet insbesondere die Zuordnung des erzeugten Bugs zur entsprechenden Programmzeile.

Feedback-basiertes Software-Testing nutzt aktuelle und ausgereifte Fuzzing-Tools, um für jeden einzelnen Input genaue Informationen zum betreffenden Codeabschnitt zu erhalten. Der Algorithmus der Mutation-Engines lernt durch jedes Feedback dazu und verbessert die Qualität der nächsten „Input-Welle“. Durch die kontinuierliche und feedback-getriebene Optimierung dringt FAST auch in tiefere Codeebenen vor und sorgt für wesentlich bessere und aussagekräftigere Ergebnisse.

Diese Feedbackschleife hilft dem Fuzzer, die Struktur der erwarteten Eingaben automatisch zu lernen und dadurch neue Eingaben zu generieren, die daraufhin neue Programmabläufe triggern. Das erhöht die Wahrscheinlichkeit Bugs zu identifizieren. Die Durchführung von FAST-Testläufen ist anspruchsvoll, allerdings gibt es kommerzielle Tools wie z.B. CI Fuzz, die dem Entwickler den Großteil der manuellen Arbeit abnehmen.

Der Feedback-Mechanismus gibt während des Testdurchlaufs die Richtung vor, weshalb menschliches Eingreifen kaum noch erforderlich ist. Der FAST-Ansatz beinhaltet nicht nur eine möglichst frühe Fehlersuche, um Aufwand und Kosten so gering wie möglich zu halten (siehe 10er-Regel), sondern sieht ebenfalls vor, das Fuzz-Tests bei jeder nachfolgenden Codeänderung vollkommen automatisiert durchgeführt werden. Damit erfolgt die Qualitätsverbesserung der Software in einem kontinuierlichen Kreislauf.

Fazit FAST

Zwar kann auch FAST nicht garantieren, dass alle möglichen Programmpfade „abgearbeitet“ werden – nichtsdestotrotz deckt das Feedback-basierte und automatisierte Software-Testing einen deutlich höheren Codeumfang ab als herkömmliche DAST-Lösungen. Die Integration von selbstlernenden und sich kontinuierlich optimierenden Prüfprozessen hebt FAST somit von den bisher dominierenden Verfahren ab.

Das nahtlose Einfügen der Fuzz-Lösung in bestehende Standard-CI-/CD-Workflows erleichtert es Entwicklern, ihre Applikationen schneller und gründlicher von Bugs zu befreien und somit zügiger eine akzeptable Marktreife zu erlangen. Wertvolle Ressourcen werden direkt von Beginn der Entwicklungsphase an eingespart und die fachlichen Ansprüche an das Testing-Team bewegen sich auf einem angenehm einfachen Niveau.

* Sergej Dechand ist CEO und Co-Founder von Code Intelligence. Zuvor arbeitete er als Projektleiter für das Industrial Data Space Projekt am Fraunhofer-Institut FKIE. Er hat einschlägige Erfahrungen als externer Softwareentwickler und IT-Berater in der Nutzfahrzeugentwicklung der Volkswagen AG gesammelt. Neben seinen Aufgaben bei Code Intelligence ist er aktiv an der Forschung im Bereich der Usable Security an der Rheinischen Friedrich-Wilhelms-Universität Bonn eingebunden, wo er auch als Dozent tätig ist.

(ID:46759504)