Security by Design verstehen

Security by Design verstehen

0:00 Über Sicherheit wird in Projekten meist dann geredet, wenn es schon knirscht: nach dem ersten Pentest-Bericht, nach dem ersten Vorfall, kurz vor einem Audit. Dieses Kapitel dreht die Reihenfolge um. Die Grundidee klingt fast banal, hat aber weite Folgen: Sicherheit ist keine Funktion, die man hinterher einbaut, sondern eine Eigenschaft, die aus dem Entwurf entsteht — oder eben nicht.

0:21 Wir schauen uns an, warum das keine Haltungsfrage ist, sondern eine schlicht wirtschaftliche, und was sich für Ihre tägliche Arbeit ändert, wenn Sie Sicherheitsfragen nach vorn ziehen. Und wir sortieren die Begriffe, die im Alltag gern durcheinandergehen.

Security by Design verstehen

0:36 Der erste Tag legt das Fundament, auf dem alles Weitere aufbaut. Wir klären, warum Sicherheit eine Architekturfrage ist, grenzen sie sauber von Secure Coding und Security-Tests ab, trennen Security by Design von Security by Default und schauen zum Schluss darauf, woher unsichere Systeme wirklich kommen. Bewusst noch ohne Werkzeuge und Checklisten — die kommen später. Erst brauchen wir ein gemeinsames Vokabular, sonst reden wir in den folgenden Kapiteln aneinander vorbei.

1:03 Vier Fäden laufen durch dieses Kapitel, und sie hängen zusammen. Der erste: der Perspektivwechsel weg von Sicherheit als nachgelagertem Test hin zu Sicherheit als Entwurfseigenschaft. Der zweite: die saubere Unterscheidung zwischen Secure Coding, Pentests und Security by Design — drei Dinge, die im Alltag oft in einen Topf geworfen werden.

1:23 Der dritte: die Beobachtung, dass die teuersten Lücken selten Tippfehler sind, sondern Entscheidungen, die viel früher gefallen sind. Und der vierte, unscheinbar, aber wichtig: ein gemeinsames Vokabular. Wenn im Projekt alle dasselbe meinen, wenn sie "Vertrauensgrenze" sagen, ist schon viel gewonnen.

Sicherheit als Entwurfseigenschaft

1:42 Beginnen wir mit der Frage, warum Sicherheit überhaupt an den Anfang gehört und nicht ans Ende. Die Antwort hat weniger mit Idealismus zu tun als mit Kosten — und die lassen sich erstaunlich klar beziffern. Denn hinter dem etwas pathetischen Satz "Sicherheit ist eine Entwurfseigenschaft" steht eine sehr nüchterne Beobachtung aus der Projektpraxis: Je später eine Entscheidung revidiert werden muss, desto mehr hängt bereits an ihr.

2:06 Schauen wir uns an, was das konkret bedeutet. Security by Design heißt: Sicherheit ist ein gestaltendes Kriterium, kein Prüfschritt. Sie wirkt schon in den Anforderungen, in der Architektur, im Entwurf mit — dort, wo Sie entscheiden, welche Komponente wem vertraut und wo Daten die Systemgrenze überqueren. Ein Bild dafür: Ein Haus wird nicht dadurch einbruchsicher, dass man am Ende ein besseres Schloss kauft.

2:30 Wo die Fenster sitzen, ob es einen einsehbaren Zugang gibt, wie die Tür angeschlagen ist — das entscheidet der Grundriss, und der entsteht am Reißbrett. Das Schloss ist wichtig, aber es kann einen schlechten Grundriss nicht heilen. Genau diese Unterscheidung trägt das ganze Seminar. Warum lohnt sich der Aufwand, so früh über Sicherheit nachzudenken? Vor allem, weil späte Korrekturen strukturell teuer sind.

2:54 Eine Entwurfsentscheidung lässt sich in der Anforderungsphase in einem Gespräch ändern — in Produktion braucht es dafür Migrationen, Abstimmungen, Ausfallfenster. Dazu kommt: Ein erheblicher Teil der Schwachstellen, die uns in der Praxis begegnen, sind gar keine Tippfehler, sondern Entscheidungen. Wer darf was, ohne gefragt zu werden.

3:14 Frühe Sicherheitsanforderungen haben außerdem Hebelwirkung: Sie steuern mit, welche Technologien und Schnittstellen Sie überhaupt wählen. Und, nicht zu unterschätzen, sie machen Sicherheit planbar — statt reaktiv nach dem ersten Vorfall. Diese Tabelle ist im Kern eine einzige Aussage: Je später eine Lücke auffällt, desto mehr hängt schon an ihr.

3:35 Das ist keine Security-Besonderheit, sondern gilt für Fehler in der Softwareentwicklung generell — nur wirkt es hier besonders hart. Der Grund ist die Zahl der Abhängigkeiten. Früh ändern Sie eine Entscheidung, die noch nichts trägt. Später hängen daran Code, Tests, Schnittstellen, vielleicht schon Verträge mit Partnern und Daten in Produktion.

3:56 Und ganz rechts, im Vorfall, kommt etwas hinzu, das in keiner Aufwandsschätzung steht: der Schaden selbst — Betriebsunterbrechung, Meldepflichten, Vertrauensverlust. Das ist der Kostenhebel, um den es geht. Drei Muster begegnen einem in Projekten immer wieder. "Das härten wir später" klingt pragmatisch und ist es kurzfristig auch — nur wird die Architektur, die inzwischen gewachsen ist, dann selbst zum Zwang, der die Härtung verhindert.

4:22 Das zweite Muster: Sicherheit als Compliance-Häkchen. Wer eine Liste abarbeitet, erfüllt eine Vorgabe, aber denkt nicht über sein System nach — und Angreifer halten sich nicht an Listen. Das dritte ist das folgenreichste: Verantwortung komplett an ein Security-Team am Ende der Kette abzugeben. Wer am Ende steht, kann nur noch Symptome finden.

4:42 Die Entscheidungen sind da längst gefallen.

Abgrenzung — Secure Coding und Security-Tests

4:45 Damit sind wir beim häufigsten Missverständnis überhaupt. Secure Coding, Security-Tests, Security by Design — drei Begriffe, die im Alltag oft synonym benutzt werden. Sortieren wir sie, denn die Verwechslung ist folgenreich. Sie führt nämlich regelmäßig dazu, dass Teams eine Ebene sehr gründlich bearbeiten und dabei glauben, damit sei das Thema erledigt.

5:07 Die anderen beiden bleiben unbesetzt — und niemand merkt es, weil auf dem Papier ja etwas für Sicherheit getan wurde. Die drei Ebenen beantworten unterschiedliche Fragen zu unterschiedlichen Zeitpunkten. Secure Coding sorgt dafür, dass eine einzelne Funktion handwerklich sauber umgesetzt ist — dass Eingaben geprüft, Ausgaben korrekt kodiert werden.

5:28 Security-Tests suchen im fertigen System nach Lücken, von außen, mit den Mitteln eines Angreifers. Security by Design entscheidet, ob das System überhaupt sicher gebaut werden kann. Ein Bild: Secure Coding ist sauberes Mauerwerk, Security-Tests sind die Abnahme durch den Prüfer, Security by Design ist der Grundriss. Alle drei braucht man.

5:48 Aber der beste Prüfer kann keinen Grundriss reparieren, und die sauberste Wand steht manchmal an der falschen Stelle. Der praktische Nutzen dieser Unterscheidung: Sie schützt vor falscher Sicherheit. Ein Feature kann perfekt kodiert sein — jede Eingabe validiert, kein Injection-Risiko — und trotzdem architektonisch unsicher, weil es Daten sieht, die es nie sehen dürfte.

6:11 Pentests wiederum finden Symptome, und sie finden sie spät. Sie sagen Ihnen, dass etwas offen ist, aber selten, warum es strukturell offen sein musste. Erst das Zusammenspiel ergibt belastbare Sicherheit: der Entwurf legt fest, was gelten soll, das Handwerk setzt es korrekt um, die Tests prüfen, ob es hält. Fällt eine Ebene weg, merken Sie es meist erst im Ernstfall.

6:34 Die Logik dieser Tabelle steckt in der mittleren Spalte, in den drei Fragen. "Ist es sicher gebaut?" ist eine Entwurfsfrage — sie lässt sich am Whiteboard beantworten, bevor eine Zeile Code existiert. "Ist es sicher umgesetzt?" ist eine Handwerksfrage, sie stellt sich beim Schreiben und im Review. "Ist es sicher geblieben?" hat eine zeitliche Komponente, die man leicht übersieht: Systeme ändern sich, Abhängigkeiten altern, Konfigurationen driften.

7:01 Deshalb steht dort "Test und Betrieb" und nicht nur "Test". Lesen Sie die Zeilen also nicht als Alternativen, aus denen man wählt, sondern als drei Zeitpunkte, an denen jeweils eine andere Frage beantwortet werden muss. Auch hier drei typische Kurzschlüsse. Der Pentest am Projektende als einzige Maßnahme — beliebt, weil er sich gut budgetieren lässt, aber er kommt zu spät, um noch etwas Grundsätzliches zu ändern.

7:26 Dann die statische Analyse, die als Ersatz für eine Bedrohungsanalyse herhalten muss: Ein Werkzeug findet Muster in Code, es kann aber nicht wissen, welche Daten in Ihrem Kontext schützenswert sind. Und schließlich der Klassiker: "grün im Scanner" mit "sicher entworfen" gleichzusetzen. Ein grünes Ergebnis heißt, dass nichts von dem gefunden wurde, wonach gesucht wurde.

7:47 Das ist etwas anderes, als sicher zu sein — und der Unterschied ist genau unser Thema.

Security by Design und Security by Default

7:53 Zwei Begriffe, die sich ähneln und doch Verschiedenes meinen. Der eine betrifft die Bauweise, der andere den Zustand bei Auslieferung. Schauen wir uns den Unterschied an einem sehr konkreten Beispiel an — an einer Konfigurationsdatei, wie sie in jedem Projekt liegt. Denn hier zeigt sich, dass Sicherheit nicht nur eine Frage der Architektur ist, sondern auch eine sehr praktische Frage danach, welchen Zustand ein System annimmt, wenn niemand eingreift.

8:19 Security by Default heißt: Das System ist im Auslieferungszustand sicher konfiguriert. Niemand muss Sicherheit erst einschalten. Denken Sie an ein Auto, bei dem ABS serienmäßig aktiv ist, statt in einem Menü zu warten, bis jemand es findet. Das klingt nach einer Kleinigkeit, ist aber der Punkt, an dem Theorie auf Wirklichkeit trifft: Sie können ein System hervorragend entworfen haben — wenn es unsicher voreingestellt ausgeliefert wird, läuft es in der Praxis unsicher.

8:46 Security by Design und Security by Default sind also keine Gegensätze, sondern zwei Stufen: sicher baubar, und sicher ausgeliefert. Die zweite entscheidet, was beim Anwender tatsächlich ankommt. Warum die Voreinstellung so viel Gewicht hat, ist eine schlichte Beobachtung aus der Praxis: Was voreingestellt ist, bleibt meistens so.

9:06 Nicht aus Nachlässigkeit — sondern weil unter Zeitdruck niemand jede Option prüft, und weil viele Nutzende gar nicht wissen können, welche Einstellung riskant ist. Der Standardpfad ist der Pfad, den die meisten tatsächlich gehen. Daraus folgt eine ziemlich klare Verantwortung für uns als Entwickelnde: Der sichere Zustand gehört in die Voreinstellung, nicht in die Dokumentation.

9:27 Nebenbei sinkt so die Angriffsfläche ab dem Moment der Installation — und nicht erst, wenn jemand Zeit zum Härten gefunden hat. Der Ausschnitt zeigt zweimal dieselbe Konfiguration, einmal in der bequemen und einmal in der sicheren Variante. Oben: verschlüsselte Verbindung optional, ein vorgegebenes Administrator-Passwort. Beides funktioniert sofort, beides ist ein offenes Scheunentor, wenn es niemand nachzieht.

9:51 Unten dieselben Schalter, anders gestellt: Verschlüsselung verpflichtend, und statt eines Standardpassworts steht schlicht nichts drin — das System zwingt beim ersten Start dazu, eines zu setzen. Worauf es hier ankommt, ist nicht die Syntax, sondern die Umkehr der Beweislast: Nicht Sicherheit muss aktiviert werden, sondern ihre Abschaltung muss bewusst entschieden werden.

10:12 Das ist der ganze Unterschied. Jetzt sind Sie dran. Die Aufgabe ist bewusst nah an dem, was Ihnen im Projekt begegnet: Sie bekommen einen echten Konfigurationsausschnitt und gehen ihn Einstellung für Einstellung durch. Für jede die Frage — ist das sicher voreingestellt, und warum? Es geht dabei weniger ums Rechthaben als ums Begründen.

10:32 Genau diese Begründung brauchen Sie später im Review oder im Gespräch mit dem Betrieb. Arbeiten Sie in Kleingruppen, und diskutieren Sie ruhig die Fälle, bei denen Sie sich uneinig sind — das sind erfahrungsgemäß die lehrreichsten. Am Ende sollte zu jeder Einstellung eine Einordnung stehen, nicht nur ein Bauchgefühl.

Typische Ursachen struktureller Sicherheitsprobleme

10:51 Bleibt die Frage, woher unsichere Systeme eigentlich kommen. Die Antwort ist selten "jemand hat schlecht programmiert" — und sie führt uns direkt zu den Themen der folgenden Kapitel. Wenn Sie sich Vorfallberichte anschauen, finden Sie am Ende der Kette zwar oft eine fehlerhafte Zeile. Aber die interessante Frage ist eine andere: Warum konnte dieser eine Fehler überhaupt so weitreichende Folgen haben? Genau darum geht es in diesem Kapitel.

11:16 Strukturelle Sicherheitsprobleme entstehen aus Entwurfsentscheidungen: aus implizitem Vertrauen, aus fehlenden Grenzen, aus vermischten Zuständigkeiten. Das Tückische daran ist, dass jede einzelne Entscheidung für sich vernünftig aussieht. Ein Bild: eine Wohnung, in der jede Tür ein gutes Schloss hat — aber alle Schlüssel hängen im Flur, weil das praktisch war.

11:37 Kein einzelnes Schloss ist kaputt, trotzdem ist die Wohnung offen. Genau so sehen die meisten strukturellen Probleme aus. Deshalb finden Sie sie auch nicht, indem Sie Zeilen prüfen — Sie finden sie, indem Sie Beziehungen zwischen Komponenten prüfen. Wer vertraut wem, und warum eigentlich? Diese vier Schritte sind kein Werkzeug, sondern eine Reihenfolge von Fragen, die sich in der Praxis bewährt hat.

12:01 Zuerst decken Sie implizites Vertrauen auf: Wo redet eine Komponente mit einer anderen, ohne dass jemand prüft, wer da eigentlich anfragt? Daraus ergibt sich der zweite Schritt fast von selbst — Sie benennen die Vertrauensgrenzen, die fehlen oder unscharf sind. Dritter Schritt: vermischte Zuständigkeiten trennen, klassisch Authentifizierung, die mitten in der Fachlogik sitzt.

12:23 Und viertens, eher ein Gespür als ein Schritt: Wo Sicherheit sichtbar nachträglich drangeschraubt wurde, lohnt genaueres Hinsehen. Das ist meist die Stelle, an der ein Entwurf einmal nicht gepasst hat. Die häufigste Annahme zuerst: Das interne Netz sei ohnehin sicher. Diese Vorstellung stammt aus einer Zeit, in der "innen" und "außen" noch klar getrennt waren — mit Cloud, Homeoffice und Dienstleisterzugängen ist sie kaum noch haltbar.

12:48 Der zweite Punkt hängt daran: Sicherheit an den Rand zu delegieren, an ein Gateway oder eine Firewall. Das funktioniert genau so lange, wie niemand daran vorbeikommt. Und der dritte Stolperstein ist der unauffälligste: Komplexität, die niemand mehr vollständig überblickt. Ein System, das keiner mehr ganz versteht, kann auch niemand mehr verlässlich beurteilen — und genau in diesen blinden Flecken sitzen die Probleme, die später teuer werden.

13:14 Zum Abschluss eine Übung, die den Perspektivwechsel dieses Kapitels auf die Probe stellt. Nehmen Sie einen bekannten Vorfall aus der Presse — davon gibt es leider reichlich — und arbeiten Sie sich von der Schlagzeile zur Ursache vor. Meist wird eine Symptomzeile berichtet: eine Lücke in einer Bibliothek, ein offener Endpunkt.

13:33 Ihre Aufgabe ist die Frage dahinter: Welche Entwurfsentscheidung hat es möglich gemacht, dass genau dieser Fehler so große Wirkung entfalten konnte? Wenn Sie beides sauber trennen können — Symptom hier, strukturelle Ursache dort — haben Sie den Kern dieses Kapitels verstanden. Halten wir fest: Sicherheit entsteht im Entwurf. Secure Coding und Security-Tests sind unverzichtbar, aber sie ergänzen den Entwurf, sie ersetzen ihn nicht.

13:59 Security by Default sorgt dafür, dass der sichere Zustand auch der Auslieferungszustand ist — der Punkt, an dem gute Absicht in der Praxis ankommt. Und die teuersten Lücken sind strukturell: implizites Vertrauen, fehlende Grenzen, vermischte Zuständigkeiten. Wenn Sie aus diesem Kapitel eine Frage mitnehmen, dann diese: Wer vertraut hier wem, und warum?

14:20 Im nächsten Kapitel wird daraus eine sehr praktische Frage — nämlich, wer im Entwicklungsprozess eigentlich dafür zuständig ist.

Fragen & Ausblick

14:29 Damit ist das Fundament gelegt. Kapitel 2 nimmt sich die Sicherheitsverantwortung im Entwicklungsprozess vor: wer welche Entscheidung trifft, wo Sicherheitsanforderungen herkommen und wie sie den Weg in die tägliche Arbeit finden. Die Materialien und Beispiele liegen in der Freigabe, damit Sie die Konfigurationsausschnitte in Ruhe nacharbeiten können.

14:49 Fragen sind jetzt willkommen — gerade die aus Ihrem eigenen Projektalltag sind hier die wertvollsten. Bei allem Weiteren erreichen Sie uns unter info@HCO.de.