| 
Haben Sie einen Fehler gefunden? Bitte benachrichtigen Sie uns per E-Mail. Vielen Dank.
Im Sommer 2003 veröffentlichte Gartner eine Untersuchung, die den Wert von Intrusion Detection Systems (IDS) in Frage stellte. Im Zentrum der Diskussion standen dabei Themen wie laufende Verwaltungskosten, Fehlalarme und Interoperabilität bei der Implementierung. Als Alternative wurde unter anderem empfohlen, den Einsatz von Intrusion Prevention Systems (IPS) zu prüfen oder das IDS in andere Sicherheitsprodukte zu integrieren.
Das Problem dabei ist, dass man den Ausweg aus einem technischen Dilemma bei noch mehr Technik sucht, während grundlegende Fragen komplett übersehen werden: Wie findet man den richtigen Sicherheitsansatz für sein Unternehmen? Wie implementiert und verwaltet man Sicherheitsprodukte, sodass sie den Geschäftszielen des Unternehmens dienen? Und wie integriert man die einzelnen Sicherheitsprodukte in eine Gesamt-Sicherheitsstrategie?
Um es kurz zu machen: Die meisten IT-Verantwortlichen gehen das Thema Sicherheit nach wie vor falsch an, nämlich reaktiv. Der typische IT-Sicherheitsansatz besteht darin, immer noch mehr Technik aufzufahren statt zunächst den Problembereich genau zu definieren, Richtlinien und Verfahren zur Lösung des Problems zu konzipieren und dann erst zu prüfen, mit welchen technischen Maßnahmen man diese Prozesse unterstützen kann.
Viel zu viele Unternehmen machen ihre Sicherheitsentscheidungen von speziellen Ereignissen und Bedrohungen abhängig. Sie warten ab, bis eine neue Bedrohung auftaucht, und weisen dann die IT-Abteilung an, neue Technik zu installieren, um der Bedrohung zu begegnen. Diese Haltung lässt sich mit dem Gesundheitswesen vergleichen: Die Leute handeln nicht, bevor sie krank werden, sondern gehen erst dann zum Arzt, wenn sie schon krank sind. Dabei gibt es immer mehr Belege dafür, dass gut funktionierende Gesundheitssysteme vorrangig auf Prävention setzen sollten.
Zurück zu IDS: "Reine" Intrusion Detection Systems können Angriffe (mehr oder weniger zuverlässig) entdecken – aber wenn sie aufgrund eines Vorfalls Alarm auslösen, was dann? Welcher Prozess zur Bearbeitung des Ereignisses ist vorgesehen? Wer ist daran beteiligt? Welche anderen technischen Systeme und Verfahren werden dafür eingesetzt? Wie sieht es mit Follow-up-Maßnahmen oder Berichterstattung aus? Mit einem IDS investiert man zunächst nur in eine Technik, die bei der Feststellung eines Problems hilft, von dessen Existenz man bereits weiß – aber wie binden Sie diese Technik in Maßnahmen zur Behebung des Problems ein? Um zum Gesundheits-Vergleich zuruückzukehren: Nicht nur, dass – ohne entsprechenden Überbau – die Abwehrkräfte nicht richtig funktionieren; es gibt auch kein Rezept, um den Patienten zu helfen, wenn sie krank werden. Das ist so, als würde ein Arzt nur bestätigen: "Stimmt, Sie sind krank", und es dabei bewenden lassen.
In vielen Unternehmen wurde der IDS-Einsatz dennoch mit dem dahinter liegenden Prozess selbst gleichgesetzt, nämlich dem Incident-Management-und-Response-Prozess als Teil der (Netzwerk-)Sicherheitspolitik. Unter diesen Umständen verkommt dieser Prozess jedoch zum bloßen Technik-Silo, an den nachträglich Geschäftsprozesse getackert wurden, die zur eingesetzten Technik passen. Am Ende musste manches Unternehmen, das diesen Weg eingeschlagen hatte, feststellen, dass seine enormen Investitionen in die einzelnen Komponenten des Incident-Management-und-Response-Prozesses nur eine unzureichende Lösung des Problems erbracht hatten. Deshalb noch einmal die Frage: Wenn ein Angriff entdeckt wurde – was dann?
Vereinfacht ausgedrückt, besteht Incident-Management und -Response aus den Teilprozessen Entdecken, Korrelieren, Benachrichtigen, Beseitigen von Schwachstellen sowie Berichterstattung. Das IDS hat hier seinen Platz als primäres Werkzeug zur Entdeckung und bis zu einem gewissen Grad auch zur Korrelation – doch erst, wenn man das IDS im Lichte des gesamten Prozesses betrachtet, erkennt man die Lücken, die es nicht schließen kann. Aus dieser Perspektive wird auch klar, dass man noch weitere Sub-Prozesse und Tools zur Korrelation, Benachrichtigung, Schwachstellenbeseitigung und Berichterstattung benötigt.
Bevor man nun die Anschaffung zusätzlicher Technik erwägt, sollte man zunächst das Potenzial bereits vorhandener Management- und Überwachungs-Tools voll ausschöpfen, um die Beseitigungs- und Korrelationsprozesse zu unterstützen. Auch der Rückgriff auf bereits bestehende Prozesse kann sinnvoll sein, beispielsweise in der Abfolge: Sperre des Internetzugangs (unter bestimmten Voraussetzungen), Einsatz von Desktop-Management-Systemen, um Updates für Viren-Signaturen zu verteilen, Planung automatischer Patch-Vorgänge für Betriebssysteme und Anwendungen und schlussendlich wieder die Freigabe des allgemeinen Internetzugangs bei gleichzeitiger Filterung nach Bedrohungs-Signaturen durch die Sicherheitssysteme am Perimeter.
Wichtig ist bei alledem eine korrekte Zuordnung von Ursache und Wirkung: Die Implementierung von Policies sollte nicht durch technische Komponenten angestoßen oder limitiert werden. Vielmehr sollte zunächst ein Gesamtsystem aus Prozessen und Prozeduren definiert und die Technik dann als mögliches Instrument für deren Implementierung zum Einsatz kommen. Die richtige Mischung aus Prozessen und Technik gewährleistet so eine effektive und skalierbare Lösung.
Ein IDS ist dabei als ein Werkzeug zu betrachten, das Teilprozesse eines Incident-Management-und-Response-Prozesses im Rahmen einer umfassenderen Sicherheitspolitik unterstützt. In den meisten Sicherheitsprofilen fehlt es jedoch an der Verknüpfung von Tools, an davon unterstützten Prozessen und den erforderlichen Richtlinien. Dabei geht es um keine übermäßig komplexen Sachverhalte: Auf einen einfachen Nenner gebracht müssen Unternehmen zunächst erkennen, dass Richtlinien unabdingbar sind und entscheiden, wie ihre Richtlinien verwaltet werden sollen.
Anschließend gilt es, die Richtlinien in Prozesse zu übersetzen, die eine Durchsetzung im gesamten Netzwerk ermöglichen, und zu prüfen, welche Tools zur Unterstützung dieser Prozesse erforderlich sind. All dies führt dann zu konkreten Implementierungen, wie etwa dem Management von Firewall-Regeln und Router ACLs im gesamten Unternehmen.
Wir haben nun sozusagen "rückwärts" hergeleitet, was für Incident-Management- und -Response als Teil einer Sicherheitspolitik realisiert werden muss. Policies sind nun die Grundlage, auf deren Basis Vorgaben, Standards und Verfahren definiert werden. Policies können viel dazu beitragen, die Bedrohungslage zu entschärfen. Einige Beispiele:
Um unternehmensweite Netzwerke effektiv schützen zu können, müssen die Sicherheitsverantwortlichen in Zusammenarbeit mit dem Management, den IT-Abteilungen und den einzelnen Geschäftseinheiten derartige High-Level-Policies formulieren, die die Entwicklung konkreter Standards und Arbeitsanweisungen fördern.
Allzu oft werden sowohl der gesamte Sicherheits-Prozess als auch die Policy von der Technik bestimmt: Hat man sich für eine Sicherheitsvorrichtung entschieden, so diktiert diese dann die mit ihr verbundenen Abläufe und die zugehörigen Richtlinien. Das muss ein Ende haben! Denn wenn die Sicherheitsvorrichtungen selbst lediglich auf Angriffe reagieren, heißt das in letzter Konsequenz, dass die Angreifer die Sicherheitspolitik diktieren.
Für mehr Sicherheit im Unternehmen muss es richtig herum heißen: Erst kommt der Prozess, dann die Technik!
Joseph Cupano (CISSP) ist Technischer Direktor von Solsoft Inc.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2005#4, Seite 66
|