Informationssicherheitsmanagement - ISIM Ablauf

Information Security Incident Management – Ablauf

Ziele der Lektion

• Kennenlernen des Ablaufs der Prozesse Incident Management und Incident Response für das Management und die Abhandlung von sicherheitsrelevanten Incidents bis hin zu Notfallsituationen

• Darstellung der Phasen eines Incident Response Plans

• Diskussion von kritischen Erfolgsfaktoren

Process

Aktivitäten

Bestimmung der bestehenden Möglichkeiten, um auf Incidents zu reagieren

Die meisten Unternehmen haben bereits Methoden und Vorgehen etabliert, um entweder ad hoc oder formal auf Incidents zu reagieren. Der Information Security Manager muss zunächst diese Abläufe identifizieren, um so den Ist-Stand zu erheben. Dies kann durch unterschiedliche Methoden erfolgen.

Umfragen / Interviews von Senior Management, Business Manager, IT bieten eine gute Möglichkeit, um herauszufinden, wie in der Vergangenheit auf Incidents reagiert wurde und wie die Einschätzung der Leistungsfähigkeit, auf Incidents zu reagieren, ist.

Ein Self-Assessment kann durch das Incident Management Team selbst gegen eine Reihe von Kriterien und Fragen durchgeführt werden, um eine Selbsteinschätzung der derzeitigen Leistungsfähigkeit zu bekommen. Das Self-Assessment kann relativ schnell und einfach, ohne die Beteiligung von anderen Interessensvertretern berücksichtigen zu müssen, durchgeführt werden. Dem gegenüber steht aber der Nachteil, dass die eingeschränkte Selbstbewertung der derzeitigen Leistungsfähigkeit möglicherweise nicht mit der durch die Interessensvertreter wahrgenommenen Leistung, übereinstimmt.

Ein externes Audit und die Beurteilung durch Dritte stellt die umfassendste Methode dar, da formalisierte Interviews, Umfragen, Simulationen und andere Beurteilungsmethoden für die Bewertung kombiniert werden. Diese Methode wird im Allgemeinen von Organisationen eingesetzt, die bereits ein adäquates Incident Management betreiben, dieses aber verbessern wollen oder die bereits etablierten Prozesse überarbeiten möchten.

Entwickeln eines Incident Response Plans

Der Incident Response Plan stellt die operative Komponente des Incident Managements dar. Der Plan beinhaltet einen detaillierten Aktionsplan, Personalbeschreibungen und Aktivitäten, die in Situationen zu tragen kommen, wenn durch einen sicherheitsrelevanten Incident IT Services beeinträchtigt sind, oder der Verlust von Informationen eingetreten ist.

Entwickeln von Detailplänen für Recovery und Response

Bei der Entwicklung von Response und Recovery Plänen müssen einige Dinge in Betracht gezogen werden, wie beispielsweise verfügbare Ressourcen, erwartete Leistungen und Arten und Schweregrad von Bedrohungen, denen die Organisation gegenüber steht. Die derzeitigen Möglichkeiten zur Erkennung von Incidents und für Monitoring müssen bekannt sein und die Risikotoleranz, welche die Organisation bereit ist zu tragen, muss bestimmt werden. Ziel einer effektiven Strategie für Recovery Pläne ist es, ein kosteneffizientes Gleichgewicht zwischen den Bemühungen des Risk Managements, Incident Management and Response und der Business Continuity- und Disaster Recovery Plans zu schaffen.

Organisation, Training und Ausrüsten des Response Personals

Das Training des Response Teams ist unerlässlich. Der Information Security Manager sollte Szenarios von Vorfällen entwickeln und daraufhin die Response- und Recovery-Pläne testen, um sicherstellen zu können, dass die Teammitglieder mit deren Aufgaben und Verantwortlichkeiten vertraut sind. Durch diesen Prozess kann das Team auch jene Ressourcen identifizieren, die für die geeignete Basisausrüstung des Teams für Response und Recovery benötigt werden. Ein zusätzlicher Nutzen des Trainings ist, dass unklare Abläufe und unpassende und ineffiziente Recovery-Maßnahmen erkannt und verbessert werden können.

Die Mitglieder des IMT sollten ein Trainingsprogramm mit mehreren Phasen durchlaufen.

• Einführung in das IMT: Während der Einführung werden die grundlegenden und wichtigsten Informationen für effektives IMT Mitglied bereitgestellt.
• Betreuen neuer Teammitglieder hinsichtlich Rollen, Verantwortlichkeiten und Abläufen (Mentoring): Erfahrene Teammitglieder können an neue Mitglieder wertvolles Wissen weitergeben, um diese nach der Einführungsphase zu unterstützen. Realisiert wird das im Allgemeinen im Rahmen einer Mentoring-Phase, in der ein erfahrenes Teammitglied (Mentor) einem neuen Mitglied über einige Zeit zur Seite steht.
• Training-on-the-job: Dient dazu, um ein Verständnis für die Unternehmensrichtlinien, Standards, Abläufe, verfügbare Softwaretools und Applikationen, richtige Verhaltensregeln etc. zu schaffen.
• Schulungen: Teammitglieder benötigen Schulungen, um geeignete Kompetenzen für umfassende Incident-Management-Fähigkeiten zu erreichen.

Wiederherstellungsstrategien

Es gibt viele Strategien für die Wiederherstellung kritischer Informationen, deren Entwicklung je nach Größe und Komplexität der Organisation entsprechend Zeit beansprucht und Kosten verursachen kann. Es sollte jene verfolgt werden, die wahrscheinliche Ereignisse innerhalb akzeptabler Wiederherstellungszeiten zu gerechtfertigten Kosten mit Sicherheit abdeckt. Die Gesamtkosten für Wiederherstellungsfähigkeiten setzt sich aus den Kosten für die Vorbereitung auf mögliche Unterbrechungen (z.B. Beschaffung, Wartung und Test von redundanten Rechnern, Wartung alternativer Netzwerkrouten, Schulungs- und Personalkosten etc.) und den Kosten des Einsatzes der vorbereiteten Maßnahmen bei Eintritt eines Ereignisses. Bei den Überlegungen möglicher Strategien sollen auch Versicherungen, welche verschiedene Formen von Beeinträchtigungen des Geschäftsbetriebs abdecken, berücksichtigt werden.

Planung der Wiederherstellung und Business Recovery Prozesse

Ein Information Security Manager muss die nötigen grundlegenden Prozesse für die Wiederherstellung des Betriebs nach Incidents, wie z.B. DoS-Attacken, Naturereignisse und anderen potentiellen Unterbrechungen der Geschäftstätigkeiten, kennen. Unter Disaster Recovery (DR) versteht man die Wiederherstellung von IT-Systemen nach Zerstörungen durch Naturgewalten. Business Recovery (BR) bezeichnet die Wiederherstellung von kritischen Geschäftsprozessen um mit dem Geschäftsbetrieb fortfahren bzw. diesen wieder aufnehmen zu können. Business Recovery beinhaltet dabei neben dem Disaster Recovery alle anderen Aspekte des Geschäftsbetriebs.

Bei der Planung müssen die Kriterien für die Deklaration eines IT-Desasters festgelegt werden. Nicht alle Ereignisse, Incidents oder kritische Unterbrechungen müssen notwendigerweise als Security Incident klassifiziert werden. Zum Beispiel können Serviceunterbrechungen durch einen System- oder Applikationsfehler verursacht worden sein. Unabhängig von der Ursache der Unterbrechung des Geschäftsbetriebs müssen die Aktivitäten zum Erhalt oder Wiederherstellung des Geschäftsbetriebs rasch gesetzt werden, um den Erwartungen des Business nach einer zufriedenstellenden Lösung gerecht zu werden. Ein wesentlicher Prozess während der Planung, ist die Durchführung einer BIA, um die Kosten beim Ausfall von Systemen bestimmen zu können. Das bereitet die Basis für die Festlegung angemessener RTOs, was wiederum Einfluss auf die Örtlichkeit und Kosten von außerbetrieblichen Einrichtungen zur Wiederherstellung (z.B. Ausfallsrechenzentren) nimmt.

Recovery Sites

Die Auswahl der geeigneten Recovery Site hängt von der Wahrscheinlichkeit eintretender Ereignisse, Auswirkungen und Kosten bei Ausfall ab. Bei langen und kostenintensiven Ausfällen, welche die primären physischen Einrichtungen beeinträchtigen, bieten sich Backup Alternativen außerhalb der Organisation an. Als mögliche Alternativen können in Betracht gezogen werden:

Hot Sites sind komplett konfiguriert und innerhalb weniger Stunden betriebsbereit. Ausstattung, Netzwerk, Systemsoftware müssen mit der primären Installation, welche gesichert wird, kompatibel sein. Zum Einsatz der Hot Site werden zusätzlich nur Personal, Programme, Daten und Dokumentationen benötigt.

Warm Sites bestehen aus einer kompletten Infrastruktur, welche jedoch nur teilweise konfiguriert ist, im Allgemeinen mit Netzwerkverbindungen und grundlegender Peripherie wie z.B. Disk Drives, Tape Drives oder Controllers. Manchmal sind Warm Sites im Vergleich zur primären, produktiven Installation auch weniger leistungsfähig ausgestattet, z.B. CPU, Memory.

Cold Sites bestehen lediglich aus einer Basisausstattung, wie z.B. Klima, Verkabelung, doppelte Böden etc., die zum Betrieb von IT-Anlagen benötigt werden. In der Cold Site kann die benötigte IT-Ausstattung bei Bedarf installiert und konfiguriert werden, was durchaus einige Wochen in Anspruch nehmen kann.

Mobile Sites sind spezielle Fahrzeuge oder Anhänger, die rasch an einen Geschäftsstandort oder andere Standorte gebracht werden können. Sie ist meist mit vorkonfigurierten IT Komponenten wie Server, Desktops, Equipment für die Kommunikation etc. ausgestattet und bieten somit eine einsatzbereite Anlage und Ausstattung für die Informationsverarbeitung. Mobile Sites sind sehr nützlich, wenn es keine Möglichkeit für Einrichtungen zur Wiederherstellung in der gewünschten Umgebung gibt.

Mirror Sites sind die beste Alternative, wenn der IT Betrieb ununterbrochen verfügbar sein soll. Mirror Sites sind ident oder sehr ähnlich zum primären IT Standort und werden im Rahmen von Load Balancing oder Load Sharing im produktiven Betrieb eingesetzt. Typischer Weise wird die Last der Applikationen automatisch nach Kapazität und Verfügbarkeit auf die Standorte verteilt. Unter der Voraussetzung, dass ausreichend Kapazitäten zur Verfügung stehen (Capacity Management), kann der Ort der Ausführung der Applikationen nahtlos und unterbrechungsfrei zwischen den Standorten gewechselt werden. Bei Organisationen mit mehreren Niederlassungen und mehreren Rechenzentren, bietet sich die Variante des „Spiegelns“ zwischen den einzelnen Rechenzentren an.

Die Auswahl der passenden Alternative für das Wiederherstellungsszenario hängt von den betrieblichen Anforderungen, welche durch eine BIA bestimmt werden, der Gegenüberstellung von Kosten und Nutzen und der Risikotoleranz des Unternehmens ab. Bei der Festlegung der Anforderungen kann sich auch herausstellen, dass einige kritische betrieblichen Aspekte mit Mirror Sites abgesichert werden müssen, um bestimmte Service Level Anforderungen erfüllen zu können, während andere Aspekte z.B. durch Hot, Warm oder Cold Sites abgedeckt sind.

Grundlagen für die Auswahl einer Recovery Site

Die Auswahl der geeigneten Site für die Response und Recovery Strategie sollte auf den Parametern: Interruption Window, RTO, RPO, SDO und MTO beruhen. Um eine passende Wiederherstellungsstrategie vorbereiten zu können, muss der Information Security Manger all diese Parameter mit den Möglichkeiten der verschiedenen Arten von Recovery Sites und deren Kosten vergleichen. Die Komplexität und Kosten der Response- und Recovery-Pläne, genauso wie die Arten und Kosten der Recovery Sites sind proportional zu diesen zeitlichen Zielen der Wiederherstellung. Ein Zeitfenster für eine Unterbrechung von zwei Stunden benötigt eine Hot-Site- oder Mirror-Site-Lösung, die meist recht teuer ist, der korrespondierende Wiederherstellungsplan dagegen ist recht simpel und daher günstig. Im Gegensatz dazu bedeutet ein Zeitfenster für eine Unterbrechung von einer Woche den Einsatz einer recht günstigen Cold Site, wobei der zugehörige Recovery Plan recht komplex und damit teuer sein wird.

Incident Management und Response Teams

Im Incident Response Plan müssen die Teams und deren Verantwortlichkeiten im Falle eines Incidents festgelegt und trainiert werden. Je nach Umfang des Geschäftsbetriebs können diese Teams auch aus Einzelpersonen bestehen. Der Einsatz der entsprechenden Teams ist abhängig von der Schwere der Unterbrechung und Art der betroffenen Systeme oder Informationen. Es sollte eine Matrix erstellt werden, in der die Beziehung zwischen den Funktionen und den verschiedenen Teams ersichtlich ist. Beispiele für Teamarten in einem Response Plan:

Team für Notfalleinsatz: Besteht z.B. aus Feuerwarten, deren Funktion die Behandlung von Ereignissen mit Feuer oder anderen Notfallszenarios ist.

Team für Schadensaufnahme: Qualifizierte Personen, deren Funktion die Feststellung des Ausmaßes des Schadens an physischen Einrichtungen oder Anlagen ist. Weiter wird durch dieses Team eine erste Einschätzung getroffen, was wiederhergestellt werden kann, was rettungswürdig ist, oder ob es sich um einen totalen Verlust handelt.

Team für Notfall Management: Ist verantwortlich für die Koordination der Aktivitäten aller anderen Recovery Teams und trifft relevante Entscheidungen.

Team für Übersiedlung und Verschiebung von Standorten: Dieses Team ist verantwortlich für die Koordination des Prozesses für die Verschiebung einer Hot Site auf einen neuen Standort oder auf den wiederhergestellten Originalstandort.

Security-Team: Wird auch Security Incident Response Team genannt und ist verantwortlich für die Überwachung der Sicherheit von kritischen Systemen und Kommunikationsverbindungen, Lösen von Sicherheitsproblemen, welche die schnelle Wiederherstellung von Systemen behindern und die einwandfreie Installation und Funktionsweise jeder sicherheitsrelevanten Software.

Voraussetzungen für Benachrichtigungen

Der Plan muss die Voraussetzungen für die Benachrichtigung von Schlüsselpersonen und Entscheidungsträgern, Systemverantwortlichen und Endanwendern bilden, die für die Initiierung und Ausführung der Incident-Behandlung benötigt werden. Ein Verzeichnis von Telefonnummern von Personen, die im Falle eines Incidents benachrichtigt werden müssen, ist ein wesentlicher Bestandteil des Benachrichtigungsprozesses. Dieses Verzeichnis sollte Informationen, wie beispielsweise eine priorisierte Liste zu benachrichtigender Kontakte, Primär- und Notfalltelefonnummer und Adressen für jede Schlüsselperson, Kontaktdaten von Lieferanten und Herstellern relevanter Hard- und Software, Kontaktdaten von Mitarbeitern des Betriebs, Telefonnummern von Behörden und Personen mit gesetzlichen Durchsetzungsrechten im Falle schwerwiegender Sicherheitszwischenfällen.

Betriebsmittel

Der Plan muss Regelungen für alle Betriebsmittel, die für die Aufrechterhaltung des Geschäftsbetriebs während der Wiederherstellungsaktivitäten nötig sind, enthalten. Das inkludiert auch detaillierte, aktuelle Ablaufbeschreibungen und Checklisten auf Papier, die auch leicht von Personal befolgt werden können, die mit dem Wiederherstellungsablauf nicht vertraut sind. Dies dient dazu, um die Ausführung des Planes zu gewährleisten, auch wenn Mitglieder des vorgesehenen Teams nicht verfügbar sind. Ebenso sollten benötigte spezielle Formulare und Checklisten, sowie Bestellformulare für kritische Hardwarekomponenten am Wiederherstellungsstandort verschlossen aufbewahrt werden. Wenn die Funktionsweise von Applikationen von bestimmten Hardwarekomponenten oder Betriebssystemen abhängig ist, müssen dieses Equipment oder Softwarekomponenten am Wiederherstellungsort verfügbar sein.

Versicherungen

Der Plan sollte auch wichtige Informationen hinsichtlich der Versicherungen der Organisation beinhalten. Eine Versicherung für informationsverarbeitende Systeme ist gewöhnlich eine Bündelpolice, die verschiedenste Arten und Typen von IT abdeckt. Sie sollte modular aufgebaut sein, sodass sie an das spezielle IT Equipment des Versicherungsnehmers angepasst werden kann. Die verschiedenen Arten der Abdeckungen durch Versicherungen umfassen beispielsweise das IT Equipment und IT-Einrichtungen, Unterbrechungen im Geschäftsbetrieb, den Wert von Unterlagen und Aufzeichnungen, Transport von Medien etc.

Regelmäßige Anpassung des Recovery Plans

Durch die Dynamik von Organisationen und stetigen Veränderungen müssen auch die Response und Recovery Pläne regelmäßig angepasst werden, um den aktuellen Zielen und Ansprüchen des Unternehmens zu entsprechen. Dabei ist es wichtig, die Zustimmung und Rückendeckung des Senior Managements für den Prozess der regelmäßigen Anpassung zu erhalten, da dieser fortlaufende Prozess Unternehmensressourcen beansprucht, um ein akzeptables Niveau der Wiederherstellungsfähigkeiten zu erreichen und zu erhalten.

Wiederherstellungspläne und Informationssicherheit

Es ist wichtig, dass die Informationsressourcen auch bei notfallbedingt chaotischen Verhältnissen geschützt bleiben. Der Information Security Manager muss sicherstellen, dass die Informationssicherheit bei allen Response und Recovery Plänen entsprechend berücksichtigt ist. Der Information Security Manager sollte die Pläne überprüfen um sicherzugehen, dass deren Ausführung keine Standards und Anforderungen der Informationssicherheit gefährdet. Es sollte auch eine Risikoanalyse durchgeführt werden, um das Management über mögliche Auswirkungen der Sicherheitsrisiken durch die Ausführung der Pläne zu informieren.

Umsetzung der Detailpläne für Response und Recovery

Um sicher zu gehen, dass die Response- und Recovery-Pläne nach den Bedürfnissen des Business ausgeführt werden, muss eine bestimmte Person, wie eine Art Regisseur, die Aufgaben innerhalb der Pläne koordinieren, ihre Ausführung überblicken und überwachen, mit dem Senior Management eng zusammenarbeiten und nötige Entscheidungen treffen. Der Information Security Manager kann, muss aber nicht, diese Rolle des Recovery-Plan-Koordinators übernehmen, muss aber zumindest sicherstellen, dass diese Rolle einer geeigneten Person zugeteilt wird.

Eskalationsprozess

Der Information Security Manager sollte einen Eskalationsprozess implementieren, um jene Ereignisse festzulegen, die durch das IRT gehandhabt werden müssen. Ereignisse, die zunächst als Routine erscheinen, können sicherheitsgefährdend sein und sich als Security-Incident herausstellen. Zum Beispiel kann eine Datenverfälschung nicht aufgrund eines Applikationsfehlers verursacht sein, sondern auf Grund eines Virus oder Wurms. Als Teil der Policies und Procedures des Notfall- und Incident Managements, sollte eine detaillierte Beschreibung des Eskalationsprozesses dokumentiert sein. Für jedes Ereignis sollte eine Liste von Aktionen und Aufgaben und die Reihenfolge deren Abarbeitung beschrieben sein (Aktionsplan). Für jede aufgelistete Aktion sollten die verantwortliche Person und eine geschätzte Ausführungszeit angegeben sein. Sollte irgendeine Aktion nicht ausgeführt werden können oder die geschätzte Ausführungszeit überschritten werden, so sollte im Prozess mit der nächsten Aktion fortgefahren werden, da jede gescheiterte Aktion wertvolle Zeit verschwendet. Wenn die Summe aller Ausführungszeiten ein vordefiniertes Limit erreicht, kann die Notfallsituation zu einer Alarmstufe (niedrig, mittel, hoch) hinaufgestuft werden. Die Situation einer Alarmstufe führt zu einer Benachrichtigung von hierarchisch übergeordneten Stellen, wie beispielsweise das Senior Management (hierarchische Eskalation). Darüber hinaus könnten spezielle Recovery Teams, Versicherungen, Hersteller etc. benachrichtigt werden (fachliche Eskalation). Der Information Security Manager sollte einen Kommunikationsplan in Zusammenarbeit mit PR-Abteilung, Rechtberatung und Senior Management entwickeln, um eine angemessene Informationsweitergabe zu gewährleisten.

Policies und Prozesse für Intrusion Detection (ID)

In Unternehmen werden oft Intrusion Detection Systems (IDS) eingesetzt, um Versuche in das Unternehmensnetz einzudringen und andere verdächtige Aktivitäten zu erkennen. Dabei sollten die Basissysteme des IDS fehlertolerant und gegen Angriffe abgesichert sein. Die IDS selbst sollten durchgehend verfügbar, leicht zu überwachen und rasch anpassbar sein, nicht übermäßig viel Netzwerk-Overhead verursachen und eine große Anzahl an Anomalien erkennen können. Das Personal, das für den Betrieb des IDS zuständig ist, muss natürlich dafür ausreichend geschult sein. Idealerweise sollten sowohl host- als auch netzwerkbasierte IDS eingesetzt werden, um eine möglichst große Abdeckung der Netzwerk-Topologien zu erreichen. Die meisten Systeme können so konfiguriert werden, dass im Falle verdächtiger Ereignisse das Personal automatisch benachrichtigt wird. Wenn eine verdächtige Aktivität identifiziert wurde, sollten definierte Prozeduren initiiert werden, um auf diesen Vorfall zu reagieren.

Service Desk Prozesse für die Identifizierung von Security Incidents

Ein Information Security Manager sollte Prozesse für das Service Personal definieren, um diesen die Unterscheidung eines typischen Service Desk Requests von einem möglichen Security Incident zu ermöglichen. Der Service Desk ist meist die erste Anlaufstelle für Meldungen eines möglichen sicherheitsrelevanten Vorfalls. Das schnelle Erkennen von Security Incidents und rasche Setzen von Maßnahmen sind kritische Faktoren für die erfolgreiche Vermeidung oder Verminderung der Schäden durch so einen Vorfall. Dafür sind die Festlegung entsprechender Kriterien für die Kategorisierung von Incidents und eine große Sensibilität des Service Desk Personals für Sicherheitsthemen unerlässlich. Ausreichendes Training des Personals kann die Gefahr erfolgreich durchgeführter Angriffe mittels Social Engineering gegenüber Service Desk Agents verringern. Neben der Fähigkeit mögliche Security Incidents zu erkennen, muss das Service-Desk-Personal über entsprechende Arbeitsanweisungen für Informationsweitergabe (Benachrichtigungen) und Eskalation verfügen und diese befolgen.

Benachrichtigungsprozess

Die effektive und zeitnahe Benachrichtigung über das Auftreten eines Security Incidents stellt einen kritischen Faktor für jedes Security Program dar. Wenn alle relevanten Informationen zur richtigen Zeit verteilt werden, kann die Organisation rasch auf Incidents reagieren und so vor potentiellen Schäden der Incidents geschützt werden. Dabei können beispielsweise Automatismen in Monitoring Systemen unterstützen, indem automatisch Emails oder SMS abhängig vom eintretenden Ereignis an bestimmte Personengruppen verschickt werden. Unternehmensbereiche, die meist Informationen beim Auftreten von Incidents benötigen sind z.B. Risk Management (zur Beurteilung des möglichen Risikos für das Unternehmen), Human Resources (sobald ein Angriff von Mitarbeitern des Unternehmens initiiert wurde), Rechtsabteilung (sobald Verletzungen von Gesetzen zu befürchten sind), Public Relations (wenn das Image des Unternehmens betroffen sein könnte) und Betrieb (damit erste Maßnahmen zur Eindämmung getroffen werden können).

Dokumentieren von Ereignissen

Wenn ein Incident eintritt, muss das Security Team über dokumentierte Verfahren (Handlungsanweisungen) verfügen, um sicherstellen zu können, dass die nötigen Informationen aufgezeichnet und die relevanten Daten sichergestellt werden. Durch die Sicherstellung von diesen Informationen können die Ereignisse untersucht und an Teams der Forensik oder gegebenenfalls an Behörden weitergegeben werden.

Festlegen der Verfahren und Handlungsanweisungen

Ein Information Security Manager sollte gemeinsam mit Hilfe von Managementebenen, Rechtsberatern und Gesetzesbehörden die Verfahren für die Sicherstellung von Daten entwickeln. Durch Einbeziehung dieser speziellen Stakeholder können Verfahren entwickelt werden, mit denen sicherheitsrelevante Vorfälle so sorgfältig behandelt werden können, dass Beweise sichergestellt werden können, die rechtlich benötigte Kontrollkette eingehalten wird und die diesbezüglichen Unternehmensanforderungen angemessen erfüllt werden.

Es gibt einige grundlegende Aktivitäten, die Mitarbeiter von Informationssystemen befolgen müssen. Dazu zählt, nichts zu unternehmen, das potentielle oder bestehende Belege und Beweise verändern, beeinträchtigen oder zerstören könnte. Geschultes Personal der Forensik kann attackierte oder infizierte IT-Systeme untersuchen, aber wenn Informationen auf diesen Systemen durch anderes Personal verändert wurden, können diese Daten möglicherweise vom Forensik-Team für die Untersuchung des Incidents nicht verwendet werden oder vom Gericht nicht anerkannt werden. Bei Security Incidents müssen die IT-Forensiker die Informationen und physische Objekte auf systematische Art und Weise sammeln und behandeln, sodass diese vor Gericht als Beweise anerkannt werden. Daher sollte die IT-Forensik durch speziell geschultes Personal im Security Incident Response Team, Spezialisten von Drittfirmen oder Gesetzesbehörden durchgeführt werden. In der ersten Reaktion eines Systemadministrators sollte der Incident bestätigt, Umfang und Größe des betroffenen Umfeld identifiziert (z.B. Netzwerk, Systeme, Applikationen etc.), der Grad des Verlustes, Zerstörung oder Veränderung bestimmt und der mögliche Hergang und die eingesetzten Mittel bei der Attacke identifiziert werden.

Voraussetzungen für die Sicherung von Beweisen

Jede Veränderung von Beweismitteln eines Ein- oder Angriffs kann die Verfolgung des Täters verhindern oder zumindest die Möglichkeiten der Verfolgung einschränken. Weiters kann die Änderung von Daten die nötigen Aktivitäten der Computer Forensik, um den Täter und alle verursachten Änderung ausfindig zu machen, behindern. Die Wahrscheinlichkeit, den Hergang der Attacke rekonstruieren zu können, sinkt. Damit kann das Security Program nicht entsprechend angepasst oder erweitert werden, um das Risiko ähnlicher Attacken für die Zukunft zu verringern. Eine gängige, aber nicht generell einsetzbare, Empfehlung für die Behandlung eines kompromittierten Systems ist es, ihn abzuschalten, um die Beweise auf der Festplatte vollständig zu bewahren. Für ein Unternehmen müssen also individuell passende Verfahren festgelegt und das Personal in diesen Verfahren geschult werden. Im Falle eines kompromittierten IT-Systems muss aber durch geschultes Personal mittels spezieller Forensik Tools eine Bit-by-bit-Kopie jeglicher Beweise, die sich auf der Festplatte oder anderer Medien des betroffenen Systems befinden, gemacht werden, um diese Beweise rechtlich verwenden zu können. Diese Kopie kann dann für die weitere Analyse oder Tests herangezogen werden. Das Original muss unverändert bleiben und sollte einer bestimmten Aufsichtsperson übergeben und bis zur Verwendung vor Gericht sicher verwahrt werden. Ein Information Security Manager muss für den Fall eines Security Incidents dokumentierte Verfahren und Handlungsanweisungen für die Beweissicherung festgelegt haben. Eine weitere Voraussetzung für rechtlich verwendbare Beweise ist die detaillierte Dokumentation der Security Incidents.

Postevent Reviews

Nach der Bearbeitung und dem Abschluss von Incidents sollten die durchgeführten Aktivitäten einer Überprüfung unterzogen werden. Durch diese Postevent Reviews kann von jedem Incident und den resultierenden Aufwänden für eine entsprechende Reaktion und für die Wiederherstellung gelernt werden. Diese Erkenntnisse liefern wesentlichen Input für die Verbesserung der Verfahren und Handlungsanweisungen für die Behandlung von Incidents und Wiederherstellung.

Identifizieren der Ursachen und korrigierende Maßnahmen

Security Incidents müssen nicht immer das Ergebnis von Attacken außerhalb oder innerhalb des Unternehmens sein, sondern können auch durch Fehler in den implementierten Security Controls verursacht werden. Für eine systematische Überprüfung von sicherheitsrelevanten Ereignissen, sollte ein Team für die Überprüfung der Ereignisse gebildet werden. Durch diese Überprüfungen kann das Team entsprechende Empfehlungen für die Verbesserung oder Erweiterung des Security Programs entwickeln, indem die Ursachen für das Ereignis und nötige Maßnahmen zur Vermeidung des wiederholten Auftretens identifiziert werden. Die Ursache vieler Einbrüche in Systeme sind oft schwache oder sogar fehlende Bewertungen von Schwachstellen und mangelndes Patch Management. Analysen sollten durchgeführt werden, um Fragen hinsichtlich der involvierten Personen, Symptom und Ursache der Attacke, Grund und Zeitraum des Angriffs etc. zu finden.

Post Incident Reviews und anschließende Prozeduren

Post Incident Reviews und die anschließenden Prozeduren sind wesentlich für eine kontinuierliche Verbesserung des Security Programs. Eine konsistente Methodik sollte innerhalb der für Sicherheit verantwortlichen Organisationseinheiten eingeführt und angewandt werden, sodass nach der Identifikation eines Problems ein Aktionsplan zur Vermeidung oder Verhinderung desselben entwickelt wird und Schritte zur Lösung ergriffen werden. Durch Wiederholen dieser einfachen Prinzipien kann das Security Program an Änderungen der Organisation und der daraus resultierenden möglichen Gefahren und Bedrohungen angepasst werden. Darüber hinaus wird der zeitliche Aufwand für die Reaktion des Personals auf Security Incidents verringert, sodass mehr Zeit für proaktive Aktivitäten genutzt werden kann. Der Follow-Up-Prozess nach der Incident-Behandlung ist das nützlichste Ergebnis des Aufwandes. Gesammelte Erfahrungen (Lessons Learned) während der Bearbeitung von Incidents können sowohl die Sicherheitsverfahren als auch den Prozess für die Incident-Behandlung selbst verbessern.

Herausforderungen bei der Entwicklung eines Incident Management Plans

Bei der Entwicklung und beim Erhalt eines Incident Management Plans können unerwartete Hürden auftreten, die durch vielfältige Gründe entstehen können.

Fehlende Unterstützung des Managements durch mangelnde Einbindung und mangelnde organisatorische Zustimmung können der Grund vieler Stolpersteine sein. Wenn ein Incident eintritt, kann die durch das Management entgegengebrachte Resonanz nicht wie benötigt sein und dadurch die Anstrengungen des Incident Managements behindern. Das passiert meistens dann, wenn das Senior Management und andere Interessensvertreter nicht in die Implementierung und Planung des Incident Managements involviert werden.

Mangelnde Übereinstimmung mit organisatorischen Zielen und Strukturen führt dazu, dass die Leistungen des Incident Management nicht den Erwartungen des Senior Managements und den Fachbereichen entsprechen. Obwohl es sicherlich nicht einfach ist, die Fähigkeiten des Incident Managements an die sich rasch ändernden Ziele und Strukturen der Organisation anzupassen, müssen durch Gespräche kritische Business Funktionen und die betroffenen Stakeholder ermittelt werden, sowie die Rahmenbedingungen, denen das Business unterliegt, verstanden werden.

Die Entwicklung eines Incident Management Plans kann viel Zeit in Anspruch nehmen und erfordert eine intensive Interaktion mit unterschiedlichen Stakeholdern. Der oberste Kopf des Incident Managements, normalerweise Mitglied des Senior Managements oder Information Security Manager, könnte unerwartet das Unternehmen verlassen und somit alle Planungs- und Entwicklungsanstrengungen zum Erliegen bringen. So eine Fluktuation oder auch ein Wechsel im Incident Management Team kann dazu führen, dass die Konzentration auf die Planung und Umsetzung schwindet oder Ressourcen dafür reduziert werden.

Mängel im Kommunikationsprozess führen entweder zu übermäßiger oder mangelnder Informationsweitergabe. Wenn zu wenig Information an die relevanten Stakeholder weitergegeben wird, führt das zu einem fehlenden oder falschen Verständnis für die Notwendigkeit der Planung, den Nutzen, oder deren Rolle bei der Planung, Implementierung und Aufrechterhaltung des Incident Managements. Zu viel Information wiederum kann bei den Stakeholdern zu Ablehnung führen, da sie das Gefühl bekommen, zu viel Aufwand in die Planung investieren zu müssen oder andere, für sie wichtige Themen zu vernachlässigen.

Der vorgeschlagene Plan kann gut sein und sehr viele Bereiche abdecken, aber gleichzeitig zu komplex und weit gegriffen. Pläne, die überdimensioniert erscheinen, können zu Ablehnung bei allen Beteiligten führen.

Incident Response Plan

Der Incident Response Plan stellt die operative Komponente des Incident Managements dar. Der Plan beinhaltet einen detaillierten Aktionsplan, Personalbeschreibungen und Aktivitäten, die in Situationen zu tragen kommen, wenn durch einen sicherheitsrelevanten Incident IT Services beeinträchtigt sind, oder der Verlust von Informationen eingetreten ist. Der Response Plan umfasst dabei auch Wiederherstellungsstrategien und -pläne (Recovery Plans). Bei der Entwicklung von Response- und Recovery-Plänen müssen einige Dinge in Betracht gezogen werden, wie beispielsweise verfügbare Ressourcen, erwartete Arten und Schweregrad von Bedrohungen, denen die Organisation gegenüber steht. Die derzeitigen Möglichkeiten zur Erkennung von Incidents und für Monitoring müssen bekannt sein und die Risikotoleranz, welche die Organisation bereit ist zu tragen, muss bestimmt werden. Ziel einer effektiven Strategie für Recovery Plans ist es, ein kosteneffizientes Gleichgewicht zwischen den Bemühungen des Risk Managements, Incident Management und Response und der Business Continuity- und Disaster Recovery Plans zu schaffen.

Phasen eines Incident Response Plans

Vorbereitung und Grundlagen

In dieser Phase werden Vorbereitungen in der Organisation getroffen und grundlegende Voraussetzungen geschaffen, um den Incident Response Plan zu entwickeln. Eine ausreichende Vorbereitung erleichtert die spätere Umsetzung. Aktivitäten in dieser Phase sind

• Festlegen einer Methode, um Incidents zu behandeln
• Festlegen einer Policy und von Warnhinweisen in Informationssystemen, um Unberechtigte abzuschrecken und Informationen sammeln zu dürfen
• Festlegen eines Kommunikationsplans gegenüber den Interessensvertretern (Fachbereichen etc.)
• Bestimmen von Kriterien, ab wann Incidents an hierarchisch übergeordnete Stellen berichtet werden (Eskalationspfade)
• Entwickeln eines Prozesses, um das Incident Management Team zu aktivieren
• Bestimmen einer sicheren Umgebung, in der der Incident Response Plan durchgeführt werden kann
• Sicherstellen, dass das benötigte Equipment vorhanden oder verfügbar ist

Identifikation

In dieser Phase wird bestätigt, dass es sich um einen sicherheitsrelevanten Incident handelt und es werden Details über diesen Incident gesammelt. Mögliche Incidents können unter anderem von Informationssystemen, Endanwendern oder anderen Personen des Unternehmens gemeldet werden. Nicht alle dieser gemeldeten Vorfälle sind als sicherheitsrelevante Incidents einzustufen, da es sich um Fehlalarme handeln kann, oder weil der Vorfall nicht den Kriterien eines sicherheitsrelevanten Incidents entspricht. Aktivitäten in dieser Phase sind

• Zuweisen des (potentiellen) Incidents an einen Bearbeiter (Incident Handler)
• Prüfen, dass es sich bei dem gemeldeten Ereignis um einen Security Incident handelt
• Festlegen einer Kontroll- oder Überwachungskette während der Identifikation, wenn mögliche Beweise gesichert werden müssen
• Bestimmen der Dringlichkeit des Incidents und entsprechende Eskalation, wenn nötig

Eindämmung

Nachdem ein Security Incident identifiziert und bestätigt wurde, wird das Incident Management Team (IMT) aktiviert und die Informationen, die der Incident Handler gesammelt hat, im Team verteilt. Das Team führt daraufhin eine detaillierte Beurteilung und Bewertung durch. Es informiert den Systemverantwortlichen oder Business Manager über die betroffenen Informationssysteme oder Assets, um weitere Schritte zu koordinieren. Die Aktivitäten in dieser Phase zielen darauf ab, die Gefahren des Incidents einzudämmen. Aktivitäten in dieser Phase sind

• Aktivierung des IMT, um den Incident zu beurteilen und einzudämmen
• Benachrichtigung der Stakeholder, welche von dem Incident betroffen sind
• Zustimmung für Aktivitäten, welche die Verfügbarkeit eines IT Services beeinflussen können oder für Risiken, die aus dem nötigen Prozessen zur Eindämmung entstehen können, einholen
• Zusammenführen der involvierten IT Experten und relevanten Mitglieder des virtuellen Teams, um die Prozeduren für die Eindämmung durchzuführen
• Einholen und Sichern von möglichen Beweisen
• Dokumentieren von und Sicherungen erstellen bei Aktivitäten von dieser Phase an
• Steuern der Kommunikation gegenüber der Öffentlichkeit durch das PR Team

Im Incident Response Plan müssen Voraussetzungen für die Benachrichtigung von Schlüsselpersonen und Entscheidungsträgern, Systemverantwortlichen und Endanwendern vorhanden sein, die für die Initiierung und Ausführung der Incident-Behandlung benötigt werden. Ein Verzeichnis von Telefonnummern von Personen, die im Falle eines Incidents benachrichtigt werden müssen, ist ein wesentlicher Bestandteil des Benachrichtigungsprozesses. Dieses Verzeichnis sollte Informationen, wie beispielsweise eine priorisierte Liste zu benachrichtigender Kontakte, Primär- und Notfalltelefonnummer und Adressen für jede Schlüsselperson, Kontaktdaten von Lieferanten und Herstellern relevanter Hard- und Software, Kontaktdaten von Mitarbeitern des Betriebs, Telefonnummern von Behörden und Personen mit gesetzlichen Durchsetzungsrechten im Falle schwerwiegender Sicherheitszwischenfällen.

Beseitigung

Wenn die Maßnahmen zur Eindämmung durchgeführt wurden, muss die Ursache des Incidents gefunden und beseitigt werden. Das kann auf unterschiedliche Art und Weise erfolgen. Beispielsweise durch Rücksichern, um einen bestimmten Zustand des Systems wiederherzustellen, oder einfaches Beheben der Ursache, oder Verstärken der Abwehrmechanismen und Durchführen von Schwachstellenanalysen (Vulnerability Analysis), um weitere mögliche Schadenpotentiale durch die gleiche Ursache zu verhindern. Aktivitäten in dieser Phase sind

• Bestimmen der Symptome und der Ursache eines Incidents
• Finden der aktuellsten Version des Backups oder von alternativen Lösungen
• Beheben der Ursache (auch z.B. durch Einspielen entsprechender Patches)
• Verstärken der Abwehrmechanismen, durch Implementierung von technischen Sicherheitsmaßnahmen
• Durchführen von Schwachstellenanalysen, um neue Schwachstellen aufgrund der gleichen Ursache zu finden

Wiederherstellung

Diese Phase stellt sicher, dass betroffene Systeme oder Services nach den definierten RPOs (Recovery Point Objectives) wiederhergestellt werden. RPO gibt an, wie alt die Daten zum Zeitpunkt der Wiederherstellung sein dürfen. Die Zeit, in der die Wiederherstellung erfolgen muss, ist in den RTOs (Recovery Time Objectives) definiert. Aktivitäten in dieser Phase sind

• Wiederherstellen des normalen Geschäftsbetriebes oder Funktionszustandes
• Überprüfen, ob die durchgeführten Aktivitäten für die Wiederherstellung der Systeme erfolgreich waren
• Testen der Systeme durch die Systemverantwortlichen
• Unterstützung der Systemverantwortlichen bei der Bekanntgabe des Normalbetriebs

Es gibt viele Strategien für die Wiederherstellung kritischer Informationen, deren Entwicklung je nach Größe und Komplexität der Organisation entsprechend Zeit beansprucht und Kosten verursachen kann. Es sollte jene verfolgt werden, die wahrscheinliche Ereignisse innerhalb akzeptabler Wiederherstellungszeiten zu gerechtfertigten Kosten mit Sicherheit abdeckt. Die Gesamtkosten für Wiederherstellungsfähigkeiten setzt sich aus den Kosten für die Vorbereitung auf mögliche Unterbrechungen (z.B. Beschaffung, Wartung und Test von redundanten Rechnern, Wartung alternativer Netzwerkrouten, Schulungs- und Personalkosten etc.) und den Kosten des Einsatzes der vorbereiteten Maßnahmen bei Eintritt eines Ereignisses. Bei den Überlegungen möglicher Strategien sollen auch Versicherungen, welche verschiedene Formen von Beeinträchtigungen des Geschäftsbetriebs abdecken, berücksichtigt werden.

Ein Information Security Manager muss die nötigen grundlegenden Prozesse für die Wiederherstellung des Betriebs nach Incidents, wie z.B. DoS-Attacken, Naturereignisse und anderen potentiellen Unterbrechungen der Geschäftstätigkeiten, kennen. Unter Disaster Recovery (DR) versteht man dabei die Wiederherstellung von IT-Systemen nach Zerstörungen durch Naturgewalten. Business Recovery (BR) bezeichnet die Wiederherstellung von kritischen Geschäftsprozessen, um den Geschäftsbetrieb wieder aufnehmen zu können. Business Recovery beinhaltet dabei neben dem Disaster Recovery alle anderen Aspekte des Geschäftsbetriebs. Unabhängig von der Ursache der Unterbrechung des Geschäftsbetriebs, müssen Aktivitäten und Maßnahmen zum Erhalt oder Wiederherstellung des Geschäftsbetriebs rasch gesetzt werden.

Ein wesentlicher Prozess während der Planung, ist die Durchführung einer Business Impact Analyse (BIA), um die Kosten beim Ausfall von Systemen bestimmen zu können. Das bereitet die Basis für die Festlegung angemessener Recovery Time Objectives (RTOs), was wiederum Einfluss auf die Örtlichkeit und Kosten von außerbetrieblichen Einrichtungen zur Wiederherstellung (z.B. Ausfallsrechenzentren) nimmt. Der Zweck einer Business Impact Analyse (BIA) ist die Erstellung eines Dokuments, das Interessensvertretern hilft, zu verstehen, welche Auswirkung ein Incident auf das Business und Geschäftsprozesse hat. Die Auswirkung oder Beeinflussung kann dabei entweder qualitativ (z.B. Einschätzungen) oder quantitativ (z.B. Kosten) bewertet werden. Um den Prozess einer BIA adäquat durchführen zu können, ist es wesentlich, über die Struktur und Kultur des Unternehmens, seine Kerngeschäftsprozesse, Risikotoleranz und kritische IT-Ressourcen Bescheid zu wissen. Für eine erfolgreiche BIA wird die Beteiligung von Prozessverantwortlichen, Senior Management, IT, Sicherheitsverantwortlichen und Endanwendern benötigt.

Eine BIA verfolgt drei Ziele:

• Priorisierung nach Kritikalität: Jeder kritische Prozess von Geschäftsbereichen muss identifiziert, priorisiert und die Auswirkung eines Incidents auf den Geschäftsbereich evaluiert werden. Je größer die Auswirkung, desto höher muss die Priorität gesetzt werden.
• Schätzung der (maximalen) Ausfallszeit: Die BIA wird auch genutzt, um die maximal tolerierbare Ausfallszeit (Maximum Tolerable Downtime MTD) und die maximal tolerierbare Unterbrechung (Maximum Tolerable Outage MTO) von kritischen Prozessen, IT Services und Informationen für das Business zu ermitteln, sodass das Business noch funktionsfähig bleibt.
• Benötigte Ressourcen zuweisen: Benötigte Ressourcen für kritische Prozesse werden zu diesem Zeitpunkt ebenfalls identifiziert. Jene Prozesse, die am zeitkritischsten sind und der größten Beeinflussung durch Incidents ausgesetzt sind, erhalten dabei die höchste Ressourcenzuteilung.

Der Prozess einer BIA besteht aus folgenden Aktivitäten:

Sammlung von Informationen für die Beurteilung: Der erste Schritt einer BIA ist die Identifikation der kritischen Geschäftsbereiche des Unternehmens. Dieser Schritt kann soweit detailliert und verfeinert werden, um jene kritischen Tätigkeiten festzustellen, die durchgeführt werden müssen, um den Fortbestand des Business zu gewährleisten.

Bewertung der Störanfälligkeit (Vulnerability Assessment)

Analyse der zusammengestellten Informationen: In dieser Phase werden die relevanten Prozesse dokumentiert, Wechselbeziehungen identifiziert und die akzeptable Unterbrechungszeit ermittelt. Die Phase beinhaltet

• Identifizierung von Wechselbeziehungen zwischen Funktionen und Geschäftsbereichen

• Aufdecken aller möglichen Störungen und Unterbrechungen, welche die Geschäftsbereiche in ihrer Zusammenarbeit behindern

• Identifizierung und Dokumentation potentieller Bedrohungen, welche die Kommunikation zwischen den Geschäftsbereichen unterbrechen können

• Sammlung von qualitativen und quantitativen Informationen in Bezug auf diese Bedrohungen

• Bereitstellen von alternativen Methoden, um Funktionalitäten und Kommunikation wieder herstellen zu können

• Dokumentation des Ergebnisses und Präsentation der Empfehlungen

Lessons Learned

Am Ende des Incident-Response-Prozesses wird ein Bericht erstellt, aus dem hervorgeht, was passiert ist, welche Maßnahmen gesetzt wurden und die Ergebnisse dokumentiert, nachdem der Incident Response Plan ausgeführt wurde. Der Plan sollte die „Lessons Learned“ beinhalten, die dem IMT und anderen Stakeholdern wertvolle Hinweise zur Verbesserung liefern können. Diese Hinweise sollten ebenso in die Weiterentwicklung des Incident Response Plans aufgenommen werden, um die Leistungsfähigkeit des Incident Management zu erhöhen. Aktivitäten in dieser Phase sind

• Erstellen eines Incident-Berichts
• Analysieren auf Probleme während der Incident-Response-Aktivitäten
• Entwickeln von Verbesserungsvorschlägen auf Basis der erkannten Probleme
• Präsentation des Berichts vor den relevanten Stakeholdern

Phasen eines Incident Response Plans

Regelmäßige Anpassung des Incident Response Plans und Recovery Plans

Durch die Dynamik von Organisationen und stetigen Veränderungen müssen auch die Response und Recovery Plans regelmäßig angepasst werden, um den aktuellen Zielen und Ansprüchen des Unternehmens zu entsprechen. Dabei ist es wichtig, die Zustimmung und Rückendeckung des Senior Managements für den Prozess der regelmäßigen Anpassung zu erhalten, da dieser fortlaufende Prozess Unternehmensressourcen beansprucht um ein akzeptables Niveau der Wiederherstellungsfähigkeiten zu erreichen und zu erhalten.

Regelmäßige Tests und Training

Das Testen aller Aspekte der Notfallpläne ist der wichtigste Faktor für die erfolgreiche Bewältigung einer Notfallsituation. Durch das Testen soll sichergestellt werden, dass die Ausführung des Plans zu einer erfolgreichen Wiederherstellung der Infrastruktur und Wiederaufnahme kritischer Geschäftsprozesse führt. Bei Response-und-Recovery-Plänen, die nicht getestet wurden, bleibt eine gewisse Unsicherheit, ob diese Pläne auch tatsächlich funktionieren. Jeder Test sollte mit folgenden Aktivitäten in Form eines Kreislaufes aufgebaut werden.

• Entwickeln und Festlegen der Ziele des Tests
• Ausführung des Tests
• Evaluierung des Testablaufs und der Testergebnisse
• Entwickeln von Empfehlungen um die Effektivität der Testprozesse und damit der Response-und-Recovery-Pläne zu verbessern
• Implementierung eines Follow-Up-Prozesses, um die Umsetzung der Empfehlungen zu prüfen

Kreislauf: Ablauf von Aktivitäten bei Tests

Jeder Test sollte den Fokus auf das Identifizieren von Schwachstellen, das Prüfen und Bestätigen von Vermutungen, das Testen der Einhaltung von Zeiten, die Effektivität der entwickelten Strategien, die Leistungen der beteiligten Personen und die Vollständigkeit und Aktualität der Informationen aus den Plänen richten.

Tests fördern die Zusammenarbeit und die Koordination innerhalb des Teams und stellen ein nützliches Trainingswerkzeug dar. Deshalb führen viele Organisationen jährlich vollständige Wiederherstellungstests durch.

Nach der Fertigstellung von Entwurfs- oder Ergänzungsplänen sowie bei Änderungen, die das Schlüsselpersonal betreffen, bei Änderungen in der eingesetzten Technologie oder im Umfeld des Business oder den Regelwerken sollten entsprechende Tests durchgeführt werden.

Das Testen muss sorgfältig geplant und kontrolliert durchgeführt werden, da das Testen einerseits Zeit und Ressourcen in Anspruch nimmt, und andererseits, um das Business nicht erhöhten Risiken auszusetzen. Vor jedem Test sollte der Information Security Manager darauf achten, dass das Risiko und die Unterbrechung durch das Testen minimiert werden, das Business über das entsprechende Risiko informiert ist und dieses akzeptiert, Vorbereitungen für den Rückstieg (Fallback) zu jedem Zeitpunkt des Tests existieren. Um die regelmäßige Durchführung von Tests aller Pläne zu gewährleisten, sollte ein Testplan mit dem Datum des geplanten Tests für alle kritischen Funktionen erstellt und gewartet werden. Alle Tests müssen durchgehend mit Pre-Test-, Test- und Post-Test- Berichten dokumentiert werden und diese Dokumentationen sollten für Audits etc. aufbewahrt werden. Darüber hinaus muss der Information Security Manager sicherstellen, dass die Sicherheit von Informationen während der Tests nicht gefährdet wird, sondern mitgetestet wird.

Arten von Tests

Das Testen sollte einfach beginnen und stufenweise durch Erweitern der Ziele und Erfolgskriterien gesteigert werden, um das Vertrauen des Business in die Tests zu stärken und Risiken für das Business zu vermindern.

• Prüfen von Checklisten: Sollte als einleitender Schritt für Tests durchgeführt werden. Bestehende Checklisten werden an alle Mitglieder des Recovery Teams zur Prüfung auf Aktualität verteilt.
• Strukturiertes Durchgehen: Teammitglieder führen den Plan auf Papier aus und prüfen jeden Schritt auf seine Effektivität und identifizieren Verbesserungen, Einschränkungen oder Mängel.
• Simulationstests: Das Recovery Team spielt ein vorbereitetes Notfallszenario mit entsprechenden Rollenverteilungen durch, ohne jedoch die Wiederherstellungseinrichtungen zu aktivieren.
• Paralleltests: Die Wiederherstellungseinrichtungen werden in einen aktiven Betriebszustand gebracht, wobei die primären Einrichtungen ihre Arbeit normal fortsetzen.
• Tests mit vollständiger Unterbrechung: Der Betrieb der primären Einrichtungen wird eingestellt (unterbrochen) und nach dem Recovery Plan in der Wiederherstellungseinrichtung wieder aufgenommen. Dies ist zwar die am meisten rigorose Art zu testen, aber gleichzeitig auch die teuerste und risikoreichste. Ein Test mit voller Unterbrechung sollte jährlich durchgeführt werden, nachdem alle einzelnen Komponenten des Plans separat erfolgreich getestet wurden.

Stufenweises Durchführen der Testarten

Tests, vor allem jene mit Unterbrechungen des Normalbetriebs, sollten zu Zeiten eingeplant werden, an denen der normale Geschäftsbetrieb so wenig wie möglich beeinträchtigt wird. Wochenenden und Feiertage können dafür eine gute Wahl sein. Es ist wichtig, dass alle Schlüsselpersonen des Recovery Teams im Testprozedere involviert sind und dem Team auch ausreichend Zeit für die Durchführung der Tests zugeteilt wird. Für realistische Ergebnisse sollte der Test alle kritischen Komponenten abdecken und Bedingungen des Betriebs zu Spitzenzeiten simulieren, auch wenn der Test außerhalb der Betriebszeiten durchgeführt wird.

Results

Ziele

Incident Management wird eingeführt, um unausweichliche Ereignisse zu behandeln, die den Betrieb jeder Organisation gefährden. Daher werden bei der Planung und Einführung von Incident Management bestimmte Ziele verfolgt. Die Behandlung von eintretenden Incidents muss so erfolgen, dass die Auswirkungen eingedämmt werden, um eine Wiederherstellung innerhalb der AIW (Acceptable Interruption Window) zu ermöglichen. Durch Dokumentation und Lerneffekte vergangener Incidents soll verhindert werden, dass diese früher aufgetretenen Incidents wieder auftreten. Proaktive Gegenmaßnahmen müssen entwickelt und ausgerollt werden, um das Eintreten von Incidents zu verhindern oder die Eintrittswahrscheinlichkeit zu mindern. Incident Management und Response muss die Behandlung einer breiten Palette an möglichen, unerwarteten Ereignissen abdecken. Dafür müssen entsprechende Überwachungsfunktionen auf technischer oder prozessualer Ebene entwickelt und eingesetzt werden, damit potentielle Probleme möglichst früh erkannt werden können. Das Personal muss ausreichend geschult und trainiert werden, um Situationen richtig einschätzen und die Handlungsreihenfolge festlegen zu können, effektive Reaktionen für die Aufrechterhaltung des Betriebs setzen zu können und die Auswirkungen zu minimieren.

Kennzahlen

Kennzahlen sind wichtige Kriterien, um die Effektivität und Effizienz des Incident Managements zu messen. Sie basieren auf Key Performance Indicators (MAPs) und Zielen des Programs für das Incident Management und sollten dem Senior Management als Basis für eine nachhaltige Unterstützung (regelmäßig) präsentiert werden. Berichte über Maßzahlen des Incident Managements sind auch als Werkzeug zur Selbstüberprüfung des IMT nötig, damit ein Verständnis geschaffen wird, was zufriedenstellend läuft, oder wo Verbesserungen nötig sind.

Übliche Kriterien für Kennzahlen des Incident Managements sind:

• Anzahl der gemeldeten Incidents

• Anzahl der entdeckten Incidents

• Durchschnittliche Reaktionszeit auf einen Incident in Relation zum Acceptable Interruption Window (AIW, ist die maximale Zeitspanne die ein System ausfallen darf, bevor die Geschäftstätigkeiten gefährdet sind)

• Durchschnittliche Lösungszeit

• Anzahl der erfolgreich gelösten Incidents

• Anzahl der gesetzten proaktiven und präventiven Maßnahmen

• Anzahl der Mitarbeiter, die an Security Awareness Trainings teilnahmen

• Gemessener Schaden von gemeldeten und entdeckten Incidents, wenn die Incidents nicht behandelt wurden

• Einsparung von potentiellem Schaden durch gelöste Incidents

Wiederholungsaufgaben

1. Beschreiben Sie kurz die Phasen eines Incident Response Plans!
2. Welche Aktivitäten sollen beim Testen der Detailpläne für Incident Response und Recovery durchgeführt werden?
3. Nennen Sie fünf Kriterien für Kennzahlen des Incident Managements! Beschreiben Sie kurz, warum der Einsatz von Kennzahlen wichtig ist?