Software Supply Chain: Risiko digitale Zutatenliste
Software Supply Chain, SBOM und TPLC: Die Inhalte von Digitalen Produkten und der Ruf nach Cyber Security Labeling
Software Supply Chain ist das neue Thema aller produzierenden Unternehmen – und wird bald immer mehr Firmen betreffen. Denn auf einmal wollen Behörden, Zertifizierer und Kunden alles darüber wissen, was in digitalen Produkten steckt. Wie kam es dazu, worum geht es im Detail und was sollte man sich merken?
Software Supply Chain, SBOM – kann man das essen? Garnicht so verkehrt, denn wir achten beim Einkauf von Lebensmitteln doch auch auf die Inhaltsstoffe, oder? Gut, dass man auf Verpackungen heute eine über die letzten Jahrzehnte stets höher detaillierte Menge an Informationen findet. Zutaten, Allergiehinweise, Farbstoffe und Nährwerte – all das interessiert uns und gilt als vollkommener Standard. In den letzten Jahren gab es zudem Erweiterungen, wie zum Beispiel den Nutri-Score, welcher mit Ampelfarben und Buchstaben an Energielabels erinnert, die wir vom letzten Kauf eines Haushaltsgeräts kennen. Letzteres ist übrigens keine kreative Marketingidee gewesen, sondern basiert auf der Wissenschaft des Nudgings – kleine Hinweise, die das Verhalten beeinflussen sollen und inzwischen vollkommener Standard sind.
Und jetzt nehmen wir einmal die Verpackung unseres letzten angeschafften, digitalen Produkts in die Hand. Was fällt auf? Ganz gleich ob Handy, Laptop oder Spielekonsole: Nirgendwo ist vor der Nutzung ersichtlich, was man da eigentlich kauft bzw. was alles in dem Produkt enthalten ist. Und sind wir ganz ehrlich, so weiss man das selbst nach dem Kauf und Auspacken noch nicht im Detail. Die Frage, warum sich das nun ändern soll, beantwortet sich schnell, wenn wir auf typische Ereignisse wie Log4j zurückblicken. Plötzlich ist ein Stück Software in der Presse, weil es ein Sicherheitsproblem gibt. Und auf einmal geht es los – jeder will wissen, ob er das unsichere digitale Element irgendwo nutzt, es etwa in einem Gerät als Software aufgespielt ist oder gar im eigenen, verkauften Produkt steckt. Was, wenn jetzt gleich der erste besorgte Kunde anruft und nachfragt?
Index
Medizinprodukte im Fokus: Was die letzten Monate geschah
Mein erster Kontakt mit dem Thema Software Supply Chain war das Thema SBOM. Der Begriff steht für „Software Bill of Materials“, und mindestens der „BOM“ Teil des Begriffs ist jedem, der einmal mit Lego gespielt oder bei IKEA eingekauft hat, geläufig: Es handelt sich um eine klassische Stückliste, eine Auflistung von Teilen und quasi das Inhaltsverzeichnis. Ganz gleich ob Schrauben, Bauteile oder Verbindungsstücke, die BOM zeigt einem, was alles enthalten ist.
Nach diesem Prinzip und aufgrund zahlreicher Zwischenfälle mit smarten, digitalen Medizinprodukten bis hin zu durch Hackerangriffe lahmgelegten Krankenhäusern war die amerikanische FDA als oberste Gesundheitsbehörde der USA zunächst drauf und dran, eine Verordnung zu erlassen. Diese sollte dazu führen, dass jeder Hersteller von Produkten, welche nicht rein als physikalische Geräte sondern durch integrierte Software funktionieren, sich um folgende Themen kümmern sollte:
- Ein Vorweisen der SBOM für das Produkt
- Die Herkunft der Bestandteile sowie die Versionen der Software
- Bekannte Schwachstellen
- Einen Plan, wie man die Software aktuell halten will
…um nur die wichtigsten Elemente zu nennen. Wir kennen es ja von Handy und Laptop: Updates sind wichtig, doch genau nach diesem Prinzip arbeiten viele Hersteller von Produkten im Medizinbereich leider noch nicht. Spätestens seit Insulinpumpen gehackt wurden und damit die Frage im Raum steht, wie leicht ein Hacker den Anwender (oder Patient) eines solchen Produkts durch Überdosierung schlicht und ergreifend ums Leben bringen könnte, war es vorbei mit dem Stand der Dinge – die ersten Drafts sogenannter Regulations for Cyber Security in Medical Devices wurden veröffentlicht und machten den Herstellern klar, dass sie ab sofort nicht nur Medizingeräte produzieren, sondern regulatorisch auch Softwareunternehmen und IT-Dienstleister sind.
Transparenz über Software – eigentlich eine ganz normale Sache
Das Ziel ist also klar: Jede neu zuzulassenden, und wohl bald auch bereits verkäufliche Produkte sollen hinsichtlich der Sicherheit der enthaltenen Software geprüft und so das Risiko eines Zwischenfalls eingedämmt werden. Bis hier wird wohl jeder zustimmen, dass dies weder überzogen noch sinnfrei ist. Gleichzeitig stellt sich die Frage, wie Unternehmen, welche Software in ihren Produkten bisher eher als Mittel zum Zweck verwendet haben, die Situation meistern sollen. Eigentlich dürfte die Herausforderung nicht zu groß sein, denn schließlich gibt es in den Herstellerfirmen Entwickler, die wissen sollten, was in den Produkten steckt. Und hier beginnt das sogenannte „Whitelabel Problem“, denn viele Produkte, welche von der Firma A angeblich hergestellt werden, kommen in Realität aus der Fabrik von Firma B. Letztere stellt keine Produkte her um sie unter eigenem Namen zu verkaufen, sondern eben mit „weissem Label“, unbeschriftet und als Blanko-Produkt für Firma A. Auf diese Weise gibt es tausende Produktkategorien, welche von einem Hersteller dominiert und am Ende, je nach Anspruch und Zielgruppe, mit gewissen Anpassungen unter bekanntem Namen in den Markt kommen. Egal ob Kreditkarte, Feuerzeug oder Schuhe: Whitelabeling ist ein Milliardenbusiness.
Dementsprechend trifft die Verpflichtung zu Transparenz und Sicherheit zwar viele Hersteller der hier fokussierten Medizintechnik, die darin enthaltenen Chips, Sensoren und Softwareteile sind jedoch meistens zugekauft. Somit kaskadiert sich die Verantwortung nach unten und wir erkennen, dass ein Hersteller eines solchen Stückwerks nun plötzlich mit in der Verantwortung steckt – obwohl er seine Produkte für alle möglichen Branchen produziert. Daraus folgt also, dass jede Branche, die in irgendeiner Form Richtung Medizintechnik liefert, nun ebenso mit dem Thema zu kämpfen hat und vielleicht überlegen wird, ob ihre Technik dafür eigentlich geeignet ist. Dies klingt zunächst logisch und machbar, bei vielen Produkten unserer Zeit ist es jedoch nicht möglich – denn am Beispiel eines Bluetooth-Chips wird schnell klar, dass dieser ja auch in einem absolut nicht medizinischen Produkt wie einem Kopfhörer stecken könnte. Wer hat nun am Ende die Verantwortung? Schlussendlich wohl eher der Hersteller des in Verkehr gebrachten Produktes, der nun die Tauglichkeit genauer prüfen muss, als je zuvor. Ein weiteres passendes Beispiel ist die Automobilbranche, welche durch geänderte Zulassungsverfahren bei der Entwicklung von Fahrzeugen seit geraumer Zeit die sogenannte UNECE R 155 erfüllen muss – Cybersecurity im Fahrzeug, was bei den komplett durchdigitalisierten Gefährten von heute auch Sinn macht. Hier kommt es sogar noch ein wenig dicker, denn die nächste Norm UNECE R 156 regelt die Sicherheit von Updateprozessen, wenn das Fahrzeug auf dem Parkplatz über Nacht mit neuer Software versorgt wird. Schließlich möchte niemand, dass die elektronische Parkbremse auf der Autobahn-Auffahrt auslöst.
Und damit schließt sich der Kreis, denn auch die Medizintechnik soll mit dem Schlagwort TPLC, der sogenannte „Total Product Lifecycle“ so wie ein Handy oder ein Windows PC mit Sicherheitspatches versorgt werden. Dazu gehören alle möglichen weiteren Themen wie Kommunikation mit Kunden, ein stetes Prüfen der Sicherheit von Softwarekomponenten sowie im Extremfall ein Zurückrufen von Produkten, die nicht mehr sicher sind. Somit kann man sich diese Branchen als zukünftig prozessual ähnlich eng getaktet vorstellen, wie die Apps auf dem Handy oder ein Softwareprodukt am PC. Doch damit nicht genug: Als nächstes steht bereits der Ruf nach Cyber Security Labeling vor der Tür, quasi einer aufgedruckten, auf der Verpackung ersichtlichen und konsumententauglichen Zutatenliste. Dadurch soll der Kunde im Laden auf der Box eines iPads schon erkennen, ob er gegen ein gewisses Stück Software in dem Gerät allergisch reagiert – wie das konkret aussehen kann und soll, ist jedoch noch Stand der Forschung. Das gewisse Software ab Werk auf den Geräten unseres Alltags nichts zu suchen hat, ist hingegen in der Breite angekommen. Doch was bedeutet das nun für uns als Geschäftsleute?
Konkrete Vorgehensweisen, Tipps und der Blick nach Vorne
Grundsätzlich rate ich Kunden, als erstes einmal strukturiert festzuhalten, was offensichtlich in den eigenen Produkten steckt. Meist sprechen wir zunächst mit Produktverantwortlichen oder Compliance-Managern, die erstaunlich wenig über die Details dazu wissen. Auf der anderen Seite wünschen sich viele Entwickler und Programmierer schon seit Jahren, dass sie mehr ins Zentrum des Interesses gestellt werden – anstatt nur die ewig wiederholte Ansage nach weniger Kosten und schnellerer Entwicklungszeit zu hören. Jetzt sind diese Experten am Zug und die klare Empfehlung ist, einfach mal mit diesen Leuten zu sprechen. Nicht selten sind sogar Schwachstellen, Probleme und Lösungen bekannt, wurden aber nie angefragt oder als Bedenken ignoriert, weil es im Business nur um Umsatz ging. Der erste Schritt zur Erhebung des Mengengerüsts an Software in den eigenen Produkten ist also gar nicht so schwer!
Als nächstes sollte das Management verstehen, dass die Assets, welche durch das Programmieren und Digitalisieren in Produkte Einzug gehalten haben, jetzt eine neue, relevante Risikoklasse darstellen. Zusammen mit dem Qualitätsmanagement und Controllern oder Risikoanalysten kann man nun übersetzen, was es bedeutet, eine 10 Jahre alte Open-Source-Bibliothek einzusetzen und wie sinnvoll plötzlich die aktuellere, immer wieder mit Sicherheitspatches versorgte Alternative ist. Jedes, absolut jedes Produkt und jede Kategorie an verwendbarer Technik wird heute nicht nur von den gerne zitierten Hackern, sondern von Security-Experten zerlegt und analysiert – ganz gleich, ob nun also ein Auto am Ende der Produktionslinie steht oder das Unternehmen Herzschrittmacher herstellt: Die Hardware selbst, das Produkt und das Gehäuse ist nur das Drumherum, jetzt gilt es, sich mit den Innereien zu beschäftigen und bereit zu sein für alle die Forderungen, welche hier erläutert wurden. Der Risikoappetit des Unternehmens wird sich also verändern und der „Total Product Lifecycle“, kurz TPLC, zu einer neuen Dimension der Planung für Management und Produktverantwortliche sowie deren Entwickler. Damit ändert sich natürlich auch der Faktor TCO, also die Gesamtkosten eines Produkt von der Idee bis zur Abkündigung.
So what’s next? Die amerikanische FDA hat zu Ende März ein Enddatum für die Übergangszeit bei der Zulassung von medizinischen Geräten festgelegt. Mit Oktober diesen Jahres gilt das Thema Cybersecurity mit seinen Bestandteilen SBOM und TPLC als Pflicht – und wer als Hersteller die Zulassung ohne entsprechende Nachweise zu Prozessen, Plänen und Methoden vorlegt, wird schlicht und ergreifend abgelehnt. Die Europäische Medical Device Regulation, kurz MDR, hat übrigens mit dafür gesorgt, dass Software nun als Medical Device eingestuft werden kann – womit endgültig klar sein sollte, dass die Digitalisierung in der Produktentwicklung für zahlreiche Änderungen sorgt und die hier beispielhaft genannten Branchen lediglich der Anfang dafür sind, dass Produkte ausschließlich mit aktiv gemanagter Software Supply Chain eine Marktzulassung erhalten können.
Die Kommentarfunktion ist geschlossen.