Model-based design for Airworthiness Security Compliance | Next Generation Aerospace Series - MATLAB & Simulink
Video length is 38:51

Model-based design for Airworthiness Security Compliance | Next Generation Aerospace Series

From the series: Next Generation Aerospace Series

Overview

This 1 hr webinar provides a technical overview on security challenges in the aerospace and defence domain. The seminar will cover state-of-the-art methods for the mitigation of security threats. We will highlight the strengths of model-based design to attain security across different stages of product life-cycle management. We will also relate to important requirements of the DO-326 set.

Highlights

You will learn:

  • The impact of aerospace security standards on product and processes,
  • How to find common security flaws in early design stages,
  • How to follow secure coding & modeling guidelines,
  • How to assess cyberattacks (attack simulation, impact and taint analysis),
  • How to implement intrusion detection systems and continuous monitoring,
  • How to integrate analysis and simulation through model-based design.

Other topics covered: attack taxonomy, shift left, intrusion detection, attack simulation, static analysis, secure coding.

About the Presenter

Sonja Krzok works as an application engineer at the MathWorks, focusing on real-time simulation and testing.

She holds a B.Eng. Degree in Electrical Engineering and is currently pursuing her master’s degree in Cybersecurity.

Before she joined The MathWorks as an application engineer in 2019, she worked for in-tech GmbH as product manager, responsible for a modular HiL system, and acted as a team and project manager for hardware and software development projects.

Recorded: 9 Jun 2022

In this presentation, we will talk about how model-based design can support you in the development process to comply with airworthiness security. We will start with an overview on security challenges in the aerospace and defense domain, and which methods for mitigating security threats already exist today. Before we enter the topic airworthiness security, or cyber security in general, I'd like to provide some context about what we're currently seeing in some of the next-generation aerospace programs.

The next generation of aerospace programs go beyond individual systems to cover complex systems of systems. Efficient ways of collaboration among entities are crucial for these programs to be successful. Common working environments, including tools and methods, will enable collaboration and artifact exchange at different abstraction levels within all stages in the development lifecycle.

The systems of systems approach combines manned and unmanned systems, for example, combat aircraft and drones, to be more powerful than with individual systems. Aircraft and ground systems must exchange information such as location, direction, and other information used to control flight patterns. Systems that collaborate and share data across operations make it possible to work more efficiently. But this type of data sharing has also led to concerns about how to protect avionics systems from cybersecurity threats.

A quick overview of what we will discuss today. We will start by looking at current trends in aviation and what evolution we can observe. Then we move to cybersecurity in aviation, and we will see that these two topics are interrelated. In order to handle these newly introduced challenges, we'll take a closer look at what guidance and standards exist today. In this context, we will also look at how safety and security relate to each other. And this brings us to the main topic of today's presentation, what can model-based design do for airworthiness security? We will answer some questions like, how can I simulate an attack, how to assess risk, or how to mitigate the effects.

OK, let's get into the first topic, trends in aviation. We'll have a look at what trends we can observe and what impact they bring with them. So the change we're seeing is driven from many directions. First, there's a general trend of having more connected systems. This happens in aerospace with, for example, the new generation fighter programs that are no longer standalone fighters, but full ecosystems for fighters, plus loyal wing man as autonomous drones. Now, this is, of course, increasing the level of accessibility to some critical systems, adding security risks to embedded controllers.

Then second, autonomy. It's another mega-trend that is increasing risk due to the cybersecurity threats. Decision making is no longer an only human thing, so cyber security breaches can have a direct impact on systems' behavior and safety. Another trend is using more and more commercial systems for critical applications. Companies need to rely on commercial solutions to keep the market pace and be competitive. Commercial off-the-shelf hardware and software made their way slowly but surely into the segment. This is leading to usage of more powerful hardware as well as usage of Linux operating systems, and causing that the same microcontroller used for a flight control computer is also used for modem and software components of different criticality, sharing the same memory need to be secured.

All this leads to the fourth point I would like to make, increased regulation and standardization of systems and software engineering processes. We will go into more detail about the standards listed here in this presentation. Modern avionics systems often need to ensure that they are not only safe per DO-178 processes, but also that cybersecurity is adressed. Security concerns are driving avionics manufacturers to make the systems more secure. If cybersecurity attacks go unchecked, the avionics infrastructure, including systems deployed in aircraft, could become vulnerable to such attacks.

We have now seen current trends, newly introduced technologies in the aerospace sector. If we ask ourself, in this context, why cybersecurity is relevant right now, we can observe that these also imply potential vulnerabilities to our system. Those are just a few examples of cyber and electronic threats, for example, command intrusion and payload control, denial of service attacks or malware, as well as spoofing, replay, and jamming.

Let's talk through one scenario. For example, systems that connect avionics could spread malicious software, like air carriers and airports, related to the operation and maintenance of airplanes, could also pose vulnerabilities by facilitating the installation of malicious software in avionics systems. For instance, if we use electronic flight bags, which are electronic information management devices, those can be standalone devices, such as a tablet, or integrated with systems such as the flight management system. Previously, these devices had no connectivity to other systems in the flight control domain when an airplane was in flight.

Now there is a way to also spoof flight data. Airplanes rely on various forms of communication to perform key functions such as sending and receiving data related to flight routes, navigation, and landing. And these communication systems could be vulnerable to spoofing. So the process of disguising a communication from an unknown source as being from a known trusted source. Having a look at aircraft communication addressing and reporting systems, which are used to transmit messages from the airplane to ground-based users, for example, air traffic control, those are used to send and receive flight plans and other messages. Aircraft transmissions are unauthenticated, and plus, it could be intercepted and altered or replaced by false transmission. For example, unprotected aircraft communication could be spoofed and manipulated to send false or erroneous messages to an airplane, such as incorrect positioning information or bogus flight plans.

So what are the sources of these risks? Starting with cyber criminals. Criminal groups, including organized crime organizations, use cyber attacks for monetary gain. For example, criminals have used cyber techniques to attack ground-based systems and commit financial crimes against aviation-related organizations, including nation-state or state sponsored, and state-sanctioned groups or programs. They may use cyber attacks as part of covert activities to gather information about individuals or government organizations and private sector entities, but also terrorists, which seek to destroy, incapacitate, or exploit critical infrastructures in order to threaten national security or inflict mass casualties, weaken the economy, or damage public morale and confidence. But also insiders, entities with authorized access to information systems. We have the potential to cause harm intentionally or unintentionally through destruction, disclosure, verification of data, or a denial of service attack.

So there's a strong need to protect against, for example, interception or spoofing or replay attacks. And only then we can guarantee, for example, the integrity or confidentiality of a system to be provided. With these new challenges and new vulnerabilities, we see guidance and standards emerging.

To conclude what we just have discussed, I would like to comment on the importance of security and defense programs. The defense industry in general is going through a digital transformation, where the procurement model is completely changing. While in the past, defense companies owned technology innovation, they are now forced to acquire commercial products to continue being competitive. This is changing the product life cycles and opening the supply chain to new challenges.

New technologies and the concept of Combat Cloud, where everything is connected, is also opening possibilities for cyber attacks. The next-generation fighter is not a fighter, but an ecosystem that is ultra-connected. The Department of Defense is pushing a lot to complete the already accepted DevOps methodology to include security. If you claim to contribute to all the processes, such as CI or CD, you need to properly address at least some important parts of the security analysis process.

That brings us to our next chapter, what guidance and standards exist today? With emerging technologies, cybersecurity risk management is becoming increasingly complex. From an aviation cybersecurity standards perspective, there has been significant activity by both the European Aviation Safety Agency and the US Federal Aviation Administration. By the close of 2019, the only way that aviation systems will be able to achieve airworthiness certification is to comply with the recently updated EO326 and ED202. These new regulations are considerably more detailed and comprehensive in their approach to the management of cybersecurity risk.

So what is in the scope? The Department of Homeland Security describes the scope of cybersecurity as any identified effort directed toward access to, exfiltration of, manipulation of, or impairment to the integrity, confidentiality, security, or the availability either of data, the application, or a Federal system without lawful authority. And then International Air Transport Association sees in the scope of aviation cybersecurity the convergence of people, processes, and technology that come together to protect civil aviation organizations, operations, and passengers from digital attacks.

Having a look at the standards, the standard the DO-356 covers airworthiness security methods and considerations. So this document provides analysis and assessment methods for executing the process assurance specified in DO-326. These documents address the airworthiness security process and how it can be integrated into the safety process and supplement the current DO-178 process. DO-326 is the airworthiness security process specification. And this document provides process assurance guidance and requirements for the aircraft design regarding systems information security. So the scope of the standards is the protection of the airworthiness of an aircraft from intentional unauthorized electronic interaction.

We have here an overview of the different aerospace security standards and what they basically cover. We are focusing on the what and how, which is covered by DO-326 and DO-356. The airworthiness security process specification supplements the current guidance for aircraft certification to handle the threat of intentional unauthorized electronic interaction to aircraft safety. And it adds data requirements and compliance objective as organized by generic activities for aircraft safety. The airworthiness security methods and consideration provide guidance for accomplishing the activities which are identified in DO-326 in the areas of security risk assessment and effectiveness assurance. And it also provides specific methods for security risk analysis and network security domains.

In the course of this presentation, will address some of the specified objectives and the standards that are required to comply with airworthiness security. Some of you may already be familiar with safety-related processes and have now to deal with security as a new challenge. The question that naturally arises is, how do these two differ? Does maybe one compliment the other, or are there certain dependencies? And we're going to take a closer look at that now. Towards this, let me propose an intuitive definition of cybersecurity which also shows its relation to safety. This definition will also suggest why our current workflows are insufficient to deal with cybersecurity.

We define safety as the absence of hazards. So that there are no negative consequences on users and the environment. Whereas for security, we need to consider a safe and proper system operation in the presence of adversaries. So for example, an attacker might inject new code that then, of course, can implement new functionality that has never been subject to safety analysis. So consequently, security is necessary to attain safety, and its analysis needs to consider safety concerns.

So in order to build safe systems, the traditional safety approach is no longer practical. Regarding safety, the design is for reliability, and for example, fail-safe operation. We can focus on what is known, and one can say that it's built based on trust. For security, there are new aspects which need to be considered. For example, we need to consider to design for abuse and also malicious attacks. So also focusing then on what is unknown, and basically build based on zero trust. In addition, there's a need to monitor for incidents and also frequent updates.

So this is where we see again the direct link to the driving forces for these changes. We have new technologies introduced, and more software and more connectivity, which basically leads to a greater attack surface, higher risk, the need for frequent updates, but also introduces higher costs and a higher complexity.

So before the new standards like the DO-326 Set were developed and published, there were already existing guidelines and standards as you know. And we see here some named in this diagram. The reason that these existing ones are not adapted or extended can be explained, for example, by a statement in the DO-326. "Airworthiness security is its own discipline, needing unique expertise and requires its own analysis techniques and assurance considerations," in the sense that it's distinct from safety and from other security considerations.

So therefore ARP4754 and DO-178 had to be coordinated with, but they also had to be kept clean of cybersecurity issues. But also integrating information security into, for example, DO-178 was hindering. It explicitly excludes this option by a definition of the term "event." So the definition says an event is an occurrence which has its origin distinct from the airplane, such as atmospheric conditions. The term is not intended to cover sabotage. And realizing that maybe any change to those formal documents may delay the process encouraged to develop a separate document or several documents that would be tightly coordinated with ARP4754 and DO-178.

So now that we have a common understanding of the challenges that come with security and that it's different from safety, let us move to the next part, what can model-based design do for cybersecurity? We show the benefits of model-based design on the well-known V model, since this allows us to conceptually group our methods to different design scopes and stages. However, this does not mean that all activities are done only once and in exactly this sequence. In fact, iterations will be necessary. Some safety and security may contradict and require trade-offs.

The idea of today's webinar is to give you a first overview of the capabilities. And we will start at system and software design, and then we'll talk about secure code generation and how we can verify our implementation. When we look at some key practices for cybersecurity, we usually start by covering what we already know. But in addition, you must also consider the unknown. So we need to consider, for example, isolation and resilience of components in the development, and provide the possibility of monitoring and detection of intrusions. And third, anticipating updates. Model-based design enables you to implement these general key practices, either for vulnerability analysis, or simulating attacks, or applying secure design principles, or also training and deploying intrusion detection system, but also different modeling techniques like modularize and re-use and analyze changes. And this is what we will examine in the next slide.

Let us briefly look at system design. At this point, we assume that part of the requirements is already defined. Our task here is to come up with an initial system design, perform of threat and risk analysis, and allocate newly deduced requirements. You will get an idea how to use our tools to cover the security standard objectives. But it can be said, in the first place, that security analysis and design is not a one-tool job. Actually, a lot of the analysis has to be done manually, and it's really difficult to automate that step. We are starting at system level, and go over to the security scope, what enters into our security risk assessment.

The first tasks are to identify and document threat conditions and scenarios. The architectural design of our system can be done using System Composer, and together with for example MATLAB and Simulink, further analysis and modeling can be done. What you see here is digital drawing board, if you will. This is our tool System Composer, which allows you to go quickly from paper to model, similar to UML or SysML. It allows you to draw your architecture, and you can easily add components and connections, but also decompose it into subsystem and refine further.

Having a hierarchical design with methods for refinement, modularization and reuse is one quality that is important for cybersecurity. And is therefore also mentioned in the standards, for example, DO-326 and DO-356. The result of this first step is not only a graphical representation, but you can also define arbitrary stereotypes, flesh out the interfaces, and most importantly, this top-level model can already be basis for simulations.

Then coming to security risk assessment, which is one task the standards ask us to perform, threat and risk analysis. There are several approaches, in aerospace threat trees are used. In DO-356, you can also find that example I'm showing at the moment. And then there are different approaches. One could be an asset-centric approach.

Basically, you work out a step-by-step plan to obtain or control an asset by listing the conditions and alternatives to arrive there. Then there could be also a design-centric approach, where you have to identify parts to be protected. For example, identify attack surfaces such as a debug port or network interfaces. Or a third approach could be attack-centric approach, based on the profile of the person who attacks, like what are the skills or the money of the person?

Common to all approaches is some kind of risk classification based on effort or likelihood and on harm or consequences usually called risk metrics. For example, if the system is vulnerable to an attack that might result in a life hazard, the risk is unacceptable. And since it can be highly subjective to put a number on aspects like motivation or skill of a hacker, such classification is usually done in ranks. And eventually, this allows for prioritization of risk and to derive security requirements that impose protection.

OK, once the security requirements have been derived, they need to be allocated and tracked throughout the design, because even the best requirements are futile when there's no proper mechanism to ensure they are satisfied during the implementation. Additionally, we also have to ensure we create or impose requirements that are imposed by standards or best practices. Those, for example, can be enumerated threats or requirements such as only allowing zero-knowledge encryption.

These play a central role in fulfilling the standards and therefore we also need to have means to track the implementation. Towards this most standards require us to capture the outcome of the threat tree and requirements. And this is an easy process with model-based design tool. So the requirements manager supports this activity and we provide a rigorous interface to connect with commonly used requirement management tools as well.

So now let's move on to the software design, which refines the system design and security concept. 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 which help you to modularize, allow reuse, detect clones and so on. And of course, all of that continues the support of allocating and tracking requirements.

So let's assume we're in the middle of the design phase now. What can we do for security beyond that? For example, security checks at model level. The model advisor allows you early security checks at model level, and you can prove that modeling standards for secure coding such as CERT C are met. Another tool Simulink Design Verifier uses formal methods to identify hidden design errors in models. It can detect blocks in the model that result in integer overflow, dead logic, array access validation, or division by 0. And it can formally verify that the design meets function requirements. And also for each design error or requirement validation, it can generate a simulation test case for debugging.

OK, now we get to one of the arguably most important steps for the security analysis, which is implement and verify the implementation. When we verify parts of your design, there's more to do than just checking requirements that deal with known attacks. We also want to ensure that we are prepared for the unknowns, that the implementation on a specific target is robust against attacks and also can detect attacks that you did not anticipate.

So when we generate code from our model, we have many options to control aspects of the implementation. For example, we can decide in which memory sections the code is going to be placed and whether to include recursion detection or not. And these choices can have a significant impact on the security properties of the resulting code. To ensure that we make the right implementation choices, we can make use of the model advisor, which helps us to set up the coder to achieve a better compliance to, for example, the secure coding standard CERT C.

However, note that correct parameterization of the code generator is still no guarantee that the generated code is completely compliant, but only decreases the likelihood of violation. And that is because the model itself and the associated user wishes, for example, to make certain test points available as global variables, may violate coding guidelines. As a consequence, this further reduces late findings of coding rule violations, but it cannot be a guarantee. The final verdict has to take place later at source code level.

Our method of choice for code-level security verification is static application security testing. This method is implemented in our Polyspace tool and based on analytical proof instead of dynamic testing, and thereby avoids the complexity problem. So what can we do here? First, we can check secure coding rules and also compliance to best practices. And the second, we can prove the absence of known vulnerabilities, that is, get a guarantee that our code is free from known defects. In this example, our static code analysis tool Polyspace was able to deduce that 93% of all potential defects are absent.

As an example here, Polyspace has given us a guarantee that one specific pointer is always safe. Thereby we know that this pointer is not going to be a weakness that allows, for example, remote code execution. Moreover, since this is a sound static analysis with analytical proof, this is equivalent to dynamic testing with 100% code coverage, which as we know is practically infeasible with dynamic testing. And this will consider all inputs in all program states without running into this feasibility problem. This is in fact at least highly recommended, if not even required by various standards.

So far we have ensured that the implementation of the software unit is free from known vulnerabilities, and is also robust. Next, we have to verify the same in integration context. So now we have the choice to do it either on model or code level. In this webinar we focus on model-based design, so therefore we show how to verify the integration at model level. Therefore, we have a look at the different methods.

So now as we have the first implementation of the system, hopefully we have already taken security into account, at least by covering the allocated requirements. But in general, you should be more rigorous. So now is a good point to dive further into security with the following steps.

First, we want to identify possible weaknesses and therefore we need to consider where to place attacks. Second, impact assessment. Affected parts and dynamic behavior must be analyzed. And third, mitigation, such as eliminating design flaws or maybe adding detection or reaction functionality to our system.

In that order, let's start with attack placement. Towards that we have to identify vulnerable parts of our system. There are different ways how to approach this. For example, from our requirements manually, we can track coverage of allocated requirements. Or derived from safety artifacts. Maybe from our risk assessment before, we have identified weak parts. And so interesting targets, by example, placing downgrade attacks on redundant systems. Or third, derived from analysis of our design models. For example, where our model checks, what we have seen before, failed. Or we could leverage smart fuzz testing top compute and test offending inputs.

Fuzz testing, as part of the refutation testing, is mentioned as one method to be applied in the security standards. Fuzzing is a technique where an application is fed malformed input data with the goal of detecting anomalies. There are different techniques to come up with those malformed inputs, for example, random or antirandom testing. However, today I want to point to another method that is based on analysis and not testing. And it works as follows. Based on an analytic approach, we can run our static analysis tool, Simulink Design Verifier. We can define forbidden behavior on the output side. Based on our static analysis, we can derive specific inputs that lead exactly to those defined validation criteria. And this approach can also then easily be automated.

So in the context of model-based design, that allows us to combine analysis and testing to automatically create test harnesses and link our tests and results to the requirements. Here the inputs can also be computed to increase coverage, as for example in our coverage-based fuzzing approach, and the results can then later be used to proceed with an impact assessment.

Fuzz testing in general is seen as a very effective and efficient testing method that can be highly automated. But also here it's important to mention that you have to know your system under test very well, to configure your fuzz testing in the best possible way.

OK, until now we have talked about static analysis and mapping cybersecurity requirements. But we haven't talked about cybersecurity testing yet. Here you can see a list of threats that are enumerated by the standards turned into an attack library. This allows you to test the design. For example, ManInTheMiddle attacks, replay attacks, and overflow, and so on, and thereby helps you to conduct, for example, a risk assessment. So the library itself can be then also extended when new threats become known. And it can be used in different development stages like software in the loop, processor in the loop, or hardware in the loop setups.

OK, so now let us assume that the vulnerability that we have found has a really bad impact. Let's move on to detection and mitigation of attacks. So far, we have talked a lot about revealing vulnerabilities and assessing them. Of course, part of the engineering process is also to fix or mitigate attacks. So let's look at one way to do that. For example, an attacker might break an existing security measure. For example, a message authentication or launch a yet unknown attack. The idea is to monitor for attacks and block possible bad inputs.

Machine learning could be one approach that can help us here to learn first the nominal behavior and then allows us to detect anomalies. So for example, the MATLAB neural network and the deep learning Toolbox can be used here to train your intrusion detection system. And you can feed it with data you have gathered before from the software in the loop or hardware in the loop model.

This brings us already closer to the end of this webinar, but before we go to the Q&A, there are a few more things. And we have seen some notable examples today where we have support already, and still, these are not all capabilities, what we have seen today.

To give you a quick overview or somehow a summary of what we have seen today, facing capabilities regarding machine learning or AI intrusion detection, but also how you could use the model slicer for impact assessment, linking and tracing requirements. But also how you can execute different checks on model or code level, and also regarding testing for example and how to simulate attacks or for example, fuzz testing on model level.

Security is much more than we could cover today, and MathWorks can make a big difference. But also, we're just one piece of the puzzle. Security requires many things to get right. For example, OS security, network security, hardware security, and last but not least, we also have to consider data privacy and usability.

So I would like to close this webinar with some key takeaways. First, there's no one testing technique. Today, we have seen some methods that can be used for testing, and it is important to start testing as early as possible and at all levels during the development. In addition, one should rely on different testing methods that complement each other. And MathWorks' tool can be used in some of the design stages required by the airworthiness security standards using model based design. For example in the early design phase, it brings a consistency and also traceability that you can benefit from, then also in later stages like in the implementation phase. And these are the same tools you're already using.

And with this, our next episode is about digital engineering for systems of systems. We would be pleased to see you in the next session. Thank you very much for attending this presentation. And please don't hesitate to contact me via email if you need more information or if you have any questions about the topics presented today. Thank you.

Up Next:

View full series (7 Videos)

View more related videos