Umberto Morelli
email: umorelli@fbk.eu

Silvio Ranise
email: ranise@fbk.eu

Assisted Authoring, Analysis and Enforcement of Access Control Policies in the Cloud

Keywords: Policy Translation and Validation, Attribute-based Access Control, Amazon AWS, OpenStack

The heterogeneity of cloud computing platforms hinders the proper exploitation of cloud technologies since it prevents interoperability, promotes vendor lock-in and makes it very difficult to exploit the well-engineered security mechanisms made available by cloud providers. In this paper, we introduce a technique to help developers to specify and enforce access control policies in cloud applications. The main idea is twofold. First, use a high-level specification language with a formal semantics that allows to answer access requests abstracting from an access control mechanism available in a particular cloud platform. Second, exploit an automated translation mechanism to compute (equivalent) policies that can be enforced in two of the most widely used cloud platforms: AWS and Openstack. We illustrate the technique on a running example and report our experience with a prototype implementation.

Introduction

Cloud computing platforms offer companies the opportunity to create applications that have global reach and can scale rapidly to meet sudden spikes in demand without requiring massive investments by adopting a pay-as-you-go approach. The cost of this extra flexibility is a loss of control over the software components deployed in the cloud and the data manipulated by applications, since part of the responsibility and control is transferred from Cloud Customers (CCs) to Cloud Providers (CPs); consider, e.g., the "Amazon Web Service Shared Responsibility Model" 1 . When using a cloud platform, it is crucial for CCs to understand and distinguish between security measures implemented and operated by CPs (called, security of the cloud) and those offered by them (called, security in the cloud), for which the CPs are accountable. Failure to understand the boundaries of this separation of concerns and responsibilities may lead to leave sensitive assets unprotected with the potential of disclosing sensitive information, thereby incurring in extra costs and potential loss of business, and eliminating many of the benefits of cloud computing. Even if the separation of responsibilities is clear, CCs may find it difficult to use effectively the large array of security mechanisms provided by the specific CP. This hinders one the most important opportunities offered by CPs to CCs, namely the exploitation of the cornucopia of well-engineered security mechanisms made available by CPs.

In order to alleviate this situation, we propose a technique capable of assisting CCs in designing and deploying access control systems in two of the most widely popular cloud platforms: AWS2 and OpenStack3 . Access Control (AC) is one of the most important security mechanisms for the protection of data and services against unauthorized disclosure (confidentiality) and intentional or accidental unauthorized changes (integrity), while ensuring their accessibility by authorized users whenever needed (availability). The development of an AC system requires the definition of the regulations according to which access is to be controlled and their implementation as functions executable by a computer system. This development process is usually carried out with a multi-phase approach based on the concepts of policy, model, and enforcement mechanism [START_REF] Capitani | Access control policies and languages[END_REF]. A policy defines the (high-level) rules according to which access control must be regulated. A model provides a formal representation of the AC policy and its working. The formalization allows the proof of properties on the security provided by the AC system being designed. An enforcement mechanism defines the low level functions that implement the controls imposed by the policy and formally stated in the model. In a cloud computing platform, several enforcement mechanisms are available, ranging from access control lists to those based on roles [START_REF] Capitani | Access control policies and languages[END_REF]. Many of these enforcement mechanisms are of a low level nature or are variant of the standards as they are tightly coupled with the resources and operations that services made available by the CP support. For application developers, it is not easy to grasp how all the different enforcement mechanisms work and how they can be used to mediate access to the data and services that the application under development is using. In many cases, even security experts may have difficulties in expressing high-level AC constraints related to an application (e.g., Separation of Duties) by means of the enforcement mechanisms available by CPs.

The main contribution of the paper is a technique that allows application developers and security experts to design the application and the AC policies by using an abstract model of a cloud platform without committing to a particular cloud solution. Since the language in which the AC policies are written has a formal semantics, it is possible to re-use automated tools for the security analysis of policies to understand whether the written policies correspond to the designer expectations. When this is the case, the tool automatically translates the highlevel AC rule into concrete policies that can be enforced by the mechanisms available in AWS and Openstack. Plan of the paper. Sec. 2 introduces a scenario that illustrates the main problems underlying the development of secure applications in the cloud. Sec. 3 describes our high-level policy specification language and its formal semantics by using a logical framework. Sec. 4 explains how the policies written in the high-level language can be translated to the policies that can be enforced by the AC mechanisms available in AWS and Openstack. Sec. 5 shows how a prototype implementation of our techniques (called SecurePG) solves the problems arising in the running example of Sec. 2. Sec. 5.2 presents some concluding remarks and a short comparison with related work.

A Running Example

The ACME shipping company wants to develop a cloud application to support a customer loyalty program (SpecialDiscounts). The idea is to reward e-payments made via a mobile application (PromoApp) with virtual credits that can be spent for additional ACME services or discounts on selected products offered by ACME Partners. To this end, ACME wants to grant the partners of the loyalty program access to a restricted set of information through the application, while maintaining control over customers' data; thereby configuring two different domains in the data storage services available in the cloud.

Figure 1 shows the ACME and the cloud domains, together with three groups of users: ACME Customers, ACME Employees and ACME Partners. ACME Employees, using a system in the ACME domain, can list customers profiles (label L), extract the information they contain (label G), add new profiles (label P) or delete existing ones (label D); those operations are represented by the labelled solid arrow from ACME Employees to the ellipse named 'Full ACME Customer Profiles'. ACME Customers, by using PromoApp, can get, add or delete the information stored in the partial customer profiles (labels G, P and D linked to the arrow connecting ACME Customers to the ellipse named 'Partial ACME Customer Profiles'). The same operations are performed on their full profiles by using a system in the ACME domain. ACME Partners, using the SpecialDiscounts application, can list the partial ACME customer profiles (label L on the arrow connecting ACME Partners to the ellipse named 'Partial ACME customer profiles') and can get or add information to the profile (labels G and P linked to the arrow connecting ACME Partners to the ellipse named 'Partial ACME Customer Profiles'). Since the full and partial ACME customer profiles can be updated independently (by using the cloud application or the system in the ACME domain), it should be possible to synchronize the information stored in both profiles (double arrow named 'Synch') so as to keep them up-to-date. The goal is to deploy the two applications, SpecialDiscounts and PromoApp, on a cloud computing platform while guaranteeing that the members of the various groups can perform only the actions discussed above. It may be also important to consider public or private cloud solutions, depending on the fact that sensitive information in the customer profiles must be stored also in the partial profiles managed by the cloud applications. For instance, it must be possible to deploy the applications on a public cloud-such as an Amazon AWS Platform-as-a-Service (PaaS) implementation, using the Simple Storage S3 service to manage customer profiles-or on a private cloud-such as an OpenStack Infrastructure-as-a-Service (IaaS) installation within ACME, that uses Swift as the data container. The main requirement is to do all this by supporting a cloud provider-agnostic specification of the access control policies that permit the automated verification of basic security properties (e.g., a member of a certain group can/cannot perform a certain action on a given resource) and their automatic instantiation to the access control mechanisms available in a particular cloud solution. In this way, it is possible to manage the heterogeneity of the multitude of IaaS and PaaS solutions currently available by increasing interoperability and avoiding vendor lock-in while exploiting to the full the well-engineered security mechanisms available in different cloud solutions. While there exist approaches in the literature that allow to manage cloud applications across different platforms (see, e.g., [START_REF] Ferry | Cloudmf: applying mde to tame the complexity of managing multi-cloud applications[END_REF]), none of these address security issues (and in particular access control policies) as we do in this paper. For this reason, in the following, we discuss only the issues related to access control while we point the interested reader to, e.g., [START_REF] Ferry | Cloudmf: applying mde to tame the complexity of managing multi-cloud applications[END_REF] for an approach abstracting away from the functionalities and storage capabilities of a particular cloud provider.

An Abstract Access Control Model for the Cloud

Since Attribute-Based Access Control (ABAC) [START_REF] Hu | Guide to attribute based access control (abac) definition and considerations[END_REF] offers a powerful and unifying extension to several access control models in the literature (see [START_REF] Jin | A unified attribute-based access control model covering dac, mac and rbac[END_REF] for a thorough discussion about the expressive power of ABAC with respect to other models), we have chosen it as the framework in which to develop our policy language and access control model for cloud applications. In ABAC, requesters are permitted or denied access to a resource based on the properties, called attributes, that may be associated to subjects, resources, and contextual information. Suitably defined attributes can represent identities, access control lists, or roles; in this sense, ABAC supplements rather than supplant traditional access control models [START_REF] Jin | A unified attribute-based access control model covering dac, mac and rbac[END_REF]. Abstractly, policies in ABAC are conditions on the attribute values of the entities involved in an access decision. Our policy language for the cloud is based on the following construct: where the parts in black are mandatory and those in gray are optional. Intuitively, the meaning is to grant or deny to a subject (described by an identifier plus, optionally, some simple conditions on its attributes) the permission to perform some action on a resource (also described by an identifier plus some simple conditions on its attributes) provided that all the complex authorization conditions on the attributes of subjects, resources, or the context are satisfied (the meaning of simple and complex conditions will be made precise below).

A subject, a resource, or an action are identified by a unique name. The attributes of a subject, a resource, or the context are also identified by a unique name and each one is associated to a type, such as the Booleans, the Integers, or an enumerated data type. Formally, a subject, a resource, or the context can be seen as records whose (typed) fields are the attributes; a type defines a set of values plus some functions and predicates (including at least the equality = operator) that can be applied to the values. A simple condition on a subject or on a resource can be expressed as a list (intended conjunctively) of equalities of the form att = val where att is an attribute and val is one of its possible values. A complex condition is a Boolean combination of atomic expressions containing attributes of subjects, resources, or the context together with values and operators of the appropriate type (notice that we forbid quantifiers in complex conditions; this restriction in expressiveness was never a hindrance to specify policies in our experience). An example of a policy specification relevant to the example of Section 2 is provided below: that grants the ACME user identified by the ID ACME user 1 the permission to access his profile (ACME user 1 profile), e.g. to check the number of virtual credits, provided that this is done in a given period of (Unix) time, namely from the first to the third of January 2016. Following [START_REF] Armando | Smt-based enforcement and analysis of nato content-based protection and release policies[END_REF], it is possible to formalize the meaning of the policy constructs in Listing 1.1 by using first-order logic formulas. For this, we preliminary introduce the notion of query as a tuple (sl , a, rl , cl ) where a is an action and sl , rl , cl are simple conditions involving the attributes and values of a subject, a resource, and the context, respectively. We write sl , rl , cl to denote the conjunction of equalities in the simple conditions sl , rl , and cl , respectively. A complex authorization condition in a policy construct can be considered as a first-order formula in which quantifiers does not occur. We assume the availability of the attributes sid and rid of subjects and resources, respectively, that range over their sets of identifiers.

Given a finite set Π of policy constructs of the form 1.1 and a theory T formalizing the types of the attributes in P (it is well-known how to do this, we point the interested reader to [START_REF] Armando | Smt-based enforcement and analysis of nato content-based protection and release policies[END_REF] for details), we say that a query (sl , a, rl , cl ) is granted (with respect to Π) iff there exists a policy construct in Π such that the formula sid = s'∧ sA' ∧rid = r'∧ rA' ∧C' in conjunction with sl ∧ rl ∧ cl is satisfiable in T . Otherwise, we say that the query is denied.

The decidability and NP-completeness of the satisfiability checks with respect to the theory T follow from results in [START_REF] Armando | Smt-based enforcement and analysis of nato content-based protection and release policies[END_REF] when the types of the attributes are Booleans, Integers or enumerated data types. We do not elaborate the details here for lack of space; we just observe that complex conditions with arbitrary Boolean structure makes the problem already NP-hard because the Boolean satisfiability problem is subsumed. Indeed, NP-completeness of the induced satisfiability problems implies that also answering queries is NP-complete. This should not be seen as a hindrance to the usability of our approach. SMT engines solving the generated satisfiability problems guarantees the practical viability of the technique at policy design-time with queries solved in few seconds. One reason for the good practical performances is the relative simplicity of the Boolean structure of complex conditions.

From Abstract to Enforceable Policies in the Cloud

Cloud providers are not able to fully support the complexity of the ABAC model and the granularity required for handling an arbitrary list of attributes: the ability to scale while maintaining data integrity and authorizations evaluation performance allows for simple AC policies based only on the identity of subjects (that request a cloud resource). Those uses a basic set of user attributes, i.e. his name, role or the group he belongs and, if supported, further restrict requester permissions with a set of environment conditions.

Using the model introduced in Section 3 it is possible to extend the identitycentric approach using generic conditions and providing attributes for the subjects and the resources. Table 1 shows the authorization patterns to explicitly suggest our prototype implementation the entity types (using their identifier and the type attribute) and the cloud attributes that uniquely identify them in Amazon and OpenStack: a subject identifier (ID), the URL or the Amazon Resource Name (ARN) code for the former and the ID or email of the subject for the latter. The current version supports three types of subjects (users, groups, roles) and two types of resources (objects and folders). Other components refer to the ability to authorize a service (handled as a role), support the identity federation features or create special policies (type keys or trust). If the end-user provides only the entity name, its type is retrieved querying a database; if the type is not supported (missing cases in the table) the information is instead ignored. Similarly, the attributes of subjects and resources, together with the environment conditions, are identified (using their name) and processed only if supported by the specific CP. This process, although not expanding the AC model of the supported CPs, greatly simplifies the task of writing AC policies. Moreover it allows the tool to create valid AC rules and easily supports the pure RBAC model of OpenStack and the RBAC-oriented implementation of AWS, with the possibility of future developments when more complex AC models will be made available by CPs. The picture shows that both solutions present an administrative boundary, called domain in OpenStack and root account in AWS, that contains all the supported entities: Users, Groups, Roles and, exclusively for OpenStack, projects and tokens. Users may belong to a group (User-Group assignment) or be linked to a role (User-Role assignment), that AWS considers as a separate complex entity (with its own set of permissions) while OpenStack as a mandatory simple Fig. 2. Amazon AWS and OpenStack AC models. Adapted from [START_REF] Zhang | Hierarchical secure information and resource sharing in openstack community cloud[END_REF][START_REF] Zhang | Community-based secure information and resource sharing in aws public cloud[END_REF] property of U. OpenStack requires the user to interact with a set of resources with specific roles (User-Project assignment) and providing a valid authentication token; the same process allows the interaction for all the entities that belongs to a group (Group-Project assignment).

Policy Support in Amazon and OpenStack

Our AC solution for the cloud supports six categories of authorization policies: assigned to the subject (User Policy or UP), to a users group or a role (respectively Group Policy or GP and Role Policy or RoP) and to the resources on which the subjects perform their actions (Resource Policy or ReP). The GP and RoP policies can also be specialized to apply only to a single user belonging to the specified group or role; in the following, these will be called special GP (sGP) and special RoP (sRoP). Two other types of permissions refer to the ability to offer the identity federation feature, which requires a trust relationship between users (Trust Policy or TP), and the possibility to assign permissions together with login credentials (Credential Policy or CredP). Those are supported only in Amazon and, when generating the OpenStack AC rules, are handled as UPs.

Table 2 provides an outline of our policy types and their support in the two CPs, including the required attributes or the services that enforce them. Amazon implement almost all types of authorization through the Identity and Access Management (IAM) service, while the Security Token Service (STS) is used for handling the CredP and three other services allow the user to specify ReP directly associated with the resource involved: S3 and the notification and queue services (respectively Simple NS and Simple QS). OpenStack instead manages permissions only through Keystone, using a set of rules related to the action performed (API actions) or the OpenStack service involved (such as identity, network or compute). The concept of TP and CredP is not supported in Open-Stack and the only way to implement ReP, in the case of Swift, is to provide an Access Control List (ACL) or generate a URL that allows the owner temporary access; unlike the ACL, the latter can distinguish between a folder and an object. The special GP and RoP are supported in both cloud platforms using the ID associated to an user.

SecurePG

To implement our AC model for the cloud according to Section 3, we developed a prototype implementation called SecurePG (also referred to as the tool ) that integrates a graphical user interface and a policy engine, both written in Java, and is supported by a MySQL database. The policy engine is responsible to analyse the authorization sentences using version 4.5.3 of the framework ANother Tool for Language Recognition (ANTLR) and identify, with the support of a general purpose grammar, the tuple < Policy Decision, Subjects, Actions, Resources, Conditions > according to our abstract policy language; it also investigates the absence of ambiguities such as the use of the same subject, resource or action in the positive and negative form or errors as the usage of a wrong operator or values when specifying the actions or the conditions names. The MySQL component contains a database schema that replicate the CPs data model and link cloud compliant names with the ones used for the authorization formulas, i.e. the subject name with its Amazon identifiers. By design, this component will interactively ask the user whether to continue if no value or more than one value are retrieved from the database tables. In the first case it also gives the possibility to generate a random value. Figure 3 provides the architecture of the tool in the default use-case scenario. Using the subjects, actions and resources (referred as the triple < S, A, R >) supported by the tool and agreed with the SA, the application developers can easily deploy cloud resource and features on the CP that best meets the requirements. To demonstrate the use of the tool on the reference scenario, we analyse the processing of two authorizations: the sRoP obtained by replacing the subject pattern 3, and the CredP listed below. The latter allows the subject identified by the ID ACME user 1 to assume the role with ID ACME Customers to access his profile and is structured in compliance with the Amazon AC model: one role policy (referred as the Role-component in Listing 1.3) assigned to the role ACME Customers and one policy (referred as the Credential-component in Listing 1.3) provided to the ACME user 1 subject when authenticating. This policy, uniquely associated to the user's credentials, cannot define new permissions or extend pre-existing authorizations; i.e. the sRoP associated to ACME Customers.

Policy Generator Engine

Processing the sRoP and the CredP authorizations, SecurePG is able to determine the correct policy types and suggest the creation of all the necessary entities. For the sRoP, the tool may suggest the creation of one AWS root account, one IAM user and one IAM role (both belonging to the same root account); regarding OpenStack, it recommends the use of a domain and the KeyStone user ACME employee 1 (created providing the KeyStone role ACME employees). In both cases SecurePG reports the skipping of the components not supported/recognized within the specific CP. Although some information may be stored, for example as metadata if the interaction refers to a Swift or S3 Resource, it can not be indicated as part of the AC rule. When specifying a Swift Resource, as in the CredP, the user can choose between two solutions: a generated URL that allows the owner temporary access to the Resource or a Swift ACL for the Keystone user that is assigned with a role on a project associated to the resource. In the example, the user id 111 of ACME user 1 must be linked with the role id 222 of ACME customers and the project id 333 of P ACME user 1. To implement the first solution, the system requires (or randomly generate) a duration, the resource path and a cluster key sig (that acts as a signature), according to the following URL template: https ://{ host }/{ path }? temp_url_sig ={ sig }& t e m p _ u r l _ e x p i r e s ={ expires } Regarding the Swift ACL instead, the SA needs to manually create a User-Project assignment using the Keystone interface (in the example, the triple <111, 222, 333>). Since OpenStack does not support the CredP type, SecurePG will ignore the resource attribute keys and create a user policy; lacking the support of negative ACLs either, the tool will be able to generate only an authorization associated to the permit component. OpenStack policy "identity:add user to group": "role:ACME employees and 'ACME customers':%(target.group.name)s and user id:123"

Abstract Policy Analysis Engine

To allow the validation of the AC policies before the enforcement, we integrated the support of the Java Content-Based Protection and Release Language tool (JCPRL) [START_REF] Armando | Smt-based enforcement and analysis of nato content-based protection and release policies[END_REF] to analyse the AC rules provided by the SA. This required a bridge component to translate from the language in Section 3 to first-order logic formulas taken in input by the JCPRL tool. A CPRL document is then created Figure 4 shows the output after the authorization query with the GUI (frame list on the left), while Figure 5 presents the AWS output from the official Amazon web interface when manually adding the rule and the OpenStack output that will be saved in the Keystone policy.json file. The former prevents the Amazon java SDK from showing the error message message: "User: arn:aws:iam::4146402582-23:user/ACME employee 1 is not authorized to perform: iam:AddUserToGroup on resource: group ACME customers ..Error Code: AccessDenied.". sectionDiscussion We have presented a technique supporting the authoring of high-level AC policies for cloud applications, the capability of answering queries independently of a particular cloud platform, and the automated translation of the high-level authorizations to policies that can be enforced in two of the most widely adopted cloud platforms, namely AWS and Openstack. We have also reported our expe-rience with a prototype tool, called SecurePG, of the technique on a typical cloud application scenario.

The development of a language able to represent, share and facilitate the evaluation of different types of AC policies has received a lot of attention. The eXtensible Access Control Markup Language (XACML) [START_REF] Committee | eXtensible Access Control Markup Language (XACML) Version 3.0. Oasis standard[END_REF] is the de facto standard. As discussed in [START_REF] Stepien | A non-technical user-oriented display notation for xacml conditions[END_REF], the precision with which this standard works is both a weakness and a strength. The solution proposed in [START_REF] Stepien | A non-technical user-oriented display notation for xacml conditions[END_REF] to overcome the difficulties of writing XACML is a graphical tool to display and edit the rules. Our approach is to avoid the difficulties of using XACML by employing a simple and abstract (but expressive) specification language to enforce user requirements in the cloud and easily exploit the JCPRL tool proposed in [START_REF] Armando | Smt-based enforcement and analysis of nato content-based protection and release policies[END_REF]. This allows to validate the AC policies before their deployment on a particular cloud platform by using a logical semantics and automated reasoning tools to mechanize the authorization query answering process. Similarly to [START_REF] Stepien | A non-technical user-oriented display notation for xacml conditions[END_REF], our prototype tool employs a graphical user interface to guide the generation and definition of the AC requirements hiding the complexities of the particular AC model and enforcement mechanism adopted by the cloud platform.

The abstract language we propose is similar to a structured natural language albeit simplified by using syntactic constructs to express ABAC authorization conditions in a way similar to Java Boolean conditions. A lot of work on the use of structured natural language has been done to express AC policies. For instance, the work in [START_REF] Perry | Modular natural language interfaces to logic-based policy frameworks[END_REF] analyzed the possibility to express user requirements using a domain dependent grammar and a restricted vocabulary of English sentences. We believe that this constitutes an interesting line of future work that can be integrated in our approach to make our abstract language even more intuitive, expressive, and friendly. Another interesting extension is to integrate a component that allows to import XACML policies in SecurePG, and therefore to compare our tool with other policy generators; following the ABAC policy mining process presented in [START_REF] Xu | Mining attribute-based access control policies from rbac policies[END_REF], we tested (although not integrated in SecurePG) a component that processes the Amazon RBAC policies to generate expressions compliant with our abstract policy language. This allows to load pre-existing AWS policies (in the native JSON format) and generate, when supported by the OpenStack AC model, equivalent OpenStack authorization rules.

To the best of our knowledge, our technique is the first that is capable of generating enforceable policies in AWS and Openstack from a high-level description of the AC requirements. Our research is now trying to expand the support of our prototype tool to other cloud platforms; such as Microsoft Azure or Google Cloud in order to gain further experience with the automatic translation of highlevel policies. We also intend to enrich the abstract policy languages with more constructs to express, for instance, the purpose of access-a feature which is becoming of paramount importance to ensure the privacy of the processing. This will also require the automatic synthesis of monitors to guarantee the satisfaction of purpose constraints. To this end, we envisage to integrate the approaches in, e.g., [START_REF] De Masellis | A declarative framework for specifying and enforcing purpose-aware policies[END_REF][START_REF] Bertolissi | Automated synthesis of run-time monitors to enforce authorization policies in business processes[END_REF].

Fig. 1 .

 1 Fig. 1. Simplified architecture of the SpecialDiscounts and PromoApp cloud apps

Listing 1 . 1 .

 11 Abstract policy specification constructGrant | Deny SUBJECTS [ATTRIBUTES] the permission to ACTIONS on RESOURCES[ATTRIBUTES] if CONDITIONS;

  Grant s [ sA ] the permission to a on r[ rA ] if C in Π such that the formula sid = s ∧ sA ∧ rid = r ∧ rA ∧ C in conjunction with sl ∧ rl ∧ cl is satisfiable in T (i.e. there exists a first-order structure which is a model of T and satisfies both formulae) and there is no policy construct Deny s ' [ sA '] the permission to a on r ' [ rA '] if C '

Fig. 3 .

 3 Fig. 3. SecurePG architecture

Listing 1 . 3 .

 13 Example of an abstract rule that translates to a CredP Role -component : Grant ACME_user_1 [ role = ACM E_custom ers ] the permission to get object and put object on ACME / User_profiles /* [ type = keys ]; Credential -component : Deny ACME_user_1 [ role = A CME_cus tomers ] the permission to get object and put object on not A C M E _ u s e r _ 1 _ p r o f i l e [ type = keys ];

Fig. 4 .Fig. 5 .

 45 Fig. 4. SecurePG query output using JCPRL

  Listing 1.2. Example of an abstract rule that translates to a role policy

Grant AC ME_emplo yees the permission to add user to group and remove user from group on ACM E_custom ers

This grants the ACME employees (identified by the role ID ACME employees) the right to add and remove users from the group of ACME customers (ACME customers). As another example, consider the following user policy:

Grant ACME_user_1 the permission to get object on A C M E _ u s e r _ 1 _ p r o f i l e if access time greater than 1451606400 and if access time less than 1451779200

Table 1 .

 1 Authorization patterns and cloud attributes that identify the entity types Reconstruction of the Amazon and OpenStack AC Model Figure2links the elements associated to the subjects in Amazon and OpenStack AC models, highlighting with dashes those that belong only to OpenStack and with the crosses those of AWS; solid lines represent instead common components and are among the ones supported by our prototype implementation.

	Authorization patterns	AWS	OpenStack
		UserID [type = user subject] ID and ARN ID and email
	Subject component	GroupID [type= group] RoleID [type = role] ServiceID [type = service]	ARN ID and ARN ID and email ID URL missing
		FederatedID [type = federated] URL or ARN missing
		ObjectID[type = object]	ARN	ID
	Resource	FolderID[type = folder]	ARN	ID
	component	ResourceID[type = keys]	ARN	missing
		ResourceID[type = trust]	ARN	missing
	4.1

Table 2 .

 2 Policy types supported in our model, Amazon AWS and OpenStack

	Policy types	Amazon AWS implementation	OpenStack implementation
	UP	IAM UP	API-Service:API UP
	GP	IAM GP	API-Service:API GP
	sGP	Restricted GP (AWS username or user ID)	Restricted GP (OpenStack user id)
	RoP	IAM RoP	API-Service:API RoP
	sRoP	Restricted RoP (AWS username or user ID)	Restricted RoP (OpenStack user id)
	ReP	AWS ReP for the S3, SNS and SQS services	Swift ACL or temporary URLs
	TP	IAM TP	missing
	CredP	STS-AWS CredP	missing

Table 3 .

 3 Example of a sRoP processing

	Auth. components	AWS policy
		[{"Role Policy": {
	Policy decision:	"ACME employee": {
	< Grant >	"Version": "2012-10-17",
	Subjects:	"Statement": {
	< ACME employee 1 >	"Sid": "1",
	Actions:	"Effect": "Allow",
	< add user	"Action": [ "iam:AddUserToGroup,
	to group, true>	iam:RemoveUserFromGroup"],
	< remove user	"Resource":
	from group, true>	["arn:aws:iam::xx:group/ACME customers"]
	Resources:	"Condition": {
	< ACME customers,	"StringEqualsIgnoreCase": {
	true>	"aws:userid": "AIDAIYHF5BVYLMF36IKZY 4 " }
		}}}}}]

https://aws.amazon.com/compliance/shared-responsibility-model

https://aws.amazon.com

https://www.openstack.org

Value retrieved from the database using the subject name ACME employee 1


David Myers
email: d2.myers@qut.edu.au

Kenneth Radke

Suriadi Suriadi

Ernest Foo

Process Discovery for Industrial Control System Cyber Attack Detection

Keywords: Industrial Control Systems, Process Mining, Anomaly Detection

Industrial Control Systems (ICSs) are moving from dedicated communications to Ethernet-based interconnected networks, placing them at risk of cyber attack. ICS networks are typically monitored by an Intrusion Detection System (IDS), however traditional IDSs do not detect attacks which disrupt the control flow of an ICS. ICSs are unique in the repetition and restricted number of tasks that are undertaken. Thus there is the opportunity to use Process Mining, a series of techniques focused on discovering, monitoring and improving business processes, to detect ICS control flow anomalies. In this paper we investigate the suitability of various process mining discovery algorithms for the task of detecting cyber attacks on ICSs by examining logs from control devices. Firstly, we identify the requirements of this unique environment, and then evaluate the appropriateness of several commonly used process discovery algorithms to satisfy these requirements. Secondly, the comparison was performed and validated using ICS logs derived from a case study, containing successful attacks on industrial control systems. Our research shows that the Inductive Miner process discovery method, without the use of noise filtering, is the most suitable for discovering a process model that is effective in detecting cyber-attacks on industrial control systems, both in time spent and accuracy.

Introduction

There have been several cyber-attacks on ICS devices and infrastructure. One notable recent example is the December 23, 2015 attack on three Ukrainian power companies, causing power disruption to 225,000 customers [START_REF]01) cyber-attack against ukrainian critical infrastructure[END_REF]. Such attacks highlight the risk of interconnecting ICS with corporate networks, most notably in terms of the inadequacy of existing IDSs for control system purposes. Corporate networks typically use Intrusion Detection Systems (IDS) to monitor for known cyber-attacks. IDSs come in two types, signature-based IDS (which compare network traffic to signatures of known cyber-attacks), and statistical anomaly based IDS, (which examines network traffic over time for unusual behaviour). However, these IDSs do not detect attacks which exploit or disrupt the control flow of an ICS [START_REF] Hadžiosmanović | A log mining approach for process monitoring in SCADA[END_REF], thus, such IDSs may not be sufficient as the goal of exploiting an ICS network is the disruption of ICS system (which is achievable through disruption of the control flow of the systems), rather than exfiltration or infiltration of data as per a typical corporate network attack.

An ICS control flow refers to a process, i.e. sequence of events, conducted by an ICS device. These ICS processes are sometimes multiple sequential processes operating concurrently. ICS typically executes a series of steps for a given task, that modify the behaviour of physical devices. Tasks may include creating various fuels in an oil refinery, manufacturing circuit boards, or large scale food manufacturing. The order of events in an ICS process is imperative to the task being conducted, and the deviation from this sequence of events, or control flow, can disrupt the current industrial process. Using the oil refinery example, there may be a sequence of events used to burn off excess gases, such as "turn on flame" → "release gas" → "turn off flame". Changing the order of events to "turn on flame" → "turn off flame" → "release gas" could result in the gas being continually released, potentially damaging equipment. These events may all be valid ICS events, however when the events are conducted in the incorrect sequence there is potential to disrupt the industrial process being conducted.

As per the example above, in order to detect anomalies in ICS system, there is first a need to have knowledge and a model of the expected behaviour of the ICS process. ICS systems are often modelled using state or control flow diagrams, where the actual execution semantics of ICS devices are not captured. This is where techniques from the process mining domain can be of use. Process mining consists of a series of techniques used to "discover, monitor, and improve real processes by extracting knowledge from event logs", and is comprised of process discovery, conformance checking, and process enhancement techniques [START_REF] Van Der Aalst | Process mining manifesto[END_REF].

Process discovery is the method of deriving a process model describing the control flow of a system from an event log. Using this technique there is the potential to generate process models of an ICS system showing the expected behaviour, by learning from device logs generated by ICS devices such as PLCs. Conformance checking is another technique used to compare a process model or some known business rules to an event log, in order to determine how the events in the log align with the expected behaviours as captured in a process model. In the context of ICS security, we can use conformance checking to identify deviant behaviour that does not match the expected behaviour identified in a generated process model. Thus, by using process discovery and conformance checking, we have a set of tools which can be used to identify deviations, or disruptions in an ICS control flow. In contrast, traditional IDSs which use signatures, or monitor a network for statistical anomalies, do not focus on the overall control flow of a process.

There are numerous process discovery algorithms, each of which have advantages and disadvantages. Several studies have been conducted, comparing these process discovery algorithms [START_REF] Weerdt | A multi-dimensional quality assessment of state-of-the-art process discovery algorithms using real-life event logs[END_REF][START_REF] Leemans | Discovery of frequent episodes in event logs[END_REF]. However, these comparisons have been con-ducted in the context of business processes. ICS is a unique environment, and as such there is a need to have an understanding of which process discovery algorithms are the most suitable for this environment.

Thus, the contributions of this paper are as follows: Firstly, we identify the ICS characteristics and ICS modeling requirements. Secondly, we evaluate process models generated using several widely used process discovery algorithms, namely the α-algorithm [START_REF] Van Der Aalst | Workflow mining: Discovering process models from event logs[END_REF], the Fuzzy Miner [START_REF] Günther | Fuzzy mining-adaptive process simplification based on multi-perspective metrics[END_REF], the ILP Miner [START_REF] Van Der Werf | Process discovery using integer linear programming[END_REF], the Flexible Heuristics Miner (FHM) [START_REF] Weijters | Flexible heuristics miner (FHM)[END_REF], and the Inductive Miner [START_REF] Leemans | Discovering block-structured process models from event logs containing infrequent behaviour[END_REF] algorithms, on our ICS process modeling requirements for process discovery. Finally, we validate the evaluation of process models with ICS modeling requirements through process mining's conformance checking activity. This conformance checking activity was conducted using ICS device logs from industry-standard ICS devices, four Siemens S7-1200s, which contain cyber-attacks from an 8-hour attacking vs defending exercise. These process discovery and conformance checking activities show that process discovery algorithms can be used to generate models, and detect cyber-attacks, within an ICS control flow.

Background

Industrial control systems (ICS), including supervisory control and data acquisition (SCADA) networks, consist of devices such as programmable logic controllers (PLC) which are controlled by operators through human-machine interfaces (HMI). These devices are used to control industrial facilities and critical infrastructure, such as power generation and distribution systems, and water treatment facilities [START_REF] Daneels | What is SCADA[END_REF][START_REF] Igure | Security issues in SCADA networks[END_REF].

ICS networks can spread over large geographical regions, and have been traditionally controlled through point-to-point communications such as serial links. However, these networks are increasingly migrating from dedicated communication links to switched and routed corporate networks through the use of specialised gateways, accessed via virtual private networks (VPN) or the Internet [START_REF] Igure | Security issues in SCADA networks[END_REF][START_REF] Knijff | Control systems/scada forensics, what's the difference?[END_REF]. While exposure to corporate networks and the Internet allows for easier management of ICS devices over a large geographical distance, it also places these devices at risk of cyber-attack [START_REF] Igure | Security issues in SCADA networks[END_REF][START_REF] Knijff | Control systems/scada forensics, what's the difference?[END_REF].

ICS devices generate device logs, which are typically stored on the PLC, or in complex ICS networks, these device logs can be aggregated to a Historian, a device for the storage and archival of device logs. There are several methods ICS devices use to generate device logs, primarily the "Cyclic" method, which records all "tags" or memory values on the PLC at some predefined interval of time, and the "On Change" method, which only records values which have changed in some way. An additional common method of event logging used by ICS devices is to log an event only when an error occurs. This method of recording events is not suitable for process mining based analysis, as the error logs do not log the control flow of the ICS system. From observation of the recorded device logs, we found the "on change" device logs did not measure each value of all tags as the value changed, where some tags with high variance (such as measuring pressure, or water level) were recorded in in 2-3 second intervals. In this regard, the "Cyclic" method configured with a 1 second polling interval provides more complete and accurate device logs than the "on change" method. As such, in this paper, we use the Cyclic type of device log as the starting point for process mining based analysis.

Process models, generated by process discovery algorithms, capture the normative behaviour of the system being modeled. As an example of a process model, we have a sequence of events, (A, B, D). In the second iteration of the process, the sequence of events is (A, C, D). This can be represented in a process model using a Petri-net, describing the control flow of the process, as shown in Figure 1. This method of discovering and modeling the sequence of events can be applied to ICS systems, with the potential to be used to discover a process model, and attacks on the control flow of an ICS process. There are a wide range of process discovery algorithms, which can be identified in several types; such as abstraction-based, heuristic-based, search-based and region-based algorithms [START_REF] Accorsi | On the exploitation of process mining for security audits: the process discovery case[END_REF]. The issue of determining the "best" process mining discovery algorithm for a process discovery activity is a known issue in the process mining domain [START_REF] Rozinat | The need for a process mining evaluation framework in research and practice[END_REF], and several comparisons of algorithms have previously been conducted [START_REF] Weerdt | A multi-dimensional quality assessment of state-of-the-art process discovery algorithms using real-life event logs[END_REF][START_REF] Leemans | Discovery of frequent episodes in event logs[END_REF]. While process discovery and conformance checking have previously been used in the area of security auditing of business processes to detect anomalous behaviour in various contexts [START_REF] Aalst | Process mining and security: Detecting anomalous process executions and checking process conformance[END_REF][START_REF] Accorsi | On the exploitation of process mining for security audits: the conformance checking case[END_REF][START_REF] Accorsi | On the exploitation of process mining for security audits: the process discovery case[END_REF], they are insufficient in the ICS context.This is because there are a number of differences between business processes, the traditional focus of process mining, and ICS processes. Business processes typically contain events which are executed by humans and recorded by an information system, such as a Workflow Management System [START_REF] Van Der Aalst | Business process mining: An industrial application[END_REF]. Compared to ICS processes, these business processes are far more flexible and varied than an ICS process, which is a structured and rigid sequence of events executed by a ICS device. In addition to this difference, event logs generated from business processes are typically far more verbose when compared to device logs from ICS devices, such as PLCs. Therefore, there is a need to identify which process mining algorithm(s) are best for discovering and modeling an ICS process.

To determine which process discovery algorithms are most suitable to generate process models from ICS device logs, that can also be used as an input to a conformance checking activity, we have identified several process discovery algorithms for comparison. These discovery algorithms, namely, are the α-algorithm [START_REF] Van Der Aalst | Workflow mining: Discovering process models from event logs[END_REF], the Integer Linear Programming (ILP) Miner [START_REF] Van Der Werf | Process discovery using integer linear programming[END_REF], the Flexible Heuristics Miner (FHM) [START_REF] Weijters | Flexible heuristics miner (FHM)[END_REF], and the Inductive Miner (IM) [START_REF] Leemans | Discovering block-structured process models from event logs containing infrequent behaviour[END_REF] algorithms. These algorithms were selected as they appear promising for use in conformance checking to detect cyber-attacks on ICS devices. Before we can assess the algorithms, we need to identify requirements needed to create a suitable model of ICS processes.

ICS Modeling Requirements

In the context of ICS networks, there are two main goals for the discovery of an ICS process model. Firstly, to use as an input for a conformance checking activity for the goal of detecting cyber-attacks in an ICS event log, and secondly, to create a process model of an ICS process which is clear and understandable for human interpretation. To generate a process model to suit both of these goals, a process discovery algorithm is used. Process discovery algorithms all have several common features, including the ability to model both sequential and concurrent events, and in addition model repeating event sequences. We have identified several further characteristics for consideration when identifying the most suitable algorithm for ICS process discovery.

Usable Model Representation. For our analysis, we require a usable process model, which contains clear execution semantics, for use in the conformance checking activity. The current state-of-the-art conformance checking activities require the use of Petri-net models. As such, throughout our experiments we use Petri-net models to represent our ICS process and conduct conformance checking activities.

Accuracy. Rozinat, et. al. [START_REF] Rozinat | The need for a process mining evaluation framework in research and practice[END_REF] outline two evaluation dimensions outline two evaluation dimensions which can be applied to determine the accuracy of a model, "Fitness", and "Precision". The first dimension, fitness, describes how well the event log matches the process model. Fitness is measured numerically, between 0 and 1, where 1 represents a perfect fit. Some process discovery techniques remove "noise" from a process model, commonly to simplify the model. Examples of this are the Fuzzy Miner, and the Inductive Miner. However, this will lower the fitness of the model. For conformance checking purposes, especially for identifying anomalous events, the fitness of the generated process model is imperative. The Precision evaluation dimensions prevents over general models, where the generated models are accurate to the process being modelled.

Simplicty. This requirement reflects the goal of creating a process model of an ICS process which is clear and understandable for human interpretation. In most ICS networks, there does not exist a process model of either individual process, or an overall model. The generated process model must be represented in a way which is understandable, avoiding overcomplicated "spaghetti" models. In the case of anomaly detection, when a process model is visually complex, it becomes difficult for a human to quickly visually validate the anomaly. Rozinat, et. al. [START_REF] Rozinat | The need for a process mining evaluation framework in research and practice[END_REF], describe two evaluation dimensions which can apply to this simplicity requirement, "Generalisation" and "Structure". The Generalisation evaluation dimension, conversely to "Precision", prevents over precise models, where over precise models may show each path in the process and may contain duplicate events, which may be easier to understand but less fitting. The Structure dimension refers to the visual structure of the process model. Highly fitting process models may be visually complicated, and hard to read and interpret. Modeling repeating event sequences is a common feature of all process discovery algorithms, and can be modeled either directly in the model, or expressed through the use of silent (τ )-transitions (suitable when there is a choice in the model). Silent transitions are not necessary to model repeating event sequences in a process model, however make the model less complicated. These evaluation dimensions can have an effect on the accuracy of the process model, where more generalisation can reduce the overall fitness of the model.

Experiment

In this section, we outline our experimental methodology to evaluate process models by generated by discovery algorithms, and compare to our identified ICS characteristics and ICS modeling requirements. Firstly, we outline the experimental setup, describing the ICS devices, logging method, and dataset used throughout our experiment. Secondly, we describe our process discovery, and validation using conformance checking activities.

Experimental Setup

The experimental setup consists of four distinct scale industrial control systems, each of these controlled by industry-standard PLCs, Siemens S7-1200's. These four scale systems include a bi-directional conveyor belt system, a water pump system, and a "reactor" system, all connected to a master power meter. These four systems are controlled through the use of a HMI, which acts as a historian, collecting device logs from each of the PLCs. These four devices together with the HMI made a "Process Control Network", connecting to a multi-level corporate network through a gateway, representing a typical ICS network. The device logs recorded throughout our experiment are "Cyclic" device logs, which were configured to record with a 1 second interval, and stored in comma-separated values (CSV) format. This "Cyclic" device log method is where the value of all "tags", or addresses in a PLCs memory, are recorded every specified interval, in our configuration, every 1 second. An example of a typical, unprocessed ICS device log is shown below, in Table 1.

The scale industrial systems form one complete industrial process. This industrial process starts with the bi-directional conveyor belt system, which consists of two loops. Two sensors; one which detects the presence of a puck, and one which detects the colour of a puck, control the direction of a "paddle". As an example of the "Cyclic" device logging method, a snippet of the device log from the conveyor belt is shown in Table 1. Once every second all "tags", or memory addresses on the PLC logged. When a puck is detected, the "VarValue" of the tag "Conv Read Conv Color PE", shown in Table 1, will change from 0 to 1 or -1 depending on the colour of the puck. Once a puck is detected and the colour is determined, the paddle will direct the puck onto one of the two conveyor belt loops depending on the colour. Once the conveyor belt system has completed, the water tank system begins to operate. The water tank system consists of an upper reservoir and a lower reservoir full of water. The lower reservoir is connected to a water pump, which transfers water to the upper reservoir, which uses gravity to feed water back to the lower reservoir. The upper water reservoir contains a water sensor, which turns off the pump when the specified water level is met. This process repeats until a specified time length has elapsed.

The final stage of the industrial process is the "reactor", a pressure vessel system. The reactor is a pipe system, which is connected to an air compressor, and a solenoid with pressure sensors that measures the pressure level in the pipe system, in pounds per square inch (PSI). Once a specified pressure level has been reached, the solenoid activates and opens its valve, releasing air and lowering the pressure to a lower level. Once the lower level has been reached, the solenoid closes and the "reactor" begins to build pressure once again. This process repeats for a designated period of time, at which the remaining pressure is released and the air compressor switches off.

The device logs were generated by the PLCs throughout the operation of an 8 hour exercise, in which two teams: a defending team of four people protecting the process control and corporate networks from an attacking team of six attackers with industrial experience. The attackers were tasked with disrupting the process, through exploiting the "Process Control Network", and causing the ICS devices to deviate from the programmed, expected behaviour of that device.

One example of the attacking team successfully disrupting the industrial process is the changing of the direction of the bi-directional conveyor belt. The conveyor belt sorts coloured "pucks" placed on the belt, sending each colour around a different loop on the conveyor. The attacking team successfully compromised the HMI, and changed the sorting direction of these coloured pucks. This results in the pucks being directed around the wrong direction, disrupting the expected industrial process. Throughout this exercise the attacking team were successfully able to disrupt the industrial process running on all three systems, the conveyor belt system, the water tank system, and the "reactor" system. The device logs from each ICS system were collected by the HMI on the "Process Control Network", which acted as the historian. These collected devices logs contained the cyber-attacks that were conducted by the attacking team throughout the duration of the 8 hour exercise. These device logs were then aggregated and pre-processed, creating our dataset of event logs, and preparing them for process mining activities.

The dataset consisted 25 cases, with 71 event classes and a total of 1855 events. One "case" represents a complete execution of the ICS process. The PLCs, HMI, and device logging methods were programmed and configured through the use of WinCC and STEP 7, as part of the Siemens TIA Portal V11 SP2. The experiments were not conducted on production ICS networks, as attacks conducted upon these scale systems interrupt the control flow of the ICS process. These scale systems and industrial process used throughout or experiments, while not production systems, use industry-standard ICS devices, four Siemens S7-1200 PLCs.

Experimental Methodology

Using our dataset of pre-processed event logs, generated from device logs aggregated throughout the 8 hour exercise, we discover 5 process models using the widely used algorithms outlined in Section 2. These include the α-algorithm, ILP Miner, Flexible Heuristics Miner, Inductive Miner configured with default fitness, and Inductive Miner configured with perfect fitness. The default and perfect fitness for the Inductive Miner are configuration parameters when generating a process model. The use of both Inductive Miner with default fitness and the Inductive Miner with perfect fitness to generate a process model is to compare the results of removing noise and low-varying events from a process model, and the impact this has upon conformance checking for anomaly detection. In addition to the models generated by process discovery algorithms, we use a manually-created Petri-net model of the ICS process. While the manual creation of a process model can capture an accurate picture of an ICS process, this requires specialist knowledge of the ICS systems, and process, being modeled. Using process discovery algorithms, a process model of a complicated ICS system can be created without this in-depth knowledge requirement.

To discover a process model using the outlined algorithms from our dataset, we extracted the first 10 cases, or first 10 complete process executions of the ICS process; a representative sample of the complete ICS process where the cases were known to contain no cyber-attacks. It is assumed while generating models of the ICS process, the event logs used in the generation contain no attack data. Using the Disco 1 tool, we converted the pre-processed event log from CSV format to XES format, for use with the Process Mining Toolkit (ProM) 2 version 6.5.1. Using the Petri-net models generated using the ProM tool, and our manually created Petri-net model, we conducted a total of 6 conformance checks, using ProM with the "Replay a Log on Petri Net for Conformance Analysis" plugin, comparing each discovered process model against our full dataset. Both the process discovery and conformance checking activities were conducted on a Dell Optiplex 9020 desktop computer, with an i7-4770 CPU, 16GB RAM, and 256GB SSD.

Results and Analysis

We have laid out in Section 3 the requirements for generating process models, firstly for use in a conformance checking activity with the goal of identifying anomalies, such as cyber attacks, in an ICS event log, and secondly for human interpretation. The process models generated by the selected process mining algorithms, outlined in Section 2 are evaluated by these requirements, and the results of this evaluation are described under each requirement below, and summarised in Table 2.

Algorithm Model Accuracy Simplicity α-algorithm [START_REF] Van Der Aalst | Workflow mining: Discovering process models from event logs[END_REF] ILP Miner [START_REF] Van Der Werf | Process discovery using integer linear programming[END_REF] FHM [START_REF] Weijters | Flexible heuristics miner (FHM)[END_REF] / IM (Default) [START_REF] Leemans | Discovering block-structured process models from event logs containing infrequent behaviour[END_REF] IM (Perfect) [START_REF] Leemans | Discovering block-structured process models from event logs containing infrequent behaviour[END_REF] Table 2. Comparison of models generated by selected process discovery algorithms with identified requirements of ICS process discovery.

All models were either generated in or can be converted to Petri-net form, making all models usable in a conformance checking activity. To test the "Fitness" of the generated process models, we conduct a conformance check on the representative sample used to generate each model. The process models generated by the ILP Miner, α-algorithm, and Inductive Miner with perfect fitness, all fit the representative example of the ICS process event log which was taken to generate the process models, and are precise. Both models generated by the Flexible Heuristics Miner with a move-log fitness of 0.27, and the Inductive Miner, configured with default fitness, with a move-log fitness of 0.95, do not fit this sample. This is due to both algorithms filtering infrequent events. The process model generated for use in conformance checking for anomaly detection must be as close to, or perfectly fitting, to the ICS process as possible. Any non fitting events during a later conformance check for anomaly detection are treated as "anomalous", resulting in "false positives" as the model is inaccurate. This can be observed in Table 3. From this "fitness" metric, we can determine that the process models generated by the Flexible Heuristics Miner and Inductive Miner with default fitness are not suitable for use in a conformance checking activity to detect anomalous events, such as cyber attacks. We have identified two evaluation dimensions for the Simplicity requirement, described in Section 3, "Generalisation" and "Structure". Both the generalisation and structure dimensions can be evaluated through observation of the generated process models. The process models generated by the Heuristics Miner, and Inductive Miner are both structured and are at a suitable level of generalisation, showing the control flow of the ICS process without impacting on the fitness of the process model. However, the models generated by the α-algorithm and ILP Miner, although fitting, have significantly more arcs within the model, with 47 places connected by 122 arcs, and 26 places connected by 179 arcs respectively. This significant difference in arcs is shown in Figure 3. This is compared to Inductive Miner with 30 places connected by 88 Arcs for default fitness, and 34 places connected by 110 arcs for perfect fitness, resulting in the ILP and α-algorithm models being less structured and visually harder to interpret. The process models generated by the Flexible Heuristic Miner and Inductive Miner with both default fitness and perfect fitness settings model repeating event sequences through the use of silent transitions. These models with silent transitions simplify the model, resulting in the models being easier to interpret. Using the process models generated from several widely used discovery algorithms, we conduct several conformance checking activities on our pre-processed ICS event log. Our dataset contained 25 cases, five of these cases contained cyber-attacks which were conducted on the experimental setup throughout the duration of the 8-hour exercise, outlined in Section 4.1. The results of these conformance checking activities are shown below, in Table 3, including number detected anomalous cases, Trace Fitness, and calculation time in milliseconds. The "Trace Fitness" value represents how well the event log fits the Petri-net models generated by the discovery algorithms.

The conformance checking activities were successfully able to identify the 5 anomalous cases on models generated by the α-algorithm, ILP Miner, Inductive Miner with perfect fitness, and our existing, manually-created model, as shown in Table 3. These anomalous cases contain the cyber-attacks conducted by the attacking team throughout the 8 hour exercise, showing where the event log deviates from the expected behaviour of the ICS, outlined in the generated process models. An example of this deviation can be shown with the water tank system. During one attack case, the attackers exploited the HMI and changed the operation of the water tank from "automatic" to "manual". This allows an attacker to manually control the level at which the water level sensor activates, potentially allowing the attackers to overflow one of the water reservoirs. When this event is recorded in the device log, and "replayed" over the process models during the conformance checking activity, it appears as a deviation where the event did not "fit" the process model representing the control flow of the ICS process. Both models created by the Flexible Heuristics Miner and Inductive Miner with default fitness settings failed to accurately model the ICS process, resulting in the conformance check returning both 25 and 24 anomalous cases, respectively. This was caused by both Flexible Heuristics Miner and Inductive Miner reducing "noise".

The Flexible Heuristics Miner, and Inductive Miner with default fitness, both employ methods of filtering noise and low-frequency events. While the removal of noise is a common and useful practice in process mining activities, it is not recommended in anomaly detection for identifying cyber-attacks, as the models must accurately represent the behaviour of the ICS. Removing low-frequency events or "noise" from the model can result in false positives, as shown with Flexible Heuristics Miner and Inductive Miner (with default fitness). These results suggest that the Inductive Miner algorithm, configured with perfect fitness, is the most suitable process discovery algorithm for both the creation of a process model of an ICS process for human interpretation, and for use in a conformance checking activity with the goal of identifying anomalies, such as cyber attacks, in a ICS event log. One limitation to current process discovery algorithms is the concept of a "case" in process mining. Most ICS device logs do not have an indication of "case", and require a pre-processing stage to prepare the logs for process mining activities. An area of future work is the development of a process discovery algorithm which can discover an ICS process model without the requirement for a "case".

In addition to detected cases, we found considerable differences in the time required for conducing the conformance checks. The ProM tool reported the calculation time in milliseconds(ms) taken for each full conformance check. The conformance check on the model generated by the Flexible Heuristics Miner was conducted in the largest amount of time, a total of 54.24ms. This was followed by the existing, manually-created model in 28.68ms, and the α-algorithm in 25.60ms. The conformance checks using the models generated by the Inductive Miner (with perfect fitness), the Inductive Miner (with default fitness), and ILP Miner, were significantly faster. The Inductive Miner with perfect fitness completing in 1.88ms, with default fitness in 1.48ms, and the ILP miner in 2.08ms. The conformance check upon the manually-created model the returned same anomalous cases as process models generated by the α-algorithm, ILP Miner, and Inductive Miner configured with perfect fitness, however took more time to complete, in 28.68ms. This indicates the process models generated by process discovery algorithms can accurately capture an ICS process.

Existing IDS used on ICS networks rely on signatures of known attacks in signature-based IDS, or long-term analysis of network traffic in statistical anomaly based IDS. For a signature of an cyber-attack to exist, there must be prior knowledge of the cyber-attack. Our process mining based process discovery and conformance checking methods used in this paper have successfully detected cyber-attacks conducted on industry standard ICS devices, the Siemens S7-1200, using process models generated by widely-used process discovery algorithms. This shows process mining can be used in supplement to traditional IDS devices to detect previously-unknown cyber-attacks.

Conclusion

The conformance checking activity with the α-algorithm, ILP Miner, Inductive Miner with perfect fitness all successfully identifying the five anomalous cases containing cyber attacks in the ICS event log. Experimental results show that the Inductive Miner algorithm, configured with perfect fitness, was the most suitable algorithm for use in detecting cyber attacks.

The process mining based methods presented in this paper, unlike IDS systems, are a form of offline analysis, which takes place on device logs after a process has been completed. An area of future work is to modify this method to operate in real or near-real time to improve the detection speed of ICS anomalies. Some attacks, such as Man-in-the-Middle (MITM) attacks used in the Stuxnet attack, may not be detected due to insufficient logging. One method of detecting these attacks could be to correlate device log data and low level sensor data for use in process mining based intrusion detection. Larger datasets, and assessment of the scalability of this method on larger datasets is required.

Fig. 1 .

 1 Fig. 1. Example of a process model capturing both sequential and concurrent events.

Fig. 2 .

 2 Fig. 2. Process model Generated using Inductive Miner (perfect fitness).

Fig. 3 .

 3 Fig. 3. Process model for illustrative purposes using the ILP Miner to show the complexity of discovered model, where there is less generalisation and structure, with and more arcs in model.

Table 1 .

 1 Example snippet of a typical ICS device log, obtained from the conveyor belt system.

	VarName	TimeString	VarValue Validity Time ms
	Conv Read Conv Color PE	16/07/2015 9:31 0	1	42201396613
	Conv Read Conv HMI Direction	16/07/2015 9:31 0	1	42201396613
	Conv Read Conv Present PE	16/07/2015 9:31 0	1	42201396613
	Conv Read Solenoid Left Direction 16/07/2015 9:31 0	1	42201396613
	Conv Read Solenoid Right Direction 16/07/2015 9:31 0	1	42201396613

Table 3 .

 3 Results of conformance checking activity on discovered process models.

	Algorithm Cases Trace Fitness Time(ms)
	α-algorithm [13] 5	0.93	25.60
	ILP Miner [16] 5	0.93	2.08
	FHM [18] 25	0.31	54.24
	IM [11] (Perfect) 5	0.93	1.88
	IM [11] (Default) 24	0.89	1.48
	Manual Model 5	0.93	28.68

http://fluxicon.com/disco/

http://www.promtools.org/doku.php