Update für altes Embedded-Linux-Board
Verfügbarkeits- Retrofit mit Security-Perspektive
Fortsetzung des Artikels von Teil 1
Schwachstellen mittels Softwarestückliste im Blick behalten
Lösen lässt sich eine solche Aufgabe mithilfe einer »Software Bill of Materials (SBOM)«. Solche maschinenverarbeitbaren Dokumente dienen als elektronische Stück- und Teileliste für die Codebasis einer einzelnen Baugruppe, Maschine bzw. Anlage oder sogar einer verteilten IoT-Anwendung mit Sensor, Gateway, Cloud-basierter Middleware plus Frontend-Anwendung in Form einer Smartphone-App. Aufgrund der Datenkomplexität sind SBOMS allerdings nur sinnvoll, wenn die Beteiligten sowohl die Erstellung als auch die Auswertung weitestgehend automatisieren. Über die SBOM-Informationen lässt sich mithilfe eines entsprechendes Application Programming Interface (API) abfragen, ob eine potenzielle Sicherheitslücke bzw. Schwachstelle in einem Produkt existiert.
Ist das der Fall, werden die zuständigen Maintainer informiert. Sie müssen dann bewerten, welche Auswirkungen die gefundene Schwachstelle in diesem Fall hat, welche Risiken sich dadurch ergeben und ob im Rahmen des Schwachstellenmanagements entsprechende Patches zu erstellen sind. Die erforderlichen Werkzeuge zur SBOM-Erstellung und Auswertung (Monitoring) lassen sich in die CD- und CI-Pipelines eines DevOps integrieren, sodass in Zukunft für jede neue Softwareversion eine SBOM entsteht und ein permanenter Schwachstellenabgleich stattfindet.
Jobangebote+ passend zum Thema
Anatomie einer SBOM
SBOMs sind den USA schon seit 2021 für Lieferungen an Regierungsbehörden und bestimmte Medizinprodukte vorgeschrieben. In der EU werden solche Software-Inventarlisten in den kommenden Jahren durch den Cyber Resilience Act (CRA) vermutlich sogar für jedes Produkt mit digitalen Elementen gefordert. Insofern hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) im Sommer 2023 bereits die sehr übersichtliche Technische Richtlinie TR-03183-2 veröffentlicht [3]. Sie fordert die SBOM-Erstellung im Rahmen des Software-Build-Prozesses sowohl bei der Produktentwicklung als auch bei jeder Änderung. Inhaltlich muss eine SBOM aus BSI-Sicht zumindest eine Ersteller-E-Mailadresse und einen Zeitstempel zum Erstellungszeitpunkt in den Kopfdaten sowie einen vollständigen Objektdatenbestand aufweisen. Innerhalb der SBOM-Objektdaten sind dann je Komponente mindestens die sechs folgenden Datenfelder erforderlich:
➔ Ersteller der Komponente: E-Mail-Adresse der Entität, die die jeweilige Softwarekomponente erstellt und ggf. verändert hat.
➔ Komponentenname: Bezeichnung des jeweiligen Softwarebausteins, die der ursprüngliche Ersteller dieser Komponente zugewiesen hatte.
➔ Version der Komponente: Versionsbezeichner des Erstellers, um Änderungen in der Softwarekomponente zu einer zuvor erstellten Version zu signalisieren. Die Bezeichner sollten sich an den Semantik-Versions-Spezifikationen unter www.semver.org orientieren, also z. B. an Versionsbezeichnern der Form »x.y.z«.
➔ Abhängigkeiten von anderen Komponenten: Aufzählung aller Komponenten, von denen diese Komponente unmittelbar abhängig ist. Diese Auflistung muss eine rekursive Auflösung aller Abhängigkeiten der jeweiligen Komponente ermöglichen.
➔ Lizenz: Effektive Lizenz der Komponente. Bei Unklarheiten kann hier »Proprietary« oder ein zwischenAnbieter und Kunde vereinbarter Lizenzbezeichner verwendet werden.
➔ Hashwert der ausführbaren Komponente: Kryptografisch sichere Prüfsumme der Komponente in ihrer ausführbaren (Datei-)Form, z. B. als SHA-256-Hashwert.
Die TR-03183-2-Anforderungen lassen sich durch die beiden De-Facto-Standards SPDX und CycloneDX [4] erfüllen (Bild 3). SPDX ist die Abkürzung für »Software Package Exchange«. Dahinter verbirgt sich eine Datenformatspezifikation, deren erste Version bereits 2011 von einer Arbeitsgruppe der Linux Foundation veröffentlicht wurde. SPDX sollte ursprünglich die Lizenzkonformität von Open-Source-Software verbessern, eignet sich aber durch eine kontinuierliche Weiterentwicklung auch für SBOMs. CycloneDX ist das SBOM-Projekt der OWASP (Open Web Application Security Project), einer Non-Profit-Organisation mit dem Ziel, die Sicherheit von Anwendungen und Diensten im World Wide Web zu verbessern. Es eignet sich sehr gut für Embedded-Systems-Lösungen.
Open-Source-Komplexität
Insgesamt hat das Retrofit-Vorhaben die ursprüngliche Annahme der ADNP/1520-Entwickler weitestgehend bestätigt, dass man durch den Zugriff auf Betriebssystem-Quellcodes jederzeit (also auch 20 Jahre später) eine neue Hardware mit identischen Funktionen entwickeln kann und lediglich ein paar Treiber anpassen muss, um bei Bedarf ein nahezu kompatibles Embedded-Linux-Modul zu schaffen. Die aktuellen Cybersecurity- und Produkthaftungs-bedingten Anforderungen lassen allerdings die Nutzung alter Linux-Quellen in einem neuen Produkt nicht mehr zu. Hinzu kommt, ohne SBOM und Software-Updates geht demnächst vermutlich nichts mehr. Insofern ist der Betriebssystem-Quellcode für viele Produktentwickler inzwischen lediglich »nice to have«, für die Software-Maintainer wegen der SBOM allerdings unverzichtbar.
Aufgrund der Komplexität – bereits 2020 bestand der Linux-Kernel incl. »systemd« aus ungefähr 30 Millionen Codezeilen – ist allerdings auch in Zukunft die Wartung und Weiterentwicklung nur durch eine große internationale Community möglich. Damit ein Embedded-Linux-Modul über den gesamten Lebenszyklus von den Weiterentwicklungen profitieren kann, sind allerdings DevOps mit Embedded-Entwickler-Teams und Anwendern erforderlich, die in der Praxis auch wirklich gelebt werden (Bild 4). Das bisher übliche »Deploy-and-Forget« für eingebettete Systeme wird in Zukunft nicht mehr funktionieren.
Literatur
[1] ttps://insights.sei.cmu.edu/documents/508/2001_019_001_496192.pdf
[2] www.cve.org und https://github.com/CVEProject/cvelistV5
[3] TR-03183 https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html
[4] Webseite zu den CycloneDX-Bausteinen (beachte die neun Bereiche einer CycloneDX-SBOM mit Abbildungen): https: //cyclonedx.org/specification/overview/
Der Autor
Klaus-Dieter Walter
ist CEO der SSV Software Systems in Hannover. Er ist Verfasser verschiedener Fachbücher zu Embedded-Systems-Themen und hat viele Jahre aktiv in der Expertengruppe Internet der Dinge innerhalb der Fokusgruppe Intelligente Vernetzung des Digital-Gipfels der Bundesregierung mitgearbeitet.
- Verfügbarkeits- Retrofit mit Security-Perspektive
- Schwachstellen mittels Softwarestückliste im Blick behalten
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
