Ein CISO eines milliardenschweren Unternehmens, mit dem wir kürzlich gesprochen haben, machte eine Bemerkung, die mir im Gedächtnis geblieben ist. Die Sicherheitsfunktion, die sie am meisten schätzten, war nicht ein weiteres Erkennungstool oder -framework. Es war Schnelligkeit.
Für sie stand die Schnelligkeit bei der Erkennung von Problemen, der Überprüfung von Lösungen und der Reaktion auf Veränderungen an erster Stelle. Angesichts der vielen Probleme, die es zu bewältigen gilt, deutet dies auch darauf hin, dass Zeit zunehmend zu einem operativen Engpass wird.
Der Cybersicherheitsexperte Phil Venables hat kürzlich darauf hingewiesen, dass der Erfolg oder Misserfolg von Sicherheitsprogrammen zunehmend von ihrer Geschwindigkeit abhängen wird.
„Auf Geschwindigkeit kommt es an. Vor allem darauf, wie Verteidiger ihren OODA-Zyklus (Beobachten, Orientieren, Entscheiden, Handeln) schneller durchlaufen können, als Angreifer sich anpassen können.“
Dies ist jedoch kein weiterer Artikel nach dem Motto „Die KI ist schuld an diesem Chaos“ – lassen Sie uns der Realität ins Auge sehen. Unsere Umfrage unter 200 CISOs und 200 Führungskräften aus dem technischen Bereich (einschließlich CTOs) ergab, dass 76 % der Unternehmen wöchentlich oder noch häufiger umfangreiche Updates bereitstellen und 39 % sogar täglich. Moderne Entwicklungsteams führen Änderungen kontinuierlich ein.
Doch die Sicherheitsüberprüfung erfolgt nicht in diesem Rhythmus; nur 21 % führen bei jeder Veröffentlichung eine Sicherheitsüberprüfung durch. Das ist mehr als nur eine Diskrepanz, es ist ein strukturelles Versagen.
Tempobahnen
Venables verweist auf Stewart Brands„PaceLayers“-Modell, um zu erklären, wie sich komplexe Systeme entwickeln.
„Die schnellen Schichten sorgen für Neuheit und Experimentierfreude, während die langsamen Schichten Stabilität und Erinnerung bieten.“
Die Softwarebereitstellung ist die schnelle Ebene, während Governance und Validierung die langsame Ebene bilden. Moderne Softwareumgebungen führen dazu, dass sich diese Ebenen immer weiter voneinander entfernen. Die Entwicklerteams steigern das Tempo ihrer Arbeit, während die Sicherheitsvalidierung nach wie vor in vierteljährlichen oder jährlichen Zyklen erfolgt.
Die Sicherheitsergebnisse liegen erst vor, nachdem sich das System bereits geändert hat – was bringt das also?
Die Folgen dieser Diskrepanz sind unvermeidlich: 85 % geben an, dass Sicherheitsbefunde zumindest manchmal bereits veraltet sind, wenn die Berichte eintreffen, wobei fast die Hälfte (48 %) davon sagt, dass dies sehr oft oder sogar immer der Fall ist.
Mit anderen Worten: Bis die Testergebnisse ausgewertet werden, hat sich das darin beschriebene System bereits verändert. Tatsächlich treffen Teams Sicherheitsentscheidungen auf der Grundlage eines früheren Zustands des Systems. Schon kleine Änderungen können die Sicherheitslage eines Systems verändern. Ein neuer Endpunkt, eine Anpassung der Autorisierungslogik oder eine aktualisierte Abhängigkeit können völlig neue Angriffswege eröffnen. Bei Penetrationstests wird oft eine Version des Systems überprüft, die gar nicht mehr existiert.
Infolgedessen können vorgeschlagene Korrekturen und erneute Tests zwar ältere Sicherheitsprobleme aufdecken, doch da sich die Software weiterentwickelt hat, verlieren die Teams allmählich das Vertrauen in die Informationen, die ihnen der Test geliefert hat, da diese Informationen zu spät kommen.
Das Ergebnis ähnelt ein wenig der vielschichtigen Zeitmechanik in „Inception“: Verschiedene Teile des Systems laufen nun mit sehr unterschiedlichen Geschwindigkeiten ab, und Maßnahmen, die in einer Ebene zu spät ergriffen werden, haben möglicherweise kaum Auswirkungen auf das, was sich in einer anderen Ebene bereits abspielt.
Schnelligkeit sollte nicht auf Kosten der Tiefe gehen
Für Unternehmen, die ihre Sicherheitslage verbessern möchten, erfordert die Validierung eine fundierte Begründung, eine gründliche Untersuchung, die Überprüfung von Sicherheitslücken sowie eine Analyse der Arbeitsabläufe. Sie muss gründlich sein (aber das wussten Sie ja bereits).
„Statische Analysen haben ihre Grenzen. Wenn man das Problem nicht anhand der laufenden Anwendung überprüfen kann, bleibt es nur eine Hypothese“, sagt Philippe Dourrasov, Leiter des Bereichs KI-Penetrationstests bei Aikido .
Aus diesem Grund haben fundierte Sicherheitstests in der Vergangenheit immer viel Zeit in Anspruch genommen.
Die Herausforderung besteht also nicht darin, die Anzahl der Tests zu erhöhen, sondern die Tiefe echter Offensivtests beizubehalten und gleichzeitig in einem deutlich höheren Tempo zu arbeiten.
Die Grenzen regelmäßiger Tests hinsichtlich ihrer Tiefe sind jedoch offensichtlich. In unserer Untersuchung sind 51 % der Befragten der Ansicht, dass tiefgreifendere Schwachstellen, wie beispielsweise Logikfehler, fehlerhafte Zugriffskontrollen oder mehrstufige Angriffspfade, immer oder häufig übersehen werden.
Das liegt nicht daran, dass es den Sicherheitsteams an Fachwissen mangelt. Vielmehr sehen sich Penetrationstester und Red Teams mit einer Reihe von Einschränkungen konfrontiert: zeitlich begrenzte Tests, wachsende Systeme, zunehmende Komplexität und die Vernetzung der Systeme. Im Kern ist das Dilemma zwischen Breite und Tiefe jedoch ein Zeitproblem.
Eine Validierung muss auf eine sinnvolle Änderung folgen
Unternehmen sind sich der zunehmenden Diskrepanz zwischen Entwicklungsgeschwindigkeit und Sicherheitsüberprüfung durchaus bewusst. Viele haben versucht, diese Lücke zu schließen, indem sie im Laufe des Jahres mehr Penetrationstests durchführen, kontinuierliche Scans einsetzen oder manuelle Prüfungen straffen, um sie an kürzere Release-Zyklen anzupassen. Theoretisch erhöhen diese Ansätze die Geschwindigkeit. In der Praxis verlagern sie die Sicherheitslücke jedoch oft nur an eine andere Stelle.
Der sinnvollere Ansatz besteht darin, die Validierung an die tatsächlichen Änderungen der Software anzupassen. Das bedeutet nicht, dass man alles ständig oder kontinuierlich testen muss, sondern dass die Validierung so gestaltet wird, dass sie reagiert, wenn wesentliche Änderungen eintreten. Mit anderen Worten: Es geht darum, Änderungen zu validieren, die tatsächlich Risiken mit sich bringen. Die Herausforderung besteht darin, dass die meisten bestehenden Testansätze nicht mit dieser Reaktionsgeschwindigkeit arbeiten können. Bei traditionellen Penetrationstests dauert es Tage oder Wochen, sie zu planen, durchzuführen und zu dokumentieren. Selbst die schnellsten Projekte können realistisch gesehen nicht mit Änderungen Schritt halten, die täglich oder mehrmals am Tag auftreten. Dabei handelt es sich nicht nur um kosmetische Änderungen, sondern um Dinge wie neue API-Endpunkte, Änderungen an der Autorisierungslogik, Agent-Workflows oder neue Integrationen von Drittanbietern.
Für Sicherheitsteams bedeutet dies in der Praxis, dass die Validierung Teil der Bereitstellungspipeline werden muss und nicht nur ein nachträglich angehängter Schritt sein darf. Dadurch verlagert sich der Schwerpunkt von der regelmäßigen Prüfung ganzer Systeme hin zur schrittweisen Validierung der Systeme.
{{cta}}
Das Bedürfnis nach Geschwindigkeit
Seit Jahrzehnten konzentrieren sich Unternehmen darauf, den Output zu steigern: mehr Code, mehr Funktionen, mehr Anwendungen. Die Teams, die schneller liefern, verschaffen sich einen Wettbewerbsvorteil. Venables argumentiert, dass dieses Prinzip zunehmend auch für die Sicherheit gilt.
Um wirklich von der Geschwindigkeit der modernen Softwareentwicklung zu profitieren, muss die Sicherheit mit derselben Geschwindigkeit voranschreiten. Unternehmen, die Probleme schneller erkennen, Korrekturen validieren und auf Veränderungen reagieren können, verschaffen sich einen Vorteil – nicht nur gegenüber Angreifern, sondern auch gegenüber Wettbewerbern, die im selben Bereich tätig sind. Diejenigen, denen dies nicht gelingt, werden zunehmend feststellen, dass sie auf der Grundlage veralteter Annahmen über ihre eigenen Systeme agieren.
Wenn sich verschiedene Ebenen eines Systems mit unterschiedlichen Geschwindigkeiten bewegen, kann es sein, dass Sicherheitsmaßnahmen, die zu spät greifen, bereits im falschen Zeitrahmen wirken – ähnlich wie in „Inception“, wo Maßnahmen, die in einer Ebene zu spät ergriffen werden, kaum Einfluss auf das haben, was sich in einer anderen Ebene bereits abspielt.
