The new European toolbox for cybersecurity regulation

Nils Brinke

The European Union (EU) is proactive in establishing regulations for cybersecurity. Initiatives such as the Cybersecurity Act of 2019, the Cyber Resilience Act, and the NIS2 directive have been implemented. The Cybersecurity Act formalizes the EU Agency for Cybersecurity’s mandate, the Cyber Resilience Act regulates digital product safety, and the NIS2 directive imposes security measures for critical infrastructure.

Implementing cybersecurity regulations is complex due to evolving technologies and conflicting stakeholder interests. Risk management is crucial for these regulations and involves several processes. However, different stakeholders’ interests in digital identities make consensus challenging.

The EU recognizes supply chain risk’s significance in cybersecurity and addresses it in the NIS directive, especially regarding components like chips. Additionally, strategic regulations are needed to reduce dependence on specific manufacturers, particularly from China, for semiconductors. Uncertainty surrounds export controls for critical hardware like semiconductors.

Addressing the human element in cybersecurity is important. Manufacturers, programmers, and technical administrators should share responsibility for ensuring cybersecurity, rather than solely focusing on end-users. Non-tech industries often overlook the value of cybersecurity, considering it an abstract and costly issue.

Ransomware is a severe threat requiring executives’ attention to protect their organizations effectively. Currently, the EU lacks an overarching IT security law. Instead, regulations have historically grown and vary across sectors. Consolidation efforts are underway, but progress is uneven.

In summary, the EU is progressing in establishing cybersecurity regulations, but implementation remains complex. Risk management and conflicting interests surrounding digital identities pose challenges. Strategic regulations are needed to address supply chain risk. The human element in cybersecurity should be prioritized, and non-tech industries need to understand the value. Ransomware is a significant threat, and the EU aims to consolidate regulations across sectors.

Audience

An audience member raises concerns about securing critical hardware components and the regulations surrounding them in the European Union. They highlight the need to not only focus on downstream regulation of products but also on the hardware components that are essential for infrastructure. The significance of considering supply chain risk in cybersecurity, particularly in relation to manufacturers, is emphasised.

Furthermore, an audience member working in the European Parliament confirms that the Cyber Resilience Act covers semiconductors, enhancing their security. The importance of the human element and awareness in cybersecurity is underscored, with the audience member emphasising the need for ordinary individuals to have a better understanding of cybersecurity.

The argument is made that policymakers should prioritise the technical administrators and teams responsible for implementing products rather than relying solely on end-users to enhance cybersecurity. It is also noted that the European Union’s MEXA tool, designed to assess the security of mail servers, has not been widely adopted despite its potential efficiency.

The resistance faced by security systems, such as DNSSEC, in achieving mass implementation is attributed to economic counter-incentives. These systems are often seen as cost centres that do not generate profit, which hinders their widespread adoption.

Regulations like the Cyber Resilience Act are highlighted as a means to address cybersecurity incidents resulting from the neglect of product safety. The Radio Equipment Directive is mentioned as a regulatory attempt to safeguard product security, and the Cyber Resilience Act is specifically identified as a regulation focusing on the deployment of secure systems in the mass market. The argument is made that threats like the Log4j incident necessitate the presence of regulations like the Cyber Resilience Act to prevent similar situations by ensuring product safety and software support.

In conclusion, the discussions revolve around the need for enhanced security measures for critical hardware components, the consideration of supply chain risk in cybersecurity, the coverage of semiconductors under the Cyber Resilience Act, the significance of the human element and awareness in cybersecurity, the necessity of focusing on technical administrators and teams, the limited adoption of the MEXA tool, the economic challenges faced by security systems, and the importance of regulations like the Cyber Resilience Act in addressing cybersecurity threats.

Narayan

The analysis focuses on two main aspects of cybersecurity: the necessity for comprehensive regulation and the effectiveness of the European Union’s (EU) actions in this area. The first speaker argues that cybersecurity regulations should cover governance, partnership, workforce development, and public awareness. Including these elements would enhance the efficacy of the regulations in addressing the various challenges posed by cybersecurity. However, the speaker does not provide any supporting evidence or facts.

In contrast, the second speaker expresses a positive sentiment towards the EU’s cybersecurity actions, describing them as prompt and efficient. Regrettably, the speaker does not offer any specific examples or evidence to support this claim, which weakens their argument.

On the other hand, the third speaker maintains a neutral position on the EU’s approach to cybersecurity regulation. They highlight the uncertainty about whether the EU’s regulations adequately cover all aspects in a single act or if separate acts are needed. Although no supporting facts are provided, this observation implies that there may be some ambiguity or complexity within the EU’s regulatory framework for cybersecurity.

In conclusion, the analysis emphasizes the significance of comprehensive regulation in cybersecurity, encompassing governance, partnership, workforce development, and public awareness. However, the lack of concrete evidence weakens the arguments made by the first and second speakers. The third speaker raises a valid point about the clarity and effectiveness of the EU’s cybersecurity regulation, calling for further examination and clarification.

Nils Brinke:
Thank you very much. My name is Nils Brinke and today I wanted to talk about cybersecurity regulation and the way we do it in the European Union and what I’ll give an overview about the current regulatory efforts of the European Union as well as dive a bit deeper into the methods that are used within those regulations as well as, yeah, what issues are coming up with that. So, yeah, I work for the Digital Society Institute of the SMT Berlin and as well I’m a fellow of the European Cyber Conflict Research Initiative and, yeah, currently mainly working, yeah, used to work on a project on the systematization of IT security law and right now working in a, yeah, accommodating research project about digital identities, yeah. So let’s, yeah, start and dive right into it. So I’d like to give you a brief overview of what are the counter-IT regulatory efforts of the EU. They are like two main former regulations or directives and two that are right now more or less work in progress. Yeah, the first is the, was the Cybersecurity Act of 2019. Yeah, I think all those regulations kind of have like an headline issue in their short description, it’s called Cybersecurity Act, but in a way what it’s all that it does is in a way it formalizes the mandate of UNICEF, which is like the major European Cyber Security Authority. It was established I think in 2011, yeah, don’t pin me down on the date, but we’re around like for quite some years and therefore like the Cybersecurity Act formalized the mandate and it also introduced, yeah, a formal process to articulate European cybersecurity certification schemes. So you can, with those certification schemes, you can, as an ITC operator or manufacturer, you can aim to formulate dedicated certifications for specific use cases and therefore choose a certification-based approach to cybersecurity. To be honest, I think they are right now like the Cybersecurity Act was agreed upon in 2019, but so far they are, I think the only major certification scheme that is work in progress is a European certification scheme on cloud computing, but otherwise there’s not much going on more. Then, yeah, some of you may have heard about the NIS2 directive, which was agreed upon in December 2022. This directive generally addresses operators of critical infrastructure to implement certain security measures to secure their services. So the aim of that directive was mainly critical infrastructure and critical services. There’s one major regulation work in progress, it’s a proposal for Cyber Resilience Act. There you can see like the headline problem again, like basically, so like the long title about this from the Cybersecurity Act is a regulation on horizontal requirements for projects with products with digital elements and short title is Cyber Resilience Act. I don’t know why it’s called Cyber Resilience Act, in the end it has nothing to do with cyber resilience, in the end it’s like cybersecurity and product safety to go all the way. But I just guess like the name Cybersecurity Act was already taken, so and yeah, cyber resilience was kind of the new buzzword to use in that sphere. And therefore, yeah, why not take it as a short title? Yeah, as I said, it’s still work in progress, I think it’s in the Trilog discussion right now. Yeah, as I said, it regulates the safety and security of digital products or products with digital elements. And therefore, the main approach of the Cyber Resilience Act is product safety regulation. So therefore, when you enter a market and want to market your product within the European Union, then you have to comply to certain product safety and security standards, which in this case also includes means of cybersecurity. Yeah, just like to put it in, it’s like not mainly a cybersecurity regulation, but just yeah, to mention it, there’s also the proposal for an AI Act, which takes a rich base approach at regulating certain high risk AI use cases. So it doesn’t regulate AI as a technique or the technical implementation itself, but certain use cases which are seen as high risk have to comply to certain security, not only cybersecurity, but basically security and risk management requirements all in all. And this is, as I said, it’s like the contact point for the regulation, there’s the use case and therefore it’s also product safety regulation, product security regulation in its heart and its core. Yeah, so you saw like the, just to give you an idea, like what it’s actually, why it’s actually so complicated to approaching cybersecurity from a regulatory perspective, it’s yeah, the latest European efforts I talked about were, yeah, quite recent, but it’s like not that in the European Union and especially in the member states, there was like no cybersecurity regulation before. You can like in the Apple overview about like how it’s managed in Germany, there were like cross-sectorial IT security law, like as I said, the NIST directive, the NIST 2 directive had a pre-assessor, NIST 1 directive and therefore a critical infrastructure was mainly regulated before like the main new thing about the NIST 2 directive is that the scope of the regulated entities has broadened significantly. There was like the GDPR, the BSE law is actually like the German implementation of the NIST 2 directive and, but they existed also like a lot of sector-specific IT security law, which was like kind of historically grown, like there was like telecommunication law, law for medical products, energy law, those sector-specific laws existed a long time before anybody thought about cybersecurity, but like it depended like sometime in the early 2000s when there was like a regulatory update of those regulations, somebody thought, oh yeah, this cybersecurity stuff is now coming, it’s now getting more important, like people use, start to use like computers to actually operate a power plant and therefore they crammed in something like, just like one paragraph, like appropriate technical and organizational measures for the security of the services have to be implemented, something like that and therefore it is still like a big historically grown, eclectic body and even though there were like recent efforts, for example, within the NIST 2 directive to make this jungle of laws a bit more approachable, but of course like regulation changes slowly and therefore, yeah, it might take some time and I think you can compare it like to a legacy system, like it’s no different like to an IT system in a way, like you have like a lot of legacy systems that are historically grown and at the end of the day nobody wants to touch them and want to start on a blank paper once over and therefore, yeah, it might take some time till it’s, to get a bit more overview in it. Yeah, what were like the basic methods used in those regulations, like to give you like a very brief and high-level overview? Of course, there were like public law measures that require member states to at first, yeah, implement institutions and authorities to enforce obligations because like when you make obligations for the private sector, you need an authority to check if all of those obligations are met by the private sector. Also, like in the NIST 2 directive, there was an effort to create something like a cyber security incident response team in order that, yeah, member states have like a public authority that if there’s like a large-scale cyber incident to be seen, that they can help direct, organize and, yeah, mitigate the fallout of those large-scale incidents. But I think like the core and major point of cyber security regulation in Europe in general is like the obligations for the private sector, like as I said, it grew from the, if you are like in a regulated sector, then you have to basically, yeah, implement appropriate technical and organizational measures to ensure the security of your service or your product. And the way this is usually conducted is by risk management, so there’s like no one-size-fits-all and here’s your compliant checklist of measures that you have to implement. But like in general, it’s the private institution have to conduct like a risk management by themselves and therefore the result of this risk management is the actual measures that have to be implemented for the most part. And I think this risk-based approach is generally a new approach. Historically, it was like more common to actually state explicit technical requirements either way, especially in the law, which is still the case in the NIS2 Directive. For example, there’s like a catalog of actual measures you have to implement. Some are very abstract, like the risk management themselves, or some are like actually more a bit explicit, like your backup management or that you have to think about encryption and all the stuff. But like very historically speaking, for example, in the field of medical products, it was, there existed like a certification-based approach that, yeah, there’s like no, not really a risk management involved, but like in order for your medical product to get certified, there were like certain standards which contained like actual explicit measures that you had to implement. And therefore, yeah, those, this was like in a way it was done back in the days. I think this approach, like this certification-based approach is still valid, like for very explicit use cases, like medical products, like a very explicit use case, but it’s like not a good measure to do it like in cross-sectoral law, when you want to address like, because like the situation in each sector is still like too different to require explicit technical measures those manufacturers or providers have to implement. Yeah, this was like the, yeah, very high level overview about like the actual tools and measures those regulation contains. Selected issues. One selected issue, I should say example of design entities, like why, for one reason, it’s like my current project I’m working on, but for the, on the other side, I think it’s a good, this is a very raw sketch, but I think it illustrates very good, like what is actually, why it’s actually so hard to come up with working cybersecurity regulation, because yeah, like digital identities are still, at least in Germany, we are not Estonia, it’s a very new field in a way. There’s like not really an infrastructure set up and there are like a lot of different stakeholders that yeah, have like interest and like also are interested in proper cybersecurity measures. Like for digital identities, for example, you have like two different regulations. You have like the NIS2 directive, because trusted providers are regulated as a critical infrastructure, but then of course you had like the IDAS directive, which is a directive on digital identities and which is like more sector specific and like in practical, you can always have to like see if those two pieces of regulations really work together, if they are like, they contradict each other, like if there are like two separate paragraphs that regulate the same thing actually, and then you have to come up with a solution, which one is actually implies, which is applies, which is like the lex specialis or yes, and this is like then an ongoing legal discussion. There are actually like established standards and norms for digital identities and especially like with the NIS2 directive, like the most established standards were like considering the IDAS regulation and yeah, and with the NIS2 it’s again like the question, okay, when I am certified for and I implemented standards for cybersecurity or digital identities concerning the IDAS regulation, but is it still, can I just like copy paste everything in order to prove my compliance with NIS2? Then of course there are like the technical requirements, which is like of course like a first like the technical reality, I would call it. It’s yeah, what can you actually technically do, but also like the, yeah, I think the market implications like the, for example, for digital identities there’s the one part of it is like a secure element, which when you have like your wallet on your phone, like the phone needs to actually have like a secure element in it and therefore in a way like the phone manufacturer dictate how the secure element actually looks like, therefore also like market interest income, market interests. come into play. And yeah, then it’s like the use cases, as I would call it, like the actual thing where you need digital identities, for example, like for not only in the cases where you actually show your passport, but like, for example, yeah, for hotel reservations or going to the library and stuff like this, which is also affected by other regulations. And of course, there’s always the users, not only the people that implement the actual infrastructure and use cases, which have an interest, like how those use cases are designed, but also how the general infrastructure of digital identities is designed. And all of this is like, at least in Germany, it’s like new. It’s an evolving ecosystem. And therefore, it’s very, very complex to recognize every requirement and every interest of every stakeholder. Yeah, like another, very briefly, like another selected issue, it’s with the risk management itself. It’s like risk management’s now like the fancy method to come up with the actual technical measures. There are like established standards and like how to actually conduct the risk management. It usually contains stuff like first of like context establishment, like get to know your system, risk identification, like what could actually go wrong, and risk estimation, like how possible is it that stuff goes wrong, risk evaluation. Yeah, just like risk, as it’s defined, it’s like probability and possible damage to be expected. And then the risk treatment, so that’s where you come up with like the actual technical and representation measures to be implemented. So risk management is nothing new, but like at the end of the day, like in the existing regulation, who has to conduct the risk management? For the most of the time, there’s like no conflict of interest. For example, when you’re a provider of critical infrastructure, you are also interested that like a power plant provider is interested that his power plant doesn’t get hacked because he has like an economic interest in it. But like this is like the pro of cybersecurity regulation, I would say, that like the interests generally align. But like at the end of the day, it’s also, for example, in the Cybersecurity Cyber Resilience Act, as a product manufacturer that has to conduct this risk assessment, I have the interest to market my product on the European market. And therefore, there are standards to make the risk management like as objective as possible. But like in the end of the day, you cannot never take the perspective of the entity that actually has to conduct the risk assessment out of the equation. It’s always slight subjectivity to it. And this is actually hard when it comes like to third party risk. And in practice, it’s not easy to always change the perspective and also consider risk that are not for yourself, but like for other persons. Yeah, this was like the substance. And I would like to ask you if you have like any points or any questions to hopefully have a short but fruitful discussion. Yeah.

Audience:
Hey, so I have a question around, so you mentioned like you use medical product regulation as an example. And then you also mentioned like critical infrastructure. And I’m just curious about whether you, like how you think about the secured, like instead of thinking maybe so much around the downstream regulation of the products, like you mentioned product security a few times, how do you think about like how the European Union currently secures like critical hardware components like chips and how whether you see any sort of regulation or export controls around those critical hardware components of, you know, that run our infrastructure, especially as they host more, you know, advanced IP and stuff like that.

Nils Brinke:
Yeah, I think in the NIST directive, there is a part to consider supply chain risk. So in order, yeah, in that way, like the private entity has to consider the manufacturers, they get their chips and their technical components from, in order to, yeah, not only from a cybersecurity perspective, but also like to don’t get reliant on one manufacturer. I think the 5G issue was like the most prominent one. Export controls, I actually don’t know, but like especially when it comes to the semiconductors, there were like strategic regulations like to, and thoughts like to actually become less reliant on, yeah, let’s name it like Chinese manufacturers. Yeah.

Audience:
Hi. It’s been a really interesting to listen to you. I might maybe start by saying that I work in the European Parliament and work on these legislations. So to answer also your question, the CRA, the Cyber Resilience Act actually covers semiconductors. So they should be more secure once it’s in force. But one element that I’m missing also on the European level when we talk about these legislations is really how are we bringing more the human element, how we bring the kind of the third element that’s missing. As you can secure your services and then the supply chains through product regulation, but we still need more awareness and bringing it into everybody of us understanding what cybersecurity is. So I would be interested in hearing how you see kind of how this can fit in this whole package of all legislations that we have on the table, the more human element of it, because it’s, of course, one important one for cybersecurity.

Nils Brinke:
I think, yeah, the human element is important, but I think it’s always important to consider who to address. Do we address the end user? And my opinion is we should not like to. I mean, it’s always good to the end users aware, but we have limited resources. And a typical example, you roll out a fake phishing email campaign and like in order to make it like a wellness trainer for your employers. But at the end of the day, this is like the end users not where it goes wrong to begin with. To be frank, if you rely that, yeah, Thomas from accounting 60 years old doesn’t click on a cat picture in order for your organization to don’t get hacked, it’s like not Thomas’ fault. Your system security was shitty to begin with. And therefore, I think the adversity of those human elements and education is like more like the manufacturers, like the programmers, like, yeah, consider cybersecurity when setting up the architecture for your product. And for the coders, yeah, what are like the common mistakes and that cause cybersecurity issues. And therefore, yeah, the main point is like don’t focus too much on the end user, but on the technical administrators and team that actually implement and make those products. Yeah. Sorry.

Audience:
Thank you. I have one questions. Any policy must have some tools to investigate the operation of that policy, I think. According to that purpose, European Union provide the MEXA, M-E-C-S-A, which is a tool to check the security of mail server. So I think it’s a very good tool to investigate the operation of each server. My question is, after that tools introduced to European Union, what is the effect of that tool? It reduce the security level or increase the level of security of each server in the European Union. For instance, I found almost none of the companies use DNS security. Why? Because it protect your server for spoofing, I think. But almost none of it. So most important, what are the tendencies not to use such an important tool? It is very cheap to introduce and very effective. But almost none of our companies use such an important tools right now.

Nils Brinke:
Yes, that’s a great question. And I actually have to admit, I have no clue why they don’t implement it. I think the general problem of cybersecurity in organizations is, like in internet companies, it shouldn’t be. But especially in non-tech industries, cybersecurity was always this abstract thing. It just costs money. And therefore, it was not, yeah, people just didn’t want to, it didn’t generate money, it didn’t generate profit. And therefore, people were not eager to invest in it. I think maybe to be a bit cynical, ransomware did a good job in bringing the abstract danger into the minds of executives. Because they have like a very, very vivid picture of the actual damage that can be caused through cybersecurity incidents. Yeah, thank you.

Audience:
May I? Thank you. So I think that is a very important question, a very interesting question that connects slightly with a CRA, even though the DNSSEC part isn’t really in scope. However, what both questions have in common, or both the regulation addresses outside your particular example is that there are economic counter-incentives to deploying security systems in the mass market. You mentioned it’s a product, first and foremost, the CRA is a product safety regulation, which is why it goes, it makes use of a whole set of pre-arranged tools that are available on the regulatory side. The radio equipment directive is the predecessor kind of on the regulatory, in the regulatory toolbox. And the threat model is the cheap cameras coming from somewhere that are thrown on the market without any support for software updates, security updates, and so on and so forth. And why is that? Because people don’t want to pay extra for the security. And that is kind of comparable to your example, right? So DNSSEC is something, first of all, it’s not something you add to a product. It’s a system that needs to be deployed in various places, needs cooperation, and so on and so forth. But economic counter-incentives in the mass market, I guess, is what both have in common. And that might be something to inform the discussion. And of course, the CRA is also a response to very prominent threats. Some of you might remember the Log4j incident, which was a, and then open source comes into play, but that is not the main point. But Log4j is the one that maybe not triggered this, but would be a prime example for something that triggers this kind of regulation. Everybody was crying around that this is a very important piece of software that is deployed all over the place. And it was maybe unmaintained or working on a shoestring budget because a single individual was, quote, quote, responsible for this. And it is deployed everywhere in products and in critical infrastructure. And I think that’s what the CRA, in part, tries to address. But the economics are very important in this part and should be looked onto. Thank you.

Nils Brinke:
Yeah, thank you. And I agree. And I think we came to the end of this session.

Narayan:
So I have a quick question.

Nils Brinke:
Sorry.

Narayan:
Basically, it was a good presentation. I am Narayan Timilsena from Nepal. So when we talk about regulation on cybersecurity, particularly what I understood is we have to go through from some dimensions such as governance, partnership, workforce development, and public awareness, as she said, about human capital. So in EU, it’s quite quick. So does it cover all these aspects in a single act, or is it very separate? Very separate.

Nils Brinke:
Like, NIST 2 is on critical infrastructure. It’s on products. Like when those categories you mentioned, like it was governance, human aspect, I think it’s not, especially for example, the human aspect, it’s kind of thought of a bit like in NIST 2. But in general, you could say there’s no overarching IT security law in the European Union. And why is that? Like as I said in the beginning, it’s like everything is a bit historically grown. And some sectors are like very further on their way. For example, like financial sectors, like historically very tightly regulated sector. And therefore, there were efforts like to consolidate it a bit. But in general, it’s still a bit like yards scattered around. OK, then I think we came to the end of this session. Thank you very much for your questions. And yeah, then see you soon on the venue.

Audience:
Thank you. Thank you.