Kopf an Kopf – Penetrationstest vs. Schwachstellenscan Security Testing für Embedded Systems

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Eskenzi PR Limited

Im Bereich der Embedded Systems sind Security by Design und sichere Software-Entwicklung von besonderer Bedeutung. Dies bedingt Security Testing über den ganzen Lebenszyklus hinweg, dieser Beitrag widmet sich dem Pen Testing auf der einen und Vulnerability Scans auf der anderen Seite.

Wenn man eingebettete Geräte mit einem angemessenen Sicherheitsniveau auf den Markt bringen will, kommt man als Anbieter nicht umhin, eine Sicherheitsüberprüfung in den Softwareentwicklungsprozess zu integrieren. Im Idealfall heißt das, Sicherheitsüberlegungen in alle Phasen des Lebenszyklus eines eingebetteten Geräts einzubeziehen.

Dies gilt von der initialen Produktarchitektur und dem Produktdesign über die Implementierung und Prüfung bis hin zur Verwendung und Überwachung im eigentlichen Einsatz. Und den ganzen Weg zurück in Richtung Design – zumindest, wenn man der sich stetig verändernden Bedrohungslandschaft ebenso Rechnung tragen will wie den Marktanforderungen und allen Problemen, die beim realen Einsatz der Geräte auftreten.

An dieser Stelle konzentrieren wir uns auf die eigentliche Prüfphase innerhalb des Sicherheitsprozesses. Ähnlich der Prüfphase innerhalb des Entwicklungsprozesses, bei der die funktionale Implementierung überprüft wird, gewährleistet dieser Teil, dass Sicherheitsfunktionen korrekt implementiert wurden.

Das Auffinden bekannter Schwachstellen gehört hier ebenso dazu wie die Prüfung auf deren Ausnutzbarkeit, das Identifizieren von potenziellen Sicherheitslücken und das Gesamtbild vom Sicherheitsprofil eines Produkts. Das betrifft sowohl das Produkt als Ganzes als auch die einzelnen Komponenten. Unabhängig davon, ob diese Komponenten komplett im eigenen Haus entwickelt wurden, mithilfe von Open Source Code erstellt oder von Drittanbietern bezogen wurden.

Die gleichen Pflichten gelten im Übrigen unabhängig davon, ob man selbst der Anbieter ist, der ein bestimmtes Produkt auf den Markt gebracht hat, ein Integrator für das Produkt oder ein OEM-Anbieter oder Dienstleister ist, der ein Standardprodukt unter dem eigenen Markennamen verwendet. Wenn bei einem vernetzten Produkt Sicherheitsprobleme auftreten, dann sind alle genannten Parteien in der Haftung.

Für diejenigen, die einfach nur ein internetfähiges Produkt kaufen wollen, ist es nicht ganz leicht, einzuschätzen, wie sicher (oder weniger sicher) es tatsächlich ist. Herstelleraussagen allein sind an dieser Stelle nicht immer hilfreich. Gerade weniger bekannte Hersteller neigen tendenziell dazu, die Sicherheit ihrer Produkte übertrieben hoch einzuschätzen. Aber selbst gestandene Anbieter sind bei Weitem nicht unfehlbar.

Regelmäßig finden Experten schwerwiegende Sicherheitsprobleme in namhaften Produkten (D-Link, Linksys, Android und MikroTik, um nur einige zu nennen). Ein Prozess, der den Sicherheitsstatus eines Produkts bewertet und konkrete Nachweise liefert, die die Sicherheitsangaben eines Herstellers prüfen und sie untermauern (oder widerlegen), hilft allen beteiligten Parteien weiter.

Dabei führen unterschiedliche Wege zum Ziel. Traditionelle Ansätze berufen sich während der Entwicklungs- und Verifizierungsphase auf die interne Qualitätssicherung und lassen Penetrationstests und Zertifizierungen durch unabhängige externe Organisationen durchführen. Neuere Ansätze konzentrieren sich demgegenüber auf automatisierte Tests und Schwachstellen-Scans. Jede dieser Methoden hat ihre Vor- und Nachteile. Wenn man aber alle relevanten Probleme lösen will, kommt man nicht umhin einige oder sämtliche Methoden zu kombinieren.

Qualitätssicherung für Sicherheitsfunktionen

Die Qualitätssicherung (QS) ist eine im Entwicklungsprozess etablierte Phase, die normalerweise von einem internen Team betreut wird. Abhängig von der jeweiligen Organisationsstruktur sind die Verantwortlichen für die Qualitätssicherung selbst Teil des Entwicklungsteams oder es handelt sich um ein separates Team. Gegebenenfalls sogar unter separater Leitung, was für ein gewisses Maß an Unabhängigkeit sorgt.

Wie ein QS-Team strukturiert ist, wirkt sich direkt auf seine Herangehensweise aus, darauf, wie es vom Input seitens der Entwickler beeinflusst wird, und nicht zuletzt darauf, welche Tests in der Praxis durchführt werden. Ein gutes QS-Team verfolgt beim Testen einen Ansatz, der dem des potenziellen Gegners entspricht. Dabei wird etwa versucht, den Produktcode zu knacken oder ihn zum Scheitern zu bringen (Negativtests). Ein Ansatz, der dem von möglichen Angreifern oder Pen-Testern sehr ähnlich ist.

QS-Teams testen aber weit häufiger, ob der Produktcode die gewünschte Funktion wie erwartet erfüllt (Positivtests). Um ein Beispiel zu geben: Beim Test eines Software-Update-Mechanismus, überprüfen positive Tests wie robust der Code ist und ob er gültige Updates korrekt anwendet. Negativtests hingegen überprüfen, ob es sich um ungültige Update-Inhalte, falsche Signaturen oder ungültige Zertifikatsketten handelt.

Diese Negativfälle sind es, die mit einer höheren Wahrscheinlichkeit in einem Angriffsszenario auftauchen. In diesem Beispiel ist es sehr viel einfacher, die positiven Tests erschöpfend aufzuführen, statt alle negativen Randfälle. Die füllen leicht eine ganze Seite, wenn man etwa auf sämtliche Möglichkeiten eingehen will, wie eine Zertifikatsüberprüfung fehlschlagen kann.

Aus ähnlichen Gründen neigen QS-Teams bei starker Arbeitsauslastung oder Überlastung (die übliche Situation) dazu, sich auf die positiven Tests zu konzentrieren. Denn die sind zwingend nötig, um ein Produkt auf den Markt zu bringen. Im Umkehrschluss führt das oft dazu, dass die QS auf Negativtests verzichtet. Und genau die sind erforderlich, um zu prüfen, wie sicher ein Produkt ist.

Um Sicherheitsfunktionen ordnungsgemäß auszuführen brauchen QS-Teams dedizierte Ressourcen und sollten ausreichend auf das Thema Sicherheit hin spezialisiert sein. So oder so sollte man nicht darauf verzichten, weitere Sicherheitsexperten im Unternehmen regelmäßig einzubeziehen. Sie sollten das QS-Team anleiten und am Testplan mitarbeiten.

Die Hauptschwierigkeit liegt darin, dass dieser Prozess ressourcenintensiv ist und von der (notwendigen!) Konzentration der QS auf funktionale Tests ablenkt. Deshalb zögern viele Unternehmen, die erforderlichen QS-Ressourcen für sichere, internetfähige Produkte freizuschaufeln. Stattdessen entscheiden sich die meisten für externe Penetrationstests, um den Sicherheitsstatus eines Produkts zu ermitteln.

Messung der Code-Abdeckung im Rahmen von Penetrationstests

Penetrationstests zur Tiefenanalyse (Deep Analysis)

Penetrationstests sind Sicherheitsprüfungen, durchgeführt von internen oder externen Spezialisten mit einem offensiven Ansatz. Anstatt die Produktfunktionen zu prüfen, konzentrieren sich Penetrationstests nur darauf, Sicherheitslücken und -schwächen aufzudecken. Abhängig von der Vereinbarung mit dem Kunden verwenden Pen-Tester entweder die White- oder die Black-Box-Methode.

Diese gewähren jeweils unterschiedlich viel Einblick in die interne Dokumentation und sogar den Quellcode eines Produkts. Beim White-Box-Ansatz haben die Tester Zugang zu internen Informationen, ähnlich wie ein internes QS-Team sie hat. Beim Black-Box-Ansatz bekommen die Pen-Tester nur das aktive Produkt und alle öffentlich zugänglichen Dokumentationen, d. h. sie können nur auf die Informationen zugreifen, die auch einem realen Angreifer zur Verfügung stünden.

Die Pen-Tester richten dann eine Testumgebung ein, die mindestens ein betroffenes Gerät enthält, eventuell mit einer Netzwerkverbindung. In einem komplexen Szenario umfasst das Setup die gesamte Systeminstanz, einschließlich von Cloud- oder Serverkonten.

Dieses Setup erlaubt es einem Tester, das Gerät durch verschiedene Onboarding- und Update-Flows zu führen, ohne die Produktivumgebung des Herstellers zu gefährden – wie das zum Beispiel beim Testen von ungültigen Eingaben der Fall ist, die an die Cloud übermittelt werden. Bei vielen gängigen vernetzten embedded Produkten gehören auch die mobilen Apps zum Pen-Test Setup. Schließlich braucht der Benutzer sie, um das Gerät zu handhaben.

Pen-Tester sind Sicherheitsprofis, deren Wissen und Fähigkeiten eher auf der offensiven Seite liegen. Das ist hilfreich, um das Verhalten eines realen Angreifers zu simulieren. Um eine vollständige Schwachstellenbewertung zu erstellen, werden die externen Eigenschaften des Produkts untersucht; hierunter fallen die Netzwerkschnittstelle und die gesamte Kommunikation, die darüber abläuft, sowie die internen Eigenschaften wie der Inhalt des Firmware-Images.

Die Tester suchen nach Möglichkeiten, das Produkt zu kompromittieren, angefangen von vergleichsweise milderen Angriffsvarianten wie Denial-of-Service und dem Offenlegen von Daten, über intrusive Wege einen unautorisierten Zugriff zu erlangen und die Kontrolle zu übernehmen bis hin zu dauerhaften Modifikationen der Gerätelogik oder dem Beschädigen von Daten und/oder der Logik in der Cloud.

Penetrationstests durch eine externe Gruppe von Testern oder ein darauf spezialisiertes Unternehmen haben gegenüber internen Tests etliche Vorteile. Einmal durch das gebündelte Fachwissen, und zum anderen durch die organisatorische Unabhängigkeit. Ein guter Testbericht deckt die Sicherheitsprobleme eines Produkts umfassend ab. Trotzdem kann er sich in der Praxis als unzureichend erweisen.

Zeitmangel und eigeschränkte Sicht

Da die meisten Penetrationstests in Black-Box-Umgebungen durchgeführt werden, konzentrieren sich die Tester oft auf die extern exponierten Komponenten eines Produkts, wie Web-Anwendungen und Remote-Login-Schnittstellen. Das geht meist auf Kosten der anfälligen internen Funktionsmerkmale. Dazu kommt, dass den Testern nur begrenzt Zeit zur Verfügung steht.

Nicht selten besteht der Ehrgeiz dann darin, möglichst eindrucksvolle Schwachstellen zu finden. Solche „Low Hanging Fruits“ konzentrieren sich aber zumeist auf Angriffe, die leicht durchführbar sind. Eine eingehende Analyse der einem Produkt zugrundeliegenden Sicherheitsarchitektur ist unter Umständen gar nicht im Interesse der Tester. Es sei denn, es handelt sich um Schwachstellen, die sich leicht ausnutzen lassen.

Ein weiterer Nachteil: Penetrationstests sind subjektiv und in hohem Maße von den Erfahrungen der jeweiligen Pen-Tester abhängig. Zwei verschiedene Teams werden nie ein und denselben Bericht erstellen. Die Ergebnisse sind immer auch das Resultat von Variablen wie der Expertise des Testers und den verwendeten Test-Tools.

Gute Penetrationstestteams verwenden automatisierte Tools, angefangen bei Portscannern wie z. B. nmap und weiterhin mit Tool-Suiten wie Metasploit oder Detectify. Automatisierte Tools erleichtern den anfänglichen Erkundungsprozess, erstellen ein Gesamtbild der Angriffsfläche eines Produkts, finden erste Einstiegspunkte für Angreifer und so weiter.

Software-Scan-Tools unterstützen Pen-Tester dabei, schwerwiegende Sicherheitsschwachstellen zu finden. Das sind beispielsweise bekannte Schwachstellen in Bibliotheken von Dritten und Open Source Code. Solche Scans führen fast zwangsläufig in Bereiche, die man gründlicher untersuchen sollte, oder sie verschaffen den Testern Zugang zur Codebase eines Produktes, die sich für weitere Angriffe ausnutzen lässt. Tools, die hier noch einen Schritt weitergehen, liefern differenzierte Ergebnisse und enthüllen auch tiefer liegende Architekturprobleme. Im Folgenden werden wir uns automatisierte Tools etwas genauer ansehen.

Unabhängige Sicherheits- und Compliance-Zertifizierungen

Pen-Testberichte lassen sich als Nachweis für eine unabhängige Zertifizierung verwenden. Wenn man Kunden allerdings von der Sicherheit eines Produkts überzeugen will, ist es in der Regel besser, die Zertifizierung über ein spezielles Verfahren zu erlangen. Einige Branchen und Märkte verlangen Zertifizierungen durch ein unabhängiges Labor und Standard-Compliance. Das ist besonders dann nachvollziehbar, wenn Sicherheit eine zentrale Rolle spielt.

Im Automobil-, Medizin- und Industriesektor ist Compliance über verschiedene Zertifizierungen gesetzlich vorgeschrieben. Wenn es aber um vernetzte, internetfähige Produkte, wie Embedded- oder IoT-Geräte, geht, sind die Compliance-Anforderungen im Bereich Cybersicherheit weit weniger klar definiert. Allerdings bringen Regulierungsbehörden zunehmend entsprechende Gesetze und Kennzeichnungssysteme auf den Weg.

In anderen Branchen ist eine Zertifizierung vielfach nicht zwingend vorgeschrieben. Dennoch verspricht sie bei zunehmend sicherheits- und datenschutzaffinen Kunden einen Wettbewerbsvorteil. Aus diesem Grund reichen Anbieter ihre Produkte häufig zur unabhängigen Zertifizierung ein.

Zertifizierungsprogramme für Cybersicherheit werden in der Regel um ein Standarddokument herum definiert. Die Bandbreite der relevanten Standards reicht von geschlossenen und proprietären Standards, die typischerweise von der zertifizierenden Organisation selbst entwickelt wurden (z. B. die UL-2900-Familie von Standards), über freie und offene Standards (z. B. die NIST-CMVP-Dokumente, ENISA- oder IoTSF-Standards) bis hin zu allem was dazwischen liegt (z. B. die Dokumente für ISA/IEC 62443, die nach einer E-Mail-Registrierung verfügbar sind).

Für jeden Standard muss der Anbieter in der Regel alle Anforderungen hinsichtlich von Verfahren und Technik umsetzen. So erwartet man von ihm, dass er detaillierte Nachweise vorlegt, aus denen hervorgeht, in welcher Weise das Produkt dem Standard entspricht oder wo es davon abweicht. Der Zertifizierungsprozess selbst verläuft sehr unterschiedlich.

Am einen Ende des Spektrums steht die Selbstzertifizierung, bei der ein Anbieter lediglich einen Fragebogen ausfüllen und die Antworten für potenzielle Kunden veröffentlichen muss. Am anderen Ende steht Compliance aufgrund einer Prüfung durch eine unabhängige Organisation. Dabei führt ein Labor eigene, umfassende Produkttests durch und überprüft die vom Anbieter eingereichte Dokumentation.

In beiden Fällen verbleibt ein Großteil der Beweislast beim Anbieter. Er liefert das Produkt und muss die dazugehörige Dokumentation erstellen. Der Entwicklungsaufwand ist beträchtlich. Dazu kommen die Kosten für die Zertifizierungsstelle und die beteiligten Labors oder Berater. Selbst nach einer erfolgreichen Zertifizierung können Folgekosten anfallen. Wird ein Produkt aktualisiert oder eine Produktlinie erweitert, muss nicht selten auch die Zertifizierung aktualisiert oder ganz erneuert werden.

Was genau Cybersicherheitsstandards beinhalten ist sehr unterschiedlich. Einige Standards widmen sich verstärkt der Dokumentation des Anbieters und dem Sicherheitsprozess selbst (einige schreiben sogar Penetrationstests oder die Verwendung automatisierter Tools zum Auffinden von Sicherheitsschwachstellen und bekannter Exploits zwingend vor), andere konzentrieren sich auf sichere Codierungstechniken. Noch technischere widmen sich der Gerätearchitektur und -konfiguration oder enthalten zumindest einige technische Kapitel.

Die meisten Standards halten ihre technischen Anforderungen auf einem relativ hohen Niveau. Allerdings formulieren nur wenige explizit technische Anweisungen wie man die Anforderungen am besten erfüllt (einige positive Beispiele sind die CIS-Benchmarks, DoD STIGs oder der AGL Security Blueprint). Für einen Anbieter ist es deshalb nicht ganz einfach, sein anfängliches Compliance-Niveau abzuschätzen, bevor er mit dem Zertifizierungsprozess beginnt. Das treibt die Kosten in die Höhe. Automatisierte Tools tragen dazu bei, Aufwand und Kosten zu senken.

Der Nutzen von Penetrationstests

Automatisierte Schwachstellen-Scans für objektive Ergebnisse

Es gibt viele Arten von automatisierten Tools, die jeweils unterschiedliche Aspekte der Produktsicherheit überprüfen. Es existiert eine Reihe von Tools, die das gesamte IoT-Ökosystem abdecken, also eingebettete, Cloud-, Web- und mobile Komponenten.

Einige verwenden den dynamischen Ansatz, bei dem ein aktives Gerät über das Netzwerk gescannt wird, um den Sicherheitsstatus hinsichtlich von Webserver und Kommunikation zu diagnostizieren. Andere verwenden den statischen Ansatz, bei dem der Quellcode oder das Binary Image eines Geräts gescannt werden.

Dynamische Tools brauchen ein aktives Gerät. Dahingehend sind statische Tools flexibler. Sie benötigen nur eine Datei, die über ein Web-Interface heruntergeladen wird. Ein weiterer Unterschied besteht darin, dass dynamische Tools auf das externe Verhalten des Geräts limitiert sind, während statische Tools auch sein Innenleben untersuchen.

Statische Tools decken sichere Codierungspraktiken ab, finden bekannte Sicherheitsschwachstellen und Exploits, identifizieren potenzielle Zero-Day-Schwachstellen und zeigen sogar verschiedene Konfigurations- und Architekturprobleme auf den untersten Anwendungsebenen (Bootloader und Betriebssystem-Interna) bis hin zu den oberen Ebenen auf. Ein gut entwickeltes Tool kann Hunderte oder sogar Tausende von einzelnen Scans oder Tests durchführen.

Dabei haben statische Tests den Vorteil, dass sie in wenigen Minuten die Art von Ergebnissen liefern, für die Penetrationstester manuell Tage oder Wochen brauchen würden. Der gesamte Testprozess verläuft automatisch und wird nahtlos in einen kontinuierlichen Integrations- beziehungsweise Entwicklungsfluss integriert. Dabei kann man potenziell jedes Produkt und jede Version scannen – ohne Automatisierung an sich schon ein unmögliches Unterfangen.

Tools sind wiederverwendbar und objektiv

Solche Tools zu entwickeln ist mit Kosten verbunden, denn jede einzelne Scan-Funktion muss auf jedes Betriebssystem portiert und die Abdeckung für jeden Dateisystemtyp und jede Softwarekomponente hinzugefügt werden. Hat man den Aufwand aber einmal betrieben, zahlt er sich aus. Denn die Scanner kann man immer wieder einsetzen, und sie erlauben eine schnelle On-Demand-Analyse.

Wer ein gutes, automatisiertes Tool für Schwachstellen-Scans anbieten will, der investiert oft jahrelang in Forschung und Entwicklung, an der im Übrigen auch Penetrationstester maßgeblich beteiligt sind. Die Expertise von solchen Forschungsteams fließt in die Analyse von Produkten, Plattformen und Softwarekomponenten ein. Umgekehrt liefern diese ihrerseits Erkenntnisse, die den Weg zurück in die Entwicklung automatisierter Scanner finden.

Im Gegensatz zu einem manuell erstellten Bericht eines Pen-Testers hat die Automatisierung noch einen weiteren Vorteil: sie ist objektiv. Ein und dasselbe Tool liefert immer objektive Ergebnisse zu einem Gerät oder einer Softwarekomponente. Ein Aspekt, der automatisierte Tools für externe Zertifizierungen sehr hilfreich macht.

Dazu kommt, dass solche Tools auch externe Standards beinhalten. Sie analysieren beispielsweise die Firmware eines Geräts und geben einen Defizitbericht in Bezug auf einen bestimmten Standard aus. Der gibt Aufschluss über den nötigen Zeit- und Arbeitsaufwand, um diesen Compliance-Anforderungen zu entsprechen. Das lässt sich in der Regel in wenigen Minuten erledigen, während der gleiche Prozess, manuell durchgeführt, Wochen für die Dokumentation und Analyse in Anspruch nehmen würde.

Sicherheitsprüfung – ein Must-Have

Sicherheitsprüfungen sind notwendig, daran besteht kein Zweifel, aber es gibt verschiedene Wege. Manuelle Methoden erzielen hervorragende Ergebnisse, erfordern aber ein engagiertes und entsprechend ausgebildetes Team sowie Zeit und Aufwand. In einigen Fällen führen sie trotzdem zu verzerrten Ergebnissen. Insbesondere dann, wenn ein Auftraggeber die Anreize falsch gesetzt hat.

Der Markt für vernetzte internetfähige Geräte (IoT) ist hoch dynamisch. Umfangreiche Produktlinien, viele unterschiedliche Varianten und eine möglichst schnelle Markteinführung sind die Regel. Anbieter sollten deshalb automatisierte Tests gegenüber manuellen in Betracht ziehen.

Die unabhängige Zertifizierung hat ihre eigenen Nachteile, vor allem hohe Kosten und langwierige Arbeitsprozesse und gegebenenfalls Aktualisierung oder gar Neuzertifizierung. Andererseits kommt man in bestimmten Märkten um eine unabhängige Zertifizierung nicht herum. Je nach Art und Umfang ist sie vermutlich der tauglichste Indikator für ein sicheres Produkt und liefert somit einen Wettbewerbsvorteil. Automatisierte Tools unterstützen auch unabhängige Zertifizierungen.

Der beklagenswerte Sicherheitslevel vieler IoT-Produkte schafft es regelmäßig in die Schlagzeilen. Aber inzwischen sind die Regulierungsbehörden hellhörig geworden und mischen bei den Vorgaben zu Sicherheitsstandards kräftig mit. Sicherheitsprüfungen sind folglich unabdingbar. Automatisierte Tools erlauben eine detaillierte Sicherheitsprüfung, On-Demand und für eine breite Palette von vernetzten Produkten. Das wird den Anteil solcher Tools innerhalb von Sicherheitsprüfungen weiter steigen lassen.

Statische Analyse zur Sicherheitstest-Toolbox hinzufügen

Sieben Eigenschaften hochsicherer Geräte

* Harry Zorn ist Vice President EMEA bei Vdoo.

Dieser Beitrag erschien zuerst auf unserem Partnerportal Dev-Insider.de. Verantwortlicher Redakteur: Stephan Augsten.

(ID:47119607)