Reaktive versus präventive Sicherheit: Prävention ist das bessere Heilmittel

Sicherheitsteams haben Mühe, mit der Flut neuer Innovationen in der heutigen Cloud-gesteuerten DevOps-Welt Schritt zu halten. Daher ist es nur logisch, dass sie auch nicht mit den unzähligen Möglichkeiten Schritt halten können, mit denen Angreifer die Schwachstellen ausnutzen, die sich bei der ständigen Generierung von so viel Code zwangsläufig ergeben. 

Doch trotz der zunehmenden Zahl bedeutender Sicherheitsverletzungen - von der Datenschutzverletzung bei Equifax und dem Angriff auf die Lieferkette von SolarWinds bis hin zu weiteren Vorfällen in den letzten Jahren, wie den erfolgreichen Angriffen auf Change Healthcare, AT&T und andere - konzentrieren sich viele Unternehmen weiterhin auf einen reaktiven Sicherheitsansatz. Sie setzen den Großteil ihrer Sicherheitsressourcen darauf ein, Schwachstellen zu finden und zu beheben und auf Vorfälle zu reagieren, sobald sie auftreten. Dieser Ansatz mag in einer anderen Zeit angemessen gewesen sein, aber die rasante Entwicklung von Software, technologischen Möglichkeiten und IT-Infrastrukturen überfordert die unterbesetzten und überlasteten Sicherheitsteams, da sie nicht Schritt halten können.

Um zu vermeiden, dass sie ständig benachteiligt werden, müssen sie aufhören, Sicherheitsbedrohungen nachzujagen, die sich für sie zu schnell entwickeln, oder zu warten, bis das Pferd der Datenpanne aus dem Stall ist. Stattdessen sollten sie dem Problem zuvorkommen, indem sie einen präventiven und nicht einen reaktiven Ansatz verfolgen. Die Verbesserung der Sicherheit sowohl von Legacy-Anwendungen als auch von neuen Anwendungen erfordert einen Secure-by-Design-Ansatz, der durch effektive Entwicklerschulungen unterstützt wird, um sicherzustellen, dass zu Beginn des Softwareentwicklungszyklus (SDLC) bewährte Sicherheitspraktiken angewendet und Schwachstellen behoben werden, bevor sie in die Produktion gelangen.

Bislang war dies leichter gesagt als getan. 

Sichere Codierer sind Mangelware

Die US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) hat versucht, mit ihrer Secure-by-Design-Initiative, die sichere Kodierung zusammen mit anderen bewährten Praktiken - von der Multi-Faktor-Authentifizierung (MFA) bis hin zur Reduzierung von Schwachstellen - fördert, die Prävention als Schlüsselpolitik voranzutreiben und Organisationen dazu zu ermutigen, das Secure-by-Design-Versprechen abzulegen. Andere Länder, darunter Australien, Kanada, Deutschland und Großbritannien, haben ähnliche Programme gestartet. Unsere Recherchen haben jedoch ergeben, dass sich bisher nur sehr wenige Unternehmen daran beteiligt haben.

Wenn wir alle Entwickler auf Secure Code Warrior's Learning Platform mit denen der SCW-Konkurrenten, die in der Secure-by-Design-Ader arbeiten, kombinieren, gibt es zwischen 500.000 und 1 Million Entwickler, die diesen Ansatz verfolgen. Nach der großzügigsten Schätzung sind das etwa 3,5 % der Gesamtzahl der Entwickler weltweit, die bis Ende 2024 voraussichtlich 28,7 Millionen erreichen wird. Das sind viele Entwickler, die mehr Code produzieren als je zuvor, vor allem angesichts der Tatsache, dass generative Programme für künstliche Intelligenz das Entwicklungstempo erheblich beschleunigen, und nur sehr wenige lernen, wie man mit sicherem Code beginnt. 

Software-Ingenieure werden in der Regel nicht in Cybersicherheit unterrichtet, weil das traditionelle Modell vorsieht, dass Entwickler und Sicherheitsexperten als getrennte Einheiten arbeiten, wobei sich die Sicherheitsteams erst nach der Erstellung der Software um Sicherheitsfragen kümmern. Doch Sicherheitsexperten sind in der heutigen Umgebung deutlich in der Minderheit. Der jüngste Bericht zum Building Security in Maturity Model (BSIMM14) zeigt, dass auf 100 Entwickler weltweit im Durchschnitt 3,87 AppSec-Experten kommen. Weniger als vier ausgebildete Spezialisten, die versuchen, den Output von 100 Entwicklern zu sichern, die mit halsbrecherischer Geschwindigkeit arbeiten, sind kein Rezept für sicheren Code. 

Die Vernachlässigung der Anwendungssicherheit wird auch deutlich, wenn man ihre Marktgröße mit anderen Sicherheitsbereichen vergleicht. Die Komponenten, aus denen sich ein Secure-by-Design-Ansatz zusammensetzt, fallen in den Markt für Anwendungssicherheit, der von 6,08 Milliarden US-Dollar im Jahr 2023 auf 17,51 Milliarden US-Dollar im Jahr 2031 anwachsen soll. Das sieht nach einem rasanten Wachstum aus, verblasst aber im Vergleich zu den Ausgaben für die Netzwerksicherheit, die von 23,57 Milliarden Dollar im Jahr 2023 auf 67,33 Milliarden Dollar im Jahr 2032 steigen sollen, oder für die Sicherheit der Betriebstechnologie, die von 18,03 Milliarden Dollar im Jahr 2023 auf 57,51 Milliarden Dollar im Jahr 2031 ansteigen soll. 

In Anbetracht der wachsenden Bedeutung von sicherem Code und sicheren Anwendungen ist dieser Bereich unterfinanziert. Wenn Unternehmen mehr in die Anwendungssicherheit und einen Secure-by-Design-Ansatz investieren, können sie möglicherweise in anderen Sicherheitsbereichen sparen. 

Es gibt noch eine Reihe anderer Faktoren, die dazu beitragen, dass präventive Sicherheit schwieriger zu implementieren und daher auch schwieriger an Führungskräfte zu verkaufen ist. Zum einen sind Unternehmen, die schon lange bestehen, wie z. B. im Finanzdienstleistungssektor, mit alten Altsystemen belastet, von denen einige noch aus der Mitte des letzten Jahrhunderts stammen, als COBOL die Programmiersprache der Wahl war. 

Der Gedanke, Legacy-Code und -Systeme zur gleichen Zeit wie neuere Anwendungen mit präventiver Sicherheit auszustatten, kann entmutigend erscheinen, aber ein Secure-by-Design-Ansatz, der durch die Weiterbildung von Entwicklern durchgesetzt wird, kann die besten Sicherheitsverfahren auf diese Systeme anwenden. Dies ist für viele Unternehmen die beste Chance, ihre Sicherheitslage zu verbessern. 

Aufbau einer Kultur der Prävention

Der Übergang zu einem präventiven Sicherheitskonzept mag nur langsam vonstatten gehen, aber der Druck zur Einführung von Secure-by-Design-Verfahren wird nicht nachlassen, denn die dringende Notwendigkeit dafür ist in der heutigen Cyber-Bedrohungslandschaft ungebrochen. Die Automobilindustrie würde in die Pfanne gehauen, wenn sie in mehr Krankenwagen und Sanitäter investieren würde, anstatt die Autos sicherer zu machen, doch viele Unternehmen folgen diesem Modell, wenn es um Cybersicherheit geht.

Unternehmen müssen einen präventiven, proaktiven Ansatz zur Risikominderung verfolgen. Sie sollten Programme entwickeln, um Entwickler für das Schreiben von sicherem Code und die Korrektur von Fehlern (z. B. durch KI-Assistenten oder Code von Drittanbietern) frühzeitig im SDLC zu schulen. Diese Programme sollten agile, interaktive Schulungsprogramme umfassen, die sich den Zeitplänen der Entwickler anpassen und auf ihre Arbeitsumgebung und die von ihnen verwendeten Programmiersprachen zugeschnitten werden können. Upskilling sollte praktische Schulungen beinhalten, die sich mit realen Problemen befassen.

Wichtig ist, dass es ein Mittel zur Messung der Fortschritte gibt, um zu gewährleisten, dass bewährte Sicherheitspraktiken zu einem wesentlichen Bestandteil der täglichen Routine geworden sind. Ein Tool wie der Trust Score von SCW nutzt Benchmarks, um den Fortschritt sowohl intern als auch im Vergleich zu Branchenstandards zu messen und gleichzeitig Bereiche zu identifizieren, die verbessert werden müssen. 

Ein "Secure-by-Design"-Ansatz wäre ganzheitlich und würde eine auf Sicherheit ausgerichtete Denkweise innerhalb des Unternehmens widerspiegeln, bei der Sicherheit eine geschäftliche Priorität darstellt. Reaktions- und Wiederherstellungsmaßnahmen sind zweifellos wichtige Bestandteile der allgemeinen Sicherheitsvorkehrungen eines Unternehmens. Durch die Konzentration auf die Vorbeugung können Unternehmen jedoch große Fortschritte bei der Risikominderung machen und vielleicht die Art von größeren Sicherheitsverletzungen vermeiden, die die Lebensfähigkeit eines Unternehmens gefährden können.

Erfahren Sie mehr darüber, wie Secure Code Warrior Sie bei der Umsetzung einer realisierbaren Secure-by-Design-Initiative unterstützen kann.