Cybersecurity: Addressing ISO/SAE 21434 and UNECE with Model-Based Design - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 21:58
Loaded: 1.21%
Stream Type LIVE
Remaining Time 21:58
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
      Video length is 21:58

      Cybersecurity: Addressing ISO/SAE 21434 and UNECE with Model-Based Design

      Dr. Martin Becker, Principal Application Engineer, MathWorks

      In the rapidly evolving landscape of the automotive industry, cybersecurity has transitioned from an optional enhancement to an absolute necessity. The intricate nature of securing automotive systems presents a multifaceted challenge, characterized by uncertainty and the need for continuous iteration under stringent time constraints. This is primarily due to the relentless occurrence of new cyber threats, necessitating persistent vigilance and recurring updates to the embedded systems.

      This presentation showcases Model-Based Design as a way to alleviate the complexities inherent in automotive cybersecurity certification. Model-Based Design serves to maintain the integrity, completeness, and consistency of certification artifacts within a singular, cohesive engineering environment. Learn how to use System Composer™ and Simulink Fault Analyzer™ to conduct integrated security risk assessments, how Requirements Toolbox™ provides end-to-end traceability of security goals, how to use Control Systems Toolbox™ to implement countermeasures that can detect replay attacks, and how to efficiently create and qualify your security patches by leveraging change impact analysis, Embedded Coder®, and static analysis.

      Published: 3 Jun 2024

      Welcome to the security talk or, as the keynote speaker this morning said it, the speed bump. So I want to share with you some ways how you can actually accelerate being compliant to those speed bumps, driving a bit quicker over those, if you will, and just how to get the most out of model-based design for security. By no means this will be complete but just some highlights to give you a taste of how it really fits together.

      Let's start by looking at a social media post not so long ago. So this person woke up in the morning and found their car like this-- scratched. The front lights don't work. And also, you see here there's a gap in the panel-- so bit angry so far. Next day, he was posting this. So what happened there? The car was stolen, obviously. And this is actually one of the security incidents that happened over the past years several times, not just once.

      So what really happened here? It turns out that behind this panel here, if you pull it away a little bit, you will find a CANbus. And this CANbus is not only controlling the front lights but also the doors. So somebody got in, unlocked it, got in, drove away, car gone.

      As I said, this is not just a single incident, but this is one of many that are appearing over and over in the past years. You see here the number is actually staggering, 150% plus in the last year. And the ramifications can be anything. It can be-- for this individual person, it's a safety problem. The lights are not working. It's a financial loss. The car is gone. For the OEM, it could be brand damage. It could mean stopping the car. For suppliers, it could mean penalties. So this is really a big problem, and security is shaking up the automotive world.

      This is what I want to talk about with you, and these are also going to be the takeaways, ideally. I will start with number one, showing why security is not mandatory. Perhaps all of you already know, but it's really urgent right now. Then I will explain why agility and consistency in your workflow is actually really important. And then in the third part, which is probably the main part today, what can you do with the tools you already have to improve compliance?

      So let's start with number one. Security is now mandatory. Today is May 7, 2024. You have 55 days to become secure. What happens then? There are two new UN regulations-- the infamous R155 and R156. They mean the following. The first one is about having a cybersecurity management system, so it's about the processes. Be ready to react if something happens to your car or to your components.

      The second one is about shipping updates and how you ship the updates to the cars. The interesting bit is here that both of these regulations are actually mandatory for type approval. So you cannot sell the car if you are not complying to those two. Some cars already had a production stop-- some names here on the slide. And sorry, some of you may be flinching right now. This is my car, or my component goes in this car. By no means does it mean that these are bad cars. It just shows how sudden those regulations came and how complex they are.

      But of course, there are more regulations. I will not bore you too much, but it's important to get the big picture. This is the R155. So this is about having the system in place, how to detect incidents, react to it, and also figure out how big is the impact of this hack? Then the R156, as we said, is about shipping the update. So here we're talking about testing properly, preparing the updates, sending it. And you see they're actually overlapping already.

      And now comes the big chunk, ISO 21434. I'm sure all of you know 26262, which is for safety. This is the cousin for security. And again, you see some overlap. So it also talks about security testing, impact assessment. But more, it also talks about the security of the toolchain so MATLAB Simulink in your case maybe. And of course, there's even more. There's the enterprise security, the security of your facilities.

      But we will not talk about those today. The main point is all of them have to be addressed together, so it's really a large task for all of us. For this talk, I will stay mostly in this. So we will do the embedded security, not the backends, not the IT security. I will show what we can do for the car, for the components.

      So let's get to the second point. Why is agility and consistency so important? We have seen we have to do it. And my thesis is this is what we need to look at first. Why is that? Back to the DevOps eight. We have seen it several times today. There's no way around it. For security, it is even worse. It looks already like an infinity symbol, and this is exactly what it's doing.

      So for security, for example, you will have to think initially about the attacks on your system. What could be done? Then you will implement this, and I'm sure all of you have many variants of your code, not just one. You have to implement all of them. Then you're going to test it, and your builds may fail. Then you may find during security testing that some of your controls, your countermeasures are not perfect. Then you may find light defects. Finally, you might actually have everything in place and go for the certification, the type homologation in this case, and ship the update.

      So far, so good. But now somebody comes and uses one of the missed weaknesses and attacks your system, like the guy in the beginning. Who could have thought that you pull away the front panel, and you will find the bus? And the bad thing is it's not just one person. It's probably many, many people at the same time. And they can use everything which is available-- cloud, artificial intelligence. They don't have to look for regulations.

      And then it's your turn again, seeing that you are being attacked, feeding back this information. And now everything restarts again. There's a new thread. You have to understand it. There is now an additional variant you have to manage because there's an update, so it becomes more and more over time. And I'm not even speaking about possible attacks on your supply chain. So maybe the bad guy is sitting in here. That could also be.

      So what does that mean for development teams? It really means two things. You have to be quick in shipping updates to limit the damage, but everything you do has to be of high quality, speaking of consistency, which we have seen several times today. And therefore, these are the two things we should be really concerned with, being quick, being consistent.

      It's even worse. The standards itself, they're really complicated. Don't try to read that, but this is a dependency graph of ISO 21434. Each of the little dots here, they are requirements. Everything in between the lines are the dependencies. You touch one thing, and many other things need to be updated. It's a nightmare. Everything that is red is a design loop, and we have seen many of those loops this morning. So that means everything you do should be as good as possible to minimize the number of iterations. Otherwise you are lost. It becomes unmanageable over time.

      The good news is you already may have the right tools, maybe not for 100% full guarantee. But you can use the same tools as for ISO 26262 to have a faster compliance. So speaking, for example of the reference workflow, which you may be using already, MATLAB Simulink, verifying the code with it generated, that will not change. If you use it the right way, you can cover essential topics, have this consistency, and reduce the number of iterations. And that is now what I want to share with you in more detail. Let's look into the tools, some specific examples, how we can actually overcome these challenges.

      The first obvious thing, of course I have to mention it is model-based design itself. So it's really a perfect match for cyber security because it has different methods which come all together in the same framework, and we need those methods. Behind all of that is the digital threat. We have seen that today already. But just to give a rough definition, it is sort of a framework to track all the artifacts and the tasks that they are doing and not just during development but across the whole life cycle.

      So you update them. What are other artifacts do you need to look at-- exactly the graph we had before. The digital threat can tell you these things. And this is now really good because now we can take different methods, run it in the MBD environment, and see which parts are dependent on each other, which parts need updating. So, for example, we can actually figure out the impact of an attack leveraging this digital threat.

      So this guy here, maybe this is the front bumper. And now you can go back and formally figure out which parts of your system are possibly affected. You can simulate the attack if you have models in place. You can analyze the code. You can analyze the models. All these things play together. And last but not least, you can, of course, generate updates. Everything is fixed in the model. You press the button. You have code. It's much quicker than doing it manually, of course. So that means model-based design really brings them together, speaking the same language. And this alone is a big efficiency boost-- very high level. But now I will give you more concrete examples even.

      Let's start with one of the very important methods, which is the threat analysis and risk assessment, also called TARA. So the goal of the TARA is to actually anticipate, figure out how your system could be attacked so that you can actually design countermeasures into it. Most people actually do that in Excel these days. So it could look a little bit like this. You have a table here, which lists all the threads, which lists the damages, which essentially computes the risk.

      And then if it's too high, you have to create a requirement, which you write down here-- linked goal. And somebody gets an implementation task-- for example, encrypt the bus. So this is how TARA works in essence, but it's disjoined from the design work most of the time. It's Excel. It's not in your model. It's not in your code. And this is now one excellent example how all the methods come together.

      If you have a tool like System Composer, where you can have your architecture, already defined with some types, with connectivity, with interfaces, you can actually leverage this. So we swap Excel now for something new. This is called fault analyzer, specifically safety analysis manager. We will see more about this this afternoon. And also outside, there's a nice demo booth for that. It looks like Excel, but it's not. You see the little symbol here, the link.

      So the first thing we do is we go in the model here, and we mark those things which we need to protect-- for example, the front lights, an encryption key, the signal for the brake pedal, all safety critical. We mark it as an asset, and then we can start, press a button. And it will automatically populate the table and linking the table crucially to the model. So you have something here. You can go back and forth. It's like Excel but much better because now it's integrated.

      The next step, we need to figure out the risks. And because it's MATLAB, which is behind that, we can have a risk matrix, and we can automatically help you to calculate the safety impact, the operational impact, privacy impact, whatever you want. So you see actually this column here is now no longer a manual input. It's calculated for you based on a specific algorithm. The next step, of course, since we are in MATLAB Simulink, we can also have static checks on this table. So for example, here it can tell you this risk is too high. You need to do something. And then you know that you have to define a countermeasure.

      Last but not least, the countermeasure means there is now an implementation goal requirement, which again is being linked from the table back to the model. And now we have a closed loop. Everything is consistent. You change the system. It will tell you which parts of the table are probably stale. You change the table. It will tell you which part of your systems are stale. Now it's consistent, and now it's efficient because you're not going in between different tools.

      And because it's so important, allow me to give one more remark on the TARA. It's the key method for security. So it's often tailored to company needs. There cannot be one TARA for all of you. Each of you will have a different definition of how risk is calculated, how much risk you accept, and when the user needs to see a warning. So the tables need to be configurable. The calculations need to be open, so you can change them. The risk matrix needs to be configurable-- the types behind that. How many impact levels do I have needs to be configurable-- and of course, also the checks we talked about. And that's easy in a closed design environment. So all of that is possible here in model-based design.

      This was example one. Example two, let's say we are completely satisfied with our architecture, and we go to implement. Now we have to figure out, is our implementation actually robust, or did we introduce additional weaknesses? So you can do things like testing, maybe fast testing, pen testing. And that's good, but it finds things rather late. What we can do instead, we can leverage the analysis capabilities in the model-based design framework.

      So specifically, again, just some use cases, when you generate code, there's a button you can press. And it will figure out which parts of your code are potentially exploitable. For example, there are memory errors. There are known security weakness patterns in there, race conditions, et cetera. So you get a counterexample, almost like a debug trace telling you step one, step two, step three. This is how it could be attacked, and then you go and fix.

      You can do it with requirements. If you write them in a certain way, you can actually figure out if the requirements have contradictions. Really interesting if you have security and safety requirements, which typically after some time they will contradict. You can check this. Of course, you can do it on models. You can find all the interesting parts, like which parts of my model are not even active? Maybe I can remove it. Or where am I exceeding expected ranges?

      All in all, taken together, these analysis capabilities are really good to minimize the vulnerabilities. And if you do it right, you can really have these three properties down here-- memory safety, robustness, and, of course, consistency. It's not an easy path, but it's completely possible. And it's more efficient than testing. And by the way, this also works for handwritten codes. So if you have some legacy code, you can still do this. Not everything needs to flow through Simulink.

      One more example is the Software Bill of Materials. I'm sure some of you have heard of this. What is it? It's basically a list of components in your software, and this list is later used if you are attacked to figure out which exact component is in which car so that you can see if this car is vulnerable and needs to be patched or not. And it's a really important method or artifact rather to communicate across the supply chain. Knowing what has the tier one put in this component and this component in which car is it is really crucial to figuring out what needs the updating.

      The good news is model-based design-- again, we have the digital thread. We have MATLAB Projects. If you take them together, this is your SBOM. You just generate it. And this will then, of course, be in the right format, like here, for example, CycloneDX. But it could also have a different one. It can filter. It keeps up to date. And it should not be manual work-- again, another way to have automation to have it consistent.

      Coming back to what the previous speaker said-- updates. This is a more in detail view on how updates could happen on the system. We already know updates must be fast. They must be consistent. Here's one example, another one, how we can leverage model-based design. So let's say we have a vulnerability in this system here. MATLAB has a dependency graph between all the artifacts and subsystems. It could look like this. So the first question I could ask, which systems are affected, which is really good because only those would go for recertification. We remember this R156-- type approval, updates. Keep it minimal, and this is how you can do it.

      Even better, if you know that this file is modified, you can look inside. And if you know that these two signals have been modified, you can even trace it down and figure out that this subsystem also needs testing. This does not. So it's a way to really minimize your testing efforts and to increase the efficiency when it comes to the updates-- less bargaining with the authorities in essence. Of course, you can automate this. Just to mention process advisor, here is one way to do that, which knows about the dependencies and then enables things like incremental verification. Yeah.

      Coming back to the beginning, could we have avoided this situation? Well, perhaps. As we have seen, we have many methods to model-based design, which can help us to build more robust systems. And this is certainly very good to avoid many attacks, but we cannot be complete. There will always be a new attack which we did not foresee. And therefore, it's really important that we cannot only find things as much as possible but also update as much as possible. And both of those I have shown how you can do it in model-based design. And I believe this is really going to be a market differentiator over the next years. Otherwise, your security will make it a really complex and endless task, and you will have a lot of damage to you maybe but also to the end users.

      In conclusion-- so we have seen three things today. Cyber security is here at latest now you know, 55 days. You can use your existing tools to get some things pretty much for free. And of course, you can automate these things. As always, there is much more. I only managed to talk about three things, but you can also simulate attacks. You can also figure out adversarial examples if you are using image recognition techniques. You can build intrusion detection systems and even prevention systems with model-based design. All of that is possible, but there's no time to do it right now. Just find me outside if you want to discuss this.

      One thing I would also like to reiterate, the previous speaker told very clearly that we are open to collaboration-- the same thing here. It's a big task ahead of us, not just for you, also for us. So let's go through this together. If you have ideas, wishes, just talk to us, and it will make things much better over the next years. With this, I'm concluding my talk. Back to you, Robert.

      OK.

      [APPLAUSE]

      View more related videos