Was ein Security Consultant nicht kann
Marc Ruef | 12.04.2010

Security Consulting im IT-Bereich ist ein weitläufiges Gebiet. Es umfasst technische, konzeptionelle und organisatorische Aspekte. Und diese können wiederum in Netzwerke, Betriebssysteme, Applikationen, etc. aufgeteilt werden. Irgendwie muss ein Security Consultant alles wissen oder wenigstens wissen, worum es bei einem Thema im weitesten geht. Keine leichte Aufgabe.

Ohne Licht gäbe es aber auch keinen Schatten und so gibt es immerwieder Dinge, die ein Consultant einfach nicht wissen kann. Ein Consultant berät einen Kunden und gibt im Hinweise, wie man ein Problem lösen könnte bzw. wie es andere vor ihm gelöst haben. Dies setzt jedoch voraus, dass sich der Consultant des Problems bewusst ist. Dies ist manchmal gar nicht möglich, wenn noch nicht einmal der Kunde sein Problem erkannt und erfasst hat.

Ich hatte vor einiger Zeit ein Mandat, bei dem ich ein internationales Versicherungsunternehmen in Bezug auf Outsourcing verschiedener Kommunikationsbereiche beraten durfte. Das Projekt war als "Papierarbeit" deklariert: Ich musste eine Vielzahl an Dokumente durchlesen (Verträge, Policies, Betriebshandbücher, Sitzungsprotokolle, etc.) und darauf aufbauend mit den involvierten Parteien Interviews führen. "Flaws and Blackspots" sollten damit gefunden, kalkulierbar oder gar eliminiert werden können.

Das Problem dabei war, dass ich keine technischen Verifikationen anstreben konnte (dies war im Budget des Projekts nicht vorgesehen). Ich musste darauf vertrauen, dass die technischen Dokumentationen stimmen und dass mir die Leute in den Interviews die Wahrheit sagen. Im schlimmsten Fall sollte die Informationsgrundlage für meine Empfehlungen auf falschen Aussagen beruhen, doch dieses Risikos war ich mir von Anfang an bewusst. Und so habe ich dies natürlich auch kommuniziert.

Nun war es so, dass der Kunde von mir plötzlich konkrete Lösungsvorschläge (inkl. bevorzugtem Produkt und den anzuwendenden Konfigurationseinstellungen) postuliert haben wollte. Doch ich kannte die Umgebung ja nur vom Hörensagen. Wie soll ich da eine konkrete Aussage machen, die zusätzlich firmenpolitische und -wirtschaftliche Entwicklungen berücksichtigen können sollte? Ich konnte es einfach nicht.

Als Empfehlung vor dem Mitlesen von Daten, die über das Netzwerk geschickt werden sollten, habe ich pauschal den Einsatz einer Verschlüsselung empfohlen. Klassische Ansätze wie IPsec, SSL oder SSH lassen sich oftmals ohne grössere Einschnitte auf bestehende Infrastrukturen applizieren. Doch der Kunde wollte konkret wissen, welche Daten verschlüsselt werden sollen, von wo nach wo diese geschickt werden und mit welcher Verschlüsselung sie geschützt werden müssen.

Dies war ein Detailgrad an Informationen, den ich mit den mir vorliegenden Grunddaten einfach nicht gewährleisten konnte. Hier sind zwei Parteien gefragt, um diese Fragen korrekt beantworten zu können: Derjenige, der die Daten geschützt haben will (Datenowner) und derjenige, der die Daten schützen soll (Administrator/Engineer). Ich bin sodann nur in einer beratenden Stabsstelle tätig, indem ich a) darauf hinweise, dass man verschlüsseln sollte, b) mögliche Lösungsansätze skizziere und c) auf Vor- und Nachteile sowohl meiner Empfehlungen als auch der angestrebten Lösung hinweise.

Ein beratender Consultant nimmt einem Kunden keine Entscheidungen ab. Das kann er nicht, da hierfür schlichtweg keine Kompetenz (und damit einhergehend auch keine Verantwortung) hat. Manche Kunden sehen dies nicht ein und werden ungehalten. Doch man macht sich als Consultant nur selber das Leben schwer, wenn man seine Rolle verlässt und plötzlich versucht auf zwei Hochzeiten (die sich widersprechen) zu tanzen. Das kann auf längere Zeit einfach nicht gut gehen. Man muss also eindeutig wissen, was man halt eben nicht weiss.