In den nun mehr neun Jahren seit Gründung des ersten Computer-Notfallteams in den USA (CERT Coordination Center, cert@cert.org) haben sehr schnell andere Organisationen, Unternehmen, Behörden und Netzbetreiber die Idee aufgegriffen, Expertengruppen für die pragmatische Unterstützung bei konkreten Vorfällen und Problemen zusammenzustellen. Die 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) 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.

Zahlreiche Teams im internationalen Raum haben sich zu einem Dachverband, dem `Forum of Incident Response and Security Teams´ (kurz FIRST, http://www.first.org/) zusammengeschlossen [FIRST 1997]. Sehr schnell hatten sie erkannt, daß kein einzelnes Team alle Aufgaben allein lösen kann. Außerdem sind aufgrund der weltweiten Netze die Probleme international oder betreffen zumindest die Einflußbereiche mehrerer Unternehmen, Netze, etc. Dies verhindert eine zentrale Abwicklung aller Aufgaben und ist für viele praktische Probleme bei der Vorfallsbearbeitung verantwortlich. Die Aufgaben, die notwendig sind, um bei Problemen der Rechner- und Netzwerksicherheit Hilfe und Unterstützung anbieten zu können, gestalten sich durch Computer-Notfallteams (egal ob national oder intern) erheblich einfacher, wobei nicht nur an mögliche Zeit- oder Sprachbarrieren zu denken ist. Die Unterschiede in der Gesetzgebung, dem Datenschutz und internen Policies machen kompetente Teams notwendig, die sich so an `ihre´ Constituency mit gezielten Vorschlägen und Ratschlägen wenden können und für andere Teams die Schnittstelle zu dieser Constituency darstellen. Daher wird durch existierende Teams und FIRST insbesondere der Aufbau neuer Teams unterstützt. Besonders interessant ist in diesem Zusammenhang die Entwicklung in Europa, wo von der Vereinigung der nationalen Forschungsnetze genau dieser Gedanke aufgegriffen wurde, um die Gründung nationaler Teams voranzutreiben. Dies zeigt heute die ersten Erfolge: Nachdem sich 14 europäische Teams im November 1994 trafen, um ihre weitere Arbeit zu koordinieren, wurde die Idee eines europäischen Koordinierungszentrums vorangetrieben. Seit Anfang 1997 wird diese freiwillige Zusammenarbeit nunmehr in einem Projekt bei JANET, dem englischen Forschungsnetz, fortgeführt, in dessen Rahmen ein solches Zentrum für die europäischen Teams tatsächlich geschaffen wird.

Heute sind Computer-Notfallteams und ihre Informationsangebote aus dem Alltag der Netze nicht mehr wegzudenken. Bis vor etwa drei Jahren wurde das `Netz´ hauptsächlich im wissenschaftlichen Umfeld genutzt, wobei Anwender und Administratoren sich auf die Funktionalität der Systeme und Anwendungen konzentrierten. Die Sicherheit der Systeme spielte bei den Betreibern eine untergeordnete Rolle, war doch eine unberechtigte Benutzung selten mit einem (direkt erkennbaren) größeren Schaden verbunden. Mit der zunehmenden kommerziellen Nutzung, dem neuen Bewußtsein über die Werte von Informationen sowie der Infrastruktur und den Privatpersonen, die ebenfalls ins Netz drängen, hat sich diese Situation jedoch total verändert. Das für die Sicherheit der Systeme notwendige Expertenwissen ist nur selten verfügbar. Fazit ist, daß die Mehrzahl der Systeme heute im Netz potentiell zugänglich sind, wenn ein Cracker einen unberechtigten Zugriff versucht. Ist der erste Einstiegspunkt erst erreicht, findet sich relativ leicht Zugang zu weiteren Systemen. Der Angreifer kann so relativ geschützt vor einer Identifizierung weitere Angriffe durchführen. Diese Bedrohung darf nicht mit dem Hinweis auf die Insider-Problematik heruntergespielt werden, die nach wie vor weitgehend unverändert bestehen bleibt. Jedoch kommen die vielfältigen Möglichkeiten externer Angriffe hinzu, die bisher ohne den Anschluß an das Internet undenkbar gewesen waren. Gerade die Industriespionage und Sabotage durch Kontrahenten werden damit ohne Insider-Kenntnisse möglich.

Es ist offensichtlich, daß Computer-Notfallteams in solchen Situationen helfen können, da sie Informationen sammeln und diese den Administratoren in einer Form zu Verfügung stellen, die leicht verständlich die Probleme offenlegt. Es werden Gegenmaßnahmen vorgeschlagen, die ergriffen werden können, ohne daß der Administrator selbst zum Experten werden muß. Durch die Meldung von Angriffen und Angriffsversuchen werden auch Informationen über potentiell betroffene Systeme an zentraler Stelle gesammelt, geordnet und nach der Aufbereitung weitergeleitet. Durch die Information der Betroffenen wird ein weiterer Nutzen erreicht: Die Administratoren werden (nach Erfahrungen der Notfallteams in über 75% der Fälle) auf ein ihnen noch unbekanntes Problem aufmerksam. Benutzer, die nur etwas `ausprobieren´ wollten, werden entdeckt und können über die Folgen ihrer unbedachten Handlungen aufgeklärt werden. Sehr viel häufiger werden aber Systeme entdeckt, die selbst angegriffen und übernommen wurden. Eine weitere wichtige Aufgabe von Computer-Notfallteams ist die Sammlung von neuen Informationen und die Klärung bzw. Aufarbeitung der aufgeworfenen Probleme mit den Betroffenen der Constituency und anderen Gruppen, vor allem mit anderen Teams, Herstellern, Netzwerkbetreibern und Ermittlungsbehörden.

Die Bezeichnung `Notfallteam´ wird oft mißverstanden, da er nur einen Aspekt der Arbeit betont: die Reaktion auf Vorfälle. Allerdings hat sich gezeigt, daß bei einer immer höheren Zahl von Vorfällen (die Zahl verdoppelt sich etwa jedes Jahr) die Probleme nicht allein durch den personellen Ausbau der Teams in den Griff zu bekommen sind. Dazu kommt, daß die Komplexität der Angriffe immer weiter zunimmt und durch Automatisierungen zig-tausende von Rechnern gleichzeitig angegriffen werden können. Stattdessen muß Vorfällen vorgebeugt werden, bevor Angriffe erfolgreich sein können und Schäden eintreten Aus diesem Grunde werden Hilfen angeboten, um Administratoren und Manager bei der Realisierung vorbeugender Maßnahmen zu unterstützen. So werden neue Angriffe nicht nur abgewehrt, sondern überhaupt erst erkennbar. Damit können dann auch die Systeme identifiziert werden, von denen Angriffe ausgehen, um so die dort verantwortlichen Betreiber und Administratoren anzusprechen und weitergehende Maßnahmen einzuleiten. Um die gewonnenen Erfahrungen und Erkenntnisse weiterzugeben, bieten sich Tutorien und Workshops an. Dadurch wird nicht nur der Kontakt zu der betreuten Zielgruppe erheblich verbessert, sondern auch die Bereitschaft zur Annahme von vorbeugenden Maßnahmen und das Bewußtsein für deren Notwendigkeit wird deutlich erhöht.

Da die meisten Teams im allgemeinen keine Weisungsbefugnis gegenüber der betreuten Zielgruppe haben, beruht der Erfolg eines Teams auf dessen Kompetenz und das Vertrauen der Zielgruppe. Damit ist klar, daß das Team immer wieder seinen Nutzen unter Beweis stellen und seine Arbeit auf den betreuten Kreis abstimmen muß. Weiteren Einfluß auf die Gestaltung der Tätigkeiten haben natürlich auch die Organisationsform und -struktur sowie die zur Verfügung stehenden Ressourcen.

Der Gedanke, Administratoren und Managern bei der Bewältigung von Vorfällen der Rechner- und Netzwerksicherheit zu unterstützen, löst natürlich nicht sofort die diesen Vorfällen zugrundeliegenden technischen Probleme. Jedoch bieten Computer-Notfallteams den betroffenen Einrichtungen und Institutionen Unterstützung bei der Minimierung von Schäden, bei der Verhinderung neuer Vorfälle und bei der Abwehr von Angriffen. Durch die Kommunikation und Kooperation der Notfallteams untereinander wird das Schweigen zwischen unterschiedlichen Zielgruppen gebrochen, das bisher oft verhindert hat, daß notwendige Informationen weitergeleitet und Administratoren gewarnt wurden. Außerdem werden die gewonnenen Informationen über neue Sicherheitslücken an die Hersteller weitergeleitet, so daß diese entsprechende Patches oder Workarounds bereitgestellen können. Insgesamt wird somit die Sicherheit aller an das Netz angeschlossenen Einrichtungen erhöht.

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.

Vorfälle wie der Internet-Wurm oder der KGB-Hack haben in der Öffentlichkeit große Aufmerksamkeit erreicht. Solche dramatischen Vorfälle zeigen sehr deutlich, welche enormen Schadenspotentiale bestehen. Im alltäglichen Betrieb von Computern und Netzwerken gibt es jedoch erheblich mehr Vorfälle, die auch ohne großes Aufsehen die Verantwortlichen beschäftigen und drastische Folgen für die Betroffenen haben können. Immer wieder gibt es neue Einbrüche und werden neue Sicherheitslücken entdeckt. Effiziente Methoden der Reaktion sind in jedem Fall erforderlich, um einen möglichen Schaden zu vermeiden, entstandene Schäden zu beheben bzw. zu minimieren und weitere Angriffe zu verhindern und andere Betroffene ebenfalls zu warnen.

Die Herausforderung in Deutschland besteht nun darin, in Kenntnis dieses Konzepts die Vorteile von Computer-Notfallteams zu erkennen und durch entsprechende Maßnahmen die sich durch sie bietende Chance zu nutzen. Gewarnt werden muß allerdings vor isolierten Bemühungen und Bestrebungen. Als erster Schritt reicht es bereits aus, das Informationsangebot existierender Teams in den lokalen Kommunikationsfluß zu integrieren, um die eigenen Mitarbeiter auf Probleme aufmerksam zu machen und aktuell zu informieren. Auf der anderen Seite wird sich aus der Analyse der eigenen Anforderungen auch für Unternehmen die Notwendigkeit eines eigenen Teams ergeben, z. B. wenn es sich um Banken, große Unternehmen oder Netzbetreiber handelt.

Der Aufwand für den Aufbau eines eigenen Teams sollte dabei nicht unterschätzt werden. Allein mit ein oder zwei Mitarbeitern, die Anrufe entgegennehmen und ein paar Informationen per Rundschreiben verteilen, ist es in den meisten Fällen nicht getan, vor allem, wenn es sich um ausgedehnte Computer-Netze mit Anschlüssen an das weltweite Netz handelt. Ausgehend von der Idee und der nachgewiesenen Notwendigkeit müssen Anforderungen aufgestellt und die Ressourcen bereitgestellt werden. Das neue Team muß so zusammengestellt werden, daß es sich in die bereits bestehenden Strukturen einfügt. Alternativ könnte es auch Aufgabe des Teams sein, geeignete Strukturen, die auch die Erkennung, Meldung und Bearbeitung von Vorfällen erlauben, erst zu entwickeln und aufzubauen.

Existierende Teams helfen hierbei, indem sie ihr Fachwissen sowie ihre Erfahrungen mit dem Aufbau einer solchen Infrastruktur und die einzelnen Tätigkeiten weitergeben. Darüber hinaus unterstützen sie die Zusammenarbeit mit anderen Teams sowie die Einführung bei FIRST. Allerdings gibt es noch kein Patentrezept für den Aufbau neuer Teams und die Ressourcen existierender Teams für unterstützende Beratungen sind in der Regel begrenzt. Auch stellt die Ausbildung des Personals ein offenes Problem dar, denn die einzigen, durch Training on the Job ausgebildeten Personen arbeiten bei aktiven Teams.

Ende des Jahres wird es zum ersten Mal ein Handbuch geben, das die Erfahrungen dreier Teams (CERT Coordination Center, USA; CERT-NL, NL, DFN-CERT, DE) zusammenfaßt. Es bietet einen Anhalt für interessierte Organisationen und Unternehmen, welche Gesichtspunkte beim Aufbau neuer Teams zu beachten sind und welche Fehler es zu vermeiden gilt. Zusammen mit anderen verfügbaren Tutorials und Dokumenten erlaubt dies mit Besuchen bei anderen Teams den Einstieg in die Planungs- und Aufbauphase. Mehr Informationen über diesen Prozeß sind direkt beim Verfasser zu erhalten, der auch einer der drei Autoren des CERT-Handbuches ist.

1. [FIRST 1997] Forum of Incident Response and Security Teams - Operational Framework / Members of FIRST. - Juni 1997.
2. [GRIP 1997] Guidelines and Recommendations for Incident Processing / Members of the IETF WG GRIP. [Charter, Meeting Minutes und verschiedene Drafts elektronisch verfügbar: http://www.kossakowski.de/grip/]
3. [Kossakowski 1994] The DFN-CERT Experience - Building up a new CERT within Europe / Klaus-Peter Kossakowski. - DFN-CERT. - Hamburg. - Mai 1994. [Vortrag auf der INET'94/JENC5 1994 in Prag.]
4. [Kossakowski 1996] Providing Incident Response Services / Klaus-Peter Kossakowski. - DFN-CERT. - Hamburg. - Februar 1996. [Tutorium auf der Open System Security Europe in London]
5. [Kossakowski 1996a] Coordination of Incident Response Teams / Klaus-Peter Kossakowski. - DFN-CERT. - Hamburg. - Juni 1996. [Vortrag auf dem 28. I-4 Meeting in Oslo]
6. [Kossakowski 1997] From Incident Response to Incident Control Management / Klaus-Peter Kossakowski . - DFN-CERT. - Hamburg. [Vortrag auf dem 9. FIRST Workshop in Bristol]
7. [Smith 1994] Forming an Incident Response Team / Danny Smith. - AUSCERT, University of Queensland. - Brisbane, Qld. - Juli 1994. [Vortrag auf dem 6. Computer Security Incident Handling Workshop 1994 in Boston, Mass.]
8. [Wack 1991] Establishing a Computer Security Incident Response Capability / John Wack. - US National Institute of Standards and Technology. - Gaithersburg, MD. - NIST Special Publication 800-3. - November 1991.