Wenn AppSec-Tools das Allheilmittel sind, warum setzen dann so viele Unternehmen sie nicht ein?

Eine Version dieses Artikels erschien im SC Magazine. Er wurde aktualisiert und hier syndiziert.

‍

Eine der vielen Herausforderungen für Sicherheitsexperten von heute ist es, das richtige Gleichgewicht bei den Lösungen zu finden, mit denen sie ihre Cyberrisiken bewältigen. Wie sollte das Budget zwischen Tools und Personal aufgeteilt werden? Welche Tool-Suite passt am besten zum bestehenden Tech-Stack? Bei der Vielzahl an Optionen gibt es keine einfachen Antworten, und die Wahl der falschen Lösungen kostet später Zeit und Geld.

Ein aktueller Bericht zeigt, dass der Markt für Anwendungssicherheitstools bis 2025 auf ein „explosives“ Wachstum zusteuert, was ein starkes Indiz für ihre unbestrittene Rolle bei erfolgreichen DevSecOps-Praktiken und ihre zunehmende Bedeutung angesichts der wachsenden Menge an Code mit potenziellen Sicherheitslücken ist.

Es gibt jedoch ein etwas kurioses Problem. Fast die Hälfte aller Unternehmen liefert wissentlich anfälligen Code aus, obwohl sie eine Reihe von AppSec-Tools einsetzen, die genau das verhindern sollen. Bei Produkten mit einer unbestreitbaren Marktnachfrage, die schnell an Bedeutung gewinnen, ergibt das wenig Sinn. Warum kaufen so viele Unternehmen hochentwickelte Sicherheitstools, nur um deren Ergebnisse zu ignorieren oder sie gar nicht erst zu nutzen? Es ist ein bisschen so, als würde man ein Haus am Strand kaufen, um dann doch in einem Zelt im Wald zu schlafen.

Es gibt einige Gründe, warum AppSec-Tools nicht so genutzt werden, wie man es vielleicht erwarten würde. Dabei geht es weniger um die Tools und ihre Funktionalität, sondern vielmehr darum, wie sie in das gesamte Sicherheitsprogramm integriert sind.

Mehr Tools bedeuten nicht weniger Probleme.

Während Unternehmen ihre Softwareentwicklungsprozesse weiterentwickeln – von Agile über DevOps bis hin zum heiligen Gral namens DevSecOps (nun ja, zumindest ist es das Beste, was wir derzeit haben) – ist es unvermeidlich, dass auf diesem Weg zahlreiche Scanner, Monitore, Firewalls und alle möglichen AppSec-Tools angeschafft werden. Auch wenn es nach dem Motto „Viel hilft viel“ aussieht, führt dies oft zu einem Tech-Stack, der an Frankensteins Monster erinnert – mit all der Unvorhersehbarkeit, die das mit sich bringt.

Angesichts knapper Budgets und begrenzter Expertenressourcen ist es eine gewaltige Aufgabe, das Chaos zu beseitigen und den besten Weg für die Tool-Landschaft zu finden, während der Code, der gescannt und bereinigt werden muss, ständig weiter wächst. Es ist kaum verwunderlich, dass viele Unternehmen gezwungen sind, weiterhin Code auszuliefern, auch wenn dies alarmierend ist und ein immenses Risiko für unsere Daten und Privatsphäre darstellt.

Scan-Tools sind langsam, und das beeinträchtigt die Release-Agilität.

Sicherheit bei hoher Geschwindigkeit zu erreichen, ist in der Softwareentwicklung so etwas wie der weiße Wal – und die Wahrheit ist, dass wir immer noch versuchen, dies richtig hinzubekommen, selbst während wir Unternehmen dazu bewegen, einen DevSecOps-orientierten Ansatz zu verfolgen. Eine akribische, manuelle Code-Überprüfung mag in den 90er Jahren als Sicherheits-Failsafe funktioniert haben, aber in einer Zeit, in der wir Hunderte von Milliarden Zeilen Code produzieren, ist das ein Plan, der in etwa so effektiv ist, wie einen Fußballplatz mit einer Nagelschere zu pflegen.

Scan-Tools automatisieren den Prozess der Suche nach potenziellen Problemen und übernehmen für uns die mühsame Code-Überprüfung. Das Problem ist, dass sie im Kontext einer CI/CD-Pipeline, die auf Hochtouren läuft, immer noch langsam sind und kein einzelnes Tool jede Schwachstelle findet. Zudem gibt es ein paar eklatante Probleme mit den Ergebnissen, die nach einem Scan an das Sicherheitsteam ausgegeben werden:

1. Es gibt eine Menge an Fehlalarmen (und übersehenen Fehlern).
2. Ein armer Sicherheitsexperte muss sich immer noch hinsetzen und eine manuelle Überprüfung durchführen, um die echten Bugs von den Phantom-Bugs zu trennen.
3. Sehr oft werden viel zu viele häufige Schwachstellen aufgedeckt, die vor der Bereitstellung des Codes hätten erkannt werden müssen. Möchten Sie wirklich, dass Ihre teuren Sicherheitsexperten durch Kleinigkeiten von den großen, komplexen Sicherheitsproblemen abgelenkt werden?
4. Scanner finden, sie reparieren nicht.

Selbst in einem Unternehmen, das sein Bestes tut, um nach Best Practices der Cybersicherheit zu arbeiten und Sicherheit in jeder Phase des Prozesses zu integrieren, ist der oben genannte Ablauf ein Hindernis, wenn Scanner die primäre Schutzmaßnahme sind und zu viele häufige Fehler das Team bei der Bereitstellung sicheren Codes ausbremsen. Es liegt nahe, dass hier Abstriche gemacht werden, was meist dazu führt, dass man sich auf das absolute Minimum an Tools verlässt, die unmöglich jedes potenzielle Risiko abdecken können, selbst wenn eine ganze Suite von Lösungen gekauft wurde.

Bestimmte technische Automatisierungen können die Codequalität mindern.

Scannen und Testen tragen die Hauptlast der automatisierten Prozesse in der AppSec-Toolchain, zusammen mit wesentlichen Elementen wie Firewalls und Monitoring. Andere gängige Tools können jedoch mit der Zeit unbeabsichtigt die grundlegenden Sicherheitsprinzipien untergraben.

Zum Beispiel wird RASP-Technologie (Runtime Application Self-Protection) oft eingesetzt, um die Sicherheitslage zu stärken, ohne die Entwicklungsgeschwindigkeit zu opfern. Sie arbeitet in der Laufzeitumgebung einer Anwendung, schützt vor bösartigen Code-Eingaben und Echtzeit-Angriffen und meldet ungewöhnliches Ausführungsverhalten.

Es ist sicherlich eine zusätzliche Schutzschicht, aber wenn sie als Sicherheitsnetz gegen alle potenziellen Schwachstellen im Code betrachtet wird, können Entwickler nachlässig werden – besonders wenn sie mit immer unrealistischeren Deadlines für die Veröffentlichung neuer Funktionen konfrontiert sind. Sichere Codierungspraktiken werden möglicherweise vernachlässigt, in der Annahme, dass der Selbstschutz zur Laufzeit alle Fehler erkennt. Entwickler haben nicht die Absicht, unsichere Codemuster zu erstellen, aber Sicherheit wird oft zugunsten der Bereitstellung von Funktionen zurückgestellt, insbesondere wenn man sich auf eine automatisierte Absicherung verlässt.

Tools können versagen (und im Fall von RASP laufen sie oft im Überwachungsmodus, um Fehlalarme zu vermeiden, was lediglich Sichtbarkeit – aber keinen Schutz – vor Angriffen bietet). Wenn das passiert, ist hochwertiger, sicherer Code die einzige verlässliche Konstante. Sicherheitsbewusstsein in jeder Rolle, die mit Code arbeitet, ist grundlegend für DevSecOps; wenn Entwickler nicht in sicherem Programmieren geschult werden oder diesen nicht produzieren, ist das ein Fehler. Sicherer und unsicherer Code erfordern den gleichen Schreibaufwand; die eigentliche Energie fließt in das Wissen, wie man sicher programmiert. Zeit, die in die Implementierung und Optimierung von RASP fließt, ist besser investiert, wenn man Entwickler darin schult, solche Fehler gar nicht erst zu machen.

Das Gleichgewicht zwischen Tools und Menschen: Es ist kein Allheilmittel, aber (vorerst) das Beste, was wir haben.

Der Kern von DevSecOps ist die gemeinsame Verantwortung für Sicherheit. Organisationen, die Software für unsere lebenswichtigen Infrastrukturen entwickeln – vom Stromnetz bis zur Türklingel –, müssen alle Beteiligten einbinden, um ein höheres Sicherheitsniveau zu gewährleisten.

Tools allein reichen nicht aus und sind zudem nicht der kostengünstigste Weg. Die mit Abstand besten Ergebnisse erzielt man, wenn man relevante Sicherheitsschulungen für alle, die mit Code arbeiten, priorisiert, das Thema Sicherheit im Entwicklungsteam aktiv präsent hält und eine positive, menschzentrierte Sicherheitskultur aufbaut, bei der Tools lediglich eine unterstützende Rolle spielen.

Selbst bei Zeitdruck, Abkürzungen und anderen Faktoren, die Sicherheitsexperten den Schlaf rauben: Wenn Entwickler gängige Sicherheitslücken gar nicht erst einbauen, stellen diese Tools (und deren Nutzung) ein weitaus geringeres Risiko dar.

‍