Gesetzliche Rahmenbedingungen auf der einen, wachsende Bedrohungen auf der anderen Seite zwingen Unternehmen heute, ein angemessenes Sicherheits- und Risikomanagement einzurichten.

Ein guter Ansatz für ein umfassendes Sicherheitsmanagement im Unternehmen geht von einer hierarchischen Struktur aus.

Wir sind sicher – alle Übergänge zu fremden oder öffentlichen Netzen sind durch Firewalls geschützt und unser mehrstufiges Anti-Virenkonzept auf Gateways, Mail-Servern, Servern und Clients schützt uns vor Viren und Würmern.« Noch vor gar nicht langer Zeit konnte man ähnliche Aussagen von vielen Unternehmen hören. Und wenn man mehr für die Sicherheit tun wollte, dann gingen die Gedanken häufig in Richtung Intrusion-Detection. Es ist eben doch einfacher, ein Bollwerk gegen »die bösen Hacker da draußen« aufzurichten, als sich an die eigene Nase zu fassen und eigene Schwächen und Fehler anzugehen. Natürlich kann ein netzwerkbasiertes Intrusion-Detection-System einen SQL-Slammer erkennen. Aber: Als Anfang 2003 die SQL-Server abstürzten, hätten da die Intrusion-Detection-Systeme wirklich geholfen? Ist es wirklich die Lösung, erst dann die Polizei zu rufen, wenn der Einbrecher schon im Haus ist? Oder kann beziehungsweise sollte man nicht vorher schon etwas unternehmen, zum Beispiel das defekte Türschloss austauschen?

Patch-Management – der erste Schritt

SQL-Slammer nutzte eine Schwachstelle aus, für die ein entsprechendes Gegenmittel schon sieben Monate lang verfügbar war. Trotzdem galt vielerorts noch der Grundsatz »Never touch a running system«. Die Folgen sind allgemein bekannt. Spätere Würmer wie Blaster oder Sasser ließen deutlich weniger Zeit zur proaktiven Abwehr. Trotzdem waren viele Unternehmen besser vorbereitet. Mit dem SQL-Slammer hat ein Umdenken in vielen Unternehmen eingesetzt.

Der Aufbau eines strukturierten und klar definierten Patch-Management-Systems steht heute vielerorts auf der Prioritätenliste ganz oben. Die wichtigsten Schritte in einem solchen System sind:

• Genaue Kenntnis über die im Unternehmen eingesetzten Betriebssysteme und Anwendungen, inklusive deren Versions- und Patchstände einholen.

• Zeitnahe Information über neu entdeckte Schwachstellen und Hersteller-Patches in Erfahrung bringen. Dabei helfen Tools wie Symantecs »DeepSight«-Frühwarnsysteme.

• Eine zentrale Bewertung der Schwachstelle erstellen. Betrifft sie überhaupt die eingesetzten Systeme? Was wären die Auswirkungen bei einem Schadensfall? Welche Auswirkungen hat die empfohlene Änderung auf die eigenen Systeme? Nur auf Basis einer sorgfältigen Analyse kann eine verbindliche Festlegung getroffen werden, ob und innerhalb welcher Frist die empfohlene Änderung durchzuführen ist.

• Teil dieses Prozesses muss natürlich ein hausinterner Test sein, um sicher zu stellen, dass keine unerwünschten Nebeneffekte auftreten.

• Die betroffenen Administratoren sind über die zu treffenden Maßnahmen sowie die Fristen zur Umsetzung zu informieren. Falls ein außerplanmäßiges Wartungsfenster erforderlich ist, müssen natürlich auch die Nutzer der betroffenen Systeme über den Grund, Art und Umfang der Arbeiten informiert werden.

• Die Maßnahmen werden von den Administratoren umgesetzt. Hierzu sind gegebenenfalls Werkzeuge, zum Beispiel zur automatischen Software-Verteilung, nötig.

• Oft vernachlässigt oder gar schlichtweg vergessen wird schließlich der letzte Schritt: Die Umsetzung der Maßnahme muss natürlich auch konsequent überwacht werden, zum Beispiel indem die Administratoren die Umsetzung quittieren müssen oder durch eine technische Überwachung mit Werkzeugen wie Symantecs Enterprise-Security-Manager.

Natürlich zeigt das Beispiel oben nur die Grundstruktur des Prozesses. So kann sich durchaus während der »Lebenszeit« einer Schwachstelle die Priorität ändern. Oder es muss ein Eskalationsverfahren definiert werden, wenn Administratoren die gesetzten Fristen nicht einhalten. Entsprechend ist der obige Prozess durch Schleifen zu ergänzen.

Die Vorteile eines solchen Systems liegen klar auf der Hand:

• Ein einheitlicher Umgang mit Schwachstellen ist gewährleistet. Es nützt nichts, wenn ein Patch nur auf 50 Prozent der Systeme eingespielt wird.

• Für die Administratoren wird Handlungssicherheit geschaffen.

• Und falls doch etwas schief geht: Versagt hat nicht mehr ein Einzelner, sondern ein von allen akzeptierter und abgesegneter Prozess. Es erleichtert die Aufarbeitung, wenn nicht mehr die Suche nach dem Schuldigen oberstes Ziel ist.

Auf der anderen Seite zeigt das Beispiel oben klar, dass Sicherheitsmanagement viel mehr umfasst als auf den ersten Blick erkennbar ist:

• Der Prozess muss über Standortgrenzen hinweg, gegebenenfalls sogar für unterschiedliche IT-Betreiber gültig sein. Er betrifft nicht nur die IT, auch die Nutzer müssen angemessen eingebunden werden. Kulturelle Unterschiede sind zu berücksichtigen. Es bedarf einer zentralen Weisungsbefugnis. Damit all dies funktioniert, muss der gesamte Prozess von der oberen Managementebene her autorisiert sein.

• Genaue Kenntnis der eingesetzten Betriebssysteme und Anwendungen bis hin zu Versions- und Patchständen sind unbedingt notwendig. Die verantwortlichen System-Administratoren müssen bekannt sein, ebenso die Nutzer der Systeme im Unternehmen. Kurz gesagt: Es muss ein genaues und aktuelles Inventar vorliegen. »Wilde« Server, von denen niemand etwas weiß oder für die niemand zuständig ist, untergraben jedes Sicherheitsmanagement.

• Will man Risiken präzise abschätzen, ist eine enge Zusammenarbeit mit dem Geschäftsbetrieb unbedingt notwendig.

• Die Umsetzung muss überwacht werden. Disziplinarische Maßnahmen können erforderlich werden, zum Beispiel wenn ein System-Administrator wiederholt Fristen versäumt. Hier kommen Betriebsrat und Personalabteilung ins Spiel.

• Budget und Personalressourcen müssen ausreichend vorhanden sein.

Sicherheit – kein rein technisches Problem

Das Beispiel Patch-Management zeigt, dass Informationssicherheit nicht auf den rein technischen Bereich beschränkt ist, obwohl der Ansatz hier klar aus der Technik kommt. Andere Beispiele zeigen noch deutlicher, dass Informationssicherheit ohne einen umfassenden Ansatz nicht zu haben ist.

Was nützt es, vertrauliche Dateien zu verschlüsseln, wenn sie dann ausgedruckt offen herumliegen oder gar übers normale Altpapier entsorgt werden? Hier ist jeder einzelne gefragt. Regeln alleine können schlechte Passwörter nicht verhindern, sondern bestenfalls erschweren. Auch wenn ich im Namen meiner Katze alle a durch @ ersetze und zudem die ersten Buchstaben jeder Silbe groß schreibe, dann ist das immer noch kein gutes Passwort. Erstrecht nicht, wenn es auf dem berüchtigten Post-it unter meiner Tastatur steht. Auch hier hängt Sicherheit ganz wesentlich von jedem einzelnen ab. Was nutzt Hochverfügbarkeit bei einem Rechner, wenn für die Klimaanlage im Rechnerraum nicht mindestens die gleichen Anforderungen gelten wie für den Rechner selbst? Verpflichtungen zur Verschwiegenheit in Arbeitsverträgen sind Sache der Personalabteilung, die Rechtsabteilung ist zuständig für entsprechende Klauseln in Dienstleisterverträgen. Man muss also Informationssicherheit fest in der Unternehmenskultur verankern, will man wirklich etwas erreichen.

Umfassendes Sicherheitsmanagement

Ein guter Ansatz für ein umfassendes Sicherheitsmanagement geht von einer hierarchischen Struktur aus. An oberster Stelle steht die Sicherheitsrichtlinie eines Unternehmens. Sie sollte von der Leitungsebene herausgegeben und unterzeichnet sein. Sie muss innerhalb des Unternehmens angemessen veröffentlicht und jedem bekannt sein. Sie sollte kurz gefasst und klar verständlich formuliert sein und der Umfang sollte sich auf wenige Seiten beschränken. Gemäß der ISO/IEC 17799 Norm muss eine Sicherheitsrichtlinie folgendes enthalten:

• Eine Definition des Begriffs Informationssicherheit, die grundlegenden Ziele, den Gültigkeitsbereich und die Bedeutung der Informationssicherheit als Grundlage für den Austausch von Informationen,

• ein klares Bekenntnis der Unternehmensleitung zur Informationssicherheit, das die grundlegenden Ziele und Prinzipien rückhaltlos unterstützt,

• eine grobe Beschreibung der Bereiche, die für das Unternehmen besonders wichtig sind, zum Beispiel Übereinstimmung mit gesetzlichen Vorgaben und vertraglichen Regelungen, Ausbildung und Schulung, Virenschutz und Schutz vor sonstiger Schadsoftware, Maßnahmen zur Weiterführung des Unternehmens im Schadensfalle, disziplinarische Maßnahmen bei Verstößen gegen die Sicherheits-Policy oder daraus abgeleiteten Vorschriften,

• Definitionen von Verantwortlichkeiten, einschließlich eines Berichtswesens im Falle von Sicherheitsverstößen,

• Bezugnahme auf weitergehende Dokumente, die in detaillierter Form weitergehende Sicherheitsregeln beschreiben.

Die Sicherheitspolicy bildet quasi das »Grundgesetz der Informationssicherheit« in einem Unternehmen.

Die nächste Ebene leitet sich aus dieser Sicherheitsrichtlinie ab. Hier werden allgemeingültige Sicherheitsstandards definiert. Der Gültigkeitsbereich ist wiederum das gesamte Unternehmen, allerdings betreffen nicht mehr alle Dokumente jeden Mitarbeiter. Ohne auf Einzelheiten der technischen Realisierung im Detail einzugehen, werden Vorgaben zur Sicherheits-Klassifizierung von Informationen gemacht, Regelungen für bestimmte Sicherheitsklassen festgeschrieben sowie sonstige allgemeinen Sicherheitsmaßnahmen definiert. Beispiele sind IT-Notfallpläne, Virenschutz, Netzwerksicherheit, Nutzung von E-Mail und Internet am Arbeitsplatz, Kennwortregeln, Anforderungen für die Zugangskontrolle und vieles mehr. In der Regel liegt diese Ebene in der Verantwortung des Sicherheitsbeauftragten des Unternehmens, der im Auftrag der Unternehmensleitung handelt.

Die praktische Umsetzung dieser Standards erfordert detaillierte technische Vorgaben. Diese Vorgaben liefert die dritte Ebene. Beispiele sind die Konfiguration von Betriebssystemen und Anwendungen, Betriebshandbücher, Datensicherungs- und Wiederherstellungspläne oder Netzwerkpläne. Diese Ebene bildet die Schnittstelle zwischen dem Sicherheitsbeauftragten und dem IT-Betrieb.

Die letzte Ebene bilden die Aufzeichnungen. Hier wird letztlich der Nachweis der Wirksamkeit der geforderten Maßnahmen erbracht. Beispiele sind Systemlogs, Besucherbücher, Anwendungsprotokolle, Berichte von Sicherheitsprüfungen oder Netzwerkscans. Die regelmäßige Überprüfung ist Aufgabe der Revision.

Die tatsächliche Zahl der Ebenen mag dabei abhängig von der Größe und Komplexität eines Unternehmens variieren. So kann in einem kleinen Unternehmen die Trennung zwischen den beiden obersten Ebenen aufgehoben werden, während für große Unternehmen die weitere Aufspaltung der zweiten oder dritten Ebene sinnvoll sein mag.

Risikoanalyse

Damit die getroffenen Regelungen den Sicherheitsbedürfnissen eines Unternehmens angemessen sind, muss zunächst eine Risikoanalyse durchgeführt werden. Man kann sich nicht angemessen schützen, wenn man nicht genau weiß, wogegen. Drei Faktoren bestimmen im Wesentlichen das Risiko:

• Die Existenz einer Bedrohung. Bedrohungen sind zum Beispiel vorsätzliche oder fahrlässige menschliche Fehlhandlungen, technische Defekte oder Katastrophen aller Art.

• Die Existenz einer Schwachstelle. Schwachstellen ermöglichen es einer Bedrohung, Schaden anzurichten. Schwachstellen sind zum Beispiel eine offen stehende Brandschutztür, ein Buffer-Overflow-Fehler in einer Anwendungssoftware, mangelnde Ausbildung der betreuenden System-Administratoren oder ähnliches.

• Die potenzielle Schadenshöhe. Diese kann direkter finanzieller Schaden sein – beispielsweise bei Ausfall eines Web-Shops, E-Betrug oder drohende Konventionalstrafen – oder eher abstrakte Werte wie die Reputation eines Unternehmens oder gar die Gefährdung von Menschenleben beinhaltet – beispielsweise bei Ausfall eines Verkehrsleitrechners oder der IT in der Intensivstation im Krankenhaus – sein.

Dabei sind Bedrohungslage und potenzielle Schadenshöhe mehr oder weniger vorgegeben. Die Schwachstellen sind also der primäre Ansatzpunkt. Die Beseitigung oder Reduzierung einer Schwachstelle aber kostet Geld und Personal. Dieser Aufwand muss in angemessener Relation zum Risiko stehen. Aufgabe der Risikoanalyse muss also sein:

• Sich über die bestehenden Risiken klar zu werden,

• festzulegen, welcher Aufwand zur Minimierung eines gegebenen Risikos akzeptabel ist und

• festzulegen, welche Risiken man zu tragen bereit ist.

Erneut wird klar, dass dies keine Aufgabe ist, die die IT alleine bewältigen kann. Hier sind Management-Entscheidungen nötig. Eine enge Zusammenarbeit zwischen Technik, Sicherheit und Geschäftsleitung ist erforderlich.

Fazit

Nur wenn Informationssicherheit über ausreichend Rückendeckung seitens der Geschäftsleitung verfügt, die Verantwortlichkeiten klar geregelt sind und der gesamte Prozess ständig an wechselnde Anforderungen angepasst wird, kann IT-Sicherheit dauerhaft und nachhaltig gewährleistet werden. Eine Ausrichtung auf internationale Standards wie die ISO/IEC 17799 stellt einerseits sicher, dass alle wesentlichen Bereiche berücksichtigt wurden. Andererseits wird eine Revision erleichtert und die Transparenz für Kunden und Geschäftspartner erhöht. Engelbert Vogel, Principal Security Consultant Symantec Security Services