Neue Forderungen der US CISA zu Security by Design [German Version]
Die Antworten sind nicht perfekt, aber die Fragen sind gut: Was müssen Nutzer über Security wissen? Und wer zahlt für Security by Design?
Zum Thema Security by Design gibt es mal wieder Neuigkeiten. Die US-amerikanische CISA (Cybersecurity & Infrastructure Security Agency) hat noch ein Papier dazu herausgebracht, und die halbe Welt macht mit: NSA, FBI und Security-Behörden aus 15 Ländern, inklusive dem deutschen BSI:
Es ist schon das zweite Dokument zu diesem Thema in diesem Jahr. Und auch dieses enthält wieder Secure by Design-Prinzipien und außerdem “Secure by default practices”, “Secure product development practices” und “Pro-security business practices” für jedes der drei Prinzipien. Alles ausschließlich für Software.
Dokumente mit “Secure by design”-Prinzipien gibt es mehr, als man zählen kann. Ein weiteres Dokument mit solchen Prinzipien wäre eher eine Randnotiz wert. Aber das CISA-Dokument enthält noch mehr, und das ist bemerkenswert. Es zeigt nämlich, dass es nicht nur etwas mit Technologie zu tun hat, dass Security by Design noch zu wenig gelebt wird, sondern wichtige Hebel (auch) woanders liegen: Bei der Kommunikation und — wie könnte es anders sein — beim Geld.
Kommunikation: Was muss ein Nutzer über ein Produkt wissen, um die Security beurteilen zu können?
Normalerweise beschränken sich Veröffentlichungen zum Thema Security by Design auf technische Empfehlungen, wie interne Entwicklungsprozesse verbessert werden können.
Das CISA-Papier enthält aber auch konkrete Forderungen, was Hersteller öffentlich machen sollten. Bedrohungsmodelle (“high level threat models”), den Secure Software Development Lifecycle, dem sie sich verschreiben, eine Software Bill of Materials (SBOM), eine Policy zur Veröffentlichung von Schwachstellen, den Manager, der Security by Design verantwortet, eine Security by Design Roadmap, interne Erfolge und Stolpersteine beim Einführen des Secure Software Development Lifecycle….
Das sind hohe Erwartungen. Ich fürchte, solang wir weiter öffentlich auf allen Herstellern herumtrampeln, die Security-Probleme haben, werden sie einen Teufel tun und all das öffentlich machen — und ich kann sie verstehen.
Transparenz funktioniert nur, wenn die Öffentlichkeit realistische Erwartungen in Bezug auf die Security-Eigenschaften eines Produkts und die Security-by-Design-Prozesse eines Herstellers hat. Oder ist vielleicht der beste Weg zu realistischeren Erwartungen, wenn die Kommunikation über die Cybersicherheit eines Produkts normaler wird und somit eine breitere Palette an realistischen Informationen öffentlich ist?
Wie auch immer: Wir brauchen eine Diskussion darüber, was Hersteller veröffentlichen müssen, damit Nutzer die Security eines Produktes beurteilen können — aber auch darüber, wie Nutzer und die Öffentlichkeit mit diesen öffentlichen Informationen umgehen sollten. Security by Design ist eben auch ein Kommunikationsproblem.
Finanzierung: Wer muss für Security by Design bezahlen?
Normalerweise beschränken sich Security-by-Design-Veröffentlichungen auf ein technische Wunschliste. Böse Stimmen könnten behaupten: Eine Wunschliste für eine ideale Welt, in der die Budgets unendlich sind. Zumindest argumentieren Hersteller gern, für Security würden Kunden nicht zahlen.
Das CISA-Papier enthält nun sehr klare Vorstellungen, wer Security by Design bezahlen soll.
Kurz: Die Hersteller. Zitat: “Manufacturers of products that are “secure by default” do not charge extra for implementing added security configurations Instead, they
include them in the base product like seatbelts are included in all new cars. […] Security should not be a luxury option, but should be considered a right customers receive without negotiating or paying more.”
Puh. Das klingt gut, aber realitätsfern — zumindest, solang es ein Dokument ist, das Hersteller (Zitat) “drängt, die Prinzipien in diesem Dokument zu befolgen”, aber außer vielen prominenten Mitherausgebern keinerlei regulatorischen Wumms hat. Jason Weiss hat das in einem LinkedIn-Post schön zusammengefasst.
Nach den vielen Gesprächen mit Produktherstellern und Produktnutzern, die ich in den letzten Jahren über Security by Design geführt hat, befürchte ich:
Hersteller werden keine Funktionen integrieren, für die niemand zahlt. Sie werden sich von niemandem “gedrängt” fühlen, Funktionen einzubauen, außer von ihren Kunden (oder von verbindlichen Gesetzen). Und das ist auch verständlich (und, unpopular opinion, wohl auch gut so. Es gibt nichts Tödlicheres für ein Produkt, als Features, die Kunden nicht wollen).
Die Diskussion ist aber auch zu schwarz-weiß. Sie suggeriert, entweder sei Security “eingebaut” oder nicht. Ich kenne Unternehmen, die “sichere Versionen” und “normale” Versionen z. B. von Programmiergeräten haben. Der Unterschied? Das Preisschild. Die meisten Kunden entscheiden sich für die normale Version.
Dabei hat Security by Design — genauso wie jede funktionale Anforderung — jede Menge Verhandlungsspielraum (was gut ist). Genau wie nicht jeder einen Porsche kauft, weil er vielleicht nicht Hunderttausende für ein Auto ausgeben möchte, werden auch Nutzer von IT/OT-Systemen niemals bereit sein, für “alle Security-Funktionen” zu zahlen.
Sie zahlen für die Funktionen, die für sie wirklich wichtig sind. Dafür braucht es: Transparenz, womit sich der Kreis zum ersten Punkt schließt.
Transparenz ist aber keine Einbahnstraße. Die Anbieter müssen aufhören zu sagen: “Das zahlt doch sowieso keiner”, und sie müssen anfangen, die Optionen für Sicherheitsfunktionen und ihren Preis transparent darzustellen. Und die Kunden müssen aufhören, mit unrealistischen Sicherheitswünschen um sich zu werfen (“Gebt mir SL 4!”) und anfangen, transparent zu machen, welche Sicherheitsziele für sie wichtig sind.
Hersteller, Nutzer: Schreitet zum Äußersten und redet miteinander, statt euch Feature-listen an den Kopf zu knallen.
Zugegeben, es mangelt nicht nur an der Bereitschaft, transparent über Sicherheit zu sprechen, es gibt auch keine Best Practices für die Cybersecurity-Kommunikation. Es gibt Millionen von Listen mit “Security by Design” Prinzipien, aber keinen Leitfaden, wie man effektiv “Security by Design” zwischen Herstellern und Nutzern kommuniziert. Aber das ist eine andere Geschichte.
Keine perfekten Antworten, aber gute Fragen
Die CISA-Veröffentlichung hat auf beide Fragen, die nach der Kommunikation und die nach der Finanzierung, klare Antworten. Die Antworten überraschen nicht, denn es ist ja klare und explizit benannte Strategie der CISA, die Hersteller für Security mehr in die Pflicht zu nehmen. Schließlich lautet der Untertitel der Publikation nicht umsonst “shifting the balance of cybersecurity risk”, und damit ist die Verschiebung nach “links im Entwicklungsprozess”, also zum Hersteller, gemeint. Man muss mit den Antworten nicht übereinstimmen; man darf sich eine differenziertere Betrachtung wünschen.
Aber die darunterliegenden Fragen, die die Veröffentlichung aufwirft, müssen definitiv diskutiert werden, wenn wir beim Thema Security by Design vorankommen wollen.
Dieser Beitrag ist als Teil des monatlichen “Security-Briefings für Hard Hats” erschienen.
