Von der Pflicht zur Kür: Sicherheit als Prozess aufsetzen

08.08.2006 von Siegfried Huber
Wer glaubt, Sicherheit mit fertigen Produkten kaufen zu können, irrt - und zwar gewaltig. Nur eine fortlaufende Evaluierung kann ein hohes Sicherheitsniveau erreichen.

Beim allgegenwärtigen Brennpunkt Sicherheit spitzen alle Beteiligten die Ohren, und das sind nicht Wenige. Der Grund dafür liegt auf der Hand: Ohne eine sicher und stabil laufende IT können Unternehmen ihre Tore für lange Zeit schließen.

Entsprechend hoch ist der Stellenwert der IT-Sicherheit anzusiedeln. Als Folge springen die Anbieter auf den Zug auf und bewerben ihre Produkte und Dienstleistungen massiv mit dem Verkaufsargument Sicherheit. Die Folge: Eine Masse und Vielzahl von Angeboten, die den trügerischen Eindruck erweckt, dass man Sicherheit einfach kaufen kann und dieser Zustand ewig währt.

Das Gegenteil ist jedoch der Fall. Eine aktuelle Studie des Bundesamtes für Sicherheit in der Informationstechnik (BSI) zeigt, dass die größte Gefahr von der mangelnden Sensibilisierung des Managements, fehlenden Prozessanalysen und ungenügenden Krisen- und Notfallplänen ausgeht. So sind Unternehmen, die einen durchgängigen Sicherheitsprozess implementiert haben, nach wie vor dünn gesät.

Dabei ist der Weg vom leichten Opfer für Attacken und Angriffe bis zum umfassend und professionell geschützten Unternehmen weder besonders lang noch steinig. So kann mit ein paar Schritten eine Risikoanalyse durchgeführt und anschließend illustriert werden, wie man auf Basis der so gewonnenen Ergebnisse, Sicherheit als Prozess im Unternehmen einführt und dadurch ein nachhaltig hohes Sicherheitsniveau erreicht.

Mit wenig Aufwand viel erreichen

Patentlösungen, wie es sie für andere Bereiche in der IT gibt, existieren für den Bereich IT-Sicherheit nicht. Gängiger Standard, um die demilitarisierte Zone (DMZ) und das Intranet zu sichern, sind Firewalls. Mittlerweile ebenso obligatorisch ist Intrusion-Detection. Auch PKI, also Public Key Infrastructure und VPN, Virtual Private Network, sind häufig Bestandteil einer „sicheren“ IT-Infrastruktur. Diese Liste lässt sich beliebig fortführen.

Geht es um die Sicherheit der IT-Landschaft, so sollte aber nicht nur darauf gesetzt werden, ein möglichst dichtes Bollwerk an Sicherheitsgerätschaften vor dem Firmen-Internet- oder Extranet-Gateway zu platzieren. Denn die bloße Existenz solcher Systeme bietet nicht zwangsläufig einen besseren Schutz. Manchmal stellen sie auch Gefahrenquellen dar, beispielsweise wenn sie die Komplexität unnötig erhöhen und der Überblick dadurch verloren geht.

Oftmals werden Sicherheitslösungen ohne Zusammenhang zwischen dem zu schützenden Objekt und dem tatsächlich bestehenden Risiko installiert. Was fehlt, ist ein lückenloser Prozess, der IT-übergreifend alle Risiken und Eventualitäten berücksichtigt und entsprechende Maßnahmen definiert. Viele Unternehmen unterschätzen dabei immer noch den Wert einer Risikoanalyse und scheuen den administrativen Aufwand, den ein solches Verfahren mit sich bringt.

Dabei ist gerade die Prozessanalyse für die Planung der IT-Sicherheit enorm wichtig. Denn im Rahmen der Risikoanalyse wird für alle relevanten IT-Komponenten eines Unternehmens das jeweils individuelle Risiko bestimmt. Erst danach ist klar definiert, welche Schutzmaßnahmen angemessen und folglich zu realisieren sind. Auf den Punkt gebracht: Ohne eine solche Analyse ist es unmöglich, eine gesicherte Aussage über das Schutzpotential der einzelnen Bereiche der IT-Infrastruktur zu machen.

Jedes Unternehmen tickt anders

Von Risiko spricht man im Zusammenhang mit IT-Infrastrukturen immer dann, wenn die Gefahr besteht, dass eine wertvolle Sache – also eine Komponente der Unternehmens-IT – beschädigt, gestohlen oder vernichtet werden könnte. Bereits diese Beurteilung von Wert und Gefährdung stellt die erste Handlung der Risikoanalyse dar. Das Ergebnis der Beurteilung kann dabei von Unternehmen zu Unternehmen höchst unterschiedlich ausfallen.

In der Praxis kann das beispielsweise so aussehen: Firma A entwickelt Open-Source-Anwendungen, der Quellcode ist also öffentlich bekannt. Firma B entwickelt Anwendungen und vertreibt diese als Closed-Source unter einer eigenen Lizenz. Bei Betrachtung des Werts, den der Quellcode der Anwendungen für beide Unternehmen darstellt, sind bei der Bewertung der Gefährdung unterschiedliche Ergebnisse die Folge:

Firma A sieht ihren offen liegenden Quellcode vermutlich überhaupt nicht gefährdet. Auf einer Skala von eins bis fünf wird Firma A deswegen einen sehr niedrigen Wert ansetzen.

Für Firma B ist der Quellcode von großem, möglicherweise existentiellem Wert. Nur bestimmte Personen dürfen ihn sehen. Da die Gefahr besteht, dass der Quellcode entwendet und veröffentlicht werden könnte, setzt Firma B einen Wert zwischen drei und fünf an.

Risikobewertung

Ein ernstzunehmendes Risiko besteht für ein Unternehmen insbesondere, wenn zusätzlich eine Prozesskomponente eine Schwachstelle aufweist. Das können zum Beispiel Sicherheitslücken im Betriebssystem, eine unverschlüsselte Verbindung oder ein Bug in einer Anwendung sein. Unter Berücksichtigung all dieser Einflussgrößen, ergibt sich für die Berechnung des Risikos folgende Gleichung:

Risiko = Gefährdung x Schwachstelle x Wert

Bezogen auf das vorhergehende Beispiel kann nun für Firma A und B folgende Risikomatrix erstellt werden.

Risikomatrix für Firma A

Faktor

Bewertung

Begründung

Gefährdung

1

Die Gefährdung durch Diebstahl ist irrelevant, da der Code für jeden Interessierten zugänglich ist.

Schwachstelle

1

Der Quellcode ist weltweit über Community-Mirrors verfügbar. Hier eine Schwachstelle zu definieren, macht keinen Sinn.

Wert

2

Der monetäre Wert ist gering. Auch bei „Diebstahl“ entsteht der Firma kein Schaden.

Risiko

2

Bei einem Risikowert von 2 müssen für den Quellcode keine gesonderten Maßnahmen ergriffen werden.

Risikomatrix für Firma B

Faktor

Bewertung

Begründung

Gefährdung

4

Die Gefährdung durch Diebstahl, Veröffentlichung oder Weitergabe des Quellcodes ist gegeben, muss aber nicht zu hoch bewertet werden.

Schwachstelle

5

Der Quellcode an sich verfügt über keine Schwachstelle. Er ist jedoch auf einem CVS-Server abgelegt, auf dem ein ungepatchter Web-Service läuft. Ein Angreifer könnte bei Ausnutzung dieser Schwachstelle root-Rechte erlangen.

Wert

5

Der Schaden, den Firma B durch Diebstahl des Quellcodes erleiden würde, ist als sehr hoch einzustufen.

Risiko

100

Ein Risikowert von 100 ist bei einem Maximum von 125 als hoch zu bewerten. Für den CVS-Server sind spezielle Schutzmaßnahmen zu ergreifen.

In vier Schritten zum umfassenden Sicherheitsprozess

Richard Bejtlich schreibt in „The Tao Of Network Security Monitoring“: „Sicherheit ist der Prozess der regelmäßigen Überprüfung eines bestehenden, akzeptierbaren Risikos.“ Er teilt dabei den Prozess Sicherheit in vier aufeinander folgende, sich ständig wiederholende Phasen ein: Assessment, Protection, Detection und Response.

Assessment

Eine wichtige Tätigkeit der Assement-Phase, die Risikoanalyse, wurde bereits behandelt. Die Assessment-Phase dient der Analyse und Dokumentation der bestehenden IT-Infrastruktur und stellt die Weichen für die drei folgenden Phasen.

Die Erfahrung zeigt, dass es sich bei der Assessment-Phase um die wichtigste der vier Phasen handelt. Fehler, die dort gemacht werden, wirken sich negativ auf alle folgenden Phasen aus. Je mehr Zeit ein Unternehmen hier investiert, umso weniger Schwierigkeiten wird man beim Durchlaufen der anderen Phasen haben.

Konkret bedeutet das, so viele Daten wie nur möglich über die IT-Infrastruktur zu sammeln. Diese Daten bilden dann den Input für die Risikoanalyse. Weitere Aufgaben in dieser Phase sind die Definition von Sicherheitsrichtlinien und die Evaluierung von Produkten, die in den folgenden Phasen zum Einsatz kommen.

Protection

Der Inhalt der Protection-Phase stellt das dar, was viele Unternehmen unter dem Begriff Sicherheit tatsächlich verstehen. In dieser Phase werden Security-Devices wie Firewalls, Virenscanner, IDS und ähnliche installiert und konfiguriert. Also alles, was konkret zum Schutz der IT-Landschaft beiträgt. Nach Abschluss der vorangehenden Assessment-Phase ist man jedoch in der Lage, wesentlich gezielter und dosierter mit dem Schutz sensibler Daten und Systeme umzugehen.

Detection

Da die Wahrscheinlichkeit besteht, dass Schutzmaßnahmen versagen, müssen für diesen Fall Vorkehrungen getroffen werden. Hauptaufgabe der Detection-Phase ist es deshalb, mithilfe von Intrusion-Detection, also Systemen, die Benutzer entdecken, die sich auffällig verhalten, Log-Analyzern oder ähnlichen Einrichtungen Schutzverletzungen zu erkennen und entsprechend zu reagieren.

Response

Was passiert jedoch, wenn alle Vorkehrungen nicht helfen und ein Angreifer sein Ziel erreicht? Auch für diesen Fall muss Vorsorge getroffen werden. Die Response-Phase definiert einen Notfallplan, der beschreibt, welche Systeme im Ernstfall vom Netz zu nehmen sind, wie man infizierte Hosts isoliert und revitalisiert oder welche Personen über den Vorfall informiert werden müssen. Eventuell erfordert die Situation auch das Einleiten rechtlicher Schritte.

Fazit und Ausblick

Es empfiehlt sich, bei jeder Änderung der Infrastruktur den Sicherheitsprozess unter Berücksichtigung aller Phasen neu anzustoßen. Das gleiche gilt, wenn sich die Werte der Risikogleichung ändern. Es können beispielsweise neue Sicherheitslücken in einer Software entdeckt werden. Dadurch verändern sich die Faktoren der Risikogleichung und dementsprechend ist eine neue Bewertung vorzunehmen.

Sicherheit ist ein Prozess, kein Produkt. Das skizzierte Phasenmodell kann dabei helfen, die Schwachstellen im Sicherheitsprozess frühzeitig zu erkennen und zu beheben. Das Ergebnis: ein strukturiertes Vorgehensmodell, das zur Transparenz und zur Steigerung der Sicherheit im Unternehmen beiträgt. Die Risikoanalyse bildet dabei die Grundlage für alle weitergehenden, sicherheitsrelevanten Maßnahmen und kann mit geringem Aufwand und hohem Nutzen durchgeführt werden. (Siegfried Huber/mha)

Der Autor Siegfried Huber ist Senior Consultant bei der Pentos AG.