text: www.enisa.europa.eu European Union Agency For Network And Information Security

text: Annual Incident Analysis Report for the Trust Service Providers

text: October 2017

text: October 2017

text: See https://www.enisa.europa.eu/publications/annual-incident-reports-2016

text: October 2017

text: October 2017

text: October 2017

text: According to

text: article 17 (6)

text: supervisory bodies have to notify Commission too. ‘By 31 March each year, each supervisory body shall submit to the Commission a report on its previous calendar year’s main activities together with a summary of breach notifications received from trust service providers in accordance with

text: Article 19(2)

text: October 2017

text: See https://www.enisa.europa.eu/publications/article19-incident-reporting-framework It has to be noted that the TSP shall only be responsible for reporting breaches on systems or processes that are under the TSP’s control. In case core functions are subcontracted, the TSP remains liable for notifying security incidents that occur in the sub-contractor's systems. A threshold is considered as a triad of an indicator accompanied by specific values and measurement unit description.

text: October 2017

text: See https://www.enisa.europa.eu/publications/article19-incident-reporting-framework, paragraph 3.2 By the provider or by the NRA or by an external party.

text: October 2017

text: Figure 1: Overview of reporting flows in

text: Article 19

text: Notification Trust service Informing provider Summary reporting 2

text: Customer 1 1 affected National Other relevant supervisory authorities body 3 5 4

text: National supervisory bodies abroad, EC Public and ENISA

text: A relying party is considered as part of the public. Flow no 1, might be either national or cross border because article 17 (1) of the Regulation foresees that Member States shall designate a supervisory body established in their territory or, upon mutual agreement with another Member State, a supervisory body established in that other Member State.

text: October 2017

text: See https://www.enisa.europa.eu/publications/article19-incident-reporting-framework, Annex D

text: October 2017

text: The Regulation states that “In particular, it should not cover the provision of services used exclusively within closed systems between a defined set of participants, which have no effect on third parties. For example, systems set up in businesses or public administrations to manage internal procedures making use of trust services should not be subject to the requirements of this Regulation. Only trust services provided to the public having effects on third parties should meet the requirements laid down in the Regulation.”

text: October 2017

identifier: Annual Incident Analysis Report for the Trust Service Providers

publisher: Europeiska unionens cybersäkerhetsbyrå

sprak: en

title: Annual Incident Analysis Report for the Trust Service Providers

serie: rapporter

text: Analysis of Article 19a annual incident reports under eIDAS - 2016 OCTOBER 2017

type: rubrik

text: About ENISA

text: The European Union Agency for Network and Information Security (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu.

type: stycke

text: Contact

text: For contacting the authors please use resilience@enisa.europa.eu. For media enquires about this paper, please use press@enisa.europa.eu.

text: Acknowledgements

text: For the completion of this report ENISA has worked closely with a group of experts from Supervisory Bodies and ministries from across Europe. Listing the organizations (in no particular order): ILNAS (LU), CERT LV(LV), Bundesnetzagentur (DE), MCA (MT), NKOM (NO), ANSSI (FR), RTR (AT), Ministry of Digital Affairs (PL), GNS (PT), Agency for Digitisation (DK), Radiocommunications Agency (NL), FPS Economy (BE), EETT (GR), Communications Regulatory Authority (LT), FICORA (FI), CRC (BG), Agenzia per l'Italia Digitale (IT), National Media and Infocommucations Authority (HU), ICO (UK), Ministry of Communications and Informational Society (RO), National Security Authority (SK), Ministry of Industry and Tourism (ES), Swedish Post and Telecom Authority (SE), Ministry of Economy, Entrepreneurship and Crafts (HR), Ministry of the Interior (CZ), RIA (EE), DCCAE (IE), Ministry of Transport, Communications and Works (CY), Ministry of Public Administration, Information Society Directorate (SI)

text: Legal notice

text: Notice must be taken that this publication represents the views and interpretations of the authors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the

text: Regulation (EU) No 526/2013

text: . This publication does not necessarily represent state-of the-art and ENISA may update it from time to time.

text: Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication.

text: This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication.

text: Copyright Notice

text: © European Union Agency for Network and Information Security (ENISA), 2017 provided the source is acknowledged.

text: ISBN: 978-92-9204-234-9, DOI: 10.2824/988312

text: Executive Summary

text: This report provides an analysis and evaluation of the incident reporting procedure in the EU under the Article 19 of the eIDAS Regulation (

text: ). Considering the fact that only the second half of 2016 was applicable and moreover that this was the first time for Supervisory Bodies to perform this exercise, a low volume of reported incidents was expected. In reality, only one incident was notified to ENISA. Thus, more emphasis has been given to the analysis of the incident reporting procedure per se, in an effort to highlight its peculiarities. It came as no surprise that the root cause was a system failure. ENISA’s corresponding analysis about significant outage incidents in the European electronic communications sector has identified that system failures are the dominant root cause of incidents for the sixth year in a row . A detailed view on the progress of the reporting procedure explains the minor number of incidents. Legislative delays, incidents slightly below the EU thresholds and incidents reportable in national level but not significant in the EU scale, are the main factors that describe this situation. In conclusion, this first year’s incident reporting is considered as successful, in view of the fact that despite the various difficulties, all the 28 Member States submitted their report in time. ENISA has provided the appropriate framework and worked constructively together with the Supervisory Bodies and the European Commission to facilitate this process.

text: Table of Contents

text: Executive Summary 3

text: 1. Introduction 5

text: 2. Article 19 of the eIDAS Regulation 6

text: Full text of

text: Article 19

text: Article 19

text: Experts Group and Incident Reporting Procedure 7

text: Incident reporting procedure 7

text: 3.1.1 Security incidents 7 3.1.2 Services in scope 7 3.1.3 Incident reporting flows 8

text: Indicators for annual summary reporting 9

text: 4. Analysis of Incident Reporting procedure 11

text: 1. Introduction

text: For the first year, ENISA publishes the annual report on significant incidents of breach of security and loss of integrity, which are reported to ENISA under Article 19 of the eIDAS Regulation (

text: ), by the Supervisory Bodies (SBs) of the different EU Member States. This report covers the incidents that occurred in the second half of 2016, when the Regulation entered into force and it gives a comprehensive overview of the annual summary reporting by the Member States together with the presentation of one incident. This report does not include details about individual countries or providers. This document is structured as follows: Section 2 briefly summarize

text: Article 19

text: and the role of ENISA. This is the section that provides the fundamental knowledge for the reader and the basis for our work. Subsequently, section 3 presents the details of the technical implementation of

text: Article 19

text: , as agreed in the

text: Article 19

text: Experts Group by the different SBs of the EU Member States. In this chapter the reader can go through the definition of the reportable security incidents, be informed about the relevant services in scope and understand the incident reporting flows as they emerge from the regulation. Finally, Section 4 presents the analysis of this year’s incident reporting procedure and summarizes the different steps that have taken place. A brief explanation of the process’ evolvement is provided, together with some useful information on the incident and the reasons behind the low volume of registered notifications.

text: 2. Article 19 of the eIDAS Regulation

text: This chapter outlines the incident reporting obligations in Article 19 of the eIDAS regulation, called “Security requirements applicable to trust service providers”. For the sake of completeness, and for the convenience of the reader, the full text of

text: Article 19

text: is quoted below. Incident reporting is addressed in paragraphs 2 and 3, and briefly touched on in the last sentence of paragraph 1.

text: Full text of

text: Article 19

text: 1. Qualified and non-qualified trust service providers shall take appropriate technical and organisational measures to manage the risks posed to the security of the trust services they provide. Having regard to the latest technological developments, those measures shall ensure that the level of security is commensurate to the degree of risk. In particular, measures shall be taken to prevent and minimise the impact of security incidents and inform stakeholders of the adverse effects of any such incidents. 2. Qualified and non-qualified trust service providers shall, without undue delay but in any event within 24 hours after having become aware of it, notify the supervisory body and, where applicable, other relevant bodies, such as the competent national body for information security or the data protection authority, of any breach of security or loss of integrity that has a significant impact on the trust service provided or on the personal data maintained therein. Where the breach of security or loss of integrity is likely to adversely affect a natural or legal person to whom the trusted service has been provided, the trust service provider shall also notify the natural or legal person of the breach of security or loss of integrity without undue delay. Where appropriate, in particular if a breach of security or loss of integrity concerns two or more Member States, the notified supervisory body shall inform the supervisory bodies in other Member States concerned and ENISA. The notified supervisory body shall inform the public or require the trust service provider to do so, where it determines that disclosure of the breach of security or loss of integrity is in the public interest. 3. The supervisory body shall provide ENISA once a year with a summary of notifications of breach of security and

text: loss of integrity received from trust service providers.”

text: ENISA’s role and objectives

text: ENISA’s role is mentioned in preamble 39 of the eIDAS regulation; “To enable the Commission and the Member States to assess the effectiveness of the breach notification mechanism introduced by this Regulation, supervisory bodies should be requested to provide summary information to the Commission and to European Union Agency for Network

text: and Information Security (ENISA).”

text: Furthermore,

text: article 19 (2)

text: , requires the ‘notified supervisory body, where appropriate, in particular if a breach of security or loss of integrity concerns two or more Member States, to inform the supervisory bodies in other Member States concerned and ENISA’. Finally,

text: article 19 (3)

text: , requires the supervisory body to provide ENISA once a year with a summary of notifications of breach of security and loss of integrity received from trust service providers.

text: Article 19

text: Experts Group and Incident Reporting Procedure

text: In 2014, after eIDAS was adopted, ENISA formed an experts group, to work together with experts from competent authorities on the application of

text: Article 19

text: and, more generally, security incidents in trust services. This group, called the

text: Article 19

text: Experts Group, reached an agreement on the following non-binding technical document providing guidance to the SBs in the EU Member States:  Incident reporting framework for eIDAS

text: Article 19

text: The

text: Article 19

text: Experts Group organises meetings, workshops and conference calls on a regular basis to develop technical guidelines, to discuss the implementation of

text: Article 19

text: and to share knowledge and exchange views about past incidents and how to address them.

text: Incident reporting procedure

text: In this section the basic

text: article 19

text: terms and concepts are presented together with some abbreviations that are used later on in this document.

text: 3.1.1 Security incidents

text: Paragraph 1 of

text: Article 19

text: asks providers to assess risks for the security of the trust services they provide, and take commensurate security measures to mitigate the impact.

text: Security incident: Any breach of security or loss of integrity that has an impact on the security of the trust service provided. i.e. an all-hazard approach is foreseen– any incident that would have an impact on the

text: security of the trust service.

text: Reportable security incidents: Any breach of security or loss of integrity that has a significant impact on the trust service provided or on the personal data maintained therein.

text: Thresholds for trust service providers to notify the national supervisory bodies (i.e. what is significant) depend on national circumstances: different countries will adopt a different approach to setting national reporting thresholds, depending on national specificities, including: the type of providers in the sector, the population of the country, national legislation, etc. The objective of this document is to agree upon indicators and thresholds which can be used as a basis for the annual summary reports submitted by the supervisory bodies to ENISA and the European Commission; they can also be used as guidance to supervisory bodies when setting national thresholds.

text: 3.1.2 Services in scope

text: Services in scope are those defined in article 3 of the eIDAS regulation, namely:

text: ‘trust service’ means an electronic service normally provided for remuneration which consists of:

text:  the creation, verification, and validation of electronic signatures, electronic seals or electronic time stamps, electronic registered delivery services and certificates related to those services, or  the creation, verification and validation of certificates for website authentication; or  the preservation of electronic signatures, seals or certificates related to those services

text: ENISA’s

text: Article 19

text: EG has agreed on a more detailed list of services, which can be helpful for the analysis. The full list is available at our Incident Reporting Framework .

text: 3.1.3 Incident reporting flows

text: Article 19

text: addresses different types of reporting:

text: 1. Notification about a security incident, that has a significant impact on the trust service provided or on the personal data maintained therein, within 24 hours after the trust service provider becomes aware of it , to the supervisory body and, where applicable, other relevant bodies (e.g. DPA, national competent authority for information security, etc.). 2. Notification of the natural or legal person to whom the trust service was provided, who was affected by the security incident, without undue delay. In this document and in the diagram below, this abbreviates to ‘the customer affected’ 3. Informing the public (or requiring the provider to do so) 4. Informing relevant supervisory bodies abroad and ENISA, when a security incident involves two or more Member States.

text: 5. Annual summary reporting to ENISA. The diagram below shows the different incident reporting flows, numbered as above.

text: Actors are explained in more detail, by referring to the legal text of

text: Article 19

text:  Trust service provider: the “Qualified and non-qualified trust service providers” where the security breach is detected.  Customer affected: the “natural or legal person to whom the trust service has been provided” who is affected by the security breach.  Supervisory body: the body established in Member State territory or, upon mutual agreement with another Member State, a body established in that other Member State which is responsible for supervisory tasks in the designating Member State.  Other relevant authorities: any other relevant bodies, depending on the national setting, such as the competent national body for information security or the data protection authority.

text: The diagram shows a number of reporting flows such as annual summary reporting (flow 5), cross-border notification (flows 1 , 4) and national incident notification (flows 1, 2, 3).

text: Indicators for annual summary reporting

text: ENISA worked together with the Article19 Experts Group on a framework to ease the overall reporting scheme. Paragraph 2 of

text: Article 19

text: says that security incidents with a “significant impact” should be reported. Thus,

text: Article 19

text: will be most effective if a framework is put in place that allows for consistency and clarity in weighing an incident's significance.

text: Member states can take different approaches to defining their national reporting thresholds, thus it is important to set notification indicators and thresholds which are the same for all Member States. ENISA had already gone through this exercise with the

text: Article 13

text: a EG and highlighted from the very beginning the value of defining parameters that could be easily adopted by both SBs and TSPs. However, trust services require a different approach compared to the telco framework, hence two proposals were drafted. The first proposal was composed by two groups of incident examples/scenarios: the service specific one which contains incident examples with an impact on each specific trust service and the generic one which contains grouped incident examples with an impact on all or most of the eIDAS service. This approach is based on the classification of incidents in different impact levels. The severity of security incidents is rated on a scale from 1 to 5:

text: 1. No impact 2. Insignificant impact: provider assets were affected but no impact on core services 3. Significant impact: part of the customers/services is affected 4. Severe impact: large part of the customers/services is affected 5. Disastrous: the entire organisation, all services, all certificates are affected

text: Only incidents of severity level 3 and beyond are reportable. The full list is available in the Incident reporting framework for eIDAS

text: Article 19

text: publication . This list should be used as a general guideline as regards level classification. Given the circumstances of each incident, when core services are affected, it is at the discretion of each Supervisory Body to assign a different level value.

text: The second proposal, was based on an impact assessment of assets, relevant to the eIDAS services. A table that shows the impact of having compromised one of the three basic security principles (Confidentiality, Integrity, Availability) for each service and the associated assets has been created. In order to produce a clear and concise presentation of the impact, a uniform scale of low, medium and high has been used.

text: Ultimately, the Supervisory Bodies, decided to adopt the first proposal in order to determine the significance of an incident. Nevertheless, when CIRAS-T, the online tool to facilitate the incident reporting procedure was under development, both proposals were incorporated. There was a common agreement, that implementing both schemes is not considered to be duplicate information on the same issue, but an approach that can offer substantial information for the analysis.

text: 4. Analysis of Incident Reporting procedure

text: As expected, as this was the first year of the incident reporting, some delays occurred in the process. First and foremost, during our

text: Article 19

text: EG meetings, we identified slow adoption of the Regulation and consequently of the national secondary legislation. Apart from the transposition of the eIDAS Regulation to the national legislation, each Member State had to appoint a competent authority as the Supervisory Body. The Supervisory Bodies landscape is mixed. In some cases, Member States (MS) followed the

text: Article 13

text: a approach and appointed an existing National Regulatory Authority for the Telecom sector. In other Member States, another national authority took over this responsibility, while there are some cases where this role was granted to a ministry. Moreover, in some Member States, there are more authorities involved, with different tasks, e.g. a National CSIRT or a Data Protection Authority, a scheme which is depicted in section 3.1.3. Considering that the Regulation’s rules for trust services entered into force on July 1, 2016, the reference period was the second half of 2016. At that time, the above mentioned legislative procedures were on-going for many Member States, thus there was a gap in the reporting procedure between TSPs and SBs. In total, all 28 EU Member States participated in this process. Out of these, only one Member State reported one significant incident and 27 countries submitted empty annual reports. There are possible various reasons for this figure. Firstly, as stated before, some incidents might not be registered due to the legislative delays and the absence of a SB. Secondly, there might be incidents on the boundary of the thresholds, eventually classified as not significant. Thirdly, SBs recorded incidents with minor significance in EU-level, but reportable in national level. Finally, other incidents are excluded from reporting because they had happened into a closed system . The registered incident’s significance was assigned with the value 3 on the adopted severity scale. The Supervisory Body indicated that the root cause was a system failure and more particularly after a system update there was no access to the validation of (qualified) certificates for electronic signatures service. Thus, the category of the impact is only availability. The affected Trust Service Provider was a qualified one and the incident’s duration was 10 hours. About 20 percent of the subscribers (41.000) were potentially impacted by this, however it had happened on a public holiday, consequently the actual percentage is considered to be far lower. In general, this incident can be marked as medium-impact, with no cross-border implications. Moreover, the TSP dealt promptly with this issue and took the appropriate measures to avoid the re-occurrence of the same problem. The new software includes a new feature which performs some additional checks in order to enhance the CRL accessibility. At this point, we should highlight a very important peculiarity of incidents falling under

text: Article 19

text: . There is the possibility that an incident has cross-border impact. According to the Regulation (see 2.1), these kind of incidents require immediate notification. Therefore, a productive endeavour is needed, to deal with them promptly, in an effective and efficient manner. Despite the fact that the Regulation is quite new, this will be important in the future. Recently, considerable attention has been placed on the role of the blockchain technology and the possible implications on the eIDAS. As the environment is continuously evolving, we might soon be confronted with the need of an updated incident reporting framework.

text: ENISA European Union Agency for Network and Information Security Science and Technology Park of Crete (ITE) Vassilika Vouton, 700 13, Heraklion, Greece Athens Office 1 Vass. Sofias & Meg. Alexandrou Marousi 151 24, Athens, Greece

text: PO Box 1309, 710 01 Heraklion, Greece ISBN: 978-92-9204-234-9 Tel: +30 28 14 40 9710 DOI: 10.2824/988312 info@enisa.europa.eu www.enisa.europa.eu

type: vagledning

utgivare: enisa


text: Legal notice

text: Notice must be taken that this publication represents the views and interpretations of the authors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the ENISA

text: Regulation (EC) No 460/2004

text: as lastly amended by

text: Regulation (EU) No 580/2011

text: . This publication does not necessarily represent state-of the-art and ENISA may update it from time to time. Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication. This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication. Reproduction is authorised provided the source is acknowledged. © European Network and Information Security Agency (ENISA), 2012

text: EC Incident notification

text: Incident reporting ENISA

text: Member stateMember state Member stateMember state

text: National National authority authority

text: Network or Network or Network or Network or Network or Network or service service service service service service provider provider provider provider provider provider

text: Here integrity means network integrity, which is often called availability or continuity in information security literature.

text: This does not mean that these are the only incidents that should be considered significant. To give an example: A cable cut of a redundant submarine cable or a security breach at a provider could well be considered significant by an NRA, but if this incident did not cause an outage it would be out of scope.

text: For example, suppose a provider with 1 million customers suffers a full outage, and suppose that in that country 10 million people have mobile internet, then the number of users affected is reported as: 10%.

text: Number of countries reporting significant incidents 11 Number of countries reporting no significant incidents

text: Number of countries without

text: Article 13

text: a implementation

text: 10 0 Fixed telephony Fixed Internet Mobile Telephony Mobile Internet Figure 2: Incidents per service (percentage)

text: 0 Fixed telephony Fixed Internet Mobile Telephony Mobile Internet Figure 3: Average number of users affected per incident per service (1000s)

text: 6 4 2 0 Fixed telephony Fixed Internet Mobile Telephony Mobile Internet

text: Hardware/software failure

text: Malicious attack

text: Human error

text: Natural phenomena

text: 10 20 30 40 50 Figure 6: Average duration of incidents per root cause category (hours) On average incidents caused by natural phenomena lasted longest (45 hours).

text: Hardware/software failure 9 9 Power cut

text: Cable cut 18 36 Bad change Storm Maintenance

text: Heavy snowfall

text: Cable theft

text: Hardware/software failure 6 6 Power cut

text: Cable cut

text: Bad change 12 Storm

text: Maintenance 12 Heavy snowfall

text: Power surges

text: Cable theft

text: failure Power cut

text: Cable cut 6 Bad change

text: Maintenance 10 Heavy snowfall

text: Human error

text: Power surges

text: failure Power cut

text: 3 Cable cut

text: Bad change

text: Heavy snowfall

text: Human error

text: Power surges

text: IPCC (the International panel on climate change) expects extreme weather to have more impact and to be more frequent in the coming years.

identifier: Annual Incident Report 2011

title: Annual Incident Report 2011

text: Annual Incident Reports 2011

text: Analysis of the Article 13a incident reports of 2011 October 2012

text: Annual Incident Reports 2011 ii Analysis of the Article 13a incident reports of 2011

text: About ENISA

text: The European Network and Information Security Agency (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu.

text: Authors

text: Dr. Marnix Dekker, Christoffer Karsberg

text: Contact

text: For contacting the authors, please use resilience@enisa.europa.eu. For media enquires about this paper, please use press@enisa.europa.eu.

text: Acknowledgements

text: For the completion of this report ENISA has worked closely with a working group of experts from national regulatory authorities and ministries from across Europe. PTS (SE), Ministry of Economic Affairs (NL), FICORA (FI), Ofcom (UK), ANACOM (PT), ComReg (IE), EETT, ADAE (GR), Ministry of Defence (DK), CPNI (UK), RTR (AT), ANCOM (RO), EA “ECNIS” (BG), CCED (FR), Bundesnetzagentur (DE), BIPT (BE), MITYC (ES), MPO, CTO (CZ), CERT LT (LT), MFSR(SK), ILR (LU), APEK (SI), MCA (MT), Ministry of Economic Development (IT), OCECPR (CY), PT (NO).

text: Annual Incident Reports 2011 iii Analysis of the Article 13a incident reports of 2011

text: Executive summary

text: For the first time in the EU, in spring 2012 national reports about security incidents were reported to ENISA and the European commission, under Article 13a of the Framework Directive (

text: ) which is a new article in the EU legal framework for electronic communications. In this document we analyse the 51 incident reports of severe outages of electronic communication networks or services. We summarize the key conclusions that can be drawn from the incident reports. Details can be found in the body of this document.  11 countries reported 51 significant incidents and 9 countries reported no significant incidents but this is probably due to the fact that these countries had implemented national reporting schemes towards the end of 2011. The number of users in these 20 countries was 166 million. We estimate that the number of incidents that will be reported over this year (2012) will increase by a factor of 10 because most countries now have mature implementation of the incident reporting process.  Most reported incidents affected mobile telephony or mobile internet (around 60% of the incidents).  Incidents affecting mobile telephony or mobile internet affected most users (around 300.000 users). This is consistent with the high penetration rate of mobile telephony and internet.  Most incidents were caused by root causes in the categories Hardware/software failure and Third party failure.  Incidents with root causes in the category Natural phenomena (storm, floods, et cetera) lasted 45 hours on average.  Natural phenomena like storms, floods and heavy snow have a big impact on the power supply of providers. Often these power cuts last several hours.  The reported incidents show there is a strong dependency on power supply, of both mobile and fixed communication services. It is well known that battery capacity of 3G base stations is limited to a few hours, and this means that lasting power cuts cause communication outages.  Hardware/software failures are the most frequent cause of mobile communication outages, and this percentage is notably higher than for fixed telephony or fixed internet. This could be the result of higher complexity (more dependencies in the more modern networks like 3G), less redundancy, or simply due to the fact that the more modern networks use hardware and software that is less mature and less reliable. ENISA, the National Regulatory Authorities (NRAs) and the EC have implemented the first incident reporting almost like a pilot, aware of the fact that implementation across the EU was still not complete. This has produced some crucial insights that would have been difficult to get otherwise – they are summarized in an epilogue.

text: As part of the activities of the

text: Article 13

text: a Working Group, ENISA, together with the NRAs of the different EU member states will discuss about specific types of incidents, and where needed initiate a discussion on technical guidance for NRAs and providers about preventing these incidents. ENISA will publish a similar overview and analysis, yearly, following subsequent rounds of annual summary reporting by the NRAs in the EU member states. The next report will be published in spring 2013, and will summarize and analyse the incidents that occurred in 2012.

text: Annual Incident Reports 2011 1 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 1 Introduction

text: For the first time in the EU, in spring 2012 national reports about security incidents were reported to ENISA and the European Commission, under

text: Article 13

text: a of the Framework Directive (

text: ), a new article introduced in the 2009 reform of the EU legal framework for electronic communications. In this document ENISA analyses the received 51 incident reports of severe outages of electronic communication networks or services. We refer to the Executive Summary for a summary of the analysis and the conclusions. This document is structured as follows. In Section 2 and Section 3 we briefly summarize

text: Article 13

text: a and we summarize the details of the technical implementation of

text: Article 13

text: a, as agreed in the

text: Article 13

text: a WG by the different NRAs of the EU member states. In Section 4 we describe step-by-step how this year the incident reporting (about the 2011 incidents) has been carried out. In Section 5 we analyse the incidents which were reported, and we conclude this paper with some general conclusions (Section 6) which follow from the analysis of the incidents. For the interested reader, as an epilogue, we raise some issues about the process of annual summary reporting itself. These issues are being discussed in the

text: Article 13

text: a Working group. Note that in this document we do not provide details from the individual incident reports. The analysis is only an aggregation, in terms of averages and percentages, across the EU. We do not make any references here to specific countries or specific providers. The incidents will be discussed in more detail in the

text: Article 13

text: a WG.

text: Annual Incident Reports 2011 2 Analysis of the

text: Article 13

text: a incident reports of 2011

text: Article 13

text: a of the Framework directive: ‘Security and Integrity’

text: The reform of the EU legal framework for electronic communications, which was adopted in 2009 and came into effect in May 2011, adds

text: Article 13

text: a to the Framework directive.

text: Article 13

text: a addresses security and integrity of public electronic communication networks and services. The legislation concerns national regulatory authorities (NRAs) and providers of public electronic communication networks and services (providers).

text: Article 13

text: a states:  Providers of public electronic communication networks and services should take measures to guarantee security and integrity of their networks.  Providers must report to competent national authorities about significant breaches of security or integrity.  National regulatory authorities should notify ENISA and national authorities abroad when necessary, for example in case of incidents with cross-border impact.  Annually, national regulatory authorities should submit a summary report to ENISA and the European Commission (EC) about the incidents.

text: The main incident reporting flows are shown in the diagram below. This document analyses the incidents that have been reported to ENISA and the EC (the black dashed arrow).

text: Annual Incident Reports 2011 3 Analysis of the

text: Article 13

text: a incident reports of 2011

text: Article 13

text: a Working Group

text: In 2010, ENISA, Ministries and NRAs initiated a series of meetings (workshops, conference calls) to achieve a harmonised implementation of

text: Article 13

text: a of the Framework directive. In these meetings, a working group of representatives of NRAs, the

text: Article 13

text: a Working Group, reached agreement on two non-binding technical documents providing guidance to the NRAs in the EU member states:  Technical Guideline for Incident Reporting and  Technical Guideline for Minimum Security Measures.

text: The

text: Article 13

text: a working group continues to meet several times a year to discuss the implementation of

text: Article 13

text: a, and to share knowledge and exchange views about addressing incidents. The current version of the technical guidelines (version 1.0) is now being updated (to version 2.0).

text: 3.1 Technical Guideline Incident Reporting Version 1.0

text: For the sake of reference we summarize the Technical Guideline on Incident Reporting Version 1.0.

text: 3.1.1 Services and incidents in scope

text: It was agreed with the NRAs to report only about incidents involving outages of services . The services in scope for annual summary reporting to ENISA and the EC are as follows:

text:  fixed telephony services,  fixed internet services,  mobile telephony services,  mobile internet services,  message services  e-mail services

text: In the remainder of this document we ignore e-mail, because only a few NRAs reported incidents regarding email, and because the total number of users (the basis for the reporting threshold) is often unknown to the NRA. We also merge messaging and mobile telephony for the sake of brevity.

text: 3.1.2 Incident reporting template

text: The reporting template has the following parameters:  Services impacted (selection)  Number of users (percentage)  Duration (hours)  Root cause category (see below)  Emergency calls or interconnections impacted  Details about the incident

text: Annual Incident Reports 2011 4 Analysis of the

text: Article 13

text: a incident reports of 2011

text:  Actions taken to mitigate  Lessons learnt It is important to note that the number of users, a percentage, is the percentage of the national user base of a service, not the percentage of the providers’ customers .

text: 3.1.3 Thresholds for annual summary reporting

text: The thresholds for annual summary reporting to ENISA and the EC are as follows.

text: 1. Number of users affected: The incident impacts more than 15% of the users of the service.

text: 2. Duration of the incident: The incident has impact for more than 8 hours.

text: 3. Geographic spread/region: The incident has impact in a specific, vulnerable, region, for instance an incident affecting an entire island or a large region with scarce population.

text: 4. Emergency calls: The incident has impact on the reachability of emergency call centres (112).

text: 5. Number of users affected and duration of the incident: The combination of number of users affected and duration of the incident is in the red area in the diagram below.

text: 6. Number of users affected and geographical spread/region: A service is unavailable for more than 10% of the users, all in a specific geographic area.

text: 7. Duration of the incident and geographical spread/region: The service is unavailable in a specific geographic area for more than 4 hours.

text: 1h<...<2h 2h<...<4h 4h<...<6h 6h<...<8h >8h

text: 1%<...< 2% of users

text: 2%<...< 5% of users

text: 5%<...< 10% of users

text: 10%<...< 15% of users

text: > 15% of users

text: 3.1.4 Root cause categories

text: In the incident reports we distinguish between five categories of root causes.  Natural phenomena - For instance storms, floods, heavy snowfall, earthquakes, and so on.  Human errors - Incidents that are caused by errors committed by employees of the provider.  Malicious attacks - Incidents that are caused by an attack, a cyber-attack or a cable theft e.g.  Hardware/Software failures – Incidents caused by a failure of hardware or software  Third party failures – Incidents caused by a failure or incident at a third party.

text: Annual Incident Reports 2011 5 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 4 Annual reporting over 2011

text: In this section we summarize how the annual reporting over 2011 was implemented. In spring 2012 the European Commission agreed with the EU Member states (in meetings of the COCOM) to do the first round of annual summary reporting about the 2011 incidents. The decision included a recommendation to use the reporting template published by ENISA agreed in the

text: Article 13

text: a WG. Following the COCOM meeting, ENISA implemented the technical procedure by deploying a basic electronic form based on the

text: Article 13

text: a guideline for incident reporting. In total, 29 countries participated in this process: all EU countries, and some of the EFTA and EU candidate countries. Eleven countries reported in total 51 significant incidents and 9 countries reported there were no incidents. The total number of users in these (20) countries was 166 million.

text: Figure 1: Countries involved in the annual summary reporting over 2011

text: Many countries implemented

text: Article 13

text: a late in 2011. This explains why so many countries (9) indicated they had not received reports about significant incidents. We estimate that the number of incidents that will be reported over this year (2012) will increase by a factor of 10.

text: Annual Incident Reports 2011 6 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 5 Analysis of the Incidents

text: In this section we aggregate the 51 reported incidents and we analyse them. First we give some examples of incidents (in Section 5.1), then we analyse the impact per service (in Section 5.2), then we analyse the impact per root cause category (Section 5.3), and in Section 5.4 we look at detailed root causes. We would like to stress that statistical conclusions based on these numbers should be drawn with care. The smaller incidents are not reported at an EU level and this means that the view is biased towards the larger incidents. Moreover many countries had set up incident reporting procedures only towards the end of 2011.

text: 5.1 Examples of incidents

text: To provide an idea of the different incidents that were reported, we provide some anonymized examples in this section.

text: 5.1.1 Big storm affecting power supply causing large scale outage (days, millions, natural disaster)

text: A severe storm hit several countries. The storm had a major impact on the power grid infrastructure and to a limited extent also on mobile network equipment (like mobile base stations). The prolonged power cuts eventually caused many mobile base stations to run out of power. As a result around a million users were without mobile communication services for 24 hours, and in some cases up to two weeks. The dependency of mobile communication services on external power supply is a common theme in many incident reports. Mobile base stations have limited battery power (for 4 to 8 hour), which is enough for everyday power outages, but obviously doesn’t help when there is a longer term power grid failure. This sequence of events (natural disaster, power cut, and outage) was frequently described in the incident reports.

text: 5.1.2 Configuration error (hours, millions, configuration error)

text: An employee of a fixed telephony provider made a configuration error. The error prevented fixed telephony users to make outgoing international phone calls to Western European countries for 4 hours. The incident was resolved after a reconfiguration and a reboot.

text: 5.1.3 Vandalism by former employee affected DSL (days, thousands, malicious attack)

text: A former employee of a provider deliberately set fire to a switching system, which was used for providing fixed internet service to around 10.000 subscribers. The incident was resolved by replacing the switch. Around 36 hours later the fixed internet service was working again.

text: 5.1.4 Faulty software update affected mobile telephony (hours, thousands, software failure)

text: A provider applied a regular software update at a Home Location Register (HLR) which turned out to be faulty. The failure at the HLR impacted mobile telephony and internet services. The incident affected about half of the provider’s customers and lasted around 8 hours.

text: Annual Incident Reports 2011 7 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 5.1.5 Submarine cable cut from anchorage (hours, thousands, third party)

text: A ship’s anchoring damaged one of four submarine cables connecting two islands. Contingency plans were triggered quickly, which meant that only a smaller number of users were affected.

text: 5.2 Impact on services

text: In this section we look at how the incidents impacted the electronic communication services.

text: 5.2.1 Incidents per service (percentage)

text: Figure 2 shows which percentage of incidents affected which services. Most incidents have an impact on two or more services (in fact the percentages in the chart add up to 175%). 100 90 80

text: 70 61 59 40 33 30 22

text: Most incidents (around 60%) affected mobile telephony or mobile internet. This would suggest that mobile services are more at risk of large-scale outages but we stress that the number of reported incidents is still rather small to support such conclusions.

text: 5.2.2 Number of users affected per incident per service (1000s)

text: Figure 3 shows the average number of users affected, per incident, per service. 500

text: 400 200 200 100

text: Annual Incident Reports 2011 8 Analysis of the

text: Article 13

text: a incident reports of 2011

text: Incidents affecting the mobile telephony involve on average 400.000 users. This is the highest for all services. This is partly due to the fact that mobile telephony has a larger penetration (on average 110% of the population for mobile telephony, compared to 50% for fixed telephony). The next paragraph corrects for this factor.

text: 5.2.3 Number of users affected per incident per service (percentage of national user base)

text: Figure 4 shows the average percentage of users affected per incident, per service. 18 16

text: 14 16 17 12 12

text: Figure 4: Average number of users affected per incident per service (percentage) On average, incidents affecting mobile telephony or mobile internet affect 16-17% of the users. This is slightly more than the percentages for the fixed communication services. This would suggest that, not only mobile communication services (telephony, internet) may be more vulnerable, but also that a larger portion of the users is affected in the incidents that were reported.

text: 5.2.4 Impact on emergency services and interconnections

text: In 33% of the incidents there was impact on emergency services - i.e. the possibility for users to contact emergency call-centres. In only 6% of the incidents there was impact on interconnections.

text: Annual Incident Reports 2011 9 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 5.3 Root causes

text: In this section we look at the impact of incidents, per root cause category. We also split the incidents out in more detailed root causes to give a better view of common root causes.

text: 5.3.1 Incidents per root cause category (percentage)

text: In Figure 5 we show the percentage of incidents per root cause category.

text: Natural phenomena

text: 33 Human error

text: 6 Malicious attack Hardware/software failure 47 Third party failure

text: Figure 5: Incidents per root cause category Most of the incident reports indicate that the root cause falls in the category ‘Hardware/Software failure’ (47 %) or ‘Third Party failure’ (33 %).

text: 5.3.2 Average duration of incidents per root cause category (hours)

text: Figure 6 shows the average duration of the incidents per root case category. Third party failure

text: 9 17 31 10 45

text: Annual Incident Reports 2011 10 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 5.3.3 Root cause categories per service (percentage)

text: Figures 7, 8, 9, and 10 show the root cause categories of incidents split out per service.

text: Fixed telephony

text: Natural phenomena 18 Human error 9 Malicious attack

text: 55 9

text: Hardware/software failure

text: Third party failure

text: Figure 7: Root cause categories for fixed telephony (percentage)

text: Fixed Internet

text: Natural phenomena 12 Human error

text: 53 Malicious attack

text: Hardware/software failure

text: Third party failure

text: Figure 8: Root cause categories for fixed internet

text: Annual Incident Reports 2011 11 Analysis of the

text: Article 13

text: a incident reports of 2011

text: Mobile Telephony

text: Natural phenomena 20 Human error

text: 30 7

text: Malicious attack

text: Hardware/software failure

text: Third party failure

text: Figure 9: Root cause categories for mobile telephony

text: Mobile Internet

text: Natural phenomena

text: Human error

text: 20 27

text: Malicious attack

text: 7 3

text: Hardware/software failure 47 Third party failure

text: Figure 10: Root cause categories for mobile internet

text: Annual Incident Reports 2011 12 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 5.4 Detailed root causes and secondary causes

text: In this section, instead of looking at the 5 root cause categories, we look at root causes and secondary causes triggering the incident. Based on the textual description in the incident reports, we have identified per incident one or two root causes that lead up to the incident. For example, when a storm leads to a power cut which leads to a network outage then for this incident both power cut and storm are counted as detailed root causes. Based on the textual descriptions in the 51 incident reports we identified 14 detailed (recurring) causes which lead up to the incidents.

text: 5.4.1 Root causes and secondary causes (percentages)

text: Figure 11 shows the percentage of incidents with a certain detailed cause causing it. 60

text: 41 20 20 14 10 6 6 4 4 4 2 2 2 2 2

text: Figure 11: Detailed root causes and secondary causes (percentages)

text: 5.4.2 Root causes and secondary causes (percentages per service)

text: Figure 12 shows the percentage of incidents per service by a particular cause. 60 50 40 30 Fixed telephony 20 Fixed Internet 10 Mobile Telephony Mobile Internet

text: Figure 12: Detailed root causes and secondary causes (percentages per service)

text: Annual Incident Reports 2011 13 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 5.4.3 Detailed root causes and secondary causes per service (percentages)

text: In Figure 13, 14, 15, 16 we show the detailed root causes and secondary causes, split out per service.

text: Fixed telephony

text: 9 18 27

text: Figure 13: Detailed root causes and secondary causes for fixed telephony.

text: Fixed Internet

text: 24 6 6 18 35

text: Figure 14: Detailed root causes and secondary causes for fixed internet.

text: For fixed internet most incidents are caused by cable cuts followed by Hardware or software failures.

text: Annual Incident Reports 2011 14 Analysis of the

text: Article 13

text: a incident reports of 2011

text: Mobile Telephony

text: 3 3 3 3 6 10 26

text: Figure 15: Detailed root causes and secondary causes for mobile telephony.

text: More than half of Mobile telephony incidents involve (as primary or secondary cause) a hardware or software failure.

text: Mobile Internet

text: 3 3 3 3 7 43 10 7 27

text: Figure 16: Detailed root causes and secondary causes for mobile internet.

text: Annual Incident Reports 2011 15 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 6 Conclusions

text: In this document we summarized how the incident reporting scheme, mandated by

text: Article 13

text: a of the Framework Directive (

text: ), was implemented across the EU and we analysed the incident reports ENISA and the EC received as part of the first round of reporting: 51 reports about major incidents that occurred in 2011. From the 51 significant incidents reported to ENISA and the EC, we can draw the following conclusions.  Mobile networks most affected: Most incidents affected mobile telephony or mobile internet (around 60% of the incidents).  Mobile network outages affect many users: Incidents affecting mobile telephony or mobile internet affected most users (around 300.000 users). This is consistent with the high penetration rate of mobile telephony and mobile internet.  Hardware/software failures and third party failures are most common root causes: Most incidents were caused by root causes in the categories Hardware/software failure and Third party failure.  Natural phenomena cause long lasting incidents: Incidents with root causes in the category Natural phenomena (storms, floods, etc.) lasted 45 hours on average .  Bad weather disrupting power supply causing outages: Natural phenomena like storms, floods and heavy snow have a big impact on the power supply of providers. Often these power cuts last several hours. In the incident reports we received, incidents caused by natural phenomena lasted 45 hours, on average.  Dependencies on the power supply sector: Dependency on power supply from both mobile and fixed communication services is clear. It is well known that battery capacity of 3G base stations is limited to a few hours, and this means, inevitably that lasting power cuts cause communication outages.  Hardware and software failures hit mobile networks more than other services. Hardware/software failures are the most frequent cause of mobile communication outages, and this percentage is notably higher than for fixed telephony or fixed internet. This could be the result of higher complexity (more dependencies in the more modern networks like 3G), less redundancy, or simply due to the fact that the more modern networks use hardware and software that is less mature and less reliable. ENISA, in the context of the

text: Article 13

text: a WG, will discuss specific incidents in more detail with the NRAs, and if needed, discuss and agree on mitigating measures. ENISA will publish a similar overview and analysis, yearly, following each round of annual summary reporting by the EU member states. The next report will be published in spring 2013, and will summarize and analyse the 2012 incidents. We would like to take this opportunity to thank the NRAs, the European Member States and the European Commission for the fruitful collaboration, which has allowed for an efficient and rapid implementation of the incident reporting process.

text: Annual Incident Reports 2011 16 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 7 Epilogue

text: ENISA, the NRAs and the EC have implemented the first incident reporting almost like a pilot, fully aware of the fact that implementation across the EU was still not complete. This pilot has provided us with some crucial insights that would have been difficult to get otherwise. For the interested reader we list them here. Note that these issues are currently being discussed in the

text: Article 13

text: a WG.  Absolute thresholds: Reporting on the basis on percentage of users instead of absolute numbers appears to make the reporting unbalanced. Large countries report few incidents, while small countries have to report many (smaller incidents). Absolute numbers for reporting should be introduced to make sure the burden of reporting is proportional to the size of the country and the resources of the NRA.  Simplification of thresholds: Thresholds used in the first version of the incident reporting guideline were sometimes unclear and complicated. Not all NRAs applied all the thresholds. To align the reporting across the EU we are simplifying and reducing the number of thresholds.  Impact on networks: The incident reporting template only mentions the type of service that was affected, for example mobile telephony. But it could be very useful to understand which type of network was affected. This could, for example, show if 2G networks are more resilient in the face of power cuts than 3G networks. The template should allow for additional fields that describe which network is impacted.  Use of the reporting template: While most of the NRAs used, as recommended by the EC, the incident reporting template of the

text: Article 13

text: a WG, some member states did not used this template. In most of these cases vital information was missing from the incident reports, and for this reason these incidents could not be included in the overall analysis. To allow for the incident reports to be included in an overall analysis, NRAs should use the same reporting template.  Generic root causes: Many incident reports mentioned Hardware/software failure or Third party failure as the root cause category. Both categories are quite generic. For example, a power cut which is a frequent cause of outages, would be reported as third-party failure, just like it was a software update by a third party vendor, or the interruption of a network connection managed by a third party. It would be good to use more detailed root causes for the incident reporting.  Sequence of events: In a number of incident reports there was a common pattern in how the incident started. For example, often there was severe weather and then a power cut, followed by the failure or depletion of backup power, causing outage. It would be useful to allow NRAs to report about such chains of events in the incident reporting template. This would also reduce conflicting situations where incidents may be perceived has having one out of two possible root causes, for instance a storm affecting power supply (third party or natural disaster?).  Mapping to security measures: Preventing incidents is the main goal of

text: Article 13

text: a, but there is currently no clear mapping from the incident reports to the security measures (mandated by

text: Article 13

text: a). Incident reporting should include a pointer to the security measures that could have (or should have) prevented the incident. This would allow NRAs (nationally) and the

text: Article 13

text: a WG (on an EU level) to better understand how to prevent future incidents.

text: Annual Incident Reports 2011 17 Analysis of the

text: Article 13

text: a incident reports of 2011

text: 8 References 8.1 Related ENISA papers

text:  The

text: Article 13

text: a WG technical guidelines on incident reporting and on minimum security measures: https://resilience.enisa.europa.eu/article-13  ENISA’s whitepaper on cyber incident reporting in the EU shows

text: Article 13

text: a and how it compares to some other security articles mandating incident reporting and security measures:  For the interested reader, ENISA’s 2009 paper on incident reporting shows an overview of the situation in the EU 3 years ago

text: 8.2 EU Legislation

text: Article 13

text: a of the Framework directive of the EU legislative framework on electronic communications: http://ec.europa.eu/information_society/policy/ecomm/doc/140framework.pdf  The electronic communications regulatory framework (incorporating the telecom reform): http://ec.europa.eu/information_society/policy/ecomm/doc/library/regframeforec_dec2009. pdf  An overview of the main elements of the 2009 reform: http://ec.europa.eu/information_society/policy/ecomm/tomorrow/reform/index_en.htm

text: Annual Incident Reports 2011 18 Analysis of the

text: Article 13

text: a incident reports of 2011

text: P.O. Box 1309, 71001 Heraklion, Greece www.enisa.europa.eu