Our society relies on the availability, security and reliability of network and information systems (NIS). Various security frameworks provide standards and guidance as to which measures organizations should implement to protect IT systems and increase resilience. However, since such recommendations are not ingrained as actual laws in most countries, these best practices and guidelines are often followed solely on a voluntary basis.

This is contrary to the European Union (EU)’s NIS Directive; a legislation that sets a range of network and information security requirements to augment IT security across all EU member states. While the directive covers a few different domains, including preparedness, cross-EU collaboration and incident response (IR), one of its main pillars focuses on breach notification requirements.

In this post, we will focus specifically on the aspects of incident notification contained in the NIS Directive as they apply to operators of essential services (OES).

Regulations Versus Directives

The NIS Directive is a different type of legal act compared to, say, the General Data Protection Regulation (GDPR). The latter is immediately applicable and enforceable by law in all member states. A directive is somewhat different.

While it also applies to all member states, instead of being immediately applicable, it sets goals, requirements and results that must be achieved. It is then up to each member state to devise its own laws on how to reach these goals and what types of penalties noncompliance will carry. The NIS Directive also sets a floor. There can be greater requirements applicable based on the organization’s industry sector and member state(s) it operates in.

This legal status reveals one of the possible issues with a directive: Whereas a regulation is direct law, a directive needs to be transposed into local laws by each member state. These transpositions can result in differences in the implementation of the directive into law, in some cases complicating matters for organizations that operate across borders.

Variance in Incident Notification Definitions

One of the articles in the NIS Directive that has received a lot of attention is Article 14, which outlines requirements for security and incident notification. It stipulates that member states must ensure that OES notify the national competent authority and the national computer security incident response team (CSIRT) in case of an incident that significantly impacts the continuity of an essential service. This is not entirely new — depending on the type of activity or sector, there are already requirements for incident reporting in Europe, including Article 13a of the Telecom Framework Directive.

An additional element of complexity is that, according to Article 5, the identification of OES per sector needs to happen individually within each member state. Although organizations might give input to this process, the actual identification is out of their hands. This process is another way by which the directive could result in various interpretations that end up adding complexity.

The Benefits of Incident Notification

One of the drivers for notification in the context of the directive is to be compliant with legal requirements. However, if the starting point of your organization is to only comply with the bare minimum of these notification requirements, then you will miss out on the opportunities provided by the directive.

Additionally, the bulk of these requirements, including notification and detection capabilities, should already be covered in large part by your existing security environment. If this is not the case, you can use the NIS Directive as a wake-up call to improve your security posture.

From a policymaker’s point of view, the notification requirements can help better identify the challenges within a sector and propose mitigation measures that are based on actual facts and figures. These facts and figures can then be used by CSIRTs (or a responsible authority) to provide more relevant warnings and situation reports together with sector-specific threat intelligence. Similarly, this information can also be used to evaluate cross-border impact of incidents or threats and optionally notify other member states.

Breaking Down Notification Requirements

Now, let’s dive into some details of the NIS Directive. There are essentially three main parts to the notification requirement.

First, prior to notification, organizations need to be able to detect security incidents — i.e., they must possess appropriate detection capabilities. The second part involves defining what a significant incident is and what risks, either directly or indirectly, can have significant impact on an essential service. The last part of the notification requirement involves understanding when, what, how and to whom organizations must report incidents.

First Things First — Detection

Every notification starts with proper detection of an incident. You can find guidelines on detection capabilities in a reference publication from the NIS Cooperation Group on security measures.

The core principles for these security measures include being effective, tailored, compatible, proportionate, concrete, verifiable (evidence of the effective implementation of security policies) and inclusive (includes all security domains that may contribute to reinforcing cybersecurity).

Applying NIS measures to the domain of detection and resilience can be done by:

• Setting up a detection system to analyze files and protocols — this can include, for example, network intrusion detection systems (NIDSs) or malware sandboxes;
• Enabling logging on critical systems (log entries should include time stamps);
• Collecting the logs centrally; and
• Conducting log correlation and analysis on the events coming from critical systems.

All of the above actions can also be automated with a security information and event management (SIEM) solution.

After Detection — Defining Incidents

But what, exactly, is a security incident? Article 4 defines it as any event that has an actual “adverse effect” on the security of network and information systems. As a side note, the directive does not include a definition of what is covered by “adverse.”

Based on the information from the NIS Cooperation Group, we can combine the definition of an incident with the definition of security of network and information systems. This would redefine an incident to be any event that affects the authenticity, confidentiality, integrity or availability of network and information systems, and has a significant impact on the continuity of the essential service itself.

What Is a Significant Incident?

A set of three parameters from Article 14 of the NIS Directive can be used to determine what is considered a significant incident:

• The number of users that are affected by the disruption of the essential service.
• The duration of the incident.
• The geographic spread of those affected by the incident.

Additionally, the parameters from Article 6 are also helpful in defining what qualifies as a significant incident:

• What is the dependency of other OES on the service affected by the incident?
• What is the impact (degree, duration) on economic and social activities or on public safety? In particular, the impact on social activities can be hard to measure for OES.
• How large is the market share of the affected service?
• What is the geographic spread that could be affected?
• How important is the affected element for maintaining a sufficient level of service?

In general, these parameters are most often already included in what OES are accustomed to using to define crises within their services that are unrelated to IT.

The actual criteria, thresholds and parameters for determining substantial incidents are defined by member states. This can include the parameters defined in the NIS Directive, possibly extended with other states or by sector-specific criteria.

The Directive’s Notification Timeline

According to Article 14, organizations need to notify without undue delay, although this timeline can be shortened or specified based on the member state. The term “undue” can also be subjective, but in most cases, this means the organization must send a preliminary notification whenever an incident is first detected, even if all the details are not available yet. The goal is to raise awareness. As your investigation progresses, you can provide intermediate follow-ups, and when the incident is closed, you can provide a full report.

It’s fairly simple to implement this step. Your IR plan should already include a notification and escalation path for certain types of critical incidents during the detection and analysis phases. It should also foresee a final incident report as part of the lessons-learned phase.

In essence, this requirement is an extension of an already established IR plan and recovery process.

Where to Report?

Each member state is free to choose its own reporting framework. This can be the national authority, sectorial authorities or a combination of both in addition to notifying the national CSIRTs.

As an organization, it is important to identify to whom you have to report, exchange contact details between your security team and the notification body, and establish and test this communication process.

Use the NIS Directive as an Opportunity

Similar to the GDPR, you can approach this directive as a roadblock or a nuisance, or you can consider it an excellent opportunity to improve your security posture. The fact that some security requirements are legal requirements can help you further establish your security program.

There are many articles in the directive to take into account, but you should start by focusing on the following:

• Article 4, which defines a security incident;
• Article 5, which mandates that member states should identify OES;
• Article 6, which sets additional parameters to define significant incidents; and
• Article 14, which requires you to implement security measures and notification processes. This article also contains the three base parameters to define what is a significant incident and describes the accepted delay for notifications.

Unfortunately, despite the fact that the bulk of the NIS Directive has been well-known for quite some time, not all EU member states have finalized the phase of transposing the recommendations into actual laws.

If this is the case for your environment, you might benefit from the situation and provide your lawmakers with input for security measures that would actually improve the level of security for network and information systems in your sector.