Guideline on assessing security measures in the context of Article 3(3) of the Open Internet regulation
www.enisa.europa.eu European Union Agency For Network and Information Security
About ENISA
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 EU citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists 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 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. Contact For queries in relation to this paper, please use resilience@enisa.europa.eu. For media enquires about this paper, please use press@enisa.europa.eu. Authors Eleni Vytogiannni, Marnix Dekker Acknowledgements This guideline is the result of a close collaboration between ENISA and the members of the Article 13a Expert Group. The ENISA Article 13a Expert group is a group of experts from national authorities and electronic communication regulators in the EU and EFTA countries, focusing on telecom security. BEREC’s Net Neutrality Expert Working Group reviewed this guideline. In preparing this paper we conducted a survey to assess the state of play. We received survey responses from 38 providers across Europe. Their input was vital in the development of this paper and we would like to thank them for their contribution. Legal notice Notice must be taken that this publication represents the views and interpretations of ENISA, 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 Regulation (EU) No 526/2013. 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. Copyright Notice © European Union Agency for Network and Information Security (ENISA), 2018 Reproduction is authorised provided the source is acknowledged. ISBN: 978-92-9204-271-4, DOI: 10.2824/94531 02
Table of Contents
Executive Summary 4 1. Introduction 5 1.1 Scope 5 1.2 Target audience 5 1.3 Terminology 5 2. Legal context 6 3. Evaluating the necessity of security measures 8 3.1 Evaluation factors 8 3.1.1 Security risk 8 3.1.2 Effectiveness 8 3.1.3 Proportionality 9 3.1.4 Appropriateness 9 3.2 Evaluation checklist 9 3.3 Justification form 10 Annex A: Examples 12 A.1 Blocking ports 7547 and 5555 by FastBito to mitigate Mirai botnet 12 A.2 Blocking ports 161 and 162 by HomeNet to protect vulnerable computers 14 Annex B: Risk assessment 17 Bibliography/References 18 03
Executive Summary
In the EU, net neutrality is guaranteed by the so-called Open Internet Regulation (Regulation (EU) 2015/2120), which came into force in 2016 and establishes rules for providers of internet access services in the EU to ensure equal and non- discriminatory treatment of internet traffic. Article 3 of the regulation states that providers can implement reasonable traffic management measures, which must be transparent, nondiscriminatory, proportionate, and based on objective technical quality of service requirements. Beyond these reasonable traffic management measures, providers can not implement traffic management measures that block, slow down, alter, restrict, interfere with, degrade or discriminate between specific content, applications or services, except when it is necessary a) to comply with EU or national legislation or court orders, b) to preserve the integrity or security of the networks, the services using the networks, or the enduser equipment, or c) to prevent an impending network congestion, which is temporary and exceptional. Article 5 of the Open Internet Regulation requires National Telecom Regulatory Authorities (NRAs) to supervise and enforce net neutrality, requiring them to, among other things, closely monitor and ensure compliance with Article 3. In doing so, NRAs may assess whether a traffic management measure applied by a provider, in a specific case, is permissible under Article 3. In its recent Opinion BEREC indicates it will work on further clarifications on how NRAs may assess security measures under Article 3. This document is a technical guideline for NRAs to support them in assessing when security measures are justified under point (b) above. This guideline contains: A list of evaluation factors that may be taken into account by NRAs to understand whether a security measure is justified or not (see Section 3.1). An evaluation checklist that NRAs may use when assessing if a measure is justified (see Section 3.2). A justification form that may be used by NRAs to collect information about a security measure from providers (see Section 3.3). The justification form may be used also by providers as part of their internal processes to document which security measures they consider to fall under this exception. It is important to note that whether or not a security measure is justified under exception b (see above) depends on the circumstances, the type of networks, services, etc. Security is a fast moving field and cyberattacks are changing constantly. What may have been an effective measure at one point in time, in the middle of a large-scale attack for instance, may be considered as unnecessary and disproportionate later on. In the annex of this paper we give two hypothetical examples showing how the justification form and the evaluation checklist could be filled in. Regulation (EU) 2015/2120 of the European Parliament and of the Council of 25 November 2015 laying down measures concerning open internet access and amending Directive 2002/22/EC and Regulation (EU) No 531/2012 https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015R2120&from=EN BEREC Opinion for the evaluation of the application of Regulation (EU) 2015/2120 and the BEREC Net Neutrality Guidelines” 04
1. Introduction
The EU’s Open Internet Regulation (Regulation (EU) 2015/2120), which came into force in 2016, establishes rules for providers of internet access services in the EU to ensure equal and non- discriminatory treatment of internet traffic. The Regulation allows providers to make two types of traffic management: Traffic management measures that are reasonable, where reasonable means that they have to be proportionate, transparent, non-discriminatory, not be based on commercial considerations, based on objective technical quality of service requirements. Exceptional traffic management measures going beyond reasonable traffic management measures (which block, slow down, alter, restrict, interfere with, degrade or discriminate between specific content, applications or services, or specific categories thereof) that are necessary, a. to comply with EU or national legislation or court orders, b. to preserve the integrity or security of i. networks ii. services using the networks iii. end-user equipment c. to prevent an impending network congestion, which is temporary and exceptional. This document is a technical guideline for NRAs to provide guidance on point b above. 1.1 Scope The scope of this guideline is the security exception (point b above) to the net neutrality rule. The goal is to help NRAs in evaluating whether or not a particular security measure is necessary to preserve the integrity or security of networks, services using the networks. This guideline does not prescribe or exhaustively list justifiable security measures, or cyber threats that must be mitigated by providers, because what is justifiable under the exception depends on the circumstances. 1.2 Target audience This guideline is intended for NRAs in the EU and EFTA countries. This guideline may also be useful for providers of internet access services operating in the EU and EFTA countries. 1.3 Terminology The term “security measure” is broad and in general security measures can range from the installation of an antivirus software on a computer, to background checks on personnel, incident response procedures, backup power diesel generators, failover submarine cables, etc. In this guideline the term "security measures" refers to the security measures relevant under this exception (i.e. item b of Article 3.3 of the Open Internet Regulation). In practice, the security measures most commonly implemented by providers under this exception, include measures like port blocking, permanently or temporarily, for certain traffic, for instance outbound traffic, or for certain customers, DNS blackholing, to address malware of DDoS attacks by using DNS redirection, or blocking of IP addresses. In most cases these security measures are directly related to ongoing or recent DDoS attacks or malware campaigns or critical vulnerabilities in common software or protocols. 05
2. Legal context
The EU’s Open Internet Regulation establishes the rules for equal and non- discriminatory treatment of internet traffic provision across Europe. The Regulation enshrines the principle of Net Neutrality into EU law and protects rights of end-users of electronic communication networks and services by providing a legal framework for an open internet. Providers of internet access services are not allowed to block, throttle or discriminate certain end-users or certain traffic, services or applications, except in certain cases. These are when the exceptions of Article 3(3) of the Regulation are met. Article 3 Safeguarding of open internet access 3. Providers of internet access services shall treat all traffic equally, when providing internet access services, without discrimination, restriction or interference, and irrespective of the sender and receiver, the content accessed or distributed, the applications or services used or provided, or the terminal equipment used. The first subparagraph shall not prevent providers of internet access services from implementing reasonable traffic management measures. In order to be deemed to be reasonable, such measures shall be transparent, non-discriminatory and proportionate, and shall not be based on commercial considerations but on objectively different technical quality of service requirements of specific categories of traffic. Such measures shall not monitor the specific content and shall not be maintained for longer than necessary. Providers of internet access services shall not engage in traffic management measures going beyond those set out in the second subparagraph, and in particular shall not block, slow down, alter, restrict, interfere with, degrade or discriminate between specific content, applications or services, or specific categories thereof, except as necessary, and only for as long as necessary, in order to: (a) comply with Union legislative acts, or national legislation that complies with Union law, to which the provider of internet access services is subject, or with measures that comply with Union law giving effect to such Union legislative acts or national legislation, including with orders by courts or public authorities vested with relevant powers; (b) preserve the integrity and security of the network, of services provided via that network, and of the terminal equipment of end-users; (c) prevent impending network congestion and mitigate the effects of exceptional or temporary network congestion, provided that equivalent categories of traffic are treated equally. Examples of traffic management measures going beyond the reasonable ones and which might be permissible under the exception b) are mentioned in the preamble 14 of the Open Internet Regulation: “ (14) Second, traffic management measures going beyond such reasonable traffic management measures might be necessary to protect the integrity and security of the network, for example by preventing cyberattacks that occur through the spread of malicious software or identity theft of end-users that occurs as a result of spyware.”. 06 BEREC in its “Guidelines on the Implementation by National Regulators of European Net Neutrality Rules” provides recommendations to the NRAs on the implementation of their obligations. We quote BEREC’s guideline in relation to the security exception (article 3(3) b), for the sake of completeness: 83. Typical attacks and threats that will trigger integrity and security measures include: • flooding network components or terminal equipment with traffic to destabilise them (e.g. Denial of Service attack); • spoofing IP addresses in order to mimic network devices or allow for unauthorised communication; • hacking attacks against network components or terminal equipment; • distribution of malicious software, viruses etc. 84. Conducting traffic management measures in order to preserve integrity and security of the network could basically consist of restricting connectivity or blocking of traffic to and from specific endpoints. Typical examples of such traffic management measures include: • blocking of IP addresses, or ranges of them, because they are well-known sources of attacks; • blocking of IP addresses from which an actual attack is originating; • blocking of IP addresses/IAS showing suspicious behaviour (e.g. unauthorised communication with network components, address spoofing); blocking of IP addresses where there are clear indications that they are part of a bot network; • blocking of specific port numbers which constitute a threat to security and integrity. 85. NRAs should consider that, in order to identify attacks and activate security measures, the use of security monitoring systems by ISPs is often justified. In such cases, the monitoring of traffic to detect security threats (such as those listed in paragraph 84) may be implemented in the background on a continuous basis, while the actual traffic management measure preserving integrity and security is triggered only when concrete security threats are detected. Therefore, the precondition “only for as long as necessary” does not preclude implementation of such monitoring of the integrity and security of the network. 86. Besides monitoring the integrity and security of the network, possible security threats may also be identified on the basis of reports/complaints from end-users or blocking lists from recognised security organisations. 87. This exception could be used as a basis for circumvention of the Regulation because security is a broad concept. NRAs should therefore carefully assess whether the requirements of this exception are met and to request that ISPs provide adequate justifications when necessary.” BEREC Guidelines on the Implementation by National Regulators of European Net Neutrality Rules https://berec.europa.eu/eng/document_register/subject_matter/berec/regulatory_best_practices/guidelines/6160berec-guidelines-on-the-implementation-by-national-regulators-of-european-net-neutrality-rules 07
3. Evaluating the necessity of security measures
This section provides guidance for NRAs in evaluating the necessity of security measures and contains A list of evaluation factors that could be taken into account by NRAs, A checklist for evaluating the factors and weighing the pros and cons of a measure, A justification form, which could be used by NRAs to collect information from providers 3.1 Evaluation factors Providers of internet access services need to have appropriate security measures in place. To keep their networks and services secure they continuously make risk assessments about security threats, risks and measures. Following a risk assessment, a provider may decide that a certain security measure is necessary to protect the networks, the services using the network, or end-user equipment. This risk assessment takes into account many factors, including the severity of the threat, the cost and complexity of a measure, sideeffects etc. NRAs may need to assess whether or not a certain security measure is justified, for example following a complaint by an end-user. In general, this assessment requires a case-by-case evaluation, because it depends on circumstances, which are specific for that provider. It is impossible to make an exhaustive or prescriptive list of security measures that are justified. NRAs could take into account the following factors when evaluating if a security measure is necessary: 1) Security risk – the security risk for the network, services, and/or end-user equipment 2) Effectiveness - the effectiveness of the security measure in reducing the risk 3) Proportionality - the proportionality of the measure, i.e. limited in time and scope, few side-effects 4) Appropriateness – the appropriateness of the measure, i.e. in line with industry good practices The evaluation factors are explained in more detail below. 3.1.1 Security risk A security risk, associated with a threat, is high if the potential impact of the threat is high and the likelihood that the threat materializes is high. In this context, what matters is the risk for the network, services, and/or the end-user equipment. If the security risk is not high, then the security measure may not be justifiable. Questions to ask: How severe and urgent is the security threat? What is the potential impact of the security threat? What is the likelihood that the security threat materializes and has an impact? To assess security risk one must look at both the likelihood and the impact. Threats with a low potential impact and a low probability, for instance, are minor risks. Threats with high probability and high impact are major risks. Annex B includes a standard table to rate risks based on likelihood and impact. 3.1.2 Effectiveness A security measure is effective if it reduces the security risk (see above) significantly. If the measure does not reduce the risk by much, then the security measure may not be justifiable. Questions to ask: To what extent is the risk mitigated when the security measure is implemented? What would the impact be on the network, services and customers if the measure is not applied? 08 What is the residual risk? 3.1.3 Proportionality A security measure is proportional when it mitigates the threat effectively, without too many side-effects. In the context of the net neutrality rules it is important to assess the impact of the measure on competing services, on ‘good’ network traffic, ‘normal’ use of end-user equipment, etc. If the security measure blocks a lot of ‘good’ network traffic or if the blocking disables an entire network protocol or software application, then the security measure may not be justifiable. Questions to ask: Is the scope of the measure limited to specific traffic, networks, or end-user? What is the duration, is the measure time-limited? Is there impact on ‘good’ network traffic and legitimate services (false positives)? Is there impact for the end-users? 3.1.4 Appropriateness A security measure is appropriate when it is the right measure for this risk, considering the threat landscape, the technology, industry standards and good practices, alternatives solutions, etc. Questions to ask: Is the measure considered the appropriate measure to mitigate this threat/risk? Is the measure recommended in industry good practices or standards? Are there alternatives that are more effective or more proportionate? As mentioned already, whether or not a security measure is justifiable as being necessary depends on the circumstances. Providers will need to do a risk assessment and evaluate this on a case-by–case basis. Also, the NRAs may need to evaluate if a security measure is justifiable, by looking at all the factors, weighing the pros and the cons. The table below gives some examples of how these factors could weigh in an evaluation.
FACTORS MORE JUSTIFIED (+) LESS JUSTIFIED (-)
Security risk The risk is major The risk is minor
Residual risk hardly changed. Risks before and Effectiveness Residual risk is significantly reduced. after are similar.
Blunt and wide-ranging, many side-effects, lots Proportionality Targeted scope and duration, few side-effects. of good traffic and services are blocked.
It is a common approach, an industry good It is an unusual measure for mitigating this Appropriateness practice. No alternatives. threat. Usually done differently.
3.2 Evaluation checklist An NRA may receive a complaint or be otherwise triggered to investigate if a security measure is justifiable under the net neutrality rules. NRAs can use the evaluation factors in an evaluation procedure, for example as part of an evaluation checklist. We give an example checklist below.
EVALUATION CHECKLIST
Security measure summary Provider(s) involved, network/services in scope, summary of security measure
09 3.3 Justification form As part of an evaluation, NRAs may need to collect information from providers about security measures in place. This section proposes a justification form for collecting and structuring the relevant information about a security measure. Providers could also use this justification form as part of internal processes, to document the reasoning and justification behind security measures.
JUSTIFICATION FORM FOR SECURITY MEASURES – SECURITY EXCEPTION OF THE NET NEUTRALITY REGULATION Provider name Hint: company name 1. General information Contact point Hint: contact name, email Summary Hint: short name of measure Exception to net-neutrality rules, for security Hint: Indicate with an X which applies and explain measures that are necessary to preserve: Networks X Hint: explain which networks 2. Legal justification services using the networks X Hint: explain which services end-user equipment X Hint: explain which equipment Hint: Describe what triggered the implementation of the measure (external Trigger request, request from a CSIRT, internal 3. Trigger and duration assessment, user complain, specific event, monitoring etc.) Start time Hint: Explain when was the measure first End time implemented and when it will be removed
Hint: Describe the threat (DDoS attack, malware, Description of the threat phishing, spam, vulnerability, etc)
4. Security threat Hint: Reference for this threat of the vulnerability, advisory bulletin and source of Reference for the threat information (CVE_ID and other external references describing this vulnerability)
Hint: Explain the risk for the security of the Explanation of the risk network, service or end-user equipment
5. Security risk Hint: Assess likelihood, e.g. very low, very high, Likelihood etc.
Impact Hint: Assess impact, e.g. very low, very high, etc.
Risk Hint: Rate the risk, e.g. – minor, significant, major
Hint: Port blocking, IP blocking, DNS blackholing Technical description of measure etc. Specify protocol, port, IPs, inbound/outbound traffic.
Hint: Refer to an international standard or Industry good practice or standard industry good practice or recommendation.
6. Measure details Hint: Alternative measures, possibilities, as Alternatives possible options for the future
Networks or services in scope Hint: All n/w, core, fixed, mobile.
End-users in scope Hint: All, some, groups
Hint: How does the measure protect from the Mechanism threat
Hint: How effective is the measure in reducing Effectiveness the risk
Hint: Are there side-effects for customers Side-effects (services affected, access to websites), which customers experience side-effects (all, some).
7. Side-effects, communication, opt-out Hint: How is the measure communicated to the Communication users (link to policy, or email etc.)
Hint: Is there an opt-out available for the users, Opt-out under which circumstances and which is the procedure
In the annex of this guideline we give two examples, using the justification form and the factors for hypothetical cases, using fictitious names of providers: Blocking of port TCP/7547 and TCP/5555 (to counter Mirai malware) by the provider FastBits Blocking of port UDP/161 (to protect from a Microsoft PC vulnerability) by the provider HomeNet.
Annex A: Examples
In this annex we give two examples by filling in the justification form for some hypothethical cases. Blocking of ports TCP/7547 and TCP/5555 to counter Mirai malware by the provider FastBits Blocking of ports UDP/161 to protect from a Microsoft PC vulnerability by the provider HomeNet. For each of these cases, we also show how the factors could weigh in the evaluation by listing, hypothetically, the pros and cons of the implemented security measures. A.1 Blocking ports 7547 and 5555 by FastBito to mitigate Mirai botnet
JUSTIFICATION FORM FOR SECURITY MEASURES – SECURITY EXCEPTION OF THE NET NEUTRALITY REGULATION
Provider name FastBito
1. General Contact point G.Puccini - GP@FastBito information Blocking of ports 7547 and 5555 to mitigate Summary Mirai
Exception to net-neutrality rules, for security measures that are necessary to preserve:
Networks X DDoS attacks flood out networks 2. Legal justification services using the networks
Routers and other Mirai targets end-user equipment X (IoT)
Internal assessment, media reports about Mirai impact. Mirai botnet is causing large Trigger outages due to ever-growing DDoS attacks. 3. Trigger and Mirai infections also caused outages by start time disabling home routers.
Start time May 2018
End time May 2019
Mirai malware exploits vulnerabilities in internet connected devices, including routers Description of the threat and IoT devices. The devices are then used for 4. Security threat large-scale DDoS attacks.
ENISA Cyber Security info note : “Mirai” Reference for the threat malware, attacks Home Routers
https://www.incapsula.com/blog/newvariant-mirai-embeds-talktalk-homerouters.html
The Mirai botnet is used for large-scale DDoS Explanation of the risk attacks with serious impact for targeted 5. Security risk websites.
Likelihood Very high
Impact Medium
Risk Major
Port blocking, TCP 7547 and 5555, inbound Technical description of measure traffic.
https://www.enisa.europa.eu/publications/in Industry good practice or standard fo-notes/mirai-malware-attacks-homerouters
6. Security Alternatives N/A measure details Networks or services in scope Core network, all inbound traffic
End-users in scope All customers
Protects from infection by Mirai. Prevents Mechanism Mirai botnet from growing bigger.
Reasonably effective, for now, but the Mirai botnet will change its attack vector and there Effectiveness are plenty of internet-connected devices with other vulnerabilities.
Limited side-effects because port TCP 7547 is only used for device configuration. Routers 7. Side-effects, Side-effects are usually not configured via the internet communication but via the local network of the customers or and opt-out from dedicated hosts in the ISP network.
Measure explained and listed at: Communication www.fastbito.com/security
Opt-out Opt-out not available
Below we show an example of how to use the evaluation factors in an assessment.
FACTORS PROS CONS
There is a major risk for the terminal equipment of end-users. Security risk There is a major risk for ISP networks because DDoS attacks cause large outages.
FACTORS PROS CONS
Reasonably effective. Measure prevents Mirai There are still plenty of vulnerable devices. This Effectiveness botnet from becoming bigger measure will be bypassed by the attackers.
Limited side effects (TCP 7547) used only for Permanent is too long, should be time-limited, Proportionality device configuration until when the Mirai threat is resolved.
Measure is widely implemented by ISPs. A better way to prevent botnets like Mirai from Appropriateness Measure is mentioned in good practice guideline spreading is to patch devices regularly and not use standard passwords on devices like routers! on mitigating Mirai
A.2 Blocking ports 161 and 162 by HomeNet to protect vulnerable computers
JUSTIFICATION FORM FOR SECURITY MEASURES – SECURITY EXCEPTION OF THE NET NEUTRALITY REGULATION
Provider name HomeNet - Internet for the home
1. General Contact point M.Zimmermann - MZ@HomeNet.com information Blocking SNMP 161 and 162 towards Summary customers
Exception to net-neutrality rules, for security measures that are necessary to preserve:
2. Legal networks justification services using the networks
end-user equipment X End user equipment, PCs, computers
Large scale SNMP reflected amplification Trigger DDoS attacks observed. Many cyber-attacks 3. Trigger and use SNMP. start time Start time May 2017 End time May 2018
SNMP Reflected Amplification DDoS attack Description of the threat targeting user devices that are SNMP enabled on the WAN interface. 4. Security threat
https://www.bitag.org/documents/SNMP- Reference for the threat Reflected-Amplification-DDoS-Attack- Mitigation.pdf
Difficult to identify the source of the 5. Security risk attackers’ host or the bot n/w. Large number Explanation of the risk of end-users infected by malware, high risk for amplification DDoS attack.
Likelihood High
Impact High
Risk Major
Blocking SNMP protocol UDP/161 for all Technical description of measure customers on the n/w – i.e. between WAN and customers.
https://www.bitag.org/documents/SNMP- Industry good practice or standard Reflected-Amplification-DDoS-Attack- 6. Security Mitigation.pdf measure details Alternatives N/A
Networks or services in scope Core network, all inbound traffic
End-users in scope All customers
Mechanism Blocks SNMP reflection DDoS attacks
Effectiveness Effective
Limited side-effects because network management is usually not done via the 7. Side-effects, Side-effects WAN. Some business users may be using communication SNMP. and opt-out Measure explained and listed at: Communication www.homenet.com/security
Opt-out Yes, opt-out available – upon request.
Below we show an example of how to use the evaluation factors in an assessment.
FACTORS PROS CONS
There is a major risk for the terminal equipment of end-users, of infection of their PCs. Security risk There is a major risk for the ISP services, because these infections are used to create DDoS attacks causing outages.
Very effective. Measure prevents spreading of Effectiveness infection and reduces DDoS attacks (using SNMP reflection).
Limited side effects, because SNMP is used for Proportionality network management which is usually not done over a WAN connection.
FACTORS PROS CONS Duration of the measure is time-limited (1 year)
Ideally, remotely exploitable vulnerabilities in Measure is mentioned as an industry good devices should be addressed by the device Appropriateness practice manufacturers and operating system vendors, not the telecom operator.