CRA-Risikoanalyse mit Excel: Anfangen, importieren, skalieren

CRA, ISO 21434, IEC 62443: Wo stehe ich, und wie fange ich an?

Der Cyber Resilience Act (CRA) ist keine Automotive-Regulierung, aber die Anforderung, die er stellt, ist aus der Automotive-Welt vertraut: Hersteller vernetzter Produkte müssen Cybersecurity-Risiken systematisch erfassen, bewerten und dokumentieren, bevor das Produkt auf den EU-Markt kommt, und dieses Wissen über den Lebenszyklus aktuell halten.

Was ich in den letzten Monaten öfter höre: “Wir haben schon etwas. Eine Tabelle, ein paar Bedrohungsszenarien, eine Liste mit Maßnahmen. Aber wir wissen nicht, ob es reicht, wie wir es weiterpflegen sollen, und was passiert, wenn das Modell wächst.”

Dieser Artikel ist für genau diese Situation. Nicht wie man eine Risikoanalyse vom Konzept her versteht, das habe ich an anderer Stelle beschrieben, sondern: wie man mit dem anfängt, was schon da ist, wie man methodisch sauber startet, wenn noch nichts da ist, und ab wann eine Tabellenkalkulation mehr Probleme erzeugt als sie löst.

Kurzer Rahmen: Was der CRA und ISO/SAE 21434 inhaltlich verlangen

Der CRA schreibt vor, dass Hersteller eine Cybersecurity-Risikoanalyse durchführen, die Ergebnisse dokumentieren und die Analyse über den Lebenszyklus des Produkts pflegen. Die Bewertung muss nachvollziehbar sein, also reproduzierbar, versioniert und im Zweifelsfall auditierbar.

In der Automotive-Welt kennt man diesen Anspruch aus ISO/SAE 21434. Der Standard für Cybersecurity-Engineering in Fahrzeugen schreibt eine Threat Analysis and Risk Assessment (TARA) vor: eine strukturierte Analyse, die Assets identifiziert, Bedrohungsszenarien ableitet, Angriffspfade bewertet und daraus Risikoentscheidungen dokumentiert. Für jedes identifizierte Risiko ergibt sich aus Impact Level (IL) und Attack Feasibility Level (AFL) ein Risk Level (RL), aus dem dann die Behandlungsentscheidung folgt.

Wer im industriellen Umfeld arbeitet, kennt statt ISO 21434 eher IEC 62443: die Normenfamilie für Cybersecurity in der industriellen Automatisierung und Steuerungstechnik. Auch dort steht eine Risikoanalyse am Anfang, mit ähnlichen Konzepten und ähnlichem Anspruch an Nachvollziehbarkeit. Der CRA trifft beide Welten, automotive und industriell, und itemis SECURE unterstützt beide Standards.

Diese Methodik passt inhaltlich auf das, was der CRA verlangt. Der Unterschied liegt im normativen Rahmen, nicht in der Analysedisziplin selbst. Wer aus der Automotive- oder der Industrie-Welt kommt, kann die Methode direkt übertragen. Wer noch keinen dieser Rahmen kennt, findet in ISO 21434 und IEC 62443 ausgereifte Grundlagen, auf die er aufbauen kann.

Ich habe schon eine Analyse. Was kann ich damit?

Meistens liegt noch nichts vor. Manche Teams bringen aber etwas mit: eine Excel-Datei mit Bedrohungsszenarien, Impact-Bewertungen und geplanten Maßnahmen — manchmal nach einem internen Template strukturiert, manchmal aus frühen Analyserunden heraus gewachsen.

Das Gute: das lässt sich importieren.

itemis SECURE unterstützt den Import aller TARA-relevanten Daten: Assets, Damage Scenarios, Threat Scenarios, Cybersecurity Goals, Claims und Security Concepts. Das itemis SECURE Excel-Template wird dabei direkt erkannt und kann ohne weiteres Mapping importiert werden. Wer ein eigenes Excel-Format mitbringt, kann seine Daten ebenfalls laden — nach einem semantischen Mapping, das die eigenen Spalten auf die TARA-Struktur abbildet.

Das erspart einem nicht die Analyse selbst, und es setzt voraus, dass die bestehenden Daten dem Template-Format entsprechen. Aber es bedeutet, dass man nicht von null anfangen muss. Was bereits durchdacht wurde, bleibt erhalten. Was fehlt oder noch nicht bewertet ist, kann man im Werkzeug ergänzen.

Noch keine Analyse? Dann mit dem Excel-Template beginnen

Wer noch nichts hat, kann methodisch sauber mit dem itemis SECURE Excel-Template starten. Das Template unterstützt den vollständigen TARA-Prozess: von der Asset-Identifikation über Damage Scenarios, Threat Catalog, Attack Steps und Controls bis zu Threat Scenarios, Risks und Cybersecurity Goals. Es ist so aufgebaut, dass man darin strukturiert arbeiten und die Ergebnisse danach in itemis SECURE importieren kann.

Ich empfehle das Template als Einstieg, nicht als Dauerlösung. Es hilft, die Methodik zu erlernen, das erste Analysemodell zu strukturieren und die Ergebnisse in einem Format zu erfassen, das sich später weiterverwenden lässt. Für eine erste TARA oder eine erste CRA-Risikoanalyse ist das ein vernünftiger Ausgangspunkt. Die Vorlage berechnet automatisch zentrale Kriterien wie AFL, IL und daraus resultierendem RL basierend auf dem Bewertungsmodell. Das Template ist dabei bewusst eine Vereinfachung. Was nicht geht:

• Die Feasibility wird lokal berechnet, nicht über den gesamten Angriffsbaum; Impact Transformations sind nicht möglich; Assumptions und Control Scenarios lassen sich erfassen, haben aber keinen Einfluss auf die Bewertung
• Tiefe Vererbungshierarchien im Katalog werden nur begrenzt aufgelöst
• Echte Zusammenarbeit, Änderungshistorie und Modellkonsistenz bietet eine Excel-Datei grundsätzlich nicht

Wer über diese Grenzen hinauswächst, braucht mehr als eine Tabelle.

Ab wann Excel nicht mehr reicht

Die Grenze liegt oft nicht bei der ersten Analyse, sondern bei der zweiten Änderung.

Sobald Angriffspfade sich über mehrere Komponenten hinweg fortpflanzen, sobald ein neu entdecktes CVE eine Neubewertung an fünf Stellen gleichzeitig auslöst, sobald zwei Personen an derselben Analyse arbeiten und eine davon Entscheidungen revidiert, wird die Tabelle zur Fehlerquelle. Konsistenz von Hand über hunderte Zeilen zu halten ist genau die Arbeit, die Werkzeuge gut und Menschen schlecht erledigen. Und die Nachvollziehbarkeit, wer hat wann was auf welcher Grundlage entschieden, bekommt man in einer Tabelle praktisch nicht sauber hin.

Das ist keine akademische Kritik. CRA-Audits schauen genau auf diese Nachvollziehbarkeit. Eine Analyse, die gut aussieht, aber nicht zeigt, wie die Entscheidung entstanden ist, wird Fragen aufwerfen.

Für große Bedrohungsmodelle empfehle ich Werkzeugunterstützung. itemis SECURE führt durch die Analyseschritte, hält Schadensbewertungen, Angriffsvektoren und Risiken konsistent, rechnet die Fortpflanzung von Risiken über Angriffspfade und hält die Entscheidungshistorie fest.

Attack Trees in itemis SECURE

Es nimmt einem die Analyse nicht ab, das soll es auch nicht, aber es hält die Buchführung sauber, damit man sich auf die eigentlichen Entscheidungen konzentrieren kann. Der modellgetriebene Ansatz zahlt sich auch für KI-Assistenz aus: Strukturierte TARA-Daten helfen LLMs nachweislich besser als Freitext. itemis SECURE bietet dafür einen MCP-Server — KI-Werkzeuge können das Modell direkt lesen und auf dieser Grundlage arbeiten, statt aus unstrukturierten Dokumenten zu rekonstruieren, was das Modell bedeutet.

Fazit

Das Template gibt es hier zum Download. Es ist der einfachste Weg, strukturiert in eine Analyse einzusteigen, ohne sofort ein Werkzeug einführen zu müssen. Wer zuerst wissen will, wo er beim CRA insgesamt steht, kann seinen Umsetzungsstand mit der kostenlosen CRA GAP-Analyse prüfen.

Wer darüber hinaus Fragen hat, ob zur Methodik, zum Werkzeug oder zu Unterstützung bei der Durchführung, kann mich direkt auf LinkedIn oder über itemis.de erreichen.

Cyber Security bei itemis — Systematisches Security-Engineering für Automotive, IoT und Industry 4.0: Cyber Security →