UL 2900 – weshalb Sie den IT-Security-Standard kennen, aber niemals kaufen sollten

Der UL 2900-2-1 nennt sich „Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems“. Er zählt zur UL-2900-Familie, der Normenfamilie zur IT-Security.

Lesen Sie in diesem Artikel, welche Schwächen der Standard hat und unter welchen Umständen er Ihnen dennoch nützlich sein kann.

Die Normenfamilie UL 2900

Die Normenfamilie UL 2900 besteht aus mehreren Normen bzw. Standards:

• Der UL 2900-1 ist der Grundstandard mit allgemeinen Produktanforderungen. Er heißt „Software Cybersecurity for Network-Connectable Products – General Requirements“
• Der UL 2900-2-1 zählt zu den branchenspezifischen Standards und wendet sich an den Gesundheitsmarkt. Allerdings gibt es derzeit nur einen weiteren Standard dieser „2er-Serie“, den UL 2900-2-2 „Industrial Control Systems“.
• In Entwicklung befinden sich die Standards der „3er-Serie“ mit den Prozessanforderungen. Der UL 2900-3-1 wird allgemeine Prozessanforderungen formulieren („General Process Requirements“), der UL 2900-3-2 Anforderungen and den Entwicklungsprozess („Security Development Lifecycle“).

UL 2900-1: Der allgemeine Produktstandard zur Cybersecurity

Aufbau des UL 2900-1

Mit 35 Seiten ist der Standard angenehm kurz. Ohne Leerseiten, Inhaltsverzeichnisse, Begriffsdefinitionen und Anhänge bleiben sogar nur ca. zehn Seiten. Kompakte Standards zeugen oft von Klarheit. Leider gilt dies nicht für den UL 2900-1.

Das beginnt mit einer Kapitelstruktur, die sich auch nach dem zweiten Lesen nicht erschließt:

Weshalb die „Risk Controls“ (Kapitel 7) nicht zum Kapitel „Risk Management“ (Kapitel 12) zählen, weshalb „Access Control, User Authentication und User Authorization“ (Kapitel 8) keine Maßnahmen zur Risikokontrolle sind, wird noch unklarer, wenn man das siebte Kapitel liest. Denn dort wird im Wesentlichen genau auf die Kapitel 8 und 12 verwiesen.

Auch die Kapitelüberschriften sind leider etwas irreführend: Hinter „Vulnerability und Exploits“ verbergen sich die Anforderungen an das (Blackbox-)Testen des Produkts, hinter „Software Weaknesses“ die statische Code-Analyse, die sich nicht auf das Kapitel 18 beschränkt, wie man meinen könnte.

Was würden Sie erwarten unter „11. Product Management“? Dass sich hier keine Anforderungen an das Produktmanagement verbergen, ahnen Sie sicher schon. Dieses Kapitel nennt Produkt- bzw. Systemanforderungen – eben die Inhalte, die man in einer System Requirements Specification erwarten würde. Allerdings enthalten viele andere Kapitel ebenfalls Systemanforderungen.

Inhalt und Anforderungen

Der UL 2900-1 formuliert Anforderungen an folgende Aspekte:

• Produkt
• Risikomanagement
• Testen (statische und dynamische Prüfungen)
• Dokumentation
• Organisation (nur bei UL 2900-2-1)

Die folgende Mindmap verschafft einen Überblick über die wichtigsten Anforderungen.

Die Anforderungen schwanken zwischen Belanglosigkeit und befremdlicher Konkretheit. Beispielsweise fordert der UL 2900-1, dass der Source Code einer statischen Code-Analyse unterzogen werden soll. Weder nennt der Standard, auf was hin der Soruce Code untersucht werden soll, noch welche Metriken oder Eigenschaften zu prüfen sind. Auf der anderen Seite fordert der UL 2900-1 mindestens fünf Millionen Testfälle oder einen mindestens achtstündigen Test. Weshalb gerade fünf Millionen, weshalb acht Stunden?!?

UL 2900-2-1: Die Ergänzungen für den Gesundheitsmarkt

Struktur und Inhalte

Der UL 2900-2-1 folgt der gleichen Struktur des UL 2900-1. Bei der ISO 9001 würde man von einer „High Level Structure“ sprechen.

Im Wesentlichen verweist der UL 2900-2-1 nur auf den UL 2900-1. An einigen Stellen, vor allem in den Kapitel 12, 13, 15 und 16 finden sich Ergänzungen oder andere Formulierungen. Das Kapitel 20 gibt es nur in dem UL 2900-2-1.

Völlig befremdlich fordert der UL 2900-2-1 ein QM-System nach ISO 13485 und eine Software-Entwicklung konform IEC 62304. Bei allem Respekt vor diesen Normen: Aber weshalb wäre ein QM-System nach 21 CFR part 820 nicht adäquat?

FDA Cybersecurity Guidance

Der UL 2900-2-1 wirbt damit, dass er in Abstimmung mit der FDA entwickelt worden und geeignet sei, die Anforderungen des FDA Guidance Documents zur Cybersecurity nachzuweisen. In der Tat gibt es ein Mapping beider Dokumente, das allerdings nicht Teil des Standards ist.

Kritik

Der Kauf

Schon der Kauf des Standards wird zur unschönen Überraschung: Erwirbt man den UL 2900-2-1, stellt man fest, dass dieser ohne den UL 2900-1 wertlos ist. Wünscht man zudem die HTML-Version, da die PDF-Version nicht nur druck- sondern auch kopiergeschützt ist, erhöht sich der Preis von 375 USD um weitere 300 USD(!!) Shipping-Kosten und 10 USD für Web-Delivery. Bekommt man die elektronischen Unterlagen per Post zugestellt?

Auf eine entsprechende Anfrage hat UL nicht reagiert.

Usability

Das sogenannte Digital Rights Management sorgt dafür, dass man die Dateien ohne weiteres gar nicht lesen kann. Ein nerviger Installationsprozess und die Installation spezieller Acrobat-Versionen sind notwendig, um die PDF-Dateien überhaupt lesen zu können.

Jede Form des Bedienerkomforts wird systematisch vermieden:

• Eine Verlinkung im Dokument fehlt völlig. Es gibt sie weder im Inhaltsverzeichnis, noch bei den Anhängen und Fußnoten noch im Text.
• Das Drucken ist verboten, das Kopieren ebenso.
• Ein Öffnen in der Standardvorschau des Betriebssystems ist nicht möglich.
• Ein gutes Literaturverzeichnis, handlungsleitende Anhänge und eine Begründung und Erläuterung der Anforderungen fehlen.

Inhalt und Struktur

Es hat einen Grund, dass es Normen gibt, wie man Normen schreibt. Doch die UL 2900 scheitert bereits vorher:

• Teilweise sind die Inhalte falsch. Verlinkungen stimmen nicht, Referenzen sind falsch.
• Der Aufbau entbehrt einer logischen Struktur.
• Der angeblich gleiche Aufbau der UL 2900-1 und der UL 2900-2-1 wird an mehreren Stellen durchbrochen.
• Dass man keine Kapitel mit nur einem Unterkapitel verwenden soll, lernen die Studierenden normalerweise im ersten Proseminar.
• Es ist nicht nachvollziehbar, weshalb die Autoren genau die Anforderungen herausgepickt haben, die jetzt in der Norm zu finden sind. Das betrifft bei Weitem nicht nur die o.g. und willkürlich erscheinenden Forderungen nach einer ISO 13485 und fünf Millionen Testfällen. Im Proseminar lernen Studenten auch Quellen mit Begründungen für solche Angaben zu nennen – es sei denn sie sind frei erfunden…
• Die innere Logik von Aufzählungen wird verletzt. Teilweise wechseln Anforderungen mit Erklärungen, also dem, was man in einer ISO-Norm als „Note“ bezeichnen würde.
• Bessere weil vollständigere und systematischere Best Practice Guidances wie der „Testing Guide des Open Web Application Security Project (OWASP), kurz OTG, wie der OWASP Mobile Security Testing Guide, der OWASP Application Security Verification Standard (ASVS) oder das Web Application Hacker’s Handbook (WAHH) ignoriert der UL 2900.

Fazit

Man kann den Standard lesen, um eigene Checklisten zu ergänzen. Man kann ihn als abschreckendes Beispiel für eine schlampig geschriebene Norm nutzen. Aber der UL 2900 reflektiert nur teilweise den Stand der Technik – weder den der IT-Security, noch den von stringenten Normen. Sparen Sie sich den Kauf.