After looking at the recitals a few weeks ago, here is my feedback on the normative text of the NIS2 proposal:

---

Art. 1(2)(c) [...] lays down obligations on cybersecurity information sharing.

It doesn't just provide obligations, it also provides a legal basis for information sharing. From our perspective, that's even more important than the obligation.

Art. 2(2)(a) the services are provided by one of the following entities:

Overall, the NIS2 is moving from the service-orientation towards a focus on organisations. Here, "service" appears and it looks like a holdover from the old text. There is no clear definition on what "services" are covered by the language in all of paragraph 2, leading to potentially absurd interpretations. e.g.:

Art. 2(2)(a) (i) + (iii)

(i) public electronic communications networks or publicly available electronic communications services referred to in point 8 of Annex I;

(iii) top–level domain name registries and domain name system (DNS) service providers referred to in point 8 of Annex I;

Let's say that an important entity runs a summer vacation camp for its employees that is connected via a small non-profit (e.g., rural wifi) ISP. Internet connectivity and DNS resolution services at that resort is a service of the entity, making the community-run ISP covered by NIS2. Or: the tennis-club of a larger entity is using dedicated server hosted at a data-centre for a few dozens of € per month. It also runs an authoritative DNS server. Thus, it falls under the NIS2 directive.

Art 2(2)(c) the entity is the sole provider of a service in a Member State;

Same thing: To be the sole provider of lemon-soaked paper napkins (to quote Douglas Adams) in a country doesn't make you important. The term "service" really needs a "relevant" or "important" or "essential" in front of it.

Art. 4(4) 'security of network and information systems’ means the ability of network and information systems to resist, at a given level of confidence, any action that compromises the availability, authenticity, integrity or confidentiality of stored or transmitted or processed data or the related services offered by, or accessible via, those network and information systems;

The word "action" can be read as a human doing something. If we look a the statistics collected by ENISA as part of the Art 13(a) reporting, we see that malicious activity has just a minor impact on the availability of the telecommunication services. If we have the CIA triad in mind, we really have to look far beyond "actions", and also have to include "events" or "circumstances".

Art. 4(15) ‘top–level domain name registry’ means an entity which has been delegated a specific TLD and is responsible for administering the TLD including the registration of domain names under the TLD and the technical operation of the TLD, including the operation of its name servers, the maintenance of its databases and the distribution of TLD zone files across name servers;

This fixation on TLDs is counter-productive. For example: nic.at allows the creation of new domains under .at, .or.at and .co.at (the latter being legacy second level domains). I see no reason why the regulation should treat those three parent domains differently from each other.

Art. 5(2) (missing)

National cybersecurity strategies need to address the international engagement and cyber diplomacy aspect, e.g., the standardization efforts of the ITU or the Internet governance by ICANN.

Art. 6(2) ENISA shall develop and maintain a European vulnerability registry.

As I wrote while discussing the recitals, the world does not need a duplication of the CVE database that is run by MITRE. Please cooperate! Start with acting as a CNA, and offer to act as a backup for the main database. We need globally unique identifiers for vulnerabilities.

Art. 7(3) (missing)

Please add a bullet on funding.

Art. 8(3) Each Member State shall designate one national single point of contact on cybersecurity (‘single point of contact’).

Please either restrict the SPoC to a purely administrative function, or just cut it out. It's not needed for operational information sharing.

Art. 9(1) Each Member State shall designate one or more CSIRTs which shall comply with the requirements set out in Article 10(1), covering at least the sectors, subsectors or entities referred to in Annexes I and II, and be responsible for incident handling in accordance with a well–defined process.

The language could be clearer that the union of the constituencies of the set of CSIRTs needs to be a superset of all the sectors. Maybe use something like "covering together at least the sectors, ...".

Art. 10(1)(d) CSIRTs shall be adequately staffed to ensure availability at all times;

This could either mean a 24x7 staffed CSIRT office or just a way to alert an CSIRT analyst who is on a on-call duty. A clarification might be helpful.

Art. 10(2)(a) monitoring cyber threats, vulnerabilities and incidents at national level;

Monitoring can be purely passive, where the CSIRT is just reading OSINT or check their mailboxes for incoming incident reports. Or, it could be active monitoring, going out trying to find vulnerabilities by testing, scanning or probing systems. From our experience as a national CSIRT, active scanning is an important part of the job. I'd prefer if the NIS2 would be clearer on this subject.

Art. 11(3) Each Member State shall ensure that its competent authorities or CSIRTs inform its single point of contact of notifications on incidents, significant cyber threats and near misses submitted pursuant to this Directive.

Just cut out the SPoC from all operational cooperation, and replace it by the CyCLONE officers.

Art. 12(4)(b) exchanging best practices and information in relation to the implementation of this Directive, including in relation to cyber threats, incidents, vulnerabilities [...]

I'm all for the Cooperation Group to talk about best practices, this could also be read as that the CG is the right place to talk about concrete incidents and their impact. Perhaps it should be clearer that the CG's job is not the exchange of operational information.

Art. 13(1) In order to contribute to the development of confidence and trust and to promote swift and effective operational cooperation among Member States, a network of the national CSIRTs is established.

We had a lot of head-ache with this language when formulating the RoP of the CSIRTs Network a few years ago. The problem is that "national CSIRT" is never defined in this document. I wrote a long blog-post about this some time ago. Just drop "national" here, we're defining the membership in the next paragraph anyway.

Art. 13(2) The CSIRTs network shall be composed of representatives of the Member States’ CSIRTs and CERT–EU.

As "CSIRT" is a generic term, this language is too broad. It should be made clear that we're talking about the set of CSIRTs that are introduced in Article 9(1). Additionally, why "representatives"? The CNW is a network of teams, and not just a forum where representatives of the teams can talk to each other.

So perhaps use "The CSIRTs network shall be composed of the Member States’ CSIRTs which are designated according to Article 9(1) and CERT–EU."

Art. 13(3)c at the request of a representative of the CSIRT network potentially affected by an incident, exchanging and discussing information in relation to that incident and associated cyber threats, risks and vulnerabilities;

Isn't that already covered by (b)?

Art. 13(3) (missing)

The CSIRTs Network is also used to share (on a voluntary basis) tools, extensions to tools, processes and documents that members have created. It would be helpful if this would also get a bullet point in Art 13(3).

Art. 14(3) (missing)

The EU-CyCLONe should also take over the operational aspects of the old SPOC, i.e. the forwarding of major incident reports affecting multiple EU member states.

Art. 15(1)b the technical, financial and human resources available to competent authorities and cybersecurity policies, [...]

It would be helpful, if the report does not only provide that information regarding the competent authorities, but also the CSIRTs and the national CyCLONe structure.

Art. 16 Peer-reviews

I support the basic idea of the peer reviews. From what I know, such reviews are already standard practice in the realms of law enforcement. Two points seem to be missing from the article:

• Cost. Who is supposed to cover the expenses?
• Classification. Yes, "the reports may be published" is in 7., but I'm not sure that's a good idea as it is written. I would recommend going for a confidential report to be shared only internally (CG, CNW, EC, ENISA) and a TLP:WHITE version for public consumption.

Art. 17(2) Member States shall ensure that members of the management body follow specific trainings, on a regular basis, [...]

Is "follow a training" the same as "attend a training" (or is it "following the stuff learned during trainings")? While I support the idea behind this point, I'm not sure how that can be implemented and audited? Whose job is it to verify that the CEOs and others possess the relevant education?

Art. 20(1) Where appropriate, those entities shall notify, without undue delay, the recipients of their services of incidents that are likely to adversely affect the provision of that service.

This might be tricky, the qualifier "When appropriate" being really important to make this workable. As we're now expanding the set of organisations covered by this directive, handling the customer notifications becomes really tricky.

Determining the "recipients of their services" is in many cases "whoever might walk through our door tomorrow" (think supermarkets or hospitals). There is no way those entities can do targeted notifications. So how should those cases be handled?

Art. 20(2) Member States shall ensure that essential and important entities notify, without undue delay, the competent authorities or the CSIRT of any significant cyber threat that those entities identify that could have potentially resulted in a significant incident.

We have a problem here. Going back to the definition contained in REGULATION (EU) 2019/881: "cyber threat" means any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact network and information systems, the users of such systems and other persons;

The definition is good, but it's not a good fit here, because it covers generic threats as well. Any competent CISO will always have a long list of threats to the information security of his organisation. Such a list is the basis for risk management and thus essential for steering defensive measures towards optimal results. It's not something that need to be shared to CSIRTs, competent authorities or recipients of services.

What we need here is a different definition. It must be restricted to a concrete event that actually happened. The only thing that can stay in the conjunctive ("might") is the connex to an actual outage. In other words, the risk that someone might have compromised the integrity of an organisation's network is not worth being reported, but the risk that someone from whom you know is inside your networks will cause a disruption, is.

Additionally, we need to make sure that not every entity will need to do a risk disclosure every time a software vendor releases a patch. (Yes, every second Tuesday each month, almost all entities learn about very concrete risks to their infrastructure. Worth reporting? No.)

Art. 20 (6) [...] the competent authority or the CSIRT shall inform the other affected Member States [...]

This is a step in the right direction, though I'd prefer that to be either CyCLONe officer or CSIRT.

Art. 20 (6,8,9) [...] single point of contact [...]

Please remove the SPOC from this operational role. As for 9.: the SPOC does not have (according to this document) the information on all NIS incident reporting, only the cross-MS relevant ones.

Art. 23(1) For the purpose of contributing to the security, stability and resilience of the DNS, Member States shall ensure that TLD registries and the entities providing domain name registration services for the TLD shall collect and maintain accurate and complete domain name registration data in a dedicated database facility with due diligence subject to Union data protection law as regards data which are personal data.

This is utterly misleading. Someone is pushing an agenda which has little to do with the purpose of the NIS directive. Last year I was asked by ENISA staff for my input to a report on the security of the DNS and the questions made it clear that the initiator of that study wanted ENSIA to come to the pre-ordained conclusion that incorrect domain ownership data is the most pressing security issue for the DNS.

No, it is not.

So here we go again. The security, stability and resilience of the DNS depends on the following players:

• The domain owner (registrant). If they lose the credentials for the web-interface of their registrars, then the domain can be compromised.
• The registrar. They act in the name of the registrant, and if they mess up, something might happen to the domain that does not conform to the wishes of the domain owner.
• The registry (and the nameserver operators it contracts). Making sure the correct registration data is kept and made available to recursive nameservers
• The recursive nameservers: run by either ISPs or corporate networks
• The domains of important or essential entities do not depend on whether the registration data for some other domain is correct or not.

This does not mean that accurate and complete registration data would not be helpful in a broader context. Depriving malicious actors a way to register domains under fake names could have positive effects with regards to the level of fraud on the Internet and might improve the overall cyber hygiene.

But the stability of the DNS itself? It just does not matter. Looking at the history of disruptions in DNS operations shows that incorrect whois data was almost never a factor.

Art. 23 [...] TLD [...]

• In the current NIS regime, TLD registries are explicitly mentioned as operators of essential services. I agree with that classification as any disruption at that level has significant impact. But this here is different: we're aiming at the problem that someone might be using a domain without disclosing who he is. Whether that domain is directly under a TLD (e.g., example.at) or one layer down (example.co.at) is completely irrelevant. If you look at the public suffix list, there are many points in the DNS where delegations happen to other organisations. If the point of Article 23 is to prevent the access to domain names without accurate ownership tracking, then the focus on TLDs is just way to narrow.
• What TLD registries are covered? Should these just be the ccTLDs of EU Member states plus .eu? Or should this (similar to the GDPR) cover all registries that cater to the EU market? Is this Article supposed to cover .org and also most of the ngTLDs? It looks like it. See also Art. 24(3).
• Thick versus Thin registries: There are two basic approaches to keeping track of registrant data: Thick registries hold a database with registrant data, thin registries leave this job to the registrars and store only the nameserver and a registrar-ID. Is article supposed to outlaw thin registries in the EU? What does this mean for .com?

Art. 23 (summary)

Summary: I can see a point in making sure that domain registration data is correct. But the way this topic is approached here is not thought through and there is a lot to say that the NIS directive is probably the wrong instrument.

Art. 26 Cybersecurity information-sharing arrangements

This looks fine.

Art. 27 Voluntary notification of relevant information

This should be a bit more generic. This article needs also to cover:

• non-covered entities reporting incidents and vulnerabilities / risks on their side
• anybody reporting incidents / vulnerabilities / risks detected anywhere else.

Why is that important? We used to get a data-feed from Google covering issues with web-pages their crawler detected in the Austrian Internet. They stopped providing this, claiming problems with the GDPR. It would be really helpful if security researchers have a clear green light to report their findings to the national CSIRTs.

---

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.