Das Internet kann ohne Zweifel als Prototyp der Infrastruktur angesehen werden, �ber das wir in Zukunft einen immer gr��eren und wichtigeren Teil unserer Kommunikation abwickeln werden. Dieses "Netz der Netze" wird getrieben von einem scheinbar unerm�dlichen Kampf und einem nie ruhenden Bem�hen der die Technik aufbauenden Individuen, Gruppen und Unternehmen um einen annehmbaren Konsens als Basis f�r die zur Anwendung kommenden Protokolle, Anwendungen und mit dem Netzbetrieb verbundenen Grundregeln. Unverkennbar f�r jeden ist dabei die Lust an der Technik und deren Einsatz f�r eine globale Kommunikation.

Nie gez�hlte Sicherheitsl�cken werden tagt�glich im Netz entdeckt, ver�ffentlicht, ausgetestet, benutzt und diskutiert. Die Bandbreite ist schwierig in Worte zu fassen, einige L�cken sind sehr konkret auf bestimmte Anwendungen bezogen, andere liegen in den grundlegenden Protokollen des TCP/IP-Protokollstacks, wieder andere entstehen durch einen unsachgem��en Umgang mit den Systemen selbst oder durch die Unvorsichtigkeit der Verantwortlichen bzw. der Unerfahrenheit der Benutzer. Die Bedrohungen, die sich f�r diejenigen ergeben, die solche L�cken in ihren (ans Internet angeschlossenen) Systemen aufweisen, reichen von Denial-of-Service- Angriffen, �ber die unberechtigte Informationsgewinnung bis hin zum Zugang als einfacher Benutzer oder als Systemadministrator. Aber auch die Kommunikation bzw. die Nutzung des Netzes ist bedroht, fehlen zumeist jegliche Garantien f�r die Authentizit�t und Vertraulichkeit der damit in Zusammenhang stehenden Vorg�nge.

F�r jeden, der diese L�cken verfolgt, gibt es au�erdem einen reichhaltigen Fundus an Programmen, die die teils recht komplexen Vorg�nge zum Ausnutzen von Sicherheitsl�cken auf das Problem reduzieren, die Parameter beim Aufruf richtig zu setzen. Auch die Zusammenstellung verschiedener Programme zu einem Toolkit - au�er den Angriffswerkzeugen werden auch gleich Tarnprogramme zum Verschleiern erfolgreicher Angriffe bereitgestellt - tr�gt viel dazu bei, da� quasi jeder heute im Internet irgendwo ein Opfer finden kann.

Mit dem �bertragen einer nicht f�r den kommerziellen Einsatz bestimmten Technik wie dem TCP/IP-Protokoll und quasi allen darauf aufbauenden Protokollen und Anwendungen wurde eine existierende Infrastruktur �bernommen, weil sie eine globale Kommunikationsbasis darstellte. Allerdings mu� jetzt festgestellt werden, da� einerseits eine Absicherung nicht m�glich ist und andererseits auch keine ernstzunehmende Alternative entwickelt werden kann, weil sich die Kommunikationsbasis st�ndig ausdehnt und ihr Nutzen immer gr��er wird. Wie immer m�ssen sp�ter hinzugef�gte Sicherheitsma�nahmen schw�cher bleiben und ein totaler Aus- tausch ist auch nicht ohne weiteres machbar. Hier zeigt sich der Nachteil, wenn der quasi "kleinster gemein- samer Nenner" der Kommunikation zugleich das verbindende Element einer globalen Kommunikation bildet.

Sicherheit existiert immer in dem Spannungsfeld zwischen dem Aufwand des Angreifers und dem Aufwand des potentiellen Opfers, Angriffen aus dem Weg zu gehen oder diese abzuwehren. Genau wie im richtigen Leben kann man kaum allen Angriffsm�glichkeiten aus dem Weg gehen, ohne sich so abzugrenzen, da� man �berhaupt nicht mehr Teil der (Netz-)Gesellschaft ist. Und ebenfalls wie im richtigen Leben gibt es immer jemanden, der st�rker, schlauer oder hartn�ckiger ist. Zusammen mit der hohen Dynamik - was heute noch als "sicher" einge- sch�tzt wird kann morgen bereits Angreifern leichten Zugang bieten - darf sich niemand in Sicherheit wiegen.

Sicherheitsl�cken - und damit auch erfolgreiche Angriffe - geh�ren zur Realit�t, wie die Berichte und Warnungen der Computer-Notfallteams zeigen. Statt also sich allein auf die Sicherheitsma�nahmen zu konzentrieren, mu� jeder im Netz mit der Unsicherheit leben lernen. Das hei�t aber auch, das eventuell bestimmte Anwendungen gerade nicht in das Netz eingebracht werden oder auf bestimmte Integrationsma�nahmen verzichtet wird. Angriffe d�rfen nicht als etwas angesehen werden, die den Internet- Anschlu� insgesamt gef�hrden, sondern als etwas allt�gliches, mit dem "richtig" umgegangen sein will. Leider wird dies durch die bisherigen Konzepte des Risiko-Managements nicht unterst�tzt.

Knapp zehn Jahre sind inzwischen seit Gr�ndung des ersten Computer-Notfallteams in den USA (CERT Coordination Center, [email protected]) vergangen. Andere Organisationen, Unternehmen, Beh�rden und Netzbetreiber haben die Idee schnell aufgegriffen, zun�chst in den USA, dann auch in Europa und �berall dort, wo das Internet gro� genug wurde und die Vorf�lle weiterreichende Ma�nahmen notwendig machten und rechtfertigten. Computer-Notfallteams sind im weitesten Sinne Expertengruppen f�r die pragmatische Unterst�tzung bei konkreten Vorf�llen und Problemen. Deren Arbeit konzentriert sich dabei auf eine besondere Klasse von Problemen - n�mlich die der Rechner- und Netzwerksicherheit einer mehr oder weniger definierten Klientel, �blicherweise Constituency genannt. Dazu geh�ren unberechtigte Benutzer, die Weitergabe gesch�tzter Informationen, Sicherheitsl�cken sowie Schwachstellen, die eine mi�br�uchliche Benutzung erst erm�glichen, und alles andere, was f�r die Betreuten einen Vorfall oder sogar Notfall ausmacht. Zun�chst wurden solche Teams vielfach durch die freiwillige Arbeit von Administratoren erm�glicht. Nachdem aber Verantwortliche von den Vorteilen des Konzeptes und den erzielten Erfolgen �berzeugt wurden, begann mit der zunehmenden Unterst�tzung der Ausbau der Teams und die Konsolidierung ihrer T�tigkeiten. Das DFN-CERT (Deutsches Forschungsnetz - Computer Emergency Response Team, [email protected]) besteht z. B. seit Anfang 1993 als Notfallteam f�r Anwender, Administratoren und Manager. Dar�ber hinaus dient es internationalen Teams als prim�rer Ansprechpartner bei Problemen mit deutschen Rechnern.

Der Anlaß, über ein eigenes Notfallteam nachzudenken, ergibt sich zumeist durch Probleme mit konkreten Vorfällen oder durch ein Vorbild in Form eines anderen Notfallteams (dies gilt insbesondere für Hersteller, Netzbetreiber und Anwendergemeinschaften). Mitunter gibt es jedoch auch `politische� Gründe, ein Notfallteam aufzubauen, z. B. um mit der Konkurrenz mithalten zu können. Aber auch die empfundene Notwendigkeit, `vor Ort� über die Expertise verfügen zu müssen, ist Anlaß für die Gründung eigener Teams.

Die Gründe für ein eigenes Notfallteam sind technisch betrachtet jedoch vor allem in den folgenden Punkten zu sehen, die direkt mit Vorfällen in Zusammenhang stehen und dem Bereich des Risiko-Managements zuzuordnen sind. Computer-Notfallteams bieten Vorteile für die Durchführung vorbeugender Maßnahmen zur Vermeidung von Vorfällen, die schnelle und effektive Reaktion auf Vorfälle sowie die Koordination der damit in Zusammenhang stehenden Tätigkeiten bei Vorfällen und die Kooperation mit anderen Gruppen. Unternehmen, die dies bereits heute erkannt haben, sind z. B. Boeing, Motorola, General Electric, die mit der Vorfallsbearbeitung ihre etablierten Risiko-Management-Strukturen um eine neue Komponente erweitert haben.

In Hinblick auf die zu leistenden Tätigkeiten bei konkreten Vorfällen sind unabhängig von den technischen Details die folgenden Phasen zu unterscheiden:

• Initiierung: Durch die Erkennung eines Vorfalls oder die Benachrichtigung durch eine andere Stelle (z. B. andere betroffene Organisation, Notfallteam) wird die Bearbeitung eingeleitet.
• Evaluation: Prüfung der Authentizität eingegangener Benachrichtigungen und Meldungen.
• Informationssammlung: Vereinnahmung neuer bzw. ergänzender Informationen, die nach einer Evaluation bezüglich ihrer Authentizität, Korrektheit und Vollständigkeit bewertet und analysiert werden können.
• Analyse: Analyse der Ursachen, Folgen und Auswirkungen als Vorbereitung weiterer Maßnahmen und zur Überprüfung bisheriger Maßnahmen.
• Schadensbegrenzung: Begrenzung des Ausmaßes, die Verhinderung weiterer Schäden sowie der Fortsetzung des Vorfalls. Üblicherweise muß dafür bereits eine erste Analyse vorgenommen worden sein.
• Schadensbehebung: Behebung des eingetretenen Schadens. Dies gestaltet sich mitunter sehr schwierig, da z. B. nach der Erkennung eines Computer-Virus nicht bekannt ist, wie lange dieser schon aktiv war und welche Datenbestände tatsächlich bösartig verändert wurden, so daß zwei Fälle zu unterscheiden sind: Teilweise vs. komplette Wiederherstellung.
• Ursachenbehebung: Behebung der Ursachen, die zu dem Vorfall geführt haben, um weitere gleiche oder ähnliche Vorfälle zu verhindern.
• Informationsverteilung und Koordination: Zusammenarbeit mit weiteren Stellen und Weiterleitung verfügbarer Informationen, um an anderen Stellen gleiche oder ähnliche Vorfälle zu vermeiden bzw. weitergehende Maßnahmen (z. B. seitens eines Herstellers) zu ermöglichen. Durch die Nutzung von Ergebnissen und Informationen anderer Teams wird die eigene Arbeit verbessert bzw. erleichtert.

Über alle Vorteile hinaus, die durch ein eigenes Team bei der Vermeidung von Vorfällen und bei der Bewältigung auftretender Vorfälle erreicht werden, kann ein Mehrwert-Effekt erreicht werden:

• Die Existenz des Teams trägt bereits zur Bewußtseinsbildung im Sicherheitsbereich bei.
• Ausbildung und Training im Bereich Sicherheit können durch konkrete Beispiele aus der Praxis verbessert und unterstützt werden.
• Es gibt ein Verständnis für die lokalen Gesichtspunkte und vor allem entsprechende Vorkenntnisse.
• Das Team arbeitet in der gleichen Zeitzone, spricht die gleiche Sprache und kennt die Unternehmenskultur.
• Vertrauliche Details können mit Insidern besprochen werden.
• Genauere Daten über das tatsächliche Ausmaß der Bedrohung, der das Unternehmen durch Angriffe ausgesetzt ist. Verfolgung aktueller Trends und Informationen über aktuelle Sicherheitsprobleme.
• Unterstützung bei der Realisierung der `Best Current Practice� in Hinblick auf die Sicherheit.
• Dokumentation der Bereitschaft, Sicherheit zu gewährleisten, nach innen und außen.

Die durch ein Unternehmens-CERT sinnvoll zu erfüllenden Aufgaben lassen sich vier Bereichen zuordnen, wobei durchaus nicht jeder Bereich oder jede Aufgabe tatsächlich erfüllt werden muß:

• Präventive Aufgaben:

  Ziel der vorbeugenden Aufgaben ist es, sowohl die Erkennung und Reaktion auf Vorfälle und Probleme zu ermöglichen als auch Vorfälle überhaupt zu verhindern. Bei den vorbeugenden Aufgaben sind zu berücksichtigen:

  • Bearbeitung von Anfragen.
  • Verbreitung relevanter Informationen.
  • Unterstützung des Meldewesens von Vorfällen und Sicherheitsproblemen.
  • Funktion als Clearinghouse, um die Authentizität verbreiteter Informationen sicherzustellen.
  • Ausbildung und Training, um die Kenntnisse zu erweitern und praktische Abläufe einzuüben.
  • Test und Analyse von Systemen, um existierende Sicherheitslücken zu erkennen.
  • Erprobung oder Entwicklung von Werkzeugen, um Angriffe erkennbar zu machen und Sicherheitslücken zu schließen.

• Reaktive Aufgaben:

  Auf die Bearbeitung von Vorfällen wurde bereits kurz eingegangen. Ziel dieses Aufgabenbereiches ist es in jedem Fall, definiert auf Vorfälle und Probleme zu reagieren. Darüber hinaus soll mit den zur Verfügung stehenden Mitteln die Entstehung größerer Schäden sowie das Auftreten ähnlicher Vorfälle verhindert werden. Im einzelnen sind dabei zu berücksichtigen:

  • Bearbeitung von Vorfällen, um Schäden und Folgeschäden zu minimieren sowie die Ursachen zu identifzieren.
  • Bearbeitung von Sicherheitslücken, um potentielle Quellen für Vorfälle zu analysieren und zu beseitigen.
  • Bearbeitung von Angriffswerkzeugen, um potentielle Angriffsverfahren zu analysieren und erkennbar zu machen.
  Die Bearbeitung von Vorfällen ist sozusagen die Kernaufgabe eines Notfallteams, d. h. ohne diese spezielle Aufgabe wird es nicht als CERT glaubhaft sein.

• Security Quality Management:

  Ziel dieses Bereiches ist es, auf eine Verbesserung der Sicherheit hinzuwirken und die gewonnenen Erkenntnisse in andere Komponenten der Risiko-Management-Prozesse einfließen zu lassen. Bei der Realisierung können unterschiedliche Zielrichtungen verfolgt werden, wobei nicht das Team selbst die Arbeiten anderer etablierter Abteilungen übernehmen soll, sondern vielmehr durch Steuerung des Informations- und Kontrollflusses sichergestellt wird, daß alle Beteiligten ihre Expertise einbringen können und die für sie notwendigen Informationen erhalten:

  • Unterstützung des Continuity Planning, um auf neue Gefährdungen schneller reagieren zu können.
  • Unterstützung der Qualitätskontrolle, um die praktischen Erkenntnisse auch hierbei einfließen zu lassen.
  • Unterstützung der Revision, um die Aufdeckung von Mißständen zu verbessern.
  • Mitwirkung bei der Risiko-Analyse, um auf die Erfahrungen bei der schwierigen Bewertung zurückgreifen zu können, und anhand konkreter Fallstudien realistische Zahlen einfließen zu lassen.
  • Mitwirkung bei der Security Policy, um auch hier eine pragmatische Orientierung an die Realität erreichen zu können.
  • Angebot von Consulting-Leistungen, um weiteren Bedarf decken zu können, der durch die übrigen Aufgabenbereiche nicht abgedeckt wird.

• Unterstützungsaufgaben:

  Ziel dieser Aufgaben ist es, die Erfüllung aller anderen Aufgaben zu erleichtern bzw. zu vereinfachen. Dazu gehört eventuell auch, in Ermangelung geeigneterer Infrastrukturen vorübergehend bestimmte Dienste anzubieten, die für die Erfüllung der eigenen Aufgaben zwingend notwendig sind. Dabei sind insbesondere folgende Aufgaben zu berücksichtigen:

  • Schutz der eigenen Systeme.
  • Authentizität und Vertraulichkeit der Kommunikation.
  • Entwicklung von Werkzeugen.
  • Forschung und Analysen.

Nicht zuletzt kann das Team durch andere Teams wertvolle Unterstützung erlangen oder ist für die Zusammenarbeit bei bestimmten Aspekten von Vorfällen (z. B. Strafverfolgung) auf andere Organisationen oder Gruppen angewiesen. Durch die Pflege geeigneter Liaisons kann die Effektivität des Teams erheblich gesteigert werden. FIRST als weltweiter Dachverband ist nur ein Beispiel.

Somit gehen die Aufgaben eines Notfallteams im Unternehmen möglicherweise sehr weit über die koordinierenden Aufgaben regionaler oder unternehmensübergreifender CERTs hinaus, die sich vor allem auf die Beschaffung, Aufbereitung und Verteilung von Informationen konzentrieren; Aufgaben, die im Unternehmen auch erbracht werden müssen, aber nicht ausreichen. Durch den Aufbau eines eigenen CERTs wird damit zusätzlich für andere - Notfallteams, Unternehmen, Betroffene, etc. - eine Ansprechstelle geschaffen, so daß hier auch die Öffentlichkeitsarbeit miteinbezogen werden muß, denn nicht alle Anfragen werden technischer Natur sein, sondern auch Fragen nach Vorfällen, Erfahrungen bzw. Schäden beinhalten.

Abhängig von den Anforderungen in bezug auf potentielle und konkrete Vorfälle sowie das Maß an Unterstützung etc., gibt es verschiedene Vorgehensweisen, die zu unterschiedlichen internen Strukturen führen:

1. Nutzung der Informationen existierender CERTs:

   Statt des Aufbaus einer eigener Gruppe wird dafür gesorgt, daß die verfügbaren Informationen existierender CERTs in den internen Informationsfluß aufgenommen werden. Dies darf sich allerdings nicht auf die Subskription eines verantwortlichen Mitarbeiters (z. B. den Verantwortlichen für den Firewall) auf einer Mailing-Liste beschränken; alle, die für die Sicherheit der Rechner und Netzwerke und damit in Zusammenhang stehende Prozesse wie die Risiko-Analyse etc. verantwortlich sind, müssen diese Informationen (eventuell geeignet aufbereitet) erhalten.

2. Festlegung von Verantwortungsbereichen für konkrete Vorfälle:

   Da alle Sicherheitsmaßnahmen darauf ausgerichtet sind, Vorfälle zu verhindern, wird der Realität eintretender Vorfälle nur unzureichend Rechnung getragen. Selbst wenn ein Angriff durch einen wirksamen Firewall abgewehrt wird, ist doch die Information, daß ein solcher Angriff stattgefunden hat, wichtig. Die Festlegung von Richtlinien in bezug auf Angriffe und Vorfälle sowie die dabei einzuleitenden Maßnahmen versetzt das Unternehmen in die Lage, geeignet zu reagieren und solchen Fällen nachzugehen, um auszuschließen, das andere Angriffe nicht erkannt oder abgewehrt wurden und ein Schaden für das Unternehmen eintritt. Aufgrund der Zuordnung der dazu notwendigen Aufgaben zu bereits übertragenen Aufgaben der Systemadministration, Planung, etc. wird das jeweilige Aufgabenprofil ergänzt, ohne daß eine Stelle geschaffen wird, die sich als eigenständige Einheit hauptverantwortlich mit Vorfällen beschäftigt.

3. Schaffung eines CERTs:

   Unabhängig davon, ob ein zentrales Team existiert oder mehrere dezentral tätige Mitarbeiter eine Organisationseinheit bilden, ist die Zusammenfassung der Verantwortungsbereiche für die oben im Einzelnen besprochenen Aufgaben der Grundstock für ein `eigenes� CERT. Wichtig ist, daß hierdurch die Vorfallsbearbeitung institutionalisiert wird und dabei auch Verantwortung und Authorität neu geregelt werden kann. Gerade in Hinblick auf eine bessere Betreuung der Mitarbeiter sowie den Aufbau von Kontakten mit anderen Notfallteams ist dies erforderlich, um konkrete Ansprechpartner zu haben, die über längere Zeiträume Kontinuität und Vertrauen schaffen. Der größte Vorteil zur Struktur 2, bei der nur die Verantwortung für Arbeiten bei Vorfällen geregelt wird, ist hier, daß die betroffenen Mitarbeiter eine Anlaufstelle erhalten, bei der sie um Rat fragen können und durch die sie weitestgehende Unterstützung erhalten. Außerdem werden neue Aufgaben, wie die Empfehlung vorbeugender Maßnahmen und die Weiterleitung wichtiger Informationen, als Erweiterungen hinzukommen, die nicht ohne weiteres ohne das Team als neue Komponente des Risiko- und Sicherheitsmanagements erbracht werden können.

4. Hierarchisierung von Verantwortungsbereichen für CERT-Aufgaben:

   Bei sehr großen oder in eigenständigen Bereichen operierenden Abteilungen/Zweigen aufgeteilten Unternehmen wird es sehr schwierig, mit nur einem zentralen Notfallteam alle Belange abzudecken und gleichzeitig den unterschiedlichen Anforderungen und Gegebenheiten Rechnung zu tragen. Hier bietet es sich an, für das Unternehmen eine zentrale Anlaufstelle zu schaffen, die den Kontakt zwischen `innen� und `außen� koordiniert und erbringt. Innerhalb der einzelnen Organisationseinheiten kann es dann entsprechende Teams geben, die die dort notwendig werdenden Maßnahmen bei Vorfällen einleiten und durchführen. Mit Hilfe gegenseitiger Absprachen kann dann auch gewährleistet werden, daß Mitarbeiter anderer Abteilungen für Notfälle zur Verfügung stehen, die das Unternehmen an sich bedrohen oder einzelne Abteilungen überfordern.

Jede der vier möglichen Strukturen baut prinzipiell auf den vorhergehenden auf und es ist auch anzunehmen, daß sich solche Strukturen mit der Zeit verändern, indem neue Aufgaben hinzukommen oder das Bewußtsein für die Notwendigkeit einer effizienteren Lösung wächst. Es soll an dieser Stelle auch davor gewarnt werden, daß allein durch den Aufbau einer Struktur diese bereits effektiv arbeiten kann. Erfahrungen aus dem Alltag existierender CERTs haben immer wieder gezeigt, daß es auf die betreuten Administratoren und Manager ankommt, denn diese müssen mit ihren Problemen offen an das Team herangehen und vor allem Vorfälle melden. Dies geht jedoch letztendlich nur mit Vertrauen, selbst wenn es innerhalb eines Unternehmens verbindliche Anweisungen gibt. Dieses Vertrauen muß sich das Team zunächst erarbeiten und später immer wieder durch sein Handeln erneuern, denn nur dann werden Administratoren und Benutzer Vorfälle berichten.

Wenn Angriffe entdeckt werden, kommt der Hinweis nur all zu oft von au�en, d. h. andere Organisationen oder Personen finden Hinweise, die sie weitergeben, um weitere Betroffene zu warnen. Eine solche Weitergabe ist, sofern nicht innerhalb eines Unternehmens interne Regelungen vorliegen, freiwillig und findet daher nicht immer statt. Wie auch Insider-Angriffe aus der Furcht vor einem Image-Verlust oft verschwiegen werden, werden Angriffe externer Individuen ebenfalls nicht gerne publik gemacht. Dies ist in verschiedener Hinsicht problematisch:

• Andere Betroffene werden nicht gewarnt und sind somit nicht in der Lage, geeignete Ma�nahmen zu ergreifen, um Sch�den zu minimieren oder weitere Angriffe zu verhindern.
• Da das Problem nicht offengelegt wird, kann auch keine geeignete Unterst�tzung erfolgen.
• Es sind nur sehr schwer Aussagen �ber die Situation im Netz hinsichtlich der Anzahl und Art von Angriffen durch geeignetes Datenmaterial zu untermauern, so da� keine bessere Ausrichtung von Empfehlungen bzgl. Sicherheitsma�nahmen m�glich ist.
• Die �ber Vorf�lle zur Verf�gung stehenden Informationen werden eingeschr�nkt, so da� weitergehende Analysen erschwert werden.

Einen Kompromi� stellt das Angebot von Computer-Notfallteams dar, weitere Betroffene ohne Nennung der Herkunft der urspr�nglichen Informationen zu alarmieren. Besonders Unternehmen nutzen dies oft. Bei der anonymen Weitergabe von Informationen �ber Angriffe bzw. Angriffsversuche wird alles direkt auf die Herkunft des Angriffs hinweisende Informationsmaterial unterdr�ckt. In der Realit�t zeigt sich jedoch, da� im Zuge der Analysen die Betroffenen in der Mehrzahl der F�lle auch das Unternehmen identifizieren, woher die Angriffe kamen und - als weiteren Betroffenen - nat�rlich direkt informieren bzw. die Adressen an ein Computer-Notfallteam weitergeben. Von daher bleibt der Nutzen einer anonymen Weitergabe begrenzt. Aber auch wenn deswegen von einer Meldung abgesehen wird, sollte bedacht werden, da� alle Beweise bereits auf anderen Systemen vorliegen. Stellt sich dann sp�ter heraus, da� bekannte Informationen nicht weitergeleitet wurden, kann dies zu Schadensersatzklagen oder zu anderen negativen Ereignissen f�hren.

F�r ein Computer-Notfallteam ist es ungeachtet solcher Fragestellungen "lebenswichtig", �berhaupt Informationen zu erhalten und dazu mu� die Kooperationsbereitschaft aller gewonnen werden. �blicherweise ist dies ein Proze�, der am Anfang nur langsam Erfolg zeigt und durchaus ein Jahr andauern kann, bevor nach und nach immer mehr Mitglieder der Constituency bereit sind, "ihrem" Computer-Notfallteam Vorf�lle zu melden. Der Aufbau eines Vertrauensverh�ltnisses ist eben ein kontinuierlicher Proze�, der weiter am Leben gehalten werden mu�, wenn das Computer-Notfallteam auch in Zukunft seine Funktion erf�llen und sein Ziele erreichen will.

Durch das erworbene Vertrauen k�nnen Computer-Notfallteams als Mittler in offenen Netzen agieren, da sich gerade die anf�ngliche Kommunikation zwischen zwei Organisationen - die eine von der anderen angegriffen - am Anfang sehr schwerf�llig entwickelt und problematisch ist. Eine weitere Facette der Vertrauensstellung ist ebenso das Ma� des Informationsaustausches, durch den das Computer-Notfallteam sehr weitgehend �ber Details informiert wird.

Die sicherlich wichtigsten Teilaspekte des "Incident Response" im Rahmen einer gro�en Anwendergemeinschaft stellen die Kommunikation mit allen Beteiligten, um alle Informationen an die richtigen Ansprechpartner weiterzuleiten, sowie die Koordination aller weiterer Aktionen wie z. B. der Analyse der Angriffsmethoden, der ausgenutzten Sicherheitsl�cken etc., dar. Wie bereits ausgef�hrt, sind diese �bergeordneten Aufgaben in Form von Computer-Notfallteams institutionalisierbar, wodurch ihr Dienstleistungsangebote quasi Bestandteil der Infrastruktur wird, die allen Netzteilnehmern - einmal ungeachtet der einzelnen Zugangsmodalit�ten - zur Verf�gung stehen. Sofern die Netzteilnehmer die Warnungen aufnehmen und die Informationsm�glichkeiten nutzen, k�nnen sie selbst die Sicherheit der eingesetzten Systeme verbessern und somit Vorf�llen vorbeugen. Durch das zunehmende Bewu�tsein und das vermittelte Wissen werden mehr Vorf�lle erkannt und k�nnen mehr Informationen �ber Angriffe weitergeleitet werden. Durch die Aufarbeitung dieser Informationen werden wiederum Trendanalysen, Warnungen vor neuen Angriffstechniken, etc. m�glich. Genau wie die Constituency nie aufh�ren darf, sich den wechselnden Anforderungen der Unsicherheit zu stellen, darf ein Computer- Notfallteam nie aufh�ren, sein Informationsangebot anzupassen und zumindest mit der Entwicklung Schritt zu halten.

Obwohl alle Computer-Notfallteams immer auch auf eine Verbesserung der Sicherheit hinarbeiten, betont ihre Arbeit eher den Aspekt, richtig mit Vorf�llen und Angriffen umzugehen. Damit wird indirekt der Aspekt der "Survivability" (�berlebensf�higkeit) �ber den Aspekt der Sicherheit gesetzt. W�hrend Sicherheit eben nicht 100% gew�hrleistet werden kann, mu� die Kontinuit�t - eventuell nur das �berleben - sichergestellt werden. Ziel in Hinblick auf Angriffe ist es dabei immer, neben einer m�glichst umfassenden Abwehr aller m�glichen Bedrohungen im Fall eines gelungenen Angriffs (oder anderer Probleme) die Funktion und das gesamte Sicherheitsgef�ge m�glichst wenig beeinflu�t zu erhalten bzw. wiederherzustellen. Dies f�hrt zu der folgenden Definition:

�berlebensf�higkeit (Survivability): F�higkeit eines Systems (im weitest m�glichen Sinne), seine Aufgabe (Mission) auch dann zeitgerecht auszuf�hren, wenn es angegriffen wird oder wenn Fehler bzw. Unf�lle eintreten.

Das CERT Coordination Center, als erstes CERT seit 1988 an dem Software Engineering Institute in Pittsburgh, PA, lokalisiert, hat inzwischen diesen Paradigmenwechsel vollzogen und ist heute Teil des Programms "Network System Survivability". Au�er der CERT-Dienstleistung sind darin Forschungs- und Entwicklungsaufgaben sowie Teams zur Unterst�tzung von Organisationen bei der Evaluation der Systeme (Security Evaluation) sowie zur schrittweisen Verbesserung (Security Improvement) zusammengefa�t.

Die Motivation, den neuen Begriff der �berlebensf�higkeit �berhaupt einzuf�hren, kann nur im Gesamtkontext der Diskussion �ber die Sicherheit nationaler und internationaler Infrastrukturen gesehen werden. Allen Verantwortlichen m��te inzwischen klar geworden sein, da� allein aufgrund der Vielzahl der Systeme, deren unterschiedlichen Architekturen, Anwendungen, Protokollen und Sicherheitseigenschaften sowie der gewollten Offenheit, m�glichst weitreichende und vielf�ltige Kommunikationsm�glichkeiten zu bieten, die daraus entstehenden Netze unsicher bleiben m�ssen. Allerdings kann auf eine gewisse Minimalfunktion der in die Netze eingebundenen kritischen Elemente bzw. Infrastrukturen seitens der Gesellschaft nicht verzichtet werden. Diese m�ssen konsequenterweise in jedem Fall erhalten bleiben:

Kritische Infrastrukturen (Critical Infrastructures): Alle Dienstleistungen, die so wichtig f�r eine Gemeinschaft sind, da� eine fehlende Verf�gbarkeit deren Fortbestand oder weitere Entwicklung gef�hrden.

Andere Definitionen weisen aus offensichtlichen Gr�nden vor allem auf Einfl�sse auf die �konomische bzw. nationale Sicherheit hin, so z. B. Anweisungen des amerikanischen Pr�sidenten (siehe Executive Order No. 13010). Aber Beispiele f�r viel direkter unsere Gesellschaft bestimmende Infrastrukturen finden sich genug im t�glichen Leben, angefangen von der Wasserversorgung bis hin zu Banktransaktionen, Flugverkehr und das Telefonnetz, auf das Polizei, Feuerwehr, Notrufe, etc. basieren.

Die Bedrohung dieser Infrastrukten selbst ist dabei nicht neu. Neu ist vielmehr, da� durch die Integration und Vernetzung Angriffe m�glich werden, die eben keinen physikalisch sichtbaren und anwesenden Angreifer erfordern. Die gleichen Angriffe, die heute im Internet erfolgreich sind, k�nnen dann sofort gegen Teile solcher Infrastrukturen eingesetzt werden, wenn diese auf der gleichen Technik basieren und die Sicherheitsma�nahmen L�cken aufweisen.

Durch das erheblich h�here Potential f�r Sch�den auf gesellschaftlicher und / oder unternehmerischer Ebene mu� auch die Einsch�tzung der Angreifer �berdacht werden. Im Internet-Bereich �berwiegt in jedem Fall nach wie vor die Masse der Angreifer, die individuell vorgehen und eigene Ziele verfolgen: Insider, Cracker und Cracker-Gruppen. In Hinblick auf die Gesellschaft insgesamt und einzelne Organisationen sind jedoch eher die Angreifer zu f�rchten, die sich bestimmten �bergeordneten Zielen verpflichtet haben und diese strukturiert und organisiert verfolgen: Organisierte Kriminalit�t, Industriespionage und Terroristen. Es kommt noch der Bereich der nationalen Sicherheit hinzu, wo Geheimdienste und Anstrengungen des Milit�rs im Bereich "Information Warfare" zu beachten sind, die nie ohne Auswirkungen auf die Gesamtgesellschaft bleiben k�nnen.

Bereits seit mehreren Jahren wird diese Problematik intensiv in Amerika diskutiert. Dies f�hrte - neben verschiedenen anderen Projekten und Organisationen - �ber verschiedene Stufen schlie�lich zur Gr�ndung eines National Infrastructure Protection Center (NIPC), das im FBI angesiedelt wurde. Seine Funktion ist vielf�ltig:

• Schutz der kritischen Infrastrukturelemente (Erkennung von Angriffen, Abschreckung, Analysen, etc.)
• Unterst�tzung bei der Bek�mpfung internationaler Angriffe
• Unterst�tzung bei Ermittlungsarbeiten des FBI
• Unterst�tzung anderer Agencies
• Verteilung von Informationen durch eine rund um die Uhr zur Verf�gung stehende Warnzentrale
• Analysen und Informationsaustausch mit anderen Organisationen, die �hnliche oder gleiche Informationen verarbeiten bzw. analysieren
• Funktion eines Clearinghouses f�r Informationen �ber Sicherheitsl�cken, Angriffswerkzeuge, etc.
• Training und Ausbildung von Mitarbeitern anderer Ermittlungsbeh�rden, aber auch der privaten Industrie

Bedeutend ist in diesem Zusammenhang, da� das NIPC wesentliche Funktionen der Computer-Notfallteams integriert hat, diese aber mit den typischen Aufgaben einer Ermittlungsbeh�rde kombiniert. Interessant ist auch, da� Aussagen wesentlicher Schl�sselpersonen deutlich machen, da� eine enge Kooperation mit allen gesucht wird, die bei dieser Aufgabe Beitr�ge leisten k�nnen, u. a. wiederum die existierenden Computer-Notfallteams. Erst die Zeit wird zeigen, ob sich die Hoffnungen auf eine gute Zusammenarbeit verwirklichen, doch schon heute zeigen sich erste Ver�nderungen ab. In einer der letzten CERT Warnungen des CERT Coordination Centers wurden Betroffene ausdr�cklich gebeten, sich an das FBI/NIPC zu wenden, wenn sie Opfer des beschriebenen Angriffs geworden sind. Au�erdem wurde darauf hingewiesen, da� in diesem Fall bereits ermittelt wird, obwohl davon auszugehen ist, da� die T�ter sicherlich alle CERT-Warnungen verfolgen.

Das FBI/NIPC sieht sich selbst in einer komplement�ren Rolle zu den existierenden Computer-Notfallteams, deren Partnerschaft es sucht. Der Schutz der nationalen Infrastruktur steht im Vordergrund und damit vor allem die aus Sicht der Ermittlungsbeh�rden und Regierung notwendigen Ma�nahmen. Aber es versteht sich gleichfalls als Informationsvermittler zwischen dem �ffentlichen Bereich, den die Constituencies der Computer- Notfallteams darstellen, und den Ermittlungsbeh�rden bzw. der Regierung mit dem Ziel, vorhandene Informationen f�r neue Kreise zug�nglich zu machen bzw. zwischen allen Bereichen auszutauschen. Auch die internationale Zusammenarbeit hat sich das Center auf die Fahnen geschrieben, doch auch hier ist abzuwarten, ob dies wirklich m�glich gemacht wird oder sich alles durch die Fragestellung der "Nationalen Sicherheit" als so schwierig erweist, da� praktisch kein Nutzen �brig bleibt.

Das Konzept der Incident Response Teams hat sich �ber die Jahre weiterentwickelt. Zun�chst als einzelne Teams f�r Netzwerkgemeinschaften aufgebaut, wird die Funktion des Incident Response f�r die Bew�ltigung von Vorf�llen immer wichtiger. Folgerichtig mu� diese Funktion in das Risiko-Management von Organisationen und Unternehmen Eingang finden, verschiedene Ans�tze dazu wurden vorgestellt.

Die Auseinandersetzung mit Vorf�llen und die Einsicht, da� es immer wieder neue Angriffe, neue Opfer geben wird, hat einen Proze� eingeleitet, durch den das Konzept des Incident Response in eine neue Perspektive gesetzt wird. Die Sicherstellung der �berlebensf�higkeit kann hier als Leitgedanke f�r die Zielsetzung des Konzepts an sich gesehen werden. Davon ausgehend werden aber auch neue Anstrengungen entwickelt, z. B. der Proze� des Security Improvements, wo die kontinuierliche Verbesserung der Sicherheit im Vordergrund steht, um die L�cke zwischen Baseline Protection und den viel zu komplexen Risiko-Analysen zu schlie�en.