Informationssicherheitsmanagement - ISIM Aufbau - Versionsgeschichte

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

2022-01-20T08:28:02Z

← Nächstältere Version		Version vom 20. Jänner 2022, 08:28 Uhr
Zeile 275:		Zeile 275:
	# Nennen Sie vier Bespiele für Recovery Sites und beschreiben Sie diese kurz!		# Nennen Sie vier Bespiele für Recovery Sites und beschreiben Sie diese kurz!
	# Was bedeutet RACI?		# Was bedeutet RACI?

			<br><hr><br>
			#''Beschreiben Sie kurz was ein IMS ist, wie ein IMS im Incident Management und Incident Response unterstützen kann und welche Anforderungen an ein IMS gestellt werden!''
			#:Incident Management Systeme können viele von manuell durchgeführten Prozessen unterstützen oder sogar automatisieren, indem Incidents über deren kompletten Lebenszyklus überwacht werden. Das verhindert einerseits, dass Incidents übersehen werden und gewährleistet andererseits, dass Incidents hinsichtlich ihrer Priorität entsprechend behandelt werden. Durch den Einsatz eines Incident Management Systems können auch Einsparungen im operativen Bereich und bei den Wiederherstellungskosten erzielt werden. Ein Incident Management System sollte Inputs von unterschiedlichen Systemen konsolidieren und in Bezug setzen können, potentielle Incidents erkennen und identifizieren können, Incidents anhand der Auswirkung auf das Business priorisieren können, Incidents über den Lebenszyklus hinweg überwachen, bis sie geschlossen werden, Information und Benachrichtigungen über den aktuellen Status des Incidents bieten, mit den wichtigsten IT Management Systemen integriert werden können, konform mit Good oder Best Practices sein.
			#''Nennen Sie vier Bespiele für Recovery Sites und beschreiben Sie diese kurz!''
			#:'''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.
			#:'''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.
			#:Weitere siehe Aufzählungsliste im Kapitel Recovery Sites.
			#''Was bedeutet RACI?''
			#:Das RACI-Modell wird zur Darstellung von Verantwortlichkeiten von Rollen für Prozessaktivitäten verwendet, wobei die Art der Verantwortlichkeit in vier Grundformen unterschieden werden kann:
			#:* R – Responsible: durchführungsverantwortlich
			#:* A – Accountable: ergebnisverantwortlich
			#:* C – Consulted: beratend
			#:* I – Informed: Informiert

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

2022-01-13T20:00:24Z

← Nächstältere Version		Version vom 13. Jänner 2022, 20:00 Uhr
Zeile 138:		Zeile 138:
	! style="width: 140.756px;" \| Gruppe von Mitgliedern des Senior Managements		! style="width: 140.756px;" \| Gruppe von Mitgliedern des Senior Managements
	! style="width: 516.119px;" \| <ul>		! style="width: 516.119px;" \| <ul>
	<li><p style="text-align: left;" >Ist für die Genehmigung der strategischen Ausrichtung des Incident Management verantwortlich</p></li>		<li><p style="text-align: left;">Ist für die Genehmigung der strategischen Ausrichtung des Incident Management verantwortlich</p></li>
	<li><p style="text-align: left;" >Dient als Eskalationsstelle für das Incident Management Team</p></li>		<li><p style="text-align: left;">Dient als Eskalationsstelle für das Incident Management Team</p></li>
	<li><p style="text-align: left;" >Genehmigt Abweichungen und Ausnahmen zu den definierten, standardisierten Verfahren des Incident Management und Incident Response</p></li>		<li><p style="text-align: left;">Genehmigt Abweichungen und Ausnahmen zu den definierten, standardisierten Verfahren des Incident Management und Incident Response</p></li>
	</ul>		</ul>
	\|-		\|-
Zeile 189:		Zeile 189:
	</ul>		</ul>
	\|}		\|}
	~~Tab. 3.~~1: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 1)		Tabelle 1: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 1)

	[CIS10, S252]		[CIS10, S252]

	{\| class="wikitable" style="border-collapse: collapse;"		{\| class="wikitable" style="border-collapse: collapse;"
	! width="14%" \| Business Manager*innen (Mitglieder der Fachbereiche)		! width="14%" \| Business Manager*innen (Mitglieder der Fachbereiche)
	! width="18%" \| Verantwortliche für Fachbereiche		! width="18%" \| Verantwortliche für Fachbereiche
Zeile 199:		Zeile 199:
	Prozess- oder Systemver-antwortliche		Prozess- oder Systemver-antwortliche
	! width="66%" \| <ul>		! width="66%" \| <ul>
	<li><p style="text-align: left;" >Trifft im Falle eines Incidents Entscheidungen, die den Prozess oder System betreffen, auf Basis der Empfehlungen des IMT/IRT</p></li>		<li><p style="text-align: left;">Trifft im Falle eines Incidents Entscheidungen, die den Prozess oder System betreffen, auf Basis der Empfehlungen des IMT/IRT</p></li>
	<li><p style="text-align: left;" >Unterstützt mit Wissen über die Auswirkungen eines Incidents auf das Business im Prozess der BIA oder im Incident Response Plan</p></li>		<li><p style="text-align: left;">Unterstützt mit Wissen über die Auswirkungen eines Incidents auf das Business im Prozess der BIA oder im Incident Response Plan</p></li>
	</ul>		</ul>
	\|-		\|-
Zeile 242:		Zeile 242:
	</ul>		</ul>
	\|}		\|}
	~~Tab. 3.~~2: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 2)		Tabelle 2: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 2)

	[CIS10, S252]		[CIS10, S252]

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

2022-01-13T19:46:28Z

Änderungen zeigen

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

2022-01-13T19:34:54Z

Änderungen zeigen

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

2022-01-13T19:20:56Z

Änderungen zeigen

JUNGBAUER Christoph: Die Seite wurde neu angelegt: „= Information Security Incident Management – Aufbau = '''Ziele der Lektion'''

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

Kennenlernen von Konzepten für die Wiederherstellung

Vorstellen der für die Prozesse benötigten Bausteine, Rollen und Verantwortlichkeiten

2022-01-12T10:08:45Z

Die Seite wurde neu angelegt: „= Information Security Incident Management – Aufbau = '''Ziele der Lektion''' <ul> <li>Kennenlernen des Aufbaus der Prozesse Incident Management und Incident Response für das Management und die Abhandlung von sicherheitsrelevanten Incidents bis hin zu Notfallsituationen</li> <li>Kennenlernen von Konzepten für die Wiederherstellung</li> <li>Vorstellen der für die Prozesse benötigten Bausteine, Rollen und Verantwortlichkeiten </…“

Neue Seite
= Information Security Incident Management – Aufbau =

'''Ziele der Lektion'''

<ul>
<li>Kennenlernen des Aufbaus der Prozesse Incident Management und Incident Response für das Management und die Abhandlung von sicherheitsrelevanten Incidents bis hin zu Notfallsituationen</li>
<li>Kennenlernen von Konzepten für die Wiederherstellung</li>
<li>Vorstellen der für die Prozesse benötigten Bausteine, Rollen und Verantwortlichkeiten
</ul>
== Incident Management & Incident Response ==

Incident Management ist nach ITIL v3 jener Prozess, der für die Verwaltung des Lebenszyklus aller Incidents verantwortlich ist. Wichtigstes Ziel des Incident Management ist eine schnellstmögliche Wiederherstellung des IT Services für die Anwender. Im Rahmen des Incident Managements wird sichergestellt, dass Vorfällen, welche den laufenden Betrieb und damit Geschäftsprozesse beeinträchtigen können, auf effektive und effiziente Art und Weise begegnet wird. Dafür gewährleistet das Incident Management, dass solche Vorfälle erkannt, dokumentiert und derart behandelt werden, damit die Auswirkungen der Vorfälle und die damit verbunden Beeinträchtigungen minimiert werden.

Incident Response stellt einen strukturierten Ansatz dar, um auf einen sicherheitsrelevanten Vorfall „richtig“ zu reagieren und somit die Auswirkungen eines über einen „üblichen“ Vorfall hinausgehenden sicherheitsrelevanten zu bewältigen. Das Ziel ist es, die Situation derart zu behandeln, dass der hervorgerufene Schaden eines Incidents in Grenzen gehalten wird und die Wiederherstellungszeit und erforderlichen Kosten minimiert werden. Incident Response stellt damit den operativen Teil des Incident Management dar, in dem auf Vorfälle reagiert wird.

Die Ziele der Aktivitäten im Incident Management und Incident Response können zusammengefasst werden als:

* Vorfälle / Incidents rasch erkennen
* Incidents sorgfältig und präzise diagnostizieren
* Incidents entsprechend handhaben und bewältigen
* Schaden eindämmen und minimieren
* Betroffene Services wiederherstellen
* Ursachen der Vorfälle bestimmen
* Verbesserungen implementieren, um ein Wiederauftreten zu verhindern

Vorfälle der Informationssicherheit nehmen in Unternehmen eine Sonderstellung ein, da sie den Fortbestand des Unternehmens gefährden können (z.B. Abhandenkommen von Unternehmenswissen, Vertrauensverlust durch Verlust von kundenrelevanten Daten etc.). Dabei muss auch die Möglichkeit von Incidents mit nicht technischem Hintergrund in Betracht gezogen werden. Vorgehen, um diesen Vorfällen effektiv und effizient begegnen zu können, müssen daher sorgfältig geplant werden. Um Incident Management und Incident Response in adäquater Weise implementieren und durchführen zu können, muss eine Reihe an Ressourcen, Betriebs- und Hilfsmittel zur Verfügung gestellt werden.

Für das Information Security Incident Management ist der Information Security Manager gesamtverantwortlich.

== Products ==

=== Konzepte ===
</li></ol>
</li></ol>

Um auf effektive Art und Weise mit Incidents umgehen zu können, ist für den Information Security Manager ein gutes konzeptuelles und praktisches Verständnis für die Behandlung von Vorfällen und Störungen unerlässlich. Zu den wichtigsten Konzepten zählen dabei, das Erkennen und Berichten von Vorfällen, das Beurteilen und Einteilen von Vorfällen (Kategorisieren, Priorisieren, zuweisen von Events und Incidents), die Analyse des Vorfalls, die Reaktion auf Vorfälle (Incident Response) und ein effektives Incident Management. Wesentlich in der Behandlung von Vorfällen ist für den Information Security Manger, dass auch die Möglichkeit von Incidents mit nicht technischem Hintergrund in Betracht gezogen werden muss [CIS10, S244f]. Dazu gehört beispielsweise Social Engineering. Social Engineering ist eine Methode, um unberechtigten Zugang zu Informationen oder IT-Systemen mittels Aushorchen zu erlangen. Dabei werden menschliche Eigenschaften wie z. B. Hilfsbereitschaft, Vertrauen, Angst oder Respekt vor Autorität ausgenutzt, um Mitarbeiter so zu manipulieren, dass sie unzulässig handeln. Weiters müssen beispielsweise verlorene oder gestohlene Sicherungsbänder, entwendete Laptops, oder der Diebstahl von sensiblen Materialien berücksichtigt werden [BSI11].

=== Benötigte Ressourcen ===

Um Incident Management und Incident Response in adäquater Weise implementieren und durchführen zu können, muss eine Reihe an Ressourcen, Betriebs- und Hilfsmittel zur Verfügung gestellt werden.

==== Konzepte und Technologien ====

Im Incident Response Team (IRT) muss spezielles Wissen und Verständnis für einige Konzepte und Technologien vorhanden sein oder es müssen diese Kenntnisse aufgebaut werden.

Ein generelles Wissen über die Sicherheitsprinzipien

* Confidentiality (Vertraulichkeit)
* Availability (Verfügbarkeit)
* Authentication (Authentifizierung)
* Integrity (Vollständigkeit)
* Access Control (Zugangskontrolle)
* Privacy (Datenschutz)
* Non-Repudiation (Nicht-Abstreitbarkeit, Nachweisbarkeit)

ist notwendig, um potentielle Probleme, die auftreten können, wenn entsprechende Sicherheitsmaßnahmen nicht korrekt implementiert sind, und deren Auswirkungen auf IT-Systeme zu verstehen.

Wissen über Netzwerkprotokolle, wie beispielsweise Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), Address Resolution Protocol (ARP) und Netzwerkservices, wie z.B. Domain Name Service (DNS), Network File System (NFS) und Secure Shell (SSH), und wie diese eingesetzt und richtig (sicher) konfiguriert werden, sollte vorhanden sein. Ebenso sollten die Teammitglieder über bekannte Risiken oder Angriffe auf diese Protokolle sowie Strategien zur Vermeidung oder Abwehr von Angriffen Bescheid wissen. Die Teammitglieder sollten verstehen, wie bösartiger Code durch gängige Methoden (z.B. Email, Datenträger, Programme etc.) oder auf spezielle Weise, wie beispielsweise PostScript, Makros, Peer-to-peer Sharing etc., verbreitet wird. Kennnisse über verschiedene Betriebssysteme und Programmiersprachen sollten ebenso vorhanden sein, wie die Fähigkeit, verwundbare Stellen in Netzwerkkonfigurationen erkennen zu können [CIS10, S250f].

=== Incident Management Systeme ===

Das Incident Management und Incident Response besteht aus Prozessen, welche zum Teil manuell durchgeführt werden. Automatisierte Incident Management Systeme können viele dieser manuell durchgeführten Prozesse unterstützen oder sogar zu einem hohen Grad automatisieren. Eine wesentliche Eigenschaft eines Incident Management Systems ist die Überwachung der Incidents über ihren kompletten Lebenszyklus. Das verhindert einerseits, dass Incidents übersehen werden und gewährleistet andererseits, dass Incidents hinsichtlich ihrer Priorität entsprechend behandelt werden. Um eine bestmögliche Unterstützung bieten zu können, muss ein Incident Management System (IMS) eine Reihe an Anforderungen erfüllen, wie beispielsweise Inputs von unterschiedlichen Systemen konsolidieren und in Bezug setzen können, Incidents oder potentielle Incidents erkennen und identifizieren können, Incidents anhand der Auswirkung für das Gesamtunternehmen priorisieren können, Incidents über den gesamten Lebenszyklus hinweg überwachen, Information und Benachrichtigungen über den aktuellen Status des Incidents bieten, konform mit Good oder Best Practices sein etc.

Durch den Einsatz eines Incident Management Systems können mitunter auch Kosteneinsparungen erzielt werden. Einerseits können operative Kosten gesenkt werden, da ohne integrierte IMS unterschiedliche Sicherheitssysteme überwacht und Events miteinander in Verbindung gesetzt werden müssen. Diese Informationen müssen dann manuell verarbeitet werden. Neben einer wahrscheinlichen Häufigkeit von Fehlern fallen Kosten für Schulungen und Wartungen über einen längeren Zeitraum an. Andererseits können Wiederherstellungskosten reduziert werden. Ein richtig konfiguriertes, automatisiertes System erkennt und eskaliert Incidents im Vergleich zu einem manuellen Prozess erheblich schneller. Das führt zu einer Verminderung des Schadens und Vermeidung weiterer Schäden, was wiederum die Kosten für die Wiederherstellung nach einem Zwischenfall reduziert [CIS10, S245].

=== Richtlinien (Policies) und Standards ===

Richtlinien und Standards gewährleisten, dass die Aktivitäten des Incident Managements an der Mission des Managementteams (Incident Management Team) ausgerichtet sind. Es werden die richtigen Ziele und Erwartungen gesetzt und Richtlinien zur operativen Umsetzung (Incident Response Plan) zur Verfügung gestellt. In einem Incident Response Plan wird dabei einerseits definiert, was ein Security Incident ist und andererseits werden die Phasen für die Abhandlung von Incidents und dabei nötigen Verantwortlichkeiten beschrieben. Ein Incident Response Plan muss durch definierte, gut verständliche und dokumentierte Richtlinien und Arbeitsanweisungen für dessen Ausführung vervollständigt werden [CIS10, S250]. Auch die ISO 2700x Familie beinhaltet einen Standard für das Management von Incidents – ISO/IEC 27035 – Information technology – Security techniques – Information Security Incident Management. Die Norm enthält vier grundlegende Elemente: Entdeckung, Meldung und Bewertung von Informationssicherheits-Vorfällen (IS-Vorfällen), Behandlung und Management von IS-Vorfällen, Entdeckung, Bewertung und Management von IS-Schwachstellen und kontinuierliche Verbesserung des IS-Managements als Ergebnis des Managements von IS-Vorfällen und -Schwachstellen [ISM14, S1ff].

Um die Einhaltung von, für das Unternehmen festgelegten, Richtlinien (Policies), Standards und Abläufen zu überprüfen, werden (regelmäßig) Audits durchgeführt. Interne Audits werden von Experten innerhalb der Organisation durchgeführt und dienen im Allgemeinen dazu, Anforderungen an die Einhaltung und Übereinstimmung mit Richtlinien zu unterstützen oder bestimmte Situationen im Unternehmen zu verbessern. Externe Audits werden meist von Drittfirmen aufgrund von verpflichtenden Auflagen durchgeführt. Das wichtigste Ergebnis eines Audits ist der Audit-Bericht, der neben dem Umfang der Prüfung auch Beobachtungen und Feststellungen sowie begleitende Empfehlungen enthält.

=== Personal und Verantwortlichkeiten ===

Für das Management und die Abhandlung von sicherheitsrelevanten Vorfällen und zumeist schwerwiegenden Ereignisse werden eine Reihe an Rollen mit unterschiedlichen Verantwortlichkeiten vorgeschlagen.

Für die Planung und Steuerung (Management) der Behandlung von sicherheitsrelevanten Incidents ist der Information Security Manager gesamtverantwortlich. Das bedeutet, dass der Information Security Manager sicherstellen muss, dass Vorfälle, welche den laufenden Betrieb und damit Geschäftsprozesse beeinträchtigen können, auf effektive und effiziente Art und Weise behandelt werden und die Auswirkungen von solchen Vorfällen minimiert werden.

==== Fähigkeiten - Skills ====

Die technischen Skills umfassen technisches Grundwissen über jene, im Unternehmen eingesetzte Technologien, und Verständnis für Techniken, Entscheidungspunkte und Softwarewerkzeuge, welche die täglichen Aktivitäten eines Incident Bearbeiters unterstützen.

==== Awareness und Ausbildung ====

Wenn keine Experten innerhalb des Unternehmens gefunden bzw. ausgebildet werden können, um das benötigte Spezialwissen zu nutzen, müssen evtl. Fachexperten mit den nötigen Skills außerhalb des Unternehmens beauftragt werden. Wenn eine Situation eintritt, in der das innerbetriebliche Wissen nicht mehr ausreicht, kann auf diese Experten zurückgegriffen werden, um die Lücke in der Fachkenntnis zu schließen.

==== Audits ====

Audits werden durchgeführt, um die Einhaltung von, für das Unternehmen festgelegten, Richtlinien (Policies), Standards und Abläufen zu überprüfen. Interne Audits werden von Experten innerhalb der Organisation durchgeführt und dienen im Allgemeinen dazu, Anforderungen an die Einhaltung und die Übereinstimmung mit Richtlinien zu unterstützen oder bestimmte Situationen im Unternehmen zu verbessern. Externe Audits werden meist von Drittfirmen aufgrund von verpflichtenden Auflagen durchgeführt. Das wichtigste Ergebnis eines Audits ist der Audit-Bericht, der neben dem Umfang der Prüfung auch Beobachtungen und Feststellungen sowie begleitende Empfehlungen enthält.

== People ==

=== Rollen und Verantwortlichkeiten ===
</li></ol>
</li></ol>

Für das Incident Management und Incident Response im Enterprise Security Bereich zeichnet die Rolle des Information Security Managers (ISM) gesamtverantwortlich. Das bedeutet, dass der Information Security Manager sicherstellen muss, dass Vorfälle, welche den laufenden Betrieb und damit Geschäftsprozesse beeinträchtigen können, auf effektive und effiziente Art und Weise behandelt werden und die Auswirkungen von solchen Vorfällen minimiert werden.

==== Senior Management Commitment ====

Eine eindeutige Zustimmung des Senior Managements kann als kritischer Erfolgsfaktor für Incident Management und Response angesehen werden. Fehlt das Engagement und der Rückhalt, besteht die Gefahr, dass benötige Ressourcen nicht zur Verfügung gestellt werden und damit ein effizientes und effektives Incident Management im Unternehmen nicht etabliert werden kann.

==== Information Security Manager ====

Der Information Security Manager definiert, ab wann von einem sicherheitsrelevanten Incident (Security Incident) gesprochen wird, denn nicht alle Ereignisse stellen sicherheitsrelevante Vorfälle dar. Security Incidents umfassen im Allgemeinen

* Attacken über bösartigen Code
* Nicht autorisierter Zugriff auf IT- oder Informationsressourcen
* Nicht autorisierte Nutzung von IT Services
* Nicht autorisierte Änderungen an Systemen oder Informationen
* Denial of Service
* Missbräuchliche Verwendung
* Spionage und Überwachung
* Hoaxes und Social Engineering

Zu den Aufgaben des Information Security Managers zählt auch die Entwicklung der Incident Management und Response Pläne, sowie die Koordination und Abwicklung der Security-Incident-Response-Aktivitäten auf effiziente und effektive Weise. Er validiert, überprüft und berichtet über technische und organisatorische Schutz- und Gegenmaßnahmen. Der ISM ist verantwortlich für die Planung, Budgetierung und Entwicklung des Programs aller Belange, die in Zusammenhang mit Information Security Management und Behandlung sicherheitsrelevanter Incidents stehen. Darüber hinaus muss der Information Security Manager das Engagement und den Rückhalt durch das Senior Management (Commitment) sicherstellen. Das erfordert einerseits das Aufbereiten eines Business Cases, um Kosten und Nutzen des Incident Managements und Response darzustellen. Andererseits ist ein regelmäßiges Reporting von MAPs als Basis, um die stetige Unterstützung (politisch und monetär) zu rechtfertigen, nötig.

==== Incident Response Team ====

Ein Incident Response Team (Team zur Abhandlung von Incidents) besteht im Allgemeinen aus permanent und vorübergehend zugehörigen Teammitgliedern und kann zentral oder dezentral organisiert sein.

Zu den permanent angehörigen, fixen Teammitgliedern zählen meist jene Personen, welche die Incidents untersuchen und behandeln. Es handelt sich in der Regel um IT-Experten und Spezialisten für physische Sicherheit.

Die vorübergehenden Mitglieder des Incident Response Teams setzen sich im Allgemeinen aus Vertretern der Fachbereiche oder des mittleren Management oder Mitarbeiter aus Rechtsabteilungen und Public Relations zusammen. Sie bewerten z.B. (finanzielle) Auswirkungen von Vorfällen für das Gesamtunternehmen. Aber auch Personen aus dem Bereich Risk Management oder IT Spezialisten werden vorübergehend, z.B. projektbezogen, in IRTs aufgenommen [CIS10, S251].

Ein zentrales IRT behandelt alle Incidents in der Regel für eine kleine Organisation, oder ein zentral organisiertes Unternehmen.

In einem verteilten oder dezentral organisierten IRT ist jedes der einzelnen Teilteams für ein logisches oder physisches Segment der Infrastruktur verantwortlich. Ein verteiltes IRT wird gewöhnlich bei großen Unternehmen oder geographisch verteilten Organisationen angewendet. Dabei übernimmt dann ein weiteres, zentrales Team die Leitung der verteilten, dezentralen Teil-IRTs. Das zentrale Team entwickelt Richtlinien und Standards, bietet Trainings und Schulungen und koordiniert oder unterstützt die Behandlung von speziellen Incidents. Die verteilten Teams führen die Schritte zur Behandlung der Incidents aus [CIS10, S251].

==== Incident Management Team und Incident Response Team ====

Die nachfolgende Tabelle beschreibt typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams [CIS10, S252].

{|
!width="14%"| Security Steering Group
!width="18%"| Gruppe von Mitgliedern des Senior Managements
!width="66%"|
<ul>
<li>Ist für die Genehmigung der strategischen Ausrichtung des Incident Management verantwortlich</li>
<li>Dient als Eskalationsstelle für das Incident Management Team</li>
<li>Genehmigt Abweichungen und Ausnahmen zu den definierten, standardisierten Verfahren des Incident Management und Incident Response</li></ul>
|-
| Information Security Manager
| Leiter des Incident Management Teams IMT
|
<ul>
<li>Ist für die Entwicklung und Aufrechterhaltung der Incident Management und Response Fähigkeiten verantwortlich</li>
<li>Verwaltet effizient Risiken und Incidents</li>
<li>Führt proaktive und reaktive Maßnahmen zur Steuerung der Höhe des Informationsrisikos durch</li></ul>
|-
| Incident Response Manager
| Leiter des Incident Response Teams IRT
|
<ul>
<li>Überwacht und betreut die Incident Response Aufgaben</li>
<li>Koordiniert Ressourcen für eine effektive Bearbeitung der Incident Response Aufgaben</li>
<li>Übernimmt die Verantwortung für die erfolgreiche Ausführung des Incident Response Plans</li>
<li>Präsentiert Incident Response Berichte und Berichte über Erfahrungen (Lessons Learned) an die Mitglieder der SSG</li></ul>
|-
| Incident Handler (Incident Bearbeiter)
| Mitglied des IMT/IRT
|
<ul>
<li>Führt Aufgaben des Incident Response aus, um die Auswirkungen eines Incidents einzudämmen</li>
<li>Dokumentiert die Schritte, die bei der Ausführung des Incident Response Plans durchgeführt werden</li>
<li>Hält die Kontrollkette aufrecht (Beweissicherung) und überwacht die Abläufe bei der Incident Behandlung für den Fall einer gerichtlichen Anwendung</li>
<li>Erstellt Incident Response Berichte und dokumentiert gemachte Erfahrungen (Lessons Learned)</li></ul>
|-
| Investigator (Ermittler, Untersuchender)
| Mitglied des IMT/IRT
|
<ul>
<li>Untersucht spezielle Incidents</li>
<li>Findet die Ursachen eines Incidents</li>
<li>Erstellt Untersuchungsberichte</li></ul>
|-
| IT Security Spezialist
| Mitglied des IMT/IRT Spezialist für bestimmte Bereiche der IT Security
|
<ul>
<li>Führt komplexe und spezielle sicherheitsrelevante Aufgaben als Teil des Incident Response Plans aus</li>
<li>Führt Beurteilungen und Prüfungen der IT Security als proaktive Maßnahmen durch</li></ul>
|}

Tab. 3.1: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 1)

[CIS10, S252]

{|
!width="14%"| Business Managers (Mitglieder der Fach-bereiche)
!width="18%"|
Verantwort-liche für Fachbereiche

Prozess- oder Systemver-antwortliche
!width="66%"|
<ul>
<li>Trifft im Falle eines Incidents Entscheidungen, die den Prozess oder System betreffen, auf Basis der Empfehlungen des IMT/IRT</li>
<li>Unterstützt mit Wissen über die Auswirkungen eines Incidents auf das Business im Prozess der BIA oder im Incident Response Plan</li></ul>
|-
| IT Spezialist
| Spezialisten für bestimmte IT Services
|
<ul>
<li>Unterstützt das IMT/IRT bei der Lösung von Incidents</li>
<li>Wartet IT Systeme anhand von Richtlinien oder Best Practice Empfehlungen</li></ul>
|-
| Rechts-vertreter
| Spezialisten für rechtliche Angelegen-heiten
|
<ul>
<li>Bietet rechtliche Unterstützung für das Incident Management und Incident Response, z.B. im Falle von Klagen</li></ul>
|-
| Human Resources
| Spezialist für personelle Angelegen-heiten
|
<ul>
<li>Unterstützt im Incident Management und Response, wenn die Untersuchung von verdächtigen Mitarbeitern erfolgen muss</li>
<li>Passt die HR-Richtlinien an, um Sanktionen des Incident Managements im Falle personeller Konsequenzen zu unterstützen</li></ul>
|-
| Vertreter aus Public Relations
| Vertreter der Presse-abteilung
|
<ul>
<li>Unterstützt mit einer kotrollierten Kommunikation (intern und extern), um Beeinträchtigungen der laufenden Incident Response Aktivitäten zu minimieren und das Images das Unternehmens zu schützen</li>
<li>Unterstützt das IMT/IRT in kommunikationsrelevanten Belangen, um dem Team den Umgang mit kritischen Themen bei der Lösung von Incidents zu erleichtern</li></ul>
|-
| Spezialist für Risk Manage-ment
| Spezialist für Risiko-management
|
<ul>
<li>Arbeitet eng mit Business Managern und dem Senior Management zusammen, um Risiken zu bestimmen und zu behandeln</li>
<li>Liefert wichtigen Input, z.B. BIA, Strategie des Risk Managements etc. für das Incident Management</li></ul>
|}

Tab. 3.2: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 2)

[CIS10, S252]

=== Kenntnisse und Training ===

Im Incident Response Team (IRT) muss ein generelles Wissen über Sicherheitsprinzipien vorhanden sein, um potentielle Probleme und Auswirkungen nicht korrekt implementierter Sicherheitsmaßnahmen verstehen zu können. Die Teammitglieder sollten Kenntnisse über Verwundbarkeiten und Schwächen in der Sicherheit und wie sich ein Angriff bei einer bestimmten Software oder Hardwaretechnologie zeigt, haben. Zu den bekanntesten Schwachstellen mit entsprechenden Angriffen zählen:

* Physische Sicherheitsaspekte
* Fehler im Protokolldesign (z.B. Man-in-the-middle-Attacken, Spoofing etc.)
* Bösartiger Code (Viren, Würmer, Trojaner etc.)
* Fehler in der Implementierung (Buffer Overflow, Race Condition etc.)
* Schwachstellen bei Konfigurationen
* Anwenderfehler oder mangelndes Sicherheitsbewusstsein (Awareness)

Wissen über Netzwerkprotokolle (z.B. TCP/IP, UDP, ICMP, ARP etc.) und Netzwerkservices (z.B. DNS, NFS, SSH etc.), und wie diese eingesetzt und richtig (sicher) konfiguriert werden, sollte vorhanden sein. Ebenso sollten die Teammitglieder über bekannte Risiken oder Angriffe auf diese Protokolle, sowie Strategien zur Vermeidung oder Abwehr von Angriffen Bescheid wissen. Die Teammitglieder sollten verstehen, wie bösartiger Code durch gängige Methoden (z.B. Email, Datenträger, Programme etc.) oder auf spezielle Weise, wie beispielsweise PostScript, Makros, Peer-to-peer Sharing etc., verbreitet wird. Kennnisse über verschiedene Betriebssysteme und Programmiersprachen sollten ebenso vorhanden sein, wie die Fähigkeit, verwundbare Stellen in Netzwerkkonfigurationen erkennen zu können [CIS10, S250f].

Die Mitglieder eines Incident-Response-Teams müssen allerdings neben technischen Fähigkeiten zur Behandlung von Incidents und für Analysetätigkeiten, auch über andere persönliche Eigenschaften (Soft Skills) verfügen. Soft Skills müssen besonders berücksichtigt werden, da sie für einen Großteil der täglichen Aktivitäten eines Bearbeiters von Incidents benötigt werden. Dazu zählen:

<ul>
<li>Kommunikationsfähigkeit, um die richtigen und benötigten Informationen bekommen und weitergeben zu können</li>
<li>Fähigkeit, Richtlinien und Arbeitsanweisungen zu befolgen, um einen effizienten Ablauf in der Incident Behandlung zu gewährleisten</li>
<li>Teamfähigkeit</li>
<li>Stressresistenz</li>
<li>Vertraulichkeit, da die Teammitglieder oft mit sensiblen und vertraulichen Daten in Berührung kommen oder Zugriff darauf haben</li>
<li>Problemlösungskompetenz, wie beispielsweise „über den Tellerrand blicken können“, um Probleme aus mehreren Perspektiven betrachten zu können</li>
<li>Präsentationsfähigkeiten, um Bericht dem Management darstellen zu können

== Wiederholungsaufgaben ==
</li></ol>
</li></ul>

# Beschreiben Sie kurz was ein IMS ist, wie ein IMS im Incident Management und Incident Response unterstützen kann und welche Anforderungen an ein IMS gestellt werden!
# Nennen Sie vier Bespiele für Recovery Sites und beschreiben Sie diese kurz!
# Was bedeutet RACI?