• No results found

7 ICS cyber security: modelling techniques and tools

7.6 Composite heterogeneous methods

7.6.2 Holistic reductionist method

The Mixed Holistic Reductionist approach (MHR in Figure 7.10) [67,93] is made by two layers. The first one (upper) is obtained considering each infrastructure as a whole and evaluating the impact of faults or services using domain simulators. We called this layer “holistic situation assessment”. The second (lower)can be considered a reductionist impact assessment layer that is build of experts re-views and try to assess interdependencies and how faults and their consequences are reflected on other facilities.

Ref. CockpitCI-D2.1-Overview of modelling techinques and tools for SCADA systems under attacks.docx

Final version Page 100 on 153

Figure 7-10 MHR model

This approach tries to guide experts in order to consider several events and not only the simple mechanical faults. In fact, in large plant, the simple physical security is not enough to protect critical infrastructures. The physical security must be assess together with cyber vulnerabilities and threats and integrating outputs of firewalls, Intrusion Detection Systems (IDS) and also information coming from national agencies and international institutions, in order to provide business continuity and the best Quality of Service (QoS) towards customers.

The definition of the term holistic is characterized by the comprehension that the parts of some-thing are intimately interconnected and explicable only by reference to the whole. In the field of Critical Infrastructure protection, evaluating faults inside the facilities where they are born using CI-related tools is a holistic point of view.

Using such point of view, a situation assessment can be realized considering several technological and organizational aspects and usually using techniques and methods specific of each facility. In the following Sections, some particular events/infrastructures will be described/analysed to better under-stand the holistic impact evaluation:

Managing of alarms, usually collected using SCADA (Supervisor Control And Data Acquisition) software and then shown to operators in order to support decisions; − Managing of physical security information, for detecting unauthorized accesses to

specific areas, using also data mining algorithms;

Evaluation of the Quality of Services (QoS) toward customers of the infrastructure, using simulator for analysing transients and outages after the faults [96, 97], like load-flow simulation for power grids or NS-2 for telecommunication networks;

Detection/spreading of cyber attacks, especially worms and viruses spreading, as Red-Code [68], Stuxnet [21] or Duqu [22] worm, through mathematical representation, such as the two-factor models;

Use of information coming from international and national agencies, like CERTs and

other institutions, to integrate cyber-related data coming out from other infrastructures.

Ref. CockpitCI-D2.1-Overview of modelling techinques and tools for SCADA systems under attacks.docx

Final version Page 101 on 153

The aim of this analysis is the evaluation of the availability of both single elements of an infrastructure and the infrastructure as a whole, to provide goods and services to other elements/customers at an acceptable predefined level, in presence of faults, failures or any kind of anomaly situations.

Several simulators can be used at reductionist level. Among them NS2, the well known open source simulator, CISIA and I2SIM.

CISIA (Critical Infrastructure Simulation by Interdependent Agents) [98, 99] is an agent- based simulator for modelling critical infrastructure interdependencies. It was born with the aim to analyze failure propagation and performance degradation in systems composed of different, heterogeneous and interdependent infrastructures.

In CISIA, each facility is modelled with macro-components at a high level of abstraction. Each macro-components is defined as an agent. Each agents has the same structure based on few common quantities, representing the state or memory of the agent:

Operative Level (OL): the ability of the agent to perform its required job. It is an internal measure of the potential production/service, if the operative level is 100% it does not mean that it is providing the maximum value but that it could, if necessary.

Requirements (R): what the node needs to reach the maximum operative level.

Faults (F): the level of failure that affects the agent, for each type of fault.

Agent inputs and outputs are necessary in order to perform interactions among agents. There are three kind of inputs and, similarly, three kind of outputs:

1. Induced/propagated faults: faults propagated to the considered agent from its neighbour-hoods and from the considered agent to its neighbourhood, described in terms of type and magnitude.

2. Input/output requirements: amount of resources requested by/to other objects.

3. Input/output operative levels: the operative level of those objects whose

resources are used in it, and the operative level of the object itself.

In CISIA, the agent dynamic is described as an input/output model among the previously listed quantities. This description of agent’s behaviour is highly abstracted but it is enough rich in order to leave the experts to model the model dynamics in the most appropriate way. The relations among agents are based on their interdependencies, and they are described by incidence matrices. In fact each matrix is able to spread a different type of interdependency, following Rinaldi characterization [100] among physical, geographical and cyber connection.

I2Sim is a simulation environment used to study interdependency problems in Critical Infrastructure Protection [94] and it allows to model physical and geographical interdependencies. The key element of I2Sim is the production cell, a functional unit that

Ref. CockpitCI-D2.1-Overview of modelling techinques and tools for SCADA systems under attacks.docx

Final version Page 102 on 153

relates a set of resource levels as input to a particular resource level as output. Only one kind of resource can be associated to a single production cell. By considering a proper set of production cells it is possible to model a scenario consisting of different infrastructures and build loose or light coupling relations to model interdependencies.

In addition to a production cell, I2Sim also relies on other components:

Channel: which is a means through which tokens flow from a generator cluster to a

load cluster.

Tokens: are goods and services that are provided by some entity to another entity that uses them. These tokens can be water, electricity, medical supplies, etc.

Cluster: is a group of one or more cells. Two clusters are separated in time or space and are connected by channels. Each cluster generates and/or consumes tokens.

Controls: are Distributor and Aggregator units. They change their state based on the

events received from the decision making layer.

The generation and flow of tokens among different entities is determined by physical capability of each of the cells (e.g., power generation capacity or water supply capacity), their environmental constraint (damage of cells or delay in transportation channel) or human decision factor (e.g., redirection of water supply to a hospital rather than to a swimming pool).

Figure 7.11 shows an I2Sim electrical scenario composed by SCADA basic controlling elements and electrical substations. Two electrical substations supply energy to two different residential areas and receive commands from two RTUs, which are connected to a Public Switched Telephone Network (PSTN). It is possible to model the consequence of failures occurring inside the electrical substation at specific time, which have the effect of reducing the quantity of energy supplied to the residential areas and to the communication components. In addition, it is possible to model the consequence of a failure against a RTU (e.g. due to a cyber attack) that may reduce the quality of service of the electrical substation. This approach allows modellers to explore the impact of failures on system performance [95].

Ref. CockpitCI-D2.1-Overview of modelling techinques and tools for SCADA systems under attacks.docx