This post summarizes our recent journal article “A systematic literature review of model-driven security engineering for cyber-physical systems“ [1] published in The Journal of Systems & Software in November 2020.

Cyber-physical systems (CPS) [2] are ubiquitous in our daily lives. CPS systems are distributed, embedded systems where communication within and between the systems and the interaction with their physical environment are important aspects [3]. This makes CPS highly safety-critical since malfunctions may harm the safety of persons. Prominent examples of CPS can be found in the automotive domain, aerospace, medical environments, or industrial control systems.

This critical functionality makes CPS especially interesting for attackers. Besides, the system’s security relies not only on cybersecurity but also on securing the physical part of the system [4]. This makes the development quite complex and interesting from a security point of view because both cyber-layer, as well as the platform (including the physical) layer and their interdependency, have to be considered. For this reason, security-by-design is an important paradigm when developing CPS.

Model-driven development (MDD)  has become a leading paradigm for developing CPS because it enables the developer to verify safety requirements in early development phases and refine the models into an implementation preserving the verified requirements. In the last years, several MDD approaches were developed focusing also on security helping to make CPS secure-by-design. However, since not all verified security properties are preserved during a refinement, security in MDD is a challenging task but also an interesting research field (e.g. see the SecureMDE workshop focusing on this research line)

The approaches developed in the last years diverge in the application domain, kind of security analyses, or used modeling languages. Since the physical part of a CPS may have high relevance for the overall security of the system, we conducted a systematic literature review (SLR) to find out how the platform is considered in current approaches in the area of model-driven security approaches. By platform, we understand the runtime environment including middleware and operating system but also the physical part of the system.

In the following, I provide some insights into the SLR and summarize our results. For a more detailed description, all results, and summaries of the surveyed approaches, we refer to the full paper [1].

Background and Rationale

In the last years, several literature surveys on model-driven security were published [5]–[10]. However, it turns out that CPS and in particular the physical part of CPS are not considered very well. We, therefore, set the focus of SLR on the use of the platform of CPS and how it is considered in current model-driven security approaches for CPS. During an initial literature study, we collected and defined a set of seven requirements we see as important for such approaches.

• (R1) Support different layers of the system: One key aspect of CPS is that they consist of different layers. In this survey, we distinguish two main layers: cyber layer and the platform layer. The cyber layer describes the software part of the system. The platform layer covers the whole runtime environment (as for usual IT systems) containing artifacts like operating system and middleware but also the physical part of the system, e.g. sensors and actuators. Since in this survey we focus on the use of the platform, this requirement has some significance.
• (R2) Phases of the SDLC: Security-by-Design means to consider security in all phases of the SDLC. Thus, all phases of the SDLC should be covered. First of all, the system has to be designed, e.g., by modeling the software architecture and the target platform. Furthermore, potential threats and attacks have to be specified, e.g., by a threat model. Additional phases are the application of formal analyses, (automatic) threat mitigation, deployment, or runtime analyses like monitoring or simulation. It is important that each phase is clearly defined and has specified input and output artifacts.
• (R3) System of systems: Modern CPS are complex systems that consist of several sub-systems. To handle the development of such system-of-systems, the method has to provide a structured approach, e.g., to allow compositional analyses, it has to provide the specification of a hierarchical system specification. In large systems, not all subsystems are developed by the same provider. Thus, complex systems often integrate third-party resources. Hence, in the best case, a method is able to process both fully known parts and only partially known (or even unknown) parts of the system.
• (R4) Threat model: Since the threat model defines potential threats to the system, it is important that such a model is sufficiently expressive; it should cover as many kinds of threats as possible. In the best case, the threat model is extensible, allowing one to define new threats. We do not restrict the threat model to the application layer but also consider threats regarding the platform and hardware.
• (R5) Formal methods and formal models: Security-by-Design is aided by applying formal analyses and model transformations to enable consistency between all development steps. Thus, the method has to provide formal models for the system and the threats and attacks as well as formal analyses on these models.
• (R6) Refinement and relation to implementation: An approach has to provide a correct synthesis to source code, i.e., a source-code generation that preserves the analysis results, e.g., by generating secure source code for the platform. In the best case, a full code generation for the is provided but also partial code generation for the security implementations might be sufficient, e.g., if the code for secure communication is generated. Other code generations are possible, e.g., automatically generated test cases or static code analyses.
• (R7) Requirements: Typically, besides functional requirements and security requirements also non-functional requirements are essential for CPS, since CPS are often restricted by resource constraints, e.g., restricted memory or computing power. Restricted computational power and timing constraints get important properties and make the secure development of CPS more difficult, e.g., when encryption is needed. Also, such systems have to formally show that specific (hard real-time) safety-requirements are fulfilled. Hence, an approach has to provide the specification and/or verification of such non-functional requirements. In the best case, an approach has to allow the specification and verification of functional, non-functional, and security requirements.

“ [1]. Based on this rationale and the stated requirements, we state the following three research questions which should be answered by our SLR. [1]

• RQ1: To which extent do model-driven security approaches for CPS consider the platform?
• RQ2: Which of the stated requirements do these approaches fulfill?
• RQ3: What are current challenges and open research questions in the area of such platform-aware approaches for model-driven security?

Conducting the SLR

For our SLR, we followed the guidelines by Kitchenham et al. [11], [12] for conducting systematic literature reviews. In the following, I describe the key information regarding the conduct of the SLR. Please find the full description in our paper [1]. We also provide a replication bundle containing a full list of survey publications and the review protocol [13].

For finding initial studies, we first did a title-based search based on keywords reflecting the areas of Security, CPS, and Model-driven engineering. The result of the automatic search of the online libraries by Springer, IEEE, ACM, and Elsevier were 1160 publications. We excluded step-wise studies not relevant for our SLR based on a set of exclusion criteria. Figure 1 shows the number of remaining studies after each exclusion step. Finally, we applied snowballing to find relevant studies not found during the automatic search. As result, we got a set of 69 relevant publications that we clustered to 17 relevant approaches. We categorized these approaches into general approaches for model-driven security, platform-specific but not CPS-specific approaches, and CPS-specific approaches for model-driven security (cf. Table 1). We found seven approaches that are CPS-specific and selected these seven approaches for data extraction.

 

General	Platform-specific	CPS-specific
SecureUML [14]	SecureMDD [15]	DREMS [16]
UMLsec [17]	Security-enhanced SPACE [18]	SysML-Sec [27]
SECTET [20]	Neureiter et al.[21]	ProCom [19]
ModelSec [23]		Wasicek et al. [22]
Motii [24]		Al Faruque et al.
Security4UML [26]		Eby et al. [25]
ISSEP [28]		SEED [29]

Table 1: Classification Of Surveyed Approaches How CPS-specific They Are

We extracted for these approaches relevant data and information needed to answer our research questions. In particular, we extracted and discussed the following information:

• General Information describing meta information, tooling, and how the method is evaluated.
• Kind of Approach describing how security is integrated into the approach, e.g., if the approach focuses on security only or if it also considers functional modeling for the system
• We describe which stages of the SDLC are covered by the approaches and how security is integrated into these stages.
• We extract which models for system design are used, e.g., architectural models describing the structure of the system, behavioral models describing the behavior of the system, and platform models describing the execution platform and environment of the system.
• We extract for each approach the step of (formal) threat specification in more detail.
• We extract for each approach which security transformations and security analyses are applied in the approach.

In addition, we also provide for each approach a description based on the phases of a secure development lifecycle. We refer the interested reader to the original SLR.

Summary of our Findings and Open Research Topics

In the following, we summarize our findings of the survey and give some insights into the extracted data. For the full discussion of the extracted data and a summary of each selected approach based on the phases of the SDLC, we refer to our original paper [1].

Even if the methods and the focus of the selected approaches differ, they have in common that they focus mainly on the phases Design, Threat Modeling, and Security Analyses of the SDLC. Requirements are only covered by SysML-Sec and SEED to some extent. Also, even if all approaches take the platform into account and, therefore, also cover the phase Deployment, only DREMS provides concrete concepts for the runtime phase of the SDLC. Taking a mature platform model into account would help to find new, platform-specific threats, e.g., when it makes a difference if the system is physically accessible or not like for an ATM. In our survey, we found ten model-driven security approaches that take the platform into account, seven of them are tailored especially for CPS. In summary, we can say concerning RQ1 that the platform is considered but could be improved in the future to consider also platform-specific attacks during the development.

	Require-ments	Design	Threat Modeling	Analyses	Deployment	Runtime
DREMS		x	x	x	x	x
SysML-Sec	x	x	x	x	x
ProCom		x	x	x	x
Wasicek et al.		x	x	x	x
Al Faruque et al.		x	x	x	x
Eby et al.		x	x	x
SEED	(x)	x	x	x	x

Table 2: Covered phases of the software development lifecycle.

Also, when modeling the software of the system, most of the approaches focus on architectural views and do not use behavioral views of the system for security engineering. Only SysML-Sec and SEED provide concepts based on behavioral views separately. This is also observable when studying security analyses and transformation applied by the selected approaches. Most approaches use analyses on the design level or aim at securing the design of the system. Approaches that also aim at securing the source code often focus on specific features, e.g., in the ProCom approach code for encryption and decryption is generated, or in DREMS middleware code to enforce security policies is used. A mature deployment step and a connection to a threat model (if existent) are missing.

Overall, the selected approaches are quite broad. However, concerning RQ2, we can summarize that all approaches satisfy all stated requirements at least partially.

	R1	R2	R3	R4	R5	R6	R7
DREMS	x	x	x	p	p	p	p
SysML-Sec	x	x	x	p	p	p	x
ProCom	x	p	x	p	p	p	x
Wasicek et al.	p	p	p	p	p	p	p
Al Faruque et al.	p	p	p	p	p	p	p
Eby et al.	x	p	x	p	p	p	p
SEED	x	x	x	p	p	p	x

Table 3: Requirements for CPS covered by the selected approaches. (x: satisfied, p: partially satisfied)

Even if the approaches differ in their domain, used techniques, and applied analyses, it was interesting to see which parts are covered in current approaches. To answer RQ3, we collected open research questions or topics that should be explored in more detail during the data extraction:

Threat Model

A threat model is essential for security approaches since it describes what can go wrong, what the assets of the system are, or who to protect against. However, it turned out that most approaches do not provide a dedicated threat model but use specifications of concrete threats, and focus in general on confidentiality and integrity of communication within the system.

In approaches where a dedicated threat model is specified, a connection to the system models is missing. Out of the surveyed approaches, only SysML-Sec provides methods for threat modeling and the integration into model-driven development. Creating a separate threat model and integrating it into CPS development would be an interesting research field. It would be interesting how existing, non-CPS-specific techniques could be adapted for CPS, e.g., by adding security information as done in UMLsec or access control information as done in SecureUML. Here, one major question would be how the platform of the system has to be considered in the analyses. Since many CPSs are developed in a highly interdisciplinary context, another interesting research direction would be to investigate how a common threat model for all involved disciplines could look like. We like the idea of creating a threat model like in ModelSec [23] because, in a high interdisciplinary context, a clear separation of security experts and domain experts is useful. However, close collaboration is also required to ensure that security is built into the system from the beginning and is not being added afterward. Hence, an explicit connection between the security model and system model is favorable and, therefore, concepts for the integration of security engineering into the development phases are required.

Third-party Code

All approaches consider hierarchical systems. However, the integration of existing external applications is mostly left aside. DREMS is the exception among the selected approaches since third-party applications can be modeled using their multi-label concept. However, third-party code is getting more important because CPSs consists usually of several subsystems (consisting of hardware and software parts) that are developed by different providers. Additionally, open-source software, especially libraries are used often. Therefore, the integration of the third-party code but also the integration of the corresponding threat model into the systems threat model seems to be an important research direction.

Platform Integration

Even if all selected approaches consider the platform of the system, it appears that the full integration of the platform, especially the physical part, seems to be an open research field. Particularly for CPSs, the physical environment is crucial when creating a threat model for the systems software. It makes a difference if a device is operating at a construction site or in a secured area where only a few people have physical access. Furthermore, the deployment and runtime of the software are also critical from a security point of view. Only DREMS provides techniques to enforce specific security properties at runtime, e.g., separating the execution of software of different security levels. Most approaches provide the generation of (secure) code for a specific execution platform. However, a holistic deployment step involves other tasks despite code generation. Since the deployment might affect the security assumptions made during development, it seems to be important to extend the classical threat model which is only used for development to a reactive security model describing the current security situation of the system.

Creating such a model and providing methods keeping it up to date and to use it as a connection to the development artifacts would help to make the security lifecycle a useful lifecycle. This would also be useful for agile development where a threat model has to be updated for each sprint or iteration. To make it affected, a higher degree of automation is necessary. Thus, analyses and transformations supporting such a reactive security model are needed.

Common Evaluation Scenario

Finally, a common evaluation scenario would be of great benefit. On the one hand, it would help to compare existing approaches. On the other hand, it would be helpful when developing new methods and approaches. However, the domain of CPS covers a wide range of different subdomains which makes comparative evaluations quite difficult. Furthermore, when comparing security approaches for CPS, there are a lot of properties that should be compared. Choosing one fixed evaluation scenario could help to increase the internal validity of the approach. However to increase the external validity a rather specific scenario would be needed ensuring to make several approaches comparable. Here, instead, an idea would be to use a set of known weaknesses, e.g., a subset from the CWE database. Consequently, a common evaluation scenario as well as a list or database of common weaknesses is needed.

Conclusion

Our survey showed that model-driven security engineering for CPS is an important research area. However, the physical layer is in current approaches only barely taken into account. The approaches selected for our survey differ in their kind, applied analyses, and focus of the development lifecycle. Our SLR gave a good impression of the current state of platform-aware security approaches for CPS development.

Secure development of CPS is a highly relevant topic and we plan to study the new approaches coming up in this area. Also, it will be interesting to analyze how concepts of non-CPS-specific approach can be used for CPS development. I expect a lot of interesting work in this research area in the future. Do not hesitate to contact me if you have questions or comments, or if you are simply interested in this research area. I am happy to discuss this topic and future research directions in the area.

 

Bibliography

[1]      J. Geismann and E. Bodden, “A systematic literature review of model-driven security engineering for cyber–physical systems,” J. Syst. Softw., vol. 169, p. 110697, 2020.
[2]      E. A. Lee, “Cyber Physical Systems: Design Challenges,” 11th IEEE Int. Symp. Object Component-Oriented Real-Time Distrib. Comput., pp. 363–369, 2008.
[3]      J. Fitzgerald, P. G. Larsen, and M. Verhoef, “From embedded to cyber-physical systems: Challenges and future directions,” in Collaborative design for embedded systems, Springer, 2014, pp. 293–303.
[4]      M. Steger, M. Karner, J. Hillebrand, W. Rom, and K. Römer, “A security metric for structured security analysis of cyber-physical systems supporting SAE J3061,” in 2016 2nd International Workshop on Modelling, Analysis, and Control of Complex CPS (CPS Data), 2016, pp. 1–6.
[5]      M. Felderer, P. Zech, R. Breu, M. Büchler, and A. Pretschner, “Model-based security testing: a taxonomy and systematic classification,” Softw. Testing, Verif. Reliab., vol. 26, no. 2, pp. 119–148, 2016.
[6]      S. Kriaa, L. Pietre-Cambacedes, M. Bouissou, and Y. Halgand, “A survey of approaches combining safety and security for industrial control Systems,” Reliab. Eng. Syst. Saf., vol. 139, pp. 156–178, 2015.
[7]      P. H. Nguyen, M. Kramer, J. Klein, and Y. Le, “An extensive systematic review on the Model-Driven Development of secure systems,” Inf. Softw. Technol., vol. 68, pp. 62–81, 2015.
[8]      P. H. Nguyen, S. Ali, and T. Yue, “Model-based security engineering for cyber-physical systems: A systematic mapping study,” Inf. Softw. Technol., vol. 83, pp. 116–135, 2017.
[9]      A. V. Uzunov, E. B. Fernandez, and K. Falkner, “Engineering Security into Distributed Systems: A Survey of Methodologies,” Journal of Universal Computer Science, vol. 18, no. 20. pp. 2920–3006, 2012.
[10]    J. Jensen and M. G. Jaatun, “Security in Model Driven Development: A Survey,” in Availability, Reliability and Security (ARES), 2011 Sixth International Conference on, 2011, pp. 704–709.
[11]    D. Budgen and P. Brereton, “Performing systematic literature reviews in software engineering,” in Proceeding of the 28th international conference on Software engineering – ICSE ’06, 2006, vol. 2, p. 1051.
[12]    B. Kitchenham, “Procedures for performing systematic reviews,” Keele, UK, Keele Univ., vol. 33, no. TR/SE-0401, p. 28, 2004.
[13]    J. Geismann and E. Bodden, “Replication Package for the SLR.” 2020.
[14]    D. Basin, “Model driven security,” Proc. – First Int. Conf. Availability, Reliab. Secur. ARES 2006, vol. 2006, no. 1945, p. 46, 2006.
[15]    N. Moebius, K. Stenzel, H. Grandy, and W. Reif, “SecureMDD: A model-driven development method for secure smart card applications,” Proc. – Int. Conf. Availability, Reliab. Secur. ARES 2009, pp. 841–846, 2009.
[16]    T. Levendovszky, A. Dubey, W. R. Otte, D. Balasubramanian, A. Coglio, S. Nyako, W. Emfinger, P. Kumar, A. Gokhale, and G. Karsai, “Distributed Real-Time Managed Systems: A Model-Driven Distributed Secure Information Architecture Platform for Managed Embedded Systems,” IEEE Softw., vol. 31, no. 2, pp. 62–69, 2014.
[17]    J. Jürjens, Secure systems development with UML. Springer Science & Business Media, 2005.
[18]    L. A. Gunawan, F. A. Kraemer, and P. Herrmann, “A tool-supported method for the design and implementation of secure distributed applications,” in International Symposium on Engineering Secure Software and Systems, 2011, pp. 142–155.
[19]    M. Saadatmand and T. Leveque, “Modeling Security Aspects in Distributed Real-Time Component-Based Embedded Systems,” in Information Technology: New Generations (ITNG), 2012 Ninth International Conference on, 2012, pp. 437–444.
[20]    M. Hafner, R. Breu, B. Agreiter, and A. Nowak, “Sectet: an extensible framework for the realization of secure inter-organizational workflows,” Internet Res., vol. 16, no. 5, pp. 491–506, 2006.
[21]    C. Neureiter, D. Engel, and M. Uslar, “Domain Specific and Model Based Systems Engineering in the Smart Grid as Prerequesite for Security by Design,” Electronics, vol. 5, no. 4, p. 24, 2016.
[22]    A. Wasicek, P. Derler, and E. a. Lee, “Aspect-oriented Modeling of Attacks in Automotive Cyber-Physical Systems,” in Proceedings of the The 51st Annual Design Automation Conference on Design Automation Conference – DAC ’14, 2014, pp. 1–6.
[23]    Ó. Sánchez, F. Molina, J. García-Molina, and A. Toval, “ModelSec: a generative architecture for model-driven security,” J. Univers. Comput. Sci., vol. 15, no. 15, pp. 2957–2980, 2009.
[24]    A. Motii, “Engineering Secure Software Architectures: Patterns, Models and Analysis,” no. Umr 5505, 2017.
[25]    M. Eby, J. Werner, G. Karsai, and A. Ledeczi, “Integrating Security Modeling into Embedded System Design,” 2007.
[26]    M. A. Neri, M. Guarnieri, E. Magri, S. Mutti, and S. Paraboschi, “A model-driven approach for securing software architectures,” in Security and Cryptography (SECRYPT), 2013 International Conference on, 2013, pp. 1–8.
[27]    L. W. Li, F. Lugou, and L. Apvrille, “Security modeling for embedded system design,” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes Bioinformatics), vol. 10744 LNCS, pp. 99–106, 2018.
[28]    J. F. Ruiz, A. Maña, and C. Rudolph, “An Integrated Security and Systems Engineering Process and Modelling Framework,” Comput. J., vol. 58, no. 10, pp. 2328–2350, 2015.
[29]    M. Vasilevskaya, Security in Embedded Systems A Model-Based Approach with Risk Metrics by, no. 1715. 2015.