Auf einer Werft entscheidet sich das Schicksal eines Schiffes lange, bevor es Wasser sieht.

Nicht im Sturm. Nicht beim ersten Leck. Sondern am Zeichentisch, in der Frage, wie der Rumpf in einzelne wasserdichte Abteilungen unterteilt wird. Reißt später unterwegs ein Loch in die Außenhaut, dann läuft nur eine Kammer voll, nicht das ganze Schiff. Diese Aufteilung ist keine Reparatur und kein Zubehör. Sie ist in den Kiel gebaut, von der ersten Linie an.

Versuchen Sie einmal, einem fertig beladenen Schiff auf hoher See noch ein paar Schotten einzuschweißen. Es geht nicht. Genau darum geht es bei Security by Design.

Security by Design baut Schutzmechanismen von Beginn an in digitale Systeme ein, statt sie später nur aufzukleben.

Eingebaut, nicht aufgeklebt

Die Idee ist im Kern unspektakulär und trotzdem erstaunlich oft missachtet. Sicherheit gehört an den Anfang. In den Bauplan. In die erste Entscheidung, nicht in die letzte.

Über Jahrzehnte funktionierte die Softwarewelt umgekehrt. Erst wurde gebaut, schnell, mit Blick auf Funktionen und Markteinführung. Dann, wenn die Lücken auffielen, kamen die Pflaster: ein Patch hier, eine Firewall dort, ein Sicherheitsprodukt obendrauf. Die Last, ein unsicheres Produkt sicher zu machen, lag am Ende beim Kunden.

Security by Design dreht diese Reihenfolge um. Sicherheit wird zur Grundanforderung, gleichberechtigt neben Tempo und Funktion, und sie begleitet das Produkt über seinen gesamten Lebenszyklus. Die amerikanische Cyber-Sicherheitsbehörde CISA hat dafür gemeinsam mit Partnerbehörden aus Deutschland, Großbritannien, Kanada, Australien, den Niederlanden und Neuseeland einen vielbeachteten Leitfaden veröffentlicht. Ihr Satz dazu bleibt hängen: Die Welt braucht sicherere Produkte, nicht mehr Sicherheitsprodukte.

Der Unterschied klingt klein. Er ist es nicht. Ein Schott im Rumpf schützt anders als ein Eimer, den man dem Passagier in die Hand drückt, wenn das Wasser schon steigt.

Sicher ab Werft

Zu Security by Design gehört ein Zwilling: Secure by Default.

Ein Schiff verlässt die Werft seetüchtig. Niemand erwartet vom Passagier, dass er seine eigenen Rettungsboote mitbringt oder die Schotten selbst nachrüstet. Die Sicherheit ist da, von Anfang an, ohne Aufpreis, ohne Bastelei.

Übertragen heißt das: Ein Produkt sollte im Auslieferungszustand sicher sein, nicht erst, nachdem ein Fachmann tagelang an den Einstellungen gedreht hat. Die wichtigsten Schutzmechanismen sind voreingestellt, nicht versteckt in einem Menü, das niemand findet. Die CISA bringt es mit einem schönen Bild auf den Punkt: Sicherheit gehört zum Produkt wie der Sicherheitsgurt zum Auto. Niemand verkauft Ihnen den Gurt als teures Extra. Er ist einfach drin.

Das verschiebt die Verantwortung. Weg vom Kunden, der kein Sicherheitsexperte sein will und es auch nicht sein sollte. Hin zum Hersteller, der sein Handwerk versteht. Wer ein Schiff baut, schuldet seinen Passagieren ein Schiff, das schwimmt. Nicht eine Anleitung, wie man es selbst abdichtet.

Wie teuer das Gegenteil wird, hat das Netz längst erlebt. 2016 kaperte ein Schadprogramm namens Mirai Hunderttausende vernetzter Geräte, Kameras, Router, Videorekorder, und schloss sie zu einem gewaltigen Angriffsnetz zusammen, das ganze Teile des Internets lahmlegte. Der Trick war beschämend simpel. Die Geräte kamen mit ab Werk eingestellten Standardpasswörtern, die niemand geändert hatte und die in keiner Liste fehlten. Eine einzige sichere Voreinstellung hätte einem ganzen Heer von Angreifern die Tür vor der Nase zugeschlagen. Das ist Secure by Default in einem Satz: Die sichere Einstellung darf nicht die versteckte Ausnahme sein. Sie muss der Normalzustand sein.

Drei Haltungen, die den Unterschied machen

Hinter dem Begriff stehen ein paar Grundhaltungen, und keine davon ist technisch. Sie sind kulturell.

Die erste: Verantwortung übernehmen. Eine gute Werft schiebt die Schuld für ein undichtes Schiff nicht auf das Meer. Sie steht für das gerade, was sie gebaut hat. In der Softwarewelt heißt das, die Sicherheit der Kunden als eigene Aufgabe zu begreifen, nicht als deren Privatproblem.

Die zweite: Ehrlichkeit, auch wenn sie wehtut. Wer einen Konstruktionsfehler findet, redet nicht darum herum, sondern legt ihn offen, sauber dokumentiert, damit andere daraus lernen. Der naheliegende Einwand lautet: Liefert man Angreifern damit nicht eine Landkarte? Die Erfahrung sagt nein. Wovon ein offen dokumentierter Fehler die Vielen schützt, wiegt schwerer als der Vorteil, den er den Wenigen verschafft. Vertuschen mag kurzfristig hübscher aussehen. Es kostet langfristig das Vertrauen, auf dem alles ruht.

Die dritte: von oben getragen. Sicherheit, die nur ein einzelner Ingenieur im Maschinenraum für wichtig hält, verpufft. Sie muss von der Führung gewollt sein, mit demselben Gewicht wie Umsatz und Termine. Sonst bleibt sie ein gut gemeinter Wandspruch.

Wann haben Sie in Ihrem letzten Projekt über Sicherheit gesprochen, bevor die erste Zeile geschrieben war?

Warum sich das rechnet

Es gibt einen handfesten Grund, warum kluge Werften so denken, und er hat nichts mit Idealismus zu tun.

Eine Linie auf dem Bauplan zu ändern kostet einen Bleistift und eine ruhige Stunde. Dieselbe Änderung am fertigen Rumpf kostet ein Vermögen, und am Schiff auf hoher See kostet sie womöglich alles. Je später ein Fehler entdeckt wird, desto teurer wird seine Behebung. Diese Kurve ist in der Softwareentwicklung gut belegt. Was im Entwurf ein Federstrich gewesen wäre, wird nach der Auslieferung zur Notoperation unter Zeitdruck.

Deshalb verlegen sorgfältige Teams das Nachdenken über Angriffe nach vorn. Sie spielen schon am Zeichentisch durch, wo ein Angreifer ansetzen könnte: Welche Daten sind wertvoll? Wo verlaufen die Grenzen zwischen vertrauenswürdig und fremd? Was könnte jemand missbrauchen, der es darauf anlegt? Diese frühe Bedrohungsanalyse ist kein Misstrauen gegen die Welt. Sie ist dieselbe Umsicht, mit der ein Schiffbauer fragt, welche See sein Schiff einmal aushalten muss.

Fachleute haben dafür erprobte Baupläne geschaffen, vom Secure Software Development Framework des Normungsinstituts NIST bis zu den Prüfkatalogen der OWASP. Sie ersetzen nicht das Denken. Aber sie sorgen dafür, dass niemand bei null anfangen muss. Und sie haben einen unterschätzten Nebeneffekt: Wer am Entwurf ansetzt, behebt nicht einen einzelnen Fehler, sondern schließt oft eine ganze Klasse von Schwächen auf einmal. Ein gut gesetztes Schott schützt nicht vor einem Leck, sondern vor allen Lecks in dieser Kammer.

„Aber das bremst uns doch aus“

Der häufigste Einwand gegen all das lautet: Sicherheit kostet Tempo, und Tempo entscheidet über den Markt. Der Einwand ist nicht falsch. Er ist nur kurzsichtig.

Wer am Anfang ein paar Stunden in den Bauplan steckt, spart sich später Wochen an Notreparaturen, Rückrufen und ramponiertem Ruf. Und so viel Zeit ist es selten: Eine durchdachte Bedrohungsanalyse für einen einzelnen Baustein ist oft in einer knappen Stunde erledigt. Schnelligkeit, die auf einem brüchigen Rumpf beruht, ist keine Schnelligkeit. Sie ist aufgeschobener Schiffbruch.

Kein neuer Gedanke, aber neuerdings Pflicht

Wer glaubt, hier werde gerade etwas Brandneues erfunden, irrt. Der Gedanke ist alt. Schon in den frühen Tagen der Computersicherheit forderten Fachleute, Schutz von Beginn an einzuplanen statt im Nachhinein aufzusatteln. Verwandt ist die Idee des Privacy by Design, die Datenschutz schon in die Konstruktion eines Systems einbaut. Die kanadische Datenschützerin Ann Cavoukian prägte sie bereits in den 1990er-Jahren, lange bevor sie europäisches Recht wurde. Sie hat es bis dorthin geschafft: Die Datenschutz-Grundverordnung verlangt in Artikel 25 ausdrücklich Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen.

Was lange eine Empfehlung war, wird zunehmend zur Vorschrift. Der europäische Cyber Resilience Act, das erste EU-Gesetz mit verbindlichen Cybersicherheitsanforderungen für Produkte mit digitalen Elementen, nimmt Hersteller in die Pflicht, Sicherheit über den gesamten Lebenszyklus mitzudenken, von der Planung bis zum letzten Update. Die freundliche Bitte wird zur Erwartung mit Zähnen.

Warum gerade KI das Prinzip braucht

Hier schließt sich der Kreis.

Bei klassischer Software lässt sich ein Fehler oft noch nachträglich herausschneiden. Bei künstlicher Intelligenz wird das schwieriger. Manche Schwächen moderner KI-Systeme lassen sich gar nicht restlos beheben, sondern nur umbauen. Wer ein Sprachmodell mit Werkzeugen, Zugängen und Eigenständigkeit ausstattet, kann ihm nicht im Nachhinein das Urteilsvermögen einimpfen, das ihm fehlt. Er kann nur die Architektur drumherum so bauen, dass ein Fehltritt nicht das ganze Haus einreißt.

Das heißt: Berechtigungen knapp halten. Bei riskanten Schritten einen Menschen dazwischensetzen. Fremde Inhalte als das behandeln, was sie sind, nämlich Material und nicht Befehl. All das funktioniert nur, wenn es vom ersten Entwurf an mitgedacht wird, nicht als Pflaster auf ein fertiges System. Genau deshalb haben internationale Sicherheitsbehörden, das deutsche Bundesamt für Sicherheit in der Informationstechnik eingeschlossen, eigene Leitlinien für die sichere Entwicklung von KI-Systemen vorgelegt. Sie tragen denselben Grundgedanken in eine neue Technik: Sicherheit gehört in den Kiel, nicht an die Reling.

Der eigentliche Gedanke

Security by Design ist letztlich keine Technik, sondern eine Reihenfolge. Erst fragen, was schiefgehen kann. Dann bauen. Nicht umgekehrt.

Das Unbequeme daran: Diese Reihenfolge kostet zu Beginn Zeit, Disziplin und manchmal eine unbequeme Diskussion mit denen, die schnell liefern wollen. Sie zahlt sich erst später aus, leise, indem etwas nicht passiert. Ein Datenleck, das ausbleibt. Ein Vorfall, von dem niemand je erfährt, weil er nie geschah. Vorsorge hat schlechte Presse, weil ihr größter Erfolg unsichtbar ist.

Aber fragen Sie einen Schiffbauer, ob er die Schotten lieber am Zeichentisch plant oder im Sturm.

Bauen Sie Ihre Sicherheit in den Kiel? Oder kleben Sie sie an die Reling und hoffen, dass das Wetter hält?