The increased reliance of organizations on information technology inherently increases their vulnerability to cyber-security attacks. As a response, a host of cyber-security approaches exists. While useful, these approaches exhibit shortcomings such as an inclination to be fragmented, not accounting for up-to-date organizational data, focusing on singular vulnerabilities only, and being reactive, i.e., focusing on patching up vulnerabilities in current systems. The paper presents and evaluates a modeling method aiming to address those shortcomings and to support security by design with a focus on the electricity sector. The proposed modeling method encompasses a multi-level reference model reconstructing and integrating existing initiatives and supporting top-down and bottom-up analyses. Compared to earlier work, the paper contributes (1) a process model for cyber-security by design, which proactively considers security as a first-class citizen during the design process, (2) a complete coverage of the multi-level model, in terms of three views complementing the introduced process model, (3) an elaborated evaluation, in terms of reporting on an additional design science cycle.
Notes
Accepted after 1 revision by Hans-Georg Fill.
1 Introduction
In the context of digital transformation, information technology (IT) has brought about considerable changes in various industries, whether structural organizational changes, value creation, or others (Vial 2019; Kraus et al. 2022). Consider the digital transformation of the electricity sector, which is also in the focus of this paper: digital transformation enables a variety of new business models (Niesten and Alkemade 2016; Paukstadt and Becker 2021), such as smart electric vehicles, where IT can be used to optimize charging times (Niesten and Alkemade 2016; Paukstadt and Becker 2021), or smart decentralized energy sources, where predictive maintenance may be used for example to support offshore wind turbines (Paukstadt and Becker 2021). Nevertheless, digital transformation also inherently comes with a variety of challenges. Among these are (cyber-)security concerns, both for industries in general (Vial 2019) and for the electricity sector in particular (Cozzi et al. 2017, p. 124). Digital transformation especially includes a fuller integration of the different components over the internet, leading to a greater attack surface, i.e., to more vulnerabilities and entry points that attackers can leverage (Möller 2023). These weaknesses can devastate the different digitized units, such as organizations, industries, or regions. This had been, for example, demonstrated for the electricity sector by a well-orchestrated cyber-security attack on the Ukrainian electricity grid, targeting the IT infrastructure of a regional electricity distribution company, which caused power outages affecting approximately 225,000 households (Case 2016; Stellios et al. 2018).
Cyber-security has often been treated as something to be accounted for or added later to existing applications and systems (Wyatt 2017). Recently, it has become clear that to keep up with the increasing frequency and sophistication of attacks on IT infrastructures, in contrast to the traditional security-by-obscurity principles, organizations need to apply a proactive approach (Abraham et al. 2019). Rather than treating cyber-security as an afterthought or a supplementary layer to be added to existing systems, it is increasingly recognized that a holistic, integrated approach is essential. This systemic perspective, often encapsulated in the concept of cyber-security by design, emphasizes the necessity of incorporating cyber-security considerations throughout the entire product lifecycle (Geismann et al. 2018). Such an approach inherently acknowledges that a system’s resilience against threats is significantly enhanced when security is embedded in every part of the system’s architecture rather than being tacked on. This paradigm shift towards viewing security as an integral, inseparable aspect of system design underscores the relevance and superiority of a systemic approach over piecemeal strategies, highlighting that the system is more than the sum of its parts.
Advertisement
Despite various initiatives which are focused on evaluating and enhancing cyber-security by design, challenges persist in specific areas. For instance, securing SCADA systems (Cherdantseva et al. 2016) and ensuring cyber-security within particular domains like smart grids (Darteh et al. 2022) present unique difficulties (Cherdantseva et al. 2016; de Kinderen et al. 2022).
First, the approaches tend to be fragmented, and lack comprehensive coverage of life-cycle phases relevant to security by design (Geismann et al. 2018). For one, there is a focus either on top-down security requirements analysis (for example, with the NISTIR 7628) or on analyzing specific vulnerabilities, attacks, and countermeasures, but not on both. Second, the existing approaches focus on singular vulnerabilities of components, not the system which comprises these components. Third, the approaches insufficiently account for up-to-date data on security attacks, and fourthly, they often lack software tool support.
To address these challenges and help organizations follow the cyber-security by design principles, we deem conceptual modeling (Mylopoulos 1992) to be a promising instrument, and therefore, we have proposed in our previous work a reference model for cyber-security by design for smart grids (de Kinderen et al. 2022), which combines the NISTIR 7628 (National Institute of Standards and Technology 2010) with a threat modeling language (Katsikeas et al. 2020). The reference model provides static support for end-to-end model-based cyber-security analysis, and as such supports security and domain experts which only have basic knowledge of the others (i.e., security or the domain under study) to design secure systems. Namely, the developed reference model provides support during all phases: starting from the identification of (security) requirements, through the identification of relevant assets, assessment of risk and identification of countermeasures, to, finally, the design of a supporting architecture. Please note that here the term “system" represents an entire organization as it comprises a combination of interacting components or applications. Thus, our approach does not address the cyber-security analysis of a single component or application.
As the initial reference model itself supported a top-down security analysis (de Kinderen et al. 2022), to support the bottom-up security analysis, such as vulnerability analysis, we complemented the reference model with attack simulations (Hacks et al. 2022). To this aim, we extended the reference model by including the aspects required for the vulnerability analysis and we provided support for simulations and threats analysis based on the extended model.
Advertisement
Both previous works focus on tooling (i.e., the reference model (de Kinderen et al. 2022) and the attack simulations (Hacks et al. 2022)). As such, they do not offer guidance on how concrete reference model instances can be created, meaning that methodical support is lacking. Accordingly, in this paper, we tackle the following research question: How can the proposed multi-level reference model be explicitly used to support comprehensive security analyses for cyber-security by design? To address this question, we provide a corresponding process model that guides the use of the multi-level reference model and supporting tools and discuss its application in the electricity sector. In addition, this paper reports on a validation of our modeling method.
Our work fits squarely within design science (Hevner et al. 2004) and follows the engineering cycles as proposed by Wieringa (2014). In this paper, we cover a complete engineering cycle which is a continuation of the outcomes of two previous engineering cycles. As such, it can be characterized as follows: (1) Problem identification and treatment design: based on existing threat modeling approaches, we design a process that suits the demands of a multi-level threat model while accounting for the bi-directional top-down and bottom-up security design. For treatment design, we identify requirements based on insights from previous engineering cycles. (2) Treatment implementation: Besides the design of the new process, we have extended the earlier version of the multi-level model to be in line with the requirements. Additionally to the extensions, we organize the multi-level model into viewpoints, each of which accompanies the process model. (3) Treatment validation: we perform a lightweight demonstration of the proposed method including our extended model and the process in interviews with three experts from the electricity sector, cyber-security domain, and modeling domain.
This paper targets both researchers and practitioners who are active and/or interested in cyber-security by design and/or the electricity sector. For researchers, we discuss a multi-level reference model and a dedicated method in the context of cyber-security by design, benefiting from an integrated modeling and programming environment, as a possible solution for the existing challenges in the domain. For practitioners, we show how the reference model may be instantiated and used to guide the security analyses from the beginning of a project, and point out the benefits of such a solution, as reported by domain stakeholders.
The paper is structured as follows. First, to make the paper self-consistent, in Sect. 2 we provide a short overview of the main concepts, approaches, and challenges in the field of cyber-security by design and point out how conceptual modeling can contribute to resolving those challenges. Next, in Sect. 3 we present our method’s goals and targeted vision, which is based on our previous research and has been further developed to reflect the identified need for a guiding process. In Sect. 4, we explain our research approach and discuss the role of domain experts. In Sect. 5, we introduce the multi-level reference model on which the method operates, which was originally presented in (de Kinderen et al. 2022) and has been updated to fit the process model, which is newly developed in this work and presented in Sect. 6. We discuss the proposed approach’s utility and position it towards other approaches in Sect. 7. The paper concludes with final remarks and an outlook on future research.
2 Background
The background section serves as the bridge between the introduction and the body of the manuscript. It establishes the context for the research by discussing relevant literature and outlining the knowledge gap the research aims to fill.
2.1 Cyber-Security by Design: Concepts, Approaches, and Challenges
The origins of “security by design” can be traced back to the 1970 s when the US Defense Science Board Task Force on Computer Security formulated that “[p]roviding satisfactory security controls in a computer system is a system design problem” (Ware 1970). Firstly, this was referred to as “secure design patterns” (Dougherty et al. 2009), but later the term “secure by design” was established (Santos et al. 2017).
“Security by design” includes two key terms: a result (i.e., “security”) that is realized by concrete actions (i.e., “design”) (Bygrave 2022). “Security” refers to the “absence or limitation of vulnerabilities or threats” (Kahn et al. 2011) towards a referent object like privacy or safety of persons, business success, or state sovereignty (Dunn Cavelty 2014). Often, this is boiled down to the triad of Confidentiality, Integrity, and Availability (CIA) (Herrmann and Pridöhl 2020).
“Design” is an ambiguous term. For instance, consider the way the term is treated in the work of Hartzog (2018). Here, the author refers at one time to the process and the results of technologies, at another time to a system’s functions and its effect on people, and finally to the creation of tools for understanding and acting under current conditions. Given the various definitions and uses of the term “design”, see Bygrave (2022), it can be argued that the term connotes an intentional, directed activity. Design involves engineering in the sense that it brings about something (Bygrave 2022).
Ensuring security in critical infrastructures is challenging because, as already mentioned, security is classically ensured ex-post. Therefore different ways to enable security by design have been proposed. For instance, Payette et al. (2015) argue that security should be a concern of IT project managers and propose to extend project management activities accordingly. They determine six security characteristics relevant to projects and extend a project maturity model to assess project security. Geismann et al. (2018) take a similar approach and integrate secure software engineering practices into the engineering process of Cyber-Physical Systems (CPS). Security requirements are defined on the system level and tracked to countermeasures. In turn, Liu et al. (2022) take a more formal position and argue that security concerns should already be considered in the mathematical-formal assessment of CPS. Using the term “secure-by-construction”, they point to information-theoretic foundations, data-driven approaches, and security for network multi-agents as future directions for such formal assessments.
2.2 Modeling in Support of Security Analysis
A wide variety of already established methods support the overarching goal of security by design. Some of them rely on an instrument to help deal with complexity, supporting understanding and enabling communication between involved stakeholders; namely, they apply conceptual modeling. Conceptual modeling may be defined as “the activity of formally describing some aspects of the physical and social world around us for understanding and communication” (Mylopoulos 1992). The application of modeling to support security analyses is deemed promising as: (1) it can promote a shared understanding of, among others, the existing vulnerabilities and possible attack vectors (Jiang et al. 2023; Geismann and Bodden 2020; 2) it has the potential to relate IT issues to enterprise-level use scenarios (Jiang et al. 2023); and (3) conceptual modeling facilitates (semi-)automated reasoning, enabling, among others, simulation. In addition, please note that the application of a modeling language forces one to be concrete and specific, which makes the analysis more valuable. Moreover, various modeling languages may be used together to offer more comprehensive analyses of a system under study.
Various conceptual modeling approaches have been proposed to support security analyses, such as risk assessment methods (ENISA 2022) that operate on different abstraction levels. For one, they support analysis of the entire organization as such, on a systems level, and for single software systems.
For instance, on an organizational level, FAIR (Freund and Jones 2015) aims to support managers in making better decisions by understanding organizational risk. Therefore, FAIR provides tools for understanding, measuring, and analyzing information risks. The approach is covered by different areas like risk theory, risk calculation, scenario modeling, and communicating risk within the organization. Based on this information, the risk is quantified according to threat actors, vulnerabilities, and incident impact.
In contrast, PASTA (Morana and Uceda Vélez 2015) was designed with IT, security, compliance, and risk leaders in mind, supporting them in mitigating risks and reasoning about different threats. Accordingly, it is a risk-centric threat modeling framework. PASTA leads the risk assessor with an iterative, adaptive process focusing on business impact, threat research, and countermeasures.
Similarly, TRIKE (Saitta et al. 2005) follows a process that starts with defining the system via a data flow diagram and its elements like actors, resources, intended actions, and rules. Next, threats are identified based on two categories: elevation of privilege or denial of service. Finally, the risk of certain threats is determined according to their impact on business objects and the threat’s probability.
A popular and widespread method to assess different threats to a system is STRIDE (Shostack 2014). STRIDE uses data flow diagrams to represent the system and attach different threats that could impact the system. The threats are grouped into six different categories, which give STRIDE its name: Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. STRIDE has been further developed into DREAD (Shostack 2008) to better evaluate threats while considering Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability. Therefore, each category has different values assigned and, thus, enables the calculation of an average value representing the overall system’s risk.
On the more detailed level of software systems design, the software engineering community relies on model-based security analysis to support a manual security assessment (e.g., CORAS (Lund et al. 2010), secureTROPOS (Mouratidis et al. 2002), and SecDSVL (Almorsy and Grundy 2014)) or automated security assessment. The automated approaches (e.g., UMLsec (Jürjens 2002, 2005), SecureUML (Basin et al. 2006, 2011), SECTET (Alam et al. 2007; Hafner et al. 2006), and STS-ml (Paja et al. 2015)) allow to specify a software system’s set of components and their interactions. Security properties enrich this specification, enabling the automated analysis based on formal reasoning, thus allowing statements about the software system’s security.
Besides the aforementioned approaches for security analysis, which tend to be general purpose, similar work for SCADA systems and CPS exists, which is sometimes framed in the light of the ISO 31000:2009 risk management process. Our contribution focuses on achieving security by design as a fundamental principle within modern risk management to address potential risks as early as possible rather than treating them as an afterthought.
Regarding SCADA systems, Cherdantseva et al. (2016) reviewed 24 different methods to assess the cyber-security of SCADA systems and suggest a categorization scheme for such methods. They identified five challenges for future research, which also guide our work: (1) the methods either focus on a holistic assessment while neglecting SCADA-specific details or on certain parts while falling short of the big picture, (2) most methods concentrate on singular vulnerabilities, not the system itself, (3) data on security attacks on SCADA systems is missing, (4) the presented methods miss a proper validation, and finally, (5) the methods are lacking tool-support.
When it comes to CPS, for instance, Tantawy et al. (2020) develop a model-based approach for the risk assessment of CPS and evaluate the approach in a test bed with real-world industrial controllers and communication protocols. The assessment is guided by identifying physical vulnerabilities, modeling the environment, and testing the vulnerabilities found in the test bed. The authors recognize within their work the benefits of automatizing the analysis itself. Finally, Jiang et al. (2023) employ conceptual modeling in general and multi-level modeling in particular for security analysis focusing on the electricity sector. Jiang et al. (2023) aim at specific vulnerabilities, attacks, and failure propagation. This approach is reactive, focusing on vulnerabilities and attacks of existing infrastructure.
3 Vision and Motivating Scenario
Our solution is designed for organizations that value security as an inherent part of the design of new solutions, and is demonstrated for organizations active in the smart grid domain, both to ensure their processes’ functionality and protect their customers’ sensitive data. To illustrate our goals and targeted outcomes, consider the following exemplary scenario. A utility company, ACM-e, wishes to digitalize its processes. They have deployed traditional analog meters to their customers, which are supposed to be exchanged with modern smart meters to enable, inter alia, a fully digitalized billing process. Simultaneously, ACM-e is aware that security aspects are important for the new architecture to ensure their processes’ functionality and protect their customers’ sensitive data.
Considering the above, the scenario of interest refers to the billing in smart grids, which relate to the capturing and processing of time-based energy consumption data from customers’ smart meters (Brown et al. 2008). The automated data collection enables ACM-e to transform their billing processes and offer time-based rates to their customers. Further, they can remotely initiate or terminate services without sending a technician. Finally, the more detailed available data can ease the optimal planning, design, maintenance, and development of tailored services. Moreover, ACM-e desires to reduce its costs associated with meter readings and increase its billing accuracy and distribution planning. The billing process relies on smart meters, a customer gateway, and a metering data management system, which uses a Home Area Network (HAN) and Wide Area Network (WAN) for communication.
As this digitalization enables attackers to penetrate the infrastructure, there is a need to account for cyber-security aspects. Therefore, a project team must be established to address security issues from the very beginning of the project. Although the project members are familiar with the basic security-related concepts and smart grid-specific aspects, they do not consider themselves security experts. Therefore, they decided to use a method based on existing reference models to ensure that security and domain-specific aspects were addressed. Based on this scenario, as well as on the analysis conducted of existing body of knowledge, we identify the following requirements which the method of choice should meet:
Requirement 1
Guide throughout the entire life-cycle of the system.
Rationale: In line with the core ideas of cyber-security by design, e.g., see (Geismann et al. 2018), the guiding process model should account for the entire life-cycle of the system under design to cover both proactive design steps during early activities such as the identification of requirements, to more reactive design steps, like assessment of the system.
Requirement 2
Provide an integrated conceptual coverage of a system’s life-cycle phases.
Rationale: As we intend to cover all steps throughout a system’s life-cycle, in line with Geismann and Bodden (2020), it naturally follows that the envisioned modeling method should provide an integrated conceptual coverage for associated domains and organizational perspectives. For instance, for identifying security requirements, concepts such as use case and security requirement are necessary (National Institute of Standards and Technology 2010); on the other hand, for security assessment, concepts such as assets, their associations, threats, and vulnerabilities would need to be accounted for (Hacks et al. 2020).
Requirement 3
Accounting for both high-level and specific aspects.
Rationale: Different types of analysis require information on different granularity levels (Atkinson and Kühne 2001). For example, one can conceptualize generic dependencies between the concept of asset and attack, and make these dependencies more specific for concrete threats for a particular asset, such as different threats that might exist for a particular meter.
Requirement 4
Support for analysis, documentation, and communication.
Rationale: In line with some of the key aims of conceptual modeling (Thalheim 2011), the models created should (1) provide information for the needs of targeted analyses, but also (2) serve as documentation for the performed steps and results achieved (e.g., uncovered vulnerabilities and risks), as well as (3) support communication among involved stakeholders. Regarding the latter, we require domain-specific concepts close to the professional terminology the involved domain stakeholders use.
Requirement 5
Accounting for existing up-to-date domain information.
Rationale: The approach shall enable security and domain experts to conduct security-related analysis. Therefore, it is important to integrate the model with external data sources that provide operational-level information and up-to-date information on vulnerabilities (Hamlet and Keliiaa 2010; Rosa et al. 2017).
Requirement 6
Reflect standards and current practices on cyber-security.
Rationale: In order to not reinvent the wheel and to also offer a modeling method that is in line with notions (presumably) familiar to end users (Frank 2014), the conceptual underpinnings of our modeling method shall reflect the state of the art in cyber-security, as reflected in standards and current practices.
On the one hand, reflecting on the fulfillment of the requirements by the relevant approaches discussed by Shevchenko et al. (2018) (e.g., not considering LINDDUN as it is privacy focused), and on the other hand also considering the NIST cyber-security framework (National Institute of Standards and Technology 2024), and (Jiang et al. 2023) as additionally relevant approaches, we can see that the methods cope well with achieving conceptual coverage and support the analysis, documentation, and communication (cf. Table 1). Regarding the analysis, the automation support is limited, even if the approaches allow some automation in the form of spreadsheets. Moreover, most approaches struggle to address a high-level assessment of the entire organization while accounting for specific aspects. This is also reflected in the fact that solely the approach of Jiang et al. (2023) accounts for domain-specific aspects. Finally, standards and current practices are of minor importance and are only reflected if the used method is itself a de-facto standard.
Table 1
Related work fulfillment of requirements
National Institute of Standards and Technology (2024)
Legend: X – Requirement fulfilled; O – Requirement partially fulfilled
Due to, on the one hand, the importance of cyber-security and the challenges of cyber-security by design analysis, and on the other hand, a lack of a comprehensive modeling solution to support organizations through different stages of creating secure systems (cf. Sect. 2), we aim to provide organizations with a multi-level modeling method offering the required support.
4 Research Approach
As discussed in the introduction, our work fits squarely within design science (Hevner et al. 2004) and follows engineering cycles as defined by Wieringa (2014), cf. Table 2. The targeted modeling method, i.e., the artifact we design, encompasses (1) a multi-level (reference) model (cf. Sect. 5), (2) a corresponding process model guiding the usage of the multi-level model (cf. Sect. 6), as well as (3) supporting tools and mechanisms.
Table 2
Performed engineering cycles
1st Engineering cycle
2nd Engineering cycle
3rd Engineering cycle
Main outcome
A multi-level reference model, support for top-down approach
An extended multi-level model, support for bottom-up analysis, tool support
A process model guiding usage of the (extended) multi-level model
Problem
Identification
Utilizing conceptual argumentative exploration and confrontation of our vision and goals to the state of the art, we identify a research gap to which our reference model is a response
Whereas the provided reference model supports the top-down analysis, the capability to support vulnerability analysis is still missing
A process model that suits the demands of a multi-level threat model while accounting for bi-directional top-down and bottom-up security design is missing
Treatment design
Based on driving goals and an illustrative scenario, we identify a set of requirements that our reference model should fulfill
A set of requirements pointing to the required extensions to the multi-level model; based on the related work, we decide to build on the simulation capabilities of a selected attack modeling language, icsLang
A set of requirements stemming from insights generated by previous engineering cycles
Treatment implementation
We provide a first sketch of a multi-level reference model and implement it in a supporting tool
We extend the earlier version of the multi-level model in line with the requirements and the selected modeling language, and, to capitalize upon the simulation capabilities of icsLang, we realize a toolchain between (Hacks et al. 2022)
The design of the new process model, together with the set of supporting artifacts, an extended version of the multi-level model, in line with the requirements. The process is based on:
\(\bullet\) current processes for security by design
\(\bullet\) expert feedback from the first engineering cycle (especially taking into consideration the IT infrastructure present at an organization, next to the reference model)
Treatment validation
An evaluation using a confrontation to the requirements, as well as feedback gathered from expert interviews
A lightweight evaluation of our extended model and toolchain in terms of a realistic attack scenario to check the applicability and utility of the proposed solution
A lightweight demonstration of our extended model and the process by applying them in workshops with three domain experts
In the first engineering cycle, see de Kinderen et al. (2022), we proposed a reference model for cyber-security by design for smart grids, which combines the NISTIR 7628 (National Institute of Standards and Technology 2010) emphasizing security requirements, use cases and assets, with a modeling language for vulnerabilities, attacks, and countermeasures (Katsikeas et al. 2020). The proposed reference model supported top-down security analysis and received positive feedback from domain experts.
In the second engineering cycle (Hacks et al. 2022), we (1) extended the reference model with the aspects required for the vulnerability analysis, such as assets’ vulnerabilities or defenses; (2) enabled simulations and threats analysis, based on the extended model; and (3) provided initial support to analyze the business impact of the identified threats. We perform this extension because identifying vulnerabilities through security testing is widely applied to assess and improve the security of systems (Xiong and Lagerström 2019). Also, by conducting attack simulations one can detect threats and evaluate alternative security designs enabling proactive identification of threats (Ekstedt et al. 2015).
In the third engineering cycle we aim to design a process model which is guided by the created reference model. Moreover, we present an adaptation of the reference model based on the received feedback from domain experts. Finally, the three domain experts were asked to evaluate the newly developed process model.
In line with the research approach followed, we have ensured the involvement of domain experts at different stages of our work. This involvement of domain stakeholders was aimed to assess the potential benefits of our work. During the first engineering cycle, we employed semi-structured interviews with two experts from the security and electricity sector respectively, and one expert for security in the electricity sector (cf. Table 3, Participants 1-3). During these interviews we gained feedback on the first version of our multi-level reference model as well as on the overall goals and vision of our project. During the third engineering cycle, we engaged with three domain experts to evaluate the created modeling method (cf. Table 3, Participants 4-6). Note that the second engineering cycle did not involve domain experts, as it focused on developing a software tool chain.
Process modeling, enterprise (architecture) modeling, UML
UML, DSLs, enterprise architecture modeling
Experience with enterprise modeling
Experience with enterprise modeling
5 Multi-level Security By Design Method: Multi-level Reference Model
5.1 Language Architecture and Rationale for Selection
Considering the requirements discussed in Sect. 3, it follows that the language architecture used to design the targeted reference model shall (1) allow for the natural modeling of domain hierarchies and allow for expressing both generic and specific knowledge; it should also (2) allow for incorporating domain knowledge (among others, current knowledge about requirements, possible threats, countermeasures, effects, as well as assets) into the reference model. In addition, (3) the language architecture used to create any reference model should also support expressing variability while avoiding redundancy. This means that a reference model should distinguish between those parts of the system that are invariant within the group of intended users, and other parts that may need individual adaptation, see also (de Kinderen and Kaczmarek-Heß 2021). Moreover, (4) while supporting adaptation (and extensions of a model), compliance and integrity of the system should be ensured. Finally, (5) in order to support different types of (also automated) analysis, the reference model and its underlying language architecture shall support not only a static perspective on the domain at hand, but also a functional one.
Considering the above requirements towards the language architecture, for the needs of the modeling method, we develop a reference model using a selected multi-level modeling approach, namely the Flexible Meta Modeling and Execution Language (FMMLx) (Frank 2014). We adopt multi-level modeling (Atkinson and Kühne 2001) as in opposition to conventional meta-modeling (1) one can define an arbitrary number of classification levels in the same body of a model. Accordingly, one can employ as many classification levels as needed for expressing the domain knowledge at hand (Atkinson and Kühne 2008), and not only two (M2 and M1) as in conventional meta-modeling. Please note that by employing an arbitrary number of classification levels one may account for both high-level information (e.g., generic types of threats, generic types of assets), as well as more specific ones (typically accounted for on lower classification levels, e.g., a specific threat to a specific asset), see Requirement 3; (2) one can defer instantiation, meaning that one can constrain the instantiation to a model element at a specific classification level (Frank 2014). This is opposed to shallow instantiation for conventional meta-modeling, whereby one can instantiate only to the directly proceeding level; (3) one can relax the strict separation between type and instance (Atkinson and Kühne 2001), allowing one to populate and use a model with instance-level data, and thus, incorporate relevant information into the model (see Requirements 5 and 6). Although a number of multi-level modeling approaches have been proposed, to the best of our knowledge only the FMMLx comes with an integrated modeling and execution engine (Frank 2014), which we need in order to account for both static and functional view. Thus we select the FMMLx together with the XModeler to create our multi-level reference model.
Table 4 provides a summarized comparison between using conventional meta modeling (on the example of UML) and multi-level modeling (on the example of FMMLx) to create a reference model, considering three aspects: possibility to account for generic and specific aspects, a support for variability, as well as support for consistency-preserving adaptation. As can be observed, UML offers several mechanisms which at least partly may address our requirements. Especially, the combined use of generalization/specialization, redefinition, and default values allows us to account for both general concepts and their relevant properties, and specific concepts and their properties, to cover specific scenarios. However, UML also comes with a set of limitations, which are alleviated by FMMLx. This is mainly because, being a multi-level modeling approach, FMMLx treats classification levels as a first class citizen and relaxes the strict separation between types and instances. Importantly, compared to the UML in FMMLx hierarchies can be created without redundancies or inconsistencies, and can also conceptually speaking be succinctly created (e.g., without the need to overload the level, or having to use both redefinition and default values as workarounds, when instantiation can suffice). In addition, the intrinsicness offered by FMMLx specifically, and the notion of deferred instantiation generally, allows us to specify at what level of classification a model element should be instantiated. In contrast, with the shallow instantiation of UML this kind of constraining according to level of classification is simply not possible. Finally, FMMLx lends itself naturally to model adaptations, since it enforces monotonic model extensions, and at least conceptually speaking one makes the adaptations in one and the same body of model.
Table 4
Comparing UML and FMMLx for addressing reference model challenges (de Kinderen and Kaczmarek-Heß 2021)
Lang.
Generic and specific
Variability
Adaptation
UML
+ creating hierarchies of concepts with generalization /specialization
+ assigning values using default values and redefinition
− modification of default values restricted to type level
− underspecified semantics of redefinition, violation of monotonic model extensions
− overloading the level
+ mature tools and mechanisms
+ covering variability and redundancy
− “shallow instantiation”, no possibility to constrain model elements according to their classification level
− monotonic model extensions are likely not guaranteed
+ mature tools and mechanisms
− reference model adaptation either (1) needs additional consistency checking mechanisms, when simply duplicating it, or (2) leads to redundant model elements, when instantiating it (due to a strict separation between types & instances), or (3) lacks consistency checking mechanisms when using power types.
+ mature tools and mechanisms
FMMLx
+ an arbitrary number of classification levels allowing to create hierarchies of concepts
+ relaxed type-instance dichotomy allowing to assign state to classes
- immaturity of model management mechanisms
+ intrinsicness (deferred instantiation)
+ an arbitrary number of classification levels
+ relaxed type-instance dichotomy
− immaturity of model management mechanisms
+ monotonic model extensions
+ adapting one and the same body of model
− immaturity of model management mechanisms
Fig. 1
Excerpt of the Multi-Level Reference Model, for an overview of FMMLx’s concrete syntax, cf. Frank (2018)
×
5.2 Multi-level Reference Model
A short description of the main features of the developed multi-level reference model follows.
5.2.1 Having an Integrated View Based on Existing Standards
Supporting cyber-security by design implies that all relevant concepts from different phases of an undertaking, cf. Table 5, starting from the identification of (security) requirements, through identification of relevant assets, risk assessment, as well as identification of countermeasures, and finally the design of a supporting architecture need to be considered. Therefore, the designed multi-level reference model provides an integrated view of the relevant aspects such as assets, their connections, threats/vulnerabilities, attacks, their effects, and possible defenses, making all of these concepts the multi-level model’s first-class citizens.
Table 5
Domains of interest
Phase
Relevant concepts
Exemplary sources
Identification of security requirements
Scenario, use case, security requirement
NISTIR, SGAM
Identification of relevant assets
Assets and their characteristics
MAL, icsLang
Security assessment
Assets, asset association, threat, vulnerability
icsLang, ATT &CK, NVD
Identification of countermeasures
Threat, countermeasure/defense, asset
icsLang, ATT &CK, NVD
Design of a supporting architecture
Assets, their associations
icsLang
The created multi-level reference model accounts for the terminology the community uses to foster its understandability. Also, the reference model is based on good practices and existing standards to ease its adoption and foster trust. As a starting point, we account for fragmented but complementary approaches, namely: (1) the NISTIR 7628 (National Institute of Standards and Technology 2010), which is a reference architecture for defining ideal-type smart grid scenarios and associated security requirements. Note that there also exists the more recent NIST security framework National Institute of Standards and Technology (2024). Nevertheless, besides this framework focusing on high level security outcomes, the NIST security framework is intended to be domain independent. As such it lacks smart grid specific details, like smart grid specific use cases. For the foundations of our modeling method, we therefore focus on the NISTIR 7628; and (2) the Meta Attack Language (MAL) (Johnson et al. 2018) with icsLang (Hacks et al. 2020). MAL is a meta-language used to develop domain-specific languages (DSL) for threat modeling and defines which information about a system is required. Moreover, it specifies the generic attack logic. Therefore, a MAL DSL contains the main elements encountered in the domain under study, so-called assets. The assets contain attack steps, representing the actual attacks/threats associated with them. Attack steps can be either of the type OR or the type AND and be linked to each, thus creating an attack graph for the attack simulation. IcsLang is organized into four categories, focusing on which assets interact. Assets within the category of computing form the main body of assets commonly found in cyber-physical environments. To interact with each other, the computing assets exchange data with each other. A characterizing property of industrial control systems (ICS) is the control as the physical world is monitored, and based on the given input parameters, decisions are taken. Besides the control functionality, ICS offers different interfaces to close the gap between humans and systems.
Additionally, we rely on the taxonomy and instance knowledge for adversary tactics and techniques provided by ATT &CK (Strom et al. 2018). Next, to structure and represent the smart grid-specific concepts, we benefit from the Smart Grid Architecture Model (SGAM), which is a product of the standardization process in the EU Mandate M/490 (SGAM 2012), which provides a set of concepts, viewpoints, and a method for standardized decomposition of smart grid systems with a focus on interoperability (Gottschalk et al. 2017).
Figure 1 presents a small excerpt from the multi-level reference model implemented using the XModeler. Please note that for readability purposes, we present only selected concepts, attributes, and operations assigned to different classification levels. For a detailed description of FMMLx, we refer to Frank (2014, 2018). Apart from the “traditional” modeling constructs such as (meta)classes (assigned to different classification levels, cf. the number standing on the left side in the class header), attributes, operations, and relationships, it is possible to defer an instantiation of modeling constructs by assigning a so-called level of intrinsicness (denoted as a white digit in the black box). Intrinsicness dictates at which classification level a given property (attribute, operation, or association) will be instantiated.
Being based on the above-mentioned standards, as well as aiming at supporting all phases of cyber-security by design, the multi-level model Fig. 1 encompasses such concepts as UseCase, Asset, Requirement, AttackStep, or Countermeasure. In line with the concepts of MAL and icsLang, the multi-level reference model accounts for the characteristics and dependencies among Attack steps (AttackStep, Level 2 (L2)), involved Assets (Asset, L4),1Countermeasures (Defenses) (L2) and Vulnerabilities (L2).
5.2.2 Accounting for Generic and Specific, as Well as Populating the Model with Information
NISTIR 7628 and MAL/icsLang include general security concepts like CIA requirements, threats, vulnerabilities, and assets to be secured. At the same time, they include concepts specific to the electricity sector, e.g., NISTIR interfaces related to smart grid areas in terms of connections between components in those areas. Therefore, the multi-level reference model provides information at varying levels of abstraction, i.e., it covers both general security concerns and concerns specific to the electricity sector, as well as different types of vulnerabilities/assets and dependencies among those.
In addition, the multi-level model has been extended with additional information so that not only high-level concepts such as asset or vulnerability are accounted for, but also further information on their possible types, products, and models is provided for in the model. In addition, by benefiting from the relaxed type/instance dichotomy, the known information on, e.g., possible attack vectors as well as vulnerabilities of different asset types, models, or products, is incorporated into the model.
Looking at Fig. 1 we account for different categories of assets such as hardware, software, computing platform, or supporting artifacts, then specific types are considered on L2 and instantiated into specific types on L1. Here, both generic IT infrastructure/Information system elements may be accounted for (e.g., Routing Firewall, SCADA System) and specific products (e.g., a specific router offered by company X). We can also observe the domain-specific knowledge, among others, in the form of already provided slot values, instantiated associations (e.g., links), as well as additional well-formedness constraints (defined using XOCL).
5.2.3 Support for Automated Analysis, Computations, and Simulations
To provide semi-automated support for a variety of security analyses, next to supporting a static perspective on the domain at hand, the language architecture shall also support a functional perspective. Such semi-automated simulations would also enable non-security experts to assess the security of their systems. For instance, to identify security threats by generating attack graphs cf. Katsikeas et al. (2020). As the XModeler is an integrated modeling and programming environment, it allows to account for both static and functional aspects. Therefore, apart from accounting for attributes or providing slot values, we can also define operations such as identifyThreats() or identifyCountermeasures() for the metaclass Asset. The multi-level reference model supports conducting analysis in cases when relatively little is known about the specific configuration of the system, e.g., when only high-level information about the main elements of the system is provided, or when it is known that some asset, such as a sensor, router or firmware is used; however, no specific details regarding a specific asset instance are known.
6 Multi-level Security by Design Method: Process Model
Figure 2 presents the macro process for our cyber-security by design modeling method. These steps are based on (1) the synthesized steps of Geismann and Bodden (2020) for model-driven engineering of security in cyber-physical systems, (2) the steps of the top-down portion from the NISTIR 7628 (National Institute of Standards and Technology 2010, pp. 8-9) and Chan and Zhou (2013), as well as, (3) our previous work de Kinderen et al. (2022) and Hacks et al. (2022).
Fig. 2
The cyber-security by design method
×
The collapsed sub-processes, highlighted in Fig. 2, are covered in this paper and are discussed in the following. Here, each sub-process is accompanied by (1) an excerpt of the reference model view relevant to the sub-process, and (2) the modeling method elements used in conjunction with the reference model and the process. These additional modeling method elements, in Table 6, detail for each sub-process the involved participants/roles, supporting tools and instruments, and the expected input and output.
Table 6
Elements of the modeling method
Element
Security requirements analysis
Systems design
Security analysis
Input
Business process documentation (for use scenario), existing security policies and involved roles
Security requirements, infrastructure model (both IT, and physical)
Assets and their associations, vulnerabilities repository
Participants / roles
Smart grid domain expert, Business analyst, security analyst, if available
CPS infrastructure manager (knowing both IT and physical assets)
We start with the selection of a Use Case, and proceed with selecting the associated NISTIRInterface(s). Here, we identify the NISTIR interface by a number, in line with the NISTIR 7628, but for usability purposes, we also offer a short description of the NISTIR interface.
Then, the identified NISTIR interface(s) bootstrap the associated security Requirements. For the requirements, especially the associated priorities are of relevance. These priorities are determined according to the NISTIR interface at hand. Nevertheless, while the priorities are set with a default value (as per the attribute defaultPriority), for a specific use case a deviating priority can also be selected (as per the attribute useCaseSpecificPriority). Furthermore, for informed decision making the priorities are accompanied by a rationale. Note that, by virtue of the ability to assign state information to classes (cf. Sect. 5), we can specify attribute values at any abstraction level in our reference model (such as for the attribute defaultPriority).
The output of this step is a set of prioritized security requirements, a given use case, and NISTIR interfaces.
Fig. 4
The security requirements view: an excerpt of more invariant concepts
Fig. 5
The security requirements view: an excerpt of concepts specific to the scenario
×
×
EXAMPLE: For our billing scenario, we take as a point of departure Billing, being a Use Case, which, amongst others, is relevant for customer premises. Subsequently, we notice that Billing is associated with two NISTIR Interfaces: 13 and 14. Subsequently, from the known NISTIR Interfaces, we can derive the relevant security requirements, as shown in Fig. 5: (1) Interface13Availability, which has its priority set to low, and (2) Interface14Availability, which has its priority set to high.
The rationale for these derived priorities is that for typical metering scenarios, availability, in terms of metering data being transmitted in (near) real-time to a utility, is less important relative to the requirements of (1) the metering data received by a utility being an accurate reflection of the amount of electricity that is consumed and produced (cf. the requirement Integrity), and (2) that the metering data can only be accessed by the relevant parties (cf. the requirement Confidentiality). This rationale is encoded for the security requirements associated with NISTIR interface 13. Nevertheless, in some cases, also for metering scenarios, one might set priorities differently, as encoded in NISTIR interface 14. It is here, especially based on the rationale documented in the reference model, that the reference model user can make an informed choice concerning security requirements prioritization. For the sake of the scenario, we assume that NISTIR interface 13 is selected.
Note the highlighted elements in Figs. 4 and 5. On their basis we will briefly illustrate two strengths of multi level modeling, as discussed in Sect. 5.2: to account for the generic and the specific, and to populate the model with information as needed. For the generic and specific, note that in Fig. 4 a NISTIR interface has an association with Requirement, whereby the association shall be instantiated on level L1 (as per the highlighted intrinsicness 1 on the association end in Fig. 4). Subsequently, we use the information so codified on a higher level of abstraction for the information codified in Fig. 5. In Fig. 5 we see that, for information on a lower level of abstraction, the particular NISTIR interface 13, being an instance of NISTIR interface, is associated to Interface 13 Availability, a particular requirement which resides on level L1. As to the ability of multi level modeling to express a model with information as needed, consider the attribute defaultPriority for the concept Interface13Availability. in Fig. 5 we see that defaultPriority has been assigned the value <priority low>, as per the intrinsicness 1 of defaultPriority for the concept Requirement in Fig. 4, whereby the intrinsicness of 1 dictates that this attribute shall be instantiated on level L1. Assigning the value <priority low> to the attribute defaultPriority is an example of, both, assigning state information to attributes of a concept, as well as serves to illustrate the organization by levels, whereby intrinsicness defined on a higher level of abstraction dictates on which level an attribute value shall be initialized.
The output for this step is constituted by the billing use case, NISTIR interface 13, and security requirements with associated priorities, especially the security requirement Availability with the priority low.
6.2 Step 2: Systems Design
In this step, we identify assets and relations between them. Referring to the micro process (Fig. 6) we do so per abstraction level, in a top-down manner.
Fig. 6
The systems design micro process
×
Given an abstraction level, to identify relevant assets we can readily rely on those already encoded in the reference model, as they are associated with the Use Case and NISTIR Interface identified in Step 1 (see Fig. 4). Once the Assets for a given abstraction level are derived, we use the corresponding AssetAssociations from the reference model to relate assets to each other.
Once the assets from the reference model are identified for each abstraction level we check for any missing assets. Prominently, such missing assets can originate from the current IT infrastructure, which needs to be accounted for in the security design. Any missing assets are encoded into the reference model-based internal documentation, such as models of the (IT) infrastructure. Note here that FMMLx only allows for monotonic model extensions, so that at least in terms of language architecture any extensions are in line with the existing concepts and are conflict-free.
The output of this step is a set of assets and their relations, existing at varying levels of abstraction.
EXAMPLE: For the Billing Use case and NISTIR interface 13, we find that, among others, the assets Smart Meter, Communications Network, and Metering Data Management System are relevant. Of these, for a given abstraction level, as shown in Fig 7, we can set the SGAM properties as soon as this is known. For example, we can declare at level L2 that a smart meter is located at the customer premises (cf. the SGAMDomain). In contrast, a metering data management system on level L2 can be declared part of the distribution grid. Moving down the abstraction hierarchy, for ACME specifically we can introduce different smart meter models and their according attributes, like the SDM230 having MODBUS as a communication protocol. Also, moving further down the hierarchy, we can introduce particular kinds of communication networks, like the Wireless Area Network.
Next, in connecting the assets, we assume that ACME follows a direct communication architecture. Such an architecture connects smart meters and metering data management systems directly through a communication network, without intermediate components such as data aggregators (Shokry et al. 2022, p. 361). We model such a direct architecture for two abstraction levels: on the level of a communication network and the level of a wireless area network as a type of communication network. These different abstraction levels for the assets and their interconnection allow us to identify suitable vulnerabilities as discussed in the next step.
Fig. 7
The systems design and analysis view: an excerpt
×
6.3 Step 3: Security Analysis
Fig. 8
The security analysis micro process
×
During security analysis (the micro process in Fig. 8), we input the assets identified in Step 2 and use the security analysis view to identify attack steps associated with these assets.
Subsequently, we identify the order in which these attack steps occur. This is so since attack steps often occur in sequence (Hacks et al. 2022), with one attack step (e.g., smart meter intrusion) often taking place before another attack step (e.g., data theft of a smart meter, after its intrusion). Once attack steps have been identified, for each attack step, we identify corresponding countermeasures as they are encoded in the reference model.
Note that in the reference model, we identify attack steps, their relations, and countermeasures per abstraction level in the multi-level model (as expressed in the micro process in Fig. 8). Furthermore, we proceed with said identification in a top-down manner. This means that we start with identifying attack steps for assets residing at higher abstraction levels (for example, a smart meter) and proceed to identify potential attack steps for assets at lower levels of abstraction (e.g., SM 230 as a particular smart meter, cf. Figure 7). Please note that any additional attack steps identified while moving down the abstraction hierarchy are added by monotonic extension, in the sense that attack steps for more specific assets do not modify or replace attack steps for assets residing on a higher level of abstraction.
After analyzing the existing multi-level model, our method offers the possibility for a simulation of attack steps. The basic idea of this simulation is to employ multiple simulation runs to identify key vulnerabilities along a path of attack steps to support the prioritization of countermeasures. A detailed explanation of said simulation capabilities can be found in Katsikeas et al. (2020).
Finally, we can prioritize countermeasures. This prioritization can happen according to (1) the security requirements identified in Step 1, (2) the location of the attack step in the overall sequence of attack steps so identified, and (3) the results of the simulation of attack steps.
The output of this step is a set of prioritized countermeasures, as they are relevant to attack steps for particular assets.
EXAMPLE: From our security analysis view (Fig. 7), we firstly find that, for the combination of the assets Communication Network, Smart Meter, and Metering Data Management System (together forming a direct communication architecture, cf. (Shokry et al. 2022, p. 361)), Impersonation can be performed as an attack step. This attack step exploits the bidirectional communication vulnerability in which an attacker can impersonate the metering data management system to gain access to the smart meter (Shokry et al. 2022, p. 361). Once gaining access to the Smart Meter through Impersonation, the attacker can perform the next attack step to instigate a remote shutdown of the Smart Meter.
To counter the two mentioned attack steps ACMe can employ the following countermeasures. Firstly, conforming to the security analysis view, authentication can be employed as a countermeasure to safeguard the identity of the metering data management system and thus counter the attack step of impersonation. Secondly, one can disable the remote shutdown of the smart meter as a countermeasure so that in case of intrusion, the attacker’s options are limited.
Moving down the abstraction hierarchy, we also discover more specific attack steps relevant to more specific assets. Specifically, for a wireless area network being a specific type of communication network, a potential jamming attack can become relevant (Aravinthan et al. 2011; Shokry et al. 2022). With jamming, an attacker disrupts the wireless communication by sending out signals on a shared medium (Aravinthan et al. 2011), thus disrupting communication needed for, e.g., monitoring and estimation functions (Zhang et al. 2019). While a jamming attack is generally difficult to defend against, a potential countermeasure encoded in our reference model, as proposed by Aravinthan et al. (2011), is to move through a list of predefined channels to prevent an attacker from attacking jamming one particular signal.
Finally, we prioritize countermeasures and select authentication based upon (1) the security requirement identified during the step security requirements analysis. Recall that, according to NISTIR Interface 13, integrity and confidentiality were prioritized over availability. This fits well with authentication since the needed extra computational capability might run counter to availability; authentication does fit nicely to achieving the prioritized integrity and confidentiality requirements; (2) the location of the attack steps. Here again, authentication seems to fit well since it aims to make smart meter access more difficult, thus preventing attack steps that can be carried out once smart meter access has been gained.
7 Evaluation and Discussion
We now reflect on the extent to which our modeling method fulfills the requirements discussed in Sect. 3, as well as its utility, as pointed out by the domain experts.
7.1 Requirements Fulfillment
In line with the cyber-security by design philosophy, our method provides comprehensive coverage of a system’s design, both proactively during early stages, like security requirements analysis, and in later phases, such as security analysis, where the focus is on attacks and countermeasures for given assets. This comprehensive coverage is catered for in terms of the stages covered (Requirement 1) and the used concepts (Requirement 2). Additionally, by adopting FMMLx as a multi-level modeling approach, we enable the expression of information at a high level of abstraction and the expression of specific information (Requirement 3). The flexibility in selecting a level of abstraction, combined with the domain-specific nature of the (security, electricity sector) concepts in our reference model, also allows the use of terminology familiar to end users, thus supporting communication and documentation (Requirement 4). Nevertheless, as visualization and model management are still known research issues for multi-level modeling in general and for FMMLx specifically, the active use of our reference model for documentation and communication purposes is still a point for further research.
Additionally, by benefiting from the relaxed type-instance dichotomy of FMMLx (again, see Sect. 5) we can keep the model up to date concerning domain information (Requirement 5). Finally, by adopting well-established concepts from NISTIR 7628, powerLang, and from modeling approaches for cyber security by design (Geismann and Bodden 2020), our modeling method is based on state-of-the-art standards and practices in (cyber-) security by design (Requirement 6).
7.2 Feedback from Domain Experts and Expected Utility of the Method
From the conducted interviews (cf. Sect. 4), we mainly gained feedback on the utility of the designed artifacts, the coverage, and understandability, and also observed a need for a clear return-on-modeling-effort (Guizzardi and Proper 2022).
Regarding utility, the reference model is perceived as a useful knowledge base for non-domain experts. For example, Participant 3 (see Table 3) mentions how the reference model could help identify security concerns for a currently running project on developing a platform for sourcing inverters for solar panels. In fact, while the electricity sector has the expertise to develop this platform, the related security concerns are less well understood. However, the utility must provide concrete and up-to-date coverage of assets, threats, and their mitigation. When it comes to the utility of our method’s basis in standards, the participants mentioned using the ISO 2700X series (Participant 1) and NISTIR 7628 (Participant 4) as typical sources of information. Therefore, they positively assessed the coverage of the reference model. Nevertheless, other standards such as MODBUS and IEC 61850 were also mentioned (by Participant 3) and recommended for inclusion in the reference model. The participants also mentioned the need to adjust the standards to local needs, supported by the reference model. Finally, Participant 5 remarked that choosing an appropriate level of abstraction is a pertinent issue in the security domain. Therefore this participant appreciated our modeling method’s inherent flexibility, allowing one to choose an abstraction level as needed. Nevertheless, it was recommended that the modeling efforts should start from the abstract view of an organization, created by people with a good overview of the system, and then let stakeholders complete the details with detailed knowledge about single parts of the system.
In terms of understandability, participants indicated that they could understand the concepts within the multi-level model after explanation, even those concepts that were not from their domain (see the participant backgrounds Table 3). However, the idea of multi-level modeling needed further explanation to the participants, as it is not easy to grasp initially, even for those familiar with conceptual modeling. Participant 3 initially interpreted the different levels in a multi-level model as reflecting their importance. For example, for Participant 3, a requirement would be more important than a use case because a requirement resides on level L3, whereas a use case resides on level L2. Only after explanation did the domain expert understand that the levels pertain to the organization of classification levels. Additionally, Participant 5 remarked on the complexity of the multi level hierarchies. He pointed out that a filtering mechanism to hide unnecessary information would be and add to the understandability of our multi-level models. Finally, Participant 4 pointed out a potential language barrier in the inherent reliance of our modeling method on English, since on a day-to-day basis, potential users of the method may be more likely to use their native language. Regarding the process model, the provided steps were overall assessed as reasonable and logical by the participants of the third design science cycle, in particular by Participants 4 and 6.
The feedback of domain stakeholders points to the need for a clear Return-on-Modeling-Effort (RoME). Such a RoME involves, on the one hand, that the application of the method should provide non-trivial information to end users so that the invested effort (e.g., the effort invested in creating models and using them in the analysis process) is perceived as justified by the users. On the other hand, for a clear RoME, additional mechanisms and incentives are needed. Regarding the latter, we gained feedback from the third engineering cycle interview mainly on four aspects, discussed subsequently.
(1) Automated model creation: Due to the considerable complexity of the systems, it is vital to support modelers in their work where possible. This includes the automated generation of the model based on existing information or automatized scans of the infrastructure. However, it was pointed out that this might be challenging in cyber-physical environments as automatized scans could crash those.
(2) Accounting for changing security requirements: The threat landscape is continuously changing. Therefore, the multi-level model must address the latest vulnerabilities by, e.g., including up-to-date databases like the National Vulnerability Database (NVD). Moreover, it was stressed that the derived recommendations to address these vulnerabilities must go beyond the obvious, such as keeping the latest patch level.
(3) Multi-level model management: The multi-level model covers different levels of abstraction and domains in the organization. None of this information is available from a single person in an organization. Accordingly, it is necessary to provide different views to stakeholders in both capacities: to analyze and maintain the model.
(4) Incentives for modelers: Not all model creation aspects can be automated. Therefore, it is important to continuously motivate the related stakeholders to share their knowledge of the multi-level model. This could be achieved by easing the provision of the related information and creating directly perceived added value to the stakeholders.
Thus, to ensure the practical adoption of the modeling method, we run into the classical issues of (1) modeling for the masses (Sandkuhl et al. 2018), which reflects on establishing a bridge between “model like” artifacts like spreadsheets which contain valuable domain knowledge, and a conceptual (enterprise) model, as well as (2) the Return on Modeling Effort (Guizzardi and Proper 2022), the highlight of which is that the effort put into domain modeling should be met by benefits that one can reap from it.
7.3 Positioning Towards Related Work
As already mentioned in Sect. 3, no comprehensive solution exists that addresses all requirements. Closest to our method comes the work of Jiang et al. (2023). Similar to our work, Jiang et al. (2023) employ conceptual modeling in general and multi-level modeling in particular for security analysis focusing on the electricity sector. Besides these similarities, substantial differences exist. First, there exist differences regarding the main goals and scenarios supported. Especially, Jiang et al. (2023) aim at specific vulnerabilities, attacks, and failure propagation. Their model is thus reactive, focusing on vulnerabilities and attacks in existing infrastructure. In contrast, our modeling method targets a security-by-design approach and thus is proactive by explicitly considering security as part of the design process. The second difference lies in the ability to keep the model up to date with data from the running organization. FMMLx, the language on which our reference model is built, inherently can keep a model synchronized with data from, e.g., the running organization. To the best of our knowledge, while Jiang et al. (2023) certainly benefit from tool support (through ConceptBase), compared to our approach, there is a less natural capability to keep model and data in synchronization; Third, the level of provided guidance differs. Jiang et al. (2023) introduce three artifacts: a general taxonomy for systems modeling (both information technology and operational technology, the latter touching on the cyber-physical systems side, cf. Jiang et al. (2023)), an artifact for teasing out functional dependence, and an instantiation of the two mentioned artifacts for the power domain. However, user guidance for the presented artifacts is missing. Our modeling method offers a multi-level model process, accompanied by typical method elements such as relevant stakeholders, inputs, outputs, and more (see Table 6).
8 Conclusions
In this paper, we present a modeling method for cyber-security by design. As a continuation of earlier work, we particularly focused on the procedural guidance of our modeling method, as well as its comprehensive presentation in terms of three views that complement the procedural guidance. In addition to an extra round of validation (the third design science cycle), we also conducted a comprehensive validation of the method.
For future work, we intend to, first, address the usability of our multi-level model. As stated in Sect. 7, while conceptually appealing, we still need to address the lack of visualization and model management inherent in the use of multi-level modeling. As a first step, the use of viewpoints with relevant information tailored to specific roles would be promising. Second, in terms of validation, a further evaluation in a real-life setting may be useful to learn from. In line with the further evaluation, third, we also intend to make simulation capabilities an inherent part of our modeling method. In earlier work, we have already achieved encouraging results by relating the multi-level reference models to attack graph-based reasoning, but due to scoping and space constraints we could not fully utilize these results for the present paper.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
WI – WIRTSCHAFTSINFORMATIK – ist das Kommunikations-, Präsentations- und Diskussionsforum für alle Wirtschaftsinformatiker im deutschsprachigen Raum. Über 30 Herausgeber garantieren das hohe redaktionelle Niveau und den praktischen Nutzen für den Leser.
BISE (Business & Information Systems Engineering) is an international scholarly and double-blind peer-reviewed journal that publishes scientific research on the effective and efficient design and utilization of information systems by individuals, groups, enterprises, and society for the improvement of social welfare.
Texte auf dem Stand der wissenschaftlichen Forschung, für Praktiker verständlich aufbereitet. Diese Idee ist die Basis von „Wirtschaftsinformatik & Management“ kurz WuM. So soll der Wissenstransfer von Universität zu Unternehmen gefördert werden.
