Sicherheit auf dem PrüfstandGrundsätze der Quantensicherheit

Jesper M. Johansson

Es kann manchmal äußerst interessant sein, eine Debatte von einem völlig anderen, aber dennoch nützlichen Blickwinkel anzugehen. Seit einiger Zeit verwende ich die Heisenbergsche Unbestimmtheitsrelation bei der Erläuterung von Sicherheitskonzepten. (Wenn Sie meine Einhorngeschichte kennen, wissen Sie, dass ich gern Grundsatztheorien aus anderen Disziplinen einbringe, um ein Argument anzubringen.) So ungewöhnlich

dies auch erscheint, aus anderen Wissenschaftszweigen können tatsächlich logische Konsequenzen für grundlegende Konzepte der Informationssicherheit abgeleitet werden.

Die Heisenbergsche Unbestimmtheitsrelation, die aus der Quantenphysik herrührt, basiert auf der Gleichung in Abbildung 1. Die Relation sagt aus, dass die Position eines Partikels (p) und das Moment eines Partikels (x) voneinander abhängig sind, d. h. wenn Sie die Messgenauigkeit für die Position erhöhen, verringern Sie die Genauigkeit, mit der Sie das Moment messen. Die Grenze für die Genauigkeit der beiden Faktoren ist ein kleines festgelegtes Vielfaches des Planckschen Wirkungsquantums. Um es verständlicher auszudrücken, dieses Prinzip besagt, dass Sie bestimmte Fakten über ein einziges Partikel nicht gleichzeitig genau beobachten können.

Abbildung 1** Heisenbergsche Unbestimmtheitsrelation **

Dies bezieht sich direkt auf das Vorherbestimmen ungewisser Bereiche, was Ihnen grundsätzlich die Vorhersage ermöglicht, wie unsicher Sie sich über den Zustand gewisser Fakten in Bezug auf ein Partikel sind. Sie können zwar die Bereiche (noch) nicht voraussagen, doch die Tatsache, dass Sie nicht mit Sicherheit voraussagen können, wie zwei Variable auf einem einzigen Computernetzwerk sich auf die Sicherheit dieses Netzwerks auswirken, ist wichtig.

Sie müssen außerdem Kompromisse eingehen. Auch wenn Sie in der Informationssicherheit nicht vom Planckschen Wirkungsquantum beschränkt werden, so liegen trotzdem Beschränkungen vor. Der wichtigste Kompromiss, den Sie eingehen müssen, betrifft die Sicherheit auf der einen und die Benutzerfreundlichkeit bzw. Nützlichkeit auf der anderen Seite. Wenn Sie für einen Moment die Verfügbarkeit ignorieren – und offen gesagt sollte das Sicherheitspersonal meiner Meinung nach nicht für die Verfügbarkeit verantwortlich sein, ausgenommen angesichts eines Denial-of-Service-Angriffs – besteht die einfachste Möglichkeit, etwas zu sichern, darin, es auszuschalten. So können Hacker nicht länger darauf zugreifen. Die Nützlichkeit geht dabei natürlich völlig verloren.

Ebenso gilt: Auch wenn es erheblich mehr kostet, können Sie den Verlust vertraulicher Daten durch das Implementieren eines entsprechenden Produkts zur Verhinderung von Datenverlust viel eher eindämmen, als durch das Senden einer alljährlichen E-Mail an alle Mitarbeiter, in der Sie daran erinnern, dass Instant Messaging-Anwendungen nicht für die Verwendung am Arbeitsplatz gedacht sind. Ist Ihre Organisation jedoch bereit, Ausgaben für ein Tool zur Verhinderung von Datenverlust vorzunehmen? Jetzt können Sie sehen, wie relevant die Quantenphysik für die Sicherheit ist.

Schrödingers Katze

Ein verwandtes, wenn auch anderes Konzept aus der Quantenphysik wird in der Parabel von Schrödingers Katze erläutert. Die Geschichte besagt, dass Erwin Schrödinger, ein bekannter Physiker des 20. Jahrhunderts, mit Albert Einstein (einem anderen bekannten Physiker des 20. Jahrhunderts, von dem Sie vermutlich schon gehört haben) ein lange andauerndes Streitgespräch über das Überlagerungsprinzip geführt hat. Schrödinger fand die Bereiche der Quantenmechanik, bei denen Elemente in einer Überlagerung von zwei Zuständen existieren, ziemlich absurd.

Um dies zu unterstreichen, führte Schrödinger ein Gedankenexperiment durch, bei dem eine Katze in einer hermetisch abgedichteten Kiste gehalten wurde. Bei dem anderen Element in der Kiste handelte es sich um einen Behälter mit Gift, dessen Ausschüttung von einem (imaginär) subatomaren radioaktiven Partikel gesteuert wurde. Beim Verfall des radioaktiven Partikels würde das Gift entweichen und die Katze sterben.

Das subatomare Partikel, das den Gesetzen der Quantenmechanik unterliegt, existiert in einem Zustand der Überlagerung. Die entschieden atomare Katze, deren Zustand vollständig vom subatomaren Partikel abhängt, existiert deshalb ebenfalls in diesem Zustand der Überlagerung. Nur dadurch, dass der Zustand der Katze tatsächlich beobachtet wird, kann sie in einen bestimmten Zustand von Lebendigkeit oder Leblosigkeit eingeordnet werden.

Schrödinger wollte damit natürlich illustrieren, wie absurd einige Gesetze der Quantenmechanik sind, wenn sie auf atomare Systeme angewendet werden. Dennoch wird sein Beispiel oft angeführt, wenn es darum geht, wie das allgemein als der „Beobachtereffekt“ bezeichnete Phänomen entstanden ist. Der Beobachtereffekt gilt zwar nicht für die subatomaren Systeme der Quantenmechanik, ist jedoch für Sicherheitsexperten interessant. Kurz gesagt, er sagt aus, dass etwas durch dessen Beobachtung geändert wird.

Der Beobachtereffekt

Nehmen Sie zum Beispiel eine Tasse Tee. Um herauszufinden, wie heiß der Tee ist, halten Sie ein Thermometer in die Tasse. Angenommen, der Tee hatte 80 Grad Celsius, als Sie das Thermometer in die Tasse gehalten haben, und das Thermometer selbst hatte eine Zimmertemperatur von 22 Grad. Sobald Sie das Thermometer in den Tee halten, nimmt es Wärme auf, und der Tee verliert bei Erwärmung des Thermometers einen Teil seiner Wärme. Schließlich erreichen das Thermometer und der Tee die gleiche Temperatur. Diese Temperatur beträgt allerdings weder 80 Grad noch 22 Grad, sondern etwas dazwischen. Folglich haben Sie die Teetemperatur durch das Messen geändert.

Der Beobachtereffekt ist auch für die Informationssicherheit wichtig. Jedes Mal, wenn Sie etwas unternehmen, um ein Sicherheitsproblem zu verringern, ändern Sie möglicherweise Ihre Sicherheitsposition, da Sie das System ändern. Ich will dies als den Effekt der Sicherheitspositionsfluidität (Security Posture Fluidity Effect, SPFE) bezeichnen, da mir momentan nichts Besseres in den Sinn kommt.

Eines der einfacheren Beispiele sind hierbei die Dienstkontenabhängigkeiten. In Kapitel 8 von „Protect Your Windows Network“ (protectyourwindowsnetwork.com) wird erläutert, wie Sie einen Angriffserkennungsdienst (Intrusion Detection Service, IDS) auf Ihren Systemen installieren, um Angriffe zu erkennen. Der Angriffserkennungsdienst speichert seine Protokolle jedoch in einem zentralen System und erfordert umfangreiche Rechte für die überwachten Systeme. In der Regel bedeutet das, dass der Dienst in einem Dienstkonto mit umfangreichen Rechten ausgeführt wird.

Wenn eins der Systeme beeinträchtigt wird, kann der Angreifer auf die Dienstkontenanmeldeinformationen und auf alle anderen Systeme zugreifen, abgesehen davon, dass er den Angriffserkennungsdienst deaktivieren kann. Dies ist ein sehr gutes Beispiel für den Effekt der Sicherheitspositionsfluidität (SPFE). Dadurch, dass Sie etwas installieren, um die Sicherheit in Ihrer Umgebung zu gewährleisten, führen Sie ein neues potenzielles Sicherheitsproblem ein.

Andere Beispiele für diesen Effekt sind reichlich vorhanden. Die Beschreibung von Steve Riley, warum bei 802.1x bestimmte Probleme in verkabelten Netzwerken auftreten (microsoft.com/technet/community/columns/secmgmt/sm0805.mspx), ist ein weiteres hervorragendes Beispiel. Es liegt auf der Hand, dass die Verwendung hostbasierter Firewalls in vielen Umgebungen sehr wünschenswert ist. Wenn sie jedoch zusammen mit 802.1x verwendet werden, ermöglicht diese Kombination einen bestimmten Angriff, der zuvor unmöglich war. Auch hier wird durch eine Sicherheitstechnologie die Sicherheitsposition der Umgebung geändert und ein Angriff ermöglicht, der andernfalls nicht möglich war.

All dies soll nicht heißen, dass diese Maßnahmen von Natur aus unnütz sind und vermieden werden sollten. Es bedeutet aber, dass Sie die Implikationen aller Sicherheitsmaßnahmen bedenken müssen. Beim Risikomanagement müssen Sie in Erwägung ziehen, was Ihre Aktionen und vorbeugenden Maßnahmen in Bezug auf Risiken tatsächlich bedeuten. Bei der Schadensbegrenzung können Sie nicht einfach aufhören, nachdem Sie eine Gegenmaßnahme implementiert haben. Sicherheit ist im wahrsten Sinne des Wortes ein Prozess. Sie müssen die Tiefenverteidigungsstrategie verwenden, doch bedenken Sie, welchen Veränderungen Ihre Sicherheitsposition durch diese Verteidigungsmaßnahmen unterworfen wird und wie Sie den neuen Bedrohungen begegnen, die aufgrund der Strategie auftreten.

Eine durchdachte Diensthärtungsstrategie

Ich arbeite bereits seit mehr als zehn Jahren an Anleitungen für die Diensthärtung. Rückblickend enthielten die ersten Handbücher, an denen ich gearbeitet habe, weiter nichts als Listen mit Einstellungen, deren Aktivierung meine Kollegen und ich für empfehlenswert hielten. Die allgemeine Sicherheitsstrategie war damals naiv. Im Grunde bestand die Logik darin, dass etwas eingeschaltet werden muss, um Sicherheit zu bieten. Die Tatsache, dass es legitime Gründe dafür geben könnte, dass etwas ausgeschaltet wird, fand nicht viel Beachtung.

Schließlich wurde mir bewusst, dass für eine effektive Diensthärtung viele Überlegungen angestellt werden und die Bedrohungen in Erwägung gezogen werden müssen, denen das System ausgesetzt ist. Diese Erkenntnis führte zu der Liste von Szenarios, die Sie im Windows 2000-Handbuch zur Härtung und Absicherung finden (go.microsoft.com/fwlink/?LinkID=22380). Der natürliche Folgeschritt bestand darin, die Anleitung in verschiedene Bedrohungsebenen aufzuteilen, was im Windows Server 2003-Sicherheitshandbuch (go.microsoft.com/fwlink/?linkid=14846) geschehen ist.

Dabei störte mich jedoch stets die Tatsache, dass es nach wie vor möglich war, in ein System einzudringen, auch wenn das gesamte Handbuch befolgt wurde und die entsprechenden Vorkehrungen getroffen waren. Das lag daran, dass entweder Patches fehlten, Zugriff aufgrund einer Betriebspraxis gewährt oder eine unsichere Drittanbietersoftware installiert wurde.

Es stellte sich heraus, dass die Diensthärtung in diesen beiden Handbüchern keine große Hilfestellung bei der gesamten Sicherheitsposition war. Wichtig sind im Endeffekt nur einige wenige Punkte. Genau genommen wurden beim sichersten System, das ich je erstellt habe (msdn2.microsoft.com/library/aa302370), nur vier oder fünf der in den Sicherheitshandbüchern aufgelisteten Anpassungen verwendet, und keine davon hat einen der Angriffe verhindert, denen sie ausgesetzt wurde. Leider will der Benutzer einfach nur eine große blaue Schaltfläche mit der Aufschrift „Jetzt sichern“, mit der die Systeme automatisch abgesichert werden. Sicherheit ist jedoch eine viel komplexere Angelegenheit.

Einstellung zum Risiko

Für einen effektiven Schutz (im Gegensatz zum finiten Zustand des Sicherseins), müssen Sie eine vernünftige Einstellung zum Risiko einnehmen. Sie müssen verstehen, welchen Risiken Sie gegenüberstehen. Sie müssen entscheiden, welche Risiken Sie verringern wollen, und schließlich müssen Sie verstehen, wie Sie diese Risiken verringern – etwas, was sich nicht allein durch den Einbau von Schaltern erzielen lässt.

In der Regel wurden diese Sicherheitsschalter für bestimmte Szenarios entworfen und bieten nicht unbedingt die beste Konfiguration für Ihr Szenario. Stattdessen stellen sie einen grundlegenden Ausgangspunkt dar und sind hauptsächlich deshalb verfügbar, weil ein Großteil des Markts solche schnellen Diensthärtungsanpassungen fordert. In moderner Software sind die meisten bereits standardmäßig aktiviert, und diejenigen, bei denen dies nicht der Fall ist, haben wahrscheinlich keine bedeutenden Nebeneffekte.

Außerdem könnte eine Vielzahl von Schaltern ein nicht unterstützbares und unsicheres System zur Folge haben, das die erforderlichen Aufgaben nicht durchführt, und das alles, um Bedrohungen zu verringern, die Sie noch gar nicht benannt haben. Der SPF-Effekt und die Quantenphysik heben die Bedeutung der erneuten Analyse nach dem Sichern hervor, doch viel zu viele Organisationen handeln nicht danach. Genau genommen machen sie den Fehler, die Bedrohungen gar nicht erst zu analysieren. Wenn Sie sich genauer mit der Analyse von Bedrohungen befassen, werden Sie feststellen, dass es sich bei den Dingen, die wirklich einen Unterschied machen, nicht um anonyme Einschränkungen für die Auflistung von Kontonamen und pauschale Änderungen von Zugriffssteuerungslisten handelt.

Was dagegen wirklich einen Unterschied macht, ist das Bestimmen, ob Ihr System einen bestimmten Dienst bieten sollte, und falls ja, für wen, und das anschließende Durchsetzen dieser Richtlinie. Es macht einen Unterschied, wenn Sie sicherstellen, dass nur die Systeme und Benutzer, die unbedingt mit Ihnen kommunizieren müssen, die Berechtigung dazu haben. Es macht einen Unterschied, wenn Sie sicherstellen, dass alle Anwendungen und Benutzer mit möglichst minimalen Berechtigungen operieren. Kurz gesagt, was einen Unterschied macht, ist eine vernünftige Einstellung zur Sicherheit und das Durchführen schwieriger Analysen, sodass Sie jedem System ermöglichen, Verantwortung für seine eigene Sicherheit zu übernehmen.

Aus diesem Grund werden im aktuellen Sicherheitsansatz jetzt solche Tools wie die Server- und Domänenisolation (microsoft.com/sdisolation), der Sicherheitskonfigurations-Assistent (SCW) in Windows Server®-Produkten und die Server-Manager-Tools für das Verwalten von Rollen in Windows Server 2008 eingesetzt. Diese Tools bieten eine Anleitung zum Verständnis der zu unterstützenden Szenarios, und sie helfen Ihnen, Ihre Systeme dementsprechend zu sperren. Zugegebenermaßen stellen diese Tools nicht das Allheilmittel dar, nach dem sich alle sehnen, doch mit ihrer Hilfe kann eine supportfähige Konfiguration hergestellt werden, die tatsächlich die Aufgaben durchführt, für die Sie die Software erworben haben.

Sicherheit einsetzen, wo sie benötigt wird

All dies bedeutet, dass Sie sich nicht auf andere Entitäten oder einfache Sicherheitsanpassungen verlassen können. Jede Ressource muss sich selbst verteidigen können, da Konzepte wie „Umkreis“ und „internes Netzwerk“ heute keine Bedeutung mehr haben.

Die große Mehrzahl organisatorischer Netzwerke enthalten bestenfalls eine teilweise feindliche Umgebung. Machen Sie sich dies bewusst, und leiten Sie die entsprechenden Schritte ein, ohne sich lediglich spontan auf Diensthärtungsanleitungen zu verlassen. Als Erstes müssen Sie über Ihre Anforderungen Bescheid wissen. Dazu gehört auch, dass Sie sich von anderen beraten lassen, die über Ihre Anforderungen ebenfalls Bescheid wissen.

Von einem Gast in einem Webcast ging kürzlich die Empfehlung aus, dass Benutzer in Kleinunternehmen die Website des „Department of Homeland Security“ besuchen, um dort eine Diensthärtungsanleitung für Internet Explorer® herunterzuladen. Weshalb sollte eine Behörde, die mit dem Schutz des Militärs und der Staatssicherheit beauftragt ist, eine vernünftige Anleitung zum Sichern eines Webbrowsers in einem Kleinunternehmen bieten können? Das ist ein sehr gutes Beispiel für die immer noch weit verbreitete unschlüssige Logik im Bereich Computersicherheit. Hier wird angenommen, dass aufgrund des Umstands, dass die Anleitung von einer Behörde veröffentlicht wurde, die Ergebnisse folglich sicher sein müssen.

Die Auswahl wird meist als eine binäre Entscheidung präsentiert: Entweder können Sie über „hohe Sicherheit“ oder über „niedrige Sicherheit“ verfügen. Eine bessere Auswahl wäre die zwischen „hoher Sicherheit“ oder „angemessener Sicherheit“. Sicherheit bedeutet nicht immer dasselbe.

Eine hohe Sicherheit eignet sich eigentlich nicht für alle. Für die meisten Organisationen ist sie sogar nicht geeignet. Sie ist nicht unbedingt das Endziel, das Sie anstreben sollten. Bei hoher Sicherheit handelt es sich um eine spezialisierte Konfiguration für Systeme, in denen es um Menschenleben geht, wenn das System gefährdet wird. Wenn dies Ihrem Risikoprofil und Bedrohungsmodell entspricht, dann verwenden Sie eine hohe Sicherheit.

Wenn das allerdings nicht Ihrem Risikoprofil und Bedrohungsmodell entspricht, dann sollten Sie ein angemesseneres Sicherheitsmodell verwenden. Vermutlich sind alle Anpassungen, die Sie konfigurieren können, standardmäßig bereits entsprechend auf die Ebene eines mittleren Risikoprofils eingestellt. Dieser Standardzustand, der heute in den meisten Microsoft-Produkten verwendet wird, bietet einen vernünftigen Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit, Nützlichkeit und Leistung. Dabei wird die Diensthärtung in der Regel für Sie vorgenommen.

Jetzt müssen Sie andere Sicherheitsschritte bedenken. Ein guter Ausgangspunkt ist das TechNet-Sicherheitscenter (microsoft.com/technet/security) – und natürlich Bücher wie das „Windows Server 2008 Security Resource Kit“.

Alles dreht sich um das Risikomanagement

Vermutlich haben Sie bereits erkannt, worauf ich hinaus will: das Risikomanagement. Die wichtigste Botschaft, die von der Heisenbergschen Unbestimmtheitsrelation ausgeht, ist die, dass Kompromisse eingegangen werden müssen. Dieser Teil der Relation ist nicht so schwer zu verstehen.

Doch die Botschaft in der Geschichte von Schrödingers Katze ist etwas, was von den meisten Menschen nicht berücksichtigt wird. Es ist nicht nur wichtig, dass Sie alle Seiten des Problems analysieren und eine Entscheidung über die Kompromisse treffen, sondern Sie müssen auch die Änderungen bedenken, die Ihre Lösungen nach sich ziehen. Bei einer vernünftigen Risikomanagementstrategie wird berücksichtigt, wie die Änderungen sich auf das System auswirken und ob die Änderungen als Teil einer Strategie zum Einsatz schadensbegrenzender Maßnahmen oder aus einem anderem Grund implementiert wurden.

Auf das Jahr umgerechnete Schadenserwartung

Eine allgemeine Art der Risikoquantifizierung und die Methode, die Sie in vielen Sicherheitszertifizierungskursen lernen, ist die auf das Jahr umgerechnete Schadenserwartungsgleichung (Annualized Loss Expectancy, ALE), die in Abbildung 2 dargestellt ist. Die Standardgleichung ist einfach. Sie bestimmen die Wahrscheinlichkeit eines Vorfalls und die Kosten, die mit jedem Vorfall verbunden sind, und multiplizieren dann diese beiden Werte. So erhalten Sie den Betrag, den Sie pro Jahr für Sicherheitsvorfälle voraussichtlich ausgeben müssen. Wenn die Kosten des Risikos hoch genug sind, implementieren Sie schadensbegrenzende Maßnahmen.

Abbildung 2** Die auf das Jahr umgerechnete Schadenserwartungsgleichung ist die Wahrscheinlichkeit eines Vorfalls, multipliziert mit den pro Vorfall anfallenden Kosten. **(Klicken Sie zum Vergrößern auf das Bild)

Das Problem besteht darin, dass die Standard-ALE-Gleichung den Kosten der schadensbegrenzenden Maßnahmen nicht gerecht wird. Abgesehen davon, dass schadensbegrenzende Maßnahmen an und für sich mit Kosten verbunden sind, ergeben sich daraus auch oft Nebeneffekte, die ebenfalls mit Kosten verbunden sind.

Bedenken Sie eine der meisten Standardsicherheitsanpassungen: die Kontosperrung. Viele Organisationen setzen die Kontosperrung ein, vorgeblich um Angreifer vom Erraten von Kennwörtern abzuhalten. Sie können mathematisch die Wahrscheinlichkeit berechnen, dass ein Angreifer ein beliebiges Kennwort errät. Wenn Sie erfinderisch sind, können Sie auch die durchschnittlichen Kosten berechnen, die durch die Sicherheitsverletzung entstehen, bei der ein Angreifer ein Kennwort errät. Aufgrund dieser beiden Zahlen haben viele Organisationen beschlossen, dass die ALE-Gleichung unannehmbar ist, und haben deshalb die Kontosperrung implementiert.

Diese Art von Schadensbegrenzung ist jedoch mit Kosten verbunden, die Sie vielleicht nicht unbedingt berücksichtigen. Dazu gehören die Kosten, die beim Implementieren schadensbegrenzender Maßnahmen selbst entstehen, auch wenn diese recht gering sind. Um genau zu sein, sollte die Berechnung auch die Kosten der Nebeneffekte einschließen, die sich aus den schadensbegrenzenden Maßnahmen ergeben.

Erstens entstehen dadurch Kosten, dass der Helpdesk die Konten der Benutzer wieder entsperrt. Selbst wenn ein Konto nur eine kurze Zeit lang gesperrt ist, angenommen 15 Minuten, entstehen trotzdem Kosten aufgrund der Produktivitätseinbußen in diesem Zeitraum. Dieser Faktor wird als die Ausgabe für den jeweiligen Vorfall gezählt, multipliziert mit der Wahrscheinlichkeit, dass dieser Vorfall im definierten Zeitraum stattfindet. In diesem Fall würden Sie die Kosten mit der erwarteten Anzahl von Sperrereignissen multiplizieren – eine Zahl, über die Ihre Protokolle möglicherweise bereits Auskunft geben können.

Außerdem müssen Sie den Faktor der Benutzerverärgerung in Betracht ziehen. Es wird gemunkelt, dass Benutzer einfachere Kennwörter verwenden, wenn sie mit einer Kontosperrung rechnen müssen, da sie sich bei einfacheren Kennwörtern nicht so oft verschreiben. Daher besteht immer noch die Möglichkeit, dass sich der Vorfall, der verhindert werden sollte, nach dem Implementieren der schadensbegrenzenden Maßnahmen wiederholt.

Abschließend ist anzumerken, dass es Sicherheitsrisiken geben kann, die erst durch die schadensbegrenzenden Maßnahmen eingeführt wurden und zuvor nicht im System vorhanden waren. Im Fall einer Kontosperrung kann ein Angreifer dieses Feature verwenden, um alle Konten im Netzwerk zu deaktivieren, indem er immer wieder die Kennwörter falsch errät. Es gibt eine Wahrscheinlichkeit dafür, dass dies vorkommt, samt den mit jedem Vorfall verbundenen Kosten.

Werden all diese Faktoren in Betracht gezogen, wird deutlich, dass Sie die Schadenserwartungsgleichung ändern müssen. Zunächst muss die Wahrscheinlichkeit des Vorfalls geändert werden. Die Wahrscheinlichkeit, dass dieser Vorfall eintritt, sollte jetzt geringer sein als zuvor, auch wenn sie, wie oben schon beschrieben, nicht ganz auf null fallen dürfte. Die Kosten der einzelnen Vorfälle dürften sich ebenfalls geändert haben. Dem jeweiligen Produkt müssen die Kosten der Schadensbegrenzung hinzugefügt werden. Diese Kosten setzen sich aus den Implementierungskosten plus der Summe der auf das Jahr umgerechneten Kosten der Nebeneffekte zusammen. Die einzelnen auf das Jahr umgerechneten Kosten sind auf die Wahrscheinlichkeit, dass ein Nebeneffekt stattfindet, und die Kosten des jeweiligen Nebeneffekts zurückzuführen. Als vereinfachte Darstellung ist die genauere Risikoanalysegleichung in Abbildung 3 aufgeführt.

Die verbesserte Gleichung in Abbildung 3 bietet eine viel genauere Möglichkeit für die Analyse des mit einem bestimmten Problem verbundenen Risikos. Viele Organisationen haben bereits auf diese Weise eine Risikoanalyse durchgeführt. Doch viele betrachten Risiken weiterhin auf eine allzu vereinfachte Weise, die der Anforderung, die Auswirkungen schadensbegrenzender Maßnahmen zu analysieren, nicht gerecht wird. Mithilfe der geänderten ALE-Gleichung stellen Sie diese Anforderung absolut in den Mittelpunkt.

Abbildung 3** Erwägen der zusätzlichen Kosten schadensbegrenzender Maßnahmen **(Klicken Sie zum Vergrößern auf das Bild)

Die Bedeutung der obigen Ausführungen

Wenn Sie nach dem Lesen dieses Artikels auch nur einen Aspekt umsetzen, dann sollte dies das Infragestellen der konventionellen Weisheit hinter Sicherheitsstrategien sein. Im Bereich der Informationssicherheit wird viel zu sehr nach einer pauschalen stereotypischen Sicht der Welt gehandelt. Viele dieser Annahmen sind jetzt veraltet.

Die Angriffe haben sich geändert. Die Angreifer sind jetzt Fachleute, denen es um Geld, eine Vormachtstellung und die Umsetzung von Ideologien geht. Sie können es sich nicht leisten, Zeit und Geld für Sicherheitsanpassungen zu verschwenden, die nicht zur Verbesserung der Sicherheit beitragen. Sie müssen daher einen viel ausgereifteren Ansatz im Bereich Risikomanagement an den Tag legen.

Zuerst ist es wichtig, dass Sie erkennen, dass alle Aktionen mit einem Kompromiss einhergehen. Sie können nicht alles mit 100-prozentiger Gewissheit wissen.

Zweitens müssen Sie verstehen, dass Sie in einem wechselseitig abhängigen System operieren. Durch Einführen von Sicherheitsänderungen ändern Sie das System selbst. Das heißt, Sie müssen das System anschließend erneut analysieren.

Vorzugsweise sollte dies vor dem tatsächlichen Implementieren der Änderungen erfolgen, da die Änderungen oft eine solch ungeheure Auswirkung auf das System haben, dass sie mehr Schaden anrichten, als Vorteile zu bringen. Setzen Sie bessere Analysetools ein, die Sie daran erinnern, die Änderungen zu analysieren.

Denken Sie abschließend daran, immer den menschlichen Faktor im Auge zu behalten. Alles, was Sie im Bereich der Informationssicherheit unternehmen, dient dem Zweck, dem Geschäft und den Benutzern innerhalb der Organisation eine möglichst sichere Arbeitsumgebung zu ermöglichen.

In einer kürzlichen Präsentation habe ich darauf hingewiesen, dass es keinen Benutzer gibt, der einen Computer kauft, um ein Antivirenprogramm auszuführen. Sicherheit ist Ihr Hauptziel, aber es ist nicht das Hauptziel des Unternehmens als Ganzes. Es gibt Organisationen, die den Faktor Sicherheit lediglich tolerieren, da dies im Augenblick in ihrem Interesse ist. Denken Sie immer daran, dass die Informationssicherheit letzten Endes dem Geschäft dienen soll, nicht umgekehrt. Wenn Sie diese Tatsache ignorieren, werden Ihre Benutzer alles tun, um ihre Arbeit zu erledigen, auch wenn sie dafür Sicherheitsbestimmungen, die sie nicht verstehen oder denen sie nicht zustimmen, umgehen müssen.

Jesper M. Johanssonist Softwarearchitekt mit dem Schwerpunkt Sicherheitssoftware und schreibt redaktionelle Beiträge für das TechNet Magazin. Er hat seine Doktorarbeit zum Thema Management Information Systems geschrieben, verfügt über mehr als 20 Jahre Erfahrung auf dem Gebiet der Sicherheit und ist Microsoft-MVP (Most Valuable Professional) im Bereich Unternehmenssicherheit. Sein aktuelles Buch ist das Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.