![[Illustration]](07-5-052-1.jpg)
Abbildung 2: Abbildung der neuen Maßnahmen auf den klassischen Incident-Management-Prozess
Die dauerhafte Aufrechterhaltung eines angemessenen Sicherheitsniveaus macht es notwendig, dass sich ein Unternehmen oder eine Behörde intensiv mit dem Thema der Behandlung von auftretenden Sicherheitsvorfällen auseinandergesetzt hat. Hierzu gehört auch, dass im Vorfeld geeignete technische und organisatorische Voraussetzungen geschaffen werden: Zum einen gehört die Schärfung des Bewusstseins, dass im eigenen Umfeld ein Sicherheitsvorfall auftreten kann und daraus Schäden entstehen können, zum ersten Startpunkt einer idealen Vorbereitung. Neben den direkten Auswirkungen eines Sicherheitsvorfalls ist zum anderen aber auch zu bedenken, dass ein wirklicher Schaden vielleicht erst durch unsachgemäßes und ineffektives Handeln in einer Krisensituation entstehen kann.
Der in den IT-Grundschutzkatalogen des BSI enthaltene und zu den übergeordneten Aspekten zählende Baustein 1.8 "Behandlung von Sicherheitsvorfällen" wird derzeit überarbeitet. Dies ist nötig geworden, da im gleichen Zuge das gesamte Themengebiet des Notfallmanagements in den IT-Grundschutzkatalogen neu gegliedert und um wesentliche Aspekte des Business Continuity Management (BCM) erweitert wird. Daraus ergab sich neben Änderungen der prozessualen Abläufe auch eine Harmonisierung der in beiden Bausteinen verwendeten Rollen. Zusätzlich sollte die Schnittstelle zwischen beiden Bausteinen stärker ausgeprägt werden.
Ein weiterer Beweggrund für die Überarbeitung des Bausteins 1.8 war der Wunsch der Anwender, sich stärker an anerkannten Standards aus dem ISO- und ITIL-Bereich (IT Infrastructure Library) zu orientieren. Da viele IT-Abteilungen bereits professionelles Störungserkennungs- und -behebungsmanagement (Incident-Management) betreiben und dafür funktionierende Prozesse und Rollen etabliert wurden, lag es weiterhin nahe, die Schnittstelle dieser Prozesse zur Sicherheitsvorfallsbehandlung (auch als Security-Incident-Management bezeichnet) zu beschreiben. Dies geschieht auch vor dem Hintergrund des gerade in Erarbeitung befindlichen IT-Grundschutzbausteins "Patch- und Updatemanagement".
Da eine professionelle Behandlung von Sicherheitsvorfällen auch zu professionellen Ergebnissen bei der Aufklärung dieser Vorfälle führen kann, muss sich die betroffene Organisation mit der Frage beschäftigen, ob die angewandten Methoden und Verfahren auch bei einer strafrechtlichen, zivilrechtlichen oder arbeitsrechtlichen Verfolgung Bestand haben würden. Aus dieser Fragestellung heraus wurde der Baustein um Fragen der Computer-Forensik beziehungsweise der digitalen Beweissicherung erweitert.
Weitere Einflussfaktoren bei der Überarbeitung des Bausteins waren ISO TR 18044 "Information security Incident-Management" sowie die Studie "ITIL und Informationssicherheit Aspekte der Integration von Incident und Security Management" der KBSt des Bundesministeriums des Innern und der HiSolutions AG.
Auch wenn ausreichende organisatorische, technische, personelle und infrastrukturelle Sicherheitsmaßnahmen vorhanden sind, kann es immer wieder zu Sicherheitsvorfällen kommen. Oft passieren aber bei der effizienten Behandlung dieser Sicherheitsvorfälle Fehler, besonders wenn die betroffene Organisation unzureichend vorbereitet ist. Häufig sind keine angemessenen Prozesse (standardisiertes Verfahren mit Rollenverantwortung) vorhanden und es wird ad-hoc an bereits vorhandenen – aber nicht bekannten – Strukturen vorbei gehandelt.
Dies kann dann dazu führen, dass redundante Strukturen die Effizienz die Behandlung von Sicherheitsvorfällen schwächen. Eine weitere große Gefahr besteht darin, dass Sicherheitsvorfälle nicht als solche erkannt werden. Neben der allgegenwärtigen Mammutaufgabe, die Anwender stärker in dieser Hinsicht zu sensibilisieren, kommt hinzu, dass im Rahmen der klassischen IT-Störungserkennung- und -behebung Sicherheitsvorfälle als scheinbar normale Störungen auflaufen. Ist das Service-Desk-Personal nicht ausreichend geschult oder sind ihm nur unzureichende Hilfsmittel an die Hand gegeben worden, können wertvolle Stunden der Früherkennung von Schadenpotenzial verstreichen.
Das klassische Incident-Management beschreibt eine Störung (Incident) als Ereignis, das tatsächlich oder potenziell eine Minderung der Servicequalität verursacht. Analog dieser Definition lässt sich beim Security-Incident-Management ein Sicherheitsvorfall als unerwünschtes Ereignis (oder Kombination mehrerer Ereignisse) verstehen, das Auswirkungen nach sich ziehen kann, die durch Beeinträchtigung von Geschäftsfunktionen einen großen Schaden anrichten können und die Informationssicherheit erheblich verschlechtern. Daraus kann sich natürlich auch eine Verminderung der Servicequalität ergeben, was eine Verzahnung der beiden Punkte an definierten Schnittstellen sinnvoll erscheinen lässt.
Analog zum Notfall ist es auch für die Behandlung von Sicherheitsvorfällen unumgänglich, dass in einem Unternehmen beziehungsweise einer Behörde eine klare Vorstellung davon herrscht, was überhaupt als Sicherheitsvorfall zu definieren ist. Vor allem muss klar sein, wie sich Sicherheitsvorfälle von Störungen im Tagesbetrieb unterscheiden. Nur so ist es möglich, im Rahmen des normalen Störungs- und Fehlerbehebungsprozesses den geeigneten Startpunkt für die besonderen Maßnahmen des Sicherheitsvorfallsbehandlung-Prozesses zu finden.
Eine weitestgehend formale Definition ohne zu breite Interpretationsspielräume kann den Start dieses Prozesses zusätzlich erleichtern. So lässt sich beispielsweise anhand des Schutzbedarfs beziehungsweise der Ergebnisse der Business-Impact-Analyse (BIA) des direkt oder potenziell betroffenen Systems eine Schwelle definieren, ab wann ein Ereignis ein Sicherheitsvorfall ist. Zusätzlich sollte es dem IT-Sicherheitsmanagement unabhängig von Definitionsgrenzen möglich sein, einen außerordentlichen Sicherheitsvorfall auszurufen.
Eine mögliche Definition eines Sicherheitsvorfalls könnte zum Beispiel lauten: Als Sicherheitsvorfall wird in unserem Haus ein Ereignis bezeichnet, das die Vertraulichkeit, Verfügbarkeit und Integrität unserer IT-Service, IT-Systeme oder IT-Anwendungen mit hohem oder sehr hohem Schutzbedarf derart beeinträchtigt, dass ein großer Schaden für unser Haus oder seine Kunden und Geschäftspartner entstehen kann. Sinnvollerweise sollte die individuelle Definition eines Sicherheitsvorfalls mit der Definition eines Notfalls abgestimmt werden.
In den IT-Grundschutzkatalogen sind typische Sicherheitsvorfälle beispielsweise
Solche Sicherheitsvorfälle können zum Beispiel ausgelöst werden durch das Fehlverhalten von Benutzern, Administratoren oder externen Dienstleistern, das zu sicherheitskritischen Änderungen von Systemparametern führt, wie
Sicherheitsvorfälle können auch ausgelöst werden durch mutwillige vorsätzliche Manipulationen beziehungsweise Manipulationsversuche. Die Auslöser sind am Anfang der Behandlung von Sicherheitsvorfällen oft nicht bekannt.
Mit der Einführung beziehungsweise Optimierung des Incident-Management werden häufig die folgenden Ziele verbunden:
Mit der Einführung beziehungsweise Optimierung der Sicherheitsvorfallsbehandlung werden die folgenden Ziele verbunden:
Die Aufgaben innerhalb des Prozesses zur Behandlung von Sicherheitsvorfällen lassen sich vereinfacht auch so beschreiben: melden, erfassen, klassifizieren, verbindlich bestätigen, beheben und schließen /dokumentieren. Hier ist ganz klar eine Nähe zum Incident-Management zu sehen.
Neben der bereits vorhandenen pauschalen Gefährdung G 2.62 "Ungeeigneter Umgang mit Sicherheitsvorfällen" sind zwei neue Gefährdungen aufgenommen worden: "Nicht erkannte Sicherheitsvorfälle" sowie "Zerstörung von Beweisspuren bei der Behandlung von Sicherheitsvorfällen".
Gerade bei einer hohen Anzahl von Störungen und Fehlern, die im täglichen IT-Betrieb einer Behörde oder eines Unternehmens auftreten können, besteht die Gefahr, dass Sicherheitsvorfälle durch das Personal nicht als solche identifiziert werden und ein Angriff beziehungsweise Angriffsversuch unerkannt bleibt. Auch wenn die IT-Benutzer nicht ausreichend für die Belange der IT-Sicherheit sensibilisiert sind, kann es dazu kommen, dass sie Sicherheitsvorfälle nicht erkennen. Beispielsweise wird die Beeinträchtigung der Kapazität der Internetanbindung eventuell auf die mangelnde Leistung des Internet-Service-Providers geschoben, ohne eine genaue Verkehrsanalyse durchzuführen. Die wirkliche Ursache für die Kapazitätseinbußen ist aber vielleicht ein kompromittierter Server im LAN, der als illegaler Dateiserver benutzt wird und dadurch Bandbreite konsumiert.
Eine anderes Beispiel: Ein Benutzer bekommt bei der Anmeldung an seiner IT-Anwendung den Hinweis, dass er das letzte Mal am Sonntagmorgen angemeldet war, obwohl er am Wochenende nicht gearbeitet hat. Der IT-Benutzer schöpft keinen Verdacht und meldet diesen Vorfall nicht dem IT-Sicherheitsmanagement. Dadurch bleibt die Tatsache verborgen, dass ein Angreifer Zugang zum Benutzerprofil des IT-Benutzers hat oder dessen Passwort möglicherweise erraten hat.
Wenn bei der Behandlung von Sicherheitsvorfällen unvorsichtig agiert wird, kann es vorkommen, dass für die Aufklärung oder spätere juristische Verfolgung wichtige Beweisspuren unbeabsichtigt zerstört werden. Ein Beispiel dafür ist, wenn ein Administrator auf seinem System feststellt, dass der zur Verfügung stehende Speicherplatz schlagartig kleiner wird und keine Daten mehr gespeichert werden können. Um die Störung zu beheben, löscht er sofort alle Protokolldateien. Diese Protokolldateien hätten dem IT-Sicherheitsmanagement eventuell enthüllt, dass der Server angegriffen wurde und die möglichen Quellen gezeigt.
Ein anderes Beispiel wäre, dass ein wichtiger Server kompromittiert wird, weil der Administrator durch die starke Arbeitsbelastung und ein fehlendes Wartungsfenster die letzten Sicherheits-Updates nicht einspielen konnte. Um möglichen disziplinarischen Konsequenzen zu entgehen, spielt der Administrator die fehlenden Updates ein, bevor das IT-Sicherheitsmanagement die Einbruchsursache und den entstandenen Schaden analysieren kann. Mangelnde Fehlerkultur hat somit eine Analyse des Problems verhindert. Um diesen und weiteren Gefährdungen zu begegnen, wurden neue Maßnahmen eingeführt.
Orientiert am Lebenszyklus der IT-Sicherheit (siehe BSI 100-1) wurde der Prozess der Sicherheitsvorfallsbehandlung an den Phasen dieses Zyklus orientiert wie im folgenden Kasten beschrieben (die angegebenen Maßnahmennummern werden sich jedoch noch ändern).
Als weiteres Hilfsmittel wurde ein Fragebogen aufgenommen, der einer Behörde oder einem Unternehmen die Möglichkeit bietet, durchgängige standardisierte Dokumentationen von Sicherheitsvorfällen zu erstellen.
----------Anfang Textkasten----------
| M 6.58/neu00 | (A) Etablierung eines Managementsystems zur Behandlung von Sicherheitsvorfällen |
|---|---|
| M 6.neu01 | (A) Erstellung einer Richtlinie zur Behandlung von Sicherheitsvorfällen |
| M 6.neu02 | (A) Definition Sicherheitsvorfall |
| M 6.neu03 | (Z) Einrichtung eines Expertenteams für die Behandlung von Sicherheitsvorfällen |
| M 6.59/neu04 | (A) Festlegung von Verantwortlichkeiten bei Sicherheitsvorfällen |
| M 6.60/neu05 | (A) Festlegung der Meldewege |
| M 6.61/neu06 | (C) Eskalationsstrategie für Sicherheitsvorfälle |
| M 6.62/neu07 | (B) Festlegung von Prioritäten für die Behandlung von Sicherheitsvorfällen |
| M 6.67/neu08 | (Z) Einsatz von Detektionsmaßnahmen für Sicherheitsvorfälle |
| M 6.neu09 | (C) Festlegung der Schnittstellen der Sicherheitsvorfallbehandlung zur Störungs- und Fehlerbehebung |
| M 6.neu10 | (A) Einrichtung einer zentralen Kontaktstellen für die Meldung von Sicherheitsvorfällen |
| M 6.neu11 | (Z) Einführung in die Computer-Forensik |
| M 6.neu12 | (Z) Etablierung von Beweissicherungsmaßnahmen bei Sicherheitsvorfällen |
| M 6.neu13 | (Z) Schulung an Beweismittelsicherungswerkzeugen |
|---|---|
| M 6.neu14 | (A) Schulung der Mitarbeiter des Service Desk |
----------Ende Textkasten----------
Die Verzahnung der Sicherheitsvorfallbehandlung mit dem Notfallmanagement und dem Incident-Management bedingt die Einführung neuer Rollen. So gibt es innerhalb des Prozesses zur Behandlung von Sicherheitsvorfällen folgende Rollen:
Abbildung 2: Abbildung der neuen Maßnahmen auf den klassischen Incident-Management-Prozess
Als Fazit lässt sich zusammenfassen, dass die Maßnahmen des überarbeiteten Bausteins 1.8 "Behandlung von Sicherheitsvorfällen" beschreiben, welche Integrationsaspekte herangezogen werden sollten, um den ITIL-Incident-Management-Prozess auch an den Anforderungen des IT-Sicherheitsmanagements auszurichten. Die Chancen, Störungen und Sicherheitsvorfälle in einem umfassenden und standardisierten Incident-Management behandeln zu können, steigen, wenn die vorgeschlagenen Integrationsaspekte berücksichtigt werden. Der überarbeitete Baustein befindet sich gerade im letzten Expertenreview und wird voraussichtlich mit der nächsten Ergänzungslieferung der IT-Grundschutzkataloge veröffentlicht werden.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007#5, Seite 52
tag:kes.info,2007:art:2007-5-052
| 