Mein Tagebuch zur Implementierung der Cybersecurity

Autoren: Timo Karasch, Florian Schmitt, Alexander Feulner

Liebes Tagebuch! „Nimm dich vor bösen Menschen in Acht!“, das haben uns schon unsere Großeltern beigebracht. Dass mich diese Warnung Jahre später im Beruf einholen würde, hätte ich nicht gedacht. Da können wir inzwischen modernste Systeme in der Automobilindustrie entwickeln, dann aber kommen böse Menschen und hacken sich in unsere Arbeit.

Schon lange sind das keine abstrakten Gedankenspiele mehr, vielmehr häufen sich konkrete Attacken. Untersuchungen zeigen, dass fast jeder hiervon betroffen – aber kaum jemand im Bereich der Cybersecurity gut aufgestellt ist. Dabei können schon verhältnismäßig einfache Angriffe Fahrzeuge oder die gesamte Kommunikationsinfrastruktur erfolgreich kompromittieren. Aber wie können wir damit umgehen, wenn Bösewichte unsere Daten stehlen, fälschen oder
manipulieren und was können wir tun, um dem entgegenzuwirken?

Die ISO/SAE 21434 Norm stellt einen einheitlichen Rahmen für die systematische Entwicklung von Systemen im Kontext der Cybersecurity dar. Gleichzeitig bilden die UNECE Regulierungen R155 und R156 Mindestforderungen ab, die für die Homologation von Fahrzeugen erforderlich sind. Auch auf meine Arbeit als Prozessberater im Entwicklungsbereich hat dies Einfluss. Mittlerweile durfte ich einige Unternehmen bei ihren Projekten zur Einführung von Cybersecurity unterstützen. Hier möchte ich dir, liebes Tagebuch, von meinen Erfahrungen berichten.

Tag 1: Wer oder Was ist „Cybersecurity“?

Liebes Tagebuch! „Aller Anfang ist schwer!“ Heute durfte ich lernen, dass das Thema Cybersecurity nicht nur sehr komplex und abstrakt ist, sondern dass auch die Auffassungen von der Implementierung sehr unterschiedlich sind.

Es wimmelt nur so von Begriffen und Konzepten: ACSMS, Automotive SPICE® for Cybersecurity, Incident Management, TARA, Vulnerabilities und endlos vielen mehr. Wie ich feststellen konnte, wird “Cybersecurity” oft mit “Safety” verwechselt. Beide Bereiche befassen sich mit der Vermeidung von unannehmbaren Risiken bei der Entwicklung von Systemen in der Automobilindustrie und spielen bei der Idee des autonomen Fahrens eine große Rolle. Daher liegt ein Zusammenhang nahe.

Bei Safety kümmern wir uns allerdings um Risiken auf Basis potenzieller Fehler, die unser System selbst verursacht. Cybersecurity hingegen fokussiert die Bedrohungen durch die Umwelt, also die Angriffe der sogenannten “bösen Menschen”. Genau hier liegt wohl auch der Grund darin, warum dieses Thema für viele Menschen so schwer zugänglich ist. Im Rahmen der Entwicklung machen wir uns ständig Gedanken über das Verhalten, also den „Use case” unseres Systems. Bei Cybersecurity betrachten wir nun allerdings den “Mis­Use case”, also die ungewollten
Vorgehensweisen, die Hacker im Blut zu liegen scheinen.

Tag 5: Warum werde ich das nicht los?

Cybersecurity zielt direkt in das Herz der Entwicklungsorganisation. “Security by Design” ist hier das Gebot und bedeutet, dass mehr als nur technische Absicherungsaspekte im Vordergrund stehen. Cybersecurity ist keine Aufgabe, die im Nachhinein ergänzt werden kann. Sie ist vielmehr
eine Risikobewertung, die unsere schützenswerten Artefakte (Assets) vor Hackern absichern soll und von Anfang an mitgedacht werden muss. Um einen besseren Überblick zu erhalten, haben wir uns heute die ISO/ SAE 21434 angesehen und die Norm in drei Aufgabenbereiche unterteilt.

Aufgabenbereiche

Erstens: Wie zu erwarten war, werden wir unsere Entwicklungsaufgaben mit Zusatzaktivitäten ergänzen müssen, um Cybersecurity schon von Beginn an in unser Konzept zu integrieren.

Zweitens: Dreh- und Angelpunkt von Cybersecurity ist die Installation eines unternehmensweiten, übergreifenden Managementsystems für Cybersecurity-Betrachtungen (CSMS).

Drittens: Zur Absicherung der kontinuierlichen Verbesserung werden wir unsere Audit- und Assessment-Planung anpassen müssen. Während wir uns mit den Grundlagen beschäftigen, melden sich unsere Kund:innen schon mit ihren ersten Anforderungen:

• Die Entwicklung muss konform zur ISO/ SAE 21434 erfolgen.

• Die Konformität muss durch einen ISO/ SAE 21434 Assessment-Report nachgewiesen werden.

• Durch ein Assessment muss mindestens ein Level 2 in allen Prozessen des Modells „Automotive SPICE® for Cybersecurity” nachgewiesen werden.

• Es muss eine Zertifizierung des Automotive Cybersecurity Management
  Systems (ACSMS) vorliegen.

Ziele setzen

Also ist Eile geboten, denn die ersten Projekte hierzu laufen bereits. Um die Anforderungen unserer Kund:innen zu priorisieren und in Einklang mit unserer Prozesswelt zu bringen, haben wir uns einige interne Ziele gesetzt:

• Unsere Roadmap zur Implementierung wird hauptsächlich den Anforderungen der ISO/SAE 21434 folgen, um die geforderte Konformität sicherzustellen.

• Die bestehenden Standardprozesse sollen nur geringfügige Anpassungen erhalten, d. h.:

• Wir erstellen nur wenige neue Prozesse.

• Wir passen bestehende Prozesse an oder erweitern diese.

• Wir integrieren die notwendige Zertifizierungen und Audits in das bestehende interne Auditprogramm und Zertifizierungssystem.

• Wir erstellen einen Entwurf zu organisatorischen Änderungen und diskutieren diesen gemeinsam mit der Managementgruppe zur anschließenden Freigabe.

Tag 12: Wen muss ich überzeugen?

Liebes Tagebuch! Wie heißt es so schön: “Die guten Dinge im Leben kriegt man nicht geschenkt.”
Die Einführung von Cybersecurity in einem Unternehmen bedeutet nicht nur Zusatzaufwände, sondern auch laufende Kosten für das „Event Monitoring“ und die Maintenance der Produkte. Damit diese bereitgestellt werden können, führt unser Weg gleich am Anfang des Projekts zum
Management des Unternehmens. Während die Überarbeitung der Prozesslandschaft durch anstehende Projekte finanziert werden kann, bieten die oben genannten Querschnittsaufgaben wirtschaftlich betrachtet keinen direkten Mehrwert.

Daher müssen wir Überzeugungsarbeit leisten, um im Management ein Bewusstsein für die Wichtigkeit von Cybersecurity zu schaffen. Zudem möchten wir ein deutliches Signal an alle Mitarbeitenden im Unternehmen senden. Aus zahlreichen Projekten weiß ich, dass Manager:innen zwar verstanden haben, dass eine neue Herausforderung auf sie zukommt, sie aber oft kein genaues Bild von den konkreten Auswirkungen haben.

Es hat sich bewährt, Übersichten für Arbeitspakete, erste Aufwandsschätzungen und Nutzensbetrachtungen vorzulegen – natürlich in einer für das Management geeigneten Form! Wir zeigen daher die erwarteten Aufwände und Ergebnisse möglichst konkret in einer Kosten-­Nutzen-Betrachtung und legen eine Roadmap vor, mit der wir das Management final überzeugen werden.

Tag 25: Welche Grundlagen sollte ich legen?

Liebes Tagebuch! „Wir müssen es eh machen, also dann gleich richtig!“ Wenn wir also schon neue Prozesse und Methoden einführen müssen, dann sollten wir das gleich in der richtigen Form tun.
Auch wenn unsere Expert:innen schon ungeduldig mit den Hufen scharren und konkrete Arbeitsergebnisse erzielen wollen, habe ich mich heute erst einmal mit dem Prozessmanagement des Unternehmens zusammengesetzt.

Wir haben festgestellt, dass wir eine angepasste Prozesslandkarte benötigen, in der die Verantwortlichkeiten für unsere neuen Prozesse festgehalten werden. Zudem stellten mir die Prozessmanager:innen die Guideline zum Prozessdesign vor. Abschließend haben wir das Update des Qualitätsmanagement Systems angestoßen, damit unsere neuen Ziele und Aufgaben auch hierin einfließen und später auditiert werden können.

Das war eine der einfacheren Aufgaben, da ich hier verhältnismäßig wenig Überzeugungsarbeit leisten musste.

Tag 31: Geht es jetzt richtig los?

Liebes Tagebuch! “Wie kommt der Elefant in den Kühlschrank? Kühlschranktür auf, Elefant rein, Kühlschranktür zu” Heute habe ich mit den Entwickler:innen über die Anpassung der Entwicklungsprozesse gesprochen. Wie sich herausgestellt hat, waren ihnen die meisten Aufgaben ohnehin bekannt. In den letzten Jahren haben sie sich intensiv mit dem Thema „Safety” auseinandergesetzt.

Daher sind viele Dokumente, wie z. B. die Anforderungsspezifikationen, dahingehend umgearbeitet, dass sie auch Safety Anforderungen enthalten. Das Gleiche wollen sie nun
auch mit den Security ­Anforderungen tun. Ähnlich verhält es sich mit den Tester:innen, die schon eine Auswahl von Testmethoden in ihren Testplänen beschrieben haben. Im Endeffekt sind wir auf vier Themen gestoßen, bei denen wir noch nach einer Lösung suchen müssen:

Am schwersten fiel uns der Kernaspekt, um den sich alles dreht: die gesamte Risikobetrachtung und Ermittlung potenzieller Gefahren. Wir sind froh, einige neue Kolleg:innen im Team zu haben, die bereits in anderen Branchen Erfahrungen sammeln konnten und das Thema Cybersecurity
schon sehr gut beherrschen. Sie bringen eine andere Sichtweise (“MisUse case”) in unsere Betrachtung, ganz im Sinne von: „Denk wie ein Angreifer!“

Tag 39: Jetzt wird es richtig hart, oder?

Heute haben wir uns in absolutes Neuland begeben. Gemeinsam mit Expert:innen haben wir uns Gedanken darüber gemacht, wie die Organisationsprozesse zur Cybersecurity funktionieren sollen. Nach den projektbezogenen Aufgaben zuvor fehlt uns hier an vielen Stellen noch eine klare Vorstellung. Beim Thema der Verantwortlichkeiten wird es anstrengend: Zwar sehen viele Bereiche die Aufgaben bei sich, um die notwendige Ausarbeitung der Prozesse möchte sich aber niemand kümmern.

Letztlich machten wir uns noch Gedanken über mögliche Lizenzkonzepte für Produktupdates, um zumindest einen Teil der anfallenden Kosten später auf Kunden abwälzen zu können. Bei meinem Versuch, eine Entscheidung herbeizuführen, erhielt ich eine typisch deutsche Antwort: „Am Ende der Diskussion sind wir uns einig, dass wir darüber noch einmal
reden müssen.“

Tag 45: Sind wir auf der Zielgeraden?

Liebes Tagebuch! Der Projektalltag rückt näher und unser Unternehmen möchte endlich die Früchte unserer Arbeit ernten. Aber sind wir denn schon so weit? Unser Team hat eine „Cybersecurity Guideline“ erarbeitet und nutzt diese als lebendes Dokument, um das erworbene Wissen zu dokumentieren und innerhalb des Unternehmens weiterzugeben. Das Cybersecurity Team auf Organisationsebene und die Projektteams haben untereinander regelmäßige Austauschformate etabliert.

Es wird identifiziert, wo die Projekte Unterstützung benötigen, damit das Team der Organisationsebene den Projekten zuarbeiten kann. Auch das Team der Organisationsebene profitiert von den Erfahrungen aus den Projekten. Neulich erhielten wir z. B. den Hinweis über einige Bibliotheken zur Durchführung der TARA. Damit konnte das Team den internen Risikokatalog weiter verbessern.

Tag 50: Haben wir es damit geschafft?

Liebes Tagebuch! „Und da hatten wir schon gedacht, wir wären fertig mit unserer Arbeit …“ Eines der Themen auf unserer Roadmap war die Zertifizierung unseres neuen Automotive Cybersecurity
Management Systems (ACSMS). In der Vorbereitung auf das externe Audit haben wir nun zum ersten Mal auch interne Audits durchgeführt, eine Ergänzung unseres internen Auditprogramms. Dabei wurden einige wesentliche Schwächen festgestellt, vor allem im Prozess der Lieferantenauswahl.

Derzeit überlegen wir gemeinsam mit dem Prozessmanagement, ob uns regelmäßige Assessments nach etablierten Modellen wie Automotive SPICE® (oder auch Automotive SPICE® for Cybersecurity) bei der Verbesserung unserer Prozessqualität helfen können. Ich hatte es bisher noch nie mit einem Thema zu tun, das uns so sehr gefordert hat, kontinuierlich dazu zu lernen und sich den Veränderungen anzupassen. Insofern bin ich dankbar, dass viele gute Verbesserungsvorschläge aus dem Projektteam kommen.

Fazit

Liebes Tagebuch! Welch eine spannende Reise liegt hinter mir… Ich denke, man kann durchaus sagen: Cybersecurity ist der nächste Schritt. Nicht nur, weil der Markt es als neues,
zusätzliches Thema fordert, sondern vor allem, weil es auf dem aufbaut, was wir bisher an Prozessqualität erreicht haben.

Cybersecurity zu integrieren setzt auf eine systematische und etablierte Prozesslandschaft. Wir müssen die Produktentwicklung systematisch und kontrolliert betreiben, anstatt im permanenten Feuerwehrmodus zu arbeiten. Denn ansonsten wird das Team mit dem Zeitbudget für Prozessarbeit, Recherche und interne Abstimmung niemals auskommen. Dass wir diesen Weg weitergehen wollen und müssen, ist uns allen klar.

Dennoch sind wir uns einig: Wir stehen alle nach wie vor am Anfang der Cybersecurity.