Security-Anforderungen im Team entwickeln

Security Requirements sind konkrete, testbare Anforderungen, die auf drei Schutzzielen basieren: Vertraulichkeit, Integrität und Verfügbarkeit. Sie entstehen nicht aus generischen Katalogen, sondern aus der Frage, welche Assets schützenswert sind und warum. Erst dann lässt sich bestimmen, welche Maßnahmen nötig sind und wie man sie überprüft.

Das Wichtigste in Kürze

• Security Requirements lassen sich nur sinnvoll formulieren, wenn vorher geklärt ist, welche Assets schützenswert sind und welche Schutzziele, Vertraulichkeit, Integrität oder Verfügbarkeit, für sie gelten.
• Einen Pentest erst kurz vor dem Release durchzuführen ist der teuerste Zeitpunkt, einen Sicherheitsfehler zu entdecken, weil alle Designentscheidungen bereits gefallen sind.
• Kartenspiele wie Elevation of Privilege oder Cornucopia ermöglichen es Teams ohne ausgewiesene Security-Expertise, Bedrohungsszenarien spielerisch zu identifizieren und zu dokumentieren.
• Kataloge wie der OWASP ASVS sind nützlich, aber erst dann anwendbar, wenn ein Team weiß, welche Schutzziele es erfüllen muss, sonst fehlt der Maßstab für Priorisierung und Testtiefe.
• Das Grundrauschen an Angriffen kommt überwiegend von opportunistisch arbeitenden IT-Firmen, die automatisiert nach Lücken scannen, nicht vom klischeehaften Hacker mit gezieltem Angriffsziel.

Security ist ein Teil der Softwarequalität, kein Sonderfall

Sicherheit gehört zu den Qualitätseigenschaften einer Software, genauso wie Performance oder Verfügbarkeit. Für klassische Qualitätsanforderungen existieren etablierte Werkzeuge: das Qualitätsszenario mit Vorbedingung, Kontext, Trigger, Outcome und einer testbaren Metrik.

Bei Performance funktioniert das gut. Du fragst den Stakeholder, wie lange eine Transaktion dauern darf, und bekommst eine konkrete Antwort: eine Sekunde in 99 Prozent der Fälle, im Normalbetrieb. Daraus lässt sich ein prüfbares Szenario bauen, und am Ende kannst du beweisen, dass die Anforderung erfüllt ist.

Bei Security fehlen vielen Teams die sprachlichen Bausteine, um genau das zu formulieren. Das Problem ist nicht die Komplexität des Themas, sondern dass über “Sicherheit” zu abstrakt geredet wird. Wer Security-Anforderungen testbar machen will, muss sie zuerst aussprechbar machen.

Warum abstrakte Security-Anforderungen nicht testbar sind

“Wir brauchen eine besonders hohe Vertraulichkeit” ist keine testbare Anforderung, solange unklar bleibt, worauf sie sich bezieht. Der Satz ergibt erst Sinn, wenn du dazu sagst, um welche Daten es geht.

Ein Beispiel: Bei einer öffentlichen Homepage oder einem LinkedIn-Profil ist Vertraulichkeit nicht das Ziel. Im Gegenteil, du willst, dass die Inhalte von möglichst vielen Leuten gesehen werden. Integrität dagegen ist hier wichtig. Niemand soll die Inhalte verändern, ohne dass du einverstanden bist.

Der Schutzbedarf hängt also vom konkreten Asset ab, über das gesprochen wird. Ohne dieses Asset bleibt jede Security-Anforderung Luft.

Die CIA-Schutzziele als gemeinsame Sprache

Statt über “Security” zu reden, lohnt sich der Blick auf die konkreten Sicherheitsziele. Die drei wichtigsten lassen sich mit dem Akronym CIA merken:

• Confidentiality (Vertraulichkeit): Was passiert, wenn die Information öffentlich wird? Stört es dich, ist es ein Problem, vielleicht sogar ein Gesetzesverstoß?
• Integrity (Integrität): Was passiert, wenn die Information ungewollt verändert wird? Ist das ein Problem, oder stellt sich der korrekte Zustand von selbst wieder her?
• Availability (Verfügbarkeit): Verlierst du Geld, wenn das System eine halbe Stunde ausfällt? Oder merkt es niemand?

Diese Leitfragen verwandeln eine vage Sicherheitsforderung in konkrete Anforderungen. Es gibt weitere Schutzziele wie Authentizität, Nicht-Abstreitbarkeit und Anonymität. An denen zeigt sich auch, dass nicht alles gleichzeitig zu haben ist: Anonymität widerspricht der Nicht-Abstreitbarkeit. Security ist immer eine Abwägung.

Erst die Assets, dann die Anforderung

Der erste Schritt in der Analyse ist die Frage, was überhaupt schützenswert ist. Dabei wird zwischen zwei Arten von Assets unterschieden.

Primary Assets sind die eigentlich schützenswerten Dinge, die wertvollen Daten selbst. Supporting Assets sind die Bestandteile des Systems, die du brauchst, um diese Daten zu verarbeiten.

Wer diese Unterscheidung sauber macht, findet einen systematischen Weg, um den Schutzbedarf zu bestimmen. Erst danach lässt sich entscheiden, was getan werden muss, um diesen Schutzbedarf tatsächlich zu erfüllen.

Wie passen Security-Kataloge in dieses Bild?

Kataloge wie der Application Security Verification Standard (ASVS) von OWASP sind nützlich, aber sie funktionieren erst auf Basis erhobener Anforderungen. Der ASVS eignet sich gut für Audits und macht relativ konkrete Vorgaben, was zu tun ist. Genau deshalb klingt er technisch.

Der Haken: Solche Kataloge sind allumfassend. Sie sagen nicht, welcher Teil für dein System relevant ist. Ob eine Non-Compliance, also die Nichterfüllung einer Katalog-Anforderung, ein echtes Problem darstellt, kannst du nur beurteilen, wenn du dein Schutzziel kennst.

Über das gesamte Kryptografie-Kapitel musst du nicht ernsthaft reden, wenn es keine vertraulichen Daten im System gibt. Der ASVS kennt drei Erfüllungsgrade, Level 1 bis 3. Welcher Level für dich gilt und wie genau du prüfen oder reviewen musst, ergibt sich aus den Anforderungen. Deshalb stehen die Anforderungen am Anfang, nicht der Katalog.

Threat Modeling ergänzt das von der anderen Seite. Es zeigt, auf welche Art und Weise ein Schutzziel kompromittiert werden könnte, und hilft beim Priorisieren der Gegenmaßnahmen. Wer aber nur die Bedrohung modelliert, weiß noch nicht, was zu tun ist. Kataloge wie der ASVS liefern an dieser Stelle die konkrete Handlungsanweisung.

Pentest ist Verifikation, nicht Vorsorge

Ein Pentest am Ende ist nur die Überprüfung dessen, was vorher entschieden wurde. Hier gilt dieselbe Regel wie bei jedem anderen Testthema: You can’t test quality in.

Es ist gut, wenn ein Problem vor dem Release auffällt. Trotzdem ist das vor dem Release der teuerste Zeitpunkt, einen Fehler zu entdecken. Nach dem Release mit echten Kundendaten wird es nur noch teurer. Über Security in Architektur und Design nachzudenken, funktioniert nur, wenn die Anforderungen bekannt sind. Eine Binsenweisheit, die trotzdem gemacht werden muss.

Security-Analyse ist iterativ, nicht einmalig

Threat Modeling und Schutzbedarfsanalyse sind kein Wasserfall-Schritt am Anfang. Sie wiederholen sich immer dann, wenn sich die ursprünglichen Entscheidungsgrundlagen ändern. Mehrere Trigger lösen eine neue Runde aus:

• Neue Funktionalität: Ein neuer Anwendungsteil bringt neue Daten ins System, deren Schutzbedarf zu bestimmen ist.
• Größeres Refactoring: Nach einer Umstrukturierung muss verifiziert werden, ob der Code noch dieselben Sicherheitseigenschaften hat. Es könnten neue Fehler hineingekommen sein.
• Bekannt gewordene Vorfälle: Wenn in der Presse oder in Blogs ein Angriff auftaucht, lohnt sich eine Viertelstunde im Team mit der Frage: Hätte das bei uns auch funktioniert?
• Neue Technologie: KI-Bestandteile bringen neue Angriffsarten wie Prompt Injection oder das Ausbrechen von Agenten aus ihrer Sandbox.

Die OWASP Top 10 bilden die klassische Webapplikationswelt ab. Sie sind übrigens kein Sicherheitskatalog, sondern ein Awareness-Dokument zum Kommunizieren der wichtigen Themen. Für KI-Angriffe gibt es inzwischen eine eigene AI Top 10, die diese neuen Szenarien berücksichtigt.

Sicherheit braucht ein Mindset im Team, keinen zentralen Experten

Einen Security-Experten pro 200 Mitarbeiter zu installieren, der bestimmt, wo es langgeht, bringt wenig. Security ist ein Mindset, das in den Teams selbst entstehen muss.

In vielen Teams gibt es Leute mit Interesse am Thema. Die lassen sich fördern, sodass sie zu Fürsprechern werden: Menschen, die beim Refinement die Hand heben und sagen, dass auch über Security geredet werden sollte und nicht nur über den Speicherplatz in der Datenbank. So entsteht ein Brückenkopf ins Team, auch ohne ausgewiesenen Experten.

Threat Modeling als Kartenspiel

Threat Modeling lässt sich auch mit einem Team angehen, das wenig Security-Erfahrung hat. Eine Methode dafür sind Kartenspiele, die echte Spielregeln nutzen.

Das bekannteste Beispiel ist Elevation of Privilege von Adam Shostack, entstanden im Security-Team bei Microsoft. Es steht unter Creative-Commons-Lizenz und wurde mehrfach adaptiert. OWASP hat mit Cornucopia eine eigene Variante, für Cloud-Szenarien gibt es Cumulus.

Die Spiele funktionieren ähnlich wie Stich-Kartenspiele mit Trumpffarbe. Du bekommst den Punkt, wenn du erklären kannst, dass das Angriffsszenario auf deiner Karte für dein System relevant ist. Jemand schreibt mit, und die gesammelten Punkte sind am Ende die potenziellen Angriffsszenarien.

Das ist ein sehr niederschwelliges Angebot, um über Bedrohungsszenarien zu sprechen und Threat Modeling zu machen, während man Freitagnachmittags zwei Stunden Karten spielt.

Markus Geiger

Es gibt Online-Versionen, was für Remote- und Hybrid-Teams praktisch ist. Auch Tester können hier mitspielen und ihren Blick einbringen.

Wie sieht die reale Bedrohungslage aus?

Angriffe finden permanent statt. Wer aufmerksam in die Logs schaut, sieht praktisch jede Stunde irgendeinen Angriffsversuch. Dass dabei ständig überall Daten abgezogen werden, stimmt aber nicht, auch weil Standard-Frameworks vieles von Haus aus nicht schlecht absichern.

Das Bild vom einzelnen Hacker im Hoodie führt in die Irre. Die große Masse sind opportunistisch arbeitende IT-Firmen, die massenweise Systeme abscannen, um zu sehen, ob sich damit Geld verdienen lässt. Eine gefundene Lücke wird teils gar nicht selbst ausgenutzt, sondern nur dokumentiert und weiterverkauft, an jemanden, der dann Ransomware installiert. Dieser Markt mit Milliardenumsätzen erzeugt das ständige Grundrauschen.

Bei kritischer Infrastruktur wie einem großen Energieversorger oder einem Flughafen sieht die Lage anders aus. Hier können staatlich finanzierte Hackergruppen ein Motiv haben, die Infrastruktur zu kompromittieren. Genau diese Frage gehört ins Threat Modeling: Wie groß ist der Anreiz, dich anzugreifen? Beim kleinen Handwerksbetrieb geht es um ein paar hundert Dollar Lösegeld für eine verschlüsselte Festplatte. Beim Flughafen um etwas ganz anderes.

Was der Cyber Resilience Act fordert

Der Cyber Resilience Act will erzwingen, dass Hersteller sich frühzeitig Gedanken über Sicherheit machen. In der breiten Masse kommt das bislang nur langsam an. Die erste Stufe gilt ab dem kommenden Herbst, die endgültige Ausbaustufe folgt etwas später.

Der Gesetzestext selbst ist schwer zu lesen. Praxisnäher ist die technische Richtlinie des BSI zum Cyber Resilience Act, mit Beispielen und einer Anleitung, wie sich die Erfüllung testen lässt. Inhaltlich ist vieles davon Common Sense.

Einige Vorgaben bedeuten Aufwand: Hersteller müssen proaktiv über Sicherheitslücken informieren, Patches bereitstellen und bei Massenprodukten eine automatische Update-Möglichkeit anbieten, die sich kundenseitig abschalten lässt.

Aus Verbrauchersicht ist genau das gewünscht. Niemand will Billighardware mit einem fünf Jahre alten Embedded Linux, die nach dem Kauf nie wieder Updates bekommt. Bei viel Consumer-Hardware ist genau das heute der Stand.