Critical Infrastructures Governance Exploring SCADA Cybernetics through Architectured Policy Semantic Djamel Khadraoui and Christophe Feltus Service Science and Innovation, Public Research Centre Henri Tudor 29, avenue John F. Kennedy L-1855 Luxembourg-Kirchberg, Luxembourg
[email protected] Abstract — SCADA-systems are very complex, sophisticated and integrated systems which support people in monitoring and governing the huge volumes of knowledge engendered by critical infrastructures (industry, energy, transport, and healthcare). These systems are elaborated upon a colossal range of precontrived components which need to interact thoroughly with each other although, a priori, they all use heterogeneous technologies and protocols, they behave unevenly through the SCADA architecture, and they are all located in miscellaneous corners of the production system. Furthermore, these components interact, amongst other, by means of policies which formulate the reasoning for component behaviour in terms of expecting actions realization or in terms of accessed information. This paper explores these policies’ semantic through a unified component modelling approach with the aim of providing a homogeneous and coherent framework, adapted for the governance of the system by all SCADA and non-SCADA operators. Keywords — Policy management; SCADA system; architecture; IS security; critical infrastructure.
I.
INTRODUCTION
1
SCADA systems are very complex, sophisticated and integrated systems which support people in monitoring and governing the huge volumes of knowledge engendered by critical infrastructures (CI – in industry, energy, transport, and healthcare) [1]. In our previous work, we have defined a metamodel for the components of the SCADA architecture [2]. This metamodel has been elaborated acknowledging traditional enterprise architecture metamodel (EAM) and it allows modelling each component according to a similar structure. This structure proposes a representation of the latter based on a three layered perspective, namely: the organization layer, the application layer and the technical layer [4, 5]. Contrary to traditional EAM, one particular aspect of the metamodel elaborated for SCADA’s components is that it is enriched with the concept of policy at the two upper architecture layers, thereby making it possible to elicit organizational policies and application policies [2]. Depicting SCADA systems allows acknowledging the wide range of components which compose it [6], like for instance: the remote terminal unit (RTU), the intrusion detection system (IDS), the monitoring tools, the honeypots, and so forth. These components need to interact with each other and therefore, it is fundamental to have the system supported by accurate and 1
Supervisory Control and Data Acquisition
perfectly integrated policies. Indeed, when for instance, a monitoring system detects an intrusion, it requests the firewall to adapt the filtering policy to face this intrusion. This requirement for adaptation is achieved by a filtering policy modification, induced by the monitoring tool. Another example is the alert correlation performed by a correlation engine. The homology is achieved according to the correlation policy which receives alerts from different network sources and which, based on the correlation policy, generates a new policy at the destination of the protection mechanisms such as the access right manager, the server, and so forth. In this context, the amount of generated policies is very important. Their elaboration is based on different (meta-) models [7] which have different semantics (intrusion detection, alert correlation, reaction, access control, etc. [8]), and that are activated at different layers of the network (organizational, application or technical policies). The objective of this work is to support the SCADA manager and human operators with an integrated approach for designing, managing and monitoring SCADA systems policies. To that end, we propose a solution which consists in modelling each SCADA component based on the SCADA metamodel, to elaborate the connections between the SCADA components’ instances, and to define the policy acknowledging the information in input, the expected format of the outlay policy, and the operational rules. This paper is organized as follows. In the next section, we propose a synthetic review of the SCADA metamodel, in Section III, we highlight how a policy may be easier engineered following components’ instances and how a policy monitoring solution may concretely benefit the SCADA operators and managers. Afterwards we provide a case study extracted from [15] and finally, we describe the main related work and conclude the paper. II.
SCADA METAMODEL BACKGROUND
This section recalls our previous work in the field of SCADA system modelling. We first introduce the SCADA metamodel, followed by the SCADA modelling layers. A. SCADA metamodelling insights Our goal in modelling the SCADA system into a layered architecture metamodel is to provide CI operators with the tools for governing SCADA systems (monitoring and decision making). In previous works [2], we have elaborated such a SCADA metamodel based on the ArchiMate® language to give a multiple layered view of a SCADA component using policies. To generate the latter, we realized a specialization of the original ArchiMate® metamodel for SCADA components.
Firstly, we redefined the Core of the metamodel in order to figure out the concept of the Policy (Fig. 1.). The Core represents the handling of Passive Structures by Active Structures during the realization of Behaviours. For the Active Structures and the Behaviour, the Core differentiates between external concepts, which represent how the architecture is being perceived by the external components (as a Service Provider attainable by an Interface), and the internal concept which is composed of Structure Elements (Roles, Components) and linked to a Policy Execution concept. Passive Structures contains Object (e.g. data and organizational object) which represents architecture knowledge. Secondly, the concept of Policy was defined in accordance to the SCADA metamodel. The proposed representation is composed of three elements defining the Policy: 1. “Event” is defined as something done by a Structure Element which generates the execution of a Policy. 2. “Context” symbolizes a configuration of Passive Structure that allows the Policy to be executed (e.g. a security level or the value of an object). 3. “Responsibility” [9, 10] is defined as a state assigned to an agent (human or software) to specify obligations and rights in a specific context [2]. Thereby, responsibilities correspond to a set of behaviours that have to be performed by Structure Elements. This behaviour can use Object from Passive Structure or modify values. With these three elements, we generate an auxiliary Policy artefact mirroring the execution of a set of Responsibilities in a specific Context and in response to a determined Event. Concepts and colours were taken from the original ArchiMate® metamodel, except for Organizational Function and the Application Function which were replaced by the Organizational Policy concept and the Application Policy concept. Through the Policy Concept, we show that each operation done by the SCADA components can be transferred into a Policy Execution. Although there is a semantic difference in ArchiMate® between the application and the user who exploits the application, in the SCADA domain, we consider that actors and roles are played by components that we define as being specific Structure Elements acting in CI context. Hence, three layers structure the metamodel for the SCADA components: 4. The Organizational Layer offers products and services to external customers, which are realized in the organization by organizational processes performed by Organizational Roles according to Organizational Policies. 5. The Application Layer supports the Organizational Layer with Application Services which are realized by Applications according to Application Policies. 6. The Technology Layer offers Infrastructure Services needed to run applications, realized by computer and communication hardware and system software. Based on this analysis, we had defined the Organizational Policy as the rules which define the organizational responsibilities and govern the execution of behaviours, at the organization domain, that serve the product domain in response to a process domain occurring in a specific context,
which is symbolized by a configuration of the information domain. And we defined the Application Policy as the rules that define the application responsibilities and govern the execution, at the application domain, of behaviours that serve the data domain to achieve the application strategy. B. SCADA metamodel layers The three layers which structure the SCADA metamodel (Fig. 1) are the Organizational, Application and Technical Layers: The Organizational Layer highlights the organizational processes and their links to the Application Layer. At first the Organizational Layer is defined by an Organizational Role (e.g. Alert Detection Component). This role, accessible from the outside through an Organizational Interface, performs behaviour on the basis of the organization's policy (Organizational Policy) associated with the role. Then, the component is able (depending on its role) to interact with other roles to perform behaviour; this is symbolized by the concept of Role Collaboration [2]. Organizational Policies are behavioural components of the organization whose goal is to achieve an Organizational Service to a role following Events. Organizational Services are contained in Products accompanied by Contracts. Contracts are formal or informal specifications of the rights and obligations associated with a Product. Values are defined as an appreciation of a Service or a Product that the Organization attempts to provide or acquire. The Organizational Objects define units of information that relate to an aspect of the organization. The Application layer is used to represent the Application Components and their interactions with the Application Service derived from the Organizational Policy of the Organizational Layer. The concept of the components in the metamodel is very similar to the components concept of UML [11] and allows representing any part of the program. Components use Data Object which is a modelling concept of objects and object types of UML. Interconnection between components is modelled by the Application Interface in order to represent the availability of a component to the outside [2] (implementing a part or all of the services defined in the Application Service). The concept of Collaboration from the Organizational Layer is present in the Application Layer as the Application Collaboration and can be used to symbolize the cooperation (temporary) between components for the realization of behaviour. Application Policy represents the behaviour that is carried out by the components. The Technical Layer is used to represent the structural aspect of the system and highlights the links between the Technical Layer and the Application Layer and how physical pieces of information called Artefacts are produced or used. The main concept of the Technical layer is the Node which represents a computational resource on which Artefacts can be deployed and executed. The Node can be accessed by other Nodes or by components of the Application Layer. A Node is composed of a Device and a System Software [4]. Devices are physical computational resources where Artefacts are deployed when the System Software represents a software environment for types of components and objects.
Communication between the Nodes of the Technology Layer is defined logically by the Communication Path and physically by the Network. The complete SCADA metamodel is the union of the three layers. As shown below, new connections between the layers have appeared. For the Passive Structure we observe that Artefact of the Technical Layer realizes Data Object of the Application Layer which, itself, realizes Organizational Object of the Organizational layer.
Application Domain in a configuration of the Data Domain. UML provides support for modelling the behaviour performed by the Application Domain as Sequence Diagram. Configuration of the Data Domain can be expressed as Preconditions of the Sequence Diagram and symbolized by the execution of a test-method on the lifeline of the diagram. III.
POLICY ENGINEERING
To engineer the SCADA policies, two steps are necessary. The first one concerns the modelling of each SCADA component according to the metamodel. The second one concerns the detection and identification of the connections amongst each composing artefact of the component models. A. SCADA metamodel instance per component This first step aims at providing the SCADA operators and managers with a holistic and integrated view of the SCADA architecture building blocks. To that end, the SCADA metamodel is instantiated for each architecture component. This step is achieved by shaping the component according to the three abstractions typically advocated by the enterprise architecture paradigm. This step allows discovering the building artefacts of the components as well as the connections amongst the components artefacts. This unified representation of each component implies paramount outcomes for the SCADA operator since it confers to the latter a global functional insight of each component irrespective of any implementation or vendors’ influence.
Figure 1: Three layers of SCADA system metamodel extracted from [2]
The Behaviour element connections show that the Application Service uses the Organizational Policy to determine the services which it proposes. In the same way, the Technical Layer bases its Infrastructure Service upon the Application Policy of the Application Layer. Concerning the Active Structure connections, the Role concept determines, along with the Application Component, the Interface provided in the Application layer. The Interface of the Technical Layer is also based on the components of the Application Layer. C. Policy modelling In the Organizational Layer, Organizational Policy can be represented as an UML Use Case [11] where concepts of Roles represent the Actors which have Responsibilities in the Use Case, and the Collaboration concepts show the connections between them. Concepts of Products, Value and Organizational Service provide the Goal of the Use Case. Pre- and Post-conditions model the context of the Use Case and are symbolized in the metamodel by the Event concept (pre-condition) and the Organizational Object (pre-/postcondition). In the Application Layer, Application Policy is defined as the realization of Responsibilities by the
B. Policy semantic investigation The unitary SCADA component models are used in the second step to picture the global structure of the SCADA architecture and of the connections, in terms of policies, amongst the components of the architecture. Fig. 2 highlights the two types of policies recovered in SCADA architecture: 1) Cognitive Policy Cognitive Policies [12] are represented in blue in Fig. 2. They represent policies which govern the behaviour of one artefact of the component architecture. This policy specifies the rule that the Responsible artefact needs to follow for the execution of a defined activity in a specific execution context. This rule is dictated by the artefact which exists in the same component or in another one. The artefact which generates the policy is the Master artefact and the one which execute it is the Slave artefact. The Cognitive Policy morphology is articulated on the following set of attributes (perceived by [13]): Master artefact, Slave artefact, Master component, Slave component, Behaving rule, Trigger item, Usage context, Priority extension (Table I). Table I. Cognitive policy attributes’ name and attributes’ ID Attribute Name
Attribute’s ID
Master artefact Salve artefact Master component Slave component Behaving rule Trigger item Usage context Priority extension
CP-Ma-art CP-S-art CP-Ma-Com CP-S-Com CP-Ru CP-TI CP-UC CP-prior
The application schema of a CP, as presented in Fig. 2, obeys the two following controls: (1) the communication path is from a Master structural concept to a Slave behavioral concept or (2) the communication path is from a Master behavioural artefact to another Slave behavioural artefact.
Therefore, we describe the case study, we elaborate its building blocks and we discuss the issues. A. Description of the case study Fig. 3 introduces the generic building blocks of a SCADA architecture. This architecture receives input from distributed probes (I/O from RTU and PLC) and SCADA adaptors, provides outputs (using a View node visualization system) to the incident team, and is refined according to new findings by the Cyber Control Room (CCR). Our approach is illustrated by three blocks selected according to [17]: the Detection Correlation, the Online Cyber Analysis and the Visualization System.
Figure 2. Two types of policy for SCADA. CP in blue and PP in red.
1) Permissive Policy Permissive Policies are represented in red in Fig. 2. They represent policies which govern the knowledge acquisition rules from the Master to the Slave artefact [14]. This knowledge acquisition traditionally takes the form of SCADA states data accessed or provided in order to provide the Responsible with the access (of in, out, in_out types [16]) to successive Cognitive Policies in case of occurring events. The Permissive Policies morphology is articulated on the following set of attributes [perceived by [15]): Master artefact, Slave artefact, Master component, Slave component, Permission rules, Pre-permission conditions, Master permission cardinality, Slave permission cardinality, and Cognitive constraints (Table II) - sustained by Cognitive Policy states). Table II. Permissive Policy attributes’ name and attributes’ ID Attribute Name
Attribute ID
Master artefact Slave artefact Master component Slave component Permission rules Permission conditions Master permission cardinality Slave permission cardinality Cognitive constraints
PP-Ma-art PP-S-art PP-Ma-Com PP-S-Com PP-Ru PP-Condi PP-Ma-Car PP-S-Car PP-Co.con.
The application schema of a CP, as highlighted in Figure 2, obeys the two following controls: (1) the communication path is from a Master structural artefact to a Slave informational artefact or (2) the communication path is from a Master behavioural artefact to a Slave informational artefact. IV. USE CASE To illustrate CP and PP in SCADA architecture and their visualization impact on the CI governance by the SCADA operator, we exploit the SCADA model from the [15].
Figure 3. Building blocks of the SCADA system extracted from [15]
1) Detection correlation Detection and cyber detection (DCD) [19] compose the skeleton of the detection correlation mechanism which supports the SCADA environment. Mainly three security zones constitute the source of classified knowledge for this DCD, namely, the corporate networks, the CI, and the field of correlation that constitutes the input from distributed sensors. The fields are architecture-based on traditional and specific components from SCADA networks, to know: IDS, Honeypots, Anti-Virus, and RTU’s mirror. DCD performs a correlation based on low validated alerts/events aggregation (true-positive detections [20]) to higher validated alerts. As highlighted in Fig. 3, cyber threat and security propagation models support the correlation mechanism by allowing analyzing and detecting suspicious signatures and suspicious behaviours to issue a set of Detected Cyber Parameter (DCP). 2) Online cyber analysis The Online Cyber Analysis (OCA) module [21] acts as the heart of the SCADA schema, since it supports the definition of the Refined Cyber Parameters provided to the Cyber Simulator. OCA receives as input the DCP from the DCD on the one hand, and the data from the analysis tools on the other hand. The Cyber-physical Events are correlated amongst this DCD and the Operative Level Analysis module (which we
have decided not to model in this paper since it semantically acts as the OCA at an operative level). 3) Visualization system The Visualization System is an extensive module pictured by a hexagon symbol and acts as an ultimate SCADA Vector of Communication for the support of the Incident Team [22]. As depicted in Fig. 3, the input of the Visualization System is
extracted from three fundamental building blocks: the Risk Evaluation, the Automatic Countermeasures Selection and the Service Simulator - concatenate data from OCA (and the Operative Level Analysis) - by means of the Cyber Simulator. The Visualization System supports the SCADA Operators and Incident Manager, and extensions are possible towards any ICT Operators.
Figure 4. SCADA architecture extracted from [15] focussed on detection correlation, online cyber analysis and visualization system
B. Building blocks modelling Fig. 4 illustrates the holistic representation of the SCADA components realized by the two steps of the policy engineering schema. In this figure, we focus on three blocks advocated by [17] cyber detection/correlation, online cyber analysis and visualization system. Four additional blocks have been partially incorporated to support the case description: IDS, Honeypot, Operative Level Analysis, and the CI. In this model, we have afterwards considered the CP and PP amongst artefacts, respectively in blue and in red. Finally, these policies have been reformulated according to the syntax policy attributes from Table I and II, such as motivated by [2]. The DCD is modeled on the left size of Fig. 4 and is associated through two PPs with the IDS and the honeypots, respectively, by the Detection Module and the Correlation Application. The Alert Detection DB Slave Artifact at the application layer is
determined, in turn, by the Analytical Function Policy Master artefact (illustrated in Table III using data from [2]) from the Online Cyber Analysis module. The OCA module is the central part of Fig. 4 and acts as a facilitator building block between the DCD and the Visualization System. The Confirmed Alert data object from its application layer acts as a Slave artifact associated with the Visualization Policy. Hence, this latter is logically of a permissive type and is bound to the Visualization Policy/Service master artefact. Moreover, three CP are associated to this artefact. The two first are related to the IDS Application and Honeypot Application (which are of Slave type – read access allowed) and the latter is directed towards the Visualization Policy/Service (which is of Master type – write access allowed). Finally, the last module of Fig. 4 is the Visualization System. This latter is sustained by a Slave type CP towards the CI Operators, and by a master type PP towards the CI Nodes.
Table III. CP instantiation for the Analytical function policy master artifact Attribute ID
Attribute Name
CP-Ma-art CP-S-art CP-Ma-Com CP-S-Com CP-Ru
Organization policy/Service (pII2) Alert/Detection Database (DB a.dd) ONLINE CYBER ANALYSIS CYBER DETECTION AND CORRELATION Policy:: pII2, DB a.dd, if Act1On=3 than DB upgrade field DB a.add correlation list else unchange Probs’ flg activate (Act3On) Any time, sector covered plant 2. Probs’ priority (From Act1 to Act9)
CP-TI CP-UC CP-prior
V.
VI.
CONCLUSIONS
The huge amount of information managed by CI argues for the support of cybernetic SCADA which behaves as a very complex and sophisticated system. This later supports human operators in monitoring and governing the system security by elaborating the operational policies amongst the architecture components. This paper explores the usage of EAM to construct an integrated SCADA metamodel dedicated to these components’ artefacts and structured according to (1) three layers of abstraction, namely: Organization, Application, and Technical layer and (2) two semantically consistent types of policies: the Permissive Policy and the Cognitive Policy. The results of the SCADA modelling and policy engineering approach constitute, as illustrated by the case study, a global analytical tool for the SCADA operators which rely on a rational and unified component security based architecture to continuously monitor and manipulate the policy attributes acknowledging their impact on the whole CI system. ACKNOWLEDGMENT The research is funded by the CockpitCI project within the 7th framework Programme of the European Union (topic SEC2011.2.5-1 – Cyber-attacks against critical infrastructures). REFERENCES
[2]
[4] [5]
[6]
[7]
RELATED WORKS
The main related work consists in a framework for assessing the maintainability using EAM proposed by [23] which sustains flexible systems maintenance by supporting the SCADA operators to assess the management of the architecture. In line with EAM, [24] provides a solution to develop and adapt the security analysis framework for the architectural language and [25] refines the monitoring paradigm using EAM. [26] tackles the visualization through real-time SCADA and very large-scale integration (VLSI) monitoring interface, such as underlined by [27]. Cyber security policy has been reviewed by [3] who summarizes cyber security problems and the possible existence of vulnerabilities. This was correlated by [17, 19 and 20] who strengthen new policy EAM based on modelling needs as well as on bound exploitation perspectives.
[1]
[3]
Briesemeister, L., et al. Detection, correlation, and visualization of attacks against critical infrastructure systems, 8th PST, 2010, Canada. Blangenois, J., Guemkam, G., Feltus, C., Khadraoui, D., Organizational Security Architecture for Critical Infrastructure, 8th International Workshop on Frontiers in Availability, Reliability and Security, ARES 2013, Regensburg, Germany
[8] [9]
[10]
[11] [12]
[13] [14] [15] [16] [17]
[18]
[19]
[20]
[21]
[22]
[23]
[24] [25] [26] [27]
Tan, S. Electric Power Automation Control System Based on SCADA Protocols. Proceedings of the International Conference on Information Engineering and Applications (IEA) 2012. Springer London, 2013. Lankhorst, M. ArchiMate language primer, 2004. Zachman, J. A. 2003. The Zachman Framework For Enterprise Architecture: Primer for Enterprise Engineering and Manufacturing. Engineering, no. July: 1-11. Li, D., Serizawa, Y., Kiuchi, M. Concept Design for a Web Based Supervisory Control and Data-Acquisition (SCADA) System, IEEE PES Transmission and Distribution Conference, Yokohama, 2002, pp. 32-36. Baskerville, R., Siponen, M. (2002). An information security meta-policy for emergent organizations. Logistics of Information Management, 15(5/6) pp. 337-46. Chang, D., Patra, A., Bagepalli, N., et al. Zone-Based Firewall Policy Model for a Virtualized Data Center. U.S. Patent No 20,130,019,277. Guemkam, G., Feltus, C., Bonhomme, C., Schmitt, P., Khadraoui, D., Guessoum, Z. Reputation based Dynamic Responsibility to Agent for Critical Infrastructure, IEEE/WIC/ACM International Conference on Intelligent Agent Technology, 22-27/8/2011, Lyon, France. doi>10.1109/WI-IAT.2011.194 Bonhomme, C., Feltus, C., Khadraoui, D. Dynamic Responsibilities Assignment in Critical Electronic Institutions - A Context-Aware Solution for in Crisis Access Right Management, ARES 2011, Vienna, Austria. DOI: 10.1109/ARES.2011.43 UML 2 ( http://www.uml.org/) Xu, W., Zhang, X., and Jahn, G. Towards system integrity protection with graph-based policy analysis. In : Data and Applications Security XXIII. Springer Berlin Heidelberg, 2009. p. 65-80. Doherty et al.. (2009). The information security policy unpacked: A critical study of the content of university policies. IJIM 29(6) Barth, A et al. (2009). Securing frame communication in browsers. Communications of the ACM, 52(6), pp. 83-91. Nicholson, A. et al. (2012) SCADA security in the light of CyberWarfare. Computers and Security , 31 (4), pp. 418-436. Maj, S. P., Makasiranondh, W., & Veal, D. (2010). An Evaluation of Firewall Configuration Methods. IJCSNS, 10(8), 1. Briesemeister, L., Cheung, S., Lindqvist, U., & Valdes, A. (2010, August). Detection, correlation, and visualization of attacks against critical infrastructure systems. In Privacy Security and Trust (PST), 2010 Eighth Annual International Conference on (pp. 15-22). IEEE. Rakocevic, V., et al. Computational intelligence in a real-time SCADA system to monitor and control continuous casting of steel billets. Systems, Man and Cybernetics, 1995. IEEE, Vol. 2. Daryabar, F., et al., Towards secure model for SCADA systems, International Conference on Cyber Security, Cyber Warfare and Digital Forensic (CyberSec), 2012 60, 64, 2012. Gill, R., Smith, J., & Clark, A. (2006, January). Experiences in passively detecting session hijacking attacks in IEEE 802.11 networks. In Proceedings of the 2006 Australasian workshops on Grid computing and e-research-Volume 54 (pp. 221-230). Australian Computer Society, Inc. Fink, G. A., et al. Visualizing cyber security: Usable workspaces. Visualization for Cyber Security, 2009. VizSec 2009. 6th International Workshop on. IEEE, 2009. Kitamura, M., Kojima, T., & Nishida, S. (2006). SCADA Data Visualization Using Equipment Graphs. IEEE Transactions on Electronics, Information and Systems, p. 126, pp.788-796. Lagerström, R. Analyzing system maintainability using enterprise architecture models. Proceedings of the 2nd Workshop on Trends in Enterprise Architecture Research (TEAR 2007). Ekstedt, M., Sommestad, T., Enterprise architecture models for cyber security analysis, PSCE '09. IEEE/PES, 1,6, 15-18 March 2009 Stanescu, A. M. et al. Supervisory control and data acquisition for virtual enterprise, IJPR, Vol. 40, Iss. 15, 2002. Qiu, B., et al. "Internet-based SCADA display system." Computer Applications in Power, IEEE 15.1 (2002): pp. 14-19. Constantinescu, C. Trends and challenges in VLSI circuit reliability. Micro, IEEE 23.4 (2003): pp. 14-19.
