Security by Design bedeutet, IT-Sicherheit über den gesamten Entwicklungszyklus als Kernanforderung zu behandeln und nicht erst am Projektende. Zu den wichtigsten Prinzipien gehören Defense in Depth (mehrere unabhängige Schutzschichten), etablierte Bibliotheken statt selbst gebauter Sicherheitstechnik, die Prüfung aller Daten an den Schnittstellen, sichere Voreinstellungen und ein sicherer Zustand, wenn Komponenten ausfallen.
Das Wichtigste in Kürze
- Wer IT-Sicherheit erst in den letzten zehn Prozent eines Projekts angeht, bekommt zehn Prozent Sicherheit. Nur die frühe Einbindung führt verlässlich zu einem sicheren System.
- Bedrohungsmodellierung ist keine Sache für Spezialisten: Jedes Team kann sich zusammensetzen, klären, was in seinem System wertvoll ist, und systematisch durchgehen, wer es haben will und wie er angreifen würde.
- Eigene Sicherheitsmechanismen, etwa für Verschlüsselung oder Authentifizierung, bringen Schwachstellen mit sich, die selbst professionelle Sicherheitstechnik regelmäßig hat und die die meisten Teams mangels Ressourcen nicht finden.
- Sicher scheitern ist Pflicht im Entwurf: Fällt eine Komponente wie ein Audit-Trail oder ein Authentifizierungsdienst aus, muss das System die Verarbeitung verweigern, statt in einen offenen Zustand zu fallen.
- Tester treiben das Sicherheitsbewusstsein ganz natürlich voran, weil die Frage “Was kann schiefgehen?” ihr Handwerk ist. Früh eingebunden, entdecken sie umgangene Sicherheitskontrollen, bevor diese in Produktion gehen.
Sicherheit durch Design: zuerst bauen, nicht zuletzt anschrauben
Wer erst in den letzten zehn Prozent eines Projekts an IT-Sicherheit denkt, bekommt zehn Prozent Sicherheit. Dieser Satz erklärt, warum so viele Systeme mit schwachem Schutz ausgeliefert werden: Die Arbeit wurde so lange verschoben, bis sich fast nichts mehr ändern ließ. Sicherheit durch Design, im Englischen Security by Design, dreht diese Reihenfolge um.
IT-Sicherheit teilt dieses Schicksal mit Performance, Resilienz und Verfügbarkeit. Alle sind sich einig, dass diese Qualitäten wichtig sind. Kaum jemand kümmert sich früh darum, weil der Plan lautet, das “irgendwann” zu erledigen. Irgendwann kommt selten in gutem Zustand an.
Wer IT-Sicherheit ernst nimmt, behandelt sie als Eingabe für den Entwurf und nicht als Abschlussaufgabe. Du entscheidest, wie sich ein System verteidigt, solange du es noch formst und Änderungen an der Struktur billig sind.
Warum Teams IT-Sicherheit immer noch hinten anstellen
Die meisten Softwareentwickler haben nur abstraktes Sicherheitswissen, und diese Lücke schiebt das Thema ans Ende. Die Begriffe kennen sie: Authentifizierung, Autorisierung, Auditing. Was sie damit in einem echten System konkret tun sollen, ist deutlich weniger klar.
Es gibt aber eine echte Veränderung. Vor zehn Jahren kamen zu einem Vortrag über IT-Sicherheit fünf Leute, und alle fünf arbeiteten schon in der Security. Heute ist der Raum voll mit Entwicklern, die etwas lernen wollen. Das Interesse ist da. Das praktische Know-how fehlt oft noch.
Das zweite Hindernis ist ein Kulturkonflikt. Wenn ein Team sich endlich an Sicherheitsspezialisten wendet, trifft es auf sehr kluge Leute, die nichts anderes machen als Security. Viele kommen aus der Infrastruktur und wissen wenig über Softwareentwicklung. Sie sprechen eine andere Sprache und begraben ein Team gern unter einer Liste von Pflicht-, Dringend- und Sonst-droht-die-Katastrophe-Forderungen.
Diese Haltung führt in die Irre, denn in der IT-Sicherheit ist nichts absolut. Alles ist eine Abwägung. Ein Team, das nur hört “Mach das alles sofort, sonst bist du gescheitert”, hat keine Chance, Aufwand und Risiko gegeneinander abzuwägen.
Designprinzipien als brauchbarer Einstieg
Prinzipien funktionieren, weil sie kurz genug sind, um sie sich zu merken, und breit genug, um echte Entscheidungen zu leiten. Eoin Woods hat eine Sammlung von zehn Prinzipien zusammengestellt, nachdem ihm aufgefallen war, dass die vorhandenen Sammlungen entweder zu dünn oder viel zu groß waren: von acht oder neun Einträgen bis zu mehreren hundert. Alle gültig, aber an den Extremen nicht zu gebrauchen.
Eine kompakte Sammlung soll dafür sorgen, dass Menschen früher über IT-Sicherheit nachdenken. Du musst keine Kryptografie beherrschen, um zu fragen, ob dein Entwurf einen Single Point of Failure hat. Du brauchst nur eine Handvoll Fragen, die in deinen Kopf passen, während du die Architektur skizzierst.
Hier die Prinzipien, die in der täglichen Entwurfsarbeit am meisten Gewicht haben.
Defense in Depth: nie auf einen einzigen Mechanismus verlassen
Geh davon aus, dass jeder einzelne Sicherheitsmechanismus überwunden werden kann. Versierte Angreifer knacken eine Verschlüsselung oder kommen an einem Authentifizierungssystem vorbei. Wenn das alles war, was du hattest, haben sie jetzt alles.
Fast jeder Mechanismus hat Schwächen oder wird fehlerhaft eingesetzt. Das Ziel ist deshalb ein mehrschichtiger, unabhängiger Schutz, also Verteidigung in der Tiefe. In Systemen, die Regierungen schützen, hat jede Ebene ihre eigenen Kontrollen, und die greifen ineinander. Wer eine Ebene knackt, steht vor demselben Problem gleich noch einmal.
Es geht darum, einen Einbruch teuer zu machen. Jede unabhängige Schicht treibt die Kosten hoch, und das ist oft die realistischste Verteidigung, die sich aufbauen lässt.
Bau keine eigene Sicherheitstechnik
Eigene Sicherheitstechnik zu entwickeln ist viel schwerer, als es aussieht, und in diese Falle tappen auch erfahrene Entwickler. Viele fähige Leute lesen ein Buch über Verschlüsselung und beschließen, ihren eigenen Passwort-Tresor zu bauen. Der ehrliche Rat: Lass es.
Dieselbe Vorsicht gilt für Authentifizierung und Autorisierung. Eine Anbindung an OAuth sieht einfach aus, trotzdem ist der richtige Schritt, eine Bibliothek zu suchen, die das schon kann.
Der Grund ist schlicht. Auch Sicherheitstechnik von Profis hat Schwachstellen. Sobald sie veröffentlicht ist, nehmen erfahrene Security-Tester sie auseinander, und sie finden jedes Mal Probleme. Wie wahrscheinlich ist es da, dass deine selbst gebaute Version keine hat? Gering.
“Das Erste, was sie tun, wenn sie so etwas produzieren: Sie lassen sofort all die erfahrenen Security-Tester darauf los, und die finden immer Probleme. Wie stehen die Chancen, dass du mit deiner Version keine Probleme hast? Ziemlich schlecht.”
(Eoin Woods)
Ob Open Source oder Closed Source, hängt vom Kontext ab. Keins von beiden hat ein Monopol auf gute Sicherheit. Open Source bringt Transparenz und viele unabhängige Forscher. In manchen Märkten ist ein Closed-Source-Produkt tatsächlich das stärkere Angebot. Stell dem Anbieter die richtigen Fragen und richte die Wahl danach aus, was du baust.
Vorsichtig vertrauen, besonders bei allem, was ins System kommt
Behandle jede Eingabe und jede Komponente als etwas, das du prüfst, nicht als etwas, das du einfach annimmst. Netzwerkverbindungen sollten ohne Autorisierung und Authentifizierung weder aufgebaut noch angenommen werden. Das ist die offensichtliche Hälfte des Prinzips.
Die weniger offensichtliche Hälfte betrifft das, was du ins System holst. Daten verdienen Misstrauen, denn viele Exploits funktionieren genau so: Sie schleusen bösartige Daten in ein System, das sie ungeprüft verarbeitet. Dasselbe gilt für alles, worauf du aufbaust: Open-Source-Bibliotheken, kommerzielle Bibliotheken, kommerzielle Plattformen. Wie sicher sind sie, und woran würdest du merken, dass eine davon einen Zero-Day enthält?
Sichere Voreinstellungen und sicheres Scheitern
Standard-Zugangsdaten sind seit Langem eine Quelle für Sicherheitsvorfälle. Jahrelang wurden Oracle-Installationen mit mächtigen Konten und Standardpasswörtern ausgeliefert, und mit dem Demo-Login Scott/Tiger kam man in fast jedes System. Oracle hat das behoben, aber viel Cloud-Demo-Software und Netzwerkhardware für Unternehmen kommt immer noch mit freigeschalteten Standardbenutzern und -passwörtern. Bequem, und gefährlich.
Sicheres Scheitern ist die andere Seite derselben Idee: Wenn etwas kaputtgeht, darf das System nicht in einen offenen Zustand fallen. Ein Datenbankhersteller, dem Performance über alles ging, baute einen manipulationssicheren Audit-Trail und ließ seine Entwickler dann das Auditing abschalten und weiterverarbeiten, sobald der Trail voll war. Ein Kunde entdeckte das in der Beta. Den Verantwortlichen erschien der Kompromiss vernünftig, und er war genau falsch.
Heute tritt dieses Problem leiser auf. Ein nachrichtengetriebenes System läuft nach dem Ausfall mehrerer Komponenten wieder an. Authentifiziert sich jeder Teil neu und verweigert die Verarbeitung, bis die Sicherheit durchgängig wiederhergestellt ist? Oder legt er schon mal los, weil die Sicherheitsdienste noch nicht bereit waren?
IT-Sicherheit gehört in die Entwurfsphase
Mach IT-Sicherheit zu einem Teil der Arbeitsweise im Team und nicht zu einer Notiz am Whiteboard, die im Tagesgeschäft niemand liest. Designprinzipien leiten einzelne Entscheidungen. Allein sorgen sie nicht dafür, dass ein Team sicher entwickelt.
Dafür brauchst du einen sicheren Softwareentwicklungszyklus. Das heißt nichts anderes, als dass du dich den ganzen Weg über um Sicherheit kümmerst und nicht erst am Ende. Erfinden musst du ihn nicht. OWASP bietet ein ausgereiftes Modell an, und mehrere staatliche Stellen veröffentlichen eigene. Nimm ein etabliertes Modell als Ausgangspunkt und pass es an, so wie jedes Team seinen Entwicklungsprozess anpasst.
Warum Tester hier die natürlichen Verbündeten sind
Tester denken ohnehin darüber nach, was schiefgehen kann, und genau diese Denkweise braucht IT-Sicherheit. Architekten versuchen das auch, aber sie sind Menschen und stehen oft unter Druck: neue Features, oder ein einzelnes Qualitätsziel wie der Durchsatz für die nächsten Sprints.
Hier verdient ein Tester sein Geld. Zu bemerken, dass ein neues Feature eine Sicherheitskontrolle zu umgehen scheint, und das auszusprechen, ist genau das, wofür Tester bezahlt werden sollten. Aufgabe des Teams ist es, diese Frage zu unterstützen, statt den Tester dafür unbeliebt zu machen. Die richtige Reaktion ist Dankbarkeit, denn die Alternative wäre gewesen, den Fehler auszuliefern.
Wenn Tester früh ins Team kommen, verschiebt sich das noch weiter. Solange der Tester als Letzter die Software gesehen hat, lautete die Reaktion: “Oh Gott, was habt ihr da gemacht?” Früh eingebunden, helfen Tester, das Problem zu verhindern, statt es zu entdecken.
Abuser Stories und Bedrohungsmodellierung, ganz einfach
Bring IT-Sicherheit als Abuser Stories ins Backlog: Wie würde jemand dieses System angreifen? Das ist ein vereinfachter Einstieg in die Bedrohungsmodellierung, eine Technik, die kompliziert klingt, es aber nicht ist.
Bedrohungsmodellierung ist ein strukturiertes Gespräch. Das Team setzt sich zusammen und fragt: Was haben wir, das wertvoll ist? Wer will es haben? Wie würde er angreifen, um es zu bekommen? Das Wertvolle können Daten sein, eine Finanztransaktion oder ein Vorgang, den ein Angreifer auslösen oder verhindern will. Geh methodisch vor und mach es nicht kompliziert, so raten es auch die echten Experten.
Das ähnelt dem Nachdenken über Hochverfügbarkeit. Du listest auf, was schiefgehen kann und was passiert, wenn einzelne Teile ausfallen. Danach weißt du, wie robust das System wirklich ist.
Zero-Days und Abhängigkeiten brauchen Automatisierung, keine Heldentaten
Komponenten aktuell zu halten ist ein Prozessproblem, das du nicht von Hand löst. In Ökosystemen mit feingliedrigen Abhängigkeiten wie Node.js behältst du bekannte Schwachstellen realistisch nur mit automatischer Unterstützung im Blick.
Auch hier gilt Defense in Depth. Wenn du dich beim Schutz stark auf eine Komponente verlässt und diese Komponente einen Zero-Day hat, wird ihn jemand ausnutzen. Verteile das Vertrauen, damit eine einzelne Schwachstelle nicht alles öffnet.
Zero-Days sind auch deshalb ein so hartnäckiges Problem, weil es einen Schwarzmarkt dafür gibt. Schon zu wissen, dass einer existiert, ist schwer. Diese Lücke schließt du nie ganz. Du kannst aber wissen, was in deinem System steckt, und die Suche nach Schwachstellen in deinen Open-Source-Komponenten automatisieren, denn dort sammelt sich das meiste Risiko.
Lose Schnittstellen sind eine verkappte Sicherheitsentscheidung
Freizügige APIs, die alles durchlassen, sind ein Sicherheitsrisiko und nicht bloß eine Bequemlichkeit. In einer Anwendungslandschaft, die über lockere Verträge verdrahtet ist, kann eine Infektion von System zu System wandern, bis sie irgendwo landet, wo es wehtut.
Der bequeme Weg ist der kleinste gemeinsame Nenner: alles zum String machen, nichts ablehnen, später übersetzen. Der Preis zeigt sich, wenn Angreifer manipulierte Strings bauen, die der String-Prozessor als gültig akzeptiert und die dann in einem anderen System, das sie interpretiert, einen Fehler auslösen. Das kann ein Denial of Service sein, oder etwas Gezielteres, das in einer Befehlsausführung aus der Ferne endet.
Stark typisierte Schnittstellen sind der Kompromiss. Sie brauchen länger, sind weniger flexibel und schwerer weiterzuentwickeln, deshalb greifen viele zu losen. Die Warnung bleibt trotzdem: Sobald du große Mengen ungeprüfter Daten annimmst, hast du ein potenzielles Sicherheitsproblem. Also prüf sorgfältig.
Häufig gestellte Fragen
Warum laufen Gespräche zwischen Entwicklungsteams und IT-Sicherheitsspezialisten oft schief?
Viele IT-Sicherheitsspezialisten kommen aus dem Infrastrukturbereich und wissen wenig über Softwareentwicklung, sodass die beiden Seiten unterschiedliche Sprachen sprechen. Sicherheitsspezialisten neigen dazu, den Teams eine Liste mit zwingenden, dringenden Forderungen zu überreichen, bei denen es um „Katastrophe oder sonst was“ geht. Diese Herangehensweise ist irreführend, denn in der IT-Sicherheit gibt es nichts Absolutes: Alles ist eine Frage der Balance. Die Teams kommen ihrerseits mit abstraktem Wissen an: Sie kennen Begriffe wie Authentifizierung und Auditing, wissen aber nicht, was sie damit anfangen sollen.
Mit wie vielen Prinzipien der IT-Sicherheit kann ein Team realistisch gesehen arbeiten?
Mit einem kompakten Satz von etwa zehn. Eoin Woods hat seinen eigenen zusammengestellt, nachdem er festgestellt hatte, dass bestehende Sammlungen entweder zu dünn waren (acht oder neun Einträge) oder unmöglich groß, mit mehreren hundert. Alle waren zwar gültig, an den Extremen aber nicht zu gebrauchen. Der Vorteil einer kurzen Liste ist, dass sie in den Kopf passt, während man eine Architektur skizziert, und frühzeitig Fragen aufwirft, etwa ob das Design einen Single Point of Failure hat.
Können mehrschichtige Abwehrmaßnahmen einen entschlossenen Angreifer tatsächlich aufhalten?
Nicht dauerhaft, und darum geht es auch nicht. Geht davon aus, dass jeder einzelne Mechanismus überwunden werden kann: Ein versierter Angreifer wird eine Verschlüsselung knacken oder an einem Authentifizierungssystem vorbeikommen. Bei unabhängigen, ineinandergreifenden Schichten steht der Angreifer nach dem Durchbruch einer Ebene erneut vor demselben Problem. Jede Schicht erhöht den Aufwand für einen Einbruch, und das ist oft die realistischste Verteidigung, die man aufbauen kann.
Sollte ein Team jemals eine eigene Verschlüsselung oder einen eigenen Speicher für Anmeldedaten entwickeln?
Nein. Selbst von Profis entwickelte Sicherheitstechnologie weist immer noch Schwachstellen auf, und erfahrene Tester nehmen sie sofort nach der Veröffentlichung unter die Lupe und finden immer wieder Probleme. Hinter einem selbst entwickelten Passwort-Tresor oder einer selbst programmierten Authentifizierung stehen weitaus weniger Ressourcen, wenn Angreifer kommen. Das Gleiche gilt für Protokolle, deren Implementierung auf den ersten Blick einfach erscheint: Such dir eine Bibliothek, die das bereits übernimmt.
Was sollte ein System tun, wenn sein Audit-Trail oder sein Authentifizierungsdienst ausfällt?
Die Verarbeitung stoppen. Sicheres Scheitern bedeutet, dass das System die Fortsetzung verweigert, anstatt standardmäßig in einen offenen Zustand zu wechseln. Ein Datenbankanbieter entwickelte einen manipulationssicheren Audit-Trail, ließ dann aber seine Ingenieure die Audit-Prozesse deaktivieren und den Betrieb fortsetzen, sobald dieser voll war; ein Kunde entdeckte das in der Beta-Phase. Eine moderne Variante ist unauffälliger: Komponenten, die nach einem Ausfall wieder anlaufen, verarbeiten Daten opportunistisch, bevor die IT-Sicherheit wiederhergestellt ist.
Brauchst du einen Experten für IT-Sicherheit, um mit der Bedrohungsmodellierung zu beginnen?
Nein. Die Bedrohungsmodellierung ist ein strukturiertes Gespräch, und jedes Team kann es führen: Setzt euch zusammen und fragt euch, was ihr an Wertvollem habt, wer daran interessiert sein könnte und wie Angreifer vorgehen würden, um daran zu gelangen. Das Wertvolle können Daten sein, eine Finanztransaktion oder ein Vorgang, den ein Angreifer aktivieren oder deaktivieren möchte. „Abuser Stories“ im Backlog sind ein einfacher Einstiegspunkt.
Wie kann ein Team den Überblick über Schwachstellen in den Komponenten behalten, auf die es angewiesen ist?
Durch Automatisierung statt manueller Arbeit. In Ökosystemen mit feinmaschigen Abhängigkeiten, wie z. B. Node.js, ist es unrealistisch, bekannte Schwachstellen manuell im Blick zu behalten. Zero-Day-Schwachstellen bleiben teilweise unkontrollierbar, weil ein Schwarzmarkt dafür es schon schwer macht, überhaupt zu erfahren, dass es sie gibt. Was du kontrollieren kannst: wissen, was sich in deinem System befindet, Open-Source-Komponenten automatisch überwachen und deine Sicherheit nicht von einer einzigen Komponente abhängig machen.
Warum sind permissive, stringbasierte Schnittstellen ein Sicherheitsrisiko?
Sie lassen eine Infektion von System zu System wandern, bis sie an einem kritischen Punkt landet. Der kleinste gemeinsame Nenner (alles als String behandeln, nichts ablehnen, später übersetzen) lädt Angreifer dazu ein, fehlerhafte Strings zu erstellen, die der String-Prozessor als korrekt akzeptiert und die dann weiter unten falsch interpretiert werden. Das Ergebnis kann eine Dienstblockade oder die Ausführung von Befehlen aus der Ferne sein. Stark typisierte Schnittstellen sind in der Entwicklung und Weiterentwicklung aufwendiger, das ist der Kompromiss.
