About this talk
This talk focuses on the Cyber Resilience Act (CRA) and its implications for companies manufacturing Products with Digital Elements (PDEs) and software producers. The speaker discusses the development of tools and methodologies designed to aid compliance with the CRA, which aims to enhance cybersecurity resilience by 2027. They introduce a service platform that facilitates the registration and security assessment of IoT devices, as well as provides compliance tools such as Self-BOM management and vulnerability tracking. The project, co-sponsored by the European Commission, seeks to make these resources accessible to small and medium-sized enterprises (SMEs) across Europe, ensuring that technologies remain robust against cyber threats. Additionally, they highlight the importance of security documentation and risk assessments in line with industry standards.
Full transcript
[music] >> Good afternoon everybody. Let's see if I can uh turn off the Microsoft stuff. Annoying as usual. Okay, so um My name is Oris Feldt Stacht. I'm here indeed to talk about crazy. Uh you have chosen the compliance track and over the last couple of days I know that uh a specific topic has been addressed already a couple of times. So let me start by asking
you uh who of you is familiar with CRA? Just raise your hands. There we go. All of you. That makes life so easy for me because then I can really quickly go to the core of uh my message here today. Um everybody of you has read the the necessary uh legal documentation, is fully aware about the central requirements, documentation requirements, vulnerability handling requirements. I see all of
you nodding, so that's great. Perfect. Okay, so what is crazy all about? So as you see it's CRA and then CY. But we call it simply crazy because we like to be a bit crazy. Um so it's really about the cyber resilience act made easy. Um we try to build with a group of experts and technology specialists a series of tools, capabilities, methodologies uh to help companies,
manufacturers of PDEs uh of course also software producers in this case, to develop um technologies in to be compliant to CRA and to of course also retrofit some of the existing technologies to be ready by December 2027. Um already there's a couple of deadlines as you might have heard that we are working towards. So too little time and not not really interested in the rest of the
talk then at least this is the summary of what I'll be talking about. We have some tools. Those are some security tools for those of you who are developing PDEs IoT oriented. It's an SaaS based security environment that you can simply go to register your your PDE your IoT device and we can facilitate the security of it which brings you to about 85% of the requirements of
the CRA. Or you can follow basically some other guidance that we have. We have different white papers available. We also created a number of compliance tools both compliance and SBOMs tools in this in this sense. What I didn't mention but you can see it of course from the the representation here is that the project is sponsored co-sponsored co-financed by the European Commission and through the European Cybersecurity
Competence Center the ECCC which is the specific department from European funding agency focusing on cybersecurity these days. Meaning that this project is not research project. It's what is called Digital Europe project and therefore very close to market when it comes to the tooling and the developments that we are doing. We're doing this together as I said with a number of experts. One of the core experts here
is an organization called Timelex which is Belgian Brussels based law firm specifically focused on everything in relation to IT law and they have been working towards CRA and all the types of legislations including also AI Act for many many different years and guiding in this case the transposition we call it the demystification of the CRA into something practical something useful and something that is also hopefully helpful
to you as as developers. And now we have a series of other technology companies that are helping us in developing some of the components and the tools that I'll talk about. Um we ourselves are LSEC participating here as the coordinator. LSEC is a non-profit association um a bit similar to Eclipse, also based here in Belgium, and we focus ourselves for the last 30 years on cybersecurity as
a spin-off of KU Leuven University. Um basically a couple of small things to catch up because we've seen some new members in this group walking in. So, why the CRA? It's basically because we need more resilience. What is resilience? It's basically everything that you can do today to break a product a PDE and in the under the terms of the CRA to not function anymore. So, then
it becomes non-resilient and we want it of course to work on a continuous basis because that's of course why you build it that it can be used. So, we want to we want the products to be also resilient and therefore we want to be them make sure that they're also cyber secure. So, we are supporting the implementation in this case of the Cyber Resilience Act. It has
been appearing in December 2024. There's some additional guidance that was released in March of this year. It's about 15 months after the original legislation. And in this case our focus is really to help SMEs small medium-sized companies throughout Europe to get in compliance to the CRA with practical tools that hope to simplify compliance. Now, the CRA is originated to these types of products. So, not directly to
you as software developers, but as you know, as we know, software is basically what driving what is driving many of these different components and technologies. Um going from uh child tools to adult toys uh going from uh key locks and uh everything that you have in terms of home automation to in this case for instance also things like business electronics. And if you think that um in
the cybersecurity world uh things are um as secure as uh as the moment that they are being released in the market then potentially hopefully they are, but over time they also have some um some some challenges. So here's a just a couple of examples uh 2026 vulnerabilities in Fortinet, in Cisco, uh so not only the European American vendors, but also uh in this case for instance a
Swiss vendor that is uh uh has been building uh some access device uh units. And taking it even further and that brings it immediately into the core of the resilience uh terminology as well, critical components um equally uh under scrutiny of cybersecurity challenges. So PDEs related to um industrial control systems, uh Schneider the southern uh signaling networks that you can find quite often in manufacturing environments. Um
and so many of those systems equally as well uh many uh vulnerabilities being discovered. Any of you here familiar with CVEs? Okay, that's definitely the majority. So you all know all of these CVEs clearly, that's easy then I don't have to explain these as well. Um but then we're going into uh the next level of PDEs, basically also why uh you're all here as well. Um so
um open source uh technologies, um there's a couple of them that I basically quickly looked up um uh some very uh famous and popular ones, open pilot navigation systems, uh home automation systems, um even an uh an desktop remote desktop environment, um all of them having more than one uh vulnerabilities. In the the case of the remote desktop solution, uh quite a number of critical uh remote
exploit capabilities. So, taking those into consideration, if you put new products in the market, also as open source developers, you'll need to make sure that they are secure. So, it's basically about those products with digital elements, Article 2 of the CRA. Does the majority of products which are not going to be relevant in terms of making sure that you do not have to go into the critical
systems or you don't have to provide all of the serious documentation. But then there's the 10% of the Class 1, Class 2 and critical ones that I just showed, which which do have quite a lot of challenges when it comes to your security And so, basically, what we have been developing is some guidance in white papers that will help you in knowing what you can do, what
you need to do when it comes to for instance security updates, when it comes to making sure that there are a couple of things that you can check before you put them into the market when it comes to compliance and the requirements in this case of the documentation. First thing that we provide you is an basically on the CRAZY website, pd.crazy.eu. Couple of basic questions that you
have to answer before you get any any next step. And basically by answering this couple of questions, you get from us a sort of a small notification that it is a confirmed PDE and so then you can take it to the next step. You can start to qualify what type of class. But you can also might be able to receive in this case a notification from us
that it's not a PDE and that helps you also later on when necessary surveillance authorities have been set up in the market. As you heard this morning, it still will take some time to get there. But before those uh, authorities have been set up, at least you know that for the different products that you have, you can uh, get to that level of uh, of So, what
we're doing is we're building a number of um, uh, solutions. Um, the majority of these uh, will be are and will be always uh, open source and freely accessible. Some of them will be starting uh, by becoming uh, free and open source and then gradually um, moving towards more commercial types of tools, but the basic the baseline of them will always be uh, open source. uh, one
of the reasons why we're here is really to promote these open source tools under the CRA uh, flags. Um, we have Sassy, we have an uh, crazy infra, um, a registry and uh, just to show you uh, a number of them. So, the Sassy as already explained, if you have IoT devices or related devices, you can simply go to uh, the platform, you can register and it
becomes basically an uh, a Sassy that helps you um, make sure that the security is ensured uh, continuously um, in this case for the device when you put it into the market. And we can guarantee you also that it's compliant to CRA. Um, composition analysis tool uh, like there's of course many. In this case, we created one specifically on um, uh, infra mapper uh, specifically everything in
relation to uh, Ansible and uh, and specifically in this case uh, scripting. Um, so it gives you an immediate result of an uh, an S-BOM and also gives you indication of the different uh, vulnerabilities. I'll come back to the S-BOMs later on, but this is something that in any case can help you identifying some vulnerabilities within your your current uh, uh, Ansible files uh, already. Um, another
one in the same lines for containers um, specifically in a composition analysis developed for containers if if you have some. Um, same uh, mechanism applies so composition analysis giving you vulnerabilities, giving you also and result into an S-BOM so that you can use it in an S-BOM repository. Uh we can help you also with uh traceability for um for PDEs in when it comes to supply chain.
So, basically in this case also dependencies, dependency tracking uh for all of the uh vulnerabilities being discovered, we can ensure that you can also follow up uh on those vulnerabilities when uh new become available um when new are being discovered so that you don't have to monitor manually all of these CVEs, but that it's being automatically uh presented to you where uh these these are coming from
and how to handle them Um we have set up a mechanism that helps you uh for self-attestation. Uh self-attestation in this case necessary for in this case CRA compliance, uh but also for instance for uh for S-BOMs. Uh so, when you do release an S-BOM, you can make sure that it's being uh um attested so that when you provide it to your customers or to the authorities,
that you know that they will be having the right uh S-BOM to look into. Um we will be helping uh with uh with signing of S-BOMs. Um it's basically a service that we have already uh set online. So, um in the uh STS platform that helps you just linking up your PDEs and uh making sure that uh the the signing of everything that's uh necessary in here
is uh is being guaranteed also in relation to the S-BOMs in this case. Um we have a a platform and a tool specifically for um dependency tracking and S-BOM management. If you have multiple different products or projects with multiple different uh products in there, uh both hardware, software, combinations of, uh it might become sometimes a bit of a challenge to maintain all of these S-BOMs and also
maintain the security. So, this is a platform that helps you out in doing that and not only for you, but you can also offer it to uh your clients so that they can uh continuously monitor all of the products that they've been buying from you. So, if you do update on on S-BOMs and on uh potential vulnerabilities, that they will be informed automatically, and so they can
take the necessary measures if needed. Um and the PDI identification tool that I already showed, there's an uh a repository and a repo that we set in place specifically for manufacturers to um help you out also with the different steps to be taken. Um so, in the essential requirements, um like we heard also with the uh the AI Act uh just before, there's a series of risk
assessments that need to be undertaken. So, it starts with the risk assessment. What have you been doing in terms of risk assessment? What risks have been identified? How are you trying to mitigate them? How are you trying to work with the residual residual uh risk in this case? And how will you be uh making sure also that um every component when it comes to the essential requirements
is being uh tracked and traced. So, what we provide here is a platform that helps you out in the tracking of everything that's necessary to provide this compliance level, and so that you can also show that either when you are going for standardization efforts, or when you decide, well, standardization is not really necessary because we fall under this 90% category, meaning that you still have to comply,
but you don't have to follow uh any specific uh uh standard uh for that. So, you can choose your own in this case. So, in this case, we've also helped in uh translating these essential requirements, and you can find those um in a in a specific document, a white paper, which is about uh unfortunately 150 pages um as well, but it really takes you step by step
uh to the necessary steps to be to the necessary uh things to do. Again, from risk management to uh documentation and uh vulnerability uh reporting. Um we have a specific series of tools for S-BOM deployments uh that help out in this case for how do you get the S-BOMs uh back into the market and making sure that uh they're also being uh followed when it comes to
uh vulnerability management in this case also uh ensuring that the S-bombs which are out there are being secured and you can trust them. So when basically you provide an S-bomb into the market, that is not going to be scrutinized by maybe a malicious agent somebody in between. And then finally we have also some AI capabilities already. We do see that many of the PDEs are being equipped
with AI. Not that unusual these days of course. So we set up a specific AI bomb which is one of the first in into the world to do this. It provides you also with an S-bomb but it does the analysis on the AI capabilities to figure out what needs to be included into the S-bomb. And then again here also we do make sure that as not only
the signing of the coding and the the capabilities but in this case also S-bomb signing. some additional tools are being developed as we speak. As I said we are a European project. The project is now about a year 13 months in in the go. So these are the tools that we already have available. There will be some others that will be releasing shortly. So do keep track
of us. If you are interested I have a box of pens with some lights and lasers if you're interested. So and it also reminds you where to go to as in crazy.eu. So do If you have some PDEs that you would like to have tested and you're not entirely certain or sure that the things that you're doing in order to prepare are the good things, you can
also ask us during the time frame of the project to help you out. We are offering to provide compliance support for PDE manufacturers both hardware as well as software. This is an example. It's an IoT developer that's basically developing their own software and and of course also the necessary components when it comes to IoT. So, we are supporting them in making sure that they are getting IoT
compliant and in this case also CRA compliant. And then the different white papers that you can find on the website. And I think that's a clear signal for me to stop that I should finalize here. Thank you very much for your attention. I leave it to you with our contact details. Thank you so much. Thank you. [applause] We have time for one quick question if any. Anybody
with a quick question? Small question, large question, but it has to be quick. Okay. All good. Thank you very much. >> much.
