[Seite 1]
Anhang 3
Informationssicherheit
zu Anlage 3 Datenschutz und Informationssicherheit
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
genannt -
– zusammen auch „Vertragspartner“, „Vertragsparteien“ oder „Parteien“
genannt –
Version 0.9
[Seite 2]
Anhang 3 – Informationssicherheit
INHALTSVERZEICHNIS
Präambel 3
Glossar und Definitionen 4
1 Geltungsbereich, Governance 6
2 Sicherheitsanforderungen 6
3 Abgleich von Informationssicherheitsvorgaben 7
4 (Bedrohungsorientierte) Penetrationstests (TLPT) 9
5 Security Incident Management / IKT-bezogenene Vorfälle 9
6 Schwachstellenmanagement 9
7 Sensibilisierung und Schulung 13
8 Informationssicherheitsaudits 13
9 Kommunikation 15
10 Übertragung von Informationen 15
11 Berichte zur Informationssicherheit 16
12 Informationsrisikomanagement 16
13 Subunternehmer 17
14 Anhänge 17
Seite 2 von 17
[Seite 3]
Anhang 3 – Informationssicherheit
Präambel
Diese Unterlage und ihre Anhänge konkretisieren die in Ziffer 18 Datenschutz und Informationssicherheit des Rahmenvertrags definierten Sicherheitsanforderungen.
Beide Parteien verpflichten sich, eine dem Stand der Technik entsprechende Informationssicherheitspolitik in den eigenen Regelwerken und Anweisungen sowie in der täglichen Praxis umzusetzen.
Die nachfolgenden Regelungen legen den Inhalt und die weitere inhaltliche Konkretisierung der Verpflichtungen fest, die sich hieraus für die Parteien ergeben.
Bei Widersprüchen zwischen den Regelungen dieses Anhangs nebst den Regelungen der weiteren zu diesem Anhang gehörenden Anhänge (im Folgenden kurz: „Anhang“) und dem Rahmenvertrag nebst Anlagen, Anhängen und Einzelverträgen gehen die Regelungen in diesem Anhang dem Rahmenvertrag nebst Anlagen, Anhängen und Einzelverträgen vor.
Seite 3 von 17
[Seite 4]
Anhang 3 – Informationssicherheit
Glossar und Definitionen
| Begriff | Erklärung |
|---|---|
| Informationssicherheitsaudit | Unter dem Begriff Informationssicherheitsaudit wird die Kontrolle und Überwachung der für die Helaba erbrachten Leistungen auf Einhaltung der vereinbarten Regelungen zur Informationssicherheit und der daraus abgeleiteten Umsetzungsstrategien und Sicherheitskonzepte verstanden. Ziel von Informationssicherheitsaudits ist es, die Angemessenheit und Wirksamkeit der mit der Helaba vereinbarten Anforderungen zur Informationssicherheit auf Grundlage des Sicherheitskonzepts und dieses Vertrages zu kontrollieren (Soll-Ist-Abgleich). |
| Internetapplikationen | Programme, die über das Internet in einem Webbrowser ausgeführt werden |
| Mitigierende Maßnahmen | Situationsbedingte Maßnahme zur Wiederherstellung eines angemessenen Sicherheitsniveaus bzw. zur Beseitigung der Ursache des potenziellen oder eingetretenen Sicherheitsvorfalls. |
| Online-Zahlungsdienste | Zahlungsdienste im Sinne des Gesetzes über die Beaufsichtigung von Zahlungsdiensten (Zahlungsdiensteaufsichtsgesetz - ZAG). |
| Security Event (sicherheits- relevantes Ereignis) | Ein Security Event ist ein unbewertetes Ereignis, welches die Verfügbarkeit, Vertraulichkeit oder Integrität von Informationen, unabhängig von der Verarbeitungsform (elektronisch oder papierhaft), beeinträchtigen könnte und damit eine Störung überschreitet. |
| Security Incident (Infor- mationssicherheitsvorfall) | Ein Security Incident ist ein bewertetes Ereignis, das über den Security Event hinausgeht und bei dem davon auszugehen ist, dass eine Beeinträchtigung der Verfügbarkeit (auch wenn die Bearbeitung der BCM- Organisation obliegt), der Vertraulichkeit oder der Integrität von Informationen und damit der Informationssicherheit sehr wahrscheinlich vorliegt oder eine erfolgreiche Kompromittierung bereits eingetreten ist. |
| Schnittstellen | Schnittstellen bedeutet Kommunikation zwischen dedizierten Ansprechpartnern und in gemeinsamen Gremien. Kommunikationsschnittstellen werden durch beide Vertragsparteien in der Kommunikationsmatrix (Anhang 7.1) benannt. |
Seite 4 von 17
[Seite 5]
Anhang 3 – Informationssicherheit
| Sicherheitsanfrage | Anfrage via Incident Management Tool, um sicherheitsrelevante Informationen einzuholen, die beispielsweise benötigt werden, um das Regelwerk der Helaba und SIEM Use Cases zu optimieren. |
|---|---|
| Shared Assets / Mehrmandantensysteme | Shared Assets/ Mehrmandantensysteme sind Systeme oder Netzwerkkomponenten in Software und Hardware, die durch den Auftragnehmer zur Leistungserbringung bei mehreren Kunden genutzt werden (nicht dediziert). |
| Störung | Eine Störung bezieht sich auf ungeplante Abweichungen vom Regelbetrieb, die keine Auswirkungen auf die Vertraulichkeit und Integrität von Informationen haben oder die Verfügbarkeitseinschränkungen von Informationen noch nicht dazu geführt haben, dass das Ausrufen eines Notfalls oder die Initiierung des Business Continuity Management/Notfall- und Krisenmanagements erforderlich wurde. |
| Transaktionsbasierte Systeme | Als solche werden Anwendungen bezeichnet, deren Zweck die Abwicklung eines diskreten Vorgangs ("Transaktion") zwischen Anwender und System zur Unterstützung geschäftstätiger oder sonstiger programmatischer Anliegen darstellt. Ziel der Informationssicherheit in diesem Kontext ist es, Informationen, die an den Transaktionen der Anwendungsdienste beteiligt sind, so zu schützen, dass eine unvollständige Übertragung, Fehlleitung, unbefugte Offenlegung, unbefugte Vervielfältigung oder unbefugte Wiederholung von Nachrichten verhindert wird. |
| Virtualisierungsschicht | Die Virtualisierungsschicht (alle Anteile unterhalb des Betriebssystems / OS) gilt als Shared Service. |
Seite 5 von 17
[Seite 6]
Anhang 3 – Informationssicherheit
1 GELTUNGSBEREICH, GOVERNANCE
1.1 Informations- und Cyber-Sicherheit sind relevant für alle Leistungen aus dem zu Grunde liegenden Rahmenvertrag und damit für jede Leistungserbringung zu berücksichtigen. Die Helaba hat das Recht, dem Auftragnehmer ergänzend zu diesem Anhang 3 Vorgaben für die physische, technische und logische Informations- und Cyber-Sicherheit sowie zu Prozessen zu machen.
1.2 Die Regelungen dieses Anhangs gelten grundsätzlich für jedes Betriebsmodell oder Art der technischen Umsetzung sowie für alle Daten, Systeme und Services im Scope des zu Grunde liegenden Rahmenvertrages (dediziert oder Shared Services inkl. Shared Assets, Cloud, Virtualisierung und Container, Netzwerkkomponenten etc.).
1.3 Werden in Abstimmung mit der Helaba zur Leistungserbringung Mehrmandantensysteme, transaktionsbasierte Systeme, Internetapplikationen und Online-Zahlungsdienste genutzt, sind zusätzliche Informationssicherheitsvorgaben anwendbar. Die Details ergeben sich aus Anhang 3.1 Anforderungskatalog.
1.4 Bei Neueinführungen und bei Anpassungen ist die fachliche Konfiguration zur Umsetzung der Vorgaben durch den Auftragnehmer auf Anforderung der Helaba durch entsprechende Vorgaben darzustellen (z.B. fachliche Richtlinien).
2 Sicherheitsanforderungen
2.1 Der Auftragnehmer betreibt ein Informationssicherheits-Managementsystem (ISMS), durch welches er die Informationssicherheit der in seiner Verantwortung stehenden Datenbestände und Informationssysteme hinsichtlich Verfügbarkeit, Vertraulichkeit, Integrität und Authentizität steuert. Die Umsetzung des ISMS erfolgt unter anderem über IT-Sicherheitsprozesse, -Verfahren und Sicherheitsmaßnahmen. Diese berücksichtigen für deren Ausgestaltung und Aufrechterhaltung folgenden einschlägigen und branchenüblichen Regelungen:
• Rundschreiben 05/2023 (BA) - Mindestanforderungen an das Risikomanagement – MaRisk • Verordnung (EU) 2022/2554 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die digitale operationale Resilienz im Finanzsektor und zur Änderung der Verordnungen (EG) Nr. 1060/2009, (EU) Nr. 648/2012, (EU) Nr. 600/2014, (EU) Nr. 909/2014 und (EU) 2016/1011 • Rundschreiben 10/2017 (BA) in der Fassung vom 16.08.2021 - Bankaufsichtliche Anforderungen an die IT (BAIT) • EBA Guidelines on ICT and security risk management • EZB-Vorgaben zur Informations- und Cybersicherheit (z.B. Rundschreiben) • Meldungen öffentlicher CERTs inkl. des S-CERT • TIBER EU Framework.
2.2 Das ISMS ist eine Aufstellung von Verfahren und Regeln innerhalb eines Unternehmens, welche dazu dienen, die Informationssicherheit dauerhaft zu definieren, zu steuern, zu kontrollieren, aufrechtzuerhalten und fortlaufend zu verbessern. Das ISMS verfolgt dabei die Ziele,
Seite 6 von 17
[Seite 7]
Anhang 3 – Informationssicherheit
a) die Einhaltung der Sicherheitsziele Integrität, Verfügbarkeit, Vertraulichkeit und Authentizität zu gewährleisten,
b) die Erkennung und Vermeidung von IT-Risiken, Ermittlung und Umsetzung von Maßnahmen zur Risikoreduktion zu ermöglichen und
c) die Umsetzung rechtlicher Anforderungen zu gewährleisten.
2.3 Für den Nachweis der standardkonformen Umsetzung des ISMS erfolgt eine Zertifizierung nach ISO 27001. Der Scope des ISMS entspricht dem, der im aktuellen Zertifikat hinterlegt und bescheinigt ist. Das jeweils gültige Zertifikat und das zugehörige Statement of Applicability sind jährlich und bei Änderungen vorzulegen.
2.4 Der Auftragnehmer wird für die an die Helaba bereitgestellten Leistungen die in diesem Anhang 3 definierten Sicherheitsziele durch geeignete Maßnahmen, mindestens jedoch die in diesem Anhang 3 inkl. Anhänge definierten Maßnahmen, sicherstellen. Sofern erforderlich, wird der Auftragnehmer zur Erreichung des vereinbarten Sicherheitsniveaus weitere ergänzende Maßnahmen definieren und umsetzen. Dieses Sicherheitsniveau muss während der Vertragslaufzeit aufrechterhalten werden.
2.5 Zur Dokumentation des Sicherheitsniveaus hat der Auftragnehmer ein Sicherheitskonzept zu erstellen und dieses der Helaba bereitzustellen. Das Sicherheitskonzept zeigt auf, über welche Maßnahmen das Sicherheitsniveau und damit die Sicherheitsziele erreicht werden. Es ist laufend zu aktualisieren und enthält die Beschreibung der Berücksichtigung der vereinbarten Sicherheitsziele, Maßnahmen, Vorgaben und Kontrollen in der schriftlich fixierten Ordnung des Auftragnehmers. Sofern die relevanten Informationen aus Anhang 3.1 Anforderungskatalog hervorgehen, kann dieser als Sicherheitskonzept dienen.
2.6 Die Helaba ist berechtigt, die Einhaltung der in diesem Anhang vereinbarten Pflichten im Rahmen der in Kapitel 8 definierten Regelungen zu prüfen. Dabei kann sie im Zusammenhang mit den vertraglichen Leistungen insbesondere Auskünfte anfordern, Einsicht in die Geschäftsunterlagen nehmen, Geschäftsräume betreten und sich Zugang zu Daten und Datenbanken verschaffen.
3 Abgleich von Informationssicherheitsvorgaben
3.1 Der Auftragnehmer verpflichtet sich, die in Anhang 3.1 Anforderungskatalog definierten Informationssicherheitsvorgaben der Helaba auf ihre Umsetzbarkeit hin zu prüfen und zu bewerten. Hierzu hat der Auftragnehmer diese Vorgaben mit den in seinem Unternehmen geltenden Informationssicherheitsdokumenten (z. B. Richtlinien, Verfahren, Arbeitsanweisungen, Handbücher) abzugleichen. Dieser Abgleich enthält insbesondere Aussagen zur Anwendbarkeit und zum Erfüllungsgrad der Vorgaben und dient darüber hinaus der Dokumentation von Abweichungen. Das Ergebnis der Gegenüberstellung wird verbindlich in Anhang 3.1 Anforderungskatalog festgeschrieben und Bestandteil dieser Vereinbarung.
3.2 Der Auftragnehmer verpflichtet sich, Vorgaben der Helaba zu prüfen und zu bewerten, mit der Helaba abzustimmen, im abgestimmten Umfang umzusetzen und deren Aufrechterhaltung sicherzustellen.
Seite 7 von 17
[Seite 8]
Anhang 3 – Informationssicherheit
3.3 Können Vorgaben ganz oder teilweise nicht umgesetzt oder nicht eingehalten werden, ist dies schriftlich zu begründen. Darüber informiert der Auftragnehmer die Helaba im Rahmen der Abstimmung, schlägt kompensierende Alternativen und einen Umsetzungsplan dazu vor.
3.4 Die Tätigkeiten des Auftragnehmers zur Prüfung und Bewertung umfassen:
• Bewertung der Helaba Vorgaben, welche die vom Auftragnehmer betriebenen oder dazu erforderlichen Komponenten betreffen.
• Rückmeldung zur Umsetzbarkeit der Vorgaben innerhalb von 10 Bankarbeitstagen, sofern im Einzelfall kein anderer Zeitraum vereinbart wurde.
• Vorlage von kompensierenden Alternativmaßnahmen, sofern einzelne Vorgaben nicht umsetzbar sind.
• Vorlage einer Umsetzungsplanung, sofern Vorgaben nicht direkt umgesetzt werden können.
• Sicherstellung der Umsetzung der abgestimmten Sicherheitsvorgaben.
• Sicherstellung der Aufrechterhaltung der Umsetzung von Sicherheitsvorgaben.
• Verpflichtende Meldung von Abweichungen von den abgestimmten Vorgaben über den Standard-Incident-Prozess innerhalb von 2 Bankarbeitstagen, nachdem die Abweichung erkannt und eingetreten ist. Dies gilt auch für temporäre Abweichungen.
• Information an und Abstimmung mit der Helaba bei Änderungsnotwendigkeiten an einzelnen Vorgaben.
• Dokumentation der Vorgaben.
3.5 Die Helaba hat das Recht, einmal jährlich eine Aktualisierung der in Anhang 3.1 Anforderungskatalog definierten Vorgaben durchzuführen. Der Auftragnehmer ist verpflichtet, die Aktualisierung aktiv zu unterstützen und der Helaba auf Anfrage die relevanten Informationssicherheitsdokumente in der aktuellen Fassung zur Verfügung zu stellen. Die Änderungen oder Ergänzungen gegenüber der Vorversion wird die Helaba kenntlich machen. Die Helaba ist berechtigt, Kopien der Informationssicherheitsdokumente des Auftragnehmers anzufertigen.
3.6 Erfolgen unterjährig möglicherweise wesentliche Änderungen an den Informationssicherheitsdokumenten des Auftragnehmers, so erfolgt die Zurverfügungstellung dieser anlassbezogen. Wesentlich sind insbesondere solche Änderungen, die das vereinbarte Sicherheitsniveau beeinträchtigen können. Die Änderungen oder Ergänzungen gegenüber der Vorversion wird der Auftragnehmer kenntlich machen. Sollten die Änderungen Auswirkungen auf das Sicherheitsniveau haben, werden die Vertragsparteien gemeinsam eine Aktualisierung des Anhangs 3.1 Anforderungskatalog durchführen.
Seite 8 von 17
[Seite 9]
Anhang 3 – Informationssicherheit
3.7 Soweit der Auftragnehmer plant, vereinbarte Leistungsinhalte und damit das vereinbarte Sicherheitsniveau in Zukunft nicht mehr zu vollständig zu unterstützen, so ist dies, soweit nicht besondere Umstände vorliegen, mit einem Vorlauf von mindestens zwölf (12) Monaten anzukündigen.
3.8 Über die Notwendigkeit der Behandlung von identifizierten Abweichungen werden sich die Vertragsparteien abstimmen. Sofern aus dieser Abstimmung Folgemaßnahmen hervorgehen, sind diese zu dokumentieren.
4 (Bedrohungsorientierte) Penetrationstests (TLPT)
4.1 Der Auftragnehmer verfügt über einen angemessenen Rahmen für Penetrationstests und geeignete Standards, um die Frequenz von Penetrationstests und bedrohungsorientierten Penetrationstests zu regeln.
4.2 Der Auftragnehmer ist verpflichtet, an den TLPT der Helaba teilzunehmen. Auf Wunsch der Helaba sind die Ergebnisse der letzten bedrohungsorientierten Penetrationstests vom Auftragnehmer zur Verfügung zu stellen. Auf Wunsch der Helaba und nur in dem Umfang, der gemäß den anwendbaren Rechtsvorschriften erforderlich ist, wird der Auftragnehmer einen gebündelten bedrohungsorientierten Penetrationstest durch einen zugelassenen externen Tester ermöglichen, soweit dem keine zwingenden gesetzlichen oder aufsichtsrechtlichen Vorgaben, denen der Auftragnehmer unterliegt, entgegenstehen.
5 Security Incident Management / IKT-bezogenene Vorfälle
5.1 Bei Sicherheitsverstößen, Vorfällen oder Abweichungen von Sicherheitsvorgaben oder Verfahren informieren sich die Parteien unverzüglich gegenseitig. Bei erkannten, eingetretenen Sicherheitsvorfällen und daraus resultierenden Maßnahmen, die die Leistungserbringung gegenüber der Helaba berühren, erfolgt eine elektronische Meldung innerhalb von 24 Stunden. Die Meldungen können via E-Mail oder toolbasiert veranlasst werden.
5.2 Der Auftragnehmer wird geeignete Maßnahmen zur Benachrichtigung und Meldung von IKT-bezogenen Vorfällen ergreifen. Der Auftragnehmer wird die Helaba in geeigneter Weise über die Benachrichtigungs- und Meldemaßnahmen informieren. Der Auftragnehmer wird mit der Helaba zusammenarbeiten und die von der Helaba benötigten Unterstützungsleistungen und Informationen bereitstellen.
6 Schwachstellenmanagement
6.1 Grundsätzliches
(1) Der Auftragnehmer verpflichtet sich, ein eigenes Schwachstellenmanagement durchzuführen, um Schwachstellen auf allen von ihm verantworteten und für die vertragsgegenständliche Leistungserbringung relevanten Systemen und Komponenten zu identifizieren und schnellstmöglich zu bearbeiten.
(2) Der Auftragnehmer ist verantwortlich für die Erkennung, Bewertung, Priorisierung und fachliche Bearbeitung von Schwachstellen, die die vertragsgegenständlichen Leistungen betreffen. Die Verantwortung umfasst alle erforderlichen Maßnahmen zur
Seite 9 von 17
[Seite 10]
Anhang 3 – Informationssicherheit
Gefährdungsbegrenzung, inklusive kurzfristiger Workarounds, Konfigurationsänderungen, Patches, Tests und Dokumentation.
(3) Der Auftragnehmer verpflichtet sich, identifizierte Schwachstellen auf allen von ihm verantworteten und im Rahmen der Leistungserbringung für den Auftraggeber eingesetzten Systemen und Komponenten zu beheben. Damit verbundene Kosten sind vom Auftraggeber nur dann zu erstatten, wenn die Schwachstelle nachweislich durch den Auftraggeber selbst oder von ihm beauftragte Dritte verursacht wurde.
(4) Der Auftragnehmer implementiert Prozesse und Regelungen, um diesem bekanntwerdende oder vom Auftraggeber gemeldete Schwachstellen im Kontext der Leistungserbringung innerhalb der vereinbarten Bearbeitungszeit zu beheben. Darüber hinaus ist der Auftragnehmer verpflichtet, Herstellermeldungen oder Schwachstellenmeldungen eines CERT-Dienstleisters (z.B. S-CERT) für die im Leistungsumfang eingesetzten Systemumgebungen und -komponenten täglich zu sichten und zu bewerten.
6.2 Bearbeitungszeit
(1) Der Auftragnehmer verpflichtet sich, alle ihm bekanntwerdenden oder gemeldeten sicherheitsrelevanten Schwachstellen gemäß den nachfolgenden Fristen zu bewerten, zu priorisieren und entsprechende Maßnahmen einzuleiten. Die Bearbeitungszeit richtet sich nach der Kritikalität der Schwachstelle gemäß nachfolgender Kategorisierung:
| Bearbeitungszeit | |||||
|---|---|---|---|---|---|
| Kritikalität | Zeit | ||||
| kritisch | 7 Tage | ||||
| hoch | 45 Tage | ||||
| mittel | 90 Tage | ||||
| niedrig | 180 Tage |
Die Definition und Bestimmung der Kritikalität der Schwachstellen wird im Rahmen der Leistungsübernahme zwischen den Vertragsparteien abgestimmt. Bei der Definition sollten neben der offiziellen Kritikalität der Schwachstelle (z.B. CVSS oder S-CERT Risikostufe) auch das betroffene Objekt (z.B. Schutzbedarf) und die Exponiertheit des Systems (z.B. Zugriff aus dem Internet) mit einbezogen werden.
(2) Die Bearbeitungszeit umfasst den Zeitraum vom Zeitpunkt der Identifizierung der Schwachstelle, bis zur Umsetzung der Behandlung der Schwachstelle. Der Auftragnehmer verpflichtet sich zur Einhaltung der hier definierten Bearbeitungszeiten, für die in seiner Verantwortung liegenden Systeme und Komponenten.
(3) Zusätzlich gilt, dass
• Schwachstellen mit kritischer oder hoher Ersteinstufung innerhalb von 24 Stunden nach Eingang bewertet werden und der weiterführend geltenden Kritikalität und damit einer Bearbeitungszeit zugeordnet werden.
Seite 10 von 17
[Seite 11]
Anhang 3 – Informationssicherheit
• Schwachstellen mit mittlerer oder niedriger Ersteinstufung spätestens innerhalb von 7 Kalendertagen zu bewerten sind und • dem Auftraggeber anlassbezogen ein Ad-hoc Schwachstellenbericht bereitzustellen ist (siehe Anlage 2 Berichtswesen).
(4) Sollte der Auftragnehmer die Bearbeitungszeit von kritischen Schwachstellen überschreiten, ist unverzüglich eine Information an den Auftraggeber und den Verantwortlichen des Schwachstellenmanagements abzugeben. In diesem Fall ist der Auftragnehmer verpflichtet:
• die Ursachen der Verzögerung schriftlich darzulegen • eine überarbeitete Zeitplanung vorzulegen • sicherzustellen, dass die Schwachstelle priorisiert abgearbeitet wird.
(5) Der Auftragnehmer hat alle Bearbeitungsschritte, Bewertungen und Kommunikationsvorgänge nachvollziehbar zu dokumentieren. Diese Nachweise sind auf Anfrage im Rahmen von internen oder externen Audits (z. B. nach ISO 27001, BSI- Grundschutz, DORA, NIS2) bereitzustellen. Die Pflichtinhalte der Ergebnisdokumentation umfassen:
• Bezeichnung und ursprüngliche Kritikalitätsbewertung der Schwachstelle (z.B. CVE-Nummer und CVSS-Score) • Bewertung durch den Auftragnehmer • empfohlene Maßnahme / Patch / Konfigurationsänderung • geplantes und tatsächliches Umsetzungsdatum • Nachweis der Beseitigung (z. B. Screenshot, Log, Ticketlink).
6.3 Zero-Day-Schwachstellen
(1) Dieses Kapitel definiert die Anforderungen an die Behandlung von Zero- Day-Schwachstellen (ZDS) sowie die hierfür geltenden verkürzten Reaktions- und Bearbeitungszeiten durch den Auftragnehmer. Ziel ist die Minimierung der Sicherheitsrisiken, die im Rahmen der Leistungserbringung des Auftragnehmers für den Auftraggeber entstehen können.
(2) Eine ZDS ist eine bislang unbekannte Sicherheitslücke, die zum Zeitpunkt ihrer Offenlegung bereits aktiv ausgenutzt wird. ZDS sind unverzüglich einer Behandlung zuzuführen sowie als „potenzieller“ Security Incident im Security Incident Management Prozess zu klassifizieren, weil eine Ausnutzung beim Auftraggeber bereits passiert sein könnte oder zeitnah erfolgen kann.
6.3.1 Unverzügliche Behandlung von ZDS
(1) Im Kontext des Schwachstellenmanagement des Auftraggebers, bedeutet "unverzüglich", dass eine notwendige Handlung ohne schuldhaftes Zögern und ohne unnötige Verzögerung vorgenommen werden muss. Es impliziert eine sofortige Reaktion auf ein Ereignis oder eine Anforderung, sobald die Notwendigkeit erkannt wurde und die technischen sowie organisatorischen Möglichkeiten zur Verfügung stehen.
(2) "Unverzüglich" ist keine feste Zeitspanne (z.B. 24 Stunden), sondern eine Handlungsmaxime. Die tatsächlich benötigte Zeit kann je nach Art und Komplexität des Ereignisses variieren.
Seite 11 von 17
[Seite 12]
Anhang 3 – Informationssicherheit
(3) Die Dringlichkeit der Situation bestimmt das Ausmaß der Unverzüglichkeit. Bei kritischen Situationen, insbesondere bei einer zu erwartenden oder bereits stattgefundenen Ausnutzung einer ZDS, wird eine unmittelbare Reaktion des Auftragnehmers ohne schuldhaftes Zögern erwartet.
(4) Der Auftragnehmer ist verpflichtet, die Dringlichkeit eigenständig und fachlich begründet vorläufig einzuschätzen und entsprechende Maßnahmen unverzüglich einzuleiten, ohne eine vorherige Abstimmung mit dem Auftraggeber abzuwarten.
(5) Die abschließende bindende Festlegung der Dringlichkeit kann durch den Auftraggeber erfolgen. Erfolgt eine abweichende Bewertung durch den Auftraggeber, hat der Auftragnehmer seine Maßnahmen entsprechend anzupassen.
(6) Bei weniger kritischen Angelegenheiten, bei denen nach fachlicher Bewertung eine zeitnahe Ausnutzung unwahrscheinlich ist, kann eine Behandlung innerhalb von bis zu drei Werktagen als unverzüglich gelten.
(7) Die Verfügbarkeit von Personal, Systemen und Informationen spielt eine Rolle. Es wird erwartet, dass alle verfügbaren Ressourcen sofort und effektiv eingesetzt werden, um die erforderliche Maßnahmen, dazu zählt vor allem eine Erstbewertung, durchzuführen.
(8) Auch wenn es keine starre Frist gibt, ist es für den Auftraggeber von wesentlicher Bedeutung, alle durchgeführten Schritte und die Gründe für etwaige Verzögerungen vollständig und nachvollziehbar zu dokumentieren, um die Einhaltung des Gebots der "Unverzüglichkeit" nachweisen zu können.
6.3.2 Umsetzung von ZDS-Maßnahmen
(1) Der Auftragnehmer informiert den Auftraggeber unverzüglich, spätestens jedoch binnen 24 Stunden nach Bekanntwerden oder erstmaligem Verdacht. Die Erstinformation enthält mindestens: • betroffene Systeme • Schweregrad (CVSS oder äquivalente Einordnung) • kurz skizzierte exploit-Relevanz • vorgeschlagene Sofortmaßnahmen • bereits durchgeführte Mitigation.
(2) Binnen 48 Stunden nach Bekanntwerden der ZDS legt der Auftragnehmer einen initialen Maßnahmenplan vor (inkl. Risikobewertung, Priorisierung, und vorgeschlagener Change-Strategie).
(3) Die Informationen an das Schwachstellenmanagement des Auftraggebers erfolgt über die vereinbarten und etablierten Kommunikationskanäle in Anhang 7.1 Kommunikationsmatrix.
(4) Der Auftragnehmer verpflichtet sich, erforderliche Maßnahmen zur Beseitigung oder wirksamen Kompensation der Schwachstelle so umzusetzen, dass die produktivrelevanten Risiken unverzüglich ab dem Zeitpunkt, ab dem alle notwendigen Informationen und Zugriffe durch den Auftraggeber bereitgestellt wurden, minimiert bzw. behoben werden können.
(5) Abweichungen hiervon sind nur zulässig, wenn diese technisch unvermeidbar sind. In diesem Fall ist der Auftragnehmer verpflichtet, unverzüglich kompensierende
Seite 12 von 17
[Seite 13]
Anhang 3 – Informationssicherheit
Maßnahmen zu etablieren und schriftlich eine detaillierte Begründung und einen neuen verbindlichen Termin vorzulegen.
(6) Sämtliche Umsetzungen erfolgen primär über das vereinbarte Change Management- Verfahren. Für Zero-Day-Fälle ist das Notfall IT-Change Verfahren anzuwenden.
(7) Das Patchen von exponierten Systemen muss innerhalb von 72 Stunden nach Bekanntwerden der ZDS erfolgt sein.
(8) Werden Fristen nicht eingehalten, ist der Auftragnehmer verpflichtet, umgehend die in Anlage 7 Governance benannten Eskalationsstufen zu aktivieren (inkl. Nennung der verantwortlichen Personen, Maßnahmenplan und neuer Termine). Der Auftraggeber kann bei wiederholter oder gravierender Nichterfüllung geeignete Maßnahmen verlangen, bis hin zur Beauftragung von Drittparteien auf Kosten des Auftragnehmers zur Gefahrenabwehr.
(9) Alle Informationen zur ZDS, zu betroffenen Komponenten sowie zu durchgeführten Maßnahmen sind vertraulich zu behandeln und nur im erforderlichen Umfang an autorisierte Personen weiterzugeben.
(10) Nach Abschluss der Behandlung erstellt der Auftragnehmer innerhalb von 10 Kalendertagen einen Abschlussbericht, ggf. schon im Kontext des Change-/Notfall- Changeverfahrens vorhanden. Der Bericht muss mindesten die folgenden Informationen enthalten: Ursache, durchgeführte Maßnahmen, ggf. verbleibende Restrisiken und Empfehlungen/mögliche Verbesserungen. Der Auftragnehmer führt eine Lessons-Learned-Analyse durch und stellt dem Auftraggeber auf Wunsch ein Maßnahmen- bzw. Verbesserungsportfolio zur dauerhaften Risikoreduzierung bereit.
7 Sensibilisierung und Schulung
7.1 Um die korrekte Einhaltung und Umsetzung aller Informationssicherheitsrichtlinien beim Auftragnehmer zu gewährleisten, sind alle Mitarbeiter regelmäßig hinsichtlich Informationssicherheit zu schulen und zu sensibilisieren. Ein angemessenes Bewusstsein für Informationssicherheit ist bei Führungskräften und Mitarbeitern zu schaffen und aufrechtzuerhalten. Der Wissensstand der Mitarbeiter beim Auftragnehmer, die direkt mit Aufgaben der Informationssicherheit betraut sind, ist durch regelmäßige Fortbildungen auf aktuellem Niveau zu halten.
7.2 Der Auftragnehmer hat sicherzustellen, dass dessen Personal auf Anfrage der Helaba an Maßnahmen (z. B. Schulungen) der Helaba im Zusammenhang mit der Sensibilisierung für IKT-Sicherheit bzw. zur digitalen betrieblichen Resilienz teilnimmt.
8 Informationssicherheitsaudits
8.1 Die Helaba sowie von ihr beauftragte Dritte sind berechtigt Informationssicherheitsaudits beim Auftragnehmer zu jeder Zeit und nach vorheriger Ankündigung durchzuführen.
8.2 Der Auftragnehmer stellt der Helaba die für die Einhaltung der Umsetzung der relevanten Sicherheitsvorgaben erforderlichen Nachweise auf Anforderung entsprechend der Vertraulichkeitseinstufung elektronisch zur Verfügung. Jegliche Dokumentation ist so zu gestalten, dass sich fachkundige Dritte einen Überblick zum Stand der Umsetzung der Vorgaben der Helaba gemäß den Vereinbarungen aus dem Rahmenvertrag verschaffen
Seite 13 von 17
[Seite 14]
Anhang 3 – Informationssicherheit
können. Sollten bezüglich der Einsichtnahme Interessenskonflikte bestehen oder Vereinbarungen mit anderen Kunden verletzt werden, sind die entsprechenden Textpassagen durch den Auftragnehmer vor der Zurverfügungstellung zu anonymisieren.
8.3 Der Auftragnehmer darf ein solches Informationssicherheitsaudit nur ablehnen, wenn Gefahr im Verzug ist oder hieraus eine Beeinträchtigung des ordnungsgemäßen Geschäftsbetriebs resultiert. Der Mehraufwand eines Audits ist keine Beeinträchtigung des ordnungsgemäßen Geschäftsbetriebs.
8.4 Wird ein Informationssicherheitsaudit mit hoher Dringlichkeit eingestuft oder ist eine unverzügliche Prüfung aufgrund einer Anordnung einer Aufsichtsbehörde (z. B. BSI, EZB, BaFin) oder einer anderen gesetzlich zuständigen Behörde erforderlich, dann ist die Aufnahme der Prüfungshandlungen mit kurzen Fristen, ggfs. auch taggleich, während der üblichen Geschäftszeiten des Auftragnehmers, möglich.
8.5 Die Einstufung der Dringlichkeit eines Informationssicherheitsaudits obliegt dem Informationssicherheitsverantwortlichen der Helaba. Bei abweichenden Auffassungen hinsichtlich der Dringlichkeit gelten die Eskalationsverfahren in Anlage 7 Governance zum Rahmenvertrag.
8.6 Der Auftragnehmer hat ergänzend selbst regelmäßige Informationssicherheitsaudits durchzuführen. Alle Ergebnisse, Feststellungen und Mängel der Prüfungen sind der Helaba im Falle von schwerwiegenden Mängeln oder Schwachstellen unverzüglich, spätestens innerhalb von 10 Arbeitstagen nach Beendigung der Prüfungshandlungen darzulegen, soweit diese die Informationssicherheit der vertragsgegenständlichen Leistungen berühren. Die Helaba berücksichtigt diese Prüfungshandlungen und - ergebnisse bei der Durchführung eigener Prüfungshandlungen.
Seite 14 von 17
[Seite 15]
Anhang 3 – Informationssicherheit
9 Kommunikation
9.1 Zur effizienten Planung und Gestaltung der Zusammenarbeit werden die Informationssicherheitsverantwortlichen der Helaba und des Auftragnehmers regelmäßig Informationen austauschen Wenn und soweit die vertraglichen Leistungen der Helaba als wesentliche Auslagerung im Sinne des § 25b KWG eingestuft werden, stimmen sich die Vertragsparteien in mindestens jährlich stattfindenden Security- Meetings, insbesondere über geplante Maßnahmen sowie erfolgte und beabsichtigte Änderungen zur Informationssicherheit ab.
9.2 Die Security-Meetings sind entsprechend der folgenden Agenda durchzuführen:
a) Begrüßung und Besprechung offener Punkte aus dem letzten Meeting.
b) Zusammenfassung der letzten Berichterstattung durch den Dienstleister.
c) Sicherheitsvorfälle und Sicherheitsereignisse.
d) Durchgeführte Maßnahmen und Projekte.
e) In Audits identifizierte Schwachstellen/ Informationssicherheitsrisiken / Ergebnisse des ISO 27001-Prüfberichts.
f) Sicherheitsrelevante Informationen zu wesentlichen Weiterverlagerungen.
g) Änderungen in den Sicherheitsstandards/-vorgaben.
h) Status Gap-Analyse zur Informationssicherheit.
9.3 Ergänzend gelten die in der Anlage 7 Governance zum Rahmenvertrag festgelegten Governance-Strukturen.
10 Übertragung von Informationen
Die Übertragung von Informationen des Auftraggebers (auch an Dritte) ist nur unter Berücksichtigung der folgenden Punkte zulässig:
a) Nach vorheriger Zustimmung des Auftraggebers mindestens in Textform, sofern keine aufsichtsrechtlichen oder gesetzlichen Anforderungen zur Übermittlung von Kundeninformationen bestehen (z. B. Meldungen von Security Incidents im Rahmen der KRITIS-Verordnung),
b) unter Nutzung abgestimmter Kommunikationsmittel und -kanäle sowie
c) nach Etablierung angemessener technischer Sicherheitsmaßnahmen.
Seite 15 von 17
[Seite 16]
Anhang 3 – Informationssicherheit
11 Berichte zur Informationssicherheit
11.1 Der Auftragnehmer berichtet der Helaba aus gegebenem Anlass sowie regelmäßig über den Stand der Informationssicherheit. Wesentliche Inhalte des Berichtswesens sind:
(1) Berichterstattung aus gegebenem Anlass (ad-hoc):
i. Security Incidents im Sinne des Kapitels 5 und darauf erfolgte Reaktionen und Maßnahmen.
ii. Datenerhebungen von Strafverfolgungsbehörden und darauf erfolgte Reaktionen und Maßnahmen, sofern Daten der Helaba betroffen sind.
iii. Wesentliche Risiken sowie Maßnahmen zur Risikoreduktion/-vermeidung.
iv. Identifizierte kritische Schwachstellen.
(2) Jährlicher Informationssicherheitsbericht mit folgenden Inhalten:
i. Nachweis der wirksamen Umsetzung der vereinbarten Maßnahmen, Vorgaben und Kontrollen zur Informationssicherheit für das aktuelle Kalenderjahr.
ii. Aufstellung und Erläuterung der durchgeführten Maßnahmen und Projekte zur Erhaltung bzw. Verbesserung der Informationssicherheit.
iii. Aufstellung und Erläuterung der für die nächste Planungsperiode vorgesehenen Maßnahmen zur Verbesserung der Informationssicherheit.
iv. Bei sehr hohem Schutzbedarf [SBK 4]: Statistiken und Trends unter Berücksichtigung aller Schwachstellen.
11.2 Eine ergänzende Übersicht der bereitzustellenden Berichte zur Informationssicherheit ist in der Anlage 2 Berichtswesen zum Rahmenvertrag dokumentiert.
11.3 Darüber hinaus können weitere individuelle und regelmäßig zu liefernde Berichte zur Informationssicherheit bzw. zur konkreten Umsetzung der Informationssicherheit gesondert durch die Helaba im Rahmen der Regelungen des Rahmenvertrags beauftragt werden.
12 Informationsrisikomanagement
12.1 Der Auftragnehmer betreibt ein Risikomanagementsystem, welches neben anderen relevanten Risiken auch Informationsrisiken berücksichtigt. Das Informationsrisikomanagement (IRM) des Auftragnehmers orientiert sich dabei an ISO 27005 und dient im Sinne ISO 31000 als vorqualifizierender Prozess in Bezug auf Risikoindikatoren des Schlüsselfaktors "Informationssicherheit" für das zentrale Risikomanagement. Die Umsetzung des Informationsrisikomanagements erfolgt unter Berücksichtigung des KWG, der MaRisk, EBA Guidelines, der BAIT sowie der DORA.
12.2 Informationsrisiken sind systematisch zu ermitteln, zu bewerten und zu steuern sowie Maßnahmen zu deren Behandlung abzuleiten. Die Durchführung des Informationsrisikomanagements findet unter maßgeblicher Beteiligung der für die
Seite 16 von 17
[Seite 17]
Anhang 3 – Informationssicherheit
Umsetzung von Maßnahmen verantwortlichen Fachbereiche statt und wird vom Informationssicherheitsmanagement kontrolliert.
13 Subunternehmer
13.1 Wenn der Auftragnehmer Teile der Leistungserbringung für die Helaba an weitere Subunternehmen auslagert und dies eine Weiterverlagerung im Sinne des KWG darstellt, sind die von der Helaba in diesem Anhang beschriebenen Sicherheitsanforderungen in den Vereinbarungen mit den Subdienstleistern angemessen zu berücksichtigen. Die Sicherheitsanforderungen mit den Subdienstleistern sind so zu definieren, dass die Sicherheitsstandards für die Daten der Helaba und Leistungen für die Helaba in jedem Fall eingehalten werden und dass der Auftragnehmer in der Lage ist, eigene Verpflichtungen zur Sicherheit gegenüber der Helaba vollumfassend zu erfüllen.
13.2 Eine transparente Darstellung der durchgehenden Sicherheit der Lieferkette einschließlich Subunternehmer ist gegenüber der Helaba nachzuweisen.
14 Anhänge
Weitere Vertragsbestandteile sind:
• Anhang 3.1 Anforderungskatalog
• Anhang 3.2 Hinweise zum Ausfüllen des Anhangs 3.1
Seite 17 von 17