Ihre CRA-Dokumentation ist größtenteils schon geschrieben

Ein Team, das sich zum ersten Mal mit der technischen CRA-Dokumentation befasst, kommt in aller Regel zum selben Schluss. Dutzende geforderter Dokumente, das Produkt hat keines davon, also muss jemand für mehrere Monate abgestellt werden. Diese Lesart führt zu einem Plan, der sich über den Ort der eigentlichen Arbeit täuscht. Die Nachweise, welche die Dokumentation benötigt, liegen größtenteils bereits in der Entwicklungsorganisation, in Architekturdiagrammen, Prüfberichten, Release Notes, Benutzerhandbüchern und Bedrohungsmodellen. Was fehlt, ist der Nachweis, der jedes dieser Dokumente mit der Anforderung verbindet, die es erfüllt. Die technische Dokumentation ist zuerst eine Zuordnungsleistung und erst danach eine Schreibleistung. Wer diese Reihenfolge vertauscht, verbraucht das Teuerste, was ein Team besitzt, nämlich die Zeit der einen Person, die sowohl das Produkt als auch die Verordnung versteht.

Dieser Beitrag behandelt, was die Verordnung von der Dokumentation nachgewiesen haben will, warum die Zuordnung schwieriger ist als das Schreiben, und warum eine Lückenliste, die vor der Zuordnung vorhandener Nachweise entsteht, das Team dazu bringt, bereits vorhandene Dokumente neu zu verfassen. Er baut auf den Nachweisanforderungen der technischen Dokumentation auf, die den geforderten Inhalt behandeln, sowie auf der Abhängigkeitskette der Artefakte, die zeigt, wie die Dokumente einander speisen.

Die Einheit der Prüfung ist die Anforderung

Anhang VII legt fest, was die technische Dokumentation enthalten muss. Eine allgemeine Beschreibung des Produkts, seine Konzeption und Entwicklung, die Cybersicherheits-Risikobewertung, die Liste der angewandten harmonisierten Normen sowie die Berichte über die durchgeführten Prüfungen. Als Packliste gelesen wirkt das wie eine Menge zu erstellender Dateien.

Artikel 31(2) liefert den Rahmen, auf den es stärker ankommt. Die Dokumentation muss die Informationen enthalten, die erforderlich sind, um die Konformität mit den grundlegenden Anforderungen in Anhang I nachzuweisen. Das tragende Wort ist "nachweisen". Ein Ordner, der jedes Dokument der Anhang-VII-Liste enthält, scheitert dennoch, wenn nichts darin erkennbar macht, welcher Anforderung jedes Dokument dient.

Anhang I Teil I(2) macht das konkret. Die Anforderungen unter (a) bis (m) gelten auf Grundlage der Risikobewertung, die nach Artikel 13(3) in der Verantwortung des Herstellers liegt. Jede Anforderung ist entweder anwendbar, dann braucht die Dokumentation einen Umsetzungsverweis, oder nicht anwendbar, dann braucht sie eine Begründung. Teil I(1) und Teil II gelten ausnahmslos. Eine prüfende Stelle arbeitet diese Liste Punkt für Punkt ab und stellt an jeder Station dieselbe Frage, nämlich wo dies erfüllt ist und wodurch. Die Aufgabe der technischen Dokumentation besteht darin, diese Frage dreizehnmal zu beantworten, ohne dass die lesende Person suchen muss.

Deshalb ist die Anzahl der Dokumente ein schlechtes Fortschrittsmaß. Zwanzig hochgeladene Dateien ohne Zuordnung zu Anforderungen weisen nichts nach. Sechs zugeordnete Dateien können sehr viel nachweisen.

Die meisten Eingangsdokumente existieren bereits

Die Struktur von prEN 40000-1-2 macht das deutlich, weil sie die Artefakte in Eingangs- und Ausgangsdokumente trennt.

Die Eingangsdokumente sind überwiegend gewöhnliche Entwicklungsunterlagen. Allein Abschnitt 6.2 verlangt eine Dokumentation der funktionalen Anwendungsfälle, eine Dokumentation der Nutzertypen, eine Dokumentation zu Marktsegmenten und vergleichbaren Produkten, ein Architektur- oder Datenflussdiagramm des Produkts einschließlich sämtlicher Schnittstellen sowie eine Dokumentation der vorhandenen Funktionen, gestützt auf Produktfotos oder andere visuelle Nachweise, soweit verfügbar. Kein Hersteller, der tatsächlich ein Produkt ausgeliefert hat, verfügt über nichts davon. Es existiert als Confluence-Bereich, als eingechecktes Diagramm im Repository, als Onboarding-Präsentation, als Produkthandbuch, als Ordner mit Fotos aus dem Prüflabor.

Die Ausgangsdokumente sind die Artefakte, die tatsächlich erstellt werden müssen. Die Produktkontextdokumentation, die Risikoakzeptanzkriterien, die angewandte Methodik, die Liste der identifizierten und bewerteten Risiken, die Behandlungsentscheidungen mit Begründung, die Anwendbarkeitstabelle zu Anhang I, die festgelegte Überprüfungsregelmäßigkeit. Das ist die eigentliche Konformitätsarbeit, und sie setzt auf den Eingangsdokumenten auf.

Der Katalog umfasst 88 Artefakte über Abschnitt 6, Abschnitt 7 und die Konformitätsartefakte hinweg. Alle 88 zu Projektbeginn als leer zu behandeln ist der Fehler, denn es bläht den scheinbaren Aufwand auf, indem es Nachweise mitzählt, die das Unternehmen bereits besitzt, und es lenkt das Team schlimmstenfalls dazu, neu zu schreiben, was es hätte zitieren können.

Warum sich die Zuordnung der Handarbeit entzieht

Wäre die Zuordnung ein Nachschlagevorgang, wäre sie Sachbearbeitung und längst überall automatisiert. Drei Dinge machen sie schwieriger.

Dokumente bedienen selten nur einen Kontrollpunkt. Ein kombiniertes Architektur- und Bedrohungsmodellierungsdokument betrifft die Schnittstellendokumentation in Abschnitt 6.2, die dokumentierte Cybersicherheitsarchitektur in Abschnitt 7.4 sowie Teile der Asset- und Bedrohungsliste, die in die Risikobewertung einfließt. Wer es einem einzigen Kontrollpunkt zuordnet und weitergeht, lässt die beiden anderen leer erscheinen, obwohl sie es nicht sind.

Die Abdeckung ist abgestuft und nicht binär. Ein Penetrationstestbericht, der die Netzwerkschnittstellen eines Geräts abdeckt, deckt einen Verifikationskontrollpunkt teilweise ab und lässt die lokalen und physischen Schnittstellen unberührt. Dies als vollständig erfüllt zu erfassen ist der Fehlermodus, der unsichtbar bleibt, bis eine prüfende Stelle nachhakt, und in diesem Moment gerät die Glaubwürdigkeit der Dokumentation in jedem anderen Punkt ebenfalls ins Wanken. Teilweise Abdeckung als teilweise erfasst ist ein offener Punkt. Teilweise Abdeckung als vollständig erfasst ist eine Falschdarstellung.

Der Umfang verschärft beides. Ein vierzigseitiges Dokument gegen einen Katalog aus 88 Artefakten zu lesen und für jeden berührten Kontrollpunkt zu entscheiden, wie weit es trägt, füllt den größten Teil eines Arbeitstags. Die dafür qualifizierte Person ist dieselbe, die die Risikobewertung durchführen sollte, und es liegen üblicherweise mehrere Dutzend Dokumente vor.

Die Beurteilung selbst muss beim Hersteller bleiben. Artikel 13(3) weist die risikobasierte Entscheidung dem Hersteller zu und sonst niemandem. Was hier automatisiert, kann vorschlagen und gewichten, und die Bestätigung muss eine menschliche Handlung sein, die als solche aufgezeichnet wird.

Wie das im CRA Portal funktioniert

Das Nachweisfeld im Produktarbeitsbereich führt den Zuordnungsschritt bewusst vor dem Entwurfsschritt aus.

Dokumente gehen als Stapel hinein, bis zu fünf Dateien mit je 5 MB. PDFs werden dem Bewertungsmodell als Dateibestandteile übergeben, textartige Dokumente lokal dekodiert, und Bilder in PNG, JPG, WEBP und GIF gehen als visuelle Eingabe ein. Gerade dieser letzte Weg macht ein Architekturdiagramm, ein Geräte-Typenschild oder einen Konfigurationsscreenshot in der Form als Nachweis nach Abschnitt 6.2 verwendbar, in der er ohnehin schon vorliegt, statt dass jemand ihn erst in Fließtext übertragen muss.

Jedes Dokument kommt zugeordnet zu allen Kontrollpunkten zurück, denen es plausibel dient, mit einem Konfidenzwert, einer Abdeckungsbewertung von erfüllt oder teilweise und einer Begründung in einem Satz je Kontrollpunkt. Derselbe Durchlauf entnimmt den Produktnamen oder die Modellbezeichnung, die das Dokument beschreibt, und bietet ihn mit einem Klick als Produktnamen des Arbeitsbereichs an, was zufällig das erste Feld ist, das ein neuer Arbeitsbereich benötigt.

In diesem Moment wird noch nichts in die Bewertung geschrieben. Die Analyse liegt auf einem Entwurfsdatensatz, wird je Dokument zur Durchsicht vorgelegt, und erst die Bestätigung durch eine administrierende Person erzeugt die Nachweiseinträge. Unbestätigte Entwürfe verfallen nach 24 Stunden und werden entfernt. Der Vorschlag gehört der Maschine, die Aussage bleibt beim Hersteller, und die Bestätigung wird auditiert.

Erst wenn die Zuordnung bestätigt ist, bedeutet die verbleibende Menge etwas. Von dort aus entwirft der Arbeitsbereich jedes fehlende Artefakt aus Abschnitt 6 und 7 nacheinander, übernimmt jedes bei der Erzeugung, speichert nach jedem einzelnen, überspringt die Artefakte, die manuelle Eingaben erfordern, und listet sie für das Team auf. Der Lauf lässt sich anhalten, der Fortschritt bleibt erhalten. Daneben löst eine Übersicht auf, was über alle drei Dimensionen der Vollständigkeit hinweg offen ist, nämlich noch zu entwerfende Artefakte, noch nicht bestandene Akzeptanzkriterien und Kontrollpunkte ohne auditfähigen Nachweis.

Diese Reihenfolge ist der ganze Punkt. Eine Lückenliste, die vor der Zuordnung vorhandener Nachweise entsteht, misst das Fehlen der Ablage und nicht das Fehlen der Nachweise, und jede Stunde Arbeit, die sie erzeugt, ist eine Stunde, in der etwas neu geschrieben wird, das das Unternehmen bereits einmal erstellt hat. Zuerst zuordnen, die Abdeckung genau erfassen einschließlich der Stellen, an denen sie teilweise ist, und die Entwurfsarbeit auf das richten, was tatsächlich fehlt. Der Anhang-VII-Erklärtext behandelt, was die fertige Dokumentation enthalten muss, und der Beitrag zur Risikobewertungsmethodik zeigt, wie die Ausgangsdokumente entstehen, sobald die Eingangsdokumente vorliegen.