CAL (Cybersecurity Assurance Level)

Was ist CAL?

Ein Cybersecurity Assurance Level (CAL) ist eine vierstufige Einstufung, CAL 1 bis CAL 4, die sagt, wie viel Absicherung ein Cybersecurity-Ziel braucht und wie streng Engineering und Tests dahinter deshalb sein müssen. Die Rolle ähnelt dem ASIL der funktionalen Sicherheit, mit einem wichtigen Unterschied: Der CAL ist informative Orientierung, keine normative Anforderung der ISO/SAE 21434.

Wo ist es definiert?

ISO/SAE 21434:2021 Anhang E, “Cybersecurity assurance levels”, beschreibt das Konzept. Tabelle E.1 leitet den CAL aus der Impact-Bewertung eines Bedrohungsszenarios (die Bewertung nach 15.5) und dem Angriffsvektor des Angriffspfads (physical, local, adjacent, network) ab. Tabelle E.2 zeigt Beispiele, wie die Strenge der Methoden mit dem CAL skalieren kann, etwa bei der Anforderungsverifikation, der Tiefe der Integrationstests und der Unabhängigkeit der Validierung. Der Standard erlaubt, einem Cybersecurity-Ziel in der Konzeptphase (Kapitel 9) einen CAL zuzuweisen und ihn bis zur Komponente weiterzureichen.

UN R155 kennt den Begriff nicht. Absatz 7.3.6 verlangt schlicht, dass der Hersteller angemessene und ausreichende Tests durchführt, um die Wirksamkeit der Sicherheitsmaßnahmen nachzuweisen. In der Praxis wird der CAL genau dort benutzt, um zu begründen, was “ausreichend” heißt.

Was es in der Praxis bedeutet

Der CAL entscheidet, wie tief ein Testprogramm gehen muss und wer es durchführt. Für ein Ziel mit CAL 1 können ein Review und funktionale Tests der Sicherheitsanforderungen reichen. Ab CAL 2 erwarten Assessoren Fuzzing der Kommunikationsschnittstellen und Schwachstellenscans, passend zur Empfehlung [RC-10-12] in Kapitel 10.4.2. Bei CAL 3 und CAL 4 erwarten sie Penetrationstests durch Tester, die vom Entwicklungsteam unabhängig sind, wie in Kapitel 11 [RQ-11-01] benannt, mit Abdeckung der gesamten Angriffsfläche und dokumentierten Angriffspfaden.

Bei der Audit-Unterstützung für einen Tier-1 war das CAL-Argument das Erste, womit der Assessor den Testplan geprüft hat: Welche Ziele tragen welchen CAL, und passen die Testnachweise pro Ziel dazu. Ein CAL-3-Ziel, geschützt durch SecurityAccess, ohne Fuzzing-Ergebnisse und ohne unabhängigen Test war eine Lücke, obwohl der Service “funktionierte”.

Der CAL setzt auch Prioritäten. Ein Steuergerät, das nur über den physischen CAN-Bus erreichbar ist, und eines, das über ein vernetztes Gateway per Ethernet erreichbar ist, können dieselbe Software fahren; die Angriffsvektoren unterscheiden sich aber, und damit CAL und Testbudget.

Wie AutoST es testet

AutoST liefert den wiederholbaren Teil der Nachweise, die CAL 2 und höher verlangen: Enumeration, SecurityAccess-Prüfungen, UDS- und CAN-Fuzzing mit Crash-Erkennung, DoIP- und SOME/IP-Tests, mit gespeicherten Seeds, datierter Historie und PDF- sowie SARIF-Berichten. Für CAL 3 und 4 ist das die Basis, auf der ein Penetrationstest aufsetzt, kein Ersatz dafür; die Unabhängigkeitsanforderung erfüllt sich darüber, wer den Test durchführt, und daran ändert AutoST nichts.

Häufige Missverständnisse

Ein CAL ist keine Zertifizierung und kein Etikett, das ein Steuergerät “hat”. Er wird einem Cybersecurity-Ziel zugewiesen, und ein Steuergerät trägt meist Ziele auf mehreren Stufen. Und ein hoher CAL macht eine schwache Maßnahme nicht akzeptabel; er hebt nur die Latte dafür, wie gründlich ihre Wirksamkeit gezeigt werden muss.