Cybersecurity for Automotive Embedded Systems - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
      Video length is 50:55

      Cybersecurity for Automotive Embedded Systems

      A technical overview on cyber security challenges and solutions in the automotive domain. See state-of-the-art tools (Simulink®, System Composer™, Embedded Coder®, Polyspace®) and methods for risk assessment and mitigation of security threats. Highlight the strengths of Model-Based Design to attain security across all stages in product life cycle management and satisfy important requirements of ISO®/SAE® 21434 and UN-ECE WP.29.

      Highlights:

      • How new automotive security standards impact products and processes
      • How security and safety considerations are (or are not) related
      • How to find common security flaws in early design stages
      • How to follow secure coding and modeling guidelines
      • How to assess cyberattacks (e.g., attack simulation, impact analysis, taint analysis)
      • How to implement intrusion detection systems and continuous monitoring (VSOC)
      • How to integrate analysis and simulation through Model-Based Design

      Other topics covered: attack taxonomy, shift left, intrusion detection, attack simulation, static analysis, taint analysis, vehicle security operations center, secure coding/CERT® C.

      Speakers:

      Sonja Krzok works as an application engineer at MathWorks, focusing on real-time simulation and testing. She holds a BSE degree in electrical engineering and is currently pursuing her master’s degree in cybersecurity. Before she joined MathWorks as an application engineer in 2019, she worked for in-tech GmbH as a product manager, where she was responsible for modular HIL systems and acted as a team and project manager for hardware and software development projects. Prior to that, she worked as a development engineer and gained experience in modeling, simulating, and implementing real-time systems, mainly in the automotive industry.

      Martin Becker is an application engineer for verification and validation workflows at MathWorks. He has more than 15 years of experience in embedded systems development and holds a PhD in static analysis and verification of embedded software. In his daily work, he supports customers in a wide range of industries to efficiently produce embedded software while meeting safety and security standards.

      Published: 8 Aug 2022

      And we are working on verification workflows, and this also, of course, includes cybersecurity, and that's our topic for today, cybersecurity in the automotive world. And with me here today is Sonja. You want to introduce yourself?

      Yes, my name is Sonja Krzok. I am as well an application engineer working with Martin in the Verification and Validation Team. And I'm focused on real-time testing, but besides that I'm currently also pursuing my master's degree in cybersecurity.

      OK, so let's get right into the topic. As I said, today we will talk about cybersecurity in embedded software, specifically automotive one, and we will talk about the whole process from paper to the product release. And this means we will not about hardware since this is about the software only, also not about the back ends or about the OTA updates, which some of you may be involved with. We just focus on the embedded devices here and, specifically, the software development phase.

      And questions we want to address in this webinar is how is this cybersecurity related to safety and also how can you address the standards. And this, for example, means simulating attacks, assessing the risk, and also, of course, introducing countermeasures in your system.

      And all of that is today the focus with model-based design, but if you are a hand-coder, if you're writing your code manually, don't just go away. There is also something for you in here which you can use.

      OK. Let's start right here with a little demo. On my screen you see Simulink, and this is a Simulink model. You see there is a controller in here and also a plant model, and they are connected via a feedback loop which goes via a simulated CAN bus. And now I can simulate the system here in real time. I can turn it on.

      This is a motor which we are simulating, so I turn the ignition on. And I can play a little bit here with the knobs, and here what I'm trying to do is control the velocity and now you see at the top left there is a hacker in the system. And this hacker now-- I can turn him on, and this will actually simulate an attack now on the system.

      And as you can see, immediately we lose control of the velocity. Even if I turn the attack off now, it doesn't recover, which is a bit surprising in this case, but that is how the system is designed. So last resort-- turn off the ignition. And now you see, slowly, the motor is recovering, the velocity is coming down. And now if I turn ignition on again, I'm fine. I have gained back my control.

      OK. So this little demo here-- it leads us to a few questions. Of course, this shows a simulation, but around the simulation we have many aspects we have to look at. And there is, for example, how can we ensure that a system doesn't react like this? You have an attack, and then even when the attack is over it just keeps being in the faulty state, how can we be more robust?

      And also the second question about these attacks-- I simulated an attack here, but how do I know where to simulate it? And actually how can I do this simulation? And last but not least, of course, what can I do to actually prevent that I get into this issue before I even have the system?

      OK. So that was a very quick intro. These are the topics we will discuss today, and just taking one step back to talk about the issue of cybersecurity in the automotive sector, why is this actually important? And I'm sure many of you are aware there are more and more attacks on cars. This one, for example, already two years ago now, hackers were able to turn your traction control off, which is, of course, a bit scary.

      And this, for example, is a list of published vulnerabilities from 2018 which affected a lot of ECUs, a lot of cars. Therefore-- and many, many more. So we see it nearly every day now that we have some vulnerabilities in some software which also affects cars, and this means this topic of cybersecurity-- it's at the least very scary and publicly visible, but there's actually more than this.

      Let's look a bit closer on these attacks. And actually, as it turns out, the embedded systems which we are designing, they are the largest attack surface or, in other words, these are the most common reasons why systems can be attacked. To give some statistics-- this is brand-new. This is merely a week old from Upstream Security, and they looked at the incidents from the last 10 years, more than 900 incidents in automotive systems.

      And they tried to figure out what is the entry point for an attack, and here on the left-hand side you will find all the embedded entry points. So for example the keyless entry system, ECU, the telematics gateway, and so on. So these are things which are very likely to be attacked, and these are involved in 58% of all attack vectors we have seen. So that means if we can make our system more secure here we have gained a lot of security.

      On the other hand, right-hand-- this is what we will not talk about today. So this would be more of your back end, your IT, maybe the apps. That's not the scope of this session, but we will talk about the left-hand side.

      Yeah, so this now poses a lot of questions, and these are typical questions we get from customers. How can I satisfy security standards and guidelines? And that's, for example, the ISO 21434 which we'll come to. How can I measure security? How can I detect those vulnerabilities? And many, many other questions.

      And all of that actually comes to the main question-- where should I start? And also, do I need new tools for that? And that's what we want to show today, and we will also show that the tools you already have, i.e. MATLAB and Simulink-- they can do a great job of avoiding many of those vulnerabilities already today.

      So now, actually, we have too much content for today, and therefore we want to start with a little poll. And this poll here on screen will now be started by Benjamin, and we will then look at your response, and whatever is the most important one for you we will start with this topic and then go as much as we can to the others.

      So Benjamin, can you start the poll for us? Great. OK. You just--

      Now you should see the poll results.

      I make it very simple. I just open the SlideShare, and I type what I see. So 52% has said A. We have 39% here. We have 39% here, and we have 22% here. OK.

      30% is the last one, I think. Oh, no, no, no, you're right.

      No, actually, you're right. yes, 30%. 20% did not answer. OK, great. So this looks like a plan. We can then go over the topic exactly in this order. We start with the concept, and we dive into the design. And if we have time, we can also go to the remainder here and look a bit more on fuzzing and attack simulation.

      OK, so let's start with the system concept, and that is, I believe, Sonja's part. Is it?

      You're right. So let's take over sharing my screen.

      Can assign to you.

      Looks good. OK, perfect. Right. So yeah, basically from the poll you already had an idea of the agenda of today. So we will get started with why safety is not enough, so basically also to get a common understanding from what we understand for safety-related and cybersecurity-related topics. Before we then go next to the topic cybersecurity and what model-based design can do for you and then, according to the poll, integrate the different steps.

      So to gain a common understanding of cybersecurity, let's start by asking us, what is cybersecurity, and why is it so special? So towards this-- let me propose an intuitive definition of cybersecurity which also shows its relation to safety. The definition will suggest why our current workflow are insufficient to deal with cybersecurity.

      So let's have a look at a system or product. This is imaged by that gray box here. And there's a fault. In the context of safety, we want to protect the environment for the failure or hazard that can happen caused by that fault.

      Talking about security, it's the other way around. We have an attacker from the outside who wants to have access or gain access to our system or product to maybe introduce new behavior to our system or product which could give him maybe the possibility to get access to information about our product.

      But also there are a lot of other ways with this gaining access to the control of the system which could lead then to a failure or hazard or even with the new behavior and causing any other fault which would be then affecting our safety itself.

      So seeing here basically the context of both safety and security. We see that security prevents the abuse of the system and safety prevents hazards. We've seen from the introduction that the number of attacks is rising, and in contrast, in the safety world, faults are mostly due to reliability of physical parts. The new behavior, which can be introduced by any attacker, often corresponds two unknowns that we have seen in the attack scenarios in the intro.

      And this explains why security is such a difficult topic. The new behavior can completely deviate from the original semantics of the system, and therefore it's difficult to predict this new behavior. For example, the attacker could inject new code but then, of course, can implement new functionality that has never been subject of a safety analysis. And consequently security is necessary to attain safety, and its analysis needs to consider safety concerns.

      So with security, there are a few new tasks coming, maybe to you well-known safety tasks you already know. So looking at the V-diagram, we have to cover tasks to gain safety, like design a reliable system and for failures and focus on what is known and rigorous testing. Compared to developing our product secure,

      we have to design for malicious attacks focus what is unknown, what could be introduced new to our system, and incident monitoring and updates, and a lot of more tasks.

      To handle those, there are mandatory regulations for the whole supply chain. So for example, the UNECE, which covers cybersecurity principles and how to handle threats and mitigation. The standard applies to everything with four wheels or that has at least one ECU like cars, vans, buses.

      With 2022, it is mandatory for type homologation to cover those and also then coming with 2024 for all new vehicles manufactured. So OEMs are required to demonstrate that the processes include identification and management of risks as well as clear measures which monitor, detect, and respond to cyber attacks.

      And also, since last year, 2021, there's a new ISO standard, 21434, for road vehicles and cybersecurity engine for road vehicles basically. And this is seen as a reference implementation of these CSMS for vehicles. Basically it describes, in the development process, how to deal with cybersecurity risks and a state-of-the-art defense against liability.

      OK. Next, let's see what model-based design can do for you for cybersecurity. Now that we have a common understanding of the challenges to the commerce security, let's have a look at the V-diagram and what model-based design can do for you here.

      So we take the V-diagram here through the whole presentation and going through the different development stages.

      Starting with the system design, which will be our next topic, they are also related to different methods like threat, risk assessment-- we will have a look at those-- then going to software design, and coming with this secure modeling, and how to implement countermeasures, going then to software implementation, and how you can generate secure code and also test then your code, executing code-level security and robustness analysis, and going on the right side on the V, how you can test your software with tests like requirement testing, fuzzing, or simulate attacks, and then also on integration tests, and how you can test your system.

      OK, so there are known key practices for cybersecurity. First, cover the knowns. So you want to have a consistent security architecture and provide evidence of compliance and robustness. Then, second, cover the unknowns, talking about isolation and resilience of your components and also about monitoring and intrusion detection.

      And then third, anticipate updates, how you can manage this complexity and the different involved dependencies and also-- and quick incident response. These key practices are well-covered by model-based design, so basically it allows you to have a digital thread for requirements, to execute your vulnerability analysis, simulate attacks, and also implement your countermeasures, but also to cover the unknowns.

      You can therefore, in model-based design, apply your security design principles, design, train, and deploy, for example, intrusion detection systems. But also it allows you to have it quite modularized how you have implemented your system and design, reuse and analyze your changes, use automatic code generation to implement your design and really quickly update if there are changes or updates. And all these topics allow you to really then manage the risk, which is centric for cybersecurity development.

      OK. Let's get started with the first topic, the system design. At this point, we assume that the part of the requirements are already defined, and our task here is to come up with an initial system design to perform a threat and risk analysis and allocate newly deduced requirements.

      Therefore the methods-- we will have a look at our threat and risk assessment and also how to allocate security requirements. OK. What you see here is our Tool System Composer. You can see it as a digital drawing board if you want to, and it allows you to go quickly from paper to model. So maybe you're familiar with UML or SysML . This is quite similar to this.

      And the terminology of the standards-- we can use it to refine the architecture of our system and cybersecurity items. So let's start this quick video to see how you can draw your architecture, easily add components, connect your components with each other-- oh, that was too quick. Sorry for that.

      So you draw your architecture. You can create connections to set it up. You see it's quite easy to edit those connections and also then the items itself. Right. Then on the component itself it's easy then also to decompose it into several subsystems and then again propagate, for example, the interfaces here.

      There are a bunch more capabilities like adding stereotypes to that. Also then we will talk about later linking it to requirements and so on. This is a starting point to have like a hierarchical design with methods for refinement, modularization, and reuse.

      This is also mentioned in the new standards, the ISO 21434 requirement 10, you see. And we have mentioned the related requirements in the left corner here, and the tools I'm talking about you will find always mentioned on the right corner on top.

      So the result of the first step is not only a graphical representation but also you can define arbitrary stereotypes, as I mentioned. And this top-level model can already be used then as a basis for simulation.

      OK, next to the standard, it asks us to perform a threat and risk analysis. This process itself is rigorously defined in the standard like ISO 21434, and is mostly done manually because it requires expert judgment, typically a group of experts, and therefore I only explain this part briefly.

      So there are several approaches to TARA, for example, starting with the asset-centric approach, for example with attack trees, working out a step-by-step plan to obtain or control an asset by listing the condition and alternatives to arrive there. Then second, the design-centric approach-- to identify paths to be protected. For example, identify attack surfaces such as debug ports or network interfaces, and may also consider weak elements in the fault tree.

      For example, if you have the weak safety limits, those are often interesting. And then to attack, such design-centric analysis can be done by static analysis of the model, and we'll show an example of that later during the webinar also. And then also a attack-centric-- based on profile, like of the attacker, skill, money, capabilities of the person who attacks.

      And common to all approaches is some kind of risk qualification based on effort of usability and on harm or consequences. And this is usually called then risk matrix. So for example, if the system is vulnerable to an attack that might result in a life hazard, the risk is unacceptable and must be mitigated.

      Then this can be highly subjective to put a number on aspects like motivation or skill of the hacker itself. Such classification is usually done in categories instead of real numbers, , and this is illustrated here. So this eventually allows us a prioritization of risk and to derive security requirements that impose protection. Each requirement has a cyber security assurance level, which defines the level of rigor to be applied in verification.

      OK. Then, coming next, requirements playing a key role in the standard 21434. You can see here from the whole and process. And once the security requirements have been derived, they need to be allocated and tracked throughout design because even the best requirements are futile if there is no proper mechanism to ensure they are satisfied during the implementation.

      Note that security requirements are the realization of security goals which means we can capture the security goals as requirements themselves and reach full traceability. And additionally, we also have to ensure we create our input requirements that are imposed by standards or best practices. And those, for example, can be enumerated threats or requirements such as only allowing zero-knowledge encryption, and these play a central role in fulfilling the standards.

      So therefore we also need to have means to track the implementation, and a handy way to do so is to import them as requirements and keep track of their consideration with our tools-- so you see here already a few in the Requirements Editor and also like Status-- if those requirements are already implemented and if you verify them later and during testing.

      Additionally, we have captured the outcome of the TARA and requirements. This is an easy process also in model-based design, and the requirements manager supports this activity. And also it allows you with the ReqIF interface to connect with commonly used and requirements management tools.

      OK. So this is what I mentioned before. Starting with the architecture and System Composer, it easily, you have seen, with one click allows you to then export this architecture to Simulink, where you can reuse it then for your design in Simulink.

      OK. So we already come-- yes?

      Quick interruption? Before we jump into the next section, there has been a question in the Q&A exactly about what you have shown, and that is, in which tool or environment is the threat and risk assessment performed?

      Good question if not the question. So here in MATLAB and Simulink you have all the things you need to do a threat and risk assessment. However, there is no ready-to-use tool for that since there are many steps in risk assessment where you just need expert input.

      For example, what Sonja just has shown is to calculate the impact that is not something which has a strict formula, but you need an expert, same for feasibility. You need an expert to tell you how likely it is to perform a certain attack, how to turn a threat into an attack.

      And for that reason we do not have a ready toolbox for that, but you can allocate all these metadata on the model. And one way to do this-- to do this is to treat these attacks and threats as requirements, and you can have custom type requirements. And then you can allocate it as you would with usual simulator requirements and can see which parts of the systems have threats allocated, which threats still need to be refined to attacks, and which of them are being treated by a counter attack or not.

      So it can have this threat and risk assessment captured in the tools, and that is, as we have seen, Simulink, that's the System Composer, and that makes then also use of the Requirement Toolbox. But there is not, let's say, a Risk Assessment Toolbox because that would make no sense. There are so many steps you have to take on your own, and also the standard leaves it open to which methods you're using.

      So for that reason, in a nutshell, this is a do-it-yourself thing. We have all the capabilities there, but you have to make use of them to come up with your own process how you want to capture risk. And then once you have done this, model-based design can make sure that all the threats, and attacks, and countermeasures you have treated are actually-- they're visible for the designers so that you do not miss anything for implementation or you don't miss anything in terms of risk assessment. That's what our tools can do.

      Thanks. OK. Yeah, so let's dive into the software design, to refine the system design and the security concept from the previous stage. At this point, I assume that most of you are familiar with MATLAB and Simulink, and therefore we will not show how to build and refine models.

      We, of course, have tools and features what help you to modularize and allow reusing components, detect clones, and so on. And of course, all of that continues the support of allocating and tracking requirements we have seen in the previous slides.

      So let's assume we're in the middle of the design phase. What can we do for security beyond that? We will have a look at the methods of secure modeling and countermeasures.

      So a goal is to have that "shift left", so having an early development stage, already those security checks on model level. And there are guidelines and analytic proof to do so. So again you see there's a tool called Model Advisor, and you can leverage this tool.

      It basically allows you to identify, discourage blocks, non-determinism, and design flows. So you see here on the right-- if you look at the Model Advisor, there are a lot of checks you can apply to your model to be proven and then to verify different stages in your model.

      The results from executing those checks in the early level are that you can prevent most frequent design flaws. You can also prove absence of unsafe operations or prove user-defined properties. And your generated code from the Simulink model will be then more secure. And a nice side effect of that-- it allows you then also that your model is compatible, for, for example, smart fuzz testing.

      Let's have a deeper look at the requirements validation. Traditionally, this is done at a later stage in the development cycle, but our tools enable you to validate your requirements early on to keep the development synchronized to the requirements and avoid then late surprises in the development.

      The traceability between requirements, and design, and the generative code, and test cases is provided for documenting the requirements if those are met and understanding the impact of changes and also bidirectionally then navigating between linked artifacts, And also then at the end, to have all this information exported into a report.

      And note if we treat cybersecurity goals as a special type of requirement, then we can use Simulink requirements to check whether each goal has been addressed and whether a direct requirement exists for it or not, not only having those tools here to manage the requirements, the implementation, and checking the traceability. There is more to have a look and analyze those implementations.

      So for example, those dashboards allow you to manage, let's say, the complexity of the models and your integrated design. So we had the topic model and library reuse, also then to analyze your model and detect, for example, clones or certain patterns, that you can leverage variant subsystems or different versions within Simulink. And then also the isolation of security domains, so using model references to separate certain implementations and also that, for example, each domain should be robust and all context.

      And this is done by tools-- like we have seen the Metrics Dashboard-- this is the few you see here in the right corner-- but also then tools like Clone Detector that allow you to find those.

      Then regarding the traceability, you can create there a report but also have inside the tools already the feedback for example you see here the implementation and verification status. So if you have your requirement defined, if it's implemented in the model, so linked to a state or an component and then verified by test case and you see-- as soon as you have executed the test case, you get direct feedback if this test case was passed or failed.

      The other part of the picture here is showing that you can also navigate from the Requirement Editor to the Test Manager and to the code. So the bottom right there is the traceability matrix, all of them, and the Requirements Editor that can be used to generate a matrix between any two artifacts you select, so for example, between requirements and test case.

      OK. Before we continue there's again a question on the section. So here the question is, which checks are specific for ISO 26262 and cybersecurity in the Model Advisor?

      OK, so I take it-- here what we have seen is that this early analysis on the model is early analysis to support cybersecurity because they allow you to set up your model for secure coding, first and foremostly. You are well aware, I guess, of our capabilities for ISO 26262, so there's all sorts of advisor checks to get you get there. And that is, for example, which blocks you are not allowed to use because it would create MISRA problems and also blocks which are not deterministic in implementation.

      And as it turns out, there is a huge overlap with cybersecurity, and for that reason, if you go to the model advisor and you activate the checks for secure coding, it will then do very similar checks, do a few on top to minimize the third C violations you will get. And I will give you a link later on where you can have a look at the specific list of checks because it's too long to elaborate those now. But you can think of it in a very similar way as for the safety.

      OK. So I will stop sharing and hand over to you , Martin again for the next part.

      Yes. And I guess it's also the last part before we have to leave some space for questions. I'll just click-- so here we are, back in the presentation. And now, before we actually jump to the last two elements, the coverage and the summary, we have a brief look at the bottom of V. And this is about software implementation.

      And now, if you are a model-based designer, this means you press a button and you get code generated, which then, if you have used the Model Advisor we have just discussed, would be more secure. It would have less violations. But if you are a hand-coder, if you are not using model-based design, you can still use what we show here in the next second. And this will be about showing compliance to third and security addendums but also talking about the CWs, the common weaknesses, and about how you can get proof for your robustness.

      So before we actually talk about why we should analyze code, there is a very common question, and that is, how can I generate more secure code. And this is what we actually-- what I just answered verbally. So the Model Advisor has checks, and, in fact, you can see a few here now. There are modeling standards for Cert CCEE and so on.

      And here are some of the checks. Maybe this also already answers the question which are being done here on the model, and if you run those, note that this is not a guarantee that your model is completely secure. It's not a guarantee, but it will find many things early on. And the reason is because whatever the user is trying to achieve in the model will, of course, have to be translated to the code.

      So this user wishes, actually, they may create vulnerabilities, and this means-- so we can, of course, not just compile them away or put them away if we generate code. So these will then propagate to the code, of course, too. So for that reason the model advisor checks-- they will actually give you a more compliant code, but the final verdict-- whether your code is actually compliant, it depends on many things. And, for example, also there is user wishes.

      And that brings us to this whole step here. We should actually still verify the generated code, and now this is where it doesn't matter anymore whether you are a hand-coder or a model designer, but you have to answer the same questions. And that is, is my code actually compliant?

      And as I just said, if the model has a defect, the defect will also show up in the code because we're just translating it. But also another good reason to still look at the code and not only at the model is because you will use this code in integration with some other code. This might be boilerplate, third party, port support packages, low-level code, libraries you may be using.

      So all of that will be merged with the code from the model, and the questions down here you still have to answer according to the standards. Am I vulnerable? Am I still compliant to Cert C? And so on. And that means you still have to verify your code.

      Of course, there is another reason. So if you talk about certification, you know there is something like tool error detection, and that means, of course, if one tool early in the tool chain should have a bug, which is unlikely but could happen, then you would still be able to catch those bugs now with the source analysis.

      And this source analysis-- that is what I want to look briefly on with you right now. This is also called static application security testing in the security world, and the idea here is you want to check, first of all, the compliance, and that's what the standards want, CERT C, CWE, MISRA Security Addendum. Are you following those? Are avoiding typical mistakes?

      And the tool we have here-- this is the Polyspace tool. And again, whether the code is coming from model-based design or from a handwritten piece of code it doesn't matter. You need to show this, and Polyspace base can do it.

      And the other question you might want to ask is, OK, I'm compliant now. This is great. But is my software really secure? And I'm sure you all know that compliance does not necessarily mean that you're fully secure, but your Polyspace can also answer the second question. And there is a capability which can look for very common behaviors which can be exploited, and that's, for example, all the undefined behaviors like a pointer, which is illegally dereferenced.

      And Polyspace can take all of those and can actually mathematically conclude whether it's possible to exploit it or not, and here in this case we just take one pointer. Poly space shows the result here and says, OK, I found a pointer in your code, and I have mathematical proof, no matter what anybody is doing with the software, this pointer is always safe.

      I think this is a proof of robustness. This is a proof that you do not have a vulnerability in your code. And moreover, there's proof actually-- this is the same as if you would test your application with all possible inputs. So you have 100% coverage equivalent here just by analysis. You're not running the code. You're just analyzing it. And where this method, static application security testing, here becomes really attractive because it can find everything that has slipped through in the model earlier.

      A quick comeback-- so looking at the model advisor checks, which we have discussed briefly, what happens if I don't do the checks? If you ran Polyspace based on the generated code, and you didn't run the Model Advisor for secure coding, then something like this could happen. You get about 67 violations in this model here for Cert C. And obviously this is not compliant. You should fix before you hand out the software.

      If you run Model Advisor on your model and do what it wants from you-- and this is, for example, configuring embedded code in a specific way, avoid this block-- then the picture already looks like this. And this means 50% fewer violations just by running the Model Advisor and following the advice you get there.

      So this is the shift left we have been talking about before. If you have the chance, use this advisor. It will not make it completely compliant, as I said before, but it will make it much more likely to be compliant and reduce the number of Cert C violations you will get.

      A quick look at the Q&A panel-- do we have something?

      We don't have any questions.

      OK, good. So then let's talk about two very important points at the end, and one of them is specifically the coverage of the ISO standard. What can you do with our tools, and where do you need to get other tools maybe? So this is a view on the standards. All the boxes here are sections, and both sections here are the most common ones. You may know the concept phase, the development phase, and the post-development phase.

      Everything above here is really something that is ongoing, and everything down here is specifically dealing with the threat and risk analysis. And now, if you look at our tools, there are some of those parts of the standard which are definitely not covered. And I give you reasons why in a minute. For example, you also see already that we start with section eight. So section seven, and six, and so on-- this is about project management, definitely not something that MathWorks tools do, so it's not even mentioned.

      And then there is a spectrum of ways we can help. There are some tools which have a button out of the box where you just press the button, such as Polyspace, as I've just shown, and it does the security testing for you. But there are other parts where you have to do more on your side-- and this is, for example, the threat and risk analysis.

      So here, just look at the standard, and we colorized this accordingly. Everything that's blue here we have out-of-the-box solutions, and that is, for example, defining your items, allocating requirements, tracing those, handling design updates, of course all the verification activities. This is all we have already available readily to use.

      And then we have the others. This is what I mentioned initially, threat and risk analysis, steps you have to do on your own because the tool cannot automate this. It doesn't mean the tool doesn't help you-- of course it helps-- but there is no button which does it. And this is, for example, questions like, how could my assets be attacked?

      Well, there's no tool in the world which can tell you that if you draw this box, a certain type of attack is happening. You have to put your own expertise into that, and then you can capture this expertise in the tool. And that also, for example, means talking about risk matrices. We all know that MATLAB. Is very good with matrices, but of course it will not just magically come up with the matrix. You will have to tell the inputs for it, and then you can, of course, compute it.

      And now you see some boxes which are completely wide, for example my vulnerability management response or risk treatment decision-- well, these are things which have no coverage and for good reasons again because, for example, 8.6-- this talks about a rationale for not managing vulnerability, and again, MATLAB cannot give you a rationale. That's up to you to capture why you made this decision.

      OK. Before we come to the Q&A part, let me quickly summarize. One thing you have to keep in mind-- security is, of course, a very wide and large topic, and there are many different aspects. You can imagine as this game you might know as the Jenga game. There's a lot of pieces to it, and the whole tower is only stable if you have everything in the right place.

      And here it means you have to think about more. It's not just your design and your software. It's also the hardware. It's the users. It's the configuration. So these are things which can be more or less covered with many different tools.

      You could do some of those aspects in MATLAB Simulink, too, but definitely some of them are again out of scope. For example, the users here-- well, I don't think you can control any people with MATLAB and Simulink, luckily, but they are definitely one piece of the puzzle to make this secure. So it's a whole system of things you have to consider.

      That being said, there are many exciting applications we have for MATLAB and Simulink. For example, if you want to secure your communication and you're looking for some help, contact us or look at the File Exchange. There are many exciting projects already which deal with problems you may already have.

      So to summarize this and to come to the end of the webinar-- and then we can handle questions-- how can you get started? First of all, we haven't covered everything today. There are two more sections we could have covered, and that is the integration, talking about text simulation, but you have also seen it in the beginning. We could extend this with intrusion detection. So if you're interested in that, please contact us.

      And I guess you still have got a picture of how we can address most of the things. And the point here you should take home is that a model-based design is really helpful, because you have all this traceability, and you can link your artifacts. But also you do not need to buy new tools for everything. Whatever you're doing for ISO 26262, there is an overlap with cybersecurity.

      I hinted this before, but I can already emphasize this. If you are ASPICE compliant and you try to go for cybersecurity, then many of the processes you have can be just reused. There's a lot of synergy and also in the tools. So MATLAB and Simulink can support you here. You do not need new tools for everything.

      If you need more details, if you want to talk about the specific coverage of the boxes I have shown-- how can I do risk assessment, or how can I actually do intrusion detection-- please contact us. We can support you here in many ways. At the least we can tell you this is the toolbox you can look at. If you need more help, we also have consulting services which have also done projects already in this area.

      And with that, I want to come to the Q&A. Before that, actually, I think, there's a poll, right?

      Yes, there is a poll. Yes, do not hesitate to put on the poll if you want to be contacted by Sonja, or Martin, or anyone else at The MathWorks for speaking about your cybersecurity issues that you could have on your project. It's important for us to be in contact with you for these kind of things, and answering that question will help us to know who wants to be recontacted.

      Yep, Martin, I don't know if there is some additional question in the Q&A.

      I'm just looking. I don't see a new question popping up. But as Benjamin just said, if you are interested in pursuing a specific topic, there is not enough time today. Just contact us. We'll have a private chat about your specific needs, and then we can be much more detailed and show you the tool live.

      I see an additional question from Jürgen in the Q&A, Martin.

      I do not see that. Can you read it?

      Yeah, question regarding communication. We are interested in MACsec feature to secure communication on layer two of ISO /OSI reference model We are looking for any kinds of information about MACsec, including tools and devices supporting this.

      OK. I'll just assume this is the ISO OC layer model, and layer two would be the MAC layer. Sounds like it. Yeah, my first reaction is, this is pretty low-level. Mostly I would see that on the hardware side.

      That being said, if you want to do that in software, nothing stops you from doing that from our tools, but we do not have a dedicated crypto solution here. So if you want to deal with cryptography with authentication with any security on protocols, we have APIs you can use. But you will have to come up with your own solution or with third-party libraries to do that.

      I see another question in the chat. Sonja, do you want to take it? Sorry, in the Q&A.

      Let me check. Is there a database of attack and vehicle application? So basically, one of the things is the database for attack. We have roughly seen from the intro we started to have something like an attack library. This should be like a starting point of the most common attacks you know maybe from the standards like man-in-the-middle attack or maybe an overflow to find those. Thanks, Martin.

      So this is an example of how you could implement attacks and could give you a starting point. It's also meant like a library. So if you face new kind of attack scenarios, to then further implement those here. And similar for how we would create test cases and test harnesses, you would place them there and easily reuse them then in your different testing stages like for model in loop or even SIL, PIL or HIL.

      OK, so it's 11:00. I think we could wrap up here. Sonja, Martin, thank you very much for your participation today. To all participants, thank you for the question and for your attention.

      We will recontact-- we will recontact the people who ask to be recontacted. For those attendees, we should be able to follow up to you the presentation. Do not hesitate to contact us if there is any additional question coming, and I wish you a great day.

      View more related videos