The EPES operates upon a set of specific SCADA communication protocols such as DNP3, Modbus and IEC-104. However, due to the convergence of IT and OT technologies a number of security incidents against these critical infrastructures has significantly increased in the last years affected by a wide range of cyber threats [1]. The SDN-microSENSE project has developed a solution for EPES systems against cyber-attacks through a dedicated sub-system called Cross Layer Energy Prevention and Detection System (XL-EPDS). The XL-EPDS provides an all-in-one IT/OT defence system for protecting EPES ecosystem from cyber threats and attacks. To achieve this objective, the XL-EPDS is capable of detecting and preventing cybersecurity attacks as well as unidentified threats in real-time. However, specific detectors are required to evaluate the cyber incidents associated with those protocols. To this end, the XL-EPDS is capable to deploy specific detectors and evaluates events produced by the incident detectors which are monitoring the EPES infrastructure. The events produced by detectors are normalised and correlated to identify a cyber-incident and trigger security alarms.
Figure 1 shows the high-level view of SDN-microSENSE architecture. The overall architecture is split into four SDN planes as described in [9]:
- Data/Infrastructure Plane, where we have the SDN Switches, and also, all the infrastructure elements that may receive network traffic (e.g., RTUs, PLCs, SCADAS, Smart Meters, Dedicated Servers, HMI Systems, and so on). Note that all these infrastructure resources are grouped into different sets – TSO/DSO Substations, Control Centres, Micro Grids or Honeypot sets – controlled as large-scale infrastructure resources deployed over a wide area network.
- Controller Plane, which can host one or more SDN controllers in a fault-tolerant fashion, in order to provide redundancy. As in the general SDN architecture, these controllers can communicate with the data and the applications plane using the southbound and northbound interfaces. The Controller Plane is responsible for translating the requirements from the Application Plane down to the SDN Data paths and provide the SDN Applications with an abstract view of the network infrastructure.
- Application Plane. This plane hosts the SDN application specifically devised for this SDN-microSENSE system, implemented through three different core frameworks:
- The Energy Prevention and Detection System (XL-EPDS), which is the core of the SDN-microSENSE architecture, since it is responsible for detecting and preventing cyber-attacks. This XL-EPDS application relies on the SDN technology to gather information from all the components deployed on the Infrastructure Plane.
- The Security and Risk Assessment framework (S-RAF), which is intended to establish the necessary risk priorities and security policies, identifying possible threats and vulnerabilities and determining the corresponding risk levels for each entity of EPES.
- The Self-healing application (SDN-SELF), which is intended to provide various management and self-healing functions that can be activated in the case of a critical state (recognised by the XL-EPDS application) is detected. Based on the SDN switching capabilities, the SDN-SELF generates islanding schemes to isolate the critical parts of the network in case of cyber-attacks.
- Management Plane, which contains the following functionalities: i.) A privacy protection responsible for the privacy and protection of the stakeholders by determining the appropriate privacy policies and deploying a Role-Based Access Control (RBAC) system; ii.) A common assets inventory to keep updated information on all the assets deployed in the architecture; and iii.). A synchronisation and coordination service providing redundancy and fault tolerance in the controller plane.
As we can see, in SDN-microSENSE, the Application Plane contains a complex SDN application consisting of three different frameworks, namely S-RAF, XL-EPDS and SDN-SELF, communicating with each other through the necessary (ad-hoc) interfaces and relying on the NBI to access the underlaying SDN controller plane [9].
Particularly, XL-EPDS is implemented by integrating and enhancing the following technologies [9]:
- The Security Information and Event Management (SIEM) function, which is intended to continuously monitor, control and correlate the operations that take place in the Data Plane (mainly at Control Centres, TSOs, DSOs and Smart Meters).
- The Intrusion Detection and Prevention System (IDPS) function, to provide specification-based detection techniques, and having the capability to detect zero-day attacks.
- The Anomaly Detection function, to apply anomaly detection methods for detecting anomalies and identify risks based on them.
- An Anonymous Repository of Incidents (ARIEC), intended to store and share information about the detected incidents with other EPES.
The SIEM functionality of XL-EPDS is implemented by the Atos’s XL-SIEM solution [2], refer also to D5.1 [3]. XL-SIEM is a SIEM tool that works as an enhanced SIEM platform with an added high-performance correlation engine able to raise alerts from a business perspective considering different events collected at different layers. It inherits the data structure of the Alienvault Open Source SIEM (OSSIM) [4]. The platform is composed of a set of distributed agents, responsible for the event collection, normalization and transfer of data; an engine, responsible for the filtering, aggregation, and correlation of the events collected by the agents, as well as the generation of alarms; a database, responsible for the data storage; and a dashboard, responsible for the data visualization in the web graphical interface.
In the context of IDPS [5], a rule-based specification IDPS includes appropriate specifications regarding the normal operation and utilisation of industrial protocols, such as Modbus, DNP3 and IEC 60870-5-104. Three main detectors are covered by this module – Enhanced Suricata[1], Data injection detector by Tecnalia and Nightwatch[2]. These detectors feed from network traffic monitored from the EPES infrastructure. These specifications are explicitly based on rules that define the normal operation and utilisation of the protocols, so when the monitoring network traffic data includes attributes different to the ones in the specifications, a relevant security event would be generated and sent to the XL-SIEM.
In the context of Anomaly Detection [6], the main focused is the usage of machine learning technologies for the detection of cyber-incidents. A number of ML-based detectors are developed in SDN-microSENSE each one focusing on the detection of incidents associated to an individual SCADA protocol. More specifically, ML detectors were developed for the following protocols: Modbus TCP/IP, DNP3 TCP/IP, DNP3, IEC 61850 GOOSE, IEC 60870-5-104 TCP/IP, IEC 60870-5-104, MQTT and NTP. For each detector, it has been described the machine learning models included in the tool, the data sets used for training and how the tool is integrated in SDN-microSENSE [6].
In the context of ARIEC [7], in order to be aligned with the NIS Directive[3], requiring mandatory reporting of cybersecurity incidents by the EPES operators, the ARIEC system implements a repository of anonymised security events. It allows storing and sharing of technical details of incidents (e.g., cyberattacks) among different EPES stakeholders belonging to a network of trust, but without identifying details that could disclose sensitive information. ARIEC ensures confidentiality, integrity and interoperability between data exchange parties. ARIEC can receive security incidents information from different sources: by automatic communication through the XL-EPDS or the S-RAF, and also, by direct reporting by a human operator (e.g., DSO Operator, Security Administrator or Power Plant Operator), who can input the details of the cybersecurity incident through a specific frontend.
XL-EPDS has been extensive evaluated in different use cases of SDN-microSENSE and cyber-attacks (e.g., FDI, MITM, DoS) with several positive results of evaluation across metrics such as accuracy, precision, recall, F1 score, but also across user acceptance qualitative metrics [8].
Blog post by Hristo Koshutanski, Atos Research and Innovation, Spain
References:
[1] Pliatsios, D., Sarigiannidis, P.G., Lagkas, T.D., & Sarigiannidis, A.G. (2020). A Survey on SCADA Systems: Secure Protocols, Incidents, Threats and Tactics. IEEE Communications Surveys & Tutorials, 22, 1942-1976.
[2] XL-SIEM, The experimental SIEM, Providing a lightweight and cost effective system information and event management. Available at https://booklet.atosresearch.eu/xl-siem
[3] SDN-microSENSE Consortium, Deliverable D5.1, XL-SIEM System. Sep 2020. Available at https://www.sdnmicrosense.eu/wp-content/uploads/2021/09/D5.1_XL-SIEM-System.pdf
[4] AlienVault OSSIM, Available at https://cybersecurity.att.com/products/ossim
[5] SDN-microSENSE Consortium, Deliverable D5.2, SS-IDPS System. Oct 2020. Available at https://www.sdnmicrosense.eu/wp-content/uploads/2021/09/D5.2_SS-IDPS-System.pdf
[6] SDN-microSENSE Consortium, Deliverable D5.3, ADS and CLS Discøvery Systems. Dec 2020. Available at https://www.sdnmicrosense.eu/wp-content/uploads/2021/09/D5.3_-ADSandDiscoverySystems_v1.0_PUBLIC.pdf
[7] SDN-microSENSE Consortium, Deliverable D5.5, Cloud-based Anonymous Repository of Incidents. Sep 2020. https://www.sdnmicrosense.eu/deliverables/ (confidential document).
[8] SDN-microSENSE Consortium, Deliverable D8.5, Validation, Evaluation and Lessons Learnt. Oct 2022. https://www.sdnmicrosense.eu/deliverables/ (confidential document).
[9] SDN-microSENSE Consortium, Deliverable D2.3, Platform Specifications and Architecture. Mar 2020. https://www.sdnmicrosense.eu/deliverables/ (confidential document).