Suchen

Expertenbeitrag

Arthur Hicken

Arthur Hicken

, Parasoft® Deutschland GmbH

Cybersecurity

Längerfristige Sicherheit von IoT-Devices: Drei praktikable Wege der Gestaltung

| Autor/ Redakteur: Arthur Hicken / Sebastian Human

Auch wenn Embedded-Geräte im IoT potenziell für kritische Anwendungen genutzt werden, müssen viele davon derzeit noch keinen Safety- oder Security-Standards entsprechen – das kann sich schnell ändern. Wie rüstet man eingebettete IoT-Geräte vorab gegen Bedrohungen der Zukunft?

Firma zum Thema

Auch wenn sie bei IoT-Devices manchmal erst im Nachhinein auftreten: Security-Compliance-Anforderungen müssen bewältigt werden können.
Auch wenn sie bei IoT-Devices manchmal erst im Nachhinein auftreten: Security-Compliance-Anforderungen müssen bewältigt werden können.
( Bild: Shutterstock )

IoT-Anwendungen halten zunehmend Einzug in unser tägliches Leben – von Industrierobotern über chirurgische Instrumente bis hin zu selbstfahrenden Autos und autonom fliegenden Drohnen. Schon heute können viele dieser Anwendungen Einfluss auf die Privatsphäre und den Schutz und die Sicherheit ihrer Anwender haben. Da die bei einem Ausfall entstehenden Kosten in einigen Fällen fatal wären, kommt es unbedingt darauf an, die betreffenden Geräte nach den einschlägigen Normen zu bauen. In der durch Agilität geprägten Welt der IoT-Entwicklung können die Compliance-Anforderungen aber unter Umständen erst zu einem späteren Zeitpunkt entstehen, wenn der Code bereits geschrieben und geprüft ist. Was kann man hier tun?

Ganz ohne Zweifel ist es am besten, etwaige Compliance-Aktivitäten von Anfang an in das Softwaredesign einzubeziehen, aber bekanntermaßen können sich stringente Entwicklungsprozesse auf die Markteinführungszeit auswirken – besonders wenn keine Automatisierung erfolgt. Nur wenige Entwickler haben Freude daran, zusätzliche Tests und das Dokumentieren der Rückverfolgbarkeit außerhalb der normalen Arbeitszeit durchzuführen. Pragmatische, agile und schnelle Teams dagegen können es sich oft nicht leisten, wegen der Integration von Compliance-Aktivitäten, die vielleicht in Zukunft notwendig sind, an Dynamik zu verlieren. Stattdessen bevorzugen viele Teams die Devise: „Kommt Zeit, kommt Rat“. Leider gibt es keine Wunderwaffe, mit der sich bestehender Code im Nachhinein normenkonform machen lässt. Solche Unternehmen erfahren dann auf die harte Tour, dass die Kosten für ein nachträgliches Herstellen der Konformität um Größenordnungen höher sind als der finanzielle Aufwand, der entsteht, wenn man ein Produkt gleich zu Beginn konform entwickelt.

Welche Maßnahmen mit wenig Mehraufwand kann man also schon heute treffen, um sich auf die Erfüllung der strengen Konformitäts-Anforderungen von morgen vorzubereiten?

Maßnahme 1: Verschaffen Sie sich einen Überblick über Ihre technische Schuld

Es ist wichtig zu verstehen, wo das Projekt im Moment steht. Bei der technischen Schuld handelt es sich um die Kosten für potenzielle Nacharbeiten infolge der Codekomplexität, kombiniert mit etwaigen, aktuell noch im Code vorhandenen Verletzungen von Codierstandards und Security-Vorgaben. Diese Schuld entsteht durch das notwendig werdende nachfolgende Bereinigen, Reparieren und Testen des Codes. Eine Möglichkeit, Aussagen über den aktuellen Stand eines Projekts zu bekommen, ist die automatisierte statische Codeanalyse. Sie vermittelt Einblicke in die Qualität und Security einer Codebasis und zeigt etwaige Verletzungen von Codierstandards auf.

Leider verlassen sich viele Teams, die Embedded-Anwendungen in C oder C++ entwickeln, bei der Suche nach Schwachstellen immer noch auf ihren Compiler oder manuelle Codeprüfungen, anstatt die statische Analyse zu bemühen. Aus den unterschiedlichsten Gründen tun sich einige Teams schwer mit der Einführung von statischen Analysetools. Möglicherweise finden sie, dass diese Tools „Noise“ erzeugen und schwierig anzuwenden sind, oder sie können sie wegen dringender täglicher Angelegenheiten nicht in den Entwicklungsprozess einbinden. Eine gängige (Fehl-)Einschätzung ist auch, dass der Zeitaufwand für die Entscheidung, bei welchen Regelverletzungen sich die Behebung lohnt, den tatsächlichen Nutzen der Problembeseitigung überwiegt.

Wir haben festgestellt: Teams, die nur einen kleinen Umfang an kritischen und zwingend notwendigen Regeln befolgten, mussten deutlich weniger Zeit für Nacharbeiten am Code aufwenden, wenn sie in einer späteren Projektphase mit Functional-Safety-Audits konfrontiert wurden. Sichere und geschützte Systeme lassen sich leichter von Grund auf erstellen, wenn der Security-Aspekt von Beginn an berücksichtigt wird (beispielsweise durch Beachtung der CERT C Secure Coding Guidelines). Man kann dabei durchaus ganz klein anfangen, denn CERT besitzt ein ausgefeiltes Priorisierungssystem. Dabei werden Schweregrad, Wahrscheinlichkeit und Nachbesserungskosten jeweils in drei Stufen bewertet, was insgesamt 27 Levels ergibt. Beim Einsatz moderner Tools erfahrener Anbieter lässt sich der Konformitätsstatus ganz einfach auf einem vorkonfigurierten Dashboard ablesen.

Die statische Analyse hilft Unternehmen ferner beim Verstehen ihrer technischen Schuld. Hierzu werden Datenpunkte gesammelt, die dem Management bezüglich der Safety- und Security-Konformität helfen. Manager können dabei auf einfache Weise Antworten auf wichtige Fragen wie diese bekommen:

  • Wie ist der aktuelle Zustand? Wie viele unkritische Codierstandard-Verletzungen gibt es derzeit in meiner Codebasis?
  • Trenddaten: Werden die neuen und behobenen Verletzungen in jedem Build gemeldet? Werden wir besser oder schlechter?
  • Wie komplex ist mein Code zurzeit? Nimmt die Komplexität zu?

Einige Standards messen die zyklomatische Komplexität, um sie unter einem bestimmten Grenzwert zu halten. Komplexitäts-Metriken können außerdem genutzt werden, um eine Testmaßnahme abzuschätzen. Zum Beispiel kann die Anzahl der Testfälle, die zum Nachweis einer Branch Level Coverage von 10 0% für die Einhaltung von IEC 61508 SIL 2 notwendig ist, proportional zur zyklomatischen (McCabe-)Komplexität einer Funktion sein.

Bildergalerie

Man kann also mit den ganz einfachen Dingen anfangen. Hat sich das Team erst einmal mit den kritischsten Fehlern vertraut gemacht, lässt sich das Spektrum der erfassten Standardverletzungen erweitern. Dabei sind keinesfalls alle Regeln in Stein gemeißelt, sondern es ist wichtig zu entscheiden, welche Regeln in den Codierstandard des Projekts fallen und welche nicht. Als Minimallösung kann ein Satz zwingend notwendiger Regeln aus verschiedenen wichtigen Codierstandards (zum Beispiel MISRA Mandatory oder CERT C Regeln) sicherstellen, dass sich die künftige Safety- und Security-Argumentation für ein vernetztes Gerät vereinfacht.

Maßnahme 2: Richten Sie ein qualifizierbares Modultest-Framework ein und messen Sie die Codeüberdeckung

Die meisten pragmatischen Entwickler dürften der Aussage zustimmen, dass es sich kaum lohnt, blindlings Modultests für sämtliche Funktionen einzurichten. Allerdings ist es eine sinnvolle Investition, dem Team im Rahmen der Projekt-Sandbox den Zugang zu einem Modultest-Framework zu ermöglichen. Modultests lassen sich immer dann lohnend einsetzen, wenn Entwickler es als sinnvoll erachten, bestimmte komplexe Algorithmen oder Datenmanipulationen isoliert zu testen. Darüber hinaus liegt schon im Entwickeln von Modultests ein entscheidender Nutzen. Wie wir von Unternehmen erfahren haben, trägt allein das Schreiben und Ausführen von Modultests dazu bei, den Code robuster und besser zu machen.

Werden Forderungen nach Safety- oder Security-Konformität laut, kann ein Unternehmen seine Modultest-Maßnahmen zügig intensivieren, indem es zeitweilig zusätzliches Personal für diese Aufgabe abstellt. Damit diese Arbeiten aber schnell skaliert werden können, müssen das Modultest-Framework und der zugehörige Prozess im Zuge des Projekts bereits verstanden und dokumentiert sein.

Eine Aufzählung gängiger Merkmale eines skalierbaren, auf die künftige Compliance ausgerichteten Modultest-Frameworks:

  • Qualifikation für die vorgesehene Nutzung für einen bestimmten Safety-Standard (z. B. durch ein TÜV-Zertifikat)
  • Integration in ein automatisiertes Build-System
  • Dokumentation der geforderten Codeüberdeckungs-Metrik (z. B. MC/DC)
  • Aufzeichnung der Ergebnisse und Überdeckung der für ein Build durchgeführten Tests über die Zeit
  • Eignung für mehrere Projekte und Teams

Die entscheidende Erkenntnis hieraus lautet, dass man alle von einem künftigen Safety-Standard geforderten Test-Techniken installieren soll – wenn auch in einem minimalen Umfang. Sollte eine Zertifizierung nötig werden, ist es einfacher, diese zu skalieren, anstatt dann ganz von vorne zu beginnen.

Maßnahme 3: Isolieren Sie kritische Funktionalität

Bei der Planung von Embedded-Systemen sind viele Faktoren zu berücksichtigen, wie etwa Einfachheit, Portierbarkeit, Wartbarkeit, Skalierbarkeit und Zuverlässigkeit. Gleichzeitig muss eine geeignete Abwägung zwischen den Anforderungen an die Latenz, den Durchsatz, den Stromverbrauch und den Platzbedarf gefunden werden. Geht es um die Planung eines Systems, das potenziell mit einem großen IoT-Ökosystem vernetzt werden soll, räumen viele Teams den Kriterien Safety und Security keine Priorität gegenüber diesen übrigen Qualitätsfaktoren ein.

Um die künftige Safety-Compliance zu vereinfachen (und um sich an gute Architektur-Praktiken zu halten), lassen sich die einzelnen Komponenten räumlich und zeitlich trennen. Zum Beispiel ist das Design eines Systems möglich, in dem alle kritischen Operationen von einer separaten, speziellen CPU ausgeführt werden, alle unkritischen Operationen dagegen auf einer anderen, sodass eine räumliche Trennung erfolgt. Eine weitere Option ist die Anwendung eines Separation Kernel Hypervisors und die Nutzung von Microkernel-Konzepten. Neben diesen gibt es noch weitere Möglichkeiten, aber entscheidend ist es, so früh wie möglich die Architekturprinzipien Separation of Concerns (Trennung der Belange), Defense in Depth (tiefgehende Verteidigung) und Separation for Mixed Criticality (Separierung für gemischte Kritikalität) anzuwenden. Diese Konzepte verringern nicht nur den Umfang der Nacharbeiten, die zur Einhaltung der Safety- und Security-Standards erforderlich sind, sondern steigern außerdem die Qualität und Resilienz der Applikation. Nachfolgend sind einige Möglichkeiten zur Isolation von kritischem Code aufgeführt:

Räumlich:

  • Dateien
  • Module
  • Verzeichnisse (Ordner)
  • Bibliotheken

Auf der Ausführungsebene:

  • Threads, RTOS-Tasks, Hypervisors
  • CPU-Kerne, separate CPUs

Die Abgrenzung kritischer Funktionen von unkritischen reduziert den Umfang künftiger Verifikationsmaßnahmen, die zum Nachweis der Konformität erforderlich werden.

Zusammenfassung

Viele Devices im IoT-Ökosystem erbringen kritische Dienstfunktionen, die von künftigen Safety- und Security-Standards betroffen sein könnten. Sicherlich ist es nicht kosteneffektiv, ohne Rücksicht auf die tatsächliche Notwendigkeit Anforderungen von Standards zu erfüllen. Aber um sich für die Zukunft zu rüsten, können Unternehmen schon heute wichtige Designtechniken, Modultest-Konzepte und statische Analysetools einsetzen und Metriken sammeln. Sofern sie früh genug damit anfangen, können Software-Teams diese Konzepte nahtlos in ihre bestehenden Prozesse integrieren. Am besten beginnt man frühzeitig mit dem richtigen Ansatz, der sich zu einem späteren Zeitpunkt skalieren lässt, denn so vermeidet man die sehr Herkules-Aufgabe, den bereits fertig entwickelten, geprüften und im Einsatz befindlichen Softwarecode nachträglich standardkonform zu machen.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 46035178)

Über den Autor

Arthur Hicken

Arthur Hicken

, Parasoft® Deutschland GmbH