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)
Datum 27.11.2017
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).
Car-Security-Incident-Response 2
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.
Car-Security-Incident-Response 3
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:
Car-Security-Incident-Response 4
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.
Car-Security-Incident-Response 5
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.
Car-Security-Incident-Response 6
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
Car-Security-Incident-Response 7
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.
Car-Security-Incident-Response 8
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
Car-Security-Incident-Response 9
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)“.
Car-Security-Incident-Response 10
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]
Car-Security-Incident-Response 11
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.
Car-Security-Incident-Response 12
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.
Process outcome Results of successful implementation of this process are:
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
Car-Security-Incident-Response 13
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].
Car-Security-Incident-Response 14
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-
Car-Security-Incident-Response 15
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.
Car-Security-Incident-Response 16
Process outcome Results of successful implementation of this process are:
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]
Car-Security-Incident-Response 17
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]
Car-Security-Incident-Response 18
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.
Process outcome Results of successful implementation of this process are:
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
Car-Security-Incident-Response 19
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]
Car-Security-Incident-Response 20
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-Incident-Response 21
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-
Car-Security-Incident-Response 22
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)
Car-Security-Incident-Response 23
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).
Car-Security-Incident-Response 24
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:
Car-Security-Incident-Response 25
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.
Car-Security-Incident-Response 26
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.
Car-Security-Incident-Response 27
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:
Car-Security-Incident-Response 28
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.
Car-Security-Incident-Response 29
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
Car-Security-Incident-Response 30
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.
Car-Security-Incident-Response 31
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,
Car-Security-Incident-Response 32
• 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
Car-Security-Incident-Response 33
□ 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
Car-Security-Incident-Response 34
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:
Car-Security-Incident-Response 35
• 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.
Car-Security-Incident-Response 36
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-Incident-Response 37
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.
Car-Security-Incident-Response 38
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
Car-Security-Incident-Response 39
□ 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
Car-Security-Incident-Response 40
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
Car-Security-Incident-Response 41
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
Car-Security-Incident-Response 42
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.
Car-Security-Incident-Response 43
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.
Car-Security-Incident-Response 44
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.
Car-Security-Incident-Response 45
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
Car-Security-Incident-Response 46
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.O2 SIR.1.BP3 SIR.1.WP1
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
Car-Security-Incident-Response 47
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.O4 SIR.1.BP4 SIR.1.WP1
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
SIR.1.Q22 Do security incident reports contain information
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
SIR.1.Q23 Do security incident reports contain information
related to trustworthiness of the reporter?
SIR.1.WP1
Car-Security-Incident-Response 48
SIR.2 Assess & Classify
# Question Outcome Base
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.O2 SIR.2.BP2 SIR.2.WP2
SIR.2.Q9 Does the organization have dedicated pro-
cesses for security and business risk assess-
ment and management?
SIR.2.O3 SIR.2.BP4 SIR.2.WP3
Car-Security-Incident-Response 49
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.O3 SIR.2.BP4 SIR.2.WP3
SIR.2.Q11 Does the organization have dedicated pro-
cesses for technical security risk assessment
and management?
SIR.2.O3 SIR.2.BP3 SIR.2.WP3
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.O3 SIR.2.BP3 SIR.2.WP3
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
Car-Security-Incident-Response 50
SIR.2.Q19 Does the incident response team maintain a
guide on how to secure the data of a suspicious
system?
SIR.2.O5 SIR.2.BP5 SIR.2.WP4
SIR.2.Q20 Is it ensured that forensic data are collected in a
verifiable manner?
SIR.2.O5 SIR.2.BP5 SIR.2.WP4
SIR.2.Q21 Are all activities in the investigation process
documented and recorded carefully and tamper-
proof?
SIR.2.O5 SIR.2.BP5 SIR.2.WP4
SIR.2.Q22 Is it guaranteed that all concerned internal bod-
ies are promptly informed when a security inci-
dent has occurred?
SIR.2.O6 SIR.2.BP6 SIR.2.WP5
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
Car-Security-Incident-Response 51
SIR.3 Decide & Respond
# Question Outcome Base
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.O1 SIR.3.BP1 SIR.3.WP1
SIR.3.Q2 Is it defined who will provide information on se-
curity incidents to third parties?
SIR.3.O1 SIR.3.BP1 SIR.3.WP1
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.O1 SIR.3.BP1 SIR.3.WP1
SIR.3.Q4 Does the organization maintain a list of custom-
izable countermeasures and standard re-
sponses?
SIR.3.O2 SIR.3.BP2 SIR.3.WP2
SIR.3.Q5 Is there a dedicated process to decide upon
countermeasures that are defined as a response
to an incident?
SIR.3.O2 SIR.3.BP2 SIR.3.WP2
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.O3 SIR.3.BP2 SIR.3.WP1
Car-Security-Incident-Response 52
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.O4 SIR.3.BP3 SIR.3.WP3
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.O4 SIR.3.BP3 SIR.3.WP3
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.O5 SIR.3.BP4 SIR.3.WP4
SIR.3.Q12 Is it ensured that forensic evidence is stored
confidentially?
SIR.3.O5 SIR.3.BP4 SIR.3.WP4
Car-Security-Incident-Response 53
SIR.4 Learn & Optimize
# Question Outcome Base
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.O2 SIR.4.BP4 SIR.4.WP3
SIR.4.Q7 Is it ensured that development units and devel-
opment partners sufficiently address the vulner-
abilities?
SIR.4.O2 SIR.4.BP4 SIR.4.WP3
SIR.4.Q8 Is it ensured- that similar vulnerabilities in soft-
ware variants and versions are addressed?
SIR.4.O2 SIR.4.BP4 SIR.4.WP3
SIR.4.Q9 Does your organization have a dedicated vulner-
ability management process?
SIR.4.O2 SIR.4.BP4 SIR.4.WP3
Car-Security-Incident-Response 54
SIR.4.Q10 Are long-term security measures derived from
incident information and returned to technical
development?
SIR.4.O2 SIR.4.BP4 SIR.4.WP3
SIR.4.Q11 Is vulnerability information fed into public infor-
mation pools? If not, why not?
SIR.4.O2 SIR.4.BP4 SIR.4.WP3
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.O3 SIR.4.BP5 SIR.4.WP4
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.O3 SIR.4.BP5 SIR.4.WP4
SIR.4.Q14 Are threat and incident information fed into
public information pools? If not, why not?
SIR.4.O3 SIR.4.BP5 SIR.4.WP4
Car-Security-Incident-Response 55
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)
Car-Security-Incident-Response 56
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.
Car-Security-Incident-Response 57
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
Car-Security-Incident-Response 58
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-
Car-Security-Incident-Response 59
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.
Car-Security-Incident-Response 60
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.
Car-Security-Incident-Response 61
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
Car-Security-Incident-Response 62
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.
Car-Security-Incident-Response 63
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.