Es ist wie immer mit den EU-Richtlinien. Theoretisch wollen sie das Richtige tun. Sie werden erlassen, um irgendeine problematische Angelegenheit zu lösen und die damit verbundenen Handlungsfelder für alle EU-Mitgliedsstaaten zu harmonisieren. Nur ist der Weg der Umsetzung, von der EU über die nationalen Regierungen bis hin zur konkreten Umsetzung auf den Schreibtischen der eigentlich Betroffenen immer komplex. So ist es auch mit der NIS-2-Direktive (EU 2022/2555), die als neue Grundlage für Cybersicherheits-Risikomanagement, Incident-Reporting und die Umsetzung von Cybersecurity-Mindestanforderungen dienen soll. Was wir davon in diesem Zusammenhang vor allem sehen: Dienstleister, Solution-Provider und Berater, die auf dem Rücken der Richtlinie plumpe Werbung machen. Daran wollen wir nicht anknüpfen. Vielmehr sollen die nachfolgenden Zeilen Verantwortlichen für Automotive Cybersicherheit und Sicherheit in der Fahrzeugentwicklung einen ersten einführenden Überblick darüber geben, welche Berührungspunkte der rechtliche Regulierungsrahmen der NIS-2 mit den Handlungsfeldern der Fahrzeugsicherheit tatsächlich hat. Here we go.
Philipp Veronesi
NIS 2? Klingt zunächst nach reiner Informationssicherheit. Also eine Aufgabe für IT-Security-Verantwortliche. Viel Spaß, ihr macht das schon. Ist es so einfach? Nicht wirklich, zumal sich die Auswirkungen der Direktive über kurz oder lang auf etliche Aspekte der Wertschöpfung erstrecken oder zukünftig erstrecken werden.
Besonders vor dem Hintergrund der voranschreitenden technologischen Entwicklungen rund um Fahrzeuge, Komponenten und Systeme ist festzuhalten, dass Klassifizierungen, Zuordnungen und Denkweisen der Vergangenheit in Zukunft möglicherweise nicht mehr zutreffen werden. Vor allem auch vor dem Hintergrund, dass das Produkt „Fahrzeug“ längst nicht mehr allein in der Hand von OEMs liegt, sondern (z.B. für Endanwender besonders sichtbar im Infotainment) inzwischen neue, tiefergehende Verflechtungen mit Zulieferern, Technologieanbietern & Co. die Verantwortlichkeiten prägen.
So empfiehlt sich Automotive-Security-Verantwortlichen stets einen Blick auf neue entstehende Vorgaben, Richtlinien und Anforderungen rund um Cybersecurity zu werfen.
Kurz ausgeholt: Woher kommen wir, wohin gehen wir?
An dieser Stelle eine kurze Erklärung eingeschoben: Wer schon einen Blick in das Dokument der NIS-2-Richtlinie auf den Seiten der Europäischen Kommission geworfen hat, erkennt schnell, dass sich die Direktive in erster Linie an die Mitgliedsstaaten der EU wendet, die hier vor der Aufgabe stehen, auf nationaler Ebene einen gültigen Rechtsrahmen und zugehörige Strukturen zu schaffen, um jeweils mit nationalen Institutionen und Vorgehensweisen eine EU-weit harmonisierte Ausgestaltung zur Umsetzung der definierten Cybersecurity-Mindestanforderungen zu gewährleisten. (Detail, aber wichtig: Bei der Verabschiedung der länderspezifischen Gesetzgebung können Einzelheiten ggf. auch noch „schärfer“ als von der EU gefordert sein.)
Damit wird es, wie immer, gleich etwas komplizierter, wie das bei Rechtstexten so ist. Wer also genau spezifizierte Anforderungen sucht, die er systematisch abhaken kann, wird vom Dokument der Richtlinie enttäuscht sein.
Zumal es in erster Linie ohnehin zunächst darum geht, herauszufinden, inwieweit man als Organisation überhaupt in den definierten Anwendungsbereich von NIS-2 fällt (sofern man nicht Teil der Kritischen Infrastruktur ist, und direkt betroffen ist).
NIS-2 adressiert dazu Organisationen in Sektoren mit hoher und sehr hoher Kritikalität, die in Anhang I und Anhang II recht generisch definiert sind.
Inwieweit betrifft die NIS-2-Richtinie die Automobilindustrie, Zulieferer und Fahrzeugbauer?
Beginnen wir dafür im wahrsten Sinne des Wortes mit dem Ende, genauer gesagt im Anhang. Anhang II, Absatz 5.5. der bereits am 14.12.2022 final verabschiedeten Richtlinie benennt sowohl die „Herstellung von Kraftwagen und Kraftwagenteilen“ als auch den „sonstigen Fahrzeugbau“ als kritischen Sektor und damit direkt von den Vorgaben der NIS 2 Richtlinie betroffen.
Im Zweifelsfall können die Mitgliedsstaaten dabei sogar noch eigene Klassifizierungen vornehmen bzw. stellen in der Regel bereits offizielle Hilfsmittel zur Verfügung, um den Wirtschaftsakteuren die Möglichkeit zu bieten, festzustellen, inwieweit sie von der NIS-2-Richtlinie betroffen sind.
10 Aspekte, die Automotive-Security-Verantwortliche rund um die NIS-2 wissen sollten
Was genau wichtig werden könnte, da versuchen wir nachfolgend einen ersten Überblick.
(1) Cybersicherheit formell korrekt angehen: Verantwortliche benennen und Rechenschaftspflichten
Im strukturierten OEM-Kosmos mögen die Anforderungen rund um Verantwortlichkeiten fixieren, Rechenschaftspflichten, Informationsflüsse (etc.) wohl schnell mit einem Achselzucken als erledigt abgetan werden. In kleineren Organisationen und Einheiten sollte sich aber im Klaren sein: NIS-2 verlangt die formale Benennung von Verantwortlichkeiten für Cybersicherheitsmaßnahmen auf höchster Managementebene. Es reicht nicht mehr aus, Verantwortlichkeiten irgendwohin zu delegieren, es geht darum, Cybersicherheit top-down anzugehen und die Umsetzung zu überwachen.
Damit wird das Management stärker in die Pflicht genommen, Cybersicherheit als strategisches Thema zu verstehen und echte Unterstützung zu gewährleisten. Daraus lassen sich Chancen und Pflichten ableiten: Einerseits sollte NIS 2 in hohem Maße als Bewusstseinskatalysator dienen, der im besten Fall neue Umsetzungsmöglichkeiten mit sich bringt, andererseits ist davon auszugehen, dass aus der Innenperspektive sämtliche sicherheitsrelevante Ausarbeitungen noch stärker gegenüber dem Management begründet und die Notwendigkeiten von Cybersicherheit noch fundierter dargestellt werden müssen.
(2) NIS-2-Forderungen nach umfassender Risikobewertung und das Cybersecurity Management System
Erst einmal ein leichtes Schulterklopfen für die Automobilindustrie. Der Aufbau und die Aufrechterhaltung eines Cybersecurity Management Systems (CSMS) ist seit Mitte letzten Jahres mit der UN Regulation No. 155 im Zuge der Typenzulassung für neue Fahrzeuge bereits verpflichtend – mit dem verteilten Risikomanagement entlang der gesamten Fahrzeug-Wertschöpfungskette sind die Wirtschaftsakteure der Lieferkette hier in der Regel bereits ebenfalls involviert.
Damit ist das CSMS – wenngleich es in erster Linie das Fahrzeug im Fokus hat und auf ein Information Security Management System (ISMS) aufbaut – de facto gegenwärtig mit die beste Grundlage für die Erfüllung der NIS-2-Anforderungen.
Hier ist auf organisatorischer Ebene dennoch ergänzend sicherzustellen, dass die detaillierten Anforderungen aller NIS-2-Aspekte ordnungsgemäß abgedeckt und auch regelmäßig überprüft werden.
Exkurs: Inwieweit fällt das vernetzte Fahrzeug selber unter die NIS-2-Richtlinie?
Die Fragestellung, inwieweit Fahrzeuge selbst auch unter die Definition der Netzwerk- und Informationssysteme nach NIS-2 fallen, ist weiterhin interpretationsbedürftig. So könnte (unter Bezugnahme auf die Definition in Artikel 6) argumentiert werden, dass moderne vernetzte Fahrzeuge mit ihren dahinterliegenden Prozessen der Datenverarbeitung den aufgeführten Kriterien entsprechen könnten. Damit würde die Richtlinie jedoch direkt das Fahrzeug selbst regulieren, was in der Tendenz nicht der Anspruch der Direktive ist, die sich primär an die Betreiber von Systemen richtet.
Im Zuge der Überführung der NIS-2 Direktive in nationales Recht argumentiert beispielsweise der Verband der deutschen Automobilindustrie in seinem Positionspaper (03/2023), dass wie im Cyber Resilience Act Fahrzeuge (bzw. Fahrzeugdienste) ausgenommen werden sollten, da branchenspezifische Regulierungen bereits mindestens gleichwertige Cybersecurity-Anforderungen stellen.
Die noch ausstehende Klarstellung dieser Frage hat eine besondere Brisanz, zumal davon die Fragestellungen der Prozesse, Pflichten, Meldewesen (u.a.) fundamental abhängig wären.
(3) Cybersicherheit in der Supply-Chain trendet.
Nicht mehr nur einzelne Akteure, vielmehr sind es gesamte Lieferketten, die mit der NIS-2 in den Fokus der Cybersicherheit rücken. Die Identifikation von Cybersicherheitsrisiken in Lieferketten und entsprechende Prozesse und Maßnahmen zu deren Bewältigung werden zu einem wichtigen Handlungsfeld. Mit der fortschreitenden Durchdringung von Cybersicherheit als Qualitätsdimension in der Fahrzeugentwicklung sollte dies für die Verantwortlichen kein neues Thema sein.
Die NIS-2 zeigt aber, wie weitreichend die Einbindung von Zulieferern in die eigene Sicherheitsarchitektur sein sollte:
- Risikobewertungen
- Sicherheitsanforderungen an Lieferanten definieren, vertraglich fixieren
- Audits, Auditnachweise
- Incident Response Prozesse
- Austausch von Informationen über Bedrohungen und Schwachstellen
- …
Die ganze Klaviatur eben. Die Automobilindustrie, die hier immer noch gerne zu restriktiv zusammenarbeitet (Stichwort: Intellectual Property), muss hier Wege finden, Informationen über Schwachstellen und Risiken (besonders in der verteilten Entwicklung) systematischer auszutauschen. Im Big Picture genauso wie z.B. rund um die Kollaboration in der Umsetzung der TARA-Methodik.
(4) Die Sache mit den Meldepflichten.
Besonderes Augenmerk gilt den recht strengen Meldepflichten für Sicherheitsvorfälle, die NIS-2 mit sich bringt. In verschiedenen Stufen und mit entsprechenden Fristen müssen Meldungen an nationale Behörden (in Deutschland: an das Bundesamt für Sicherheit in der Informationstechnik) erfolgen.
Wer sich z.B. mit GDPR/DSGVO und Datenschutz bereits auskennt, weiß, dass auch dort Datenschutzvorfälle systematisch gemeldet werden müssen – entsprechend sollte der Umgang mit der Meldung von Sicherheitsvorfällen an Behörden ernst genommen werden, entsprechende Vorgaben sollten bekannt und funktionierende Prozesse (und das Wissen darüber!) sollten etabliert werden.
(5) Priorität für Business Continuity
Obwohl man annehmen könnte, dass die NIS 2-Richtlinie in erster Linie auf die Initiierung von „Dokumenten-Schubserei“ abzielt, greift sie auch in die Geschäftsprozesse ein, genauer gesagt in die Aufrechterhaltung selbiger.
Konkret werden Business Continuity (BC) und Disaster Recovery (RC) adressiert. Über die kritischen Auswirkungen von Ausfällen, etwa rund um die Cybersicherheit in der Automobilproduktion, haben wir zuletzt bereits gesprochen.
Auch wenn die Business Continuity z.B. in der UN R155/CSMS nicht explizit benannt wird, sind diese Aspekte natürlich im Rahmen des übergeordneten Risikomanagements entlang aller Phasen im gesamten Fahrzeuglebenszyklus zu berücksichtigen.
Insbesondere auch mit Blick auf die Cybersicherheitsanforderungen, die zukünftig auf die Branche zukommen werden, wird deutlich, dass Notfallpläne, Ausfallsicherheit, Aufrechterhaltung sicherheitsrelevanter Strukturen, Prozesse und Mechanismen mit Blick auf involvierte Funktionen im gesamten Fahrzeuglebenszyklus (Software Update Management, Incident Response u.a.) absolut essentiell sein werden – auch (wenn nicht sogar besonders!) auf Zuliefererseite.
(6) Ja, sichere Entwicklungsprozesse.
Aus Sicht der Produktsicherheit könnte man zwar sagen, dass NIS-2 in erster Linie nur „das Drumherum“ adressiert, dennoch werden in der Richtlinie „sichere Entwicklungsprozesse“ im Kontext des Cybersecurity-Risikomanagements (auch bei beteiligten Lieferanten und Dienstleistern) klar benannt.
Die handfeste Evaluierung von sicherer Entwicklung, die organisatorische Bewältigung der Überprüfung von „cybersicheren Arbeitsweisen“ (mit der unglaublichen Breite und Tiefe, die dazu gehört!), diese Dinge werden nicht wieder aus den Verantwortungsbereichen der Fahrzeug-Cybersicherheit verschwinden.
Klar ist aber: NIS-2 wird hier nicht „übergriffig“ in dem Sinne, dass Sicherheitsprinzipien und Entwicklungspraktiken (beginnend mit der ISO/SAE 21434 und in den domänenspezifischen Vertiefungen) hier nicht ausgehebelt werden.
Wer Security-by-Design bereits als Treiber in der Fahrzeugentwicklung erkannt hat, sollte die erforderliche Ausbalancierung zwischen Business Case und Cybersecurity-Anforderungen immer frühzeitig mitdenken, um später nicht unangenehm überrascht zu werden.
(7) Weil Cybersecurity-Awareness wohl niemand mehr hören kann, heißt es jetzt Cyberhygiene?
Für uns, Expertinnen und Experten aus dem Metier der (Cyber-)Sicherheit, wird alles, was mit Awareness und Bewusstsein für Cybersicherheit zu tun hat, gerne schnell als Banalität abgetan.
Gleichzeitig sind wir uns aber bewusst, dass viele Strukturen, Prozesse, Abläufe, Funktionen und Rollen doch häufig von einer Idealvorstellung abweichen, wie Cybersicherheitsanforderungen berücksichtigt werden.
Die entsprechenden Passagen in der ISO/SAE 21434 und der UN R155 zu Automotive-Cybersecurity-Kompetenzvermittlung und der Bedeutung von Awareness sind bestenfalls bekannt – mit der NIS-2 wird ebenfalls deutlich aufgeführt, das Bewusstsein für Cyberrisiken zu schärfen
Insbesondere aber kleine und mittlere Unternehmen, die strukturell bedingt weniger Möglichkeiten, aber ebenso häufig auch weniger Bewusstsein für Cybersicherheitserforderlichkeiten haben, werden in der NIS-2 adressiert.
Konkret wird es zukünftig darum gehen, die Sensibilisierung, die entsprechende Weiterbildung und die in der Praxis tatsächlich wirksame Befähigung rund um angewandte Cybersicherheit noch konsequenter anzugehen. Ausdrücklich werden hier auch die Mitglieder der Leitungsorgane benannt, die hier besonders verpflichtet werden an Schulungen regelmäßig teilzunehmen.
(8) Aufsetzen, durchsetzen, dokumentieren – Austausch mit nationalen Behörden … Cybersicherheit wird Chefsache.
Was wichtig zu verstehen ist: Die NIS-2-Richtlinie geht sehr genau darauf ein, dass sie vorsieht, dass die Verantwortung für die Cybersicherheit in der Geschäftsleitung einer Organisation verankert wird. Dabei geht es nicht nur konkret um die Genehmigung und Überwachung von Risikomanagementmaßnahmen, sondern auch darum, dass natürliche Personen für Verstöße gegen ihre Pflichten zur Sicherstellung der Einhaltung der NIS-2-Richtlinie haftbar gemacht werden können.
Im Klartext bedeutet dies, dass Vorstände und Geschäftsführer persönlich haftbar gemacht werden können, wenn sie ihren Pflichten zur angemessenen Berücksichtigung der Cybersicherheit nicht nachkommen.
Während eine Wegdelegation der Verantwortung, wie bereits erwähnt, nicht ausreicht, ist auch eine Übertragung der Verantwortung auf externe Dienstleister nicht möglich, um eine Abwälzung der persönlichen Haftung auszulösen.
Dies zeigt, wie tief die Richtlinie in die Unternehmensführung und -prozesse eingreift und welche neuen Verantwortlichkeiten auf der Ebene der Gesamtorganisation entstehen.
(9) Möglicherweise relevant: Die Sache mit den „Betreibern intelligenter Verkehrssysteme“
Die Frage, wer in welchem Umfang direkt / indirekt von der NIS 2 betroffen ist, sollte (theoretisch) durch systematisches Durcharbeiten des entsprechenden nationalen Fragenkatalogs (s. oben) bzw. durch anschließende Prüfung der hier eine Rolle spielenden Geschäftsbeziehungen geklärt werden, wenn ein Geschäftspartner betroffen ist.
Alternativ gilt die vereinfachte Faustregel: Man ist möglicherweise betroffen.
Wichtig ist parallel dazu, dass „Betreiber intelligenter Verkehrssysteme“ als Sektor mit hoher Kritikalität angesehen werden (Vgl. Anhang I).
Konkret sind damit private Organisationen, Dienstleister und Datenlieferanten gemeint, die für die Bereitstellung und Verarbeitung von Verkehrs- und Mobilitätsdaten verantwortlich sind. Während der Begriff „Betreiber“ hier primär auf Akteure abzielt, die für den Betrieb und das Management solcher Systeme verantwortlich sind, ist im Einzelfall zu prüfen, inwieweit eigene Dienste rund um intelligente Verkehrssysteme hier unter diese Definition fallen können. (Disclaimer: Dies ist keine Rechtsberatung).
(10) Zu guter Letzt: Es gilt weiterhin, den Überblick zu behalten
So sehr es zu begrüßen ist, dass mit der NIS-2 auf europäischer Ebene eine große Anstrengung unternommen wird, um die Harmonisierung von Cybersicherheitsstandards weitläufig bei Wirtschaftsakteuren und nationalen Institutionen voranzutreiben, so bleibt doch die immense Herausforderung, gesamtheitlich über alle relevanten Anforderungen den Überblick zu behalten.
Insbesondere Verantwortliche für Automotive Cybersecurity, die hier in erster Linie ihre branchenspezifischen Regularien, Richtlinien, Anforderungen, Industriestandards, Guidelines, Best Practices und Industriestandards berücksichtigen müssen, tun gut daran, hier ganzheitlich zu denken.
Zwar sollten sich unterschiedliche Anforderungen nicht widersprechen, mit einer konsistenten organisationsspezifischen Handhabe (insbesondere z.B. mit Blick auf die erforderlichen Dokumentationen) können gute Hilfestellungen für Vergleichbarkeit, Auditierbarkeit und kontinuierliche Weiterentwicklung geschaffen werden.
So gilt es im Endeffekt das Richtige zu tun, die Umsetzung richtig nachzuhalten und im Fall der Fälle die richtigen Meldungen anzustoßen. Wenn das die EU schafft, dann ja vielleicht auch die eigene Organisation.
