Kommentar: Schluss mit falschen Pentests!
Pentests sind ein gutes Mittel, um übersehene Sicherheitslücken zu finden. Aber es müssen auch die Voraussetzungen dafür stimmen, kommentiert Janis König.
(Bild: peterschreiber.media/Shutterstock.com)
- Janis König
Wir wollen einen Pentest machen. So begannen für einige Zeit viele meiner Kundengespräche – manchmal mit der Variation "müssen" statt "wollen". Doch warum pentesten wir überhaupt?
Wie andere fortgeschrittene Sicherheitsmechanismen bauen Pentests auf vorher umgesetzten Schutzmaßnahmen auf. Ohne die ist ihr Nutzen deutlich geringer. Denn Pentests sind ein Tool, um die Wirksamkeit solcher Maßnahmen zu verifizieren – gibt es keine Maßnahmen, werden sie selbstverständlich anschlagen. Aber was verifizieren Pentests genau? Um die Anwesenheit von Sicherheitslücken zu beweisen, brauche ich keinen Pentest – die gibt es, das garantiere ich.
Schritt Eins: Bekannte Probleme beheben
Pentests sind in ihrem Umfang eingeschränkt und werden nur punktuell, stichprobenartig Probleme finden. Heißt aber auch: Wenn ich "sicher werden" möchte, reicht es nicht, die gefundenen Probleme zu beheben. Dafür sind Pentests zu teuer. Hier muss vorher schon einiges passiert sein: statische Codeanalyse in der CI bei der Entwicklung, Vulnerability Scanner beim Deployment, Reviewprozesse, Weiterbildungen des Personals. Ist das nicht vorhanden, brauche ich nicht mit einem Test anzufangen: Ein Gang zur Entwicklungsabteilung oder zu den Admins ist günstiger und schneller. Die wissen oft Bescheid, in welchen Ecken Dreck zu finden ist.
Sind die Sicherheitsprozesse da (und werden genutzt), ist ein Pentest eine gute Möglichkeit, Dritte den Code oder das Netzwerk auf Punkte abklopfen zu lassen, die man übersehen hat. Und dann gehts in den nächsten Prozess: Abdeckung erhöhen, sodass zukünftig diese Art von Lücke an der Stelle gar nicht erst entstehen kann.
Grundlagen erfüllen, statt mit Checklisten erschlagen
Natürlich kann man auch vor der Einführung all dieser Prozesse Pentests beauftragen, um die Sichtbarkeit der Probleme zu verbessern und eine Übersicht zu gewinnen. Aber allzu häufig rennt man dann in Goodharts Gesetz: "Wenn ein Maß zum Ziel wird, hört es auf ein guter Maßstab zu sein." Es wird versucht, mit Checklisten die Fülle an Findings zu erschlagen, anstatt die Grundlagen anzugehen. Man rennt von einer Sofortmaßnahme in die nächste – und am Ende ist die Excel-Tabelle vielleicht grün, aber nach dem nächsten Pentest wird wieder alles rot sein. Oft sogar mit den gleichen Lücken: Mit dem nächsten Feature/Roll-out hat man denselben Fehler gemacht, nur in anderer Geschmacksrichtung. Ein nachhaltiger Lerneffekt ist ausgeblieben.
Zu guter Letzt: Pentests sind keine Angriffssimulation. Letztere überprüft die Effektivität von Defensivmaßnahmen wie von einem Blue Team, einem SOC oder SIEM, von EDR/XDR et cetera – alles Mechanismen, die darauf zielen, Angriffsmethoden und verdächtiges Verhalten zu erkennen. Hierfür ist eine möglichst realistische Simulation natürlich zwingend.
Pentest sollen eure Lücken finden!
Ein Pentest soll aber Schwachstellen finden, und zwar so viele unterschiedliche wie möglich. Daraus folgt auch, dass ein angeblich "realistischer" Blackbox-Test, bei dem die Pentester – ähnlich wie ein Angreifer – nichts über die zu testende Infrastruktur wissen, nur Aufwand bei den Testern erzeugt. Und durch weniger akkurate Ergebnisse auch bei den Getesteten für Mehraufwand sorgt. Und dann sind die Ergebnisse auch noch weniger umfangreich, da ein Großteil der bezahlten Zeit auf Orientierung und Informationssuche verschwendet wurde. Daher ist man besser beraten, den Scope zu verringern, den Test jedoch als Whitebox mit dem nötigen Vorwissen durchzuführen. Dann kann man wenigstens mit den Ergebnissen was anfangen.
(pst)