The electricity sector increasingly intertwines IT and the physical grid, increasing the risk of cyber attacks on this critical infrastructure. Hitherto, we have developed a modeling method to support cyber-security by design in the electricity sector by providing (1) a multi-level reference model, (2) a semi-automated security assessment, and (3) a dedicated process model. In this paper, we focus on four challenges identified based on interactions with domain experts, namely: (1) automated model creation; (2) accounting for changing security requirements; (3) multi-level model management; and (4) incentives for modelers. These challenges are relevant to our modeling method and overlap with challenges on the practical uptake of modeling in general.
The electricity sector is increasingly characterized by an intertwining of IT and the physical
grid infrastructure [
Our research project fits squarely into design science research, and we have followed the
engineering cycles as proposed by [
In line with the research approach, we have involved domain experts at diferent stages of our undertaking to ensure the problem’s relevance and perform a reality check. The results of the conducted interviews and interactive workshops are stimulating, not only in terms of feedback on the designed artifact but especially in the sense that they confront our idealistic ideas of what a reference model should be able to accomplish, with down-to-earth insights from practitioners. In this light, this paper ofers a brief reality check of our modeling method, especially the gained feedback on the reference model and its (potential) usage. The results reported here provide input for our reference model specifically but also touch upon perceived challenges in the domain of conceptual modeling as such, referring to (1) automated creation and maintenance of models, (2) accounting for changes in the body of knowledge, (3) model management and support for diferent views, as well as (4) incentivizing users.
This paper is structured as follows. First, to make the paper self-consistent, we summarize our main artifact. Then, after discussing the involvement of domain experts, we report on identified challenges and resulting implications. The paper concludes with final remarks.
The targeted method encompasses (1) a reference model, (2) a corresponding process model, as
well as (3) supporting software tools. Being a design science artifact, our method is naturally
based on a set of design requirements grounded in the state-of-the-art on cyber-security by
design, smart grids, reference models, and multi-level modeling. Nevertheless, due to space
constraints, we focus on illustrating the artifact and refer to earlier work for further details
[
Multi-level reference model. The reference model accounts for the terminology used by
the community and is based on good practices and existing standards (to ease its adoption and
foster trust), among others: the NISTIR 7628 [
Looking at Fig. 1, the model provides an integrated view of the relevant aspects such as
assets, their connections, vulnerabilities, or attacks. For instance, in line with the concepts of
MAL and icsLang, the model accounts for the characteristics and dependencies among Attack
steps (A t t a c k S t e p , Level 2 (L2)), involved Assets (A s s e t , L4), C o u n t e r m e a s u r e s (Defenses) (L2) and
V u l n e r a b i l i t i e s (L2). Please note that the designed model uses numerous classification levels
to account for generic information (e.g., diferent categories of assets) and specific information
(e.g., specific threats and vulnerabilities of specific IT components). Furthermore, by capitalizing
on a relaxed type-instance dichotomy, we incorporate into the model (by assigning a state to
classes, populating the model with objects, and defining links) the current knowledge about,
e.g., possible attack vectors and their efects. Next, we use the defer instantiation mechanism (in
this case, the intrinsicness) to constrain the instantiation of properties to a specific classification
level [
A macro process for cyber-security by design. Our modeling method, cf. Fig. 2, which is
based on [
Security requirements analysis supported by multi-level modeling. To provide a more concrete description of our reference model, let us now zoom in on the first step: security requirements analysis. During security requirements analysis, we rely on the reference model excerpts presented in Fig 3 and Fig. 4. Note that these two figures present security-related concepts across multiple abstraction levels: from more invariant concepts, such as Use case and Requirement (in Fig. 3) to more scenario-specific ones, such as Billing being a specific Use case, and according Availability as a security requirement for Billing (in Fig. 4).
Let us now dive into further detail for the step of security requirements analysis, whereby we focus on the ACMe billing scenario. We start with selecting a Use Case, consistent with the scenario-driven nature of our modeling method, and specify it in turn of relevant attributes. An example of such an attribute, cf. the security requirements analysis view in Fig. 3, is the SGAM Domain. We subsequently select the relevant NISTIRInterface(s) associated with the selected use case. Here, we identify the NISTIR interface by a number, in line with the NISTIR 7628, but for usability purposes, we also ofer a short description of the NISTIR interface. The identified NISTIR interface(s) bootstrap the associated security Requirements. The requirements, especially the associated priorities, are of relevance. These priorities are set following the necessities of the NISTIR interface in question, and for informed decision-making, the priorities are accompanied by a rationale. 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). The output of this step is a set of prioritized security requirements, a given use case, and NISTIR interfaces.
When exemplifying the above description for our billing scenario, we take as a point of departure Billing, being a Use Case, which amongst others, is characterized as being relevant for customer premises (a value for the attribute sgamDomain, cf. Fig. 4). Subsequently, we notice that Billing is associated with two NISTIR Interfaces: 13 and 14 (both being a NISITRInterface whereby the value of the attribute number is initialized accordingly). Subsequently, from the known NISTIR Interfaces, we can derive the relevant security requirements, as shown in Fig. 4: Interface13Availability, which (cf. the logic from the NISTIR 7628) has the priority set to low, and Interface14Availability, which has the 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’). The output for this step is the billing use case, NISTIR interface 13, and security requirements with associated priorities, especially the requirement ‘Availability’ having the priority low.
Involvement of domain experts. In line with the design science research approach followed,
we have ensured the involvement of domain experts at diferent stages of our work. In the first
phase of the project, we employ semi-structured interviews with two experts from the security
and electricity sector respectively, and one expert for security in the electricity sector, to gain
feedback on the first version of our reference model, as well as the overall goals and vision of
our project, see [
Challenges. Based on the conducted interviews, we observed three types of challenges for applying our reference model that can be generalized to modeling challenges. These challenges relate to detailed and up-to-date information (Challenges 1 and 2), management of the model itself (Challenge 3), and a need for incentives (Challenge 4).
Challenge 1: Automated creation of IT infrastructure models, especially concerning Operation Technology (OT). Rationale: The domain experts liked the potential of linking the model to code and the flexibility in expressing information at diferent levels of abstraction. Indeed, in the last interview, in terms of potential, a favorable comparison was made to related modeling languages, especially to the Enterprise Architecture (EA) modeling language ArchiMate, which is currently used internally at the organization of the domain expert. The domain expert recognized the potential flexibility of multi-level modeling compared to ArchiMate by allowing adding new concepts while still providing a formalism allowing automation. At the same time, describing that the recommendations for the displayed scenario were considered a bit high-level and were not pointing towards complex IT infrastructure currently being a part of the organization.
In this light, the domain expert pointed out that he liked the potential of multi-level modeling
to keep a model in sync with code and generally keep the model in sync with organizational
data. One remark was, for example, especially data on the IT infrastructure, e.g., in line
with the idea of infrastructure as code. Nevertheless, our domain expert did point out some
challenges in keeping a model in line with IT infrastructure data. One issue is that, especially
in the electricity sector, one has to consider the Operation Technology (OT) next to the IT.
In particular, organizational stakeholders are careful when it comes to, e.g., scanning the OT
infrastructure. Our expert reported that scanning the OT infrastructure by classical IT means
letting the diferent devices crash, leaving the OT infrastructure unusable. Considering it,
although newly proposed approaches to automatically create IT landscape models [
Challenge 2: Accounting for ever-changing threats and countermeasures. Rationale: During the demonstration of our reference model, we used a smart metering scenario that was, among others, prone to impersonation attacks, and for which a countermeasure would be to cater for authentication so as to check for user identity. As a reaction, the domain expert stated that while sensible, the attacks and countermeasures encoded in the reference model could use further detail to have a substantial practical impact. Indeed, the domain expert suggested that to perform a security assessment of the system with a more practical impact, it is essential to link the infrastructure assets of a model to known and up-to-date threats and security vulnerabilities so that meaningful recommendations can be deduced from it. For example, such threats and vulnerabilities can be derived from the National Vulnerability Database (NVD1).
According to the expert, attacks and countermeasures must be kept in line with up-to-date
security information regarding the running system and external sources, such as repositories
with vulnerabilities. As such, we observe an overlap with Challenge 1, in the sense that it is
crucial that, for future reference, we capitalize on the potentials ofered by multi-level modeling
and keep the model up-to-date with detailed data on, both the running infrastructure [
Challenge 3: Model management for multi-level modeling. Rationale: While the reference model was deemed to hold potential, it was also deemed comprehensive. As a result, it was suggested that diferent views would be required, which present, at diferent levels of abstraction, diferent needs/views of both (1) stakeholders using information from the model, as well as (2) stakeholders that keep the information in the model up-to-date.
In light of this, we would like to highlight diferent points of attention, especially the need
for model management mechanisms for multi-level modeling. Such model management
mechanisms [
Challenge 4: A need for incentives. Rationale: While there is a need for automatically keeping the multi-level model up-to-date with domain information (see Challenges 1 and 2). Indeed, not all concerns related to modeling can be automated. Prominently user input is required on conceptual issues, such as deciding on new scenarios for which security by design would be required. For these concerns, the modeling needs to be performed by domain experts. However, these are classically rarely available, and thus, an incentive is needed so that their input is provided. Moreover, the incentives might need to encourage not only providing information once but to encourage continuous participation. Moreover, making maintenance as easy as possible is vital to keep the efort minimal. This also means that the notion of the multi-level model might be abstracted away as not to confuse the respective experts.
As such, to ensure the relevance of our reference model, we run into classical issues on
(1) modeling for the masses [
In this work, we have presented the key takeaways resulting from the involvement of domain experts in designing a reference model and a supporting process model. Here, we have highlighted the outcomes of challenges identified in the most intensive interview. These outcomes are not surprising but stress well-known needs in the conceptual modeling domain, such as (1) the automation of modeling tasks and (2) incentives for diferent stakeholders to provide their knowledge. These insights will shape our future endeavors of evolving our reference model and the linked modeling process to ensure its practical relevance.