Der anhaltende Kampf um Sicherheit durch Design

Wenn es um Sicherheitsprobleme bei neuen, komplexen Produkten geht, ist die Reaktion der Gesellschaft in der Regel konsequent: Erstens, dem Benutzer die Schuld geben. Erst später sollten Sie den Hersteller für inhärente Konstruktionsfehler seiner Produkte zur Verantwortung ziehen. Wir haben das bei Autos und dann bei Computern gesehen. Doch so wie sich das Auto verändert hat, verändern sich auch die Einstellungen in der IT-Branche.

Die ersten Autos wurden Ende der 1890er Jahre in den USA verkauft. Danach kamen eine Reihe staatlicher Sicherheitsgesetze. Connecticut führte 1901 das erste Tempolimit ein. Dann kamen die ersten Ampeln. New York verabschiedete 1910 das erste Gesetz gegen Trunkenheit am Steuer. Irgendwann (aber langsam) begannen die Bundesstaaten, Fahrer zu lizenzieren und sie gelegentlich sogar zu testen.

Bestrafen Sie den Benutzer, verschonen Sie den Verkäufer

Diese Maßnahmen zur Steuerung des Fahrerverhaltens waren alle wichtig, aber zunächst einmal machte niemand die Automobilhersteller dafür verantwortlich, Sicherheit in ihre Produkte zu integrieren. Erst 1965, als Ralph Nader sein Fachbuch über Fahrzeugsicherheit „Unsafe at Any Speed“ veröffentlichte, begannen Verbraucher darüber nachzudenken, sicherere Autos zu fordern. Ein Jahr später verabschiedete der Kongress den National Traffic and Motor Vehicle Safety Act, der das Verkehrsministerium gründete und schließlich Autoverkäufer dazu zwang, Sicherheitsgurte in Fahrzeugen anzubringen.

Der Kongress verabschiedete dieses Sicherheitsgurtgesetz 60 Jahre, nachdem das erste Ford Model T vom Band lief. Es ist daher vielleicht nicht überraschend, dass es 42 Jahre nach der Markteinführung des PCs durch IBM solche gibt fast keine Gesetze Anbieter von Technologieprodukten müssen gleichermaßen für die Sicherheit ihrer Produkte verantwortlich gemacht werden.

Die einzigen wirklichen Gesetze, die heute die Computersicherheit regeln, dienen der Überwachung der Benutzer. Der Computer Fraud and Abuse Act (CFAA), der das Eindringen in die Cybersicherheit stoppen soll, wurde vor fast 40 Jahren verabschiedet und seitdem nicht wesentlich aktualisiert. Der Digital Millennium Copyright Act (DMCA) konzentriert sich darauf, Menschen daran zu hindern, digitale Urheberrechtskontrollen zu umgehen.

Aufwachen mit Sicherheit durch Design

Jetzt gibt es besondere Anstrengungen, um Hersteller dazu zu bringen, das Richtige zu tun und Sicherheit bereits in der Designphase in ihre Produkte zu integrieren, anstatt sie als nachträgliches Add-on auf den Markt zu bringen. Im April 2023 veröffentlichte die Cybersecurity and Infrastructure Security Agency (CISA) ihre Leitlinien zum sicheren Produktdesign: Das Gleichgewicht des Cybersicherheitsrisikos verschieben: Prinzipien und Ansätze für Security-by-Design und -Default.

„Security by Design“ integriert die Sicherheit bereits in der Entwurfsphase und ist nicht als nachträglicher Einfall oder nachträglich auf den Markt gebrachtes Add-on zu sehen. Die standardmäßige Sicherheit stellt sicher, dass die Sicherheit aktiviert ist, um Benutzer sofort und ohne zusätzliche Kosten zu schützen.

Die Grundsätze der gemeinsamen Beratung beinhalten einige offensichtliche Selbstverständlichkeiten. So wird beispielsweise davor gewarnt, dass die Last der Sicherheit nicht allein beim Kunden liegen sollte. Softwareanbieter sollten „die Verantwortung für die Sicherheitsergebnisse des Kaufs ihrer Kunden übernehmen.“ Dies war auch ein strategisches Ziel im März 2023 des Weißen Hauses Nationale Cybersicherheitsstrategie.

Ein weiterer Grund ist „radikale Transparenz“, bei der Softwareanbieter stolz darauf sein sollten, sichere Produkte zu entwickeln und zu demonstrieren, wie sie dies tun.

All dies basiert auf dem dritten Prinzip: dem Aufbau einer Führungsstruktur, die diese Ziele unterstützt. Führungskräfte müssen bereit sein, Kundenfeedback zur Produktsicherheit einzuholen und dann interne Ressourcen für die Lösung dieser Probleme einzusetzen. Diese Organisationsstruktur könnte bedeuten, dass eine bestimmte Person für die Softwaresicherheit zuständig ist, heißt es in dem Dokument weiter.

Das Problem der Lieferantenhaftung

„Security by Design“ klingt nach einem einfachen Vorschlag, doch die Befürworter stehen vor mehreren großen Herausforderungen, von denen viele finanzieller Natur sind.

Erstens stellt die Übernahme der Verantwortung für die Softwaresicherheit ein erhebliches Risiko für Softwareanbieter dar, deren Kunden täglich große Verluste aufgrund von Fehlern in ihrer Software riskieren. Nur in sehr extremen Fällen leiden diese Anbieter finanziell. Zum Beispiel die Versicherer von SolarWinds bezahlt 26 Millionen US-Dollar an Kunden in einem Vergleich, nachdem im Jahr 18,000 rund 2020 Unternehmen von der kompromittierten Software betroffen waren.

Für jeden Technologieanbieter, der bestrebt ist, seine Produkte von Grund auf zu sichern, wird es viele geben, die dies nicht tun. Das Weiße Haus hat sich verpflichtet, mit dem Kongress zusammenzuarbeiten, um Gesetze zu entwickeln, die die Haftung der Anbieter für die Sicherheit von Technologieprodukten festlegen. Da wir jedoch in ein Wahljahr gehen und der Kongress sich kaum auf genug einigen kann, um die Regierung am Laufen zu halten, scheinen die Chancen dafür gering zu sein.

Vorerst liegt es wohl an den Kunden, die Hersteller zum Umdenken zu bewegen. CISA empfiehlt Unternehmen, mit ihrem Kaufverhalten ein Zeichen zu setzen und die Bemühungen ihrer Lieferanten um Produktsicherheit von Grund auf zu bewerten. Das Weiße Haus leistet hierbei Unterstützung. Im Juli kündigte es das US Trust Mark an, ein Cybersicherheitsbewertungssystem, das Verbrauchern bei der Beurteilung vernetzter Geräte helfen soll.

Es gibt noch weitere Herausforderungen bei der Lieferantenhaftung. Während einige Fehltritte bei der Sicherheit möglicherweise auf die Schuld des Anbieters zurückzuführen sind, gibt es viele, bei denen der Anbieter dem Kunden die Schuld für den Missbrauch oder die Fehlkonfiguration der Software geben könnte.

Ein Hilfsmittel zur Verhinderung eines solchen Kundenmissbrauchs ist das Software-Autorisierungsprofil. Diese integrierte Sicherheitstaktik, die von CISA in seinen Leitlinien hervorgehoben wird, empfiehlt, wie Benutzer bestimmter Typen die Software verwenden sollten, einschließlich der Beschreibung der Zugriffsrechte für diese unterschiedlichen Rollen. Dadurch wird verhindert, dass der Poststellenleiter auf die gleichen Funktionen im Warenwirtschaftssystem zugreifen kann wie beispielsweise der Vertriebsleiter. Erfahrene Softwareanbieter können Benutzer warnen, wenn sie versuchen, vom Profil abzuweichen.

Kosten und Komplexität

Eingebettete Sicherheit ist komplex und teuer. In der gemeinsamen Empfehlung heißt es: „Die Secure-by-Design-Entwicklung erfordert die Investition erheblicher Ressourcen seitens der Softwarehersteller auf jeder Ebene des Produktdesign- und Entwicklungsprozesses, die später nicht ‚angepasst‘ werden kann.“

Dies ist besonders problematisch, wenn es um veraltete Software- und Hardwareprodukte geht. Viele Softwareanbieter arbeiten mit monolithischem, über Jahre entwickeltem Legacy-Code, der spröde und schwer zu aktualisieren ist. Dies ist schwieriger zu aktualisieren als modulare Software mit vielen unabhängigen und lose gekoppelten Komponenten.

Unternehmen können diese technischen Schulden schrittweise über mehrere Produktiterationen hinweg abbezahlen, es sind jedoch erhebliche Ressourcen erforderlich, um die Software wieder in ihre Grundfesten zu zerlegen und die Sicherheit von Grund auf neu zu strukturieren.

Sicheres Design: Eine undankbare Aufgabe

Das bringt uns zum nächsten Problem: Sichtbarkeit bzw. deren Fehlen.

Erstellen Sie eine glänzende, gut sichtbare neue Funktion wie generative KI, und Sie werden Kunden dazu verleiten, entweder die nächste Version Ihres Produkts zu kaufen oder ihr Abonnement beizubehalten. Umgekehrt anpassen Code unter der Haube, um die Sicherheit zu erhöhen und gut organisiert ist lobenswert, aber undankbar; Für viele Kunden ist es kein großes Verkaufsargument. Eine Website mit der Aufschrift „Jetzt von innen nach außen sicher“ wird wahrscheinlich zu der Antwort führen: „Was meinst du damit, dass es von Anfang an nicht so sicher war?“

Sicherheit war schon immer ein bisschen wie eine Sach- oder Lebensversicherung: Man muss sie abschließen, aber sie ist schwer zu verkaufen. Wenn Sie Ihre eigenen, nicht sicherheitsrelevanten Produkte sicherer machen, generieren Sie keine direkten Einnahmen. Allerdings ist der Verkauf von After-Market-Sicherheitsprodukten wie Anti-Malware-Software und Firewalls lukrativ.

Taktiken für Sicherheit durch Design

Trotz alledem sollten uns die Herausforderungen nicht davon abhalten, Security by Design anzustreben. Unternehmen können einige Taktiken anwenden, die dazu beitragen, die Softwaresicherheit von Anfang an zu fördern. Eine davon, die in den CISA-Leitlinien hervorgehoben wird, ist die Verwendung speichersicherer Sprachen.

Einige traditionelle Low-Level-Programmiersprachen, insbesondere C und C++, ermöglichen es Programmierern, Speicherbereiche zu manipulieren, die sie nicht sollten. Sie können Speicher lesen, der möglicherweise vertrauliche Informationen oder unangemessenen Code enthält. Sie können auch die Ausführung anderer Programme ändern oder sie in einen verwirrten Zustand versetzen, wodurch sie anfällig für Angriffe werden.

Betriebssystemhersteller haben Speicherschutzmaßnahmen eingeführt, aber CISA sagt, dass diese allein nicht ausreichen. Stattdessen empfiehlt es die Verwendung von Programmiersprachen mit integrierten Speicherschutzmaßnahmen wie C#, Go oder Rust.

Die Bewältigung dieses Problems von Anfang an könnte zu erheblichen Sicherheitsverbesserungen führen. Im Jahr 2019 haben Microsoft-Ingenieure sagte dass etwa sieben von zehn aller Schwachstellen in Microsoft-Produkten auf Probleme mit der Speichersicherheit zurückzuführen sind.

Wer ist führend im Bereich Security by Design?

Mehrere Regierungs- und Industriegruppen verfügen bereits über sichere Designprinzipien und Frameworks, die sich auf verschiedene Ebenen des Technologie-Stacks konzentrieren. Auf der Softwareseite sind dies u.a NISTs Secure Software Development Framework und eine branchenweite Initiative für sichere Softwareentwicklung namens SafeCode. Es gibt auch einige Bemühungen, die Sicherheit in bestimmte Bereiche zu integrieren, beispielsweise in das Design von Webanwendungen Die sicheren Designprinzipien von OWASP.

Auf der Hardwareseite arbeiten Unternehmen seit Jahren an TPM-Systemen (Trusted Platform Module) zusammen, die Geheimnisse physisch in manipulationssicherem Silizium auf der Hauptplatine speichern. Derzeit können Sie Windows 11 nicht ohne ein TPM der Version 2.0 installieren.

Ein Wettlauf nach unten (des Stapels)

Das Beharren von Microsoft auf TPM-Hardware ist ein Beispiel dafür, wie einige Anbieter ihr Bestes tun, um Security by Design anzugehen, indem sie miteinander zusammenarbeiten, um Sicherheitsketten zu schaffen, die im Silizium beginnen und sich bis in das Betriebssystem erstrecken.

Ein Beispiel ist Secure Boot, eine Sicherheitsfunktion, die vom Hersteller genehmigte Codes speichert, die die Legitimität verschiedener Komponenten im System, wie der Firmware und des Betriebssystems, beweisen. Dies basiert auf einem TPM zusammen mit Unified Extensible Firmware Interface (UEFI), der modernen Version der Computer-Firmware – dem Ding, das den Rest des Computers beim Einschalten ausführt und bootet.

Durch die Überprüfung und den Schutz von Code auf niedrigeren Systemebenen wollen die Betriebssystemanbieter und Originalgerätehersteller die vollständige Kontrolle über alles gewährleisten, was auf diesem Code basiert. Allerdings unterliegen diese Schutzmaßnahmen, wie alles andere auch, eigenen Sicherheitslücken. Im Fall von Secure Boot ermöglichte ein Schwachstellencode namens Baton Drop Angreifern die Einführung eines UEFI-Rootkits namens BlackLotus, das diese Schutzmaßnahmen umging und es Angreifern ermöglichte, das System für seine Angreifer zu besitzen.

Angriffe wie diese bedeuten nicht, dass wir keine Security by Design and Default anstreben sollten. Wenn man von Anfang an mehr Sicherheit in das System bringt, bewegt sich das zugunsten der Verteidiger und erschwert Angriffe. Doch Angriffe wie BlackLotus zeigen, dass selbst in der Designphase auferlegte Sicherheitsmaßnahmen umgangen werden können. Die Antwort besteht darin, mehrere Schutzebenen und -facetten in Systeme zu integrieren, die Angriffsfläche zu minimieren und den Angreifern mehrere Hürden zu überwinden.

Regulierungen

Regierungen nehmen das Thema „Security by Design“ ernst und haben bereits mehrere gesetzgeberische Maßnahmen ergriffen oder sind in Planung. In den USA haben Kalifornien und Oregon IoT-Sicherheitsgesetze erlassen. Diese erfordern, dass einzelne angeschlossene Geräte entweder über eindeutige vorprogrammierte Passwörter verfügen oder Benutzer dazu zwingen, ein neues Authentifizierungsmittel zu generieren, bevor sie zum ersten Mal auf das Gerät zugreifen können.

Im Vereinigten Königreich wird der Product Security and Telecommunications Act grundlegende Sicherheitsanforderungen für vernetzte Produkte vorschreiben. Dazu gehören eindeutige Passwörter, Informationen zum Melden von Sicherheitsproblemen mit einem Produkt und der Mindestsupportzeitraum für Sicherheitsupdates.

Dies ist ein Anfang, aber es werden noch einige Möglichkeiten zur Durchsetzung robuster Sicherheit durch Design bei wichtigen Produkten verpasst. Beispielsweise sind Desktop- und Laptop-Computer sowie Tablets vom britischen Recht ausgenommen, ebenso wie medizinische Geräte, intelligente Messgeräte und Smartphones. Zumindest Ihre angeschlossenen Wasserkocher und Web-Überwachungskameras sind abgedeckt.

Das Problem bei solchen Gesetzen besteht darin, das Gleichgewicht zwischen Wirksamkeit und Komplexität zu finden. Gesetze, die die Anwendung von Sicherheitsprinzipien bis ins kleinste Detail steuern, sind schwer zu überwachen und zu aktualisieren. Dennoch ist die Beantragung und Dokumentation eines Sicherer Lebenszyklus der Softwareentwicklung würde helfen, viele Produkte zu sichern.

Die EU hofft auch, das eingebaute Sicherheitsproblem auf Blockebene angehen zu können. Im September 2022 veröffentlichte es einen Gesetzesentwurf, der weitaus strenger als das britische Recht ist und die Cybersicherheitsregeln verschärfen würde, um eine bessere Produktsicherheit durchzusetzen. Das Cyber-Resilience-Gesetz würde Hersteller dazu zwingen, die Sicherheit von Produkten über den gesamten Produktlebenszyklus hinweg zu verbessern.

Aus der Geschichte lernen

Der Security-by-Design-Ansatz der PC-Industrie entspricht derzeit dem der Automobilindustrie Mitte der sechziger Jahre. Cybersicherheit ist zu einem weit verbreiteten öffentlichen Anliegen geworden, und einige Organisationen haben auf freiwilliger Basis Ansätze für integrierte Sicherheit untersucht, um sich von anderen abzuheben und ihre Benutzer zu schützen.

Nun drängen die Regierungen das Problem schrittweise mit Gesetzen auf. Der Weg dorthin ist noch lang, auch weil die Komplexität der IT-Lösungen und der sie unterstützenden digitalen Lieferketten um eine Größenordnung größer ist als die des Automobilsektors vor der Digitalisierung.

Einige Dinge bleiben gleich, insbesondere mangelndes Bewusstsein oder Ambivalenz der Verbraucher. Als die USA die Einführung von Sicherheitsgurten in Autos vorschrieben, war deren Verwendung freiwillig. Als fast zwei Jahrzehnte später die ersten Bundesstaaten die Verwendung von Sicherheitsgurten vorschrieben, benutzte weniger als jeder fünfte Mensch sie. Es liegt an Regierungen und Anbietern, eine bessere Sicherheit in Technologieprodukten durchzusetzen und sicherzustellen, dass diese standardmäßig für Benutzer aktiviert sind.