Megjelentek a DORA RTS-ek első csomagjának tervezetei

2023. június 19-én a European Supervisory Authorities (ESAs) kiadták társadalmi konzultációra a DORA (Regulation (EU) 2022/2554 on digital operational resilience for the financial sector) szabályozástechnikai sztenderdjeinek (RTS és ITS) első csomagját.

A csomag azon alábbi RTS-eket és ITS-t tartalmazza, melyeket az ESAs tervezetten 2024. január 17-én fognak benyújtani az Európai Bizottság részére:

• IKT kockázatkezelési keretrendszer (RTS)
• Egyszerűsített IKT kockázatkezelési keretrendszer (RTS)
• IKT szolgáltatásokra vonatkozó szabályzati elvárások meghatározása (RTS)
• IKT vonatkozású események osztályozásának kritériumai (RTS)
• IKT harmadik fél szolgáltatókról szóló nyilvántartás űrlapja (ITS)

A tervezetek a https://www.esma.europa.eu/press-news/esma-news/esas-consult-first-batch-dora-policy-products  linken letölthetőek és a konzultáció 2023. szeptember 11. napjáig tart.

A továbbiakban RTS-enként szeretnék pár észrevételt tenni – továbbra is a felkészülési feladatokra fókuszálva – tekintetbe véve, hogy a pénzügyi szervezetekre kötelező, 2025. januári, alkalmazási határidő egyre közeledik.

1. IKT kockázatkezelési keretrendszer (RTS)

Talán mondhatom, hogy a leginkább várt RTS-ről van szó, figyelemmel arra, hogy szabályozási tárgyköre kiterjed az alábbiakra:

• IKT-biztonsági szabályzatok, eljárások, protokollok és eszközök
• Emberi erőforrások, hozzáférés-kezelés
• IKT incidensek észlelése és kezelése
• IKT üzletmenet-folytonosság
• Beszámoló az IKT kockázati keretrendszer felülvizsgálatáról

A várakozásainkkal ellentétben az anyag sokkal magasabb szintű, általánosabb követelményeket fogalmaz meg, aminek az okára az RTS 80. oldalán – POLICY ISSUE 2: PRESCRIPTIVENESS OF THE RTS – találjuk az elvi magyarázatot („the RTS shall adopt a principle-based and objective-focused approach. At the same time, considering (a) the nature of the empowerment to cover in detail certain provisions, and (b) the need to be more specific in the requirements, to provide clarity to the industry and facilitate the implementation of the requirements, a combination of principle-based and rule-based approach have been followed, especially for the articles on network security, data and system security, encryption and cryptography, and access control.”)

Az MNB által július utolsó hetében tartott DORA RTS workshopon azt az üzenetet közvetítette a piaci szereplőknek, hogy a magyar pénzügyi szervezeteket nem kell, hogy nagy meglepetés érje a jelenlegi MNB ajánlásokat figyelembe véve. Végig olvasva az RTS-t ezt alapvetően alá tudjuk támasztani, de nyilván a magas szintű elvárásokból következően kérdéses lesz, hogy a megújítás (harmonizáció) alatt álló MNB ajánlásokban, illetve az MNB ellenőrzési gyakorlatában hogyan fognak ezen követelmények konkretizálódni.

Természetesen számos, a jelenlegi 8/2020-as számú MNB ajánláshoz képest új vagy részletesebb, eltérő követelményt lehet találni az RTS-be, melyből párat emelnék ki jelen blogpostban:

Article 10v – Vulnerability and patch management

Procedures shall:

• (b) ensure the performance of automated vulnerability scanning and assessments on ICT assets commensurate to their classification and overall risk profile of the ICT asset. For those supporting critical or important functions it shall be performed at least on a weekly basis.
• (e) establish procedures for responsible disclosure of vulnerabilities to clients and counterparts as well as to the public, as appropriate;

Article 11 – Data and system security:

• (k) for cloud computing resources: i. the requirement that the individual in charge of using the cloud client interface to manage the cloud computing resource shall have adequate competences and training in the management and security of cloud computing resources that are specific to the cloud service used;

Article 13 – Network security management:

• (h) identification of the roles and responsibilities for the definition, implementation, approval, change and review of firewall rules and connections filters. Financial entities shall perform the review on a regular basis according to the classification and overall risk profile of ICT systems involved. For the ICT systems supporting critical or important functions, the financial entities shall perform this review at least every six months;
• (i) performance of reviews of the network architecture and of the network security design once a year to identify potential vulnerabilities;

Article 16 – ICT systems acquisition, development, and maintenance:

• 4. Financial entities shall perform source code review covering both static and dynamic testing. The testing shall include security testing for internet-exposed systems and applications. Financial entities shall identify and analyse anomalies in the source code, adopt an action plan to address them and monitor their implementation.
• 5. Financial entities shall perform security testing of software packages not later than the integration phase.
• 9. The source code and proprietary software provided by ICT third-party service providers or coming from open-source projects shall be analysed and tested for vulnerabilities and for absence of malicious codes in accordance with paragraph 4 prior to the deployment in the production environment.

Article 22 Article 22 – Access control: 1. As part of their control of access management rights, financial entities shall develop, document and implement a policy that includes all of the following elements:

• iv. review of access rights, at least once a year for all ICT systems, other than critical ICT systems and at least every six months for ICT systems supporting critical or important functions.
• ii. the use of strong authentication methods in accordance with leading practices and techniques for remote access to the financial entity’s network, for privileged access, for access to ICT assets supporting critical or important functions or that are publicly accessible.

Article 24 – Anomalous activities detection and criteria for ICT-related incidents detection and response:

• To detect anomalous activities that can result in ICT network performance issues and ICT-related incidents in accordance with Article 10(1) of Regulation (EU) 2022/2554, financial entities shall implement detection mechanisms allowing them to: (a) collect and analyse all the following information on:
• ii. potential internal and external threats, including usual scenarios of detection used by threat actors and scenarios based on threat intelligence activity

Article 26 – Testing of the ICT business continuity plans:

• The testing of the ICT business continuity plan shall: (c) include the successful switchover of critical business functions, supporting processes and information assets to the disaster recovery environment and demonstrating that they can be run in this way for a sufficiently representative period of time and that normal functioning can be restored afterwards;

Article 28: 

• 1. Financial entities shall develop and document the report referred to in Article 6(5) of Regulation (EU) 2022/2554 in a searchable electronic format. (A riport kötelező tartalmi elemeit 2,5 oldalon részletezi a dokumentum.)

2. IKT vonatkozású események osztályozásának kritériumai (RTS)

Az előzőekben tárgyalt RTS-el ellentétben a szabályozás egy teljesen konkrét, minden DORA által szabályozott entitás számára azonos osztályozási szempontrendszert határoz meg. A rendszer alapelve, hogy un. elsődleges és másodlagos kritériumokat különböztet meg és a jelentős esemény az alábbi kritériumok kombinációja esetén áll elő:

• legalább 2 elsődleges kritérium elérése, vagy
• három vagy több kritérium teljesülése, melyből legalább 1 elsődleges kritériumnak számít.

A folyamatot az alábbi ábra szemlélteti a legjobban:

Az elsődleges és másodlagos kritériumok az alábbiak:

„The following criteria shall be primary criteria:

1. a) ‘Clients, financial counterparts and transactions’ as set out in Article 1;
2. b) ‘Data losses’ as set out in Article 5; and
3. c) ‘Critical services affected’ as set out in Article 6.

The following criteria shall be secondary criteria:

1. a) ‘Reputational impact’ as set out in Article 2;
2. b) ‘Duration and service downtime’ as set out in Article 3;
3. c) ‘Geographical spread’ as set out in Article 4; and
4. d) ‘Economic impact’ as set out in Article 7.”

Ki kell emelni, hogy az események időbeli ismétlődése befolyásolja az értékelést és azok az események is jelentősnek minősülnek, melyek önállóan bár nem érik el a küszöbértékeket, de legalább 2 darab, azonos gyökérokra visszavezethető, hasonló természetű és hatású esemény történt 3 hónapon belül ami együtt már eléri a jelentős esemény küszöbértékeit.

Úgy gondolom, hogy a DORA felkészülés jegyében az RTS-ben foglalt osztályozási rend kialakítását érdemes mielőbb megkezdeni, kardinális változtatások már nem várhatóak az RTS-ben, és a szervezetek incidenskezelési eljárásainak jelentős átalakítását teszi szükségessé. Az nyer, aki mielőbb elkezdi próbálgatni, alkalmazni az új osztályozási rendszert.

3. IKT harmadik fél szolgáltatókról szóló nyilvántartás űrlapja (ITS)

Az RTS egy relációs adatbázis tervét írja le az adatbázis táblák és kapcsolatok pontos meghatározásával. A nyilvántartás elkészítése minden pénzügyi szervezet által elkészítendő (függetlenül a mérettől), célja, hogy a teljes szolgáltatási láncolatot lefedje és évente vagy kérésre át kell adni a Felügyelet részére.

Az egyelőre nem ismert, hogy az adatátadás milyen formában fog megvalósulni: pl. lesz esetleg egy az MNB által készített template – L. törvény szerinti OVI táblákhoz hasonlóan, ami a felügyelet általi feldolgozhatóságot lehetővé teszi – vagy központi alkalmazás – pl NAIH nyilvántartásokhoz hasonlóan – vagy minden szereplő maga fejlessze ki az erre szolgáló nyilvántartó rendszerét.

A fenti bizonytalanságokra tekintettel érdemes kivárni, hogy pontosan mit és hogyan fog kialakítani/elvárni a Felügyelet.

4. IKT szolgáltatásokra vonatkozó szabályzati elvárások meghatározása (RTS)

A DORA 28. cikk (10) szerint az EFH-knak a vegyes bizottság keretében szabályozástechnikai standardtervezeteket kell kidolgozniuk, amelyek részletesen meghatározzák a (2) bekezdésben említett szabályzat tartalmi elemeit a harmadik fél IKT-szolgáltatók által nyújtott, kritikus vagy fontos funkciókat támogató IKT-szolgáltatások igénybevételéről szóló szerződéses megállapodások tekintetében.

A fentieknek megfelelően az RTS az IKT szolgáltatók alkalmazására vonatkozó szabályzat követelményeit fekteti le. Fontosnak tartom rögtön kiemelni, hogy nem kizárólag a kiszervezett szolgáltatások nyújtóiról van szó, hanem minden IKT szolgáltatóról és a szabályozás nem tesz különbséget a cégcsoporton belüli IT szolgáltatókkal:

„When applying the policy on the use of ICT services supporting critical or important functions, ICT intra-group service providers, where applicable, including those fully or collectively owned by financial entities within the same institutional protection scheme, undertaking the provision of ICT services, should be considered as ICT third party services providers. The risks posed by those ICT services providers may be different but the requirements applicable to them are the same in accordance with Regulation (EU) 2022/2054. In a similar way, this policy should apply to subcontractors to ICT third-party service providers where this is relevant in case a chain of ICT third-party service providers exists.”

Az alábbiakban a IKT kockázatkezelési keretrendszer (RTS)-hez hasonlóan pár követelményt emelnék ki a szabályozás tervezetből:

Article 3 – Governance arrangements regarding the policy on the use of ICT services supporting critical or important functions:

• 3. The policy referred to in paragraph 1 shall define or refer to a methodology for determining which ICT services support critical or important functions. The policy shall also specify when this assessment should be conducted and reviewed.
• 6. The policy referred to in paragraph 1 shall clearly identify, in accordance with Article 5(3) of Regulation (EU) 2022/2554, the role or member of senior management responsible for monitoring the relevant contractual arrangements. This policy shall define how this role or member of senior management shall cooperate with the control functions where it is not part of it and define the reporting lines to the management body, including the nature and frequency of the documents to report.

Article 6  – Ex-ante risk assessment:

• 2. The policy referred to in paragraph 1 shall require that, before entering into a contractual arrangement with an ICT third-party service provider a risk assessment shall be conducted at financial entity level and, where applicable, at consolidated and sub-consolidated level, taking into account all the relevant requirements under of Regulation (EU) 2022/2554 and applicable sectoral legislations and regulations. This risk assessment shall consider, in particular, the impact of the provision of ICT services supporting critical or important functions by ICT third-party service providers on the financial entity and all its risks, including operational risks, legal risks, ICT risks, reputational risks, risks to the protection of confidential or personal data, risks linked to the availability of data, risks linked to where the location of the data is processed and stored and the location of the ICT third-party service provider as well as ICT concentration risks at entity level in accordance with Article 29 of Regulation (EU) 2022/2554.

Article 11 – Exit and termination of contractual arrangements for the use of ICT services supporting critical or important functions:

• Without prejudice to Article 28 (7) and (8) of Regulation (EU) 2022/2554, the policy on the use of ICT services supporting critical or important functions provided by ICT third-party service providers shall include requirements for a documented exit plan for each ICT service supporting critical or important functions provided by an ICT third-party service provider and their periodic review and testing, taking into account possible service interruptions, inappropriate or failed service delivery or the unexpected termination of a relevant contractual arrangement. The exit plan shall be realistic, feasible, based on plausible scenarios and reasonable assumptions and shall have a planned implementation schedule compatible with the exit and termination terms established in the relevant contractual arrangements.