Towards formal verification of cyber security standards

. Cyber security standards are often used to ensure the security of industrial control systems. Nowadays, these systems are becoming more decentralized, making them more vulnerable to cyber attacks. One of the challenges of implementing cyber security standards for industrial control systems is the inability to verify early that they are compliant with the relevant standards. Cyber security standard compliance is also only validated and not formally verified, often not providing strong proofs of correct use of cyber security standard. In this paper, we propose an approach that uses formal analysis to achieve this. We formally define building blocks necessary to define the system formally in order to enable formal modeling of the system and carry out the analysis using the Alloy Analyzer. Our approach can be used at an early design stage, where problems are less expensive to correct, to ensure that the system has the desired security properties. We show the applicability of our approach by modeling two distinct cyber attacks and mitigations strategies used to defend against these attacks and also evaluate our approach based on its flexibility to handle and combine different aspects of the cyber security standards. We discuss the future directions of our research.


Introduction
In an industrial setting there is an increasing use of wireless technology because many components becomes Internet of Things (IoT) enabled. Rather than having to investing in a continuation of wired connections the balance between cost and agility many companies moves to such IoT solutions. However, this move towards wireless technologies gives new security challenges that must be taken serious in order to protect both the data and algorithms owned by the companies. In order to ensure this different security standards have emerged and here the IAS/IEC-62443 is a promising candidate that deserves special examination [1]. In order to master the increase of complexity caused by the increased wireless connections the architectures of the distributed systems needs thorough analysis. Here model checking is a promising candidate to provide such an analysis. This has an appropriate balance between the time and cost spent on the analysis and the exhaustiveness favorable. In this paper we demonstrate how this can be achieved defining possible attacks and the corresponding mitigations using a formal approach. The main result is an illustration of how this kind of framework can be deployed to illustrate how a specific architecture and its chosen mitigations can be proven that the different cyber-attacks cannot be realized. The remainder of this paper is structured as follows: Section 2 introduces the essential parts of the ISA/IEC-62443 standard and this is followed in Section 3 defining the architecture of considered system. The main result of this paper is presented in Section 4 defining extended formal framework for cyber-attacks and possible mitigations for these. Section 5 explains about how formal analysis can be conducted using the Alloy Analyzer [2]. This is followed by Section 6, which considers related work for formal analysis of cyber security standards. Finally, Section 7 provide concluding remarks also indicating the future directions planned for this work.

The chosen cyber security standard
Within this paper we consider security of an industrial control systems based on IoT environment. This is further considered in terms of applying cyber security standards that are used to ensure industrial automation and control system security, specifically the ISA/IEC-62443 series of standards. The series is split into 4 distinct groups where each group considers different perspective of cyber security of the industrial automation control system (IACS). Each of the groups contain documents, where each document is understood as a single standard. This leads to name designation of specific standards based on the format: ISA/IEC-62443-X-Y where X is the designation of the group and Y is the designation of the specific document. The first group, ISA/IEC-62443-1, General, considers the general aspects of the standard and cyber security. Concepts and metrics defined within this group are present throughout the other groups of the standard as shown in Fig. 1. The second group, ISA/IEC-62443-2, Policies and procedures, focuses on organizational aspects of cyber security. The main consideration of this group is providing the requirements that the organization has to fulfill in order to manage their cyber security program. The third group, ISA/IEC-62443-3, System, addresses the security on a system level. The security requirements for the system is defined here as well as guidance on implementation of these and fulfillment of these requirements. The final group, ISA/IEC-62443-4, Component, contains documents defining detailed requirements for cyber security on the component level.

The standard under consideration
The standard that we consider for formal verification is ISA/IEC-62443-3-3, System security requirements and security levels. This standard has been selected as it provides requirements that are applicable on system level and are verifiable by technical means. The intended audience for this standard are asset owners, system integrators and service suppliers and the purpose of this standard is to use the defined requirements to evaluate the system under consideration and determine if this system is capable of reaching a specific security level (SL). The standard defines 4 SLs:  SL 1: The lowest SL aimed to prevent unauthorized disclosure of information via eavesdropping or casual exposure.  SL 2: Aimed to prevent unauthorized disclosure of information to an entity actively searching for it using simple means with low resources, generic skills and low motivation.  SL 3: Aimed to prevent unauthorized disclosure of information to an entity actively searching for it using sophisticated means with moderate resources, IACS specific skills and moderate motivation.  SL 4: The highest SL aimed to prevent unauthorized disclosure of information to an entity actively searching for it using sophisticated means with extended resources, IACS specific skills and high motivation. Within the standard the security requirements on the system level are considered as system requirements (SRs) where each SR can define 0 to 3 requirement enhancements (REs). SL of the aspect of the system is measured as a compliance with SRs and REs for this aspect, shown in Table 1. In case that no SR is defined for the given aspect of the system, the standard implicitly defines SL 0 as an SL for this aspect of the system.

System architecture
The system under consideration extends a generic control systems architecture and capabilities defined in the framework for Threat-driven Cyber Security Verification of IoT Systems (FCSVIoT) [3]. This architecture consists of subsystems equipped with sensors and actuators shown on Fig. 2. Each subsystem is a microcontroller capable of computation and communication. Communication between the subsystems creates a distributed control system, which provides data to and accepts commands from a central engineering terminal. In this paper we extend the architecture with the notion of router, a special type of subsystem that enables data exchange among other subsystems and extends the capabilities of the system by defining user actions on the engineering terminal. We further consider that communication channels must exist between subsystems in order to exchange data.

Fig. 2. Architecture of the system under consideration
We let our subsystems be governed by a set of atomic actions forming a basic alphabet for each subsystem as = {generate, send, acquire, accept, discard, connect, disconnect, recover, compromise} and each subsystem has a finite set of states S. Actions cause transitions between states of the subsystem such as: ( ) → ′ ℎ , ′ ∈ S We further define a predicate on communication channels secure(c) stating that the communication channel is secured. The generate action represents generation of data by the subsystem, send action represents sending the data on a communication channel, acquire represents acquiring data from the communication channel, accept defines accepting the acquired data, discard defines discarding the acquired data. The connect and disconnect action represent a subsystem connecting to and disconnecting from a communication channel. The compromise action moves the subsystem to a compromised mode of operation, compromised( ), where we consider that the subsystem has malicious intent. Recover action moves the subsystem from compromised to normal mode of operation, normal( ). We extend the actions in the FCSVIoT by considering the engineering terminal as an user interaction part of the system by defining its own alphabet of actions ={allow, forbid}, where allow represents allowing and forbid represents disallowing interaction with an user by the engineering terminal. We also consider that the system holds a set of user accounts allowing users access to the Engineering terminal, Ac where a single account is denoted as a. Each account has exactly one credential cr, hence the system also holds a set of valid credentials Cr. We further define the router as with alphabet = \{generate} as the router is not equipped with sensors to generate its own data. This leads to creation of system alphabet = ∪ .

Attacks and mitigations
We define cyber attacks as sequences of events leading to potential harm to the system under attack. Within this paper we consider two cyber attacks, specifically data packet tampering and brute force attack against an user account [4]. These attacks have been purposefully selected as the selected cyber security standard addresses them and specifies requirements for mitigations aimed to increase cost of these attacks. We provide a formal description of the attack sequence and mitigation for both of the attacks under consideration.

Data packet tampering attack
Packet tampering is the act of a compromised subsystem, specifically a router changing values in a data packet, causing the intended receiving subsystem to receive different values from those sent by the transmitting subsystem. This has then the potential to cause unsafe behavior of the system. In order to describe an instance of this attack, consider two subsystems 0 and 1 operating in normal mode, which we show formally as normal( 0 ) ∧ normal( 1 ) and a router used to enable data exchange between the two subsystems. The router operates in a compromised mode compromised( ), meaning that some malicious actor has access to and control over this router. The subsystems 0 and 1 are always connected to the router, meaning that at any time they can exchange data with the router using communication channels c 0 and c 1 . We use the FCSVIoT predicate always_connected as always_connected( 0 , 0 , 0 ) ∧ always_connected( 1 , 0 , 1 ) specifying that there is always possibility of communication between 0 and 1 via 0 . Now we consider that 0 is sending a unit of data d to 1 . The data d is first obtained by 0 , which modifies the data d, represented by a new modify action added to the alphabet of the router in order to represent software installed by malicious actor, and then sends it further to 1 . The attack hence combines actions into a pattern by following a specific sequence: 1 .accept(d) Main act of the attack happens at the 0 .modify(d) event. Here the data d becomes malicious as malicious(d). In case of non-existent mitigations within the system, the subsystem 1 simply accepts the data and becomes itself compromised, hence the attack is successful. In order to mitigate this attack, we consider security requirements from the ISA/IEC-62443-3-3 security standard, covering the communication integrity, namely SR 3.1 stating that The control system shall provide the capability to protect the integrity of transmitted information. The requirement itself does not provide the necessary guidance on what method to use to protect the data, hence we consider the SR 3.1 RE 1 specifying the cryptographic integrity protection as The control system shall provide the capability to employ cryptographic mechanisms to recognize changes to information during communication. To mitigate the attack from a general perspective we consider that the data has to contain a cryptographic signature derived from the data content and a secret known to subsystems, but not routers. This introduces a concept of signed data, which we do by extending the alphabet of the subsystem by adding an atomic sign event as sign(d). We further define a predicate for signed data stating that the data is considered signed only if signed by a subsystem operating in a normal mode: We then consider applying the signing event as a mitigation by specifying that the subsystem discards the signed data if it has been modified, with indices added to the state notation, describing the order of state transitions:

Brute force attack against an user account
Brute force attack against an user account uses computational power to try to guess user sign in credentials by randomly generating passwords and user names and providing them to the system for verification. The attack can be streamlined if the user name and length of the password is known, decreasing the "guess space", which in turn leads to less time required to guess the correct credentials. If the user account can be breached this gives the malicious actor control over the system in terms that the breached account allows, potentially allowing the malicious actor submission of malicious commands to the system. To formally describe the attack we consider a single engineering terminal 0 operating in a normal mode, normal( 0 ). We further define a check function on an engineering terminal, responsible for raising the allow or forbid event: We formulate the attack as a recursive crack(cr) function that generates new cr for every attempt used to find a cr such that cr ∈ Cr: Once the function returns true the malicious actor has obtained access to the engineering terminal, causing the engineering terminal to operate in a compromised mode of operation, as compromised( 0 ) and the attack is considered successful. In order to mitigate the attack we consider the requirement SR 1.11 defined in ISA/IEC-62443-3-3, stating, The control system shall provide the capability to enforce a limit of a configurable number of consecutive invalid access attempts by any user (human, software process or device) during a configurable time period.
The control system shall provide the capability to deny access for a specified period of time or until unlocked by an administrator when this limit has been exceeded. To enforce this we define a locked predicate acting on specific account mapped via its valid credential where mapping between account ac and credential cr is one to one and hence for simplicity we omit cr and consider ac as belonging to a specific cr as: We then need to consider the amount of allowed invalid access attempts. In order to abstract away from details of password complexity, we present an assumption stating that the successful brute force attack against an system that allows reasonable small amount (in general we would consider this less than 10 for practical reasons) invalid access attempts is so unlikely that we consider it impossible. Using this assumption as a mitigation we can guarantee that the user account cannot be breached by brute force attack. We also abstract away from notion of time intervals as we consider that the brute force attack is happening rapidly and would always exceed the amount of tries within a specific time interval. We formally show this mitigation by first defining a global variable for ac holding the current attempt as attempt(ac) for its credential cr: We then use the variable in adding an attempt limit on using a credential to sign in to an user account such that the account becomes locked if the maximum amount of attempts is reached:

limited(cr, max_att)= locked(ac) if attempt ≥ max_att
By applying the limited predicate to the credentials we cause the account to become locked as a result of the crack function. Since a locked account cannot be used to gain access to the engineering terminal, the cyber attack fails and the engineering terminal continues in the normal mode of operation, normal( 0 ). It is important to note that in general the max_att has to be set in such a way that does not hinder usability of the system, while providing assurance of sufficient security. This mitigation strategy has therefore a limitation in case the max_att is set unreasonably large.

Formal analysis
In this section we shortly present the extensions made to the FCSVIoT and show how the mitigations for data packet tampering and brute force against user account attacks have been verified when considered within the architecture defined in Section 2. This is achieved by expressing the aforementioned attacks and mitigations using FCSVIoT with extensions introduced in this paper and verifying these scenarios using the Alloy Analyzer.

Short introduction to Alloy Analyzer
Alloy is a formal specification language, based on first order logic, used for expressing structural constraints in software systems. Alloy allows for modeling at different levels of abstraction, where at the highest level it provides object oriented interpretation, at second level it uses the set theory and at the lowest level atoms and relations are used. Within our model we are using the set theory, atoms and relations to model the types using the sig keyword. Subtyping is supported in Alloy by usage of extends keyword. We model relations between objects by specifying mappings between sets, for example has:set EngTerminal one->some Account, where has is the relation stating that the one, meaning exactly one engineering terminal has some, meaning at least one account associated with it. The scope of the model is specified after the run block, by quantifying how many atoms do we want to include in the model by using the exactly keyword. Properties of the Alloy model can be verified by usage of the Alloy Analyzer software tool [5], which checks properties of the model by generating counterexamples.

Overview of extensions to FCSVIoT
Among the first extensions is addition of new data types Router corresponding to the router, EngTerminal corresponding to the engineering terminal, Account corresponding to user account and Credential corresponding to credential for specific account as specified in Section 3. Using Alloy Analyzer, we define these datatypes using set definitions, represented by the sig keyword. We further extend the State definition with number of new relations. We further define the router as an extension of Device type and also adapt Subsystem to be extension of Device, as shown in Listing 1.
The Device type is used as a base type since Router and Subsystem share most of the actions. The only difference is that we consider that the router is not capable of generating data. The relations within State now also use Device in order to model relation that cover both Router and Subsystem. For example, the compromised relation shown in Listing 1 shows that a state can contain any number of compromised devices. Another relation recorded in each state is for example accepted which maps devices to data. The different types discussed above are governed by several facts, which are understood as constraints on the model. One of these is the consideration that the data is either signed or not and this does not change as the system progresses in its state transitions. This is shown in Listing 2. In this constraint s' is the state following the s state, hence the constraint guarantees that the data remains signed in all states.

Verification of data tampering mitigation strategy
Here we demonstrate the mitigation strategy applied to a scenario discussed in 4.1.
The simplest model to demonstrate data tampering mitigation strategy in fact only requires one subsystem and a router as it is the router that is responsible for the attack. This is shown in Listing 3. The listing shows the constraint for mitigation and the setup of the model. The complete extended FCSVIoT can be found via [6].

Listing 3. Verifying the data tampering mitigation strategy using Alloy
The run commands checks that the data is signed in five states, required to exectute the whole scenario. The result of this execution is: No instance found. This means that the Alloy Analyzer could not find a counter-example within the requested scope and the mitigation strategy is proven to work.

Verification of brute force attack:
We will show how the mitigation strategy for brute force attack can be modeled by considering a scenario described in Section 4.2. The run command for the model we use consists of one engineering terminal with one user account, with its associated credentials and omits subsystems as shown in Listing 4. The mitigation used in this scenario states that all accounts within all states of the system are always considered limited (i.e. they consider limit on the number of unsuccessful login attempts). This scenario considers three states, creating the smallest scope necessary for its execution. Once the run command is executed the Alloy Analyzer returns No instance found, confirming that the mitigation strategy prevents the user account from being cracked.

Related work
As cyber security is becoming very important topic in the industry, mainly in advent of digitalization and trends such as industry 4.0 [7], research is being carried out within the area of using formal methods in order to provide proofs that systems meet cyber security requirements [8][9] [10]. The benefits of using model based verification are its applicability at an early stage of system development in order to help avoid exposure to attacks as well as provide mitigations for attacks that are not easily avoidable [11] [12]. This approach consists of formal description of the behavior of a system and formal description of cyber-attacks and mitigations. The complete model is then formally analyzed in order to verify that the mitigation strategies prevent the cyber-attacks from causing potentially harmful behavior of the system. Sometimes specific cyber security standards are considered as criteria for these mitigations strategies [13].
In order to provide assurance that an industrial control system meets criteria specified in a cyber security standard, authors of [14] have investigated the ISA-99.01-01 standard by considering the requirements and metrics specified within the standard. While the authors have described part of the standard formally, their goal was not to conduct formal analysis to ensure the satisfiability of the security requirements by a given architecture but rather to provide recommendations to the operators of industrial control systems to not blindly trust standards but verify their security impact on the system. The authors of [15] have proposed a formalization and verification technique for ISO/IEC-15408 standard known as Common Criteria using Z notation. In their technique they consider the natural language definitions within the standard and create formal templates based on these. The authors suggest usage of the templates against the formalized specification of the target system, which is left to the party verifying the system against the instantiated templates. The authors provide an example of this verification using the Z/EVES theorem prover. Our approach differs by providing formal building blocks for the system from the start, hence formalization of the system can be done by selecting from these building blocks.