Bro in SCADA: dynamic intrusion detection policies based on a system model

We present an online monitoring tool for SCADA systems based on the network monitor Bro, which can be used locally at ﬁeld stations. The tool generates alerts when suspicious and erroneous commands and sensor readings are detected. It can hence been seen as a local Intrusion Detection System, as well as an safety enhancement. It maintains a model of the local system, which is updated with incoming packets containing sensor readings and commands. Focusing on the protocol IEC-104, a parser was developed and the packet content was directly fed into the system model. Adaptive policies are implemented in Bro, which formulate physical constraints and safety requirements and allow to check whether SCADA trafﬁc complies to these rules in real time. A case study with a real IEC-104 trafﬁc trace shows the feasibility of our approach.


INTRODUCTION
Safe and reliable critical infrastructures need to be at the core of our modern society.In order to ensure their stability, they have to be continuously monitored.Geographically distributed critical infrastructures, such as electricity distribution and transmission, are monitored and controlled by SCADA (Supervisory Control and Data Acquisition) systems.By allowing remote control, operators save time and companies save money when managing the distribution grid.However, at the same time, such automation introduces new opportunities for malicious parties to disrupt the process.
Although SCADA systems include a communication network, their direct interaction with the physical process requires additional security methods specifically tailored to the safety requirements and physical constraints of the process.For example, when an attacker hacks into a control room by means of phishing (ICS-CERT (2016)), or a USB stick (ICS-CERT (2010)), and sends legitimate commands, from a legitimate source, that can easily result in disrupting the physical process.The detection of SCADA attacks aiming at disrupting the physical process is challenging if one only relies on network Intrusion Detection Systems (IDSes), implementing e.g.whitelisting or log-analysis (Barbosa et al. (2013); Hadžiosmanović et al. (2012)).Even if the mentioned IDSes are designed specifically for SCADA protocols, malicious control commands sent in a legitimate format would remain undetected.For example, the detection of a sequence attack (Caselli et al. (2015)), requires a complementary, processaware system, which analyzes each command in the context of the physical system state.
The concept of process-aware monitoring has recently been investigated in the context of industrial control systems and electricity transmission and distribution systems (Nivethan and Papa (2016a); Lin et al. (2013); Fovino et al. (2010); Hadžiosmanović et al. (2014);C árdenas et al. (2011)).It usually involves deep-packet inspection and processing that content, e.g., by comparing process variables to predefined thresholds ensuring system safety.Previously, we proposed a process-aware monitoring approach for field stations, which relies on a model of the directly controlled system (Chromik et al. (2016a,b)).Additionally, physical constraints, e.g., Kirchoff's law for nodes in the system, and safety requirements, e.g., maximum current allowed on the power lines, are formalized for this system.This paper paves the way to a monitoring tool based on the network security monitor Bro (Paxson (1999)), which can be used for intrusion detection.Maintaining a model of the state of the physical system, the proposed tool checks physical constraints and safety requirements online and locally for field stations.Moreover, the tool alerts the system operator whenever an incoming command at that location could disrupt the physical process or when a sensor measurement deviates from the model more than a predefined threshold.
The presented monitoring tool is intended for use in field stations to detect attacks coming from a corrupted control room or via a corrupted communication channel.Examples are insider attacks in the control room, and man-in-the-middle or replay attacks in the communication channel.We emphasize that our approach should be used in addition to existing centralized mechanisms, such as the Energy Management Systems, and is not as a replacement.In our local approach, the tool uses measurements taken close to their source, which are less likely to being manipulated.These measurements are then used to validate the impact of commands coming from the "less trustworthy" control center, which is more commonly attacked by hackers (ICS-CERT (2016, 2010)).
We explain how the safety and security rules are implemented as policies in Bro, such that they can run in close proximity to the RTUs in the field stations.Furthermore, we discuss how these policies need to change with the current state of the system.The contribution of this paper is threefold: (i) A parser for the SCADA communication protocol IEC-104 is presented, which is able to interpret packet content and allow it to be processed using the Bro monitoring tool.(ii) For a specific field station, we illustrate how two constraints are turned into Bro rules and how they depend on the system state.(iii) The proposed approach is evaluated on a real traffic trace recently captured at a substation of a Dutch electricity distribution operator.
The paper is further organized as follows.Section 2 presents the related work w.r.t.process-based intrusion detection.Section 3 discusses necessary background on SCADA systems and intrusion detection.Section 4 explains how the existing physical constraints and safety requirements are written in the form of rules and Section 5 explains how such rules are translated to Bro policies and explains how those polices are state-dependent.The proposed monitoring system is evaluated in Section 6 and the paper is concluded in Section 7.

RELATED WORK
SCADA security and intrusion detection is a very active research area.Many proposed intrusion detection mechanisms only analyze the periodicity of packets sent in the network (Udd et al. (2016)), or investigate the structure of packets, creating a model according to the specification (Yang et al. (2013)).However, they do not incorporate process information into the decision process.Nivethan and Papa (2016a) propose to incorporate process semantics by mapping the monitoring requirements to the respective PLC registers.The proposed mechanism issues alerts when, e.g., process variables are not within the requested bounds.While this paper does not discuss where and how this detection method could be implemented, it mostly duplicates the Energy Management System (EMS) at the central control room.Moreover, the defined rules are static, i.e., they compare process values with a desired set point.Furthermore, many popular protocols do not simply transport floating point values between the field stations and the main control room, e.g., IEC-104 uses scaled and normalized values, while Modbus transports the floating points in the form of several pairs of 2-byte registers.This complicates the use of the above approach for different protocols.Also, a method to dynamically generate rules for fine-tuned deep packet inspection has been proposed by the same authors (Nivethan and Papa (2016b)), which however, does not discuss taking the process semantics into account.Lin et al. (2013) propose to detect malicious commands in power grids by including a model of the entire power grid into a centrally-located detection mechanism and share that information with a distributed network of Intrusion Detection Systems.These implement a Bro IDS, which triggers run-time power flow analysis that uses information obtained from network packets, to pre-calculate the physical consequences of the sent command.This approach trusts the directly connected, locally obtained data from sensing devices and does not trust the "intelligent" (controlling) devices.In their earlier work, Lin et al. (2013) explain a way to include specification-based IDS for the DNP3 protocol, also implementing a Bro IDS.Fovino et al. (2010) aim at detecting complex SCADA attacks by monitoring the evolution of the state of PLC registers and creating a database of critical states, which are unsafe, to the system.Complex attacks consist of series of commands, that are licit to a traditional IDS when considered separately, but causing harm when issued together.
They present examples of packet signatures for the two implemented protocols: Modbus/TCP and DNP3.To maintain an up-to-date system state, the presented solution uses a Modbus client that polls all PLCs for the values of all their registers, which introduces an additional load in the network.The approach heavily relies on the availability of an upto-date database of the blacklisted critical states.It remains unclear whether this database is updated automatically, or manually.Moreover, critical states may change with the current state of the system, which is not addressed in the paper.While their approach is close to one proposed here, we make use of more abstract rules to detect unsafe states and to blacklist them.Hadžiosmanović et al. (2014) proposed an anomaly detection approach that compares register values to predictions of process variables based on historical data.This approach does not predict the outcome of an incoming command, it rather detects whether process variables deviate from their normal values.

SCADA AND INTRUSION DETECTION
Section 3.1 provides a brief overview on SCADA systems and IDS for industrial control systems.Section 3.2 discusses how process variables are communicated within the protocol IEC-104.

Background on SCADA and IDS
SCADA systems are often used in critical infrastructures, like power distribution, to monitor and control the underlying physical system.In the field stations, sensors measure e.g., voltage and current on the buses and power lines, and pass them to a Remote Terminal Unit (RTU) or Programmable Logic Controller (PLC).Via a communication infrastructure RTUs and PLCs forward information to the Master Terminal Unit (MTU), located in the Control Room.There, the information is processed by additional SCADA servers, which, e.g., estimate the state of the physical system, and determine if changes are required in that system.In that case, commands are sent to actuators using the same communication channels.The information is then archived in a historian server and after it is processed, the the overview of the physical system state is updated on the Human Machine Interface (HMI).
SCADA systems have been designed to provide better functionality and availability for physical systems, often lacking mechanism to ensure integrity and security of the processed information.However, even newly designed systems, which implement security mechanisms have vulnerabilities.Recent events, such as the attack on the Ukrainian power grid (ICS-CERT (2016)), or reports of new malware tailored specifically to ICS, such as CRASHOVERRIDE1 or TRISIS2 , show that hackers are aware of vulnerabilities and are able to abuse them.
Many security mechanisms can be implemented in SCADA systems to reduce the risk and the (impact) of a security breach.IDSes help to analyze and secure ongoing communication, e.g., by whitelisting known IP addresses (Barbosa et al. (2013)).In contrast, this paper focuses on processaware IDS, which requires the ability to inspect the content of packets and relate them to the physical process at hand.Among the open-source network monitoring tools available for SCADA protocols, the most popular are Snort (Roesch (1999); Yang et al. (2013)), and Bro (Paxson (1999); Lin et al. (2013); Udd et al. (2016)).Snort allows for pattern matching within packets to, e.g., determine whether their format matches their specification, or alert when variables exceed certain thresholds.Instead, Bro has a modular structure, which can be extended to include the necessary parsers for different SCADA protocols.More importantly, Bro includes a framework for rule-based evaluation of the packet content, which enables the evaluation of the proposed process-aware rules.

Process variables in IEC-104
Many of the currently used SCADA protocols, such as Modbus, IEC-104, or DNP3 do not implement security mechanisms.However, some of them, such as IEC-104, allow to transfer analog values as scaled or normalized values instead of the actual floating point values (IEC104 (2013)).
Normalized values are numbers in the range <-1;1>, where the precision depends on the number of bits available.If the resolution of the measured value is coarser than the unit of the least significant bit, then the least significant bit is set to 0 (IEC101 (2003); Clarke et al. (2004)).For example, when using normalized values, both the main server in the control room and the RTUs in the field stations store reference values of all process variables, e.g., P V ref .The transmitted value P V trans of a real value P V real is then defined as

Scaled values
For example, if the reference value for the current on a line is equal to 1000A and the measured value is 150A, then 0.15 is sent as normalized value to the control room.This approach is used by operators to obscure the data passed along the communication channels.However, this complicates security mechanisms as proposed e.g. by Nivethan and Papa (2016a), while process-aware policies, as proposed in this paper, facilitates the use of normalized values.
Overall, IEC-104 passes information using Application Protocol Data Units (APDUs) which consist of Application Protocol Control Information (APCI) and Application Service Data Units (ASDUs).APCIs contain the start byte (104), the length of the APDU, and 4 bytes of control information.The content of a header of an I-frame, which transports actual system information, could be: The command above activates a request to set a threshold of the IOA with number 12333 to the value 0.0517578.
Process variables are also stored in the IEC-104 RTU configuration.Such a configuration contains sensor and actuator information, i.e., analog or digital input and output.Sensors provide information about the system state, while actuators enable the control of that system state.Separate addresses (IOAs) are used for all analog and digital inputs and outputs in the monitoring and in the control direction using a communication infrastructure.

FROM RULES TO POLICIES
Previously, a set of physical constraints and a set of safety requirements have been defined, which need to be satisfied by the system in order to ensure its safety (Chromik et al. (2016a)).Both these sets can be used to improve the system security, by maintaining a model of the system state and checking new measurements and commands against this model.Any violation of these rules then indicates a possible intrusion.
The system state changes over time, and as the rules depend on the state of the system, they have to be implemented into adaptive Bro policies in order to monitor and alert potentially malicious traffic.Turning these rules into process-aware policies within Bro requires knowledge on the topology of the system, as well as on the configuration of the RTU present in the field station.
This paper explains the idea of state-dependent policies and investigates how dynamic policies need to be, i.e., when and how they need to be updated within the IDS.In the future it might be possible to automatically generate such policies for given input topologies, configurations and protocols.A complete implementation of the approach, as sketched in Figure 2, is considered future work.

Physical constraints encompass physical laws, like
Kirchoff's law.They are used to determine whether the system is consistent.If the measured values do not follow the laws of physics, they must be corrupted.They can also be used to pre-compute the next system state upon receiving a command.They are summarized in Table 1.
Safety requirements are conditions which need to hold to ensure the system operates in a safe and reliable way.They are based on low and medium voltage norms, e.g., that the low voltage needs to be within 10% bound from the nominal 240V (CENELEC (1988)), as well as on the knowledge of the operators, for this particular system.We list the requirements in Table 2. Upon every reading and every command, the pre-calculated system state has to satisfy all safety requirements.For example, if the pre-calculated system state shows a current on a power line that exceeds the maximum current allowed, the operator is notified, since the power line wears out faster.
RTU configuration contains the mapping of process variables to the addresses, where the values are stored.In case of IEC-104, the address of the process variables in the monitoring direction (used for data acquisition) is usually different than in the control direction (used for commands).In the example below, the current limit value for field 1 is contained in address 12333 in the control direction.
RtuAddr: 1500, Address: 120, IOA_M: 9000, IOA_Mtt: 11222, IOA_C: 12333, IoDescription: Field_1 current limit, LowerBound: -1000, UpperBound: 1000, DimensionText: A  Topology is the description of the system at hand.We use the format previously proposed (Chromik et al. (2016b)).This paper analyzes the topology shown in Figure 1, provided to us by the Dutch distribution system operator where we have also obtained the traffic capture.We build Bro policies for the RTU that is located at bus B 3 (marked in green).
In Section 6, we investigate commands concerning line 5 and 9, also marked in this figure.
However, just the topological information about the elements listed above is not enough to define the policies for the monitoring tool.Based on the interactions between the listed elements, it is possible to develop three sets of rules: (i) infrastructure-based, (ii) topology-based, and (iii) load-based, that help to keep the system in a safe and secure state.We illustrate these types and their input and output dependencies in Figure 2, as explained below.
Rules type A: Infrastructure -these rules depend on the present infrastructure and change only when the physical system is changed, e.g., if a cable is replaced by one with a different maximum allowed current.Infrastructure changes are relatively rare, hence, we decided to not adjust these rules automatically within the Bro policies.Hence, a change in the infrastructure requires an explicit update by the operator, which we believe helps to keep the system secure.
Rules type B: Topology/Switching -these rules are to some extent dynamic and can be updated based on the system state.They change when the topology of the system is changed, e.g., due to a switching command.An example of such a rule is interlocking, i.e., a mutual dependency between the state of some switches.Upon receiving a command about the change of a switch state, the reference model of the switch states in Bro is updated, and the policies analyze the new, resulting model.Rules type C: Load -these rules depend on the load and are highly dynamic.They are updated automatically in the system, e.g., a decision to open a power line depends on the load of all connected power lines.The state of the system depends on the load that is newly reported with every reading of sensor measurements, and is updated in Bro accordingly.The policies referring to the load depend on that reference state.
To illustrate our approach, we investigate the use of the following rules for the RTU located at bus B 3 (cf.Figure 1): R1: ensures that only one of the lines L 9 and L 10 can be open at the same time.Their states are determined by switches S 9 and S 10 , respectively.This is a rule of Type B and ensures an interlock: (S 9 .st.close)OR(S 10 .st.close) == True.
R2: The maximum allowed current in line L 5 is 160 A. This is a rule of Type A and relates to the set point defining the maximum allowed current on a line.This threshold may be set to any value within a 5% range of the maximum allowed current.
For example, the operator may want to change it to 165 A. However, significantly larger values, such as 200 A are suspicious.
Once, the rules for a specific RTU and a given (part of the) topology have been defined, they need to be translated into state-dependent Bro policies for a given protocol type (cf. Figure 2).Separating the definition of rules form Bro policies and the protocol ensures the extensibility of our approach, e.g., to other monitoring tools and protocols.

STATE-DEPENDENT POLICIES IN BRO
The developed parser is described in Section 5.1, the requirements for implementing state-dependent policies in Bro are discussed in Section 5.2 and 5.3.The implementation for the two previously discussed rules is provided in Section 5.4.

IEC-104 Parser
As the previously discussed rules might depend on the current state of the physical system, the model of the system needs to be updated and compared to the communicated system information.Hence, a parser is needed that reads the relevant information from the packets transmitted using a certain standard and directly feeds them into the monitoring tool.To analyze IEC-104 traffic in Bro, a dedicated parser for processing the packets and extracting the values representing process variables is required.
We developed a dedicated Bro parser for the IEC-104 protocol using the Spicy parser generator (Sommer et al. (2016)) and part of the parser developed with BinPAC++ (Udd et al. (2016)).The development version of our parser is available on github 3 .We extended previous work of Udd et al. (2016) by adapting it to the Spicy parser generator, adding more Type IDs present in our capture, and by writing functions that enable content processing in Bro.Table 3 lists the implemented Type IDs.

Table 3: Implemented Type IDs
The Type IDs marked in green are especially interesting, because packets carrying these functions directly influence the physical system.C SC TA 1 is a single command function, that changes the state of a digital output on an RTU, and therefore, e.g., the state of a switch on a power line.C SE TA 1 is a set point command, changing, e.g., the maximum allowed current on the power line.

Construction of the monitoring tool
Based on the information about the configuration of the system under consideration, as discussed in Section 4, two main components are created for the monitoring tool: (i) a description of the system state (To), and (ii) a set of policies.
Figure 3 illustrates the dependencies of Bro policies on the current state of the system.Upon the arrival of a new packet, the monitoring tool first pre-computes (or extracts) the system state (step (i)), then checks the respective policies for the IOA in the packet on the resulting system state (step (ii)).For example, if the IOA refers to a switch state, the IDS will only check switching-related policies.If the policies detect a violation of the rules described in Section 4 for the pre-computed system state, an alert is issued to the operator.In step (iii), the pre-computed (or extracted) state is saved as the current system state.

State of the system
The state of the switches in a specific system is described as shown in Listing 1 and updated

Policies
The rules can directly be translated into policies, using the input language of the monitoring tool.This paper presents two policies, which directly translate the two rules R1 and R2 specified in Section 4. Listings 3 and 4 refer to those rules, respectively.
We implement the Bro policies to be triggered upon receiving packets with following Type IDs: C SC TA 1 and C SE TA 1 with the IEC-104 ASDU Cause Of Transmission field set to "Activation".Once a packet containing either of those Type IDs is received by the monitoring tool, a state update is triggered, followed by a policy check.If a policy detects a violation, an alert is generated.
In the currently proposed solution, the monitoring tool only informs the operator about the violation.It is possible, however, to block the packets from reaching the RTU, therefore, preventing the command from being executed.
Listing 3 Bro policy for interlocks.

EVALUATION
We use a trace captured on March 2, 2018 in a Dutch electrical facility that implements the IEC-104 protocol for the communication between the field stations and the control room.Next to regular SCADA traffic, the capture contains packets resulting from the operator performing two procedures: (i) changing the state of one switch from connected to disconnected, and (ii) changing the set point (threshold) value of the maximum current on one power line, significantly.
Listing 5 shows our monitoring tool's output as provided to the operator.An alert is displayed (shown in red), when a violation of the interlock policy is detected.The tool informs which packet is being processed, therefore, the operator can directly see what caused the alert.
According to Listing 1, the initial state of all switches, except S 10 , is closed, i.e., the power lines are connected.Due to the interlock constraint, cf.rule R1 in Section 4, line 10 and line 9 cannot be open simultaneously.Hence, the action of sending a command to open switch S 9 should trigger an alert, as can be seen in Listing 5.However, closing switch S 9 is allowed, which can be seen in Listing 5: where the command to set "S 9 .st.close" to True results in the output "Switching allowed".These two commands (open switch S 9 and close switch S 9 ) were present twice in the captured file, and both times they provided the same (correct) output.
Listing 6 again shows the monitoring tool's output to the operator.As shown in Listing 2, the threshold for the normalized maximum allowed current is set to 0.08 for all power lines.Rule R2 from Section 4 mentions that the set point can be changed only within a 5% range of the original value.This is checked by the Bro policy shown in Listing 4. As can be seen in Listing 6, our tool alerts when a new set point command requests to change this value to 0.051758 or 0.030762.The set point 0.082031 is within the allowed bounds, hence, does not issue an alert.
The following observations can be made from the presented log outputs.Firstly, the proposed parser is able to extract the relevant values of the IOAs present in IEC-104 packets and feed them to the Bro monitoring tool for further analysis.Secondly, the output of the policies implemented in Bro reflect the current system state.Finally, the log output can be adjusted to be informative to the system operator, e.g., when the object name is used instead of an IOA number.

CONCLUSION AND FUTURE WORK
The security of field stations in power distribution requires adequate mechanisms that can operate in a distributed manner and that take the state of the physical system into account.For that purpose, this paper proposes an approach for intrusion detection in field stations, implementing statedependent policies using the Bro monitoring tool.
We have shown the feasibility of our processbased monitoring approach using real IEC-104 traffic traces.Clearly, in order to apply the approach to other protocols, also dedicated parsers have to be developed.
While the presented approach is not meant as a replacement of security measures at the central control room, it has certain advantages, as it has direct access to the physical On the one hand, it could potentially have prevented an attack like the one that happened in Ukraine (ICS-CERT (2016)), as it would not simply execute the command sent from the corrupted control room.On the other hand, also mistakes made by the operators could be prevented with it.For example, the power outage in 2015 in the Schiphol area (Associated Press (2017)), which heavily affected the largest airport in the Netherlands, was a result of violating the interlocking policies, as discussed in this paper.Hence, processbased IDS is not only able to increase the security of the controlled process, but also its safety, as it also captures legitimate commands which jeopardize the safety of the process.Future work will focus on the automated generation of rules for a given topology and RTU configuration, as well as their automated translation into Bro policies.With increasing system complexity, it is likely that the processing time per packet increases within the Bro monitoring tool.We plan to conduct a careful trade-off analysis between execution time and accuracy when including larger parts of the real topology into the system.Note, that the values of IOAs and thresholds have been changed to ensure anonymity.
transmit values with a defined fixed decimal point.Values span <-32768; 32767>, and the range and position of the decimal point are stored in the configuration of the RTU and central server (IEC101 (2003);Clarke et al. (2004)).

Figure 2 :
Figure 2: Example of generating Bro policy for maximal current from the system description components.

Figure 3 :
Figure 3: Diagram representing the working of the monitoring tool.

Table 1 :
Physical consistency constraints

Table 2 :
Safety requirements