Sicherheitsverantwortung im Entwicklungsprozess

Sicherheitsverantwortung im Entwicklungsprozess

0:00 Im ersten Kapitel haben wir die Haltung geklärt: Sicherheit entsteht im Entwurf. Jetzt wird es konkret — und zwar an der Stelle, an der die meisten Projekte den Faden verlieren. Denn bevor Sie irgendetwas absichern können, müssen zwei Fragen beantwortet sein: Was genau schützen Sie eigentlich, und vor wem? Erstaunlich viele Teams überspringen diese Fragen und beginnen direkt mit Maßnahmen. Das Ergebnis sind dann Systeme, die an der falschen Stelle stark sind.

0:26 In diesem Kapitel arbeiten wir uns deshalb vom Schutzobjekt über den Schutzbedarf bis zur prüfbaren Anforderung vor.

Sicherheitsverantwortung im Entwicklungsprozess

0:34 Der Weg durch dieses Kapitel folgt einer klaren Reihenfolge. Wir beginnen bei den Sicherheitsanforderungen und ihrem richtigen Zeitpunkt, klären dann, was Assets und Schutzbedarf bedeuten, schauen uns an, wer uns eigentlich angreift, und übersetzen das Ganze am Ende in Anforderungen, die man auch prüfen kann. Zum Schluss drehen wir die Perspektive einmal um und fragen nicht, was das System können soll, sondern was es verhindern muss.

0:58 Vier Gedanken tragen dieses Kapitel. Der erste ist eine Zumutung für manche Organisation: Sicherheit ist geteilte Verantwortung — sie liegt nicht allein beim Security-Team, sondern bei allen, die Entscheidungen treffen, vom Product Owner bis zum Betrieb. Der zweite ist ein Weg: vom Schutzobjekt über den Schutzbedarf zur konkreten Anforderung, in dieser Reihenfolge.

1:19 Der dritte ist ein Perspektivwechsel: Angreifer und ihre Ziele werden zum Ausgangspunkt des Entwurfs, nicht zum Nachgedanken. Und der vierte ist die handwerkliche Pointe: Anforderungen müssen so geschrieben sein, dass man ihre Erfüllung erkennen kann. Sonst bleiben sie fromme Wünsche.

Sicherheitsanforderungen frühzeitig berücksichtigen

1:36 Beginnen wir mit dem Zeitpunkt. Sicherheitsanforderungen gehören in dieselbe Gesprächsrunde wie die fachlichen Anforderungen — nicht in eine eigene, die später stattfindet. Warum das mehr als eine Terminfrage ist, sehen wir gleich. So viel vorweg: Es geht um die Frage, wer im Raum sitzt, wenn die folgenreichen Entscheidungen fallen.

1:55 Und die fallen erfahrungsgemäß früher, als den meisten Beteiligten bewusst ist. Sicherheitsanforderungen legen fest, welche Werte ein System schützen muss und gegen welche Bedrohungen. Entscheidend ist der Zusatz: erhoben zusammen mit den fachlichen Anforderungen, nicht danach. Der Unterschied ist derselbe wie zwischen einem Bauantrag, in dem der Brandschutz von Anfang an mitgedacht ist, und einem, bei dem er nachgereicht wird — im zweiten Fall stehen die Wände schon.

2:23 Praktisch heißt das: Wenn im Refinement über eine neue Funktion gesprochen wird, gehört die Frage "und was darf dabei nicht passieren?" in dieselbe Diskussion. Sie kostet dort Minuten. Später kostet sie Umbauten. Der Nutzen früher Sicherheitsanforderungen liegt vor allem in ihrer Hebelwirkung: Sie prägen Architektur und Technologiewahl, während beides noch formbar ist.

2:44 Kommen sie später, entstehen Kompromisse — Sicherheit, die um die vorhandene Struktur herumgebaut werden muss und dadurch löchrig bleibt. Ein zweiter, oft unterschätzter Punkt: Prüfbare Anforderungen machen Sicherheit abnehmbar. Erst dann kann jemand sagen "erfüllt" statt "sieht gut aus". Und drittens, eher kulturell: Wenn Sicherheitsanforderungen im normalen Anforderungsprozess auftauchen, wird Sicherheit zur geteilten Aufgabe von Product, Entwicklung und Betrieb — statt zur Zuständigkeit einer Abteilung, an die man Probleme weiterreicht.

3:15 Vier Schritte, und ihre Reihenfolge ist der eigentliche Inhalt. Zuerst identifizieren Sie gemeinsam, was überhaupt schützenswert ist — gemeinsam heißt hier: mit den Fachleuten, denn welche Daten wirklich kritisch sind, weiß selten die Entwicklung allein. Dann schätzen Sie ein, wie schwer ein Verlust je Wert wiegt. Erst danach kommen Bedrohungen und Angreifer ins Spiel, und ganz am Ende die Anforderungen.

3:39 Der häufigste Fehler in der Praxis ist, bei Schritt vier anzufangen — mit einer Maßnahme, die man kennt und die sich gut anfühlt. Erst verstehen, was zu schützen ist, dann, wie. Diese Reihenfolge spart später viel Diskussion.

Assets, schützenswerte Daten und Schutzbedarf

3:53 Damit sind wir beim Schutzobjekt. Ein sperriges Wort für eine einfache Frage: Was genau wäre eigentlich der Schaden, wenn hier etwas schiefgeht? Ohne diese Antwort ist jede Maßnahme geraten — vielleicht richtig, vielleicht am Wesentlichen vorbei. Und weil Sicherheitsaufwand immer begrenzt ist, entscheidet genau diese Antwort darüber, ob Ihr Budget dort landet, wo es wirkt. Nehmen wir uns also Zeit für den Begriff.

4:18 Ein Asset ist ein schützenswerter Wert — und das sind mehr Dinge, als man zuerst denkt: nicht nur Daten, sondern auch Funktionen, die Verfügbarkeit eines Dienstes, sogar der Ruf eines Unternehmens. Der Schutzbedarf sagt, wie schwer ein Verlust wiegt, und zwar getrennt nach den drei klassischen Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit.

4:37 Denken Sie an eine Versicherung: Bevor über die Prämie gesprochen wird, wird der Wert des Gegenstands bestimmt. Genau das tun Sie hier — und zwar bewusst getrennt, weil dasselbe Asset in einer Dimension unkritisch und in einer anderen hochkritisch sein kann. Die drei Schutzziele wirken auf den ersten Blick akademisch, aber die Trennung hat einen sehr praktischen Zweck: Sie zwingt zum differenzierten Blick.

5:01 Nehmen Sie einen öffentlichen Fahrplan. Vertraulichkeit? Praktisch irrelevant, die Daten sollen ja jeder sehen. Integrität? Hoch — manipulierte Abfahrtszeiten wären ein echtes Problem. Verfügbarkeit? Ebenfalls hoch, ein Fahrplan, den niemand abrufen kann, ist wertlos. Hätten Sie nur pauschal "wichtig" notiert, wäre diese Information verloren gegangen.

5:23 Genau deshalb schätzen Sie je Asset getrennt nach C, I und A ein — die Antwort sagt Ihnen anschließend, wo Sie Aufwand investieren sollten und wo eben nicht. Jetzt probieren Sie das an einem Beispiel aus, das jeder kennt: ein einfacher Online-Shop mit Kundenkonten. Sammeln Sie zuerst die Assets — und lassen Sie sich Zeit dabei, die Liste ist länger, als sie zunächst scheint.

5:46 Danach stufen Sie je Asset ein, wie schwer ein Verlust in Vertraulichkeit, Integrität und Verfügbarkeit wöge, jeweils niedrig, mittel oder hoch. Wichtiger als die Einstufung selbst ist die Begründung. Wenn Sie später im Projekt erklären müssen, warum ein bestimmter Aufwand gerechtfertigt ist, ist genau diese Begründung Ihr Argument.

6:05 Und die Fälle, in denen Sie in der Gruppe uneinig sind, sind meist die interessantesten.

Angreifer und Angriffsszenarien

6:11 Wir wissen jetzt, was zu schützen ist. Bleibt die zweite Hälfte der Frage: vor wem? Sicherheit denkt aus der Sicht des Gegenübers — und dieses Gegenüber ist konkreter, als das abstrakte Wort "Angreifer" vermuten lässt. Solange es bei diesem Wort bleibt, bleibt auch die Verteidigung vage. Sobald Sie sagen können, wer realistisch Interesse an Ihrem System hat und was er mitbringt, werden aus vagen Sorgen konkrete Entscheidungen.

6:37 Ein Angreifermodell beschreibt, wer ein System bedroht, mit welchen Fähigkeiten und aus welchem Motiv. Die Spannweite ist groß: vom Gelegenheitstäter, der einen automatisierten Scan laufen lässt und nimmt, was sich findet, bis zum internen Mitwissenden mit legitimen Zugängen und Detailwissen über Ihre Prozesse. Der Nutzen liegt darin, dass "Angreifer" aufhört, ein Nebelwort zu sein.

6:58 Sobald Sie sagen können "unser realistischer Gegner ist eine automatisierte Kampagne auf bekannte Lücken" oder "unser Risiko ist ein ausscheidender Mitarbeiter mit Datenbankzugriff", folgen die sinnvollen Maßnahmen fast von selbst — und die unsinnigen fallen weg. Warum lohnt sich dieser Aufwand? Weil die passende Schutzmaßnahme von der Angreiferstärke abhängt.

7:19 Gegen einen Gelegenheitstäter helfen Aktualität und saubere Grundhygiene; gegen einen gezielten, gut ausgestatteten Angreifer braucht es gestaffelte Verteidigung. Besonders wichtig ist der Innentäter: Er umgeht viele klassische Perimeter-Maßnahmen einfach dadurch, dass er schon drinnen ist — Firewall und Gateway sehen ihn gar nicht.

7:38 Und ein dritter, sehr nüchterner Punkt: Realistische Szenarien schützen vor beidem, vor Unterdimensionierung genauso wie vor Überdimensionierung. Sicherheitsaufwand, der am realistischen Risiko vorbeigeht, kostet Geld und Akzeptanz — und beides fehlt Ihnen dann an anderer Stelle. Interessant an dieser Übersicht ist die rechte Spalte im Verhältnis zur mittleren. Das Motiv bestimmt, wie hartnäckig jemand ist; die Fähigkeit bestimmt, wie tief er kommt.

8:04 Der Gelegenheitstäter sucht nicht Sie, er sucht irgendein verwundbares System — gegen ihn hilft, schlicht kein leichtes Ziel zu sein. Der organisierte Angreifer sucht sehr wohl Sie, weil sich das rechnet; er kommt wieder, auch wenn der erste Versuch scheitert. Und der Innentäter braucht gar keinen Exploit, er hat ja Zugang — bei ihm verschiebt sich die Verteidigung von "Eindringen verhindern" zu "Missbrauch begrenzen und nachvollziehbar machen".

8:29 Drei Typen, drei völlig verschiedene Antworten.

Security Requirements formulieren

8:33 Jetzt läuft alles zusammen. Aus Schutzbedarf und Angreifermodell wird eine Anforderung — und zwar eine, an der man später messen kann, ob sie erfüllt ist. Genau daran scheitern die meisten gut gemeinten Sicherheitsvorgaben. Sie stehen im Dokument, alle nicken, und niemand kann sagen, wann sie erledigt sind. Dieser Abschnitt ist deshalb weniger ein Sicherheitsthema als ein handwerkliches: Wie schreibt man etwas auf, das man prüfen kann?

8:59 Security Requirements übersetzen Schutzbedarf und Bedrohungen in konkrete, überprüfbare Vorgaben. Zwei Wörter tragen die Last dieser Definition: positiv und testbar. Positiv formuliert heißt, Sie beschreiben, was das System tun soll — nicht, was es nicht tun darf. "Darf nicht unsicher sein" lässt sich nicht bauen und nicht prüfen.

9:19 Testbar heißt, es gibt eine Beobachtung, die die Erfüllung zeigt. Der Maßstab ist derselbe wie bei fachlichen Anforderungen: Eine Anforderung, bei der zwei Leute unterschiedlicher Meinung sein können, ob sie erfüllt ist, ist noch keine Anforderung. Sie ist eine Absichtserklärung. Diese vier Schritte sind die Brücke von allem Vorherigen zur konkreten Vorgabe.

9:42 Zuerst benennen Sie das Schutzziel je Asset — Vertraulichkeit, Integrität oder Verfügbarkeit, nicht alle drei pauschal. Dann machen Sie die Bedrohung konkret: nicht "Angriff", sondern "jemand probiert automatisiert Passwörter durch". Erst dann formulieren Sie die Anforderung, positiv und prüfbar. Und im vierten Schritt, der am häufigsten vergessen wird, ergänzen Sie das Abnahmekriterium — den Testfall, der zeigt, dass es hält.

10:08 Faustregel: Jede Anforderung braucht ein "woran erkennt man Erfüllung". Fehlt das, haben Sie einen Wunsch aufgeschrieben, keine Anforderung. Der Vergleich zeigt dasselbe Anliegen zweimal. Oben "Login muss sicher sein" — ein Satz, dem jeder zustimmt und mit dem niemand arbeiten kann. Er sagt nicht, was zu bauen ist, und er sagt nicht, wann man fertig ist.

10:30 Unten dieselbe Absicht, aber zerlegt in Aussagen, die man umsetzen und prüfen kann: eine Sperre nach mehreren Fehlversuchen, ein konkretes Verfahren zum Speichern von Passwörtern, eine Mindestanforderung an die Transportverschlüsselung. Worauf es hier ankommt, sind nicht die einzelnen Werte — die hängen von Ihrem Kontext ab.

10:49 Es ist der Sprung von einer Eigenschaft, die man nur behaupten kann, zu Aussagen, die ein Test entscheiden kann. Das ist der ganze Unterschied.

Abuse Cases und Misuse Cases

10:58 Zum Schluss ein Perspektivwechsel, der überraschend viel sichtbar macht. Wir haben bisher gefragt, was das System können soll. Jetzt fragen wir, was jemand damit anstellen könnte, der nichts Gutes im Sinn hat. Das ist keine akademische Übung: Erfahrungsgemäß kommen in der halben Stunde, in der ein Team diese Frage ernst nimmt, mehr brauchbare Sicherheitsanforderungen zusammen als in jedem Checklisten-Durchlauf.

11:22 Ein Abuse Case beschreibt, wie jemand das System bewusst missbraucht — das Spiegelbild eines Use Cases. Der Trick daran ist seine Anschlussfähigkeit: Use Cases sind in den meisten Teams etabliert, jeder kann damit umgehen. Der Abuse Case nutzt genau dieses vertraute Format und dreht nur die Absicht der handelnden Person um.

11:40 Damit wird Sicherheitsdenken für alle zugänglich, auch für Fachleute ohne Security-Hintergrund — und Sie brauchen keine neue Methode einzuführen, sondern nur eine zusätzliche Spalte. Der Effekt in Workshops ist regelmäßig verblüffend: Sobald jemand die Angreiferrolle einnimmt, fallen Lücken auf, über die vorher niemand gesprochen hat.

11:59 Beachten Sie das Muster hinter den drei Zeilen: In jedem Fall wird dieselbe legitime Funktion benutzt, nur mit anderer Absicht. Niemand bricht hier ein — angemeldet wird sich, hochgeladen wird, zurückgesetzt wird, alles wie vorgesehen. Genau das ist die Lehre: Angriffe brauchen oft gar keine Lücke im engeren Sinn, sie missbrauchen die vorgesehene Funktion.

12:20 Daraus folgt die Frage, die Sie zu jeder Funktion stellen sollten: Was passiert, wenn jemand das hier tausendmal tut, für ein fremdes Konto oder mit unerwarteten Inhalten? Jede ehrliche Antwort auf diese Frage erzeugt eine konkrete Gegenmaßnahme — und die ist dann keine Vermutung mehr, sondern begründet. In dieser Übung wenden Sie das auf den Online-Shop an, mit dem Sie vorhin schon die Assets bestimmt haben.

12:44 Nehmen Sie drei fachliche Use Cases und entwickeln Sie zu jedem ein Missbrauchsszenario — und dann, das ist der eigentliche Ertrag, jeweils eine passende Gegenmaßnahme. Achten Sie darauf, dass die Gegenmaßnahme wirklich zum Szenario passt und nicht nur eine allgemein gute Idee ist. Wenn Sie am Ende sagen können "diese Maßnahme existiert, weil genau dieser Missbrauch sonst möglich wäre", haben Sie eine begründete Sicherheitsanforderung — und damit alles, was das nächste Kapitel als Ausgangspunkt braucht.

13:12 Halten wir fest: Sicherheitsverantwortung ist geteilt und beginnt in der Anforderungsphase — nicht bei einer Abteilung und nicht am Projektende. Assets und Schutzbedarf machen Sicherheit greifbar und, ebenso wichtig, priorisierbar: Sie wissen danach, wo Aufwand hingehört. Angreifermodell und Abuse Cases liefern die Bedrohungssicht, ohne die jede Maßnahme geraten bleibt. Und prüfbare Anforderungen sind das Bindeglied zwischen Absicht und Abnahme.

13:37 Damit haben Sie alle Zutaten beisammen — was im nächsten Kapitel folgt, ist die Methode, die daraus ein strukturiertes Verfahren macht: Threat Modeling.

Fragen & Ausblick

13:47 Im nächsten Kapitel wird aus den einzelnen Bausteinen ein Verfahren: Threat Modeling als praktische Methode — mit einem klaren Ablauf, den Sie in einem Workshop von zwei Stunden durchführen können. Die Beispiele und Vorlagen zu den beiden Aufgaben liegen in der Freigabe, inklusive der Asset-Liste zum Online-Shop, mit der wir weiterarbeiten werden.

14:07 Wenn jetzt Fragen offen sind, gern — besonders zu den Stellen, an denen Sie in Ihrem eigenen Projekt unsicher sind. Ansonsten erreichen Sie uns unter info@HCO.de.