Ein CISO eines Multi-Milliarden-Dollar-Unternehmens, mit dem wir kürzlich sprachen, machte eine Beobachtung, die mir im Gedächtnis geblieben ist. Die Sicherheitsfunktion, die sie am meisten schätzten, war kein weiteres Erkennungstool oder Framework. Es war Geschwindigkeit.
Für sie stand die Geschwindigkeit der Problemidentifizierung, der Validierung von Fixes und der Reaktion auf Änderungen im Vordergrund. Angesichts so vieler Baustellen deutet dies auch darauf hin, dass Zeit zu einer operativen Einschränkung wird.
Der Cybersicherheitsexperte Phil Venables schlug kürzlich vor, dass Sicherheitsprogramme zunehmend aufgrund von Geschwindigkeit erfolgreich sein oder scheitern werden.
„Geschwindigkeit ist alles. Insbesondere, wie Verteidiger ihre OODA (Observe, Orient, Decide, Act)-Schleife schneller durchlaufen können, als Angreifer sich anpassen können.“
Dies ist jedoch kein weiterer Artikel nach dem Motto „KI verursacht dieses Chaos“ – blicken wir der umfassenderen Realität ins Auge. In unserer Studie mit 200 CISOs und 200 Engineering-Führungskräften (einschließlich CTOs) stellen 76 % der Organisationen signifikante Updates wöchentlich oder schneller bereit und 39 % täglich. Moderne Engineering-Teams stellen Änderungen kontinuierlich bereit.
Doch die Sicherheitsvalidierung operiert nicht in diesem Takt; nur 21 % validieren die Sicherheit bei jeder Veröffentlichung. Dies ist mehr als eine Fehlausrichtung, es ist ein strukturelles Versagen.
Pace Layers
Venables verweist auf Stewart Brands „Pace Layers“-Framework, um zu erklären, wie sich komplexe Systeme entwickeln.
„Die schnellen Schichten bringen Neuheit und Experimentierfreudigkeit, und die langsamen Schichten bieten Stabilität und Gedächtnis.“
Die Software-Bereitstellung ist die schnelle Schicht, während Governance und Validierung die langsame Schicht darstellen. Moderne Softwareumgebungen treiben diese Schichten noch weiter auseinander. Entwicklungsteams erhöhen die Geschwindigkeit, mit der sie arbeiten, während die Sicherheitsvalidierung immer noch in quartalsweisen oder jährlichen Zyklen erfolgt.
Sicherheitsergebnisse kommen an, nachdem das System sich bereits geändert hat – was nützt das dann?
Was infolge dieser Diskrepanz geschieht, ist unvermeidlich: 85 % geben an, dass Sicherheitsergebnisse zumindest manchmal veraltet sind, wenn die Berichte eintreffen, wobei fast die Hälfte (48 %) angibt, dass dies sehr oft oder immer der Fall ist.
Mit anderen Worten: Wenn Testergebnisse überprüft werden, hat sich das von ihnen beschriebene System bereits geändert. Im Grunde treffen Teams Sicherheitsentscheidungen auf der Grundlage eines früheren Systemzustands. Selbst kleine Änderungen können die Sicherheitsposition eines Systems verschieben. Ein neuer Endpunkt, eine Anpassung der Autorisierungslogik oder eine aktualisierte Abhängigkeit können völlig neue Angriffswege eröffnen. Pentesting validiert oft eine Version des Systems, die nicht mehr existiert.
Infolgedessen können vorgeschlagene Korrekturen und erneute Tests ältere Sicherheitsprobleme zwar beheben, aber da die Software sich weiterentwickelt hat, verlieren Teams das Vertrauen in das Signal, das der Test ihnen geliefert hat, weil dieses Signal verspätet ist.
Das Ergebnis ähnelt den geschichteten Zeitmechanismen in Inception: Verschiedene Teile des Systems arbeiten nun mit sehr unterschiedlichen Geschwindigkeiten, und zu spät in einer Schicht ergriffene Maßnahmen haben möglicherweise wenig Einfluss auf das, was sich bereits in einer anderen entfaltet.
Geschwindigkeit sollte nicht auf Kosten der Tiefe gehen
Für Organisationen, die eine verbesserte Sicherheitsposition anstreben, benötigt die Validierung Argumentation, Exploration, Exploit-Bestätigung und Workflow-Analyse. Sie muss gründlich sein (aber das wussten Sie ja bereits).
„Statische Analyse hat ihre Grenzen. Wenn man das Problem nicht gegen die laufende Anwendung validieren kann, ist es nur eine Hypothese“, sagt Philippe Dourrasov, AI Pentest Lead bei Aikido Security.
Deshalb hat aussagekräftiges Sicherheitstesting historisch Zeit in Anspruch genommen.
Die Herausforderung besteht also nicht darin, die Anzahl der Tests zu erhöhen, sondern die Tiefe echter offensiver Tests zu bewahren, während man mit einem viel höheren Tempo arbeitet.
Die Grenzen periodischer Tests in Bezug auf die Tiefe sind jedoch klar. In unserer Untersuchung glauben 51 % der Befragten, dass tiefere Schwachstellen, wie Logikfehler, fehlerhafte Zugriffskontrolle oder mehrstufige Angriffswege, immer oder oft übersehen werden.
Dies liegt nicht daran, dass Sicherheitsteams keine Expertise haben. Vielmehr liegt es daran, dass Pentester und Red Teams mit einer Reihe von Einschränkungen konfrontiert sind: zeitlich begrenzte Tests, expandierende Systeme, zunehmende Komplexität und die Vernetzung von Systemen. Doch im Kern ist das Dilemma zwischen Breite und Tiefe eigentlich ein Zeitproblem.
Validierung muss bedeutsamen Änderungen folgen
Organisationen sind sich der wachsenden Diskrepanz zwischen Liefergeschwindigkeit und Sicherheitsvalidierung bewusst. Viele haben versucht, die Lücke zu schließen, indem sie das ganze Jahr über mehr Pentests durchführen, kontinuierlich scannen oder manuelle Engagements komprimieren, um engere Release-Zyklen zu ermöglichen. Theoretisch erhöhen diese Ansätze die Geschwindigkeit. In der Praxis verlagern sie den Kompromiss oft nur an eine andere Stelle.
Der bessere Ansatz ist es, die Validierung an die tatsächliche Veränderung der Software anzupassen. Das bedeutet nicht, alles ständig oder kontinuierlich zu testen, sondern die Validierung so zu gestalten, dass sie auf bedeutsame Änderungen reagieren kann. Mit anderen Worten: Änderungen validieren, die tatsächlich ein Risiko einführen. Die Herausforderung besteht darin, dass die meisten bestehenden Testansätze dieses Maß an Reaktionsfähigkeit nicht bieten können. Traditionelle Pentests dauern Tage oder Wochen für Planung, Ausführung und Berichterstattung. Selbst die schnellsten Engagements können mit täglich oder mehrmals täglich stattfindenden Änderungen realistisch nicht mithalten. Die Änderungen sind nicht nur kosmetischer Natur, sondern betreffen Dinge wie neue API-Endpunkte, Änderungen an der Autorisierungslogik, Agenten-Workflows oder neue Drittanbieter-Integrationen.
Was dies operativ für Sicherheitsteams bedeutet, ist, dass die Validierung Teil der Delivery Pipeline werden muss, nicht ein nachträglich angefügtes Ereignis. Dies wiederum verlagert den Fokus vom periodischen Testen ganzer Systeme auf die inkrementelle Validierung von Systemen.
{{cta}}
Die Notwendigkeit von Geschwindigkeit
Seit Jahrzehnten konzentrieren sich Organisationen auf die Steigerung des Outputs: mehr Code, mehr Features, mehr Anwendungen. Teams, die schneller liefern, erzielen einen Wettbewerbsvorteil. Venables argumentiert, dass dasselbe Prinzip zunehmend auch für die Sicherheit gilt.
Um wirklich von der Geschwindigkeit moderner Softwareentwicklung zu profitieren, muss die Sicherheit im gleichen Tempo agieren. Organisationen, die Probleme schneller erkennen, Korrekturen validieren und auf Ä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, die dies nicht können, werden zunehmend feststellen, dass sie auf veralteten Annahmen über ihre eigenen Systeme basieren.
Wenn verschiedene Schichten eines Systems mit unterschiedlichen Geschwindigkeiten agieren, kann Sicherheit, die zu spät reagiert, bereits im falschen Zeitrahmen agieren, ähnlich wie in Inception, wo zu spät in einer Schicht ergriffene Maßnahmen wenig Einfluss auf das haben, was sich bereits in einer anderen entfaltet.
