Cybersecurity-Lösungen im Auto implementieren

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 dessen Implementierung sehr unterschiedlich sind. Es wimmelt nur so von neuen Begriffen und Konzepten: ACSMS, Automotive SPICE for Cybersecurity, Incident Management, TARA, Vulnerabilities, Enisa. Die Liste ließe sich endlos fortsetzen.

Wie ich feststellen konnte, verwechseln viele Cybersecurity mit Safety. Beide 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 dieser Zusammenhang nahe.  

Bei Safety kümmern wir uns um Risiken auf Basis potenzieller Fehler, die unser System selbst verursacht. Cybersecurity hingegen fokussiert die Bedrohungen durch die Umwelt, also die Angriffe der oben genannten "bösen Menschen". Genau hier liegt wohl auch der Grund darin, dass dieses Thema für viele 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.

Liebes Tagebuch! Cybersecurity zielt direkt aufs Herz der Entwicklungsorganisation.

“Security by Design” ist das Gebot. Dies umfasst dabei mehr als nur technische Absicherungsaspekte. Insbesondere ist dies keine Aufgabe, die sich im Nachhinein ergänzen lässt. Im Kern geht es um eine Risikobewertung, die unsere schützenswerten Artefakte (Assets) vor Hackern absichern soll.

Für einen besseren Überblick haben wir uns heute die ISO/SAE 21434 angesehen und die Norm dabei in drei Aufgabenbereiche unterteilt.

1. Wie zu erwarten war, werden wir unsere Entwicklungsaufgaben mit Zusatzaktivitäten ergänzen müssen, um Cybersecurity, wie oben genannt, schon mit Beginn des Konzepts zu integrieren.
2. Dreh- und Angelpunkt von Cybersecurity ist die Installation eines unternehmensweiten, übergreifenden Managementsystems für Cybersecurity-Betrachtungen (CSMS).
3. Zur Absicherung der kontinuierlichen Verbesserung werden wir unsere Audit- und Assessmentplanung anpassen müssen.

Während wir uns noch mit den Grundlagen beschäftigen, melden sich unsere Kunden 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.

Also ist Eile geboten, denn die ersten Projekte hierzu laufen bereits. Um diese Anforderungen zu priorisieren und in Einklang mit unserer Prozesswelt zu bringen, haben wir uns ein paar 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 Prozesse ganz neu.
  • Ansonsten passen wir bestehende Prozesse an oder erweitern sie.
• Wir integrieren notwendige Zertifizierungen und Audits in das bestehende interne Auditprogramm und Zertifizierungssystem.
• Wir erstellen zunächst einen Entwurf der organisatorischen Änderungen und diskutieren diesen dann in der Managementgruppe zur anschließenden Freigabe.

Liebes Tagebuch! „Die guten Dinge im Leben kriegt man nicht geschenkt.“

Die Einführung von Cybersecurity bedeutet nicht nur Zusatzaufwände, sondern auch laufende Kosten für das „Event Monitoring“ und Maintenance der Produkte. Damit diese bereitgestellt werden können, führt uns unser Weg gleich zu Anfang zum Management des Unternehmens.

Während sich die Überarbeitung der Prozesslandschaft über anstehende Projekte finanzieren lässt, bringen die o.g. Querschnittsaufgaben aber – wirtschaftlich betrachtet – keinen direkten Mehrwert. Hier ist also im Vorfeld Überzeugungsarbeit zu leisten, um im Management eine „Awareness“ zu schaffen. Zudem wollen wir ein deutliches Signal an alle Mitarbeiter des Unternehmens setzen.

Liebes Tagebuch! Aus zahlreichen Projekten weiß ich, dass Manager zwar verstanden haben, dass eine neue Herausforderung auf sie zukommt. Zu Beginn können sie sich jedoch noch kein genaues Bild davon machen, was dies konkret für sie bedeutet. Es hat sich bewährt, Übersichten für Arbeitspakete, erste Aufwandsschätzungen und Nutzenbetrachtungen vorzulegen; selbstverständlich in managementtauglicher 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:

Liebes Tagebuch! „Machen müssen wir es eh, also können wir es auch gleich richtig machen.“

Wenn wir also schon neue Prozesse und Methoden einführen müssen, dann sollten wir dies gleich in der richtigen Form tun.

Auch wenn die Experten schon ungeduldig mit den Hufen scharren und konkrete Arbeitsergebnisse erzeugen wollen, habe ich mich heute erst einmal mit dem Prozessmanagement des Unternehmens zusammengesetzt. Wir haben festgestellt, dass wir eine angepasste Prozesslandkarte mit Verantwortlichkeiten für unsere neuen Prozesse benötigen. Zudem stellten die Prozessmanager mir die Guideline zum Prozessdesign vor. Abschließend haben wir noch 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, liebes Tagebuch, da ich hier verhältnismäßig wenig Überzeugungsarbeit leisten musste.

Liebes Tagebuch! „Wie isst man einen Elefanten? Man schneidet ihn in kleine Scheiben und isst dann eine nach der anderen.“

Heute habe ich mich mit den Entwicklern getroffen; wir haben die Anpassung der Entwicklungsprozesse besprochen. Wie sich herausgestellt hat, waren ihnen die meisten Aufgaben ohnehin schon bekannt. In den letzten Jahren haben sie sich intensiv mit dem Thema Safety auseinandergesetzt. Daher sind viele Dokumente, wie z.B. 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 Testern, die schon eine Auswahl von Testmethoden in ihren Testplänen beschrieben haben.

Im Endeffekt stießen wir auf vier Themen (Bild 4), bei denen wir noch nach einer Lösung suchen müssen:

• Cybersecurity-Risikomanagement
• Threat Modelling
• Penetration Testing
• Data Management

Sicherlich am schwersten fiel uns das Zentrum, um das sich alles dreht: die gesamte Risikobetrachtung und Ermittlung potenzieller Gefahren. Wir sind froh, dass wir ein paar neue Kollegen im Team haben, die vorher in anderen Branchen tätig waren und das Thema schon sehr gut beherrschen. Sie bringen eine andere Sichtweise („Mis-Use case“) in unsere Betrachtung, ganz im Sinne von: „Denk wie ein Angreifer!“

Liebes Tagebuch! Heute haben wir uns in absolutes Neuland begeben. Gemeinsam mit Experten haben wir uns Gedanken darüber gemacht, wie die Organisationsprozesse zur Cybersecurity funktionieren sollen. Nach den eher projektbezogenen Aufgaben zuvor fehlt uns hier an vielen Stellen noch eine klare Vorstellung.

Vor allem beim Thema der Verantwortlichkeiten wird es anstrengend. Zwar sehen viele Bereiche die Aufgaben unbedingt bei sich, aber um die notwendige Ausarbeitung der Prozesse möchte sich niemand kümmern. Daher fällt viel Abstimmungsarbeit an.

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 alle einig, dass wir darüber noch einmal diskutieren müssen.“

Liebes Tagebuch! Der Projektalltag rückt näher und unser Unternehmen möchte jetzt gerne 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 sowie innerhalb des Unternehmens weiterzugeben. Das Cybersecurity-Team auf Organisationsebene und die Projekt-Teams 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. Beispielsweise kam kürzlich der Hinweis, dass es für die Durchführung der TARA einige interessante Bibliotheken gibt. Damit konnte unser Team den internen Risikokatalog weiter verbessern.

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.

Zudem überlegen wir zurzeit gemeinsam mit dem Prozessmanagement, ob uns regelmäßige Assessments nach etablierten Modellen wie Automotive SPICE (oder auch Automotive SPICE for Cybersecurity) nicht bei der Verbesserung unserer Prozessqualität helfen können. Liebes Tagebuch, 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, wie viele gute Verbesserungsvorschläge aus der Projektmannschaft kommen.

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 auf. Wir müssen die Produktentwicklung systematisch und kontrolliert betreiben, anstatt im permanenten Feuerwehrmodus zu verweilen. 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.