Autor: Stefan Kriso, Robert Bosch GmbH Mit der zunehmenden Vernetzung von Fahrzeugen mit ihrer Umgebung gewinnt das Thema Automotive Security derzeit stark an Bedeutung \u2013 angefangen von der „einfachen“ Anbindung \u00fcber ein im Fahrzeug befindliches Smartphone mit Internetzugang bis hin zu einer zuk\u00fcnftig m\u00f6glicherweise dauerhaften Datenanbindung des Fahrzeugs f\u00fcr das automatisierte Fahren. Wo ein Datenzugang nach au\u00dfen vorhanden ist, werden auch fr\u00fcher oder sp\u00e4ter Hacker versuchen, sich Zugang zum Fahrzeug zu verschaffen, wie ein aktuelles Beispiel eindrucksvoll zeigt\u00a0<\/strong>[1]<\/strong>: Unabh\u00e4ngig von der dargestellten Security-Problematik und der tats\u00e4chlichen Praxisrelevanz gelingt es hier, Fahrzeug-Funktionen auszul\u00f6sen, die als Safety-relevant einzustufen sind, z.B. Motor-aus (Liegenbleiber), Selbstlenker oder Bremsenausfall. Prinzipiell besteht also die Gefahr, dass durch einen Security-Angriff auf ein Fahrzeug \u2013 sei es unbeabsichtigt oder gewollt \u2013 Safety-relevante Fehlfunktionen ausgel\u00f6st werden. In diesem Paper wird der Zusammenhang zwischen Automotive Security und Functional Safety n\u00e4her beleuchtet. Dabei bleiben die \u00fcbrigen zu sch\u00fctzenden Assets der Security, wie zum Beispiel Datenschutz, bewusst au\u00dfen vor. Zun\u00e4chst betrachten wir die Themen Produktsicherheit (Product Safety) und Funktionssicherheit (Functional Safety). Ausgangspunkt f\u00fcr die Sicherheit, die ein Produkt bieten muss, um im Markt bereitgestellt werden zu d\u00fcrfen, bildet in Deutschland das Produktsicherheitsgesetz [2]:<\/p>\n „Ein Produkt darf [\u2026] nur auf dem Markt bereitgestellt werden, wenn es bei bestimmungsgem\u00e4\u00dfer oder vorhersehbarer Verwendung die Sicherheit und Gesundheit von Personen nicht gef\u00e4hrdet.“<\/em>\u00a0[\u00a73(2) ProdSG]<\/p>\n Der Begriff Sicherheit ist\u00a0 hier im Sinne von Safety zu verstehen. Doch was ist „Sicherheit“ \u00fcberhaupt? Eine Definition dieses Begriffs findet man zum Beispiel in [3]:<\/p>\n „Safety = freedom from unacceptable risk“<\/em>\u00a0bzw.\u00a0 „Sicherheit = Freiheit von unvertretbaren Risiken“<\/em><\/p>\n Sicherheit ist also nicht die Freiheit von\u00a0allen\u00a0Risiken \u2013 prinzipiell gibt es in technischer Hinsicht akzeptable Restrisiken. Die Frage, die sich stellt, ist, ob man als Individuum bereit ist, das verbleibende Restrisiko zu tragen oder nicht bzw. ob die Gesellschaft ein Restrisiko als zumutbar ansieht oder nicht.<\/p>\n Schauen wir uns den Begriff des Risikos n\u00e4her an. Eine m\u00f6gliche Definition finden wir in [3]:<\/p>\n „Risiko = Kombination aus Eintretenswahrscheinlichkeit eines Schadens und seiner Auswirkungsschwere<\/em>“<\/p>\n Die Eintretenswahrscheinlichkeit des Schadens kann hierbei gebildet werden aus der Kombination der Wahrscheinlichkeit der gef\u00e4hrdenden Situation, der Auftretenswahrscheinlichkeit des gef\u00e4hrdenden Ereignisses sowie der M\u00f6glichkeit, die Gef\u00e4hrdung zu vermeiden bzw. zu mindern (Abbildung 1,\u00a0PDF<\/a>).<\/p>\n Eine Reduktion des Risikos ist notwendig, wenn das verbleibende Restrisiko oberhalb eines zumutbaren Risikos liegt. Diese Vorgehensweise ist ebenfalls in [3] beschrieben, siehe Abbildung 2 (siehe\u00a0PDF<\/a>): In einer Gef\u00e4hrdungsanalyse und Risikobewertung werden die Gef\u00e4hrdungen ermittelt und die daraus resultierenden Risiken bewertet. Stellt sich nach dieser ersten Gef\u00e4hrdungsanalyse und Risikobewertung heraus, dass dieses „initiale“ Risiko oberhalb des zumutbaren Restrisikos liegt, so sind risikoreduzierende Ma\u00dfnahmen notwendig, um das Restrisiko mindestens auf ein zumutbares bzw. unvermeidbares Niveau zu reduzieren.<\/p>\n Hierbei ist neben der beabsichtigten Verwendung auch die vern\u00fcnftigerweise vorhersehbare Fehlanwendung zu ber\u00fccksichtigen. Dies deckt sich mit \u00a73(2) ProdSG, wo dies als „beabsichtigte und vorhersehbare Verwendung“ bezeichnet wird, siehe oben. Es wird jedoch nicht in jedem Fall erwartet, dass man bei seinen Betrachtungen auch Missbrauch mit einbezieht \u2013 wobei es zugegebenerma\u00dfen schwer f\u00e4llt bis unm\u00f6glich erscheint, hier eine objektive oder gar zeitlich unver\u00e4nderliche Grenze festzulegen.<\/p>\n Ein Beispiel aus dem Automobilbereich mag dies verdeutlichen: Beabsichtigte Verwendung eines Stra\u00dfenfahrzeugs sei es, dass man damit innerorts nicht schneller als 50 km\/h f\u00e4hrt (gesetzliche Vorgabe). Bei der Betrachtung der Gef\u00e4hrdungen und Risiken ist im Sinne einer vorhersehbaren Verwendung davon auszugehen, dass diese Geschwindigkeitsgrenze nicht immer strikt eingehalten und dass beispielsweise auch mit 60 km\/h gefahren wird. Es ist aber nicht davon auszugehen, dass regelm\u00e4\u00dfig 250 km\/h schnell gefahren wird, da dies ein erhebliches kriminelles Potenzial voraussetzt, das dem durchschnittlichen Benutzer nicht unterstellt werden braucht. Wo allerdings die Grenze zwischen „vorhersehbare Verwendung“ und „Missbrauch“ genau liegt, l\u00e4sst sich nicht zweifelsfrei und objektiv angeben.<\/p>\n Diese grundlegenden Definitionen f\u00fcr „Sicherheit“ und „Risiko“ lassen sich auch auf andere Bereiche des t\u00e4glichen Lebens \u00fcbertragen, z.B. auf die Sicherheit \/ das Risiko von Finanzanlageprodukten. Im Bereich der Safety wie wir es hier betrachten, wenn es also um die Sicherheit von Leib und Leben von Personen geht, dienen diese Definitionen als Grundlage entsprechender Safety-Normen. Grundlegend finden wir dies wieder in der IEC 61508 [4], der \u00fcbergeordneten „Mutternorm“ vieler abgeleiteter, branchenspezifischer Normen zur Funktionalen Sicherheit von elektrischen\/elektronischen (E\/E-) Systemen. F\u00fcr Stra\u00dfenfahrzeuge stellt die ISO 26262 die entsprechende branchenspezifische Ableitung der IEC 61508 dar und \u00fcbernimmt den Safety- bzw. Risikobegriff entsprechend [5]:<\/p>\n „Safety = Absence of unreasonable risk<\/em>“<\/p>\n „Risk = Combination of the probability of occurrence of harm and the severity of that harm<\/em>“<\/p>\n „Unreasonable risk = Risk judged to be unacceptable in a certain context according to valid societal moral concepts<\/em>“<\/p>\n „Functional safety = Absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E\/E systems<\/em>“<\/p>\n Im Folgenden sei dargestellt, wie sich die oben eingef\u00fchrten Begrifflichkeiten weiter auf die ISO 26262 abbilden:<\/p>\n Bei der Gef\u00e4hrdungsanalyse und Risikobewertung wird das „initiale Risiko“, d.h. das Risiko ohne Ber\u00fccksichtigung von risikoreduzierenden Ma\u00dfnahmen, mit Hilfe von drei Einflussfaktoren bestimmt:<\/p>\n Aus diesen drei Parametern ergibt sich der sogenannte Automotive Safety Integrity Level (ASIL) gem\u00e4\u00df Abbildung 3 (siehe\u00a0PDF<\/a>).<\/p>\n ASIL D stellt hierbei die h\u00f6chste Stufe dar, ASIL A die geringste. Je h\u00f6her die ASIL-Einstufung, umso h\u00f6her ist das initiale Risiko und umso mehr risikoreduzierende Ma\u00dfnahmen sind notwendig. Die Einstufung „QM“ dr\u00fcckt aus, dass die Anwendung eines Standard-Qualit\u00e4tsmanagementsystems, z.B. nach ISO\/TS 16949, ausreichend ist zur Risikoreduktion (Abbildung 4,\u00a0PDF<\/a>).<\/p>\n Dar\u00fcber hinaus sind aus Sicht der ISO 26262 keinerlei Ma\u00dfnahmen notwendig (also nicht einmal die Anwendung eines QM-Systems), wenn die Wahrscheinlichkeit der gef\u00e4hrdenden Situation extrem unwahrscheinlich ist (Exposure E0 = es passiert so gut wie nie) oder wenn es keinen Handlungsbedarf zur Beherrschung der Fehlfunktion gibt (Controllability C0 = es ist lediglich st\u00f6rend) oder wenn es zu keiner Gef\u00e4hrdung f\u00fcr Leib und Leben kommt (Severity S0 = reiner Blechschaden)[1].<\/p>\n Die Abbildung 5 (siehe\u00a0PDF<\/a>) veranschaulicht den Zusammenhang zwischen der ISO 26262 [5] und der allgemeinen Begrifflichkeit \/ Vorgehensweise nach [3].<\/p>\n Das verbleibende Risiko (in Abbildung 5 als „Risk“ bezeichnet) ist somit eine Kombination aus dem initialen Risiko und der Wahrscheinlichkeit des tats\u00e4chlichen Auftretens der Gef\u00e4hrdung (im Sinne einer Ausfallrate). Ist dieses verbleibende Risiko auf ein Niveau unterhalb eines (nicht quantifizierten!) zumutbaren Restrisikos zu limitieren, so hei\u00dft das, dass je h\u00f6her das initiale Risiko ist, umso geringer muss die Wahrscheinlichkeit des tats\u00e4chlichen Auftretens der Gef\u00e4hrdung sein, z.B. die Ausfallrate des Systems.<\/p>\n Die „Feindbilder“, die die ISO 26262 f\u00fcr die Funktionale Sicherheit von Stra\u00dfenfahrzeugen adressiert, sind systematische Fehler und zuf\u00e4llige Hardware-Fehler. Zur Vermeidung systematischer Fehler stellt sie Anforderungen an den Entwicklungsprozess (Safety Life Cycle), zur Beherrschung zuf\u00e4lliger Hardware-Fehler und verbleibender systematischer Fehler (deren Vermeidung grunds\u00e4tzlich nicht vollst\u00e4ndig sichergestellt werden kann) stellt sie Anforderungen an die technische Umsetzung im Produkt (z.B. Redundanzen, Monitoring, Diagnosen).<\/p>\n Verlassen wir nun die Feindbilder der funktionalen Sicherheit, n\u00e4mlich die systematischen Fehler und zuf\u00e4lligen Hardware-Fehler, und schauen uns ein weiteres Feindbild an: den bewussten Angriff auf das Fahrzeug bzw. seine E\/E-Systeme. Zun\u00e4chst gilt festzustellen, dass wir uns mit diesem Feindbild au\u00dferhalb des Anwendungsbereichs der ISO 26262 befinden. Trotzdem kann auch dieses Feindbild zu einem Safety-kritischen Verhalten f\u00fchren und daher prinzipiell Safety-relevant sein, wie in [1] eindrucksvoll gezeigt wird. Die Frage, die es nun aus Safety-Sicht zu beantworten gilt, ist: Sind f\u00fcr einen gegebenen Angriff risikoreduzierende Ma\u00dfnahmen notwendig zur Sicherstellung einer ausreichenden Produktsicherheit (i.S.v. Safety)?<\/p>\n Auch hier empfiehlt sich die oben und in [3] dargestellte zweistufige Vorgehensweise:<\/p>\n Im Schritt 1 stellt man sich letztendlich die Frage, wie wahrscheinlich ein Angriff auf das Fahrzeug ist. Ist dieser hochwahrscheinlich, weil zum Bespiel das Angriffsziel sehr attraktiv ist, und ergibt sich hieraus ein initiales Risiko f\u00fcr eine durch den Angriff provozierte Fehlfunktion, das h\u00f6her liegt als das zumutbare Risiko, so sind zur Sicherstellung der Product Safety risikoreduzierende Ma\u00dfnahmen notwendig. Hervorzuheben ist, dass die Einsch\u00e4tzung der Angriffswahrscheinlichkeit eine Experteneinsch\u00e4tzung mit sehr hohen Unsicherheiten darstellt, da Parameter wie Angreiferf\u00e4higkeiten, Angreifermotivation sowie die das betrachtende System umgebenden Komponenten starken Einfluss auf das Ergebnis haben. Insbesondere kann sich die Einsch\u00e4tzung \u00fcber die Wahrscheinlichkeit eines Angriffs im Laufe der Zeit stark \u00e4ndern, z.B. durch Hinzuf\u00fcgen einer bei der urspr\u00fcnglichen Betrachtung nicht vorhandenen Vernetzungsfunktion oder durch steigende Angreiferf\u00e4higkeiten.<\/p>\n Ma\u00dfnahmen zur Sicherstellung der Product Safety m\u00fcssen das jeweilige Feindbild adressieren, d.h. der bewusste Angriff als Feindbild f\u00e4llt in den Bereich der Automotive Security, und entsprechende Ma\u00dfnahmen sind prinzipiell zun\u00e4chst au\u00dferhalb der Funktionalen Sicherheit \/ ISO 26262 zu suchen. Bei n\u00e4herer Betrachtung stellt man jedoch fest, dass die beiden Themen nicht so isoliert voneinander zu betrachten sind wie man zun\u00e4chst annehmen k\u00f6nnte.<\/p>\n Bei der Betrachtung der Vorgehensweisen stellt man fest, dass sie sich sehr \u00e4hnlich sehen (Abbildung 6,\u00a0PDF<\/a>).<\/p>\n Auf der linken Seite des V-Modells finden \u00e4hnliche Aktivit\u00e4ten statt, jedoch mit unterschiedlicher inhaltlicher Auspr\u00e4gung. Zu ihrer Durchf\u00fchrung sind unterschiedliche Expertisen notwendig, es ist nicht unbedingt sinnvoll, Security-Aufgaben bei Safety-Experten anzusiedeln. Wichtig ist aber, Synchronisationspunkte einzuf\u00fchren, bei denen sich die Safety- und Security-Experten miteinander abgleichen, um Widerspr\u00fcche aufzul\u00f6sen, um sich konterkarierende Ma\u00dfnahmen im Produkt zu vermeiden und um m\u00f6gliche Synergien zu heben.<\/p>\n Da auf der rechten Seite des V-Modells idealerweise gegen Anforderungen getestet wird, sollte hier die Quelle der Anforderung (Safety oder Security) keine (gro\u00dfe) Rolle spielen. Erst bei der abschlie\u00dfenden Validation findet wieder eine Auftrennung statt, Safety Validation und Security Validation erfordern deutlich andere Vorgehensweisen und Ma\u00dfnahmen.<\/p>\n Bei der Definition oder Einf\u00fchrung eines „Security Engineering Process“ sollte darauf geachtet werden, dass die Prozesse und Vorgehensweise im Bereich der Funktionalen Sicherheit bereits implementiert sind und sich am aktuellen Stand der Technik orientieren. Vorgehensweisen bzw. Ma\u00dfnahmen der Security sollten sich hier m\u00f6glichst nahtlos einf\u00fcgen und dem Bestehenden nicht widersprechen, um eine effiziente Umsetzung zu erm\u00f6glichen.<\/p>\n<\/div>\n Auf der technischen Ebene gilt es zun\u00e4chst zu vermeiden, dass sich Safety- und Security-Konzepte gegenseitig negativ beeinflussen. Dies sei an einem (stark vereinfachten) Beispiel erl\u00e4utert:<\/p>\n Safety-kritischste Fehlfunktion eines Fahrerairbags stellt die ungewollte Ausl\u00f6sung dar, gem\u00e4\u00df ISO 26262 ist diese Fehlfunktion mit der h\u00f6chsten Einstufung ASIL D versehen. Die Vermeidung dieser Fehlfunktion hat h\u00f6chste Priorit\u00e4t, insbesondere sollte sichergestellt sein, dass es auch im Falle eines Hackerangriffs \u2013 sei es gewollt oder unbeabsichtigt \u2013 \u00a0nicht zu dieser Fehlfunktion kommt (Safety braucht Security). Andererseits darf aber ein „zu stringenter“ Security-Mechanismus nicht dazu f\u00fchren, dass die Airbagausl\u00f6sung im Falle eines Unfalls verz\u00f6gert oder gar verhindert wird, da damit die intendierte Funktion des Airbags, der Schutz der Insassen im Falle eines Unfalls, gemindert wird (Security darf Safety nicht beeintr\u00e4chtigen).<\/p>\n Neben der Herausforderung, Safety und Security gemeinsam und widerspruchsfrei zu implementieren, gibt es auf der technischen Ebene auch m\u00f6gliche Synergien. Als Beispiel seien hier die Botschaftsabsicherungsma\u00dfnahmen CRC (Cyclic Redundancy Check) und MAC (Message Authentication Code) genannt (Abbildung 7,\u00a0PDF<\/a>). Unter bestimmten Voraussetzungen ist es m\u00f6glich, die Botschaftsabsicherung durch den CRC durch eine Absicherung durch den MAC zu ersetzen, so dass dieser sowohl der Safety- als auch der Security-Absicherung n\u00fctzt [7], [8].<\/p>\n Dar\u00fcber hinaus gibt es noch weitere m\u00f6gliche Synergien sowohl auf technischer Ebene als auch auf Ebene der Prozesse, die eine enge Zusammenarbeit der Safety- und Security-Experten sinnvoll machen.<\/p>\n Wie bei der Safety gibt es auch bei der Security keine absolute Sicherheit. Somit kann jede individuelle L\u00f6sung im Nachhinein dem Vorwurf ausgesetzt sein, nicht ausreichend sicher zu sein. Ein Schritt in die richtige Richtung w\u00e4re eine branchenweite Abstimmung \u00fcber die Vorgehensweisen zur Erreichung des Mindeststands der Technik. Im Bereich der Safety gibt es hierf\u00fcr zahlreiche Normen, speziell f\u00fcr die Funktionale Sicherheit von Stra\u00dfenfahrzeugen beschreibt die im November 2011 ver\u00f6ffentlichte und derzeit in \u00dcberarbeitung befindliche ISO 26262, welche Anforderungen an die Entwicklung funktional sicherer E\/E-Systeme im Automobil gestellt werden. Spezielle Ber\u00fccksichtigung finden hier die Spezifika der Automobildom\u00e4ne, zum Beispiel die Vorgehensweisen bei der verteilten Entwicklung \u00fcber mehrere Zulieferergrenzen hinweg. Diese Norm stellt damit die gemeinsame Sicht der Automobilindustrie auf die Funktionale Sicherheit dar, die Anwendung ist eine notwendige aber nicht hinreichende Voraussetzung zur Erreichung des Stands der Technik.<\/p>\n Im Bereich der Automotive Security fehlt es momentan noch einem solchen Standard. Als erste Aktivit\u00e4t in dieser Richtung entsteht zwar derzeit eine Guideline (SAE J3061, [9]), diese beschreibt aber in erster Linie m\u00f6gliche Ma\u00dfnahmen („was ist zu tun“), ohne normativen Anspruch und ohne sie in einen entsprechenden Lebenszykluskontext zu setzen („wann ist wie viel zu tun“). Hier w\u00e4re eine der ISO 26262 vergleichbare Norm w\u00fcnschenswert, die Vorgehensweisen standardisiert, wie bei der Entwicklung von sicheren (im Sinne von „secure“) Systemen in Stra\u00dfenfahrzeugen vorzugehen ist, zum Beispiel wie eine Klassifikation der notwendigen Risikoreduktion durchgef\u00fchrt werden kann.<\/p>\n Dar\u00fcber hinaus fokussiert die SAE Guideline zu sehr auf die Safety als durch Security-Ma\u00dfnahmen zu sch\u00fctzendes Gut und ber\u00fccksichtigt die anderen „Assets“ zu wenig, z.B. Privacy oder Confidentiality. Dies sollte bei einer zuk\u00fcnftigen Standardisierung st\u00e4rkere Ber\u00fccksichtigung finden. Eine solche, mit der ISO 26262 vergleichbaren Norm, k\u00f6nnte auch im Bereich der Automotive Security dazu beigetragen werden, eine gemeinsame Sicht der Automobilbranche auf das Thema zu formulieren und damit die Entwicklung von sicheren („secure“) Systemen auch \u00fcber Zulieferergrenzen hinweg zu verbessern.<\/p>\n Durch die zunehmende Vernetzung von Stra\u00dfenfahrzeugen und die damit neu entstehenden Zugangsm\u00f6glichkeiten von au\u00dfen gewinnt das Thema Automotive Security immer st\u00e4rkere Bedeutung. Neben anderen zu sch\u00fctzendes Assets wird die (Functional) Safety zuk\u00fcnftig st\u00e4rker in den Fokus r\u00fccken, da heute schon \u2013 wenn momentan auch noch haupts\u00e4chlich auf akademischem Niveau \u2013 Angriffe demonstriert werden k\u00f6nnen, die safetykritisches Verhalten ausl\u00f6sen. Aus Sicht der Produktsicherheit sind Security-Ma\u00dfnahmen dann notwendig, wenn die Wahrscheinlichkeit f\u00fcr einen Angriff zu einem Safety-Risiko f\u00fchrt, so dass das Produkt nicht mehr die erwartbare Sicherheit bietet. Synergien zwischen Functional Safety und Automotive Security sind sowohl auf Prozessebene als auch bei der technischen Umsetzung m\u00f6glich, so dass eine Abstimmung zwischen den beiden Disziplinen notwendig und sinnvoll erscheint. Eine der ISO 26262 vergleichbare Norm zur Automotive Security kann das gemeinsame Verst\u00e4ndnis in der Automobilbranche f\u00f6rdern und dazu beitragen, sichere (im Sinne von „secure“) Systeme auch \u00fcber Zulieferergrenzen hinweg zu entwickeln. Einerseits ist es nicht sinnvoll, das Thema Automotive Security innerhalb der ISO 26262 zu standardisieren, andererseits muss aber darauf geachtet werden, dass eine solche Norm nicht zur ISO 26262 im Widerspruch steht, da ansonsten eine effiziente Implementierung in den Unternehmen nicht m\u00f6glich sein wird.<\/p>\n [1] „Hacker remotely crashes Jeep“, The Telegraph<\/a>\u00a0(abgerufen am 03.08.2015)<\/p>\n [2] Gesetz \u00fcber die Bereitstellung von Produkten auf dem Markt (Produktsicherheitsgesetz \u2013 ProdSG), 08.11.11<\/p>\n [3]\u00a0 ISO\/IEC Guide 51:2014: „Safety aspects \u2013 Guidelines for their inclusion in standards“<\/p>\n [4]\u00a0 IEC 61508:2010: „Functional safety of electrical\/electronic\/programmable electronic safety-related systems“<\/p>\n [5]\u00a0 ISO 26262:2011: „Road vehicles \u2013 Functional safety“<\/p>\n [6]\u00a0 M. Klauda, S. Kriso: „Sicherheit als Treiber der zuk\u00fcnftigen Systementwicklung“, ESE Management Summit 2014, W\u00fcrzburg, 10.07.2014<\/p>\n [7]\u00a0 B. Glas et al.: „Automotive Safety and Security Integration Challenges“, In: Automotive – Safety & Security 2015, Lecture Notes in Informatics, Volume P-240, 2015, ISBN 978-3-88579-634-3.<\/p>\n [8]\u00a0 B. Glas, C. Gebauer: „Safety & Security: Synergies and Challenges of Integrity-protected Bus Communication“ (to be published)<\/p>\n [9]\u00a0 „SAE committee busy developing standards to confront the cybersecurity threat<\/a>„, \u00a0SAE, (abgerufen am 11.08.2015)<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n<\/div>\n [1] Anmerkung: In der Praxis wird man jedoch \u2013 aus anderen Gr\u00fcnden au\u00dferhalb der Funktionalen Sicherheit \/ ISO 26262 \u2013 dennoch auch in diesem F\u00e4llen ein Standard-QM-System zur Anwendung bringen.<\/p>\n<\/div>\n<\/div>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Hier\u00a0<\/a><\/strong>finden Sie au\u00dferdem Schulungen zum Thema Software- und Vertragsrecht.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Security steht\u00a0hier\u00a0<\/a><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2015<\/h3>\n
\n<\/strong><\/p>\nProduct Safety, Functional Safety<\/h2>\n
\n
Automotive Security aus Safety-Sicht<\/h2>\n
\n
Zusammenspiel zwischen Automotive Security und Funktionaler Sicherheit<\/h2>\n
Standardisierung<\/h2>\n
Zusammenfassung<\/h2>\n
Referenzen<\/h2>\n
\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n