In this section, we describe how powerLang is comprised. Therefore, we take a closer look at the reused languages, icsLang that bridges the identified gap between these two languages, and the mechanics that we apply to combine these languages.
MAL and reused languages
Before we present powerLang as a whole, we give first a short introduction to MAL so that the reader can understand the mechanics of MAL-based languages. Further, we give an overview of the reused languages. For detailed insights, we refer to the original publications introducing MAL (Johnson et al. 2018), coreLang (Katsikeas et al. 2020), and sclLang (Ling 2020).
Introduction to MAL
Hitherto, we proposed the use of system architecture models to conduct attack simulations (e.g., Ekstedt et al. 2015; Holm et al. 2015). However, our previous approaches used static implementations to represent assets and the related security information within the tools. Thus, changes to these underlying structures require high effort. Therefore, we developed MAL (Johnson et al. 2018). MAL itself defines which information about a system is required and specifies the generic attack logic. MAL is a meta language (i.e. the set of rules that should be used to create a new DSL) and represents no particular domain of interest. But it is to be used for creating languages that represent a particular domain. Before we explain such a concrete language, we present the basic building blocks of MAL, to ease the understanding of these languages.
First, a MAL language contains so called assets, which are the main elements found in the domain under study. Next, assets contain attack steps, which are actual attacks/threats that can be exploited. An attack step can be connected with one or more following attack steps to create an attack path. The sum of the attack paths are attack graphs used for the simulation. Assets can be linked by associations to model possible transitions of an attacker among them. Further, inheritance between assets is allowed as known from object orientation. Finally, there exists categories that allow organization of assets and probability distributions can be assigned to attack steps. A probability expresses the effort needed to complete the related attack step.
Next, we give a short example how a MAL language looks like. This example, which is a snippet of a complete language, contains attack steps on three assets. It illustrates how the attack steps are connected with each other, for example if one achieves blockingOperation, one is able to reach overspeed on Turbine and as a result finally lead to plantDamage and powerOutage on the power plant. Additionally, blockingOperation is annotated with Normal(5,0.2) meaning that an attacker’s effort is described by a normal distribution with a mean of 5 and a standard deviation of 0.2. In the last lines of the example, the associations between the assets are defined.
coreLang
As illustrated before, MAL provides the basics to create a threat modeling language from scratch. However, many languages created with MAL share a common set of concepts. To reduce unnecessary redundant work, we developed coreLang (Katsikeas et al. 2020) that is comprised of predefined assets that appeared in different languages created with MAL. Thus, this coreLang can serve as starting point to model more domain specific languages or even act as a rudimentary language to model simple environments. In the following, we will give a short overview on the basic elements of this language and refer to the original publication for all the details.
Figure 1 presents the overall structure of coreLang. The extends relationship expresses an inheritance between the parent and the child assets. Consequently, all attack steps and defenses of the parent asset are available in the child, too. However, it is possible to either complement the existing attack steps with further logic or to completely overwrite the logic. In contrast, the association relationship expresses possible paths for attackers between different assets. In other words, the associations describe the links between assets that can be used by attackers to traverse from one asset to another. For coreLang, we have identified six different main categories: system, vulnerability, user, IAM (Identity and Access Management), data resources, and networking. In the following, we will describe those categories and the related design decisions.
System
The first category, we like to shed light on, is system. This is the collection of assets that usually represent the computing instances in an environment, and thus are the natural attack surface. First, we created an asset called Object (inspired by the object in object-oriented programming languages) that provides common functionality to all inheriting assets. Basically, an Object is the simplest form of an asset that can be compromised by a Vulnerability. On the one hand, Object is specialized into System, which specifies the hardware on which Applications can run. The attacker can DoS everything that is running on it and access (using physical control) on the OS after effort. On the other hand, Object is specialized into Application, which specifies pretty much everything that is executed or can execute other applications. Lastly, this category contains PhysicalZone, which is the location where systems are physically deployed.
Vulnerability
The basic idea of creating a MAL related language is to provide a set of already known attack steps to the modeller. However, this incorporates two types of shortcomings. First, we concentrate on known attack steps. But, there are also attack steps that are not known yet. Second, we stay on a relatively abstract level for coreLang. Consequently, we cannot provide all possible attack steps upfront, as the attack steps are very diverse for different assets. To overcome this issue, we provide a set of Vulnerability and Exploit. On the one hand, these assets can be used as extension points for other language developers. On the other hand, we provide a standard set of Vulnerability and Exploit. These can be used by the end-user to model attack steps that are not known at the time of creating the language. Basically, an Object does have a Vulnerability that can have different levels of complexity to take advantage of. This Vulnerability can then be facilitated by an Exploit that leads to different levels of access to the exploited Object.
User
This category contains only the representation of a User. The User serves as attack surface for social engineering attacks. The most apparent attack modeled in this asset is the phishing, which can lead to either credential theft or takeover of the user’s computer. However, this asset will be extended to represent more attacks in future iterations.
IAM
is an accepted way to manage different identities representing users and their access to certain applications (Witty et al. 2003). Therefore, the category IAM is comprised of Identity that visualizes a user group. After authentication or compromise of an Identity, the attacker assumes its privileges. This is leads to both legitimate and illegitimate access. This access to an Identity is usually secured by means of Credentials. Those Credentials can be stolen/guessed by the attacker directly (e.g., due to brute-force) or the User can be convinced to enter them by herself (e.g., due to social engineering).
DataResources
This category groups the assets that are usually communicated. First, there is Data that represents any form of data that can be stored or transmitted. An attacker can perform the classical actions of read, write, and delete. Second, we have defined Information as an abstract concept that is incorporated in Data.
Networking
The last category elaborates on networking related assets. First, we have identified the Network where a network zone is a set of network accessible applications. The border of such a Network is a RoutingFirewall that specifies a router with firewall capabilities that connects many networks. Lastly, there are Connections between Applications that allow a communication along different Networks, and consequently, a lateral movement of an attacker.
sclLang
The standard IEC 61850 was developed as substations became increasingly automated and digitalized to help with the transition (IEC Standard 2003). One part of this standard is the Substation Configuration Description Language (SCL). SCL was created to help with compatibility of different vendors and to share configurations of Intelligent Electronic Devices (IEDs) (IEC 2018). Because modern substations built according to the IEC 61850 standard already have existing configuration files according to SCL, we decided to build a DSL based on SCL so that this already existing information could be used to create threat models.
In sclLang (Ling 2020), the assets and their associations are precisely as specified in SCL as seen in Fig. 2. These assets are divided into three different categories. The Functional assets are related to the main substation functionality and includes, for example, transformers that are most often used to alter the voltage level. The Product category includes the products used in a substation, for example the IEDs that are used to enable automation. Finally, the Communication category includes all assets that are needed for the communication of the IEDs.
Regarding attacks, the attack steps in sclLang are access, communicate, execution, impact and hasRouter.
The attack steps access, execution and impact are from the categories of tactics as found in the ATT&CK Matrix for Enterprise (MITRE 2020a). Please note that access has been renamed from the category Initial Access. The categories of attacks were used to keep the complexity of the attacks down in the first version of the language. The attack step communicate was added to model how an attacker may communicate throughout the substation. Finally, the attack step hasRouter was added because whether an IED has the routing function enabled or not affects the attacker possibility to move throughout the substation.
Access
The attack step access is the first attack that an external attacker would perform to gain initial access to a substation. It is possible that, for instance, a disgruntled employee would not need this attack step. After the attacker has access, they can move further through the substation by reaching other attack steps.
Communicate
The modern IEC 61850 substations are built with communication networks and this attack steps shows how the attacker would be able to move through the network and therefore also the substation. Most of the communication happens through the access points, which can be physical or logical interfaces. If one IED has two different access points that are part of two different subnetworks, it is possible for the attacker to move between the subnetworks in a substation.
Execution
The term execution in attacks is often defined as running malicious code. In a substation it is not necessarily code that creates certain actions but instead sending and receiving logical nodes. Logical nodes are sent for automation purposes to increase the voltage when a specific voltage level is detected. In this sense, one can consider that sending logical nodes is similar to execution of malicious tasks in an IT system. If an attacker reaches the execution attack step it is possible to potentially shut down the entire substation.
Impact
The attack step impact means that the attacker has managed to in some way made an alteration in the substation. As described above in execution, the substation automation happens with logical nodes. This means that if an attacker can make an impact on a logical node, perhaps make the voltage level seem lower than it actually is, a malicious execution to increase the voltage level can occur and cause damage to the substation. It is also possible for the attacker to use that impact attack step to alter the clock, which is essential to the synchronization of substations and cause disruptions in this way.
HasRouter
The attack step hasRouter is reached only if the router functionality is enabled on an IED. Similar to IT networks a router is needed to move between subnetworks in a substation. With this attack step it is possible for an attacker to move throughout the substation in between subnetworks.
In terms of MAL, this means that the AccessPoint can either have a Router existing or not. If the router exists, then the attacker can reach the attack step and communicate across Subnetworks. However, if no Router exists the attacker will not succeed to communicate.
icsLang
Following, we will focus on icsLang (depicted in Fig. 3) that is based on the ATT&CK Matrix for ICS (MITRE 2020b). The main asset in this language is represented by the IcsAsset. It represents the abstract common behavior of all represented assets. Therefore, we have created a connection to IcsNetwork to illustrate that assets can communicate with each other if they are attached to the same network. The rest of the language is structured along the MITRE ATT&CK categories level 2 (supervisory control), level 1 (control network), and security.
Level 2 The supervisory control LAN level includes the functions involved in monitoring and controlling physical processes and the general deployment of systems. The central asset on this layer is the ControlServer which operates the Controller on level 1 and also computes their output (Stouffer et al. 2011). Those ControlServer and Controller are configured, maintained, and diagnosed using EngineeringWorkstations. To carry on the entire system, the operators use human machine interfaces (HMI) that provide a graphical user interface to EngineeringWorkstations and ControlServer. Lastly, there is a DataHistorian on level 2, which provides access to external users that are interested in data access for archival or analysis.
Level 1 The control network level includes the functions involved in sensing and manipulating physical processes. This is usually done by Controller that are controlled by ControlServer situated on level 2. However, this connection is not direct, but through an IOServer that provides the interface between the control system LAN applications and the field equipment monitored and controlled by the control system applications. Additionally, there exists a safety layer consisting of safety instrumented systems (SIS). The function of protective relaying is to cause the prompt removal from service of an element of a power system when it suffers a short circuit or when it starts to operate in any abnormal manner that might cause damage or otherwise interfere with the effective operation of the rest of the system.
Security Originally, the ATT&CK Matrix for ICS does not include security related assets explicitly. However, for every asset, there are mitigation defined that can be also modelled as assets. First, we introduced an AntiVirus that can detect malicious files on connected assets leading to a higher effort an attacker has to spend. Second, we added a Firewall that can block certain ports, enforce white lists, or apply intrusion detection systems (IDS).
Attack Steps The ATT&CK Matrix for ICS contains 81 different techniques that can be used to exploit an ICS environment. Every of these techniques can be an attack step in our icsLang. As the justification if a certain technique will be included into the language would be quite extensive, we will focus on the overarching eleven tactics similar to the approach followed in substation-DSL. Based on the techniques, we will argue if a related technique will be included as attack step or not.
When we create MAL languages, we assume worst case scenarios, meaning that the attacker already knows about the architecture of the attacked organization. This leads to the decision that techniques related to collection, discovery, and lateral movement does not needed to be modelled in icsLang. Additionally, command and control related techniques that describe the way the attacker connects to the environment are not taken into account.
Another set of techniques, we will not model explicitly in our language, are related to the techniques of evasion, persistence, and inhibit response function. These techniques aim to masquerade the doing of the attacker or to create hooks which should prevent the lock out of the attacker by countermeasures. This cannot be represented in MAL directly but is already included in the given probabilities that a certain attack step is successful.
The rest of the techniques follow the common attacker’s behavior pattern of access, privilege escalation, and harm the system (Ramsbrock et al. 2007). First, the techniques related to initial access provide either the initial attack surface or the entry-point to an asset due to lateral movement through the network. If the access is established, the attacker can perform techniques related to execution to perform a privilege escalation. Reaching this stage allows to perform attack steps that end up in impact on the asset or impair process control. Impact means in this case that ICS systems, data, and their surrounding environment can be manipulated, interrupted, or destroyed. Impair process control leads to manipulation, deactivation, or physical damage on control processes.
Probability Distributions on Attack Steps For MAL based languages it is essential to define probability distribution on attack steps and defenses to describe how much effort an attacker has to spend to exploit certain attack steps or to which degree a defense is successful. Unfortunately, research that assess such probability distributions is quite scarce and often we have to rely on expert knowledge to model them. In the following, we will give an overview of the applied probability distributions that can be found in literature. Nonetheless, we like to highlight that the following distributions reflect not the entire reality but rather are approximately reasonable as long as no more solid studies on each and every attack step has been conducted. Additionally, the main contribution of this paper are the structures provided before and not the figures presented next.
First, (Baggett 2008) has identified that if anti-malware is enabled on a system, an attacker’s success probability decreases to 90%. Therefore, we model a defense on different attack steps such as modifyControlLogic or rootkit with a Bernoulli distribution of 0.9. This means that if an anti-malware is in place it will be effective in 10% of the cases.
Second, research (Holm 2014; Sommestad and Hunstad 2013) has elaborated on identifying the effort that an attacker needs to spend to bypass an IDS. This effort depends on different parameters as the IDS is tuned and updated regularly. However, due modeling reasons we assume the worst case that the IDS is neither patched nor updated leading to an exponential distribution with a median of 3.5 days.
Third, from an interview with a domain expert in combination with vulnerability data from the US National Vulnerability Database (NVD), we conclude that a man in the middle attack is successful in 99% if no defense is in place and in 1% if the communication is encrypted. Accordingly, we model defenses with corresponding Bernoulli distributions.
Fourth, the probabilities of finding an entrance in a misconfigured firewall are gathered from a non-published expert survey performed in June 2016. According to the survey, a one day effort will result in a 28% probability of finding an entrance, after ten days the probability is 55%. The estimated gamma parameters then become 0.33, and 74.
Linking languages
So far, we have presented different languages that can be used to model different parts in the energy domain. However, to provide a fully functional language that covers the needs of the energy domain, these languages need to be linked to each other. Generally, there are two ways to link MAL-based languages to each other: First, associations between different assets of languages can be created. In this case, additional attack steps need to be created to make use of these associations. Second, inheritance relations between the assets of the different languages can be established.
In our approach, we rely on the second way as it figured out that it requires less effort to keep the links when one of the languages is updated. In relation to the Purdue Enterprise Reference Architecture (PERA), the three languages can be situated on different level. coreLang refers mainly to the levels 3 and 4 representing the business IT. icsLang is mainly situated on the levels 2 (supervisory control) and 1 (control network itself), while sclLang includes level 1 and 0 (physical processes, sensors, and actuators). Consequently, we will link coreLang to icsLang and icsLang to sclLang as presented in Fig. 4.
To link coreLang to icsLang, we specify that the IcsNetwork is a specialized Network and IcsAsset is an Application. Due to this, the assets of both languages are linked to each other. Additionally, the attack steps need to be connected. Therefore, we overwrite authenticate that leads to the icsLang specific authenticatedAccess. Further integration is not needed.
Similarly, we proceed with linking icsLang and sclLang. We define that Equipment is a Controller, IED is a SIS, and Server is a ControlServer. To link the attack steps to each other, we overwrite authenticatedAccess that it leads to execution on Equipment. On the IED, we overwrite access that it leads to communicate. Same for Server where authenticatedAccess leads to communicate.