The current guideline draft tries to cover operational and security incidents under the same set of definitions, criteria and according requirements. There are considerable differences between both events. As a consequence, the current definition as well as the further criteria for “major operational or security incident” might not be sufficiently clear, i.e. demarcated.
For security incidents THE important fact to consider is, whether confidential information was compromised leading to a loss of confidentiality, integrity and/or availability . The current definition takes this into account by including a potential impact on confidentiality, which is further described as “The property that information is not made available or disclosed to unauthorised individuals, entities, or processes”. The further criteria, however, only indirectly consider this important fact as part of the level 1 criterium “Reputational Impact”.
We kindly encourage the EBA to consider separate definitions for operational incidents on the one hand and security incidents on the other hand. In this way, any requirements connected to these incidents become more tangible in practice, even if the further criteria remain the same. The EBA should also reconsider though, if “Reputational Impact” remains the only criterion to cover information compromising and if so, if this should remain a level 1 criterion (see also Question 2). From our point of view, it might be an alternative to use the “Reputational Impact” criterion with penetrating power, i.e. as a level 2 criterion. In this way, market participants could establish appropriate and specific internal processes (e.g. confidential business partner or client information in scope of a security incident needs to have a higher attention than internal company information.) to determine any reputational impact that should definitely be reported to the competent authority. For example, if (less than 5000 but significant) VIP clients are affected by an incident, which could be picked up by the press and spread by the public.
Moreover, the “Continuity of payment-related services” is part of the incident definition. It might be unclear for PSPs under the PSD2, whether or how they might avoid redundant reportings. If a major operational incident under the guidelines on hand as well as a reporting obligation under Article 28 No. 2 (b) and (c) of the Regulatory Technical Standards on Strong Customer Authentication and common and secure communication under Article 98 of PSD2 (EBA/RTS/2017/02) occurs. The same incident that occurs at a major ASPSP’s dedicated interface (with high market relevancy due to large amount of clients) could be reported by
- the affected major ASPSP under the guidelines on hand
- the affected major ASPSP under Article 28 No. 2 (b) of the Regulatory Technical Standards (EBA/RTS/2017/02)
- all affected TPPs under the guidelines on hand as well as
- all affected TPPs under Article 28 No. 2 (c) of the Regulatory Technical Standards (EBA/RTS/2017/02).
Last but not least, during the EBA hearing on February 9th, 2017, it was mentioned by the authority’s responsibles, that ISO standards were taken into account to derive appropriate definitions and criteria for major operational and security incidents. Explicit ISO standards are not cited as part of the guidelines’ rationales. As the EBA does not require from market participants to comply with specific industry standards as part of this guidelines, but only uses them as a theoretical basis, we would suggest to cite any standards taken into account. In this way market participants, considering ISO compliance would be able to link their different requirement sources in a more comprehensible manner.
With regard to security incidents, we refer to our input under question 1 as outlined above.
In general for operational and security incidents, we would like to point out that all current criteria for a major incident might be applicable, but an impact can still be low as the company already has proper impact prevention actions in place, so this incident could be nevertheless insignificant from the outset and should not raise any high awareness of competent authorities. The major incidents that do not have a high prevention/recovery rate need to be handled with higher priority. Therefore, we suggest to consider a “recovery” criterium from the beginning of any incident occurring.
If the EBA decides to “start” the process of the reporting of operational or security incidents under the PSD2 on the basis of the criteria provided with the guidelines on hand, it should at least regulate a specific follow up option: if possible for the EBA as part of its mandate, the guidelines on hand should include the opportunity to adapt the guidelines’ methodology and criteria determined after a dedicated (and recurrent) lesson learned phase in which the criteria and thresholds shall be fine-tuned and evaluated by all competent authorities, incl. the EBA.
For further good practices and details in the regard of security incident handling we suggest to also take approaches of other jurisdictions into consideration, e.g. the Special Publication by the US National Institute of Standards and Technology on Computer Security Incident Handling (NIST SP 800-61: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf).
As a newly to be regulated entity (AISP/PISP) under PSD2, figo GmbH (hereafter: figo) cannot provide any experience in that regard.
We refer to our explanations with regard to the appropriateness of the current criteria as part of Question 2, which might also affect the further thresholds as defined by the guideline on hand. figo also likes to put emphasis again on the need for a suggested lesson learned phase and adapting opportunity in this context.
Apart from that, the defined downtime threshold of 2 hours in Guideline 1.3 should be appropriately aligned with the deadline defined in Guideline 2.8 for the initial incident report. The latter defines that “Payment service providers should send the initial notification to the competent authority within the first 2 hours from the moment the incident was first detected”. As a consequence, the initial report is supposed to be send out before one of the level 1 criteria can actually be determined as met or surpassed (see also Question 7). We suggest that the deadline in Guideline 2.8 should be extended accordingly to avoid a mismatch between the establishment of the materiality of an incident and a due and proper reporting.
In part 4 of the current template in Annex 1 certain types of attacks are to be selected by the reporting entity. From our point of view these type of attacks are not clear, i.e. helpful for the purposes of the regulated reporting. We suggest to refer to attack vectors as an attack can be a utilisation of many attack vectors. A best practice basis in that regard would be the so-called “OWASP Top Ten” (https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf):
Typical attack vectors according to these standards are:
- Broken Authentication and Session Management
- Cross-Site Scripting (XSS)
- Insecure Direct Object References
- Security Misconfiguration
- Sensitive Data Exposure
- Missing Function Level Access Control
- Cross-Site Request Forgery (CSRF)
- Using Components with Known Vulnerabilities
- Unvalidated Redirects and Forwards
If the “type of attacks” are changed according to our suggestion under Question 5, the instructions provided should be changed accordingly.
The defined downtime threshold of 2 hours in Guideline 1.3 should be appropriately aligned with the deadline defined in Guideline 2.8 for the initial incident report. The latter defines that “Payment service providers should send the initial notification to the competent authority within the first 2 hours from the moment the incident was first detected”. As a consequence, the initial report is supposed to be send out before one of the level 1 criteria can actually be determined as met or surpassed (see also Question 7). We suggest that the deadline in Guideline 2.8 should be extended accordingly to avoid a mismatch between the establishment of the materiality of an incident and a due and proper reporting.
Alternatively and a prefered approach would be to limit the initial report within the first 2 hours to a more simple information, such as a simplified template or a short note in the sense of “we detected an operational/security incident that might be a major one and are currently establishing its materiality”; so that a second report incl. a filled-in template would have to be provided later, within an appropriately extended time frame. The moment an incident occurs, PSPs should focus with priority on its mitigation and recovery measures instead of due and proper template reporting. Even if responsibilities for these tasks are shared within a company: The mitigation responsibles will have to be involved to draft an appropriate reporting. It is not feasible to handle both tasks within the first 2 hours after an incident has occurred.
Moreover, appropriate resources at the CAs could be gathered within the time frame of the initial “short notice/simplified template” report and the initial complete template report, e.g. gathering operational incident experts or security incident experts. Of course, an “unnecessary alarm” notification by the PSP would be necessary, in case the thresholds of a major incidents are not met/surpassed after the short notice report.
figo agrees with EBA’s reasoning and draft Guideline in that regard. It will help over time to grasp the incident and attack landscape. Especially with regard to the newly regulated payment services covered by PSD2. If, for example, at figo as a platform service provider in various constellations of services such as AIS, PIS as well as “dedicated interface”-services (self-licensed contract models as well as outsourcing models) an incident occurs, an impact on various other market participants is imminent. So the delegation of reporting procedures means efficiency when practised.
figo agrees with EBA’s reasoning and draft Guideline in that regard. It will help over time to grasp the incident and attack landscape. BUT - as the EBA did not provide any questions for market participants to comment on the Guidelines 5-6, we would like to use the opportunity to highlight our concerns in that regard at the end of this online consultation form:
(A) Avoid double-requests by different EU member states’ CAs
Our understanding with regard to the regulated process is the following:
1. A licensed/registered PSP is - according to Guidelines 2.1 supposed to report incidents to “the competent authority in the home Member State”, independently from which countries might be affected, when the PSP is operating under EU passporting on the basis of the PSD2 rules (affected countries are to be mentioned within the submitted template).
2. The home Member State’s CA will forward this report to the EBA according to Guideline 7.1.
3. Article 96 Sec. 2 of the PSD2 provides that the EBA and the ECB shall, in cooperation with the competent authority of the home Member State, assess the relevance of the incident to other relevant Union and national authorities and shall notify them accordingly.
4. According to Guideline 2.5 the PSP is supposed to follow up on any requests from the competent authority in the home Member State to provide additional information or clarifications regarding already submitted documentation. Conversely, this means that other national authorities that might have been notified meanwhile are NOT supposed to address PSPs directly, but have to address any requests and/or instructions to the PSP INDIRECTLY via the home Member State CA.
5. This process must be seen independently from any relevant local data protection reporting obligations the PSP might have to take into account when providing services in other EU member states.
We kindly ask EBA to object - especially with regard to step 4 - if this does not reflect EBA’s view on the regulated approach. If the EBA agrees - especially with step 4 -, we encourage to include an explicit guideline in that regard to support PSPs in any necessary prevention of “overlapping” requests and/or instructions by not-home Member State CAs in times of handling incidents.
(B) Avoid redundant reportings to other domestic authorities:
figo is aware that the EBA considered the problem but lacks a mandate to directly regulate alignments of any ADDITIONAL local reporting requirements by PSPs, such as under any national data protection or information security laws. We appreciate the attempts in that regard (rationale no. 11 for exemptions under the NIS Directive as well as Guideline 5: details of the incident reports to be shared with other domestic authorities). In addition, we kindly encourage the EBA to discuss if any general incentive for CAs could be covered under the Guidelines on hand, to actively foster alignments with other local reporting requirements. For example, the Guidelines could at least grant CAs the opportunity to provide the EBA with their experiences of local alignments after the lesson learned phase in which the Guidelines thresholds shall be fine-tuned and evaluated and as we proposed as part of Question 2.