Safety & Security Sicherheitstests für das Internet der Dinge

Anbieter zum Thema

Parasoft® Deutschland GmbH

MicroConsult Microelectronics Consulting & Training GmbH

RTI Real-Time Innovations

Die Sicherheit ist durch die enorme Verbreitung von Geräten im Internet der Dinge (IoT) in fast allen vertikalen Marktsegmenten zu einem Hauptanliegen geworden. Industrielle Steuerungsanlagen, Autos und medizinische Geräte können alle aus der Ferne überwacht oder gesteuert werden. Obwohl diese drahtlose Konnektivität hochwertige Funktionen bietet, führt sie zu Sicherheitslücken und Möglichkeiten für böswillige Angriffe.

Die Auswirkungen eines Hackerangriffs oder einer Lösegeldforderung können sowohl für den User als auch für den Hersteller verheerend sein. Doch alle Sicherheitsmaßnahmen zur Verschlüsselung, Authentifizierung und zum Schutz reichen nicht aus, wenn die Software nicht in jeder Phase ihres Lebenszyklus sicher entwickelt wird - von der Entwicklung über die Wartung bis zur endgültigen Stilllegung. Konkret bedeutet dies: Zunächst müssen alle gesetzlichen Sicherheitsanforderungen berücksichtigt werden, einschließlich der Sicherheitsanforderungen der Kunden und der Anforderungen an die Qualität der Sicherheitsdienste. Anschließend sollten diese Anforderungen in allen Entwicklungsphasen der Systemtechnik einbezogen werden: Anforderungsmanagement und -zerlegung, die den Architekturentwurf, die Implementierung und das Testen vorantreiben. Aber das Testen ist nicht viel komplizierter als früher.

Die Komplexität bei der Gewährleistung der Sicherheit durch Tests liegt nicht nur in der Konnektivität mit anderen Geräten, wie in Abbildung 1 dargestellt, sondern auch in der Interaktion mit weiteren verwandten Technologien. Ist zum Beispiel das Betriebssystem sicherheitsgehärtet? Ist das Boot-Image sicher verifiziert? Sind alle Eingangs- und Ausgangsendpunkte der Anlage sicher? Bei diesen Fragen kommt man ins Grübeln: Wie können wir das IoT sichern?

Es ist wichtig, dass das Unternehmen eine klare Vorstellung von den Grenzen des Systems hat, das auf Sicherheit geprüft werden soll. Der Umfang geht über die bestehenden funktionalen Anforderungen hinaus. Die Sicherung des IoT-Geräts beinhaltet die Validierung des Benutzerzugriffs durch erzwungene Klassen von Benutzerprivilegien, die Verhinderung von Hardware- und Softwareänderungen am Gerät, um die Umgehung von Sicherheitsfunktionen zu verhindern, und die Gewährleistung des Schutzes von Daten vor Online- und Offline-Zugriffen, und zwar nicht nur über Wi-Fi, sondern auch durch sichere Datenübertragung über alle möglichen Kanäle (Bluetooth, USB, usw.).

Leitfaden für Softwaretest-Methoden – ein Überblick

Gartner [1] hat einige Prognosen zur Cybersicherheit veröffentlicht, die sich auf dieses verteilte Ökosystem beziehen. Demnach haben die Vorstände von Unternehmen erkannt, dass Cybersicherheit nicht nur ein technisches, sondern auch ein geschäftliches Risiko darstellt. Die Prognosen lauten:

• Bis 2026 werden mindestens 50 Prozent der Führungskräfte in ihren Arbeitsverträgen Leistungsanforderungen in Bezug auf Cybersicherheitsrisiken enthalten.

• Bis 2025 werden 60 Prozent der Unternehmen das Cybersecurity-Risiko als wesentliches Kriterium bei der Durchführung von Transaktionen mit Dritten und bei geschäftlichen Engagements berücksichtigen.

• Bis 2025 werden 50 Prozent der Führungskräfte im Bereich Cybersicherheit erfolglos versucht haben, die Quantifizierung von Cybersicherheitsrisiken zur Entscheidungsfindung im Unternehmen zu nutzen.

• Bis 2026 werden 30 Prozent der großen Unternehmen öffentlich geteilte Umwelt-, Sozial- und Unternehmensführungsziele (ESG-Ziele) haben, die sich auf die Cybersicherheit konzentrieren. 2021 waren es noch weniger als 2 Prozent.

• Bis 2025 werden 40 Prozent der Programme verhaltenssoziologische Prinzipien (wie z. B. Nudge-Techniken) einsetzen, um die Sicherheitskultur im gesamten Unternehmen zu beeinflussen, gegenüber weniger als 5 Prozent im Jahr 2021.

100-prozentige Sicherheit gibt es nicht

Bereiten Sie sich darauf vor, gehackt zu werden

Sicherheitsvorschriften und –standards für IoT

Um den richtigen Weg zur Sicherheit einzuschlagen, muss man alle geltenden Gesetze und Vorschriften kennen, wobei die geografische Lage einen großen Unterschied macht. So hat Kalifornien in 2017 als erster Bundesstaat der Vereinigten Staaten ein IoT-spezifisches Cybersicherheitsgesetz (California Civil Code § 1798.91.04) [3] verabschiedet, das die Hersteller von IoT-Geräten verpflichtet, jedes hergestellte IoT-Gerät mit einer oder mehreren „angemessenen Sicherheitsfunktionen" auszustatten. Dazu gehören Sicherheitsanforderungen zum Schutz des Geräts und aller auf dem Gerät enthaltenen Informationen vor unbefugtem Zugriff, Zerstörung, Verwendung, Änderung oder Offenlegung. Andere Staaten ziehen nun nach.

Ein weiteres Beispiel sind die Vorschriften der Europäischen Union zum Datenschutz und zum Schutz der Privatsphäre, die General Data Protection Regulation (GDPR) [3]. Viele IoT-Geräte arbeiten mit denselben personenbezogenen Daten wie E-Mail-Adressen, IP-Adressen, Telefonnummern und anderen privaten Daten, so dass die GDPR Anwendung findet: IoT-Assets müssen sicherstellen, dass sie volle Transparenz in ihre Netzwerkendpunkte und sogar die Zustimmung der Kunden haben, um identifizierbare Kundeninformationen vollständig vor Datenverletzungen zu schützen

Es gibt auch mehrere Sicherheitsstandards wie der IEC 62443 - Sicherheit für industrielle Automatisierungs- und Steuerungssysteme (IACS). Er zielt darauf ab, die Risiken für industrielle Kommunikationsnetze zu verringern, indem er Verfahren für die sichere Entwicklung von Software für IACS definiert. Die Gewährleistung der Sicherheit ist allerdings ein sich ständig weiterentwickelndes Projekt, das über die reinen technischen Entwicklungs- und Prozessstandards wie IEC 62443 hinausgeht.

Unternehmen müssen auch organisatorische Änderungen vornehmen, die das Zusammenspiel von Mitarbeitern, Prozessen und Technologien bei der Wahrung der Sicherheit fördern. Standards wie ISO 27001 bilden den Rahmen für den Einsatz eines Informationssicherheits-Managementsystems (ISMS), mit dem Unternehmen ihre Sicherheitspraktiken konsequent und kosteneffizient verwalten können. Zu den empfohlenen Praktiken nach ISO 27001 gehören ein Programm zur Sensibilisierung des Sicherheitspersonals, Verfahren zur Überwachung von Bedrohungen, Verschlüsselung, ein Prozess zur Verwaltung von Zwischenfällen und vieles mehr. Auch wenn eine Zertifizierung nach ISO 21001 nicht obligatorisch ist, zeigt sie den potenziellen und bestehenden Kunden, dass ein Unternehmen bereit ist, international anerkannte Sicherheitsstandards zu erfüllen.

Sicherheitslebenszyklus und Tests

Die Einführung und Integration von Sicherheit ist nicht so schwierig, wie es vielleicht scheint. Hersteller von Embedded-Geräten sind mit der Norm für funktionale Sicherheit IEC 61508 bestens vertraut. Der in der IEC 61508 definierte Lebenszyklus von Sicherheitssoftware überschneidet sich in weiten Teilen mit den Anforderungen der IEC 62443-4-1 (Secure Product Development Lifecycle).

Eine intensive Zusammenarbeit zwischen Ihren Sicherheits- und Sicherungsteams ist erforderlich, einschließlich des Einsatzes eines soliden Produkt- oder Anwendungslebenszyklus-Management-Tools (ALM). So wie Sicherheitsanforderungen von Systemingenieuren in ALM-Tools erfasst werden, um später das Anforderungsmanagement durchzuführen, muss das Sicherheitsteam dasselbe tun.

Die Sicherheitsanforderungen für das System müssen erfasst und genau definiert werden. Deren Zuordnung zu den verschiedenen technischen Domänen (Software, Hardware, Mechanik, Elektrik usw.) sollte ebenso erfolgen. Die Sicherheitsanforderungen sollten weiter aufgeschlüsselt und zu den übergeordneten Sicherheitsanforderungen zurückverfolgt werden, um sicherzustellen, dass der Entwurf keine Sicherheitslücken aufweist. Tatsächlich sind die Prozesslebenszyklen von Safety und Security so ähnlich, dass sie sich überschneiden, wie im wohlbekannten Lebenszyklus des V-Modells dargestellt.

Auch für Sicherheitsanforderungen auf Systemebene sind Testfälle auf Systemebene zu erstellen. Sicherheitsingenieure, die Anforderungen definieren und zerlegen eigenen sich am besten, um Testfälle zu definieren, die gewährleisten, dass die korrekte Sicherheitsfunktionalität erreicht wird. Testfälle auf Sicherheitssystemebene werden mit Hilfe von Beschreibungstexten mit spezifischen Eingabe- und Ausgabekriterien definiert. Später führt das Qualitätssicherungsteam jeden Testfall durch und validiert die Sicherheitsanforderungen, auf die er zurückgeht.

Es ist wichtig, die Abstraktionsebenen der Sicherheitsanforderungen und damit auch die Abstraktionsebenen der Sicherheitstests zu verstehen. DAST (Dynamic Application Security Testing )-Tests auf dieser Ebene umfassen Testmethoden wie Penetrationstests, API-Tests, Service-Virtualisierung, funktionale Sicherheitstests, Fuzz-Tests, UI-Tests und Testfall-Codeabdeckung.

Auf der linken Seite des V-Modells werden die Sicherheitsanforderungen auf Systemebene zerlegt und in den übergeordneten Architekturentwurf des Systems integriert. Definiert werden auch Testfälle für Sicherheitsanforderungen auf hoher Ebene, die in der Regel die Interaktion zwischen Komponenten, Subsystemen und/oder funktionalen Fähigkeiten testen. Diese Art von DAST-Testverfahren ist besser bekannt als Integrationstestfälle und kann in dieser Stufe des Lebenszyklus Testmethoden wie API-Tests, Service-Virtualisierung, funktionale Sicherheitstests und Fuzz-Tests umfassen.

Die nächste Stufe der Zerlegung der Sicherheitsanforderungen betrifft den Feinentwurf. Zur Unterstützung der Sicherheitsfunktionalität müssen funktionale Codeeinheiten erstellt werden. Diese Anforderungen sind mit der übergeordneten Anforderung und den vom Sicherheitssystemtechniker erstellten Testfällen auf Einheitsebene verknüpft, die vom Softwareentwickler zu realisieren sind. Im Gegenzug kann der Softwareentwickler den Code, der die Anforderung implementiert, mit dem Anforderungsobjekt verknüpfen.

Diese Ebene der Rückverfolgbarkeit ist von großem Wert, wenn sich die Anforderungen ständig ändern. Wird beispielsweise eine Anforderung gestrichen oder für ein zukünftiges Release festgelegt, ermöglicht die direkte Rückverfolgbarkeit zu dem genauen Code, der die Anforderung implementiert, einen nahtlosen Übergang mit minimalen bis gar keinen negativen Auswirkungen beim Entfernen des Codes. Auch wenn die Rückverfolgbarkeit mehr Energie verschlingt, rechnet sie sich bei ständig ändernden Anforderungen enorm. Und wenn ein Entwickler Änderungen am Code vornimmt, verweist die Rückverfolgbarkeit auf die Anforderungen, die davon betroffen sein könnten.

Der Softwareentwickler muss auch verschiedene Unit-Testfälle konstruieren, um nicht nur die Anforderungen und die implementierten Funktionen zu überprüfen, sondern auch, ob der Code robust genug ist, um möglichst viele Bedrohungsszenarien zu unterstützen. So können beispielsweise Testfälle, die Set- und Get-Funktionen aufrufen, die Gültigkeit von Anfragen überprüfen, wenn Daten angefordert oder bereitgestellt werden. Man sollte die Verschlüsselung der Daten sollte zumindest in Betracht ziehen. Als weitere Testmethoden auf Unit-Ebene bietet sich Fuzzing an, mit dem eine Schwachstelle aufgedeckt werden kann.

Am unteren Ende des V-Modells findet die Implementierung der Sicherheit statt. Der Ingenieur kodiert nach den Anforderungen. Für IoT-Geräte werden in der Regel C und C++ verwendet, und in diesen Sprachen gibt es Programmierkonstrukte, die nicht verwendet werden sollten. Viele Sicherheitslücken in C beziehen sich beispielsweise auf Pufferüberläufe. Puffer sind Speicherbereiche, die für die Speicherung von Daten reserviert sind.

Es kann anfälliger Code geschrieben werden, der es einem Angreifer ermöglicht, andere wichtige Werte im Speicher zu überschreiben, z. B. die Anweisungen, was als nächstes von der CPU ausgeführt werden soll. C und C++ sind anfällig für Pufferüberläufe, weil sie Zeichenketten als nullterminierte Arrays von Zeichen definieren, keine implizite Prüfung der Grenzen vornehmen und Standardbibliotheksaufrufe für Zeichenketten bereitstellen, die keine Prüfung der Grenzen erzwingen. Hier auf der Kernebene der Entwicklung gibt es Lösungen zur Analyse der Sicherheitskodierung, um diese Sicherheitsprobleme zu entschärfen.

SAST (Static Application Security Testing) sollte die erste Stufe der Prüfung auf Sicherheitsschwachstellen sein. Es gibt Programmierstandards wie SEI CERT, CWE und andere wie MISRA C:2012 und AUTOSAR C++14, die zur Analyse auf den Code angewendet werden können. Sicherheitsverletzungen im Code werden zur schnellen Behebung aufgedeckt. Statische Analysetools wie Parasoft C/C++test lassen sich nicht nur in die bevorzugte IDE integrieren, sondern es ist möglich, die statische Analyselösung direkt in eine DevOps-Pipeline zu integrieren, so dass die Sicherheit direkt in den Build-Prozess des Unternehmens einfließt. Viele Unternehmen, die agile Methoden wie Scrum und DevOps CI/CD eingeführt haben, berichten von höherer Codequalität, niedrigeren Testkosten und einer kürzeren Markteinführungszeit.

Der Durchgang durch den Entwicklungszyklus sollte einen Überblick über die verschiedenen Ebenen der Produktentwicklung vermitteln, auf denen Sicherheitsmaßnahmen notwendig sind. Tritt man nun einen Schritt zurück und betrachtet das Gesamtbild, bei dem das IoT ein Teil eines großen Netzwerks ist, müssen möglicherweise Tests durchgeführt werden, die sich mit seiner Konnektivität und dem größeren Umfang oder Kontext befassen, in dem es lebt. Diese Art von Tests kann eine Kombination aus SAST und DAST sein.

Bedrohungsanalyse Risikobewertung

Um festzustellen, wie man sich am besten gegen Bedrohungen der Cybersicherheit schützen kann, müssen Unternehmen eine Bedrohungsanalyse und Risikobewertung durchführen. Dies ist unter Umständen etwas kompliziert, da es viele Ansätze und Rahmenwerke zur Risikobewertung im Bereich der Cybersicherheit gibt, die derzeit zum Einsatz kommen. Einige stammen von Behörden, andere von kommerziellen Organisationen (u.a. NIST, ISO, OCTAVE, NCSA).

Im Mittelpunkt dieses Themas stehen mehrere Risikokategorien – mit Ethik als einer davon. Ist ein Unternehmen bereit, sein IoT-Gerät unmoralisch einzusetzen, um gesetzliche Vorschriften zu umgehen oder sich einen Vorteil zu verschaffen? Es gibt auch das unheimlichere Risikoszenario, bei dem ein Akteur nach einer Möglichkeit sucht, sich Zugang zu Vermögenswerten zu verschaffen, um Schaden anzurichten. Und schließlich gibt es auch das technische Risiko, dass Software- und/oder Hardware-Schwachstellen im IoT-Design vorhanden sind.

Diese Risikofaktoren werden in der Regel mit einer hohen, mittleren oder niedrigen Wahrscheinlichkeit eingestuft. Neben der Bedrohung ist auch ihre Auswirkung bei Eintritt zu berücksichtigen – diese kann als schwer, hoch oder gering eingestuft werden [4]. Für die Berechnung der Risikoeinstufung gibt es folgende Formel:

Risikoeinstufung = Auswirkung (falls ausgenutzt) x Wahrscheinlichkeit (des Ausnutzens)

Die Berechnung der Risikoeinstufung ist noch weiter ausbaufähig, indem man durch Einbeziehung quantitativer Gewichtungsmaßnahmen eine qualitative Ebene zuweist.

Einige Unternehmen haben weitere Sicherheitsstufen für die Cybersicherheit (CAL) definiert, die den in Tabelle I aufgeführten quantitativen Stufen entsprechen. Beispielsweise bedeutet CAL 4 ein „sehr hohes" Risiko und verlangt das strengste Verfahren zur Gewährleistung der Sicherheit. CAL 0 bedeutet, dass praktisch kein Risiko besteht.

Die IEC 62443 definiert Sicherheitsstufen (SLs 0-4) wie folgt [5] :

• SL 0: Keine besonderen Anforderungen oder Sicherheitsvorkehrungen erforderlich.

• SL 1: Schutz vor unbeabsichtigtem oder ungewolltem Missbrauch.

• SL 2: Schutz vor vorsätzlichem Missbrauch mit einfachen Mitteln und geringen Ressourcen, allgemeinen Fähigkeiten und niedriger Motivation.

• SL 3: Schutz vor vorsätzlichem Missbrauch mit anspruchsvollen Mitteln mit moderaten Ressourcen, InVeKoS (Integrierte Verwaltungs- und Kontrollsystem)-spezifischen Kenntnissen und moderater Motivation.

• SL 4: Schutz vor vorsätzlichem Missbrauch unter Einsatz anspruchsvoller Mittel mit umfangreichen Ressourcen, InVeKoS-spezifischen Kenntnissen und hoher Motivation.

Bedeutung für die Entwicklung von Software-Sicherheit

Die verschiedenen Sicherheitslevel (SLs) drücken unterschiedliche Niveaus von Aufwand oder Strenge aus, die auf die Entwicklung und das Testen der Software angewendet werden müssen. In Anhang B der IEC 62443-3-3 sind beispielsweise die Sicherheitsanforderungen oder -fähigkeiten aufgeführt, die je nach SL (Security Level)-Wert zu erfüllen sind. Zusätzlich muss jede Anforderung oder Fähigkeit, die implementiert wird, gründlich verifiziert und validiert werden. Die Testmethoden (Pen-Tests, API-Tests, SAST usw.) hängen von der implementierten Fähigkeit/Anforderung ab.

Tabelle 2 – Beispiel für die Zuordnung von Sicherheitsanforderungen (SR) und Anforderungserweiterungen (RE) zu SLs. [5]

Ausblick

Die Welt des IoT wächst weiterhin in rasantem Tempo, und die Verantwortung für die Sicherheit verlagert sich mehr und mehr auf die Unternehmen. Deshalb müssen sie weiterhin Standards wie IEC 62443 für ihre technischen Sicherheitsanforderungen und ISO 27001 für ihre geschäftlichen und organisatorischen Sicherheitsvorkehrungen übernehmen.

Legende:

• [1] Gartner’s Predictions

• [2] Section 1798.91.04 - Duty of manufacturer, Cal. Civ. Code § 1798.91.04 | Casetext Search + Citator Current through 2022 legislation.

• [3] Privacy and data protection measures for IoT; GDPR for IoT; Internet of Things and General Data Protection Regulation. (legalitgroup.com)

• [4] IoT cyber risk: a holistic analysis of cyber risk assessment frameworks, risk vectors, and risk ranking process

• [5] Standard IEC 62443-3-3

 (mbf)

* Als Senior Technical Product Marketing Manager für Parasofts Embedded-Testing-Lösungen verfügt Ricardo Camacho über Erfahrung im SDLC (Software Development Life Cycle) und in der Testautomatisierung von embedded Echtzeit-, Sicherheits- und sicherheitskritischen Anwendungen sowie in der Einhaltung von Industriestandards durch Software.

(ID:49233933)