I 26 - Anhang_19.1_Incident_Management_Reportingplattform_V.0.9.pdf

[Seite 1]

Anhang 19.1

Incident Management

zu Anlage 19 Servicemanagement

zum Rahmenvertrag vom TT.MM.JJJJ

zwischen

Landesbank Hessen-Thüringen Girozentrale

Neue Mainzer Straße 52 -58

60311 Frankfurt

- nachfolgend Helaba oder Auftraggeber genannt –

und

[Adresszeile 1: Vollständige Firmierung des Auftragnehmers]

[Adresszeile 2: Straße des Auftragnehmers]

[Adresszeile 3: PLZ und Stadt des Auftragnehmers]

- nachfolgend [Kürzel des Auftragnehmers] oder Auftragnehmer ge-

nannt –

– zusammen auch „Vertragspartner“, „Vertragsparteien“ oder „Parteien“

genannt –

Version 0.9

[Seite 2]

Anhang 19.1 – Incident Management

INHALTSVERZEICHNIS

1 Gegenstand ............................................................................................................ 3

1.1 Abgenzung des Dokuments ..................................................................................... 3

1.2 Begriffsklärung ......................................................................................................... 3

2 Leistungsbeschreibung ........................................................................................ 3

2.1 Qualifizierung von Störungsmeldungen ................................................................... 4

2.2 Vergabe von Incident-Prioritäten .............................................................................. 4

2.3 Kommunikation zum Störungsverlauf (Priorität „kritisch“ und „hoch“) ....................... 7

2.4 Umgang mit melderelevanten Störungen (KRITIS, mit Flag „Unterstützung kwF“) und Meldeverpflichtungen ............................................................................................... 7

2.5 Leistungen und Verantwortlichkeiten ......................................................................10

3 Prozesseinbindung und -schnittstelle ................................................................11

4 Reporting ..............................................................................................................11

Seite 2 von 11

[Seite 3]

Anhang 19.1 – Incident Management

1 Gegenstand

Gegenstand dieses Anhangs zu Anlage 19 Servicemanagement des Rahmenvertrages ist die Beschreibung von Leistungen und wesentlichen Aufgaben des Auftragnehmers bei der Zusammenarbeit im Incident Management sowie die Definition erforderlicher Mitwirkungen durch den Auftraggeber.

1.1 Abgenzung des Dokuments

Dieses Dokument beschreibt weder die internen Prozesse des Auftraggebers noch die des Auftragnehmers. Die Ausgestaltung der Prozesse des Auftraggebers verbleibt in der Hoheit des Auftraggebers, ebenso wie die Ausgestaltung der Prozesse des Auftragnehmers in der Hoheit des Auftragnehmers verbleibt. Wechselseitige Ansprüche beschränken sich auf die Einhaltung bzw. Erfüllung der hier vereinbarten Abläufe, Schnittstellen und Rollen.

Die Regelungen dieses Anhangs stellen den grundlegenden fachlichen und prozessualen Rahmen für das Incident Management dar. Sie enthalten keine abschließende operative Aus- gestaltung der im Einzelfall anzuwendenden Prozesse, technischen Anforderungen oder be- trieblichen Abläufe.

Die für den jeweiligen Leistungsgegenstand maßgeblichen Detailregelungen – insbesondere operative Prozessschritte, Rollen, Schnittstellen, technische Spezifikationen und Dokumenta- tionspflichten – werden von den Vertragsparteien im Rahmen der Leistungsübernahme ge- meinsam konkretisiert und außerhalb dieses Anhangs in einem Prozesshandbuch (vgl. An- lage 19 Servicemanagement) festgelegt. Dieses Dokument präzisiert die vorliegenden Rah- menvorgaben und ist für beide Vertragsparteien verbindlich einzuhalten.

Für den vereinbarten Leistungsgegenstand nicht relevante Anforderungen dieses Anhangs finden keine Anwendung.

1.2 Begriffsklärung

Auch wenn der in DORA1 verwendete Begriff „IKT-bezogener Vorfall“ eine IT-Sicherheits-Kom- ponente beinhaltet, so ist er damit nicht mit einem „IT-Security-Incident“ im Sprachgebrauch des Auftraggebers gleichzusetzen. Vielmehr gilt:

• Der Begriff „Incident“ bzw. „IT-Incident“ umfasst „IKT-bezogene Vorfälle“ gemäß Art. 3 Ziff. 8 DORA, geht jedoch darüber hinaus. Regelungen für Incidents gelten in jedem Fall auch für IKT-bezogene Vorfälle.

• Der Begriff „Major Incident“ bzw. „Major IT-Incident“ umfasst „schwerwiegende IKT- bezogene Vorfälle“ gemäß Art. 3 Ziff. 10 DORA, geht jedoch darüber hinaus. Regelun- gen für Major Incidents gelten in jedem Fall auch für schwerwiegende IKT-bezogene Vorfälle.

Alle weiteren Begriffe sind in dem Glossar des Auftraggebers erläutert, dass auf Anforderung zur Verfügung gestellt werden kann.

2 Leistungsbeschreibung

Zweck des IT-Incident Managements ist die Wiederherstellung des normalen Servicebetriebs und die Minimierung der negativen Auswirkungen auf den Geschäftsbetrieb innerhalb der

Seite 3 von 11

[Seite 4]

Anhang 19.1 – Incident Management

festgelegten Service Levels im Falle von Störungen (IT-Incidents). Auf diese Weise wird die vereinbarte Servicequalität gewahrt.

Vorrangiges Ziel ist es sicherzustellen, dass standardisierte Methoden und Verfahren einge- setzt werden für die Analyse, Dokumentation, das laufende Management und die Berichter- stattung über IT-Incidents sowie das Sicherstellen der Anwenderzufriedenheit durch eine hohe Qualität. Das IT-Incident Management bietet die Möglichkeit für eine eventuell notwendige Übergabe von Aufgaben in das Problem-, Anforderungs-, Change- sowie Request-Manage- ment.

Als genereller Single Point of Contact (SPOC) für die Anwender des Auftraggebers fungiert der Service-Desk des Auftraggebers (siehe Anhang 7.1 Kommunikationsmatrix).

Störungen, die den Leistungsbereich des Auftragnehmers betreffen, werden durch den Ser- vice-Desk des Auftraggebers ohne eigenständige Bearbeitung oder Erstlösung unmittelbar an den Auftragnehmer weitergeleitet. In diesen Fällen übernimmt der Auftragnehmer die vollstän- dige Incident-Bearbeitung (Erfassung, Klassifizierung, Priorisierung und Entstörung) gemäß den Regelungen dieses Anhangs.

Zur Sicherstellung einer reibungslosen Incident-Bearbeitung ist festzulegen, auf welche Weise die Ticketbearbeitung zwischen Auftraggeber und Auftragnehmer prozessual gekoppelt wird. Die gewählte Variante (Nutzung des Tickettools des Auftraggebers oder bidirektionale Toolkopplung) beeinflusst lediglich die technische Umsetzung, nicht jedoch die Rollen- und Verantwortungsverteilung.

Das Ticket-System des Auftraggebers gilt als führendes System für die Erfassung, Bearbei- tung und Dokumentation von Incidents. Bei einer bidirektionalen Kopplung der Systeme ist sicherzustellen, dass alle relevanten Informationen im führenden System des Auftraggebers vollständig und nachvollziehbar enthalten sind.

Die Bearbeitung von Incidents im 2nd- und 3rd-Level-Support für die vertragsgengenständli- chen Leistungen obliegt grundsätzlich dem Auftragnehmer, soweit die dafür erforderlichen Systeme, Zugriffsrechte und Fachkenntnisse beim Auftragnehmer vorhanden sind. Der Auf- traggeber stellt sicher, dass für vom Auftraggeber verantwortete Services eine eindeutige Ab- grenzung dokumentiert ist. Die grundsätzlichen Verantwortlichkeiten ergeben sich im Detail aus der RACI-Matrix in Kapitel 2.5 Leistungen und Verantwortlichkeiten.

2.1 Qualifizierung von Störungsmeldungen

Eine Störungsmeldung wird vor der weiteren Bearbeitung klassifiziert.

Innerhalb der Bearbeitung sind die einzelnen Analyseschritte durch den Incident-Bearbeiter für Dritte nachvollziehbar und lückenlos zu dokumentieren (revisionssicher).

Der Auftragnehmer wird die erforderlichen Informationen so lange aufbewahren, wie dies für die Lösung des Incidents notwendig ist oder geltende Gesetze dies vorschreiben.

2.2 Vergabe von Incident-Prioritäten

Incidents werden gemäß der Festlegung der Auswirkung und der Dringlichkeit der Störung mit einer Priorität versehen. Die Einschätzung von Dringlichkeit und Auswirkung nehmen Auftrag- geber und Auftragnehmer einvernehmlich vor. Sofern keine gemeinsame übereinstimmende Sicht erzielt wird, kann das Incident Management des Auftraggebers im Fall einer operativen

Seite 4 von 11

[Seite 5]

Anhang 19.1 – Incident Management

Eskalation einseitig die Priorität festlegen. Der Auftragnehmer wird diese Priorität zur Lösung des Incidents verwenden.

Prioritätsmatrix des Auftraggebers

Aus der Kombination von Dringlichkeit und Auswirkung beim Auftraggeber ergibt sich die fol- gende interne Prioritätenmatrix:

** Die mit zwei Asterisken markierten Prioritäten sind Incidents, die einen IT-Notfall darstellen Tabelle 1: Prioritätsmatrix Incident Management

Im Folgenden sind die beim Auftraggeber definierten Auswirkungen und Dringlichkeiten je Pri- oritätsstufe dargestellt:

1. Auswirkung

Seite 5 von 11

[Seite 6]

Anhang 19.1 – Incident Management

• gemäß Kritikalitäts-Analyse bzw. BIA des Auftraggebers Tabelle 2: Auswirkungsstufen Incident Management

2. Dringlichkeit

Seite 6 von 11

[Seite 7]

Anhang 19.1 – Incident Management

• gemäß Kritikalitäts-Analyse bzw. BIA des Auftraggebers Tabelle 3: Dringlichkeitsstufen Incident Management

2.3 Kommunikation zum Störungsverlauf (Priorität „kritisch“ und „hoch“) Der Auftragnehmer informiert den Auftraggeber bei Incidents der Priorität 1 (kritisch) und 2 (hoch) anlassbezogen sowie in regelmäßigen, gemeinsam abgestimmten Intervallen über den Status der Störung. Die Statusmeldungen erfolgen gemäß Anhang 7.1 Kommunikations- matrix.

Für kritische Incidents werden zusätzlich Telefon- oder Videokonferenzen (sog. „Technical Calls“) zwischen Auftraggeber und Auftragnehmer initiiert, um eine schnelle gemeinsame Ent- störung sicherzustellen. Management-Abstimmungen können bei Bedarf ergänzt werden. Er- gebnisse und nächste Schritte werden dokumentiert und dem Incident zugeordnet.

Major Incidents (Sonderfall innerhalb Priorität 1)

Major IT-Incidents sind schwerwiegende IKT-Störungen, die aufgrund ihrer Auswirkung auf den Auftraggeber einem IT-Notfall gleichzusetzen sind.

Für Major Incidents gelten ergänzend zu den oben beschriebenen Kommunikationspflichten folgende Regelungen für den Auftragnehmer:

• Sofortige Information des zentralen IT-Incident Management des Auftraggebers

• Einrichtung eines dedizierten Technical Call / War Room unmittelbar nach Feststellung des Major Incidents

• Statusmeldungen mindestens alle 60 Minuten oder nach individueller Abstimmung

• Dokumentation aller Ergebnisse, Entscheidungen und nächsten Schritte im Incident- Ticket.

2.4 Umgang mit melderelevanten Störungen (KRITIS, mit Flag „Unterstützung kwF“) und Meldeverpflichtungen

Störungen an kritischen Infrastrukturen bzw. an Systemen mit dem Flag „Unterstützung kwF“ werden im Rahmen des zwischen dem Auftraggeber und dem Auftragnehmer vereinbarten Incident Management-Prozesses behandelt. Eine gegebenenfalls erforderliche Krisen- oder Notfallbewältigung seitens des Auftragnehmers erfolgt im Rahmen des implementierten Not- fallmanagements gemäß Ziffer 19 Notfallplanung des Rahmenvertrags. Notwendige Mel- dungen an Aufsichtsbehörden erfolgen durch den Auftraggeber. Sofern der Incident in der Hoheit des Auftragnehmers liegt und der Auftraggeber betroffen ist, melden beide Parteien in

Seite 7 von 11

[Seite 8]

Anhang 19.1 – Incident Management

enger Abstimmung, nach Einholen der erforderlichen Freigaben. Beim Auftragnehmer erfolgt dies durch das Incident Management oder ein Mitglied des Lagezentrums. Bei Störungen, die durch den Auftraggeber an eine Aufsichtsbehörde gemeldet werden müssen, unterstützt der Auftragnehmer und stellt benötigte Informationen umgehend zur Verfügung. Unterstützung leistet der Auftragnehmer auch im Falle erheblicher Cyberbedrohungen, die nach Auffassung des Auftraggebers für das Finanzsystem, die Dienstnutzer oder die Kunden relevant sind.

Der Umgang mit melderelevanten Incidents KRITIS-relevanter bzw. mit dem Flag „Unterstüt- zung kwF“ markierter Systeme wird wie folgt vereinbart:

• Der Auftraggeber wird im Falle o. g. Incidents zeitnah informiert, wobei eine erste Sta- tus-Meldung nach 15 Minuten erfolgt, jedes weitere Update nach weiteren 60 Minuten.

• Die Entstörung seitens des Auftragnehmers erfolgt mit hoher Priorität, bestimmt durch die Auswirkung und Dringlichkeit der Störung (mit Priorität 1 Kritisch/Critical).

• Meldungen und Meldepflichten des Auftragnehmers gegenüber der Aufsicht werden beachtet und eingehalten.

• Der Auftraggeber unterstützt den Auftragnehmer bei der Beurteilung der Melderele- vanz im Störungsfall.

• Der Auftraggeber unterstützt die Abgabe der Meldung durch Zulieferung benötigter In- formationen, die dem Auftragnehmer nicht zur Verfügung stehen.

Der Auftragnehmer sollte nach Möglichkeit spätestens innerhalb eines Monats aus einem Not- betrieb wieder in einen Regelbetrieb zurückkehren. Dies bedeutet, dass sämtliche plan- und nachweisbaren Change- und Dokumentationsanforderungen sowie alle Sicherheits- und Frei- gabeanforderungen wieder vollständig angewendet werden (einschließlich dokumentierter Ab- weichungen zum Normalbetrieb), Dies gilt auch dann, wenn einzelne implementierte Punkte noch nicht dem Stand vor dem Incident entsprechen

Je nach Status des melderelevanten Incidents (KRITIS oder mit Flag „Unterstützung kwF“) sind unterschiedliche Inhalte an die Aufsichtsbehörden zu melden. Der Auftragnehmer unter- stützt die Meldungen durch Zulieferung der erforderlichen Informationen nach den folgenden Anforderungen:

2.4.1 Erstmeldung

Der Auftragnehmer stellt sicher bzw. wirkt dabei mit, dass dem Auftraggeber unverzüglich die nachfolgenden Informationen inhaltlich so zur Verfügung stehen, dass der Auftraggeber seiner Pflicht zur Erstmeldung an die Aufsichtsbehörden nachkommen kann. Mit der Erstmeldung an den Auftraggeber, die so schnell wie möglich, spätestens 4 Stunden nach der Erkennung eines Vorfalls, getätigt werden muss, wird der Auftragnehmer die folgenden Mindestinforma- tionen mitteilen:

• Eindeutige Incident-Referenznummer

• Datum und Zeitpunkt der Erkennung des Incidents. Sofern ein Change den Incident ausgelöst hat, gilt Folgendes:

• Bei einem Service, der 24/7 verfügbar sein muss, entspricht der Endzeitpunkt des Change-Fensters dem Zeitpunkt der Erkennung des Incidents

Seite 8 von 11

[Seite 9]

Anhang 19.1 – Incident Management

• Bei allen anderen Services entspricht der auf den Change folgende Beginn der Servicezeit dem Zeitpunkt der Erkennung des Incidents

• Datum und Zeitpunkt der Klassifizierung des Incidents

• Beschreibung des Incidents

• Klassifizierungs-Kriterien, die Grund für den Incident-Report waren

• die geographische Ausdehnung des Incidents, optional auch die vom Incident betroffe- nen EU-Mitgliedsstaaten

• Information über die Umstände der Entdeckung des Incidents

• Informationen über den Ursprung des Incidents, falls verfügbar, insbesondere, ob ein erfolgreicher böswilliger und unbefugter Zugriff auf Netzwerk- und Informationssysteme vorlag und dies zu Verlusten von Daten führen kann

• Information darüber, ob ein Business-Continuity-Plan eingesetzt wurde

• Information über die Herunterstufung eines Incidents von „Kritisch“ auf „Hoch“, falls anwendbar

• Weitere verfügbare Informationen, insbesondere

• ob der Incident mehr als 24h andauert oder eine kritische/wichtige Funktion mehr als 2h ausfällt
• die Zahl möglicher Betroffener, falls verfügbar
• Verluste von Daten

• Kosten des Incidents, sofern sie über 100.000,- € liegen.

2.4.2 Zwischenmeldung

Der Auftragnehmer stellt sicher bzw. wirkt dabei mit, dass dem Auftraggeber unverzüglich die nachfolgenden Informationen inhaltlich so zur Verfügung stehen, dass der Auftraggeber seiner Pflicht zur Zwischenmeldung an die Aufsichtsbehörden nachkommen kann. Im weiteren Ver- lauf der Störung informiert der Auftragnehmer den Auftraggeber bei wesentlichen Änderungen des Status, spätestens jedoch innerhalb von 72 Stunden nach der Einstufung des Vor- falls als schwerwiegend, oder wenn die regulären Aktivitäten wiederhergestellt sind und der Geschäftsbetrieb wieder normal läuft. Die Zwischenmeldung enthält die folgenden Informatio- nen, die, soweit möglich, vom Auftragnehmer zugeliefert und bei Änderungen aktualisiert wer- den:

• Incident-Referenznummer der Aufsichtsbehörde, falls vorhanden

• Datum und Zeitpunkt des Auftretens des Incidents

• gegebenenfalls Datum und Zeitpunkt, wann der Auftraggeber seine regulären Tätigkei- ten wieder aufgenommen hat

• Klassifizierungs-Kriterien, die Grund für den Incident-Report waren

Seite 9 von 11

[Seite 10]

Anhang 19.1 – Incident Management

• Incident-Typ

• gegebenenfalls vom Angreifer verwendete Bedrohungen und Techniken

• betroffene Funktionsbereiche und Geschäftsprozesse

• Auswirkungen auf die finanziellen Interessen der Kunden

• Informationen über Meldungen an andere Behörden

• geplante oder bereits ausgeführte vorläufige Handlungen und Maßnahmen, die unter- nommen wurden, um den Incident zu lösen

• gegebenenfalls Informationen über Anzeichen einer Kompromittierung.

2.4.3 Abschlussmeldung

Der Auftragnehmer stellt sicher bzw. wirkt dabei mit, dass dem Auftraggeber unverzüglich die nachfolgenden Informationen inhaltlich so zur Verfügung stehen, dass der Auftraggeber seiner Pflicht zur Abschlussmeldung an die Aufsichtsbehörden nachkommen kann. Spätestens ei- nen Monat nach der Einstufung des Vorfalls als schwerwiegend teilt der Auftragnehmer die erforderlichen Informationen für die Abschlussmeldung mit. Ist der Vorfall noch nicht gelöst, beträgt die Frist einen Tag nach endgültiger Klärung des Vorfalls.

Die Abschlussmeldung enthält die folgenden Informationen, die, soweit möglich, vom Auftrag- nehmer zugeliefert und bei Änderungen aktualisiert werden:

• Informationen über die Ursache (den Root Cause) des Incidents

• Datum und Zeitpunkt, an dem der Incident gelöst wurde

• Datum und Zeitpunkt, an dem die Ursache beseitigt wurde

• Informationen darüber, wie der Incident gelöst wurde

• gegebenenfalls Informationen, die für die Abwicklungsbehörde relevant sind

• Informationen über direkte und indirekte Kosten und Verluste, die sich aus dem Inci- dent ergeben, sowie Informationen über finanzielle Rückflüsse

• gegebenenfalls Informationen über wiederkehrende Vorfälle.

2.5 Leistungen und Verantwortlichkeiten

Im Folgenden sind die für das Incident Management notwendigen Leistungen, die durch die Auftragnehmer (AN) und den Auftraggeber (AG) zu erbringen sind, definiert. Dabei ist jeder Leistung eine Verantwortlichkeit gemäß RACI-Matrix aus Anlage 19 Servicemanagement zugeordnet.

Seite 10 von 11

[Seite 11]

Anhang 19.1 – Incident Management

Tabelle 4: Incident Management RACI

3 Prozesseinbindung und -schnittstelle

Im Rahmen der Serviceerbringung arbeitet der Auftragnehmer eng mit dem Auftraggeber zu- sammen.

Die Einzelheiten der Zusammenarbeit werden im Zuge der Leistungsübernahme gemeinsam von beiden Parteien festgelegt, in konkrete Prozessschritte überführt und entsprechend doku- mentiert.

Die operative Zusammenarbeit erfolgt entweder über eine Toolschnittstelle oder durch ein On- boarding des Auftragnehmers in das System des Auftraggebers.

4 Reporting

Der Auftragnehmer stellt dem Auftraggeber die in Anlage 2 Berichtswesen definierten Ser- vice Level-Reports zum Incident Management in der vereinbarten Form bereit.

Seite 11 von 11