Schwerpunkte

Der Weg ist das Ziel

13. Dezember 2006, 19:37 Uhr   |   | Kommentar(e)

Der Weg ist das Ziel

Sicherheit als Prozess aufsetzen – Die Vielzahl von Security-Angeboten erweckt den trügerischen Eindruck, dass man Sicherheit einfach kaufen kann und dieser Zustand dann 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 den ersten Schritt der Risikoanalyse dar. Das Ergebnis der Beurteilung kann dabei von Unternehmen zu Unternehmen höchst unterschiedlich ausfallen.

In der Praxis kann das so aussehen: Firma A entwickelt Anwendungen unter der Lizenz der General-Public-License (GPL), das heißt der Quellcode muss veröffentlicht werden. 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.

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 eine Risikomatrix erstellt werden.

In vier Schritten zum 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
Neben der Risikoanalyse beschäftigt sich die Assessment-Phase hauptsächlich mit der Vorbereitung auf die folgenden drei Phasen. Sie beginnt mit der Dokumentation der IT-Infrastruktur. Dabei ist eine Inventur aller Netzkomponenten wie Server, Router oder Switches Voraussetzung, um die kommenden Tätigkeiten planen zu können. Das Ergebnis einer solchen Inventur sollte mindestens Hostname, IP-Adresse, Betriebssystem, Release-Stand und Aufgabe einer jeden dokumentierten Komponente ausweisen. Erst wenn all diese Informationen vorliegen, ist ein Unternehmen in der Lage, realistische Schutzmaßnahmen zu planen. Systeme, deren Existenz nicht oder nur mangelhaft beschrieben ist, stellen die größte Gefahrenquelle dar. Der Grund: Bei der Planung des Schutzbedarfs können sie logischerweise nicht ausreichend berücksichtigt werden.

Eine weitere wichtige Aufgabe in der Assessment-Phase ist es, die Sicherheitsrichtlinien zu erarbeiten. Diese sind sowohl für die Anwender als auch für das IT-Personal bindend und sollten mit entsprechendem Rückhalt durch die Unternehmensführung durchgesetzt werden.

Ein Beispiel: Erfahrungsgemäß sehen sich Firewall-Administratoren einem täglichen Gewissenskonflikt ausgesetzt: Auf der einen Seite fordern Anwender und Entwickler ständig, neue Netzwerkports für ihre Anwendungen zu öffnen. Aus Gründen der Unternehmenssicherheit empfiehlt es sich jedoch, nur eine geringe Anzahl von Ports nach außen zu öffnen. Liegt eine verbindliche Richtlinie vor, so hat der Administrator eine Grundlage, auf die er sich jederzeit berufen kann. Gleichzeitig fordert diese von den Entwicklern und Usern, ihre Anwendungen dahingehend zu entwickeln beziehungsweise auszuwählen, dass sie den Sicherheitsrichtlinien des Unternehmens entsprechen. Ein Beispiel für solch eine Richtlinie ist die Vorgabe von Netzwerkprotokollen für In- und Outbound-Traffic:

Erlaubte Outbound-Protokolle:

  • Web-Zugriff über HTTP und HTTPS für beliebige Webserver,
  • FTP-Zugriff für beliebige FTP-Server,
  • Namensauflösung über DNS zu den Nameservern des Unternehmens,
  • E-Mail-Verkehr per SMTP und POP3 zu den Mailservern des Unternehmens,
  • VPN-Traffic (IPsec oder SSL) zum VPN-Gateway.

Erlaubte Inbound-Protokolle:

  • Web-Zugriffe über HTTP und HTTPS zu den Webservern des Unternehmens,
  • Namensauflösung zu den DNS-Server des Unternehmens,
  • E-Mail-Verkehr zu den Mailservern des Unternehmens.

Davon abweichende Protokolle werden von der Firewall blockiert. Jeder Verstoß gegen eine dieser Richtlinien wird später in der Detection-Phase als eine Schutzverletzung erkannt und dementsprechend behandelt. Als Ergebnis können auf Grund aller gewonnen Informationen der Assessment-Phase Projekte budgetiert, Personal ausgewählt und Sicherheitskomponenten wie Firewalls, Intrusion-Detections, Virenscanner, Spamfilter oder Proxies evaluiert werden.

Protection
Fälschlicherweise setzen viele Unternehmen die Protection-Phase mit dem Begriff Sicherheit gleich. Jedoch beschäftigt sie sich mit der Anwendung von Gegenmaßnahmen, um die Wahrscheinlichkeit eines erfolgreichen Angriffs zu verringern. Nach den Vorgaben des Assessments werden nun Firewall-Regeln, Virenscanner oder Access-Controls zum Schutz sensibler Daten und IT-Komponenten wesentlich dosierter und gezielter implementiert.

Zu viele Unternehmen schließen danach ihren Sicherheitsprozess bereits ab. Konfigurationsfehler, Schwachstellen in der Software und oft auch Unwissenheit des Personals führen schnell zu der Erkenntnis, dass die getroffenen Maßnahmen nicht ausreichen. Jedoch bedeutet die Tatsache, dass der Schutz der Protection-Phase versagen kann, nicht gleichzeitig, dass man den betriebenen Aufwand vernachlässigen könnte. Denn der Schutz der IT-Infrastruktur stellt eine unverzichtbare Notwendigkeit dar. Er allein ist jedoch nicht ausreichend, um die Sicherheit eines Unternehmens gewährleisten zu können.

Detection
Verstöße gegen Sicherheitsrichtlinien aufdecken und angemessen reagieren sind Maßnahmen, die in Phase 3 definiert werden: Intrusion-Detection-Systeme (IDS) zeichnen an Schlüsselstellen der IT-Infrastruktur Netzwerkverkehr auf und werten diesen anschließend aus. Im Gegensatz zu den in der Protection-Phase verwendeten Firewalls ist der Aufwand für Konfiguration und Maintenance von IDS sehr hoch – ein Aspekt, der oft vernachlässigt wird. Vielfach werden sie mit Firewallsystemen in einen Topf geworfen und ebenso behandelt: Policy definieren, Policy installieren, ausrollen.

In der Regel ist dieses Vorgehen für Firewallsysteme ausreichend. Da ihre einzige Aufgabe darin besteht, bestimmte Netzwerkdienste zu erlauben beziehungsweise zu blockieren, verrichten sie einmal konfiguriert, zuverlässig und mit geringem administrativem Aufwand ihr Werk.

Anders sieht es bei IDS aus: Jeder Verstoß gegen eine Richtlinie muss vom System zuerst interpretiert und unter Umständen als Intrusion gekennzeichnet werden. Jede Intrusion hat dann, in Abhängigkeit ihres Gefährdungspotenzials, unterschiedliche Aktionen zur Folge. Einige können heutzutage mit so genannten Intrusion-Prevention-Systemen (IPS) automatisiert werden, andere hingegen erfordern das unbedingte Eingreifen eines Administrators. Beispielsweise kann ein System so designed werden, dass es bei einem unerlaubten Zugriff auf einen bestimmten Dienst die IP-Adresse des Absenders automatisch blockiert. Wesentlich gefährlichere Intrusions, wie die Verseuchung durch Zombie-Clients, die bei verteilten DOS-Attacken zum Einsatz kommen, erfordern möglicherweise das Abschalten ganzer Netzsegmente.

Dies sollte nach Möglichkeit nicht automatisch erfolgen. Die Entscheidung darüber, ob eine Schutzverletzung gleichzeitig eine Intrusion darstellt, fällt ein IDS auf Grund von Regelsätzen, die zuvor das zuständige IT-Personal definiert hat. Falsch oder unzureichend konfigurierte Regelsätze können dabei zu sogenannten »False Positives« führen. Dabei handelt es sich um versehentlich als schädlich identifizierten, regulären Netzwerkverkehr.

Automatisierte Aktionen, die von »False Positives« herrühren, können unter Umständen verheerenden Schaden anrichten. Um den Nutzen eines IDS nicht ins Gegenteil zu kehren, sollte bei der Definition des Regelwerks deshalb mit größter Sorgfalt vorgegangen werden. Denn ein IDS kann, falsch angewendet, einen größeren Schaden anrichten als die Abstinenz eines solchen. Insbesondere für die Detection-Phase gilt deshalb: Je mehr Zeit während der Assessment-Phase in die Analyse und die Dokumentation der IT-Infrastruktur investiert wird, desto wahrscheinlicher greifen die Mechanismen der Detection-Phase, lösen sinnvolle Aktionen aus, verringern den Administrationsaufwand und erhöhen die Sicherheit.

Response
Ebenso wie die Schutzvorkehrungen der Protection-Phase versagen können ist es auch möglich, dass ein Angreifer einen Weg durch das in der Detection-Phase gewobene Netz findet. Für diesen Ernstfall stellt die Response-Phase Mechanismen und Maßnahmen bereit. Nutzt ein Angreifer eine Schwachstelle in der Software eines Serverdienstes, könnte eine sinnvolle Gegenmaßnahme zum Beispiel folgende Schritte beinhalten:

Alle Netzwerkanschlüsse des Servers physikalisch deaktivieren, den betroffenen Serverdienst beenden, entsprechenden Serverpatch einspielen, Server herunterfahren, Netzwerkanschlüsse verbinden, Server wieder in Betrieb nehmen, Rückmeldung an Assessment-Personal.

In bestimmten Fällen reicht es jedoch nicht aus, die betroffenen Hard- und Software-Stände zu korrigieren. Für den Fall, dass der verursachte Schaden so groß ist, dass die Aufrechterhaltung des regulären IT-Betriebs nicht mehr möglich ist, sollten auch rechtliche Schritte vordefiniert werden. Unter Umständen können sonst Partner-Unternehmen, die mit dem Firmennetz verbunden sind, Schaden nehmen. Auch diese Klientel ist unbedingt über den Vorfall zu informieren. Das Abschalten ganzer Netzsegmente als letzte Konsequenz kann nicht in der Verantwortung eines Administrators allein liegen. Hierfür müssen klare Eskalationsstufen und Kompetenzen vorgegeben werden.

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.

Fazit
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,
Senior Consultant, Pentos

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen