Richtig penetrant : Best Practices für Penetrationstests im Rahmen eines ganzheitlichen Sicherheitskonzepts

Von Severin Quell und Aaron Brown, Köln

Mittlerweile gehört das professionelle Management der IT-Sicherheit zu den wichtigsten Aufgaben von Vorständen und Geschäftsführern. Mittelstand, Konzerne und besonders Betreiber kritischer Infrastrukturen (KRITIS) müssen sehr detaillierte Compliance-Regeln im Umgang mit Daten und IT-Infrastrukturen umsetzen. Die EU Datenschutzgrundverordnung (DSGVO) fordert in Artikel 32 „ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung“. Noch konkreter werden das IT-Sicherheitsgesetz (IT-SiG) mit den branchenspezifischen Sicherheitsstandards (B3S) sowie die KRITIS-Verordnung: Das IT-SiG fordert ein Sicherheitskonzept und Maßnahmen, die in Echtzeit über Sicherheitsausfälle informieren. KRITIS-Betreiber sollten ein Intrusion-Detection/Prevention-System (IDS/IPS) oder ein Security-Information- und -Event-Management (SIEM) einsetzen.

Angesichts der rasanten technischen Entwicklung und der kriminellen Energie von Angreifern sind diese Anforderungen ein ständiger Kampf für Unternehmen, mit der Härtung ihrer IT-Systeme Schritt zu halten. Denn häufig spielen veraltete oder unzureichende Sicherheitskonzepte, mangelhaft informierte Mitarbeiter sowie Schwachstellen in Webanwendungen, Hard- und Software sowie unpassende Netzwerkeinstellungen Cyberkriminellen in die Hände. Bleibt auch nur bei einer IT-Komponente im Netzwerk eine bekannte Schwachstelle offen, kann ein Angreifer ins Netzwerk vorstoßen – auch Phishing-Methoden werden immer raffinierter und können Mitarbeiter zum Anklicken von Anhängen und Links verleiten, die Schadcode enthalten.

Umfassende Prüfung

Angesichts dessen müssen Unternehmen ihre Informationssicherheitsmanagementsysteme (ISMS) noch häufiger Wirksamkeitsüberprüfungen unterziehen. Dazu gehören regelmäßige Sicherheitsanalysen, Schwachstellenanalysen und Penetrationstests, wobei erstere nur bekannte Lücken aufdecken können.

Die DSGVO, aber auch das IT-SiG (mit B3S und KritisV) bilden den Rahmen für umfassende Compliance-Anforderungen, die Unternehmen heute erfüllen müssen. Die Neufassung des § 8a, Abs. 1 des IT-SiG (Referentenentwurf) formuliert noch deutlicher als bisher, was von KRITIS-Betreibern künftig gefordert wird. Diese sollen verpflichtet werden, „angemessene organisatorische und technische Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit, Integrität, Authentizität oder Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse zu treffen, die für die Funktionsfähigkeit der von ihnen betriebenen kritischen Infrastrukturen maßgeblich sind“ und künftig auch den Einsatz von Systemen zur Angriffserkennung in Echtzeit umfassen.

Sicherheitsanalysen

Grundlage für Sicherheitsanalysen sind die Dokumentationen der IT-Infrastruktur, der eingesetzten Hard- und Software sowie ein IT-Sicherheitskonzept. Auf dieser Basis sind dabei sowohl die Dokumente als auch Systeme, Einstellungen und Versionen zu prüfen – unter anderem daraufhin, ob die eingesetzte Hard- und Software sowie Schutzmaßnahmen vor Schadcodes aktuell sind, ob Authentifizierungsverfahren ausreichend, Passwort- und Benutzersicherheit gewährleistet sind und keine Konfigurations- und Administrationsfehler vorliegen.

Bei Webanwendungen sind auch die Verarbeitung von Benutzereingaben sowie beispielsweise die Sicherheitsmaßnahmen gegen Cross-Site-Scripting sowie SQL-Lücken und das Session-Management zu überprüfen. Für verschlüsselte Verbindungen (z. B. in VPNs) sollten IT-Sicherheitsanalytiker die Authentifizierungsverfahren checken, die Sicherheit der Verschlüsselungsalgorithmen und Schlüssellängen sowie die Aktualität der eingesetzten Zertifikate verifizieren. Vor allem vor dem Hintergrund aktueller Bedrohungslagen ist auch wesentlich, ob potenzielle Angreifer eine gültige VPN-Verbindung ausnutzen können, um Sicherheitsmaßnahmen für die Zugriffskontrolle zu umgehen.

Bei der Sicherheitsanalyse ist es also das Ziel, alle potenziellen Angriffsziele rund um die Schnittstellen zwischen dem Netzwerk, den Anwendungen und den Nutzern mit ihren Endgeräten auf Grundlage der Dokumentation zu identifizieren. Fast immer findet man dabei Sicherheitslücken, die durch technische Entwicklungen mit der Zeit entstehen – fast immer fördert bereits diese Methode Lücken zutage, die durch Updates und durch von den Herstellern bereitgestellte Sicherheitspatches zu beheben sind. Ebenso oft offenbaren solche Prüfungen veraltete Versionen in Betriebssystemen und Anwendungssoftware, abgelaufene Zertifikate oder unzureichende Einstellungen in Sicherheitsprogrammen.

Schwachstellenanalysen

Einen Schritt weiter gehen Schwachstellenanalysen, mithilfe derer man IT-Infrastruktur – üblicherweise toolbasiert – auf bekannte „Vulnerabilities“ testet. Die Schwachstellenanalyse mit Testprogrammen ist standardisiert und liefert schnelle Ergebnisse, meist aber leider nicht nur echte Findings, sondern auch „False Positives“. Denn automatisierte Tools identifizieren Schwachstellen nur durch bestimmte Service-Banners oder Fingerprints – und nicht durch das tatsächliche Ausnutzen der Schwachstellen. Deshalb sind einige Ergebnisse des Scans keine echte Bedrohung. Ein „Herausrechnen“ der Falschmeldungen kann jedoch zu einem trügerischen Sicherheitsgefühl verleiten, da sich neue oder komplexe Schwachstellen mit der Schwachstellenanalyse prinzipbedingt nicht detektieren lassen.

Immerhin ermöglicht sie es Administratoren, gefundene Schwachstellen nach Erkennung unmittelbar zu schließen und damit mögliche Angriffe zu verhindern. Sowohl Sicherheits- als auch Schwachstellenanalysen stoßen jedoch an ihre Grenzen, wenn es um neue oder noch unbekannte Bedrohungen geht. Hier hilft dann nur noch die systematische Suche nach Lücken mit bewährten „Hackermethoden“, sprich: mit einem Penetrationstest.

Penetrationstests

In einem Penetrationstest nutzen Tester (ihnen) bekannte Schwachstellen, um zunächst in ein System einzudringen – davon ausgehend versuchen sie anschließend mögliche Angriffsstrategien in der mit dem Kunden vereinbarten Tiefe durchzuführen. Dabei kommt es vor allem auf Kreativität und Erfahrung der Tester an, um zum Beispiel per „Trial and Error“ neue Schwachstellen zu entdecken. Wie Kriminalisten brauchen sie dafür ein forensisches Gespür, suchen nach neuen Wegen und setzen ihr in einschlägigen Foren gesammeltes Wissen ein. Innerhalb des festgelegten – und damit gegebenenfalls auch für Externe autorisierten – Rahmens simulieren Penetrationstester Attacken auf praktisch alles, was im vereinbarten Scope zuvor definiert worden ist: Netzwerke, Datenbanken oder Anwendungen.

Penetrationstests enthüllen nicht zuletzt den aktuellen Stand der Resilienz des IT-Sicherheitskonzepts und der IT-Infrastruktur und ermöglichen außerdem eine gegenwärtige Risikobewertung. Überdies liefern sie Hinweise darüber, ob sich unbefugte Dritte oder auch interne Mitarbeiter Zugriff auf vertrauliche Informationen beschaffen können.

Ein Penetrationstest ist (genauso wie Sicherheitsanalysen) mit einem ausführlichen Report abzuschließen, der gefundene Schwachstellen dokumentiert sowie Empfehlungen enthält, wie Netzwerke, Systeme, Hard- und Software noch besser abzusichern sowie wo und wie Mitarbeiter noch intensiver für mögliche Cyber-Gefahren zu sensibilisieren sind.

Taxonomie

Penetrationstests lassen sich nach verschiedenen Ansätzen unterschieden: Haben die Durchführenden keine weiteren Informationen, spricht man von einem Black-Box-Test – bei einem White-Box-Test erhält der Dienstleister (oder besitzt ein internes Team) detaillierte Informationen über das zu penetrierende System, beispielsweise das IT-Sicherheitskonzept mit der Dokumentation der zugehörigen IT-Infrastruktur. Stehen nur Teilinformationen bereit, handelt es sich um einen Grey-Box-Test. Häufig simulieren Penetrationstester den Angriff von Hackern oder Cyberkriminellen und werden dann als „Red Team“ bezeichnet – sollen die Tester auch die Schnelligkeit und Kompetenz der eigenen IT-Security-Mitarbeiter des Unternehmens prüfen, nennt man jene „Blue Team“.

Untersuchte Angriffsvektoren und -kanäle

Je nach Untersuchungsziel und Vorgehensmodell kann man drei Vektorklassen mit fünf Kanälen unterscheiden, die im Rahmen von Penetrationstests systematisch analysiert werden und in Tabelle 1 dargestellt sind.

Beim Angriff über das Netzwerk beziehungsweise die verwendeten Protokolle versuchen Penetrationstester auf geschützte Netzwerkbereiche und Anwendungen zuzugreifen. Hierbei setzen sie teilweise toolbasierte Methoden ein (z. B. automatische Portscans), hören Kommunikation ab (z. B. via Man-in-the-Middle-Angriff), schleusen Schadcode ein (Code-Injection) oder bringen mit Denial-of-Service-(DoS)-Attacken bestimmte Dienste durch Überlastung zum Erliegen. Darüber hinaus setzen sie Methoden ein, um Schwachstellen in Betriebssystemen, Netzwerkprotokollen, drahtlosen Netzwerken, Telekommunikationssystemen und Webanwendungen zu identifizieren und für das weitere Vordringen zu nutzen.

Ein aktuell besonders gefährlicher Kanal ist das Social Engineering, bei dem Angreifer versuchen, über die Schwachstelle „Mensch“ Zugang zu sensiblen Daten zu erlangen. Durch Manipulation von Mitarbeitern oder Verleiten zu Fehlverhalten erbeuten sie so beispielsweise Passwörter oder geheime Kryptoschlüssel (Private Keys). Die meistgenutzte Methode ist aktuell das Phishing. Dieser Angriffsvektor ist jedoch nur im Rahmen oder nach einer Awareness-Schulung als Wirksamkeitsprüfung der Trainingsmaßnahme zu empfehlen (s. a. <kes> 2020#5, S. 6).

Ein weiterer Kanal der Vektorklasse „Physische Sicherheit“ ist der Einbruch oder unbefugte Zutritt zu Gebäuden oder Räumen mit IT-Systemen. Je nach Bedarf des Unternehmens ist allerdings nicht jeder Angriffsvektor im Rahmen von Penetrationstests sinnvoll, ethisch vertretbar oder erwünscht.

Vorgehensweise

Ein Penetrationstest lässt sich grob in fünf Phasen unterteilen (vgl. Abb. 1):

• Vorbereitung: Abstimmung von Zielen, Umfang (Scope), eingesetzten Methoden und Systemen.
• Informationsbeschaffung: Dokumentensichtung, „Google Hacking“, Netzwerk-Mitschnitt, Portscans.
• Analyse und Angriffsauswahl: Recherche nach geeigneten Exploits, detaillierte Netzwerkanalyse, Hash-Cracking, Abstimmung der Angriffe mit dem Auftraggeber.
• Verifikationstests: Ausnutzen von Schwachstellen, Umgehung der Sicherheitsmaßnahmen und Penetrieren von IT-Systemen, beispielsweise durch Man-in-the-Middle-Angriffen oder Post-Exploitation.
• Abschlussanalyse: Auswertung und Dokumentation der Ergebnisse, Management-Summary und Präsentation, Auflistung gefundener Schwachstellen, Empfehlungen für Gegenmaßnahmen.

In der Regel starten Penetrationstester mit passiven Techniken, um Informationen über die jeweiligen Untersuchungsbereiche zu sammeln (z. B. RIPE-Abfragen und Netzwerkverkehrsanalysen). Danach tasten sie sich mit nicht-intrusiven, aber interaktiven Scans weiter in der Infrastruktur vor. Solche Scan-Werkzeuge suchen in Firewalls, Webservern und Remote-Access-Services (RAS) zur Fernwartung (bei Microsoft z. B. das Remote-Desktop-Protokoll, RDP) sowie Funkverbindungen (WLAN und Mobilfunktechnologie) nach möglichen Schwachstellen. Zu diesen Scannern zählen beispielsweise nmap (https://nmap.org), die Burp Suite (https://portswigger.net/burp/) oder Nessus (www.tenable.com/products/nessus). Vor allem Webserver sind leicht zu knacken: Wegen ihrer zahlreichen Funktionen (E-Mail, FTP, DNS und weitere) sowie ihrer leichten Erreichbarkeit von außen sind sie besonders vulnerabel – bisweilen genügt schon die Kenntnis einer IP-Adresse, um sich Zugang zum Netzwerk zu verschaffen.

Mittels verschiedener automatisierter Tools und Skripte sammeln Penetrationstester die Informationen, die sie für den nächsten Schritt in der System- und Anwendungsanalyse brauchen. Im Mittelpunkt dieser Phase stehen erste Erkenntnisse über potenzielle Schwachstellen, die über die weitere Angriffsstrategie entscheiden. Außerdem sollte spätestens hier die Dokumentationsarbeit beginnen, denn genutzte Schwachstellen und Befunde simulierter Angriffe sind für den Abschlussbericht wichtig, damit man sie später ausmerzen kann.

Je nach Auftrag oder Kundenwunsch folgt danach ein aktives Eindringen bis hin zur Schwachstellen-Ausnutzung. Durch vorsichtiges Herantasten verhindern Profis dabei eine Störung des Regelbetriebs und vor allem länger andauernde oder permanente Schädigungen der laufenden Systeme. Mit einem solchen progressiven Verfahren lassen sich zudem auch Sicherheitsvorkehrungen im Bereich der Angriffserkennung effektiv überprüfen.

Klare Vereinbarung des gewünschten Rahmens

Wichtig ist, dass sich Auftraggeber und Pentest-Team beziehungsweise Dienstleister vor dem Start eines Tests klar auf dessen Umfang verständigen und dies idealerweise schriftlich festhalten. Handelt ein Penetrationstester ohne Auftrag, erfüllt er zumindest den Straftatbestand „Vorbereiten des Ausspähens und Abfangens von Daten“, der nach § 202c StGB mit einer Freiheitsstrafe bis zu zwei Jahren oder mit einer Geldstrafe bedroht ist.

In einer solchen Scope-Definition ist zu regeln:

• welche IT-Systeme und welche Umgebung Gegenstand des Tests sind,
• welche Basissysteme, Webanwendungen, Datenbanken getestet werden sollen,
• welche Angriffstypen zum Einsatz kommen sollen,
• welche Angriffsvektoren auf den Prüfstand kommen (bzw. verwendet werden dürfen) und
• in welcher Tiefe die Tests durchgeführt werden sollen.

Zudem bedarf es einer Abgrenzung, was nicht getestet werden darf (Out-of-Scope), weil man etwa Produktionssysteme oder zentrale Funktionen nicht gefährden will. Ein standardbasiertes, progressives und risikoabschätzendes Vorgehen vermeidet zwar weitgehend, dass es zu Betriebsstörungen in kritischen Bereichen kommen kann. Da unbeabsichtigte Ausfälle jedoch nicht völlig auszuschließen sind, müssen Auftraggeber und Penetrationstester einen Notfallplan bereithalten, wie bei unerwarteten Auswirkungen vorzugehen ist.

Die folgenden essenziellen Komponenten sollten allerdings idealerweise immer Gegenstand von Penetrationstests sein:

• Netzkoppelelemente wie Router, Switches, Gateways, RTU
• Sicherheitsgateways und andere direkt IT-sicherheitsrelevante Objekte wie Firewalls, Paketfilter, Intrusion-Detection-System (IDS) und Malware-Abwehr
• Server wie Datenbankserver, Webserver, Fileserver, Speichersysteme, Distributed Control-Systems (DCS) und speicherprogrammierbare Steuerungen (SPS – bzw. engl. Programmable Logic Controller, PLC)
• Webanwendungen mit vorgeschaltem Sicherheitsgateway
• relevante Clients und Mitarbeiter-Schnittstellen (Human– Machine-Interfaces, HMI)

Sonderfall: Penetrationstests mit Verschlusssachen

Besonders heikel sind Penetrationstests für Behörden und staatliche Institutionen, die mit vertraulichen Informationen umgehen. Zu beachten sind dann die Vorschriften zum staatlichen Geheimschutz, wie beispielsweise die Verschlusssachenanweisung (VSA) für Arbeiten in eingestuften Netzen und das Geheimschutzhandbuch des Bundesministeriums für Wirtschaft und Energie.

Penetrationstester dürfen in einem solchen Umfeld nur VSA-konforme Hardware nutzen: Der im Penetrationstest eingesetzte Laptop darf keine Festplatte enthalten – alle Daten dürfen nur auf projektspezifischen USB-Sticks gespeichert werden. Damit ist die Datenhaltung auf Test-Laptops strikt untersagt. USB-Speicher müssen nach dem Test entsorgt oder sicher beim Kunden verwahrt werden. Die Verwahrung erfolgt mit durchnummeriertem Siegel, damit eine nachträgliche Nutzung des Sticks sofort erkennbar ist – für jeden neuen Test ist auch ein neuer oder sicher gelöschter Stick notwendig.

Sichere VSA-konforme Hardware wie Test-Laptop und USB-Speicher dürfen überdies nur mit einem speziell und individuell gehärteten Kali Linux betrieben werden. Zusätzliche Sicherheitsmaßnahmen sind regelmäßige Hashwert-Überprüfungen und eine Verschlüsselung mit crypto_LUKS (auf dm-crypt basierend). Updates dürfen nur in sicherer Umgebung erfolgen. Zudem müssen Notebooks und USB-Speicher ein dediziertes System-Hardening durch sichere Konfiguration durchlaufen und regelmäßig auf Schadcode und Rootkits überprüft werden.

Zusätzliche Vereinbarungen mit externen Penetrationstestern

Kommen Dienstleister zum Einsatz, muss ein Vertrag detailliert regeln, welche Aufgaben der Penetrationstester hat und welchen Umfang seine Analysen haben sollen/dürfen, welche Risiken bei der Durchführung der vereinbarten Tests bestehen und in welchem Zeitraum der Test stattfinden soll. Bei einem Penetrationstest mit Social-Engineering-Methoden sind zudem Rechtsabteilung und Betriebsrat einzubeziehen: Denn wenn Sicherheitsanalytiker beispielsweise auch prüfen sollen, ob Mitarbeiter gefälschte E-Mails erkennen und dennoch nicht auf die Anhänge mit Schadcode klicken, sind besondere Absprachen zu treffen. Auch Penetrationstests müssen sicherstellen, dass keine Arbeitnehmerrechte verletzt werden, auch nicht das „Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme“. Viele Testergebnisse sind daher nur anonymisiert zu dokumentieren! Darüber hinaus muss ein Dienstvertrag unbedingt auch eine Geheimhaltungsvereinbarung für die Penetrationstester enthalten.

Standards und Leitfäden

Leitfäden mit Vorgehensmodellen von Expertenorganisationen sorgen für vertrauenswürdige, nachprüfbare und vergleichbare Standards auf dem Gebiet der Penetrationstests. Wer also einen Dienstleister beauftragen will, sollte ihn unter anderem danach fragen, an welchen Standards er sich orientiert – eigene Teams sollten sich ebenfalls hieran orientieren. Gebräuchlich sind die Leitfäden des Bundesamts für Sicherheit in der Informationstechnik (BSI, [1]) und das „Open Source Security Testing Methodology Manual“ (OSSTMM, [2]). OSSTMM wurde vom Institute for Security and Open Methodologies (ISECOM) im Peer-Review-Verfahren entwickelt, überprüft und herausgegeben und ist heute der Standard für die meisten Dienstleister.

Darüber hinaus existieren Leitfäden des Open Web Application Security Project (OWASP, [3], mit OSSTMM kompatibel) für Testverfahren von Web- und mobilen Anwendungen oder des National Institute of Standards and Technology (NIST, [4]) mit branchenspezifischen Vorgaben. Das Expertenprojekt „PTES Framework“ wiederum enthält Strukturierungsvorgaben einzelner Testmethoden [5].

Das OSSTMM umfasst neben verschiedenen Szenarien von Penetrationstests und einem Verhaltenskodex für Dienstleister auch Dokumentationsrichtlinien: Diese verpflichten Penetrationstester, alle entdeckten Schwachstellen systematisch nach dem Vorgehensmodell zu dokumentieren und Empfehlungen zu erarbeiten, wie sie zu schließen sind. Eine Dokumentation ist auch notwendig, um bei wiederholten Penetrationstests die Entwicklung der Sicherheitslage eines IT-Systems nachvollziehen und vergleichen zu können.

Severin Quell (www.linkedin.com/in/severin-quell-7b3306159/) ist Director IT Security Consulting, Aaron Brown (www.linkedin.com/in/aaron-brown1a0b0853/) ist Team Lead Security Audits bei der Infodas GmbH.

Literatur

[1] Bundesamt für Sicherheit in der Informationstechnik (BSI), Ein Praxis-Leitfaden für IS-Penetrationstests, November 2016, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Sicherheitsberatung/Pentest_Webcheck/Leitfaden_Penetrationstest.pdf;?__blob=publicationFile
[2] Institute for Security and Open Methodologies (ISECOM), The Open Source Security Testing Methodology Manual (OSSTMM), Version 3.02, Dezember 2010, www.isecom.org/OSSTMM.3.pdf
[3] Open Web Application Security Project (OWASP), Web Security Testing Guide (WSTG), 3.8 Penetration Testing Methodologies, https://owasp.org/www-projectweb-security-testing-guide/latest/3-The_OWASP_Testing_Framework/1-Penetration_Testing_Methodologies
[4] Karen Scarfone, Murugiah Souppaya, Amanda Cody, Angela Orebaugh, Technical Guide to Information Security Testing and Assessment, NIST Special Publication 800-115, September 2008, https://csrc.nist.gov/publications/detail/sp/800-115/final
[5] Penetration Testing Execution Standard (PTES), Wiki, www.penteststandard.org