Prävention im Zeitalter der unendlichen Angriffsfläche

Eine Version dieses Artikels erschien in der SD-Zeiten. Er wurde aktualisiert und hier wiedergegeben.

‍

Wenn wir über Fortschritt sprechen, steht in der Regel der digitale Fortschritt im Vordergrund des Gesprächs. Wir wollen alles besser, schneller, bequemer, leistungsfähiger und mit weniger Geld, Zeit und Risiko erreichen. In den meisten Fällen werden diese "unmöglichen" Ziele schließlich erreicht. Es kann zwar mehrere Jahre und mehrere Versionen dauern (und ein Team von Entwicklern, das einen Putsch anzettelt, wenn es noch ein einziges Mal gebeten wird, beim Funktionsdesign einen anderen Gang einzulegen), aber jeden Tag verändert der Code da draußen die Welt. 

Mit einer großen Softwareexpansion geht jedoch auch eine große Verantwortung einher, und die Realität ist, dass wir aus der Sicherheitsperspektive einfach noch nicht bereit sind, damit umzugehen. Die Softwareentwicklung ist keine Insel mehr, und wenn wir alle Aspekte des softwarebasierten Risikos berücksichtigen - von der Cloud über eingebettete Systeme in Geräten und Fahrzeugen bis hin zu unserer kritischen Infrastruktur, ganz zu schweigen von den APIs, die alles miteinander verbinden - ist die Angriffsfläche grenzenlos und außer Kontrolle. 

Wir können keine magische Zeit erwarten, in der jede Codezeile von erfahrenen Sicherheitsexperten akribisch geprüft wird - diese Qualifikationslücke wird sich in absehbarer Zeit nicht schließen -, aber wir können als Branche einen ganzheitlicheren Ansatz für die Sicherheit auf Codeebene verfolgen.

Lassen Sie uns untersuchen, wie wir diese unendliche Angriffsfläche mit den uns zur Verfügung stehenden Tools eindämmen können:

Seien Sie realistisch, was das Geschäftsrisiko angeht (und was Sie bereit sind zu akzeptieren)

Perfekte Sicherheit ist nicht von Dauer, aber es ist auch nicht möglich, sich die Augen zu verbinden und so zu tun, als sei alles in Butter. Wir wissen bereits, dass Unternehmen wissentlich anfälligen Code ausliefern, und dies ist eindeutig ein kalkuliertes Risiko, das auf der Markteinführungszeit neuer Funktionen und Produkte beruht. 

Sicherheit im Eiltempo ist eine Herausforderung, vor allem dort, wo DevSecOps nicht zur Standardentwicklungsmethodik gehört. Wir brauchen uns jedoch nur den jüngsten Log4Shell-Exploit anzusehen, um zu erkennen, wie relativ kleine Sicherheitslücken im Code Möglichkeiten für einen erfolgreichen Angriff eröffnet haben, und um zu sehen, dass die Folgen dieser kalkulierten Risiken für die Auslieferung von minderwertigem Code viel größer sein könnten als angenommen.

Gewöhnen Sie sich daran, ein (Zugangs-)Kontrollfreak zu sein

Eine alarmierende Anzahl von kostspieligen Datenschutzverletzungen wird durch schlecht konfigurierte Cloud-Speicherumgebungen verursacht, und die Gefahr der Offenlegung sensibler Daten aufgrund von Fehlern bei der Zugriffskontrolle beschäftigt die Sicherheitsteams in den meisten Unternehmen weiterhin. 

Im Jahr 2019 musste das Fortune-500-Unternehmen First American Financial Corp. diese Erfahrung auf die harte Tour machen. Ein Authentifizierungsfehler - der relativ einfach zu beheben war - führte zur Offenlegung von über 800 Millionen Datensätzen, darunter Kontoauszüge, Hypothekenverträge und Fotoausweise. Die Links zu den Dokumenten erforderten keine Benutzeridentifizierung oder Anmeldung, so dass sie für jeden mit einem Webbrowser zugänglich waren. Schlimmer noch, sie wurden mit fortlaufenden Nummern protokolliert, was bedeutet, dass eine einfache Änderung der Nummer im Link einen neuen Datensatz enthüllte. 

Dieses Sicherheitsproblem wurde intern erkannt, bevor es in den Medien aufgedeckt wurde. Allerdings führten Versäumnisse bei der korrekten Einstufung als Hochrisiko-Sicherheitsproblem und das Versäumnis, es der Geschäftsleitung zur dringenden Behebung zu melden, zu Auswirkungen, die bis heute andauern.

Es gibt einen Grund dafür, dass eine unzureichende Zugriffskontrolle jetzt ganz oben auf der OWASP Top 10 steht: Sie ist weit verbreitet und Entwickler benötigen ein verifiziertes Sicherheitsbewusstsein und praktische Fähigkeiten, um Best Practices rund um Authentifizierung und Privilegien in ihren eigenen Builds zu beherrschen und sicherzustellen, dass Prüfungen und Maßnahmen zum Schutz sensibler Daten vorhanden sind. 

Die Natur von APIs macht sie besonders relevant und heikel; sie sind von vornherein sehr gesprächig mit anderen Anwendungen, und Entwicklungsteams sollten alle potenziellen Zugangspunkte im Blick haben. Schließlich können sie in ihrem Bestreben, sichere Software bereitzustellen, keine unbekannten Variablen und Anwendungsfälle berücksichtigen.

Analysieren Sie Ihr Sicherheitsprogramm: Wie viel Wert wird auf Prävention gelegt?

Es ist sinnvoll, dass ein großer Teil eines Sicherheitsprogramms der Reaktion auf einen Vorfall gewidmet ist, aber viele Unternehmen verpassen eine wertvolle Risikominimierung, indem sie nicht alle verfügbaren Ressourcen nutzen, um einen Sicherheitsvorfall von vornherein zu verhindern.

Sicher, es gibt umfassende Sicherheitstools, die bei der Aufdeckung problematischer Fehler helfen, aber fast 50 % der Unternehmen gaben zu, dass sie Code ausgeliefert haben, von dem sie wussten, dass er anfällig ist. Zeitmangel, die Komplexität der Toolsets und der Mangel an geschulten Experten, die auf Meldungen reagieren können, tragen dazu bei, dass es sich im Wesentlichen um ein kalkuliertes Risiko handelt. Die Tatsache, dass Code in der Cloud, in Anwendungen, in API-Funktionen, eingebetteten Systemen, Bibliotheken und einer sich ständig erweiternden Technologielandschaft gesichert werden muss, sorgt jedoch dafür, dass wir mit dem derzeitigen Ansatz immer einen Schritt hinterherhinken werden.

Sicherheitsfehler sind ein von Menschen verursachtes Problem, und wir können nicht erwarten, dass Roboter die ganze Arbeit für uns erledigen. Wenn Ihre Entwickler nicht effektiv weitergebildet werden - nicht nur durch ein jährliches Seminar, sondern durch geeignete Ausbildungsbausteine - dann besteht immer die Gefahr, dass Sie minderwertigen Code als Standard akzeptieren und das damit verbundene Sicherheitsrisiko in Kauf nehmen. 

Haben Sie die Bereitschaft Ihrer Entwickler überschätzt?

Entwickler werden selten nach ihren Fähigkeiten zur sicheren Programmierung beurteilt, und es ist nicht ihre Priorität (und in vielen Fällen auch kein KPI). Sie können nicht die Sündenböcke für schlechte Sicherheitspraktiken sein, wenn ihnen kein besserer Weg aufgezeigt oder gesagt wird, dass dies ein Maßstab für ihren Erfolg ist. 

Allzu oft wird in Unternehmen jedoch davon ausgegangen, dass die bereitgestellten Anleitungen das Entwicklungsteam wirksam auf die Eindämmung gängiger Sicherheitsrisiken vorbereitet haben. Je nach Schulung und Bewusstsein für die Anwendung bewährter Sicherheitspraktiken sind sie möglicherweise nicht darauf vorbereitet, die wünschenswerte erste Verteidigungslinie zu sein (und endlose Injektionsfehler zu verhindern, die die Pentestberichte verstopfen). 

Der Idealzustand ist, dass Lernpfade von zunehmender Komplexität absolviert werden und die daraus resultierenden Fähigkeiten überprüft werden, um sicherzustellen, dass sie für den Entwickler in der realen Welt tatsächlich funktionieren. Dies erfordert jedoch einen kulturellen Standard, bei dem die Entwickler von Anfang an berücksichtigt und korrekt befähigt werden. Wenn wir uns als Branche in die Wildnis begeben, um diese riesige Codelandschaft, die wir selbst geschaffen haben, zu verteidigen, brauchen wir jede Hilfe, die wir bekommen können... und es gibt mehr davon direkt vor unserer Nase, als uns bewusst ist.