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.

(ID:47103349)