Absichern für die Zukunft Drei praktische Ansätze, um IoT-Geräte zukunftsfsicher zu machen

Anbieter zum Thema

Parasoft® Deutschland GmbH

Vogel IT-Medien GmbH

Fujitsu Technology Solutions GmbH

QUNIS GmbH

Noch gibt es für IoT-Geräte keine verpflichtenden Standards, doch entsprechende Normen kündigen sich bereits an. Wie können Entwickler jetzt schon dafür sorgen, dass ihre Software auch künftigen Anforderungen standhalten wird?

Trotz des Potenzials für Embedded Devices im IoT-Umfeld müssen viele Geräte derzeit keine Sicherheitsstandards einhalten, auch wenn sie heute schon die Sicherheit, den Datenschutz und die Privatsphäre ihrer Nutzer beeinträchtigen können. In der agilen Welt der IoT-Entwicklung können Konformitätsanforderungen viel später hinzukommen, nachdem der Code bereits geschrieben und getestet worden ist. Weil ein Ausfall unter Umständen tödlich sein kann, ist es von entscheidender Bedeutung, diese Geräte nach den geltenden Normen zu bauen. Wie lassen sich also embedded IoT-Geräte zukunftsfähig gestalten?

Am besten ist es, Konformitätsaktivitäten von Anfang an in das Softwaredesign einzubinden, auch wenn es eine bekannte Tatsache ist, dass strikte Entwicklungsprozesse (insbesondere ohne die Hilfe von Automatisierung) die Markteinführungszeit verzögern können. Nicht viele Entwickler führen gerne zusätzliche Tests durch und dokumentieren die Rückverfolgbarkeit außerhalb der normalen Arbeitszeiten. Pragmatische, agile und schnell arbeitende Teams können es sich daher oft nicht leisten, den Zeitplan wegen der Einhaltung von Richtlinien zu überziehen, nur weil sie diese in der Zukunft „vielleicht brauchen“. Stattdessen entscheiden sie sich oft dafür, sich darum zu kümmern, wenn es „notwendig wird“.

Es gibt leider keinen Zauberstab oder Patentrezept, um den Code rückwirkend konform zu machen. Diese Unternehmen lernen auf die harte Tour, dass die Kosten für das Hinzufügen der Konformität am Ende des Projekts um Größenordnungen höher sind als die Kosten für die Entwicklung des ursprünglichen funktionalen Produkts.

Welche Maßnahmen können Sie also schon heute ergreifen, um die strengen Compliance-Anforderungen von morgen zu erfüllen?

Verschaffen Sie sich Einblick in Ihre technischen Schulden

Es ist wichtig zu verstehen, wo Ihr Projekt im Augenblick steht. Die Höhe der technischen Schulden entspricht den Kosten für potenzielle Nacharbeiten aufgrund der Komplexität des Codes in Verbindung mit den verbleibenden Verstößen gegen die Programmierstandards und die Sicherheitsregeln, die derzeit im Code vorhanden sind. Diese Schulden sind der anschließenden Bereinigung, Korrektur und Prüfung des Codes geschuldet. Eine Möglichkeit, um sich einen guten Überblick über den aktuellen Stand eines Projekts zu verschaffen, ist die automatisierte statische Codeanalyse. Sie gibt Aufschluss über die Qualität und Sicherheit einer Codebasis und zeigt gegebenenfalls Verletzungen der Programmierstandards auf.

Leider verlassen sich viele Teams, die embedded Anwendungen in C und C++ entwickeln, immer noch auf ihren Compiler oder manuelle Code-Reviews, um Probleme zu erkennen, anstatt statische Analysen einzusetzen. Teams tun sich aus verschiedensten Gründen schwer mit der Einführung statischer Analysewerkzeuge, z. B. weil sie sie als lästig und schwer zu bedienen empfinden, oder weil sie es aufgrund dringender alltäglicher Angelegenheiten nicht schaffen, sie in den täglichen Entwicklungsprozess einzubauen. Eine verbreitete (Fehl-)Wahrnehmung ist, dass der zeitliche Aufwand für die Ermittlung der behebungswürdigen Verstöße größer ist als der Wert der tatsächlichen Korrektur.

Nach unseren Erkenntnissen mussten Teams, die eine kleine Anzahl entscheidender und verbindlicher Regeln übernommen haben, viel weniger Zeit für die Überarbeitung des Codes aufwenden, wenn sie später im Projekt mit Audits zur funktionalen Sicherheit konfrontiert wurden. Es ist viel einfacher, sichere Systeme von Grund auf zu entwickeln, indem man die Sicherheit einbaut, beispielsweise durch die Umsetzung der CERT C Secure Coding Guidelines. Man kann auch klein anfangen, denn CERT verfügt über ein ausgeklügeltes Priorisierungssystem (mit Schweregrad, Wahrscheinlichkeit und Kosten für die Behebung, jeweils in 3 Stufen, insgesamt 27 Stufen). Wenn Sie Parasoft-Tools verwenden, können Sie den Status der Konformität leicht in einem vorkonfigurierten Dashboard einsehen.

Mit der statischen Analyse können Unternehmen auch ihre technischen Schulden besser verstehen, weil sie Datenpunkte sammelt, die die Geschäftsführung bei der Einhaltung von Sicherheitsvorschriften unterstützen. Manager können auf einfache Weise wichtige Fragen beantworten, wie z. B.:

• Was ist meine Baseline? Wie viele unkritische Verstöße gegen Codierungsstandards gibt es in meiner Codebasis?

• Tendenzdaten: Werden bei jedem Build neue und behobene Verstöße gemeldet? Werden wir besser oder schlechter?

• Wie hoch ist die Komplexität meines Codes heute? Nimmt sie zu?

Einige Normen verlangen die Erfassung der zyklomatischen Komplexität, um sie unter einem bestimmten Schwellenwert zu halten. Mithilfe von Komplexitätsmetriken lässt sich auch der Testaufwand abschätzen: Beispielsweise ist die Anzahl der Testfälle, die für den Nachweis einer 100-prozentigen Abdeckung der Verzweigungsebene erforderlich sind, um die IEC 61508 SIL2 zu erfüllen, proportional zur zyklomatischen Komplexität einer Funktion nach McCabe.

Oben sehen Sie ein Beispiel für ein Dashboard, das die MISRA -Konformität eines Projekts in Parasoft DTP, der Berichts- und Analyseplattform von Parasoft, zeigt. Die Anzeige der Codemetriken kann dazu beitragen, komplexere Bereiche für eine zusätzliche Codeüberprüfung aufzudecken und zu prüfen, wie gut diese Bereiche durch Tests abgedeckt sind.

Links ist ein Beispiel für ein Metrics-Dashboard zu sehen. Sie können also mit den Grundlagen beginnen. Sobald das Team mit den kritischsten Fehlern vertraut ist, können Sie die Verstöße gegen die Standards ausweiten. Nicht alle Regeln sind „in Stein gemeißelt“, sodass es wichtig ist, zu entscheiden, welche Regeln in den Kodierungsstandard des Projekts aufgenommen werden oder nicht. Zumindest die Übernahme der obligatorischen Regeln in einigen wichtigen Kodierungsstandards (z. B. die obligatorischen MISRA- oder CERT-C-Regeln) erleichtert die künftige Sicherheitsargumentation für ein angeschlossenes Gerät.

Richten Sie ein qualifizierbares Unit-Test-Framework ein

Die meisten pragmatischen Entwickler sind sich einig, dass das blinde Erstellen von Unit-Tests für alle ihrer Funktionen keinen guten ROI bringt. Hat Ihr Team jedoch Zugang zu einem Unit-Testing-Framework als Teil der Projekt-Sandbox, ist dies eine wertvolle Investition. Unit-Tests lassen sich intelligent einsetzen, wenn Entwickler das Gefühl haben, dass sie bestimmte komplexe Algorithmen oder Datenmanipulationen isoliert testen müssen. Auch der Prozess der Entwicklung von Unit-Tests ist von erheblichem Wert – wir haben in Unternehmen festgestellt, dass durch die Praxis des einfachen Schreibens und Ausführens von Unit-Tests der Code robuster und besser konzipiert ist.

Wenn Anforderungen an die Sicherheit oder die Einhaltung von Vorschriften entstehen, kann ein Unternehmen den Aufwand für Unit-Tests schnell erhöhen, indem es vorübergehend zusätzliche Mitarbeiter einsetzt. Damit dieser Aufwand jedoch schnell skaliert werden kann, sollten die Verantwortlichen das Unit-Testing-Framework und den Prozess bereits im Laufe des Projekts verstehen und dokumentieren. Die gemeinsamen Merkmale eines skalierbaren Unit-Testing-Frameworks mit Blick auf die zukünftige Konformität sind:

• Qualifiziert für den beabsichtigten Einsatz für einen bestimmten Sicherheitsstandard (z.B. durch TÜV-Zertifikat)

• Integriert in ein automatisiertes Build-System

• Melden der erforderlichen Codeabdeckungsmetrik (z. B. MC/DC)

• Aufzeichnung der Ergebnisse und der Abdeckung der durchgeführten Tests pro Build und im Zeitverlauf

• Verkäuflich für mehrere Projekte und Teams

Die wichtigste Erkenntnis ist, dass alle Prüfverfahren, die eine künftige Sicherheitsnorm erfordert, in minimalem Umfang eingesetzt werden sollten. Es ist einfacher, diese zu erweitern, wenn ein Zertifizierungsbedarf entsteht, als bei Null anzufangen.

Isolieren Sie kritische Funktionen

Bei der Architektur von embedded Systemen gibt es viele „Funktionen" zu berücksichtigen: Einfachheit, Übertragbarkeit, Wartbarkeit, Skalierbarkeit und Zuverlässigkeit, während gleichzeitig Kompromisse zwischen Latenz, Durchsatz, Stromverbrauch und Größenbeschränkungen eingegangen werden müssen. Bei der Entwicklung eines Systems, das möglicherweise mit einem großen IoT-Ökosystem verbunden wird, räumen viele Teams der Sicherheit (Safety und Security) keine Priorität gegenüber einigen dieser anderen Qualitätsfaktoren ein.

Um die Einhaltung künftiger Sicherheitsvorschriften zu erleichtern (und gute Architekturpraktiken einzuhalten), lassen sich Komponenten zeitlich und räumlich trennen. Sie können beispielsweise ein System entwerfen, bei dem alle kritischen Operationen auf einer separaten dedizierten CPU ablaufen, während alle nicht kritischen Operationen auf einer anderen ausgeführt werden – und somit eine physische Trennung vornehmen. Eine andere Möglichkeit ist der Einsatz eines Separation Kernel Hypervisors und von Microkernel-Konzepten. Es gibt noch weitere Optionen, aber der Schlüssel liegt darin, so früh wie möglich die architektonischen Schlüsselansätze „Separation of Concerns“, „Defense in Depth“ und „Separation for Mixed Criticality“ anzuwenden. Diese senken nicht nur den Arbeitsaufwand für das Einhalten von Sicherheitsstandards, sondern verbessern auch die Qualität und Widerstandsfähigkeit der Anwendung. Hier sind einige Möglichkeiten, um kritischen Code zu isolieren:

• Space domain: Dateien / Module / Verzeichnisse / Bibliotheken

• Execution domain: Threads, RTOS-Tasks, Hypervisors / CPU-Cores, separate CPU

Die Trennung von kritischen und unkritischen Funktionen verringert den Umfang des künftigen Überprüfungsaufwands zum Nachweis der Konformität.

Fazit

Viele Edge-Geräte im IoT-Ökosystem bieten wichtige Leistungen an, die möglicherweise unter zukünftige Sicherheitsstandards fallen. Natürlich ist es keine kosteneffiziente Strategie, zu versuchen, die Anforderungen von Standards zu erfüllen, ohne zu wissen, ob dies notwendig ist oder nicht. Als Vorbereitung auf die Zukunft können Unternehmen wichtige Entwicklungstechniken, Unit-Testing-Ansätze und statische Analysetools übernehmen und Metriken zur Unterstützung künftiger Anforderungen sammeln. Softwareteams können diese Ansätze nahtlos in ihre bestehenden Prozesse übernehmen, sofern sie früh genug damit beginnen. Der Schlüssel ist: Frühzeitig mit dem richtigen Ansatz beginnen, der später skaliert werden kann, um zu verhindern, dass nach der Entwicklung, dem Testen und der Bereitstellung von Softwarecode ein fast herkulischer Aufwand betrieben werden muss, um die Konformität zu gewährleisten.

Dieser Artikel stammt von unserem Partnerportal ElektronikPraxis.

* Andrey Madan ist Senior Solution Architect bei Parasoft.

(ID:48403431)