プロアクティブな保護:高度な脅威防止のための国家サイバーセキュリティ戦略の活用

Dieser Artikel erschien ursprünglich im Rahmen des Forbes Technology Council. Er wurde aktualisiert und hier syndiziert.

‍

Was glauben Sie, wie viele Datensätze im Jahr 2022 kompromittiert wurden? Sie wären auf der richtigen Spur, wenn Sie auf etwa eine halbe Milliarde tippen würden. Ausgehend von öffentlich zugänglichen Daten über Datenschutzverletzungen wurden allein im letzten Jahr etwa 480.014.323 Datensätze gestohlen, aber die Zahl ist wahrscheinlich noch viel höher. In jedem Fall ist dies eine ernüchternde Statistik für den Durchschnittsbürger und eine sehr besorgniserregende für jeden Sicherheitsexperten in Unternehmen.

Wir sind an einem Punkt angelangt, an dem die meisten Menschen in den Industriestaaten wahrscheinlich schon einmal erlebt haben, dass zumindest einige ihrer persönlichen Daten durch einen erfolgreichen Cyberangriff in die Hände von Kriminellen gefallen sind. Daher ist es nur natürlich, dass die Regierungen der Welt nach Lösungen suchen, um diesen störenden Strom von Online-Kriminalität einzudämmen. Die jüngste Maßnahme stammt von der Biden-Regierung in Form der Nationalen Cybersicherheitsstrategie, die ich mit großem Interesse verfolge. Diese Strategie enthält Richtlinien zu einem meiner Lieblingsthemen dieser Tage: die Rechenschaftspflicht im Bereich der Sicherheit.

Die Strategie, die nach einer bahnbrechenden Präsentation der CISA-Direktorin für Cybersicherheit und Infrastruktursicherheit, Jen Easterly, veröffentlicht wurde, hat verständlicherweise einige Spaltungen in der Sicherheitsgemeinschaft verursacht. Ich glaube jedoch, dass sie die beste Chance darstellt, die wir haben, um die Softwarestandards auf breiter Front anzuheben und endlich eine neue Ära sicherheitskompetenter Entwickler einzuläuten.

Die Anbieter hätten schon immer für unsichere Software zur Verantwortung gezogen werden müssen.

Seit Jahrzehnten ist es so, dass die Verantwortlichkeit für die Softwaresicherheit eine heiße Kartoffel ist, mit der kein Team jonglieren möchte. Führungskräfte und Teams neigen dazu, sich vehement darüber zu streiten, wer letztendlich für die Softwaresicherheit verantwortlich ist. Ein Bericht von Venafi zeigt, dass 97 % der leitenden IT-Führungskräfte der Meinung sind, dass die Softwareerstellungsprozesse nicht sicher genug sind. 61 % der Führungskräfte sind der Meinung, dass die IT-Sicherheitsteams die Verantwortung für die Softwaresicherheit übernehmen sollten, während 31 % der Meinung sind, dass das Entwicklungsteam die Verantwortung dafür tragen sollte. Und das ist nur ein Teil der Gleichung: Das Problem der Open-Source- und kommerziellen Komponenten von Drittanbietern in Software-Builds stellt eine ständige Erweiterung der Angriffsfläche dar. Selbst zwischen den AppSec- und Sicherheitsteams gibt es selten einen eindeutigen "Eigentümer", obwohl kontinuierliche Wachsamkeit bei der Aktualisierung, Überwachung und Prüfung erforderlich ist.

Dieselbe Umfrage ergab auch, dass - trotz interner Konflikte darüber, wer für die Sicherheit und Integrität von Software verantwortlich sein sollte - 94 % der Führungskräfte der Meinung sind, dass es Strafen für Softwareanbieter geben sollte, die ihre Build-Pipelines nicht vor Bedrohungsakteuren schützen und Kunden und Endbenutzer einem Risiko aussetzen. 

Mit der jüngsten strafrechtlichen Verfolgung des CISO von Uber im Zusammenhang mit dem Missmanagement eines verheerenden Cyberangriffs im Jahr 2016 sowie mit regulatorischen Initiativen wie der GDPR wird der Einsatz für Anbieter, die mit dem Feuer spielen und die Sicherheit vernachlässigen, langsam erhöht. Doch das reicht einfach nicht aus. Wir verlieren den Kampf gegen Cyberkriminelle, und auch wenn es schwer zu schlucken ist, so sind es doch die laxen Praktiken von Softwareanbietern, die ihnen grenzenlose Möglichkeiten bieten, zu gedeihen. 

Die Nationale Cybersicherheitsstrategie versucht, einen Schlussstrich zu ziehen und dem Kreislauf der Schuldzuweisungen ein Ende zu setzen, indem die volle Haftung für unsichere Software dem Anbieter zugewiesen wird.

Werfen wir einen Blick darauf:

Strategisches Ziel 3.3 - Verlagerung der Haftung für unsichere Softwareprodukte und -dienste:

"Zu viele Anbieter "ignorieren bewährte Verfahren für die sichere Entwicklung, liefern Produkte mit unsicheren Standardkonfigurationen oder bekannten Schwachstellen aus und integrieren Software von Drittanbietern ungeprüfter oder unbekannter Herkunft.

Wir müssen damit beginnen, die Haftung auf diejenigen Unternehmen zu verlagern, die keine angemessenen Vorkehrungen zur Sicherung ihrer Software treffen, und gleichzeitig anerkennen, dass selbst die fortschrittlichsten Software-Sicherheitsprogramme nicht alle Schwachstellen verhindern können."

Dies hat verständlicherweise einige Gemüter erregt. Aber wie bei anderen entscheidenden Momenten in der Entwicklung von Normen und Vorschriften in den meisten Branchen sind es mittelfristige Schmerzen, die ein besseres langfristiges Ergebnis gewährleisten. Als Softwareanbieter ist es nur logisch, dass wir in Sachen Sicherheit den Kopf hinhalten müssen. Es ist unsere Build-Pipeline, unsere Prozesse und unsere Qualitätskontrolle, und wenn wir einen Fehler machen, sind wir dafür verantwortlich, ihn zu beheben.

Außerdem sollten wir danach streben, Software von höchstmöglicher Qualität zu erstellen, und sichere Programmierung muss Teil der Messgrößen sein, die ein erfolgreiches Ergebnis definieren. In einer Welt, die sich auf Geschwindigkeit um jeden Preis konzentriert, ist dies eine große Aufgabe, aber es liegt an den Sicherheitsverantwortlichen, die unsere Zukunft leiten, sicherzustellen, dass alle am Softwareentwicklungsprozess Beteiligten angemessen geschult sind, um die besten Sicherheitsverfahren im Kontext ihrer Rolle zu vermitteln, insbesondere die Entwickler. 

Es fehlt uns noch immer eine Orientierung für langfristige Best Practices.

Das strategische Ziel 3.3 bezieht sich auf das etablierte NIST Secure Software Development Framework als Grundlage für seine allgemeinen Best Practices, und diese sind umfassende, allumfassende Richtlinien. Es wird zwar darauf hingewiesen, dass "sichergestellt werden muss, dass die Mitarbeiter, Prozesse und Technologien des Unternehmens auf die Durchführung einer sicheren Softwareentwicklung auf Unternehmensebene vorbereitet sind", aber es werden keine besonderen Vorschriften zu den Faktoren gemacht, die beispielsweise ein Manager für Sicherheitsbewusstsein bei der Auswahl von Befähigungslösungen beachten sollte.

Damit der Ansatz wirklich transformativ ist, sollten Entwickler als integraler Bestandteil des Sicherheitsprogramms betrachtet werden und jede Gelegenheit erhalten, ihre Fähigkeiten zu verbessern und die Verantwortung für die Erkennung und Beseitigung von Schwachstellen zu teilen. Sie können dies nicht auf eine Art und Weise erreichen, die ohne hyperrelevante, kontextbezogene Lernprogramme und Tools messbar ist, und auch nicht, wenn dies als jährliche Compliance-Übung statt als kontinuierlicher Weg zur Entwicklung von Fähigkeiten betrachtet wird. 

Entwickler sind ein wichtiger Teil des Puzzles, wenn es darum geht, das Sicherheitsrätsel zu knacken, und ein Team von sicherheitskompetenten Entwicklern ist in den meisten Unternehmen die fehlende Zutat. Sie ermöglichen eine schnelle Sicherheit, aber nur, wenn Zeit und Ressourcen aufgewendet werden, um diese im Team freizusetzen. Bis dahin werden alle allgemeinen Best-Practice-Richtlinien der Welt nichts bewirken können.

Der lange Weg ins Nirwana der Software-Sicherheit.

Die Biden-Administration hat 3 Milliarden Dollar für das CISA-Programm bereitgestellt, um eine schnelle Resilienz kritischer Infrastrukturen zu erreichen. Auch wenn die Finanzierung und Unterstützung durch die höchsten Regierungsebenen von entscheidender Bedeutung sind, haben wir nur dann eine Chance, die Bedrohungsakteure in die Schranken zu weisen, wenn wir einen globalen Vorstoß unternehmen, um die Sicherheitskultur neu zu gestalten.

Es liegt noch ein langer Weg vor uns, aber er beginnt damit, dass jeder Softwarehersteller den ersten mutigen Schritt in Richtung Sicherheitsverantwortung auf Unternehmensebene macht.