+Artikel 26 Erweiterte Tests von IKT-Tools, -Systemen und -Prozessen auf Basis von TLPT
---+Artikel 26 (1)
---+Artikel 26 (2)
---+Artikel 26 (3)
---+Artikel 26 (4)
---+Artikel 26 (5)
---+Artikel 26 (6)
---+Artikel 26 (7)
---+Artikel 26 (8)
---+Artikel 26 (9)
---+Artikel 26 (10)
---+Artikel 26 (11)

Artikel 26 Erweiterte Tests von IKT-Tools, -Systemen und -Prozessen auf Basis von TLPT

-

1. Übersicht

,
Artikel 26 (1)
Gemäß Absatz 8 Unterabsatz 3 des vorliegenden Artikels ermittelte Finanzunternehmen, bei denen es sich weder um die in Artikel 16 Absatz 1 Unterabsatz 1 genannten Unternehmen noch um Kleinstunternehmen handelt, führen mindestens alle drei Jahre anhand von TLPT erweiterte Tests durch. Auf der Grundlage des Risikoprofils des Finanzunternehmens und unter Berücksichtigung der betrieblichen Gegebenheiten kann die zuständige Behörde das Finanzunternehmen erforderlichenfalls auffordern, die Häufigkeit dieser Tests zu verringern oder zu erhöhen.
Artikel 26 (2)
Jeder bedrohungsorientierte Penetrationstest schließt mehrere oder alle kritischen oder wichtigen Funktionen eines Finanzunternehmens ein und wird an Live-Produktionssystemen durchgeführt, die derartige Funktionen unterstützen.

Finanzunternehmen ermitteln alle relevanten zugrunde liegenden IKT-Systeme, -Prozesse und -Technologien, die kritische oder wichtige Funktionen und IKT-Dienstleistungen unterstützen, einschließlich derer, die diejenigen kritischen oder wichtigen Funktionen unterstützen, die an IKT-Drittdienstleister ausgelagert oder per Vertrag vergeben wurden.

Finanzunternehmen bewerten, welche kritischen oder wichtigen Funktionen ein TLPT einschließen muss. Der genaue Umfang von TLPT ist vom Ergebnis dieser Bewertung abhängig und wird von den zuständigen Behörden validiert.
Artikel 26 (3)
Sind IKT-Drittdienstleister in das Spektrum der TLPT einbezogen, ergreift das Finanzunternehmen alle erforderlichen Maßnahmen und Vorkehrungen, um die Einbindung dieser IKT-Drittdienstleister in die TLPT sicherzustellen, und trägt jederzeit die volle Verantwortung für die Gewährleistung der Einhaltung dieser Verordnung.
Artikel 26 (4)
Wenn vernünftigerweise davon auszugehen ist, dass sich die Einbindung eines IKT-Drittdienstleisters in einen TLPT gemäß Absatz 3 nachteilig auf die Qualität oder die Sicherheit von Dienstleistungen des IKT-Drittdienstleisters an Kunden, bei denen es sich um nicht in den Anwendungsbereich dieser Verordnung fallende Unternehmen handelt, oder auf die Vertraulichkeit in Bezug auf die mit diesen Dienstleistungen verbundenen Daten auswirkt, können das Finanzunternehmen und der IKT-Drittdienstleister unbeschadet Absatz 2 Unterabsätze 1 und 2 schriftlich vereinbaren, dass der IKT-Drittdienstleister unmittelbar vertragliche Vereinbarungen mit einem externen Tester schließt, um unter der Leitung eines benannten Finanzunternehmens einen gebündelten TLPT durchzuführen, an dem mehrere Finanzunternehmen beteiligt sind (gebündelter Test), für die der IKT-Drittdienstleister IKT-Dienstleistungen erbringt.

Diese gebündelten Tests erstrecken sich auf das relevante Spektrum von IKT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen, die von den Finanzunternehmen per Vertrag an die jeweiligen IKT-Drittdienstleister vergeben wurden. Die gebündelten Tests gelten als TLPT, die von den an den gebündelten Tests beteiligten Finanzunternehmen durchgeführt werden.

Die Zahl der Finanzunternehmen, die sich an den gebündelten Tests beteiligen, wird unter Berücksichtigung der Komplexität und der Art der betreffenden Dienstleistungen angemessen austariert.
Artikel 26 (5)
Finanzunternehmen wenden in Zusammenarbeit mit IKT-Drittdienstleistern und anderen beteiligten Parteien, einschließlich der Tester, jedoch ohne die zuständigen Behörden, wirksame Risikomanagementkontrollen an, um die Gefahr von potenziellen Auswirkungen auf Daten, Schäden an Vermögenswerten und Unterbrechungen kritischer oder wichtiger Funktionen, Dienste oder Vorgänge im Finanzunternehmen selbst, seinen Gegenparteien oder im Finanzsektor zu mindern.
Artikel 26 (6)
Nach Abschluss der Tests und der Ausarbeitung von Berichten und Plänen mit Abhilfemaßnahmen legen das Finanzunternehmen und gegebenenfalls die externen Tester der gemäß Absatz 9 oder 10 benannten Behörde eine Zusammenfassung der maßgeblichen Ergebnisse, die Pläne mit Abhilfemaßnahmen und die Unterlagen vor, mit denen belegt wird, dass der TLPT anforderungsgemäß durchgeführt wurden.
Artikel 26 (7)
Die Behörden stellen Finanzunternehmen eine Bescheinigung aus, aus der hervorgeht, dass der Test — wie in den Unterlagen nachgewiesen — im Einklang mit den Anforderungen durchgeführt wurde, um die gegenseitige Anerkennung bedrohungsorientierter Penetrationstests zwischen den zuständigen Behörden zu ermöglichen. Das Finanzunternehmen übermittelt der jeweils zuständigen Behörde die Bescheinigung, die Zusammenfassung der maßgeblichen Ergebnisse und die Abhilfemaßnahmen.

Unbeschadet einer solchen Bescheinigung bleiben Finanzunternehmen jederzeit in vollem Umfang für die Auswirkungen der in Absatz 4 genannten Tests verantwortlich.
Artikel 26 (8)
Finanzunternehmen beauftragen Tester für die Zwecke der Durchführung von TLPT gemäß Artikel 27. Ziehen Finanzunternehmen für die Zwecke der Durchführung von TLPT interne Tester heran, so beauftragen sie für jeden dritten Test einen externen Tester.

Kreditinstitute, die gemäß Artikel 6 Absatz 4 der Verordnung (EU) Nr. 1024/2013 als bedeutend eingestuft wurden, ziehen nur externe Tester gemäß Artikel 27 Absatz 1 Buchstaben a bis e heran.

Die zuständigen Behörden ermitteln Finanzunternehmen, die TLPT durchzuführen haben, unter Berücksichtigung der in Artikel 4 Absatz 2 aufgeführten Kriterien und stützen sich dabei auf die Bewertung von:

a) 

wirkungsbezogenen Faktoren, darunter insbesondere inwieweit sich die vom Finanzunternehmen erbrachten Dienstleistungen und ausgeführten Tätigkeiten auf den Finanzsektor auswirken;

b) 

etwaigen Bedenken hinsichtlich der Finanzstabilität, einschließlich des systemischen Charakters des Finanzunternehmens auf Unionsebene oder auf nationaler Ebene, je nach Sachlage;

c) 

dem spezifischen IKT-Risikoprofil, dem IKT-Reifegrad des Finanzunternehmens oder einschlägigen technologischen Merkmalen.
Artikel 26 (9)
Die Mitgliedstaaten können eine einzige staatliche Behörde für den Finanzsektor benennen, die auf nationaler Ebene für mit TLPT verbundenen Angelegenheiten im Finanzsektor zuständig ist, und betrauen sie mit allen diesbezüglichen Zuständigkeiten und Aufgaben.
Artikel 26 (10)
In Ermangelung einer Benennung gemäß Absatz 9 und unbeschadet der Befugnis zur Ermittlung der Finanzunternehmen, die verpflichtet sind, TLPT durchzuführen, kann eine zuständige Behörde die Wahrnehmung einiger oder aller in diesem Artikel oder in Artikel 27 genannten Aufgaben auf eine andere für den Finanzsektor zuständige nationale Behörde übertragen.
Artikel 26 (11)

Die ESA arbeiten im Einvernehmen mit der EZB im Einklang mit dem TIBER-EU-Rahmen gemeinsame Entwürfe technischer Regulierungsstandards aus, in denen Folgendes präzisiert wird:

a) 

die für die Zwecke der Anwendung von Absatz 8 Unterabsatz 2 herangezogenen Kriterien;

b) 

die Anforderungen und Standards für den Einsatz interner Tester;

c) 

die Anforderungen hinsichtlich:

i) 

des Umfangs der in Absatz 2 genannten TLPT;

ii) 

der Testmethodik und des Testkonzepts für jede einzelne Phase des Testverfahrens;

iii) 

der Ergebnisse, des Abschlusses und der Behebungsphasen der Tests;

d) 

der Art der aufsichtlichen und sonstigen relevanten Zusammenarbeit, die für die Umsetzung von TLPT und die Erleichterung der gegenseitigen Anerkennung dieser Tests im Kontext von Finanzunternehmen, die in mehr als einem Mitgliedstaat tätig sind, erforderlich ist, um eine angemessene Beteiligung der Aufsichtsbehörden und eine flexible Umsetzung zu ermöglichen, damit den Besonderheiten finanzieller Teilsektoren oder lokaler Finanzmärkte Rechnung getragen wird.

Bei der Ausarbeitung dieser Entwürfe technischer Regulierungsstandards berücksichtigen die ESA gebührend etwaige Besonderheiten, die sich aus der unterschiedlichen Art der Tätigkeiten in verschiedenen Finanzdienstleistungssektoren ergeben.

Die ESA übermitteln der Kommission diese Entwürfe technischer Regulierungsstandards bis zum 17. Juli 2024.

Der Kommission wird die Befugnis übertragen, die vorliegende Verordnung durch Annahme der in Unterabsatz 1 genannten technischen Regulierungsstandards gemäß den Artikeln 10 bis 14 der Verordnungen (EU) Nr. 1093/2010, (EU) Nr. 1094/2010 und (EU) Nr. 1095/2010 zu ergänzen.

1.1 Referenzen

1.2 Identifizierte Anforderungen

1.3 Zugehörige Standards

2. Identifizierte Anforderungen

Anforderungen

3. Zugehörige Standards

Standards
SCF Penetration Testing

Description

Mechanisms exist to conduct penetration testing on Technology Assets, Applications and/or Services (TAAS).

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Annual external vulnerability scan; penetration test when required by customers/contracts

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Annual penetration test by qualified tester

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Annual penetration test by qualified third-party tester

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Enterprise penetration testing program
∙ Annual external and internal pen tests

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Enterprise penetration testing program
∙ Annual and event-driven pen tests
∙ Red team exercises
∙ Purple teaming

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Attack Surface Management (ASM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.

Level 2 Planned Tracked

Vulnerability & Patch Management (VPM) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with VPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Vulnerability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel, or contracted professionals, conduct annual penetration testing on network segments hosting High Value Assets (HVAs).

Level 3 Well Defined

Vulnerability & Patch Management (VPM) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.
▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution and vulnerability scanning solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with VPM domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to conduct penetration testing on Technology Assets, Applications and/or Services (TAAS).

Level 4 Quantitatively Controlled

Vulnerability & Patch Management (VPM) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.