Von der Blaupause zur Auditbereitschaft: Anforderungen an die Anwendungssicherheit für ISO 27001, DORA und NIS2 sicher beherrschen

Die Nervosität vor dem Audit war greifbar. Für Maria, CISO eines mittelgroßen Fintech-Unternehmens, fühlte sich die bevorstehende DORA-Compliance-Bewertung weniger wie eine Prüfung und mehr wie eine Abrechnung an. Ihr Team war kompetent, ihre IT-Infrastruktur gehärtet, doch eine hartnäckige Schwachstelle raubte ihr den Schlaf: die ausufernde, unübersichtliche Anwendungslandschaft.

Der aktuelle Anlass war ein neues kundenorientiertes Zahlungsportal, das zur Erreichung der Quartalsziele unter hohem Zeitdruck auf den Markt gebracht worden war. Das Entwicklungsteam, das in einem ambitionierten agilen Modell arbeitete, hatte alle funktionalen Anforderungen erfüllt. Als Marias Team jedoch einen ersten Scan durchführte, bestätigten die Ergebnisse ihre Befürchtungen.

Dem Portal fehlten robuste Regeln für Sitzungszeitüberschreitungen, seine Eingabefelder waren anfällig für einfache Injektionsangriffe, und Fehlermeldungen gaben sensible Systeminformationen preis. Das waren keine ausgefeilten Zero-Day-Exploits, sondern grundlegende Designfehler. Die Ursache war schmerzhaft klar: Sicherheitsanforderungen waren nie formal definiert, dokumentiert oder in die Entwicklungssprints integriert worden. Das Team hatte den vagen Auftrag, es „sicher zu machen“. Ohne eine konkrete Blaupause blieb Sicherheit jedoch ein unklarer und häufig ignorierter nachträglicher Aspekt.

Dieses Szenario ist kein Einzelfall. Es verdeutlicht die kritische Lücke, vor der viele CISOs und Compliance-Verantwortliche stehen: die Absicht „wir betreiben Sicherheit“ in explizite, prüfbare Anforderungen an die Anwendungssicherheit zu übersetzen, die mit grundlegenden Standards wie ISO/IEC 27001:2022 und wichtigen Vorschriften wie NIS2, DORA und GDPR übereinstimmen.

Die hohen Kosten der Unschärfe: Was Compliance tatsächlich erwartet

Der Kern von Marias Problem liegt in einem verbreiteten organisatorischen Versäumnis: Sicherheit wird als Qualitätsmerkmal behandelt, nicht als Satz nicht verhandelbarer Anforderungen. Eine wirksame Sicherheitsanforderung ist spezifisch, messbar und prüfbar. „Die Anwendung muss sicher sein“ ist ein Wunsch. „Die Anwendung muss Sitzungen nach 15 Minuten Inaktivität automatisch beenden, alle benutzerseitig bereitgestellten Eingaben gegen einen vordefinierten Zeichensatz validieren und alle Daten bei der Übertragung mit TLS 1.3 verschlüsseln“ ist eine Anforderung. Genau diese Klarheit erwarten Auditoren, und genau diese Klarheit benötigen Entwickler, um sichere Software zu entwickeln.

Fehlt sie, entsteht eine Kaskade von Fehlern:

• Uneinheitliche Umsetzung: Unterschiedliche Entwickler interpretieren „sicher“ unterschiedlich. Das Ergebnis ist ein Flickwerk aus Kontrollen mit unvorhersehbaren Lücken.
• Höhere Abhilfekosten: Einen Designfehler in der Produktion zu finden und zu beheben, ist um ein Vielfaches teurer, als ihn in der Entwurfsphase zu adressieren.
• Audit-Nichtkonformitäten: Auditoren erkennen schnell, wenn ein strukturierter Prozess zur Definition von Sicherheitsanforderungen fehlt; dies führt zu wesentlichen Feststellungen.
• Geschäftsrisiko: Jede nicht definierte Anforderung ist ein potenzieller Angriffsvektor und setzt die Organisation Datenpannen, finanziellen Verlusten und Reputationsschäden aus.

In modernen Standards ist die Erwartung einheitlich: Sicherheit muss frühzeitig als Anforderung definiert und mit Risiken sowie rechtlichen Vorgaben verknüpft werden. Die Leitlinien von ISO/IEC 27002:2022 zu Maßnahme 8.26, Anforderungen an die Anwendungssicherheit, erwarten, dass Organisationen Sicherheitsanforderungen auf Grundlage formaler Risikobeurteilungen und regulatorischer Vorgaben systematisch bestimmen, dokumentieren und genehmigen.

Dieses einzelne Prinzip ist der Dreh- und Angelpunkt für eine Vielzahl von Compliance-Vorgaben. Clarysecs Cross-Compliance-Zuordnung in Zenith Controls: The Cross-Compliance Guide Zenith Controls zeigt, wie dieses Konzept überall wiederkehrt:

• GDPR Artikel 25 und 32 erwarten „Datenschutz durch Technikgestaltung“ und „Sicherheit der Verarbeitung“.
• NIS2 Article 21(2)(d)-(e) betont sichere Entwicklung und Sicherheit der Lieferkette.
• DORA Artikel 6(4), 8, 10 und 11 verlangen Management von IKT-Risiken und Security by Design für Finanzunternehmen.
• NIST SP 800-53 Rev.5 fordert in den Kontrollen SA-4 und SA-15 definierte Systemsicherheitsanforderungen und sichere Entwicklungspraktiken.
• COBIT 2019 verlangt in den Prozessen BAI03 und DSS05, dass sicherheitsbezogene Anforderungen vor dem Bau einer Lösung an Geschäfts- und Compliance-Anforderungen ausgerichtet werden.

Das Ziel besteht darin, in den Worten von Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, „zu definieren, was Sicherheit für Ihre Anwendungen bedeutet, bevor eine einzige Codezeile geschrieben wird.“

Warum traditionelle Ansätze scheitern: Checklisten, späte Tests und Sicherheitstheater

Die meisten Organisationen betreiben bereits irgendeine Form von Anwendungssicherheit. Das Problem ist, dass sie selten so strukturiert ist, dass sie einer Zertifizierung nach ISO/IEC 27001:2022 oder einer regulatorischen Prüfung standhält.

Typische Fehlermuster sind:

1. Generische Checklisten: Teams verwenden für jedes Projekt dieselbe einseitige „Checkliste für sichere Programmierung“. Sie ist nicht an die spezifischen Risiken, die Datensensitivität oder den regulatorischen Kontext der Anwendung gebunden. Wenn ein Auditor fragt, wie die Checkliste auf GDPR Article 25 abgebildet ist, gibt es keine klare Antwort.
2. Sicherheit als spätes Gate: Sicherheitsanforderungen sind nicht in Design oder User Stories eingebettet. Sie erscheinen erst am Ende als Anfrage für einen Penetrationstest. Der Zenith Blueprint warnt: „Sich am Ende des Projekts auf eine Sicherheitscheckliste zu verlassen, funktioniert nicht; diese Anforderungen müssen die Architektur prägen, Bibliotheksentscheidungen beeinflussen und die Priorisierung von Funktionen ab dem ersten Tag steuern.“
3. Keine Nachvollziehbarkeit von der Anforderung bis zum Test: Eine Anforderung wie „Daten bei der Übertragung verschlüsseln“ mag existieren, doch es gibt keinen verknüpften Testfall, der die Durchsetzung der TLS-Version, die Zertifikatsgültigkeit und die Stärke der Chiffren überprüft. Der Zenith Blueprint verlangt, dass Erwartungen messbar und prüfbar sind und Sicherheitstests direkt den zugehörigen Anforderungen zugeordnet werden.
4. Ad-hoc-Umgang mit Drittcode: Moderne Anwendungen werden häufig „aus internem Code, Drittanbieter-Bibliotheken, Programmierschnittstellen und Cloud-native Diensten zusammengesetzt“, wie der Zenith Blueprint feststellt. Ohne explizite Anforderungen an Lieferanten und Open-Source-Komponenten bleibt das Lieferkettenrisiko ein massiver, unkontrollierter blinder Fleck.

Das Ergebnis ist Sicherheitstheater: Dokumente existieren und Tests werden durchgeführt. Wenn jedoch ein ernstzunehmender Auditor oder eine Aufsichtsbehörde eine kohärente Anforderungskette sehen will, bricht der gesamte Prozess auseinander.

Das Fundament schaffen: Von der Richtlinie zur Praxis

Ein disziplinierter Ansatz für Anwendungssicherheit beginnt mit klarer Governance. Eine Richtlinie ist nicht bloße Bürokratie; sie ist die verbindliche Referenz, die Teams handlungsfähig macht und Auditoren eine klare Absichtserklärung liefert. Bei Clarysec entwickeln wir Richtlinien, die sowohl verbindlich als auch praktikabel sind.

Unsere Richtlinie zu Anforderungen an die Anwendungssicherheit Richtlinie zu Anforderungen an die Anwendungssicherheit legt nicht verhandelbare Grundregeln fest. Beispielsweise schreibt Klausel 5.2 unter „Governance-Anforderungen“ vor:

Alle Anwendungen müssen während der Planung oder Beschaffung einer Validierung der Sicherheitsanforderungen unterzogen werden, einschließlich dokumentierter Genehmigung durch das Team für Anwendungssicherheit.

Diese klare Vorgabe verhindert die Mentalität „erst bauen, später absichern“. Die Richtlinie weist außerdem eindeutige Verantwortlichkeiten zu. Klausel 4.3.1 unter „Rollen und Verantwortlichkeiten“ legt fest, dass Entwickler Folgendes erfüllen müssen:

Anwendungen in Übereinstimmung mit definierten Sicherheitsanforderungen und Standards implementieren.

Damit wird die Verantwortung für Sicherheit von einem separaten, häufig als Gegenspieler wahrgenommenen Sicherheitsteam auf die Personen verlagert, die die Software erstellen. Darüber hinaus stellt die Richtlinie den Zusammenhang zwischen verschiedenen Sicherheitsdomänen her. Klausel 10.2 verweist auf die Integration mit weiteren zentralen Kontrollen:

P4 – Richtlinie zur Zugriffskontrolle. Definiert die Standards für Identitäts- und Sitzungsmanagement, die von allen Anwendungen durchgesetzt werden müssen, einschließlich starker Authentifizierung, Prinzip der minimalen Berechtigung und Anforderungen an die Berechtigungsprüfung.

Für kleinere Organisationen stellt eine angepasste Richtlinie wie unsere Richtlinie zu Anforderungen an die Anwendungssicherheit – KMU Richtlinie zu Anforderungen an die Anwendungssicherheit – KMU sicher, dass diese Grundsätze skalierbar bleiben. Sie berücksichtigt, dass die Risiken ähnlich sind, die Umsetzung aber pragmatisch sein muss. Beide Versionen verfolgen letztlich dasselbe Ziel: Anwendungssicherheit ist vollständig in das ISMS integriert und auditbereit.

Eine praktische Roadmap: Auditbereite Anforderungen an die Anwendungssicherheit aufbauen

Die Richtlinie definiert das „Was“ und „Warum“, doch Entwickler und Projektmanager benötigen das „Wie“. Ein strukturierter Umsetzungsleitfaden ist unverzichtbar, um übergeordnete Kontrollen in umsetzbare Schritte zu übersetzen. Schritt 21 des Zenith Blueprint, der sich auf ISO/IEC 27002:2022 Maßnahme 8.26 konzentriert, bietet eine klare Methodik in sechs Schritten.

Gehen wir diesen Prozess anhand von Marias Zahlungsportal durch.

Schritt 1: Mit Risiko und regulatorischem Kontext beginnen

Auf Basis der Ergebnisse der Risikobeurteilung, ausgerichtet an ISO/IEC 27005:2024 (Risikobehandlung), identifizieren Sie zunächst den Kontext:

• Anwendung: Kunden-Self-Service-Zahlungsportal.
• Daten: personenbezogene Daten, Zugangsdaten, Zahlungstoken.
• Jurisdiktionen: EU, Finanzdienstleistungen, Cloud-gehostet.
• Vorschriften: GDPR, DORA, PCI DSS.

Auf Grundlage der Leitlinien zu Maßnahme 8.26 in Zenith Controls und den zugehörigen ISO-Standards (27034-1, 27017, 27701) müssen Ihre initialen Anforderungskategorien Identifizierung und Authentifizierung, Autorisierung, Datenklassifizierung, Eingabevalidierung, Protokollierung sowie Schutz von Daten bei der Übertragung und im Ruhezustand umfassen.

Schritt 2: Eine Vorlage für Sicherheitsanforderungen erstellen oder übernehmen

Der Zenith Blueprint empfiehlt, eine standardisierte Vorlage zu erstellen, damit jedes Projekt dieselben grundlegenden Sicherheitsfragen beantwortet. Dieses Dokument muss Teil Ihres Projekt-Kick-off-Toolkits werden.

Mindestabschnitte sollten enthalten:

• Anwendungsname, Verantwortlicher und Kritikalität.
• Datenkategorien und Sensitivitätsstufen.
• Anwendbare regulatorische und vertragliche Verpflichtungen (GDPR, DORA usw.).
• Eingaben zur Bedrohungslage (abgeleitet aus Maßnahme 5.7 Bedrohungsinformationen).
• Spezifische Sicherheitsanforderungen nach Kategorie (Authentifizierung, Protokollierung usw.).
• Verknüpfungen zu User Stories und Abnahmekriterien.
• Verknüpfungen zu Testfällen (funktional, sicherheitsbezogen, Penetration).
• Anforderungen an Lieferanten und Drittanbieterkomponenten.

Schritt 3: Anforderungen in agile Artefakte einbetten

Sicherheitsanforderungen müssen direkt in User Stories und Abnahmekriterien eingebettet werden. Für das Epic „Kundenregistrierung“ in Marias Portalprojekt bedeutet dies, eine einfache funktionale Story in eine sicherheitsbewusste Story zu überführen.

• Ursprüngliche User Story: „Als neuer Benutzer kann ich ein Konto erstellen.“
• Sichere User Story: „Als neuer Kunde möchte ich ein sicheres Konto erstellen, damit meine Zahlungsinformationen geschützt sind.“
• Abnahmekriterien (mit eingebetteter Sicherheit):
  • Das System muss eine starke Passwortrichtlinie im Einklang mit der P4 – Richtlinie zur Zugriffskontrolle durchsetzen.
  • Das System muss eine E-Mail-Verifizierung über einen Einmal-Link verlangen, bevor das Konto aktiviert wird.
  • Das Formular zur Kontoerstellung muss durch CAPTCHA vor Botangriffen geschützt sein.
  • Alle Registrierungsversuche müssen mit Quell-IP und Geräte-Fingerprint protokolliert werden.
  • Alle über das Formular übermittelten Daten müssen bereinigt werden, um Cross-Site Scripting (XSS) zu verhindern.

Das sind keine separaten Sicherheitsaufgaben; sie sind integraler Bestandteil der Definition of Done der Funktion.

Schritt 4: Anforderungen mit Sicherheitstests verknüpfen

Mithilfe von Maßnahme 8.29 Sicherheitsprüfung aus Zenith Controls stellen Sie sicher, dass jede Anforderung einen zugeordneten Testfall hat. Dadurch wird der Regelkreis geschlossen und auditierbarer Nachweis der Kontrollwirksamkeit bereitgestellt.

• Anforderung: Verschlüsselung bei der Übertragung mit TLS 1.3. → Test: Automatisierter Scan zur Überprüfung der TLS-Durchsetzung, Zertifikatsgültigkeit und genehmigter Cipher Suites.
• Anforderung: Eingabevalidierung zur Verhinderung von SQL-Injection. → Test: Automatisierte SAST-/DAST-Scans und manuelles Fuzzing während der Qualitätssicherung.
• Anforderung: Sitzungszeitüberschreitung nach 15 Minuten Inaktivität. → Test: Automatisierte und manuelle Tests zur Bestätigung der serverseitigen Sitzungsinvalidierung nach 15 Minuten Inaktivität.

Schritt 5: Anforderungen auf die Lieferkette ausweiten

Da ISO-Maßnahme 8.26 in Zenith Controls mit Lieferantensicherheit (5.19, 5.20) und ausgelagerter Entwicklung (8.30) verknüpft ist, muss Ihr Prozess Drittcode berücksichtigen. Für KMU, die stark auf externe Bibliotheken angewiesen sind, ist die Richtlinienklausel aus der Richtlinie zu Anforderungen an die Anwendungssicherheit – KMU entscheidend:

Jedes Drittanbieter-Werkzeug, Plugin oder jede externe Code-Bibliothek, die in einer Anwendung verwendet wird, muss erfasst und jährlich hinsichtlich Sicherheitsauswirkungen und Patch-Status überprüft werden.

Diese einfache, pragmatische Anforderung erzwingt eine Software-Bill-of-Materials-(SBOM)-Denkweise, die unter Vorschriften wie NIS2 eine zentrale Erwartung ist. Bei wesentlichen Lieferanten müssen dieselben Anforderungen an die Anwendungssicherheit in Verträge aufgenommen werden, mit Verweis auf ISO/IEC 27036-1 (Sicherheit der IKT-Lieferkette).

Schritt 6: Regelmäßige Neubewertung etablieren

Wenn Anwendungen sich weiterentwickeln, verändern sich auch ihre Risiken. Die Leitlinien des Zenith Blueprint zur regelmäßigen Neubewertung sind daher entscheidend. Wenn Sie eine neue API integrieren oder zu einem anderen Cloud-Service wechseln, verändert sich der Risikokontext. Dies muss eine Überprüfung der bestehenden Sicherheitsanforderungen auslösen, um sicherzustellen, dass sie weiterhin angemessen sind. Das entspricht ISO/IEC 27005:2024 (laufende Risikobehandlung) und macht Anwendungssicherheit zu einer kontinuierlichen Praxis – nicht zu einem einmaligen Projekt.

Das Kontrollökosystem entschlüsseln

Eine ISO-Maßnahme existiert nie isoliert. Wirksame Sicherheit beruht auf einem vernetzten Geflecht von Maßnahmen. Die eigentliche Wirkung von Maßnahme 8.26 entfaltet sich, wenn Sie ihre Beziehung zu anderen Kontrollen verstehen – eine Perspektive, die in Zenith Controls detailliert dargestellt wird.

Maßnahme 8.26 ist als präventive Kontrolle klassifiziert, wirkt aber als zentrale Drehscheibe für den gesamten sicheren Entwicklungsprozess und verbindet sich mit:

• 8.25 - Secure development life cycle: Dies ist das übergreifende Rahmenwerk. Maßnahme 8.26 liefert das konkrete Was (die Anforderungen), das in das Wie (den SDLC-Prozess) integriert werden muss.
• 8.27 - Secure system architecture and engineering principles: Anforderungen steuern Architekturentscheidungen und stellen sicher, dass Sicherheit grundlegend verankert ist.
• 8.28 - Secure coding: Sobald Anforderungen definiert sind (z. B. „SQL-Injection verhindern“), geben Standards für sichere Programmierung den Entwicklern die Techniken an die Hand, um diese Anforderung zu erfüllen.
• 8.29 - Security testing in development and acceptance: Diese Maßnahme validiert, dass die in 8.26 definierten Anforderungen korrekt umgesetzt wurden.
• 5.34 - Privacy and protection of PII: Wenn eine Anwendung personenbezogene Daten verarbeitet, müssen die Anforderungen aus 8.26 die Grundsätze von Datenschutz durch Technikgestaltung einbeziehen.
• 5.19 & 5.20 - Information security in supplier relationships: Für beschaffte oder ausgelagerte Anwendungen schreibt Maßnahme 8.26 vor, dass Ihre Sicherheitsanforderungen in die Lieferkette hineinreichen müssen.

Wenn Sie diese Kontrollen als Ökosystem und nicht als Checkliste betrachten, können Sie ein mehrschichtiges, belastbares Risikoprofil der Informationssicherheit aufbauen.

Die Perspektive des Auditors: Auf Prüfung vorbereitet sein

Auditoren denken in Nachweisen. Zur Vorbereitung müssen Sie verstehen, welche unterschiedlichen Perspektiven ein Auditor einnehmen kann. Der Abschnitt zur Auditmethodik in Zenith Controls antizipiert diese unterschiedlichen Ansätze.

Das Verständnis dieser Perspektiven ermöglicht Ihnen, ein umfassendes Nachweisportfolio vorzubereiten, das einen lebendigen, in Ihrer Organisation verankerten Prozess belegt.

Der Cross-Compliance-Kompass: Ein Prozess, viele Rahmenwerke

Für ein Unternehmen wie Marias ist die Erfüllung von DORA, GDPR und NIS2 verpflichtend. Kontrollen manuell zuzuordnen, führt zwangsläufig zu Doppelarbeit und Compliance-Lücken. Ein zentralisierter Cross-Compliance-Ansatz bietet erheblichen Mehrwert. Die Definition von Anforderungen an die Anwendungssicherheit ist die praktische Umsetzung des Security-by-Design-Prinzips, das all diesen modernen Vorschriften zugrunde liegt.

Wenn Sie einen belastbaren Prozess für Anforderungen an die Anwendungssicherheit auf Basis von ISO/IEC 27002:2022 implementieren, bauen Sie gleichzeitig Nachweise auf, die einen erheblichen Teil dieser weiteren Vorschriften abdecken. Sie „machen“ nicht nur ISO; Sie bauen ein universell compliancefähiges Sicherheitsprogramm.

Vom Chaos zur Kontrolle: Ihr Weg nach vorn

Marias Geschichte nimmt einen positiven Verlauf. Sie nutzte den Vorfall mit dem Zahlungsportal als Katalysator für Veränderung. Ausgestattet mit einem klaren Richtlinienrahmen von Clarysec und einem praktischen Umsetzungsleitfaden brachte sie Entwicklungs-, Sicherheits- und Produktteams zusammen. Sie nutzten die Methodik des Zenith Blueprint, um rückwirkend Anforderungen für das Portal zu definieren und Abhilfemaßnahmen risikobasiert zu priorisieren.

Noch wichtiger: Sie etablierten eine neue Arbeitsweise. Die „Sicherheitscheckliste“ wurde durch kollaborative Design-Sessions ersetzt. Als die DORA-Auditoren eintrafen, konnte Maria ihnen nicht nur eine sichere Anwendung zeigen, sondern auch einen reifen, wiederholbaren Prozess nachweisen, mit dem sichergestellt wird, dass alle künftigen Anwendungen auf einem Sicherheitsfundament aufgebaut werden.

Die Transformation Ihres Risikoprofils der Informationssicherheit von Anwendungen beginnt mit einem einzigen, strukturierten Schritt. Ihr Weg nach vorn ist klar:

1. Governance etablieren: Implementieren Sie eine formale Richtlinie zur Definition von Anforderungen an die Anwendungssicherheit. Unsere Vorlagen, etwa die Richtlinie zu Anforderungen an die Anwendungssicherheit, bieten einen auditbereiten Ausgangspunkt.
2. Ein praktikables Rahmenwerk übernehmen: Nutzen Sie den Zenith Blueprint, um Sicherheitsanforderungen direkt in Ihren Entwicklungslebenszyklus zu integrieren und sie umsetzbar, prüfbar und nachvollziehbar zu machen.
3. Den vollständigen Kontext verstehen: Verwenden Sie Zenith Controls, um zu erkennen, wie diese kritische Kontrolle mit dem breiteren Sicherheitsökosystem verbunden ist und wie sie auf DORA, NIS2, GDPR und weitere Vorgaben abgebildet wird.
4. Auf Ihr Portfolio skalieren: Sobald der Ansatz für eine Anwendung funktioniert, skalieren Sie ihn auf Ihr gesamtes Portfolio, indem Sie Ihre Vorlage für Sicherheitsanforderungen in Standard-Checklisten für Projekt-Kick-offs, agile Vorlagen und Beschaffungsprozesse integrieren.

Wenn Sie diese Transformation beschleunigen möchten, stellt Clarysec vorgefertigte Richtlinien, Umsetzungs-Roadmaps und Cross-Compliance-Zuordnungen bereit, mit denen Sie von fragmentierten Einzelmaßnahmen zu einem nachweislich reifen und auditbereiten Programm gelangen. Behandeln Sie Anwendungssicherheit nicht länger als finale Gate-Prüfung. Verankern Sie sie in der Blaupause von allem, was Sie entwickeln.