A twofold model for the analysis of access control policies in industrial networked systems

Computer Standards & Interfaces 42 (2015) 171–181

Contents lists available at ScienceDirect

Computer Standards & Interfaces journal homepage: www.elsevier.com/locate/csi

A twofold model for the analysis of access control policies in industrial networked systems Ivan Cibrario Bertolotti, Luca Durante, Lucia Seno ⁎, Adriano Valenzano CNR-IEIIT, c.so Duca degli Abruzzi 24, I-10129 Torino, Italy

a r t i c l e

i n f o

Article history: Received 16 June 2014 Received in revised form 31 March 2015 Accepted 25 May 2015 Available online 11 June 2015 Keywords: Industrial networked systems Access control RBAC Security Modeling of distributed systems

a b s t r a c t Requirements concerning the specification and correct implementation of access control policies have become more and more popular in industrial networked systems during the last years. Unfortunately, the peculiar characteristics of industrial systems often prevent the designer from taking full advantage of technologies and techniques already developed and profitably employed in other application areas. In particular, the unavailability and/or impossibility of adopting hardware (h/w) and software (s/w) mechanisms able to automatically enforce the policies defined at a high level of abstraction, often results in checking the correctness of policy implementation in the real system manually. The first step towards carrying out this cumbersome task in an automated way is the development of a model able to capture both the high level policy specification as well as the details and low-level mechanisms characterizing the actual system implementation. This paper introduces a twofold model for the description of access control policies in industrial environments aimed at coping with this requirement and which can be profitably adopted in several kinds of automated analysis. © 2015 Elsevier B.V. All rights reserved.

1. Introduction In the last years, the security of industrial networked systems (INS) and, especially, those aspects regarding the protection against threats carried out from either their inside or their outside have been receiving increasing attention [1–7]. Prevention/detection of attacks as well as reaction triggering have been also significantly considered in the scientific literature [8–10]. Unfortunately, relatively little work has been done about techniques for the coherent, error-free design of access control policies and, in particular, for the verification of correctness of policy implementation. The specification and implementation of access control policies is one of the fundamental steps in the process of securing any kind of system. Indeed, in almost all situations where the access to resources has to be managed in a secure way, a basic need is guaranteeing that the specification of access control policies and their implementation match correctly to some extent. This aspect is remarkably true for INS, such as those adopted in distributed process control/automation applications and critical infrastructures. Because of technological progresses and enhancements, these systems look more and more similar, today, to general-purpose IT solutions that are popular in other application areas such as, for instance, office and enterprise networks. The other side of the coin is

⁎ Corresponding author. E-mail addresses: [email protected] (I. Cibrario Bertolotti), [email protected] (L. Durante), [email protected] (L. Seno), [email protected] (A. Valenzano).

http://dx.doi.org/10.1016/j.csi.2015.05.002 0920-5489/© 2015 Elsevier B.V. All rights reserved.

that they are exposed to the same cyber-threats experienced by their IT counterparts. Different performance and functional requirements, which make INS different from general-purpose IT systems [11], deeply affect the way the matching between the specification and implementation of policies can be guaranteed. In particular, in most real situations the only viable option is an a posteriori verification of correctness of policy implementation. Moreover, this difficult and cumbersome task has often to be performed by hand, which makes it even more time-consuming and error-prone. In these conditions a model, designed to both specify access control policies and capture descriptive elements about the low-level access control mechanisms used for their implementation, is of valuable help in enabling correctness and coherence analyses. Our approach keeps a neat separation between the description of policies following the Role Based Access Control (RBAC) paradigm [12,13], and the description of the system structure including its low-level access control mechanisms and architectural details. In the following we will refer to the RBAC-based portion of the model as the Specification model, while the part dealing with the actual system description will be called Implementation model. The Implementation view of the model, in particular, takes into account a wide variety of access control mechanisms, which are usually deployed in industrial distributed systems, and is the basis needed to provide a detailed description of the sequences of actions which can be performed by any user to access resources in the considered system. Specifically, the Implementation model allows for the description of both the system spatial topology (i.e. rooms and gates, cabinets, and so on) and its protection

172

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181

(locks and keys, electronic access control mechanisms, etc.). Devices and their physical locations and interconnections are also modeled together with services offered by any of them. Preconditions necessary for accessing services are considered as well (i.e. the need for either the physical access to the host where the service is located or the host accessibility through the network) and network device settings (e.g. firewall configurations) are also taken into account. The main idea is schematically represented in Fig. 1 which puts into evidence how information about high-level policies is collected in the Specification part of the model, while low-level mechanisms and fine-grained details, concerning the real system implementation, build up the Implementation part. The two portions of the model are then processed by an automated analysis s/w tool, which is able compute all the possible actions a user should be allowed to perform according to the policy definition (Specification set), on the one hand, and all the operations the user is actually able to carry out in the actual system implementation (Implementation set), on the other hand. In particular, to compute the Implementation set, the tools builds a Labeled Transition System (LTS) for each user in the system, recording all the possible sequences of actions he/she can perform in the real systems. Elements in both Specification and Implementation sets are triples in the form (user, operation, object). By (automatically) comparing the resulting sets, the designer can check whether the system is correctly supporting the policies as expected (verification) or discrepancies are discovered. Clearly, in practical situation this process is iterative and, in principle, it should be repeated any time anything changes in the system. This occurs, for instance, whenever some policy implementation error is discovered and corrected, so as to keep the Implementation model aligned with the physical system characteristics and guarantee the

consistency of the verification procedure. Note that in Fig. 1 dashed lines indicate tasks that need to be carried out manually by the designer, while solid ones represent actions/computations automatically performed by the tool. Even though our final goal is checking whether or not the Implementation matches the Specification correctly, the focus of this paper is on the ability of our model to describe policies and access mechanisms in industrial systems in detail, thus the characteristics of the analysis and automated s/w tool will not be discussed further. The interested reader can find more details on these aspects in [14–17]. It must be pointed out that, while the Specification set directly comes from the policy definition, deriving the Implementation model from the real system could be a cumbersome task requiring careful consideration. Our future activities will address such a critical point by trying to use already available system information (network equipment configuration files, cabling and network schema, and so on) to automatically feed parts of the model. The paper is then organized as follows: Section 2 discusses some related works and Section 3 introduces the model structure. Section 4 describes the RBAC-based Specification model in more detail, while Section 5 deals with the Implementation model and, in particular, presents the description of the physical system and the LTS used to compute the Implementation set. Finally, some conclusions are drawn in Section 6. 2. Related works Access control in general, and RBAC in particular [18–21], have been hot topics for many years: a lot of research has been done in the past,

Fig. 1. Logical schema of the verification process.

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181

and many studies are currently being carried out. Clearly, access control alone cannot guarantee the protection of a system from malicious attacks, indeed an attacker can always impersonate a legitimate user and carry out unwanted actions. Nevertheless, the definition and enforcement of suitable access control policies is a necessary building block on which the security of any type of system security is constructed. Access control policy management and compliance check are main subtopics and related scientific activities can be categorized according to three principal branches, that is: 1. works that deal only with policies, independently of their explicit relations to real-world systems. These works are mainly aimed at checking that a given set of policies satisfies some set of requirements. Typical examples are [18–23]. In particular, [22] proposes a formal model to describe access control policies and a tool for verifying their properties, [23] pursues a similar goal using SecureUML as a descriptive framework, [19] deals with the verification of properties of RBAC policies with constraints on the user-role assignments, [20] addresses the automated analysis of administrative attribute-based RBAC policies by means of symbolic techniques, while [21] proposes an efficient and scalable technique for analyzing administrative RBAC policies. Finally, [18] addresses the problem of verifying properties of RBAC access control policies from a computational complexity point of view. 2. Works that also take into account the problem of enforcing policies in a real system, by either proposing or assuming that the system is able to provide mechanisms to guarantee such an enforcement. For instance, the introduction of slight modifications in the operating system of the networks nodes and/or in the node hardware architecture has been considered in [24]. This requires powerful nodes, able to deal with enriched software, and (de facto) standard architectures for s/w and h/w, so as to make the cost of these enhancements affordable. Unfortunately, these requirements are rarely satisfied in most INS and, as a consequence, this kind of approach results rather unfeasible for industrial applications. In fact, INS are often very heterogeneous in their nature, since they include many different kinds of special devices, such as Programmable Logic Controllers (PLCs), robots, intelligent sensors and actuators, etc. which are usually equipped with proprietary h/w and s/w and whose modification is beyond dispute. Communication protocols used in industrial environments are special-purpose and often proprietary too, making it even more difficult to deal with the distributed components of the system in a general and comprehensive way. Furthermore, h/w and s/w patching and upgrading is not a common (and viable) practice in most cases since from this point of view, this kind of systems are often designed and expected to last for decades and work for 24 h 7 days a week. Examples of this kind of solutions are reported in [25–27,24,28,29]. In particular, [25] proposes a method to conduct conformance checking of access control policies specified in XACML; in this case a Policy Decision Point (PDP) is assumed to be available, so that the underlying real system can provide some basic enforcement mechanism for access control. [26] presents a tool for analyzing role-based access control policies expressed in XACML. Policies of a real software application are analyzed by assuming that the application is able to enforce them. [27] deals with the conformance testing of software implementations required to enforce temporal RBAC policies. [24] proposes an integration of RBAC in UNIX systems to give more flexibility in users administration, but the proposed approach involves changes to the operating system. [28] compares access control schemes with respect to (a formal model of) the application needs, assuming that enforcement mechanisms are available for the application. [29] proposes a complete methodology for the specification, analysis and enforcement of access control policies where underlying enforcement mechanisms are assumed. 3. Very few methodologies [30–33] are able to check access control

173

policies against real distributed and networked systems (such as INS) without assuming (reliable) policy enforcement mechanisms. SkyBox [30] is a software suite able to check network access policies against a real system, whose model can be automatically fed from the configuration files of real devices. The analysis is mainly focused on firewalls and other network devices. NetAPT (now NP-View) [31, 32] is a software tool able to check global network access policies against the network topology and firewall configurations of a real system. The tool is also able to take into account further sources of system details (e.g., SE-Linux policies). [33] proposes a technique to generate all the actions allowed by the policies and all the actions allowed by the real system, limited to a network infrastructure and hosts that have to be equipped with SE-Linux. Possible actions are then compared in order to identify discrepancies. 3. The model The Specification and Implementation model parts, namely S and I , are the basis needed to compute the sets of “who can do what on what object” in the two system views, that is the Specification and the Implementation sets. In the following we will call S and I these two sets respectively. The comparison of S and I is the first step of the verification process. More formally, the input M of the analysis tool in Fig. 1 is a pair: M ¼ ðS; I Þ while its output is given by the two sets S and I, where ^; ω ^ Þg ^; π S ¼ fðu

ð1Þ

I ¼ fðpˇ ; πˇ ; ωˇ Þg:

ð2Þ

The components of the triples in S and I are elements of the sets introduced in Table 1. In the table, USERS, OPS, OBS, PLAYERS, OPERATIONS, and OBJECTS are, in general, disjoint sets of names, which could also be pairwise put into one-to-one correspondence (each row in Table 1) in order to simplify the verification phase. Actually, we have introduced this simplifying assumption in the ongoing experimentation of our analysis tool since, besides making the verification process easier, it looks reasonable in most real industrial situations we considered where, for instance, it does make little or no sense having a single RBAC user impersonated by more than one system player. In particular, in establishing a correspondence between the Specification USERS and the Implementation PLAYERS, we assume that û and pˇ are the subjects ^ or πˇ on object ω ^ or ωˇ respectively (the carrying out the operation π adoption of two different cap symbols ‘ˆ’ and ‘ˇ’ takes into account the conceptual difference between the two views). The word “player”, in particular, was chosen to prevent the occurrence of ambiguities with “username”, another concept used in the Implementation part of the model. 4. The specification part The Specification part of the model is based on RBAC. RBAC is a well known framework [12], also standardized by ANSI [13] allowing for the design and management of sophisticated access control policies by means of the definition of roles, that is job titles with associated Table 1 Specification vs Implementation names. Specification names

Implementation names

û ∈ USERS ^ ∈ OPS π ^ ∈ OBS ω

pˇ ∈ PLAYERS πˇ ∈ OPERATIONS ωˇ ∈ OBJECTS

174

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181

functions and duties. Both permissions and users are assigned to roles. Roles can be organized in a hierarchical fashion, allowing role inheritance to users and permission inheritance to roles. Following the classification of the RBAC flavors of [13], here we consider hierarchical RBAC, although without the introduction of sessions (see Table 2), because we have to deal with industrial systems that often do not provide any mechanism able to manage them. The removal of sessions from both core and hierarchical RBAC has been already deeply discussed in [34] and [35]. Moreover, on one side industrial systems are quite static in terms of configuration and management, and consequently it makes little sense using the administrative part of RBAC, on the other, they usually lack the software and hardware support to implement such a dynamic role management. For these reasons, we do not explicitly address methodologies such as Attribute Based Access Control (ABAC) [36–38] and Discretionary Access Control (DAC) [39], as they are mainly suited when access control policies are affected by dynamically changing attributes and permission assignments to users/roles respectively. Anyway, our model allows exploiting ABAC, DAC and also RBAC with sessions and administrative roles by simply analyzing configurations arising from dynamic changes one at a time. Given the definitions of Table 2, the set S of Eq. (1) corresponding to an RBAC specification can be computed as:

^; ω ^ Þ ∈ S ⇔ ∃ ^r ∈ ROLES j ^; π ðu

8 <

^ ∈ auth usersð^r Þ u : ∧ : ^ ^ ðπ; ωÞ ∈ p ∈ auth prmsð^r Þ

ð3Þ

4.1. Specification example Let us consider an industrial environment where some roles (e.g., process engineer, junior maintainer, junior engineer) operate on a programmable logic controller (PLC) and a DataBase application (DB) running on a supervisory control and data acquisition (SCADA) server. These roles, as well as related resources, allow operations and permissions that are very common in industrial networks. We can assume these elements to be constrained by a set of company-wide policies, regardless of their actual implementation in a specific factory or plant. Fig. 2 graphically shows a very basic hierarchy for roles, expressed in terms of inheritance in Table 3. Further implementation-independent ingredients are, for instance, the two objects in Table 4 and the set of operations in Table 5, whereas the users in Table 6 are context-dependent. The assignment of users to roles (UA) in the example is graphically shown in Table 7 (row by row) by means of the two leftmost columns, while the assignment of permissions to roles (PA) is obtained through Table 2 RBAC — short summary. Core RBAC without sessions ROLES USERS UA ⊆ users × ROLES assigned_users(^r : ROLES) → 2(USERS) OPS OBS PRMS = 2ðOPSOBSÞ PA ⊆ PRMS × ROLES assigned_prms(^r : ROLES) → 2ðPRMSÞ

Set of roles: ^r ∈ ROLES Set of users: û ∈ USERS Users assignment to roles ^ ; ^r Þ ∈ UA} assigned_users(^r ) = {û ∈ USERS| ðu ^ ∈ OPS Set of operations: π ^ ∈ OBS Set of objects: ω Set of permissions Permissions assignment to roles assigned_prms(^r ) = {p ∈ PRMSj(p, ^r ) ∈ PA}

General role hierarchies RH ⊆ ROLES × ROLES auth_users(^r : ROLES) → 2(USERS) auth_prms(^r : ROLES) → 2(PRMS)

Partial order on ROLES: inheritance relation ≽ auth_users(^r ) = {û ∈ USERS| ^r' ≽ ^r,(û, ^r') ∈ UA} auth_prms(^r ) = {p ∈ PRMS| ^r ≽ ^r ',(p, ^r ') ∈ PA}

pe jm

process engineer

junior maintainer

je

junior engineer

Fig. 2. Role hierarchy.

the two rightmost columns. By applying rule in Eq. (3), it is then possible to compute S as shown in Table 8.

5. The implementation part The Implementation part of the model deals with the details of the physical system and its access and traffic control mechanisms, thus it is a bit more complex and larger than the high-level policy specification counterpart. As already stated and motivated before, the systems we deal with are not powerful enough to automatically implement high-level access control policies by means of some policy enforcement infrastructure. As an obvious consequence, only the simplest and traditional low-level access control mechanisms are taken into account in our model. This lead to the not trivial task of checking whether or not all the available low-level mechanisms implemented and configured in the system, globally cooperate in order to make the high-level access control policies satisfied. As expected, these mechanisms are the following: • physical containment, such as rooms and cabinets possibly requiring some credential (key, password, badge) to be accessed; • network reachability, managed through active network devices (e.g. firewall, routers and switch) properly configured by means of suitable rules; • local and remote access rights on system resources, as usual based on usernames and groups and their assigned rights and/or capabilities.

The system model must allow to describe the above mechanisms (static description) and how they affect the user behavior (inference rules), and our solution is centered on these concepts. Anyway, also more sophisticated mechanisms, such as centralized authentication systems, can be easily taken into account in our framework. In particular, the Implementation part of the model has two main sub-parts: the data model is the static description of the system, e.g., network topology and devices, hosts and their configurations, physical locations of devices (rooms, cabinets and so on). The second part of the implementation consists of both inference rules, needed to compute all possible actions of players, and the players' (initial) state. Unessential details about the traffic control devices such as firewalls, switches and routers, will be omitted in the following, as well as the techniques for computing the reachability of nodes, since the theory, data structures and algorithms presented in [40] fit in well with our framework and have been borrowed consequently. In particular, our model takes into account the same network elements at the basis of the methodology of [40], and we assume that the whole network reachability has already been computed by means of [40], and is available through simple queries. This implies that our view of the network is static, that is its connectivity properties are not affected by the actions of players. In principle this assumption could also sound unrealistic, but this choice is motivated by the following reasons: Table 3 Role inheritance. RBAC roles pe ≽ jm pe ≽ je

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181 Table 4 RBAC OBS.

P LC DB

175 Table 6 RBAC USERS.

Programmable Logic Controller DataBase Application

Jeff@@@ Jenny Jim Peggy

• we have to deal with systems that were designed with very little or no attention to security. In these situations, which occur very frequently in industrial environments, the verification of access control policies belonging to the first line of defense [11], is justified even if carried out in a coarse grained way. • In this framework a violation is, for instance, a legitimate operation on a legitimate object, done by a subject not explicitly authorized to do so by a suitable policy. • From a pragmatic point of view, more subtle violations (and sophisticated techniques originating them) should be investigated only after main flaws have been detected and patched. • Our perception is that removing such a restriction from the model might not be too difficult from a theoretical point of view, but this would surely increase the computational complexity of the analysis and, at least in the experimentation phase, we prefer to keep the set of possible problems sufficiently small. 5.1. System description As already mentioned, the Implementation set can be computed from the data model, the players' status representation and a set of inference rules. Formally, the data model D is a pair: D ::¼ ðΩ; ΛÞ

ð4Þ

where Ω :: = {ω★} is the set of objects, that is the set of all elements of the system on which operations can be performed, such as rooms and other containers (e.g. cabinets), host devices (e.g., PCs, PLCs and so on) and relevant software services (e.g. DB), and network devices (e.g. firewalls, switches, routers and so on), while Λ :: = {λ} keeps track of all physical network links. Any object ω★ ∈ Ω is formally described as     ω★ ::¼ ωid ; π★ ; ωpath ; fðn; g Þg; fppg; f f r g :

ð5Þ

In Eq. (5) ωid and ωpath are the object identifier and path respectively. Indeed, in the data model objects can be nested, that is an object can contain and can be contained in other objects, so that any of them is uniquely identified by both its identifier ωid and its path ωpath ¼ ωid1 ; ωid2 ; …; ωidk , namely the ordered sequence of identifiers of the k objects that need to be crossed to access the considered one. The unique identifier of an object is then given by ωˇ ¼ ωpath ; ωid. To keep the notation lighter, we will use the shortest suffix of ωˇ allowing to uniquely identify each object. This means that when ωid is enough to uniquely identify an object, it will be used as object name without any further prefix, that is in our example ωˇ ¼ ωid . Moreover, the description of objects (and operations) belonging to this part of the model, includes implementation details. In an RBAC model, objects and operations belong to orthogonal sets, so that the

designer can build permissions by selecting any possible (operation, object) pair. Typical industrial systems, however, include a lot of special objects where only ad hoc operations are meaningful, and this would introduce an excessive number of forbidden pairs, if the two sets were considered orthogonal. Thus, for practical reasons, we decided to specify the meaningful operations for each object and bind them to the object itself. This choice does not prevent the computation of the set I in (2) in any way. As a consequence in our model we introduce the concept extended objects (i.e. ω★), that is objects to which a set of extended operations (i.e. operations enriched with implementation details) is bound (i.e. fπ★ g). Table 9 lists the remaining elements in Eq. (5) with their definition (note that [⋯] stands for optional and {⋯} means a possible empty set). The meaning of the items appearing in the table is the following: • (n, g) is an account defined on object ω★. • pp is a physical port (network interface). idpp is its unique identifier, while dla is a data-link address (e.g. MAC address: some network interfaces, such as in firewalls, are not assigned a data-link address), and {na} is a set of network addresses bound to dla. ½w; ½c; fωˇ g, instead, is used to characterize wireless interfaces: w means that the interface supports wireless communications, [c] is the possible credential required to connect to the interface (i.e., access point), and fωˇ g is the set of room objects where the interface is accessible. Many sub-tuples hdla; fnag; ½w; ½c; fωˇ gi are allowed. • fr, filtering rules, have a general form based on the constitutive elements listed in the lower part of Table 9. A single rule for a specific device may not include all the elements in the table, and wildcards are also allowed. We will not discuss filtering rules in more details in this paper, since we rely on [40] for the network reachability computation. Such a rule format is general, and contains the union of the fields needed in firewall rules, switch rules, and so on. This means that given a particular device and/or rule, not all the fields are meaningful or needed and, in this case, we use symbol “−” for the unused fields. • λ is a set of fully interconnected physical port identifiers. A point-topoint link is described by means of two ports, whereas buses can have several ports. ★

An extended operation π can take one of the two possible forms described by Eqs. (6) and (7): π★ ::¼ hπˇ ; fhd; fcgigi

ð6Þ

π★ ::¼ hπˇ ; f f gi:

ð7Þ

Form in Eq. (6) is used when the object, to which the operation is bound, is a room or a physical container, πˇ is the operation name,

Table 7 RBAC assignments. Table 5 RBAC OPS. read write upload_part_program run_part_program admin

U SERS

ROLES

P eggy Jim Jef f Jenny

pe UA

jm je

PA

P RM S admin, P LC admin, DB run part program, P LC upload part program, P LC read, DB write, DB

176

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181

Table 8 The S set.

Table 10 Preconditions and effects f.

(Peggy, admin, PLC) (Peggy, run_part_program, PLC) (Peggy, read, DB) (Jim, run_part_program, PLC) (Jeff, read, DB) (Jenny, read, DB)

(Peggy, admin, DB) (Peggy, upload _part_program, PLC) (Peggy, write, DB) (Jim, upload_part_program, PLC) (Jeff, write, DB) (Jenny, write, DB)

f pre

::= ::=

pre, post access ½ci hphysical D

j j j

e.g. enter, whereas the set {〈d, {c}〉} describes all the gates which allow entering the room. {c} is the set of all credentials that are needed to open gate d. The adoption of a set is useful, in this case, to model situations where each player has his/her own credential to open a given gate, besides circumstances where just one credential is shared among all players. Moreover, different credentials can also be assigned to the same gate, depending on the direction it is actually crossed. Similarly to form in Eq. (6), form in Eq. (7) is used to describe operations a player can carry out on devices and their resources and πˇ is the operation name (e.g., upload_part_program, start_part_program, admin), while f specifies both the preconditions and effects of πˇ on either the involved resource or (possibly) other resources. Table 10 shows the f syntax, where four different and mutually exclusive kinds of preconditions can be specified. Their semantics is, informally, the following: • physical_acccess[c] means that a player must be in the same room of ωˇ , i.e. have physical access to it, and own credential c (if specified) in order to be able to perform πˇ . 0 0 • local access ωˇ : n0 ½c and local access ωˇ : g 0 ½c mean that, in order to perform πˇ on ωˇ , a player must already be active (e.g., logged) on 0 some object ωˇ , by means of either the player's username n′ or the group g ′ he/she belongs to. Note that, that preconditions may involve different objects. Moreover, when specified, credential c must also be owned by the player. • remote_access[c] means that the operation can be carried out by a player through a remote connection at either the network or data link level. The player must own credential c when specified. It is worth noting that TCP/IP connections are always established between logical ports, but industrial systems often include special-purpose devices and software that adopt communications at the data-link level. In the definition of port, lp is a logical port whose unique identifier is idlp. pn is an optional port number (e.g., 8080), na is the network address (e.g., IP address), while pr is an optional protocol (e.g. Modbus).

The element post in Table 10 takes into account the possible effect of the operation: in particular ωˇ ″ : n″ , if specified, means that, by performing the operation, the player gains (local) access with username n″ to object ωˇ ″ (e.g., the effect of the UNIX su operation on the login status).

port lp

::= ::=

post

::=

D

E 0 0 local access ωˇ : n ½c E 0 0 local access ωˇ : g ½c

hremote access port ½ci

dla | lp

hidlp ; ½pn; na; ½pri ½ωˇ ″ : n″ 

5.2. Implementation model example Fig. 3 shows a very simple example of topology for an industrial plant, where rooms and gates are put into evidence. The corresponding data model description, is given in Fig. 4. It is worth noting that, for the sake of simplicity and conciseness, each gate is assigned only one credential (e.g., a password or a physical key). The first row of the description concerns room RO, and shows the correspondence between elements and definitions (5) and (6). The larger set {〈d, {c}〉} for RE is specified in the second row. All gates in the example, with the exception of dPP, adopt the same credential for enabling crossing in both directions. In our example, dPP is shared between RPN and RPLC. This is because RPLC models a cabinet and requiring a credential (i.e., a physical key) to open it is reasonable for many practical situations (the corresponding operation has been named open in the last row). Of course, it does not make sense for a player to “cross” the gate from RPLC to RPN in this case, so no credential is specified. The logical structure of the sample network in Fig. 5 is rather common in industrial environments and has been inspired by best practices. Clouds have been used to hide (even large and complex) parts of the plant that have been left unspecified to keep the example simple, so that they will not be dealt with in the following. The Process Network (PN), in particular, includes a PLC and a host running a supervision, control and data acquisition (SCADA) server (SS); the two nodes are connected through a switch (SPN). Physical ports of each device, as well as links, are also shown in the figure. Fig. 6 shows the description of the PLC object and the correspondence between the different elements and definitions introduced in Tables 9 and 10. The host is named PLC, it is located (contained) in room RPLC and equipped with just one wired physical port (no wireless extension is specified). The physical port id, data-link address and network address are ppPLC, MACPLC and IPPLC respectively. No account is defined on PLC, in fact many real-world PLCs still do not support such a feature even today. Moreover, three extended operations π★ are available, that is admin, run_part_program and upload_part_program respectively. A precondition f is specified for admin, stating that a physical access to the PLC is needed to carry out administrative tasks, but no credential is required to this purpose. This aspect (i.e., preventing the execution of administrative tasks on a PLC through network connections) is the only configurable mechanism of many real devices, which can be exploited for security purposes. Two preconditions, instead, are

Table 9 Implementation elements.

λ

::=

{idpp}

dlad nad pnd pr act

dest data link addr dest network addr dest port number protocol (TCP, UDP,…) action (allow or deny)

dOE

RE

RE: enterprise room (offices) RDMZ: demilitarized zone room

dEP

RPN

RPN: process network room RPLC

source physical port dest physical port source data link addr source network addr source port number

RO

RO: external environment

RDMZ

dPP

idpps idppd dlas nas pns

dED

dDP

(n, g) n and g represent a username and a group respectively; usernames and groups are linked through a many-to-many relation as usual   pp ::= idpp ; fhdla; fnag; ½w; ½c; fωˇ gig   fr ::= idpps ; idppd ; dlas ; nas ; pns ; dlad ; nad ; pnd ; pr; act

RPLC: PLC cabinet dXY: door between two rooms

Fig. 3. A simple plant topology.

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181

177

Fig. 4. Description of room objects for the plant of Fig. 3.

foreseen for both the run_part_program and upload_part_program operations. Actually, each operation can be carried out either by means of a physical access (i.e., through a local console) or remotely by connecting to the logical port named lpPLC. The lack of a port number (“−”) and protocol (“−”) in the description reflects the system configuration in some cases, but it could also mean that some configuration details are unknown, thus possibly leading to false positives when some policy violation is detected. In general, the default behavior taken by the tool when a required value is missed, is the worst one, i.e. the most conservative. As an example, a firewall without filtering rules is assumed it allow any kind of traffic. The unavailability of security mechanisms is taken into account by the absence of credentials in this case too. No filtering rules are associated to PLC since the device is not configured to provide switching capabilities. By contrast host SS, running the SCADA server and other applications, can support some kind of access right management and user authentication, so its description, shown in Fig. 7, is a bit more complex. The host identifier is SS, and it is located in room RPN and equipped with a physical port associated to the MACSS and IPSS addresses. Four accounts are configured for SS: jeff and jenny are usernames belonging to group je, jim belongs to group jm, while peggy is in group pe. It is worth reminding that the adoption of the same names used in the RBAC part of the model (S — see Tables 3–8) is not a theoretical constraint, but a pragmatic choice to enhance readability in this case, and to simplify the analysis of the model. A single extended operation π★ (login) is possible for SS, requiring a physical_access precondition and one of the four possible credentials (c je f f 1 , cjenny1 , c jim1 , cpeggy1 ) and enabling a player to log in on SS as jeff, jenny, jim or peggy.

ppSPN_R

Fig. 5. Network architecture.

PLC

Control Network and Field Area

ppPLC

SCADA Server SS ppSPN_U

ppss

SPN

DMZ

E

FW1

FW2

Process Network PN

An additional object is defined for system in Fig. 5, that is the data base application running on the SCADA server and formally described in Fig. 8 as object DB. Object DB is contained in SS in room RPN and provides three meaningful operations to the player: admin, read and write. All operations require the player to be already active on SS, since local_access 〈RPN, SS〉 is the only kind of precondition. The precondition is further constrained by either the username (e.g., peggy) or group (e.g., je) the player must belong to, besides owning suitable credentials. No filtering rules are associated to SS. Finally the description of switch SPN in Fig. 5 is given in the upper part of Fig. 9, which also shows the correspondence of elements to definitions in Tables 9 and 10. By assumption SPN is a very basic kind of switch, so that it has no extended operations associated and each physical port is completely described by the port id. Similarly, only the first two elements of each filtering rule are meaningful, while the other parameters have been left unspecified, because this is a very simple switch, and only the paths among physical ports can be specified. In order to complete the description D for the sample system, we need to build the set Λ as shown in the lower part of Fig. 9. The two sets in the figure takes into account the network links, connecting SS to SPN and PLC to SPN through their physical ports as shown in Fig. 5.

5.3. Computation of I The set I of Eq. (2) can be obtained by letting each player move around the system rooms, and carry out all possible operations πˇ on objects ωˇ , described in D (Eq. (4)). To this purpose, both a state for each player (keeping track of some facts about its activity) and a framework (i.e., a Labeled Transition System — LTS enabling each player to be active) are needed. The description of the player's state T pˇ is shown in Table 11: it includes the set LA of all local accesses (i.e. active loggedin conditions) already gained by the player, the current room reached by the player and the set of credentials he/she owns. Table 12 shows the players' initial states, T pˇ0 for the example system: the sets of local accesses are obviously empty, since all players are assumed to be in the external area RO of the plant in Fig. 3 at the beginning. Moreover, all players have credentials to cross dOE as well as dEP, whereas only Peggy owns credentials required to cross dED, dDP, and dPP. From Fig. 7, it is easy to see that cpeggy1 is needed to carry out the login operation successfully on object SS, gaining a local access to the same object with username peggy. The same holds for credentials c je f f 1 , cjenny1 , and c jim1 , and usernames jeff, jenny, and jim respectively. Fig. 8 also shows that credential cpeggy2 is needed to perform operations admin, read, and write on object DB by players that have already gained local access with username peggy to SS after performing a login action on it. The same is true for credentials c je f f 2 and cjenny2 and group je, with respect to the read and write operations.

178

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181

Fig. 6. PLC object — PLC.

Players, as shown in the following, cannot change the data model D and nobody can affect the behavior of other players through his/her actions. As a consequence, the set I can be computed incrementally by considering one player at a time in the system. To this purpose let us define    ω★ ⊢ðωˇ ; πˇ ; f Þ ::¼ ∃ω★ ∈ Ω ∃π★ ∈ ω★ : π★  ∃f ∈ π★ :f f g

  ″ 

0 ★ ˇ ˇ ˇ ˇ ω★ ωˇ s ≠ ωˇ d s ⊢ ðω s ; π s ; hd; fc giÞ ωd ⊢ ω d ; π d ; d; c ″ T ˇp :ωˇ ¼ ωˇ s c ¼ ∅ ∨ c″ ∩ T ˇp :C ≠ ∅      ðˇπd ;ωˇ d Þ D; T ˇp ↦ D; T ˇp :LA; ωˇ d ; T ˇp :C

ð11Þ

ð8Þ

  ω★ ⊢ðωˇ ; πˇ ; hd; fcgiÞ ::¼ ∃ω★ ∈ Ω j ∃π ★ ∈ ω★ : π ★  ∃hd; fcgi ∈ π ★ :fhd; fcgig

ð9Þ where πˇ ¼ π★ :πˇ and, in our case, ωˇ ¼ ω★ :ωid since ωid is enough to uniquely identify each object. 5.3.1. Labeled transition system The system description D and the player's state T ˇp allow to check whether the player can carry out the operation πˇ on object ωˇ or, more precisely, on object ω★, whose unique identifier is ωˇ . The LTS transitions can then be described by means of the following syntactical form:   ðπˇ ;ωˇ Þ   D; T pˇ ↦ D; T ˇ0p

The derivation rules are defined by Eqs. (11)–(18):

ð10Þ

where D is the fixed environment and T pˇ records the effect of the player's action, that is either a new room has been entered or a new local access has been acquired.

Rule (11) enables a player to cross a gate and move from one room ˇ s ) and ω★ ˇ d ), which share the to another. Given two rooms ω★ s (ω d (ω ★ ˇ same gate d, if ωs (ω s ) is the player's current room and either no credential is required or the player owns a right credential, then the ˇ s ) to ω★ ˇ d ) and his/her state is updated player moves from ω★ s (ω d (ω accordingly. ω★ ⊢ ðωˇ ; πˇ ; f Þ

″

T pˇ :ωˇ ¼ ω★ :ωid1

f ¼ physical access½c; ½ωˇ : n  c ∈ T pˇ :C   ðπˇ ;ωˇ Þ n o    ″ D; T pˇ ↦ D; T pˇ :LA ∪ ωˇ ; n″ ; T pˇ :ωˇ ; T pˇ :C ″

ð12Þ

Rule (12) enables a player to carry out the operation πˇ on object ωˇ , provided that the player and the object are in the same room (i.e., the most external of path objects, always a room, is the current player's room). The operation has physical_access as a precondition and the player owns the possible required credential. When this happens, the acquired local access, if any, is included in the new player's state. In fact, it is worth noting when the optional postcondition n″ is omitted in f, the player does not acquire any local access, and, consequently, no update occurs in the new player's state, i.e. T pˇ0 ¼ T pˇ . Moreover, when the optional credential c is omitted in f, the test c ∈ T pˇ :C becomes

Fig. 7. SCADA server object — SS.

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181

179

Fig. 8. Data base object — DB.

meaningless. This rule can be used, for instance, to model a login enabled from the system console: the player gains access to console, types the password in and is then logged as username n″. 0 0

ω ⊢ ðωˇ ; πˇ ; f Þ ωˇ ; n ∈ T pˇ :LA 0 ″ 0 ″ ˇ ˇ c ∈ T pˇ :C f ¼ local access ω : n ½c; ½ω : n    ðπˇ ;ωˇ Þ   n o  ″ D; T pˇ ↦ D; T pˇ :LA ∪ ωˇ ; n″ ; T pˇ :ωˇ ; T pˇ :C

in Eq. (16) returns true or false depending on whether or not the specified path is allowed by the network infrastructure ∃ pathðdlas ; pns ; nas ; dlad ; pnd ; nad ; pr; hωˇ ; C iÞ

ð16Þ

★

ð13Þ

Rule (13) enables a player, who has already acquired a local access 0 on object ωˇ with username n′, to carry out the operation πˇ on object ˇ ω , provided he/she owns the possibly needed credential c. The same comments as in rule (12) apply to n′ and c in this case too. This rule can be used, for instance, to describe the effect of the su command issued by an already logged user. 0 ω★ ⊢ ðωˇ ; πˇ ; f Þ ðn0 ; g 0 Þ ∈ ωˇ :fðn; g Þg 0 ″ f ¼ local access ωˇ : g0 ½c; ½ωˇ : n″ 



(



D; T pˇ

 ðπˇ ;ωˇ Þ

↦

   n o ″ ωˇ ; n″ ; T pˇ :ωˇ ; T pˇ :C D; T pˇ :LA ∪

ð17Þ ð14Þ

Rule (14) is very similar to rule (13), the only difference being in the precondition of f. In this case, in fact, the player's local access is constrained by the group g′ instead of username n′. This requires first 0 looking for an account on object ωˇ whose username is bound to group g′, and then checking whether the player has already gained a local access to the object by exploiting that username. In order to introduce derivation rules for managing network accesses, let us define   ω ⊢ dla; na ::¼

″ f ¼ remote access lpd ½c; ½ωˇ : n″  c ∈ T pˇ :C  0 0

0

 ★ ⊢ ðdlas ; nas Þ ωˇ ; n ∈T pˇ :LAωs ⊢ ωˇ ; ; ⊢ ð dla ω★ d ; lpd :naÞ  D d E ★ ∃ path dlas ; ; nas ; dlad ; lpd :pn; lpd :na; lpd :pr; ωs :ωid1 ; T pˇ :C

ω★ ⊢ ðωˇ ; πˇ ; f Þ d ω★ s

0 ωˇ ; n0 ∈ T pˇ :LA

c ∈ T pˇ :C   ðπˇ ;ωˇ Þ   n o  ″ D; T pˇ :LA ∪ ωˇ ; n″ ; T pˇ :ωˇ ; T pˇ :C D; T pˇ ↦

★

where the meaning of dlas, pns, nas, dlad, pnd, nad has already been introduced and explained in Table 9, whereas hωˇ ; C i are room id (ωˇ ) where the source host is, and (player's) credentials to access wireless networks (C) respectively.

   ★   ∃pp D ∈ω :fppg E pp ¼ idpp ; fhdla; fnag; ½⋯ig   : fa ; ½⋯ ∈ pp:fhdla; fnag; ½⋯ig ∧ na ∈ n fa dla; n

ð15Þ Eq. (15) returns a pair consisting of a datalink address dla and a network address na such that na is bound to dla for some physical port of ω★. According to the approach presented in [40], we also assume that the network reachability has already been computed and stored in a suitable database that can simply be queried. Thus the general query

Rule (17) enables the player to carry out the operation πˇ on object ωˇ by exploiting a network connection (remote access). The object ωˇ must support the activation of πˇ through a network connection to its logical port lpd (possibly requiring a credential c and assigning the player a ″ 0 local access on ωˇ with username n″). A source object ωˇ must also exist (with a physical port bound to a data-link address dlas, which in turn has to be bound to a network address nas), and the player has 0 already gained an active local access on ωˇ , besides a network path between the pair (dlas, nas) and lpd. In these conditions the player is 0

able to carry out πˇ on ωˇ by means of its active local access ωˇ ; n0 . ″ f ¼ remote access dlad ½c; ½ωˇ : n″  



 ★ ˇ0 0 0 ˇ ⊢ ðdlas ; Þ ω ; n ∈ T pˇ :LAωs ⊢ ω ; ;  D E c ∈ T pˇ :C ∃ path dlas ; ; ; dlad ; ; ; ; ω★ s :ωid1 ; T pˇ :C

ˇ ˇ ω★ d ⊢ ðω ; π ; f Þ ω★ s

  ðπˇ ;ωˇ Þ D; T pˇ ↦



   n o ″ D; T pˇ :LA ∪ ωˇ ; n″ ; T pˇ :ωˇ ; T pˇ :C

:

ð18Þ

Rule (18) is simpler than rule (17), since the network connection is allowed at the data-link level and the identification of proper addresses at the network level is no longer necessary. The set I can then be easily obtained by activating a player at a time and by applying the derivation rules (11)\\(18), paying attention not to generate the same state more than once.

Fig. 9. Object switch — SPN — and Λ.

:

180

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181 Table 13 S and I.

::=

ðLA; ωˇ ; C Þ LA ::= ωˇ C ::=

fðωˇ ; nÞg {c}

set of all player's local accesses player current room player's credentials

Table 13 summarizes both sets S and I for the sample system in Figs. 3 and 5. The two leftmost columns contain all the pairs (operation, object), specified one for each row. The symbol ◦ is used to show triples ^; ω ^ Þ of S. The ^; π ðpˇ ; πˇ ; ωˇ Þ belonging to I, whereas ⦁ is used for triples ðu upper half of the table describes elements of I that do not have any counterpart in S. In practice, triples in this part take into account system operations and objects that are not involved in the specification of the RBAC policies. The lower half of the table concerns pairs (π, ω) that can be found in both S and I. Cells containing ⦁ in the lower half of Table 13, also include a ◦ symbol and this means, in practice, that all the RBAC policies have been implemented in the physical system (if this were not true, we would have cells marked with ⦁ only). However, the overall situation is not completely satisfactory in the example, since this part of the table also includes four cells containing only the symbol ◦. Actually, the physical system allows both Jeff and Jenny to upload_part_program and run_part_program to the PLC, even though no explicit policy authorizes them to do so (this is a violation according to the kind of verification of our interest). This happens because these operations can be remotely invoked through a network connection without any kind of credential (see Fig. 6), so anybody, who is logged on a host able to reach PLC through the network such as SS (see Fig. 7), can connect to the PLC logical port. Of course, such a kind of comparison puts into evidence possible discrepancies between the Specification and Implementation but, in order to help fixing the detected problems, knowing the originating reasons is more than desirable. To this purpose, the LTS traces can be exploited to analyze the sequence of each player's actions. The basic labels of the LTS transitions can then be enriched with additional useful information (e.g. player's room, host where the player is logged on when a remote access is started, details of f) but this aspect is out the scope of this paper.

users/players P eggy Jim Jef f Jenny System only

T ˇp

System & RBAC

Table 11 Player's state T ˇp .

enter enter enter open login admin read write admin upload part program run part program

RO RE R DM Z R PN R P LC SS DB DB DB P LC P LC P LC

the set of policies defined at a higher abstraction level. Although these mechanisms can also be very poor, in principle, they are often the only element that can be leveraged to try setting up a satisfactory configuration of the system from the access control point of view. The model introduced in this paper has been developed bearing this basic aspect in mind. An automatic analysis tool, able to help with the policy design and check their correct implementation, has to be based on a system description capable of capturing the definition of high-level policies, on the one hand, but also a very large number of system implementation details, on the other hand. To the best of our knowledge, several other approaches appeared in the literature have dealt very extensively with the former aspect, but no attempt has been carried out, till today, to include also the description of the physical system in the model as we have done in our proposal. The model definition, however, is only the first necessary step of our work, which is focused on the development and experimentation of an automatic analysis tool for access policies in industrial environments. Ongoing activities, in fact, include the study of efficient analysis algorithms for verifying whether the specification part of the model correctly matches the implementation part and, finally, the enhancement of our automated analyzer prototype.

6. Conclusions and future work References The design and implementation of access policies in industrial networked systems demand for new techniques and automated tools able to cope with a number of characteristics, that are peculiar to most situations where a physical process or plant is interfaced, controlled and/or managed through a distributed ICT infrastructure. For instance, the difficulty or even impossibility to modify the architecture of the special-purpose hardware and software, that are frequently adopted in industrial systems, their real-time requirements and their long lifespan (i.e., decades) with respect to that of many IT technologies (i.e., few years) make appealing solutions, already developed and available in other application areas, hard to be applied also to industrial systems. A key point in designing and implementing the access policies correctly, in this case, is the ability to exploit the low-level security mechanisms, which are present in the industrial system, to support Table 12 Players' initial state. T 0Peggy

=

T 0Jim

=

T 0Jeff

=

T 0Jenny

=

 

∅; RO ; cdOE ; cdEP ; cdED ; cdDP ; cdPP ; cpeggy1 ; cpeggy2  

∅; RO ; cdOE ; cdEP ; c jim1  

∅; RO ; cdOE ; cdEP ; c je f f 1 ; c je f f 2  

∅; RO ; cdOE ; cdEP ; cjenny1 ; cjenny2

[1] M. Cheminod, I. Cibrario Bertolotti, L. Durante, P. Maggi, D. Pozza, R. Sisto, A. Valenzano, Detecting chains of vulnerabilities in industrial networks, IEEE Trans. Ind. Informat. 5 (2) (2009) 181–193, http://dx.doi.org/10.1109/TII.2009.2018627. [2] M. Lin, L. Xu, L.T. Yang, X. Qin, N. Zheng, Z. Wu, M. Qiu, Static security optimization for real-time systems, IEEE Trans. Ind. Informat. 5 (1) (2009) 22–37, http://dx.doi. org/10.1109/TII.2009.2014055. [3] W. Granzer, F. Praus, W. Kastner, Security in building automation systems, IEEE Trans. Ind. Electron. 57 (11) (2010) 3622–3630, http://dx.doi.org/10.1109/TIE. 2009.2036033. [4] T. Novak, A. Gerstinger, Safety- and security-critical services in building automation and control systems, IEEE Trans. Ind. Electron. 57 (11) (2010) 3614–3621, http://dx. doi.org/10.1109/TIE.2009.2028364. [5] G. Wang, J. Yu, Q. Xie, Security analysis of a single sign-on mechanism for distributed computer networks, IEEE Trans. Ind. Informat. 9 (1) (2013) 294–302, http://dx.doi. org/10.1109/TII.2012.2215877. [6] N. Liu, J. Chen, L. Zhu, J. Zhang, Y. He, A key management scheme for secure communications of advanced metering infrastructure in smart grid, IEEE Trans. Ind. Electron. 60 (10) (2013) 4746–4756, http://dx.doi.org/10.1109/TIE.2012.2216237. [7] D. He, C. Chen, S. Chan, J. Bu, L. Yang, Security analysis and improvement of a secure and distributed reprogramming protocol for wireless sensor networks, IEEE Trans. Ind. Electron. 60 (11) (2013) 5348–5354, http://dx.doi.org/10.1109/TIE.2012. 2218562. [8] M. Cheminod, A. Pironti, R. Sisto, Formal vulnerability analysis of a security system for remote fieldbus access, IEEE Trans. Ind. Informat. 7 (1) (2011) 30–40, http:// dx.doi.org/10.1109/TII.2010.2099233. [9] A. Carcano, A. Coletta, M. Guglielmi, M. Masera, I. Nai Fovino, A. Trombetta, A multidimensional critical state analysis for detecting intrusions in SCADA systems, IEEE Trans. Ind. Informat. 7 (2) (2011) 179–186, http://dx.doi.org/10.1109/TII.2010. 2099234.

I. Cibrario Bertolotti et al. / Computer Standards & Interfaces 42 (2015) 171–181 [10] E. Shakshuki, N. Kang, T. Sheltami, EAACK — a secure intrusion-detection system for MANETs, IEEE Trans. Ind. Electron. 60 (3) (2013) 1089–1098, http://dx.doi.org/10. 1109/TIE.2012.2196010. [11] M. Cheminod, L. Durante, A. Valenzano, Review of security issues in industrial networks, IEEE Trans. Ind. Informat. 9 (1) (2013) 277–293, http://dx.doi.org/10. 1109/TII.2012.2198666. [12] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman, Role-based access control models, IEEE Comput. 29 (2) (1996) 38–47, http://dx.doi.org/10.1109/2.485845. [13] ANSI, INCITS 359-2012, Role Based Access Control, 2012. [14] M. Cheminod, L. Durante, L. Seno, A. Valenzano, Automated analysis of access policies in industrial plants, Proc. of the 2nd Int. Symp. for ICS & SCADA Cyber Security Research, ICS-CSR 2014, pp. 43–52, http://dx.doi.org/10.14236/ewic/ics-csr2014.6. [15] M. Cheminod, L. Durante, L. Seno, A. Valenzano, On the description of access control policies in networked industrial systems, Factory Communication Systems (WFCS), 2014 10th IEEE Workshop on, 2014 2014, pp. 1–10, http://dx.doi.org/10.1109/ WFCS.2014.6837594. [16] A. Valenzano, Industrial cybersecurity: improving security through access control policy models, IEEE Ind. Electron. Mag. 8 (2) (2014) 6–17, http://dx.doi.org/10. 1109/MIE.2014.2311313. [17] M. Cheminod, L. Durante, L. Seno, A. Valenzano, Semi-automated check of access policy implementation in industrial networked systems, 2015. (submitted for journal publication). [18] S. Jha, N. Li, M. Tripunitara, Q. Wang, W. Winsborough, Towards formal verification of role-based access control policies, IEEE Trans. Dependable Secure Comput. 5 (4) (2008) 242–255, http://dx.doi.org/10.1109/TDSC.2007.70225. [19] Y. Sun, Q. Wang, N. Li, E. Bertino, M. Atallah, On the complexity of authorization in RBAC under qualification and security constraints, IEEE Trans. Dependable Secure Comput. 8 (6) (2011) 883–897, http://dx.doi.org/10.1109/TDSC.2010.55. [20] F. Alberti, A. Armando, S. Ranise, Efficient symbolic automated analysis of administrative attribute-based RBAC-policies, Proc. of the 6th ACM Symp. on Information, Computer and Communications Security, ASIACCS 2011, pp. 165–175, http://dx. doi.org/10.1145/1966913.1966935. [21] K. Jayaraman, V. Ganesh, M. Tripunitara, M. Rinard, S. Chapin, Automatic error finding in access-control policies, Proc. of the 18th ACM Conf. on Computer and Communications Security, CCS 2011, pp. 163–174, http://dx.doi.org/10.1145/ 2046707.2046727. [22] G. Hughes, T. Bultan, Automated verification of access control policies using a SAT solver, Int. J. Softw. Tools Technol. Transfer 10 (6) (2008) 503–520, http://dx.doi. org/10.1007/s10009-008-0087-9. [23] D. Basin, M. Clavel, J. Doser, M. Egea, Automated analysis of security-design models, Inf. Softw. Technol. 51 (5) (2009) 815–831, http://dx.doi.org/10.1016/j.infsof.2008. 05.011. [24] G. Faden, RBAC in UNIX administration, Proc. of the 4th ACM Wksp. on Role-based access control, RBAC 1999, pp. 95–101, http://dx.doi.org/10.1145/319171.319180. [25] V.C. Hu, E. Martin, J. Hwang, T. Xie, Conformance checking of access control policies specified in XACML, Proc. of the 31st IEEE Annual Int. Computer Software and

[26]

[27]

[28]

[29]

[30] [31]

[32]

[33]

[34]

[35]

[36] [37] [38]

[39]

[40]

181

Applications Conf., Vol. 2 of COMPSAC 2007, pp. 275–280, http://dx.doi.org/10. 1109/COMPSAC.2007.96. K. Fisler, S. Krishnamurthi, L.A. Meyerovich, M.C. Tschantz, Verification and changeimpact analysis of access-control policies, Proc. of the 27th ACM Int. Conf. on Software Engineering, ICSE 2005, pp. 196–205, http://dx.doi.org/10.1145/1062455. 1062502. A. Masood, A. Ghafoor, A. Mathur, Conformance testing of temporal role-based access control systems, IEEE Trans. Dependable Secure Comput. 7 (2) (2010) 144–158, http://dx.doi.org/10.1109/TDSC.2008.41. T.L. Hinrichs, D. Martinoia, W.C. Garrison, A.J. Lee, A. Panebianco, L. Zuck, Application-sensitive access control evaluation using parameterized expressiveness, Proc. of the 26th IEEE Symp. on Computer Security Foundations, CSF 2013, pp. 145–160, http://dx.doi.org/10.1109/CSF.2013.17. A. Cau, H. Janicke, B. Moszkowski, Verification and enforcement of access control policies, Form. Methods Syst. Des. 43 (3) (2013) 450–492, http://dx.doi.org/10. 1007/s10703-013-0187-3. http://www.skyboxsecurity.com. D.M. Nicol, W.H. Sanders, S. Singh, M. Seri, Usable global network access policy for process control systems, IEEE Secur. Priv. 6 (6) (2008) 30–36, http://dx.doi.org/10. 1109/MSP.2008.159. D.M. Nicol, W.H. Sanders, M. Seri, S. Singh, Experiences validating the access policy tool in industrial settings, Proc. of the 43rd IEEE Hawaii Int. Conf. on System Sciences, HICSS 2010, pp. 1–8, http://dx.doi.org/10.1109/HICSS.2010.194. H. Okhravi, R.H. Kagin, D.M. Nicol, PolicyGlobe: A Framework for Integrating Network and Operating System Security Policies, Proc. of the 2nd ACM Wksp. on Assurable and usable security configuration (SafeConfig), SafeConfig 2009, pp. 53–62, http://dx.doi.org/10.1145/1655062.1655074. N. Li, J.-W. Byun, E. Bertino, A critique of the ANSI standard on role-based access control, IEEE Secur. Priv. 5 (6) (2007) 41–49, http://dx.doi.org/10.1109/MSP.2007. 158. D.F. Ferraiolo, R.D. Kuhn, R.S. Sandhu, RBAC standard rationale: comments on “a critique of the ANSI standard on role-based access control”, IEEE Secur. Priv. 5 (6) (2007) 51–53, http://dx.doi.org/10.1109/MSP.2007.173. E.J. Coyne, T.R. Weil, ABAC and RBAC: scalable, flexible, and auditable access management, IT Prof. 15 (3) (2013) 14–16, http://dx.doi.org/10.1109/MITP.2013.37. D.R. Kuhn, E.J. Coyne, T.R. Weil, Adding Attributes to Role-Based Access Control, IEEE Comput. 43 (6) (2010) 79–81, http://dx.doi.org/10.1109/MC.2010.155. V.H. HU, D. Ferraiolo, D.R. Kuhn, A. Schnitzer, K. Sandlin, R. Miller, K. Scarfone, Guide to Attribute Based Access Control (ABAC) Definitions and Considerations, NIST SP 800-162, 2014.http://dx.doi.org/10.6028/NIST.SP.800.162. S. Osborn, R. Sandhu, Q. Munawer, Configuring role-based access control to enforce mandatory and discretionary access control policies, ACM Trans. Inf. Syst. Secur. 3 (2) (2000) 85–106, http://dx.doi.org/10.1145/354876.354878. A. Liu, A. Khakpour, Quantifying and verifying reachability for access controlled networks, IEEE/ACM Trans. Networking 21 (2) (2013) 551–565, http://dx.doi.org/ 10.1109/TNET.2012.2203144.