Dass ein Pentest neben vielen Chancen auch Risiken mit sich bringt, muss einem Kunden im Rahmen einer Risikoaufklärung bewusst gemacht werden. Erst letztens wurde im Rahmen der Risikoaufklärung innerhalb einer Auftaktbesprechung die Frage gestellt
Der Penetrationstest ist doch dazu da, um Risiken aufzuzeigen – nicht um den Betrieb zu stören. Wie bekommen wir dieses Risiko denn ausgeschlossen?
Ein Kunde
In diesem Beitrag werden durch ein fiktives Kundengespräch zum Thema „Chancen und Risiken von Penetrationstests“ die Thematik und der Umgang damit näher erläutert.
Welche Risiken bringt denn ein Pentest mit sich?
Ein Kunde
Im Rahmen von Pentests werden Angriffe simuliert. Die größten Risiken eines Pentests sind die Einschränkung der Verfügbarkeit durch
- Ausfall des geprüften Dienstes / der geprüften Anwendung,
- Ausfall des Gesamtsystems oder
- Ausfall vor- oder nachgelagerter Systeme/Dienste/Anwendungen.
Die Usachen für Verfügbarkeitseinschränkungen können mannigfaltig sein. Um den Teufel mal an die Wand zu malen:
- Überlastung, z. B. durch rechenintensive Anfragen innerhalb der geprüften Anwendung oder eine entsprechend hohe Grundlast des Systems
- Datenverlust, z. B. durch fehler in Datenbankabfragen
Dadurch wird jedoch aus Pentester-Sicht (und sicher auch aus Kundensicht) nicht viel gewonnen. Ein Penetrationstest sollte aus unserer Sicht nie bewusst das Ziel verfolgen, die Verfügbarkeit einzuschränken, sondern viel mehr Schwachstellen aufdecken, die auf die Vertraulichkeit oder Integrität von Daten oder deren Verarbeitung Einfluss nehmen können. Daher führen wir standardmäßig keine Prüfungen durch, die Bewusst die Verfügbarkeit einschränken. Das allein schließt aber ein gewisses Restrisiko nicht aus.
Gibt es noch andere Risiken als den Ausfall des Systems?
Ein Kunde
Ja, die gibt es. Die lassen sich am Besten anhand eines Beispiels näher erläutern lassen.
Nehmen wir an, es soll ein Webshop, sowie die Plattform auf Sicherheit überprüft werden. Webshops haben viele Funktionen, darunter
- Nutzerkonten
- Wunschlisten
- Produktinformationsseiten
- der Warenkorb
- Kontaktformulare
- Bewertungsfunktionen
- …
Wenn der Geschäftsprozess von der reinen Produktinformation über Rückfragen via Kontaktformular bis hin zur Bezahlung geprüft werden soll, müssen folglich auch Kontaktanfragen gestellt oder Bestellungen durchgeführt werden.
Falls z. B. Scanwerkzeuge ein Kontaktformular prüfen und es dabei mehrere hundert mal absenden, wird das mit der Beantwortung betraute Support-Personal Luftsprünge vor Freude machen, weil auf einmal so viele Kontaktanfragen von vermeintlichen Interessenten auf sie einprasseln.
Um den Bezahlprozess zu prüfen, müssen Bestellungen getätigt werden. Werden diese z. B. auf Rechnung getätigt, besteht das Risiko, dass der Paketlieferdienst mit einem LKW anrücken muss die Bestellung fakturiert wird und die Buchhaltung mehrere Mahnungen für nicht gezahlte Bestellrechnungen verfassen und versenden muss.
In Summe besteht also die Gefahr, dass der Penetrationstest sich auf die mit dem IT-System abgebildeten Geschäftsprozesse auswirkt und mitunter nicht zu unterschätzende Kosten und Aufwände verursachen kann.
Lassen sich die Risiken vermeiden?
Ein Kunde
Kurze Antwort: Jein.
Lange Antwort: Ja, wenn man die Vorgehensweise bzw. angewandte Methodik ändert oder den Prüfgegenstand austauscht.
…Prüfgegenstand austauschen?
Ein Kunde
Ja, richtig gelesen. Eine Operation am offenen Herzen macht kein Entwickler/Systembetreuer gerne – auch der Pentester nicht. Daher haben viele Kunden für viele Anwendungen neben dem eigentlichen, produktiv genutzten IT-System sowohl ein Entwicklungs- als auch ein Test- oder Abnahmesystem. Warum also auf dem Produktivsystem prüfen, wenn es auch auf den anderen, weniger kritischen (aus Verfügbarkeitssicht) Systemen geht?
Wären da nicht die Einschränkungen der nicht-prduktiven Systeme. Viele Test- oder Abnahmesysteme unterscheiden sich entgegen der eigentlichen Annahme meist durch unterschiedliche Konfigurationen oder Ressourcen.
Reflektiert auf das Beispiel von oben gibt es oftmals bei Test- oder Abnahmesystemen keine (Test-)Anbindung an Bezahlanbieter oder das Kontaktformular wird erst gar nicht per Mail versandt. Dies stellt dann eine Testeinschränkung dar und sollte entsprechend im Ergebnis berücksichtigt werden.
Und was kann man an der Methodik verändern?
Ein Kunde
Wir stützen uns bei unseren Prüfungen auf bewährte Methoden, wie z. B. dem „Durchführungskonzept für Penetrationstests“ des Bundesamts für Sicherheit in der Informationstechnik. Man kann die Agressivität von Prüfungen bestimmen. Unterschieden wird zwischen „passiv scannend“, „vorsichtig“, „abwägend“ und „aggresiv“.
Na also, dann lassen sie uns passiv scannend oder vorsichtig wählen!
Ein Kunde
Naja. „passiv scannend“ bedeutet
„Bei der niedrigsten Aggressivitätsstufe werden die Testobjekte nur passiv untersucht, d. h. gefundene mögliche Schwachstellen werden nicht ausgenutzt.“
Durchführungskonzept für Penetrationstests
Das Problem dabei: um Festzustellen, ob eine Schwachstelle vorhanden ist, muss ein Penetrationstester versuchen, die Schwäche auszunutzen. Folglich würde passiv zu sein bedeuten, dass keine Versuche zum Ausnutzen einer evtl. vorhandnen Schwäche unternommen werden.
Ja gut, dann nehmen Sie halt „vorsichtig“!
Ein Kunde
Ja, das sind wir immer. Aber nach der Definition darf ich dann nur rudimentäre Prüfungen durchführen wie z. B. das Abprüfen von Standardkennworten. Das geht leider nicht tief genug und es sollte mindestens „abwägend“ gewählt werden.
Ja gut, was aber, wenn dann was passiert?!
Ein Kunde
Dann haben wir noch eine Karte: Sie wissen bei einem Penetrationstest, wer Sie angreift, kennen seine Telefonnummer und können – entgegen einem echten Angriff – einen Testabbruch veranlassen.
Zwar können Prüfungen dann nicht immer an der Stelle fortgesetzt werden, an dem die Prüfungen unter- oder abgebrochen wurden, aber zumindest können betriebliche Probleme in den Griff gebracht werden oder der „Störfaktor Penetrationstester“ zunächst aus der Gleichung genommen werden.
Ja gut, dann passen wir die Gleichung weiter an und nehmen wir einfach <Name beliebiger Funktion / eines Systems> aus dem Prüfungen aus
Ein Kunde
Das kann man tun. Ratsam ist es jedoch nicht, denn wird der Ergebnisgehalt des Pentests um genau die Fragestellung „Was wäre, wenn Funktion XY / Gegenstand XY angegriffen wird?“ reduziert.
Fazit
Man führt einen Penetrationstest durch, um Schwachstellen zu identifizieren, bevor sie jemand anderes/fremdes identifizieren könnte.
Obwohl meist eine Vorgehensweise gewählt wird, bei der bewusst auf verfügbarkeitseinschränkende Prüfungen verzichtet wird, können dennoch Probleme auftreten. Diese können sich dabei mitunter auf den Prüfgegenstand selbst oder vor- bzw. nachgelagerte Systeme / Prozesse auswirken.
Die genannten Auswirkungen (Ausfall oder Beeinflussung der mit dem Prüfgegenstand abgebildeten Prozesse) lassen sich nicht gänzlich vermeiden, sondern lediglich mit entsprechenden Maßnahmen (Wahl der Vorgehensweise, Austausch des Prüfgegenstand (Produktiv- vs. Abnahmesystem) oder geklärte Meldewege) weitestgehend minimieren.
Ohne einen Angriff zu simulieren wird man nie in Erfahrung bringen, wie sich ein Prüfgegenstand verhält, wenn ein Angriff durchgeführt wird.
Schließlich ist ein Vorteil bei einem Penetrationstest gegenüber einem realen Angriff neben der Tatsache, dass gefundene Schwachstellen identifiziert werden, dass man weis wer den Untersuchungsgegenstand penetriert und an wen man sich im Fall der Fälle wenden kann, um Prüfungen zu unterbrechen und weitere Beeinträchtigungen vorerst auszuschließen.