Introduction

The original EU cybersecurity blueprint from 2017 (officially: “Commission Recommendation of 13.9.2017 on Coordinated Response to Large Scale Cybersecurity Incidents and Crises”) is now close to seven years old and an update is overdue. The Commission recently published a draft for an updated version, and I’d like to take this opportunity to publish my feedback to this text.

Overall, this is good document, both readable and quite short. As it is full of references to other EU documents, it would really benefit from a consistent use of hypertext links in the text. There are some URLs in the footnotes, but not all are actually active, clickable links in the pdf version. Having the links directly in the main text might not be standard in EU documents but would make reading the document in its digital form more accessible.

DNS/Cloud

Recital (16) and points (15) and (16) single out DNS resolution capabilities as a critical technical dependency. Yes, DNS resolutions is important, but it is by far not the only one. DNS4EU might be a worthwhile EU initiative, but that should not elevate it to a critical component in the EU cybersecurity blueprint.

Other dependencies worth looking at are the Internet’s routing infrastructure, including the mechanism for securing BGP, the authoritative side of the DNS, content delivery networks (CDNs – where some services claim to serve significant portions of the global content), large e-mail operators and the hyper-scaler IaaS/PaaS/SaaS cloud services. The singular focus on DNS resolution is not warranted. We shouldn't just talk about the dependency where we have an EU alternative in place.

Triggers for large-scale incidents

The text is not really explicit about this, but it reads like it implicitly assumes that malicious technical cyber operations will be the cause for large-scale incidents. In other words, some sort of illegal access to computing resources in the EU (or a denial-of-service attack) with either hacktivist, criminal or political motivations. I think this is far too narrow.

One of the basic ways of looking at cyber security is the C-I-A triad: Confidentiality, Integrity and Availability. And the latter is not only threatened by “malicious hackers”, but mainly (if one looks at NIS 1 mandatory reporting) by bugs, mistakes of operators, flooding, backhoes + anchors, failing disks, power outages, and dozens of other reasons for IT Oopsies. The incident from July 2024 where a CrowdStrike EDR update crashed 8.5 million systems worldwide, is a good example. As a thought experiment: assume that a similar error results in a more sustained downtime or even data loss: would the blueprint be applicable?

Another possible trigger for a large-scale incident could be supply chain issues. Here EU documents usually only think in terms of the SolarWinds incident of 2019/20 or the trustworthiness of certain categories of vendors (see the 5G toolbox). In focus are network intrusions caused by security problems by managed service providers, by business partners, by vendors, or outsourcing partners. We sometimes forget about the most basic of supply chain issues: not being supplied any more.

Supply chain disruptions in the software business used to be long-term issues: maybe the supplier cancels the product, and you must transition to another one, or there might be issues with updates and security fixes. In the age of online license checks and Software-as-a-Service delivered via the cloud, any disruptions on the side of the vendor can have immediate effects on all his customers. That all assumes that the vendor is acting freely, but this assumption might be wrong: in the case of geopolitical tensions, other forces might trump the will and the interests of a vendor. There might be sanctions, there might be secondary sanctions, there might be sudden export restrictions, and, in the case of hardware supply, there might be disruptions in the production.

Not all of these cases will be something where the CSIRTs (or commercial incident response companies) can ride in to save the day, some of these cases will be highly political and will require a solution on that layer. Better yet, these cases need to be considered long before the crisis hits. Sometimes I think that “rely completely on US cloud providers” is the 2025 version of “buy natural gas exclusively from Russia”.

High-risk vendors

In recital (18), “high-risk suppliers” is only used in the context of “vulnerabilities have to be disclosed for state use”. This is one-dimensional thinking. Suppliers can be high-risk because they are a monopoly and can thus raise prices without market considerations. Others may become a pawn in geopolitical power-plays.

Secure Communication

As recital (23) states, communication can be a key component in handling a crisis. But we don’t need yet another bespoke solution for the EU entities and their national partners, we need something where we can also add the private sector to the communication, as they are the ones who run most of our digital infrastructure. Insofar, recital (24) is correct: we need to think not in individual silos. Instead, the crisis communication and response need to bridge between them.

The idea from point (30) to use Matrix as a technological base is a good one. One word of caution, though: we cannot continue to use Open-Source software and only think of deployment costs, we also need to reserve funding for the development and maintenance of the product itself. For example, when switching from the commercial version of Mattermost to Matrix, one should redirect a considerable fraction of the no longer needed license fees to support the Open-Source project.

Situational Awareness

II(6) is a bit too much focussed on technical part of the situational awareness. A complete threat assessment also needs to factor in the motivation, capabilities and intentions of possible adversaries. This is something I hear often from the private sector: they are mostly satisfied with the technical CTI available to them, but they lack the strategic intelligence on potentially adversary actors ranging from hacktivists, organized crime up to state actors. Point (23) is well taken, but what about the commission’s own cyber situation centre? What value can that provide to the aggregated situational awareness of all actors?

Taxonomy

To be honest, there are already too many proposals for incident taxonomies out there. Doing yet another iteration is unlikely to improve the situation. Where a common taxonomy is really missing in practice is a unified severity scale.

Responding to a cyber crisis

Point (25) is the core of the document.

(a) is fine, it correctly defines the role of the CSIRTs Network.

I have issues with (b): it should be the sole responsibility of EU-CyCLONe to provide information about the impact of an incident to the political layer. Its members are the national cyber crisis coordinators, they should have the national impact assessments and can aggregate those within their network. The CSIRTs are focussing on the technical, purely cyber parts of the incident. The aggregation of this technical information in the CSIRTs Network talks about intrusion vectors, vulnerabilities, indicators of compromise, affected IT systems, mitigation measures, and expected time to restore. This is the information that the CSIRTs Network will share with EU-CyCLONe.

Crisis Management

The text is a bit thin on the actual crisis management processes used across all actors. For example: I assume that the national CSIRTs will operate under the direction of their respective national crisis centres. Their main reporting requirements will be there and decisions by the national crisis manager will have precedence to any request coming in from the CSIRTs Network.

Or: how much will EU-CyCLONe act as the crisis coordinator for the CSIRTs Network? My assumption here is “not at all”, instead I expect that requests from EU-CyCLONe will first go to the national cyber crisis coordinator who will, if sensible, instruct the national CSIRT accordingly.

In other words, crisis management needs clear responsibilities and chains of command; a simple “everybody should cooperate” is not enough. This blueprint should be clearer on the questions whether those chains of command are on the national side or on the EU side.

EU Cybersecurity Reserve

There is no need to describe the SLA of the reserve in this text, point 26(a) should be removed.

A statement on the information flow triggered by the deployment of the reserve would improve the document.