Wenn AppSec-Tooling der Königsweg ist, warum setzen so viele Unternehmen es nicht ein?

Eine Version dieses Artikels erschien in SC Zeitschrift. Er wurde aktualisiert und hier syndiziert.

‍

Eines der vielen Rätsel, mit denen die Sicherheitsspezialisten von heute konfrontiert sind, besteht darin, die Balance zwischen den Lösungen zu finden, die sie zur Bewältigung der Cyber-Risiken einsetzen werden, denen sie ausgesetzt sind. Wie soll das Budget zwischen Tools und Mitarbeitern aufgeteilt werden? Welche Tool-Suite passt am besten zum vorhandenen Tech-Stack? Bei so vielen Optionen gibt es keine einfachen Antworten, und die Wahl der falschen Optionen wird später Zeit und Geld kosten.

Ein kürzlich veröffentlichter Bericht zeigt, dass der Markt für Anwendungssicherheits-Tools bis 2025 ein "explosives" Wachstum verzeichnen wird. Dies ist ein deutlicher Hinweis auf die unbestrittene Rolle dieser Tools für erfolgreiche DevSecOps-Praktiken und die zunehmende Relevanz in der Branche angesichts der wachsenden Mengen an Code mit potenziellen Sicherheitslücken.

Es gibt jedoch ein etwas merkwürdiges Problem. Fast die Hälfte aller Unternehmen liefert wissentlich angreifbaren Code aus, obwohl sie eine Reihe von AppSec-Tools einsetzen, die genau das verhindern sollen. Für Produkte mit einer unbestreitbaren Marktnachfrage, die schnell an Zugkraft gewinnt, macht das wenig Sinn. Warum kaufen sich so viele in ausgeklügelte Sicherheitstools ein, nur um deren Ergebnisse zu ignorieren oder sie gar nicht zu nutzen? Das ist ein bisschen so, als würde man ein Haus am Strand kaufen, nur um dann in einem Zelt im Wald zu schlafen.

Es gibt einige Gründe, warum AppSec-Tools nicht so genutzt werden, wie wir es vielleicht erwarten. Dabei geht es weniger um die Tools und ihre Funktionalität, sondern vielmehr darum, wie sie sich in ein Sicherheitsprogramm als Ganzes integrieren.

Mehr Werkzeuge sind nicht gleichbedeutend mit weniger Problemen.

Wenn Unternehmen ihre Softwareentwicklungsprozesse weiterentwickeln, von Agile über DevOps bis hin zum heiligen Nirwana DevSecOps (hey, für den Moment ist es das Beste, was wir haben), ist es unvermeidlich, dass auf dem Weg dorthin mehrere Scanner, Monitore, Firewalls und alle möglichen AppSec-Tools gekauft werden. Auch wenn es den Anschein hat, dass es ein Fall von "je mehr, desto besser" ist, führt dies sehr oft zu einem Tech-Stack, der Frankensteins Monster ähnelt, mit all der Unvorhersehbarkeit, die dies mit sich bringt.

Mit Budgets und Expertenressourcen, die für den Umfang der erforderlichen Arbeit zunehmend begrenzt sind, ist der Versuch, das Chaos zu beseitigen und den besten Tooling-Pfad für die Zukunft zu finden, eine entmutigende Aufgabe, und der Code, der gescannt und behoben werden muss, kommt einfach immer wieder. Es ist nicht verwunderlich, dass viele Unternehmen weiterhin Code ausliefern müssen, auch wenn dies ziemlich alarmierend ist und immer noch ein immenses Risiko für unsere Daten und unsere Privatsphäre darstellt.

Scanning-Tools sind langsam, was sich auf die Agilität von Releases auswirkt.

Sicherheit mit Geschwindigkeit zu erreichen, ist so etwas wie ein weißer Wal in der Softwareentwicklung, und die Wahrheit ist, dass wir immer noch versuchen, das richtig hinzubekommen, selbst wenn wir Organisationen dazu bringen, einen DevSecOps-orientierten Ansatz zu übernehmen. Akribisches, manuelles Code-Review mag in den 90er Jahren als Sicherheitsgarantie funktioniert haben, aber in einer Zeit, in der wir Hunderte von Milliarden Codezeilen produzieren, ist dieser Plan ungefähr so effektiv wie die Vorbereitung eines Fußballfeldes mit einer Nagelschere.

Scanning-Tools automatisieren den Prozess der Suche nach potenziellen Schwachstellen und übernehmen den Teil der akribischen Codeüberprüfung für uns. Das Problem ist, dass sie im Kontext einer CI/CD-Pipeline, die auf allen Zylindern läuft, immer noch langsam sind, und kein einziges Tool findet jede Schwachstelle. Es gibt auch ein paar eklatante Probleme mit den Ergebnissen, die nach einem Scan an das Sicherheitsteam ausgespuckt werden:

1. Es gibt eine Menge falsch positiver (und negativer) Ergebnisse
2. Irgendein armer Sicherheitsexperte muss immer noch dasitzen und eine manuelle Überprüfung durchführen, um die echten Bugs von den Phantom-Bugs zu trennen
3. Oft werden viel zu viele allgemeine Schwachstellen aufgedeckt, die schon vor der Bereitstellung des Codes hätten erkannt werden müssen. Wollen Sie wirklich, dass Ihre sehr teuren Sicherheitsexperten von den großen, haarigen Sicherheitsproblemen mit dem Kleinkram abgelenkt werden?
4. Scanner finden, sie beheben nicht.

Selbst in einer Organisation, die ihr Bestes tut, um nach den besten Praktiken der Cybersicherheit zu arbeiten und mit der Zeit zu gehen, um Sicherheit in jede Phase des Prozesses einzubeziehen, ist der oben beschriebene Prozess immer noch ein Showstopper, wenn Scanner die wichtigste Schutzmaßnahme sind und zu viele häufige Fehler das Team bei der Bereitstellung von sicherem Code behindern. Es liegt auf der Hand, dass hier an der falschen Stelle gespart wird, und zwar in der Regel in der Form, dass man sich auf das absolute Minimum an Tools verlässt, die unmöglich alle potenziellen Risiken abdecken können, selbst wenn man eine ganze Reihe von Lösungen gekauft hat.

Einige technisch geführte Automatisierungen können zu einer verminderten Codequalität führen

Scannen und Testen tragen die Hauptlast der automatisierten Prozesse im AppSec-Tooling, zusammen mit essenziellen Dingen wie Firewalls und Monitoring, aber andere gängige Tools können mit der Zeit unbeabsichtigt die praktischen Sicherheitsgrundlagen aushöhlen.

So wird beispielsweise die RASP-Technologie (Runtime Application Self-Protection) häufig eingesetzt, um die Sicherheitslage zu verbessern, ohne die Codierungsgeschwindigkeit zu beeinträchtigen. Sie arbeitet in der Laufzeitumgebung einer Anwendung und schützt vor böswilligen Code-Eingaben, Echtzeitangriffen und meldet jedes merkwürdige Ausführungsverhalten.

Es ist sicherlich ein zusätzlicher Schutz, aber wenn man es als Ausfallsicherung gegen potenzielle Schwachstellen in der Codebasis betrachtet, können Entwickler selbstgefällig werden, besonders wenn sie mit immer unmöglicheren Terminen für die Markteinführung neuer Funktionen konfrontiert werden. Sichere Coding-Praktiken werden möglicherweise nicht befolgt, in der Annahme, dass der Selbstschutz zur Laufzeit alle Fehler erkennen wird. Entwickler machen sich nicht die Mühe, unsichere Codierungsmuster zu erstellen, aber die Sicherheit wird oft zugunsten der Bereitstellung von Funktionen zurückgestellt, vor allem in der Annahme, dass es einen automatischen Schutz gibt.

Tools können versagen (und laufen im Fall von RASP oft im Überwachungsmodus, um False Positives zu vermeiden, was wiederum nur Sichtbarkeit - aber keinen Schutz - vor einem Angriff bietet), und wenn das passiert, ist es hochwertiger, sicherer Code, auf den man sich jedes Mal verlassen kann. Sicherheitsbewusstsein in jeder Rolle, die mit Code in Berührung kommt, ist grundlegend für DevSecOps, und Entwickler, die keinen sicheren Code trainieren oder produzieren, machen einen Fehler. Das Schreiben von sicherem und unsicherem Code erfordert den gleichen Aufwand; es ist die Aneignung des Wissens, um sicher zu codieren, die die wirkliche Energie erfordert. Die Zeit, die für die Implementierung und Optimierung von RASP aufgewendet wird, kann viel besser für die Weiterbildung von Entwicklern genutzt werden, damit diese den Fehler gar nicht erst machen.

Das Gleichgewicht zwischen Werkzeugen und Menschen: Es ist kein Allheilmittel, aber es kommt dem am nächsten (im Moment).

Das Hauptethos von DevSecOps besteht darin, Sicherheit zu einer gemeinsamen Verantwortung zu machen. Unternehmen, die die Software entwickeln, die unser Leben bestimmt - vom Stromnetz bis hin zu unseren Türklingeln - müssen alle Beteiligten mit einbeziehen, um ein höheres Maß an Sicherheit zu gewährleisten.

Mit Tools lässt sich nicht alles erreichen, und es ist nicht einmal der billigste Weg. Die bei weitem besten Ergebnisse werden erzielt, indem man relevante Sicherheitsschulungen für jeden, der mit Code in Berührung kommt, priorisiert, aktiv daran arbeitet, die Sicherheit für das Entwicklungsteam in den Vordergrund zu stellen, und eine positive Sicherheitskultur aufbaut, die von Menschen geführt wird, wobei eine Tooling-Suite eine unterstützende Rolle spielt.

Selbst angesichts von Zeitbeschränkungen, abgeschnittenen Ecken und anderen Dingen, die Sicherheitsexperten nachts den Schlaf rauben, stellen diese Tools (und ob sie nun verwendet werden oder nicht) einen weitaus geringeren Risikofaktor dar, wenn die Entwickler gängige Sicherheitsmängel gar nicht erst einführen.

‍