Smart Grid Testbed

In order to test our framework, we designed a realistic representative smart grid testbed which performs essential operations conforming to the International Electrotechnical Commission 61850 (IEC61850). The proposed testbed includes both resource-limited (e.g., Remote Terminal Units (RTUs), Programmable Logic Controllers (PLCs)) and resource-rich (e.g., Phasor Measurement Units (PMUs), Intelligent Electronic Devices (IEDs)) devices. In our testbed, the devices use open source libiec61850 libraries to exchange smart grid time-critical device messages using the GOOSE messaging format. The use of open source software increases our framework’s interoperability, flexibility, and opens new possibilities for customizations and for making this tool more configurable.

Adversary Model

We consider six different types of compromised devices with different computing resources and hardware capabilities. Our adversary model also complies with the security requirements defined by the US National Institute of Standards and Technology (NIST) for the smart grid. Considering the high device diversity of the smart grid, we define two types of devices: resource-rich and resource-limited devices. For our analysis, we consider a compromised smart grid device (e.g., RTUs, PMUs, IEDs, etc.) as a genuine device with some malicious function installed on it. The malicious function can be due to a compromised hardware or software component installed on the smart grid device otherwise assumed to be genuine. The malicious function can change the basic operations of the original device and it could have been installed either in one of the supply chain stages or while performing software upgrade in the field.

Overview of the Proposed Framework

The proposed framework compares and correlates, based on three different detection approaches, the statistical information of system and function calls lists from equivalent ground truth and compromised devices that are performing similar tasks in the smart grid infrastructure. For this purpose, we create a database of different ground truth profiles (GTPs) from genuine smart grid devices throughout our learning process. Different profiles need to be created for different class of devices that are performing different operations in the smart grid infrastructure.

There are three fundamental operations in our framework:

  • Data collection: in this step, we apply the proposed system/function call tracing techniques. The objective is to trace and capture all the system/function calls raised during the interval in which the devices from our testbed are being tested.
  • Data processing: in this step, we apply up to three different detection approaches to extract, compare, and correlate information from the system call lists and the ground-truth device profiles obtained from the GTPs database.
  • Decision: finally, the decision algorithm processes the results from steps 1 and 2 to decide if the devices are genuine or compromised.

 Finally, we utilize two different hooking techniques: ptrace (that performs function call tracing) and LD\_PRELOAD (that performs system call tracing). By utilizing and comparing the performance of function and system calls, we are able to study the device’s behavior from the user and kernel levels, respectively.

Framework Performance

In order for our framework to be useful for any realistic smart grid scenario, the tool should be able to work with relative accuracy and scalability. In our case, the former refers to the performance during compromised device detection. On the other hand, the latter refers to the possibility of our framework to cope with the high smart grid device diversity. Also, our framework has to make efficient use of the resource. For that reason, the three detection methods proposed are applied as needed to save from energy and computing resources.

Experimental results demonstrated an excellent detection rate for the compromised smart grid devices. Performance metrics revealed accuracy values between 0.95 and 1 for the different devices and detection methods analyzed. Additionally, the detailed performance analysis showed minimum overhead on the use of computing resources (i.e., CPU, memory, etc.) with our framework. On average, memory utilization does not increase more than 0.03 % while real, system, and user time would not increase more than 230 ms for even the worst case scenario (resource-limited devices).