Die Auswirkungen der DevOps-Methode auf Sicherheitsüberprüfungen

Laut dem 7. Jahresbericht von Splunk/Puppet zum „State of DevOps“ arbeiten bereits 51 % der Softwareentwicklungs-Unternehmen weltweit mit einem eigenen DevOps-Team. Die gute alte, am Release orientierte, Software-Entwicklung nach dem Wasserfallmodell verliert dagegen langsam an Bedeutung. Die fortschrittlichsten Unternehmen in diesem Sektor veröffentlichen mehrere hundert (Mikro-)Releases pro Monat. Es folgt: Eine unverblümte Bestandsaufnahme.

DevOps verbessert den klassischen, in der Vergangenheit praktizierten Zugang zu Sicherheitstests: nach Dev vor Ops. DevSecOps scheint die richtige Methode zu sein – zumindest, weil sie die Sicherheit in den Prozess einbezieht. Leider geht es dann nicht so einfach weiter. DevSecOps ist stark von der jeweiligen Toolchain abhängig, um die Entwicklungsqualität zu gewährleisten – Sicherheit als nicht-funktionale Anforderung ist schließlich ein Qualitätsaspekt von Software. Das Problem dabei ist, dass sich der Mensch meist zu sehr auf ein Tool verlässt und aufhört selbst zu denken.

Ohne den Usern von Sicherheitstest-Tools zu nahe zu treten, sollten Sie sich die Frage stellen ob Sie die Ressourcen haben, um sie auch alle richtig zu nutzen? Diese sehr leistungsstarken Werkzeuge müssen feingeschliffen und optimiert werden, damit man sie für die entwickelte Anwendung einsetzen kann: Sie müssen die Frameworks, die CI/CD-Kette, den Coding Style, die Technologie, die Integration von Altsystemen, die IDE-Plattform und noch vieles mehr beachten.Sie müssen sich ständig bewusst sein, dass Probleme auf unerwartete Weise auftauchen und sich entwickeln; zugleich müssen Sie immer wachsam und vorsichtig sein und auf neu auftretende Bedrohungsmuster achten. Sorgen Sie also dafür, dass Sie Ihre DevSecOps-Tools mit entsprechender Unterstützung vom Hersteller oder – noch besser – von einem erfahrenen Berater für Applikationssicherheit beziehen.

Die Sicherheitstest-Tools sind zwar sehr leistungsstark, ihre positive Wirkung geht aber verloren, wenn sie falsch verwendet werden. Das Ganze könnte sogar nach hinten losgehen: Wenn Sie beispielsweise Ihre Entwickler plötzlich mit Tausenden von Fehlalarmen quälen, sinkt die Akzeptanz für Sicherheitsmaßnahmen.

Sicherheit funktioniert nicht nach dem Urknall-Prinzip

Statt viel auf einmal und nichts davon richtig zu machen, entscheiden Sie sich lieber für einen langsameren Ansatz: Entwickeln Sie zuerst ein Prüfverfahren und beginnen Sie mit nur einer Schwachstellenklasse – selbst wenn Sie dadurch nicht sofort das volle Potenzial ausschöpfen können. Geben Sie Ihren Teams die Chance, in einen soliden und professionellen Überprüfungsprozess hineinzuwachsen. Integrieren Sie die Ergebnisse direkt in Bug-Tracking-Tools, Source Code Management Systeme oder Ihre allgemeine Entwicklungsumgebung – bitte verschwenden Sie Ihre Zeit nicht mit PDF-Berichten.

Zwischen Schwarz und Weiß

Konzentrieren wir uns ein wenig auf die DevOps-Phase des „Monitorings“. Diese Phase sollte nicht nur überwachen, was gerade in der Applikation passiert, sie sollte auch durch punktuelle, wiederkehrende Sicherheitstests erweitert werden. So können die Ergebnisse der Überprüfung durch konkret identifizierte Schwachstellen optimiert werden.

Aber wann ist der Einsatz sinnvoll? Sobald die entwickelte Anwendung einsatzbereit ist. Bisher nutzte man im Zuge der Abnahme einen großen Pentest in verschiedenen Ausprägungen, von Blackbox bis zu Whitebox Tests, statt kontinuierliche Überprüfungen. Im Regelfall passierte dies nach Dev und zuweilen vor Ops, aber seien wir ehrlich: meistens erst nach ein paar Wochen Ops. 

Der Beschaffungsprozess von der Ausschreibung über die Bestellung bis zum tatsächlichen Start des Pentesting-Projekts kann ziemlich lange dauern und viel wertvolle Testzeit und letztendlich auch Testqualität kosten. Da das Testen Fehlerfreiheit nicht garantieren kann, wird das Budget für einen Pentest fast immer über eine Timebox festgelegt (auch wenn Ihr Pentest-Anbieter Ihnen etwas anderes erzählt).

Aus Liebe zum Report

Diese Timebox umfasst in der Regel alles von der Projekteinrichtung über die Verwaltung bis zu Berichterstellung und -bearbeitung – um nur ein paar Leistungen zu nennen. Und Achtung: Je kleiner der Zeitrahmen, desto höher ist der Anteil des Verwaltungsaufwands. Aber nachdem alle nötigen Schritte unternommen wurden und die Tester den Papierkram für den Zugriff auf den Scope sowie auf gültige Benutzerkonten erledigt haben, können sie endlich das tun, was sie am beste können: die Software auf Herz und Nieren prüfen.

Schließlich wird ein mit Hingabe verfasster Bericht erstellt – natürlich im PDF-Format –, unter dem alle Beteiligten leiden: Der Prüfer muss den Bericht schreiben und der Kunde ist dazu verdammt, ihn auch zu lesen, er ist geradezu moralisch verpflichtet dazu.

Dann beginnt der mühsame Prozess, die Sicherheitsprobleme zu beheben: Es wird nochmals getestet, dann diskutiert, wie der Bericht geschrieben werden soll, und debattiert, wie die neuen Erkenntnisse während des Re-Checks in die Applikation gekommen sind (diese Liste kann endlos ergänzt werden). Letztendlich investieren Sie also viel Aufwand in die Beschaffung, Koordination und Auswertung eines Pentests.

Vielleicht ist es daher endlich an der Zeit, einen anderen Ansatz zu wählen – einen, der mit DevOps sogar viel besser harmoniert?

Was kann man tun, um den Administrationsaufwand eines Pentests zu verringern?

Die Hauptargumente für DevOps sind Geschwindigkeit und Flexibilität. Warum sollten wir diese Qualitäten nicht auch zur Erhöhung der Applikationssicherheit nutzen? Warum nicht regelmäßig kleine Pentests, eingebettet in den Entwicklungsprozess der Applikation, durchführen? Die Frage ist nur: In welchen Iterationen ist das sinnvoll? Vielleicht nicht nur regelmäßig, sondern sogar ununterbrochen? Oder sagen wir einfach kontinuierlich.

Kontinuierliches Testen passt perfekt zu DevOps. Wenn Sie selbst niemanden in Vollzeit anstellen können oder wollen, der Ihre App permanent prüft, können Sie Ihre Tests alle 2, 3 oder 4 Wochen planen – je nachdem, was Ihr Budget erlaubt.

Was kann ich tun, wenn meine Anwendung vor dem Testen online geht?

Je nachdem, welches Testmuster Sie gewählt haben, bliebe mit dem kontinuierlichen Ansatz Ihre Anwendung nicht länger als einen Monat ungetestet.  Aber seien wir ehrlich, unsichere Anwendungen waren bisher deutlich länger exponiert und Sie hatten nicht die Vorteile von Continuous Integration/Continuous Development (CI/CD), um bereits ein oder zwei Tage später eine Korrektur vorzunehmen.

Was kann ich tun, wenn es nichts Neues zu testen gibt?

Nehmen wir an, Ihre Entwickler sind zwei Wochen im Urlaub und es wird gerade nicht entwickelt, sodass es nichts Neues zu testen gibt. Kein Problem! Lassen Sie die Tester den vorhandenen Code noch einmal überprüfen. Ein Pentest nimmt sich ja immer zuerst die leicht identifizierbaren Sicherheitslücken vor – Stichwort „low hanging fruits“. Geben Sie den Testern nun die zusätzliche Zeit, tiefer ins Detail zu gehen und andere Betrachtungswinkel auszuprobieren, um auch die nicht offensichtlichen Schwachstellen zu finden. Oder geben Sie ihnen Zeit, um in dem einen Loch herumzustochern, in dem sie Probleme vermuten, wobei sie aber bisher nicht die Zeit hatten, sich wirklich eingehend damit zu beschäftigen.

Bedenken Sie auch: Frameworks und deren Sicherheit neigen zum Erodieren. Grundlegende Komponenten und komplexe Angriffsvektoren verdienen ebenfalls eine genauere Betrachtung, nachdem die offensichtlichen Schwachstellen identifiziert wurden. Geben Sie den Pentestern diese zusätzliche Zeit, um tiefer zu graben. Es wird sich auszahlen.

Vernetzte Welt

Denken Sie daran, dass Sie DevOps wegen der Geschwindigkeit und Agilität anwenden wollten. Und Sie wollten die Zusammenarbeit zwischen den verschiedenen Rollen im gesamten Entwicklungszyklus verbessern. Vergessen Sie den Unsinn, dass Ihr Code vor Ort überprüft werden muss. Das SEC Consult Vulnerability Lab bewertet regelmäßig Code aus der Ferne, ohne die Sicherheit der Applikationen zu gefährden. Unabhängig davon sind Ihre Entwickler in der Regel über die ganze Welt verstreut und organisieren sich selbst mit Webkonferenzen, Chat, Messenger etc. Und am Ende wird Ihr der Code Ihrer Applikation mit der Veröffentlichung ohnehin in die freie Wildbahn entlassen.

Bestrafen Sie nicht den Überbringer der Nachricht

Es wäre verrückt zu glauben, dass durch die Arbeit von Sicherheitsexperten Lücken in Ihren Anwendungen entstehen. Diese Schwachstellen sind bereits vorhanden (weil Ihre Entwickler sie dort platziert haben – versehentlich vermutlich), bevor der Pentest startet. Das heißt von „remote“ arbeitenden Entwicklern geht genauso viel oder wenig potentielle „Gefahr“ aus, wie von Sicherheitsexperten, die aus der Entfernung testen. Pentester finden das, was zu finden ist.