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

Eine Version dieses Artikels erschien in SC Magazin. Es wurde hier aktualisiert und syndiziert.

‍

Eines der vielen Rätsel, mit denen Sicherheitsspezialisten heute konfrontiert sind, besteht darin, herauszufinden, welche Lösungen sie zur Bewältigung der Cyberrisiken verwenden werden, denen sie ausgesetzt sind. Wie sollte das Budget zwischen Tools und Mitarbeitern aufgeteilt werden? Welche Toolsuite eignet sich am besten für den vorhandenen Tech-Stack? Bei so vielen Optionen gibt es keine einfachen Antworten, und die Auswahl der falschen Optionen wird später Zeit und Geld kosten.

Ein kürzlich veröffentlichter Bericht ergab, dass der Markt für Anwendungssicherheitstools nach „explosives“ Wachstum bis 2025, ein starker Hinweis auf ihre unbestrittene Rolle bei erfolgreichen DevSecOps-Praktiken und die zunehmende Branchenrelevanz angesichts der wachsenden Codemengen mit potenziellen Sicherheitslücken.

Es gibt jedoch ein etwas merkwürdiges Problem. Fast die Hälfte aller Unternehmen versendet wissentlich anfälligen Code, trotz mit einer Reihe von AppSec-Tools, die genau das verhindern sollen. Für Produkte mit einer unbestreitbaren Marktnachfrage, die schnell an Fahrt gewinnt, macht das wenig Sinn. Warum sollten sich so viele auf ausgeklügelte Sicherheitstools einlassen, nur um ihre Erkenntnisse zu ignorieren oder sie überhaupt nicht zu nutzen? Es 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 verwendet werden, wie wir es vielleicht erwarten würden. Es geht weniger um die Tools und ihre Funktionalität als vielmehr darum, wie sie sich in ein Sicherheitsprogramm als Ganzes integrieren lassen.

Mehr Tools bedeuten nicht weniger Probleme.

Da Unternehmen ihre Softwareentwicklungsprozesse weiterentwickeln und von Agile zu DevOps und zum heiligen Nirvana DevSecOps übergehen (hey, im Moment ist es das Beste, was wir haben), ist es unvermeidlich, dass mehrere Scanner, Monitore, Firewalls und alle Arten von AppSec-Tools gekauft werden. Obwohl es den Anschein hat, als ob es sich um „je mehr, desto besser“ handelt, führt dies sehr oft zu einem Tech-Stack, der Frankensteins Monster ähnelt, mit all der Unvorhersehbarkeit, die dies impliziert.

Angesichts der Tatsache, dass Budgets und Expertenressourcen für den erforderlichen Arbeitsumfang immer knapper werden, ist es eine schwierige Aufgabe, das Chaos zu beheben und die besten Tools für die Zukunft zu finden, und der Code, der gescannt und korrigiert werden muss, kommt einfach weiter. Es ist kein Wunder, dass viele Unternehmen weiterhin Code versenden mussten, obwohl das ziemlich alarmierend ist und immer noch ein immenses Risiko für unsere Daten und Privatsphäre darstellt.

Scan-Tools sind langsam, was sich negativ auf die Release-Agilität auswirkt.

Schnelles Erreichen von Sicherheit ist so etwas wie ein weißer Wal in der Softwareentwicklung, und die Wahrheit ist, dass wir immer noch versuchen, das richtig zu machen, auch wenn wir Unternehmen dazu bringen, einen DevSecOps-orientierten Ansatz zu verfolgen. Eine akribische, manuelle Codeüberprüfung mag in den 90er Jahren als Sicherheitsausfallschutz gedient 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.

Scan-Tools automatisieren das Auffinden potenzieller Probleme und übernehmen den sorgfältigen Teil der Codeüberprüfung für uns. Das Problem ist, dass sie im Zusammenhang mit einer CI/CD-Pipeline, die auf allen Zylindern läuft, immer noch langsam sind und kein Tool alle Sicherheitslücken findet. Es gibt auch ein paar eklatante Probleme mit den Ergebnissen, die dem Sicherheitsteam nach einem Scan mitgeteilt werden:

1. Es gibt eine Menge von falsch positiven (und negativen)
2. Ein schlechter Sicherheitsexperte muss immer noch da sitzen 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äufig vorkommende Sicherheitslücken aufgedeckt, die vor der Bereitstellung des Codes hätten erkannt werden müssen. Möchten Sie wirklich, dass Ihre sehr teuren Sicherheitsexperten von den großen, haarigen Sicherheitsproblemen mit den kleinen Dingen abgelenkt werden?
4. Scanner finden, sie reparieren nicht.

Selbst in einer Organisation, die ihr Bestes tut, um an den Best Practices der Cybersicherheit zu arbeiten und mit der Zeit Schritt zu halten, um Sicherheit in jede Phase des Prozesses einzubeziehen, ist der oben genannte Prozess immer noch ein Hingucker, wenn Scanner die wichtigste Schutzmaßnahme sind und zu viele häufige Fehler das Team bei der Bereitstellung von sicherem Code zum Stolpern bringen. Es liegt auf der Hand, dass hier Abstriche gemacht werden können, und das in der Regel in der Form, dass man sich auf ein Minimum an Tools verlässt, die unmöglich jedes potenzielle Risiko abdecken können, selbst wenn eine Reihe von Lösungen gekauft wurde.

Eine gewisse technisch führende Automatisierung kann zu einer verminderten Codequalität führen

Beim Scannen und Testen fällt die Last automatisierter Prozesse in den AppSec-Tools zusammen mit grundlegenden Funktionen wie Firewalls und Überwachung auf. Andere gängige Tools können jedoch im Laufe der Zeit versehentlich die praktischen Sicherheitsgrundlagen untergraben.

Beispielsweise wird die RASP-Technologie (Runtime Application Self-Protection) häufig eingesetzt, um die Sicherheitslage zu verbessern, ohne die Programmiergeschwindigkeit zu beeinträchtigen. Sie arbeitet in der Laufzeitumgebung einer Anwendung und schützt vor der Eingabe von bösartigem Code, Angriffen in Echtzeit und warnt vor merkwürdigem Ausführungsverhalten.

Es ist sicherlich eine zusätzliche Schutzschicht, aber wenn es als Failsafe gegen potenzielle Schwächen in der Codebasis betrachtet wird, können Entwickler selbstgefällig werden, insbesondere wenn sie mit zunehmend unmöglichen Markteinführungsfristen für die Einführung neuer Funktionen konfrontiert werden. Sichere Codierungspraktiken werden möglicherweise nicht befolgt, da davon ausgegangen wird, dass der Selbstschutz zur Laufzeit alle Fehler erkennt. Entwickler geben sich keine Mühe, unsichere Codierungsmuster zu erstellen, aber die Sicherheit wird häufig zugunsten der Bereitstellung von Funktionen untergeordnet, insbesondere unter der Annahme automatisierter Schutzmaßnahmen.

Tools können ausfallen (und im Fall von RASP werden sie oft im Überwachungsmodus ausgeführt, um Fehlalarme zu vermeiden, was wiederum nur Sichtbarkeit — keinen Schutz — vor Angriffen bietet), und wenn das passiert, handelt es sich um hochwertigen, sicheren Code, auf den man sich jedes Mal verlassen kann. Das Sicherheitsbewusstsein in jeder Rolle, die mit Code zu tun hat, ist für DevSecOps von grundlegender Bedeutung, und Entwickler, die nicht in sicherem Code geschult sind oder diesen nicht produzieren, ist ein Fehler. Das Schreiben von sicherem und unsicherem Code erfordert den gleichen Aufwand. Es erfordert die eigentliche Energie, sich das Wissen anzueignen, um sicher zu programmieren. Die Zeit, die für die Implementierung und Optimierung von RASP aufgewendet wird, kann viel besser genutzt werden, um Entwickler weiterzubilden, damit sie den Fehler gar nicht erst machen.

Tools und Menschen in Einklang bringen: Es ist keine Wunderwaffe, aber es ist das nächste, was wir (vorerst) haben.

Das Hauptethos von DevSecOps besteht darin, Sicherheit zu einer gemeinsamen Verantwortung zu machen, und Unternehmen, die die Software entwickeln, die unser Leben antreibt — vom Stromnetz bis zu unseren Türklingeln — müssen alle mit auf die Reise nehmen, um ein höheres Maß an Sicherheit zu gewährleisten.

Tools machen nicht alles, und es ist nicht einmal der billigste Weg. Die mit Abstand besten Ergebnisse werden erzielt, wenn relevante Sicherheitsschulungen für alle, die mit Code zu tun haben, aktiv daran gearbeitet wird, die Sicherheit für das Entwicklungsteam in den Mittelpunkt zu stellen, und eine positive Sicherheitskultur aufzubauen, die von Menschen geleitet wird, mit einer Toolsuite, die eine unterstützende Rolle spielt.

Selbst angesichts von Zeitengpässen, Kürzungen und anderen Dingen, die Sicherheitsexperten nachts den Schlaf rauben, stellen diese Tools (und ob sie verwendet werden oder nicht) einen weitaus geringeren Risikofaktor dar, wenn Entwickler nicht von vornherein übliche Sicherheitslücken einführen.

‍