Bei einem Penetration Test steht in der Regel das Identifizieren von Schwachstellen, deren Ausnutzung sowie das Abschätzen möglicher Folgeschäden im Vordergrund. Schwachstellen ist dabei ein etwas weit gefasster Begriff: Je nach Projektrahmen, können Schwachstellen sehr konkreter technischer, aber auch sehr tiefgehender konzeptioneller Natur sein.

Ein gutes Beispiel dafür sind lokale Firmennetzwerke. Schwachstellen, die hier beobachtet werden, sind oftmals systemischer Natur: Träges Patch Management kann dazu führen, dass Schwachstellen ausnutzbar bleiben, die eigentlich durch den Hersteller bereits geschlossen wurden. Fehlende oder ineffektive Netzwerküberwachung führt dazu, dass ein Angriff über längere Zeit hinweg unentdeckt bleibt und zu Folgeschäden führt. Tests von Webapplikationen sind dagegen ein gutes Beispiel für Projekte, die traditionell eher konkrete Findings zu Tage fördern: Fehlende Eingabevalidierung führt zu Cross Site Scripting oder SQL Injection. Security Header wurden nicht korrekt gesetzt, Cookies nicht mit den korrekten Flags versehen.

Diese Unterschiede spielen eine entscheidende Rolle bei der Berichterstattung über die getätigten Überprüfungen. Der Nutzen der gefundenen Schwächen hängt für den Auftraggeber im Regelfall stark davon ab, wie konsistent, präzise und ausführlich der Report ausfällt. Nicht selten herrscht initiales Erstaunen darüber, dass bei einem Penetration Test oftmals rund ein Drittel des Gesamtaufwandes für die Erstellung entsprechender Berichte verwendet wird.

Was vielen angehenden Penetration Testern anfangs nicht bewusst ist, ist die Notwendigkeit und Wichtigkeit von adäquaten Empfehlungen zur Mitigation oder gar gesamthaften Behebung von Schwachstellen. Der Auftrag des Penetration Testing endet nicht mit der Identifikation der Schwachstelle, sondern deren möglicher Elimination.

Die oben ausgeführte Bandbreite von sehr konkreten, technischen Fehlern bis hin zu konzeptionellen Fehlüberlegungen ist hier umso gravierender. Konkrete Schwachstellen sind oftmals einfach zu adressieren: Empfohlen wird, die betroffene Codezeile zu korrigieren, eine Konfiguration anzupassen oder einen obsoleten Dienst abzuschalten. Das ist nicht immer so: Bei komplexen Webapplikationen deuten mehrere, punktuell identifizierte, Schwachstellen mit gewissen Charakteristiken oft auf Qualitätsprobleme der Software hin, die generell adressiert werden sollten. Im Regelfall aber, ist das Abgeben von Empfehlungen hier verhältnismässig einfach.

Was aber, wenn die identifizierten Schwachstellen sich nicht mit ein bis zwei konkreten Massnahmen adressieren lassen? Was, wenn die Massnahme eben generisch lauten müsste Patch Management verbessern oder Fehlende Incident Response aufbauen?

Diese Gegenmassnahmen sind valide, aber lassen Kunden oftmals ratlos zurück: Ein internes CERT, einen verlässlichen Secure Software Development Lifecycle (SDLC), umfassende Erkennung von ungewöhnlichem Benutzerverhalten – das alles sind valide Empfehlungen, die sich nicht innen Tages- oder Wochenfrist umsetzen lassen, sondern ein tiefergehendes Commitment von technischem Personal und Top-Management erfordern.

Penetration Testing Teams sollten dabei mit offenen Karten spielen: Übermässige Vereinfachung von Gegenmassnahmen nützen am Ende niemandem etwas, sondern führen oftmals höchstens zu Verwirrung und verzerrten Erwartungshaltungen. Der klare, ehrliche Hinweis, dass gewisse Problematiken nicht in einer einzigen Tabellenspalte mit der Beschriftung Gegenmassnahme abgehandelt werden können, sondern ganz zielgerichtet im Kontext des betroffenen Unternehmens diskutiert werden sollte, trägt schon viel zur zielorientierten und konstruktiven Problembehandlung zu. Das widerspricht dem oftmals gehörten Ruf nach Sofortmassnahmen nicht. Sofortmassnahmen machen Sinn, sind aber als Symptombehandlung zu verstehen: Sie lösen nicht die Ursache des Problems, sondern verhindern in erster Linie die kurzfristige, akute Ausnutzung durch einen realen Gegenspieler, der sich unter Umständen nicht an die Zeitachse einer nachhaltigeren Mitigation halten dürfte.

Oftmals ist es auch angebracht, bei komplexeren Mitigationsplänen entsprechende Spezialisten zuzuziehen. So ist es, in unserem konkreten Beispiel der scip AG, nicht unüblich dass nach einem erfolgreichen Penetration Test die komplexeren Massnahmenpläne in Zusammenarbeit mit dem, auf defensive Massnahmen spezialisierten, Blue Team koordiniert werden, je nachdem sogar im Rahmen eines dedizierten Folgeprojektes. Wichtig ist am Ende, dass ein Penetration Test stets konstruktive Früchte trägt: Schwachstellen, die aus dem Schatten der Obskurität ans Licht getragen wurden und nun auf eine sinnvolle Weise adressiert werden.

Über den Autor

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.