Open-Source-Sicherheit: ISO/IEC 18974:2023 (1)
Neben zahlreichen Vorteilen birgt Open-Source-Software auch erhebliche Sicherheitsrisiken. Die ISO 18974 ermöglicht Unternehmen, diese Herausforderungen strukturiert anzugehen und eine solide Open-Source-Sicherheitsstrategie zu entwickeln. Unser Autor zeigt, wie die Norm hilft, Risiken zu identifizieren und Compliance sicherzustellen, damit Unternehmen langfristig von den Stärken der Open-Source-Welt profitieren können.
Hinweis: Dieser Artikel stammt aus der Ausgabe 6/2024 der Zeitschrift IT-SICHERHEIT. Das komplette Heft können Sie hier herunterladen. (Registrierung erforderlich)
In modernen IT-Systemen und Unternehmenslandschaften spielt Open-Source-Software (OSS) direkt oder indirekt eine zentrale Rolle. Die Nutzung von Open Source und auch deren Entwicklung stellt eine strategische Entscheidung dar, die Unternehmen und deren Management eines Tages treffen müssen. Unternehmen nutzen solche Software zum Beispiel, um Kosten zu senken, indem sie Open-Source-Projekte selbst betreiben und implementieren, oder die Effizienz der Entwicklung durch Wiederverwendung fremder Softwareprojekte steigern.
Code heute noch von der ersten Zeile an komplett selbst zu schreiben, ist ineffizient, nicht mehr zeitgemäß und ergibt nur in seltenen Fällen Sinn, weswegen moderne Software zu einem Großteil (70 bis 90 Prozent) aus anderen Open-Source-Projekten besteht (siehe Abbildung 1). Doch mit dieser Effizienzsteigerung kommen auch Herausforderungen, besonders in den Bereichen Open-Source-Sicherheitsmanagement und der Compliance.
Die XZ Utils Backdoor, die über Ostern 2024 die IT-Community beschäftigte, ist ein anschauliches Beispiel für die großen Sicherheitsrisiken, die die Nutzung von Open Source mit sich bringen kann. Dennoch ist der Verzicht auf Open-Source-Software keine Option, da sie eine zentrale Säule der modernen Softwareentwicklung darstellt. Vielmehr gilt es, sich der Risiken ihres Einsatzes bewusst zu sein, diese im besten Fall strukturiert zu betrachten und Sicherheitsmaßnahmen zu konzipieren. Doch wie kann ein Unternehmen sicherstellen, dass der Einsatz von Open-Source-Software sicher und regelkonform bleibt? Das Zauberwort lautet hier Open-Source-Sicherheitsmanagement und das Beste ist, hierfür gibt es die ISO/IEC 18974:2023 „Information technology – OpenChain security assurance specification“, an der man sich orientieren kann.
Aufau eines soliden Sicherheitsmanagements für OS
Das Hauptziel eines umfassenden Open-Source-Sicherheitsmanagements ist es, die Sicherheitsrisiken bei der Nutzung und Einbindung solcher Software zu minimieren. Gleichzeitig müssen Unternehmen gewährleisten, dass sie alle rechtlichen Anforderungen im Rahmen der Open-Source-Compliance erfüllen. Dabei geht es nicht nur um die Vermeidung von Lizenzverstößen, sondern auch darum, bestehende regulatorische Anforderungen zu betrachten und Sicherheitslücken, die zum Teil durch die Nutzung anderer Open-Source-Projekte nicht einmal selbst verschuldet sind, proaktiv zu schließen sowie Risiken zu managen.
Der erste Teil der ISO 18974 befasst sich mit dem Aufbau eines effektiven Open-Source-Sicherheitsmanagementprogramms und fordert eine klare, gut strukturierte Grundlage, auf der die Kompetenzen, der Scope und die Best Practices festgelegt werden, an denen sich das gesamte Sicherheitsmanagement orientiert.
Richtlinien: Die Grundlage für Sicherheit und Compliance
Was wäre ein Managementsystem ohne Richtlinien? Die ISO 18974 empfiehlt, dass jedes Unternehmen, das Open-Source-Software in seinen IT-Systemen nutzt, eine formell dokumentierte Vorgabe für die Sicherheitsprüfung der Software erstellen sollte. Diese dient als Leitfaden für alle beteiligten Akteure und sorgt dafür, dass ein strukturierter Rahmen für den Umgang mit potenziellen Sicherheitsrisiken vorhanden ist.
Wichtig ist dabei nicht nur die Erstellung der Richtlinie, sondern auch deren regelmäßige Kommunikation innerhalb des Unternehmens. So wird gewährleistet, dass alle relevanten Teilnehmer im Programm auf dem neuesten Stand sind und die Richtlinie verstanden und umgesetzt wird.
Zur Sicherstellung der Aktualität und Relevanz dieser Richtlinie sollten Unternehmen einen Überprüfungsprozess einrichten. So ist gewährleistet, dass Änderungen in der Bedrohungslage oder der Softwareumgebung auch in der Sicherheitsrichtlinie berücksichtigt werden. Es ist entscheidend, dass Unternehmen diese Richtlinie dokumentieren und einen Mechanismus zur Sensibilisierung der Teilnehmer etablieren.
Dies kann durch Schulungen oder regelmäßige Meetings geschehen. Sollte man bereits ein Managementsystem wie ein ISMS nach ISO 27001 in Betrieb haben, ist der beschriebene Prozess der Richtlinienerstellung und Kommunikation sicherlich keine Neuheit und sollte sich aus Effizienzgründen am besten an den bestehenden Richtlinienprozessen orientieren. Wichtig ist, dass man das Open-Source-Sicherheitsmanagement an das eigene Unternehmen anpasst und nicht umgekehrt. Alles andere ist mit hoher Wahrscheinlichkeit zum Scheitern verurteilt.
Kompetenz der Teilnehmer: Die Schlüsselrolle der richtigen Fähigkeiten
Für den Erfolg eines OS-Sicherheitsmanagementprogramms ist die Kompetenz der beteiligten Personen von zentraler Bedeutung. Das Unternehmen muss die notwendigen Rollen und Verantwortlichkeiten identifizieren, die Einfluss auf die Effektivität des Programms haben. Dies schließt nicht nur die technischen Fachkräfte ein, sondern auch die Personen, die die Compliance-Überwachung und das Risikomanagement verantworten.
Es ist unerlässlich, dass diese Teilnehmer über die notwendige Ausbildung, Schulung oder Erfahrung verfügen, um ihre Aufgaben effektiv zu erfüllen. Wo nötig sollten Maßnahmen ergriffen werden, um die Kompetenzen der Teilnehmer weiter zu verbessern. Dazu gehören etwa das Angebot von spezialisierten Weiterbildungen im Bereich Open-Source-Sicherheitsmanagement oder grundlegende Schulungen der Entwickler in der sicheren Softwareentwicklung wie zum Beispiel der DevSecOps-Methodik.
Die Sicherstellung und regelmäßige Überprüfung der Fachkompetenz sollte dokumentiert werden, um Transparenz und Nachvollziehbarkeit über die Kenntnisse der Mitarbeiter zu erlangen und ein effizientes Beheben möglicher Lücken zu gewährleisten. Zudem lassen sich so die richtigen Ansprechpartner bei spezifischen Problemstellungen auch in größeren Organisationen schnell ausfindig machen.
Sensibilisierung und Bewusstsein: Sicherheitskultur stärken
Neben der Kompetenz spielt auch die Sensibilisierung der Programmbeteiligten eine entscheidende Rolle. Es muss sichergestellt werden, dass alle Beteiligten die Richtlinien und Ziele des Open-Source-Sicherheitsmanagements kennen und verstehen. Dazu gehört nicht nur das Verständnis der eigenen Aufgaben, sondern auch das Wissen, wie die eigene Rolle und das eigene Handeln zur Sicherheit des Unternehmens beitragen und welche Konsequenzen es hat, wenn die Anforderungen nicht erfüllt werden.
Dies sollte neben Schulungen auch regelmäßige Überprüfungen und Feedbackschleifen umfassen, um sicherzustellen, dass das Bewusstsein für die Bedeutung von Sicherheit und Compliance stets präsent ist. Ein gut dokumentierter Nachweis dieser Sensibilisierung der Mitarbeiter wird nicht nur von den Auditoren geschätzt, sondern erleichtert zudem das Management, da mögliche Lücken schnell erkannt werden können.
Scope: Anpassung an die Bedürfnisse des Unternehmens
Ein weiteres Schlüsselelement für ein erfolgreiches Open-Source-Sicherheitsmanagement ist die klare Definition des Anwendungsbereichs. Der Umfang des Programms sollte mit den Risikomanagementrichtlinien des Unternehmens übereinstimmen. Das OS-Sicherheitsmanagement kann sich auf eine bestimmte Produktlinie, eine Abteilung oder das gesamte Unternehmen beziehen. Es ist wichtig, dass dieser Umfang klar kommuniziert und regelmäßig überprüft wird, um sicherzustellen, dass er den aktuellen Anforderungen des Unternehmens entspricht.
Zusätzlich sollte das Programm auf messbaren Leistungsindikatoren (Key Performance Indicators, KPIs) wie dem Risikofaktor der betrachteten Anwendungen oder der Zeit, die es braucht, um Sicherheitslücken zu schließen, basieren, die kontinuierliche Anpassung und Verbesserungen ermöglichen. Diese Kennzahlen sollten ebenfalls regelmäßig überprüft werden, um die Effizienz und Wirksamkeit des Programms sicherzustellen. Besteht bereits ein Managementsystem, zum Beispiel ein Informationssicherheitsmanagementsystem (ISMS), empfiehlt es sich, den Anwendungsbereich und die KPIs so weit wie möglich an das bestehende System anzupassen.
Best Practices umsetzen
Ist die organisatorische Grundlage gelegt, wird es erst richtig spannend, denn im Rahmen eines umfassenden Open-Source-Sicherheitsmanagements ist die Implementierung bewährter Standardpraktiken zur Identifizierung und Behebung von Sicherheitslücken in Open-Source-Software auf der technischen Ebene unverzichtbar. Schwachstellen und daraus resultierende Sicherheitslücken in der Software sind ein Einfallstor für Cyberkriminelle und können auch ganz ohne Angreifer die Schutzziele wie die Verfügbarkeit oder die Integrität von Daten negativ beeinflussen.
Eine solide Sicherheitsstrategie stellt sicher, dass Unternehmen, die auf Open-Source-Software setzen, in der Lage sind, bekannte und neu entdeckte Schwachstellen proaktiv zu identifizieren, zu überwachen und darauf zu reagieren.
1. Erkennung struktureller und technischer Bedrohungen:
Eine der ersten umzusetzenden Maßnahmen besteht darin, strukturelle und technische Bedrohungen in der gelieferte Software zu erkennen. Diese Bedrohungen können von Sicherheitslücken im Quellcode hin zu Fehlkonfigurationen der Infrastruktur oder Konzeptionsfehler in der Softwarearchitektur reichen. Die Implementierung eines zuverlässigen Verfahrens zur Bedrohungserkennung ist essenziell, da es als Grundlage für alle weiteren Sicherheitsmaßnahmen dient.
Umsetzungstipp: Unternehmen sollten für selbst geschriebene Software automatisierte Werkzeuge zur statischen Codeanalyse einsetzen. Um potenzielle (bekannte) Schwachstellen in Open-Source-Komponenten frühzeitig zu erkennen, können Software-Composition-Analysis-(SCA)-Scanner benutzt werden. Wenn die Verantwortlichen besonders sichergehen wollen, kann ein Experte den Code in einem Secure-Code-Review manuell untersuchen. Eine strukturierte Bedrohungsanalyse (Threat Modeling), zum Beispiel mit der STRIDE-Methode, hilft, Schwachstellen im Softwaredesign systematisch zu identifizieren, zu bewerten und präventive Maßnahmen zu ergreifen.
2. Identifizierung bekannter Schwachstellen:
Ein effizientes Verfahren zur Erkennung bekannter Schwachstellen ist ein weiterer zentraler Bestandteil eines robusten Sicherheitsprogramms. Hierbei geht es darum, Schwachstellen zu identifizieren, die bereits in der Open-Source-Community bekannt sind. Diese Informationen werden in Datenbanken wie der National Vulnerability Database (NVD) oder über Plattformen wie GitHub bereitgestellt.
Umsetzungstipp: Regelmäßige Abfragen von Schwachstellendatenbanken sowie die Integration von Sicherheitstools können helfen, bekannte Sicherheitslücken in den verwendeten Open-Source-Komponenten schnell zu erkennen. Ein regelmäßiger Abgleich mit diesen Datenbanken sollte automatisiert und kontinuierlich (mehrmals täglich) erfolgen.
3. Nachverfolgung identifizierter Schwachstellen:
Die Nachverfolgung von identifizierten Schwachstellen ist entscheidend, um zu gewährleisten, dass erkannte Sicherheitslücken auch konsequent behoben werden. Nachdem Schwachstellen identifiziert wurden, müssen Unternehmen klare Prozesse für die Risikobewertung und die Priorisierung der Behebung entwickeln. Dies verhindert, dass identifizierte Schwachstellen unbeachtet bleiben und ein erhöhtes Risiko darstellen.
Umsetzungstipp: Unternehmen sollten auf ein Ticketing-System oder auf ein zentrales Schwachstellenmanagement-Tool setzen, um erkannte Schwachstellen zu verfolgen. Es müssen Verantwortlichkeiten festgelegt und sichergestellt werden, dass jede erkannte Schwachstelle mit einem klar definierten Zeitrahmen für die Behebung versehen wird. Einige Regularien wie der PCI-DSS erfordern eine solche Behebung innerhalb bestimmter Zeitfenster.
4. Kommunikation von Schwachstellen:
Wenn relevante Schwachstellen gefunden werden, müssen diese Informationen an die Kunden oder Benutzer weitergegeben werden. Dies ist besonders dann wichtig, wenn Geschäftspartner Sicherheitsmaßnahmen ergreifen müssen, um das Risiko zu minimieren.
Umsetzungstipp: Ein Incident-Response-Verfahren regelt den Kommunikationsprozess mit Kunden. Man sollte sichere Kanäle nutzen, um Schwachstellenmeldungen zu übermitteln, und zudem proaktive Anleitungen zur Risikominimierung anbieten. Sehr zu empfehlen ist auch das Bereitstellen dieser Informationen in einem maschinenlesbaren Format: dem Vulnerability Exploitability Exchange (VeX).
5. Analyse neu entdeckter Schwachstellen nach der Freigabe:
Sicherheitslücken treten oft auch nach der Auslieferung der Software auf, daher ist es wichtig, dass Unternehmen einen Prozess zur Analyse neu entdeckter Schwachstellen nach der Freigabe der Software haben. Die kontinuierliche Überwachung der eingesetzten Open-Source-Komponenten ist entscheidend, um schnell auf neue Sicherheitsrisiken reagieren zu können.
Umsetzungstipp: Der Einsatz von Tools zur kontinuierlichen Überwachung von Open-Source-Komponenten der eigenen Softwarelösungen ist empfehlenswert. Automatisierte Überwachungssysteme oder spezielle Security-Plug-ins können helfen, neu entdeckte Schwachstellen zu erkennen und schnell zu reagieren.
6. Fortlaufende und wiederholte Sicherheitstests vor Freigabe:
Bevor eine Software veröffentlicht wird, müssen fortlaufende und wiederholte Sicherheitstests durchgeführt werden, um sicherzustellen, dass alle identifizierten Risiken adressiert wurden.
Umsetzungstipp: Sicherheitstests sollten automatisiert Teil des „Continuous Integration/Continuous Deployment“-Prozesses sein, um sicherzustellen, dass jede Softwareversion frühzeitig und vor der Veröffentlichung auf Schwachstellen geprüft wird (Stichwort: Shift-Left). Es ist ratsam, die Tests bei jeder neuen Version oder Änderung der Software durchzuführen, um potenzielle Schwachstellen zu identifizieren. Denn je früher Probleme entdeckt werden, umso leichter ist es, diese zu beheben. Die OWASP-DevSecOps-Guideline und deren DevSecOps-Pipeline (siehe Abbildung 2) sind hierbei eine gute Orientierungsmöglichkeit.
7. Bestätigung, dass Risiken vor Freigabe adressiert wurden:
Es ist wichtig, dass alle identifizierten Risiken vor der Freigabe der Software adressiert werden. Dies bedeutet, dass alle erkannten Schwachstellen entweder behoben oder anderweitig eingedämmt wurden, bevor die Software ausgeliefert wird.
Umsetzungstipp: Unternehmen sollten eine Freigaberichtlinie erstellen, die klar definiert, wann eine Software freigegeben wird und wann nicht. Ein Freigabeprozess, der eine Sicherheitsprüfung integriert, hilft dabei, die Qualität und Sicherheit der Software zu gewährleisten.
8. Export von Risikoinformationen an Dritte:
Unter Umständen ist es notwendig, Risikoinformationen, also beispielsweise die identifizierten Sicherheitslücken, an Dritte weiterzugeben, besonders wenn Open-Source-Komponenten in einem größeren Netzwerk verwendet werden oder von anderen Parteien eingebunden wurden. Der Austausch von Sicherheitsinformationen trägt dazu bei, die Sicherheitskultur zu fördern und Risiken in der gesamten Software-Lieferkette zu minimieren.
Umsetzungstipp: Unternehmen können automatisierte Schnittstellen oder Berichterstellungstools nutzen, um relevante Risikoinformationen an Partner oder Kunden zu exportieren. Transparente Kommunikation stärkt das Vertrauen und fördert die gemeinsame Verantwortung in Bezug auf Open-Source-Sicherheit.
Fazit
Der erste Teil der ISO 18974 beschreibt die Grundlagen eines strukturierten Open-Source-Sicherheitsmanagements, die Unternehmen, die Open-Source-Software einsetzen, etablieren sollten. Dabei sind klare Richtlinien, die Definition von Zuständigkeiten und die kontinuierliche Weiterbildung der beteiligten Akteure unverzichtbar, um Sicherheitsrisiken zu minimieren und gleichzeitig die rechtlichen Anforderungen zu erfüllen.
Der Standard empfiehlt dafür bewährte Best Practices, durch die potenzielle Schwachstellen frühzeitig erkannt, systematisch behoben und an die notwendigen Stakeholder kommuniziert werden können. Eine klare Kommunikation, messbare KPIs und regelmäßige Überprüfungen sowie fortlaufende Verbesserungen sind essenziell, um die Sicherheitskultur und die Compliance aufrechtzuerhalten. Unternehmen sollten den Umfang ihres Open-Source-Sicherheitsmanagements individuell anpassen, um Effizienz und Nachhaltigkeit zu gewährleisten. Auf dieser Basis können dann die Empfehlungen des zweiten Teils der ISO 18974 aufbauen.
Im nächsten Teil des Artikels, der in der kommenden Ausgabe erscheinen wird, wird der Autor die Handhabung von Sicherheitsabfragen durch Dritte sowie die Verwaltung der Open-Source-Softwarekomponenten (Bill of Materials) vertiefen. Zudem werden Prozesse zur Erkennung, Priorisierung und Behebung bekannter Sicherheitslücken und die fortlaufende Sicherheitsüberwachung im Fokus stehen.
Frédéric Noppe ist COO & Senior IT-Security-Consultant bei der L3montree Cybersecurity in Bonn.
