IT-Security Management & Technology Conference 2017 Security in agile Software-Projekte integrieren

Agile Projekte liefern in Verbindung mit DevOps in der Regel schnell und häufig neue Releases aus. Jedoch kann bei einer hohen Rolloutfrequenz nicht jedes einzelne Release einen eigenen umfangreichen Penetrationstest erhalten, ohne dass Security als Bottleneck den Vorteil zügiger Rollouts wieder zunichtemachen würde. Um dennoch mit einem guten Gewissen agil live gehen zu können, bedarf es anderer Lösungen.

Anbieter zum Thema

Vogel IT-Akademie

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Windhoff Group

Schon bevor ein neues Projekt umgesetzt wird, sollte in den agilen Teams ein entsprechendes Security-Verständnis installiert werden, um Sicherheitslücken so früh wie möglich zu vermeiden. Das beginnt mit der Erstellung von Security Guidelines für Entwickler, passend zugeschnitten auf die von ihnen konkret eingesetzten Frameworks.

Daneben sollte auch über das Einführen von Werkzeugen zur automatischen Überprüfung des Quellcodes und der testbaren Anwendungsteile nachgedacht werden. Hierdurch können agil arbeitende Teams laufend unterstützt werden, da bestimmte Security-Prüfungen teil- bzw. vollautomatisiert im Hintergrund stattfinden.

Kategorisierung von Security-Werkzeugen

Grob gesehen unterteilen sich die verfügbaren Security-Werkzeuge in die folgenden Kategorien:

DAST (Dynamic Application Security Testing):DAST-Werkzeuge betrachten die zu prüfende Webanwendung aus Sicht eines Angreifers von außen, also als Black-Box. Je nach Konfigurationsmöglichkeiten des Werkzeugs können auch vollautomatisierte Tests im eingeloggten Bereich der Webanwendungen durchgeführt werden. Im Falle von komplexen Webanwendungen können jedoch die Anpassungsaufwände des Werkzeugs nicht unerheblich sein, insbesondere wenn fachlich zu füllende Dialogstrecken abzubilden sind, bei denen der Crawler an seine Grenzen stößt. Prominente Open-Source DAST-Werkzeuge sind z. B. OWASP ZAP sowie der Arachni Scanner.

SAST (Static Application Security Testing): SAST-Werkzeuge scannen den Quellcode oder Bytecode der Anwendung auf Sicherheitslücken. Einfachere SAST-Werkzeuge betrachten nur die Sinks, also die potenziell unsicheren Stellen, ohne eine Verbindung von potenziell manipulierbaren Daten herzustellen. Professionellere SAST-Werkzeuge prüfen hingegen diese Verbindung und können damit genauere Aussagen zur tatsächlichen Ausnutzbarkeit treffen. Im Vergleich zu DAST-Werkzeugen haben SAST-Werkzeuge einen höheren Abdeckungsgrad der Anwendung, weil der gesamte Quell- oder Bytecode gescannt werden kann. Andererseits führen DAST-Werkzeuge im Vergleich zu SAST-Werkzeugen teilweise auch andere Kategorien von Prüfungen durch, so dass der Einsatz beider Werkzeugkategorien empfohlen wird. Zusätzlich zu kommerziellen SAST-Werkzeugen existieren im Open-Source-Bereich z. B. das FindBugs-Plugin Find Security Bugs oder auch erweiterte Sonar-Regeln für Java-Anwendungen. Für JavaScript kann das in ESLint aufgehende ScanJS verwendet werden. Weiterhin gibt es Brakeman für Ruby-on-Rails-Anwendungen. Ebenfalls existieren Werkzeuge zur Prüfung der Abhängigkeiten einer Anwendung, um das Risiko durch veraltete und unsichere Bibliotheken zu reduzieren. Diese gleichen die Listen bekannter verwundbarer Komponenten (z.B. CVE-Listen) gegen die verwendeten Bibliotheken ab. Als Open-Source-Lösungen, die im Rahmen des Builds eingesetzt werden können, existieren hier OWASP Dependency Check für Java-Abhängigkeiten sowie Retire.js zur Prüfung der eingebundenen JavaScript-Bibliotheken.

IAST (Interactive Application Security Testing): Diese im Vergleich jüngere Kategorie kann als dynamische Codeanalyse betrachtet werden: Hierbei wird mittels Instrumentierung einer Testumgebung die Anwendung zur Laufzeit quasi einer White-Box-Analyse unterzogen. Bemerkenswert bei manchen IAST-Werkzeugen ist, dass die Sicherheitsüberprüfung parallel zur fachlich getriebenen Benutzung der Anwendung stattfinden kann, was die Integration in die vorhandenen Testprozesse einfacher gestaltet. Andere IAST-Werkzeuge setzen hingegen auf eigene UI-Testtreiber, die das Crawler-Problem mit entsprechenden Anpassungsaufwänden mitbringen. Leider sind in diesem Bereich Open-Source-Lösungen noch nicht ausgereift vorhanden, so dass hierzu ausschließlich auf kommerzielle Werkzeuge zurückgegriffen wird. Im Gegensatz dazu existieren bei DAST und SAST empfehlenswerte Open-Source-Produkte.

Roadmap für eine Einführung: Security DevOps Maturity Model

Um Projekten eine gute Möglichkeit zu bieten, den eigenen Standpunkt hinsichtlich der Einführung automatisierter Sicherheitschecks zu evaluieren und davon abgeleitet mögliche nächste Schritte zur Verbesserung zu definieren, kann das „Security DevOps Maturity Model“ (SDOMM) herangezogen werden.

(Folien zum Video)

Dieses Modell beschreibt die vier Achsen „Dynamische Tiefe“, „Statische Tiefe“, „Intensität“ sowie „Konsolidierung“, in je vier Ausprägungsstufen. Die Achse der „Intensität“ widmet sich der Härte der Sicherheitschecks. Die Achse der „Konsolidierung“ versucht, den Feedback-Loop in Richtung Entwicklung zu schließen und eine ganzheitliche Prozessintegration zu ermöglichen. Um etwaige Einstiegshürden zur Einführung von Security DevOps für Projekte gering zu halten, zeigt das Modell mögliche Integrationen anhand von Open-Source Werkzeugen auf. Kommerzielle Lösungen in den einzelnen Bereichen der dynamischen und statischen Analysen sind ebenfalls sinnvoll und können in dem Modell gleichermaßen Einsatz finden. Die einzelnen Schritte je Achse müssen nicht zwingend in der Reihenfolge aus dem Modell durchlaufen werden – vielmehr sind diese Schritte anhand des zu erwartenden Umsetzungsaufwandes für ein Projekt geschnitten, so dass selbst Projekte ohne „Security DevOps“-Integration, erste leicht erreichbare Ziele vorfinden.

Wenn Security-Werkzeuge im Rahmen von Continuous Integration (CI) eingesetzt werden, muss vorab geklärt werden, wie mit Findings umgegangen werden soll. Vor allem in der Einführungsphase wird geraten, nur zuverlässige Findings auszugeben - also Findings, welches das Werkzeug mit hoher Treffersicherheit bewertet hat. Andernfalls müsste jedes Finding von Sicherheitsexperten begutachtet und bewertet werden, erst dann kann eingeschätzt werden, ob tatsächlich eine Schwachstelle vorliegt und dafür ein Ticket eingestellt werden soll. Dies stünde dann im Widerspruch zu einer vollautomatischen Prüfung durch ein Werkzeug im Rahmen der Build-Kette.

Security-Rolle in agilen Teams

Um die Einführung von Security-Werkzeugen durchgängig auch in agilen Teams zu ermöglichen, bietet sich die Etablierung einer neuen Rolle an, welche im agilen Team speziell in der Anwendung der eingeführten Security-Werkzeuge geschult wird. Ein weiterer Vorteil dieser bzgl. Security umfangreicher geschulten Teammitglieder ist, dass diese den Kontakt zur IT-Sicherheitsabteilung halten können und als Ansprechpartner im Team dienen. Langfristig kann diese Rolle auch aus Security-Sicht auf Architekturentscheidungen im agilen Team von innen positiv einwirken. Hierdurch bleibt der agile Ansatz der Eigenverantwortung und Flexibilität der Teams weitestgehend aufrechterhalten, während durch die neue Security-Rolle innerhalb der Teams nicht auf einen übergreifend hohen Sicherheitsstandard in der Entwicklung verzichtet werden muss.

Bei der Integration von Security in agilen Teams können auch externe Security-Coaches zeitweise in den Teams mitarbeiten und dort das nötige Security-Wissen bei den für die neue Rolle vorgesehenen Teammitgliedern on the Job aufbauen.

Über den Autor

Christian Schneider ist als freiberuflicher Softwareentwickler, White-Hat Hacker und Trainer tätig. Er unterstützt Kunden im Bereich der Web Security durch Penetrationstests und „Security Architecture Consulting“ sowie bei der Einführung von „Security DevOps“ innerhalb von agilen Entwicklungsprojekten. In dieser Rolle ist er regelmäßig als Trainer tätig. Während der IT-Security Management & Technology Conference 2017 hält er in Köln, Hanau und Hamburg, eine Keynote zum Thema „Schlimmer geht immer: Eine Auswahl der Top-Hacks der letzten Jahre“, sowie einen Roundtable zum Thema „Integration von Security in agilen Projekten“.

(ID:44682269)