Sicherheit ist relativ
Marc Ruef | 26.10.2006

Relativität ist eine ganz besondere Sache. Schon die Philosophen des alten Griechenlands wussten mehrere tausend Jahre vor Albert Einstein, dass das Erscheinen der Dinge oftmals oder gar ausschliesslich vom Betrachtungswinkel abhängt. Friedrich Nietzsche sah das ähnlich, schrieb, dass das, was für jemanden Gift ist, für den anderen Macht darstelle. Und auch Charles Manson postulierte in seinem verworrenen und über zwei Stunden andauernden Schlussplädoyer, dass er aus seiner Sicht nichts falsches getan hätte. Obschon in einigen Fällen die Grundsätze der Physik durch die spezielle Relativitätstheorie erschüttert wurden und in anderen Fällen die Ethik und Moral der Gesellschaft wegen kognitiver Dissonanz in Frage gestellt wird, zielt alles auf das Gleiche ab: Da wo ich stehe, sieht das Gesehene für mich immer richtig aus.

Auch und ganz besonders die Computersicherheit ist von einer solchen Relativität geprägt. Viele Kunden, vorwiegend aus den Bereich der Industrie und kleiner Versicherungen, pflegen uns bei einer Kickoff-Sitzung den folgenden Spruch entgegenzuwerfen: "Ich glaube nicht, dass Sie etwas finden werden. Wir sind eigentlich sicher." Derlei Postulate absoluter Natur erinnern stets an die Aussage eines anderen Griechen, die da hiess: Je mehr das ich weiss, desto mehr weiss ich, was ich nicht weiss.

Denn eben gerade oft sind es jene Kunden, die in ihren Reports haufenweise typische und schon nur deswegen am ehesten vermeidbare Schwächen vorgelegt bekommen. Fehlends Hardening, ein schleppendes Patching, schlecht konfigurierte Software und Firewall-Elemente machen den Grossteil der Findings aus. Der Spruch vom Beginn des Projekts ist dann schnell wieder vergessen, will man nun in dieser Phase des hitzigen Gefechts nur noch schauen, dass nun doch alles so sicher wird, wie man es sich gewünscht hat. Dies sei ja alles verziehen, wusste man es halt nicht besser. Bei den Nachfolge-Projekten werden diese Kunden dann gerne vorsichtiger und meinen eher: "Kann durchaus sein, dass Sie etwas finden..."

Doch dies ist alles gar nicht tragisch, liegt es doch in der Natur des Menschen und der durch Leistungsdruck geprägten Epoche des wirtschaftlich möglichst performanten Informationszeitalters. Uns Auditoren tut sich aber ein ganz anderes Problem auf. Gerade weil Sicherheit und die Tragweite von Schwachstellen besonders relativ ist, gestaltet sich eine Einstufung oftmals sehr schwierig.

Dem Problem einfach Herr zu werden kann man auf folgender Ebene. Eine Pufferüberlauf-Schwachstelle, bei der ich auf einem exponierten Webserver-System beliebigen Programmcode ausführen kann, wird wohl bei jedem Kunden als High eingestuft werden. Egal ob Bank oder Hochschulzentrum. Was ist aber nun, wenn wir es mit "internen" Systemen zu tun haben, mit denen vorwiegend "vertrauenswürdige" Mitarbeiter interagieren. Was nun, wenn auf diesem die komplette Konfiguration ausgelesen werden kann, sich aber direkt keine Manipulation von Daten umsetzen lässt. Ist das nun ein High oder lediglich ein Medium? Oder fällt die Risikoklassifizierung bei einer Versicherung nun anders aus weder bei einer militärischen Organisation?

Da ich nun seit über 4 Jahren tagtäglich die Verwundbarkeitsdatenbank der scip AG (http://www.scip.ch) moderiere und zuvor auch schon ähnliche Projekte (z.B. Buglist) begleitet habe, zudem schon einige Duzend Security Audits leiten durfte, habe ich mehr oder weniger ein Gefühl dafür, was nun wie kritisch ist. Doch dieses Gefühl ist nicht genug. Viele Kunden wollen eine transparente Metrik, die sich auf nachvollziehbaren Algorithmen abstützt. Vor allem auf der Management-Ebene wird gut und gerne nach Kennzahlen geschrien.

Die grundlegenden arithmetischen Operatoren reichen eigentlich aus, um dieses Ziel zu erreichen. Ob diese Skala nun von 1 bis 4, 1 bis 10 oder 1 bis 1000 reicht, ist eigentlich egal. Berechnet werden kann immer. Das schwierige bleibt aber, diese Berechnung möglichst akkurat und vor allem realitätsbezogen zu inszenieren. Die Grunddaten müssen sehr umfassend sein, um Abweichungen in spezifischen Umgebung erfassen und in das Endresultat auch richtig einfliessen lassen zu können. Das Erstellen eines solchen Modells ist keine leichte Aufgabe!

Schon zig Algorithmen, Metriken und Modelle habe ich erarbeitet und verfeinert. Mittlerweile, so meine ich, haben wir ein gutes Konstrukt zusammengetragen, das sowohl sehr akkurate Resultate liefert als auch nur minim von den verschiedenen Expertenmeinungen abweichen (Wir haben Umfragen bei verschiedenen Experten gemacht und damit die Abweichungen unseres Modells determinieren können). Oschon unsere dadurch erstellte Datenbank gut und gerne zum Tragen kommt, gibt es immerwieder Ausnahmesituationen, bei denen sie versagt.

Beliebte Probleme sind Abhängigkeiten und Rekursivitäten. Dies ist am besten an unserem Modell der Firewall-Regelwerk-Analysen zu beobachten. Kommen in der Netzwerk-Topologie verschiedene Zonen zum Einsatz und sind teilweise Zirkelbeziehungen zwischen diesen gegeben, kann es zu typischen Logikfehlern kommen. Eine Schwäche wird sodann von einer anderen abhängig, die wiederum von einer anderen abhängig ist, usw. Ein sehr langer Rattenschwanz, der aus theoretischer Sicht druchaus gerechtfertigt ist. Doch wie bewertet man nun diese Abhängigkeiten - Vor allem, wenn sie rekursiv sind? Erinnerungen an das Halteproblem werden wach.

Da bleibt meistens nichts anderes übrig, weder dem eigenen System harte Grenzen aufzuzwingen. Rekursionen sind verboten bzw. werden nach einer gewissen Wiederholung ignoriert. Abhängigkeiten sind nur bedingt Einfluss auf das Resultat ausübend, da die Komplexität der Berechnung sonst ins Unermessliche steigen würde. Manuelles Feintuning ist halt manchmal doch erforderlich, um jene Resultate liefern zu können, die auch vom Grossteil der Experten als korrekt identifiziert werden. Schade, aber das perfekte Berechnungsmodell gibt es nicht. Weder in der Meteorologie noch in der Computersicherheit.