Was eine leere Risikobeurteilung auslässt

Es gibt ein ernsthaftes Argument dagegen, irgendjemandem eine vorausgefüllte CRA-Risikobeurteilung in die Hand zu geben. Artikel 13 Absatz 2 verpflichtet den Hersteller, die Cybersicherheitsrisiken des Produkts zu beurteilen, und Artikel 13 Absatz 3 macht diese Beurteilung zur eigenen Festlegung des Herstellers, dokumentiert und über den Unterstützungszeitraum hinweg aktuell gehalten. Diese Beurteilung entscheidet, welche der Anforderungen aus Anhang I Teil I Nummer 2 für Ihr Produkt gelten und welche Sie begründet ausschließen. Wer einem Team ein Dokument mit fertigen Antworten gibt, gibt ihm einen Weg, genau den Schritt zu überspringen, der rechtlich trägt.

Dieses Argument benennt ein echtes Risiko. Es behandelt zugleich das leere Dokument als neutral, und an dieser Stelle bricht die Überlegung. Beide Ausgangspunkte tragen eine Verzerrung. Nur einer davon zeigt sie Ihnen.

Dieser Beitrag behandelt, wofür ein leeres Blatt selektiert, wozu ein Entwurf berechtigterweise dient, und welche einzelne Eigenschaft einen nützlichen Startpunkt von einem Konformitätsrisiko trennt.

Wofür das leere Blatt selektiert

Bitten Sie ein Team, das dies zum ersten Mal tut, die Bedrohungen für sein Produkt aufzulisten. Die Liste kommt schnell und enthält die Bedrohungen, über die dieses Team ohnehin spricht: jene aus selbst erlebten Vorfällen, aus den Komponenten, die den Anwesenden gehören, und aus den Angriffsarten, die kürzlich in der Presse standen. Es ist Erinnerung im Gewand einer Analyse.

Die Lücken dieser Liste sind vorhersehbar, denn sie sind struktureller Art.

Bedrohungen für die Produktteile, für die niemand im Raum zuständig ist. Das Firmware-Team nennt Firmware-Bedrohungen. Die Schnittstelle zwischen Gerät und Hersteller-Cloud gehört zwei Teams und wird von keinem beurteilt.

Bedrohungen über den Außerbetriebnahmepfad. Kaum jemand hält fest, was mit Zugangsdaten und gespeicherten Daten geschieht, wenn das Produkt weiterverkauft oder verschrottet wird, denn an dieser Phase wird niemand gemessen. Anhang I Teil I Nummer 2 fragt trotzdem danach, und die Pflicht, die Vertraulichkeit gespeicherter Daten zu schützen, gilt weiter, nachdem das Gerät den Kunden verlassen hat.

Bedrohungen der Verfügbarkeit, die erst in der Fläche sichtbar werden. Ein Gerät, das den Backend-Dienst nicht erreicht, ist ein Supportfall. Alle Geräte, die im selben Moment neu verbinden, sind ein anderer Fehlerfall, und ein Team, das pro Gerät denkt, übersieht ihn.

Bedrohungen, die das Team stillschweigend jemand anderem zugeordnet hat. Der Klassiker ist die Zulieferkomponente mit einer bekannten, nicht behebbaren Schwäche. Sie fehlt, weil ihr Aufschreiben nach zusätzlicher Arbeit aussah.

Diese Lücken gehen auf eine Beurteilung zurück, deren Umfang davon bestimmt wurde, wer zufällig im Raum saß. Das leere Blatt bestätigt diesen Umfang und erzeugt ein Dokument, das vollständig wirkt, weil jede Zeile darin von jemandem gedacht wurde.

Produktarchetypen teilen mehr Angriffsfläche, als Teams erwarten

Ein Entwurf kann überhaupt helfen, weil die Angriffsfläche eines Produkts aus seiner Art folgt. Wem das Produkt gehört, zählt weit weniger als seine Bauform.

Zwei Industriesteuerungen unabhängiger Hersteller haben nahezu dasselbe Bestandsverzeichnis schützenswerter Werte. Firmware mit einer Boot-Kette. Ein Engineering-Zugang, über den Logik geladen werden kann. Ein Feldbus, der Befehle an Antriebe trägt. Ein Steuerungsprogramm, dessen Integrität das physische Verhalten bestimmt. Ein sicherer Zustand, der halten muss, wenn das Netz ausfällt. Die konkreten Umsetzungen unterscheiden sich erheblich. Die Liste der lohnenden Angriffsziele bleibt nahezu konstant.

Dasselbe gilt für eine Smart-Home-Zentrale, bei der stets die Frage entscheidend ist, ob ein Entriegelungsbefehl einer Person oder einer Position im Netz zugeordnet wird. Es gilt für ein Smart-Meter-Gateway, wo das Schlüsselmaterial im Sicherheitsmodul und die Gesamtwirkung eines flottenweiten Befehls die beiden wichtigsten Punkte sind. Es gilt für einen mobilen Roboter, wo die Teleoperationsverbindung und das Verhalten bei Verbindungsverlust das physische Risiko tragen.

Hier verdient Inhalt auf Archetypebene seinen Platz. Er zählt die Fragen auf, die ein Produkt dieser Bauart beantworten muss, einschließlich der vier oder fünf, die ein Team beim ersten Mal verlässlich überspringt.

Ein Startpunkt trägt Behauptungen, die Sie erledigen müssen

Hilfreich ist die Sicht, dass ein Startpunkt Behauptungen trägt, die Sie erledigen müssen.

Nehmen Sie die Manipulation von Daten während der Übertragung auf einem lokalen Kopplungsfunk, angewandt auf eine Smart-Home-Zentrale. Niemand außerhalb Ihres Teams kennt Ihren Funk, Ihren Kopplungsablauf oder Ihren Wiedereinspielschutz, also klärt die Zeile für sich genommen nichts. Ihr Wert liegt darin, dass Ihr Team sie nun beantworten muss, und es gibt nur drei vertretbare Ausgänge. Die Bedrohung trifft zu, und hier ist die Maßnahme, die sie adressiert, was einen Umsetzungsnachweis erzeugt, den die technische Dokumentation ohnehin braucht. Oder sie trifft nicht zu, und hier ist der Grund, was genau die Begründung erzeugt, die Anhang I Teil I Nummer 2 für eine nicht zutreffende Anforderung verlangt. Oder niemand weiß es, und das ist der wertvollste der drei Ausgänge, denn eine Unklarheit, die während der Beurteilung auftaucht, kostet ein Gespräch, und eine Unklarheit, die nach dem Inverkehrbringen auftaucht, kostet eine Meldung nach Artikel 14.

Jeder dieser Ausgänge bringt die Dokumentation voran. Ein leeres Blatt liefert einen vierten, bei dem die Frage ungestellt bleibt, nie im Dokument erscheint und ihr Fehlen nirgends vermerkt ist.

Dieselbe Überlegung gilt für Standardwerte für Eintrittswahrscheinlichkeit und Auswirkung in einem Startpunkt. Die Standardwerte treffen für Ihren Einsatz nicht zu, und genau das ist der Zweck: Eine falsche Zahl lädt zum Widerspruch ein, während ein leeres Feld zur Zustimmung einlädt. Ein Team, das eine Schnittstelle, die in seiner Architektur nachweislich nicht erreichbar ist, mit mittlerer Wahrscheinlichkeit bewertet sieht, korrigiert die Bewertung. Dasselbe Team geht an einer unbewerteten Zeile vorbei.

Die eine Eigenschaft, die das Ganze tragfähig macht

All das bricht zusammen, sobald vorbelegte Inhalte ohne Entscheidung übernommen werden können. Ein Startpunkt, der stillschweigend auf Ihren Konformitätsstand einzahlt, richtet echten Schaden an, denn er verwandelt eine ungeprüfte Annahme in scheinbaren Nachweis.

Entscheidend ist deshalb dieser Grundsatz: Nichts, was eine Vorlage liefert, darf zählen, bevor ein Mensch es bestätigt hat.

Praktisch heißt das, dass vorbelegte Werte unbestätigt ankommen und außerhalb Ihrer Abdeckungsmessung bleiben, bis jemand sie bestätigt. Es heißt, dass eine vorgeschlagene Einstufung als Vorschlag ohne Entscheidungszeitpunkt hinterlegt wird, sodass die Prüfung vor dem Inverkehrbringen weiterhin verlangt, dass ein Mensch in die Listen aus Anhang III und Anhang IV schaut und sich festlegt. Es heißt, dass die Risikokriterien erkennbar Standardwerte sind, vorhanden, damit die Bewertung vom ersten Tag an dokumentierte Skalen hat, mit den Skalen vor den Bewertungen.

Die Einstufung verdient dabei besondere Sorgfalt, denn sie ist das eine Feld, in dem eine falsch übernommene Antwort teuer wird. Nach Artikel 32 bestimmt die Klasse das Verfahren. Ein Produkt der Standardklasse darf sich selbst bewerten. Ein Produkt der Klasse II nach Anhang III benötigt die Einbindung einer notifizierten Stelle. Ein kritisches Produkt nach Anhang IV benötigt ein Zertifizierungsschema oder einen gleichwertigen Weg. Ein Team, das eine vorgeschlagene Klasse ungeprüft übernimmt, kann Monate auf dem falschen Konformitätspfad verbringen und den Fehler genau dann entdecken, wenn seine Korrektur am teuersten ist. Keine Vorlage sollte diese Entscheidung stillschweigend treffen.

Es gibt hier einen berechtigten Einwand. Auch unbestätigter Inhalt wirkt als Anker, und ein Team, das mit zehn Bedrohungen beginnt, könnte bei zehn stehen bleiben. Das trifft zu, und deshalb muss ein Startpunkt sich als Archetyp zu erkennen geben, und deshalb wiegen die Aufforderungen, nach dem Fehlenden zu fragen, schwerer als die bereits ausgefüllten Zeilen. Die vertretbare Aussage ist bescheiden: Ein Entwurf tauscht eine unsichtbare Verzerrung gegen eine sichtbare, und über eine sichtbare lässt sich streiten.

Was das für die Arbeit bedeutet

Die Risikobeurteilung bleibt Ihre. Artikel 13 Absatz 3 verschiebt sich nicht, die Festlegung, welche Anforderungen aus Anhang I Teil I Nummer 2 gelten, treffen und verteidigen Sie, und kein Entwurf ändert etwas an Ihrer Verantwortung.

Was ein Entwurf ändert, ist die erste Stunde. Das Team verbringt sie im Widerspruch zu einer Liste, die den Außerbetriebnahmepfad, die Schnittstelle ohne Zuständigen und den erst in der Fläche sichtbaren Fehlerfall bereits enthält. Das Ergebnis ist eine kürzere Liste offener Fragen und eine längere Liste begründeter Entscheidungen, und die zweite Liste ist das, was die technische Dokumentation nach Anhang VII am Ende tragen muss.

Wir haben Startpunkte für zehn verbreitete Produktarten veröffentlicht, jeweils mit der Einstufung und dem daraus folgenden Konformitätsweg, einem ersten Bestandsverzeichnis, einer Bedrohungsanalyse, die jede Bedrohung an die Anforderung aus Anhang I Teil I knüpft, die sie belegt, sowie den Standardskalen für die Bewertung. Sie finden sie auf der Vorlagenseite, und jeder davon ist zum Widersprechen gebaut. Wenn Ihr Produkt keinem davon nahekommt, ist auch das eine nützliche Information über Ihren Umfang, und das Einstufungswerkzeug ist dann der bessere Anfang.

Eine gute erste Risikobeurteilung bemisst sich daran, wie viele Dinge das Team dabei entdeckt hat, die es nicht wusste.