The EU commission dropped a large cyber security package on December 16th 2020, including a first draft for a new version of the NIS Directive.

In front of the actual normative legal text, there are 84 recitals, describing the intents of the regulation. I’ve now read through them and this blogpost is my first reaction (not the official position of CERT.at) to that proposal.

I haven't really looked at the normative text yet, feedback to that will come in another blogpost.

I’ll quote some bits from the recitals of interest and comment on them.

(8) Uniform size minimums for essential entities across the EU

This might be suboptimal, as the importance of entities must be seen in relation to the size of the MS. (9) tries to mitigate this somewhat, but doesn’t define how small or micro entities from (9) need to be notified, too.

(12) Sector-specific legislation and instruments can contribute to ensuring high levels of cybersecurity, while taking full account of the specificities and complexities of those sectors. […]

Under the current NIS framework in Austria, it is possible that sectors define their own national security baseline and have that approved by the competent authority. Continuity for such setups is essential.

(13) bringing the finance sector into the NIS framework

This is a positive development, and might stimulate the establishment of a national CSIRT for the financial sector.

(15) Therefore, this Directive should apply to all providers of DNS services along the DNS resolution chain, including operators of root name servers, top-level-domain (TLD) name servers, authoritative name servers for domain names and recursive resolvers.

This is wrong on two counts:

• All authoritative and recursive name servers is way too broad. Many people run recursive nameservers on the CPE connecting their home network to the Internet. Any server deployment might contain a recursive nameserver. My own private server runs the unbound program for that purposes. On a typical Linux box, installing that service is a one-line command, and I guess that for Windows Server a single ticked checkbox might do the same.
  
  Your personal computer should not fall under the NIS directive just because of that.
  
  On the authoritative side, a good number of small enterprises, schools, associations, and private persons run their own authoritative name server. Again, this is really trivial to do. And this is one of the really good design points of the Internet: Running services is democratic, you don’t need to be a big organization to run your own DNS, Mail, or Webserver.
  
  Additionally, it is valuable for the resilience of the Internet as a whole that the DNS is run not only by a handfull of large players. The protocol supports redundant servers by design, it make a lot of sense to use those features.
  
  
• The resolution chain is only one side of the DNS ecosystem. Equally important is the provisioning side, where domain owners ask registrars to create/change/delete delegation data at registries and provision resource records into their own zones. Over the last years, we’ve seen at least as many security issues on the provisioning side as on the resolution side.

I fully understand that important name-servers need to be covered by the NIS Directive. But there are many pretty irrelevant ones out there as well.

(22) In order to facilitate cross-border cooperation and communication among authorities and to enable this Directive to be implemented effectively, it is necessary for each Member State to designate a national single point of contact responsible for coordinating issues related to the security of network and information systems and cross-border cooperation at Union level.

(23) The single points of contact should be tasked with forwarding incident notifications to the single points of contact of other affected Member States.

The SPOC has always been the bastard child of the NIS directive. Its job description mixes policy issues “responsible for coordinating issues related to the security of network” with very operational jobs like “forwarding incident notifications”. Its implemention varies a lot between MS. There is no public directory of SPOC contact addresses (this is a joke). There is no clear definition on response times and service levels.

• We have a cooperation mechanism on the technical layer: the CSIRTs Network.
• We have a cooperation mechanism on the policy layer: the cooperation group.
• We’re establishing a cooperation mechanism on the operational layer: the CyCLONe.

I think the problem arises as the incident reporting is neither uniformly to the CSIRTs (which would make sharing in the CNW ideal) or the NCAs (which are all part of the cooperation group). Thus they had to invent that virtual role of the SPOC to patch up the differences in the MSs’ NIS implementations.

With NIS 2.0, it is really time to fix this for good. My preferred solution is this: 

• As long as the reporting did not trigger a national alert, reports should only be shared via the CSIRTs Network
• If there is any escalation based on the report (or if a significant cross-MS effect is possible), then the CyCLONe should be activated.
• All policy questions between MS should be handled by the cooperation group (or the HWP Cyber).

Alternatively, the new consolidated reporting portals can implement cross-connects, making lateral passes between Member States a lot easier.

So just kill the SPOC role. It only complicates things.

(26) Given the importance of international cooperation on cybersecurity, CSIRTs should be able to participate in international cooperation networks in addition to the CSIRTs network established by this Directive.

Yes. This is really needed.

(28ff) Since the exploitation of vulnerabilities in network and information systems may cause significant disruption and harm, swiftly identifying and remedying those vulnerabilities is an important factor in reducing cybersecurity risk. Entities that develop such systems should therefore establish appropriate procedures to handle vulnerabilities when they are discovered.

I fully support that we bring vulnerability disclosure into the NIS fold. There are a few points in the text where I see room of clarifications and improvements:

• “products” vs. “services”. Here I have a flash-back to the GPL 2 to GPL 3 evolution: The GNU Public Licence used to be all about software and its properties once that software is changing hands. As the software you use started to run not only on your own computer, but might run on someone else’s server where you interact via some network client software (e.g., a Web-Browser), the legal framework covering open-source software had to change.
  
  It is thus necessary that the NIS-D also makes the transition. The use of the “product or service” language is appropriate and a step in the right direction. It shouldn’t be just “Entities that develop such systems …”, but also “Entities that operate such systems …”
  
  
• Once we are moving from software (whether sold shrink-wrapped, open source, sold online or bespoke) to the (online-)services provided by software, then a vulnerability might not only be a classical bug in the source code, but could also be a mistake in the operation of that software. A configuration mistake can have the same security impact as a bug in the software. It is thus necessary to take a more expansive view on the vulnerability handling and mitigation process. CERT.at has been busy for years providing operators of vulnerable services with information about obsolete software, about misconfigurations and other operational errors. Having that effort as an official task according to the NIS Directive is welcome. Nevertheless, there are clear differences to the vulnerability disclosure process for software. The text should be evaluated from that perspective, too. (e.g. w.r.t. to a vulnerability registry)

All this needs more refinement.

(31) Although similar vulnerability registries or databases do exist, these are hosted and maintained by entities which are not established in the Union. A European vulnerability registry maintained by ENISA would provide improved transparency regarding the publication process before the vulnerability is officially disclosed, and resilience in cases of disruptions or interruptions on the provision of similar services. To avoid duplication of efforts and seek complementarity to the extent possible, ENISA should explore the possibility of entering into structured cooperation agreements with similar registries in third country jurisdictions.

The world does not need a duplication of the CVE system. Mitre, who handles the CVE registry has for years tried to get other entities to provide CVE registration services. This is the way to go.

(35) The competent authorities and CSIRTs should be empowered to participate in exchange schemes for officials from other Member States in order to improve cooperation.

This is a good point.

(36) The Union should, where appropriate, conclude international agreements, in accordance with Article 218 TFEU, with third countries or international organisations, allowing and organising their participation in some activities of the Cooperation Group and the CSIRTs network.

Yes. This was on my wish-list for NIS 2.0.

(42) Essential and important entities should ensure the security of the network and information systems which they use in their activities. Those are primarily private network and information systems managed by their internal IT staff or the security of which has been outsourced.

Yes, these entities run internal IT systems. Increasingly, those are interconnected and have external interfaces to customers, business partners, suppliers and public entities.

Additionally (also covered in (44)), I find the focus on MSSPs to be strange. In terms of the overall security of entities, all outsourcing partners with administration level access to the IT systems are important. We have seen a string of reports in 2019 covering breaches in important entities caused by compromised MSPs (Managed Service Providers).

(47) The supply chain risk assessments, […]

The word missing here is “digital sovereignty”.

(48) In order to streamline the legal obligations imposed on providers […]

This is very much needed and welcomed.

(50) Given the growing importance of number-independent interpersonal communications services, it is necessary to ensure that such services are also subject to appropriate security requirements in view of their specific nature and economic importance.

Bringing in the worlds of iMessage, WhatsApp, Skype, Duo, Messenger, Signal, Threema & co into the folds of the NIS directive is a positive step. The language in recital (50) is a bit unclear, as the actual identifier used to address communication endpoints is not the relevant criterium. To make this a bit better, one should specify clearly that the numbers we’re talking about are E.164 phone numbers, and we want to address those interpersonal communication systems that are not covered by the telecom regulation (via which they can get allocations of E.164 numbers).

It has been my longstanding opinion that the over-the-Internet interpersonal communication services that reached significant market share should be covered by regulation similar to the one that covers legacy telephone systems, especially with respect to interconnection requirements. A good number of the current issues regarding market power, privacy abuses and anti-competitive behaviour of these players are actually pretty similar to what transpired in the pre-liberalized phone ecosystem.

(53) In particular, providers of public electronic communications networks or publicly available electronic communications services, should inform the service recipients of particular and significant cyber threats and of measures they can take to protect the security of their communications, for instance by using specific types of software or encryption technologies.

This should also apply to vendors or devices and software that service recipients use to connect to those communication networks.

(54) […] Solutions for lawful access to information in end-to-end encrypted communications should maintain the effectiveness of encryption in protecting privacy and security of communications, while providing an effective response to crime.

This sounds good in theory, but there is no information here how these contradictory goals can be both achieved at the same time. This needs to be resolved (although the NIS Directive is probably not the right place for that).

(55) This Directive lays down a two-stage approach to incident reporting in order to strike the right balance between, on the one hand, swift reporting that helps mitigate the potential spread of incidents and allows entities to seek support, and, on the other hand, in-depth reporting that draws valuable lessons from individual incidents and improves over time the resilience to cyber threats of individual companies and entire sectors. Where entities become aware of an incident, they should be required to submit an initial notification within 24 hours, followed by a final report not later than one month after.

The basic premise is a good one, we need both the quick heads-up and the detailed reporting. Just be aware that it is not uncommon for larger incidents to take more that a month from detection to remediation. In such cases the “one month after start of the incident” might be too early. My suggestion is to require monthly updates and a full report no longer that one month after the resolution of the incident.

(56) Essential and important entities are often in a situation where a particular incident, because of its features, needs to be reported to various authorities as a result of notification obligations included in various legal instruments. Such cases create additional burdens and may also lead to uncertainties with regard to the format and procedures of such notifications. In view of this and, for the purposes of simplifying the reporting of security incidents, Member States should establish a single entry point for all notifications required under this Directive and also under other Union law …

This is a really good idea and this is something the regulated entities have been requesting.

(59) – (62)

A clearer regulation regarding the requirements on the data-quality for and the access rights to the domain ownership information is welcome. Be careful regarding the definition, though: Top-Level Domains are not the only levels in the DNS where delegations to end-users can happen. See e.g., in Austria the “gv.at” or “co.at” Second Level Domains. The distribution of work and responsibilities between registries and the registrars need to be worked out as well. In the case of Registries under ICANN rules, the set of requirements need to be reconciled.

(60) […] CERTs, (CSIRTs,

Is this just a typo, or is this an indication that non-NIS accredited security teams should also have access to whois data? See also (69).

(69) The processing of personal data, to the extent strictly necessary and proportionate for the purposes of ensuring network and information security by entities, public authorities, CERTs, CSIRTs, and providers of security technologies and services should constitute a legitimate interest of the data controller concerned, as referred to in Regulation (EU) 2016/679. That should include measures related to the prevention, detection, analysis and response to incidents, measures to raise awareness in relation to specific cyber threats, exchange of information in the context of vulnerability remediation

As with (28ff), “vulnerability remediation” needs to also include configuration errors and similar operational errors. The list at the end of (69) cannot be exhaustive, we need a more generic definition of the relevant data types.

(76) In order to further strengthen the effectiveness and dissuasiveness of the penalties applicable to infringements of obligations laid down pursuant to this Directive, the competent authorities should be empowered to apply sanctions consisting of the suspension of a certification or authorisation concerning part or all the services provided …

A few comments here:

It’s one thing that sanctions are possible against the operators of improperly secured services, but in some cases, they are not the ones to blame, but the vendors they are relying on did not due diligence to make sure their software, hardware or services deliver the promised level of security.

I’m missing here the tie-in to the security certification framework contained in the EU Cybersecurity Act.

(79) A peer-review mechanism should be introduced, allowing the assessment by experts designated by the Member States of the implementation of cybersecurity policies, including the level of Member States’ capabilities and available resources.

This could be helpful.

Overall, the NIS 2.0 proposal is a step in the right direction.

This blog post is part of a series of blog posts related to our CEF Telecom 2018-AT-IA-0111 project, which also supports our participation in the CSIRTs Network.