Gehen Sie einen schnelleren, intelligenteren Weg zur KI-gestützten C/C++-Testautomatisierung. Erfahren Sie mehr >>
3 Praktische Möglichkeiten zur Zukunftssicherung Ihrer IoT-Geräte
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.
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.
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) bezieht sich auf ein System netzwerkfähiger Geräte, Komponenten oder Dienste, die Daten veröffentlichen und/oder konsumieren. IoT-Anwendungen werden 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 Auswirkungen auf die Sicherheit, den Datenschutz und die Sicherheit ihrer Benutzer haben. In einigen Fällen sind die Kosten eines Ausfalls tödlich, daher ist es von entscheidender Bedeutung, diese Geräte gemäß den geltenden Standards zu bauen.
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 verstehen, wo Ihr Projekt steht im Augenblickdem „Vermischten Geschmack“. Seine Höhe der technischen Schulden sind die Kosten für potenzielle Nacharbeiten aufgrund der Komplexität des Codes in Kombination mit etwaigen verbleibenden Codierungsstandards und Sicherheitsverletzungen, die derzeit im Code vorhanden sind. Diese Schuld ist auf die anschließende Bereinigung, Korrektur und Prüfung des Codes zurückzuführen. Eine Möglichkeit, den aktuellen Stand eines Projekts genau in den Griff zu bekommen, ist der Einsatz einer automatisierten statischen Code-Analyse. Die statische Analyse bietet Einblicke in die Qualität und Sicherheit einer Codebasis und zählt 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.:
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 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 Ingenieure sind sich einig, dass das blinde Erstellen von Unit-Tests für alle Funktionen keinen guten ROI bringt. Wenn Ihr Team jedoch Zugriff auf eine Framework für Unit-Tests Als Teil der Projekt-Sandbox ist es eine wertvolle Investition. Unit-Tests können sinnvoll eingesetzt werden, wenn Ingenieure bestimmte komplexe Algorithmen oder Datenmanipulationen isoliert testen müssen. Auch die Entwicklung von Unit-Tests ist von großem Wert – wir haben in Unternehmen festgestellt, dass das einfache Schreiben und Ausführen eines Unit-Tests den Code robuster und besser gestaltet.
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 Aspekte: Einfachheit, Portabilität, Wartbarkeit, Skalierbarkeit und Zuverlässigkeit bei gleichzeitiger Abwägung von Latenz, Durchsatz, Stromverbrauch und Größenbeschränkungen. Bei der Architektur eines Systems, das potenziell an ein großes IoT-Ökosystem angeschlossen werden soll, priorisieren viele Teams nicht 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 Bedenken, Verteidigung in der Tiefe, und 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:
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
