Security-Anforderungen im Team entwickeln

Generische Security-Anforderungen wie “das System muss sicher sein” helfen beim Software Testing exakt null weiter. Stattdessen braucht es konkrete Schutzziele: Welche Daten müssen vertraulich bleiben? Was darf auf keinen Fall verändert werden? Und was kostet es wirklich, wenn das System eine Stunde ausfällt? Wer diese Fragen früh klärt und Bedrohungen spielerisch modelliert, spart sich teure Pentests und kann Security endlich testbar machen.

Podcast Episode: Security-Anforderungen im Team entwickeln

Diesmal spreche ich mit Markus Geiger über ein Problem, das viele Tester kennen: Security Requirements sind oft so abstrakt formuliert, dass man damit beim Testen wenig anfangen kann. Markus zeigt, wie man über konkrete Schutzziele wie Vertraulichkeit, Integrität und Verfügbarkeit spricht – und warum Teams ohne Security-Experten mit einfachen Methoden wie Threat-Modeling-Kartenspielen selbst herausfinden können, wo ihre Schwachstellen liegen.

„Wir reden nicht nur über Sicherheit, wir reden über Schutzziele.” - Markus Geiger

Markus Geieger ist Projektleiter, Trainer und Architekt bei der WPS - Workplace Solutions. Markus hat Nachrichtentechnik in Esslingen am Neckar und Distributed Computing Systems Engineering an der Brunel University in London studiert und hat mehr als 25 Jahre Erfahrung als Softwareentwickler, Softwarearchitekt und Coach in vielen Projekten im Umfeld von Industrie, Logistik und Handel. Neben der Software-Architektur gilt sein besonderes Interesse der IT-Security und dem Secure Development Lifecycle.

Highlights der Episode

• Security-Anforderungen nach CIA-Modell formulieren: Confidentiality, Integrity, Availability – nicht abstrakt über „Sicherheit” reden.
• Pentests sind nur Verifikation am teuersten Punkt – Security-Anforderungen müssen vorher klar sein.
• Threat-Modeling-Kartenspiele wie Elevation of Privilege machen Security-Diskussionen im Team niederschwellig und spielerisch.
• Jede Stunde finden Angriffsversuche statt – meist opportunistisch, nicht gezielt durch Hacker-Elite.
• Cyber Resilience Act fordert Common Sense: proaktive Kommunikation, Updates, keine verwaiste Billig-Hardware mehr.

Security Requirements in der Softwareentwicklung – Wie Teams Sicherheit testbar machen

Software wird jeden Tag angegriffen. Das ist keine Übertreibung, sondern Alltag, wie Markus Geiger in der Podcast-Folge betont. Doch wie schaffen es Entwicklungsteams, Sicherheit nicht nur als abstrakte Forderung zu verstehen, sondern ganz konkret umzusetzen? Dieser Beitrag beleuchtet, warum Security Requirements schwierig zu greifen sind, wie man das ändern kann und wie Teams mit wenig Vorwissen trotzdem viel bewirken.

Security als Teil von Softwarequalität

Sicherheit ist ein wichtiges Qualitätsmerkmal – und genauso schwer, in konkrete Anforderungen zu fassen, wie viele andere Aspekte der Softwarequalität. Bei Leistung oder Zuverlässigkeit lassen sich typische Szenarien formulieren: „Wie lange darf die Antwort dauern?“ oder „Wie viele Nutzer muss das System gleichzeitig ertragen?“. Für diese Fragen gibt es einfache, nachvollziehbare Metriken.

Im Bereich Security tun sich viele Teams schwerer. Das liegt daran, dass Schutz oft mit allgemeinen Phrasen (“Unser System muss sicher sein”) beschrieben wird. Das hilft aber niemandem und schon gar nicht den Testern. Sie brauchen greifbare Kriterien.

Aus Sicherheits-Zielen Anforderungen machen

Der erste Schritt ist, Security Requirements herunterzubrechen. Dazu hilft das sogenannte CIA-Prinzip:

• Vertraulichkeit (Confidentiality): Wer darf Informationen sehen?

• Integrität (Integrity): Dürfen Daten verändert werden – und wenn ja, von wem?

• Verfügbarkeit (Availability): Wie lange darf das System ausfallen, bevor es kritisch wird?

Solche Zielsetzungen machen es möglich, klare Fragen zu stellen: Was passiert, wenn diese Datei öffentlich wird? Verlieren Kunden Geld, wenn unsere Anwendung für 30 Minuten offline ist? Anhand dieser Fragen entsteht ein greifbarer Gesprächsrahmen – und plötzlich kann man Anforderungen testbar machen.

Schutzobjekte erkennen: Was ist eigentlich schützenswert?

Entscheidend ist, worauf sich Sicherheitsziele beziehen. Jede Anwendung verarbeitet Daten, aber nicht alles ist gleich wichtig. Für manche Elemente ist Integrität wichtiger als Vertraulichkeit. Für andere das Gegenteil.

Markus Geiger schlägt vor, zuerst sogenannte „Security Assets“ zu identifizieren: Das sind die Dinge, die wirklich geschützt werden müssen. Dazu gehören die eigentlichen Daten (z.B. Kundendaten, Zahlungsinformationen), aber auch unterstützende Komponenten wie Server oder Datenbanken.

Wenn Teams wissen, welche Assets sie schützen wollen, können sie Anforderungen viel präziser formulieren – und danach nach geeigneten Maßnahmen suchen.

Kataloge helfen – aber erst im zweiten Schritt

Viele greifen zu Security-Katalogen wie dem ASVS von OWASP. Das sind Listen mit sehr detaillierten Anforderungen aus der Security-Szene. Sie können ein nützliches Werkzeug sein – aber nur dann, wenn vorher bekannt ist, welche Anforderungen und Schutzobjekte für das eigene System wirklich relevant sind.

Was bringt es, ein ganzes Kapitel zu kryptografischer Absicherung umzusetzen, wenn im System gar keine vertraulichen Daten verarbeitet werden? Solche Kataloge sind eher Landkarten mit potenziellen Abzweigungen als ein starrer Plan für jedes Projekt.

Bedrohungsmodelle gemeinsam besprechen

Threat Modeling klingt erst einmal technisch, ist aber oft nichts anderes als eine strukturierte Diskussion: Welche Gefahren drohen unserer Anwendung? Wie könnten Angreifer versuchen, unsere Schutzmaßnahmen zu umgehen? Diese Teamerkenntnisse helfen nicht nur, Schwachstellen früher zu erkennen. Sie schaffen auch ein gemeinsames Security-Bewusstsein.

Dazu braucht es übrigens keine Experten im Kapuzenpulli. Methoden wie Security-Kartenspiele (z. B. „Elevation of Privilege“) erleichtern es allen, mitzumachen. Sie bringen Leichtigkeit ins Team und sind eine einfache Möglichkeit, Bedrohungen gemeinsam zu besprechen und Maßnahmen abzuleiten.

Team-Mindset statt Einzelkämpfertum

Security ist keine Aufgabe für Einzelne. Ein, zwei „Sicherheitsbeauftragte“ können nicht alles abdecken. Viel wirksamer ist es, wenn im Team Interesse für Security geweckt und kleine Schritte etabliert werden: Wer im Refinement öfter auf Sicherheitsaspekte achtet, ermöglicht es, Probleme früh zu erkennen – und nicht erst im teuren Penetrationstest kurz vor dem Release.

Die wichtigsten Schritte: Assets erkennen, Ziele festlegen, gemeinsam diskutieren. Das klingt simpel, ist aber sehr wirkungsvoll und besser als jede Checkliste im Blindflug abzuarbeiten. Wer als Team das Thema anpackt, kann Security Requirements schrittweise testbar und handhabbar machen – und damit Software wirklich besser schützen.