Entdecken Sie das TÜV-zertifizierte GoogleTest mit Agentic AI für C/C++-Tests!
Details ansehen »
Parasoft-Blog
Das Internet der Dinge hat sich weiterentwickelt, aber wie stellen wir sicher, dass es Sicherheitsstandards erfüllt? Hier sind drei Möglichkeiten, um sicherzustellen, dass Ihre eingebetteten IoT-Geräte zukünftige Sicherheits- und Compliance-Standards erfüllen.
Zum Abschnitt springen
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 der Dinge (IoT) bezeichnet ein System vernetzter Geräte, Komponenten oder Dienste, die Daten veröffentlichen und/oder verarbeiten. IoT-Anwendungen werden immer mehr zu einem festen Bestandteil unseres Lebens: von Industrierobotern und chirurgischen Instrumenten bis hin zu selbstfahrenden Autos und autonom fliegenden Drohnen. Viele dieser Geräte können bereits heute die Sicherheit, den Datenschutz und die Privatsphäre ihrer Nutzer beeinträchtigen. In manchen Fällen sind die Folgen eines Ausfalls fatal, weshalb die Einhaltung der geltenden Standards bei der Entwicklung dieser Geräte von entscheidender Bedeutung ist.
Obwohl Compliance-Aktivitäten am besten von Anfang an in die Softwareentwicklung integriert werden sollten, ist es allgemein bekannt, dass strenge Entwicklungsprozesse (insbesondere ohne Automatisierung) die Markteinführungszeit beeinträchtigen können. Nicht viele Entwickler führen gerne zusätzliche Tests durch und dokumentieren die Rückverfolgbarkeit außerhalb der normalen Arbeitszeiten. Daher können es sich pragmatische, agile und schnelllebige Teams oft nicht leisten, an Dynamik zu verlieren, indem sie Compliance in den Zeitplan einbauen, nur weil sie davon ausgehen, dass sie sie in Zukunft möglicherweise benötigen. Stattdessen entscheiden sich viele Teams dafür, die Dinge erst zu tun, wenn sie dazu kommen.
Leider gibt es kein Patentrezept, um Code nachträglich konform zu machen. Diese Organisationen müssen auf die harte Tour lernen, dass die Kosten für die Konformität am Ende des Projekts um ein Vielfaches höher sind als die Kosten für die Entwicklung des ersten 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?
Es ist wichtig zu wissen, wo Ihr Projekt aktuell steht . Die technischen Schulden entsprechen den Kosten potenzieller Nacharbeiten aufgrund der Codekomplexität sowie aller noch vorhandenen Verstöße gegen Programmierrichtlinien und Sicherheitsvorkehrungen. Diese Schulden entstehen durch die anschließende Bereinigung, Fehlerbehebung und das Testen des Codes. Eine Möglichkeit, den aktuellen Projektstatus zu ermitteln, ist die automatisierte statische Codeanalyse. Die statische Analyse liefert Einblicke in die Qualität und Sicherheit der Codebasis und listet gegebenenfalls Verstöße gegen Programmierrichtlinien auf.
Leider verlassen sich viele Teams, die eingebettete Anwendungen in C und C++ entwickeln, immer noch auf ihren Compiler oder manuelle Code-Reviews, um Fehler zu finden, anstatt statische Codeanalyse einzusetzen. Manche Teams tun sich aus verschiedenen Gründen schwer mit statischen Analysetools, beispielsweise weil sie diese als unübersichtlich und schwierig zu bedienen empfinden (was kein Problem sein sollte, wenn man den Einstieg richtig lernt ), oder weil sie aufgrund dringender Aufgaben im Entwicklungsalltag keine Zeit dafür finden . Ein weit verbreiteter Irrglaube ist, dass der Zeitaufwand für die Ermittlung der zu behebenden Fehler höher ist als der Nutzen der eigentlichen Fehlerbehebung.
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.:
Einige Normen fordern die Messung der zyklomatischen Komplexität, um diese unter einem bestimmten Schwellenwert zu halten. Komplexitätsmetriken können auch zur Abschätzung des Testaufwands herangezogen werden – beispielsweise ist die Anzahl der Testfälle, die für eine 100%ige Zweigabdeckung gemäß IEC 61508 SIL 2 erforderlich sind, proportional zur McCabe-Zyklomatischen Komplexität einer Funktion.
Nachfolgend ein Beispiel aus einem Dashboard, das die MISRA- Konformität eines Projekts innerhalb von Parasoft DTP, dem Reporting- und Analyse-Hub von Parasoft, anzeigt:
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 Bewältigung der kritischsten Fehler vertraut ist, können Sie die Bandbreite der Standardverletzungen erhöhen. Nicht alle Regeln sind in Stein gemeißelt, daher ist es wichtig zu entscheiden, welche Regeln zum Kodierungsstandard des Projekts gehören und welche nicht. Zumindest die Übernahme der verbindlichen Regeln einiger wichtiger Kodierungsstandards (z. B. MISRA-Verpflichtung oder CERT-C-Regeln) erleichtert die zukünftige Argumentation zur Sicherheit eines vernetzten Geräts.
Die meisten pragmatischen Entwickler sind sich einig, dass das wahllose Erstellen von Unit-Tests für alle Funktionen keinen guten ROI bietet. Steht Ihrem Team jedoch im Rahmen der Projektumgebung ein Unit-Testing-Framework zur Verfügung , ist dies eine wertvolle Investition. Unit-Tests lassen sich sinnvoll einsetzen, wenn Entwickler bestimmte komplexe Algorithmen oder Datenmanipulationen isoliert testen möchten. Auch der Entwicklungsprozess von Unit-Tests selbst ist sehr wertvoll: Erfahrungsgemäß führt das Schreiben und Ausführen von Unit-Tests in Unternehmen zu robusterem und besser strukturiertem Code.
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:
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.
Die Architektur eingebetteter Systeme erfordert die Berücksichtigung zahlreicher Eigenschaften: Einfachheit, Portabilität, Wartbarkeit, Skalierbarkeit und Zuverlässigkeit. Gleichzeitig müssen die Zielkonflikte zwischen Latenz, Durchsatz, Stromverbrauch und Größenbeschränkungen gelöst werden. Bei der Entwicklung eines Systems, das potenziell in ein großes IoT-Ökosystem eingebunden werden soll, räumen viele Teams der Sicherheit nicht die gleiche Priorität ein wie anderen Qualitätsfaktoren.
Um die Einhaltung zukünftiger Sicherheitsanforderungen zu vereinfachen (und bewährte Architekturpraktiken zu befolgen), können Sie Komponenten zeitlich und räumlich trennen. Beispielsweise können Sie ein System entwerfen, in dem alle kritischen Operationen auf einer separaten dedizierten CPU ausgeführt werden, während alle nicht-kritischen Operationen auf einer anderen laufen – wodurch eine physische Trennung erreicht wird. Eine weitere Möglichkeit ist der Einsatz eines Separation Kernel Hypervisors und von Mikrokernel-Konzepten. Es gibt noch weitere Optionen, aber entscheidend ist, die wichtigsten Architekturansätze der Trennung von Belangen , der gestaffelten Verteidigung und der Trennung bei gemischter Kritikalität so früh wie möglich zu implementieren. Diese Ansätze reduzieren nicht nur den Aufwand für die Einhaltung von Sicherheitsstandards, sondern verbessern auch die Qualität und Ausfallsicherheit der Anwendung. Hier sind einige Beispiele zur Isolierung kritischen Codes:
Durch die Trennung kritischer von nicht kritischen Funktionen wird der Umfang zukünftiger Überprüfungsbemühungen zum Nachweis der Konformität verringert.
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.
„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.
Weiterführende Inhalte
