CHARACTERISATION OF CYBER-INCIDENTS

1.1 Definitions

Cybersecurity can be defined as a particular state, which could be qualified as "optimal", or as a collection of activities that ensures the achievement of a particular state. As defined by the Dutch Cybersecurity Supervisor (2017), a system is cyber-secured when it reaches a state that is free of danger or damage caused by a disruption or failure of IT or through the abuse of IT. Overall, the danger or damage caused by abuse, disruption or failure may comprise a limitation on the availability and reliability of the IT, violation of the confidentiality of information stored in IT environments or damage to the integrity of that information.

According to ENISA (2017), cybersecurity comprises all activities necessary to protect cyberspace, its users and impacted persons from cyber-threats. Cyberspace is the time-dependent set of tangible and intangible assets which store and/or transfer electronic information. The present report will use "cybersecurity" indistinctly as a state and as a collection of activities that ensures that state.

1.2 Types of cyberattacks in financial services

Many statistics can be found on the most common types of cyberattacks in financial and insurance services. Although differences can be observed in these statistics across sources, overall there is a broad consensus that denial of services (DoS), web application attacks and payment card skimming represent the vast majority of security incidents. The most common motive for these attacks is, as expected, financial, whereas a small share is driven by espionage and other purposes. For the vast majority of cyberattacks, the compromised data are credentials. Personal and payment data represent a much smaller share.

A large share of these cyberattacks has limited impact and affects only one or a few individuals. But, over the last decade, a few large-scale cyberattacks have been identified in the financial sector, with marked impact in both the short and long term. As shown in Table 1, these extensive attacks have affected a broad range of financial segments: retail payments, health insurance, investment, consumer credit, credit registers, etc. It seems that any segment of the financial sector can be the target of a large-scale cyberattack.

NEED FOR CONVERGENCE IN INCIDENT REPORTING SCHEMES

2.1 Increase in legislation with incident reporting requirements

Several recent new EU regulations and directives include incident reporting requirements in the event of a cyber-breach. The requirements for an institution or data controller to report or notify specific authorities, and in some cases the public, in the event of a cyber-breach are notably covered in the following legislation:

• General Data Protection Regulation (GDPR) in Articles 33 and 34

• Payment Service Directive 2 (PSD2) in Article 96 as well as the corresponding EBA Guidelines

• Directive on Security of Network and Information Systems (NIS) in Articles 6, 14 and 16

• Regulation on Electronic Identification and Trust Services for Electronic Transactions in the Internal Market (eIDAS) in Article 19

• Cyber-incident reporting of the European Central Bank

• TARGET2

As shown in Table 2, high fragmentation can be observed between rules in taxonomy for reporting, reporting time frame, the template to be used and the threshold to trigger an incident. For instance, whereas there is no undue delay in the reporting time frame for the NIS, the deadline is 72 hours for the GDPR, 24 hours for the eIDAS and 48 hours for Target2. The template is not clearly defined in GDPR and NIS, while it is provided for the eIDAS (via document for ENISA reporting but not defined in member states) and for TARGET2 (via document in Annex II).

There is also great diversity in the types of authorities that have to collect incident reports (see Table 3). Some of these authorities are European bodies, such as the ECB for ECB cyber-incidents. Others are national: national NIS authorities for the NIS Directive, NCA for the PSD2 (the information is then reported to the EBA which eventually reports it to the ECB), national data protection authorities for the GDPR, national certification authority for the eIDAS Regulation and national central banks for Target2. Also, some requirements and the related authority in charge concern only financial firms: PSD2 or Target2. Some others are multisectoral: eIDAS, NIS Directive and GDPR. Finally, each piece of legislation defines a different set of criteria to determine the type of financial firm that needs to comply with the reporting requirements.

In addition to incident reporting to the competent authorities, most regulations require the notification of consumers which have been affected by a cybersecurity incident. The GDPR requires the supervisory authority, unless the financial institution has already done so, to inform consumers without undue delay if the data breach has a high risk to impact their rights and freedoms negatively. Similarly, the eIDAS Regulation requests consumer notification with appropriate information in case of major security breaches or integrity losses. The NIS Directive defines either the necessity of public awareness or public interest as the threshold for incident reporting to consumers. PSD2 requires the payment service providers to inform their affected consumers without undue delay about both the cybersecurity incident and the remedial measures if the incident has or may have an impact on the financial interests of consumers.

While these regulations all cover reporting requirements to consumers, significant heterogeneity can be observed in terms of the criteria, standards, thresholds, time frames and general approaches to consumer notification. Different interpretations across legislations might further raise the degree of this fragmentation. Moreover, the reporting requirements are characterised by discretion, meaning that for instance financial institutions are obliged to assess consumers' personal and financial risks arising from a data breach. Therefore, the consumer dimension and scope of cyber-incident reporting as well as the difficulties due to legal fragmentations should not be underestimated.

2.2 Need to develop a common taxonomy for incidents reporting

The development of a common taxonomy for incident reporting is needed for various reasons. First, as cyberspace is global, cyberinsecurity is often a multi-country issue. Often, similar patterns of threat can simultaneously affect organisations located in different countries. As such, cross-border exchange of information is needed to address cybersecurity issues better and manage cyber-incidents efficiently and effectively. Fragmentation in taxonomies across jurisdictions is likely to impede the efficiency of cross-border exchanges of information, as the process of understanding the incident could be slower. As such, convergence in taxonomies should contribute to help respond to multi-country cyberattacks better.

Secondly, as shown in Table 2, there is an increase in incident reporting requirements. A standard taxonomy, adopted across all regulations and directives, regardless of whether it is on a cross-border basis, should facilitate smooth and efficient interactions between authorities and CSIRTs, especially by contributing to avoiding inconsistencies in the reported information.

In principle, the creation of a distinct taxonomy for each piece of legislation should not be justifiable. Finally, as emphasised by ENISA (2018), persistent fragmentation in taxonomies will slow the emergence of automation in incident reporting and responses.

Nevertheless, the development of a common taxonomy for incident reporting faces specific challenges. First, cyberspace is constantly evolving. As a result, cyberattacks are changing on a regular basis and new forms of attacks continuously appear. A nonflexible taxonomy that sets rigid standards for long periods is therefore ill-adapted.

Secondly, existing taxonomies are often designed for specific economic sectors or companies. Organisations often have different needs and expectations. As such, CSIRTs often end up developing their own incident classifications for internal use (ENISA, 2018).

As highlighted by ENISA (2018), one possibility for strengthening convergence in incident taxonomies is to develop a centralised repository for hosting all relevant taxonomies. Questions remain about which body should be in charge of such a task. Given the global nature of many cyberattacks, it would a priori make sense to design a global repository. But the development of a final consensus at the global scale might be unrealistic. Therefore, as a first step, it would be preferable to focus on an EU depository developed by the EU agency in charge of cybersecurity, namely ENISA.

The next objective would be to develop only one taxonomy that encompasses all the processes in the scope. This taxonomy should include specific sections to cover the variants applicable to the different sectors, if relevant. Given the constant changes in the type and nature of cyberattacks, the common taxonomy should also be sufficiently flexible to be continuously updated.

2.3 Need to develop an efficient legislative and institutional framework for incident reporting

The emergence of different reporting requirements raises questions about the most adequate legislative and institutional framework for shaping the relationships between CSIRTs and authorities. Eventually, the objective is to ensure that the framework helps financial firms protect themselves from cyberattacks and, in case of cyberattacks, helps these firms activate timely and efficient responses.

Responses that are timely and efficient should contribute to limiting the short-term and mid-term damages to firms and, in some circumstances, are likely to prevent the expansion of attacks to other firms and sectors. The framework as developed should aim at reinforcing cyber-resilience and business continuity as much as possible. In order to do so, regulators, supervisors and financial firms should focus on the following five issues.

Issue 1. Convergence in templates across the EU

For each piece of legislation whose purpose is to develop incident reporting, convergence in templates should be ensured across the EU. This priority concerns mainly the NIS Directive and the GDPR, as related templates should be primarily defined at national level. As regards the GDPR, one of the roles of the Data Protection Article 29 Working Party and the future European Data Protection Board (the latter will replace the former once the GDPR takes effect, see Recital 139 of GDPR) should be to reinforce the harmonisation in those national templates.

Issue 2. Adequate governance at group level

For financial firms that have activities across different jurisdictions, high fragmentation in templates and typologies could impede the ability of CISRTs to understand the overall picture of the incidents impacting the banking group. Against this background, the banking group could be compliant with the respective incident reporting requirements at national level, while not being able to understand holistically what is at stake. Effective governance at HQ level, with adequate consolidation processes of the "overall cyber-risk" at group level, is therefore also needed. This is a key condition for the authority in charge to have a clear idea of the overall level of risks triggered by specific cyber-incidents.

Issue 3. Assessing the possibilities to develop an infrastructure with bidirectional flows

At present, all incident reporting processes are defined with a single direction flow, from CSIRTs to authorities in charge. None of the legislation emphasises or designs two-way flows. There was a broad consensus within the Task Force that a bidirectional process with respect to incident reporting will eventually be needed. In other words, authorities should be able to exploit the content of incident reporting to inform and advise CSIRTs in return.

One of the options to achieve two-way flows concerns the development of specific network infrastructure channels that provide secure messaging services. This would imply that financial firms use a common application to report incidents. The development of SWIFT messages on the interbank market could be inspirational in this respect. In the end, information about cyber-incidents could be sent and received in a secure, standardised and reliable environment.

This model should contribute to streamlining incident reporting processes. High standardisation of templates should in principle increase processing speed and response. Given that speed is one of the main criteria for coping with large-scale cyberattacks, this benefit could be precious.

However, one of the main issues to address in order to create a common application for cyber-incidents concerns the nature and type of information encoded in the message. The diversity of templates across pieces of legislation (and likely, for two of them, across countries) can be justified by the fact that each piece of legislation has a specific purpose. The development of standard messages should ensure that this diversity can be replicated in that new system. The different authorities need to be able to retrieve the right information within the expected time. There is a significant risk that incident reporting based on standard messaging services might end up being too generic to be adequately exploited by CSIRTs and authorities.

Should the financial sector decide in any event to go in that direction, questions would remain about the funding of such an application: Should it be funded by financial firms? by governments, for the sake of cybersecurity? Or should it be a hybrid model combining both funding channels?

Issue 4. Assessing the possibility of developing a centralised hub

A hub should be developed with the objective of centralising all incident reports and dispatching them to the right authorities. The hub could be in charge of incident reporting for the whole financial sector and handle relationships with all concerned authorities, regardless of whether these authorities are national or European, and cover all sectors or only the financial sector. In return, the hub would be in charge of informing and advising financial firms on cyber-incidents. By centralising all incident reports for the financial sector, the hub would have a broad and clear picture at any given time of the cyber-risks in this sector. Strong analytical capabilities would be needed in this respect. The purpose would not be to have a hub that is only a dispatcher of incident reports.

The hub could also play the role of coordinator between, on the one hand, all authorities in charge and, on the other hand, authorities and CSIRTs. Given the global nature of cyber-insecurity, the hub should be established at European level. The mandate of existing European agencies such as ENISA could be significantly extended to cover these complex tasks or a new agency could be built from scratch to focus primarily on these attributes.

A priori, the former option that builds upon the existing institutional framework would be preferable. The objective is to avoid the multiplication of EU agencies that cover broadly similar topics. But, in order to be able to handle all reporting requirements and distribute key information to the right stakeholder, the chosen agency will need a large amount of resources in terms of staff and budget. In order to fulfil its mission of technical adviser, the centralised hub would also need a clear mandate from regulators.

Issue 5. Assessing the possibility of covering all economic sectors

So far, many of the recorded large-scale cyberattacks not only have affected more than one country; they have also disrupted more than one sector. The institutional framework therefore needs to handle a multi-sectoral dimension. The objective is to ensure that any cyberattacks are confined to one or a few firms in a specific sector and do not spread to others. If there is for example a high risk of a cyber-incident spreading from the energy sector to the financial sector, the supervisor should be able to provide real-time information to financial firms on the nature of the attack and, if possible, on the best way to respond to it.

Two options can be considered to cover the multi-sectoral dimension of cyberattacks. The first is to build a centralised hub that is in charge of all sectors including the financial one. The second concerns the establishment of a multi-sectoral network for cyber-incidents where one hub is developed for each sector of the economy: finance, energy, telecommunications, food, etc. Each hub would be in charge of one given economic sector for everything that relates to the dispatching of incident reports, notification and advice of firms in return, coordination of all stakeholders, etc. In order to handle multi-sectoral attacks, a network of sectoral hubs would be established, preferably at European level, with a hub of hubs.