Ein Musterbeispiel für gelungene CRA-Dokumentation [German version]

Den Cyber Resilience Act erfüllen UND Kunden in kritischen Infrastrukturen glücklich machen

Bildquelle: KI-generiert (Midjourney)

Der EU Cyber Resilience Act (CRA) zwingt Produkthersteller, Security bei der Entwicklung zu berücksichtigen, Prozesse für die Bereitstellung von Security Advisories und -Updates einzurichten und ihren Kunden Benutzeranweisungen für Security bereitzustellen. Derzeit beobachten viele Produkthersteller nervös ihre Konkurrenten und fragen sich, wie alle anderen das Thema Product Security wohl angehen werden.

Die “information and instructions to the user“, eines der erforderlichen Dokumente für die Einhaltung des CRA und das einzige, das den Käufern des Produkts direkt ausgehändigt wird, hat bisher nicht viel Aufmerksamkeit bekommen. Wenn Sie aber ein Produkthersteller sind, der an Betreiber kritischer Infrastrukturen bzw. von Anlagen mit Operational Technology (OT) verkauft, kann genau dieses Dokument den Unterschied machen zwischen einem missmutigen Kunden, der nicht für Cybersecurity zahlen will, und einem zufriedenen, zahlenden Kunden.

Dieser Text liefert ein konkretes Beispiel dafür, wie man die „information and instructions to the user“ gut und effizient umsetzen kann.

Das Problem mit der Product Security

Wenn Sie Betreiber von kritischen Infrastrukturen nach der Produktsicherheit fragen, hören Sie Folgendes: „Wenn ein Hersteller mit mir über Security sprechen will, habe ich immer den Verdacht, dass er mir neue Hard- oder Software andrehen will.”

Und das hier sagen Produkthersteller: “Wir würden ja gern alle Security der Welt einbauen — wenn unsere Kunden bereit wären, dafür zu bezahlen…”

Oder, auch beliebt:

“Wir haben eine “secure” Version unseres Produkts und eine normale. Und jetzt raten Sie, welche Version die Kunden kaufen!”

Klingt, als ginge es um Geld, was? Niemand will für Security bezahlen. Die Produkthersteller werden sie nicht umsonst einbauen, und die Anlagenbetreiber wollen die zusätzlichen Kosten auch nicht tragen.

Und Geld ist definitiv ein Teil des Problems. Aber insbesondere bei kritischen Infrastrukturen und OT ist das nicht das ganze Problem. Security von Produkten wird Betreiber kritischer Infrastrukturen nur dann zufrieden stellen, wenn sie auch die zweite Hälfte des Problems löst. Und die hat etwas mit Kommunikation zu tun.

Die Cybersecurity-Kommunikationspyramide

Ich möchte Ihnen die Kommunikationspyramide der Cybersicherheit vorstellen. Sie ist ein Ergebnis der Security by Design-Forschung, die ich in den letzten drei Jahren im Rahmen meines Promotionsprojekts durchgeführt habe.

Wie Sie Cybersicherheit angemessen kommunizieren, hängt von Ihrer Kommunikationsabsicht ab. Je nachdem, wen Sie ansprechen wollen, benötigen Ihre Adressaten unterschiedliche Informationen.

An der Spitze der Pyramide wird die geringste Menge an Informationen benötigt. Es braucht nicht viel, um einem privaten Verbraucher, der ein Produkt nur sicher benutzen will, ausreichende Cybersecurity-Informationen zu vermitteln. Eine Liste mit Security-Merkmalen ist in Ordnung. Ein Cybersecurity-Kennzeichen, das die Erfüllung dieser Merkmalsliste sicherstellt, ist ebenfalls in Ordnung. Dafür sind all die IoT- Labels für Verbraucher gedacht, die momentan weltweit entstehen.

Eine Autorität, die sich für die Security Ihres Produkts interessiert, wird mehr wissen wollen (Betreiber kritischer Infrastrukturen können das aus eigener Erfahrung wahrscheinlich bestätigen). Eine Autorität kann eine externe Behörde oder Ihr eigenes Management sein, aber alle Autoritäten haben gemeinsam, dass sie nicht nur eine Liste von Security-Merkmalen sehen wollen, sondern die Entscheidungen dahinter verstehen. Das funktioniert nur, wenn sie die Gründe kennen, warum bestimmte Security-Merkmale ausgewählt wurden (und andere nicht).

Und dann gibt es noch die unterste Ebene der Pyramide. Am Fuße der Pyramide müssen Ihre Adressaten selbst Security- Entscheidungen treffen. Dafür kann es zwei Gründe geben, die oft gleichzeitig zutreffen:
Erstens, weil sie selbst reguliert sind, wie viele Betreiber kritischer Infrastrukturen. Sie müssen ihre eigenen Bedrohungsmodelle und Risikobewertungen durchführen und ihre Security-Entscheidungen selbst Behörden erklären.
Zweitens, weil sie oft einen großen Teil des Engineerings selbst erledigen. Die Produkte, die sie von Ihnen kaufen, sind nur Komponenten, die in komplexe Systeme integriert werden (industrielle Automatisierungs- und Steuerungssysteme, um genau zu sein). Diese komplexen Systeme stellen die Erbringungen genau der Dienstleistung sicher, die die Anlage zur kritischen Infrastruktur macht.

Diese Käufer Ihrer Produkte sind keine Verbraucher. Betrachten Sie sie lieber als Mit-Entwickler (co-engineers). Sie müssen selbst Security-Entscheidungen treffen, oft in Zusammenarbeit mit Ihnen, ihrem Produktlieferanten. Und dafür brauchen sie nicht nur Security-Features. Sie brauchen Optionen für Security-Features, und sie brauchen genug Kontext, um zu entscheiden, welche Features sie für ihre Einsatzumgebung wählen sollten.

Dies, liebe Produkthersteller, ist ein wichtiger Grund, warum die Anlagenbetreiber scheinbar nicht für Security bezahlen wollen. Sie wollen vielleicht nicht für Ihre „secure Version“ ihres Produkts zahlen, das alle Security-Features auf dem Planeten hat (von denen sie die meisten nicht brauchen). Aber sie sind wahrscheinlich auch mit Ihrer „unsicheren“ Version nicht zufrieden. Sie brauchen etwas dazwischen, sie brauchen Optionen.

Diese Zielgruppe, die der Co-Ingenieure, wird oft übersehen. Sie sind in der Regulierung unterrepräsentiert, die sich in erster Linie auf die Verbraucher konzentriert — und das ist für IoT in Ordnung. Aber für die Zielgruppe der kritischen Infrastrukturen, die zufällig auch viel Operational Technology (OT) enthalten, müssen Product Security für die Zielgruppe der Co-Ingenieure brauchbar sein.

Und das kann man in großen Teilen lösen, indem man die Kommunikation der Produktsicherheit verändert.

Security gut an Betreiber kritischer Infrastrukturen vermitteln

Wie kommuniziert man also Cybersecurity an Co-Ingenieure? Wie macht man die Betreiber kritischer Infrastrukturen glücklich?

Ehrlich gesagt, ist das gar nicht so schwer. Anlagenbetreiber haben im Wesentlichen drei Forderungen:

1. Sagt uns, wo wir hinschauen sollen: Betreiber wollen wissen, welche Ihrer der fünftausend Konfigurationsoptionen für Security einen Unterschied machen. Machen Sie sie so einfach sichtbar wie eine rote Stecknadel auf einer Landkarte.
2. Lasst uns auswählen: Anlagenbetreiber sind Risikoeigentümer. Sie müssen Verantwortung für ihr eigenes Anlagenrisiko übernehmen, and diese Anlage besteht aus so viel mehr als nur Ihren Produkten. Machen Sie Ihnen das Leben leichter, indem Sie keine Security-Feaures, sondern Optionen anbieten.
   Das ist übrigens auch Teil des Problems, das wir momentan mit Security Leveln in der ISA/IEC 62443 haben: Sie helfen Produktherstellern um einfach lesbare Zertifikate für bestimmte Security-Level zu bekommen, aber für Anlagenbetreiber sind sie nicht feingranular genug. Betreibern hilft es nicht, wenn sehr verschiedene Maßnahmen in einem Security-Level zusammengefasst werden — sie müssen gezielt auswählen können, was sie brauchen.
3. Helft uns bei der Auswahl: Und wenn Sie dann alle Security-Merkmale gekennzeichnet und die verschiedenen Optionen aufgeführt haben….dann haben Sie die Anlagenbetreiber ziemlich sicher komplett abgehängt. Lassen Sie sie sie mit diesem Wust an Informationen also nicht allein. Bieten Sie Anleitungen und Empfehlungen an, welche der Security-Optionen in welcher Einsatzumgebung sinnvoll sind.

Dokumente, die man für die Erfüllung des CRA braucht

Wenn (verständlicherweise!) Ihr Hauptanliegen als Produkthersteller die Einhaltung des CRA ist — wie können Sie compliant sein und dabei möglichst gut doe Cybersecurity-Bedürfnsise Ihrer Kunden im Bereich kritischer Infrastrukturen / OT erfüllen?

Hier sind die drei Dokumente, die Sie zur Erfüllung des CRA brauchen:

1. Sie benötigen eine EU-Konformitätserklärung, damit Sie das CE-Kennzeichen an Ihr Produkt anbringen dürfen. Das ist nicht viel, nur eine Seite, die besagt, dass Sie die CRA-Vorgaben erfüllen.
2. Sie brauchen eine technische Dokumentation, in der Sie darlegen, wie Sie die CRA-Vorgaben erfüllen.
3. Und sie brauchen eine Benutzeranleitung, die “information & instructions to the user”.

Betrachten wir das Ganze kurz aus der Perspektive der Cybersecurity-Kommunikationspyramide. Welchem Kommunikationsziel dient welches Dokument?

Für das mittlere Dokument ist das einfach. Die technische Dokumentation ist für die Marktaufsichtsbehörde bestimmt, um zu belegen, dass Ihr Produkt die CRA-Anforderungen tatsächlich erfüllt — das wäre die mittlere Ebene (B) der Pyramide.

Die Dokumente auf der linken und rechten Seite werden an den Anwender weitergegeben. Aber wo sind die Anwender in unserer Kommunikationspyramide?

Das hängt von Ihrem Produkt ab. Wenn Sie ein Endverbraucherprodukt für Privathaushalte haben, finden Sie sich an der Spitze der Pyramide wieder: Sie kommunizieren Security an Verbraucher, dafür müssen Sie nicht viele Informationen vermitteln. Wenn Sie aber ein Produkt haben, das in Anlagen und kritischen Infrastrukturen eingesetzt wird, befinden Sie sich am breiten Fuß der Pyramide. In diesem Fall kommunizieren Sie eher mit Co-Ingenieuren die sich ebenfalls mit der Security befassen müssen —dafür muss Ihre Kommunikation mehr Informationen vermitteln. Und das ist der Fall, den wir uns jetzt ansehen werden.

Hier ist eine Übersicht, welche Informationen in jedem der CRA-Dokumente stecken müssen:

Wie bereits erwähnt, ist die EU-Konformitätserklärung nicht umfangreich. Sie verweist lediglich auf die Vorschriften und harmonisierten Normen, die Sie für dieses Produkt einhalten. Die im CRA aufgeführten “essential requirements” sind eher vage. Harmonisierte Normen sind europäische Normen, die die so genannte Konformitätsvermutung erfüllen: Wenn Sie diese Normen erfüllen, können Sie sicher sein, dass Sie auch die essential requirements des CRA erfüllen.

Die technische Dokumentation belegt, dass Sie die “essential requirements” des CRA erfüllen. Wenn Sie eine Bewertung durch Dritte vornehmen lassen, werden diese die technische Dokumentation prüfen. Auch die Marktaufsichtsbehörden können diese Unterlagen jederzeit anfordern. Die technische Dokumentation enthält eine ausführliche Produktbeschreibung, Ihr Verfahren zum Umgang mit Schwachstellen und Ihre Risikoanalyse, aus der hervorgeht, welche “essential requirements ” Ihr Produkt erfüllt.

Die Nutzerinformationen (information and instructions to the user) sind im Wesentlichen Auszüge aus der technischen Dokumentation, um die wichtigsten Fragen der Produktanwender zu beantworten. Sie ahnen es wahrscheinlich bereits: Dieses Dokument ist der beste Ort, um unser Kommunikationsproblem zu lösen.

Wenn vom CRA die Rede ist, geht es eigentlich nie um die information and instructions to the user. Sie werden gänzlich unterschätzt, wahrscheinlich weil die meisten Menschen an Benutzerhandbücher denken, die sie sowieso nie lesen. Und wahrscheinlich wird das für bei der Cybersecurity für Verbraucherprodukte genauso sein. Aber bei Produkten, die nicht an Endverbraucher, sondern an Anlagenbetreiber vor allem in kritischen Infrastrukturen verkauft werden, kann dieses unterschätzte kleine Dokument den Unterschied machen zwischen einem grummeligen Kunden, der nicht für Cybersecurity zahlen will, und glücklichen, zahlenden Kunden.

Musterbeispiel

Und deswegen zeige ich Ihnen nun zum Abschluss ein richtig gutes Beispiel für ein gelungenes Cybersecurity-Benutzerhandbuch.

Dafür schauen wir uns unseren “Example Engineering PC EE-2024-CRA” an. Er wird von Good Practice Incorporation hergestellt. Der Name ist Programm: Good Practice, Inc. hat natürlich ein Musterbeispiel für CRA-konforme “information and instructions to the user” erstellt. Schauen wir mal rein:

Teil 1: Produktbeschreibung

Der erste Teil enthält die Produktbeschreibung, den Link zur EU-Konformitätserklärung und eine Beschreibung des Verwendungszwecks und der wesentlichen Produktfunktionen.

Good Practice, Inc. hat sich dafür entschieden, den Verwendungszweck und die wesentlichen Funktionen in Diagrammen darzustellen, was für den Leser sehr effizient ist. Das fragliche Produkt, der Beispiel-Engineering-PC, ist grün eingefärbt, und die Diagramme zeige Szenarien für die vorgesehene Verwendung — zusammen mit den Rollen, die mit dem PC interagieren sollen, den Komponenten, mit denen er verbunden werden soll, und den Protokollen, die für die verschiedenen Anwendungsfälle verwendet werden. Sie können auch Anmerkungen dazu machen, für welche Anwendungsfälle das Produkt NICHT vorgesehen ist — z. B. Fernwartung.

All dies erscheint simpel, ist aber sehr wertvoll, wenn Sie so einen Engineering PC einsetzen und versuchen herauszufinden, wie man ihn sicher nutzen kann. Ich kann nicht zählen, wie viele Stunden ich im Auftrag von Anlagenbetreibern mit Produktherstellern telefoniert habe, um herauszufinden, wie ein Produkt funktioniert und welches Protokoll für bestimmte Aufgaben verwendet wird… mit dieser Dokumentation würden alle diese Informationen einfach mit dem Produkt mitgeliefert.

Teil 2: Umgang mit Schwachstellen

Zweiter Teil: Alles, was man über den Umgang des Herstellers mit Schwachstellen wissen muss. Eine zentrale Kontaktperson, das Datum, ab dem keine Security-Updates mehr zur Verfügung gestellt werden, ein Link zur Software Bill of Materials (SBOM) und Informationen darüber, wie die Installation von Security-Updates funktioniert.

(Der „Link zur SBOM“ ist natürlich viel leichter gesagt als getan… Sie ist ein wichtiger Teil der Dokumentation, die allerdings mindestens einen eigenen Text verdient hätte. Nur so viel: Um nützlich zu sein, sollte die SBOM natürlich maschinenlesbar sein — in einem Format, das der Kunde verarbeiten kann).

Aber schauen wir uns doch einmal die Informationen an, wie die Installation von Sicherheitsupdates funktioniert. Spätestens seit dem Crowdstrike-Vorfall in diesem Jahr, bei dem ein automatisch ausgeliefertes, aber fehlerhaftes Update Windows-PCs auf der ganzen Welt zum Absturz brachte, wissen wir alle, dass es sinnvoll ist, sich über diese Update-Prozesse Gedanken zu machen.

Ähnlich wie bei den wesentlichen Funktionen und dem Verwendungszweck hat sich Good Practice Inc. dafür entschieden, die Update-Prozesse in Diagrammen zu erklären — auch hier wieder mit allen Komponenten, menschlichen Rollen und Kommunikationsprotokollen, die rund um den (grünen) Engineering-PC für das Funktionieren des Update-Mechanismus’ erforderlich sind. Auf der Grundlage dieser Informationen können die Kunden eine informierte Entscheidung treffen, wie sie Security Updates installieren möchten.

Teil 3: Cybersecurity-Risiko und -Maßnahmen

Dieser Teil ist entscheidend. Denn erinnern Sie sich an die drei Aspekte, die Anlagenbeteiber glücklich machen? Einer davon war die Hilfestellung bei der Wahl der Security-Features.

Natürlich hängt die sinnvolle Auswahl der Maßnahmen von der Einbauumgebung des Produkts in der Anlage ab… Dies könnte für Produkthersteller nun als Ausrede dienen: „Ich weiß nichts über Ihre Einbauumgebung, also müssen Sie selbst beurteilen, welche Security-Maßnahmen für Sie wichtig sind”. Aber natürlich nicht für Good Practice Inc.! Good Practice Inc. hat sich überlegt, wie mögliche Einbauumgebungen für unseren Beispiel-Engineering-PC aussehen könnten und diese in den “information and instructions to the user” zur Verfügung gestellt: Zum Beispiel könnten Kunden den PC an eine SPS im Feld ohne Netzwerkverbindung anschließen oder ihn für das Engineering über das Netzwerk oder über das Leitsystem verwenden. Und das Netzwerk könnte segmentiert oder nur ein flaches Netzwerk sein.

Der Kunde kann dann die Architektur auswählen, die seiner geplanten Verwendung des Beispiel-Engineering-PCs am nächsten kommt. Nehmen wir an, das wäre die Architektur 2b (Engineering über das Netzwerk): Dann würde er in den “information and instructions to the user” eine detailliertere Darstellung aller sicherheitsrelevanten Eigenschaften für diese ausgewählte Architektur vorfinden:

Jedes der kleinen grünen Symbole in der Dokumentation kennzeichnet eine security-relevante Eigenschaft (wir erinnern uns: die sollen ja so leicht zu erkennen sein wie rote Stecknadeln auf einer Landkarte).

Das können Eigenschaften des Engineering-PCs selbst oder um Eigenschaften der ihn umgebenden Komponenten sein, z. B. das Netzwerk, in dem er sich befindet, oder der Ingenieur, der ihn benutzt.

Schauen wir uns eine der Eigenschaften des Beispiel-Engineering-PCs genauer an, zum Beispiel den Mechanismus zur Integritätsprüfung:

Hier hat Good Practice Inc. eine Entscheidungshilfe bereitgestellt: eine Erklärung, worum es bei dieser Eigenschaft geht und warum sie security-relevant ist, realisierbare Optionen im vorliegenden Produkt und Empfehlungen, wann man welche Option wählen sollte. (Denn, wir erinnern uns: Betreiber kritischer Infrastrukturen möchten die Möglichkeit haben, ihre eigene Wahl zu treffen, gleichzeitig aber damit nicht alleingelassen werden).

Vielleicht haben Sie die roten Ausrufezeichen bemerkt? Sie kennzeichnen Optionen, die unter Security-Aspekten riskant sein können.

Diese Ausrufezeichen können auch Änderungen hervorheben, die zu einem Security-Risiko führen können — und zwar nicht nur für eine einzelne Eigenschaft, sondern für alle Eigenschaften in der gewählten Architektur:

Und schließlich wird das Bedrohungsmodell für den Example Engineering PC transparent gemacht:

Denn Betreiber kritischer Infrastrukturen müssen ja ihre eigenen Bedrohungsmodelle und Risikobewertungen durchführen — und die Bedrohungsmodelle der verwendeten Komponenten zu kennen, ist dafür eine große Hilfe. Im Idealfall können die Anlagenbetreiber sie direkt für ihre eigenen Risikobewertungen wiederverwenden.

Apropos Wiederverwendung: Wir leben im 21. Jahrhundert! Wir sind stolz darauf, dass wir bereits digitale SBOMs und digitale Schwachstellenmeldungen haben. Wir sollten also unbedingt all die Informationen, die wir jetzt gesehen haben, in einem digitalen Format bereitstellen, das Kunden direkt nutzen können. Um es klar zu sagen: Damit ist nicht ein digitales PDF gemeint, sondern ein maschinenlesbares Format wie JSON, das in die (Sicherheits-)Engineering-Tools der Anlagenbesitzer eingespeist werden kann.

Und jetzt?

Okay, das war ein kurzer Vorgeschmack auf eine bessere Zukunft der Produktsicherheit: So viele wertvolle Informationen zur Cybersicherheit könnten auf ein paar Seiten vermittelt werden! Was können Sie jetzt tun, um uns näher dorthin zu bringen? Das hängt von Ihrer Rolle ab:

Wenn Sie ein Betreiber kritischer Infrastrukturen (oder anderweitig reguliert) sind, können Sie Ihren Herstellern klar sagen, was Sie wollen und brauchen. Verlangen Sie keine Security-Features und auch nicht irgendein Security-Level. Verlangen Sie Optionen, und verlangen Sie Informationen, die Ihnen helfen, zwischen den Optionen zu wählen.

Und die andere Seite der Medaille: Seien Sie auch transparent genug in Bezug auf Ihre Installationsumgebung, damit Ihr Produktlieferant eine Chance hat, Security mit Ihnen gemeinsam — im Co-Engineering — zu entwickeln.

Wenn Sie ein Produkthersteller sind, können Sie den “information and instructions to the user” einen hohen Stellenwert einräumen, unabhängig davon, ob Sie reguliert sind oder nicht. Das Dokument ist Ihre Chance, bei Ihren Kunden zu glänzen! Sie werden Produkte herstellen inklusive Security, für die Ihre Kunden tatsächlich bezahlen — weil sie die Security an die eigene Einbauumgebung und die eigenen Bedürfnisse anpassen können und für das bezahlen, was sie wirklich brauchen.

Wenn Sie Gesetzgeber sind, können Sie sich bewusst machen, dass die überwiegende Mehrheit der Product-Security-Regulierungen für Verbraucher geschrieben wird — und das ist okay. Aber um die Situation für kritische Infrastrukturen wirklich zu verbessern, müssen Regularien so geschrieben werden, dass sie Co-Ingenieuren helfen und nicht nur Verbrauchern.