Hardening Massnahmen vs. Audit Gegenmassnahmen
Marc Ruef | 29.11.2010

Eine klassische Sicherheitsmassnahme der angewandten Computersicherheit ist das Hardening (dt. Härtung). Bei einem solchen wird ein System umfassend abgesichert. Hierzu werden beispielsweise restriktive Konfigurationseinstellungen vorgenommen, nicht benötigte Dienste deaktiviert und Antiviren-Lösungen installiert. Dies ist nur eine sehr begrenzte Anzahl an möglichen Massnahmen. Ein Hardening kann dabei generisch ausfallen (wie die zuvor genannten Punkte). Es kann aber auch individuelle Lösungen und Anforderungen einer Umgebung berücksichtigen (z.B. Erstellen spezifischer Benutzerkonten für Services/Prozesse).

Der reguläre Lebenszyklus eines Systems sieht vor, dass dieses nach dem Aufsetzen bzw. Installieren gehärtet wird. Erst danach bzw. nach einer Prüfung des Erfolgs des Hardenings wird es produktiv eingesetzt. So mancher Kunde will diesen Prozess jedoch überspringen und das System im laufenden Betrieb reifen (http://de.wikipedia.org/wiki/Bananenprinzip) lassen. Dabei besteht natürlich das latente Risiko einer Kompromittierung des Systems.

Wir definieren als Voraussetzung für eine Sicherheitsüberprüfung (http://www.scip.ch/?dienstleistungen.audit) eines laufenden Systems, dass dieses zuvor mindestens einem generischen Base-Hardening unterzogen wurde. Wurde auf ein solches verzichtet, wird die Prüfung voraussichtlich eine schier unenedliche Zahl an Findings generieren lassen. Die Analyse ist damit nicht mehr wirtschaftlich durchführbar, denn umso mehr Schwachstellen vorhanden sind, umso grösser ist der Aufwand einer Validierung und Dokumentierung dieser.

Würde ein solcher Ablauf dieser fehlbaren Natur durchgeführt werden, erhielte der Kunde zwar zum Schluss einen hochgradid personalisierten Hardening-Guide. Im Audit-Report würden schliesslich genau jene Massnahmen empfohlen sein, die eine Absicherung des Systems durchführen lassen würden. Das Hardening könnte also in einem späten Schritt doch noch durchgeführt werden.

Abgesehen davon, dass dieser Ansatz eine paradoxe Unwirtschaftlichkeit während der Prüfungsphase generiert, ist er auch noch zwei anderen Einschränkung unterworfen. Einerseits kann eine Sicherheitsüberprüfung nur jene Schwachstellen zu Tage fördern, die sich im Rahmen des Projekts (Fokus und Aufwand) identifizieren lassen. Stehen für die Analyse x Tage zur Verfügung, werden sämtliche Schwachstellen, für deren Auffinden mehr als diese erforderlich wären, übersehen. In einem wirtschaftlichen Test ist es in den meisten Fällen unmöglich zu beweisen, dass alle möglichen Schwachstellen geprüft und alle existenten Sicherheitslücken gefunden wurden.

Andererseits kann eine Sicherheitsüberprüfung nur jene Schwachstellen ausmachen, die sich durch die genutzte Herangehensweise auch identifizieren lassen. Mit falschen oder fehlbaren Mitteln werden Schwächen übersehen werden. Eine angewandte Bruteforce-Attacke auf einen Login-Prompt ist zum Beispiel nur begrenzt von Nutzen, um die definierte und etablierte Passwort-Policy zu überprüfen. Nur die Durchsicht des Konzepts, die Berechnung der Angreifbarkeit und eine technische Querprüfung mit zielgerichteten Bruteforce-Zugriffen können deterministische Resultate liefern.

Es scheint damit offensichtlich, dass ein wohl durchdachter und eingesetzter Hardening-Prozess unabdingbar ist, um ein solides Mass an Sicherheit erreichen zu können. Sicherheitsüberprüfungen machen einen anderen Teil des Sicherungsprozesses aus. Sie ergänzen sich gegenseitig und können gegenseitige Schwächen kompensieren. Aufgrund der fehlenden Deckungsgleicheit ist es jedoch nicht möglich, den einen Prozess gänzlich durch den anderen ersetzen zu lassen. Dies führt nur weiterführende Risiken ein, die es ja eigentlich zu vermeiden gilt.