Kapitel 32:
Durchführen von Penetrationstests

In diesem Buch haben Sie bisher die theoretischen Grundlagen sowie die praktische Vorgehensweise des Hackings in allen möglichen Facetten kennengelernt. Bereits im ersten Kapitel haben wir die verschiedenen Szenarien beschrieben, in denen Hacking-Techniken zum Einsatz kommen. Wir haben immer wieder betont, dass dieses Buch White Hat Hacking bzw. Ethical Hacking vermittelt. Daraus ergibt sich, dass der professionelle Einsatz dieser Hacking-Techniken nur im Rahmen von erlaubten bzw. beauftragten Penetrationstests durchgeführt werden darf.

Dieses letzte Kapitel betrachtet nun die Methodik sowie den organisatorischen und rechtlichen Rahmen von Penetration-Tests. Um dem Prüfungsinhalt des CEH gerecht zu werden, erhalten Sie in diesem Zusammenhang auch noch weitere Informationen zu rechtlichen Gegebenheiten, die in Europa nicht unbedingt gleichermaßen von Bedeutung sind bzw. auf amerikanisches Recht beschränkt sind. Wir weisen an entsprechender Stelle darauf hin.

Hier sind die Themen dieses Kapitels:

Ein Penetrationstest unterliegt strengen Richtlinien und ethischen Grundsätzen. Die Vorgehensweise hängt vom Szenario ab, folgt aber ebenfalls bestimmten Regeln. Unter dem Strich sollten bei einem Penetrationstest eine Dokumentation der gefundenen Schwachstellen und eine möglichst umfassende Liste mit konkreten Empfehlungen zur Verbesserung der Sicherheit herauskommen.

32.1   Begriffsbestimmung Penetrationstest

Es gibt diverse Begriffe, wie z.B. Penetrationstest, White Hat Hacking, Ethical Hacking, Security Audit und noch einige mehr, die scheinbar alle dasselbe aussagen. Aber wo liegen hier die Gemeinsamkeiten oder Unterschiede? In diesem Abschnitt betrachten wir die Begrifflichkeiten und die Terminologie und klären, was es konkret mit einem Penetrationstest auf sich hat.

32.1.1   Was bedeutet »Penetrationstest« eigentlich?

Beginnen wir also bei dem Begriff, um den es in diesem Kapitel zentral geht: Ein Penetrationstest‌ (engl. Penetration Test) oder kurz: Pentest, ist ein Sicherheitstest für IT-Systeme, der das Angriffspotenzial und die Schwachstellen der Zielumgebung analysiert. Dabei nimmt der Pentester die Perspektive des Angreifers ein und versucht, mit dessen Mitteln, Methoden und Tools die Sicherheit der betreffenden IT-Infrastruktur zu untergraben und auszuhebeln. Wie weit er dabei geht, welcher Methodik er sich bedient und andere Rahmenbedingungen werden zuvor mit dem Auftraggeber bzw. Verantwortlichen der zu betrachtenden Systeme abgesprochen.

Im Gegensatz zu einem echten Angriff führt der Pentester in der Regel keine destruktiven Handlungen durch, die die Integrität der Zielsysteme oder den Produktivbetrieb gefährden könnten. Weiterhin wird im Rahmen eines Penetrationstests immer ein Pentest-Report verfasst, der die Ergebnisse des Tests zusammenfasst und Empfehlungen zur Beseitigung gefundener Schwachstellen enthält.

Die Begriffe »Penetration Testing«, »White Hat Hacking‌« und »Ethical Hacking‌« werden oft synonym genutzt und meistens ist das auch in Ordnung, wenn auch formal nicht vollständig korrekt: Während der Penetrationstest eine formale Prozedur mit individuellen, aber klaren Regeln, einem definierten Ziel und abgestimmtem Vorgehen darstellt, umfassen die Begriffe »Ethical Hacking« und »White Hat Hacking« die Gesamtheit der Hacking-Aktivitäten, die der Verbesserung der IT-Sicherheit dienen. Penetration Testing ist somit nur ein formalisierter Teilbereich hiervon.

Wichtig: Auch beim Ethical Hacking gibt es klare Regeln!

Um es jedoch ganz deutlich zu formulieren: Auch beim Ethical Hacking werden alle Handlungen unterlassen, die rechtswidrig sind oder nicht dem Code of Ethics bzw. der Hackerethik entsprechen. Es ist also beispielsweise nicht erlaubt, während eines Penetrationstests in das Gebäude des Zielunternehmens einzubrechen oder einen Mitarbeiter zu erpressen, um an Informationen zu gelangen.

Der Begriff »White Hat Hacking« stammt von der Unterscheidung der Ambitionen und Beweggründe eines Hackers, die wir Ihnen in diesem Buch ja immer wieder dargelegt haben. Ein White Hat Hacker handelt nach dem Code of Ethics und führt Penetrationstests durch.

32.1.2   Wozu einen Penetrationstest durchführen?

Ein Penetrationstest ergänzt häufig die allgemeine Sicherheitsanalyse und soll ein möglichst realistisches Bild der Empfindlichkeit der betreffenden IT-Systeme gegenüber Angriffen zeichnen. Aufgrund des Perspektivenwechsels ist es dem Pentester möglich, Aspekte der Sicherheit zu untersuchen, die vonseiten der IT-Sicherheitsverantwortlichen bisher unter Umständen nur unzureichend berücksichtigt werden.

Damit ist der Penetrationstest ein wichtiger Bestandteil der IT-Sicherheitsprozesse von Unternehmen und Organisationen. Er sollte regelmäßig ergänzend zu anderen Maßnahmen im Rahmen der Sicherheitsanalyse durchgeführt werden und hat das Potenzial, die Sicherheit der IT-Infrastruktur entscheidend zu verbessern.

Während im Rahmen der IT-Sicherheit in der Regel nur allgemein Firewalls, AV-Systeme, IDS/IPS, Application Layer Gateways etc. implementiert werden und damit eine Breitbandwirkung und ein Grundschutz erzielt wird, sticht der Penetrationstest den Finger in die Wunde und bohrt dort hinein, wo die getroffenen Maßnahmen bisher nur unzureichend wirken. Damit können im Anschluss gezielte Maßnahmen ergriffen werden, um die vorhandenen Schwachstellen der IT-Systeme zu beseitigen.

Durch einen Penetrationstest können die Sicherheitskomponenten und deren Konfiguration auf Herz und Nieren geprüft werden. Werden neue Systeme oder Anwendungen eingeführt bzw. entwickelt, ist ein Penetrationstest ebenfalls eine hervorragende Möglichkeit zu prüfen, ob die Sicherheitsmechanismen greifen oder Schwachstellen vorhanden sind. Während Vulnerability-Scans nur die Standard-Schwachstellen aufdecken, können im Rahmen eines Penetrationstests auch unbekannte Schwachstellen und sogar Zero-Day-Exploits identifiziert werden.

Ein anderer Aspekt sind Compliance-Anforderungen, an die eine Organisation oder ein Unternehmen gebunden ist. Compliance‌ beschreibt die Einhaltung von Gesetzen, Richtlinien und freiwilligen, teilweise branchenspezifischen Bestimmungen. Hieraus ergibt sich in einigen Fällen die Anforderung an einen entsprechenden Penetrationstest. Unter diesen Aspekt fallen auch bestimmte Zertifizierungen, wie z.B. BS7799, ISO/IEC 27001/2, HIPAA und andere, die ebenfalls Bestimmungen zur Durchführung von Penetrationstests enthalten.

32.1.3   Penetrationstest vs. Security Audit vs. Vulnerability Assessment

Wir haben bereits in Abschnitt 32.1.1 eine Begriffsbestimmung und Abgrenzung vorgenommen. An dieser Stelle betrachten wir zwei weitere Begriffe, die häufig im selben Atemzug mit Penetrationstests genannt werden:

Security Audit (IT-Sicherheitsaudit)

Ein Security Audit‌ oder IT-Sicherheitsaudit betrachtet die Sicherheit von IT-Systemen eines Unternehmens oder einer Organisation aus einer ganzheitlichen, übergeordneten Perspektive. Bedrohungen der Sicherheit können nicht nur von Angriffen ausgehen, sondern auch von technischen Vor- und Unfällen, organisatorischen Mängeln oder höherer Gewalt.

Security Audits finden oft im Rahmen des Qualitätsmanagements statt und prüfen nicht nur die technischen Sicherheitskomponenten wie Firewall-Konfiguration, AV-Systeme und so weiter, sondern auch, ob Standards und Richtlinien eingehalten werden, welche Sicherheitsprozesse existieren, ob die Mitarbeiter richtig geschult sind und die Prozesse kennen sowie weitere ähnliche Aspekte.

Viele Security Audits integrieren auch Komponenten des Penetrationstests. So werden oft auch (automatisierte) Security-Scans und Analysen durchgeführt mittels Nmap, Wireshark und Vulnerability-Scannern. Allerdings geht ein Security Audit in der Regel nicht so tief in die Details, wie es ein manueller Penetrationstest erfordert. Hinsichtlich dieser Scans gibt es auch Überschneidungen zum nachfolgend beschriebenen Prozess.

Vulnerability Assessment

Das Vulnerability Assessment‌ fokussiert sich auf die Aufdeckung von Schwachstellen der betrachteten IT-Systeme. Dies geschieht in der Regel mittels automatischer Tools, wie Nmap, Nessus und Ähnlichen. Im Unterschied zum Penetrationstest wird bei einem Vulnerability Assessment jedoch nicht im Detail festgestellt, ob die Schwachstelle tatsächlich ausgenutzt werden kann oder welche Auswirkung eine Schwachstelle hat.

Da Vulnerability Assessments in der Regel auf die oben genannten Tools zurückgreifen, ist die Qualität des Ergebnisses von vielen Faktoren abhängig. Wie Sie bereits wissen, sind die Vulnerability-Scanner nur so gut wie ihre Patterns und Scan-Engines. Zudem decken sie nur Standardszenarien ab und berücksichtigen keine Besonderheiten in der IT-Infrastruktur. Damit sind Vulnerability Assessments eher ein erster Schritt im Rahmen der technischen Schwachstellenanalyse als ein umfassender Prozess zur Absicherung der Systeme. Sie kommen oft auch im Rahmen des Security Audits zur Anwendung oder als einer der ersten Schritte beim Penetrationstest.

Der Penetrationstest geht in jedem Fall weiter und prüft die gefundenen Schwachstellen im Detail. Der Pentester versucht, die Schwachstellen auszunutzen und die sich daraus ergebenen Möglichkeiten für den Angreifer zu evaluieren. Dadurch wird es möglich, die Auswirkungen einer Schwachstelle festzustellen. Durch die manuelle Natur eines Penetrationstests und der Kreativität des Pentesters ist die Chance, Schwachstellen zu finden, bei professionell durchgeführten Penetrationstests ungleich größer als bei standardisierten Security Audits und Vulnerability Assessments.

32.1.4   Arten des Penetrationstests

Es gibt verschiedene Varianten zur Durchführung von Penetrationstests. Sie unterscheiden sich hinsichtlich der Freiheit des Pentesters, der Vorgaben und festgelegten Grenzen (engl. Scope) durch den Auftraggeber und dem Vorwissen des Pentesters, das dieser über das Zielsystem bzw. Zielnetzwerk hat.

Black-Box-Test

Beim Black-Box-Test‌ versucht der Pentester, ohne Vorkenntnisse über die Adressen, Systeme, Anwendungen und Prozesse das Ziel anzugreifen. Das Hauptargument für diesen Ansatz ist, dass dieses Szenario der echten Welt am nächsten kommt und somit ein reales Angriffsszenario simuliert. Dies ist allerdings nur bedingt richtig, da ein echter Angreifer nicht nur ein oder zwei Wochen zur Verfügung hat wie ein beauftragter Pentester, sondern ihm beliebig viel Zeit, also auch Monate oder Jahre zur Verfügung stehen, um den Angriff vorzubereiten. Tatsächlich liefen einige der erfolgreichsten Hacking-Angriffe über einen Zeitraum von bis zu einem Jahr. Diese Verzerrung führt dazu, dass Black-Box-Tests oftmals nicht aussagekräftig sind und den Auftraggeber in falscher Sicherheit wiegen.

White-Box-Test

Bei einem White-Box-Test‌ erhält der Pentester alle Informationen über das Zielsystem oder -netzwerk. Er kann und darf mit allen Parametern arbeiten. Das Hauptargument für einen White-Box-Test ist, dass alles auf Herz und Nieren geprüft werden soll. Der Vorteil dabei ist, dass dies zum einen Zeit spart, da der Pentester mit seinem umfassenden Vorwissen viel gezielter nach Schwachstellen suchen kann, und zum anderen mehr Ergebnisse liefert und einen besseren Einblick in die tatsächlich vorhandenen Schwachstellen bietet.

In der Regel sind White-Box-Tests effektiver für die Verbesserung der Sicherheit der IT-Systeme und sollten bevorzugt werden. Dennoch gibt es Szenarien, in denen Black-Box-Tests sinnvoller und zielführender sind. Teilweise werden auch nur partielle Informationen an den Pentester übermittelt, sodass er zwar Anhaltspunkte hat, aber andere Aspekte selbst herausfinden muss. In diesem Fall sprechen wir von Grey-Box-Tests‌.

Red Teaming und Blue Teaming

Als »Red Team‌« (zu Deutsch: Rotes Team) wird eine organisatorisch unabhängige Gruppe von White Hat Hackern bezeichnet, die als Angreifer versucht, in die IT-Systeme der Zielorganisation einzudringen. Dabei verhält sie sich wie echte Angreifer. Das Szenario ähnelt also einem Black-Box- oder Grey-Box-Test, kann aber mehr Realitätsnähe und Dynamik erreichen als Übungen, Rollenspiele oder konventionelle Penetrationstests.

Mitglieder des Red Teams können verschiedene Administratoren oder Sicherheitsbeauftragte unterschiedlicher Standorte oder aber externe Mitarbeiter sein. Die Angriffe können nach Absprache erfolgen oder ohne vorherige Ankündigung. Red Teams bestehen aus qualifizierten Personen mit Erfahrung im Ethical Hacking.

Red Teams werden insbesondere in staatlichen Organisationen der USA häufig eingesetzt. Geheimdienste beauftragen Red Teams, die sich in die Situation von staatlich geförderten Hackern fremder Staaten versetzen und entsprechende Szenarien durchspielen sollen. Aber auch große Privat-Unternehmen installieren öfters derartige Institutionen.

Das »Blue Team‌« (also Blaues Team) stellt das Verteidigungsteam dar und ist damit beauftragt, zum einen die IT-Sicherheit kontinuierlich zu verbessern und zum anderen die durch das Red Team durchgeführten Angriffe (oder andere Angriffe) zu verhindern oder die gefundenen Schwachstellen im Nachgang schnellstmöglich zu beseitigen. Unter Blue Teaming lässt sich die abteilungs- und standortunabhängige Zusammenarbeit aller für die IT-Sicherheit einer Organisation zuständigen Mitarbeiter bezeichnen. Die Angriffe des Red Teams dienen auch dazu, die Reaktionsart und -zeit des Blue Teams zu messen. Unter dem Strich geht es um die Stärkung des Blue Teams zur Verbesserung der IT-Sicherheit.

Angekündigte vs. nicht angekündigte Pentests

Eine wichtige Unterscheidung bei der Durchführung von Penetrationstests ist die Frage, ob der Test angekündigt wird oder nicht. Wird ein Pentest angekündigt, so sind die Administratoren und Verantwortlichen gewarnt und können sehr schnell und zielgerichtet reagieren, wenn etwas Unvorhergesehenes passiert. In der Praxis kommt es bei Penetrationstests immer wieder zu Situationen, in denen versehentlich die Integrität von Produktivsystemen gefährdet ist. Plötzlich reagiert ein Server nicht mehr oder das Logging spielt verrückt und so weiter. In diesem Fall führt ein sofortiges Gespräch mit dem Pentester-Team meistens zu einer schnellen Lösung des Problems.

Auf der anderen Seite kann es vom Auftraggeber auch gewünscht sein, die Reaktionszeit des IT-Sicherheitspersonals (also des Blue Teams) zu testen, sodass auch unangekündigte Pentests erfolgen dürfen. Hier geht es primär darum, festzustellen, ob die Monitoring-Prozesse funktionieren und Einbruchsversuche schnell bemerkt werden.

Welche Variante zum Einsatz kommt, hängt von der Zielsetzung ab. Bei aggressiven Scans und Einbruchsversuchen ist die Wahrscheinlichkeit einer Entdeckung höher, aber auch die Gefahr, dass Teile der IT-Infrastruktur in Mitleidenschaft gezogen werden. In derartigen Fällen sollte der Scan in jedem Fall angekündigt und die Zielsysteme im Detail zuvor kommuniziert werden.

32.2   Rechtliche Bestimmungen

Es gibt eine Reihe von Gesetzen und anderen Bestimmungen, aufgrund derer sich direkt oder indirekt Anforderungen zur Durchführung von Penetrationstests ableiten lassen. Der CEH erfordert von Ihnen Kenntnisse über diesbezügliche Regularien, daher führen wir deren Inhalte teilweise etwas ausführlicher aus. Einige Gesetze greifen nur für Organisationen und Unternehmen in den USA. Nicht selten spielen diese allerdings auch außerhalb der USA eine Rolle, da ausländische Unternehmen, die in den USA tätig sind, diese Gesetze ebenfalls berücksichtigen müssen. Da wir auch in Deutschland und Europa derartige Gesetze und Bestimmungen kennen, führen wir die wichtigsten nachfolgend auf.

32.2.1   In Deutschland geltendes Recht

Eine Vorschrift zur Durchführung von Penetrationstests oder ähnlichen Audits gibt es hier nicht. Das Strafgesetzbuch beschränkt sich auf die Festlegung der Straftatbestände in Bezug auf elektronische Datenverarbeitung.

Darüber hinaus gibt es noch eine Reihe einschlägiger Gesetze, die von Unternehmen, Organisationen und Privatpersonen zu befolgen sind. Hierzu gehören:

Weiterhin sind spezielle branchenspezifische Regeln zu beachten, wie z.B. Basel III mit speziellen Vorschriften zur Regulierung von Banken. Durch das Gebot, geeignete Maßnahmen zur Risikominimierung vorzunehmen und über IT-Sicherheitsmaßnahmen das operative Risiko zu reduzieren, leiten sich auch Maßnahmen zur Kontrolle der IT-Sicherheit ab, deren Bestandteil Penetrationstests sein können.

32.2.2   US-amerikanisches und internationales Recht

Es existiert eine Reihe einschlägiger Gesetze, die zum einen in den USA gelten und zum anderen international Anwendung finden, da viele Unternehmen weltweit agieren und daher ebenfalls an diese gesetzlichen Regelungen gebunden sind. In vielen Fällen halten sich Unternehmen auch an die jeweiligen landesspezifischen Anforderungen, da sie dort geschäftlich tätig sind oder die entsprechende Kundschaft anziehen möchten.

Payment Card Industry Data Security Standard (PCI DSS)

Dabei‌ handelt es sich um ein Standard- und Regelwerk im Zahlungsverkehr mit Kreditkarten, der vom PCI Security Standards Council entwickelt und veröffentlicht wird. Der Standard wird von allen großen Kreditkartenanbietern unterstützt und ist damit de facto verpflichtend für alle Unternehmen, die in den Kartenzahlungsprozess involviert sind. Das umfasst daher auch die Handelsunternehmen, Dienstleister, Service-Provider, Lesegerät-Hersteller und alle anderen Beteiligten, die Kreditkarten-Transaktionen speichern, übermitteln oder abwickeln.

Die Regelungen umfassen 12 Anforderungen zur Erfüllung der Compliance, die in sechs Kontrollziele aufgeteilt sind:

  • Aufbau und Betrieb eines sicheren IT-Netzwerks: Umfasst die Einrichtung von Firewalls und die Vermeidung von unsicheren Default-Sicherheitseinstellungen seitens der Hersteller.

  • Schützen der Daten der Karteninhaber: Bedeutet das sichere Speichern der Daten und die starke Verschlüsselung der Daten beim Transport über unsichere Netzwerke (wie z.B. das Internet).

  • Betreiben eines Vulnerability-Management-Programms: Betrifft zum einen das regelmäßige Update von Programmen und Virenschutz-Software und zum anderen die Entwicklung sicherer Systeme und Anwendungen.

  • Implementieren starker Zugriffskontrollmechanismen: Hierunter fällt die Beschränkung des Zugriffs auf die Karteninhaber-Daten auf das notwendige Minimum, die eindeutige Identifikation von Benutzern bei der Anmeldung an Computersystemen (also z.B. kein nicht personalisierter Zugang unter dem User root oder admin) sowie die physische Zugangsbeschränkung zu den Daten der Karteninhaber.

  • Permanente Überwachung und regelmäßige Tests des Netzwerks: Dies umfasst das Tracking und Monitoring aller Zugriffe auf Netzwerk-Ressourcen und Karteninhaber-Daten sowie regelmäßige Tests der Security-Systeme und Prozesse, darunter auch Penetrationstests.

  • Einrichtung einer Informationssicherheitsrichtlinie: Dieser letzte Punkt betrifft die organisatorische Sicherheit und verlangt eine entsprechende Richtlinie (engl. Informationen Security Policy) zum Umgang mit IT-Sicherheit für alle Mitarbeiter einer Organisation.

Werden diese Bestimmungen nicht eingehalten, können Strafen verhängt, Einschränkungen ausgesprochen werden oder die betreffenden Kreditkarten werden nicht mehr akzeptiert.

Health Insurance Portability and Accountability Act (HIPAA)

Das‌ von der US-Regierung 1996 beschlossene Gesetz legt fest, wie persönliche Daten im Gesundheitswesen geschützt und behandelt werden müssen. Dies umfasst fünf Sektionen (als Titles bezeichnet) für unterschiedliche Bereiche, wie z.B. Steuern, Versicherungen und Verwaltung, die insbesondere die Vereinfachung der Verwaltung (original: Administrative Simplification Rules) zum Ziel haben. Der Title II hat Bezeichnungen wie Preventing Health Care Fraud and Abuse; Administrative Simplification; Medical Liability Reform und regelt unter anderem die IT-Sicherheitsaspekte. Er ist unterteilt in fünf Regeln:

  • Privacy Rule: Gewährt staatlichen Schutz für personenbezogene Gesundheitsinformationen, die von den betroffenen Stellen aufbewahrt werden, und gibt den Patienten eine Reihe von Rechten in Bezug auf diese Informationen.

  • Transaction and Code Sets Rule: Erfordert die Übermittlung von Daten in einer standardisierten und einheitlichen Art und Weise unter Verwendung einheitlicher Codes und eindeutiger Identifier für die Datensätze.

  • Security Rule: Legt eine Reihe administrativer, physischer und technischer Sicherheitsmaßnahmen fest, die einzuhalten sind, um personenbezogene Gesundheitsdaten zu speichern und deren Vertraulichkeit, Integrität und Verfügbarkeit sicherzustellen. Speziell aus dieser Regel leiten sich diverse Maßnahmen ab, die auch Sicherheitsprüfungen, wie z.B. Penetrationstests, erfordern.

  • National Identifier Requirements: Erfordert eine eindeutige Identifikationsnummer für Gesundheitsorganisationen und deren Angestellte, die diese bei Standard-Transaktionen verwenden müssen.

  • Enforcement Rule: Enthält Bestimmungen zur Einhaltung und Untersuchung von Vorschriften, zur Verhängung von Geldstrafen für Verstöße gegen die Verwaltungsvereinfachungsregeln der HIPAA und zu Verfahren für Anhörungen.

Das Gesetz gilt zwar grundsätzlich nur in den USA, wird aber von vielen überregionalen Providern und Organisationen, wie z.B. Cloud-Providern, ebenfalls eingehalten.

Sarbanes-Oxley Act (SOX)

Dieses‌ Gesetz wurde 2002 von der US-Regierung verabschiedet als Antwort auf die Bilanzskandale bestimmter großer Unternehmen, die den öffentlichen Kapitalmarkt in Anspruch nehmen. Es soll das Vertrauen der Anleger in die Bilanzzahlen und veröffentlichten Finanzdaten von Unternehmen stärken bzw. wiederherstellen und betrifft nicht nur US-amerikanische Unternehmen, sondern alle Unternehmen, deren Wertpapiere an US-Börsen oder anderweitig in den USA gehandelt werden. Durch die Bedeutung des Börsenstandorts USA wird es daher de facto zu internationalem Recht.

Es werden diverse Festlegungen hinsichtlich der Zuverlässigkeit der Rechnungslegung und Berichterstattung getroffen, die umfassende interne Kontrollsysteme erfordern. Da fast alle Prozesse von der IT-Infrastruktur abhängen, können auch umfangreiche Anforderungen an das Netzwerk und die IT-Sicherheit hieraus abgeleitet werden und durch die Anforderungen an die Kontrolle der Sicherheitsmaßnahmen indirekt auch die Durchführung von Penetrationstests oder ähnlichen Audits.

Federal Information Security Management Act (FISMA)

Dieses‌ Gesetz wurde ebenfalls im Jahr 2002 verabschiedet und verpflichtet öffentliche Verwaltungen und Einrichtungen dazu, geeignete Maßnahmen für die IT-Sicherheit zu ergreifen. Es handelt sich um ein umfassendes Framework an Standards und verpflichtenden Richtlinien zur Einrichtung sicherer IT-Infrastrukturen und Datensicherheit. Zudem werden Kontrollmechanismen vorgeschrieben, aus denen auch Security-Audits bzw. Penetrationstests abgeleitet werden können.

ISO/IEC 27001 und 27002

Diese‌ internationale Norm mit der Bezeichnung Information technology – security techniques – Information security management systems – Requirements definiert Anforderungen für ein umfassendes Informationssicherheits-Management-System. Zudem umfasst die Norm Anforderungen für die Risikoanalyse, abhängig von der betreffenden Organisation und die daraus resultierende kontinuierliche Verbesserung der Sicherheit.

ISO/IEC 27001 dient als Qualitätssicherung für die Informationssicherheit und lehnt sich stark am IT-Grundschutz des BSI an. Unternehmen und Organisationen können sich über ein externes Audit zertifizieren lassen und dadurch gegenüber Kunden und anderen Interessenten dokumentieren, dass sie die festgelegten Standards einhalten.

Mit ISO/IEC 27002 existiert ein internationaler Standard mit Empfehlungen für diverse Kontrollmechanismen für die IT-Sicherheit. Dieser Standard zielt konkret auf die Absicherung gegen Angriffe ab, sodass hieraus auch die Anforderungen zur Durchführung von Security Audits und Penetrationstests abgeleitet werden können. ISO/IEC 27002 hat allerdings nur Empfehlungscharakter, es ist keine Zertifizierung für diesen Standard möglich.

32.3   Vorbereitung und praktische Durchführung des Penetrationstests

Nachdem wir die theoretischen Grundlagen des Penetrationstests abgehandelt haben, kommen wir nun zu den konkreten Fragestellungen. In diesem Abschnitt beschreiben wir alles rund um die Organisation und Durchführung eines Penetrationstests.

Eine sehr nützliche Quelle für alle Aspekte rund um die Durchführung von Pentests ist www.pentest-standard.org. Hier finden Sie eine Fülle von Informationen und Guidelines, die Ihnen als wertvoller Leitfaden dienen können. Die Seite ist schon recht alt, aber die Grundstruktur von Pentests hat sich nicht grundlegend geändert.

32.3.1   Die Beauftragung

Penetrationstests können sowohl intern durch eigene Mitarbeiter als auch durch externe Dienstleister durchgeführt werden. Periodische Tests durch externe Pentester sind wichtig, da interne Mitarbeiter zwar die eigenen Schwachstellen im Zweifel besser kennen, aber irgendwann »betriebsblind« werden. Externe Penetrationstester haben den Blick von außen und bringen Erfahrung von vielen unterschiedlichen Kunden mit. Ein gesunder Mix zwischen internen und externen Penetrationstests ist in der Praxis daher oft am effektivsten.

Eigene Mitarbeiter mit einem Penetrationstest zu beauftragen ist organisatorisch bzw. rechtlich oft einfacher, da sie weisungsgebunden und ohnehin zur Verschwiegenheit verpflichtet sind und im Rahmen des Arbeitsvertrags viele Regelungen bereits gelten. Gehen wir in diesem Szenario einmal davon aus, dass Sie als externer Dienstleister mit einem Penetrationstest beauftragt werden sollen.

Wichtig: Alles schriftlich fixieren!

Diese Beauftragung durch den Kunden ist für Sie als Pentester von größter Wichtigkeit und bewahrt Sie vor rechtlichen Konsequenzen! Für einen Penetrationstest ist eine klare Beauftragung seitens des Unternehmens oder der Organisation notwendig. Dabei reicht es nicht, dass der IT-Sicherheitsbeauftragte Ihnen bei einem Kaffee die Zustimmung gibt: »Versuchen Sie doch einmal, in unsere Systeme einzudringen, ich bin gespannt, wie weit Sie kommen!« Nein, es muss genau festgelegt werden, in welchem Rahmen der Test durchgeführt werden soll. Dies wird dann in einem Vertrag, dem beide Seiten zustimmen müssen, festgehalten. Achten Sie darauf, dass nur Berechtigte seitens des Auftraggebers den Vertrag gegenzeichnen.

Am Anfang steht in der Regel ein Gespräch mit dem Auftraggeber. Oft weiß der Auftraggeber noch nicht genau, worauf es ankommt und welche Optionen es gibt. Hier ist es wichtig, sich als Berater zu verstehen und ein für den Kunden sinnvolles Angebot zu erstellen. Dazu lassen Sie sich zunächst so viele Informationen wie möglich über die Rahmenbedingungen und technischen Gegebenheiten geben. Anschließend müssen folgende Fragestellungen möglichst detailliert geklärt und im Auftrag schriftlich fixiert werden:

Je nach Szenario müssen weitere Punkte geklärt werden. Je detaillierter der Auftrag festgelegt ist, desto sicherer ist der Boden, auf dem der Pentester steht. Alle Rahmenbedingungen sollten genau abgesprochen werden.

32.3.2   Methodik der Durchführung

Ein professioneller Penetrationstest ist in der Regel durch eine systematische Vorgehensweise geprägt. Die Wahl der Vorgehensweise sollte Bestandteil des Penetrationstest-Vertrags sein. Auch wenn erfahrene Pentester mit der Zeit eine eigene Herangehensweise entwickeln, so muss das Rad nicht unbedingt neu erfunden werden. Es existieren einige Standards, die der Pentester als Basis für seine Vorgehensweise nutzen kann.

MITRE ATT&CK Framework

Dieses vom MITRE unter https://attack.mitre.org zur freien Verfügung bereitgestellte Framework dient als Knowledge Base für »Adversary Tactics«, also gegnerische Taktiken, sprich: Angriffstechniken. Es basiert auf Beobachtungen in der realen Welt und dient zur Entwicklung von spezifischen Bedrohungsmodellen und Methodologien in allen Bereichen der Wirtschaft und Verwaltung. Grundsätzlich werden die Informationen in Matrizen dargestellt und in drei grundlegende Sammlungen aufgeteilt: Enterprise, Mobile und ICS (Industrial Control Systems).

Die Matrix für den Bereich Enterprise, also für Unternehmensumgebungen, enthält 14 Taktik-Kategorien. Dazu gehören Reconnaissance, Initial Access, Privilege Escalation und Lateral Movement, also Vorgehensweisen, die wir im Rahmen der Hacking-Phasen und im Rahmen dieses Buches immer wieder genannt haben. Das MITRE ATT&ACK Framework bietet einen umfassenden Überblick und eine hervorragende Übersicht über wichtige Angriffsvektoren und effektive Verteidigungsmaßnahmen. Es ist eine wertvolle Quelle für Security-Audits.

[Bild]

Abb. 32.1: Das MITRE ATT&CK Framework

Open Source Security Testing Methodology Manual (OSSTMM)

Vom Institute for Security and Open Methodologies, kurz: ISECOM, wird ein De-facto-Standarddokument namens OSSTMM‌ entwickelt und als Open Source bereitgestellt. Es ist unter www.isecom.org/OSSTMM.3.pdf erhältlich. OSSTMM enthält eine Methodik für umfassende Sicherheitstests nahezu aller Aspekte, die im Rahmen eines Penetrationstests berücksichtigt werden müssen.

[Bild]

Abb. 32.2: Darstellung einer REV-Berechnung im OSSTMM-Dokument

Das Dokument umfasst in der Version 3 von 2010 über 200 Seiten und kann für so ziemlich alle Audit-Varianten, inklusive Penetrationstests, Vulnerability Assessments, Red Teaming und Blue Teaming und andere genutzt und angepasst werden. Trotz seines Alters ist es nach wie vor fast uneingeschränkt nutzbar, da sich die Methodik im Gegensatz zur Technik nicht grundlegend geändert hat.

Die eigentliche Methode wird in fünf Channels unterteilt, die alle Aspekte der IT-Sicherheit berücksichtigen und die wiederum aus einzelnen Modulen bestehen. Diese Module werden in Form von Tasks, also Aufgabenpaketen, durchlaufen.

OSSTMM untersucht den Status aller relevanten Sicherheitskomponenten und -aspekte und quantifiziert diese durch Formeln. Dies wird als Risk Assessment Value (RAV) bezeichnet. Der Vorteil ist eine Vergleichsmöglichkeit zweier Tests und deren Ergebnisse, die Replizierbarkeit der Ergebnisse und die Vollständigkeit und Genauigkeit durch das Zahlenwerk.

Der Nachteil ist, dass einige Fakten und Zusammenhänge nur unzureichend als Zahl ausgedrückt werden können und daher das Bild verzerrt werden könnte. Zwar werden die errechneten Werte mit Nachkommastellen dargestellt und suggerieren hier einen sehr genauen Wert, jedoch besteht viel Spielraum seitens des Auditors bzw. Pentesters bei der Bewertung der Eingangswerte. Zudem sind die Berechnungen teilweise recht speziell und nicht immer auf den ersten Blick nachvollziehbar, ohne sich damit im Detail auseinanderzusetzen.

Doch selbst wenn Sie das Bewertungssystem nicht übernehmen wollen (wir sehen dies nach unserer Erfahrung auch kritisch), können Sie dennoch den systematischen Ansatz aus OSSTMM auch isoliert nutzen.

Open Web Application Security Project (OWASP)

Auch wenn wir uns bei unseren bisherigen Betrachtungen darauf konzentriert haben, welche Top-10-Schwachstellen OWASP‌ identifiziert hat, so ist dieses Projekt doch noch deutlich vielschichtiger. Mit seinen über 100 Projekten liefert OWASP jede Menge Anleitungen, Checklisten und Tools, die von Security-Auditoren und Pentestern genutzt werden können, um für die jeweiligen Bereiche (Webanwendungen, IoT-Hacking u.a.) entsprechende Vorgehensweisen zu entwickeln. Dabei liefert OWASP auch komplette Anleitungen für Sicherheitstests, wie z.B. der OWASP Testing Guide v4: www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents. Die Anleitungen sind detailliert, umfassen aber im Wesentlichen den Bereich »Webanwendungen«.

Penetration Testing Execution Standard (PTES)

Auf‌ der Seite www.pentest-standard.org, die wir Ihnen bereits früher in diesem Kapitel vorgestellt haben, finden Sie neben vielen anderen Informationen rund um Penetrationstests auch eine Richtlinie zur Durchführung von Pentests. Sie nennt sich PTES Technical Guidelines. Die angebotenen Informationen sind umfassend und eine wahre Fundgrube mit unzähligen Ressourcen.

Zum Teil werden die Vorgänge sogar technisch dargestellt, sodass PTES hier schon fast als Lehrwerk gelten kann. In jedem Fall lohnt sich das Studium dieser Website und der dort genannten Ressourcen. Allerdings sind einige Bereiche auch noch nicht ausgefüllt, sodass das Werk unfertig erscheint. Während es als grundsätzlicher Leitfaden sehr gut geeignet ist, kann man bisher nur eingeschränkt von einer eigenen Methodik sprechen. Trotzdem erfreut sich PTES großer Beliebtheit.

Darüber hinaus gibt es noch weitere frei verfügbare Dokumente und Frameworks zur methodischen Durchführung von Penetrationstests. Auch EC-Council, das Unternehmen, von dem der CEH stammt, stellt mit der EC-Council LPT Methodology eine Methodik bereit, die allerdings closed source und damit nicht allgemein zugänglich ist. Sie erhalten Zugriff auf diese Methodik, wenn Sie sich zum Licensed Penetration Tester (LPT) zertifizieren lassen. Dies ist die höchste Zertifizierungsstufe des EC-Council.

Auch andere große Anbieter, wie z.B. IBM oder McAfee Foundstone, haben eigene, proprietäre Vorgehensweisen entwickelt, die von ihren Mitarbeitern bei internen und externen Penetrationstests und Security Audits eingesetzt werden. Diese sind allerdings in der Regel nicht durch Außenstehende einsehbar.

32.3.3   Praxistipps

Der dumme Mensch lernt aus seinen eigenen Fehlern – der schlaue aus den Fehlern anderer ... An dieser Stelle möchten wir Ihnen aus der Praxis ein paar Hinweise geben, die Ihnen die eine oder andere negative Erfahrung ersparen kann und Ihre Effizienz verbessert.

Diamond Model of Intrusion Analysis

Ein Vorgehensmodell, das im Curriculum des CEHv12 eingeführt wurde, ist das Diamond Model of Intrusion Analysis. Wie der Name schon andeutet, handelt es sich hier nicht um ein präventives Modell oder ein Modell zur Vorgehensweise für Pentests, sondern um einen Ansatz, wie ein bereits erfolgter Einbruch forensisch analysiert werden kann. Zudem liefert das Modell Ansätze zur Entwicklung von Schutzmaßnahmen, um sich vor derartigen Angriffen zukünftig effektiv zu schützen. Wer sich auf die CEH-Prüfung vorbereiten möchte, sollte sich näher mit den Konzepten dieses Ansatzes beschäftigen. Eine mögliche Quelle dazu ist https://flare.io/learn/resources/blog/diamond-model/.

Organisatorische Details vorher klären

Ein typisches Problem in der Praxis ist eine mangelnde Vorbereitung beiderseits – sowohl des Pentesters als auch des Auftraggebers. So wird im Vorfeld z.B. nicht ausreichend geklärt, wie der erste Tag abläuft und welche Voraussetzungen zu erfüllen sind. Stellen Sie sich einen typischen Montagmorgen vor: Sie fahren mit Ihrem Kollegen zum Standort des Kunden und erklären am Empfang, dass Sie für einen Pentest beauftragt wurden und von Herrn Meyer erwartet werden. Die freundliche Dame am Empfang stellt fest, dass Herr Meyer heute gar nicht im Haus ist.

Leider haben Sie keine weiteren Kontaktdaten für den Notfall und auch keine Telefonnummern ... Sie haben vergessen, diese Informationen beim Vertragsabschluss einzufordern. Frau Wazlav, so heißt die Dame am Empfang, gibt aber nicht auf und ruft verschiedene Mitarbeiter an. Irgendwann findet sich eine Frau Schulz, die über Ihr Kommen ebenfalls informiert wurde und Sie zu den für Sie reservierten Arbeitsplätzen führt. Sie stöpseln sich mit Ihren Laptops ein und stellen fest, dass Sie keinen Netzzugang haben.

Frau Schulz sucht den verantwortlichen Netzwerkadministrator, der die beiden Ports Ihrer Arbeitsplätze nach einer Stunde freischaltet. Leider kommen Sie jedoch nicht durch die Firewalls, um an die Zielsysteme zu gelangen, die Sie im Rahmen eines White-Box-Tests prüfen sollen. Es vergeht eine weitere Stunde, bis der Firewall-Admin die entsprechenden Regeln geschaltet hat, da er sich zunächst weigert, externen Mitarbeitern Zugang zum entsprechenden System zu geben. Später wird ihm vom Vorgesetzten die Freigabe hierzu erteilt, doch dieser Vorgang nimmt ebenfalls einige Zeit in Anspruch. Natürlich fehlen einige Ports, sodass Sie ihn erneut um seine Hilfe bitten. Das Spiel wiederholt sich.

Im Vorfeld haben Sie Zugangsdaten für die Webanwendung erhalten, doch leider stellt sich heraus, dass der Account nicht existiert ... es vergeht eine weitere Stunde, bis der Zugriff funktioniert. So geht der erste Tag vorüber, ohne dass Wesentliches in der Sache passiert ist. Das kostet Zeit und Nerven und ist hochgradig ineffizient.

Dieses Szenario ist nicht so weit hergeholt, wie Sie vielleicht denken. Tatsächlich sollten Sie dem Kunden im Vorfeld eine Checkliste an die Hand geben, die seine vorbereitenden Aufgaben enthält, und sicherstellen, dass Sie bereits am ersten Tag wirklich produktiv werden können. Insbesondere Kontaktdaten aller Verantwortlichen sollten Sie einfordern, damit Probleme schnell und zielgerichtet gelöst werden können.

Kommunikation mit dem Kunden

Externe Pentester werden von internen Mitarbeitern im Netzwerk- und Sicherheitsbereich oftmals nicht als »Freunde« empfangen. Stattdessen schlägt ihnen eine ordentliche Portion Skepsis entgegen und die Kooperationsbereitschaft hält sich in engen Grenzen. Hier gilt es, die Zielstellung klar zu kommunizieren und vorab sicherzustellen, dass alle Beteiligten von ihren Vorgesetzten instruiert wurden – immer vorausgesetzt, es handelt sich um einen internen Test im Hause des Kunden. Bei externen Black-Box-Tests sind natürlich deutlich weniger Voraussetzungen zu erfüllen, da der Pentester keinen Arbeitsplatz beim Auftraggeber benötigt und auch keine Freischaltungen auf Netzwerk- oder Firewall-Ebene erforderlich sind.

Auf jeden Fall sollten Sie dafür sorgen, dass Sie nicht als Störenfriede wahrgenommen werden. In gemeinsamen, vorbereitenden Meetings sollten die Verantwortlichen informiert und beauftragt werden, Ihnen alle erforderlichen Informationen zukommen zu lassen. Bei White-Box-Tests sollte den Beteiligten auch klar sein, dass es nicht zielführend ist, Informationen zurückzuhalten. Genau das passiert jedoch in der Praxis häufig, da die Verantwortlichen nicht zu viel preisgeben möchten.

Das Ziel von White-Box-Tests ist es jedoch, mit möglichst umfassendem Wissen die Zielsysteme zu prüfen. Dies muss von der Geschäftsführung zuvor in geeigneter Weise an die betreffenden Mitarbeiter kommuniziert werden, damit diese sich nicht »querstellen«, wenn von Ihrer Seite Fragen kommen und Informationen angefordert werden. Die Kommunikation mit den Beteiligten ist eine nicht zu unterschätzende Herausforderung. Weisen Sie die Mitarbeiter gegebenenfalls darauf hin, dass Sie eine NDA unterschrieben haben und von daher ohnehin zur Geheimhaltung verpflichtet sind – abgesehen von den ethischen Gesichtspunkten.

Tipp: Die Seele des Admins

Loben Sie den verantwortlichen Administrator auch ruhig einmal, wenn Sie einen Prozess oder eine Konfiguration finden, den oder die Sie als sicher erachten. Lassen Sie ihn wissen, dass Sie nicht dazu da sind, die Arbeit der Security-Admins zu zerreißen und sie bloßzustellen. Hier herrschen in der Praxis oft viele Befindlichkeiten.

Bereiten Sie sich vor!

Abgesehen von den bisher geschilderten Problemen, die in erster Linie auf Kundenseite auftreten, können auch Sie als Pentester Ihren Beitrag für einen reibungslosen und effizienten Ablauf leisten. Sie sollten sich gut auf Ihren Auftrag vorbereiten und im Vorfeld bereits einen genauen Ablaufplan festlegen. Je nach Vorkenntnissen über das Ziel können Sie Ihr Vorgehen detailliert planen.

In diesem Sinne sollten Sie auch schon in den ersten Gesprächen mit dem Kunden so viele Informationen sammeln wie möglich. Im Anschluss können Sie einen Pentest-Plan und entsprechende Checklisten erstellen. Prüfen Sie auch Ihr Equipment – nichts ist peinlicher, als wenn Sie ohne entsprechende Ausrüstung beim Kunden ankommen und feststellen, dass Ihr Laptop eine veraltete Version der benötigten Software hat oder bestimmte Hardware-Komponenten wie z.B. der HackRF One oder eine Verstärkerantenne fehlen. Wie? Nein! Uns ist das noch nie passiert ...!

Schauen Sie dahin, wo es niemand erwartet

Es ist bereits dunkel. Ein Mann sucht etwas unter einer Laterne im Park. Ein Passant fragt, was er denn suchen würde, der Mann antwortet: »Meinen Schlüssel« Der Passant fragt, wo er ihn verloren hätte, darauf der Mann: »Irgendwo dahinten im Dunklen.« Darauf fragt er ihn, warum er dann unter der Lampe suchen würde. Der Mann antwortet: »Na, da hinten sehe ich doch nichts ...«

Es passiert nicht selten, dass der Auftraggeber den Pentester an Stellen suchen lässt, von denen er mit großer Wahrscheinlichkeit davon ausgehen kann, dass dort keine Schwachstellen zu finden sind. Hier hilft ein Perspektivenwechsel: Suchen Sie an Stellen, die niemand auf dem Schirm hat, die also, bildlich gesprochen, im Dunklen liegen.

Ein Beispiel hierzu: Der Kunde beauftragt Sie, eine Webanwendung zu prüfen, die kürzlich Opfer eines Angriffs wurde – bisher ist nicht geklärt, wie der Angriff stattgefunden hat. Sie analysieren die Webanwendung und finden partout keine Schwachstelle.

Ihre nächste Idee ist, den Webserver als Plattform zu untersuchen. Zunächst ist der Kunde skeptisch, da dieser doch nichts mit der Webanwendung selbst zu tun hätte. Schließlich gibt er nach und gestattet Ihnen Zugriff auf den Webserver via SSH. Sie benötigen keine zehn Minuten und haben das Problem gefunden: Eine RPC-Schwachstelle hat dazu geführt, dass die Angreifer eine Backdoor installieren konnten und damit direkten Zugriff auf den Webserver und damit auch auf die Webanwendung hatten.

Nehmen Sie nichts als gegeben hin!

Eine Grundregel, die für alle Szenarien gilt, in denen Sie etwas finden sollen, was bisher niemand sonst gefunden hat – egal ob Troubleshooting oder Pentesting: Nehmen Sie niemals etwas als gegeben hin! Wenn Ihnen der Admin eines Systems Stein und Bein schwört, dass er das System übertrieben gehärtet hat und selbst andere Pentester schon daran gescheitert wären, was soll’s? Testen Sie dieses System, als ob Sie diese Information nie erhalten hätten. Gehen Sie auf keinen Fall davon aus, dass der Versuch Zeitverschwendung sei. Letztlich wissen Sie nicht, was der Admin konkret gemacht und was der damalige Pentester versucht hat.

Auch Ihre eigenen Annahmen sind häufig falsch, also hinterfragen Sie sich und testen Sie Dinge, von denen Sie annehmen, dass es eigentlich unmöglich sei, hier zu einem Erfolg zu gelangen. Nehmen Sie insbesondere nicht an, dass bestimmte Security-Maßnahmen zwangsläufig greifen. Kein Test ist zu dumm, keine Phishing-Mail zu blöd, als dass sie nicht doch die Chance beinhalten, zu einem überraschenden Ergebnis zu gelangen.

Tests wiederholen

Hier gelangen wir an einen Punkt, den Sie nicht unbedingt selbst in der Hand haben, da der Kunde hier einwilligen (und bezahlen) muss: Sie sollten darauf hinwirken, den Pentest nach einer bestimmten Zeit, z.B. drei Monaten, zu wiederholen. Dadurch setzen Sie den Kunden unter Druck, die gefundenen Schwachstellen zeitnah zu beseitigen, und können die Umsetzung kontrollieren.

Es kommt sehr häufig vor, dass bei einem erneuten Test (auch als Re-Test bezeichnet) eine verbleibende Reihe von Schwachstellen existiert. Das wird das Management des Unternehmens vermutlich wissen wollen, auch wenn Sie hier vermutlich keine Freunde unter den Sicherheitsverantwortlichen finden werden – da diese ihren Job an dieser Stelle entweder nur unzureichend gemacht haben oder aufgrund von Arbeitsüberlastung oder mangels Budget nicht dazu in der Lage waren, die Schwachstellen zeitnah zu beseitigen. Im Endeffekt sollten Sie durch eine entsprechend positive Kommunikation jedoch in der Lage sein, alle ins Boot zu holen und klarzumachen, dass Sie die Verbesserung der Sicherheit im Sinn haben und niemandem auf die Füße treten wollen.

32.4   Der Pentest-Report

Ein großer Unterschied zwischen einem echten Hacking-Angriff und einem Penetrationstest ist die Dokumentation. Mit dem Pentest-Report liefern Sie dem Auftraggeber am Ende des Penetrationstests einen schriftlichen Nachweis Ihrer Tätigkeiten, der gefundenen Schwachstellen, deren konkrete Ausnutzung und last, but not least, Vorschläge zur Beseitigung der Schwachstellen.

Wichtig: Sie werden nach dem Pentest-Report bewertet!

Ihre Arbeit als Pentester wird vom Auftraggeber in erster Linie nach dem Report beurteilt. Sie können einen tollen Job als Pentester machen, aber wenn Sie Ihre Tätigkeit nicht anschließend auch adäquat dokumentieren, kann der Kunde das nicht beurteilen. Legen Sie daher besonderen Wert auf die Erstellung eines ausführlichen, aussagekräftigen und hilfreichen Reports.

Achten Sie jedoch auch darauf, dass der Report nicht zum Selbstzweck wird und zweifelhafte Schwachstellen aufgeführt werden, die bei genauerem Hinsehen bzw. im konkreten Kontext keine sind. Es kommt leider nicht selten vor, dass dem Management wenig relevante Findings (Sicherheitslücken) präsentiert werden, nur um den Report schöner aussehen zu lassen und die eigene Arbeit zu rechtfertigen.

Nachfolgend schauen wir uns an, worauf es in einem Pentest-Report ankommt. Und hier starten wir auch gleich nachfolgend mit dem wichtigsten Punkt.

32.4.1   Dokumentation während des Pentests

Die Erstellung des Reports beginnt nicht erst nach dem Ablauf des praktischen Penetrationstests. Stattdessen sollten Sie von Anfang an Ihre Analysetätigkeiten und natürlich die entsprechenden Ergebnisse dokumentieren. Hier trennt sich auch die Spreu vom Weizen: Während Profis die Abläufe und Ergebnisse zeitnah und prozessintegriert erfassen, beginnen andere zunächst mit dem praktischen Pentesting und verschieben die Dokumentation auf später. Dann allerdings besteht die Gefahr, dass wichtige Informationen und Details verloren gehen, die während des Pentests gesammelt wurden.

Viele Assessment-Tools bringen ihre eigenen Reporting-Module mit und erleichtern die Dokumentation sowie die Erstellung des Pentest-Reports. Darüber hinaus existieren zahlreiche Tools zur Dokumentation von Prozessen. Auch Office-Programme, wie z.B. MS Word oder Excel bzw. analoge Tools können Sie nutzen.

Oft reichen aber auch einfache Programme aus, um die wichtigsten Erkenntnisse eines Penetrationstests zu erfassen. Eines dieser Tools ist das freie, unter der GPL stehende KeepNote. Es ist auf allen gängigen Plattformen verfügbar und steht auch in Kali Linux zur Verfügung. Es ist einfach zu nutzen und unterstützt durch den hierarchischen Aufbau eine klare Dokumentationsstruktur (vgl. Abbildung 32.3).

Ein wichtiger Bestandteil der Dokumentation sind Screenshots. Während Kali Linux das Tool Kazam‌ vorinstalliert bereitstellt, um Screenshots und Bildschirmvideos zu erstellen, können Sie unter Windows die mit Windows mitgelieferte App Snipping Tool nutzen oder das freie und sehr leistungsfähige Greenshot‌. Es gibt diverse weitere Programme für diesen Zweck. Wir nutzen das kostenpflichtige Snagit‌ von Techsmith. Es bietet zahlreiche Bearbeitungsmöglichkeiten. Mit diesem Tool sind auch die Screenshots für dieses Buch entstanden.

Weitere nützliche Dokumentationstools sind Microsoft OneNote und Notepad++‌. Darüber hinaus können Sie natürlich auch jedes andere Tool nutzen, das Ihnen geeignet erscheint und mit dem Sie vertraut sind. Wichtig ist, dass die Dokumentation gleich zu Beginn des Audits beginnt und nicht erst im Anschluss.

[Bild]

Abb. 32.3: KeepNote bietet eine einfache Dokumentationsoberfläche.

32.4.2   Was umfasst der Pentest-Report?

Grundsätzlich richtet sich der Inhalt des Pentest-Reports nach dem Ziel, das mit dem Kunden vereinbart wurde. In der Regel werden jedoch zwei Dokumente erstellt:

Darüber hinaus sind weitere Reports denkbar, wie z.B. Zusammenfassungen für ausgewählte Netzwerkbereiche oder besonders sensible Systeme oder aber eine isolierte Zusammenfassung der empfohlenen Maßnahmen. Welche Auswertungen der Kunde wünscht, muss vorab abgesprochen werden.

Allen Pentest-Reports ist gemein, dass sie zu jeder gefundenen Schwachstelle nicht nur eine Beschreibung, Einschätzung und Bewertung erhalten, sondern insbesondere auch einen Maßnahmen-Katalog mit Empfehlungen, wie sie zu beseitigen ist. Unter dem Strich dient ein Pentest nicht dazu, zu demonstrieren, wie toll der ausführende Ethical Hacker ist, sondern dazu, die IT-Systeme des Kunden nachhaltig sicherer zu machen.

32.4.3   Aufbau des Pentest-Reports

Da der Management-Report nur eine Kurzform des technischen, ausführlichen Reports ist, konzentrieren wir uns hier auf den technischen Report. Natürlich gibt es verschiedene Ansätze, einen Pentest-Report zu verfassen, aber der nachfolgende Aufbau entspricht Best Practices.

Vertraulichkeitserklärung und formale Abschnitte

Während das NDA in der Regel ein separates Dokument ist, sollte der Pentest-Report zu Beginn darauf verweisen, dass die hier genannten Informationen vertraulich sind und entsprechend behandelt werden müssen. Auch ein formaler Abschnitt, der klarstellt, dass der Pentester keine Garantie für die Richtigkeit der bereitgestellten Informationen liefern kann, da sich die Situation bereits durch eine geringe Änderung der Parameter punktuell anders darstellen kann, sollte enthalten sein. Es bieten sich unter Umständen auch Abschnitte mit Kontaktdaten des Verantwortlichen, Namen der Autoren und Revisionsangabe an.

Inhaltsverzeichnis

Für ein ordentliches Dokument sollte immer auch ein Inhaltsverzeichnis erstellt werden. Es hilft dabei, die Übersicht zu bewahren und gezielt zu bestimmten Stellen zu springen. Der Kunde weiß es zu schätzen, wenn Sie ihm ein sauber strukturiertes Dokument vorlegen.

Beauftragung und Ziel des Pentests

Als Einleitung sollten die Form der Beauftragung (wer hat was beauftragt?) und das Ziel des Pentests aufgeführt werden. In diesem Zusammenhang können auch der formale Rahmen (White-Box-Test mit oder ohne Credentials etc.) und der Testzeitraum genannt werden.

Zu testende Zielsysteme (Scope)

Ganz wichtig ist es, den Bereich der IT-Infrastruktur bzw. die Systeme zu benennen, um die es bei dem Test geht. Dabei sollten auch die vereinbarten Freiheiten und Grenzen genannt werden, sprich: auch die Komponenten genannt werden, die explizit außen vorgelassen wurden. Im Zweifel liegt einem Verantwortlichen später nur dieser Report, nicht jedoch die Beauftragung im Detail vor. Er muss also auf alles Wesentliche schließen können, ohne weitere Dokumente zurate ziehen zu müssen.

Zusammenfassung (Executive Summary)

Auch wenn es eine Management-Zusammenfassung gibt, sollte auch im ausführlichen Dokument eine sogenannte »Executive Summary« zum Anfang auftauchen, um die Key Facts, also die wichtigsten Punkte, gleich zu Beginn herauszuarbeiten. Kaum ein Kunde wird es Ihnen danken, wenn Sie es spannend machen, die gesamte Geschichte Ihres Pentests inklusive Pleiten, Pech und Pannen erzählen und erst ganz zum Schluss des Dokuments auf die Ergebnisse zu sprechen kommen. Oberstes Gebot ist Klarheit, Einfachheit und Übersichtlichkeit.

Die Executive Summary enthält auch oben erwähnte Tabellen, Grafiken und Diagramme, die die Findings nach Schweregrad (engl. Severity) und ggf. nach anderen Kriterien sortiert, darstellen. Hier liefern die Auswertungstools der Vulnerability-Scanner in der Regel viele Möglichkeiten der Darstellung, von denen Sie sich inspirieren lassen können.

An dieser Stelle können Sie auch bereits die empfohlenen Maßnahmen platzieren. Es ist aber auch möglich, hier auf die jeweiligen Detailbesprechungen zu verweisen. In den Management-Report gehören sie auf jeden Fall hinein.

Methodik der Durchführung

Auch die bereits oben beschriebene Methodik der Durchführung sollte unbedingt dargestellt werden. Dies dient der Klarheit und zeigt, dass der Pentest unter professionellen Gesichtspunkten mit Best-Practice-Methoden durchgeführt wurde. Wie detailliert Sie an dieser Stelle Ihr Vorgehen formal beschreiben wollen, hängt vom Szenario ab und ist Ihnen überlassen.

Ablauf des Penetrationstests

Nachfolgend können Sie eine Beschreibung des tatsächlichen Ablaufs des Penetrationstests einfließen lassen und bestimmte Ereignisse dokumentieren, falls dies einen Mehrwert bietet. In einigen Fällen gibt es z.B. aufgrund von verschiedenen Faktoren Planänderungen und es werden Anpassungen notwendig. Es gibt auch die Möglichkeit, den Ablauf nach Phasen geordnet zu beschreiben. Wichtig ist immer, ob es dem Kunden einen Mehrwert bringt oder die Erläuterung aus Ihrer Sicht notwendig für das Gesamtbild ist.

Es ist auch in der Regel sinnvoll, die einzelnen Tests, die durchgeführt wurden, inklusive deren Ergebnissen aufzuführen. Dabei kommt in vielen Fällen heraus, dass keine Schwachstellen entdeckt wurden, aber auch das ist für den Kunden wichtig zu wissen. Durch diese Abschnitte kann der Kunde erkennen, welche Bereiche Sie in welcher Form geprüft haben. Somit dient dies auch als Arbeitsnachweis.

Findings im Detail

Nun folgen die gefundenen Schwachstellen. Diese müssen beschrieben werden und sind in Risikostufen einzuteilen (z.B. critical, high, medium, low, none, am besten farblich entsprechend markiert). Die Art, wie die Schwachstelle ausgenutzt werden konnte, sollte detailliert und, wo sinnvoll, mit Abbildungen wie Screenshots oder schematischen Darstellungen verdeutlicht werden.

In diesem Zusammenhang sollten alle Findings auch durch entsprechende Textausgaben bzw. Screenshots durch den Pentester bewiesen werden. Wir haben in diesem Buch immer wieder gezeigt, wie das geschehen kann.

Sehr wichtig ist die Einschätzung des Pentesters, wie die Schwachstelle zu bewerten ist. Dies sollte erläutert und dadurch besser nachvollziehbar werden. Hier ist es allerdings auch oft sinnvoll, mit dem Auftraggeber bzw. mit den Verantwortlichen zu sprechen, da ein Ermessensspielraum besteht und ein »High-Finding« (also rot) in einigen Situationen hohen Druck auf die jeweilige Abteilung aufbaut.

Um hier (teilweise heftige) Auseinandersetzungen zu vermeiden, sollte ein vermeintliches High-Finding besprochen und gemeinsam bewertet werden, wenn dies im Ermessen des Pentesters liegt. Hier kommt es nämlich oft auch auf die Rahmenparameter an, ob die Schwachstelle tatsächlich ausgenutzt werden kann – das kann der Pentester in einigen Fällen nicht vollständig einschätzen. Von daher kann eine sehr gefährliche Schwachstelle vorliegen, da aber das betreffende System nur durch vertrauenswürdige, interne Systeme angesprochen werden kann, ist die Schwachstelle auf »medium« zu setzen, da die Wahrscheinlichkeit, dass sie ausgenutzt werden kann, eher gering eingestuft wird.

Empfehlungen zur Beseitigung der Schwachstellen

In jedem Fall sollten zu jedem Finding entsprechende Vorschläge unterbreitet werden, wie die jeweilige Schwachstelle zu beheben ist. Hierbei ist auch die besondere Situation des Kunden zu berücksichtigen. In einigen Fällen reichen die Standard-Maßnahmen nicht aus, sondern müssen durch spezifische Maßnahmen ergänzt werden.

In jedem Fall ist dieser Teil der entscheidende für den Kunden. Zwar ist es spannend, ihm die diversen Schwachstellen zu präsentieren und darüber zu berichten, wie es dem Pentester gelungen ist, in die jeweiligen Geräte einzudringen und welcher Schaden dadurch entstehen würde, aber letztlich möchte der Kunde im Anschluss an den Pentest als Ergebnis eine Verbesserung seiner IT-Sicherheit erreichen. Stellen Sie also sicher, dass Ihre Empfehlungen dem Kunden tatsächlich hilfreich sind und nicht nur pauschale Informationen darstellen, wie zum Beispiel »Die Firewall konfigurieren«. Stattdessen formulieren Sie: »Die Firewall sollte die Kommunikation aus dem Internet auf Port 135/tcp und Port 111/tcp auf das Zielsystem blockieren und sicherstellen, dass Kommunikationsversuche protokolliert werden.«

Bewertung des Gesamtergebnisses

Am Schluss des Pentest-Reports ist es in der Regel sinnvoll, eine Zusammenfassung (engl. Summary oder Conclusion) zu verfassen, um das Ergebnis als Ganzes zu bewerten und zudem die nun anstehenden Aufgaben des Auftraggebers zur Beseitigung der Findings zusammenzufassen. Dies ist der Call-to-Action, um noch einmal klarzustellen, in welcher Form der Auftraggeber jetzt aktiv werden muss. Dabei ist zu berücksichtigen, wie der Auftraggeber generell zur Akzeptanz von Risiken steht. Eine Bank hat hier sicher andere Anforderungen als ein Bauunternehmer. Von daher sollten Sie auch die Formulierungen entsprechend anpassen.

32.5   Abschluss und Weiterführendes

Ist der Penetrationstest abgeschlossen und der Bericht verfasst, folgt in der Regel die persönliche Besprechung mit dem Auftraggeber und die Aufarbeitung der Findings. Schauen wir uns an, wie dieser Prozess typischerweise abläuft.

32.5.1   Das Abschluss-Meeting

Der Penetrationstest und dessen Ergebnis werden in der Regel in einem Abschluss-Meeting mit den Beteiligten besprochen. Jedem Teilnehmer an diesem Meeting sollte zu diesem Zeitpunkt eine Kopie des Pentest-Reports vorliegen.

Der Pentester zieht ein Resümee und die Findings werden besprochen. Hierbei ist es sehr wichtig, dass der Pentester sich als Consultant versteht und beratend tätig wird. Die Findings sind immer nur der erste Schritt. Daraus müssen entsprechende konkrete Maßnahmen zur Verbesserung der IT-Sicherheit und zur Beseitigung der Schwachstelle abgeleitet werden.

Je nach Unternehmen bzw. Organisation sind Sie nun gefordert, die erforderlichen Maßnahmen mit dem Auftraggeber zu erarbeiten. Hier ist es wiederum eine Frage des Umfangs, ob sich daraus ein neuer Auftrag ergibt oder ob dies im Rahmen des Abschluss-Meetings und des Pentest-Reports abgedeckt werden kann. Zum Abschluss des Gesprächs sollte dem Auftraggeber klar sein, welche To-dos er aus dem Gespräch mitnimmt, um die gefundenen Schwachstellen zu beseitigen, und wo die Prioritäten liegen.

32.5.2   Weiterführende Tätigkeiten

Inwieweit der Pentester die zu ergreifenden Maßnahmen zur Beseitigung der Findings begleitet, ist dem Kunden überlassen. Das Angebot sollten Sie ggf. unterbreiten, aber ob Sie an dieser Stelle benötigt werden, hängt stark davon ab, wie das Unternehmen, für das Sie tätig sind, aufgestellt ist.

Oftmals haben die Unternehmen eigene Teams für die IT-Sicherheit und gut ausgebildete Security-Administratoren, sodass das technische Know-how durchaus vorhanden ist, um adäquat zu reagieren. Gerade in Behörden und öffentlichen Verwaltungen wird dagegen nicht selten gewünscht, dass der Dienstleister an dieser Stelle den weiteren Verlauf auch zur Verbesserung der IT-Sicherheit unterstützend begleitet.

In jedem Fall sollten Sie jedoch einen Folgetest vorschlagen (Re-Test), bei dem Sie nach einer gewissen Zeitspanne, z.B. drei Monaten, den Penetrationstest erneut durchführen, um zu prüfen, ob die Findings beseitigt wurden oder nicht. Es ist mit großer Sicherheit davon auszugehen, dass einige Findings noch vorhanden sind und andere Schwachstellen entdeckt werden.

Es kann vorkommen, dass das Ziel des Pentests aus zeitlichen oder anderen Gründen nicht vollständig erreicht werden konnte. Hier kann im Bericht und im Abschluss-Meeting darauf verwiesen werden, dass noch Aufgaben ausstehen, die in einem weiteren Pentest zu absolvieren sind.

Somit zeigt sich, dass der Prozess der Sicherheit ein sich immer drehendes Rad ist, da die Dynamik in der IT generell extrem hoch ist und eine Aussage, die heute noch Gültigkeit hat, ggf. morgen schon wieder obsolet sein kann.

32.6   Zusammenfassung und Prüfungstipps

Werfen wir wieder einen Blick zurück: Was haben Sie gelernt, wo stehen Sie und wie geht es weiter?

32.6.1   Zusammenfassung und Weiterführendes

Der Begriff »Penetrationstest« beschreibt einen strukturierten Test der IT-Sicherheit in der Perspektive und mit den Mitteln eines Hackers. Es gibt viele Gründe, um einen Penetrationstest durchzuführen. Er ist einer der effektivsten Wege, die eigene IT-Sicherheit auf Herz und Nieren prüfen zu lassen und anschließend die gefundenen Schwachstellen zu beseitigen.

Ein häufiger Grund, Penetrationstests durchführen zu lassen, ist eine rechtliche oder andere normative Anforderung. Es existieren diverse Gesetze, die sich mit der IT-Sicherheit beschäftigen – einige davon fordern direkt oder indirekt ein Security-Audit, woraus die Anforderungen für einen Penetrationstest abgeleitet werden können.

Es gibt verschiedene Arten des Penetrationstests. Er kann als White-Box-Test (der Pentester weiß alles über das Ziel) oder als Black-Box-Test (der Pentester weiß nichts über das Ziel) durchgeführt werden. Auch Grey-Box-Tests sind möglich, bei denen der Auftraggeber dem Pentester nur bestimmte Informationen zukommen lässt. Ein erweitertes Konzept ist das Red Teaming, bei dem eine unabhängige Gruppe von Ethical Hackern als Angreifer auftritt und versucht, die Sicherheitsmaßnahmen des Blue Teams, also der Sicherheitsverantwortlichen des Unternehmens, auszuhebeln.

Bei der Durchführung von Penetrationstests sind vorab diverse Fragen zu klären, die im schriftlichen Auftrag aufgeführt werden sollten. Dies sichert auch den Pentester ab, der ohne einen solchen autorisierten Auftrag mit seinen Aktivitäten sehr schnell mit einem Bein im Gefängnis steht.

Penetrationstests sind professionelle Sicherheitstests, die sich einer bestimmten Methodik bedienen. Es existieren verschiedene Methoden und Frameworks, die den Ablauf eines Pentests oder Security-Audits beschreiben. Hierzu gehören freie Anleitungen wie MITRE ATT&ACK Framework, OSSTMM, OWASP und ISSAF oder das Diamond Model sowie proprietäre Vorgehensweisen, die Unternehmen, die Pentests anbieten, entwickelt haben.

Bei einem Pentest sind viele Fallstricke vorhanden, die ein erfahrener Pentester umschiffen kann, indem er sich gut vorbereitet und dafür sorgt, dass auch sein Auftraggeber gut vorbereitet ist. Ansonsten drohen unangenehme Situationen und ein ineffizienter Test aufgrund von Zeitverlust und unnötigen Diskussionen und so weiter.

Zu einem Pentest gehört auch immer ein Pentest-Report. Dieser umfasst insbesondere die gefundenen Schwachstellen, die nach ihrem Schweregrad und ihrer Eintrittswahrscheinlichkeit bewertet werden. Hierzu werden Empfehlungen zur Beseitigung der jeweiligen Schwachstelle formuliert.

Auf www.hacking-akademie.de/buch/member finden Sie weitere Materialien wie z.B. einen Beispiel-Pentest-Report und weitere interessante Links.

32.6.2   CEH-Prüfungstipps

Als CEH-Anwärter sollten Sie sich mit den verschiedenen Varianten der Penetrationstests auskennen und auch die Begriffe »Penetration Test«, »Vulnerability Assessment« und »Security Audit« definieren und voneinander unterscheiden können. Ebenso sollten Sie den Charakter von Red Teaming bzw. Blue Teaming beschreiben können.

In der CEH-Prüfung können Ihnen Fragen zu den rechtlichen Bestimmungen und Standards begegnen, sodass Sie hier sattelfest sein sollten. Stellen Sie insbesondere sicher, dass Sie die amerikanischen Gesetze verstanden haben. Die deutschen Gesetze werden mit großer Sicherheit keine Rolle im CEH-Examen spielen.

Eine gewisse Wahrscheinlichkeit besteht, dass Sie auf Fragen hinsichtlich der Methodik stoßen werden. Sie sollten also die gängigen Methoden wie OSSTMM, OWASP und ISSAF kennen und berücksichtigen, dass auch das EC-Council einen eigenen, proprietären Standard für Penetrationstests bereitstellt, der laut eigenen Aussagen als Industriestandard anerkannt ist.

Hinsichtlich des Pentest-Reports dürften eher weniger Fragen auf Sie zukommen. Diese Aussage ist unter Vorbehalt, da sich der Fragepool jederzeit ändern kann und weitere Fragen aus neuen Bereichen hinzukommen können.

32.6.3   Fragen zur CEH-Prüfungsvorbereitung

Mit den nachfolgenden Fragen können Sie Ihr Wissen überprüfen. Die Fragestellungen sind teilweise ähnlich zum CEH-Examen und können daher gut zur ergänzenden Vorbereitung auf das Examen genutzt werden. Die Lösungen zu den Fragen finden Sie in Anhang A.

  1. Welcher Prozedur sollte ein Ethical Hacker als Erstes folgen, wenn er in einem Unternehmen tätig werden soll?

    1. Eine Analyse durchführen, was das betreffende Unternehmen als schützenswert betrachtet und hierzu ein Assessment durchführen

    2. Die Ergebnisse des Penetrationstests dokumentieren und durchsprechen

    3. Mit dem Penetrationstest beginnen, um keine Zeit des Kunden zu vergeuden

    4. Einen formalen Vertrag mit der Beauftragung aufsetzen und eine NDA-Vereinbarung unterschreiben

    5. Abklären, ob White- oder Black-Box-Testing gewünscht ist

  2. Zwecks Einhaltung der Compliance-Anforderungen führt die AVC Allgemeiner Verkehrsclub GmbH ein Security-Audit seiner Systeme und Netzwerke durch. Welches der folgenden Tools wird in derartigen Szenarien vorwiegend zum Einsatz kommen?

    1. Vulnerability-Scanner

    2. Portscanner

    3. Protocol-Analyzer

    4. Penetration Frameworks wie Metasploit oder Empire

    5. Intrusion-Detection-Systeme

  3. Der ISO-Standard 27002 bietet Richtlinien und Empfehlungen für welchen Bereich?

    1. Best Practice für die Qualitätssicherung für die Informationssicherheit

    2. Kontrollmechanismen für die Absicherung von IT-Systemen

    3. Kennzahlen zu finanzieller Solidität und Rentabilität

    4. Best Practice für Configuration Management

  4. Sie werden mit einem Penetrationstest für ein mittelständisches Unternehmen beauftragt. Der Kunde möchte vertraglich festhalten, welche Methodologie Sie für den Test einsetzen. Welche der folgenden Aussagen beschreibt einen Vorteil von Pentest-Methoden?

    1. Sie sind durch jeden einsetzbar, sodass beliebige Plattformen getestet werden können.

    2. Sie sind für einen geringen Preis erhältlich und somit breit verfügbar.

    3. Sie werden durch öffentliche Regularien festgeschrieben und sind daher erforderlich.

    4. Sie bieten einen strukturellen Rahmen für die Durchführung von Penetrationstests.

  5. Ein Security-Unternehmen, das auf Penetrationstests spezialisiert ist, bietet im Rahmen einer Ausschreibung auf ein großes Pentest-Projekt. Das ausschreibende Unternehmen möchte Beweise für die Arbeitsqualität in Form von Nachweisen von bisher durchgeführten Audits des Bieters inklusive der entsprechenden Berichte. Was wird voraussichtlich passieren, wenn die Berichte übermittelt werden?

    1. Das Security-Unternehmen wird eine NDA-Vereinbarung einfordern, bevor die vertraulichen Pentest-Berichte anderer Kunden übermittelt werden können.

    2. Das Security-Unternehmen wird einen Aufschlag für die Übermittlung der Nachweise fordern.

    3. Das Security-Unternehmen läuft Gefahr, vertrauliche Informationen anderer Unternehmen preiszugeben.

    4. Das ausschreibende Unternehmen wird nach Übermittlung der Nachweise einen Pentest beauftragen, der in gleicher Form durchgeführt wird.

    5. Falls die Nachweise detailliert genug die Arbeitsqualität nachweisen können, wird das ausschreibende Unternehmen das Security-Unternehmen mit dem Pentest beauftragen.

  6. Welche Art der Sicherheitsanalyse wird durchgeführt, wenn der Penetrationstester nur teilweise Kenntnisse der internen Netzstrukturen und Anwendungen einer Organisation hat?

    1. White Box

    2. Announced

    3. Black Box

    4. Grey Box