Open-Source-Sicherheit: ISO/IEC 18974:2023 (2)

Hinweis: Dieser Artikel stammt aus der Ausgabe 1/2025 der Zeitschrift IT-SICHERHEIT. Das komplette Heft können Sie hier herunterladen. (Registrierung erforderlich)

Im ersten Teil dieses Artikels haben wir uns mit den grundlegenden Elementen eines strukturierten Open-Source-Security-Managements (OSSM) auf Basis der ISO 18974 beschäftigt. Diese Norm bietet eine gute Orientierungshilfe für Unternehmen, die Open-Source-Software (OSS) sicher und regelkonform einsetzen wollen. Mit der Festlegung von Richtlinien, der Sicherstellung der notwendigen Kompetenzen der Mitarbeiter und der klaren Definition des Geltungsbereichs konzentrierte sich der erste Teil des Artikels auf die organisatorische Basis eines erfolgreichen OSSM (siehe IT-SICHERHEIT 6/2024).

In diesem Teil werden nun die prozessualen und technischen Anforderungen der ISO 18974 beschrieben, die unter anderem die effiziente Bearbeitung von Sicherheitsanfragen Dritter sowie die Verwaltung von Open-Source-Softwarekomponenten mittels einer Software Bill of Materials (SBOM) umfassen. Ebenfalls vertieft werden die Prozesse zur Erkennung und Behebung bekannter Sicherheitslücken sowie die kontinuierliche Sicherheitsüberwachung, die in einer dynamischen Softwarelandschaft entscheidend ist, um neue Bedrohungen zu identifizieren und abzuwehren.

Mit der Implementierung dieser Prozesse schaffen Unternehmen die notwendige Grundlage, um ihre OSS-Komponenten kontinuierlich zu überwachen und schnell auf Sicherheitsrisiken reagieren zu können – und zwar nicht nur während der Entwicklung, sondern auch nach der Veröffentlichung und Inbetriebnahme der Software. Solche Prozesse zur Verbesserung der Sicherheit in der Softwareentwicklung spielen ebenfalls eine Rolle bei der Erfüllung von Compliance-Anforderungen anderer Frameworks wie ISO 27001 oder dem Cyber Resilience Act.

Der Umgang mit Sicherheitsanfragen

Eine schnelle Reaktion auf Sicherheitsanfragen ist entscheidend, um potenzielle Risiken frühzeitig zu identifizieren und zu beheben. Das bedeutet auch, dass auf Sicherheitsanfragen Dritter in Bezug auf bekannte oder neu entdeckte Sicherheitslücken (CVEs) angemessen und schnell reagiert werden muss. Nach ISO 18974 sollen Unternehmen daher eine öffentlich zugängliche Methode bereitstellen, über die Dritte Anfragen zu Sicherheitslücken einreichen können. Dies kann beispielsweise über eine spezielle E-Mail-Adresse, ein Webportal oder bei neu entdeckten Schwachstellen direkt über einen Responsible-Disclosure-Prozess erfolgen.

Ein prominentes Beispiel ist die Log4Shell. Nachdem diese Lücke Ende 2021 öffentlich bekannt wurde, mussten viele Unternehmen umgehend auf Kundenanfragen zur Sicherheit ihrer Software oder Dienste reagieren. Zur Umsetzung dieser Anforderung empfiehlt die ISO 18974, eine leicht auffindbare Möglichkeit zur Übermittlung von Schwachstellenmeldungen bereitzustellen. Das kann etwa ein Webformular sein, das direkt auf der Website des Unternehmens verlinkt ist. Weiterhin sollte das Unternehmen intern dokumentierte Prozesse entwickeln, um eingehende Anfragen effizient zu bearbeiten.

Diese Prozesse sollten Folgendes umfassen:

• Monitoring: regelmäßige Überwachung des Security-Portals oder der E-Mail-Adresse
• Reaktionsprozess: Ein klar definierter Prozess zur Bewertung und Priorisierung von Anfragen. Hierbei sollten Kriterien wie der vermeintliche Schweregrad der Sicherheitslücken und die potenziellen Auswirkungen auf die Software berücksichtigt werden.
• Kommunikation: Eine transparente Kommunikation mit den Absendern der Sicherheitsanfragen, um sicherzustellen, dass diese über den Bearbeitungsstatus ihrer Anfrage informiert sind.

Als Vorbild für eine solche Implementierung kann die Datei „Security.txt” dienen, die viele Unternehmen auf ihren Webseiten zur Verfügung stellen, um Sicherheitsforschern den Kontakt zu erleichtern. Diese Datei enthält Kontaktinformationen für Hinweise auf von Dritten gefundene Sicherheitslücken (Responsible Disclosure) und ist über einen standardisierten Weg schnell auffindbar.

Ein Beispiel einer solchen Security.txt ist in Abbildung 1 dargestellt. Die Implementierung wird von der ISO 19874 zwar nicht gefordert, ist aber eine dringende Empfehlung des Autors. Der Aufwand ist gering, und der mögliche Mehrwert groß, denn Hinweise auf Sicherheitslücken sind meistens nett gemeint und langfristig kostengünstig. Cyberkriminelle würden einem Unternehmen die Lücke auch gar nicht erst mitteilen – man tut also gut daran, White-Hat-Hacker und Sicherheitsforscher nicht zu verklagen.

Software Bill of Materials (SBOM)

Die Software Bill of Materials (SBOM) ist ein wesentliches Instrument, um die Transparenz der in einer Software verwendeten Komponenten zu gewährleisten. Die ISO 18974 fordert, dass Unternehmen einen Prozess implementieren, der die Erstellung und Pflege einer solchen SBOM sicherstellt. Diese Liste enthält alle Softwarekomponenten, einschließlich ihrer Versionsnummern, die in der ausgelieferten Software verwendet werden (siehe Abbildung 2 auf der nächsten Seite).

Die sicherheitskritische Bedeutung einer SBOM liegt darin, dass sie es Unternehmen ermöglicht, jederzeit einen Überblick über die im Betrieb eingesetzten Softwarekomponenten zu behalten. Das ist besonders wichtig, wenn es darum geht, Sicherheitslücken zu erkennen, die in einer Abhängigkeit dieser Komponenten auftreten.

Bleiben wir beim Beispiel Log4Shell: Da die Sicherheitslücke nur in älteren Versionen vorhanden war, musste schnell festgestellt werden, ob die in der eigenen oder der zugekauften Software verwendete Version verwundbar war. Das führte in einigen IT-Abteilungen zu erheblichem Mehraufwand, da nicht bekannt war, welche Softwarekomponenten in der Software und den Systemen verbaut worden waren. Die Folge: überlastete IT-Abteilungen und unzufriedene Kunden. Mit einer gut gepflegten, aktuellen SBOM wäre eine solche Frage schnell beantwortet gewesen.

Die SBOM in der Praxis

Um eine SBOM effektiv zu erstellen und zu pflegen, sollten Unternehmen folgende Schritte durchführen:

• Dokumentation des Prozesses: Unternehmen müssen sicherstellen, dass der gesamte Prozess der SBOM-Erstellung und -Pflege dokumentiert ist. Dazu gehört ein klares Verfahren, das beschreibt, wie jede Komponente in der Software erfasst wird und wie diese Informationen aktualisiert werden. Ein Beispiel wäre die automatische Generierung einer SBOM durch Tools wie Trivy oder Syft, die die Software analysieren und die Ergebnisse in einer strukturierten Liste darstellen.
• Archivierung der SBOM: Die SBOM sollte nicht nur erstellt, sondern auch archiviert werden, um sicherzustellen, dass jederzeit auf historische Daten zugegriffen werden kann. Das hilft Unternehmen dabei, die Rückverfolgbarkeit zu gewährleisten und in der Lage zu sein, nachträglich festzustellen, welche Komponenten in einer älteren Softwareversion verwendet wurden.
• Lebenszyklusmanagement: Die SBOM muss immer auf dem neuesten Stand sein, besonders wenn neue Versionen der Software veröffentlicht oder Softwarekomponenten hinzugefügt werden. Das kann automatisiert werden, indem der SBOM-Prozess in den CI/CD-Workflow integriert wird, sodass bei jedem neuen Build die verwendeten Komponenten erfasst und aktualisiert werden.

Eine gut gepflegte SBOM ist nicht nur ein Werkzeug für die interne Sicherheit, sondern auch ein wichtiger Bestandteil der Kommunikation mit Kunden, um Transparenz und Vertrauen in die Sicherheitspraktiken des Unternehmens zu schaffen. Wichtig: Für gekaufte Software sollte man ebenfalls eine SBOM anfordern. Diese sollte in ein internes Asset-Management eingepflegt werden. So lassen sich die verwendeten Komponenten der eingekauften Software gegen eine Liste aller angreifbaren Komponenten regelmäßig abgleichen, um proaktiv, noch bevor der Hersteller einen darauf aufmerksam macht, auf Sicherheitslücken reagieren zu können.

Sicherheitsüberprüfung und Freigabe von Komponenten

Neben der reinen Auflistung der verwendeten Komponenten fordert die ISO 18974 auch, dass für jede dieser Komponenten Sicherheitsüberprüfungen durchgeführt werden. Das bedeutet, dass eine Methode zur Erkennung bekannter Sicherheitslücken implementiert werden muss, sowie ein Risikobewertungssystem, um diese Schwachstellen zu priorisieren und entsprechende Gegenmaßnahmen festzulegen. Diese Sicherheitsüberprüfung ist entscheidend, um proaktiv auf Sicherheitsrisiken zu reagieren, bevor diese von Cyberkriminellen genutzt werden können. Um den Anforderungen der ISO 18974 gerecht zu werden, sollten Unternehmen folgende Schritte umsetzen:

• Erkennung bekannter Sicherheitslücken: Vulnerability-Scanner können, wie im ersten Teil beschrieben (Stichwort: OWASP DevSecOps Pipeline), automatisiert in den Entwicklungsprozess integriert werden, um bekannte Sicherheitslücken in Softwarekomponenten zu identifizieren. Diese Tools prüfen regelmäßig die verwendeten Bibliotheken gegen CVE-Datenbanken wie die National Vulnerability Database (NVD). Häufig reicht für einen solchen Abgleich die SBOM der Software. Der Zugriff auf den Quellcode ist nicht immer zwingend erforderlich.
• Risikobewertung und Priorisierung: Da eine Sicherheitslücke ein reales Risiko darstellt, sollte für jede identifizierte Schwachstelle ein Risiko- oder Impact-Score festgelegt werden, beispielsweise basierend auf dem Common-Vulnerability-Scoring-System (CVSS). Sicherheitslücken mit einem hohen CVSS-Score auf kritischen Komponenten sollten vorrangig behoben werden. Das hilft Unternehmen, ihre Ressourcen auf die wichtigsten Probleme zu konzentrieren. Solche CVSS-Werte lassen sich durch Hinzugabe von Sicherheitsanforderungen und derzeitiger Bedrohungslage verfeinern (CVSS-BE, CVSS-BTE), was zu empfehlen ist, um Schwachstellen realistisch zu priorisieren.
• Dokumentation und Maßnahmen: Es sollte ein dokumentierter Prozess existieren, der beschreibt, wie das Unternehmen auf gefundene Sicherheitslücken reagiert. Dieser Prozess umfasst die Ermittlung und Umsetzung von Abhilfemaßnahmen, die entweder eine direkte Behebung der Sicherheitslücke oder alternative Maßnahmen wie das Umgehen des betroffenen Codes vorsehen. Zusätzlich sollte die Zustimmung des Kunden eingeholt werden, falls die Abhilfemaßnahmen dies erfordern, zum Beispiel bei wesentlichen Änderungen der Software.
• Überwachung nach der Freigabe: Die Überprüfung der verwendeten Open-Source-Komponenten endet nicht mit der Auslieferung der Software. Unternehmen müssen in der Lage sein, die Software auch nach der Freigabe auf neue Sicherheitslücken zu überwachen und entsprechend zu reagieren. Tools zur kontinuierlichen Überwachung der Software wie Dependency-Track und DevGuard (Open Source) ermöglichen es, neue Sicherheitslücken automatisch zu erkennen und zu melden.
• Kommunikation mit Kunden: Sobald eine Schwachstelle identifiziert und bewertet wurde, ist es wichtig, die Kunden zu informieren, wenn ein Risiko für deren Systeme besteht. Ebenso sollten, falls notwendig, direkt die Informationen, die zur eigenständigen Behandlung der Sicherheitslücke notwendig sind, kommuniziert werden. Das kann über Sicherheitsmeldungen oder spezielle Plattformen wie den von der CISA 2022 vorgeschlagenen Vulnerability Exploitability Exchange (VEX) erfolgen, der den Austausch von maschinenlesbaren Informationen über Sicherheitslücken ermöglicht.

Dabei handelt es sich um Prozesse und Verfahren, die aus Risikomanagementsystemen wie dem Informationssicherheitsmanagementsystem (ISMS) nach ISO 27001 bekannt sind. Sollten Unternehmen bereits ein solches System in Betrieb haben, empfiehlt es sich, die Verfahren so weit wie möglich anzugleichen oder zu integrieren. Damit lässt sich nicht nur unnötiger doppelter Verwaltungsaufwand sparen, sondern auch elegant und ganzheitlich die Einhaltung regulatorischer Anforderungen gewährleisten.

Die ISO-18974-Zertizierung

Um die Konformität mit der ISO 18974 sicherzustellen, müssen Unternehmen nachweisen, dass ihr OSSM alle Anforderungen der Spezifikation erfüllt. Hierzu ist die ausreichende Dokumentation der in der Norm geforderten Prozesse notwendig. So können Unternehmen gegenüber Dritten wie Kunden, Auditoren oder Behörden schriftlich nachweisen, dass sie alle relevanten Sicherheitsanforderungen erfüllen und das OSSM einen ganzheitlichen Ansatz verfolgt.

Nur durch diese Vollständigkeit kann sichergestellt werden, dass keine kritischen Bereiche vernachlässigt werden und die Sicherheit der eingesetzten Open-Source-Komponenten gewährleistet ist. Diese Dokumentation sollte jede Aktivität und jeden Prozess, der Teil des OSSM ist, umfassen und unbedingt für Dritte nachvollziehbar sein. Wie bei allen dokumentierten Prozessen sollten Unternehmen in festgelegten Zyklen prüfen, ob alle Anforderungen der ISO 18974 weiterhin erfüllt werden. Das kann durch interne Audits geschehen, die sicherstellen, dass keine veralteten Prozesse bestehen und neue Anforderungen oder Sicherheitsrisiken berücksichtigt werden.

Die Konformität eines OSSM, das den Anforderungen der ISO 18974 entspricht, ist wie die meisten Zertifizierungen nicht unbegrenzt gültig. Stattdessen muss das Unternehmen nachweisen, dass sein Programm regelmäßig aktualisiert wird, um den neuesten Standards und Sicherheitsanforderungen zu entsprechen. Eine Zertifizierung nach der OpenChain-Spezifikation, die eine Laufzeit von 18 Monaten hat, stellt sicher, dass das Unternehmen kontinuierlich an der Verbesserung und der Anpassung seines Programms arbeitet.

Nur durch diese regelmäßige Aktualisierung können sie sicherstellen, dass das OSSM auf dem neuesten Stand der Technik ist. So kann durch die kontinuierliche Sicherheitsüberwachung der Softwarekomponenten tatsächlich ein Höchstmaß an Sicherheit für die Organisation selbst und ihre Kunden erreicht werden, und Compliance-Vorgaben im Bereich der Softwareentwicklung können kontinuierlich eingehalten werden.

Praktische Umsetzung

Um die Anforderungen an die Zertifizierungsdauer und die fortwährende Konformität zu gewährleisten, sollten Unternehmen die folgenden Schritte beachten.

1. Zeitplan für Rezertifizierung: Unternehmen sollten einen festen Zeitplan zur Überprüfung und Rezertifizierung ihres Open-Source-Security-Management-Programms erstellen. Das stellt sicher, dass alle 18 Monate ein Konformitätsnachweis erbracht wird und der Prozess nicht vernachlässigt wird.
2. Kontinuierliche Verbesserung: Sofern nicht bereits durch andere Managementsysteme vorhanden, ist ein kontinuierlicher Verbesserungsprozess in das Sicherheitsmanagement zu integrieren. Dieser sollte regelmäßige Sicherheitsüberprüfungen, Feedback-Schleifen und die Implementierung neuer Best Practices umfassen, um sicherzustellen, dass das Programm immer auf dem neuesten Stand ist – Stichwort PDCA-Zyklus.

Fazit

Die ISO 18974 bietet Unternehmen eine umfassende Orientierungshilfe, um Open-Source-Software sicher und regelkonform zu nutzen. Mit einem klar definierten Ansatz, der sowohl organisatorische als auch prozessuale und technische Aspekte umfasst, ermöglicht die Norm eine strukturierte Implementierung eines proaktiven
Open-Source-Security-Managements. Unternehmen, die diese Anforderungen umsetzen, sind besser in der Lage, Risiken zu minimieren, regulatorische Vorgaben zu erfüllen und das Vertrauen ihrer Kunden zu stärken.

Auch wenn Unternehmen keine Zertifizierung anstreben, bietet die ISO 18974 einen praktischen Leitfaden für die sichere Nutzung von Open-Source-Software und unterstützt dabei, Sicherheits- und Compliance-Anforderungen effizient und nachhaltig zu erfüllen.