An update on the state of the NIS2 draft
This is a TLP:WHITE summary of my presentation at the 15th CSIRTs Network meeting in Ljubljana on November 11th. This is not a complete review of the current state of the NIS2 discussions.
Overall, I think the council should abandon the idea of finishing the text this year. There is too much in flux and we all lost sense if the text is still consistent. I recommend publishing a new consolidated draft and get a new round of public comments. We reached the limit of high-speed tinkering with the text.
This blog post may sound negative. That is selection bias, as I primarily write about the things that need changing, not the other parts with which I agree.
Update 2021-11-18: More text on scanning and some links added.
- My blog posts
These are my personal opinions; this is not the official position of Austria. I talk a lot to our representative in the Horizontal Working Party for Cyber Issue. He is the diplomatic one; I prefer to call things as I see them.
Historically, the term "national CSIRT" had a clear meaning: The Default CSIRT of a country, the main liaison point for international relations and the primary info-sharing hub inside the country. This can only be a coordinating / advising CSIRT, it usually has no enforcing powers. Its constituency is the whole country (however that is defined in cyberspace).
NIS1 botched this
- That role is never even implied (The CSIRTs cover only the NIS sectors!)
- An alternative meaning is not defined
- But the term is used in a few places
- After long discussions, the CSIRTs Network kind of agreed that all CSIRTs that are accredited according to the NIS transpositions and that cover at least a NIS sector, are "national CSIRTs"
- The wording caused us many headaches during the ToR/RoP update of 2018.
NIS2 does not fix this deficiency in the text.
- It still contains no definition
- The word is used in Rec. (13), (25), Art. 9, 13
- We managed to fix some of them in the current draft. See below.
Two problems: Gaps in the constituency + unclear usage
"CSIRTs that cover the NIS sectors" turned out to be a problem as a relevant part of the country is not covered by a CSIRT. Our colleagues in the NCSC-NL had serious problems because they are operating for a strictly defined constituency. Whenever they learn of some danger to other Dutch entities, they are forced to sit on their hands instead of reaching out and helping. "Not in their constituency -> No rights to process data"
Austria solved this in the national transposition:
§14 NISG: "(6) CSIRTs can perform the tasks pursuant to para 2 subparas 3 to 5 also with regard to other entities or persons if such entities or persons are affected by a risk or incident in their network and information systems."
- Clean up the language: Use "NIS CSIRTs" for the teams that are accredited according to Article 9/10
- There is value in actually defining the role of a real national CSIRT.
- This can be done analogous to Art 6 (1): "Each Member State shall designate one of its CSIRTs as referred to in Article 9 as a coordinator for the purpose of coordinated vulnerability disclosure."
- Define the tasks for the national CSIRT: act as a coordinating CSIRT for the whole country.
- Decide for all occurrences of "national CSIRT" in the text what definition should actually apply: "NIS CSIRT" or the "national CSIRT".
- Be careful about international collaboration. What are the corresponding teams in third countries? (Yes, we need that collaboration.)
Definition of CSIRTs (Article 9)
On the Commission and Council side, I see no real problem except for the missing national scope (see above). The Parliament went a bit overboard:
"Member States shall ensure the possibility of effective, efficient and secure information exchange on all classification levels between their own CSIRTs and CSIRTs from third countries on the same classification level."
With the broad scope of NIS2 and sectoral CSIRTs operating with small teams, this is completely unworkable. For coordinating CSIRTs, this is also unneccessary.
Requirements and Tasks (Article 10)
Art. 10(1)(d) "CSIRTs shall be adequately staffed to ensure availability at all times;"
What does this mean? A manned team 24x7 on-site or just one analyst on on-call duty? The former proved to be unworkable (just ask NCSC-NL), the latter makes a lot more sense.
Art. 10(2)(a) monitoring cyber threats, vulnerabilities and incidents at national level; and (e) [proactive scanning, language in flux]
We need clearer language on scanning for vulnerabilities. As suitable definition would be e.g.:
"(e) conducting, upon identified operational needs, a proactive scanning of the network and information systems of CSIRT constituency area, including a member state-wide scan, to detect vulnerabilities with potential significant impact, provided [text on safeguards]. An essential or important entity could request a specific scan of their own resources from a CSIRT serving the entity constituency. "
Update 2021-11-18: after a bit more reflection, this is my position on scanning:
For any scanning done on request of the entity we don't need any safety clauses like "no intrusions", "no access", "no negative impact", as these scans basically amount to a light form of penetration test that are done frequently by commercial consulting companies. Such a service usually is done after a "permission to attack" document was signed, which clearly lays out the limits and risks of the activity.
I don't think we need a specific clause in the directive on this. From my PoV, adding something like "on request by a constituent, a CSIRT can assist with proactive security measures" to the list of Article 10 (2) might be helpful. It doesn't have to be scans, it can be a review of a policy/design, some generic consulting, ...It needs to be a "may" clause, because this is open-ended and can consume boundless resources at the CSIRT.
Scanning your constituency for vulnerabilities is a valuable tool for a national CSIRT. We do this every now and then.
Important point to note here: There is little point in doing such scans on demand. We do this because organisations might have missed to install an update. If they have e.g. "ProxyShell" in focus, they can just look at their infrastructure, there is no need to ask the CSIRT for a scan.
So these scans need a legal basis. But now the increased Scope of NIS2 is biting us:
- the number of entities is rising by up to two orders of magnitude
- the CSIRTs don't know who is covered in advance It is thus really hard for a national CSIRT to restrict scanning activities to the "important" and "essential" entities.
What we really need here is the license to scan the whole country.
The international cooperation, as defined in the Presidency draft is very welcome.
Again, the Parliament went overboard:
- 1a. CSIRTs shall develop at least the following technical capabilities:
- (a) the ability to conduct real-time or near-real-time monitoring of networks and information systems, and anomaly detection;
- (b) the ability to support intrusion prevention and detection;
- (c) the ability to collect and conduct complex forensic data analysis, and to reverse engineer cyber threats;
- (d) the ability to filter malign traffic;
- (e) the ability to enforce strong authentication and access privileges and controls; and
- (f) the ability to analyse cyber threats
Phew. "Ability to filter malign traffic" for a real national CSIRT? That is very thin ice. "Enforce" anything? That might work for a GovCERT, but never ever for a coordinating sectoral one.
CSIRTs Network (Article 13)
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.
Drop the "national" here, please.
Art. 13(2) The CSIRTs network shall be composed of representatives of the Member States' CSIRTs and CERT-EU.
Representatives? This is not the Cooperation Group where "composed of representatives of Member States" makes sense. The CNW is more than just the meeting of the representatives three times per year. So drop "representatives" here. Our teams are the members, not just the liaison officers. We talked about the need for a broad participation of the teams at the meeting in Ljubljana.
Which CSIRTs? NIS (see Art. 9), the national one, or any CSIRT? I think a reference to Article 9 is the correct answer and is what we use right now in the CNW ToR.
The Presidency changes (ba) [Sharing Publications & Recommendations] and (bb) [Sharing Tools] are good.
Scope of NIS2
The scope of the NIS2 was a major part of the discussions in the council. I don't worry about the details regarding important vs. essential entities, I worry about:
- Scale: the pure number of entities. Probably a factor 20 to 50 over the NIS1 numbers
- Our tasks, e.g. EP: "(c) responding to incidents and providing assistance to the entities involved;"
If you see the CSIRTs as hands-on entities that are involved in on-site incident response in their constituency, then this role will not scale with the proposed numbers of organization. I see little chance that the NIS CSIRTs will cover all the Incident Response capability that all the important/essential entities will need, as this would close to monopolize that job in an EU member state. Thus, the logical conclusion is to reduce the hands-on part of CSIRTs as the size of the constituency increases. The extreme point is the role of the national CSIRT, which is purely a coordination and info-sharing function.
Voluntary Reports vs. CVD
I still think that the voluntary reporting is more important than the mandatory one. We are way too new to the whole NIS thingy to be able to say how this will really work out. The identification of all OeS just finished here. Give it time to develop.
Be careful when transposing: Reports can be about other people's systems, which is a special case of Responsible Disclosure. Example: "Dear CSIRT, I spotted the following bug in the website of company X, please help getting this fixed." We messed up in Austria on our NIS1 transposition, our law says "(2) Entities which have not been identified as operators of essential [...] can submit notifications of risks, incidents and security incidents concerning them to the competent CSIRT [...]". We should have left out the two words "concerning them".
So what really is the difference between the coordinated vulnerability disclosure (CVD) and a voluntary report on a weakness in an online service? In first case, the bug is in the software itself, whereas in the latter the mistakes might also have been in the configuration or deployment of the software. As we are moving from the distribution of software via physical media in shrink-wrapped boxed to online distribution (including automatic updates) and Software-as-a-Service (Google Docs, Salesforce, (parts of) Office 365, so is the process of dealing with vulnerabilities changing. The world of software licensing is also making this switch, see e.g. the move from GPL2 to the GNU AGPLv3.
I really think we need to re-examine what this evolution of software / services implies for the distinct NIS2 concepts of coordinated vulnerability disclosure, voluntary reporting, network scanning (Article 10(2)(e)) and the job of a truly national CSIRT.
The idea here is sound: do not just report actual outages, but also report when something bad is really close to happening. We had such a case recently in Austria: an OeS discovered an APT like intrusion into their systems. It took them about half a year to finish the incident response process to clean their network. The attacker caused no outage at all. Thus, according to our NIS law, the mandatory reporting requirement never triggered. (In this case, a voluntary report was submitted.) Nevertheless, it felt wrong that having someone inside an OeS with the capability to cause mayhem is not enough to trigger a mandatory report. Based on that thinking, it makes sense that the NIS2 draft also wants reports on threats:
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.
If you trace the citations, you arrive at the following definition: "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;
Whoopsie. This is way too generic. Ransomware is a "significant cyber threat" to basically anyone running IT systems. So is the discovery of a 0-day vulnerability in an Internet-facing service. Anyone who isn't aware of a "significant cyber threat" to his/her own organization messed up their risk assessment. It looks to me like the drafters hoped that adding "significant" would be enough, but in my opinion, this does not suffice. "significant" is doing too much heavy lifting here.
To be on the safe side, entities need to report their risk assessment (e.g. done as part of their ISO 27001 certification) to the CSIRT. Additionally, this definition triggers on any non-trivial change of the IT setup: those have the nasty property to cause outages every now and then. Yes, we CSIRTs certainly want to see Cc of non-standard changes according to ITIL processes in our constituency. Not really. And then there are the patch cycles: hardly any Microsoft patch Tuesday fails to deliver a critical update. "Significant Cyber Threat" until patched? Oh yes. And Art. 20(2) triggers and the CSIRT should get a report from all Microsoft customers in the constituency.
The language needs more precision here.
Domain Name System Scope
The points on whois access are good.
Looking at the provisioning and the resolution side makes a lot of sense (from Presidency draft).
But the Scope?
- Root Nameservers? That is a highly political minefield. Demanding security precautions from them is sensible, but enforcement is not possible for most of them. The most I can envision is a reference to some global standard (optimally set by ICANN) and delegate oversight to the respective national bodies from where the operators' headquarters are.
- TLDs? European ccTLDs are easy, but what about .com? nGTLDs? ...
- Are we aiming for a global enforcement like with the GDPR? If yes, this needs a very public discussion.
- What about other public suffixes? E.g., gv.at, gov.ee, com.es, ...
DNS Registration Data (Article 23)
1. For the purpose of contributing to the security, stability and resilience of the DNS, Member States shall ensure that TLD name 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 in accordance with Union data protection law as regards data which are personal data.
This statement on the purpose is either a bald-faced lie, the result of ignorance about the DNS, or a sleigh of hands in order to insert someone's pet policy objective into the NIS2 directive. Or all three at once.
Someone has an agenda. And it is not the security, stability and resilience of the DNS. It may be phishing, spamming, business email compromise (BECs) or other cyber-crime topics. The DNS itself doesn't care about the correctness of domain ownership data just as roads don't care about license plates of cars.
The Cooperation Group tasked ENISA to write a report on "DNS Stability" declaring that incorrect registration data is the most pressing issue for the functioning of the DNS. It is not. According to the last draft I have seen, the document only quotes a Centr doc on current practices of some TLDs. I worry that that will morph into a hard requirement.
The impact of incorrect whois data is far away from the goals of the NIS directive. The E-Commerce directive would be a much better fit for the topic. We've been hijacked. This reminds me of 1995, when the EU passed telecom surveillance policy via the fishery council.
This is utterly ridiculous.
The scope, overall effect and the un-intended side effects have not been thought through at all.
Just as with the basic scope of NIS2, it is not clear which registries (and the associated registrars/resellers) are covered by this article. Is this by home country? By target audience? Is this supposed to be like the GDPR and establish a global requirement for global services?
In the case of .com, this has another effect. It is a "thin registry", meaning that the registry itself does not contain any information on domain owners. It only stores NS, DS, glue records, the sponsoring registrar and some metadata. What do the requirements of NIS2 mean for such a system? Either change to a thick model, or include the distributed whois databases of all .com registrars.
How do you guarantee "accurate"?
Even if a registry wants to implement this, how is it going to do that? eID doesn't even really work across the EU. This is a global market. How can one verify a domain owner from other continents?
This might somehow work for certain TLDs, which have historically targeted a very specific set of customers, e.g. a few select ccTLDs (.dk, .fi, ...) or sponsored gTLDs (e.g., .aero, .travel). The vast majority of TLDs do not restrict the ownership of domains at all.
Can the registries completely push this requirement on registrars? How big is the scope there? According to the ICANN website, we are talking about 2497 ICANN accredited registrars. Not all of them target the EU market. Are they in scope, because .com has a big business in the EU and a thin registry?
According to Centr, there are currently 69 Million ccTLD domains in Europe; the global market is around 317 Million domains.
How are the registries supposed to verify those? What is the transition/grace period? Has anybody done a cost estimate? Isn't there a legal requirement to do this when you propose a legislation? Ok, there is a "LEGISLATIVE FINANCIAL STATEMENT", let's have a look: ... impact on DG CNECT ... EU Budget ... ENISA. And that's it.
If the commission thinks that this verification is only for new domains, then it should bloody well write it into the directive. If it thinks that this could be done during the domain renewal process, then this reveals yet another level of ignorance about the European domain market.
All this will have a major effect on prices and friction, and thus the competitiveness of the EU domains in a global market.
Domains are just one form of online names that are delegated to customers by some sort of registry. We have just as much trouble with Social Media accounts, Cloud service accounts (Cloudflare is very popular by miscreants right now), Webspace, IP-address ownership, email addresses, ...
The common denominator with regard to ransomware (the top threat in 2021 according to ENISAs threat landscape report) are crypto currencies. Not invalid domain registrations.
The legislators are barking up the wrong tree. Dealing with network abuse is certainly an interesting topic. This needs a fine balance of minimal friction in business versus restrictions to deter and/or stop abuse. This needs the threading of a fine needle. Not a broadsword to one singular network resource.
First, we need a real problem statement. You cannot develop policy without first clearly laying out what problem a legislation is trying to mitigate (Case in point: the JCU). Then you can start to think of remedies and start drafting laws.
This is how I see it:
- We need to be able to deal quickly with network abuse
- That needs clear guidance on who can act under what circumstances against a network resource
- Right now, the Austrian law enforcement does not have the right tools
- Whether the owner of that resource has been properly verified must matter when dealing with a misuse of that resource
- There are examples. E.g. how CH reacts to domain abuse
Nevertheless: this is not a topic for the NIS directive.
See also the Blog post from the Internet Society.
Encryption (Recital 54)
For god's sake. Don't start to re-litigate the crypto wars of the 90's. It's over. That horse is dead.
The EP got it. "However, this should not lead to any efforts to weaken end-to-end encryption, which is a critical technology for effective data protection and privacy." is the polite way of saying that the preceding sentence on "reconciling encryption with LE needs" is bullshit.