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

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.

(ID:47103349)