Wieso Re-Check, wenn es kein Fixing gab?
Marc Ruef | 24.03.2008

Wer sich ein bisschen mit Prozessen auseinandergesetzt hat, der kennt die typische Visualisierung solcher: Verschiedene Prozessstufen, die als gerichtete Pfeile einen Kreis bilden. Sicherheitsüberprüfungen gestalten sich nicht viel anders. Nach der Definition der Analyse wird eben diese durchgeführt. Die determinierten Schwächen werden dokumentiert und behoben. Nachdem dies getan wurde, kann die nächste Prüfung stattfinden.

In den ersten Jahren meiner Tätigkeit als technischer Auditor sprach man vorzugsweise von zyklischen Tests, die immerwieder aufs neue durchgeführt werden sollten. Handelt es sich dabei um die gleiche Betrachtung, kann man sogenannte Delta-Prüfungen durchführen. Bei diesen wird lediglich der Unterschied zum vorangehenden Test ermittelt und dokumentiert. Jenachdem gestaltet sich ein solches Vorgehen besonders effizient, müssen nämlich nicht mehr erneut die gleichen Dinge dokumentiert werden.

Dabei ist es jedoch wichtig zu verstehen, dass eine Sicherheitsüberprüfung als solche nicht mit sich selbst abgeschlossen ist. Das Controlling, bei dem die vorgeschlagenen und umgesetzten Massnahmen auf ihre Richtigkeit und Praxistauglichkeit hin untersucht werden, ist nicht zu vernachlässigen. Re-Checks, also kurze Nachprüfungen nach etablierter Gegenmassnahmen, werden immer mehr von unseren Kunden gewünscht.

Ein solcher Re-Check ist ebenso effizient, denn dabei muss ja nur das geprüft werden, was zuvor beanstandet wurde und mittlerweile behoben sein sollte. Oftmals sind das also nur eine Reihe von wiederholten Tests, die man anzustreben hat. Typischerweise das Verifizieren einer Eingabeüberprüfung zur Adressierung einer Cross Site Scripting-Schwachstelle oder das Untersuchen des von einer Netzwerkanwendung zurückgelieferten Willkommen-Banners.

Zu meinem Erstaunen passiert es immerwieder, dass bei diesen Re-Checks die gleichen Fehler nocheinmal gefunden werden. Und dies, obschon sie laut Kunde eigentlich nach der Abgabe und Besprechung des Reports des ersten Tests behoben worden hätten sein sollen. Eine Wiederholungsrate von 80 % ist da nichts Ungewöhnliches. Leider.

Ich frage mich oft, wieso ein Re-Check angeordnet wird, obschon die empfohlenen Gegenmassnahmen gar nicht zum Tragen gekommen sind. Hat man schliesslich auf diese verzichtet, muss man sie auch nicht prüfen. Ich geh ja schliesslich auch nicht an eine Fahrprüfung, ohne jemals ein Gaspedal selbstständig gedrückt zu haben.

Vielleicht hoffen die Entwickler und Administratoren, dass sich das Problem von alleine gelöst hat. Viele Bastler haben nämlich eine besondere Beziehung zum Computer entwickelt. Ein bisschen Voodoo, könnte man vermuten. Funktioniert etwas, dann ist es Zauberei. Und funktioniert halt mal etwas nicht, dann hat man die Götter erntzürnt. Diese mit der Verlängerung eines Wartungsvertrags gütig zu stimmen, scheint sodann die letzte Hoffnung zu bleiben.

Tatsächlich kann es vorkommen, dass gewisse Schwachstellen aus wirtschaftlichen oder technischen Gründen nicht gelöst werden können oder wollen. Zum Beispiel deswegen, weil es zu Inkompatibelitäten kommen kann, will man das Verhalten des TCP/IP-Stacks des Betriebssystems zur Bekämpfung von OS-Fingerprinting verändern. Oder weil man potentielle Käufer verlieren könnte, will man auf dem HTTPS-Webserver ausschliesslich die stärksten kryptographischen Methoden unterstützen.

Computersicherheit ist halt schlussendlich für viele nur ein leidiges Thema, das halt irgendwie zwangsweise mit den neuen Medien verbunden ist. In einer Zeit, in der von Web 2.0 geredet und von der New Economy 2.0 geträumt wird, spielen zeitaufwendige Schutzmassnahmen halt nur eine untergeordnete Rolle. Wie man von Geschäftsleitungen oft zu hören kriegt: "Security sollte ein 'Enabler' sein...!"