Risikomanagement-Systeme für Cybersecurity

Nun also ISO 21434. Reichen denn ISO 27001 oder TISAX nicht? Und warum spielen denn nun plötzlich ISO 26262 und die funktionale Sicherheit so eine Rolle? So und so ähnlich lauten die häufigsten Fragen vieler Kunden.

Bedeutung von ISO 21434

ISO 21434, die ganze ISO 270xx-Serie sowie TISAX haben – im Detail – völlig verschiedene Inhalte. Nur aus sehr oberflächlicher Perspektive ist alles irgendwie „nur“ das mit dem Hackerschutz.

Die wesentlichen Unterschiede:

  • ISO 27001 und sämtliche Teile dieser Normenfamilie drehen sich um den Schutz der eigenen Organisation. Tatsächlich klingt dieser Scope zunächst relativ ganzheitlich. In der Praxis hat sich herausgestellt, dass die hergestellten Produkte nicht umfasst sind. Auch wenn man gemäß ISO 27001 Zugangssicherungen wie Passworte oder auch Zugangskarten hat, heißt das keineswegs, dass die von der Organisation entwickelten und produzierten Airbag-Systeme ihrerseits ausreichen abgesichert gegen Angriffe und Hackversuche sind.
  • TISAX zielt vorwiegend auf den Schutz der Lieferkette ab. Hier dreht es sich im Kern darum, dass vor allem die Schnittstellen zwischen Lieferant und Kunde abgesichert sind. Schwerpunkte von TISAX-Assessments sind dementsprechend etwa der Schutz von Prototypen oder die Datensicherheit. Wiederum ist die Absicherung von Systemen, die den Kunden geliefert werden, nur am Rande betrachtet.
  • Damit ergibt sich die Lücke, die ISO 21434 schließt: die Absicherung von Systemen, die in Fahrzeuge integriert werden. Es geht um die Sicherheit in Fahrzeugen und nicht um die Sicherheit der Firma, die die Systeme baut oder der Daten, die zu deren Entwicklung ausgetauscht werden.

Schwerpunkte

ISO 21434 stellt damit notwendigerweise andere Anforderungen als die anderen Normen. Einmal sind Fahrzeugnetze anders aufgebaut als Firmennetze. Man verwendet mit CAN, LIN oder Flexray andere Protokolle und Bussysteme als etwa TCP/IP oder SMB. Es stehen auch keine Administratoren bereit, die schon mitkriegen, wenn sich Systeme irgendwo im Haus auffällig verhalten. Im Zweifelsfalle hört ein Hersteller nach dem Verkauf eines Fahrzeuges nie wieder davon. Solange es ein Zubehör im After Sales-Bereich zu verkaufen gilt, ist das nicht einmal unliebsam.

Gleichzeitig ist ein hohes Maß an Abstimmung zwischen Integratoren und Lieferanten notwendig. Systeme können so gewünscht sein, dass sie viele Absicherungs-Aufgaben für sich lösen. Und auf der anderen Seite können Integratoren durch die Gestaltung der Umgebung viel dazu betragen, dass Systeme einfacher und sicher sein können. Dazu müssen dann aber die Umgebungen in diesem Bereich mehr managen – oder z.B. separieren.

Da es im Fahrzeugbereich – anders als etwa im Bereich der Industriemaschinen – üblich ist, dass man kaum noch Kontrolle über das verkaufte Produkt hat, müssen Mechanismen zur Absicherung praktisch zu diesem Zeitpunkt implementiert sein. Verfahren wie Rückrufe existieren für dümmste Fälle natürlich – aber genau diese Konstellation will man möglichst am Wenigsten.

Risiko-Management: TARA

Best Practice für solche komplexen Anforderungen sind Systeme zum technischen Risikomanagement. Es handelt sich hier nicht um sog. High Level Managementsystem wie etwa bei ISO 27001, ISO 14001, IATF 16949 etc. mit einheitlicher Kapitelstruktur. Einige der Zutaten liegen aber vor:

  • Regelung der Zuständigkeit: zur Entwicklungsphase muss es einen Cybersecurity-Manager geben
  • Prozess-basierter Ansatz: die notwendigen Tätigkeiten müssen in Prozessen strukturiert werden
  • Risiko-basierter Ansatz: es notwendig Risiken zu bewerten, die von sog. Item-Funktionen ausgehen können

Spezifisch für den Automotive-Bereich ist hingegen die bereits mit ISO 26262 eingeführte Betrachtung des gesamten Produktlebenszyklus.

ISO 21434 führt eine neue Methodik zum Umgang mit den Produktrisiken ein: Threat Analysis and Risk Assessment, kurz TARA. Das Verfahren ist der FMEA nicht unähnlich und ist de facto eine Art Spezialisierung.

Dr. Gellner bringt aus zahlreichen Projekten Erfahrung mit und berät sie gerne bei:

  • der Gap-Analyse ihrer bestehende Prozesslandschaft
  • TARA-Verfahren für Systeme und Software
  • dem Aufbau der benötigen Damage- und/oder Threat-Szenarien
  • der Bewertung der Angriffs-Möglichkeiten nach den Attack Potential Based Approach, dem Common Vulnerability Scoring System oder der Attack Vector-Methode
  • der Erstellung sämtlicher erforderlicher Work Products
  • dem Sicherstellen der Traceabiliy
  • der Bewertung der Cybersecurity Mechanismen