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

In modernen IT-Systemen und Unternehmenslandschaften spielt Open Source Software (OSS) direkt oder indirekt eine zentrale Rolle. Die Nutzung von Open Source Software und auch deren Entwicklung stellt eine strategische Entscheidung dar, die Unternehmen und deren Management früher oder später treffen müssen. Unternehmen nutzen Open Source z. B., um Kosten zu senken, indem Sie Open Source Projekte selbständig 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-90%) aus anderen Open Source Projekten besteht (siehe Abbildung 1). Doch mit dieser Effizienzsteigerung kommen auch Herausforderungen, besonders in den Bereichen Open Source Security Management und der Compliance. Die XZ Utils Backdoor, die die IT-Community über Ostern 2024 beschäftigt hat, ist ein gutes Beispiel, welche großen Sicherheitsrisiken die Open Source Nutzung mit sich bringen kann. Und nein, ich werde Ihnen nicht davon abraten, auf Open Source Software zu verzichten, da ich sie, wie viele andere auch, als das zentrale Standbein der modernen Softwareentwicklung betrachte. Vielmehr muss man sich der Risiken ihrer Verwendung bewusst sein und diese in einer im besten Falle strukturierten Weise betrachten und Sicherheitsmaßnahmen entwerfen. Doch wie kann ein Unternehmen in einer geregelten Art und Weise sicherstellen, dass der Einsatz von Open Source Software sicher und regelkonform bleibt?

Das Zauberwort lautet hier Open Source Security Management und das Beste ist, hierfür gibt es natürlich auch eine ISO-Norm, die ISO 18974, an der man sich beim Aufbau seines Open Source Security Managements orientieren kann. Die Norm und ihre Inhalte werde ich in diesem und einem folgenden Artikel beschreiben und durch praktische Umsetzungsbeispiele erweitern.

 Abbildung 1: Abhängigkeiten des npm Software-Pakets
Quelle: npmgraph.js.org

Ziele des Open Source Security Managements

Das Hauptziel eines umfassenden Open Source Security Managements besteht darin, die Sicherheitsrisiken von Open Source Software Nutzung und Einbindung zu minimieren. Gleichzeitig müssen Unternehmen sicherstellen, dass sie alle rechtlichen Anforderungen im Rahmen der Open Source Compliance erfüllen. Hierbei geht es nicht nur um die Vermeidung von Lizenzverstößen, sondern auch darum, bestehende Regulatorik 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 und Risiken zu managen.

Die Basis: Aufbau eines soliden Open Source Security Management Programms

Der erste Teil der ISO 18974 beschäftigt sich mit dem Aufbau eines effektiven Open Source Security Management Programms und fordert eine klare, gut strukturierte Grundlage. Diese Open Source Security Management Programmbasis legt die Richtlinie, Kompetenzen, den Scope und Best Practices fest, an denen sich das gesamte Sicherheitsmanagement orientiert.

Richtlinien: Die Grundlage für Sicherheit und Compliance

Was wäre ein Management System ohne Richtlinien? Die ISO 18974 empfiehlt, dass jedes Unternehmen, das Open Source Software in seinen IT-Systemen nutzt, eine formell dokumentierte Richtlinie für die Sicherheitsprüfung von Open Source Software erstellen sollte. Diese Richtlinie dient als Leitfaden für alle beteiligten Akteure wie die Entwickler und stellt sicher, 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 sollte ein Überprüfungsprozess eingerichtet werden. Dieser Prozess stellt sicher, 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 aus Effizienzgründen am besten an den bestehenden Richtlinienprozessen orientieren. Wichtig ist zu beachten, dass das Open Source Security Management an Ihr Unternehmen angepasst werden muss und nicht andersherum. Alles andere ist mit hoher Wahrscheinlichkeit zum Scheitern verurteilt.

Kompetenz der Teilnehmer: Die Schlüsselrolle der richtigen Fähigkeiten

Für den Erfolg eines Open Source Security Management Programms 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ört beispielsweise 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. Auch können so die richtigen Ansprechpartner bei spezifischen Problemstellungen auch in größeren Organisationen schnell ausfindig gemacht werden.

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 Security Managements kennen und verstehen. Dies umfasst nicht nur das Verständnis für die eigenen Aufgaben, sondern auch das Wissen darüber, wie die eigene Rolle und Handlungen zur Sicherheit des Unternehmens beiträgt und welche Konsequenzen es hat, wenn die Anforderungen nicht erfüllt werden.

Dies sollte neben Schulungen auch regelmäßige Überprüfungen und Feedback-Schleifen umfassen, um sicherzustellen, dass das Bewusstsein über die Bedeutung der Sicherheit und Compliance stets präsent ist. Ein gut dokumentierter Nachweis über diese Sensibilisierung der Mitarbeiter gefällt nicht nur den Auditoren, sondern erleichtert auch das Management, da mögliche Lücken so schnell ausfindig gemacht werden können.

Scope: Anpassung an die Bedürfnisse des Unternehmens

Ein weiteres Schlüsselelement eines erfolgreichen Open Source Security Management Programms ist die klare Definition des Anwendungsbereichs. Der Umfang des Programms sollte mit den Risikomanagement-Richtlinien des Unternehmens übereinstimmen. Dabei kann das Open Source Security Management auf eine bestimmte Produktlinie, eine Abteilung oder das gesamte Unternehmen angewendet werden. 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 (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 wie z. B. ein ISMS, empfiehlt es sich, den Anwendungsbereich und die KPIs so weit wie möglich an das bestehende System anzupassen.

Implementierung bewährter Best Practices in der Entwicklung und im Open Source Security Management

Ist die organisatorische Grundlage gelegt, wird erst richtig spannend, denn im Rahmen eines umfassenden Open Source Security Managements 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 Angreifer 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 eines effektiven Open Source Security Managements besteht darin, strukturelle und technische Bedrohungen in der gelieferten 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: Verwenden Sie automatisierte Tools zur statischen Codeanalyse für selbst geschriebene Software ein. Um potenzielle (bekannte) Schwachstellen in Open Source Komponenten frühzeitig zu identifizieren, können SCA (Software composition analysis) Scanner genutzt werden. Wenn Sie besonders sichergehen wollen, kann der Code in einem Secure Code Review durch einen Experten manuell untersucht werden. Eine strukturierte Bedrohungsanalyse (Threat Modeling), etwa mittles STRIDE Methode, hilft dabei, Schwachstellen im Softwaredesign systematisch zu identifizieren, zu bewerten und präventive Maßnahmen zu ergreifen.

2. Erkennung 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 sicherzustellen, dass erkannte Sicherheitslücken auch konsequent behoben werden. Nachdem Schwachstellen identifiziert wurden, müssen Unternehmen klare Prozesse zur Risikobewertung und Priorisierung der Behebung entwickeln. Dies verhindert, dass identifizierte Schwachstellen unbeachtet bleiben und ein erhöhtes Risiko darstellen.

Umsetzungstipp: Setzen Sie auf ein Ticketing-System oder ein zentrales Schwachstellen-Management-Tool, um erkannte Schwachstellen zu verfolgen. Weisen Sie Verantwortlichkeiten zu und stellen Sie sicher, dass jede erkannte Schwachstelle mit einem klar definierten Zeitrahmen zur Behebung versehen wird. Manche Regularien, wie der PCI-DSS erfordern eine solche Behebung in bestimmten Zeitfenstern.

4. Kommunikation von Schwachstellen an Kunden

Wenn relevante Schwachstellen gefunden werden, die die Sicherheit der ausgelieferten Software beeinträchtigen könnten, müssen diese an die Kunden oder Benutzer weitergegeben werden. Dies ist insbesondere dann wichtig, wenn Kunden Sicherheitsmaßnahmen ergreifen müssen, um das Risiko zu minimieren.

Umsetzungstipp: Implementieren Sie ein Incident Response-Verfahren, das den Kommunikationsprozess an Kunden klar regelt. Nutzen Sie sichere Kanäle, um Schwachstellenmeldungen zu übermitteln, und bieten Sie proaktive Anleitungen zur Risikominimierung. Sehr zu empfehlen ist auch das Bereitstellen dieser Informationen in einem maschinenlesbaren Format: dem VeX (Vulnerability exploitability exchange).

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 auf neue Sicherheitsrisiken schnell reagieren zu können.

Umsetzungstipp: Nutzen Sie Tools zur kontinuierlichen Überwachung von Open Source Komponenten in Ihren Softwarelösungen. Automatisierte Überwachungssysteme oder spezifische Security-Plugins können dabei helfen, neu entdeckte Schwachstellen zu erkennen und schnell zu reagieren.

6. Fortlaufende und wiederholte Sicherheitstests vor Freigabe

Bevor Software veröffentlicht wird, müssen fortlaufende und wiederholte Sicherheitstests durchgeführt werden, um sicherzustellen, dass alle identifizierten Risiken adressiert wurden.

Umsetzungstipp: Automatisieren Sie Sicherheitstests in Ihrem CI/CD-Prozess, um sicherzustellen, dass jede Softwareversion frühzeitig und vor der Veröffentlichung auf Schwachstellen geprüft wird (Stichwort: Shift-Left). Sicherheitstests sollten bei jeder neuen Version oder Änderung der Software durchgeführt werden, um neue 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) ist hierbei eine gute Orientierungsmöglichkeit.

Abbildung 2: OWASP DevSecOps Pipeline
Quelle: OWASP

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 identifizierten Schwachstellen entweder behoben oder anderweitig mitigiert wurden, bevor die Software ausgeliefert wird.

Umsetzungstipp: Erstellen Sie eine Freigaberichtlinie, die klar definiert, dass keine Software freigegeben wird, bevor alle bekannten Sicherheitsrisiken entweder behoben oder bewertet und entsprechend gemindert wurden. 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 zum Beispiel die identifizierten Sicherheitslücken, an Dritte weiterzugeben, insbesondere 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, eine größere Sicherheitskultur zu fördern und Risiken in der gesamten Software-Lieferkette zu minimieren.

Umsetzungstipp: Nutzen Sie automatisierte Schnittstellen oder Berichterstellungstools, um relevante Risikoinformationen an Ihre 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 Basis eines strukturierten Open Source Security Managements, die Unternehmen, die Open Source Software nutzen, 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. Sie empfiehlt 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 Compliance aufrechtzuerhalten. Unternehmen sollten den Umfang ihres Open Source Security Managements individuell anpassen, um Effizienz und Nachhaltigkeit zu gewährleisten. Auf diese Basis können die Empfehlungen des zweiten Teils der ISO 18974 aufbauen und somit ein effektives sowie effizientes Open Source Security Management in modern aufgestellten Unternehmen etabliert werden.

Ausblick auf Teil 2

Im zweiten Teil werden wir die Handhabung von Sicherheitsanfragen durch Dritte sowie die Verwaltung der Open Source Software-Komponenten (Bill of Materials) vertiefen. Zudem werden Prozesse zur Erkennung, Priorisierung und Behebung bekannter Sicherheitslücken und die fortlaufende Sicherheitsüberwachung im Fokus stehen.