© Sebastien Decoret / 123RF.com

Konformitätstest, Penetrationstest, Schwachstellen-Scan und Red Teaming – so heißen unterschiedliche Sicherheitsuntersuchungen. Wir erklären, was sie bedeuten.

Ob Pentest oder Schwachstellen-Scan, Red Teaming oder Konformitätsanalyse – allen diesen Vorgehensweisen liegt dieselbe Frage zugrunde: Ist das untersuchte System sicher? Die Methoden, mit denen man sich einer Antwort auf diese Frage nähert, unterscheiden sich jedoch erheblich. Das beginnt bereits bei der Frage, welcher Teil des Systems überhaupt analysiert werden soll. Schließlich handelt es sich oft um ein Zusammenspiel aus organisatorischen, personellen und technischen Komponenten.

Dieser Artikel geht im Wesentlichen auf die Analyse der technischen Komponenten ein. Probleme der organisatorischen und personellen Sicherheit stehen hier nicht im Fokus. Die Frage, ob der Sachbearbeiter freimütig jeden E-Mail-Anhang öffnet oder welche Risiken fehlende Regelungen für BYOD bergen, zählt aber dennoch häufig zu den Aspekten von Red Teaming.

Dieser Artikel erläutert die häufig verwendeten Begriffe und klärt Missverständnisse auf. Viele davon rühren nicht zuletzt daher, dass es an einer offiziellen Definition fehlt und verschiedene Organisationen die Begriffe teilweise widersprüchlich verwenden. In der Praxis sollten Sie darum zunächst die Definition der verwendeten Begriffe mit dem Dienstleister klären, den Sie mit einer Sicherheitsprüfung beauftragen möchten. Nicht selten stellt man als potenzieller Auftraggeber dann fest, dass es sich beim vermeintlichen Penetrationstest eher um einen Schwachstellen-Scan handelt.

Selbst wenn es Ihnen als Auftraggeber peinlich vorkommt, ist es auf jeden Fall besser nachzufragen als nachträglich festzustellen, dass die gut gemeinte (und vielleicht sogar gut gemachte) Arbeit überhaupt nicht den eigenen Anforderungen entspricht. Wie so häufig gilt: Doofe Fragen sind kluge Fragen!

Das setzt voraus, dass Sie als Auftraggeber die eigene Motivation klar definieren und offen mit dem Sicherheitsdienstleister Ihres Vertrauens kommunizieren. Wollen Sie die Sicherheit Ihrer Infrastruktur prüfen, damit der nächste Verschlüsselungstrojaner nicht gleich das ganze Unternehmen in den Abgrund reißt? Oder wollen Sie verhindern, dass Ihr Produkt aus den ganz falschen Gründen die Überschriften der Fachpresse füllt? Gibt es eventuell regulatorische Anforderungen an Sie oder Ihre Kunden, die eine unabhängige Überprüfung zwingend erforderlich machen?

Insbesondere die gesetzlichen Anforderungen verändern sich mittlerweile enorm schnell. Für den europäischen Markt gehören dazu insbesondere NIS2 [1] und CRA [2] (siehe Kasten “Cyber Resilience Act”). Aber auch in Übersee tut sich momentan eine Menge. Die Food and Drug Association (FDA) verlangt bei der Zulassung medizinischer Geräte in den USA zum Beispiel einen Nachweis dafür, dass ein Penetrationstest absolviert wurde.

Konformitätsbewertung

Ein etabliertes Mittel, um die IT-Sicherheit zu überprüfen, sind Konformitätsbewertungen. Mit ihnen wird kontrolliert, ob ein System festgelegte Anforderungen erfüllt. Der Grundgedanke: Wenn ich die einschlägigen und von Experten ersonnenen Anforderungen umsetze, dann ist mein System sicher.

Beispielsweise lässt sich anhand der Technischen Richtlinie TR-02102-2 [3] die Kommunikation mittels TLS bewerten. Die Richtlinie wurde vom Bundesamt für Sicherheit in der Informationstechnik (BSI [4]) entwickelt und wird dort auch gepflegt. Sie beschreibt, wie ein HTTPS-Server zu konfigurieren ist, damit der Verkehr nicht mitgelesen werden kann. Auf diese Weise muss sich der Prüfer nicht mit den Untiefen der verwendeten kryptografischen Protokolle auseinandersetzen, sondern lediglich das Ist mit dem Soll abgleichen. Eine solche Prüfung kann ein Dienstleister übernehmen, sie lässt sich aber mit geringem Aufwand auch selbst erledigen.

Die Grenzen einer solchen Konformitätsbewertung sollte der Nutzer jedoch verstehen. Beispielsweise ist die lückenlose Umsetzung von TR-02102-2 kein Garant dafür, dass ein aktiv in die Verbindung eingreifender Dritter die Daten nicht entschlüsselt. Dieser Aspekt – Stichpunkt Zertifikatspfad-Validierung – wird nämlich von einer anderen Richtlinie aufgegriffen, der TR-02103. Vor einer Konformitätsbewertung sollten Sie also prüfen, welche Anforderungskataloge sinnvoll und angemessen sind. Dazu stellt unter anderem das Center for Internet Security (CIS [5]) entsprechende Benchmarks bereit.

Ein offensichtliches Manko eines solchen Verfahrens: Man kann die Konformität nicht überprüfen, wenn es keine entsprechenden Anforderungen gibt. Ob also die Schutzmaßnahmen eines selbst entwickelten Kommunikationsprotokolls oder ob die Authentifizierung in einer selbst entwickelten Software umgangen werden können, lässt sich auf diesem Wege nicht ermitteln.

Penetrationstest

Eine andere Methode ist der Penetrationstest. Die simple Idee: Lernen vom Angreifer. Die Rolle des Angreifers übernimmt dabei der Penetrationstester. Er attackiert das System unter kontrollierten Rahmenbedingungen. Dazu kapert er beispielsweise eine Sitzung auf einem Server, um über eine Firewall in ein internes Netzwerk einzudringen oder vermeintlich sichere Kommunikation einzusehen. Die dadurch ermittelten Schwachstellen lassen sich im Anschluss beheben, sodass ein wirklicher Angreifer sie nicht mehr ausnutzen kann.

Hier stellt sich häufig die Frage, ob und inwieweit man den Pentester dabei durch nicht öffentlich verfügbare Informationen unterstützt. Ein häufig vorgebrachtes Argument, solche Informationen nicht zur Verfügung zu stellen, lautet, man wolle das Angriffsgeschehen möglichst realistisch gestalten. Ein solcher Blackbox-Ansatz hat aber erhebliche Nachteile: So muss der Penetrationstester gezwungenermaßen viel Zeit und damit auch viel vom Budget des Kunden darauf verwenden, die grundlegende Funktionsweise des Systems zu erforschen. Warum sollten Sie dem Dienstleister gutes Geld bezahlen, um herauszufinden, was Sie ohnehin schon wissen?

Bei einem Grey-Box- oder White-Box-Verfahren stellt man dem Pentester entsprechende Informationen teilweise oder vollständig zur Verfügung. Zudem kann es sehr sinnvoll sein, ihm Zugang zu den Systemen zu geben. Kann der Penetrationstester die Auswirkungen seiner eigenen Angriffe von innen beobachten, fällt es ihm häufig viel leichter, Schwachstellen zu entdecken. Als Faustregel gilt: Machen Sie es dem guten Angreifer leicht, um es dem bösen Angreifer schwer zu machen.

Sie müssen sich ferner darüber im Klaren sein, dass die Angriffe des Penetrationstesters ungeachtet ihrer positiven Intention erhebliche Folgen haben können. Greift er einen produktiv genutzten Dienst an und schafft es, ihn zum Absturz zu bringen, kann der Schaden weitaus größer sein als der Nutzen. Hier gilt es also, vorab sinnvolle Arbeitsbedingungen zu schaffen. Schließlich soll es ja die Aufgabe sein, den Kunden des Pentesters vor Schwachstellen zu warnen, bevor das Kind in den Brunnen fällt, aber nicht, es selbst in den Brunnen zu werfen.

Dank weitverbreiteter Virtualisierung lassen sich geeignete Bedingungen oft durch das Klonen der relevanten Systeme erzeugen. Daneben können Test- und Entwicklungssysteme ein ungefährliches Hacken unter realistischen Bedingungen ermöglichen. Besonders unproblematisch ist die Untersuchung von eingebetteten Systemen, sofern man eine Beschädigung von Testsystemen hinnehmen kann. Clouds dagegen erschweren Penetrationstests unter Umständen erheblich. Dabei gilt es möglicherweise außerdem, den Cloudbetreiber einzubeziehen.

Schwachstellen-Scan

Eine automatisierte Form des Penetrationstests ist der Schwachstellen-Scan. Dabei ermittelt ein Werkzeug Schwachstellen in Diensten und Anwendungen, indem es sie mit Schwachstellendatenbanken abgleicht. Dank dieser Automatisierung lassen sich entsprechende Scans kostengünstig realisieren.

Auf diese Weise kann man jedoch lediglich bereits bekannte Schwachstellen erkennen. Für Standardsoftware wie den Webserver Apache stellt das kein Problem dar. Für weniger verbreitete Software existieren solche Informationen oft nicht. So kann es vorkommen, dass ein menschlicher Angreifer mit geringem Aufwand erkennt, dass ein System sperrangelweit offen steht, der Schwachstellen-Scanner dagegen wunschlos glücklich ist. Auch erweist es sich oft als schwierig, den genauen Patch-Stand einer Anwendung zu ermitteln, was zu False-Positive-Meldungen führen kann.

Verwechseln Sie also einen umfassenden Penetrationstest nicht mit einem Schwachstellen-Scan. Sie sollten auch kritisch sein, wenn man Ihnen statt eines Penetrationstests einen Schwachstellen-Scan als “Einstieg” anbietet. Im besten Fall identifizieren Sie auf diese Weise unsichere oder ungepatchte Systeme in Ihrem Netzwerk. Im ungünstigsten Fall erhalten Sie eine lange Liste von False Positives, die Sie dann abarbeiten müssen.

Schwachstellen-Scanner sind sehr sinnvolle Werkzeuge, wenn man sie kontrolliert und schrittweise nutzt. Ein Scan des gesamten Unternehmensnetzwerks kann aber auch nach hinten losgehen.

Red Teaming

Eine weitere Methode, die Sicherheit in Ihrem Unternehmensnetz zu hinterfragen, ist das Red Teaming. Hierbei handelt es sich um den in der Literatur am wenigsten einheitlich verwendeten Begriff.

Oft steht bei einer Red-Teaming-Übung nicht das Identifizieren einzelner Schwachstellen im Vordergrund. Stattdessen werden eine oder mehrere der folgenden Fragen in den Fokus genommen: Erkennt die Organisation, dass sie angegriffen wird? Kann sie den Angriff erfolgreich unterbinden? Lässt sich der Regelbetrieb anschließend wieder herstellen?

Je nach Schwerpunktsetzung lässt sich eine solche Übung ganz unterschiedlich umsetzen. Beispielsweise können Sie Ihre Organisation vorab über den Angriff informieren und ein Blue Team zur Abwehr bereitstellen oder aber den Angriff überraschend stattfinden lassen.

Vor einer solch umfassenden Angriffssimulation fällt einiger Aufwand für die Vorbereitung an, um einen Erkenntnisgewinn zu erzielen und die IT-Systeme nicht unverhältnismäßig zu gefährden. Ganz sicher eignet sich eine solche Übung daher nicht als Einstieg in den Themenkomplex der Sicherheitsuntersuchungen.

Empfehlungen

Ganz gleich, welche Methode Sie wählen: Einige Punkte sind immer zu beachten. So ist eine Geheimhaltungsvereinbarung, ein Non-Disclosure Agreement (NDA) obligatorisch, wenn Sie einen Sicherheitsdienstleister beauftragen.

Zudem sollten Sie sich vorab ein kostenfreies Vervielfältigungs- und Weitergaberecht des Ergebnisberichts einräumen lassen. Ansonsten könnte eine effiziente Beseitigung der Schwachstellen durch einen weiteren Dienstleister nur nach Zustimmung der Pentester erfolgen. Auch Aufträge für nachfolgende Penetrationstests lassen sich nur schwer an ein neues Team vergeben, wenn das die vorangegangenen Ergebnisse nicht einsehen darf.

Ferner sollten beiden Seiten vorab Ansprechpartner für den Notfall benennen. Sie oder Ihre Vertreter müssen über den gesamten Testzeitraum verfügbar sein. Wird ein wichtiger Dienst zum Absturz gebracht oder ein großes Loch in der Internet-Firewall gefunden, soll die Benachrichtigung schließlich nicht erst nach dem dreiwöchigen Sommerurlaub erfolgen.

Daneben sollten Sie vorab die zu nutzenden Kommunikationskanäle vereinbaren, um eine sichere Kommunikation zu ermöglichen. Wer den Schwachstellenbericht nach dem Penetrationstest über eine unverschlüsselte E-Mail-Kommunikation versendet, schafft womöglich die gravierendste Schwachstelle erst selbst.

Die Methodik

Als Kunde muss Ihnen bewusst sein, dass die verschiedenen Tests sich auch in der Methodik unterscheiden. Während der Tester bei einem Vulnerability Scan (Schwachstellen-Scan) ein standardisiertes Tool verwendet, das auch Sie selbst mit einem geringen Lernaufwand verwenden könnten, sind klassische Penetrationstests und Red Teaming wesentlich komplizierter.

Bei einem Penetrationstest folgt der Tester einem strukturierten Ansatz. Nach der Festlegung des Umfangs und des Scopes macht er sich mit dem System vertraut. Dabei identifiziert er die verfügbaren Kommunikationsschnittstellen. Meist verhindert die zeitliche Begrenzung des Tests eine vollständige Betrachtung sämtlicher Schnittstellen. In solchen Fällen hat sich ein risikobasiertes Vorgehen bewährt. Dabei wählt der Tester jene Schnittstellen aus, bei denen er aufgrund seiner Erfahrung das größte Risiko für die Sicherheit des Systems erwartet.

Für die Analyse sollte der Tester einer standardisierten Methodik folgen. Dabei haben sich verschiedene Vorgehensweisen etabliert. Drei davon gelten als allgemein akzeptiert.

Der OWASP Testing Guide des Open Web Application Security Projects (OWASP [6]) bietet einen umfassenden Leitfaden für das Testen von Webanwendungen, der Best Practices und Techniken für Sicherheitsprüfungen umfasst. Diese Vorgehensweise bietet sich besonders bei Webapplikationen an. Darüber hinaus veröffentlicht das Projekt regelmäßig Top-10-Listen.

Ein zweiter anerkannter Leitfaden ist NIST SP 800-115 [7]. Das National Institute of Standards and Technology hat einen speziellen Leitfaden für technische Sicherheitsbewertungen veröffentlicht, der unter anderem Penetrationstests behandelt.

Als drittes nennenswertes Verfahren hat sich der Penetration Testing Execution Standard [8] etabliert: PTES bietet einen strukturierten Ansatz für die Pentests und deckt verschiedene Phasen des Testprozesses ab.

ISO/IEC 27001 [9], ein allgemeiner Standard für Informationssicherheitsmanagementsysteme, kann ebenfalls als Grundlage für die Sicherheitsbewertungen und Penetrationstests dienen. Und schließlich gibt es CREST: Das Council for Registered Ethical Security Testers [10] bietet Zertifizierungen und Standards für Penetrationstests an und fördert bewährte Verfahren in der Branche.

Diese Standards helfen dabei, die Qualität und Konsistenz von Penetrationstests zu gewährleisten und sicherzustellen, dass die Tests umfassend und effektiv erfolgen. Wenn der Tester diese Standards seinem Test zugrunde legt und in seinem Bericht referenziert, gewährleistet das eine gewisse Vergleichbarkeit.

Red Teaming ist flexibler und kreativer: Die Tester nutzen eine Vielzahl von Techniken, um in das System einzudringen, und können auch unkonventionelle Methoden anwenden, um die Verteidigung zu umgehen. Dabei greifen sie häufig auf das MitreATT@CK Framework [11] zurück, das unterschiedliche Angriffstechniken für die verschiedenen Phasen des Red Teaming bereitstellt (siehe Tabelle “Red-Teaming-Phasen”). Grundsätzlich führt das Red Team dabei potenziell Angriffe in allen Phasen durch (Abbildung 1). Auch künstliche Intelligenz kann dabei helfen (Kasten “KI und Pentests”).

Abbildung 1: Das MitreATT@CK Framework stellt die verschiedenen Angriffsmethodiken nebeneinander dar. Quelle: mitre.org

Der Bericht

Als Ergebnis eines Pentests entsteht in der Regel ein detaillierter Bericht über gefundene Schwachstellen, einschließlich Empfehlungen zu deren Behebung. Beim Red Teaming stellt der Bericht oft eine umfassende Analyse der Sicherheitslage dar, einschließlich der Reaktionsfähigkeit des Sicherheitsteams und der Identifizierung von Schwachstellen in den Sicherheitsprozessen.

Der Bericht sollte die eingesetzte Methodik referenzieren und einen strukturierten Aufbau haben. Dabei sollte der Tester in einer einleitenden Zusammenfassung die wesentlichen Ergebnisse allgemein verständlich darstellen. Dieses Abstract sollte eine Seite nicht überschreiten und die wichtigsten Erkenntnisse erwähnen, einschließlich der identifizierten Schwachstellen und deren Schweregrad.

Der restliche Bericht stellt dann die weiteren Details dar. Er beginnt mit einem Abschnitt, der eine kurze Übersicht über den Zweck des Penetrationstests, dessen Ziele und den Umfang gibt. Insbesondere sollte er die Aspekte benennen, die nicht betrachtet wurden. Darauf folgt eine Beschreibung der verwendeten Testmethoden und -techniken, einschließlich der eingesetzten Werkzeuge.

In einem eigenen Kapitel sollte eine detaillierte Schwachstellenanalyse erfolgen. Diese ausführliche Beschreibung jeder identifizierten Schwachstelle enthält Informationen zu den technischen Details, möglichen Auswirkungen und dem Nachweis der Schwachstelle, etwa durch Screenshots oder Logs. Zu jeder Schwachstelle sollte der Tester auch Empfehlungen formulieren, die konkrete Vorschläge zur Behebung beinhalten.

Der Bericht schließt mit einer finalen Bewertung der Sicherheitslage des Systems oder der Anwendung, basierend auf den Testergebnissen. Zusätzliche Informationen, wie ein Glossar, Referenzen oder detaillierte technische Daten, die für das Verständnis des Berichts hilfreich sein können, sollten in einem Anhang zusammengefasst werden.

Bewertung

Für die Vergleichbarkeit der Schwachstellen und ihre Beurteilung ist deren richtige Einordnung wichtig. In einem Penetrationstest identifizierte Schwachstellen können auf verschiedene Weisen bewertet werden, um ihre Schwere und potenzielle Auswirkungen auf die Sicherheit des Systems zu bestimmen. Dazu hat sich eine Reihe von Verfahren etabliert.

Das prominenteste ist sicherlich das Common Vulnerability Scoring System (CVSS [12]). Das weitverbreitete System zur Bewertung von Schwachstellen (Abbildung 2) bietet eine standardisierte Methode zur Berechnung eines Scores, der die Schwere einer Schwachstelle auf einer Skala von 0 bis 10 bewertet. Der Score berücksichtigt Faktoren wie die Ausnutzbarkeit, die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit sowie die Reaktionsmöglichkeiten. Ein Bericht sollte immer den CVSS Score jeder Schwachstelle angeben. Achtung: Den Score gibt es in unterschiedlichen Versionen, aktuell ist die Version 4.0.

Abbildung 2: Das Common Vulnerability Scoring System nutzt unterschiedliche Vektoren, um zu einer belastbaren Bewertung einer Schwachstelle zwischen 0 und 10 zu gelangen. Quelle: first.org

Als hilfreich erweist sich oft eine Schweregradkategorisierung, die Schwachstellen in Rubriken wie kritisch, hoch, mittel und niedrig einteilt. Diese Kategorisierung hilft, Prioritäten für die Behebung zu setzen und Ressourcen effizient zuzuweisen. Sie lässt sich direkt aus dem CVSS Score ableiten: Niedrig entspricht CVSS 0.1 bis 3.9, mittel CVSS 4.0 bis 6.9, hoch CVSS 7.0 bis 8.9 und kritisch CVSS 9.0 bis 10.0.

Auch eine Risikoanalyse ist sinnvoll. Sie bewertet die Wahrscheinlichkeit, dass eine Schwachstelle ausgenutzt wird, sowie die potenziellen Auswirkungen auf das Unternehmen. Das kann durch die Berücksichtigung von Faktoren wie der Angreifbarkeit des Systems, der Sensibilität der Daten und der vorhandenen Sicherheitsmaßnahmen erfolgen. Für bekannte Schwachstellen (CVEs [13]) gibt es eine allgemeine standardisierte Vorgehensweise, das Exploit Prediction Scoring System (EPSS [14]). Es bewertet die Wahrscheinlichkeit, dass eine Schwachstelle ausgenutzt wird.

Eine Business Impact Analysis (BIA [15]) ordnet ein, wie sich eine Schwachstelle auf die Geschäftsabläufe auswirken könnte. Sie berücksichtigt Aspekte wie finanzielle Verluste, Reputationsschäden und rechtliche Konsequenzen. Diese Analyse kann jedoch häufig nicht allein der Penetrationstester leisten, da er nicht über die entsprechenden Hintergrundinformationen verfügt.

Schließlich gibt es noch eine Bewertung, die auch den Kontext der Schwachstelle berücksichtigt. Dazu gehören beispielsweise die spezifische Umgebung, in der das System betrieben wird, und die vorhandenen Sicherheitsmaßnahmen. Eine Schwachstelle kann in einem bestimmten Kontext kritischer sein als in einem anderen. Das CVSS-Modell unterstützt diese Betrachtung durch die Environmental Metrics.

Fazit

Durch die Kombination aller Methoden können Sicherheitsteams eine fundierte Entscheidung darüber treffen, welche Schwachstellen zuerst behoben werden sollten und wie sich die Sicherheitslage des Systems insgesamt verbessern ließe. Ein gut strukturierter Bericht hilft den Beteiligten, die Erkenntnisse zu diskutieren, die Sicherheitslage besser zu verstehen und geeignete Maßnahmen zu ergreifen. (jcb/jlu)