Runtime Application Self Protection DevOps mit RASP sicherer machen

DevOps stellt besondere Herausforderungen an die IT-Sicherheit. Kontinuierliches Feedback aber kann Anwendungen sicherer machen kann. In diesem Beitrag schauen wir uns an, welche Technologien dabei helfen.

Anbieter zum Thema

Insider Research

OutSystems

Fastly GmbH

Veracode Limited

Fast immer, wenn es um die Absicherung von DevOps geht, geht es um die Frage, wie sich Security-Tests in die Continuous-Integration-/Continuous-Deployment-Pipeline (CI/CD) integrieren lassen. Selbstverständlich ist es richtig, sich mit diesem Thema auseinanderzusetzen: Die Sicherheit darf nicht darunter leiden, dass die Software-Entwicklung immer schneller vonstattengeht.

Security-Testing benötigt deshalb einen festen Platz in der neuen Kultur – die für DevOps so wichtige Automatisierung kann außerdem dazu beitragen, es noch effizienter zu machen. Wer die Diskussion rund um DevSecOps aber auf das Security-Testing beschränkt, der begeht einen Fehler. Es ist nämlich falsch so zu tun, als würde sich Anwendungssicherheit auf die Phase vor dem Deployment beschränken.

Genauso wichtig ist die Frage, was mit der Software passiert, nachdem sie ausgeliefert wurde. Eine Technologie wie Runtime Application Self Protection (RASP) liefert Antworten: Sie hilft im Rahmen von DevOps, die Anwendungssicherheit auf die Produktivumgebung auszudehnen.

Erst Feedback-Schleifen machen DevOps zu DevOps

Der Unterschied zwischen Continuous Integration und Deployment sowie DevOps erschließt sich vielen Betrachtern nicht auf Anhieb. Und tatsächlich basiert DevOps auf den vorgenannten Methoden – es gibt also viel Deckungsgleichheit. DevOps aber ist wesentlich mehr als nur eine neue Form, Software-Releases zu managen: Es ist eine Kombination aus Kulturwandel und technischer Innovation, die die Entwicklung und Auslieferung von Software schneller, effizienter und zuverlässiger macht.

Wer sich nur auf Pipeline fokussiert, ignoriert einen der Grundpfeiler von DevOps: Feedback-Loops. Diese zielen darauf ab, Störungen und Probleme unmittelbar zu erkennen, Informationen darüber ohne Zeitverzögerung an die zuständigen Personen zu übermitteln und so eine rasche Behebung zu ermöglichen. Das dahinterstehende Prinzip ist die perfekte Ergänzung zu Continuous Deployment.

Für die IT-Sicherheit sind Feedback-Loops ebenfalls von entscheidender Bedeutung. Informationen über die aktuelle Bedrohungslandschaft und Vorfälle in der Produktivumgebung müssen direkt an Entwicklerteams zurückgespielt werden. Nur so haben diese die Möglichkeit, Schwachstellen rechtzeitig zu beseitigen.

Weshalb WAFs nicht ausreichen

Welche Tools sind dazu notwendig? Reicht eine Web Application Firewall (WAF)? Prinzipiell ist diese in der Lage, sicherheitsrelevante Ereignisse zu identifizieren und Alarm zu schlagen. Gleichzeitig blockiert sie das weitere Vorgehen, wodurch mehr Zeit zur Beseitigung der Schwachstelle bleibt. Problematisch ist jedoch, dass WAFs ausschließlich auf Regelverletzungen reagieren – und die Regeln für SQL-Injections, Cross-Site-Scripting (XSS) und andere Angriffsmethoden üblicherweise für jede Anwendung eigens definiert werden müssen.

Nach Updates kann es außerdem erforderlich sein, die Regeln erneut zu konfigurieren. In der Zwischenzeit bleibt die Anwendung ungeschützt und die WAF kann Vorfälle nicht erkennen und melden. Darüber hinaus ist die WAF eine separate Appliance, die nicht im Kontext der Anwendungs-Entwicklung bereitgestellt wird. Sie unterliegt also nicht der Kontrolle des DevOps-Teams. Will dieses die WAF aktualisieren oder neu konfigurieren, bleibt nur der Umweg über die zuständige Abteilung.

Folge dieses recht umständlichen Verfahrens sind Verzögerungen bei der Beseitigung von Schwachstellen. Ein weiteres Problem der WAFs im Rahmen von DevOps: Lizenzprobleme verhindern in der Regel, dass sie auch in Entwicklungs- oder Testumgebungen zum Einsatz kommen. Das führt zu einem Verstoß gegen eines der Grundgesetze der Anwendungsentwicklung: Software sollte in der gleichen Konfiguration getestet werden, in der sie später bereitgestellt wird.

RASP als Alternative

Gerade im Kontext von DevOps ist RASP deshalb eine sinnvolle Alternative zu WAFs und dem klassischen Perimeterschutz. RASP erfordert keine anwendungsspezifische Konfiguration, kann Vorfälle jedoch genauer beobachten, da es direkten Einblick in das Innenleben der Anwendung nehmen kann. Außerdem liegt RASP auf dem gleichen Server wie die Anwendung selbst.

Über ein Puppet- oder Chef-Script beziehungsweise als Teil eines Containers ist eine schnelle Bereitstellung möglich – zum Beispiel im Rahmen einer vollautomatischen Continuous-Deployment-Pipeline. Ob es dabei um die Bereitstellung in die Produktivumgebung oder eine Entwicklungsumgebung geht, ist unerheblich.

Gleichzeitig ist RASP in der Lage, Angriffe selbstständig zu stoppen und das aufgetretene Problem zu melden. Auf diese Weise wird die unmittelbare Gefahr abgewendet und es besteht mehr Spielraum für Entscheidungen. Sollte die Lösung des Problems oberste Priorität genießen? Reicht es aus, es im Rahmen des nächsten Sprints anzugehen? Oder sollte man das Problem, sofern es um ein Legacy-System geht, einfach als technische Schuld verbuchen und seine Lösung vertagen, weil es wirtschaftlich sinnvoller ist? Unter dem Schutzschirm von RASP sind all diese Wege gangbar.

Fazit

Wenn es um IT-Sicherheit im Rahmen von DevOps geht, drehen sich die Diskussionen in der Regel um die Frage, wie sich Tests und andere Sicherheitsmaßnahmen automatisieren lassen, um zu verhindern, dass sie den Entwicklungszyklus der Software unnötig ausbremsen. Wer sich aber allein auf dieses Thema beschränkt, denkt zu einseitig.

Continuous Feedback ist schließlich eine wesentliche Säule von DevOps und spielt auch für die Sicherheit eine wichtige Rolle. Nur wenn es gelingt, Informationen über Vorfälle in der Produktivumgebung an das Entwicklerteam zurückzuspielen, kann dieses adäquat reagieren. RASP ist eine Technologie, die diesen Prozess bestmöglich unterstützt.

* Nabil Bousselham ist seit Juli 2015 als Solutions Architect beim Spezialisten für Anwendungssicherheit Veracode tätig. Bousselham hat Informatik und Physik an der Universität Leipzig studiert und verfügt über mehrere Zertifikate im Bereich Software Engineering der ISQI GmbH und ISSECO CPSSE.

(ID:44934261)