Informationssicherheitsmanagement - ISIM Aufbau: Unterschied zwischen den Versionen
Zeile 134: | Zeile 134: | ||
Die nachfolgende Tabelle beschreibt typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams [CIS10, S252]. | Die nachfolgende Tabelle beschreibt typische Rollen und Verantwortlichkeiten von Mitgliedern des Incident Management Teams und Incident Response Teams [CIS10, S252]. | ||
{| class="wikitable" style="border-collapse: collapse; border-style: dotted;" | {| class="wikitable" style="border-collapse: collapse; border-style: dotted;" | ||
! style="width: 109.475px;" | Security Steering Group | ! style="width: 109.475px;" | Security Steering Group | ||
! 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>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>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>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 152: | Zeile 152: | ||
</ul> | </ul> | ||
|- | |- | ||
| style="width: 109.475px;" | Incident Response Manager | | style="width: 109.475px;" | Incident Response Manager*in | ||
| style="width: 140.756px;" | Leiter des Incident Response Teams IRT | | style="width: 140.756px;" | Leiter*in des Incident Response Teams IRT | ||
| style="width: 516.119px;" | | | style="width: 516.119px;" | | ||
<ul> | <ul> | ||
Zeile 162: | Zeile 162: | ||
</ul> | </ul> | ||
|- | |- | ||
| style="width: 109.475px;" | Incident Handler (Incident Bearbeiter) | | style="width: 109.475px;" | Incident Handler (Incident Bearbeiter*in) | ||
| style="width: 140.756px;" | Mitglied des IMT/IRT | | style="width: 140.756px;" | Mitglied des IMT/IRT | ||
| style="width: 516.119px;" | | | style="width: 516.119px;" | | ||
Zeile 172: | Zeile 172: | ||
</ul> | </ul> | ||
|- | |- | ||
| style="width: 109.475px;" | Investigator (Ermittler, | | style="width: 109.475px;" | Investigator (Ermittler*in, Untersuchende*r) | ||
| style="width: 140.756px;" | Mitglied des IMT/IRT | | style="width: 140.756px;" | Mitglied des IMT/IRT | ||
| style="width: 516.119px;" | | | style="width: 516.119px;" | | ||
Zeile 181: | Zeile 181: | ||
</ul> | </ul> | ||
|- | |- | ||
| style="width: 109.475px;" | IT Security Spezialist | | style="width: 109.475px;" | IT Security Spezialist*in | ||
| style="width: 140.756px;" | Mitglied des IMT/IRT Spezialist für bestimmte Bereiche der IT Security | | style="width: 140.756px;" | Mitglied des IMT/IRT Spezialist für bestimmte Bereiche der IT Security | ||
| style="width: 516.119px;" | | | style="width: 516.119px;" | | ||
Zeile 193: | Zeile 193: | ||
[CIS10, S252] | [CIS10, S252] | ||
{| | {| class="wikitable" style="border-collapse: collapse;" | ||
! width="14%" | Business | ! width="14%" | Business Manager*innen (Mitglieder der Fachbereiche) | ||
! width="18%" | | ! width="18%" | Verantwortliche für Fachbereiche | ||
Prozess- oder Systemver-antwortliche | Prozess- oder Systemver-antwortliche | ||
! width="66%" | <ul> | ! width="66%" | <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 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>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> | ||
|- | |- | ||
| IT Spezialist | | IT Spezialist*in | ||
| | | Spezialist*innen für bestimmte IT Services | ||
| | | | ||
<ul> | <ul> | ||
Zeile 211: | Zeile 211: | ||
</ul> | </ul> | ||
|- | |- | ||
| | | Rechtsvertreter*innen | ||
| | | Spezialist*innen für rechtliche Angelegenheiten | ||
| | | | ||
<ul> | <ul> | ||
Zeile 219: | Zeile 219: | ||
|- | |- | ||
| Human Resources | | Human Resources | ||
| Spezialist für personelle | | Spezialist*innen für personelle Angelegenheiten | ||
| | | | ||
<ul> | <ul> | ||
<li><p>Unterstützt im Incident Management und Response, wenn die Untersuchung von verdächtigen | <li><p>Unterstützt im Incident Management und Response, wenn die Untersuchung von verdächtigen Mitarbeiter*innen 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> | <li><p>Passt die HR-Richtlinien an, um Sanktionen des Incident Managements im Falle personeller Konsequenzen zu unterstützen</p></li> | ||
</ul> | </ul> | ||
|- | |- | ||
| Vertreter aus Public Relations | | Vertreter*innen aus Public Relations | ||
| Vertreter der | | Vertreter*innen der Presseabteilung | ||
| | | | ||
<ul> | <ul> | ||
<li><p>Unterstützt mit einer | <li><p>Unterstützt mit einer kontrollierten 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> | <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> | </ul> | ||
|- | |- | ||
| Spezialist für Risk | | Spezialist*innen für Risk Management | ||
| Spezialist für Risiko-management | | Spezialist*innen für Risiko-management | ||
| | | | ||
<ul> | <ul> | ||
<li><p>Arbeitet eng mit Business | <li><p>Arbeitet eng mit Business Manager*innen 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> | <li><p>Liefert wichtigen Input, z.B. BIA, Strategie des Risk Managements etc. für das Incident Management</p></li> | ||
</ul> | </ul> | ||
Zeile 255: | Zeile 255: | ||
* Fehler in der Implementierung (Buffer Overflow, Race Condition etc.) | * Fehler in der Implementierung (Buffer Overflow, Race Condition etc.) | ||
* Schwachstellen bei Konfigurationen | * Schwachstellen bei Konfigurationen | ||
* | * Anwender*innenfehler 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]. | ||
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 | 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 einer/s Bearbeiterin von Incidents benötigt werden. Dazu zählen: | ||
<ul> | <ul> | ||
Zeile 267: | Zeile 267: | ||
<li><p>Vertraulichkeit, da die Teammitglieder oft mit sensiblen und vertraulichen Daten in Berührung kommen oder Zugriff darauf haben</p></li> | <li><p>Vertraulichkeit, da die Teammitglieder oft mit sensiblen und vertraulichen Daten in Berührung kommen oder Zugriff darauf haben</p></li> | ||
<li><p>Problemlösungskompetenz, wie beispielsweise „über den Tellerrand blicken können“, um Probleme aus mehreren Perspektiven betrachten zu können</p></li> | <li><p>Problemlösungskompetenz, wie beispielsweise „über den Tellerrand blicken können“, um Probleme aus mehreren Perspektiven betrachten zu können</p></li> | ||
<li><p>Präsentationsfähigkeiten, um | <li><p>Präsentationsfähigkeiten, um dem Management Bericht darstellen zu können</p> | ||
== Wiederholungsaufgaben == | == Wiederholungsaufgaben == |
Version vom 13. Jänner 2022, 21:46 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 Expert*innenen 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 die/der Information Security Manager*in gesamtverantwortlich. Das bedeutet, dass die/der Information Security Manager*in 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 einer/s Incident Bearbeiter*in unterstützen.
Awareness und Ausbildung
Wenn keine Expert*innen innerhalb des Unternehmens gefunden bzw. ausgebildet werden können, um das benötigte Spezialwissen zu nutzen, müssen evtl. Fachexpert*innen 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 Expert*innen 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 Expert*innen 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 ist die Rolle der/des Information Security Manager*in (ISM) gesamtverantwortlich. Das bedeutet, dass die/der Information Security Manager*in 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*in
Die/der Information Security Manager*in 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 der/des Information Security Manager*in 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. Sie/er validiert, überprüft und berichtet über technische und organisatorische Schutz- und Gegenmaßnahmen. Die/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 die/der Information Security Manager*in 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-Expert*innen und Spezialist*innen für physische Sicherheit.
Die vorübergehenden Mitglieder des Incident Response Teams setzen sich im Allgemeinen aus Vertreter*innen der Fachbereiche oder des mittleren Management oder Mitarbeiter*innen 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 Spezialist*innenen 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*in | Leiter*in des Incident Management Teams IMT |
|
Incident Response Manager*in | Leiter*in des Incident Response Teams IRT |
|
Incident Handler (Incident Bearbeiter*in) | Mitglied des IMT/IRT |
|
Investigator (Ermittler*in, Untersuchende*r) | Mitglied des IMT/IRT |
|
IT Security Spezialist*in | 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 Manager*innen (Mitglieder der Fachbereiche) | Verantwortliche für Fachbereiche
Prozess- oder Systemver-antwortliche |
|
---|---|---|
IT Spezialist*in | Spezialist*innen für bestimmte IT Services |
|
Rechtsvertreter*innen | Spezialist*innen für rechtliche Angelegenheiten |
|
Human Resources | Spezialist*innen für personelle Angelegenheiten |
|
Vertreter*innen aus Public Relations | Vertreter*innen der Presseabteilung |
|
Spezialist*innen für Risk Management | Spezialist*innen 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
- Anwender*innenfehler 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 einer/s Bearbeiterin 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 dem Management Bericht 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?