Security-Instrumentierung in der Entwicklung

Der Scan-Vorgang selbst kann die Entwicklung, die Qualitätssicherung und die Überführung in den Betrieb unnötig aufhalten. Da Code nicht ausgeführt wird gilt es, alle möglichen Kombinationen von Eintrittspunkten in die Applikation auf vielen Pfaden zu berechnen. Das ist sehr komplex, zeitintensiv und schließt falsche Ergebnisse nicht aus. Für DAST müssen diverse Tests erst vorkonfiguriert werden und spezielles Tool Know-how ist vonnöten.

Jenseits von Applikationen, wenn es etwa um APIs und Microservices (REST/JSON, SOAP/XML) geht, sind SAST und DAST auch nicht erfolgreicher. Wie kann ein DAST-Scanner automatisch wissen, wie korrekte Anfragen auszusehen haben und ob ein HTTP-500-Fehler auf eine SQL Injection oder einen Crash der Anwendung zurückzuführen ist? SAST ist ohne vorhandenen Code, beispielsweise durch den Einsatz von Open-Source-Bibliotheken oder gegebenenfalls Legacy-Applikationen, überhaupt nicht einsetzbar. Die Methode erfordert es, weitere Lösungen für die Softwarekomponenten-Analyse einzusetzen und zu integrieren.

Testergebnisse und Qualitätsaussagen für diverse SAST- und DAST-Tools lassen sich mit Hilfe des OWASP-Benchmarks ermitteln. Ergebnisse für spezielle Herstellerwerkzeuge werden jedoch nicht veröffentlicht. Die selbst ermittelten Ergebnisse unterstreichen oben genannte Herausforderungen, insbesondere im Bereich False Positives.

Alternative Ansätze aus dem Monitoring

Die Analysten von Gartner listen in ihrem Magic Quadrant für Application Security Testing Produkte, die alternative Ansätze zu Code-Scannern bieten, als Visionäre und stuft sie als geeignet für AgileAgile und DevOpsDevOps ein. Mit ihnen lassen sich Sicherheitslücken in Web-Applikationen bei wenigen False Positives erkennen. Damit können Risiken wie die der OWASP Top 10 vermeiden, Zeit eingespart und Fehler früher gefunden werden. Alles zu Agile auf CIO.de Alles zu DevOps auf CIO.de

Ein solcher Ansatz ist das kontinuierliche Security Testing mittels Instrumentierung von Applikationen während der Entwicklung, Qualitätssicherung und dem Betrieb. Hersteller für Application Performance Monitoring (APM) wie New Relic und AppDynamics setzen Instrumentierung bereits ein, um eine Leistungsüberprüfung von Anwendungen durchzuführen. Das Prinzip wird bereits seit Jahren erfolgreich in der Cloud oder on-premise für viele Applikationen eingesetzt und stellt ein etabliertes Verfahren dar.

Knapp umschrieben wird Code mit geringem Overhead automatisch in Applikationen injiziert ohne vorab umfangreiche Konfigurationen vorzunehmen. Der APM-Software ist bekannt, was sie zu tun hat und wo Code einzufügen ist, um entsprechende Leistungsdaten zur Laufzeit oder während Tests zu extrahieren.

Interactive Application Security Testing

Diese Vorgehensweise lässt sich auf Anwendungssicherheit übertragen. In diesem Fall wird eine spezifische Instrumentierung vorgenommen, um Sicherheitslücken aufzudecken. Auch hier gilt es, den Overhead gering zu halten sowie die Anwendungsqualität und -geschwindigkeit nicht zu beeinträchtigen. Voraussetzung dafür ist, dass die instrumentierte Applikation ausgeführt wird. Dieses sogenannte Interactive Application Security Testing (IAST) ermöglicht, Sicherheitslücken in Echtzeit aufzudecken ohne Mehraufwand für Continuous-Integration- und Continuous-Delivery (CI/CD)-Prozesse.

Anwendungen oder Teile davon werden im Laufe der Entwicklung während funktionalen (Unit-) Tests, der Qualitätssicherung oder dem Release Build ohnehin ständig ausgeführt. Mit IAST wird jegliche Verwendung, jeder Lauf und jeder funktionale Test einer instrumentierten Applikation automatisch auch zum Sicherheitstest. Die Entwickler müssen keine dedizierten Skripte für Security-Tests erstellen.

Dies eignet sich auch für automatisierte API-Tests von Microservices. Die Abdeckung bezüglich der Security beruht im Großen und Ganzen auf der bereits vorhandenen Testabdeckung. Größter Unterschied im Vergleich zu SAST und DAST ist, dass die Untersuchung aus der laufenden Applikation heraus stattfindet. Datenfluss und -eingaben von der Quelle bis zur Verarbeitung (Senke) müssen nicht emuliert werden, sondern lassen sich während des Laufs detailliert beobachten. Falsche Ergebnisse werden weitestgehend vermieden und die Ergebnisse in Echtzeit aber auch wie gewohnt aggregiert zur Verfügung gestellt.

Abbildung zwei zeigt vereinfacht, wie eine Eingabe durch eine instrumentierte Applikation "wandert". Kleine injizierten Codeschnipsel arbeiten wie Sensoren an unterschiedlichen Stellen. Sie untersuchen beispielsweise den Datenfluss und wie der Input als Bestandteil einer Datenbankabfrage in SQL verwendet wird. Auf diese Weise werden Sicherheitslücken sichtbar, die Angreifer etwa durch SQL-Injection ausnutzen könnten, ohne tatsächlich schädliche Anweisungen einspeisen zu müssen.

Rücken diese Sicherheitstests im Entwicklungszyklus (vereinfacht aufgeteilt in: Entwicklung, Test und Betrieb) vom Ende (rechts) näher an den Anfang (links), spricht man von "Shift Left". Entwickler erfahren so früher über neue eingeführte Sicherheitsdefizite und können sie eher beseitigen. Nicht jeder Entwickler ist jedoch ein Sicherheitsexperte. Deshalb erklären IAST-Lösungen meist den Sicherheitsverstoß und beschreiben, welche Änderungen erforderlich sind. Diese Lerneffekte finden auch spezifisch für eingesetzte Frameworks und integriert in der Entwicklungsumgebung statt.

Runtime Application Self Protection

Jenseits von Entwicklungs- und Testumgebungen dienen instrumentierte Anwendung auch dazu, Angriffe auf die Applikation zur produktiven Laufzeit zu erkennen. Damit dringt die Instrumentierung in den Bereich der Möglichkeiten einer Web Application Firewall (WAF) vor und ergänzt diese, da erkannte Angriffe im Log vermerkt und im Idealfall blockiert werden können. Das wird auch als Runtime Application Self Protection (RASP) bezeichnet.

Für RASP muss die Applikation weder trainiert noch konfiguriert werden. Anders als mit einer WAF erfolgt die Erkennung nicht von außen, sondern aus der Applikation heraus. Das sorgt für weniger Fehlalarme im laufenden Betrieb und vermeidet "Alarmmüdigkeit" bei den Mitarbeitern. Eine gute RASP-Implementierung kann auch erkennen, ob eine Sicherheitslücke lediglich vorliegt oder ob sie tatsächlich durch einen Angriff ausgenutzt wird.

Fazit

IAST und RASP ermöglichen es, DevSecOps in jeder Phase des Lebenszyklus einer Applikation (Entwicklung, Test, Betrieb) umzusetzen:

• in Echtzeit erhobene, akkurate Ergebnisse vermeiden eine unnötige Verfolgung von Sicherheitslücken;

• durch Shift Left werden Fehler früher erkannt und behoben wodurch Kosten gespart und Lerneffekte zur Verbesserung von Source Code vermittelt werden können;

• aufwändige, spezielle Security-Tests müssen weniger oft oder gar nicht mehr erstellt werden;

• die CI/CD Pipeline wird nicht durch weitere Wartezeiten von Penetrationstests belastet.

Instrumentierung bei der Entwicklung ermöglicht es Unternehmen, eine Sicherheitskultur zu entwickeln, die sowohl schnell als auch sicher ist. Fehlendes Know-how oder Zeitmangel zwingen nicht mehr dazu, Security zu vernachlässigen. Steht Source Code im Falle von Legacy Anwendungen oder eingesetzten Bibliotheken nicht zur Verfügung, können Sicherheitsdefizite durch Instrumentierung trotzdem aufgefunden werden. RASP ergänzt WAFs und hat das Potenzial, vorab nicht erkannte oder behobene Sicherheitsdefizite zur Laufzeit zu blockieren.

Obwohl sich die Technologie im Bereich APM bereits etabliert hat, ist Instrumentierung kein Allheilmittel. Es gilt, wie bei allen anderen Werkzeugen, dass nur ein Proof-of-Concept entscheiden kann, ob und für wen sich dieser Ansatz lohnt. Die große Sorge, dass eine Instrumentierung sich nachteilig in Bezug auf Performance oder Benutzererfahrung auswirkt, wird in der Regel nicht bestätigt.