Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
25 2021 Elektronik 23 EmbEddEd TEchnology Kraftfahrzeug übernehmen kann dann kann er es auch in den Graben lenken Aber wenn ein System nicht safe ist kann es dann unter Umständen trotz dem secure sein? Man könnte sich ein System vorstellen dessen Software keine angreif baren Schnittstellen hat sondern beispielsweise nur einen manuellen Bedienknopf weswegen die interne Software nicht manipulierbar ist Die Argumentation greift aber zu kurz denn eines der Ziele von Security kann verfehlt werden nämlich das Ziel Verfügbarkeit Wenn das System nicht safe ist kann seine Software abstürzen etwa bei zu schnell aufeinanderfolgen der Betätigung des Bedienknopfs und daraufhin würde das System seinen Dienst einstellen Richtlinien für Security Es gibt Standards und Richtlinien deren Vorgaben darauf abzielen durch ihre Einhaltung Software secure zu machen ➔ ➔ ISO IEC TS 17961 2013 Dieser Stan dard [3] trägt im Untertitel die Bezeich nung »Csecure« und enthält 46 Vor gaben Im Jahr 2016 wurde im Technical Corrigendum 1 die Regel 5 21 genauer formuliert dies ist in der Ausgabe von 2018 Edition 2 des Standards enthalten ➔ ➔ SEI CERT C Coding Standard Dieser Standard stellt Vorgaben für das sichere Programmieren – im Sinne von secure – in der Sprache Czur Verfügung Aller dings ist der vom Computer Emergency Response Team CERT [4] des Software Engineering Institute SEI der Carnegie Mellon University in Pittsburgh Penn sylvania herausgegebene »Standard« kein eigentlicher Standard denn er ist nicht von Standardisierungsgre mien wie ISO oder IEC herausgegeben Zudem entwickelt sich dieser Stan dard im Internet weiter und ist sofern ein bewegliches Ziel Moving Target etwa für Hersteller statischer Analyse tools die ihn unterstützen wollen Im Jahr 2016 wurde der aktuelle Stand in einem Dokument fixiert dieses Doku ment enthält 99 Vorgaben Vergleich mit Richtlinien für Safety Die Vorgaben der Motor Industry Soft ware Reliability Association MISRA ursprünglich für den Automobilbe reich gedacht werden wohl am häu figsten mit Safety assoziiert So werden die MISRARichtlinien auch von Stan dards zur Entwicklung sicherheitskriti scher Software erwähnt etwa in Teil 6 Abschnitt 5 4 3 von ISO 26262 2018 [5] Die aktuelle Richtlinie MISRA C 2012 [6] enthält ursprünglich 159 Vorgaben 16 Direktiven und 143 Regeln Im Jahr 2016 kamen durch Ergänzung Amendment 1 [7] weitere 14 Vorgaben hinzu 1 Direktive + 13 Regeln Diese 14 zusätzlichen Vorgaben adressieren speziell Security Im Januar 2018 wurden zwei Zusätze Addenda veröffentlicht Addendum 2 und 3 In Addendum 2 [8] wird die Abdeckung von MISRA C 2012 mit Amendment 1 zu ISO IEC TS 17961 2013 Csecure diskutiert mit dem Ergeb nis dass alle 46 Vorgaben aus Csecure durch MISRAVorgaben abgedeckt sind In Addendum 3 [9] wird die Abde ckung von MISRA C 2012 mit Amend ment 1 zum SEI CERT C Coding Stan dard Edition von 2016 diskutiert mit dem Ergebnis dass von den 99 Vor gaben 80 mehr oder weniger gut abge deckt sind d h manche nur partiell 15 Vorgaben werden als »outofscope« betrachtet weil sie C11 betreffen und MISRA C 2012 zu der Zeit nur für C90 und C99 vorhanden war vier Vorgaben aus CERT werden durch MISRA nicht abgedeckt Insgesamt ergibt sich eine starke Überdeckung zwischen den Safety Vorgaben aus MISRA und den Secu rityVorgaben aus Csecure und CERT Die Frage ob gewisse Vorgaben eher Safety oder eher Security zuzuordnen sind wird anhand der untenstehenden Beispiele beantwortet Statische Analysewerkzeuge Ganz offensichtlich sparen statische Analysewerkzeuge großen manuellen Aufwand ein wenn es darum geht Quellcode auf die Einhaltung von Codierrichtlinien zu überprüfen Das gilt für Vorgaben sowohl zur Safety als auch zur Security Allerdings muss man bedenken dass Vorgaben aus Codier richtlinien entweder entscheidbar oder unentscheidbar sind In MISRA und C Secure ist dies für jede Regel angegeben Entscheidbare Vorgaben sind solche bei denen man aufgrund des Quellcodes sicher sagen kann ob Bild 1 Der Unterschied zwischen Safety und Security Bild Hitex Bild 2 Ist Pufferüberlauf ein Security-Problem? Bild Hitex