car-security-incident-response -...

Car-Security-Incident-Response Projektbericht

Projektnummer 9810007

Projektlaufzeit 01.02.2017 – 31.07.2017

Autoren Gunnar Harde (Automotive Quality Institute GmbH) Dr. Jürgen Großmann (Fraunhofer-Institut FOKUS)

[email protected]

Datum 27.11.2017

mailto:[email protected]

Diese Veröffentlichung basiert auf dem Expertenwissen aus dem AQI und wissenschaftlicher Partner.

Sie stellt einen konsolidierten Standpunkt zum entsprechenden Themenkomplex dar.

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht

ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung.

Inhalt

Prolog: die Erpressung .......................................................................................................................... 1

Einleitung .............................................................................................................................................. 2

TEIL 1: GRUNDLAGEN ................................................................................................. 3

Herausforderung Car-Security-Incident-Response ............................................................................... 3

Prozessuale und organisatorische Grundlagen .................................................................................... 5

Ein Prozessreferenzmodell für Security-Incident-Response ................................................................ 8

Car-Security-Incident-Response-Prozess ........................................................................................... 20

Aufgaben des Qualitätsmanagements ................................................................................................ 29

TEIL 2: HANDLUNGSEMPFEHLUNGEN ........................................................................ 30

Handlungsempfehlungen an das Topmanagement ............................................................................ 30

Handlungsempfehlungen an das Car-SIR-Team ................................................................................. 34

Handlungsempfehlungen an Komponentenverantwortliche .............................................................. 39

Handlungsempfehlungen an den IT-Betrieb ....................................................................................... 40

TEIL 3: BEWERTUNG DER CAR-SIR-FÄHIGKEIT ........................................................... 41

Integration in das Automotive-SPICE-Bewertungsmodell .................................................................. 41

Fragenkataloge zur Evaluierung der Prozessleistung ........................................................................ 44

Zusammenfassung ............................................................................................................................. 56

ANHANG ................................................................................................................. 57

Glossar ............................................................................................................................................... 57

Stand der Technik ............................................................................................................................... 58

Literaturverzeichnis ............................................................................................................................ 63

Car-Security-Incident-Response 1

Prolog: die Erpressung

Folgendes Szenario:

Hacker wollen die Fahrzeuge einer Marke so manipulieren, dass sie sich nicht mehr starten lassen,

um dann vom Hersteller der Fahrzeuge Gelder zur Beendigung des Angriffs erpressen zu können.

Die Hacker analysieren dazu die Infotainment-Systeme in verschiedenen Fahrzeugmodellen und

stellen fest, dass der Hersteller eines Infotainment-Systems, das in vielen Fahrzeugen der Marke

verbaut ist, den Port 6667, einen Port für die interne Kommunikation innerhalb des Infotainment-

Busses, für den externen Zugriff offengelassen hat. Diesen offenen Port nutzen die Hacker, um

über das Internet Zugriff auf die Fahrzeuge zu erhalten. Die Angreifer finden zudem heraus, dass

es möglich ist, Code einzuschleusen, der vom Infotainment-System ausgeführt wird. Damit haben

sie die Möglichkeit das Verhalten des Infotainment-Systems zu manipulieren.

Das Infotainment-System ist physisch über den Chip V850 mit dem CAN-Bus verbunden. Jedoch

ist ein Zugriff auf den CAN-Bus über das Infotainment-System direkt nicht möglich. Um dies zu

ändern, laden die Hacker die im Netz frei verfügbare Systemsoftware für den Chip herunter und

analysieren diese. Schließlich gelingt es ihnen, eine manipulierte Version der Chip-Software über

das Infotainment-System einzuspielen, der ihnen den Zugriff auf den CAN-Bus erlaubt. All dies

gelingt ihnen remote über das Internet. Als nächstes steuern die Hacker über den CAN-Bus Nach-

richten so ein, dass das Motorsteuergerät in den Boot-Mode gesetzt wird und somit der Motor

nicht mehr gestartet werden kann.

Die Angreifer manipulieren zeitgleich viele Fahrzeuge der Marke. Danach warten sie ab bis der

Angriff publik wird, um dann an den Hersteller mit der Lösegeldforderung zur Beendigung des

Angriffs heranzutreten. Erst bei erfolgter Zahlung informieren die Angreifer den Hersteller über

die ausgenutzten Sicherheitslücken.

Das hier skizzierte Angriffsszenario ist fiktiv. Bis 2015 wäre ein solcher Angriff jedoch tatsächlich

möglich gewesen. Dieses Angriffsszenario basiert auf den Arbeiten von Dr. Charlie Miller und

Chris Valasek, denen es 2015 gelang über eine Internetverbindung auf den CAN-Bus eines 2014

Jeep Cherokee zuzugreifen (Miller/Valasek 2015).


Einleitung

Der Einzug innovativer Informations- und Kommunikationstechnologien mit Internetkonnektivi-

tät in Kraftfahrzeugen führt zu neuen Herausforderungen an die Absicherung und Wartung der

gesamten Fahrzeugelektronik inklusive ihres ständig wachsenden Softwareanteils. Neben der Be-

reitstellung und Pflege sicherer Systeme zählt hierzu auch die Fähigkeit der Automobilhersteller

sowie ihrer Zulieferer auf Hackerangriffe auf Fahrzeuge rasch und umfassend reagieren zu kön-

nen.

Sowohl Kunden, die Öffentlichkeit als auch Regulierungsbehörden erwarten, dass OEMs und

Zulieferer technische und organisatorische Maßnahmen treffen, mit denen sichergestellt wird,

dass Car-Security-Vorfälle, die durch Hackerangriffe oder sonstige unerwünschte Aktivitäten aus-

gelöst werden, effektiv erkannt, ihre Ursachen beseitigt und ihre Folgen gemindert werden.

Hierzu dient der Car-Security-Incident-Response-Prozess (Car-SIR-Prozess).

Car-SIR wird insbesondere dann zu einer großen Herausforderung, wenn die Analyse eines Car-

Security-Vorfalls nicht, wie beispielsweise im Falle des Chrysler-Hacks, von den Hackern selber

gemeldet wird, sondern Ursache und folgen auf Basis von Nutzerdaten und -reports eigenständig

abgeleitet werden müssen. Die dafür notwendige Expertise stammt in der Regel aus verschiede-

nen Organisationsbereichen, die bereits im Falle eines Verdachts auf einen Car-Security-Vorfall,

abhängig von der jeweiligen Ausprägung des Vorfalls, aktiviert und zusammengeführt werden

müssen.

Darüber hinaus muss das Unternehmen in der Lage sein,

• zügig die Risiken eines solchen Vorfalls zu bewerten,

• angemessene Maßnahmen zur Eindämmung der Folgen zu erarbeiten und auszuführen,

• die dem Vorfall zugrundeliegenden Sicherheitslücken zu identifizieren und zu entfernen

sowie

• Kunden, Öffentlichkeit und Behörden die erforderlichen Informationen zum Umgang

mit dem Vorfall bereitzustellen.

Im Folgenden wird ein Car-SIR-Musterprozess beschrieben, der als Basis für die Etablierung sol-

cher Prozesse in den jeweiligen Automotive-Unternehmen dienen kann. Dieser Musterprozess ist

so generisch, dass daraus prinzipiell jedes Unternehmen der Automobilbranche einen für sich

adäquaten Prozess ableiten kann; gleichzeitig berücksichtigt er die derzeit bereits existierenden

Prozesse in der Automobilindustrie wie z. B. die Prozesse zur Bearbeitung von Schadensfällen,

zum Abstellen von Fehlern und zum Rückruf defekter Fahrzeuge. Ergänzend dazu wurde ein Fra-

genkatalog zur Prüfung der Car-SIR-Fähigkeiten für Unternehmen der Automobilindustrie erar-

beitet und dokumentiert.


TEIL 1: GRUNDLAGEN

Herausforderung Car-Security-Incident-Response

Ziel des Car-SIR-Prozesses ist es, Car-Security-Vorfälle so schnell wie möglich zu erkennen und

wirksame Gegenmaßnahmen durchzuführen, sodass

• die Sicherheit (Safety) der Verkehrsteilnehmer gewährleistet bleibt bzw. schnell wieder-

hergestellt wird,

• der Funktionsumfang eines Fahrzeugs vor Kunde erhalten bleibt bzw. schnell wieder be-

reitgestellt wird,

• datenschutzrechtliche Anforderungen erfüllt bleiben bzw. schnell wieder eingehalten

werden und

• wirtschaftliche Schäden für Unternehmen der Automobilindustrie abgewendet bzw. mi-

nimiert werden.

Um diese Ziele zu erreichen, muss der Car-SIR-Prozess Folgendes leisten:

1. Möglichst alle Car-Security-Vorfälle müssen erkannt und den verantwortlichen Stellen

gemeldet werden.

2. Car-Security-Vorfälle müssen möglichst schnell bearbeitet werden, sodass Gegenmaß-

nahmen schnell greifen.

3. Car-Security-Vorfälle müssen entsprechend ihrer Dringlichkeit und Kritikalität priori-

siert bearbeitet werden.

4. Es müssen die richtigen Gegenmaßnahmen ergriffen werden, um die Bedrohung mög-

lichst nachhaltig und wirksam zu beseitigen.

5. Die Gegenmaßnahmen müssen zielgerichtet sein, um so unnötige Aufwände und Unan-

nehmlichkeiten für Kunden, wie z. B. nicht erforderliche Rückrufe, zu vermeiden.

6. Der Car-SIR-Prozess sollte effizient sein.

Im Gegensatz zur in der Automobilindustrie etablierten Bauteil-fokussierten Schadensfallbear-

beitung müssen drei besondere Herausforderungen durch den Car-SIR-Prozess bewältigt werden:


1. Das Erkennen und Beheben von Car-Security-Vorfällen erfordert einen hohen Grad an

Security-Expertise. Die Unternehmen der Automobilindustrie müssen weiter in den Auf-

bau von IT-Security-Expertise investieren. Neben dezidierten Security-Fachabteilungen

muss auch eine grundlegende IT-Security-Expertise in beim Qualitätsmanagement, im

Service und in allen Entwicklungsbereichen sichergestellt werden.

2. Bei der Analyse eines Car-Security-Vorfalls und bei dem Erstellen eines Aktionsplans

müssen funktionale und nichtfunktionale Abhängigkeiten der IT-Komponenten verstan-

den und berücksichtigt werden. Entscheidend hierfür ist eine systemische Sicht bei der

Ursachenanalyse, nicht so sehr eine Bauteilsicht. Nur so lassen sich letztendlich Car-

Security-Vorfälle verstehen und effektive und nachhaltige Gegenmaßnahmen einleiten.

3. Sicherheitsvorfälle können extrem dringlich sein und ein unmittelbares Handeln erfor-

dern. In Notfallsituationen müssen die Verantwortlichen schnell informiert und über Maß-

nahmen entscheiden und diese einleiten können. Hierzu bedarf es ergänzend zu den bis-

herigen Prozessen zur Schadensfallbearbeitung über den Händler einer Service-Infra-

struktur, die 24/7 verfügbar ist und sich den Mitteln der modernen IT-Kommunikation

bedient.

Zudem gibt es noch eine weitere Herausforderung, die für alle unerwarteten Ereignisse – und

Vorfälle sind immer unerwartete Ereignisse – gilt: Sie sind nicht planbar. Es liegt in der Natur von

Vorfällen, dass weder der Zeitpunkt des Auftretens noch der Aufwand und die benötigten Res-

sourcen für ihre Analyse und Behebung vorhersagbar sind. Dies gilt gerade auch für Sicherheits-

vorfälle mit ihrer Vielfalt und hohen Komplexität. Das Spektrum der möglichen Sicherheitsvor-

fälle reicht von einem Zugriff auf einen Port, der versehentlich nicht geschlossen wurde, bis hin

zu hochkomplexen Angriffen auf das Produktionssystem, die das Einschleusen von korrumpierten

Sicherheitszertifikaten und somit das Einspielen von Schadsoftware in Fahrzeuge ermöglichen.

Eine detaillierte Prozessdefinition, die allen diesen unterschiedlichen Angriffsszenarien und mög-

lichen Gegenmaßnahmen gerecht wird, kann vorab nicht festgelegt werden. Ebenso wenig lässt

sich der Kreis der an der Bewertung und Behebung teilnehmenden Personen für alle Sicherheits-

vorfälle und für alle Organisationen vorab bestimmen. So können beispielsweise Vertreter aus

HR, PR, Datenschutz oder anderen Bereichen bei einem Sicherheitsvorfall involviert sein, um

ggfs. Personalmaßnahmen, Öffentlichkeitsmaßnahmen oder Datenschutzmaßnahmen zu flankie-

ren.

Entscheidend für einen effektiven Car-Security-Incident-Response-Prozess ist die Kompetenz der

Mitarbeiter, die an dem Prozess beteiligt sind, sei es als Melder eines Verdachts, als Analyst eines

Vorfalls oder als Entscheider über die zu treffenden Maßnahmen. Auch wenn im Folgenden ein

Car-SIR-Prozess hergeleitet und beschrieben ist, so darf dieser die Fach- und Entscheidungskom-

petenz der Experten nicht einschränken. Nur so kann sichergestellt werden, dass die Organisation

auf die Vielzahl der bislang unbekannten zukünftigen Sicherheitsvorfälle angemessen reagieren

kann.


Statt detailliert vorzugeben, wie die Mitarbeiter mit Vorfällen umzugehen haben, sollten das Ma-

nagement vielmehr die Rahmenbedingungen schaffen, die den Mitarbeitern einen kompetenten

Umgang mit Vorfällen ermöglichen. Dazu gehört die Bereitstellung der notwendigen Sach- und

Entscheidungskompetenz, die Etablierung von Schnittstellen für eine effektive Zusammenarbeit

zwischen den beteiligten Organisationseinheiten und die Bereitstellung von Ressourcen und Per-

sonal, die im Falle eines Sicherheitsvorfalls, abhängig von der Brisanz des Vorfalls, zur Verfügung

stehen.

Neben der Prozessbeschreibung werden daher auch Empfehlungen gegeben, wie das Unterneh-

men als lernende Organisation das notwendige Fachwissen integrieren und den Car-SIR-Prozess

testen und kontinuierlich verbessern kann.

Prozessuale und organisatorische Grundlagen

Der Basisprozess

Ausgangspunkt für die Herleitung eines Car-SIR-Prozesses ist der Automotive-unabhängige SIR-

Prozess, wie er in den einschlägigen Standards vorgeschlagen wird (ISO/IEC 2016, NIST 2012,

SANS 2007, BSI 2016, MU/SEI 2003, ISACA 2012). Demnach lässt sich ein SIR-Prozess in vier

Abschnitte unterteilen:

1. Sicherheitsvorfall erkennen und erfassen

2. Sicherheitsvorfall bewerten und klassifizieren

3. Maßnahmen beschließen und auf Sicherheitsvorfall reagieren

4. Aus Sicherheitsvorfall lernen und Prozess und Produkt optimieren

Diese vier Prozessschritte erfolgen für jeden Sicherheitsvorfall weitgehend sequentiell in der oben

genannten Reihenfolge. Das Reagieren auf Sicherheitsvorfällen kann jedoch auch schon erfolgen,

wenn die Bewertung noch nicht abgeschlossen ist. So können Notfallmaßnahmen schon nach

einer rudimentären Bewertung der Situation beschlossen und durchgeführt werden, während die

Detailbewertung mit den anschließenden langfristigeren Maßnahmen erst danach erfolgt.


Abbildung 1: Die Hauptphasen eines Security-Incident-Response-Prozesses

Neben diesen vier Prozessschritten gibt es noch vorbereitende Aktivitäten, die dem Security-In-

cident-Response-Prozess vorangehen und die ggf. aufgrund der Lessons-Learned, die während

des SIR-Prozesses gewonnen wurden, anzupassen sind (siehe Abbildung 1). Diese vorbereitende

Planung und Konzeption des SIR-Prozesses umfasst (BSI 2016)

• die Etablierung einer Vorgehensweise zur Behandlung von Sicherheitsvorfällen,

• die Festlegung von Verantwortlichkeiten bei Sicherheitsvorfällen,

• die Festlegung von Meldewegen für Sicherheitsvorfälle,

• eine Eskalationsstrategie für Sicherheitsvorfälle,

• die Festlegung von Prioritäten für die Behandlung von Sicherheitsvorfällen,

• die Erstellung einer Richtlinie für die Behandlung von Sicherheitsvorfällen und

• die Definition eines Sicherheitsvorfalls.

Mehr zum Aufbau eines Car-SIR-Prozesses in Teil 2: Handlungsempfehlungen.

Grundsätzlich ist es empfehlenswert, den SIR-Prozess so aufzusetzen, dass nicht nur tatsächlich

aufgetretene Sicherheitsvorfälle, sondern auch Ereignisse, die eine potentielle Sicherheitsbedro-

hung darstellen, im Rahmen des SIR-Prozesses behandelt werden. Hierzu zählen neu entdeckte

Sicherheitslücken ebenso wie bisher nicht berücksichtigte Angriffsmethoden und Werkzeuge. Die

Bewertungen und Reaktionen auf solche Sicherheitsereignisse ähneln denen von Sicherheitsvor-

fällen, und die Bearbeitung sollte grundsätzlich von denselben Mitarbeitern erfolgen.

Das Security-Incident-Response-Team

Die Bewertung von Sicherheitsvorfällen und die Festlegung von Gegenmaßnahmen erfordert Ex-

pertenwissen und Entscheidungskompetenz, die in den einzelnen Entwicklungsteams in der Regel


nicht vorhanden sind. Daher sollte ein dezidiertes Team für die Behandlung von Sicherheitsvor-

fällen zuständig sein. Dieses Security-Incident-Response-Team (SIR-Team)1 übernimmt die Ver-

antwortung für die Bearbeitung von Sicherheitsvorfällen und koordiniert alle notwendigen Akti-

vitäten zur Behebung der damit verbundenen Bedrohungen. Das SIR-Team verantwortet damit

den gesamten Lebenszyklus eines der Organisation bekannt gewordenen Vorfalls, ausgehend von

der ersten Meldung bis zum Abschluss aller Gegenmaßnahmen.

Ein SIR-Team ist zudem erforderlich, weil ein Sicherheitsvorfall sich oftmals nicht klar einer

einzigen Sicherheitslücke und damit einer Systemkomponente zuordnen lässt. Vielmehr nutzten

Hacker ein unzureichend gesichertes Zusammenspiel verschiedener Komponenten. Die Zuwei-

sung eines Sicherheitsvorfalls zu einem Entwicklungsteam ist daher nicht zielführend. Vielmehr

muss die Behebung von Bedrohungen entwicklungsteamübergreifend erfolgen. Genau dies ist die

wesentliche Aufgabe eines SIR-Teams: Es übernimmt die notwendige funktional-systemische

Sicht bei der Analyse und Behebung der Sicherheitslücken und übersteuert ggf. die Rollout-Pläne

der einzelnen Entwicklungsteams.2

Das SIR-Team wird immer dann eingeschaltet, wenn ein ernsthafter Verdacht auf einen (potenti-

ellen) Sicherheitsvorfall vorliegt. Das SIR-Team ist maßgeblich für die Bewertung und die Reak-

tion auf den Sicherheitsvorfall verantwortlich. Je nach Sicherheitsvorfall kann und sollte das SIR-

Team um Experten und/oder Entscheidungsträger erweitert werden bzw. diese in die Vorfallsbe-

arbeitung mit einbinden, wenn diese die Vorfallsbearbeitung sinnvoll unterstützen können. So

kann jedes Unternehmen je nach Anzahl der zu erwartenden Sicherheitsvorfälle für sich entschei-

den, ob primär bestehende Organisationsstrukturen außerhalb des SIR-Teams genutzt und das

SIR-Team im Wesentlichen koordinierende Aufgaben wahrnimmt oder ob ein großes SIR-Team

eher eigenständig Sicherheitsvorfälle bearbeitet. Im Folgenden ist mit dem erweiterten SIR-Team

das temporär je Sicherheitsvorfall aufgestellte Team bestehend aus dem SIR-Team und weiteren,

für die jeweilige Bearbeitung des Sicherheitsvorfalls notwendigen Experten und Entscheidern ge-

meint.

Die Bewertung von Sicherheitsvorfällen und die Reaktion auf diese muss sowohl technisch als

auch organisatorisch-rechtlich erfolgen. Technisch bedeutet: die technische Analyse des Vorfalls

1 Neben SIR-Team sind auch alternative Begriffe wie CERT (Computer-Emergency-Response-Team),

CSIRT (Computer-Security-Incident-Response-Team) und IRT (Incident-Response-Team) gebräuchlich

(Hoyer 2006: 11). Zudem kann zwischen Sicherheitsteam, dezentrales CERT, zentrales CERT,

kombiniertes CERT und koordinierendes CERT unterschieden werden (Hoyer 2006: 16ff). Da diese

konkreten Organisationsformen von den Rahmenbedingungen eines Unternehmens abhängen, wird hier

bei einer unternehmensübergreifenden Betrachtung auf diese Differenzierung verzichtet.

2 Hingegen ist es nicht generell Aufgabe des SIR-Teams, Security-Anforderungen zu formulieren, bei der

Softwareentwicklung zu beauftragen oder einzufordern und diese zu validieren. Security sollte nicht

singulär betrachtet, organisatorisch separiert und aus dem Entwicklungsprozess ausgelagert werden.

Security sollte ein integraler Bestandteil des Softwareentwicklungsprozesses sein und durch die

Softwareentwicklung inkl. Product-Owner und Softwarearchitekten verantwortet werden, nicht durch das

SIR-Team.


einschließlich ihrer technischen Auswirkungen, die Suche nach Sicherheitslücken und die Einlei-

tung und Durchführung technischer Gegenmaßnahmen wie beispielsweise das Beheben von Soft-

warefehlern oder die Neukonfiguration eines IT-Systems; organisatorisch-rechtlich bedeutet: die

Bewertung des Sicherheitsvorfalls aus haftungsrechtlicher, datenschutzrechtlicher, finanzieller

und organisatorischer Sicht und das Einleiten von nicht-technischen Maßnahmen wie z. B. die

Kommunikation mit Behörden, Kunden oder der Öffentlichkeit.

Die oben beschriebene Organisationsstruktur ist in Abbildung 2 zusammenfassend skizziert, er-

gänzt um die Dokumentation, die durchgehend den Gesamtprozess begleitet.

Ein Prozessreferenzmodell für Security-Incident-Response

Im Folgenden werden die Teilprozesse des Incident-Response-Prozesses als Referenzprozess an-

hand von Tabellen beschrieben. Sowohl Art als auch Umfang der Prozessspezifikation entspre-

chen den Anforderungen eines Referenzmodells nach SPICE (SPICE 2012) bzw. Automotive

Abbildung 2: Grundlegende Rolle des SIR-Teams beim Security-Incident-Response-Prozess


SPICE (A-SPICE 2015) und erlauben dadurch die Integration dieses Modells in SPICE bzw. Au-

tomotive SPICE konforme Prozessevaluationen (siehe Teil 3).

Der Security-Incident-Response-Referenzprozess untergliedert sich in die vier Teilprozesse „De-

tect & Register“, „Assess & Classify“, „Decide & Respond“ und „Learn & Optimize“. Alle Teil-

prozesse im Referenzprozess sind in Form von Tabellen beschrieben, die explizit den Zweck des

jeweiligen Teilprozesses (process purpose) definieren, die erwarteten Prozessergebnisse (process

outcome) spezifizieren, geeignete Grundpraktiken (base practices) beschreiben sowie die zu er-

zielenden Ergebnisartefakte (output work products) auflisten. Sowohl die Grundpraktiken als

auch die Ergebnisartefakte referenzieren auf die durch sie erzielten bzw. dokumentierten Prozes-

sergebnisse. Das Referenzmodell ist in englischer Sprache verfasst, um die Anschlussfähigkeit an

Automotive SPICE bzw. an weitergehende internationale Standardisierung sicherzustellen.

Sicherheitsvorfall erkennen und erfassen (Detect & Register)

Der SIR-Prozess beginnt mit dem Erkennen und Erfassen eines Sicherheitsvorfalls. Hierbei kön-

nen eine Vielzahl unterschiedlicher Fälle auftreten: Kunden melden Vorfälle beim Händler, der

Betrieb stellt Sicherheitsereignisse anhand der Auswertung von Log-Dateien fest, auf Konferen-

zen stellen Security-Experten entdeckte Sicherheitslücken vor, etc. Die Quellen für Hinweise auf

Sicherheitsvorfälle oder Sicherheitsbedrohungen können vielfältig sein, ebenso der Grad der Ge-

wissheit, ob ein Sicherheitsvorfall tatsächlich vorliegt – angefangen von Verdachtsmomenten bis

hin zu komplett dokumentierten Hackerangriffen.

Zur Entgegennahme von Vorfällen, auch von Sicherheitsvorfällen, hat sich in der IT-Branche eine

zwei- oder dreistufige Support-Organisation in vielen Unternehmen bewährt.

Neben Sicherheitsvorfällen können auch Sicherheitsbedrohungen, also Ursachen für potentielle

Sicherheitsvorfälle, über diese Infrastruktur erfasst (z. . meldet ein Lieferant oder eine Behörde

eine solche Bedrohung) oder nach ihnen aktiv gesucht werden (z. B. durch Teilnahme an Sicher-

heitskonferenzen oder die aktive Suche im Darknet).

Zu den organisatorischen Voraussetzungen für die erfolgreiche Erkennung und Erfassung von Si-

cherheitsvorfällen gehören eine geeignete Support-Infrastruktur, um den Kontakt zum Kunden

und Nutzer realisieren zu können, gut ausgebildete Mitarbeiter, die in der Lage sind, Sicherheits-

vorfälle bzw. Hinweise darauf zu erkennen und zu dokumentieren, sowie notwendige Definitio-

nen und Sicherheitsrichtlinien, die es erst ermöglichen, einen Sicherheitsvorfall von der Normal-

situation oder einer regulären Service-Situation zu unterscheiden.

Die folgende Tabelle beschreibt Details und die organisatorischen Voraussetzungen des Teilpro-

zesses „Sicherheitsvorfall erkennen und erfassen (Detect & Register)“.


Detect & Register

Process purpose Security Incident Detection & Registration aims to support the detec-

tion of security incidents (i.e. attacks, intrusions, security policy vio-

lations) and suspicious security events. It provides means to receive,

register, accept and forward incident reports from external and inter-

nal parties (support infrastructure).

Process outcome Results of successful implementation of this process are:

1. Information related to security incidents are systematically col-

lected

2. Reports on security related incidents or security related events are

registered and documented

3. Reports on security incidents or security events are classified so

that responsibility is exposed

4. Reports on security incidents or security events are assigned for

further processing

Base practices SIR.1.BP1 Monitor and supervise system: Check for security related

events and security events in systems and products. This activity is

related to the systematic analysis of IT and product related data that

may show intrusion attempts, anomalies in usage and suspicious

network traffic. It is best supported by means of tools that allow to

collect, centralize, aggregate, and visualize system monitoring data

(e.g. SIEM tools) in the field and in the IT infrastructure. [OUTCOME 1]

SIR.1.BP2 Monitor public information pools: Check for security re-

lated reports in public information pools, press and other media. This

activity consists of a systematic and periodic analysis of publicly

available information on emerging security threats, new vulnerabili-

ties, and new attack capabilities that are related to the organizations

services and products. This may be complemented by dedicated

threat intelligence services and tools which actively push this kind of

information into the organization. [OUTCOME 1]


SIR.1.BP3 Accept and register: Accept and register security inci-

dents and security events. This activity requires the availability of

dedicated contact point that are known in public and inside the or-

ganization. The contact points shall be available 24/7 and allow for

an initial registration of reports related to security incidents and se-

curity events. The registration process shall be able to document all

incident or event related information as well as information related

to the reporter (e.g. name, phone number, etc.) [OUTCOME 2]

SIR.1.BP4 Assign security incidents and security events: Assign re-

ports on security incidents and security events to internal entities

that can further validate, assess and, if required, respond the re-

ported security incident. [OUTCOME 3, 4]

Output work products Security incident report: An incident report is the documentation of

a reported security incident and related security events. It contains

information related to the reporter (name, contact details), the time

(time of registration, time of observation), the reporter's observa-

tion on origin, effects and status and all other information that are

initially available. → [OUTCOME 1, 2, 3, 4]

Sicherheitsvorfall bewerten und klassifizieren (Assess & Classify)

Das SIR-Team analysiert einen Sicherheitsvorfall und schätzt dessen Auswirkungen ab, beides

sowohl technisch als auch organisatorisch-rechtlich. Daher sollte das SIR-Team sowohl techni-

sche als auch organisatorisch-rechtliche Expertise haben bzw. darauf zugreifen können.

Das technische SIR-Team analysiert die Ursachen eines Sicherheitsvorfalls. Zu den Ursachen ge-

hören sowohl die Sicherheitslücken als auch die Identität, Motivation und Expertise der Angreifer.

Grundsätzlich besteht das Ziel der Analyse darin, den Sicherheitsvorfall zu verstehen und nach-

zuvollziehen, um eine möglichst gute Basis für das Ableiten von Sofortmaßnahmen und länger-

fristigen Gegenmaßnahmen zu haben. Darüber hinaus schätzt das technische SIR-Team ab, wel-

che Angriffsszenarien aufgrund der gefundenen Sicherheitslücken und der identifizierten Moti-

vation und Expertise der Angreifer grundsätzlich möglich sind. Hierzu kann das technische SIR-

Team je nach Sicherheitsvorfall erweitert werden, z. B. durch Softwarearchitekten oder andere

IT-Spezialisten oder IT-Entscheidungsträger.

Die organisatorisch-rechtliche Betrachtung beinhaltet die Risikobewertung unter Berücksichti-

gung haftungsrechtlicher, datenschutzrechtlicher, finanzieller und organisatorischer Aspekte.


Auch hier wird das Team je nach Sicherheitsvorfall um Mitarbeiter aus anderen Bereichen unter-

stützt, wie beispielsweise aus den Bereichen PR oder Datenschutz.

Die folgende Tabelle beschreibt Details und die organisatorischen Voraussetzungen des Teilpro-

zesses „Sicherheitsvorfall bewerten und klassifizieren (Assess & Classify)“.

Assess & Classify

Process purpose Security Incident Assessment & Classification aims to validate secu-

rity incident reports, to assess security incidents and to identify the

technical and organizational causes and impacts of incidents. This

includes the identification of vulnerabilities, the assessment of the

technical and business impact, and digital forensics.


1. The content of each security incident report is validated

2. Immediate actions have been triggered if required

3. The technical and business impacts of an incident are sufficiently

known

4. The causes of an incident are sufficiently known (attacker, moti-

vation, vulnerabilities)

5. Proofs and evidence on origin, effects and course of an incident

are kept safe

6. Internal stakeholders are informed


Base practices SIR.2.BP1 Assess and classify security incident report: Assess and

classify security incident report in terms of validity and criticality.

This activity validates and classifies each incident report. It supports

a first decision whether the report contains information on security

incidents and whether the reported security events require further in-

vestigation. It raises questions like:

1. Is the report trustworthy and valid?

2. What is the criticality of the affected service, system, or applica-

tion?

3. What is the potential damage or liability with respect to the inci-

dent?

4. Is it an active problem, a threat, or an incident-in-progress?

5. Is the intrusion dormant or completed?

As a result, this activity produces an initial classification of the inci-

dent report that is basis for further investigation and treatment [OUT-

COME 1].

SIR.2.BP2 Initiate immediate actions: If required, this activity initi-

ates immediate actions that are required to prevent and contain dam-

age and preserve evidence in case of rapidly evolving threat. It may

trigger any actions related to “Assess& Classify” as well as “Decide &

Respond”.

SIR.2.BP3 Technical impact analysis: This activity aims for analyze

and assess the technical impacts of the incident. It is meant as an

initial step to identify which products or services are [OUTCOME 3].

SIR.2.BP4 Risk analysis: Analyze and assess the business and legal

risks [OUTCOME 3].

SIR.2.BP5 Forensics: Assessment of compromised systems and safe

keeping of traces, logging data and other forms of proofs [OUTCOME

4,5].

SIR.3.BP6 Internal incident reporting: Distribute incident-related in-

formation to affected parties and stakeholders [OUTCOME 6].


Output work products 1. Incident record: An incident record is a record with all the de-

tails of an incident that document the status of the incident re-

sponse. It contains life cycle information starting with the initial

incident detection until the incident resolution and closure. It

may refer to additional records that are related to the incident

like incident reports, vulnerability records, forensic analysis,

countermeasure documentation, etc. → [OUTCOME 1, 2]

2. Incident prioritization list: Is a sorted list of incident records

that organizes the order and schedule for assessment and re-

sponse. → [OUTCOME 1]

3. Assessment result: Is the documentation of the incident as-

sessment. It contains the results of the technical impact and

risk analysis as well as information regarding causes and origin.

→ [OUTCOME 3,4]

4. Forensic artifacts: Collected list of artifacts that complement

the assessment results with data that come from forensics like

malicious binaries, memory dumps, system log files etc.

Note: Storage of forensic data must adhere specific requirements

with respect to confidentiality, integrity and long-term preserva-

tion. → [OUTCOME 5]

5. Internal incident notification: Is a document about the security

incident and its importance for the organization that is appro-

priate for internal communication within the organization.

Note: Depending on the target group, such a document may vary

widely in its information content and its confidentiality. → [OUT-

COME 6]

Maßnahmen beschließen und auf Sicherheitsvorfall reagieren (Decide & Respond)

Ebenso wie bei der Bewertung muss bei der Reaktion auf den Sicherheitsvorfall zwischen tech-

nischen und organisatorisch-rechtlichen Maßnahmen unterschieden werden. Das erweiterte SIR-

Team stimmt zwar einen gemeinsamen Maßnahmenplan ab und steht weiter in enger Abstim-


mung, die Maßnahmen werden jedoch sowohl technisch als auch organisatorisch-rechtlich geson-

dert betrachtet. Je nach Organisationsstruktur in den einzelnen Unternehmen kann die Aufteilung

der Aufgaben in organisatorisch-rechtlichen und technischen Unterteams erfolgen.

Das technische SIR-Team verantwortet technische Maßnahmen, insbesondere das Beheben von

sicherheitsrelevanten Softwarefehlern und die Neukonfiguration fehlerhaft konfigurierter Sys-

teme. Das organisatorisch-rechtliche SIR-Team kümmert sich um die nicht-technischen Maßnah-

men wie beispielsweise die Kommunikation mit externen Stakeholdern.

Typischerweise besteht der Maßnahmenplan aus

• Maßnahmen zur Eindämmung des Schadens,

• Maßnahmen zum Entfernen der Schadensursache,

• Maßnahmen zur Wiederherstellung der Betriebsfähigkeit und

• Maßnahmen zur Beweissicherung und juristischen Verfolgung des Angreifers.

Jede Maßnahme bzw. jedes Maßnahmenbündel durchläuft dabei folgende Prozessschritte:

1. Definition der Maßnahme

2. Entscheidung über die Durchführung der Maßnahme

3. Definition der Akzeptanzkriterien zur Validierung der Maßnahmenwirksamkeit

4. Durchführung der Maßnahme

5. Validierung der Maßnahmenwirksamkeit

Die folgende Tabelle beschreibt Details und organisatorische Voraussetzungen des Teilprozesses

„Maßnahmen beschließen und auf Sicherheitsvorfall reagieren (Decide & Respond)“.

Decide & Respond

Process purpose Security Incident Decision & Response aims to ensure the

confidentiality, integrity and availability of an organization's cyber

services and products by responding to incidents (i.e. attacks and

intrusions, and other kinds of security policy violations), and thus

minimizing the damage incurred by security breaches.



1. User and relevant stakeholders are informed if required

2. Countermeasures are specified and agreed

3. Countermeasures are executed and controlled

4. Incidents are resolved

5. Forensic evidence is documented and archived

Base practices SIR.3.BP1 Countermeasure definition and decision: This activity

aims for the definition and decision on countermeasures that

eliminate the incident cause, mitigate the consequences and initiate

the associated changes to the product or service. This may include

technical actions such as software updates, new or changed security

configurations (e.g. firewall settings), application of custom

configurations, creation of new accounts and application of access

controls. [OUTCOME 2]

SIR.3.BP2 External incident reporting: If required, inform users and

other stakeholders of the product or service failures as soon as pos-

sible. This process includes the distribution of other information rel-

evant to stakeholders, e.g. security alerts. [OUTCOME 1]

Note: This activity may be smoothly integrated with the decision

process in SIR.3.BP1 and the execution process in SIR.3.BP3.

SIR.3.BP3 Countermeasure execution and control: This activity aims

for the execution and control of the countermeasures that are

defined in “Assess& Classify” as well as “Decide & Respond”. Since,

the measures aim for recovering to an operational, safe and secure

state in products and systems, the execution process require

appropriate testing and assurance of the product’s and system's

integrity and stability before rollout. Moreover, it requires the

assessment and validation of the countermeasure effectiveness with

respect to the identified threats after rollout. Finally, effective

customer service including regular communication with external

stakeholders ensures that relevant external parties are informed of

the mitigation and recovery process. [OUTCOME 2,3]


SIR.3.BP4 Incident monitoring and escalation: This activity aims for

continuously monitoring the process status of unresolved incidents

so that additional countermeasures may be introduced as soon as

possible if threats are addressed improperly or service-levels are

likely to be breached. [OUTCOME 3]

SIR.3.BP5 Security incident and forensic closure: Control the

completeness of the countermeasure execution and collect, preserve

and archive forensic evidence that may be required to reject legal

claims. [OUTCOME 4, 5]

Output work products 1. Countermeasure documentation and status: Contains the docu-

mentation of all identified countermeasure including their ra-

tionale and their status with respect to decision and execution.

→ [OUTCOME 1, 2, 3]

2. External incident notifications: Is a document that is appropri-

ate to distribute information about the security incident and its

importance to external stakeholders.

Note: Depending on the target group, such a document may

vary widely in its information content and its confidentiality. →

[OUTCOME 1]

3. Incident management report: Is a report that summarizes the

status and results of the incident resolution so that the man-

agement is informed. → [OUTCOME 4]

4. Forensic evidence records: A data record that stores references

to forensic artifacts and forensic artifacts like software images,

memory dumps, log data etc.

Note: Storage of forensic data must adhere specific requirements

with respect to confidentiality, integrity and long-term preserva-

tion. → [OUTCOME 5]


Aus Sicherheitsvorfall lernen und Prozess und Produkt optimieren (Learn & Optimize)

Nach erfolgreichem Abschluss der Maßnahmen zur Behebung des Sicherheitsvorfalls schließt das

gesamte erweiterte SIR-Team den SIR-Prozess mit einem gemeinsamen Lessons-Learned-Mee-

ting ab. Die Erkenntnisse hieraus sollen einer Verbesserung des SIR-Prozesses dienen sowie lang-

fristige Maßnahmen zur Verbesserung der Produktsicherheit bzw. des Datenschutzes anstoßen.

Die folgende Tabelle beschreibt Details und organisatorische Voraussetzungen des Teilprozesses

„Aus Sicherheitsvorfall lernen und Prozesse und Produkte optimieren (Learn & Optimize).

Learn & Optimize

Process purpose Learn & Optimize aims to identify process and product improvements

in the aftermath of the incident handling process. It aims for

completing and closing the incident handling process with respect to

an incident or several incidents by reviewing what initially occurred,

what was done during detection and response, and how well the

overall intervention worked. Learn & Optimize should be carried out

after a major incident and periodically to cover lesser incidents.


1. Process and policy improvements related to the organizations

security policies and the incident response process or relevant

partner processes are identified and elaborated. Measures are

specified and agreed

2. Product improvements to the affected products or systems are

identified and elaborated

3. Threat and vulnerability information are adapted according to new

knowledge obtained by the incident handling process


Base practices SIR.4.BP1 Incident response evaluation: Evaluate incidents and the

incident handling process with respect to policy and process

changes [OUTCOME 1].

During this process, the following questions might occur:

• Did all processes and procedures work as expected? Were they

adequate? What can be improved?

• Are the security policies adequate or do they need to be updated?

• Are all required stakeholders involved?

• Which measures can be done to ensure that the incident will not

happen again?

• Which events should be observed in the future to detect similar

incidents?

• What kind of information was needed? What information was not

available or available to late? What can be improved?

SIR.4.BP2 Identify process improvements: Identify the concrete

measures and procedures that require improvements to achieve a

more efficient and timely incident response process. [OUTCOME 1]

SIR.4.BP3 Training requirements identification: Identify gaps in

qualification or knowledge of personnel that could be resolved by

training and education. [OUTCOME 1]

SIR.4.BP4 Product improvements identification: Identify the

concrete improvements that help to make the affected systems more

resilient against future incidents of the same or similar kind.

[OUTCOME 2]

SIR.4.BP5 Trends and pattern identification: Identify trends and

pattern with respect to threats and vulnerabilities and means to

handle this new pattern. [OUTCOME 3]


Output work products 1. Security policy: A security policy is a definition of rules and reg-

ulations that allows the secure operation of systems products

and processes. → [OUTCOME 1]

2. Process improvement report: A process improvement report in-

cludes a summary of findings where the process has not per-

formed as expected, suggestions for improvements addressing

the issues identified by the team to move towards a better pro-

cess, and the action items that are chosen to eliminate the find-

ings. → [OUTCOME 1]

3. Product improvement report: A product improvement report in-

cludes a summary of flaws, weaknesses, vulnerabilities and

other security relevant findings in the organizations' products,

suggestions for product improvements, and the concrete action

items that are chosen to eliminate the findings. → [OUT-

COME 2]

4. Security bulletin (i.e. updated vulnerability and threat infor-

mation): Security bulletins include information for users, devel-

opers, partners to support and improve a secure operation of

the organization’s products. → [OUTCOME 3]

Car-Security-Incident-Response-Prozess

Der Car-SIR-Prozess basiert auf den SIR-Prozess; alle oben beschriebenen Schritte des SIR-Pro-

zesses gelten auch hier uneingeschränkt. Der Car-SIR-Prozess ist jedoch eine Konkretisierung

des SIR-Prozesses hinsichtlich der Sicherheitsvorfälle, die sich auf Fahrzeuge beziehen, und der

Organisationsstruktur, wie sie in der Automobilindustrie etabliert ist. Daher wird zunächst eine

Definition für Car-Security-Vorfälle vorgeschlagen und erläutert, wie Car-Security-Vorfälle dem-

nach sich von anderen Sicherheitsvorfällen unterscheiden. Anschließend werden die einzelnen

Prozessschritte „Erkennen und Erfassen“, „Bewerten und Kategorisieren“, „Entscheiden und Re-

agieren“ und „Lernen und Optimieren“ für Car-Security-Vorfälle und für die bestehenden Struk-

turen der Automobilindustrie konkretisiert.


Car-Security-Vorfälle

Die Definition eines Car-Security-Vorfalls und damit die Abgrenzung zu betrieblichen Sicher-

heitsvorfällen wirkt sich auf die organisatorische Aufteilung zwischen Car-Security und betrieb-

licher IT-Security aus. Daher obliegt es jedem Unternehmen selbst, für sich eine Definition für

Car-Security-Vorfälle zu finden, die den organisatorischen Rahmenbedingungen angemessen ist.

Statt des Begriffs „Car-Security“ kann es sinnvoll sein, allgemein von „Produkt-Security“ zu spre-

chen, insbesondere für Lieferanten, deren Produkte nicht nur in der Automobilindustrie Verwen-

dung finden.

Hier und im Folgenden wird folgende Definition verwendet:

Ein Car-Security-Vorfall ist ein Sicherheitsvorfall bezogen auf ein oder mehrere IT-Systeme, Ser-

vices oder Netzwerke, die sich im Fahrzeug befinden oder mit einem Fahrzeug verbunden sind.

Diese Definition schließt Sicherheitsvorfälle von IT-Systemen, Services oder Netzwerken ein, die

außerhalb des Fahrzeugs betrieben werden und mit Fahrzeugen verbunden sind, wie beispiels-

weise Car2Enterprise-Backendsysteme oder Car2Infrastucture-Services.

Somit sind beispielsweise folgende Sicherheitsvorfälle Car-Security-Vorfälle:

• Über das Infotainment-System eines Fahrzeugs werden Kundendaten auf einem Ba-

ckendsystem des OEMs gehackt.

• Die Plattform, über die Softwareupdates per OTA (Over-the-Air) eingespielt werden,

wird gehackt und so das Einspielen von Schadsoftware ins Fahrzeug ermöglicht.

• Das Produktionssystem wird gehackt, sodass manipulierte Software auf Steuergeräte ein-

gespielt wird.

Hingegen sind folgende Sicherheitsvorfälle keine Car-Security-Vorfälle:

• Der Server, mit denen sich Apps im Fahrzeug verbinden, wird gehackt, sodass die Apps

im Fahrzeug nicht genutzt werden können.

• Das Produktionssystem wird gehackt und die Produktion mechanischer, Safety-relevanter

Bauteile manipuliert.

• Eine Webplattform eines OEMs wird gehackt, sodass Kundendaten unerlaubt abgerufen

werden können.

• Der Laptop eines Mitarbeiters aus der Technischen Entwicklung wird gehackt und, sodass

die Angreifer Zugang zu Unterlagen über die Architektur von Softwarekomponenten ha-

ben und Schwachstellen identifizieren können.

Viele Automotive-Unternehmen unterscheiden zwischen Technischer Entwicklung (TE), zustän-

dig für die Produktentwicklung, und Informationstechnologie (IT), zuständig für die unterstüt-


zenden IT-Systeme außerhalb der Fahrzeuge. Somit betrifft das Thema Car-Security und die Be-

arbeitung von Car-Security-Vorfällen dort beide Bereiche. Es besteht die besondere Herausforde-

rung, beide Bereiche in den SIR-Prozess einzubinden; nur so kann die notwendige funktional-

systemische Sicht bei der Bewertung von Car-Security-Vorfällen und das Reagieren darauf ge-

währleistet werden.3

Erkennen & Erfassen

Zum Erkennen und Erfassen von Car-Security-Vorfällen wird das im IT-Service-Management

etablierte mehrstufige Supportsystem für den Car-SIR-Prozess verwendet. Dieses Supportsystem

besteht in der Regel aus zwei oder drei Stufen. Das Car-SIR-Team ist die höchste Support-Stufe

für Car-Security-Vorfälle und entscheidet final, ob das gemeldete Ereignis oder der gemeldete

Vorfall ein Car-Security-Vorfall ist, der in dem Car-SIR-Prozess weiter behandelt werden soll.

3 Alternativ zu der hier verwendeten Definition könnten als Car-Security-Vorfälle nur die

Sicherheitsvorfälle betrachtet werden, die durch Sicherheitslücken von IT-Komponenten im Fahrzeug

hervorgerufen werden. Dies entspräche der typischen Aufteilung zwischen TE und IT und würde gerade

die Koordination der technischen Gegenmaßnahmen vereinfachen. Erschwert wäre dadurch die

frühzeitige Zuordnung eines Sicherheitsvorfalls während der Erfassung. Zudem müsste das betriebliche

SIR-Team Prozesse zur Umsetzung von organisatorisch-rechtlichen Maßnahmen ähnlich denen des Car-

SIR-Teams betreiben.

Abbildung 3: Beispiel für eine Support-Organisation und einen Informationsfluss bei der Erkennung und Erfassung von Car-Security-Incidents durch einen OEM (kursiv: externe Melder)


Bei einem dreistufigen Supportsystem kann ggf. ein bereits bestehender 2nd-Level-Support ge-

nutzt werden, wenn dieser auch in der Lage ist, Car-Security-Vorfälle zu erkennen und in einer

ersten Einschätzung zu bewerten.

Für einen OEM ist in Abbildung 3 eine mögliche Support-Organisation mit ihrem Informations-

fluss und den verschiedenen Meldern von Vorfällen und Ereignissen dargestellt.

Der Car-SIR-Prozess nutzt sowohl bestehende, Bauteil-orientierte Servicestrukturen zur Erken-

nung und Erfassung von Car-Security-Vorfällen als auch spezielle Strukturen, die für digitale Pro-

dukte und andere fahrzeugunabhängige Sicherheitsvorfälle geschaffen wurden.

Im Folgenden wird die Meldung von Car-Security-Vorfällen in einer möglichen Servicestruktur

eines OEMs betrachtet.

Meldungen über den 1st-Level-Support

Beanstandungen über Vertragshändler: Klassischerweise geht ein Kunde bei einer Beanstandung

zu einem Vertragshändler des OEMs, der so die Rolle des 1st-Level-Supports übernimmt. Das

schadhafte Bauteil kann so über den Schadensfallbearbeitungsprozess zum entsprechenden Kom-

ponentenverantwortlichen4 gelangen. In diesem Fall spielt der Komponentenverantwortliche eine

wichtige Rolle bei der Erkennung von Car-Security-Vorfällen. Sollte der Komponentenverant-

wortliche einen Verdacht auf einen Car-Security-Vorfall haben, so wendet er sich an den 2nd-Le-

vel-Support. Dies bedeutet, dass das Management-System zur Schadensfallbearbeitung um Car-

Security-Vorfälle erweitert werden oder die gesammelten Daten an das Management-System für

Car-Security-Vorfälle leiten muss.

Service-Hotline: Falls ein Kunde oder ein Händler bereits von einem Car-Security-Vorfall ausgeht

oder zumindest Hinweise dazu hat, kann er sich an einen Helpdesk als 1st-Level-Support wenden.

Hierzu sollten Kommunikationsmedien wie Chat, Hotline oder E-Mail in Betracht gezogen wer-

den. Der Helpdesk ist öffentlich erreichbar und kann auch von anderen Stellen, die auf Car-

Security-Vorfälle oder Sicherheitslücken aufmerksam machen wollen, wie z. . Hacker, genutzt

werden.

Meldungen über den 2nd-Level-Support bzw. direkt an das Car-SIR-Team

Feldbeobachtung: Ähnlich klassisch ist der Einstieg über die Feldbeobachtung (typischerweise

durch den Vertrieb). Stellt die Feldbeobachtung Schadensfallhäufungen fest, so kann es den Feh-

lerabstellprozess anstoßen und zur Lösung an den Komponentenverantwortlichen weiterleiten.

Auch hier ist es Aufgabe des Komponentenverantwortlichen, Hinweise auf Car-Security-Vorfälle

4 Unter Komponentenverantwortlichen soll hier ein Mitarbeiter verstanden werden, der für die Qualität

einer Komponente verantwortlich ist. Andere Bezeichnungen dieser Rolle sind beispielsweise auch

Bauteilverantwortlicher (BTV) oder Engineer-Product-Quality (EPQ).


zu erkennen und dem 2nd-Level-Support zu melden. In diesem Fall muss das Management-System

für den Fehlerabstellprozess den Car-SIR-Prozess unterstützen oder mit ihm gekoppelt werden.

Der 2nd-Level-Support steht zudem anderen internen Stellen und auch externen Stellen, mit denen

Zusammenarbeiten bei der Entwicklung und dem Betrieb von IT-Systemen bestehen, offen. In-

terne Stellen sind u. a. Feldbeobachter, die selbst Hinweise auf einen Car-Security-Vorfall ent-

deckt haben, und der IT-Betrieb. Externe Stellen können Importeure, Wettbewerber, Zulieferer

und Provider von digitalen Services, die im Fahrzeuge genutzt werden, sein.

Direkter Kanal zum Car-SIR-Team

Neben dem 2nd-Level-Support (bei einem dreistufigen Supportsystem) können weitere interne

Stellen Car-Security-Vorfälle dem Car-SIR-Team direkt melden. Dies können PR-Abteilungen

sein, die von der Presse oder anderen Medien auf Car-Security-Vorfälle oder Car-Security-Bedro-

hungen hingewiesen worden sind, das Rechtswesen, das von Regulierungsbehörden von Car-

Security-Vorfällen oder Car-Security-Bedrohungen erfahren hat und um Stellungnahme gebeten

worden ist, oder der Betreiber einer Bug-Bounty-Plattform (sofern vorhanden), über den Hacker

Sicherheitslücken melden können.

Darüber hinaus sucht das Car-SIR-Team aktiv nach Informationen zu möglichen Sicherheitsbe-

drohungen und Sicherheitslücken, die es in den Prozess einsteuern kann. Beispiele hierfür sind

die aktive Auswertung von Log- und Monitoring-Daten aus Fahrzeugen und Intrusion-Detection-

Systemen, die Teilnahme an Konferenzen zum Thema Car-Security oder auch die eigenständige

Suche nach Angriffswerkzeugen im Darknet.

Bewerten & Klassifizieren / Entscheiden & Reagieren

Wie beim allgemeinen SIR-Prozess auch bewertet und klassifiziert das Car-SIR-Team einen Car-

Security-Vorfall, beschließt Maßnahme und reagiert auf den Car-Security-Vorfall sowohl tech-

nisch als auch organisatorisch-rechtlich. Und auch hier können und sollen weitere Experten und

Entscheidungsträger je nach Car-Security-Vorfall eingebunden werden. Folgende Personen könn-

ten z. B. bei einem OEM im erweiterten Car-SIR-Team teilnehmen:


Technisch Organisatorisch-rechtlich

Systemarchitekt Mitglied Ausschuss für Produktsicherheit

Komponentenverantwortlicher Datenschutzbeauftragter

IT-Projektleiter / Product-Owner Mitarbeiter Rechtswesen

Applikationsbetreiber Mitarbeiter HR

Mitarbeiter PR

Welche dieser Personen zum Car-SIR-Team gehören und welche nur bei Bedarf zum Bearbeitung

eines konkreten Car-Security-Vorfalls dazukommen, kann in den Unternehmen unterschiedlich

entschieden werden.

An der Bewertung von Car-Security-Vorfällen, gerade aber auch an der Behebung von Sicher-

heitslücken sind die Entwicklungsteams der involvierten IT-Komponenten mit eingebunden. Im

Gegensatz zu mechanischen Bauteilen können sich diese IT-Komponenten auch außerhalb des

Fahrzeugs befinden, beispielsweise Backend-Systeme, mit denen die Fahrzeuge kommunizieren.

Daher sollte je nach Car-Security-Vorfall Entwicklungsteams der Technischen Entwicklung

und/oder Entwicklungsteams der IT in den Car-SIR-Prozess eingebunden werden.

Eine besondere Herausforderung besteht darin, die Analyse und das Einleitung von Gegenmaß-

nahmen zu einem Car-Security-Vorfall auch über die Lieferantenkette effektiv zu realisieren. Die

sich daraus ergebenen Anforderungen werden gesondert im Abschnitt „Einbindung der Lieferan-

ten“ dargestellt.

Lernen & Optimieren

Die Lessons-Learned sollten gemeinsam im erweiterten Car-SIR-Team erarbeitet werden. Als Er-

gebnis können sowohl organisatorische als auch produkttechnische Änderungen gefordert und

angestoßen werden. Die sich daraus ergebenden Folgeschritte sind nicht mehr Teil des Car-SIR-

Prozesses.

Technischen Maßnahmen zum Entfernen der Schadensursache, die während des Car-SIR-Prozes-

ses durchgeführt worden sind, betreffen in der Regel das Beheben von Softwarefehlern und Än-

dern von Konfigurationen. Anforderungen an das Produktdesign sind hingegen in der Regel das

Ergebnis eines Lessons-Learned und entsprechend in den (langfristigen) Fehlerabstellprozess ein-

zusteuern, sofern kein unmittelbares Sicherheitsrisiko mehr besteht.


Validierte Schwachstellen

Das Car-SIR-Team muss grundsätzlich über alle Car-Security-Vorfälle informiert sein. Nur so hat

das Car-SIR-Team einen Überblick über alle Car-Security-Vorfälle und kann diese fundiert be-

werten. Erst das Zusammenspiel mehrere Security-Schwachstellen und die Identifikation mehre-

rer Car-Security-Vorfälle können Muster erkennen lassen, die ein fundiertes Bewerten ermögli-

chen. Daher muss das Car-SIR-Team auch über kleine Car-Security-Vorfälle, die zumindest an-

scheinend keine großen Auswirkungen haben sollten, informiert sein.

Nichtsdestotrotz kann das Car-SIR-Team unkritische Schwachstellen akzeptieren und Gegenmaß-

nahmen festlegen, die eigenständig z. B. vom Händlern, 1st- oder 2nd-Level-Support durchgeführt

werden können. Beispielsweise könnte ein Fahrzeugbesitzer selbst Software eingespielt haben,

die ihm unautorisiert erweiterte Rechte z. B. für das Infotainment-System gibt (Jailbreak). Sollten

das Car-SIR-Team die sich daraus ergebenden Sicherheitsrisiken validieren, als unkritisch einstu-

fen und Handlungsanweisungen für Service und Support formulieren, so müssen nicht alle Folge-

Vorfälle dieser Art an das Car-SIR-Team gemeldet werden. Das Car-SIR-Team soll sich vielmehr

auf die neuen und kritischen Car-Security-Vorfälle konzentrieren können, anstatt sich mit bekann-

ten, validierten Vorfällen beschäftigen zu müssen.

Damit das Car-SIR-Team über alle relevanten Car-Security-Vorfälle informiert ist, gleichzeitig

sich aber auf die wesentlichen Vorfälle fokussieren kann, werden folgende Regeln vorgeschlagen:

• Alle Car-Security-Vorfälle werden grundsätzlich dem Car-SIR-Team gemeldet.

• Das Car-SIR-Team kann Schwachstellen, die es validiert hat und als unkritisch einstuft,

als validierte Schwachstellen festlegen.

• Das Car-SIR-Team beschreibt die Car-Security-Ereignisse und Handlungsempfehlungen

von Car-Security-Vorfällen basierend auf diesen validierten Schwachstellen in einer Car-

Security-Guideline und kommuniziert dies den Service- und Support-Stellen, die solche

Car-Security-Vorfälle entgegennehmen, dokumentieren und Maßnahmen zur Behebung

eigenständig durchführen können.

• Im Zweifelsfällen leiten die Service- und Support-Stellen einen Car-Security-Vorfall an

das Car-SIR-Team.

Einbindung der Lieferanten

Bei der oben beschriebenen Car-SIR-Prozessbeschreibung wurde davon ausgegangen, dass alle

Kompetenzen zum Feststellen eines Car-Security-Vorfalls und zur Behebung von Sicherheitslü-

cke innerhalb des Unternehmens selbst vorhanden sind. Tatsächlich dürften bei vielen Car-

Security-Vorfällen Sicherheitslücken von gekauften IT-Komponenten ausgenutzt worden sein.

Die Lieferanten dieser IT-Komponenten müssen bei dem Car-SIR-Prozess mit eingebunden wer-

den, da nur sie diese Sicherheitslücken analysieren und schließen können.


Im Gegensatz zu Schadensfällen bei mechanischen Bauteilen können bei Car-Security-Vorfällen

Sicherheitslücken in IT-Komponenten ausgenutzt worden sein, die weder vom OEM noch von

einem seiner Lieferanten oder Unterlieferanten zu verantworten sind. So können beispielsweise

Schwachstellen bei den IT-Systemen des Netzwerkbetreibers oder Sicherheitslücken von mobilen

Endgeräten, die mit dem Fahrzeug gekoppelt sind, zu Car-Security-Vorfällen führen. In Zukunft

dürfte sich die Angriffsfläche auf das Fahrzeug durch extern zu verantwortende IT-Systeme noch

weiter vergrößern: durch Car2Infrastructure, Car2Car, Car2Home und anderen Formen der Fahr-

zeugvernetzung. Die Betreiber dieser externen IT-Komponenten müssen ggf. in den Car-SIR-Pro-

zess ebenfalls mit eingebunden werden.

Dennoch soll hier weiterhin der Begriff Lieferant verwendet werden. Dieser beschränkt sich hier

aber nicht nur auf Lieferanten von Kaufteilen, die in Fahrzeugen oder IT-Systemen außerhalb des

Fahrzeugs als Teil der gesamten Kommunikationsinfrastruktur verbaut sind, sondern umfasst

auch die Betreiber von digitalen Dienstleistungen, bei denen Sicherheitslücken zu Car-Security-

Vorfällen führen können.

Lieferanten nehmen im Rahmen des Car-SIR im Wesentlichen die Rolle der Entwicklung ein.

D. h., Lieferanten analysieren in enger Abstimmung mit dem technischen Car-SIR-Team die fest-

gestellten Sicherheitslücken ihres Systems und beheben selbst diese Sicherheitslücken. Zudem

führt der Lieferant eine Risikobewertung bzgl. der festgestellten Sicherheitslücke durch und in-

formiert seine anderen, von der Sicherheitslücke ebenfalls betroffenen Kunden.

Ein Lieferant sollte ebenfalls ein SIR-Team haben, das als Ansprechpartner dem Car-SIR-Team

des OEM bekannt ist. Der Informationsaustausch zwischen dem technischen Car-SIR-Team des

OEM und dem SIR-Team des Lieferanten zur Behebung einer Sicherheitslücke ist in der folgen-

den Tabelle dargestellt:


Nr. Nachricht Inhalt Sender / Empfänger

1 Meldung des Car-

Security-Vorfalls

• Beschreibung des Car-Security-Vorfalls

• Beschreibung der vermuteten Sicher-heitslücke

Kunde an Lieferant

2 Eingangsbestätigung • Verantwortlicher Ansprechpartner

• Ggf. Informationen über bereits verfüg-bare Maßnahmen

Lieferant an Kunde

3 Akzeptanzkriterien • Akzeptanzkriterien zur Abnahme (ggf. schon mit Meldung 1)

Kunde an Lieferant

4 Analyseergebnis • Bestätigung der Sicherheitslücke, andern-falls begründete Ablehnung

• Analysebericht

• Ggf. Informationen über Weiterleitung an Unterlieferanten

Lieferant an Kunde

5 Maßnahmen • Beschreibung der durchgeführten Maß-nahmen

• Ggf. Information über Bezug von Updates inkl. Systemdokumentation

Lieferant an Kunde

6a Akzeptanzbestäti-

gung

• Bestätigung, falls Akzeptanzkriterien er-füllt sind

Kunde an Lieferant

6b Ablehnung • Ablehnungsgründe, falls Akzeptanzkrite-rien nicht erfüllt sind

Kunde an Lieferant

Der Aufbau der Kommunikation orientiert sich dabei an den in der Automobil-Industrie etablier-

ten 8D-Report. Im Gegensatz zum 8D-Report gibt es jedoch zwei wesentliche Unterschiede:

1. Der 8D-Report bezieht sich auf beanstandete Bauteile. Bei Car-SIR-Vorfällen ist meist

nicht ein Bauteil, sondern vielmehr eine Software, ein digitaler Service oder ein Netzwerk

betroffen. Das Austauschformal für Car-SIR-Vorfälle muss dies berücksichtigen.

2. Der 8D-Report unterstützt keine spezifische Beschreibung von Akzeptanzkriterien für die

Wirksamkeitsprüfung der durchgeführten Maßnahmen. Solche Akzeptanzkriterien soll-

ten für Car-SIR-Vorfälle mit übermittelt werden können, um die Anforderungen detail-

lierter spezifizieren zu können und eine Übernahme ist Testwerkzeuge zu erleichtern.


Aufgaben des Qualitätsmanagements

Die grundlegende Aufgabe des Qualitätsmanagements umfasst das Definieren von Qualitätsan-

forderungen bezüglich Prozesse und Produkte, die Unterstützung bei der Umsetzung qualitätssi-

chernder Maßnahmen und die Verifizierung und Validierung der realisierten Prozesse und Pro-

dukte hinsichtlich der gestellten Qualitätsanforderungen. Zudem verantwortet das Qualitätsma-

nagement in der Automobilindustrie typischerweise die Kommunikation mit den Lieferanten bei

Prozess- und Produktbeanstandungen.

Bei dem Car-SIR-Prozess sollte daher das Qualitätsmanagement zum einen auf Prozessebene Car-

SIR als Managementsystem mit verantworten und ggf. die Leitung des Car-SIR-Teams überneh-

men; zum anderen sollten die Mitarbeiter, die für die Qualität von IT-Komponenten verantwort-

lich sind (z. B. Komponentenverantwortliche) auf Produktebene bei der Behebung eines Car-

Security-Vorfalls eingebunden sein. Diese Mitarbeiter beteiligen sich an der technischen Bewer-

tung, liefern Informationen für eine organisatorisch-rechtlich Bewertung, legen den Maßnahmen-

plan mit fest, unterstützen dessen Umsetzung und prüfen die Wirksamkeit.

Für diese beiden Rollen ergeben sich somit folgende Aufgaben:

Car-SIR-Management (z. B. als Leiter des Car-SIR-Teams):

• Car-Security-Ziele definieren

• Car-SIR-Prozesse und Verantwortlichkeiten definieren

• Risikobewertungsverfahren festlegen

• Prozesseffizienz validieren und Lessons-Learned erheben

Car-SIR-Mitarbeit (z. B. als Komponentenverantwortlicher):

• Car-Security-Anforderungen bezogen auf IT-Komponente definieren

• Car-Security-Vorfälle im Feld oder Hinweise darauf (mit) erkennen und (mit) erfassen

• Risiken bewerten

• Car-Security-Vorfall-Analyse unterstützen

• Mit Lieferanten kommunizieren

• Maßnahmen mit erarbeiten

• Umsetzung verifizieren

• Wirksamkeit validieren


TEIL 2: HANDLUNGSEMPFEHLUNGEN

Basierend auf den im ersten Teil beschriebenen Grundlagen sind hier im zweiten Teil konkrete

Handlungen zur Vorbereitung und zur Optimierung eines Car-Security-Incident-Response emp-

fohlen. Diese Handlungsempfehlungen richten sich an Führungskräfte und Mitarbeiter von Un-

ternehmen der Automobilindustrie, die an dem Car-SIR-Prozess direkt oder indirekt beteiligt sein

können oder diesen vorbereiten.

Handlungsempfehlungen an das Topmanagement

Das Topmanagement sollte grundsätzlich die Aufgabe übernehmen, einen Car-SIR-Prozess, so-

fern noch nicht vorhanden, aufzubauen, dessen Effektivität zu prüfen, Mitarbeiter für das Thema

Car-Security und damit auch Car-SIR zu sensibilisieren und Schulungsmaßnahmen bei Bedarf zu

unterstützen sowie im Falle einer Eskalation als Entscheidungsträger bereitzustehen. Das Topma-

nagement sollte hingegen die konkrete Ausgestaltung des Car-SIR-Prozesses an das Car-SIR-

Team delegieren und diesem dafür die Verantwortung übertragen.

Grundlegende Sicherheitsrichtlinien und Car-Security-Vorfall definieren

Das Topmanagement soll die grundlegenden Sicherheitsrichtlinien festlegen und definieren las-

sen, was unter einem Car-Security-Vorfall im Unternehmen zu verstehen ist. Die grundlegenden

Sicherheitsrichtlinien sollten den sicheren und regelkonformen Normalzustand bei der Nutzung

von Fahrzeug-IT beschreiben, sodass ein Car-Security-Vorfall als Verletzung bzw. Abweichung

von diesem definierten Normalzustand erkannt werden kann. Auf Basis dieser Richtlinien kann

ein Car-Security-Vorfall von anderen Vorfällen und Ereignisse abgegrenzt werden. Bei der Defi-

nition soll berücksichtigt werden, dass bestehende Organisationseinheiten bereits Vorfälle bear-

beiten. Hier ist zu prüfen, ob diese bestehenden Organisationseinheiten in den Car-Security-Pro-

zess mit eingebunden werden und getrennt vom Car-SIR-Prozess arbeiten sollen.


Aufgaben:

□ Grundsätzliche Sicherheitsrichtlinien festlegen

□ Car-Security-Vorfälle in Abgrenzung zu sonstigen, nicht Fahrzeug-relevanten Sicher-

heitsvorfällen und zu sonstigen, nicht sicherheitsrelevanten Vorfällen definieren

□ Festlegungen kommunizieren

Grundlegenden Car-SIR-Prozess festlegen und Car-SIR-Team aufbauen

Das Topmanagement soll die grundlegenden Car-SIR-Prozess beschreiben, ein Car-SIR-Team be-

nennen und diesen mit dem Aufbau und der detaillierten Festlegung des Prozesses beauftragen.

Das Topmanagement soll dem Car-SIR-Team mit den erforderlichen fachlichen Kompetenzen

bzw. organisatorische Befugnisse ausstatten, damit dieses Car-Security-Vorfälle technisch und or-

ganisatorisch-rechtlich fundiert bewerten und je nach Kritikalität und Dringlichkeit entsprechend

der Sicherheitsrichtlinien Gegenmaßnahmen zur Behebung von Car-Security-Vorfällen eigenver-

antwortlich einleiten kann.

Aufgaben:

□ Grundlegenden Car-SIR-Prozess definieren und kommunizieren

□ Car-SIR-Team aufbauen und die dazu erforderlichen Ressourcen bereitstellen

□ Entscheidungskompetenzen des Car-SIR-Teams festlegen und kommunizieren

□ Richtlinien für das Berichten des Car-SIR-Teams an das Topmanagement festlegen

□ Eskalationsprozess definieren und kommunizieren

Support-Organisation aufbauen bzw. erweitern

Das Topmanagement soll eine für Car-Security-Vorfälle geeignete Support-Struktur aufbauen

bzw. die bestehende Support-Struktur für Car-Security-Vorfälle anpassen und erweitern. Zum

Support könnten gehören:

• ein 1st-Level-Support in Form eines öffentlich zugänglichen Helpdesks, der beispiels-

weise über Hotline, Chat und/oder E-Mail erreichbar ist, und der allen externen und in-

ternen Stellen bekannt ist,

• ein 2nd-Level-Support, der z. B. allen Komponentenverantwortlichen, Feld-Schadensfall-

Analysten, Importeuren, Zulieferern, Service Providern, Wettbewerbern, dem IT-Betrieb

und 1st-Level-Support bekannt und zugänglich ist,


• ein 3rd-Level-Support, der dem 2nd-Level-Support, dem Bug-Bounty-Betreiber (sofern

vorhanden), der PR-Abteilung und dem Rechtswesen bekannt und zugänglich ist.

Alle Support-Levels sollen an 365 Tagen im Jahr 24 Stunden erreichbar sein. Die Support-Mitar-

beiter sollen die erforderliche Qualifikation zur Erkennung und Erfassung von Car-Security-Vor-

fällen und zur Durchführung definierter Gegenmaßnahmen haben.

Aufgaben:

□ Support-Strukturen festlegen

□ Ressourcen für Support-Struktur bereitstellen und Mitarbeiter qualifizieren

□ Technische Voraussetzungen für die Erreichbarkeit des Supports sicherstellen

Car-SIR-Kommunikation zu externen Stakeholdern vorbereiten

Das Topmanagement soll Richtlinien zur Kommunikation mit externen Stakeholdern bei Car-

Security-Vorfällen definieren. Zu den externen Stakeholdern gehören Kunden, Regulierungsbe-

hörden und die Presse. Es soll klären, was zu welchem Zeitpunkt durch wen zu kommunizieren

ist, sodass alle notwendigen Informationspflichten erfüllt, die notwendige Vertraulichkeit gewahrt

und ein effizientes Handeln sichergestellt ist.

Aufgaben:

□ Kommunikationskanäle identifizieren und dokumentieren

□ Ereignisse, die eine externe Kommunikation auslösen, definieren

□ Zuständigkeiten für externe Kommunikation klären

SIR-Fähigkeit in der Lieferantenkette einfordern

Das Topmanagement soll bei den Lieferanten von IT-Komponenten die Bereitstellung eines SIR-

Teams und eines SIR-Prozesses auf Seiten der Lieferanten fordern. Diese SIR-Fähigkeit schließt

auch ein, dass der Lieferant dies auch von seinen IT-Komponenten-Lieferanten fordert, sodass die

SIR-Fähigkeit für die Lieferantenkette durchgängig gewährt ist.

Aufgaben:

□ Richtlinien für die Beauftragung von IT-Komponenten-Lieferanten hinsichtlich des SIR-

Prozesses erstellen

□ Richtlinien der Beschaffung kommunizieren


□ Verträge mit den IT-Komponenten entsprechend der Richtlinien verhandeln und ggf. an-

passen

Car-SIR-Prozess testen (optional)

Das Topmanagement soll den Car-SIR-Prozess testen lassen. Hierzu sollen kritische Vorfälle

identifiziert und als Testszenario beschrieben werden. Bei der Durchführung eines Tests sollen

möglichst wenige Personen eingeweiht werden und es muss sichergestellt sein, dass ein echter

Schaden ausgeschlossen ist. Hierzu sind ggf. externe Experten zu beauftragen.

Aufgaben:

□ Kritische Vorfälle identifizieren und Testszenario festlegen

□ Test so vorbereiten, dass tatsächlicher Schaden ausgeschlossen ist

□ Test durchführen lassen

□ Stärken und Schwächen des Car-SIR-Prozess identifizieren und Defizite beheben

Mitarbeiter sensibilisieren und schulen

Das Topmanagement soll die Mitarbeiter im Unternehmen über die Risiken von Sicherheitsbe-

drohungen unterrichten und notwendige Schulungsangebote bereitstellen und deren Nutzung un-

terstützen. Dabei soll die Bedeutung von Car-Security für das Unternehmen verdeutlicht und die

Mitarbeiter zu dem Thema sensibilisiert werden. Dies gilt insbesondere für Mitarbeiter, die bei

dem Feststellen von Car-Security-Vorfällen als auch bei der Behebung von Sicherheitslücken be-

teiligt sein könnten.

Aufgaben:

□ Bedeutung von Car-Security für das Unternehmen den Mitarbeitern verdeutlichen

□ Schulungsangebote zum Thema Sicherheit im Allgemeinen und Car-Security im Speziel-

len anbieten


Handlungsempfehlungen an das Car-SIR-Team

Das Car-SIR-Team sollte den Car-SIR-Prozess verantworten. Es sollte daher alle notwendigen

vorbereitenden Aktivitäten hierzu mit Unterstützung den Topmanagements durchführen und ein-

fordern. Zudem sollte es sich kontinuierlich über aktuelle Themen, die Car-Security betreffen,

informieren und die Car-Security im Unternehmen diesbezüglich prüfen und anpassen.

Sicherheitsrichtlinien konkretisieren

Das Car-SIR-Team soll die grundlegenden, vom Topmanagement verabschiedeten Sicherheits-

richtlinien konkretisieren und kommunizieren. Die konkretisierten Sicherheitsrichtlinien sollen

die Verhaltensrichtlinien bei Car-Security-Vorfällen für die unterschiedlichen Personengruppen

bzw. Organisationseinheiten enthalten.

Insbesondere sollen die Support-Mitarbeiter sowie die Komponentenverantwortlichen von IT-

Komponenten folgende Informationen kennen, sodass sie Car-Security-Ereignisse frühzeitig er-

kennen, initial beurteilen und bei der weiteren Bearbeitung von Car-Security-Vorfällen effektiv

unterstützen können:

• sicherer Normalzustand bei der Nutzung der Fahrzeug-IT

• mögliche Car-Security-Ereignisse

• grundlegende Absicherungsmaßnahmen im Fall eines Car-Security-Vorfalls

• validierte Schwachstellen, deren Erkennung und Gegenmaßnahmen

Aufgaben:

□ Sicherheitsrichtlinien für Car-Security-Vorfälle konkretisieren und Verhaltensrichtlinien

je Personengruppe/Organisationseinheit definieren

□ Car-Security-Ereignisse dokumentieren und klassifizieren

□ Validierte Schwachstellen (Erkennung und Gegenmaßnahmen) dokumentieren

□ Sicherheitsrichtlinien für Car-Security-Vorfälle kommunizieren

Sich mit relevanten Experten und Entscheidungsträgern im Unternehmen vernetzen

Das Car-SIR-Team soll die Experten und Entscheidungsträger im Unternehmen kennen und je-

derzeit einbinden können, die für die Bewertung von Car-Security-Vorfällen, zum Eindämmen

der Schäden, zum Entfernen der Schadensursachen und/oder zur Wiederherstellung des Systems

benötigt werden. Dies können Mitarbeiter u. a. folgender Geschäftsbereiche sein:


• Datenschutz bzw. Rechtsabteilung

• Produktsicherheit

• Komponentenverantwortliche

• Personalabteilung

• Kommunikation / PR

• Technische Entwicklung und Softwareentwicklung

• IT-Betrieb

Aufgaben:

□ Alle für den Car-SIR-Prozess relevanten Experten und Entscheidungsträger identifizieren

□ Kommunikationsstruktur mit Experten und Entscheidungsträgern abstimmen und festle-

gen

□ Verfügbarkeit der Experten und Entscheidungsträger bei Notfällen zusichern lassen

□ Sicherheitsrichtlinien kommunizieren

Zugang zu kompromittierten Systemen sicherstellen

Das Car-SIR-Team soll im Vorfeld sicherstellen, dass es Zugang zu den kompromittierten Syste-

men erhält. Dazu sind organisatorische und technische Rahmenbedingungen zu schaffen.

Aufgaben:

□ Rechtliche, organisatorische und logistische Möglichkeiten für den Zugang zu kompro-

mittierten Fahrzeugen und Fahrzeugkomponenten prüfen und vorbereiten

□ Zugriffsrechte auf IT-Systeme für Mitglieder des Car-SIR-Teams einrichten bzw. eine

Einrichtung im Notfall sicherstellen lassen

□ Zugangssoftware für relevante IT-Systeme einrichten lassen

□ Sich im Umgang mit den Systemen einweisen lassen

□ Zugang zu Log-Dateien und anderen relevanten Daten sicherstellen

Netzwerk zu externen Experten aufbauen und nutzen können

Das Car-SIR-Team soll externe Experten kennen und diese bei Bedarf konsultieren und in die

Car-Security-Vorfallsbearbeitung einbinden können.


Aufgaben:

□ Externe Experten identifizieren und Netzwerk aufbauen

□ Vertragliche Rahmenbedingungen klären und ggf. bereits Verträge mit externen Partnern

schließen

Effektive Kommunikation mit externen Stakeholdern sicherstellen

Das Car-SIR-Team soll eine funktionierende und effektive Kommunikation mit externen Stake-

holdern im Bedarfsfall sicherstellen. Zu den Stakeholdern können u. a. gehören:

• Lieferanten von IT-Komponenten

• Regulierungsbehörden

• Wettbewerber

• Kunden (bei Zulieferunternehmen)

Aufgaben:

□ Ansprechpartner bei den externen Stakeholdern kennen

□ Kommunikation (auslösende Ereignisse, Kanäle, Daten, Datenformate) mit den externen

Stakeholdern abstimmen bzw. Vorgaben umsetzen

□ Prozesse, Werkzeuge und Vorlage für die externe Kommunikation installieren bzw. er-

stellen und pflegen

Risikobewertung für Car-Security-Vorfälle vorbereiten

Das Car-SIR-Team soll in Abstimmung mit dem Topmanagement ein Risikobewertungsverfahren

für Car-Security-Vorfälle festlegen und Vorlagen mit Beispielen für die Risikobewertung erstel-

len.

Aufgaben:

□ Risikobewertungsverfahren definieren

□ Prozess für Risikobewertung definieren

□ Vorlagen mit Beispielen erstellen


Car-Security-Vorfälle dokumentieren und Beweise forensisch sichern können

Das Car-SIR-Team soll Systeme zur durchgängigen Dokumentation von Car-Security-Vorfällen

und zur forensischen Sicherung von Beweisen (Daten und Systeme) aufbauen, betreiben und den

fachgerechten Umgang damit sicherstellen. Es ist zu berücksichtigen, dass die erhobenen Daten

vertraulich zu behandeln und langfristig vorzuhalten und die Systeme dafür ausgelegt sind.

Aufgaben:

□ Anforderungen an Systeme zur Dokumentation von Car-Security-Vorfällen und zur Be-

weissicherung definieren

□ Systeme zur Beweissicherung und Dokumentation implementieren

□ Sich im Umgang mit den Systemen zur Beweissicherung und Dokumentation schulen

lassen

□ Vertraulichkeit der erfassten Daten organisatorisch und technisch sicherstellen

□ Nach Car-Security-Vorfällen suchen und Car-Security-Vorfallsberichte miteinander ver-

binden bzw. verlinken können

□ Bearbeitungsstatus von Car-Security-Vorfällen ermitteln können

□ Know-how zur forensischen Beweissicherung aufbauen und pflegen

Wirksamkeit von Gegenmaßnahmen prüfen können

Das Car-SIR-Team soll die Wirksamkeit von Gegenmaßnahmen prüfen können. Hierzu sind alle

dazu erforderlichen organisatorischen und technischen Maßnahmen vorzubereiten.

Aufgaben:

□ Zugang zu Informationen über Ereignisse im Feld sicherstellen

□ Informationen bewerten können

□ Schließen von Car-Security-Vorfällen nur durch Car-SIR-Team sicherstellen

Car-Security-Bedrohungen aus externen Quellen erfassen

Das Car-SIR-Team soll sich aktiv über neue Car-Security-Bedrohungen informieren und diese

bei Bedarf in den Car-SIR-Prozess einsteuern. Quellen können u. a. Security-Konferenzen oder

Publikationen zum Thema Security sein.


Aufgaben:

□ Quellen sichten und Informationen beziehen (z. B. Newsletter abonnieren, Konferenzen

besuchen, etc.)

□ Prozesse und Werkzeuge zur Informationsbeschaffung installieren

□ Externe Informationen über mögliche Car-Security-Bedrohungen bewerten und ggf. in

den Car-SIR-Prozess einsteuern

Penetrationstests durchführen (optional)

Das Car-SIR-Team soll nach eigenem Ermessen Penetrationstest durchführen lassen können, um

so bislang unbekannt Sicherheitslücken zu erkennen.

Aufgaben:

□ Experten für Penetrationstest kennen und bei Bedarf zeitnahe Beauftragung durchführen

können

□ Bei Bedarf Ergebnisse eines Penetrationstests als Car-Security-Vorfall in den Car-SIR-

Prozess einsteuern

Bug-Bounty aufbauen (optional)

Das Car-SIR-Team soll eine Bug-Bounty-Plattform aufbauen, über das Hacker rechtssicher Si-

cherheitslücken melden können.

Aufgaben:

□ Konzept (organisatorisch, rechtlich, finanziell, etc.) zum Aufbau einer Bug-Bounty-Platt-

form erstellen

□ Bug-Bounty-Plattform betreiben

Kritische Funktionen deaktivieren können

Das Car-SIR-Team soll die Möglichkeit schaffen, kritische Funktionen notfalls abschalten zu kön-

nen, sofern die rechtlichen Rahmenbedingungen dies erlauben.

Aufgaben:

□ Funktionen, die deaktivierbar sein sollen, identifizieren

□ Deaktivierungsmechanismus für jede dieser Funktionen beschreiben


□ Deaktivierungsmechanismen implementieren lassen und testen

Handlungsempfehlungen an Komponentenverantwortliche

Die Komponentenverantwortlichen werden in der Regel keine Experten für Car-Security sein.

Dennoch sollten sie bei der Bearbeitung von Car-Security-Vorfällen, falls diese die von ihnen

verantworteten Komponente betreffen, bei Bedarf mit eingebunden werden, da sie üblicherweise

die Kommunikation mit den Lieferanten ihrer Komponente verantworten. Zudem sollten sie in

der Lage sein, bei den ihnen gemeldeten Vorfällen Hinwiese auf Car-Security-Vorfälle zu erken-

nen und entsprechend weiterzuleiten.

Bedeutung der Komponente für Car-Security kennen

Der Komponentenverantwortliche soll die Sicherheitsarchitektur kennen und verstehen, welche

Bedeutung die von ihm verantwortete Komponente für die Architektur hat. Der Komponenten-

verantwortliche weiß und hat dokumentiert, welche Daten in der Komponente gespeichert werden

und welche Vertraulichkeitsstufen diese Daten haben.

Aufgaben:

□ Sicherheitsrichtlinien kennen

□ Bedeutung der Komponente für Car-Security kennen

□ In der Komponente gespeicherte Daten und deren Vertraulichkeitsstufe kennen

Fahrzeuge mit verbauter Komponente identifizieren können

Der Komponentenverantwortliche soll wissen, in welchen Fahrzeugen die von ihm verantwortete

Komponente verbaut ist, um diese Information zur Risikobewertung durch das Car-SIR-Team

bereitstellen zu können.

Aufgaben:

□ Auskunft über die Fahrzeuge mit der Komponente bei Bedarf zeitnah geben können


Handlungsempfehlungen an den IT-Betrieb

Der IT-Betrieb sollte grundsätzlich das Monitoring von IT-Systemen verantworten und damit auch

Car-Security-Ereignisse erkennen, erfassen, initial bewerten und weiterleiten können. Darüber

hinaus sollte der IT-Betrieb bei Bedarf bei den Gegenmaßnahmen eingebunden und eine effektive

Umsetzung unterstützen. Hierzu sollte der IT-Betrieb vorbereitende Aktivitäten durchführen.

Car-Security-Ereignisse loggen und monitoren

Der IT-Betrieb soll Car-Security-Ereignisse in den Fahrzeugen und auf den Servern erfassen, ini-

tial bewerten und bei Bedarf den Car-SIR-Prozess anstoßen können. Hierzu soll der Betrieb die

dafür notwendigen Schritte vorbereiten.

Aufgaben:

□ Anforderungen an das Loggen und Monitoren von Car-Security-Ereignissen definieren

und in die Realisierung einsteuern

□ Automatisierte Meldungen über Car-Security-Ereignisse an IT-Betrieb-Mitarbeiter si-

cherstellen

□ Know-how zur Bewertung von Car-Security-Ereignissen auf- bzw. ausbauen

Effizientes Deployment sicherstellen

Der IT-Betrieb soll ein effizientes Deployment von Gegenmaßnahmen bei Car-Security-Vorfällen

ermöglichen. Dazu sollen die technischen und organisatorischen Voraussetzungen geschaffen

werden.

Aufgabe:

□ Effiziente Verifizierung von Akzeptanzkriterien sicherstellen

□ Effiziente Bereitstellung von Sicherheits-Patches sicherstellen

□ Effiziente Installation von Sicherheits-Patches auf Server sicherstellen

□ Effiziente Verteilung von Sicherheits-Patches an Kunden und Händlern sicherstellen


TEIL 3: BEWERTUNG DER CAR-SIR-FÄHIGKEIT

Die Bewertung der Car-SIR-Fähigkeit eines Unternehmens der Automobilindustrie lässt sich über

eine klassische Prozessbewertung realisieren. In den Bereichen der Softwareentwicklung sind mit

dem Software Process Improvement and Capability Determination (SPICE 2012) und der Capa-

bility Maturity Model Integration (CMMI 2010) explizite Fähigkeitsbewertungen für Software-

entwicklungsprozesse entwickelt worden. Mit Automotive SPICE (A-SPICE 2015) existiert ein

solches Bewertungsschema, das explizit auf die Softwareentwicklung von Steuergeräten in der

Automobilindustrie zugeschnitten ist, sich etabliert hat und vom VDA gepflegt wird.

SPICE-Prozessbewertungen werden grundsätzlich entlang eines zweidimensionalen Modells be-

stehend aus seiner Prozessdimension und einer Reifegraddimension durchgeführt. Die Prozessdi-

mension wird durch ein Prozessreferenzmodell (Process Reference Model – PRM) charakterisiert

und dient der Beschreibung sowie der Festlegung der im Bewertungsprozess zu untersuchenden

Prozesse. Die Reifegraddimension wird durch ein Prozessbewertungsmodell (Process Assessment

Model – PAM) beschrieben, das aufbauend auf dem Referenzmodell Bewertungskriterien und

Methoden zur Bewertung der Prozessreife definiert.

Integration in das Automotive-SPICE-Bewertungsmodell

Der internationale SPICE-Standard definiert die grundlegenden Anforderungen an Prozessrefe-

renzmodelle sowie an Prozessbewertungsmodelle, nicht aber die Modelle selber. Die eigentlichen

Modelle werden dann domänenspezifisch beschrieben. In diesem Kontext stellt Automotive

SPICE eine domänenspezifische Ausrichtung des SPICE Standards dar und definiert als solches

ein eigenes Prozessreferenzmodell und ein eigenes Prozessbewertungsmodell für die Reifegrad-

bewertung von Softwareentwicklungsprozessen in der Automobilindustrie. Sowohl das PRM wie

auch das PAM aus Automotive SPICE sind konform zur ISO/IEC 15504-2 (SPICE).

Die von uns an dieser Stelle skizzierte Bewertung der Car-SIR-Fähigkeit einer Organisation ba-

siert auf der Bewertung der Prozessreife ihrer Incident-Response-Prozesse. Grundlage dafür ist


das in Teil 1 beschriebene Referenzmodell für den Security-Incident-Response-Prozess sowie das

Prozessbewertungsmodell aus dem Automotive-SPICE-Standard.

Abbildung 4: Zusammenspiel von PAM und PRM gemäß Automotive SPICE (siehe auch: A-SPICE 2015)

Abbildung 4 zeigt das grundsätzliche Zusammenspiel zwischen den einzelnen Elementen zur Pro-

zessbewertung sowie ihre Herkunft. Das Rahmenwerk zur Prozessvermessung (Measurement

Framework) stammt aus der ISO 33020 und definiert die Reifegradstufen und Bewertungsskalen.

Das Prozessreferenzmodell wurde im Rahmen dieses Projekts entwickelt und definiert den fach-

lichen Kontext, d. h. die Prozessbeschreibung inklusive der Definition der Grundpraktiken (Base

Practices – BP) und Ergebnisartefakte (Work Product – WP). Das Bewertungsmodell schlussend-

lich stammt aus dem Automotive-SPICE-Standard und beschreibt Indikatoren, die es erlauben,

die Prozesse bzw. Teilprozesse den einzelnen Reifegradstufen zuzuordnen.

Reifegrade in Automotive SPICE

Die Reifegraddimension in Automotive SPICE besteht aus den sechs Gradstufen (Capability Lev-

els) „CL0 – unvollständig“, „CL1 – durchgeführt“, „CL2 – gesteuert“, „CL3 – etabliert“, „CL –

vorhersagbar“ und „CL5 – optimierend“. Diese Stufen erlauben Aussagen über die Reife und

Leistungsfähigkeit der in der Prozessdimension beschriebenen Prozesse zu standardisieren. Im

Prüfprozess wird nicht nur die Existenz einer Prozessaktivität beurteilt, sondern auch deren adä-

quate Durchführung und Dokumentation sowie die grundsätzlichen Fähigkeiten eines Prozesses

zur Kontrolle, Innovation und Optimierung.


Prozessattribute und Prozessindikatoren in Automotive SPICE

Zur Vereinfachung der Bewertung sind den Reifegraden insgesamt neun Prozessattribute zuge-

ordnet (siehe die Bezeichnungen PA 1.1 bis PA 5.2 in Abbildung 4). Die Prozessattribute definie-

ren messbare Prozesseigenschaften wie z. B. den Grad der Selbstkontrolle, die Umsetzung eines

nachvollziehbaren Artefaktmanagements, den Grad der Vorhersagbarkeit, usw. Prozessattribute

werden jeweils durch ihre zugeordneten und überprüfbaren Prozessfähigkeitsindikatoren (Pro-

cess Capability Indicators) und Prozessleistungsindikatoren (Process Performance Indicators)

genauer beschrieben.

• Prozessfähigkeitsindikatoren werden durch sog. generischen Praktiken (Generic Prac-

tices – GPs) und generischen Ressourcen (Generic Resources – GRs) charakterisiert. Ge-

nerische Praktiken und generischen Ressourcen sind unabhängig vom jeweiligen Pro-

zessreferenzmodell definiert und anwendbar. Sie erlauben eine Bewertung der Prozes-

sattribute in den Reifegradstufen CL2-CL5.

• Prozessleistungsindikatoren bieten ein Maß dafür, ob ein Prozess seinen Prozesszweck

grundsätzlich erfüllt und die spezifizierten Prozessergebnisse erzielt werden. Prozessleis-

tungsindikatoren sind nicht generisch und werden für die Bewertung der Reifegradstufe

CL1 verwendet. In Automotive SPICE werden die Prozessleistungsindikatoren die im

Referenzmodell definierten Grundpraktiken und Ergebnisartefakte realisiert, indem diese

auf ihr Vorhandensein und ihre Qualität geprüft werden. Die Grundpraktiken repräsentie-

ren in diesem Zusammenhang aktivitätsorientierte Leistungsindikatoren, die einen Beleg

dafür liefern können, dass im Prozess die richtigen Aktivitäten durchgeführt werden. Die

Ergebnisartefakte hingegen repräsentieren ergebnisorientierte Leistungsindikatoren, die

ein Beleg dafür sind, dass die richtigen Ergebnisse erzielt und als Dokumentation für

Folgeprozesse zur Verfügung gestellt werden.

Die Bewertung eines Prozessattributs erfolgt anhand einer vierstufigen Skala mit den Werten

• „nicht erfüllt (not achieved)“: 0 % – 15 %

• „teilweise erfüllt (partially achieved)“: >15 % – 50 %

• „weitgehend erfüllt (largely achieved)“: >50 % – 85 %

• „vollständig erfüllt (fully achieved)“: >85 % – 100 %.

Eine genauere Definition der generischen Praktiken und der generischen Ressourcen findet sich

im Automotive-SPICE-Standard (A-SPICE 2015) im Kapitel 5 “Process capability levels and

process attributes”. Automotive SPICE definiert darüber hinaus verschiedene Vorgehensmodelle

zur Bewertung, Regeln zur Aggregation der Bewertungsergebnisse sowie Möglichkeiten die Ska-

lierung der Bewertungsskala zu verfeinern. Weitere Informationen dazu finden sich im Automo-

tive-SPICE-Standard.


Prozessindikatoren für die Bewertung der Car-SIR-Fähigkeit

Grundsätzlich liefert das in Teil 1 dieses Berichts definierte Prozessreferenzmodell bereits die

notwendigen Prozessleistungsindikatoren für die Evaluierung der Reifegradstufe CL1 eines

Security-Incident-Response-Prozesses und damit der grundsätzlichen Car-SIR-Fähigkeit einer

Organisation der Automobilindustrie. Für eine weitergehende Evaluierung der Reifegradstufen

CL2-CL5 schlagen wir vor, die Prozessattribute und Prozessfähigkeitsindikatoren, so wie sie in

Automotive SPICE definiert sind, zu übernehmen.

Fragenkataloge zur Evaluierung der Prozessleistung

Die Evaluierung der Reifegradstufe CL1 zielt darauf ab, festzustellen, ob ein Prozess seinen Pro-

zesszweck grundsätzlich erfüllt und die spezifizierten Prozessergebnisse erzielt werden. Geprüft

wird auf die Prozessleistung als fachlich richtige Implementierung des Prozessreferenzmodells.

Die konkrete Evaluierung erfolgt mittels sog. Prozessleistungsindikatoren (Process Performance

Indicators), die in Automotive SPICE durch die Spezifikation der Grundpraktiken und Ergebnis-

artefakte definiert sind.

Zusätzlich zur Definition der Grundpraktiken und Ergebnisartefakte haben wir zur Vereinfachung

des Prüfungsvorgangs eine Reihe von Kontrollfragen erarbeitet. Die Kontrollfragen unterstützen

den Prüfer dabei, den Umfang der Instanziierung der Grundpraktiken, die Existenz und Vollstän-

digkeit der Ergebnisartefakte, sowie Qualität der Prozessergebnisse besser einschätzen zu können.

Jede einzelne Kontrollfrage bezieht sich auf einen Teilprozess aus dem Prozessreferenzmodell

und ist individuell einer oder mehreren Grundpraktiken, Ergebnisartefakten sowie den Prozesser-

gebnissen aus dem Referenzmodells zugeordnet. Jede Frage kann mit „Ja“, „Nein“ und „teil-

weise“ beantwortet werden.

Insgesamt existieren für alle vier Teilprozesse „Detect & Register“, „Assess & Classify“, „Decide

& Respond“ sowie „Learn & Optimize“ Fragenkataloge mit insgesamt mehr als 60 Fragen, die

jeweils einzeln beantwortbar sind. Die Fragen inklusive ihrer Zuordnung zu den Grundpraktiken,

Ergebnisartefakten sowie den Prozessergebnissen sind im Folgenden in Form von Tabellen für

jeden Teilprozess separat dargestellt.


SIR.1 Detect & Register

# Question Outcome Base

Practice

Work

Product

SIR.1.Q1 Does the organization actively monitor security

events and security incidents of their own prod-

ucts and services? What is done to monitor se-

curity events and security incidents?

SIR.1.O1 SIR.1.BP1

SIR.1.Q2 Does the organization use tools for security

event and/or incident monitoring of their

backend systems? Which ones (intrusion detec-

tion systems, product monitoring, backend

monitoring)?

SIR.1.O1 SIR.1.BP1

SIR.1.Q3 Does the organization use tools for security

event and/or incident monitoring of their vehicle

systems? Which ones (intrusion detection sys-

tems, product monitoring, backend monitoring)?

SIR.1.O1 SIR.1.BP1

SIR.1.Q4 Does the organization actively monitor public

information pools on security incidents, security

threats and security vulnerabilities that are re-

lated to their own products and services? Which

public information pools are monitored? How

frequently?

SIR.1.O1 SIR.1.BP2

SIR.1.Q5 Are organizational units other than dedicated in-

cident response teams aware of the necessity

to look for security events or security incidents?

Which organizational units are involved in the

supervision of systems or the detection of secu-

rity incidents?

SIR.1.O1 SIR.1.BP1

SIR.1.BP2


SIR.1.Q6 Do organizational units other than dedicated in-

cident response teams know the definition of a

security incident? Are they capable of identify-

ing security incidents and differentiate between

service request or service disruption and secu-

rity incidents?

SIR.1.O1 SIR.1.BP1

SIR.1.BP2

SIR.1.Q7 Are the contact details/contact means for the

reporting of security incidents known to all in-

ternals (i.e. employees)?

SIR.1.O2 SIR.1.BP3

SIR.1.Q8 Are the contact details/contact means for the

reporting of security incidents available in the

public (e.g. for partners, customers, authori-

ties)?

SIR.1.O2 SIR.1.BP3

SIR.1.Q9 Is there a centralized structure or contact point

to accept and register security incidents?

SIR.1.O2 SIR.1.BP3

SIR.1.Q10 Are the employees of the centralized structure

or contact point trained adequately with respect

to information security?

SIR.1.O2

SIR.1.Q11 Does the organization manage (create, store,

update, control) security incident reports?

SIR.1.O2 SIR.1.BP3 SIR.1.WP1

SIR.1.Q12 Are IT-security incident reports kept confiden-

tial?


SIR.1.Q13 Is service desk staff aware of critical systems

that show considerable risk in case of an inci-

dent?

SIR.1.O3

SIR.1.O4

SIR.1.BP3

SIR.1.BP4

SIR.1.Q14 Do service desk staff know the definition and

policies related to incident response?

SIR.1.O3

SIR.1.O4

SIR.1.BP4

SIR.1.Q15 Do service desk staff tag or flag incidents when

they are related to security?

SIR.1.O4 SIR.1.BP4


SIR.1.Q16 Do service desk staff know who to contact in

case a severe security incident has happened?

SIR.1.O3

SIR.1.O4

SIR.1.BP4

SIR.1.Q17 Do the service desk checklists also contain

questions on the detection of security inci-

dents?

SIR.1.O3 SIR.1.BP3

SIR.1.BP4

SIR.1.Q18 Are security events and security incidents esca-

lated differently to service request and service

disruptions?

SIR.1.O4 SIR.1.BP4

SIR.1.Q19 Are security events and security incidents man-

aged by a ticket system that allow for assigning

and managing responsibilities?


SIR.1.Q20 Does the organization maintain a template for

security incident reports?

SIR.1.WP1

SIR.1.Q21 Do security incident reports contain information

related to the reporter (name, contact details)?

SIR.1.WP1


related to the observation and time (time of reg-

istration, time of observation), the reporter's ob-

servation on origin, effects and status?

SIR.1.WP1


related to trustworthiness of the reporter?

SIR.1.WP1


SIR.2 Assess & Classify


Practice

Work

Product

SIR.2.Q1 Does the organization check each report of a se-

curity incident or security events by means of

qualified personnel?

SIR.2.O1 SIR.2.BP1

SIR.2.Q2 Does the organization possess technical and or-

ganizational means to search for reports with

similar incidents?

SIR.2.O1 SIR.2.BP1

SIR.2.Q3 Does the organization maintain a classification

scheme to support decisions on trustworthiness

and criticality of incident reports?

SIR.2.O1 SIR.2.BP1

SIR.2.Q4 Does the organization maintain security inci-

dent records that are used to access all incident

related information and track the incident sta-

tus?

SIR.2.WP1

SIR.2.Q5 Are incident records are kept confidentially? SIR.2.WP1

SIR.2.Q6 Does the organization have dedicated rules to

handle ongoing major incidents?

SIR.2.O2 SIR.2.BP2

SIR.2.Q7 Is there 24/7 availability on personnel that are

required to carry out immediate actions (e.g. ex-

ternal communication, press information, sys-

tem deactivation etc.)?

SIR.2.O2 SIR.2.BP2

SIR.2.Q8 Do the organization prioritize incident records

with respect to the urgency of follow up ac-

tions?


SIR.2.Q9 Does the organization have dedicated pro-

cesses for security and business risk assess-

ment and management?



SIR.2.Q10 Does the incident response team know how to

contact business risk assessment to learn

about the business impact for incidents related

to each of the organization's relevant products

and services?


SIR.2.Q11 Does the organization have dedicated pro-

cesses for technical security risk assessment

and management?


SIR.2.Q12 Does the incident response team know how to

contact technical staff that is able to provide

details for each of the organization's relevant

products and services?


SIR.2.Q13 Do explicit rules exists that explain the interac-

tion between the security response team and

the risk assessment units?

SIR.2.O3 SIR.2.BP3

SIR.2.BP4

SIR.2.WP3

SIR.2.Q14 Does the organization and the incident response

team have access to compromised systems?

SIR.2.O4

SIR.2.O6

SIR.2.BP5 SIR.2.WP4

SIR.2.Q15 Does the organization and the incident response

team have access to all incident related infor-

mation like incident reports, log data etc.

SIR.2.O4

SIR.2.O6

SIR.2.BP4 SIR.2.WP3

SIR.2.WP4

SIR.2.Q16 Is the incident response team able and do they

have the permission to consult external ex-

perts?

SIR.2.O4 SIR.2.BP2

SIR.2.BP3

SIR.2.BP4

SIR.2.BP5

SIR.2.WP3

SIR.2.WP4

SIR.2.Q17 Do rules exist to interact with external security

experts? Are the rules known by staff?

SIR.2.O4 SIR.2.BP2

SIR.2.BP3

SIR.2.BP4

SIR.2.BP5

SIR.2.WP3

SIR.2.WP4

SIR.2.Q18 Do the incident response team has dedicated

forensics know how?

SIR.2.O4

SIR.2.O5

SIR.2.BP5 SIR.2.WP3

SIR.2.WP4


SIR.2.Q19 Does the incident response team maintain a

guide on how to secure the data of a suspicious

system?


SIR.2.Q20 Is it ensured that forensic data are collected in a

verifiable manner?


SIR.2.Q21 Are all activities in the investigation process

documented and recorded carefully and tamper-

proof?


SIR.2.Q22 Is it guaranteed that all concerned internal bod-

ies are promptly informed when a security inci-

dent has occurred?


SIR.2.Q23 Is it ensured that all concerned internal bodies

are informed of the immediate actions to mini-

mize the impact of a security incident and to re-

store the safe state?

SIR.2.O2

SIR.2.O6

SIR.2.BP2

SIR.2.BP6

SIR.2.WP5

SIR.2.Q24 Does the incident response team know and

maintain direct contact to the incident response

team in the supply chain?

SIR.2.01

SIR.2.02

SIR.2.03

SIR.2.BP1

SIR.2.BP2

SIR.2.BP3

SIR.2.BP4

SIR.2.BP6

SIR.2.WP1

SIR.2.WP2

SIR.2.WP3


SIR.3 Decide & Respond


Practize

Work

Product

SIR.3.Q1 Is it ensured that all concerned external bodies

are promptly informed when a security incident

has occurred? Is it ensured that they are in-

formed of the necessary measures to minimize

the impact of a safety incident and to restore

the safe state?


SIR.3.Q2 Is it defined who will provide information on se-

curity incidents to third parties?


SIR.3.Q3 Is it guaranteed that no unauthorized person

has access to information about the security in-

cident? (If information was distributed to exter-

nal parties for one of the last security incidents,

who was informed in which order and in what

detail?)


SIR.3.Q4 Does the organization maintain a list of custom-

izable countermeasures and standard re-

sponses?


SIR.3.Q5 Is there a dedicated process to decide upon

countermeasures that are defined as a response

to an incident?


SIR.3.Q6 Does the incident response team have control

over the actual status of countermeasure devel-

opment and execution?

SIR.3.O3

SIR.3.O4

SIR.3.BP3

SIR.3.BP4

SIR.3.WP1

SIR.3.Q7 Are technical countermeasures tested for ade-

quacy, stability and functionality before they are

rolled out as a response to an incident?



SIR.3.Q8 Is there a dedicated process to control the ef-

fectiveness of countermeasures that are rolled

out as a response to an incident?

SIR.3.O3 SIR.3.BP2

SIR.3.Q9 Does the incident response team have control

over the complete incident response life-cycle?


SIR.3.Q10 Does the incident response team is in charge to

finally close the incident after successful execu-

tion and control of the countermeasures?


SIR.3.Q11 Is there a technical infrastructure to preserve

and archive forensic evidence that may be re-

quired to reject legal claims?


SIR.3.Q12 Is it ensured that forensic evidence is stored

confidentially?



SIR.4 Learn & Optimize


Practice

Work

Product

SIR.4.Q1 Is there an overview of the detections methods

and tools that are used to detect security inci-

dents?

SIR.4.O1 SIR.4.BP1

SIR.4.BP2

SIR.4.BP3

SIR.4.WP1

SIR.4.WP2

SIR.4.Q2 Are the methods and tools checked for suitabil-

ity and efficiency on a regular basis?

SIR.4.O1 SIR.4.BP1

SIR.4.BP2

SIR.4.BP3

SIR.4.WP1

SIR.4.WP2

SIR.4.Q3 Is there a dedicated process that reviews the

suitability and efficiency of the incident re-

sponse process?

SIR.4.O1 SIR.4.BP1,

SIR.4.BP2

SIR.4.BP3

SIR.4.WP1

SIR.4.WP2

SIR.4.Q4 Is there a dedicated process that identifies pro-

cess improvement in the aftermath of larger se-

curity incidents?

SIR.4.O1 SIR.4.BP1

SIR.4.BP2

SIR.4.BP3

SIR.4.WP1

SIR.4.WP2

SIR.4.Q5 Is there a dedicated process that identifies edu-

cation gaps and training requirements in the af-

termath of larger security incidents?

SIR.4.O1 SIR.4.BP1

SIR.4.BP2

SIR.4.BP3

SIR.4.WP1

SIR.4.WP2

SIR.4.Q6 Are vulnerabilities and other technical causes of

an incident reported back to development units

and development partners?


SIR.4.Q7 Is it ensured that development units and devel-

opment partners sufficiently address the vulner-

abilities?


SIR.4.Q8 Is it ensured- that similar vulnerabilities in soft-

ware variants and versions are addressed?


SIR.4.Q9 Does your organization have a dedicated vulner-

ability management process?



SIR.4.Q10 Are long-term security measures derived from

incident information and returned to technical

development?


SIR.4.Q11 Is vulnerability information fed into public infor-

mation pools? If not, why not?


SIR.4.Q12 Are security incidents evaluated so that new

threat information can be identified? Are this

threat information reported back to technical

development?


SIR.4.Q13 Are new patterns for incident detection derived

from most recent incident information? Are this

information systematically reported back to or-

ganizational units that respond incident detec-

tion?


SIR.4.Q14 Are threat and incident information fed into

public information pools? If not, why not?



Das Verhältnis der für einen Indikator positiv beantworteten zu den negativ beantworteten Fragen

ist, neben dem Vorhandensein und der Vollständigkeit der Grundpraktiken und Ergebnisartefakten

in allen Prozessinstanzen, ein starkes, wenn auch nicht alleiniges Indiz dafür, dass in dem Prozess

die richtigen Aktivitäten durchgeführt und die richtigen Artefakte in ausreichender Qualität reali-

siert werden. Das endgültige Urteil darüber, welchen Stellenwert die einzelnen Fragen im Prüf-

prozess haben sollen, obliegt jedoch weiterhin dem Prüfer.

Zur Operationalisierung des Fragenkatalogs haben wir ein Excel-Dokument erstellt, dass die

Durchführung einer Befragung entlang des Fragenkatologs unterstützt und die Bewertung der

Antworten automatisiert. Abbildung 1 zeigt einen Ausschnitt der Excel-Tabelle zur Operationali-

sierung der Kontrollfragen. Auf der linken Seite befinden sich die Kontrollfragen, es folgen die

Felder für die Antworten und die Zuordnung zu den Leistungsindikatoren und Prozessergebnis-

sen. In den unteren Spalten befinden sich die aus den Antworten errechneten Bewertungen zu den

einzelnen Leistungsindikatoren und Prozessergebnissen.

Abbildung 5: Excel-Tabelle zur Operationalisierung der Kontrollfragen (Auszug)


Zusammenfassung

Wir halten es für wichtig, dass im Bereich der Automobilindustrie Prozesse nicht nur in Form von

Base-Practices beschrieben werden, sondern die Umsetzung der Prozesse in den Unternehmen

und ihr Reifegrad in Bezug auf Kontrollierbarkeit sowie Optimierungs- und Innovationsfähigkeit

überprüfbar wird. Aus diesem Grund haben wir uns entschieden, den Car-SIR-Prozess so zu be-

schreiben, dass er sich möglichst einfach in ein bestehendes Prüfverfahren eingliedern lässt. Wir

haben uns für SPICE bzw. Automotive SPICE als Integrations- bzw. Zielplattform entschieden,

weil dieses Verfahren bereits in der Automobilindustrie etabliert ist und aktiv vom VDA unter-

stützt wird. Der Security-Incident-Response-Prozess inklusive des Fragenkatalogs ist in Form ei-

nes Excel-Arbeitsmappe spezifiziert und diesem Bericht beigelegt. Mit der Bereitstellung des Re-

ferenzprozesses sowie des Fragenkatalogs haben wir den Car-SIR-Prozess initial in ein existie-

rendes Prüfschema integriert sowie dezidierte Hilfsmittel geschaffen, mit der sich eine CL1-Prü-

fung unterstützen lässt. Uns ist bewusst, dass eine vollständige Prüfung auch der anderen Reife-

gradstufen ein komplexer Prozess ist, den wir im Rahmen dieses Projekts weder durchführen noch

evaluieren konnten.


ANHANG

Glossar

Dieser Bericht behandelt den Umgang mit Sicherheitsvorfällen bezogen auf IT-Systeme im Kon-

text Fahrzeuge, die durch Überwindung von IT-Sicherheitsmaßnahmen z. B. durch Hackeran-

griffe ausgelöst wurden. Zur Vereinfachung wird daher der Begriff Sicherheit im Sinne von IT-

Sicherheit verwendet. Entsprechend beziehen sich die Begriffe Sicherheitsereignis, Sicherheits-

lücke und Sicherheitsvorfall auf die IT-Sicherheit. Falls von IT-unabhängiger Sicherheit und/oder

von Sicherheit im Sinne von Safety (statt Security) gesprochen wird, ist dies entsprechend explizit

angemerkt.

Begriff Synonym(e) Definition (kursiv: ISO/IEC 27000:2016(en))

Bedrohung Threat Threat: potential cause of an unwanted inci-

dent, which may result in a harm to a system

or organization

Car-Security Fahrzeugbezogene IT-Si-

cherheit

Die IT-Sicherheit von Fahrzeugen betreffend

Car-Security-Ereignis Fahrzeugbezogenes Sicher-

heitsereignis

Ein Sicherheitsereignis bezogen auf ein oder

mehrere IT-Systeme, Services oder Netz-

werke, die sich im Fahrzeug befinden oder

mit einem Fahrzeug verbunden sind

Car-Security-Vorfall Fahrzeugbezogener Sicher-

heitsvorfall

Ein Sicherheitsvorfall bezogen auf ein oder

mehrere IT-Systeme, Services oder Netz-

werke, die sich im Fahrzeug befinden oder

mit einem Fahrzeug verbunden sind


Ereignis Event Event: occurrence or change of a particular

set of circumstances

Sicherheit IT-Sicherheit, Information-

Security

Information security: preservation of confi-

dentiality, integrity and availability of infor-

mation

Sicherheitsereignis IT-Sicherheitsereignis,

Security-Event, Information-

Security-Event

Information security event: identified occur-

rence of a system, service or network state in-

dicating a possible breach of information se-

curity policy or failure of controls, or a previ-

ously unknown situation that may be security

relevant

Sicherheitslücke Vulnerability, Security-Vul-

nerability

Vulnerability: weakness of an asset or control

that can be exploited by one or more threat

Sicherheitsvorfall IT-Sicherheitsvorfall,

Security-Incident, Informa-

tion-Security-Incident

Information security incident: single or a se-

ries of unwanted or unexpected information

security events that have a significant proba-

bility of compromising business operations

and threatening information security

Stand der Technik

Computer-Security-Incident-Response (CSIR) oder Security-Incident-Response (SIR) ist aus ei-

nem modernen IT- Betrieb nicht mehr wegzudenken. Entsprechend existieren bereits heute eine

Reihe etablierter Praktiken, Methoden, Prozesse und Standards, die sich diesem Thema, insbe-

sondere im Kontext der Unternehmens- bzw. Organisations-IT ausführlich widmen. Zu nennen

sind hier dedizierte CSIR bzw. SIR Standards und Handbüchern wie die ISO 27035, NIST SP

800-61r2 oder auch der IT-Grundschutz des BSI (ISO/IEC 2016, Cichonski at al. 2012, BSI

2016). Zusätzlich dazu können grundlegende Prozessmodelle zum Incident-Response-Manage-

ment aus IT-Prozessframeworks wie z.B. ITIL (ITIL 2017) oder COBIT (ISACA 2012) sinnvolle

Anhaltspunkte für Security-Incident-Response-Prozesse auch für fahrzeugbezogene Softwaresys-


teme werden. Schlussendlich gibt es auch im Umfeld der Automobilindustrie mit den Standardi-

sierungsinitiativen bei der ISO (ISO2017) und der SAE (SAE2016) Arbeiten, die das Thema In-

cident-Response speziell für Fahrzeugsoftware adressieren.

Betrachtet man die wichtigsten Handbücher und Standards im Bereich des Security-Incident-

Response, lassen sich die die relevanten Phasen für die Behandlung von Sicherheitsvorfällen wie

folgt zusammenfassen:

• Planung und Vorbereitung

• Vorfalldetektion und -erkennung

• Vorfallanalyse und -klassifizierung

• Eindämmung und Wiederherstellung

• Dokumentation und Feedback

BSI-Grundschutz

Die IT-Grundschutz-Kataloge (BSI 2016) sind eine Sammlung von Anleitungen und Dokumen-

tationen des deutschen Bundesamts für Sicherheit in der Informationstechnik (BSI), die der Er-

kennung und Vermeidung sicherheitsrelevanter Schwachstellen in IT-Umgebungen dienen. Die

Sammlung dient Organisationen, Unternehmen und Behörden, in Kombination mit der ISO/IEC

27001, als Grundlage zum Erlangen einer kombinierten Zertifizierung nach IT-Grundschutz und

ISO/IEC 27001.

Die IT-Grundschutz-Kataloge umfassen detaillierte Sicherheitsmaßnahmen für den IT-Betrieb.

Das Kapitel B1.8 der aktuellen Ausgabe des IT Grundschutz enthält eine detaillierte Anleitung zu

organisatorisch, technischen Maßnahmen für die Behandlung von Sicherheitsvorfällen (Security-

Incident-Handling oder auch Security-Incident-Response) in Organisationen und Unternehmen.

Das BSI unterscheidet hierbei Maßnahmen zur „Planung und Konzeption“, „Umsetzung“ und den

„Betrieb“ des Security-Incident-Handlings. Ergänzend definiert das BSI das sog. Notfallmanage-

ment (siehe B1.3 in BSI 2016), welches sich speziell mit der Aufrechterhaltung oder Wiederher-

stellung der Verfügbarkeit kritischer Unternehmensinfrastruktur beschäftigt. Die IT-Grundschutz-

Kataloge sind im Hinblick auf die Absicherung von Organisations- und Unternehmensinfrastruk-

tur entwickelt worden und fokussieren insbesondere organisatorische Maßnahmen, die als Grund-

lage einer Zertifizierung geprüft werden können. Die IT-Grundschutz-Kataloge werden laufend

aktualisiert. Derzeit werden sie im Rahmen eines Modernisierungsprozesses überarbeitet und neu

strukturiert. Die aktualisierten BSI-Standards 200-1, 200-2 und 200-3 stehen zur Kommentierung

durch die Anwender bereit.


ISO 27035

Der ISO Standard 27035 (ISO/IEC 2016) umfasst die Prozesse für die Behandlung von Informa-

tionssicherheitsereignissen, Sicherheitsvorfällen und Schwachstellen. Der Standard definiert ei-

nen Prozess mit den fünf Phasen „Prepare“, „Identify“, „Assess“, „Respond“ und „Learn“. Diese

definieren organisatorische Maßnahmen zum Aufbau und Ausbau von Strukturen und Fähigkeiten

zur Behandlung von Sicherheitsvorfällen sowie Maßnahmen und Best-Practices zur konkreten

Behandlung von Sicherheitsvorfällen. Neben der Definition von Maßnahmen bietet der Standard

Vorlagen für den Aufbau von Dokumentations- und Berichtsformulare über Sicherheitsereignisse,

Sicherheitsvorfälle und Schwachstellen. ISO/IEC 27035 ersetzt ISO TR 18044. Der Standard

wurde im Jahr 2011 veröffentlicht. Derzeit wird der Standard überarbeitet und in drei Teile auf-

geteilt.

ISO/IEC 27035-1: 2016 Grundsätze des Vorfallmanagements skizziert die Konzepte und Grunds-

ätze, die das Management von Sicherheitsvorfällen untermauern. Es beschreibt einen Prozess be-

stehend aus den oben genannten fünf Phasen und definiert, wie man das Vorfallmanagement ver-

bessern kann.

ISO/IEC 27035-2: 2016 Leitlinien zur Planung und Vorbereitung des Vorfallmanagements um-

fasst speziell die Phasen „Prepare“ und „Learn“ und beschäftigt sich mit der Herausbildung und

Verbesserung der Security-Incident-Response-Fähigkeiten in einer Organisation.

ISO/IEC 27035-3: Leitlinien für den Betrieb stellt konkrete Anleitungen für das effiziente Ma-

nagement und die Reaktion auf Sicherheitsvorfälle zur Verfügung. Der Standard beschreibt ent-

lang vordefinierter Klassen bzw. Typen von Sicherheitsereignissen Maßnahmen für die Erken-

nung, Berichterstattung, Bewertung, Entscheidung, Reaktion und Dokumentation im Kontext der

jeweiligen Ereignistypen.

Während die Dokumente ISO 27035-1 und ISO 27035-2 im Jahr 2016 veröffentlicht wurden,

steht ISO 27035-3 aufgrund ungenügender Beiträge aus den nationalen Gremien aktuell nur als

Draft-Dokument zur Verfügung.

NIST SP 800-61r2

Der amerikanische Standard NIST SP 800-61r2 (Cichonski at al. 2012) unterstützt Organisationen

und Unternehmen beim Aufbau von Computer-Security-Incident-Response-Fähigkeiten sowie

bei der konkreten Behandlung von Vorfällen. Das Dokument definiert typische Informationsflüsse

und einen idealisierten Lebenszyklus sowie die notwendigen Unterlagen wie schriftliche Richtli-

nien, Vorfallspläne und Dokumentationen.


CERT: Handbook for Computer Security Incident Response Teams (CSIRTs)

Das Handbuch “CERT: Handbook for Computer Security Incident Response Teams (CSIRTs)”

(Brown et al. 2003) ist einer der meistzitierten Dokumentationen zum Aufbau von Security-Inci-

dent-Response-Fähigkeiten und enthält Anleitungen zum Aufbau und Betrieb eines Computer-

Security-Incident-Response-Teams (CSIRT). Insbesondere hilft es Organisationen und Unterneh-

men, die Art und den Umfang eines Computersicherheits-Incident-Handling-Service zu definie-

ren und zu dokumentieren. Das Dokument erläutert die Funktionen, aus denen ein solcher Service

besteht sowie die Art und Weise, wie diese Funktionen sinnvoll miteinander interagieren sollten.

Darüber hinaus definiert das Handbuch die notwendigen Werkzeuge, Verfahren und Rollen, die

zur Umsetzung des Dienstes erforderlich sind.

Weil das Handbuch die CSIRT-Konstituenten als Klienten betrachtet, deren Zufriedenheit vorran-

gig ist, adressiert das Dokument auch Aspekte der Qualitätssicherung. Das primäre Publikum für

das Handbuch sind Führungskräfte, die für die Erstellung oder den Betrieb eines CSIRT oder

eines Incident-Handling-Service verantwortlich sind.

ITIL

ITIL (ITIL 2017) ist eine herstellerunabhängige Sammlung von Best-Practices für IT-Service-

Management. Ziel der Sammlung ist es, Effizienz und Qualität von der IT-Services und Service-

Organisationen maßgeblich zu erhöhen. ITIL ist kein Framework, das sich speziell dem Thema

IT-Sicherheit widmet. Im Fokus stehen Service-Verfügbarkeit und Qualität. Folgerichtig werden

Sicherheitsvorfälle im Rahmen von ITIL nicht explizit betrachtet, sondern im Rahmen der allge-

meinen Vorfallbehandlung (mit-)behandelt. Die Vorfallbehandlung nach ITIL besteht aus einer

Reihe von Teilprozessen, die sich entweder wie der „Incident-Management-Support“ um den Auf-

bau, die Verstetigung und die Verbesserung der Vorfallbehandlung kümmern oder aber für die

konkrete Vorfallbehandlung zuständig sind. Zu Letzterem gehören Prozesse für die Vorfallerfas-

sung und -kategorisierung, eine Supportinfrastruktur (1st bis 3rd-Level-Support) sowie Prozesse

zur Überwachung und Eskalation, Anwenderinformation, zur Dokumentation und zum Reporting.

ISACA: Incident Management and Response

Das ISACA Whitepaper (ISACA 2012) motiviert die Notwendigkeit eines Incident-Response-

Teams und definiert die Phasen des Incident-Lifecycles, die damit verbundenen Strategien zur

Informationssicherheit und andere Governance-Aktivitäten. Ähnlich wie auch die anderen Stan-

dards bzw. Handbücher wird unterschieden zwischen Vorbereitung und Planung sowie der Vor-

fallbehandlung mit den Phasen „Detection, triage and investigation“, „Containment, analysis,

tracking and recovery“, „Post-incident assessment“ und „Incident closure“. Im Gegensatz zu ITIL

argumentiert das Whitepaper vor dem Hintergrund der besonderen Relevanz der IT-Sicherheit


und des Schutzes der IT-Infrastruktur für die Aufrechterhaltung der Funktionsfähigkeit von Un-

ternehmen und Organisationen. Zur Unterstützung einer strukturierten Einführung bzw. Integra-

tion von Incident-Response-Fähigkeiten in bestehende Prozesse bzw. Strukturen verbindet das

Dokument die dargestellten Incident-Response-Funktionen mit relevanten COBIT-Kontrollzie-

len. COBIT wird so zur systematischen und prüfbaren Basis für eine effektive Vorfallbehandlung.

SAE J3061 Cybersecurity Guidebook for Cyber Physical Vehicle Systems

Der SAE Standard J3061(SAE 2016) stellt ein Prozess-Framework für den Aufbau von Cyber-

Security-Prozessen in der Automobilindustrie zur Verfügung. Er unterstützt Organisationen dabei,

Cyber-Security-Bedrohungen für Fahrzeuge zu identifizieren, zu bewerten und zu eliminieren so-

wie sichere Fahrzeugsysteme zu entwerfen. Der Standard definiert ein komplettes Prozess-Frame-

work für den gesamten Produktlebenszyklus eines Fahrzeugs mit Maßnahmen für die Absiche-

rung der Fahrzeugsoftware sowie der Begleitung eines sicheren Betriebs von Fahrzeugsystemen

von der Konzeption, Entwicklung, Produktion über den Betrieb bis zur Stilllegung der Fahrzeuge.

Neben der Definition von Richtlinien bietet der Standard konkrete Hinweise auf geeignete Me-

thoden und Werkzeuge, die die Cyber-Security-Prozesse geeignet unterstützen. In der Definition

des Incident-Response-Prozesses bezieht sich der Standard maßgeblich auf NIST SP 800-61r2

(NIST 2012). SAE J3061 wurde im Januar 2016 veröffentlicht.

ISO/SAE AWI 21434 Cybersecurity Engineering

ISO/SAE AWI 21434 Road Vehicles – Cybersecurity Engineering (ISO 2017) ist eine neue Stan-

dardisierungsinitiative der ISO, um gemeinsam mit der SAE einen verbindlichen Standard für

Cyber-Security-Prozesse bei der Entwicklung und für den Betrieb von Fahrzeugsystemen zu ent-

wickeln. Der Standard wird in der ISO vom TC22/SC32 Electrical and Electronic Components

and General System Aspects entwickelt und befindet sich aktuell in der Phase „20.00 – Prepera-

tory“. Die Entwicklung des Standards wird von den deutschen OEMs maßgeblich unterstützt. Es

wird eine Harmonisierung mit SAE J3061 (SAE 2016) angestrebt.


Literaturverzeichnis

A-SPICE (2015): Automotive SPICE Process Assessment / Reference Model. VDA QMC Work-

ing Group 13 / Automotive SIG. 2015.

Brown, Moia West / Stikvoort, Don / Kossakowski, Klaus-Peter/ Killcrece, Georgia / Ruefle,

Robin / Zajicek, Mark (2003): Handbook for Computer Security Incident Response Teams

(CSIRTs), Software Engineering Institute, MU/SEI-2003-HB-002, 2003.

BSI (2016): IT-Grundschutz-Kataloge. Köln: Bundesanzeiger, 2016.

Cichonski, P. / Millar, T. / Grance, T. / Scarfone, K. (2012): Computer Security Incident Handling

Guide: Recommendations of the National Institute of Standards and Technology. National Insti-

tute of Standards and Technology, NIST SP 800-61r2, Aug. 2012.

Hoyer, Stefan (2006): Kritische Erfolgsfaktoren für ein Computer Emergency Response Team

(CERT). 2006

ISACA (2012): Incident management and response. Whitepaper, 2012.

ISO/IEC (2016): ISO/IEC 27035:2016 Information technology – Security techniques – Infor-

mation security incident management – Part 1-3, 2016.

ISO/SAE (2017): ISO/SAE AWI 21434 Road Vehicles – Cybersecurity engineering, (Standard in

Entwicklung), angekündigt unter https://www.iso.org/standard/70918.html, 2017.

ITIL (2017): IT Process Wiki - Das ITIL®-Wiki | IT Process Maps, IT Process Wiki - das ITIL®-

Wiki. [Online]. Verfügbar unter: http://wiki.de.it-processmaps.com/index.php/Hauptseite.

[Zugegriffen: 27-März-2017].

Miller, Charlie / Valasek, Chris (2015): Remote exploitation of an unaltered passenger vehicle.

Black Hat USA, 2015.

MU/SEI (2003): MU/SEI-2003-HB-002 Handbook for computer security incident response teams

(CSIRTs). Software Engineering Institute, 2003.

NIST (2012): SP 800-61r2, 2012.

SANS (2007): Creating and managing an incident response team for a large company, 2007.

SAE (2016): SAE J3061 Cybersecurity Guidebook for Cyber Physical Vehicle Systems, 2016.

SPICE (2012): Information technology – Process assessment – Part 5: An exemplar life cycle

process assessment model. ISO/IEC 15504-5: 2012.

car-security-incident-response -...

Documents