Open Source Security Management und Compliance: Die ISO 18974 erklärt (2/2)

Im ersten Teil dieses Artikels haben wir die grundlegenden Elemente eines strukturierten Open Source Security Management (OSSM) auf Basis der ISO 18974 betrachtet. Diese Norm bietet eine gute Orientierungshilfe für Unternehmen, die Open Source Software (OSS) sicher und regelkonform nutzen wollen. Mit der Festlegung von Richtlinien, der Sicherstellung der notwendigen Kompetenzen der Mitarbeiter und der klaren Definition des Anwendungsbereichs konzentriert sich dieser erste Artikel auf die organisatorische Basis eines erfolgreichen OSSM.

Im zweiten Teil widmen wir uns nun den prozessualen und technischen Anforderungen der ISO 18974. Diese umfassen unter anderem die effektive Bearbeitung von Sicherheitsanfragen durch Dritte sowie die Verwaltung der Open Source Software-Komponenten mittels einer Software-Bill of Materials (SBOM). Darüber hinaus vertiefen wir die Prozesse zur Erkennung und Behebung bekannter Sicherheitslücken sowie die fortlaufende Sicherheitsüberwachung, die entscheidend ist, um neue Bedrohungen in einer dynamischen Softwarelandschaft zu erkennen und zu mitigieren.

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

Der Umgang mit Sicherheitsanfragen

Die 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. Unternehmen sollen laut ISO 18974 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 im Falle neu entdeckter Sicherheitslücken direkt einen Responsible Disclosure Prozess erfolgen. Ein prominentes Beispiel dafür ist die Log4Shell Sicherheitslücke. Nachdem diese Ende 2021 öffentlich bekannt wurde, mussten viele Unternehmen umgehend auf Anfragen ihrer Kunden zur Sicherheit ihrer Software oder Dienstleistungen reagieren. 

Praktische Umsetzung

Zur Umsetzung dieser Anforderung empfiehlt die ISO 18974, eine leicht öffentlich auffindbare Methode zur Übermittlung von Berichten zu Sicherheitslücken bereitzustellen. Dies könnte beispielsweise über ein Webformular geschehen, das direkt auf der Unternehmenswebsite verlinkt ist. Darüber hinaus 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 Orientierung für eine solche Implementierung ist die „Security.txt”-Datei, die viele Unternehmen auf ihren Websites bereitstellen, um Sicherheitsforschern den Kontakt zu erleichtern. Diese Datei enthält Kontaktinformationen für Hinweise zu von Dritten gefundenen Sicherheitslücken (Responsible Disclosure) und ist über einen standardisierten Weg schnell auffindbar. Ein Beispiel einer solchen Security.txt sehen sie in Abbildung 1.

Abbildung 1: Beispiel einer Security.txt nach RFC9116
Quelle: L3montree Cybersecurity

Die Implementierung dieser wird zwar nicht durch die ISO 19874 verlangt, ist aber eine dringende Empfehlung meinerseits. Der Aufwand ist gering und der mögliche Mehrwert groß, da Hinweise auf Sicherheitslücken immer nett gemeint und langfristig kostengünstig sind. Cyberkriminelle würden diese Ihnen garantiert nicht mitteilen. Sehen Sie also bitte davon ab, White-Hat Hacker und Sicherheitsforscher zu verklagen.

Überprüfung und Freigabe von Open-Source-Softwarekomponenten

Software Bill of Materials (SBOM)

Die Software Bill of Materials (SBOM) ist ein entscheidendes Instrument, um die Transparenz der verwendeten Komponenten in einer Software sicherzustellen. Die ISO 18974 fordert, dass Unternehmen einen Prozess implementieren, der die Erstellung und Pflege einer solchen SBOM sicherstellt. Diese Liste enthält alle Software-Komponenten und u.a. deren Versionsnummern, die in der gelieferten Software verwendet werden (siehe Abbildung 2).

Abbildung 2: Ausschnitt einer SBOM im CycloneDX Format. Deutlich zu erkennen ist das Softwareprodukt, auf die sich diese SBOM bezieht, sowie eine enthaltene Komponente und deren Versionsnummer.
Quelle: L3montree Cybersecurity

Die sicherheitskritische Bedeutung einer SBOM liegt darin, dass sie es Unternehmen ermöglicht, jederzeit einen Überblick über die im Betrieb eingesetzten Software-Komponenten zu behalten. Dies ist besonders wichtig, wenn es darum geht, Sicherheitslücken zu erkennen, die in einer Abhängigkeit dieser Komponenten auftauchen. Wir bleiben beim Beispiel Log4Shell: Da die Sicherheitslücke nur in älteren Versionen enthalten war, musste hier schnell festgestellt werden, ob die in der eigenen oder eingekauften Software genutzte Version vulnerabel war. Dies sorgte in einigen IT-Abteilungen für viel Mehrarbeit, da Unkenntnis darüber herrschte, welche Softwarekomponenten in der Software und den Systemen verbaut worden waren. Das Ergebnis: Überlastete IT-Abteilungen und unzufriedene Kunden. Mit einer gut gepflegten, aktuellen SBOM wäre eine solche Frage schnell beantwortet gewesen.

Praktische Umsetzung

Um eine SBOM effektiv zu erstellen und zu pflegen, sollten Unternehmen folgende Schritte befolgen:

1. Dokumentation des Prozesses: Unternehmen müssen sicherstellen, dass der gesamte Prozess der SBOM-Erstellung und -Pflege dokumentiert ist. Dies umfasst eine klare Prozedur, die 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.

2. Archivierung der SBOM: Die SBOM sollte nicht nur erstellt, sondern auch archiviert werden, um sicherzustellen, dass jederzeit auf historische Daten zugegriffen werden kann. Dies hilft Unternehmen, Rückverfolgbarkeit zu gewährleisten und in der Lage zu sein, auch nachträglich festzustellen, welche Komponenten in einer älteren Softwareversion verwendet wurden.

3. Lebenszyklusmanagement: Die SBOM muss kontinuierlich aktualisiert werden, insbesondere wenn neue Versionen der Software veröffentlicht oder neue Software-Komponenten hinzugefügt werden. Dies 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: Bei eingekaufter Software sollte ebenfalls eine SBOM angefordert werden. Diese sollte in einem internen Asset-Management eingepflegt werden. So lassen sich die eingesetzten 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 zu reagieren.

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. Dies bedeutet, dass eine Methode zur Erkennung bekannter Sicherheitslücken implementiert werden muss, sowie ein Risikobewertungssystem, um diese Sicherheitslücken 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. 

Praktische Umsetzung

Um den Anforderungen der ISO 18974 gerecht zu werden, sollten Unternehmen folgende Schritte umsetzen:

1. Erkennung bekannter Sicherheitslücken: Vulnerability-Scanner können, wie im ersten Artikel beschrieben (Stichwort OWASP DevSecOps Pipeline), automatisiert in den Entwicklungsprozess integriert werden, um bekannte Sicherheitslücken in Software-Komponenten 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. Zugriff auf den Quellcode ist nicht immer zwingend erforderlich.

2. Risikobewertung und Priorisierung: Da eine Sicherheitslücke ein reales Risiko darstellt, sollte für jede identifizierte Sicherheitslücke ein Risiko- oder Impact-Score festgelegt werden, beispielsweise basierend auf dem CVSS (Common Vulnerability Scoring System). Sicherheitslücken mit einem hohen CVSS-Score auf kritischen Komponenten sollten vorrangig behoben werden. Dies hilft Unternehmen, ihre Ressourcen auf die kritischsten Probleme zu konzentrieren. Solche CVSS-Werte lassen sich durch Hinzugabe von Sicherheitsanforderungen und derzeitiger Bedrohungslage verfeinern (CVSS-BE, CVSS-BTE). Dies ist durchaus zu empfehlen, um Schwachstellen realistisch zu priorisieren.

3. 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 diese erfordern (z. B. bei wesentlichen Änderungen der Software).

4. Ü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 DependenyTrack und DevGuard (Open Source) ermöglichen es, neue Sicherheitslücken automatisch zu erkennen und zu melden.

5. Kommunikation mit Kunden: Sobald eine Sicherheitslücke 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. Dies kann über Sicherheitsmitteilungen oder spezielle Plattformen wie den angedachten Vulnerability Exploitability Exchange (VEX) den die CISA 2022 vorgestellt hat erfolgen, die es ermöglichen, maschinenlesbare Informationen über Sicherheitslücken zu teilen.

Das klingt schon sehr nach Verfahren, die aus bekannten Risikomanagementsystemen, wie zum Beispiel aus dem ISMS nach der ISO 27001 bekannt sind. Sollten Sie bereits ein Risikomanagementsystem in Betrieb haben, empfiehlt es sich, die Verfahren so weit wie möglich anzugleichen oder gar zu integrieren, da es sich bei Sicherheitslücken in der produktiven Software um reale Risiken für Ihr Unternehmen handelt.So können Sie sich nicht nur unnötigen doppelten Verwaltungsaufwand sparen, sondern auch elegant und ganzheitlich die Einhaltung regulatorischer Anforderungen gewährleisten. 

Eine ISO 18974 Zertifizierung

Vollständigkeit

Um die Konformität mit der ISO 18974 sicherzustellen, müssen Unternehmen nachweisen, dass ihr OSSM alle Anforderungen der Spezifikation erfüllt. Hierzu ist natürlich die ausreichende Dokumentation der in der ISO 18974 geforderten Prozesse notwendig. So können Unternehmen gegenüber Dritten wie etwa Kunden, Auditoren oder Behörden schriftlich nachweisen, dass sie sämtliche 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, um die Sicherheit der eingesetzten Open-Source-Komponenten zu gewährleisten. Diese Dokumentation sollte jede Aktivität und jeden Prozess, der Teil des OSSM ist, umfassen und ganz wichtig: 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. Dies kann durch interne Audits geschehen, die sicherstellen, dass keine veralteten Prozesse bestehen und neue Anforderungen oder Sicherheitsrisiken berücksichtigt werden.

Zertifizierung

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 Anpassung seines Programms arbeitet. Nur durch diese regelmäßige Aktualisierung können Sie sicherstellen, dass Ihr OSSM auf dem neuesten Stand der Technik ist. So kann die kontinuierliche Sicherheitsüberwachung der Softwarekomponenten Ihnen und Ihren Kunden tatsächlich ein Höchstmaß an Sicherheit bieten und Compliance-Vorgaben im Bereich der Softwareentwicklung stetig eingehalten werden.

Praktische Umsetzung

Um die Anforderungen der Zertifizierungsdauer und die laufende Konformität zu gewährleisten, sollten Unternehmen folgende Schritte befolgen:

1. Zeitplan für Rezertifizierung: Unternehmen sollten einen festen Zeitplan zur Überprüfung und Rezertifizierung ihres Open Source Security Management Programms erstellen. Dies stellt sicher, dass alle 18 Monate ein Konformitätsnachweis erbracht wird und der Prozess nicht vernachlässigt wird.

2. Kontinuierliche Verbesserung: Integrieren Sie, wenn nicht bereits durch andere Managementsysteme vorhanden, einen Prozess zur kontinuierlichen Verbesserung im Sicherheitsmanagement. Dieser Prozess 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-Management. Unternehmen, die diese Anforderungen umsetzen, sind besser in der Lage, Risiken zu minimieren, regulatorische Vorgaben einzuhalten und das Vertrauen ihrer Kunden zu stärken.

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