Informationssicherheitsmanagement - ISIM Ablauf - Versionsgeschichte

JUNGBAUER Christoph am 20. Jänner 2022 um 08:31 Uhr

2022-01-20T08:31:04Z

← Nächstältere Version		Version vom 20. Jänner 2022, 08:31 Uhr
Zeile 333:		Zeile 333:
	# Welche Aktivitäten sollen beim Testen der Detailpläne für Incident Response und Recovery durchgeführt werden?		# Welche Aktivitäten sollen beim Testen der Detailpläne für Incident Response und Recovery durchgeführt werden?
	# Nennen Sie fünf Kriterien für Kennzahlen des Incident Managements! Beschreiben Sie kurz, warum der Einsatz von Kennzahlen wichtig ist?		# Nennen Sie fünf Kriterien für Kennzahlen des Incident Managements! Beschreiben Sie kurz, warum der Einsatz von Kennzahlen wichtig ist?

			<br><hr><br>
			#''Beschreiben Sie kurz die Phasen eines Incident Response Plans!''
			#:'''Vorbereitung''': In dieser Phase werden Vorbereitungen in der Organisation getroffen, um den Incident Response Plan zu entwickeln, denn eine ausreichende Vorbereitung erleichtert die spätere Umsetzung.
			#:'''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.
			#:'''Eindämmung''': Nachdem ein Security Incident identifiziert und bestätigt wurde, wird das 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.
			#:'''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.
			#:'''Wiederherstellung''': Diese Phase stellt sicher, dass betroffene Systeme oder Services nach den definierten RPOs wiederhergestellt werden.
			#:'''Lessons Learned''': Am Ende des Incident Response Prozesses sollte immer ein Bericht erstellt werden, aus dem hervorgeht, was passiert ist, welche Maßnahmen gesetzt wurden und die Ergebnisse, 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.
			#''Welche Aktivitäten sollen beim Testen der Detailpläne für Incident Response und Recovery durchgeführt werden?''
			#:Jeder Test sollten 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
			#''Nennen Sie fünf Kriterien für Kennzahlen des Incident Managements! Beschreiben Sie kurz, warum der Einsatz von Kennzahlen wichtig ist?''
			#:Kennzahlen sind wichtige Kriterien, um die Effektivität und Effizienz des Incident Managements zu messen. Sie 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.
			#:5 Kriterien für Kennzahlen des Incident Managements sind:
			#:* Anzahl der gemeldeten Incidents
			#:* Durchschnittliche Lösungszeit
			#:* Anzahl der erfolgreich gelösten Incidents
			#:* Gemessener Schaden von gemeldeten und entdeckten Incidents, wenn die Incidents nicht behandelt wurden
			#:* Einsparung von potentiellem Schaden durch gelöste Incidents

KLAUSNER Daniela am 14. Jänner 2022 um 08:42 Uhr

2022-01-14T08:42:28Z

KLAUSNER Daniela am 14. Jänner 2022 um 08:27 Uhr

2022-01-14T08:27:17Z

KLAUSNER Daniela am 14. Jänner 2022 um 08:13 Uhr

2022-01-14T08:13:51Z

Änderungen zeigen

KLAUSNER Daniela am 14. Jänner 2022 um 07:53 Uhr

2022-01-14T07:53:05Z

KLAUSNER Daniela am 13. Jänner 2022 um 20:07 Uhr

2022-01-13T20:07:10Z

← Nächstältere Version		Version vom 13. Jänner 2022, 20:07 Uhr
Zeile 48:		Zeile 48:
	===== Planung der Wiederherstellung und Business Recovery Prozesse =====		===== 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.		Die/der Information Security Manager*in 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.		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.
Zeile 62:		Zeile 62:
	'''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.		'''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.		'''Mobile Sites''' sind spezielle Fahrzeuge oder Anhänger, die rasch an einen Geschäftsstandort oder andere Standorte gebracht werden können. Diese sind 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.		'''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. Typischerweise 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.		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.

KLAUSNER Daniela am 13. Jänner 2022 um 19:55 Uhr

2022-01-13T19:55:42Z

JUNGBAUER Christoph am 12. Jänner 2022 um 10:15 Uhr

2022-01-12T10:15:35Z

← Nächstältere Version		Version vom 12. Jänner 2022, 10:15 Uhr
Zeile 6:		Zeile 6:
	<li><p>Kennenlernen des Ablaufs der Prozesse Incident Management und Incident Response für das Management und die Abhandlung von sicherheitsrelevanten Incidents bis hin zu Notfallsituationen</p></li>		<li><p>Kennenlernen des Ablaufs der Prozesse Incident Management und Incident Response für das Management und die Abhandlung von sicherheitsrelevanten Incidents bis hin zu Notfallsituationen</p></li>
	<li><p>Darstellung der Phasen eines Incident Response Plans</p></li>		<li><p>Darstellung der Phasen eines Incident Response Plans</p></li>
	<li><p>Diskussion von kritischen Erfolgsfaktoren</p>		<li><p>Diskussion von kritischen Erfolgsfaktoren</p></li>
	</ul>		</ul>

	== Process ==		== Process ==

Zeile 203:		Zeile 204:
	* Dokumentieren von und Sicherungen erstellen bei Aktivitäten von dieser Phase an		* Dokumentieren von und Sicherungen erstellen bei Aktivitäten von dieser Phase an
	* Steuern der Kommunikation gegenüber der Öffentlichkeit durch das PR Team		* 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.		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.

Zeile 224:		Zeile 224:
	* Testen der Systeme durch die Systemverantwortlichen		* Testen der Systeme durch die Systemverantwortlichen
	* Unterstützung der Systemverantwortlichen bei der Bekanntgabe des Normalbetriebs		* 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.		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.

Zeile 236:		Zeile 235:
	* ''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.		* ''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.		* ''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:		Der Prozess einer BIA besteht aus folgenden Aktivitäten:

Zeile 251:		Zeile 249:
	<li><p>Sammlung von qualitativen und quantitativen Informationen in Bezug auf diese Bedrohungen</p></li>		<li><p>Sammlung von qualitativen und quantitativen Informationen in Bezug auf diese Bedrohungen</p></li>
	<li><p>Bereitstellen von alternativen Methoden, um Funktionalitäten und Kommunikation wieder herstellen zu können</p></li>		<li><p>Bereitstellen von alternativen Methoden, um Funktionalitäten und Kommunikation wieder herstellen zu können</p></li>
	<li><p>Dokumentation des Ergebnisses und Präsentation der Empfehlungen</p></li></ul>		<li><p>Dokumentation des Ergebnisses und Präsentation der Empfehlungen</p></li>
			</ul>

	===== Lessons Learned =====		===== Lessons Learned =====
Zeile 261:		Zeile 260:
	* Entwickeln von Verbesserungsvorschlägen auf Basis der erkannten Probleme		* Entwickeln von Verbesserungsvorschlägen auf Basis der erkannten Probleme
	* Präsentation des Berichts vor den relevanten Stakeholdern		* Präsentation des Berichts vor den relevanten Stakeholdern
			[[Datei:IM423 8.png\|300px\|none\|thumb\|Phasen eines Incident Response Plans]]
	[[~~File~~:~~media/image16~~.png\|~~492x441px]]~~

	~~<span id="_Toc384634259" class="anchor"></span>Abb. 4.1:~~ Phasen eines Incident Response Plans

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

Zeile 279:		Zeile 274:
	* Entwickeln von Empfehlungen um die Effektivität der Testprozesse und damit der Response-und-Recovery-Pläne zu verbessern		* 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		* Implementierung eines Follow-Up-Prozesses, um die Umsetzung der Empfehlungen zu prüfen
			[[Datei:IM423 9.png\|300px\|none\|thumb\|Kreislauf: Ablauf von Aktivitäten bei Tests]]
	[[~~File~~:~~media/image17~~.png\|~~402x383px]]~~

	~~<span id="_Toc384634260" class="anchor"></span>Abb. 4.2:~~ 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.		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.
Zeile 301:		Zeile 293:
	* Paralleltests: Die Wiederherstellungseinrichtungen werden in einen aktiven Betriebszustand gebracht, wobei die primären Einrichtungen ihre Arbeit normal fortsetzen.		* 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.		* 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.
			[[Datei:IM423 10.png\|300px\|none\|thumb\|Stufenweises Durchführen der Testarten]]
	[[~~File~~:~~media/image18~~.png\|~~548x192px]]~~

	~~<span id="_Toc384634261" class="anchor"></span>Abb. 4.3:~~ 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.		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.
Zeile 313:		Zeile 302:

	=== Ziele ===		=== Ziele ===
	~~</li></ol>~~
	~~</li></ol>~~

	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.		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.
Zeile 333:		Zeile 322:
	<li><p>Anzahl der Mitarbeiter, die an Security Awareness Trainings teilnahmen</p></li>		<li><p>Anzahl der Mitarbeiter, die an Security Awareness Trainings teilnahmen</p></li>
	<li><p>Gemessener Schaden von gemeldeten und entdeckten Incidents, wenn die Incidents nicht behandelt wurden</p></li>		<li><p>Gemessener Schaden von gemeldeten und entdeckten Incidents, wenn die Incidents nicht behandelt wurden</p></li>
	<li><p>Einsparung von potentiellem Schaden durch gelöste Incidents</p>		<li><p>Einsparung von potentiellem Schaden durch gelöste Incidents</p></li>
	</ul>		</ul>

	== Wiederholungsaufgaben ==		== Wiederholungsaufgaben ==

JUNGBAUER Christoph: Die Seite wurde neu angelegt: „= 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 === ==== B…“

2022-01-12T10:13:45Z

Die Seite wurde neu angelegt: „= Information Security Incident Management – Ablauf = '''Ziele der Lektion''' <ul> <li>Kennenlernen des Ablaufs der Prozesse Incident Management und Incident Response für das Management und die Abhandlung von sicherheitsrelevanten Incidents bis hin zu Notfallsituationen</li> <li>Darstellung der Phasen eines Incident Response Plans</li> <li>Diskussion von kritischen Erfolgsfaktoren </ul> == Process == === Aktivitäten === ==== B…“

Änderungen zeigen

← Nächstältere Version		Version vom 14. Jänner 2022, 08:42 Uhr
Zeile 284:		Zeile 284:
	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.		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.		Das Testen muss sorgfältig geplant und kontrolliert durchgeführt werden, da das Testen einerseits Zeit und Ressourcen in Anspruch nimmt, andererseits, um das Business nicht erhöhten Risiken auszusetzen. Vor jedem Test sollte die/der Information Security Managerin 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 die/der Information Security Managerin sicherstellen, dass die Sicherheit von Informationen während der Tests nicht gefährdet wird, sondern mitgetestet wird.

	=== Arten von Tests ===		=== Arten von Tests ===
Zeile 307:		Zeile 307:


	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.		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 eintretenen 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 ===

	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.		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:		Übliche Kriterien für Kennzahlen des Incident Managements sind:
Zeile 322:		Zeile 322:
	<li><p>Anzahl der erfolgreich gelösten Incidents</p></li>		<li><p>Anzahl der erfolgreich gelösten Incidents</p></li>
	<li><p>Anzahl der gesetzten proaktiven und präventiven Maßnahmen</p></li>		<li><p>Anzahl der gesetzten proaktiven und präventiven Maßnahmen</p></li>
	<li><p>Anzahl der Mitarbeiter, die an Security Awareness Trainings teilnahmen</p></li>		<li><p>Anzahl der Mitarbeiter*innen, die an Security Awareness Trainings teilnahmen</p></li>
	<li><p>Gemessener Schaden von gemeldeten und entdeckten Incidents, wenn die Incidents nicht behandelt wurden</p></li>		<li><p>Gemessener Schaden von gemeldeten und entdeckten Incidents, wenn die Incidents nicht behandelt wurden</p></li>
	<li><p>Einsparung von potentiellem Schaden durch gelöste Incidents</p></li>		<li><p>Einsparung von potentiellem Schaden durch gelöste Incidents</p></li>

← Nächstältere Version		Version vom 14. Jänner 2022, 08:27 Uhr
Zeile 186:		Zeile 186:
	===== Identifikation =====		===== 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		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, Endanwender*innen 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)		* Zuweisen des (potentiellen) Incidents an eine/n Bearbeiter*in (Incident Handler)
	* Prüfen, dass es sich bei dem gemeldeten Ereignis um einen Security Incident handelt		* 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		* Festlegen einer Kontroll- oder Überwachungskette während der Identifikation, wenn mögliche Beweise gesichert werden müssen
Zeile 195:		Zeile 195:
	===== Eindämmung =====		===== 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		Nachdem ein Security Incident identifiziert und bestätigt wurde, wird das Incident Management Team (IMT) aktiviert und die Informationen, die die/der Incident Handler gesammelt hat, im Team verteilt. Das Team führt daraufhin eine detaillierte Beurteilung und Bewertung durch. Es informiert die/den Systemverantwortlichen oder Business Managerin ü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		* Aktivierung des IMT, um den Incident zu beurteilen und einzudämmen
	* Benachrichtigung der Stakeholder, welche von dem Incident betroffen sind		* 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		* Zustimmung für Aktivitäten, welche die Verfügbarkeit eines IT Services beeinflussen können oder für Risiken, die aus den 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		* Zusammenführen der involvierten IT Expert*innen und relevanten Mitglieder des virtuellen Teams, um die Prozeduren für die Eindämmung durchzuführen
	* Einholen und Sichern von möglichen Beweisen		* Einholen und Sichern von möglichen Beweisen
	* Dokumentieren von und Sicherungen erstellen bei Aktivitäten von dieser Phase an		* Dokumentieren von und Sicherungen erstellen bei Aktivitäten von dieser Phase an
	* Steuern der Kommunikation gegenüber der Öffentlichkeit durch das PR Team		* 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.		Im Incident Response Plan müssen Voraussetzungen für die Benachrichtigung von Schlüsselpersonen und Entscheidungsträgerinnen, Systemverantwortlichen und Endanwenderinnen 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 Mitarbeiter*innen des Betriebs, Telefonnummern von Behörden und Personen mit gesetzlichen Durchsetzungsrechten im Falle schwerwiegender Sicherheitszwischenfällen, beinhalten.

	===== Beseitigung =====		===== 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		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, einfaches Beheben der Ursache oder Verstärken der Abwehrmechanismen und Durchführen von Schwachstellenanalysen (Vulnerability Analysis), um weitere mögliche Schadenspotentiale durch die gleiche Ursache zu verhindern. Aktivitäten in dieser Phase sind

	* Bestimmen der Symptome und der Ursache eines Incidents		* Bestimmen der Symptome und der Ursache eines Incidents
Zeile 224:		Zeile 224:
	* Testen der Systeme durch die Systemverantwortlichen		* Testen der Systeme durch die Systemverantwortlichen
	* Unterstützung der Systemverantwortlichen bei der Bekanntgabe des Normalbetriebs		* 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.		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 setzen 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 zusammen. 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.		Die/der Information Security Manager*in 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.		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 Interessensvertreterinnen hilft, zu verstehen, welche Auswirkung ein Incident auf das Business und die 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 Endanwenderinnen benötigt.

	Eine BIA verfolgt drei Ziele:		Eine BIA verfolgt drei Ziele:
Zeile 254:		Zeile 254:
	===== Lessons Learned =====		===== 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		Am Ende des Incident-Response-Prozesses wird ein Bericht erstellt, aus dem hervorgeht, was passiert ist, welche Maßnahmen gesetzt und die Ergebnisse dokumentiert wurden, 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		* Erstellen eines Incident-Berichts

← Nächstältere Version		Version vom 14. Jänner 2022, 07:53 Uhr
Zeile 78:		Zeile 78:
	Team für Notfalleinsatz: Besteht z.B. aus Feuerwarten, deren Funktion die Behandlung von Ereignissen mit Feuer oder anderen Notfallszenarios ist.		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 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 Notfall Management: Ist verantwortlich für die Koordination der Aktivitäten aller anderen Recovery Teams und trifft relevante Entscheidungen.
Zeile 88:		Zeile 88:
	===== Voraussetzungen für Benachrichtigungen =====		===== 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.		Der Plan muss die Voraussetzungen für die Benachrichtigung von Schlüsselpersonen und Entscheidungsträgerinnen, Systemverantwortlichen und Endanwenderinnen 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 Mitarbeiter*innen des Betriebs, Telefonnummern von Behörden und Personen mit gesetzlichen Durchsetzungsrechten im Falle schwerwiegender Sicherheitszwischenfällen.

	===== Betriebsmittel =====		===== 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.		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 vom Personal befolgt werden können, die mit dem Wiederherstellungsablauf nicht vertraut sind. Dies dient dazu, 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 =====		===== Versicherungen =====
Zeile 104:		Zeile 104:
	===== Wiederherstellungspläne und Informationssicherheit =====		===== 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.		Es ist wichtig, dass die Informationsressourcen auch bei notfallbedingt chaotischen Verhältnissen geschützt bleiben. Die/der Information Security Managerin muss sicherstellen, dass die Informationssicherheit bei allen Response und Recovery Plänen entsprechend berücksichtigt ist. Die/der Information Security Managerin 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 ====		==== 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.		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 Regisseurin, die Aufgaben innerhalb der Pläne koordinieren, ihre Ausführung überblicken und überwachen, mit dem Senior Management eng zusammenarbeiten und nötige Entscheidungen treffen. Die/der Information Security Managerin kann, muss aber nicht, diese Rolle der/des Recovery-Plan-Koordinator*in übernehmen, muss aber zumindest sicherstellen, dass diese Rolle einer geeigneten Person zugeteilt wird.

	===== Eskalationsprozess =====		===== 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.		Die/der Information Security Managerin 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 dem Senior Management (hierarchische Eskalation). Darüber hinaus könnten spezielle Recovery Teams, Versicherungen, Hersteller etc. benachrichtigt werden (fachliche Eskalation). Die/der Information Security Managerin sollte einen Kommunikationsplan in Zusammenarbeit mit PR-Abteilung, Rechtsberatung und Senior Management entwickeln, um eine angemessene Informationsweitergabe zu gewährleisten.

	===== Policies und Prozesse für Intrusion Detection (ID) =====		===== Policies und Prozesse für Intrusion Detection (ID) =====

← Nächstältere Version		Version vom 13. Jänner 2022, 19:55 Uhr
Zeile 15:		Zeile 15:
	==== Bestimmung der bestehenden Möglichkeiten, um auf Incidents zu reagieren ====		==== 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.		Die meisten Unternehmen haben bereits Methoden und Vorgehen etabliert, um entweder ad hoc oder formal auf Incidents zu reagieren. Die/der Information Security Manager*in 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.		'''Umfragen / Interviews''' von Senior Management, Business Manager*innen, 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 '''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 Interessensvertreterinnen 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 Interessensvertreterinnen 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.		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.
Zeile 25:		Zeile 25:
	==== Entwickeln eines Incident Response Plans ====		==== 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.		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 ====		==== 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.		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 des Business Continuity- und Disaster Recovery Plans zu schaffen.

	===== Organisation, Training und Ausrüsten des Response Personals =====		===== 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.		Das Training des Response Teams ist unerlässlich. Die/der Information Security Manager*in 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 sowie ineffiziente Recovery-Maßnahmen erkannt und verbessert werden können.

	Die Mitglieder des IMT sollten ein Trainingsprogramm mit mehreren Phasen durchlaufen.		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.		* Einführung in das IMT: Während der Einführung werden die grundlegenden und wichtigsten Informationen für effektives IMT 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.		* 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.		* 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.