Informationssicherheitsmanagement - ISIM Aufbau: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „= Information Security Incident Management – Aufbau = '''Ziele der Lektion''' <ul> <li><p>Kennenlernen des Aufbaus 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 von Konzepten für die Wiederherstellung</p></li> <li><p>Vorstellen der für die Prozesse benötigten Bausteine, Rollen und Verantwortlichkeiten</p> </…“) |
|||
Zeile 6: | Zeile 6: | ||
<li><p>Kennenlernen des Aufbaus 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 Aufbaus 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 von Konzepten für die Wiederherstellung</p></li> | <li><p>Kennenlernen von Konzepten für die Wiederherstellung</p></li> | ||
<li><p>Vorstellen der für die Prozesse benötigten Bausteine, Rollen und Verantwortlichkeiten</p> | <li><p>Vorstellen der für die Prozesse benötigten Bausteine, Rollen und Verantwortlichkeiten</p></li> | ||
</ul> | </ul> | ||
== Incident Management & Incident Response == | == 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 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*innen. 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. | 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. | ||
Zeile 20: | Zeile 21: | ||
* Incidents sorgfältig und präzise diagnostizieren | * Incidents sorgfältig und präzise diagnostizieren | ||
* Incidents entsprechend handhaben und bewältigen | * Incidents entsprechend handhaben und bewältigen | ||
* | * Schäden eindämmen und minimieren | ||
* Betroffene Services wiederherstellen | * Betroffene Services wiederherstellen | ||
* Ursachen der Vorfälle bestimmen | * Ursachen der Vorfälle bestimmen | ||
* Verbesserungen implementieren, um ein Wiederauftreten zu verhindern | * 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 Hilfsmitteln zur Verfügung gestellt werden. | |||
Für das Information Security Incident Management ist die/der Information Security Manager*in gesamtverantwortlich. | |||
Für das Information Security Incident Management ist der Information Security Manager gesamtverantwortlich. | |||
Zeile 34: | Zeile 34: | ||
=== Konzepte === | === Konzepte === | ||
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 | |||
Um auf effektive Art und Weise mit Incidents umgehen zu können, ist für die/den Information Security Manager*in 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 die/den Information Security Manger*in, 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*innen 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 === | === 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 | Um Incident Management und Incident Response in adäquater Weise implementieren und durchführen zu können, muss eine Reihe an Ressourcen, Betriebs- und Hilfsmitteln zur Verfügung gestellt werden. | ||
==== Konzepte und Technologien ==== | ==== Konzepte und Technologien ==== | ||
Zeile 56: | Zeile 56: | ||
* Privacy (Datenschutz) | * Privacy (Datenschutz) | ||
* Non-Repudiation (Nicht-Abstreitbarkeit, Nachweisbarkeit) | * 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. | |||
ist notwendig, um potentielle Probleme, die auftreten können | |||
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]. | 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]. | ||
Zeile 96: | Zeile 95: | ||
=== Rollen und Verantwortlichkeiten === | === Rollen und Verantwortlichkeiten === | ||
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. | 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. | ||
Zeile 117: | Zeile 116: | ||
* Spionage und Überwachung | * Spionage und Überwachung | ||
* Hoaxes und Social Engineering | * 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. | 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. | ||
Zeile 137: | Zeile 135: | ||
{| | {| | ||
!width="14%"| Security Steering Group | ! width="14%" | Security Steering Group | ||
!width="18%"| Gruppe von Mitgliedern des Senior Managements | ! width="18%" | Gruppe von Mitgliedern des Senior Managements | ||
!width="66%"| | ! width="66%" | <ul> | ||
<ul> | |||
<li><p>Ist für die Genehmigung der strategischen Ausrichtung des Incident Management verantwortlich</p></li> | <li><p>Ist für die Genehmigung der strategischen Ausrichtung des Incident Management verantwortlich</p></li> | ||
<li><p>Dient als Eskalationsstelle für das Incident Management Team</p></li> | <li><p>Dient als Eskalationsstelle für das Incident Management Team</p></li> | ||
<li><p>Genehmigt Abweichungen und Ausnahmen zu den definierten, standardisierten Verfahren des Incident Management und Incident Response</p></li></ul> | <li><p>Genehmigt Abweichungen und Ausnahmen zu den definierten, standardisierten Verfahren des Incident Management und Incident Response</p></li> | ||
|- | </ul> | ||
|- | |||
| Information Security Manager | | Information Security Manager | ||
| Leiter des Incident Management Teams IMT | | Leiter des Incident Management Teams IMT | ||
Zeile 151: | Zeile 149: | ||
<li><p>Ist für die Entwicklung und Aufrechterhaltung der Incident Management und Response Fähigkeiten verantwortlich</p></li> | <li><p>Ist für die Entwicklung und Aufrechterhaltung der Incident Management und Response Fähigkeiten verantwortlich</p></li> | ||
<li><p>Verwaltet effizient Risiken und Incidents</p></li> | <li><p>Verwaltet effizient Risiken und Incidents</p></li> | ||
<li><p>Führt proaktive und reaktive Maßnahmen zur Steuerung der Höhe des Informationsrisikos durch</p></li></ul> | <li><p>Führt proaktive und reaktive Maßnahmen zur Steuerung der Höhe des Informationsrisikos durch</p></li> | ||
|- | </ul> | ||
|- | |||
| Incident Response Manager | | Incident Response Manager | ||
| Leiter des Incident Response Teams IRT | | Leiter des Incident Response Teams IRT | ||
Zeile 160: | Zeile 159: | ||
<li><p>Koordiniert Ressourcen für eine effektive Bearbeitung der Incident Response Aufgaben</p></li> | <li><p>Koordiniert Ressourcen für eine effektive Bearbeitung der Incident Response Aufgaben</p></li> | ||
<li><p>Übernimmt die Verantwortung für die erfolgreiche Ausführung des Incident Response Plans</p></li> | <li><p>Übernimmt die Verantwortung für die erfolgreiche Ausführung des Incident Response Plans</p></li> | ||
<li><p>Präsentiert Incident Response Berichte und Berichte über Erfahrungen (Lessons Learned) an die Mitglieder der SSG</p></li></ul> | <li><p>Präsentiert Incident Response Berichte und Berichte über Erfahrungen (Lessons Learned) an die Mitglieder der SSG</p></li> | ||
|- | </ul> | ||
|- | |||
| Incident Handler (Incident Bearbeiter) | | Incident Handler (Incident Bearbeiter) | ||
| Mitglied des IMT/IRT | | Mitglied des IMT/IRT | ||
Zeile 169: | Zeile 169: | ||
<li><p>Dokumentiert die Schritte, die bei der Ausführung des Incident Response Plans durchgeführt werden</p></li> | <li><p>Dokumentiert die Schritte, die bei der Ausführung des Incident Response Plans durchgeführt werden</p></li> | ||
<li><p>Hält die Kontrollkette aufrecht (Beweissicherung) und überwacht die Abläufe bei der Incident Behandlung für den Fall einer gerichtlichen Anwendung</p></li> | <li><p>Hält die Kontrollkette aufrecht (Beweissicherung) und überwacht die Abläufe bei der Incident Behandlung für den Fall einer gerichtlichen Anwendung</p></li> | ||
<li><p>Erstellt Incident Response Berichte und dokumentiert gemachte Erfahrungen (Lessons Learned)</p></li></ul> | <li><p>Erstellt Incident Response Berichte und dokumentiert gemachte Erfahrungen (Lessons Learned)</p></li> | ||
|- | </ul> | ||
|- | |||
| Investigator (Ermittler, Untersuchender) | | Investigator (Ermittler, Untersuchender) | ||
| Mitglied des IMT/IRT | | Mitglied des IMT/IRT | ||
Zeile 177: | Zeile 178: | ||
<li><p>Untersucht spezielle Incidents</p></li> | <li><p>Untersucht spezielle Incidents</p></li> | ||
<li><p>Findet die Ursachen eines Incidents</p></li> | <li><p>Findet die Ursachen eines Incidents</p></li> | ||
<li><p>Erstellt Untersuchungsberichte</p></li></ul> | <li><p>Erstellt Untersuchungsberichte</p></li> | ||
|- | </ul> | ||
|- | |||
| IT Security Spezialist | | IT Security Spezialist | ||
| Mitglied des IMT/IRT Spezialist für bestimmte Bereiche der IT Security | | Mitglied des IMT/IRT Spezialist für bestimmte Bereiche der IT Security | ||
Zeile 184: | Zeile 186: | ||
<ul> | <ul> | ||
<li><p>Führt komplexe und spezielle sicherheitsrelevante Aufgaben als Teil des Incident Response Plans aus</p></li> | <li><p>Führt komplexe und spezielle sicherheitsrelevante Aufgaben als Teil des Incident Response Plans aus</p></li> | ||
<li><p>Führt Beurteilungen und Prüfungen der IT Security als proaktive Maßnahmen durch</p></li></ul> | <li><p>Führt Beurteilungen und Prüfungen der IT Security als proaktive Maßnahmen durch</p></li> | ||
</ul> | |||
|} | |} | ||
Tab. 3.1: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 1) | Tab. 3.1: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 1) | ||
Zeile 192: | Zeile 194: | ||
{| | {| | ||
!width="14%"| Business Managers (Mitglieder der Fach-bereiche) | ! width="14%" | Business Managers (Mitglieder der Fach-bereiche) | ||
!width="18%"| | ! width="18%" | Verantwort-liche für Fachbereiche | ||
Verantwort-liche für Fachbereiche | |||
Prozess- oder Systemver-antwortliche | Prozess- oder Systemver-antwortliche | ||
!width="66%"| | ! width="66%" | <ul> | ||
<ul> | |||
<li><p>Trifft im Falle eines Incidents Entscheidungen, die den Prozess oder System betreffen, auf Basis der Empfehlungen des IMT/IRT</p></li> | <li><p>Trifft im Falle eines Incidents Entscheidungen, die den Prozess oder System betreffen, auf Basis der Empfehlungen des IMT/IRT</p></li> | ||
<li><p>Unterstützt mit Wissen über die Auswirkungen eines Incidents auf das Business im Prozess der BIA oder im Incident Response Plan</p></li></ul> | <li><p>Unterstützt mit Wissen über die Auswirkungen eines Incidents auf das Business im Prozess der BIA oder im Incident Response Plan</p></li> | ||
|- | </ul> | ||
|- | |||
| IT Spezialist | | IT Spezialist | ||
| Spezialisten für bestimmte IT Services | | Spezialisten für bestimmte IT Services | ||
Zeile 207: | Zeile 208: | ||
<ul> | <ul> | ||
<li><p>Unterstützt das IMT/IRT bei der Lösung von Incidents</p></li> | <li><p>Unterstützt das IMT/IRT bei der Lösung von Incidents</p></li> | ||
<li><p>Wartet IT Systeme anhand von Richtlinien oder Best Practice Empfehlungen</p></li></ul> | <li><p>Wartet IT Systeme anhand von Richtlinien oder Best Practice Empfehlungen</p></li> | ||
|- | </ul> | ||
|- | |||
| Rechts-vertreter | | Rechts-vertreter | ||
| Spezialisten für rechtliche Angelegen-heiten | | Spezialisten für rechtliche Angelegen-heiten | ||
| | | | ||
<ul> | <ul> | ||
<li><p>Bietet rechtliche Unterstützung für das Incident Management und Incident Response, z.B. im Falle von Klagen</p></li></ul> | <li><p>Bietet rechtliche Unterstützung für das Incident Management und Incident Response, z.B. im Falle von Klagen</p></li> | ||
|- | </ul> | ||
|- | |||
| Human Resources | | Human Resources | ||
| Spezialist für personelle Angelegen-heiten | | Spezialist für personelle Angelegen-heiten | ||
Zeile 220: | Zeile 223: | ||
<ul> | <ul> | ||
<li><p>Unterstützt im Incident Management und Response, wenn die Untersuchung von verdächtigen Mitarbeitern erfolgen muss</p></li> | <li><p>Unterstützt im Incident Management und Response, wenn die Untersuchung von verdächtigen Mitarbeitern erfolgen muss</p></li> | ||
<li><p>Passt die HR-Richtlinien an, um Sanktionen des Incident Managements im Falle personeller Konsequenzen zu unterstützen</p></li></ul> | <li><p>Passt die HR-Richtlinien an, um Sanktionen des Incident Managements im Falle personeller Konsequenzen zu unterstützen</p></li> | ||
|- | </ul> | ||
|- | |||
| Vertreter aus Public Relations | | Vertreter aus Public Relations | ||
| Vertreter der Presse-abteilung | | Vertreter der Presse-abteilung | ||
Zeile 227: | Zeile 231: | ||
<ul> | <ul> | ||
<li><p>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</p></li> | <li><p>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</p></li> | ||
<li><p>Unterstützt das IMT/IRT in kommunikationsrelevanten Belangen, um dem Team den Umgang mit kritischen Themen bei der Lösung von Incidents zu erleichtern</p></li></ul> | <li><p>Unterstützt das IMT/IRT in kommunikationsrelevanten Belangen, um dem Team den Umgang mit kritischen Themen bei der Lösung von Incidents zu erleichtern</p></li> | ||
|- | </ul> | ||
|- | |||
| Spezialist für Risk Manage-ment | | Spezialist für Risk Manage-ment | ||
| Spezialist für Risiko-management | | Spezialist für Risiko-management | ||
Zeile 234: | Zeile 239: | ||
<ul> | <ul> | ||
<li><p>Arbeitet eng mit Business Managern und dem Senior Management zusammen, um Risiken zu bestimmen und zu behandeln</p></li> | <li><p>Arbeitet eng mit Business Managern und dem Senior Management zusammen, um Risiken zu bestimmen und zu behandeln</p></li> | ||
<li><p>Liefert wichtigen Input, z.B. BIA, Strategie des Risk Managements etc. für das Incident Management</p></li></ul> | <li><p>Liefert wichtigen Input, z.B. BIA, Strategie des Risk Managements etc. für das Incident Management</p></li> | ||
</ul> | |||
|} | |} | ||
Tab. 3.2: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 2) | Tab. 3.2: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 2) | ||
Zeile 251: | Zeile 256: | ||
* Schwachstellen bei Konfigurationen | * Schwachstellen bei Konfigurationen | ||
* Anwenderfehler oder mangelndes Sicherheitsbewusstsein (Awareness) | * 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]. | 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]. | ||
Zeile 266: | Zeile 270: | ||
== Wiederholungsaufgaben == | == Wiederholungsaufgaben == | ||
</li | </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! | # 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! | # Nennen Sie vier Bespiele für Recovery Sites und beschreiben Sie diese kurz! | ||
# Was bedeutet RACI? | # Was bedeutet RACI? |
Version vom 13. Jänner 2022, 21:20 Uhr
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
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*innen. 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
- Schäden 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 Hilfsmitteln zur Verfügung gestellt werden.
Für das Information Security Incident Management ist die/der Information Security Manager*in gesamtverantwortlich.
Products
Konzepte
Um auf effektive Art und Weise mit Incidents umgehen zu können, ist für die/den Information Security Manager*in 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 die/den Information Security Manger*in, 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*innen 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 Hilfsmitteln 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
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].
Security Steering Group | Gruppe von Mitgliedern des Senior Managements |
|
---|---|---|
Information Security Manager | Leiter des Incident Management Teams IMT |
|
Incident Response Manager | Leiter des Incident Response Teams IRT |
|
Incident Handler (Incident Bearbeiter) | Mitglied des IMT/IRT |
|
Investigator (Ermittler, Untersuchender) | Mitglied des IMT/IRT |
|
IT Security Spezialist | Mitglied des IMT/IRT Spezialist für bestimmte Bereiche der IT Security |
|
Tab. 3.1: Typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams (Teil 1)
[CIS10, S252]
Business Managers (Mitglieder der Fach-bereiche) | Verantwort-liche für Fachbereiche
Prozess- oder Systemver-antwortliche |
|
---|---|---|
IT Spezialist | Spezialisten für bestimmte IT Services |
|
Rechts-vertreter | Spezialisten für rechtliche Angelegen-heiten |
|
Human Resources | Spezialist für personelle Angelegen-heiten |
|
Vertreter aus Public Relations | Vertreter der Presse-abteilung |
|
Spezialist für Risk Manage-ment | Spezialist für Risiko-management |
|
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:
Kommunikationsfähigkeit, um die richtigen und benötigten Informationen bekommen und weitergeben zu können
Fähigkeit, Richtlinien und Arbeitsanweisungen zu befolgen, um einen effizienten Ablauf in der Incident Behandlung zu gewährleisten
Teamfähigkeit
Stressresistenz
Vertraulichkeit, da die Teammitglieder oft mit sensiblen und vertraulichen Daten in Berührung kommen oder Zugriff darauf haben
Problemlösungskompetenz, wie beispielsweise „über den Tellerrand blicken können“, um Probleme aus mehreren Perspektiven betrachten zu können
Präsentationsfähigkeiten, um Bericht dem Management darstellen zu können
Wiederholungsaufgaben
- 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?