Blackbox oder Whitebox Approach
Marc Ruef | 06.02.2006

Es ist Donnerstag Morgen, 09:00 Uhr. Ich stehe gerade am Fenster eines Sitzungszimmers, aus dem ich den gesamten Vorhof dessen überblicken kann. Einige schöne Autos sehe ich. Mercedes, Porsche und Jaguar - Vorwiegend High Class. Mir fällt dabei auf, dass sämtliche dieser in Dunkel gehalten oder mit einem schlichten Silber eingefärbt sind. Mittlerweile hat sich mein Kunde wieder zurückgemeldet, bringt mir mein gewünschtes Mineralwasser und sich selbst stellt er einen schwarzen Kaffee auf den runden Tisch.

Einmal mehr finde ich mich innerhalb eines Kickoff Meetings wieder, bei dem die technischen Details für die Durchführung eines Penetration Tests besprochen werden. Diese Bank, ein Neukunde, möchte die Perimeter-Sicherheit des öffentlichen Netzes ausgetestet haben, um potentielle Schwachstellen zu erkennen und gegen diese Massnahmen zu ergreifen.

Wie immer frage ich die anwesenden Herren, beide zuständig für das technische Management der Umgebung, nach ihrem Befinden. Beiläufig erwähne ich, dass ich vor einigen Jahren - mindestens 4 müssen es sein - schon einmal hier war, mich jedoch nicht mehr an meinen Kontakt erinnern könne, was mit der unendlichen Vergesslichkeit, die mir anheim fällt, zusammenhänge. Der Netzwerkadministrator meinte daraufhin, dass er sich zwar nicht an ein solches Treffen erinnern könne. Aber mein Name sei ihm von einem meiner Interviews für das Nachrichtenmagazin 10vor10 (http://www.10vor10.ch) geläufig. Der Situation mit Ironie entgegenhaltend erwiderte ich, dass ich aufgrund dieser Tatsache gerne gegen Bezahlung ein Autogramm aushändigen würde...

Das Gespräch verlief typisch. Nicht nur, weil ich dies mittlerweile ein paar Duzend Male durchlaufen habe. Ebenso gewährt mir eine eigens angefertigte Kickoff-Checkliste das unkomplizierte Einholen der wichtigsten Informationen zur technischen Umsetzung des Projekts. Technische Daten sind für mich dabei mindestens so wichtig, wie administrative Wünsche (z.B. Detailtiefe des Reports oder Aufbereitung der Präsentation).

Schon sehr früh frage ich dabei nach den IP-Adressbereichen der zu testenden Umgebungen. Die beiden Herren sahen sich ob dieser Frage verdutzt an. Noch bevor der Schall des ersten Wortes mein Trommelfell erreichte wusste ich, was jetzt kommen würde. Dann wandten sie sich zu mir und meinten: "Diese geben wir Ihnen sicher nicht. Ein richtiger Hacker muss sich derlei Informationen ja auch selbst beschaffen!"

Es war nicht das erste Mal, dass ich diesen Widerstand bei der verflixten Frage 7 meiner Checkliste zu hören bekomme. Entsprechend gelassen, ja schon fast eine Arroganz der Ruhe vermittelnd, setzte ich zum argumentativen Gegenschlag an: "Sie sind der Kunde, Sie definieren die Ziele und geben den Takt an. An diesen werde ich mich natürlich halten. Aber bedenken Sie, dass ich kostbare Zeit verliere, mühe ich mich mit dem stupiden Zusammentragen von IP-Adressen ab. Als Spezialist bin ich sodann falsch plaziert, kann ich mein Wissen und die Erfahrung nicht richtig einsetzen."

Nur selten lässt sich der Widerstand zur Herausgabe von Informationen eines Audit-Projekts nicht mit solchen Worten brechen. Ein jeder Kunde hat bisher begriffen, dass es wirklich unsinnig ist, offensichtlich zusammentragbare Informationen zu verheimlichen und dadurch das eigentliche Testing zu behindern.

Die Vor- und Nachteile von Blackbox-Approaches, bei denen dem Tester die Informationen weitestgehend vorenthalten werden, sind den wenigsten Kunden von Anfang an bekannt. Ich tendiere vorwiegend zu offenen Tests, da sie effizienter ausfallen, da das mühselige und langwierige Zusammentrage von Detailinformationen entfällt. Als Auditor kann man sich auf die wirklich exklusiven Dinge, wie das effektive Ausnutzen einer vermeintlichen Schwachstelle konzentrieren. Oder würden Sie einen kostspieligen Gehirnchirurgen einsetzen, um mal eben nebenher einen Hustensaft zu verschreiben?

Blackbox-Tests machen nur dann Sinn, wenn man ein Real World-Szenario errichten will, bei dem es die echte Sicherheit einer Umgebung zu determinieren gilt. Dies ist jedoch meines Erachtens auch nur dann sinnvoll, wenn die Zielumgebung vorher schon umfassend überprüft (breitflächig auditiert) und weitestgehend abgesichert (Patching und Hardening) wurde. Nur dann können zielgerichtete Exploitings überhaupt noch einen wirtschaftlichen und technischen Vorteil versprechen. Alles andere ist das Einsetzen kostbarer Ressourcen am falschen Ort.

Im Übrigen trete ich ausnahmslos von jedem Audit-Projekt zurück, bei dem noch nicht mal die zu testenden IP-Adressbereiche bekannt sind. Und zwar deswegen, weil es zu Komplikationen kommen kann, weil beispielsweise der falsche Zielbereich eruiert wurde und die Checks auf eine nicht authorisierte Umgebung stattfinden. Juristisch können derlei Fauxpas schlimme Nachspiele haben, die ich um jeden Preis verhindern möchte - Auch wenn dies mit dem Verlust eines Projekts einhergeht. Dies bin ich jedoch der Professionalität meines Berufsstandes schuldig.