WDWS-Cybersecurity-Prozess

Kein System kann von sich aus garantieren, dass es zu 100% sicher ist. Durch das Befolgen eines definierten und gut strukturierten (WDWS) Cybersecurity Prozesses bietet für uns eine Möglichkeit, die Wahrscheinlichkeit eines erfolgreichen Angriffs auf eine Schachstelle zu minimieren.
Ein gut definierter und gut strukturierter (WDWS = WELL DEFINED and WELL STRUCTURED) Prozess beinhaltet wiederholbare strukturierte Methoden für eine systematische Identifizierung und Bewertung möglicher Bedrohungen und Schwachstellen, die von Angreifer ausgenutzt werden können, sowie geeignete Cybersecurity-Kontrollen, die während der Entwicklung in das System integriert werden, um sich vor den identifizierten Schwachstellen zu schützen.
Ein WDWS-Prozess beinhaltet Anleitungen über den gesamten Lebenszyklus von der Konzeptphase über Entwicklung, Produktion, Betrieb und Service.

Product Development life-cycle

Der Produkt Development Life-Cycle besteht aus
- der Produktentwicklung auf Systemebene,
- der Produktentwicklung auf Hardwareebene und
- der Produktentwicklung auf Softwareebene.

Im Laufe der Produktentwicklung auf Systemebene wird das Cybersecurity-Konzept in ein technisches Cybersecurity-Konzept verfeinert (d.h. die im Cybersecurity-Konzept beschriebene Cybersecurity Strategie auf hoher Ebene wird in einer technischen Beschreibung verfeinert). Um das Cybersecurity-Konzept in das Technical Cybersecurity-Konzept zu verfeinern, wird eine Bedrohungsanalyse bzw. eine Schwachstellenanalyse auf Systemebene durchgeführt.

Tara

TARA ist die Abkürzung für “Thread Analysis and Risk Assessment” bedeutet soviel wie “Bedrohungsidentifikation und Risikobewertung”; ähnlich der HARA “Hazard & Risk Analysis” die in der funktionalen Sicherheit Anwendung findet.

Die SAE J3061 fordert, dass Cyber-Security Engineering einen geeigneten Lebenszyklusprozess erfordert, der analog zu dem in der ISO 26262 beschriebenen Prozessrahmen definiert ist.
Es gibt keine Einschränkungen hinsichtlich der Aufrechterhaltung von jeweils separater Prozesse für funktionaler Sicherheit und Cybersecurity oder beider Prozesse direkt miteinander zu integrieren. Darüber hinaus empfiehlt der Leitfaden eine erste Bewertung potenzieller Bedrohungen und eine Abschätzung der Risiken für Systeme, die als Cybersicherheitsrelevant oder sicherheitsrelevante Systeme angesehen werden können, um festzustellen, ob mögliche Cyber-Sicherheitsbedrohungen vorliegen, die potenziell zu Safety-Sicherheitsverletzungen führen können.

Vor dem Start des Entwicklungsprozesses wird auf Grundlage einer “Feature Definition” eine TARA durchgeführt. Dabei geht es um die Identifikation und Kategorisierung von Bedrohungen durch unberechtigte Dritte auf sicherheitsrelevante elektronische Steuerungssysteme. Die Risikoidentifikation und -bewertung wird qualitativ durchgeführt und der Umfang der Risikobetrachtung umfasst die Kompromittierung der Sicherheitsfunktion sowie der unberechtigter Zugriff auf sensible und vertrauliche Daten zum Zweck der betrügerischen oder schädlichen Manipulation.
Die SAE J3061schlägt für die Automotive Domain die folgenden Bedrohungs- & Risiko Analysemethoden für eine TARA vor:
– EVITA method (E-Safety Vehicle Intrusion Protected Applications);
– TVRA (Threat, Vulnerabilities, and implementation Risks Analysis)*;
– OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)*;
– HEAVENS security model (HEAling Vulnerabilities to ENhance SW Security & Safety);
– Attack trees (Angriffsbäume zeigen, wie ein Asset oder Ziel angegriffen werden kann);
– SW vulnerability analysis (Software Schwachstellen Analyse);
darüber hinaus gibt es noch weitere Methoden eine TARA durchzuführen:
- FMVEA (Failure Mode Vulnerability & Effect Analysis);
- SAHARA (security-aware hazard and risk analysis method);
- Threat Matrix (Bedrohungsmatrix);
- BRA (Binary Risk Analysis);
- BDMP (Boolean logic Driven Markov Process / in Kombination mit FMVEA Analysis);
- SHIELD-, CHASSIS-Methodology, ..usw.
( * nicht für den Automotivebereich)

Cybersecurity Processes for Automotive

Die grundlegende Prozessstruktur der Cybersecurity Engineering Prozesse ähneln der Prozessstrukturen aus der Funktionalen Sicherheit für elektronische Systeme für Kraftfahrzeuge (ISO 26262).
Dieses besteht aus den grundlegenden Bereichen “Management of Cybersecurity”, den Entwicklungsaktivitäten für System, Hardware und Software, den Produktions- & Operationsbegleitende Aktivitäten, sowie den Supporting Aktivitäten.
Jeder Prozess besteht wiederum aus mehreren Prozessschritte (Anforderungen), benötigt prozessspezifische Eingangs-Informationen und liefert gemäß seines Prozesszwecks einen oder mehrere Prozess-Outputs (Prozessergebnisse / Work Products).

Cybersecurity Tasks (Life-Cycle Example)

Vorhandenseins der Cybersecurity-Prozesse und Etablierung einer Cybersecurity Culture (siehe oben) sowie die Bereitstellung der benötigten Templates, Checklisten, Normen, Review-Checklisten, vordefinierte Arbeitsdokumente (WP’s) und Anleitungen werden vorausgesetzt, sowie die oben genannten Cybersecurity Supporting-Prozesse.

- Ermittlung der Feature Definition und Ableitung der Cybersecurity Requirements;
- Erstellung & Management des Cybersecurity Plans (ähnlich dem des SafetyPlans);
- Durchführung der TARA: Identifikation von Bedrohungen und Risikobewertung (z.B. STRIDE, THROP, HEAVENS, EVITA, FMVEA/ATA..) & Erstellung eines Attack-Trees;
- Identifikation der Cybersecurity-Goals (CG);
- Ableitung des Cybersecurity Konzepts;
- Ableitung der funktionalen Cybersecurity-Anforderungen aus den Cybersecurity-Konzept und den Cybersecurity-Zielen;
- Ableitung der Anforderungen des Cybersecurity-Konzepts auf technische Spezifikationen und jeweiligen Schutzmaßnahmen/Verteidigungsmaßnahmen;
- Ableitung der Cybersecurity-Anforderungen an Hardware und Software;
- Festlegung der Teststrategie sowie der Testmethoden zum Nachweis der Angriffssicherheit;
- Erstellen des Cybersecurity CASE nach SAE J 3061;
- Durchführung des Cybersecurity Assessment zur unabhängigen Bestätigung der Angriffssicherheit;
- Permanente Weiterqualifizierung und Training der mit Cybersecurity betrauten Personals;
- Parallel stattfindende unabhängige Reviews sowie Phasenreviews (interne Assessments);
- Umsetzung der Absicherung der Cybersecurity nach SOP für Produktion, Betrieb und Instandhaltung angriffssicherer Systeme (sowie Feldüberwachung, Behandlungen von Vorkommnissen/Attacken, Reparaturen, Austausch, SW-Updates usw..);

FMVEA Analysis

Eine FMVEA (Failure Mode Vulnerability & Effect Analysis) Analyse erweitert den klassischen Standardansatz der FMEA Methodik um sicherheitsrelevante Bedrohungsmodi im Bereich Cybersecurity und stellt somit eine weitere Methode einer Threat Analysis and Risk Assessment (TARA) zur Verfügung.
Die angewandten Bedrohungsmodi der FMVEA basieren auf dem STRIDE*-Ansatz, bei dem Bedrohungen in sechs der häufigsten Kategorien* eingeteilt werden:
Spoofing of user identity, Tampering, Repudiation, Information disclosure, Denial of service (DoS), Elevation of privilege (EoP).
Abhängig von der Domäne, der Systemarchitektur und dem Wissen über das System sowie deren Sub-Systeme können Fehler- und Bedrohungsmodi analysiert, detailliert und erweitert werden; somit effektive Massnahmen gegen sicherheitsrelevante Bedrohungen abgeleitet werden.
Um Einschränkungen der FMVEA Methodik bezüglich der Analyse von nur einzelnen Ursachen eines Angriffs, und mehrstufige Angriffe zu unterschlagen, werden oft eine Kombination von FTA (Fault-tree Analysis) und ATA (Attack-tree analysis) zur Unterstützung der FMVEA im Laufe der Entwicklungsphase herangezogen.

Cybersecurity- / Safetysecurity- System

Nach SAE J3061 ist ein Cybersecurity-kritisches System ein System, das zu finanziellen, betrieblichen, Datenschutz- oder Sicherheitsverlusten führen kann, wenn das System durch eine im System vorhandene Sicherheitsanfälligkeit gefährdet wird. Alle sicherheitskritischen Systeme sind Cybersicherheitskritisch, da ein Cyberangriff egal ob direkt oder indirekt auf ein sicherheitskritisches System immer zu potenziellen Sicherheitsverlusten führen kann.
Man unterscheidet Safety-Systemsicherheit und Cyber-Systemsicherheit.
Beispiel für ein Cybersicherheitskritisches System, das nicht sicherheitskritisch ist, ist z.B. ein Unterhaltungssystem, das persönliche Informationen vom Fahrer erhält. Wenn dieses System kompromittiert wird, kann dies z.B. zu finanziellen oder Datenschutzverlust für den Fahrer führen. Es würde jedoch wahrscheinlich keinen physischen Schaden für den Fahrer verursachen. Daher ist das System Cybersicherheitskritisch, aber nicht sicherheitskritisch.
Ein Beispiel für ein System, das sowohl für die Cybersicherheit als auch für die Sicherheit kritisch ist, ist ein Lenkassistenzsystem. Ein Lenkassistenzsystem ist sicherheitskritisch, da es bei einer Fehlfunktion zu möglichen Schäden für die Fahrzeuginsassen führen kann. Das Lenkassistenzsystem ist aber auch Cybersicherheitskritisch, da dies zu potenziellen Schäden für die Fahrzeuginsassen führen kann, wenn das System von einem Angreifer manipuliert wird und ein böswilliges absichtliches Lenkmanöver eingeleitet wird. In der Cybersecurity würde dies als potenzieller Sicherheitsverlust analysiert und ausgewiesen werden.
System Cybersecurity berücksichtigt also potenzielle Bedrohungen durch einen Angreifer, dessen Ziel es ist, Schaden zu verursachen, Chaos anzurichten, finanzielle oder andere Vorteile für sich zu erzielen oder einfach nur um Bekanntheit zu erlangen.

Je höher der Automationsgrad, komplexer, intelligenter technische Systeme werden, desto größer wird die Gefahr und Anfälligkeit dieser Systeme Ziel einer Cyberattacke zu werden und umso wichtiger ist es, diese Systeme (Fahrzeuge/Fahrzeugkomponenten) nach SAE J3061 nachweislich zu entwickeln und konsequenterweise auch zu zertifizieren.

Cybersecurity CULTURE

- Bekenntnis des Managements zum Status von Cybersecurity innerhalb der Organisation;
- die Zielstellung der Organisation bezüglich Cybersecurity;
- die Entwicklung und Management des Sicherheitsplans für Cybersecurity;
- Beschreibung und Einhaltung der Cbersecurity-Prozesse;
- die Bereitstellung und Zuordnung aller benötigten Ressourcen die für die Umsetzung von Cybersecurity benötigt werden;
- die permanente Weiterqualifikation der Personen, die an der Umsetzung von Cybersecurity längs des Lebenszyklus involviert sind;
- die Beschreibung und Zuordnung der benötigten Rollen;
- die Sicherstellung der geforderten Unabhängigkeit derer, die für die Ausführung der Cybersecurity-Prozesse gefordert werden; 
- die Beschreibung und Umsetzung eines effektiven Kommunikationsprozesses;
- die Definition und Umsetzung von Verifikations- & Validierungsprozesse;
- die Beschreibung und Umsetzung eines wirksamen Eskalationsprozesses.

=> Jede nicht definierte oder nicht vollständig umgesetzte Anforderung der SEA J3061stellt nicht nur eine Abweichung zu den Anforderungen der SEA J3061dar, sondern ist damit auch eine potentielle Schwachstelle und dadurch nicht nur ein offener Angriffspunkt, sondern auch ein Hebel für eine mögliche spätere straf-bzw. zivilrechtliche Untersuchung im Schadensfall.

Thread Analysis and Risk Assessment (EVITA-method)

Durch Analyse von Sicherheitsschwachstellen wird versucht, potenzielle Cybersecurity-Sicherheitslücken oder Schwachstellen in der Software und Hardware des zu entwickelnden Systems zu identifizieren und zu klassifizieren, die von einem Angreifer ausgenutzt werden könnte. Sobald die Schwachstellen identifiziert und klassifiziert wurden, können effektive Cybersicherheitsmassnahmen festgelegt werden, um entweder die Schwachstellen zu beseitigen oder die Ausnutzung der Schwachstellen für einen Angreifer erheblich zu erschweren.
Die Schwachstellenanalyse kann auf verschiedenen Ebenen durchgeführt werden, auf der Systemebene, Hardwareebene und Softwareebene. Einige Analysemethoden, wie z. B. Angriffsbäume (Attack Trees), können auf jeweils verschiedenen Ebenen angewendet werden.
Ziel ist es das verbleibende Restrisiko (residual risk) eines potentiellen Angriffs nach Festlegung der Cybersecurity Massnahmen zu bewerten und gegebenenfalls zusätzliche Massnahmen zur Risikominderung vorzunehmen.

Die EVITA-Methode berücksichtigt z.B. vier Cybersicherheitsziele:
• Operational (Betrieb) - um die beabsichtigte Betriebsleistung aller Fahrzeuge sowie der ITS Funktion aufrechtzuerhalten;
• Safety (Sicherheit) - um die funktionale Sicherheit der Fahrzeuginsassen und anderer Verkehrsteilnehmer zu gewährleisten,
• Privacy (Datenschutz) - zum Schutz der Privatsphäre von Fahrzeugführern und des geistigen Eigentums von Fahrzeugherstellern und deren Zulieferern,
• Financial (Finanziell) - um betrügerische Handelsgeschäfte und den Diebstahl von Fahrzeugen zu verhindern.

Die Wahrscheinlichkeit eines erfolgreichen Angriffs in EVITA basiert auf dem Konzept des (Attack Potential) also des Angriffspotenzials, das bei der Bewertung der Cyber-Sicherheit verwendet wird, und berücksichtigt sowohl den Angreifer als auch das System. Bezüglich eines Angreifers berücksichtigt das Angriffspotential eine Reihe von Faktoren wie z.B.
- die Zeit, die ein Angreifer als Vorbereitung benötigt, um zu festzulegen, wie ein System angreifbar ist und der Angriff auch erfolgreich ausgeführt werden kann.
- das vom Angreifer benötigte Fachwissen,
- die Kenntnis des erforderlichen Systems und
- das dazu benötigte technische Equipment usw.

Das Angriffspotential reicht von “Basic”, was bedeutet, dass das Feature leicht angegriffen werden kann, bis “Beyond High”, was bedeutet, dass das Feature extrem schwer angreifbar ist. Basierend auf dem ermittelten Angriffspotential wird dann eine Angriffswahrscheinlichkeit zugewiesen.

Über die ermittelte Angriffswahrscheinlichkeit (AP) und den zu ermittelnden Risiken (Ri) der jeweiligen Cybersecurity Goals (CG’s) für Severity’s: Sp, Sf und So, wobei Sp den Schweregrad in Bezug auf Datenschutzbedrohungen darstellt, Sf den Schweregrad in Bezug auf finanzielle Bedrohungen darstellt und So den Schweregrad in Bezug auf betriebliche Bedrohungen darstellt. Der Schnittpunkt in der Matrix aus Schweregrad (Si) und Angriffswahrscheinlichkeit (AP) bestimmt das Risiko R0 - R6 für die potenzielle Bedrohung, die bewertet wird, wobei R0 das niedrigste Risiko und R6 das höchste Risiko darstellt.

Durch Berücksichtigung der jeweiligen Kontollierbarkeit (Controllability) sprich Einflussnahme oder Reaktion bezüglich des Risikos jeder ermittelten potentiellen Bedrohung kann dann die Kombinierte Risikowahrscheinlichkeit ermittelt werden. Je höher das Risiko für eine Bedrohung ist, desto mehr muss getan werden um das Restrisiko zu reduzieren und desto stringenter muß bei der Umsetzung der Prozesse vorgegangen werden.