Parasoft C/C++test 2022.2 unterstützt MISRA C:2012 Amendment 3 und eine Entwurfsversion von MISRA C++ 202x. Erfahren Sie mehr >>

3 Praktische Möglichkeiten zur Zukunftssicherung Ihrer IoT-Geräte

Von Andrej Madan

10. Juli 2019

6  min lesen

Trotz des Potenzials für eingebettete Geräte im IoT-Kontext müssen viele Geräte derzeit nicht den Sicherheitsstandards entsprechen. In der agilen Welt der IoT-Entwicklung können Compliance-Anforderungen jedoch viel später gestellt werden, nachdem der Code bereits geschrieben und getestet wurde. Wie können Sie sich also auf die Zukunft Ihrer eingebetteten IoT-Geräte vorbereiten?

Der Begriff Internet of Things (IoT) bezieht sich auf ein System von netzwerkfähigen Geräten, Komponenten oder Diensten, die Daten veröffentlichen und/oder konsumieren. IoT-Anwendungen werden zu einem festen Bestandteil unseres Lebens: von Industrierobotern und chirurgischen Instrumenten über selbstfahrende Autos bis hin zu autonom fliegenden Drohnen. Viele dieser Geräte können sich bereits heute auf die Sicherheit, den Datenschutz und die Sicherheit ihrer Benutzer auswirken. In einigen Fällen sind die Kosten eines Ausfalls tödlich, daher ist es von entscheidender Bedeutung, diese Geräte nach den vorherrschenden Standards zu bauen.

Während es am besten ist, Compliance-Aktivitäten von Anfang an in das Software-Design einzubetten, ist es eine bekannte Tatsache, dass strenge Entwicklungsprozesse (insbesondere ohne die Hilfe der Automatisierung) die Markteinführungszeit beeinflussen können. Nicht viele Entwickler führen gerne zusätzliche Tests durch und dokumentieren die Rückverfolgbarkeit außerhalb der normalen Arbeitszeit. Daher können es sich pragmatische, agile und schnelllebige Teams oft nicht leisten, an Dynamik zu verlieren, indem sie die Einhaltung von Vorschriften in den Zeitplan einbauen, unter der Voraussetzung, dass sie diese möglicherweise benötigen Zukunft. Stattdessen entscheiden sich viele Teams dafür, „diese Brücke zu überqueren, wenn sie dazu kommen“.

Leider gibt es keinen Zauberstab oder eine Silberkugel, die den Code rückwirkend „konform“ macht. Was diese Organisationen auf die harte Tour lernen, ist, dass die Kosten für das Hinzufügen von Compliance am Ende des Projekts um Größenordnungen höher sind als die Kosten für die Entwicklung des ursprünglich funktionierenden Produkts.

Welche Maßnahmen mit geringen Auswirkungen können Sie heute ergreifen, um sich auf die Erfüllung der strengen Compliance-Anforderungen von morgen vorzubereiten?

Aktion 1: Erhalten Sie Einblick in Ihre technischen Schulden

Es ist wichtig zu verstehen, wo Ihr Projekt steht im Augenblick. Die Höhe der technischen Schulden sind die Kosten für mögliche Nacharbeiten aufgrund der Komplexität des Codes in Verbindung mit allen verbleibenden Codierungsstandards und Sicherheitsverletzungen, die derzeit im Code vorhanden sind. Diese Schulden sind auf die anschließende Bereinigung, Korrektur und Prüfung des Codes zurückzuführen. Eine Möglichkeit, den heutigen Stand eines Projekts in den Griff zu bekommen, ist die Verwendung einer automatisierten statischen Code-Analyse. Die statische Analyse bietet Einblick in die Qualität und Sicherheit einer Codebasis und listet gegebenenfalls Verstöße gegen Codierungsstandards auf.

Leider verlassen sich viele Teams, die eingebettete Anwendungen in C und C ++ entwickeln, immer noch auf ihre Compiler- oder manuellen Codeüberprüfungen, um Probleme zu erkennen, anstatt statische Analysen durchzuführen. Einige Teams haben aus verschiedenen Gründen Schwierigkeiten, statische Analysewerkzeuge einzusetzen, z. B. weil sie laut und schwer zu bedienen sind (sollte kein Problem sein, wenn Sie dies tun) Erfahren Sie, wie Sie richtig anfangen) oder nicht arbeite es in den täglichen Entwicklungsprozess ein aufgrund dringender alltäglicher Angelegenheiten. Eine verbreitete (falsche) Wahrnehmung ist, dass die Zeit, die für die Ermittlung der zu behebenden Verstöße aufgewendet werden muss, größer ist als der Wert der tatsächlichen Behebung.

Wir stellen jedoch fest, dass Teams, die einen kleinen Satz kritischer und verbindlicher Regeln verabschiedet haben, viel weniger Zeit damit verbracht haben, den Code zu überarbeiten, wenn sie später im Projekt mit Audits zur funktionalen Sicherheit konfrontiert werden. Es ist viel einfacher, sichere Systeme von Grund auf durch Building Security In zu erstellen, indem beispielsweise CERT C Secure Coding Guidelines implementiert werden. Sie können klein anfangen. CERT verfügt über ein ausgeklügeltes Priorisierungssystem (unter Verwendung von Schweregrad, Wahrscheinlichkeit und Korrekturkosten, jeweils in 3 Klassen, insgesamt 27 Stufen). Wenn Sie Parasoft-Tools verwenden, können Sie den Konformitätsstatus einfach in einem vorkonfigurierten Dashboard anzeigen.

Die statische Analyse hilft Unternehmen auch dabei, ihre technischen Schulden zu verstehen, indem Datenpunkte gesammelt werden, die das Management bei der Einhaltung von Sicherheitsbestimmungen unterstützen. Manager können wichtige Fragen leicht beurteilen, z. B.:

  • Was ist meine Grundlinie? Wie viele unkritische Verstöße gegen den Codierungsstandard sind in meiner Codebasis vorhanden?
  • Trenddaten: Neue und behobene Verstöße bei jedem Build gemeldet? Werden wir besser oder schlechter?
  • Was ist meine heutige Codekomplexität? Wächst es?

Einige Standards erfordern die Messung der zyklomatischen Komplexität, um sie unter einem bestimmten Schwellenwert zu halten. Komplexitätsmetriken können auch verwendet werden, um den Testaufwand abzuschätzen. Beispielsweise ist die Anzahl der Testfälle, die Sie zum Nachweis einer 100% igen Abdeckung auf Verzweigungsebene zur Einhaltung von IEC 61508 SIL 2 benötigen, proportional zur McCabe Cyclomatic Complexity einer Funktion.

Im Folgenden finden Sie ein Beispiel aus einem Dashboard, das die MISRA-Konformität eines Projekts in Parasoft DTP, dem Berichts- und Analyse-Hub von Parasoft, zeigt:

 

Und hier ist das gleiche für CERT C:

Der Wert des Anzeigens der Codemetriken kann dazu beitragen, komplexere Bereiche für zusätzliche Codeüberprüfungen verfügbar zu machen und zu überwachen, wie gut diese Bereiche durch Tests abgedeckt werden. Hier ist ein Beispiel für das Metrics Dashboard:

Sie können also mit den Grundlagen beginnen. Sobald das Team mit der Verwaltung der kritischsten Fehler vertraut ist, können Sie die Breite der Verstöße gegen Standards erhöhen. Nicht alle Regeln sind in Stein gemeißelt, daher ist es wichtig zu entscheiden, welche Regeln im oder außerhalb des Codierungsstandards des Projekts enthalten sind. Zumindest erleichtert die Übernahme der obligatorischen Regeln in einige wichtige Codierungsstandards (z. B. MISRA-obligatorische oder CERT C-Regeln) die zukünftige Sicherheitsargumentation für ein verbundenes Gerät.

„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.

Aktion 2: Richten Sie ein qualifiziertes Framework für Komponententests ein und messen Sie die Codeabdeckung

Die meisten pragmatischen Ingenieure sind sich einig, dass das blinde Erstellen von Komponententests für alle Ihre Funktionen keinen guten ROI bietet. Wenn Ihr Team jedoch als Teil der Projekt-Sandbox Zugriff auf ein Unit-Testing-Framework hat, ist dies eine wertvolle Investition. Unit-Tests können intelligent eingesetzt werden, wenn Ingenieure das Gefühl haben, bestimmte komplexe Algorithmen oder Datenmanipulationen isoliert testen zu müssen. Es gibt auch einen bedeutenden Wert bei der Entwicklung von Komponententests - was wir von Organisationen gesehen haben, ist, dass die Praxis des einfachen Schreibens und Ausführens eines Komponententests den Code robuster und besser gestaltet macht.

Wenn Anforderungen an die Einhaltung von Sicherheitsbestimmungen gestellt werden, kann eine Organisation den Aufwand für Unit-Tests schnell erhöhen, indem sie vorübergehend Mitarbeiter hinzufügt. Um diesen Aufwand jedoch schnell zu skalieren, sollten das Framework und der Prozess für Unit-Tests bereits im Verlauf des Projekts verstanden und dokumentiert werden. Die gemeinsamen Merkmale eines skalierbaren Unit-Testing-Frameworks im Hinblick auf zukünftige Konformität sind:

  • Qualifiziert für den Verwendungszweck für einen bestimmten Sicherheitsstandard (zB über TÜV-Zertifikat)
  • Integriert in ein automatisiertes Build-System
  • Meldet die erforderliche Codeabdeckungsmetrik (zMC / DC)
  • Zeichnen Sie die Ergebnisse und die Abdeckung der ausgeführten Tests pro Build und im Laufe der Zeit auf
  • Verkaufbar für mehrere Projekte und Teams

Der Schlüssel zum Erfolg besteht darin, alle Testtechniken einzusetzen, die ein zukünftiger Sicherheitsstandard erfordert, jedoch in minimalem Umfang. Dies ist einfacher zu skalieren, wenn ein Zertifizierungsbedarf auftritt, als von vorne zu beginnen.

Aktion 3: Kritische Funktionen isolieren

Die Architektur eingebetteter Systeme erfordert die Berücksichtigung zahlreicher „Funktionen“: Einfachheit, Portabilität, Wartbarkeit, Skalierbarkeit und Zuverlässigkeit, während die Kompromisse zwischen Latenz, Durchsatz, Stromverbrauch und Größenbeschränkungen gelöst werden. Bei der Entwicklung eines Systems, das möglicherweise mit einem großen IoT-Ökosystem verbunden ist, setzen viele Teams keine Prioritäten Sicherheit und  Sicherheitdienst über einige dieser anderen Qualitätsfaktoren.

Um die Einhaltung zukünftiger Sicherheitsbestimmungen zu vereinfachen (und gute Architekturpraktiken zu befolgen), können Sie Komponenten zeitlich und räumlich trennen. Sie können beispielsweise ein System entwerfen, in dem alle kritischen Vorgänge auf einer separaten dedizierten CPU ausgeführt werden, während alle nicht kritischen Vorgänge auf einer anderen CPU ausgeführt werden. Auf diese Weise wird eine physische Trennung bereitgestellt. Eine weitere Option ist die Verwendung eines Separation Kernel Hypervisor- und eines Mikrokernel-Konzepts. Es gibt andere Optionen, aber der Schlüssel besteht darin, wichtige architektonische Ansätze von zu übernehmen Trennung von BedenkenVerteidigung in der Tiefeund  Trennung für gemischte Kritikalität so früh wie möglich. Diese Ansätze reduzieren nicht nur den Arbeitsaufwand zur Einhaltung der Sicherheitsstandards, sondern verbessern auch die Qualität und Ausfallsicherheit der Anwendung. Hier sind beispielsweise einige Möglichkeiten, um kritischen Code zu isolieren:

  • Weltraumdomäne:
    • Dateien
    • Module
    • Verzeichnisse
    • Bibliotheken
  • Ausführungsdomäne:
    • Threads, RTOS-Aufgaben, Hypervisoren
    • CPU-Kerne, separate CPU

Durch die Trennung kritischer von nicht kritischen Funktionen wird der Umfang zukünftiger Überprüfungsbemühungen zum Nachweis der Konformität verringert.

Zusammenfassung

Viele Edge-Geräte im IoT-Ökosystem bieten wichtige Dienste, die möglicherweise unter zukünftige Sicherheitsstandards fallen. Der Versuch, die Anforderungen der Standards zu erfüllen, ohne zu wissen, ob dies erforderlich ist oder nicht, ist natürlich keine kostengünstige Strategie. Um sich auf die Zukunft vorzubereiten, können Unternehmen wichtige Entwurfstechniken, Unit-Test-Ansätze und statische Analysewerkzeuge anwenden und Metriken sammeln, um zukünftige Anforderungen zu erfüllen. Softwareteams können diese Ansätze nahtlos in ihre vorhandenen Prozesse übernehmen, wenn sie früher gestartet werden. Beginnen Sie frühzeitig mit dem richtigen Ansatz, der später skaliert werden kann, um zu vermeiden, dass fast herkulische Anstrengungen erforderlich sind, um den Softwarecode bei der Entwicklung, dem Test und der Bereitstellung in Übereinstimmung zu bringen.

Neuer Handlungsaufruf

Von Andrej Madan

Andrey ist Senior Solution Architect bei Parasoft, wo er sich auf automatisierte Tools und Methoden konzentriert und mit Kunden zusammenarbeitet, um die besten technischen und geschäftlichen Ansätze für ein effizientes Testen heterogener Anwendungen zu ermitteln.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.