Prävention im Zeitalter der unendlichen Angriffsfläche

Eine Version dieses Artikels erschien in der SD Times. Er wurde aktualisiert und hier syndiziert.

‍

Wenn wir über Fortschritt sprechen, steht die digitale Entwicklung meist im Mittelpunkt. Wir wollen alles besser, schneller, bequemer und leistungsfähiger – und das bei geringerem Kosten-, Zeit- und Risikoaufwand. Die meisten dieser „unmöglichen“ Ziele werden letztlich erreicht; es mag Jahre und mehrere Versionen dauern (und ein Entwicklerteam, das kurz vor einer Meuterei steht, wenn es noch ein einziges Mal die Richtung beim Feature-Design ändern soll), aber jeden Tag verändert Code die Welt.

Doch mit der enormen Ausweitung der Software wächst auch die Verantwortung, und die Realität ist, dass wir aus Sicherheitsperspektive einfach nicht darauf vorbereitet sind. Softwareentwicklung ist keine isolierte Angelegenheit mehr. Wenn wir alle Aspekte softwarebasierter Risiken berücksichtigen – von der Cloud über eingebettete Systeme in Haushaltsgeräten und Fahrzeugen bis hin zu unserer kritischen Infrastruktur, ganz zu schweigen von den APIs, die alles miteinander verbinden –, dann ist die Angriffsfläche grenzenlos und außer Kontrolle.

Wir können nicht auf eine magische Zeit hoffen, in der jede Codezeile akribisch von erfahrenen Sicherheitsexperten geprüft wird – diese Qualifikationslücke wird sich so schnell nicht schließen –, aber wir können als Branche einen ganzheitlicheren Ansatz für Sicherheit auf Code-Ebene verfolgen.

Lassen Sie uns untersuchen, wie wir diese unendliche Angriffsfläche mit den vorhandenen Mitteln eingrenzen können:

Seien Sie realistisch in Bezug auf das Geschäftsrisiko (und was Sie bereit sind zu akzeptieren)

Perfekte Sicherheit ist nicht nachhaltig, aber sich die Augen zu verbinden und so zu tun, als sei alles in bester Ordnung, ist es ebenso wenig. Wir wissen bereits, dass Unternehmen wissentlich anfälligen Code veröffentlichen, und dies ist eindeutig ein kalkuliertes Risiko, um neue Funktionen und Produkte schneller auf den Markt zu bringen.

Sicherheit bei hoher Geschwindigkeit ist eine Herausforderung, insbesondere dort, wo DevSecOps nicht die Standard-Entwicklungsmethodik ist. Wir müssen uns jedoch nur den jüngsten Log4Shell-Exploit ansehen, um zu erkennen, wie relativ kleine Sicherheitsprobleme im Code Möglichkeiten für einen erfolgreichen Angriff eröffnet haben, und um zu verstehen, dass die Folgen dieser kalkulierten Risiken bei der Veröffentlichung von Code minderer Qualität weit größer sein können als prognostiziert.

Gewöhnen Sie sich daran, ein Kontrollfreak (in Sachen Zugriff) zu sein

Eine alarmierende Anzahl kostspieliger Datenschutzverletzungen wird durch schlecht konfigurierte Cloud-Speicherumgebungen verursacht, und das Potenzial für die Offenlegung sensibler Daten durch Fehler bei der Zugriffskontrolle verfolgt Sicherheitsteams in den meisten Unternehmen.

Im Jahr 2019 musste das Fortune-500-Unternehmen First American Financial Corp. dies auf die harte Tour lernen. Ein Authentifizierungsfehler – der relativ einfach zu beheben gewesen wäre – führte zur Offenlegung von über 800 Millionen Datensätzen, darunter Kontoauszüge, Hypothekenverträge und Personalausweise. Die Dokumentenlinks erforderten keine Benutzeridentifizierung oder Anmeldung, wodurch sie für jeden mit einem Webbrowser zugänglich waren. Schlimmer noch: Sie waren fortlaufend nummeriert, was bedeutete, dass eine einfache Änderung der Nummer im Link einen neuen Datensatz freilegte.

Dieses Sicherheitsproblem wurde intern identifiziert, bevor es in den Medien bekannt wurde. Versäumnisse bei der korrekten Einstufung als Hochrisiko-Sicherheitsproblem und das Unterlassen der Meldung an das Senior Management zur dringenden Behebung führten jedoch zu einem Nachspiel, das bis heute andauert.

Es gibt einen Grund, warum fehlerhafte Zugriffskontrolle mittlerweile ganz oben auf der OWASP Top 10 steht: Sie ist allgegenwärtig. Entwickler benötigen ein fundiertes Sicherheitsbewusstsein und praktische Fähigkeiten, um Best Practices für Authentifizierung und Berechtigungen in ihren eigenen Builds umzusetzen und sicherzustellen, dass Kontrollmechanismen zum Schutz sensibler Daten vorhanden sind.

Die Natur von APIs macht sie besonders relevant und tückisch; sie sind von Design her sehr kommunikativ mit anderen Anwendungen, und Entwicklungsteams sollten den Überblick über alle potenziellen Zugriffspunkte behalten. Schließlich können sie bei ihrem Streben nach sichererer Software 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 Vorfälle gewidmet ist, aber viele Unternehmen verschenken wertvolle Möglichkeiten zur Risikominimierung, indem sie nicht alle verfügbaren Ressourcen nutzen, um Sicherheitsvorfälle von vornherein zu verhindern.

Sicher, es gibt umfassende Sicherheitstools, die dabei helfen, kritische Fehler aufzudecken, doch fast 50 % der Unternehmen gaben zu, Code veröffentlicht zu haben, von dem sie wussten, dass er anfällig ist. Zeitdruck, die Komplexität der Toolsets und ein Mangel an geschulten Experten für die Reaktion auf Meldungen tragen zu dem bei, was im Grunde ein kalkuliertes Risiko ist. Doch die Tatsache, dass Code in der Cloud, in Anwendungen, API-Funktionen, eingebetteten Systemen, Bibliotheken und einer ständig wachsenden Technologielandschaft abgesichert werden muss, sorgt dafür, dass wir mit dem aktuellen Ansatz immer einen Schritt hinterherhinken.

Sicherheitslücken sind ein menschliches Problem, und wir können nicht erwarten, dass Roboter die gesamte Fehlerbehebung für uns übernehmen. Wenn Ihr Entwicklungsteam nicht effektiv weitergebildet wird – nicht nur durch ein jährliches Seminar, sondern durch fundierte Bildungsbausteine –, laufen Sie immer Gefahr, minderwertigen Code als Standard zu akzeptieren und das damit verbundene Sicherheitsrisiko in Kauf zu nehmen.

Haben Sie die Einsatzbereitschaft Ihrer Entwickler überschätzt?

Entwickler werden selten nach ihren Fähigkeiten im sicheren Programmieren bewertet, und es hat für sie keine Priorität (und ist in vielen Fällen auch kein KPI). Sie können nicht für schlechte Sicherheitspraktiken verantwortlich gemacht werden, wenn ihnen kein besserer Weg aufgezeigt wird oder ihnen nicht vermittelt wird, dass dies ein Maßstab für ihren Erfolg ist.

Allzu oft wird in Unternehmen jedoch davon ausgegangen, dass die bereitgestellten Leitlinien das Engineering-Team effektiv auf die Minderung gängiger Sicherheitsrisiken vorbereitet haben. Je nach Schulung und Bewusstsein für die Anwendung von Best Practices im Sicherheitsbereich sind sie möglicherweise nicht darauf vorbereitet, die gewünschte erste Verteidigungslinie zu bilden (und zu verhindern, dass endlose Injektionsfehler die Pentest-Berichte verstopfen).

Der Idealzustand ist, dass Lernpfade mit zunehmender Komplexität absolviert werden und die daraus resultierenden Fähigkeiten überprüft werden, um sicherzustellen, dass sie für den Entwickler in der Praxis auch wirklich funktionieren. Dies erfordert jedoch einen kulturellen Standard, bei dem Entwickler von Anfang an berücksichtigt und richtig befähigt werden. Wenn wir als Branche in die Wildnis hinausziehen, um diese riesige Landschaft aus Code zu verteidigen, die wir selbst geschaffen haben, brauchen wir jede Hilfe, die wir bekommen können – und davon liegt mehr direkt vor uns, als wir ahnen.