Angriff als unnötige Art der Verteidigung Marc Ruef | 08.06.2009 Müsste ich meiner Grossmutter meine Arbeit in einem Satz erklären, würde ich wahrscheinlich folgendes sagen: "Ich werde von Firmen bezahlt, dass ich mir ihre Computersysteme anschaue und Kritik daran übe, wie diese eingesetzt werden." Nicht alle Menschen lassen sich kritisieren. Ich muss das wissen, denn auch ich reagiere bei destruktiver und diplomatisch ungeschickt vorgetragener Kritik eher ungehalten und abwehrend. Es sollte jedoch in der Intelligenz des Menschen liegen, die konstruktiven Punkte herausnehmen und in der Verbesserung seiner Selbst zum Vorteil nutzen zu können. Doch nicht alle meiner Kunden sehen das gleich. Meine Fragen und Ratschläge werden dann als unhöflich und unnötig aufgefasst. Vor allem in grösseren Firmen ist der direkte Auftraggeber sehr selten derjenige, der im Rahmen des Projekts ebenfalls geprüft wird. Nicht selten ist es der Chief Security Officer (CSO) oder ein anderes Mitglied des höheren Managements, das eine Sicherheitsüberprüfung wünscht. Die Geprüften sind dabei meistens Administratoren oder Benutzer, die die Beweggründe der Vorgesetzten nicht nachvollziehen können oder wollen ("Ach, wieso darf ich nun plötzlich meine Emails auf Gmail nicht mehr lesen?"). Vor einiger Zeit war ich im Rahmen eines grösseren Projekts mit der Analyse einer Exchange Umgebung beschäftigt. Diese sollte von allen Blickwinkeln her begutachtet werden, um Fehlentscheide und Probleme ausmachen und denen beim Upgrade auf die nächste Version entgegenwirken zu können. Neben technischen Penetration Tests der jeweiligen Module (Client, Mailserver, Webserver) wurden ebenfalls Audit-Interviews mit den zuständigen Stellen (Projektleiter und Techniker) vereinbart. Am Montag Nachmittag sollte ich um 13:00 Uhr ein Interview mit einer Person führen, die sich für die Umsetzung des Email-Archivs verantwortlich zeichnet. Man hatte mich vorgängig mehrfach gewarnt, dass der besagte Herr sehr kritisch und der Umgang mit ihm nicht einfach sei. Da ich schon mehrere Hundert Audit-Projekte durchgeführt und so mancherlei erlebt habe, sah ich dem Meeting gelassen entgegen. Ich habe alle mir vorgelegten Dokumente aufmerksam durchgelesen und einen umfassenden Fragenkatalog zu diesen zusammengestellt. Angst vor dem Gespräch musste ich also bestimmt nicht haben. Pünktlich konnte das Interview starten. Ich hiess mein Gegenüber willkommen und leitete das Gespräch dadurch ein, indem ich meinen Auftrag kurz zusammenfasste. So sollte ich unter anderem im Rahmen des Exchange Penetration Test das Projekt EA2010 begutachten. Mein Gesprächspartner entgegnete darauf gelangweilt, dass es kein Projekt mit dem Namen EA2010 geben würde. Ich führt weiter aus, dass EA2010 für "Email Archive 2010" stehen würde, und dass ich seit Tagen die Dokumente dazu lesen würde. Erneut und sichtlich genervt wiederholte er, dass es kein Projekt EA2010 geben würde. Ich war verwirrt, griff sofort in meine Mappe und nahm ein Dokument mit dem Titel "EA2010 - Security Concept and Risk Analysis" hevor. Als ich es auf den Tisch legte fragte ich höflich, ob nicht er der Autor des besagten Schriftstücks sei. Weiterhin unfreundlich warf mir mein Gegenüber an den Kopf, dass das Projekt gefälligst nicht mehr EA2010 sondern neu EC2010 - nämlich "Email Collection 2010" - heissen würde. Ich nahm diese Information dankend zur Kenntnis und verkniff mir den Kommentar, dass in sämtlichen Dokumenten nach wie vor von EA2010 die Rede sei. Hellsehen, dass ein Projekt nun einen neuen Namen hat, liegt mir halt nicht so. Sodann leitete ich die effektive Fragerunde ein. Die Archivierung (oder musste ich nun "Sammlung" sagen) der Emails erfolgt, indem jedem Schreiben in einem versteckten BCC-Feld das Systemkonto des Archivsystems mitgegeben wird. In der Dokumentation konnte ich nirgends den Hinweis darauf finden, ob die Einführung der BCC-Definition auf dem Outlook-Client oder auf einem Mailserver erfolgt. Schon fast angewiedert von meiner Anwesenheit sagte der Interviewte, dass er meine Frage nicht verstehen würde. Kein Problem. Die Denkvorgänge und Denkmuster unterschiedlicher Personen sind oftmals komplett anders und so versuchte ich den Hintergrund meiner Frage zu illustrieren: Wird das BCC-Feld nämlich auf dem Client gesetzt, bestünde eventuell die Möglichkeit, diese Einfügung zu verhindern oder zu manipulieren. Einer Archivierung des Emails könnte so entgegengewirkt werden. Die fehlende Integrität und damit die Unglaubwürdigkeit des Archivsystems wäre die Folge davon. Als erstes würde die Rechtsabteilung auf die Barrikaden gehen, das wäre sicher. Einmal mehr sagte der gute Mann, dass er meine Frage nicht verstehen würde. Er fügte jedoch sogleich an: "Ich nehme an, dass Ihre Frage einfach nur dumm gestellt wurde. Ich werde sie jetzt aber einfach mal so beantworten, wie wenn sie klug gestellt worden wäre." Ich konnte mir ein Grinsen nicht verkneifen, als ich diesen monumentalen Satz auf meinem Interview-Fragebogen notierte. Zeitgleich dachte ich mir, dass die besagte Person aufgrund ihrer offenherzigen Dreistigkeit sehr klug sein muss und ich wohl in den kommenden 30 Minuten noch vieles lernen könnte. Also lauschte ich gespannt. Die Antwort war übrigens, dass das BCC-Feld nicht auf dem Client, sondern auf einem der Server forciert wird. Sehr gut. Ich kreutzte "passed" an. Warum meine Frage angeblich dumm gestellt wurde, war mir aber auch nach dem Dialog nicht klar. So dumm kann sie ja dann doch nicht gewesen sein, denn ich erhielt ja jene Antwort, die ich gebraucht habe. Der Rest des Interviews verlief in ähnlichem Stil. Immerwieder wurden durch mein Gegenüber Sticheleien geäussert. Auf eine Interview-Frage hin wurde eine Antwort verweigert mit der Begründung, dass diese nicht IT-relevant sei. Ich wies höflich aber bestimmt darauf hin, dass ich in diesem Gespräch derjenige bin, der entscheidet, was im Rahmen des Audits relevant ist und was nicht. Ironischerweise hat der gute Mann sich danach ein bisschen besser darum bemüht, mir entgegenzukommen. Wie sagt Friedrich Nietzsche so schön: "Vergiss die Peitsche nicht!" Ich habe meine immer griffbereit. Nach der doch etwas harzigen Diskussion ging ich zu meinem Auftraggeber, dem Chief Security Officer, und fasste kurz meinen Eindruck des Gesprächs zusammen. Dabei habe ich ausschliesslich die technischen Resultate resumiert und in keinster Weise auf die zwischenmenschlichen Reibungspunkte hingewiesen. Letztere interessieren hier schliesslich nicht. Und da ich wohl nicht der erste war, der sich eben jenem Gegendruck konfrontiert sah, sah ich keinen nutzen darin, meinen Unmut über diese ebenfalls nach Aussen zu tragen. Der Chief Security Officer war jedoch erstaunt ob dem Hinweis, dass das BCC-Feld auf den Servern durchgesetzt werden würde. "Angeblich wird das auf dem Client gelöst", hat er gesagt. Sogleich schickte er meinem ehemaligen Interview-Partner ein Email und bat um Aufklärung. Mein neuer bester Freund schrieb innert Sekunden zurück, dass ich ihn falsch verstanden hätte (ebenfalls in einem anderen Punkt). Da mein Auftraggeber schon so manches komplexe Projekt mit mir durchgeführt hat und weiss, wie sehr ich auf Genauigkeit achte, sah er mich verschmitzt ob dieser Dreistigkeit an. Er wartete wohl nur darauf, dass ich mich dieser erneuten Provokation hingeben wurde. Stattdessen sagte ich eher resigniert: "Bei einem Interview kann ich halt nichts anderes machen als mich darauf zu verlassen, dass mich die Leute nicht anlügen." Die weitaus interessantere Frage ist jedoch, warum eine solch extreme Abwehrhaltung zelebriert wurde. Ging es darum die Mühsamkeit mit Provokationen etwas unterhaltsamer zu machen? Oder erachtete man den Angriff als die beste Form der Verteidigung. Meine Erfahrungen lassen vermuten, dass Letzteres eher zutrifft. Vielleicht sollte ich die Resultate des Client Penetration Tests doch nocheinmal etwas genauer unter die Lupe nehmen - Wer im Glashaus sitzt, sollte nicht mit Steinen werfen...