Von der Pflicht zur Kür
Sicherheit als Prozess aufsetzen
"Sicherheit ist ein Prozess" - dieser Satz ist inzwischen auf jeder Konferenz zu hören und in vielen Artikeln zu lesen. Trotzdem schaffen es nicht viele Unternehmen, ihn in die Tat umzusetzen. Vergessen wird vor allem, Sicherheitsprozesse an das jeweilige Unternehmen anzupassen.
Ohne eine sicher und stabil laufende IT können Unternehmen heute nicht lange produktiv arbeiten.
Entsprechend hoch ist der Stellenwert dieses Themas in den Firmen. Die Anbieter wiederum springen
allzu gern 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 erwecken, dass man Sicherheit einfach kaufen kann und dass sie als einmal erreichter
Zustand ewig währt. Das Gegenteil ist 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 (Die
Lage der IT-Sicherheit in Deutschland 2005, www.bsi.de, Seite 31). 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 Public Key
Infrastructure (PKI) und Virtual Private Networks (VPNs) 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 Firmeninternet- 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 der lückenlose 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 Gefahrenpotenzial bestimmt. Erst danach ist klar definiert,
welche Schutzmaßnahmen angemessen und folglich umzusetzen sind. Auf den Punkt gebracht: Ohne eine
Risikoanalyse 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 so aussehen: Firma A entwickelt Anwendungen unter der Lizenz der GPL
(General Public License), 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 aber von großem, möglicherweise
existenziellem 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
dann für Firma A und B jeweils eine Risikomatrix erstellt werden (Bilder 1 und 2).
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" (Addison Wesley
2005). Er teilt dabei den Prozess Sicherheit in vier aufeinander folgende, sich ständig
wiederholende Phasen ein: Assessment, Protection, Detection und Response.
Schritt 1: 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 Netzwerkkomponenten wie Server, Router, Switches und so weiter 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
Netzwerk-Ports 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 oder 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:
Webzugriff ü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 und
VPN-Traffic (IPSec oder SSL) zum VPN-Gateway.
Erlaubte Inbound-Protokolle:
Webzugriffe über HTTP und HTTPS zu den Webservern des Unternehmens,
Namensauflösung zu den DNS-Servern des Unternehmens und
E-Mail-Verkehr zu den Mailservern des Unternehmens.
Hiervon 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 aufgrund aller gewonnen Informationen der Assessment-Phase Projekte
budgetiert, Personal ausgewählt und Sicherheitskomponenten wie Firewalls,
Intrusion-Detection-Systeme, Virenscanner, Spam-Filter, Proxies und so weiter evaluiert werden.
Phase 2: Protection
Fälschlicherweise setzen viele Unternehmen die Protection-Phase mit dem Begriff "Sicherheit"
gleich. Sie beschäftigt sich jedoch mit der Anwendung von Gegenmaßnahmen, um die Wahrscheinlichkeit
eines erfolgreichen Angriffs zu minimieren. Nach den Vorgaben des Assessments werden nun
Firewall-Regeln, Virenscanner oder Zugriffskontrollen zum Schutz sensibler Daten und IT-Komponenten
wesentlich dosierter und gezielter implementiert.
Zu viele Unternehmen schließen nach diesem Punkt 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. Allerdings 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.
Phase 3: Detection
Verstöße gegen Sicherheitsrichtlinien aufzudecken und angemessen zu reagieren sind Maßnahmen,
die in Phase 3 definiert werden: Intrusion-Detection-Systeme (IDS) zeichnen an Schlüsselstellen der
IT-Infrastruktur Netzwerk-Traffic 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 Firewall-Systemen
in einen Topf geworfen und ebenso behandelt: Policy definieren, Policy installieren, ausrollen.
In der Regel ist dieses Vorgehen für Firewall-Systeme ausreichend: Da deren 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 IDS:
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 inzwischen mit so
genannten Intrusion-Prevention-Systemen (IPS) automatisiert werden, andere hingegen erfordern das
unbedingte Eingreifen eines Administrators. Beispielsweise kann ein System so verwaltet 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 eines Netzes
durch Zombie-Clients, die bei verteilten DOS-Attacken zum Einsatz kommen, erfordern möglicherweise
das Abschalten ganzer Netzwerksegmente.
Dies sollte nach Möglichkeit nicht automatisch erfolgen. Die Entscheidung darüber, ob eine
Schutzverletzung gleichzeitig eine "Intrusion" darstellt, fällt ein IDS aufgrund von Regelsätzen,
die zuvor vom zuständigen IT-Personal definiert wurden. Falsch oder unzureichend konfigurierte
Regelsätze können dabei zu so genannten "False Positives" führen. Dabei handelt es sich um
versehentlich als schädlich identifizierten, regulären Netzwerk-Traffic. 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 das Fehlen 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.
Stufe 4: 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 umfassen:
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 Softwarestände zu
korrigieren. Für den Fall, dass der verursachte Schaden so groß ist, dass der reguläre IT-Betrieb
nicht mehr aufrechterhalten werden kann, sollten auch rechtliche Schritte vordefiniert werden.
Unter Umständen können sonst Partnerunternehmen, die mit dem Firmennetzwerk verbunden sind, Schaden
nehmen. Auch diese Klientel ist unbedingt über den Vorfall zu informieren. Das Abschalten ganzer
Netzwerksegmente 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.
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.
Lesen Sie mehr zum Thema
