Traceable Security-by-Design Decisions for Cyber-Physical Systems (CPSs) by Means of Function-Based Diagrams and Security Libraries
- Decision identification: The challenge is to identify which of the many system characteristics and design decisions affect the system’s security.
- Decision making: The challenge is to have all relevant information handy to make profound, informed, and systematic security decisions.
- Decision tracing: The challenge is to clearly understand and document the decisions’ rationales.
- Decision timing: The challenge is to make the security decisions regarding a certain design aspect early enough, i.e., when this design aspect can still be influenced. This means that the security decision making needs to be integrated early enough into the existing engineering workflow.
2. State of the Art
2.1. Decision Identification
2.2. Decision Making
|Category and Example References||Advantages/Use Cases||Limitations|
|Compliance-driven security decision making|
based on requirements lists such as
|Risk-driven security decision making|
Abundance of publications, surveys, e.g., in
|Goal-driven security decision making|
|Library-supported security decision making|
2.3. Summary: Problems of Existing Methods
3. Security-by-Design Decisions Method: Workflow for Making Traceable Security Decisions
- Function-based security parameter libraries for decision identification;
- Function-based security diagrams, and in combination with an underlying
- Data model and tool, these diagrams guide decision making and enable traceable security decisions to be made.
3.1. Workflow Overview
- Step 1: Identify security decisions
- Step 2: Fill decision base
- Goal-driven decision making (marked blue in Figure 1): For goal-driven decisions, the security decision base is filled with security goals for specific functions or function components or the overall systems. Security goals are often composed of (combinations of) confidentiality, integrity, and availability of certain functions, components, or pieces of information, but they can also include reliability or compliance aspects . Goals can also be hierarchically organized into sub-goals to allow the break-down of high-level goals into more specific ones.Example: For a chemical production plant, a security goal could be “stable pressure in reactor” with a sub-goal “integrity of output value for pump P”.
- Risk-driven decision making (marked red in Figure 1): For risk-driven decision making, it can make sense to define High-Consequence Events (HCEs)—events that would make for a really bad day at the organization and that must be prevented [10,55]. In addition, all kinds of attack scenarios potentially leading to HCEs are a meaningful addition to the security decision base because they provide more detailed indicators on how to prevent HCEs. Attack scenarios can be function-specific, detailing how a specific function may be exploited to cause a specific HCE.Security parameters contain some built-in guidance for constructing attack scenarios: parameter values that may be used in an attack are marked as attack indicators in the library. See Section 3.2 for details.Attack diagrams provide guidance by overlaying all relevant information for modeling attack scenarios onto function diagrams. See Section 3.3 for details.Example: For the same chemical production plant, a HCE could be “reactor explodes”. For the function “update of PLC logic”, an imaginable attack scenario would be sending a spearphishing attachment to a PLC engineer to gain access to her programming device, exploit a vulnerability allowing user execution on that device, and ultimately modify the PLC’s logic to cause overpressure in the reactor.
- Compliance-driven decision making (marked grey in Figure 1): For compliance-driven decision making, the decision base simply needs to be filled with the regulations, laws, or standards affecting security that should be complied with. These can be international, national, or even internal company regulations.Example: For the chemical plant, it is determined that the company-internal policy “automation security guideline ABC” needs to be complied with. It has eleven paragraphs that may each be referenced separately.
- Step 3: Make security decisions
- Goal-driven decision making (marked blue in Figure 1): For goal-driven decision making, the security parameter contributes to fulfilling a security goal defined before. This security goal forms the rationale for the security decision.Example: for the security parameter selection “integrity protection of PLC logic: hash”, a goal-driven rationale could be “stable pressure in reactor R”, or more specifically “integrity of output values for pump P”.
- Risk-driven decision making (marked red in Figure 1): For risk-driven decision making, the security parameter helps mitigate a risk, or to be more precise, it helps to reduce the impact or likelihood of a high-consequence event (HCE) occurring; thus, the addressed HCE serves as a rationale for the risk-driven security decision. If attack scenarios that include one of the security parameter’s attack indicators have been defined, these may be referenced in the rationale as well.Example: for the same security parameter selection “integrity protection of PLC logic: hash”, a risk-driven rationale could be that the parameter value “integrity protection of PLC logic: none” is used in a potential attack scenario leading to the HCE “reactor explodes”.
- Compliance-driven decision making (marked grey in Figure 1): For compliance-driven decisions, the security parameter helps comply with a specific regulation or standard. As a rationale, it is sufficient to reference the relevant regulation or standard.Example: for the security parameter selection “CVE-2023-001: patched”, a compliance-driven rationale could be “national critical infrastructure protection directive, §1” (assuming that, in the example country, patching certain vulnerabilities is mandated in critical infrastructure regulation).
- Functional-requirement-driven decision making: Sometimes, a security decision is made for no security reason, but because the need to fulfill a functional requirement has taken the security parameter out of the solution space available to security decision makers.Although it might sound counter-intuitive to call a decision a “security decision” even though it has been made for no security reason at all, it should be remembered that it is a security decision because it influences the system’s security posture, not because it was made for security reasons. Maybe even more than for security decisions actually made for security reasons, it matters to be aware of these decisions, because it means the overall security posture is (often negatively) impacted by decisions made outside the security domain.Example: for the security parameter selection “updating logic during operations: enabled”, a functional-requirement-based rationale could be “enable on-line program changes to accommodate for fast adaptation of modular plants”.
3.2. Function-Based Security Parameter Libraries
3.3. Function-Based Security Diagrams
3.4. Workflow Support by Security Data Model and Tool
3.5. Limitations and Open Issues
3.5.1. Library Maintenance
3.5.2. Additional Security Decisions (Lifecycle Decisions)
- Procurement: Decision of which security parameters should be included in procurement as SHALL or SHOULD criteria;
- Audits: Decision of which security parameters shall be audited (and how) in factory acceptance tests (FATs), site acceptance tests (SATs), or other tests/audits;
- Operations (monitoring): Decision of which security parameters should be visualized on an HMI or alarmed;
- Operations (procedures): Decision of which security parameters need organizational procedures to be adhered to or are inputs to specific procedures.
4.1. Validation Setup
4.2. Validation Method, Questions, and Metrics
4.3. Validation Setup Limitations
4.4. Validation Results
6. Conclusions and Outlook
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
- Easterly, J.; Goldstein, E. Stop Passing the Buck on Cybersecurity: Why Companies Must Build Safety Into Tech Products. Foreign Aff. 2023, 102. Available online: https://www.foreignaffairs.com/united-states/stop-passing-buck-cybersecurity (accessed on 1 April 2023).
- European Parliament/European Council. Proposal for a Regulation on Horizontal Cybersecurity Requirements for Products with Digital Elements (COM/2022/454): Cyber Resilience Act (CRA). 2022. Available online: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act (accessed on 1 April 2023).
- Biden-Harris Administration. National Cybersecurity Strategy; The White House: Washington, DC, USA, 2023. Available online: https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf (accessed on 1 April 2023).
- CISA; NSA; FBI; ACSC; NCSC-UK; CCCS; BSI; NCSC-NL; CERT NZ; NCSC-NZ. Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default. 2023. Available online: https://www.cisa.gov/resources-tools/resources/secure-by-design-and-default (accessed on 25 April 2023).
- Hollender, M. Collaborative Process Automation Systems; ISA: Durham, NC, USA, 2009; ISBN 978-1-936007-10-3. [Google Scholar]
- NAMUR e. V. NA35—Engineering and Execution of PCT Projects in Process Industry; NAMUR: Leverkusen, Germany, 2019. [Google Scholar]
- Kieseberg, P.; Weippl, E. Security Challenges in Cyber-Physical Production Systems. In Software Quality: Methods and Tools for Better Software and Systems; Winkler, D., Biffl, S., Bergsmann, J., Eds.; Springer International Publishing: Cham, Switzerland, 2018; pp. 3–16. ISBN 978-3-319-71439-4. [Google Scholar]
- Eckhart, M.; Ekelhart, A.; Luder, A.; Biffl, S.; Weippl, E. Security Development Lifecycle for Cyber-Physical Production Systems. In Proceedings of the IECON 2019-45th Annual Conference of the IEEE Industrial Electronics Society, Lisbon, Portugal, 14–17 October 2019; IEEE: Piscataway, NJ, USA, 2019; pp. 3004–3011, ISBN 978-1-7281-4878-6. [Google Scholar]
- Ruiz, J.F.; Maña, A.; Rudolph, C. An Integrated Security and Systems Engineering Process and Modelling Framework. Comput. J. 2015, 58, 2328–2350. [Google Scholar] [CrossRef]
- Fluchs, S.; Drath, R.; Fay, A. A Security Decision Base: How to Prepare Security by Design Decisions for Industrial Control Systems. In Proceedings of the 17th EKA (Fachtagung “Entwurf Komplexer Automatisierungssysteme”), EKA 2022, Magdeburg, Germany, 11–12 June 2022; ISBN 978-3-948749-23-1. [Google Scholar]
- IEC 62443-2-1; Industrial Communication Networks—Network and System Security—Part 2-1: Establishing an Industrial Automation and Control System Security Program. IEC: Geneva, Switzerland, 2010.
- IEC 62443-4-1; Security for Industrial Automation and Control Systems-Part 4-1: Secure Product Development Lifecycle Requirements. IEC: Geneva, Switzerland, 2018.
- IEC 62443-4-2; Security for Industrial Automation and Control Systems-Part 4-2: Technical Security Requirements for IACS Components. IEC: Geneva, Switzerland, 2018.
- IEC 62443-3-3; Industrial Communication Networks-Network and System Security-Part 3-3: System Security Requirements and Security Levels. IEC: Geneva, Switzerland, 2013.
- ISO/IEC 27001:2022; Information Security, Cybersecurity and Privacy Protection—Information Security Management Systems—Requirements. ISO/IEC: Geneva, Switzerland, 2022.
- NIST. Framework for Improving Critical Infrastructure Security, Version 1.1. 2018. Available online: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf (accessed on 29 March 2023).
- Anderson, R. Security Engineering: A Guide to Building Dependable Distributed Systems, 2nd ed.; Wiley: Indianapolis, Indiana, 2008; ISBN 978-0-470-06852-6. [Google Scholar]
- Baskerville, R. Information systems security design methods: Implications for information systems development. ACM Comput. Surv. 1993, 25, 375–414. [Google Scholar] [CrossRef]
- Peterson, D. Explore… (S4x23 Keynote). Available online: https://dale-peterson.com/2023/02/21/explore-s4x23-intro/ (accessed on 29 March 2023).
- An, L.; Yang, G.-H. Distributed secure state estimation for cyber–physical systems under sensor attacks. Automatica 2019, 107, 526–538. [Google Scholar] [CrossRef]
- Peterson, D. Insecure by Design/Secure by Design. Available online: https://dale-peterson.com/2013/11/04/insecure-by-design-secure-by-design/ (accessed on 9 May 2022).
- Directive (EU) 2022/2555 on Measures for a High Common Level of Cybersecurity Across the Union: NIS 2 Directive; Official Journal of the European Union L333/80; European Union: Luxembourg, 2022.
- Directive (EU) 2022/2557 on the Resilience of Critical Entities: RCE Directive; Official Journal of the European Union L333/164; European Union: Luxembourg, 2022.
- Presidential Policy Directive–Critical Infrastructure Security and Resilience: PPD-21. 2013. Available online: https://www.cisa.gov/sites/default/files/2023-01/ppd-21-critical-infrastructure-and-resilience-508_0.pdf (accessed on 1 April 2023).
- Cherdantseva, Y.; Burnap, P.; Blyth, A.; Eden, P.; Jones, K.; Soulsby, H.; Stoddart, K. A review of cyber security risk assessment methods for SCADA systems. Comput. Secur. 2016, 56, 1–27. [Google Scholar] [CrossRef][Green Version]
- Lemaire, L.; Vossaert, J.; de Decker, B.; Naessens, V. An Assessment of Security Analysis Tools for Cyber-Physical Systems. In Risk Assessment and Risk-Driven Quality Assurance; Großmann, J., Felderer, M., Seehusen, F., Eds.; Springer International Publishing: Cham, Switzerland, 2017; pp. 66–81. ISBN 978-3-319-57857-6. [Google Scholar]
- Fluchs, S.; Rudolph, H. Making OT security engineering deserve its name—A guide to security engineering for OT engineers. CONTROL Glob. 2019. Available online: https://www.controlglobal.com/articles/2019/making-ot-security-engineering-deserve-its-name (accessed on 1 April 2023).
- Fluchs, S.; Rudolph, H. Wie OT-Security-Engineering eine Ingenieurwissenschaft wird-Ein Denkmodell und ein Datenmodell [Making OT Security Engineering an Engineering Discipline-A Thought Model and a Data Model]. Atp Mag. 2019, 61, 74–86. [Google Scholar] [CrossRef]
- Haley, C.B.; Laney, R.; Moffett, J.D.; Nuseibeh, B. Security Requirements Engineering: A Framework for Representation and Analysis. IEEE Trans. Softw. Eng. 2008, 34, 133–153. [Google Scholar] [CrossRef][Green Version]
- Mead, N.R.; Stehney, T. Security quality requirements engineering (SQUARE) methodology. ACM SIGSOFT Softw. Eng. Notes 2005, 30, 1–7. [Google Scholar] [CrossRef]
- Mouratidis, H.; Giorgini, P. Secure Tropos: A security-oriented extension of the Tropos methodology. Int. J. Softw. Eng. Knowl. Eng. 2007, 17, 285–309. [Google Scholar] [CrossRef][Green Version]
- Elahi, G.; Yu, E. A Goal Oriented Approach for Modeling and Analyzing Security Trade-Offs. In Conceptual Modeling-ER 2007; Parent, C., Schewe, K.-D., Storey, V.C., Thalheim, B., Eds.; Springer: Berlin/Heidelberg, Germany, 2007; pp. 375–390. ISBN 978-3-540-75562-3/978-3-540-75563-0. [Google Scholar]
- Hatebur, D.; Heisel, M.; Schmidt, H. A Security Engineering Process based on Patterns. In Proceedings of the 18th International Conference on Database and Expert Systems Applications (DEXA 2007), Regensburg, Germany, 3–7 September 2007; IEEE: Regensburg, Germany, 2007; pp. 734–738, ISBN 978-0-7695-2932-5. [Google Scholar]
- Vasilevskaya, M. Designing Security-Enhanced Embedded Systems: Bridging Two Islands of Expertise; Linköping University Electronic Press: Linköping, Sweden, 2013; ISBN 978-91-7519-486-8. [Google Scholar]
- Vivas, J.L.; Montenegro, J.A.; López, J. Towards a Business Process-Driven Framework for Security Engineering with the UML. In Information Security; Goos, G., Hartmanis, J., van Leeuwen, J., Boyd, C., Mao, W., Eds.; Springer: Berlin/Heidelberg, Germany, 2003; pp. 381–395. ISBN 978-3-540-20176-2/978-3-540-39981-0. [Google Scholar]
- Department of Information Engineering and Computer Science, University of Trento. The Tropos Methodology. Available online: http://www.troposproject.eu/node/93 (accessed on 1 April 2023).
- Yu, E.S. Social Modeling and i*. In Conceptual Modeling: Foundations and Applications; Borgida, A.T., Chaudhri, V.K., Giorgini, P., Yu, E.S., Eds.; Springer: Berlin/Heidelberg, Germany, 2009; pp. 99–121. ISBN 978-3-642-02462-7/978-3-642-02463-4. [Google Scholar]
- Morkevicius, A.; Bisikirskiene, L.; Bleakley, G. Using a systems of systems modeling approach for developing Industrial Internet of Things applications. In Proceedings of the 2017 12th System of Systems Engineering Conference (SoSE), Waikoloa, HI, USA, 18–21 June 2017; IEEE: Waikoloa, HI, USA, 2017; pp. 1–6, ISBN 978-1-5090-5945-4. [Google Scholar]
- Lemaire, L.; Lapon, J.; de Decker, B.; Naessens, V. A SysML Extension for Security Analysis of Industrial Control Systems. In Proceedings of the 2nd International Symposium for ICS & SCADA Cyber Security Research 2014, St. Poelten, Austria, 11–12 September 2014; BCS Learning & Development: Swindon, UK, 2014. ISBN 978-1-78017-286-6. [Google Scholar]
- Fluchs, S. Fluchs, S. For Security, Think Functions-Not Systems, 2020. Fluchsfriction. Available online: https://fluchsfriction.medium.com/for-security-think-functions-not-systems-b0e08a9d89b6 (accessed on 1 April 2023).
- Ruiz, J.F.; Rudolph, C.; Mana, A.; Arjona, M. A security engineering process for systems of systems using security patterns. In Proceedings of the 2014 IEEE International Systems Conference Proceedings, Ottawa, ON, Canada, 31 March–3 April 2014; IEEE: Ottawa, ON, Canada, 2014; pp. 8–11, ISBN 978-1-4799-2086-0. [Google Scholar]
- Schumacher, M. Security Engineering with Patterns: Origins, Theoretical Models, and New Applications; Springer: Berlin/Heidelberg, Germany; New York, NY, USA, 2003; ISBN 978-3-540-40731-7. [Google Scholar]
- Schumacher, M.; Fernandez-Buglioni, E.; Hybertson, D.; Buschmann, F.; Sommerlad, P. Security Patterns: Integrating Security and Systems Engineering; John Wiley & Sons: Chichester, UK; Hoboken, NJ, USA, 2006; ISBN 978-0-470-85884-4. [Google Scholar]
- Common Criteria. Common Criteria for Information Technology Security Evaluation. Version 3.1, Revision 5. Available online: https://www.commoncriteriaportal.org/cc/ (accessed on 1 April 2023).
- Glawe, M.; Tebbe, C.; Fay, A.; Niemann, K.-H. Knowledge-based Engineering of Automation Systems using Ontologies and Engineering Data. In Proceedings of the 7th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management, Lisbon, Portugal, 12–14 November 2015; SCITEPRESS-Science and and Technology Publications: Lisbon, Portugal, 2015; pp. 291–300, ISBN 978-989-758-158-8. [Google Scholar]
- Tebbe, C. Durchgängiges Wissensmanagement von OT-Security-Wissen im Lebensweg von Produktionsanlagen; Helmut Schmidt Universität/Universität der Bundeswehr Hamburg: Hamburg, Germany, 2021. [Google Scholar]
- Eckhart, M.; Ekelhart, A.; Weippl, E.R. Automated Security Risk Identification Using AutomationML-based Engineering Data. IEEE Trans. Dependable Secur. Comput. 2020, 19, 1655–1672. [Google Scholar] [CrossRef]
- MITRE. ATT&CK for ICS. Available online: https://attack.mitre.org/matrices/ics/ (accessed on 29 May 2022).
- Object Management Group. Unified Modeling Language (UML) Specification v2.5.1. Available online: https://www.omg.org/spec/UML/2.5.1/About-UML/ (accessed on 1 April 2023).
- Bagade, P.; Banerjee, A.; Gupta, S. Validation, Verification, and Formal Methods for Cyber-Physical Systems. In Cyber-Physical Systems; Elsevier: Amsterdam, The Netherlands, 2017; pp. 175–191. ISBN 9780128038017. [Google Scholar]
- Krichen, M.; Lahami, M.; Cheikhrouhou, O.; Alroobaea, R.; Maâlej, A.J. Security Testing of Internet of Things for Smart City Applications: A Formal Approach. In Smart Infrastructure and Applications; Mehmood, R., See, S., Katib, I., Chlamtac, I., Eds.; Springer International Publishing: Cham, Switzerland, 2020; pp. 629–653. ISBN 978-3-030-13704-5. [Google Scholar]
- Uzunov, A.V.; Fernandez, E.B.; Falkner, K. Engineering Security into Distributed Systems: A Survey of Methodologies. J. Univers. Comput. Sci. 2012, 18, 2920–3006. [Google Scholar]
- Crawley, E.; Cameron, B.; Selva, D. System Architecture: Strategy and Product Development for Complex Systems; Global Edition; Pearson: Edinburgh, UK, 2016; ISBN 978-1-292-11084-4. [Google Scholar]
- Walden, D.D.; Roedler, G.J.; Forsberg, K.; Hamelin, R.D.; Shortell, T.M. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 4th ed.; Wiley: Hoboken, NJ, USA, 2015; ISBN 978-1-118-99941-7/978-1-119-01512-3. [Google Scholar]
- Bochman, A.A.; Freeman, S.G. Countering Cyber Sabotage. In Introducing Consequence-Driven, Cyber-Informed Engineering (CCE), 1st ed.; CRC Press: Boca Raton, FL, USA; Taylor & Francis Group: Abingdon, UK, 2021; ISBN 978-1-00-313082-6. [Google Scholar]
- Fluchs, S.; Drath, R.; Fay, A. Evaluation of Visual Notations as a Basis for ICS Security Design Decisions. IEEE Access 2023, 11, 9967–9994. [Google Scholar] [CrossRef]
- Larkin, J.H.; Simon, H.A. Why a Diagram is (Sometimes) Worth Ten Thousand Words. Cogn. Sci. 1987, 11, 65–100. [Google Scholar] [CrossRef]
- Goolkasian, P. Pictures, words, and sounds: From which format are we best able to reason? J. Gen. Psychol. 2000, 127, 439–459. [Google Scholar] [CrossRef] [PubMed]
- Moody, D. The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. IEEE Trans. Softw. Eng. 2009, 35, 756–779. [Google Scholar] [CrossRef]
- Kosslyn, S.M. Graphics and Human Information Processing: A Review of Five Books. J. Am. Stat. Assoc. 1985, 80, 499–512. [Google Scholar] [CrossRef]
- Tastan, E.; Fluchs, S.; Drath, R. AutomationML-basierte Modellierungsansätze für ein Security-Engineering-Informationsmodell. In Tagungsband zur AUTOMATION 2022 (23. Leitkongress der Mess- und Automatisierungstechnik); VDI Verlag GmbH: Düsseldorf, Germany, 2022; ISBN 978-3-18-102399-0. (In German) [Google Scholar]
- Wieringa, R.J. Design Science Methodology for Information Systems and Software Engineering; Springer: Berlin/Heidelberg, Germany, 2014; ISBN 978-3-662-43838-1/978-3-662-43839-8. [Google Scholar]
- IEC 62443-3-2; Security for Industrial Automation and Control Systems, Part 3-2: Security Risk Assessment for System Design. IEC: Geneva, Switzerland, 2020.
- Fluchs, S.; Tastan, E.; Mertens, M.; Ritter, J.; Horch, A.; Drath, R.; Fay, A. Security by Design Decisions for Automation Systems. Part 2: Concept for Integrating Security Decisions into the Engineering Workflow. Atp Mag. 2022. (In German) [Google Scholar] [CrossRef]
- Fluchs, S.; Tastan, E.; Mertens, M.; Ritter, J.; Horch, A.; Drath, R.; Fay, A. Security by Design for Automation Systems. Part 1: Explanation of Terms and Analysis of Existing Approaches. Atp Mag. 2022. (In German) [Google Scholar] [CrossRef]
- Fluchs, S.; Tasten, E.; Mertens, M.; Horch, A.; Drath, R.; Fay, A. Security by Design Integration Mechanisms for Industrial Control Systems. In Proceedings of the IECON 2022–48th Annual Conference of the IEEE Industrial Electronics Society, Brussels, Belgium, 17–20 October 2022; IEEE: Piscataway, NJ, USA, 2022. ISBN 978-1-6654-8025-3. [Google Scholar]
- German Federal Ministry of Education and Research. IDEAS-Integrierte Datenmodelle for the Engineering of Automation Security. Project Overview (In German). Available online: https://www.forschung-it-sicherheit-kommunikationssysteme.de/projekte/ideas (accessed on 1 April 2023).
|Problem (and Causes)||Impact||Potential Solution |
(See Proposed Concept)
|1. “Undercover” security decisions: System characteristics that do not include obvious security technologies but have an impact on the system’s security posture are not identified as security decisions.|
Cause: These decisions are not included in security checklists, because they do not look security-relevant at first sight but are “other domains’ business”.
|Security decisions are missed during development and made without considering their security impact.||Do not identify security decisions based on potential security requirements (or the lack thereof), but based on security relevance of existing design decisions across all engineering domains.|
|2. Lack of comprehensive guidance for security decision making: There is no guidance that covers all decision-making paths (compliance-driven, risk-driven, goal-driven, library-supported). |
Especially, goal-driven and library-supported decision making is hardly present in state-of-the-art CPS security research.
For risk-driven security decision making: fragmented methods for single steps in the decision-making-workflow, but none that give comprehensive guidance from problem understanding to decision making.
|ICS/CPS engineers cannot turn to any single method they can use for their entire decision-making workflow. |
In addition, existing methods do not reflect the variety of reasons why they are making security decisions in reality.
Both factors are lowering the engineers’ willingness to adopt cybersecurity methods during design.
|Develop an overarching method that can incorporate different kinds of specialized methods, but that is simple enough to use by engineers that are not security experts.|
|3. Shortcomings in system understanding: There is little guidance and no comprehensive model for the system understanding phase at the beginning of risk-driven or goal-driven (and potentially library-supported) decision making.||Security decisions are made based on fragmentary system understanding.|
Security decisions and the assumptions that led to them are not documented systematically.
|Develop a security decision-making concept with a systematic, guided system-understanding phase. |
Develop a comprehensive security system model that contains security-relevant information for all decision-making steps along all different decision-making paths (e.g., threats, risks, goals, requirements, measures).
Make sure it is straight-forward to use system models when making security decisions.
|4. Lack of security decision traceability: It is difficult to clearly understand and document the rationale for each security decision. |
Cause: This is a result from problems 2 and 3. If the system understanding is only documented fragmentarily, and the logical steps from the system understanding to making the security decisions are not interconnected in a comprehensive method and data model, it is difficult to trace back a security decision to why it was made—which decision-making path was followed, which goal was to be fulfilled, which risk was to be mitigated, which regulation was to be complied with, and which system functions were to be protected.
|It is difficult to explain to third parties (e.g., clients or auditors), management, or even engineering colleagues why a security decision was made.|
When a system or its (threat) environment changes and security decisions need to be revised, they need to be made all over again because the rationales and underlying assumptions for the existing decisions are not known.
|Develop an easy, efficient way to document the reason behind each security decision, regardless of decision-making path.|
|5. Large amount of information to be digested: The amount of information that needs to be processed by the security decision maker has always been large, and it is increasing.|
Cause: Many of the state-of-the-art approaches that improve guidance for security decision identification and making at the same time increase the amount of relevant information: Adding “undercover” security decisions increases the number of decisions to be made. Overcoming the mechanistic system view and adding human stakeholders, their goals or intentions, and relations and dependencies between system components makes the system model more complex. The value of library-supported approaches increases with library comprehensiveness, also increasing the amount of potentially relevant information.
In addition, compared to software systems, the engineering of CPS (and especially ICS) involves more engineering domains than for a conventional software system, again increasing the amount of potentially relevant information for security decision making.
|The overwhelming amount of relevant information makes it more difficult to identify the relevant pieces of information for a decision at hand.|
It also makes security decision making more complex and time-consuming.
|Find efficient ways to filter and present the large amounts of security-relevant information to the security decision-maker.|
|6. Lack of tool support: There is no tool to support security decision making during system design. |
Lack of tool support was identified by many of the reviewed publications, especially those that work with libraries or ontologies or aim at automating certain parts of security decision making.
|With the increasing comprehensiveness (and complexity) of decision making, it becomes increasingly unlikely that engineers can follow a methodology without the clear guidance of a tool. |
Attempting to consider all information without tool support is error-prone and time-consuming.
Security decision making that is inefficient and time-consuming is very likely to be skipped altogether.
If security decisions are made, documentation is not likely to be produced without a tool, and it probably cannot be exchanged digitally with other engineering domains.
|Develop a tool that provides guidance through security decision making, efficiently stores and presents all required information, provides sound documentation with little overhead, and has interfaces to other engineering tools.|
|Library Category||Exemplary Functions in This Category|
|IT administration||Manage clients; administrate users; …|
|Security services||Detect malware; monitor security events; …|
|Network operations||Synchronize time; resolve names; …|
|Automated control||Influence physical process; transmit measurements to control system; …|
|Operate and monitor||Display controller states; react to alarms; force controller outputs; …|
|Cloud||Offline data analysis; forecast operating data; …|
|Office operations||Save files; place an order; pay a bill; …|
|Engineering||Update PLC logic; test and debug PLC logic; calibrate sensor; …|
|Building automation||Monitor climate; operate lights automatically; …|
|Communication services||Transfer file to third party; transfer file internally; send e-mail; …|
|Process information services||Archive process data; analyze process data; …|
|ID and Title||SP091: Logic Update during Operations|
|Description||Some controllers have a configuration that allows the controller logic to be updated during operation (i.e., the controller does not have to be shut down).|
|Entities 1||PLC; Safety PLC|
|Possible values||Enabled; disabled|
|Attack indicators 2||Enabled|
|Security relevance||Updating during operation may be technically necessary. From a security point of view, however, it makes it easier to manipulate the controller, and because the PLC is in operation, the manipulated logic would then also be directly productive, regardless of system state.|
|Workflow Step||Activity||Diagram Type|
|1. Identify security decisions||Choose/modify functions||Function diagram|
|Gain overview of security decisions |
that need to be made/have been made
|Security decision diagram|
|2. Fill decision base||Provide network architecture context||Function diagram|
|Define security goals||Security decision diagram|
|Define High-Consequence Events||HCE diagram (opt.),|
Security decision diagram
|Model attack scenarios leading to HCEs||Attack diagram (opt.), Security decision diagram|
|Define applicable regulation or standards||Security decision diagram|
|3. Make security decisions||Eliminate unnecessary functions||Function diagram|
|Decide about security parameters and document rationale(s)||Security decision diagram|
|Decision identification: Do decision makers identify more security decisions?||148 Decisions identified in 3.5 h.|
27 Additional 1 decisions identified
|Decision identification: Do decision makers identify the same security decisions independently from each other?||% Decisions identified by all test persons|
NOT MEASURED (only one group of test persons)
|Decision making: Can decision makers make security decisions autonomously based on the information offered?||61 Decisions made in 4 h (≈15 decisions/h) 2|
6 additional architectural decisions made
27 (44%) Additional 1 decisions made
4 (7%) Decisions changed 1
0 (0%) Decisions that could not be made
→ Were you the right person to make the decisions?
→ Why could you not make decisions/
which information was missing?
|Decision tracing: Can a third party understand why each security decision was made this way?||3 high-consequence events (HCEs), 10 attack scenarios, 11 security goals, 6 standards identified in 1 h.|
18 (30%) Goal-driven decisions
22 (36%) Risk-driven decisions
9 (15%) Compliance-driven decisions
35 (57%) Decisions based on a functional requirement 3
0 (0%) Decisions without a rationale
→ Likelihood of use for management/
|Decision re-use: Can artifacts used/produced during decision making be re-used in future projects?||14 Applicable library functions (13% of library)|
9 (64%) library functions modified
0 (0%) library functions newly created
135 Applicable security parameters (86% of library)
→ Likelihood of re-use in future projects?
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Fluchs, S.; Taştan, E.; Trumpf, T.; Horch, A.; Drath, R.; Fay, A. Traceable Security-by-Design Decisions for Cyber-Physical Systems (CPSs) by Means of Function-Based Diagrams and Security Libraries. Sensors 2023, 23, 5547. https://doi.org/10.3390/s23125547
Fluchs S, Taştan E, Trumpf T, Horch A, Drath R, Fay A. Traceable Security-by-Design Decisions for Cyber-Physical Systems (CPSs) by Means of Function-Based Diagrams and Security Libraries. Sensors. 2023; 23(12):5547. https://doi.org/10.3390/s23125547Chicago/Turabian Style
Fluchs, Sarah, Emre Taştan, Tobias Trumpf, Alexander Horch, Rainer Drath, and Alexander Fay. 2023. "Traceable Security-by-Design Decisions for Cyber-Physical Systems (CPSs) by Means of Function-Based Diagrams and Security Libraries" Sensors 23, no. 12: 5547. https://doi.org/10.3390/s23125547