Wie ISO 27001 und Open Source Standards gemeinsam Sicherheit und Compliance stärken

Wie ISO 27001 und Open Source Standards gemeinsam Sicherheit und Compliance stärken

Inhaltsverzeichnis

Open Source Software ist längst kein Nischenthema mehr, sondern fundamentaler Bestandteil moderner IT-Architekturen. Kaum ein Softwareprojekt wird heute ohne den Einsatz von Open Source Software durchgeführt. Gleichzeitig steigt der regulatorische Druck auf Unternehmen, ihre Informationssicherheit systematisch und nachvollziehbar zu managen. Wie beispielsweise durch ein zertifiziertes Informationssicherheits-Managementsystem (ISMS) nach der ISO/IEC 27001.

Bisher wurden die Themenbereiche Informationssicherheit und Open Source Compliance getrennt betrachtet. Während das Thema Informationssicherheit oft in den entsprechenden IT-Teams verankert war, war Open Source Compliance eher ein Thema für die Legal-Teams. Diese beiden Themenbereiche wachsen jedoch zunehmend zusammen.

Mit der ISO/IEC 5230 und der neueren ISO/IEC 18974, die speziell auf Sicherheitsaspekte im Umgang mit Open Source eingeht, existieren international anerkannte Standards, die strukturierte Prozesse für den sicheren Einsatz von Open Source Software fordern und entsprechende Anforderungen sowie Checklisten an die Hand geben. Doch wie lassen sich diese Anforderungen mit einem ISMS nach ISO 27001 verbinden? Welche Kontrollziele aus dem Anhang A der ISO 27001 werden durch Open Source Compliance und Security direkt oder indirekt adressiert?

Dieser Artikel beleuchtet die Schnittmengen zwischen diesen Normen und zeigt auf, wie Unternehmen Synergien nutzen können, um sowohl ihre Sicherheits- als auch ihre Compliance-Ziele effizienter zu erreichen und damit auch konform zu sein gegenüber den entsprechenden Normen. Gleichzeitig gilt dies als Vorbereitung und auch besser auf neue gesetzliche Anforderungen wie den Cyber Resilience Act (CRA) gewappnet zu sein.

Überblick über die Normen

ISO/IEC 27001 – Informationssicherheitsmanagement

Die ISO/IEC 27001 definiert Anforderungen an die Einführung, den Betrieb und die kontinuierliche Verbesserung eines ISMS. Ihr Ziel ist es, Risiken für Vertraulichkeit, Integrität und Verfügbarkeit von Informationen systematisch zu identifizieren und zu behandeln. Ein zentraler Bestandteil ist der Anhang A, der 93 Sicherheitsmaßnahmen (Controls) enthält, die im Rahmen einer Risikoanalyse berücksichtigt werden sollten. Der Maßnahmenkatalog deckt ein sehr breites Feld ab, von Zugriffskontrollen über Lieferantenmanagement bis zu Schwachstellenmanagement. In der ISO/IEC 27002 werden diese Maßnahmen weiter detailliert, diese Norm (ISO 27002) ist jedoch hinweisend.

ISO/IEC 5230 – OpenChain Specification

Die ISO/IEC 5230 ist der erste internationale Standard für Open Source Compliance Management. Sie zielt darauf ab, sicherzustellen, dass Organisationen OSS-Komponenten rechtssicher nutzen können. Im Fokus stehen dokumentierte Prozesse zur Lizenzkonformität, zum Umgang mit Open Source Policies, zur Schulung relevanter Stakeholder sowie zur Nachvollziehbarkeit eingesetzter Software.

ISO/IEC 18974 – Open Source Security Assurance

Ergänzend zur ISO 5230 legt ISO/IEC 18974 Sicherheitsanforderungen für den Umgang mit Open Source fest. Im Mittelpunkt stehen Prozesse zur Verwaltung von Schwachstellen, die Erstellung und Pflege von Software Bill of Materials (SBOMs) sowie Maßnahmen zur Sicherheitsüberprüfung von Drittanbieter-Komponenten. Die Norm ist insbesondere relevant, wenn Open Source Bestandteil von Produkten oder Plattformen ist, die Sicherheitszertifizierungen erfordern.


Gemeinsame Anforderungen und Überschneidungen

In der folgenden Tabelle sind typische Überschneidungen zwischen den drei Normen dargestellt:

ThemaISO 27001 (Anhang A)ISO 5230ISO 18974
Rollen & VerantwortlichkeitenA.5.2 - Informationssicherheitsrollen und VerantwortlichkeitenRollen und deren entsprechende Pflichten müssen identifiziert, dokumentiert und mit Leben gefüllt werdenRollen und deren entsprechende Pflichten müssen identifiziert, dokumentiert und mit Leben gefüllt werden
Leitlinie und Unterstützung von der FührungsebeneA.5.4 – Verantwortlichkeit der LeitungDie Open Source Policy muss zwar nicht von der Führungsebene unterzeichnet werden, jedoch braucht es ein starkes Signal, dass Open Source Policy Chefsache ist
LieferkettensicherheitA.5.20 – Behandlung von Informationssicherheit in Lieferentenvereinbarungen
A.8.30 - Ausgegliederte Entwicklung
In den Lieferentenvereinbarungen muss Open Source Compliance sichergestellt werden. Der Lieferant muss die Prüfungen übernehmen und die Lizenzvereinbarungen sicherstellen.In den Lieferentenvereinbarungen muss Open Source Sicherheit sichergestellt werden. Der Lieferant muss die Software scannen und etwaige Schwachstellen beseitigen.
SicherheitsvorfälleA.5.24 - Planung und Vorbereitung der Handhabung von InformationssicherheitsvorfällenSollte es zu neuen Schwachstellen in verbauten Open Source Komponenten kommen, muss es einen Prozess geben, wie diese behandelt werden.
Eigentumsrechte und vertragliche AnforderungenA.5.31 Juristische, gesetzliche, regulatorische und vertragliche Anforderungen
A.5.32 Geistige Eigentumsrechte
Jede Open Source Komponente hat eine entsprechende Lizenz, was einem Vertrag gleicht. Gleichzeitig muss das entsprechende Copyright der Komponente beachtet werden.
Schwachstellenmanagement und SoftwareentwicklungsprozesseA.8.8 – Handhabung von technischen Schwachstellen
A.8.25 – Lebenszyklus einer sicheren Entwicklung
A.8.27 - Sichere Systemarchitektur und Entwicklungsgrundsätze
A.8.28 - Sichere Codierung
A.8.29 Sicherheitsüberprüfungen bei Entwicklung und Abnahme
Das Herzstück der ISO 18974. Es müssen Prozesse in der Softwareentwicklung existieren, um Schwachstellen zu erkennen und SBOMs zu erstellen. Jedoch müssen diese Komponenten auch nach Release beobachtet werden.
Software Asset ManagementA.5.9 – Inventar der Informationen und anderer damit verbundener WerteSBOMSBOM
Awareness & TrainingA.6.3 – Informationssicherheitsbewusstsein sowie Ausbildung und SchulungOSS Compliance AwarenessSecurity Awareness zu OSS

Diese Überschneidungen zeigen, dass viele der in ISO 5230 und 18974 geforderten Aktivitäten gleichzeitig auch Anforderungen oder Maßnahmen nach ISO 27001 adressieren. Insbesondere im Kontext von Lieferkettensicherheit, Schwachstellenmanagement und Softwareentwicklungsprozesse.

Integration in bestehende Managementsysteme

Ein großer Vorteil für Unternehmen mit einem bestehenden ISMS nach ISO 27001 ist, dass viele Prozesse und Rollen bereits etabliert sind wie beispielsweise im Bereich Risikoanalyse, Schulung oder Lieferentenmanagement. Weiterhin legt die ISO 27001 bereits großen Wert auf die notwendigen Prozesse innerhalb der Softwareentwicklung. Diese können mit wenig zusätzlichem Aufwand um Aspekte der Open Source Compliance und Security erweitert werden:

  • Eine SCA (Software Composition Analysis) Lösung kann in bestehende Softwareentwicklungsprozesse und Freigaben etabliert werden
  • Das Awarenessprogramm kann um die Aspekte der Open Source Compliance und Sicherheit erweitert werden
  • Die Lieferentenvereinbarungen können und müssen um die Aspekte von Open Source ergänzt werden

Für Unternehmen, die ISO 27001 zertifiziert sind oder dies anstreben, bietet die Integration von ISO 5230 und 18974 eine Möglichkeit, ihre Sicherheitsprozesse zukunftssicher aufzustellen und diese noch weiter zu verbessern. Insbesondere im Hinblick auf gesetzliche Anforderungen wie den Cyber Resilience Act, der SBOMs und Schwachstellenmanagement in der Software-Lieferkette fordert.

Fazit und Ausblick

Die Einführung von ISO/IEC 5230 und ISO/IEC 18974 bietet nicht nur rechtliche Absicherung im Umgang mit Open Source, sondern stärkt auch die Resilienz gegenüber Software-Sicherheitsrisiken. Im Zusammenspiel mit ISO/IEC 27001 entsteht ein ganzheitlicher Ansatz für die sichere und konforme Nutzung von Open Source Software. Und das ganzheitlich vom Lizenzmanagement über das Schwachstellenmonitoring bis hin zur Lieferantensicherheit.

Angesichts wachsender regulatorischer Anforderungen wie dem Cyber Resilience Act sollten Unternehmen frühzeitig beginnen, ihre Prozesse in diesem Bereich zu harmonisieren. Wer bereits ein ISMS etabliert hat, kann hier auf bestehenden Strukturen aufbauen und mit geringem Zusatzaufwand bereits große Erfolge feiern.

Glossar

ISO/IEC 27001 Internationale Norm für Informationssicherheits-Managementsysteme (ISMS), mit dem Ziel, Risiken für Vertraulichkeit, Integrität und Verfügbarkeit von Informationen systematisch zu steuern.

ISO/IEC 5230 Internationaler Standard zur Sicherstellung von Open Source Compliance in Unternehmen, insbesondere im Hinblick auf Lizenzanforderungen und Prozesssicherheit.

ISO/IEC 18974 Norm zur Open Source Security. Sie beschreibt Anforderungen für den sicheren Umgang mit Open Source Komponenten, insbesondere zur Schwachstellenbewertung und -behandlung.

ISMS (Information Security Management System) Ein Rahmenwerk aus Richtlinien, Prozessen und Maßnahmen zur systematischen Verwaltung von Informationssicherheit in einer Organisation.

SBOM (Software Bill of Materials) Eine strukturierte Liste aller Komponenten (einschließlich Open Source), aus denen eine Software besteht. Eine SBOM ist vergleichbar mit einer Stückliste in der Fertigung.

VEX (Vulnerability Exploitability eXchange) Ein maschinenlesbares Format zur Beschreibung, ob eine bekannte Schwachstelle (CVE) für ein konkretes Produkt tatsächlich ausnutzbar ist.

OSS (Open Source Software) Software, deren Quellcode öffentlich zugänglich ist und unter einer Open-Source-Lizenz steht, die Nutzung, Änderung und Weiterverbreitung erlaubt.

Compliance Einhaltung von gesetzlichen, regulatorischen oder vertraglichen Vorgaben – im Kontext von OSS insbesondere die Einhaltung von Lizenzbedingungen.

Cyber Resilience Act (CRA) Geplante EU-Verordnung zur Verbesserung der Cybersicherheit von Produkten mit digitalen Elementen – fordert u. a. SBOMs und Schwachstellenmanagement über den gesamten Produktlebenszyklus.

Asset Management Verfahren zur Identifikation und Verwaltung von IT-Assets, einschließlich Software-Komponenten – eine Grundvoraussetzung für Sicherheits- und Lizenzmanagement.

Du möchtest mehr zum Thema erfahren?

Vereinbare einen kostenlosen Gesprächstermin mit uns oder sende uns deine Anfrage über unser Kontaktformular.

App screenshot

Ähnliche Posts

ISO/IEC 5230 als Grundlage für sicheres Open Source Management

ISO/IEC 5230 als Grundlage für sicheres Open Source Management

Jeden Tag werden mehr als 20 000 neue Open-Source-Software Komponenten released. Ein Softwareprojekt ohne den Einsatz von Open-Source-Software Komponenten ist in der Realität nicht mehr vorstellbar. Doch mit den vielen Vorteilen kommen natürlich auch Pflichten. Welche Lizenz gilt für welchen Code? Was muss ich mitliefern? Welche Risiken gehe ich ein? Wenn Unternehmen Open Source professionell einsetzen, brauchen sie klare, wiederholbare Prozesse. Genau hier setzt die ISO/IEC 5230 an.

Mehr lesen
Von der Lizenz zur Sicherheit mit ISO/IEC 18974

Von der Lizenz zur Sicherheit mit ISO/IEC 18974

Was haben die Sicherheitsvorfälle Spring4Shell, OpenSSL Heartbleed oder XZ Utils Backdoor gemeinsam? Alles waren Open-Source-Software Komponenten und mit ihnen entstanden zahlreiche Sicherheitsvorfälle durch manipulierte Software innerhalb der Komponenten. Das sind nur wenige Beispiele, die zeigen, wie anfällig Software-Lieferketten sind. Der Einsatz von Open-Source-Software Komponenten ist heute ein integraler Bestandteil in der Softwareentwicklung.

Mehr lesen