Scoping the NIS Directive

The NIS Directive is all about securing the delivery of a service. Yet, it can be difficult to understand the systems in scope. In this white paper, we present two methodologies to identify the systems and assets in scope of the NIS Directive.

Preamble

In a first article, we introduced the NIS Directive, one major cyber security regulation in these recent years.

In this article, we discuss on the applicability of the NIS Directive. We will see that the NIS Directive is all about securing the delivery of a service. Yet, its application could become tedious as most network and information systems work interdependently. For that purpose, we will explain how to refine the scope of the NIS Directive and present two methodologies to identify the critical assets in scope.

This article is part of a series that aims to better apprehend this directive.

Securing the Continuity of Essential Services

The NIS Directive requires Operators of Essential Services (OESs) and Digital Service Providers (DSPs) to implement “appropriate and proportionate organisational and technical security measures to manage the risks posed to the security of network and information systems which they use to operate their service.”

Moreover, OESs and DSPs must take “appropriate measures to prevent and minimise the impact of incidents affecting the security of the network and information systems used for the provision of their service, with a view to ensuring the continuity of those services.”

These two regulatory requirements emphasize the importance of protecting the service from cyber security risks. It demands a proactive approach to identify the scope, i.e. the assets that are essential to the service. It also reinforces the importance of resilience and incident handling in order to limit the potential impact on a service should a security incident occurs.

Hence, the intent of the NIS Directive is really about protecting the society from major disruptions due to a cyber incident. For that purpose, OESs and DSPs must identify their critical network and information systems, the security risks they face, and protect them with appropriate and proportionate security measures. In the spirit of the NIS Directive, these security measures will depend on business objectives.

Thresholds for Incident Notification

The NIS Directive requires OESs and DSPs to notify their competent authority or CSIRT of incidents having “significant impact on the continuity of their service, without undue delay.” We call these incidents “NIS Incidents”.

The significant impact is defined by competent authorities for the OESs and DSPs in their sector. In order to do so, competent authorities can establish thresholds using various parameters:

By combining these parameters, it is possible to refine thresholds for various scenarios (local or national operator, short or long disruption, etc.).

In reality, most competent authorities will define NIS incident thresholds using one or two parameters. This keeps these thresholds measurable and gives OESs and DSPs the ability to react before an incident can cause a significant impact on their service.

Figure 1. Possible combination of incident thresholds

Nevertheless, incidents can evolve through time, and some minor incidents can rapidly escalate into a NIS incident. To limit this risk, OESs and DSPs should consider business continuity and resilience requirements in order to minimise the impact of a security event as soon as possible. We will explore this topic in a future article.

Refining the scope

Assets in Scope

The scope of the NIS Directive focuses on network and information systems that are used to provide a service. This means any network, hardware, software that are essential to deliver a service (i.e. which failure would affect the level of service). We will refer to them as “critical assets” in the rest of this article.

The NIS Directive defines these network and information systems as:

  1. An electronic communications network within the meaning of point (a) of Article 2 of Directive 2002/21/EC;
  2. any device or group of interconnected or related devices, one or more of which, pursuant to a program, perform automatic processing of digital data; or
  3. digital data stored, processed, retrieved or transmitted by elements covered under points (a) and (b) for the purposes of their operation, use, protection and maintenance;

In summary, the scope of the NIS Directive applies beyond data. It considers physical devices, their dependencies and the systems in charge of their security. As such, the NIS Directive requires following a system-of-systems approach.

Note that the dependencies of critical assets must also be considered. These dependencies can be “cyber” or “non-cyber” such as power supply, air conditioning, etc.

Incidents in Scope

A NIS Incident is an incident that has a significant impact on the continuous delivery of a service. In case of such incident, OESs and DSPs must notify their Competent Authority or CSIRT using a reporting template, without undue delay.

This means that the type of NIS Incident does not matter: any incident that causes a disruption must be notified. This makes sense, as it can be very difficult to analyse the root causes of an incident in the short timeframe allocated for notification.

For that purpose, OESs and DSPs must notify:

Note that a NIS Incident can be the result of one or several issues. The intention of the mandatory notification is to serve a purpose for lessons-learned and continuous improvement.

What is Out of Scope?

The NIS Directive only considers network and information systems that are essential to provide a service. This means that non-essential assets fall out of scope. For example, an email server that does not directly contribute to the service would be out of scope.

Similarly, manual processes would fall out of scope. Manual processes are quite common in sectors where safety is involved.

In some Member States, some legacy assets can be left out of scope if there is a plan to replace them to reduce the risks they may introduce. Yet, this decommission must happen in a near future. For instance, planning the replacement of a legacy critical asset with known vulnerabilities in the next five years goes against the spirit of the NIS Directive.

However, it is important to consider a holistic approach during scoping. Some systems might present a risk even though they are out of scope. For example, an IoT CCTV system might not be essential to the service. Yet, it may contain vulnerabilities that can give an entry-point to an attacker to escalate an attack on critical assets. Hence, OESs and DSPs must assess these risks during their NIS Directive assessment.

Identification of Critical Assets

The NIS Directive requires OESs and DSPs to secure their critical assets in order to minimise the risks that a security incident affects the delivery of their service. In theory, every organisation knows what is important to deliver its service (and run the business). In practice, it is not always easy to maintain an up-to-date asset inventory (if it exists), list all critical assets, their dependencies, and the necessary information to secure them.

Most of the Member States leave the identification of critical assets to operators, as they know better than anyone else what assets are important to them. However, in some Member States, competent authorities can establish a list of critical assets to secure at minimum in their sector.

For that purpose, several methodologies can help identify and categorise assets. These methodologies demand a certain degree of cooperation between different parts of the business. They contain implicit requirements for people, process and techniques that would help comply with the NIS Directive: asset management, risk management, governance, resilience, etc.

Note that the NIS Directive applies to critical assets owned by the operator, even when managed by a third-party.

Asset-based Methodology

Disclaimer: I worked on a similar Methodology for the Identification of Critical Information Infrastructure Assets and Services when I was at ENISA.

In this first methodology, we present a three-step approach to identify critical assets.

Figure 2. Asset-based methodology

This asset-based methodology is useful to identify the scope in a well-known environment as it reuses existing mechanisms (asset management, risk assessment, supply chain).

One shortcoming is that this methodology does not explicitly integrate the roles and responsibilities involved in the assessment process. Yet, it is important to involve the right stakeholders where and when needed.

Process-based Methodology

Disclaimer: This methodology is suggested by the UK regulator “ofgem” in their guidance to OESs.

The second methodology is a six-step approach that considers business objectives. By doing so, it is visible that cyber security aims to protect the business.

This process-based methodology is a high-level methodology that focuses on business requirements. As such, it can simplify the identification of critical assets. Moreover, some steps directly map to steps from the asset-based methodology.

This methodology still has shortcomings: it requires to perform a business risk assessment a priori; and having an up-to-date asset inventory would be key to successfully perform some steps.

Completeness of the scope

The scoping of the NIS Directive is an important step on the road to compliance. Hence, it is important to ensure the completeness of the scope: i.e. all assets that could cause a risk to the service are in scope.

For that purpose, we presented two methodologies that support the identification of critical assets, how they operate and their dependencies. The NIS Directive considers both “cyber” and “non-cyber” dependencies: Cloud services, power supply, air conditioning, staff, contractors, etc. These dependencies must be in scope when their disruption can affect service delivery.

A successful scoping will involve different stakeholders across the business. It will also go beyond the assets (in isolation or as a group of assets) and integrate how these assets work together and how they contribute to the business to support service delivery.

To refine their scope and ensure its completeness, operators may exchange with their peers on methodologies, good practices and traps. In some cases, competent authorities can also play a role. For instance, they could provide an overview on main critical assets in a sector or establish a list of assets to secure at minima.

Conclusions

The NIS Directive requires the identification of critical assets that contribute to service delivery. This is an important step that will lead to the implementation of appropriate and proportionate security measures to mitigate the risks faced by these critical assets.

We have presented two methodologies for scoping the NIS Directive. To be successful, this scoping must go beyond the identification of individual critical assets and integrate dependencies and business functions.

In the next article, we will discuss on the UK implementation of the NIS Directive, the “NIS Regulations”.

About Cetome

Dr. Cédric LÉVY-BENCHETON is the CEO and founder of Cetome. Cédric has expertise in critical infrastructure, in particular around strategic advisory and the NIS Directive. Cédric previously worked at ENISA, the European Union Cyber Security Agency. Before that, Cédric designed critical networks for public transports.

Cetome is an independent security consultancy. We work with operators of essential services, infrastructure owners and solution vendors to ensure they are ready for the NIS Directive.

We support your NIS Directive journey. We make sure that your activity is secure against cyber risks in compliance with the requirements of the NIS Directive.

Our experts have worked at ENISA, the EU Cyber Security agency, where they directly contributed to the NIS Directive and developed security measures for several sectors in scope.

We have developed our services to help implement appropriate and proportionate technical and organisational security measures as required by the NIS Directive. We follow a holistic approach that goes beyond technical and considers critical assets, third-party suppliers and the staff.

We also provide awareness and training adapted to Competent Authorities, Operators of Essential Services, Digital Service Providers and their suppliers.

About Cetome

Cetome is an independent security consultancy based in London, UK and Lyon, France and operating globally. We work with organisations where security is important and that need to tackle several challenges in terms of resources, capabilities or skills. Most of our clients have an international presence and 250+ staff. At Cetome, we understand the challenges of the NIS Directive its complexity. We work with OESs to help them assess their security posture and implement appropriate and proportionate security measures. Cetome has developed and delivered the only GCHQ Certified Training on the NIS Directive and the Cyber Assessment Framework.

About the Author

Dr. Cédric LÉVY-BENCHETON is the CEO and founder of Cetome. Cédric has expertise in the NIS Directive and OT/ICS security. Cédric previously worked at ENISA, the European Union Cyber Security Agency. Before that, Cédric designed critical networks for public transports.