ISO 27001 in der Verteidigungssoftwareentwicklung: Was es in der Praxis bedeutet

ISO 27001 taucht zunehmend als verbindliche Anforderung in Ausschreibungsrahmen für Verteidigungssoftware in ganz Europa auf. Was früher ein gewünschtes Differenzierungsmerkmal war, ist zur Mindestanforderung geworden: Anbieter ohne aktuelle ISO 27001:2022-Zertifizierung werden aus Vergabelisten ausgeschlossen, bevor die technische Bewertung beginnt. Zu verstehen, was der Standard tatsächlich verlangt — nicht nur, wie das Zertifikat aussieht — ist sowohl für Anbieter, die eine Zertifizierung anstreben, als auch für Beschaffungsbeauftragte, die Angebote bewerten, unerlässlich.

Dieser Artikel untersucht, was ISO 27001:2022 im Kontext von Softwareentwicklungsorganisationen fordert, welche wesentlichen Änderungen die Revision 2022 eingeführt hat und was die Zertifizierung praktisch für Entwicklungsprozesse, Teamzusammensetzung und Projektdurchführung bedeutet.

Was ISO 27001:2022 ist — und was sich geändert hat

ISO 27001 ist eine internationale Norm, die Anforderungen an ein Informationssicherheits-Managementsystem (ISMS) festlegt. Anders als technische Sicherheitsstandards, die spezifische Kontrollen vorschreiben, verlangt ISO 27001 von Organisationen, Informationssicherheitsrisiken zu identifizieren, geeignete Kontrollen zu implementieren und einen kontinuierlichen Verbesserungszyklus zu betreiben.

Die Revision 2022 ersetzte ISO 27001:2013 und führte wesentliche Änderungen an Anhang A ein, der den Referenz-Kontrollsatz enthält. Die Version 2013 hatte 114 Kontrollen in 14 Domänen. Die Version 2022 restrukturierte diese zu 93 Kontrollen in 4 Themen: organisatorische, personenbezogene, physische und technologische Kontrollen. Zusätzlich wurden 11 neue Kontrollen eingeführt, die für Softwareentwicklungsorganisationen besonders relevant sind:

• Bedrohungsintelligenz (5.7) — Organisationen müssen Informationen über relevante Bedrohungen sammeln und analysieren
• Informationssicherheit bei der Nutzung von Cloud-Diensten (5.23) — explizite Anforderungen an die Governance der Cloud-Nutzung
• IKT-Bereitschaft für Geschäftskontinuität (5.30) — Kontinuitätsplanung muss IKT-Abhängigkeiten berücksichtigen
• Web-Filterung (8.23) — Kontrollen darüber, auf welche Internetressourcen Systeme zugreifen dürfen
• Sicheres Codieren (8.28) — formale Anforderungen an sichere Entwicklungspraktiken
• Datenmaskierung (8.11) — Anforderungen an die Maskierung sensibler Daten in Nicht-Produktionsumgebungen

Für Anbieter von Verteidigungssoftware ist Kontrolle 8.28 (Sicheres Codieren) besonders bedeutsam. Der Standard 2022 verlangt nun ausdrücklich, dass Organisationen Prinzipien des sicheren Codierens in der Softwareentwicklung anwenden — sichere Entwicklungspraktiken müssen dokumentiert, befolgt und auditiert werden.

Wesentliche Kontrollen im Bereich der Softwareentwicklung

ISO 27001 schreibt keine spezifischen Technologien oder Entwicklungsmethodologien vor. Es verlangt einen strukturierten Ansatz zur Identifizierung und Verwaltung von Informationssicherheitsrisiken im gesamten Softwareentwicklungslebenszyklus. In der Praxis bedeutet dies mehrere Anforderungskategorien, die den Betrieb einer Softwareentwicklungsorganisation beeinflussen.

Zugangskontrolle (8.2–8.5). Der Standard verlangt, dass der Zugang zu Systemen, Code-Repositories und Deployment-Infrastruktur nach dem Prinzip der geringsten Berechtigung verwaltet wird. Für die Verteidigungssoftwareentwicklung bedeutet dies, dass Entwickler keinen Produktionszugang haben sollten, Code-Reviews Merges in geschützte Branches kontrollieren müssen und privilegierter Zugang zu Deployment-Systemen zeitlich begrenzt und protokolliert sein muss.

Kryptografie (8.24). Organisationen müssen eine Richtlinie für kryptografische Kontrollen haben: welche Algorithmen genehmigt sind, wie Schlüssel verwaltet werden und wer für kryptografische Entscheidungen verantwortlich ist. Für Verteidigungssoftware bedeutet dies typischerweise die Ausrichtung an nationalen kryptografischen Standards — etwa BSI-genehmigten Algorithmen in Deutschland.

Sicherer Entwicklungslebenszyklus (8.25–8.31). Der Standard verlangt die Integration von Sicherheit im gesamten Entwicklungsprozess: Sicherheitsanforderungen müssen in der Entwurfsphase festgelegt werden, Sicherheitstests müssen vor der Freigabe durchgeführt werden und Abhängigkeiten müssen auf Schwachstellen bewertet werden. Dies erfordert direkt Praktiken wie Bedrohungsmodellierung, statische Analyse, Schwachstellen-Scanning von Abhängigkeiten und Penetrationstests.

Incident Management (5.24–5.28). Organisationen müssen dokumentierte Verfahren zur Erkennung, Meldung und Reaktion auf Sicherheitsvorfälle haben. Für Softwareentwicklungsumgebungen bedeutet dies die Überwachung von anomalem Zugriff auf Code-Repositories und nicht autorisierten Änderungen an Deployment-Konfigurationen.

Was sich in den Entwicklungsprozessen wirklich ändert

Organisationen, die erstmals eine ISO 27001-Zertifizierung anstreben, stellen typischerweise fest, dass der Einfluss des Standards auf ihre Entwicklungsprozesse substanzieller ist als erwartet. Folgende Änderungen sind konsistent erforderlich und werden konsistent unterschätzt.

Die Risikobewertung wird zum dokumentierten Artefakt. ISO 27001 verlangt, dass Informationssicherheitsrisiken identifiziert, bewertet und nachverfolgt werden. Für die Softwareentwicklung bedeutet dies die Führung eines Risikoregisters, das Entwicklungsumgebungsrisiken, Lieferkettenrisiken und Betriebsrisiken abdeckt. Das Risikoregister ist kein einmaliges Dokument — es muss in definierten Abständen überprüft und aktualisiert werden.

SDLC-Gates werden zu obligatorischen Prüfpunkten. Sicherheitsanforderungen müssen zu Beginn jedes Entwicklungszyklus erfasst werden. Sicherheitstests müssen vor der Freigabe der Software durchgeführt werden. Auditoren werden nach Sicherheitstestergebnissen fragen, nicht nach Zusicherungen, dass Tests durchgeführt wurden.

Lieferanten- und Abhängigkeitsmanagement erfordert formelle Behandlung. Der Standard verlangt, dass Informationssicherheitsanforderungen an Lieferanten kommuniziert werden und Lieferantenbeziehungen überwacht werden. Für die Softwareentwicklung umfasst dies Open-Source-Bibliotheken und Drittanbieterkomponenten.

Personalsicherheitsanforderungen beeinflussen Einstellung und Onboarding. ISO 27001 verlangt Hintergrundüberprüfungen für Personal, dessen Rollen den Zugang zu sensiblen Informationsbeständen umfassen. Für Anbieter von Verteidigungssoftware muss dies möglicherweise mit nationalen Sicherheitsanforderungen übereinstimmen.

Warum Beschaffungsbeauftragte ISO 27001 fordern

Aus der Perspektive eines Beschaffungsbeauftragten für Verteidigung erfüllt die ISO 27001-Zertifizierung mehrere Funktionen, die über die Sicherheitskontrollen selbst hinausgehen.

Erstens bietet sie eine unabhängige Verifikation. Das Zertifikat wird von einer akkreditierten Drittpartei nach einer Prüfung des ISMS der Organisation ausgestellt. Anders als selbst bewertete Compliance-Frameworks verlangt ISO 27001, dass ein qualifizierter Auditor Nachweise über die Implementierung von Kontrollen prüft. Überwachungsaudits finden jährlich statt; Rezertifizierungsaudits alle drei Jahre.

Zweitens schafft sie Rechenschaftspflicht. Die ISO 27001-Zertifizierung verlangt, dass die oberste Führungsebene sichtbar zum ISMS verpflichtet ist. Dies bedeutet, dass die Organisation nicht glaubhaft behaupten kann, dass Sicherheitsversagen isolierte Vorfälle ohne Managementbezug waren.

Drittens vereinfacht sie die Due-Diligence-Prüfung. Anstatt jedes potenzielle Unternehmen einer detaillierten Sicherheitsbewertung zu unterziehen, können Beschaffungsrahmen, die ISO 27001 erfordern, das Zertifikat als Basisfilter verwenden. Anbieter sollten auch wissen, dass Zertifikate, die auf den Standard von 2013 verweisen, nach Oktober 2025 für Beschaffungszwecke als abgelaufen gelten.