Die Notwendigkeit von Security Schutzmaßnahmen im Office-IT-Umfeld ist uns allen schon lange in Fleisch und Blut übergegangen. Firewall, Virenscanner, Verschlüsselung von Daten: Office-IT ist ohne diese Aspekte nicht mehr denkbar.
Relativ neu dagegen ist, dass Thema Security für Embedded Systeme. Auch diese Systeme sind heute schon schutzbedürftig, hinsichtlich möglicher bösartiger Angriffe. Lange Zeit gab es schlicht keine technischen Möglichkeiten, solche Systeme anzugreifen. Ob Flugzeug, Auto oder Zug, all diese Systeme waren, wenn überhaupt nur individuell angreifbar. Dazu bedurfte es aber einer konkreten Manipulation am individuellen System. Seit geraumer Zeit gehen aber diese Systeme immer mehr „online“. Das bedeutet, es wird z.B. möglich ganze Fahrzeugflotten online zu manipulieren, was wiederum die Attraktivität für mögliche Angreifer erhöht.

Folgende Fragen stellen sich damit unmittelbar:

• Können Security Schutzmaßnahmen aus der Office-IT- auf die Embedded Welt übertragen werden?
• Gibt es spezifische Fragestellungen zur Security die nur für Embedded Systeme relevant sind?
• Gibt es anwendbare Normen?

Der nachfolgende Blog gibt ein paar Antworten.

Können Security Schutzmaßnahmen von der Office-IT- auf die Embedded Welt übertragen werden?

Die Frage lässt sich mit einem klaren „Jein“ beantworten. Passwörter werden heute schon auch in Embedded Anwendungen eingesetzt. Ein Virenscanner kann aber in der Regel aus Performance Gründen auf einer Embedded Anwendung nicht eingesetzt werden.

Wiederum alle Maßnahmen zur Verhinderung von Social Engineering sind sowohl für Embedded als auch für Office IT anwendbar.

Codier Richtlinien für SQL Datenbanken Programmierung für Web-Applikationen sind allgemein bekannt. Sie sind entstanden als Reaktion auf Hacker-Angriffe. Codierrichtlinien für C und C++ mit dem Ziel die Security einer Embedded Anwendung zu erhöhen, sind in einer ersten Version (MISRA) auch vorhanden. Es gibt aber bisher kaum Erfahrungen aus der Praxis über Ihre tatsächliche Wirksamkeit. Folgende, mögliche Angriffsszenarien, zeigen aber auf, dass Codierrichtlinien zur Erreichung von Security Zielen sehr sinnvoll sind:

• Unbehandelte Exceptions – Übernahme der Execution.
• Manipulation von (Stack-) Pointer – Sprünge in Schadcode.
• Undefinierte Reaktionen auf Fehlerzustände – Substitution von Code.
• Unzureichende Eingabevalidierungen – Ausführbare Systemcodes.
• Überschreitung von Begrenzungen – z.B. DDOS Attacken.
• Veraltete Betriebssystemkomponenten oder Bibliotheken – Angriffe über bekannte Sicherheits-Lücken.
• „Quick and dirty“ Programmierstyle.

Gibt es spezifische Fragestellungen zur Security die nur für Embedded Systeme relevant sind?

Diese Frage muss mit einem klaren „Ja“ beantwortet werden. Die immer wieder sehr unterschiedliche Hardware und die damit nicht standardisierten Schnittstellen zur Software werfen eine Vielzahl von Fragen aus Sicht der Security auf. Die Antworten hierauf findet man aber nicht bei der Office IT. Die Tatsache das der CAN-Bus nie entwickelt wurde mit dem Ziel Security eines Embedded Systems sicherzustellen ist so eine Problemstellung.

Ein weiteres Beispiel sind die doch recht unterschiedlichen Betriebssysteme die im Embedded Bereich verwendet werden. Bisher berücksichtigt kaum ein Entwicklungsprozess, die Security Aspekte die sich daraus ergeben. Die Verhinderung von sogenannten Back-Door Angriffen ist sicher ein Szenario, das zeigt, das hier Handlungsbedarf besteht.

Nicht zuletzt ist aber auch die Sicherstellung von Security für Safety relevante Systeme eine komplett neue Herausforderung mit ganz neuen Fragestellungen. Für solche Systeme ist es bisher undenkbar, dass regelmäßige und vor allem schnelle und flexible Updates der Software zum Schließen von Security Lücken durchgeführt werden, da dies in den Meisten Fällen den Zielen zur Erreichung von Safety widersprechen. In der Office IT ist aber genau diese Maßnahme sehr effektiv im Bezug auf die Erreichung der Security Ziele.

Für Safety relevante Systeme ist auch undenkbar, dass Sie systematisch, gezielt und kontinuierlich angegriffen werden, da im Falle der Entdeckung von Security Lücken, die Safety nicht mehr gewährleistet wäre.

Diese Beispiele zeigen, dass hier ganz neue Ansätze gefordert sein werden.

Gibt anwendbare Normen?

Ja die gibt es. Die IEC62443 ist eine Norm, die sich mit den spezifischen Security Fragen für Embedded Systeme beschäftigt. Es ist eine Norm, die auf die Bedürfnisse der Industrieautomatisierung zugeschnitten ist und auch dort ihre Anwendung finden wird.

Der Teil 1 der IEC 62443 definiert grundlegende Begriffe und beschreibt übergreifende, generelle Themen. In Teil 2 beschäftigt sich die IEC 62443 mit den Prozessen und im Teil 3 und 4 mit notwendigen Technologien.

Anmerkung: IACS = Industrial Automation and Control Systems

Die Automobilbranche kennt die SAE J 3061 welche in eine ISO 27xxx Norm überführt werden wird.
Der BSI-Grundschutz sowie die Normen der ISO27001-xx Serie sind dagegen für Embedded Systeme nur sehr eingeschränkt anwendbar.

Fazit

Die Embedded Community ist gut beraten zu schauen welche langjährigen Erfahrungen aus der Office IT Welt bezogen auf die Security auch für die Embedded Welt sinnvoll und anwendbar sind.

Darüber hinaus ist es aber geboten, dass neue Lösungen zur Erreichung einer angemessenen Security für Embedded Systeme erarbeitet werden. Hier steht die Entwicklung noch sehr am Anfang. Autonomes Fahren und Industrie 4.0 sind aber Trends anhand derer man die Defizite im Bereich der Security deutlich erkennen kann.

Im Normenbereich tut sich was auch im Bezug auf Security. Wirkliche Lösungen kann man aber hier nur für die Definition und Vereinheitlichung von Prozessen und Methoden erwarten. Die ungeheure Dynamik des technologischen Fortschritts und die Komplexität der menschlichen Kreativität wird man mit Normen nicht beherrschen können. Beides spielt aber in der Security eine ganz große Rolle.

Ihre individuellen Fragen zum Test Embedded Security beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).