Metriken der IT-Sicherheit

von Michael Loger

Jeden Tag lesen wir in den Nachrichten über neue  große Datenlecks und Datenpannen. Seien es Angriffe der Internet-Aktivisten, versehentlich an falscher Stelle kopierte Dateien, schwache Konfigurationen oder schlichtweg die unsachgemäße Entsorgung von Datenträgern.  Bei genauerer Betrachtung der Datenpannen lässt sich erkennen: die meisten wären leicht vermeidbar gewesen, „hätte man nur“ die richtigen Vorkehrungen getroffen. Doch um Schwachstellen rechtzeitig zu erkennen, bedarf es vernünftiger Messmethoden. Die Ergebnisse der daraus resultierenden Messwerte sollen ermöglichen festzustellen, wo man gerade steht, auf was man seine Aufmerksamkeit richten sollte und ob Maßnahmen umgesetzt worden sind.

 

Das Dilemma der Vergleichbarkeit

 

Der IT-Sicherheitsverantwortliche steht aber in einem Dilemma: Wie ist seine IT-Sicherheit messbar und damit letztendlich auch bewertbar? Für den Betrieb der IT-Infrastruktur gibt es bereits viele validierbare Kennzahlen, wie etwa MTBF (Mean Time Between Failures), die  HRG-Klassen für Verfügbarkeit der IT-Systeme (AEC 0-5:Availability Environment Classification) oder die Energieeffizienz von Rechenzentren mittels PUE (Power Usage Effectiveness).

 

Da es solche Kennzahlen nicht für die IT-Sicherheit gibt, versuchen viele die IT-Security quasi als „Business Enabler“ mit einem ROI (Return of Investment) zu versehen, und messen Prozessen der IT-Security Umsatzzahlen bei, die eher auf einem Bauchgefühl, denn auf verifizierbaren Zahlen basieren. Diese, dem betriebswirtschaftlichen Controlling entnommene Verfahrensweise, macht  nur vordergründig Sinn. Denn entgegen anderer Prozesse, für die z. B. Ausfallzeiten der IT-Systeme in Euro und Cent taxiert werden können, ist dies im Falle der IT-Sicherheit nicht möglich.

 

IT-Sicherheit lebt von Wahrscheinlichkeiten,  die aufgrund der oft fehlenden Werte schwer berechenbar sind. Sicher kann man eine Kundendatenbank  oder auch Betriebsgeheimnisse mit Eurowerten versehen – die tatsächlichen  Schäden, die durch deren Verlust entstehen, sind aber schwer zu ermitteln.

 

Bei Kreditkartendaten etwa wird einerseits der Schadensersatz an die Kreditkartenausstellende Stelle fällig, wenn man zum Zeitpunkt des Angriffs nicht PCI DSS (Paymentcard Industrie Data Security Standard) compliant war. Dies lässt sich noch recht einfach berechnen, das Verhalten der Kunden aber ist eine unbekannte Größe. Der erfolgreiche Angriff gegen Sony zum Beispiel hat das Unternehmen Millionen und den verantwortlichen IT-Security-Manager den Job gekostet.

 

Ein weiteres Beispiel dafür, wohin mangelhafte IT-Security führen kann, ist das  niederländische  Unternehmen DigiNotar: Die Firma musste nach dem Diebstahl von 500 Zertifikaten Insolvenz anmelden.

 

Eine fundierte ROI-Berechnung von IT-Security-Vorfällen ist also kaum zu bewerkstelligen, zumal es auch solche Beispiele gibt, bei denen ein Datenverlust kaum zu nennenswerten Änderungen der Umsätze geführt hat.

 

Auch der Versuch, metrische Analysen auf reine Zahlenwerte zu reduzieren, etwa die Anzahl von Malwarefunden, Spam-Mails oder offener Ports an der Firewall, ist wenig zielführend und liefert kaum Aussagekraft bezüglich des aktuellen  Security-Status. Denn hier fehlt es an vernünftigen Sollwerten.

 

Messen der Compliance

 

Ein erfolgversprechender Ansatz ist die Einhaltung von IT-Security-Prozessen sowie des Compliance-Status der Systeme und deren Messung. Denn hier kann auf recht einfache Weise der Istwert mit vernünftig definierbaren Sollwerten verglichen werden.

 

Audits und auch die Schwachstellenanalyse mit herkömmlichen Vulnerability Scans können einen Überblick verschaffen und durch regelmäßige Wiederholung auch Tendenzen aufzeigen. Beide Verfahren haben jedoch die gleiche Eigenschaft: Sie bieten nur einen sehr kurzen Einblick in die IT-Landschaft. Zudem beginnt jedes Audit oder jeder Scan mit der gleichen Ungewissheit, da Änderungen der Systeme nicht validiert wurden. Bei Audits spielt darüber hinaus noch der Faktor Mensch eine wesentliche Rolle: Er macht es schwer, Audits miteinander zu vergleichen, vor allem dann, wenn sich der Auditor ändert.

 

Zwischen den Audits ist man oft „im Blindflug“ unterwegs und erkennt Verstöße gegen die Compliance nicht. Was zwischen den Audits passieren kann, demonstriert etwa Malware wie das neue DuQu (eine neue Variante der StuxNet Malware; DuQu treibt wohl bereits seit Ende 2010 und von AV-Herstellern unerkannt sein Unwesen), das sich nach 36 Tagen selbst löscht und in der Lage ist, kritische Änderungen innerhalb der Systemumgebungen durchzuführen.

 

Was können wir messen

 

Eines der effektivsten Messverfahren  ist es, IT-Systeme gegen Standards wie ISO 27001, CSI oder PCI DSS, aber auch auf Basis der Härtungsempfehlungen der Hersteller (etwa VMware oder Microsofts Hardening-Guidelines) und eigenen, für das Unternehmen definierten Systemkonfigurationen zu verifizieren.

 

Für jedes IT-System sollte es eine Risikoeinstufung  und die dazu passende Compliance-Richtlinie geben. Beides zusammen ermöglicht eine individuell für das System messbare Risikobewertung. Ein System, das Änderungen auf allen wichtigen Systemen erfasst und gegen das entsprechende Regelwerk vergleicht  bietet die Möglichkeit, zu jedem beliebigen Zeitpunkt den Level der Einhaltung der Compliance zu messen und auch zu bewerten. Hier kommen die notwendigen IT-Kontrollen aus der SANS-Liste (Nummer 3&4) zum Tragen.

 

 

Was bleibt als Fazit:

 

Nur wer in der Lage ist, messbare Größen für die IT-Sicherheit auf seine IT-Landschaft abzubilden wird auch in der Lage sein, seine IT-Sicherheit zu steuern.

Man kann seinen Kurs nur dann bestimmen, wenn man weiß, wo man steht und in der Lage ist, Ziele zu definieren.

 

“Der Kluge ist der, welchen die scheinbare Stabilität nicht täuscht und der noch dazu die Richtung, welche der Wechsel zunächst nehmen wird, vorhersieht.”
Arthur Schopenhauer, Aphorismen zur Lebensweisheit

 

 

Michael Loger

Senior Systems Engineer – Tripwire

http://twitter.com/#!/MichaelLoger