We've learned that there's no easy way any more to put digital products on the EU market,
and I'm going through what you at least, like, what is a minimum requirement to anyone
needs to do, who has some manufacture.
And this started as a practical introduction, but now it's the fastest introduction because I
got, basically, not enough time to go through a complete service security risk assessment.
But, again, the date is circulating all over from 11 December, 2027, a manufacturer,
like someone who puts a digital product on a European market and takes money for it,
needs to comply to the European CRA, and this includes a risk-based approach.
So the number for today that you should remember is 81.
This is the occurrences of the term cybersecurity risks in the CRA.
So the entire CRA talks about risks and cybersecurity risks, so you have to find a way
how you approach cybersecurity risk.
And I'm not reading it to you, but I have highlighted what it is about.
So you need to have cybersecurity risk.
You need to assess this while you plan design, develop product, deliver, and maintain your product.
Including, this is a difference to information security, health and safety of this users.
This is not only information security.
This is not, oh yeah, I'm losing some data and I get, like, my, my arms email is somewhere and
get spam.
This is about also health and safety.
And the cybersecurity risk assessment needs to contain a lot of specifics that help you
to understand the risk of your product.
And this contains, as social is, you must do this, otherwise you're not
compliant to the legal text, that's not a standard, that's a legal text.
The intended purpose, reasonable foreseeable use, conditions of use,
operational environment, assets to protect.
And you have to do this over the expected period of life for your product.
So if you do operating system for embedded systems, you should plan to do this for the next 15 years.
Not two or three, but very long.
So why is this a risk-based approach?
So these are all these essential cybersecurity requirements in the legal text.
But there's a very, very thin information in there on the basis of the cybersecurity risk
assessment.
You share, implement all these requirements.
If we wouldn't have a risk-based approach, we now would start understanding how we can
implement all of them in every digital product that we put on the market, which is nonsense.
So that's why we need a risk-based approach.
Because we need to understand what is applicable and what is not applicable.
So there's one flaw on this, we have to document this.
And we all are developers and the thing that we don't like is documenting what we do.
Because we want to do coding or work on a product.
But there's now a legal obligation in the CRA that says you have to draw together a technical documentation.
And one essential part of this is an assessment of the cybersecurity risk.
And how you design and develop and produce and all the stuff.
And the last line is the very important one.
You need to demonstrate that the cybersecurity requirement from this list is applicable to your product.
You cannot do this if you don't do a risk assessment.
That's the point. So you have to do a risk assessment that you can justify the applicability of the requirement.
I've gone for this year, and checked what's information security risk management procedure is existing.
For example, the information security risk assessment, according to ISO 2705,
and you find all the pieces and bits where you basically can map it all together to a risk management.
It's not only assessing the risk, it's managing risk.
And again, bottom line documented information.
This is the key part. Everything I will show you now needs to be documented by you.
So because otherwise, you cannot prove in the case of some information or cybersecurity problem with the product,
that you have put it on a market in a diligent way.
Then there is the sense that it has an answer to the understanding how do I do secure software development.
And this is the EN-41-2 with still a draft.
But it boils down that you need to understand how your requirements are applicable to you.
What is your product context? How do you do a risk assessment based on criterion method?
You execute a risk assessment. You have a risk treatment plan.
You communicate the risks that remain in your product.
You review and monitor your risk assessment, and then you document.
And because this is super dry, and I started with a 45 pages of risk assessment,
I took my solution for everything bicycles.
So, every problem that I can see I can solve by bicycle.
This is my cargo bike, me and my son going on a vacation by bike.
He's sitting in this bike, including all the luggage.
So, why bicycles? Because they have the norms of having a direct impact on the physical environment.
So, how do you describe the product context based on the bicycle?
So, you have a function. You can run fast, you can break, you can attach another bike.
So, you have to describe this. There's no tool doing this for you.
So, start now. You can start today. Sit down. What is the functionality of your product of your software product?
And, is it an integration product? Or is it a product that you place on the market directly to a user?
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.
And, we all build software products and software components, but we then need to specify what is the interface to securely use my component.
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.
But, this also comes with some requirements to the bike. So, this bike is as heavy as my race bike.
Because the kids will fall with this bike thousands of times, and it's basically planned that a kid will fall with the bike.
With my race bike and the carbon fork, they hope I don't fall with it because then the focus basically trash.
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.
So, this bike, for example, is allowed to carry 275 kilograms. So, your software product should also define what is foreseeable use.
Are you doing a server component that someone can offer library that someone can use to process person information?
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?
This is like a big sheet of what you need to define. And, the interesting part is you need to understand the operational environment.
So, on the left side, this was when we still lived in Germany, this was the way to do.
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.
And, my son is just a breezing to school, basically on his own.
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.
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.
This may be a problem.
So, now, we have to understand that you need to follow like code guiding principles.
So, what is your risk management methodology? So, let's say, don't do this product or what is your idea.
And, standard idea is that you start understanding what is the assets and the security objectives.
So, this fury friend of my son is a very important asset for him. So, he got a helmet and not himself.
And, in information security, cybersecurity, these are basically the confidentiality, integrity, all the stuff.
So, understand what are the objectives, the security objectives of your assets.
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.
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?
Risk assessment. Very long, basically it boils down to how likely is it that the server security risk happens and what is impact.
And, again, I highly encourage you to go for the OS risk rating methodology.
But, with the hint, this is for information security, this is not including health and safety implications for a user.
I have some ideas in the slides, I put on the session on the first step.
And, there are two important things you should think about. You need to understand the inherent risk.
So, basically, here's the inherent risk you fall down from a very high bike.
So, what is the risk of using your software before you do anything security related?
Even if you don't do, like you have to imagine how insecure it is using software with our code scanning.
Then you have the impact analysis, then you have a likelihood analysis, then you have threat actors.
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.
Then you come up with a nice table that you have, I suppose you have to do this.
And, for you, very important, the right column is the requirement based on my risk from the legal text applicable, yes or no.
And, if it's applicable, you need to implement it and you end up with the risk of your product.
Then you communicate and have user instructions, you monitor your risk, you have to do this for a very long time.
Last bike, there's one kicker.
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.
Thank you.