Fachinterview Safety&Security Verlässlichkeit auf Systemdesign-Basis

Safety&Security steht gegenwärtig im Zentrum der Embedded-Evolution. Diese beiden Attribute spannen allerdings noch keinen akkuraten Sprachraum der System-Verlässlichkeit. Das Fachinterview mit Dr. Daniel Ziener gibt eine vollständige Definition und zeigt Systemdesign-Methoden in diesem Bereich auf.

DESIGN&ELEKTRONIK: Herr Dr. Ziener, im Embedded-Bereich wächst der Begriff »Safety&Security« dieser Tage zu einem Kernthema. Eine Referenz wird in der Diskussion aber nur selten angeführt. Kennen Sie dafür eine fundamentale Definition?

Dr. Daniel Ziener: Im Prinzip ist der Begriff Safety&Security zu eng gefasst. Ein besserer Begriff ist die Verlässlichkeit, wie sie von Laprie und weiteren [1] definiert wurde. Wir möchten ja verlässliche eingebettete Systeme haben. Die Verlässlichkeit hat drei Aspekte: Bedrohungen die diese kompromittieren können, ihre Attribute und die Mittel um sie zu gewährleisten (Bild 1).

Safety ist in diesem Konzept beispielsweise nur ein Attribut. Es bezeichnet ein System, das ohne katastrophale Konsequenzen für Anwender oder Umgebung betrieben werden kann. Es wird relativ zu der spezifizierbaren Risikoumgebung bemessen, kann aber nicht direkt quantifiziert werden. Die weiteren Attribute sind: Verfügbarkeit, Zuverlässigkeit, Vertraulichkeit, Integrität und Wartbarkeit.

Während Verfügbarkeit und Zuverlässigkeit alle Auswirkung von Fehlern berücksichtigen, fußt Safety nur auf den katastrophalen Auswirkungen. Wichtig ist die technologische Definition der Bedrohungen: hier wird zwischen »Failure«, »Error« und »Fault« unterschieden. Das deutsche Wort »Fehler« ist hier leider zu unspezifisch.

Failure lässt sich im deutschen mit Systemversagen umschreiben und beschreibt eine Abweichung vom spezifizierten Verhalten, welches von außen beobachtbar ist, z.B. an der Schnittstelle. Ein Error ist ein Fehlerzustand, der eine Abweichung von den spezifizierten internen Zuständen einer Komponente darstellt. - Dieser kann, wenn er nicht behandelt wird, zu einem Systemversagen führen. Ein Fault ist dabei ein Defekt, der einen Fehlerzustand auslösen kann aber nicht muss [2].

Fehlerzustände sind transient oder permanent: ein transienter Fehlerzustand kann z.B. von einem transienten Defekt ausgelöst werden, welcher in Systemen ohne Rückkopplung vorkommt. Bei rückgekoppelten Systemen werden alle Folgezustände beeinflusst und der Fehlerzustand somit permanent. Die Spezifikation muss aber niemals vollständig sein. Methoden um Verlässlichkeit zu gewährleisten sind Fehlervorbeugung, Fehlertoleranz, Fehlerbeseitigung und Fehlervorhersage.

An den englischen Begriffen erkennt man, dass diese sich auf den Defekt (Fault) beziehen, z.B. »fault tolerance« für Fehlertoleranz. Fehlertolerante Systeme arbeiten sogar im Fehlerzustand verlässlich weiter: dazu müssen Fehlerzustände zuverlässig erkannt werden - zur Laufzeit oder in der Servicepause. Anschließend muss der Fehlerzustand, mit einer wiederholten Ausführung von einem zuvor gespeicherten fehlerfreien Zustand, oder durch Neuinitialisierung des Systems verlassen werden.

Bei permanenten oder wiederkehrenden periodischen Defekten muss eine Fehlerbehandlung durchgeführt werden, um die Ursache zu beheben. D.h. die Defekte müssen analysiert und isoliert werden, sowie das System rekonfiguriert und neu gestartet werden. Um die Fehlerbehandlung bei der Entwicklung zu verifizieren, können Fehler z.B. in der Systemsimulation injiziert werden. Bei der Fehlervorhersage werden vor allem Modelle und Simulationen eingesetzt.

D&E: Security kommt in diesem Konzept gar nicht vor?

DZ: Security wird dabei als Kombination der Attribute Vertraulichkeit, Integrität und Verfügbarkeit definiert. Hier werden aber nur jene Fehlerzustände berücksichtigt, welche die oben genannten Attribute verletzen. Die Untermenge der Security-relevanten Fehler (fault), bzw. Schwachstellen welche sich durch Angriffe ausnutzen lassen, heißt auch »Flaw« .

Unter einem Angriff, welcher durch eine externe Bedrohung ausgelöst wird, überführt eine Schwachstelle das System in einen Fehlerzustand. Wenn dieser nicht erkannt wird, kann es zum Security-relevanten Systemversagen führen, z.B. sensitive Daten gelangen nach außen. Eine Bedrohung hat mit der Einsatzumgebung des Systems zu tun, eine Schwachstelle ist eine Systemeigenschaft.

Schwachstellen können gewollt oder unbeabsichtigt, boshaft oder nicht boshaft sein. Trojaner sind ein landläufiges Beispiel für gewollte boshafte Schwachstellen, gewollt aber nicht boshaft eine zusätzliche Debug-Schnittstelle in einem Computersystem und typischerweise können Software-Bugs unbeabsichtigte Schwachstellen darstellen.

Angriffe können hier nach den Security-Zielen, den Attributen Vertraulichkeit, Integrität und Verfügbarkeit kategorisiert werden.

D&E: Was denken Sie - worauf fußt dieses verstärkte Interesse an dem Thema?

DZ: Ein Treiber ist auch die höhere Integrationsdichte - performantere SoCs mit hoher Packungsdichte sind z.B. auch anfälliger für thermische Fluktuationen und mechanische Schockereignisse. Gleichzeitig dringen SoCs mit dem kompakten Formfaktor in immer rauere Einsatzumgebungen vor.

Des Weiteren werden eingebettete Systeme immer komplexer und vernetzter. Mit der zunehmenden Vernetzung durch das IoT-Paradigma, wachsen dann auch die Angriffswege in der SoC-Peripherie. Die Wahrscheinlichkeit Fehler und Schwachstellen im System nicht zu erkennen wird, durch die dem Marktdruck geschuldeten kurzen Entwicklungszeiten, erhöht.

Ein weiterer, noch nicht erwähnter Faktor, ist der IP-Schutz. Heute sind immer mehr Hardwarefirmen Fab-less. D.h. sie produzieren keine Chips im Haus sondern verkaufen modulare Schaltungen, die sogenannten IP-Cores, an Lizenznehmer. Die Firma arm zum Beispiel verkauft ihre Prozessoren nicht als Chips sondern als IP-Lizenzen welche, z.B. durch Apple in Hardware implementiert werden. Solche IP-Cores sind allerdings auch einfach zu kopieren und können unter Umständen auch ohne Lizenzierung Verwendung finden.