WEBVTT 00:00.000 --> 00:11.000 We've learned that there's no easy way any more to put digital products on the EU market, 00:11.000 --> 00:17.000 and I'm going through what you at least, like, what is a minimum requirement to anyone 00:17.000 --> 00:20.000 needs to do, who has some manufacture. 00:20.000 --> 00:25.000 And this started as a practical introduction, but now it's the fastest introduction because I 00:25.000 --> 00:32.000 got, basically, not enough time to go through a complete service security risk assessment. 00:32.000 --> 00:40.000 But, again, the date is circulating all over from 11 December, 2027, a manufacturer, 00:40.000 --> 00:46.000 like someone who puts a digital product on a European market and takes money for it, 00:46.000 --> 00:54.000 needs to comply to the European CRA, and this includes a risk-based approach. 00:54.000 --> 00:59.000 So the number for today that you should remember is 81. 00:59.000 --> 01:05.000 This is the occurrences of the term cybersecurity risks in the CRA. 01:05.000 --> 01:11.000 So the entire CRA talks about risks and cybersecurity risks, so you have to find a way 01:11.000 --> 01:14.000 how you approach cybersecurity risk. 01:14.000 --> 01:19.000 And I'm not reading it to you, but I have highlighted what it is about. 01:19.000 --> 01:21.000 So you need to have cybersecurity risk. 01:21.000 --> 01:28.000 You need to assess this while you plan design, develop product, deliver, and maintain your product. 01:28.000 --> 01:35.000 Including, this is a difference to information security, health and safety of this users. 01:35.000 --> 01:38.000 This is not only information security. 01:38.000 --> 01:44.000 This is not, oh yeah, I'm losing some data and I get, like, my, my arms email is somewhere and 01:44.000 --> 01:45.000 get spam. 01:45.000 --> 01:48.000 This is about also health and safety. 01:49.000 --> 01:57.000 And the cybersecurity risk assessment needs to contain a lot of specifics that help you 01:57.000 --> 01:59.000 to understand the risk of your product. 01:59.000 --> 02:04.000 And this contains, as social is, you must do this, otherwise you're not 02:04.000 --> 02:08.000 compliant to the legal text, that's not a standard, that's a legal text. 02:08.000 --> 02:12.000 The intended purpose, reasonable foreseeable use, conditions of use, 02:12.000 --> 02:15.000 operational environment, assets to protect. 02:15.000 --> 02:21.000 And you have to do this over the expected period of life for your product. 02:21.000 --> 02:27.000 So if you do operating system for embedded systems, you should plan to do this for the next 15 years. 02:27.000 --> 02:32.000 Not two or three, but very long. 02:32.000 --> 02:34.000 So why is this a risk-based approach? 02:34.000 --> 02:40.000 So these are all these essential cybersecurity requirements in the legal text. 02:40.000 --> 02:45.000 But there's a very, very thin information in there on the basis of the cybersecurity risk 02:45.000 --> 02:46.000 assessment. 02:46.000 --> 02:50.000 You share, implement all these requirements. 02:50.000 --> 02:55.000 If we wouldn't have a risk-based approach, we now would start understanding how we can 02:55.000 --> 03:00.000 implement all of them in every digital product that we put on the market, which is nonsense. 03:00.000 --> 03:04.000 So that's why we need a risk-based approach. 03:04.000 --> 03:09.000 Because we need to understand what is applicable and what is not applicable. 03:09.000 --> 03:14.000 So there's one flaw on this, we have to document this. 03:14.000 --> 03:20.000 And we all are developers and the thing that we don't like is documenting what we do. 03:20.000 --> 03:26.000 Because we want to do coding or work on a product. 03:26.000 --> 03:34.000 But there's now a legal obligation in the CRA that says you have to draw together a technical documentation. 03:34.000 --> 03:39.000 And one essential part of this is an assessment of the cybersecurity risk. 03:39.000 --> 03:43.000 And how you design and develop and produce and all the stuff. 03:43.000 --> 03:46.000 And the last line is the very important one. 03:46.000 --> 03:57.000 You need to demonstrate that the cybersecurity requirement from this list is applicable to your product. 03:57.000 --> 04:00.000 You cannot do this if you don't do a risk assessment. 04:00.000 --> 04:10.000 That's the point. So you have to do a risk assessment that you can justify the applicability of the requirement. 04:10.000 --> 04:17.000 I've gone for this year, and checked what's information security risk management procedure is existing. 04:17.000 --> 04:23.000 For example, the information security risk assessment, according to ISO 2705, 04:23.000 --> 04:30.000 and you find all the pieces and bits where you basically can map it all together to a risk management. 04:30.000 --> 04:35.000 It's not only assessing the risk, it's managing risk. 04:35.000 --> 04:38.000 And again, bottom line documented information. 04:38.000 --> 04:45.000 This is the key part. Everything I will show you now needs to be documented by you. 04:45.000 --> 04:51.000 So because otherwise, you cannot prove in the case of some information or cybersecurity problem with the product, 04:51.000 --> 04:56.000 that you have put it on a market in a diligent way. 04:56.000 --> 05:05.000 Then there is the sense that it has an answer to the understanding how do I do secure software development. 05:05.000 --> 05:10.000 And this is the EN-41-2 with still a draft. 05:10.000 --> 05:16.000 But it boils down that you need to understand how your requirements are applicable to you. 05:16.000 --> 05:22.000 What is your product context? How do you do a risk assessment based on criterion method? 05:22.000 --> 05:26.000 You execute a risk assessment. You have a risk treatment plan. 05:26.000 --> 05:30.000 You communicate the risks that remain in your product. 05:30.000 --> 05:36.000 You review and monitor your risk assessment, and then you document. 05:36.000 --> 05:41.000 And because this is super dry, and I started with a 45 pages of risk assessment, 05:41.000 --> 05:46.000 I took my solution for everything bicycles. 05:46.000 --> 05:50.000 So, every problem that I can see I can solve by bicycle. 05:50.000 --> 05:54.000 This is my cargo bike, me and my son going on a vacation by bike. 05:54.000 --> 05:58.000 He's sitting in this bike, including all the luggage. 05:58.000 --> 06:06.000 So, why bicycles? Because they have the norms of having a direct impact on the physical environment. 06:06.000 --> 06:11.000 So, how do you describe the product context based on the bicycle? 06:11.000 --> 06:18.000 So, you have a function. You can run fast, you can break, you can attach another bike. 06:18.000 --> 06:22.000 So, you have to describe this. There's no tool doing this for you. 06:22.000 --> 06:30.000 So, start now. You can start today. Sit down. What is the functionality of your product of your software product? 06:30.000 --> 06:36.000 And, is it an integration product? Or is it a product that you place on the market directly to a user? 06:36.000 --> 06:44.000 For example, someone who builds a break. It's not responsible for the fork or for the frame of a bicycle, but for the break. 06:44.000 --> 06:54.000 And, we all build software products and software components, but we then need to specify what is the interface to securely use my component. 06:54.000 --> 07:02.000 And, you need to define a user profile. So, this is a kids bike. So, the user profile for this bike is like a kid is sitting on this. 07:02.000 --> 07:10.000 But, this also comes with some requirements to the bike. So, this bike is as heavy as my race bike. 07:10.000 --> 07:18.000 Because the kids will fall with this bike thousands of times, and it's basically planned that a kid will fall with the bike. 07:18.000 --> 07:26.000 With my race bike and the carbon fork, they hope I don't fall with it because then the focus basically trash. 07:26.000 --> 07:36.000 And, you have to come up with ideas of foreseeable use. So, if you build a car bike, you should expect that people do stuff with the car bike. 07:36.000 --> 07:48.000 So, this bike, for example, is allowed to carry 275 kilograms. So, your software product should also define what is foreseeable use. 07:48.000 --> 07:58.000 Are you doing a server component that someone can offer library that someone can use to process person information? 07:58.000 --> 08:08.000 So, you need to define this for yourself. You have to define what is the architecture of your product. So, where is the interface to the user, where is the interface between components? 08:08.000 --> 08:18.000 This is like a big sheet of what you need to define. And, the interesting part is you need to understand the operational environment. 08:18.000 --> 08:22.000 So, on the left side, this was when we still lived in Germany, this was the way to do. 08:22.000 --> 08:30.000 To the Kindergarten very unsafe environment. So, we had to do all the flag and all the stuff. Now, we live in the Netherlands. We have nice bike lanes. 08:30.000 --> 08:36.000 And, my son is just a breezing to school, basically on his own. 08:36.000 --> 08:46.000 And, there's one part also to this, when you have a component or a software product, you need to understand if you have a remote data processing system. 08:46.000 --> 08:58.000 That is important for the security of your product. For example, this is a bike that you can lock with your mobile phone. If you're mobile phone dies, there have been cases that you don't unlock your bike. 08:58.000 --> 09:01.000 This may be a problem. 09:01.000 --> 09:09.000 So, now, we have to understand that you need to follow like code guiding principles. 09:09.000 --> 09:18.000 So, what is your risk management methodology? So, let's say, don't do this product or what is your idea. 09:18.000 --> 09:25.000 And, standard idea is that you start understanding what is the assets and the security objectives. 09:25.000 --> 09:35.000 So, this fury friend of my son is a very important asset for him. So, he got a helmet and not himself. 09:35.000 --> 09:45.000 And, in information security, cybersecurity, these are basically the confidentiality, integrity, all the stuff. 09:45.000 --> 09:51.000 So, understand what are the objectives, the security objectives of your assets. 09:51.000 --> 10:02.000 And, then, you define what is acceptable risk. So, if I go on a beat with a bike, I accept the risk that I fall on soft sense. So, there's no big risk on this. 10:02.000 --> 10:15.000 But, you need to define this for your product. What's acceptable risk do you see? So, if you have a server component, do you accept that the server component is a lot to crash or not? 10:15.000 --> 10:28.000 Risk assessment. Very long, basically it boils down to how likely is it that the server security risk happens and what is impact. 10:28.000 --> 10:34.000 And, again, I highly encourage you to go for the OS risk rating methodology. 10:34.000 --> 10:43.000 But, with the hint, this is for information security, this is not including health and safety implications for a user. 10:43.000 --> 10:52.000 I have some ideas in the slides, I put on the session on the first step. 10:52.000 --> 10:58.000 And, there are two important things you should think about. You need to understand the inherent risk. 10:58.000 --> 11:03.000 So, basically, here's the inherent risk you fall down from a very high bike. 11:03.000 --> 11:08.000 So, what is the risk of using your software before you do anything security related? 11:08.000 --> 11:16.000 Even if you don't do, like you have to imagine how insecure it is using software with our code scanning. 11:16.000 --> 11:26.000 Then you have the impact analysis, then you have a likelihood analysis, then you have threat actors. 11:26.000 --> 11:38.000 You also have threat events, you have scaled accessibility of the risk and then you treat the risk by reducing the likelihood or by reducing the impact of the risk. 11:38.000 --> 11:43.000 Then you come up with a nice table that you have, I suppose you have to do this. 11:43.000 --> 11:52.000 And, for you, very important, the right column is the requirement based on my risk from the legal text applicable, yes or no. 11:52.000 --> 12:02.000 And, if it's applicable, you need to implement it and you end up with the risk of your product. 12:02.000 --> 12:12.000 Then you communicate and have user instructions, you monitor your risk, you have to do this for a very long time. 12:12.000 --> 12:16.000 Last bike, there's one kicker. 12:17.000 --> 12:29.000 And the problem is you have to do like future risks, like post-pandom computing, decryption of your security for embedded devices is already a hot topic because you have to plan it for in 10 years. 12:29.000 --> 12:34.000 Thank you.