Rhett Smith

Tutorial: Security in Electric Utility Control Systems

This paper provides a tutorial on practical security measures that can be implemented in power system communication networks. It also includes a discussion and comparison of NERC CIP regulations requirements and proven IT security implementations. This tutorial provides a straightforward look at what NERC CIP requires along with potential steps on how to comply, what basic cybersecurity practices are available today, and how these can be implemented quickly and inexpensively. This tutorial examines new security protocols in development for substation applications to achieve cybersecurity using proven and vetted IT security protocols tailored for substation use including Ethernet, serial, and modem communications links. This tutorial covers specifically emerging standards including the following: 1. IEEE P1711-trial-use standard for a cryptographic protocol for cybersecurity of substation serial links. 2. OPSAID (Open PCS Security Architecture for Interoperable Design)-Design standard vendors may use to build secure systems for use in industrial control applications. The standard comes from the OPSAID project, under the auspices of the U. S. Department of Energy Office of the Electric Delivery and Reliabilitys National SCADA Test Bed Program.

How would we know

Modern power system monitoring, protection, automation, and control rely on communications and computing technology. Along with the benefits of these technologies come some risks of electronic or cyber attack. There are legitimate concerns about how inadequate information security (cyber security) is affecting electric power systems and other critical infrastructure. As a result of cyber security threats, both governments and industry are putting forth significant effort to improve critical infrastructure security. In the United States, for example, electric power utilities must now follow a set of cyber security standards. Security practices are evolving and improving, and new products and architectures are being developed and applied to counter the ever-increasing sophistication of attacker exploits that attempt to access, inspect, manipulate, and control critical infrastructure control systems. A fundamental question is “How would we know if our assets are being explored and exploited?” An attack strategy would likely include a number of initial probes, data collection, tests, and other activities as the adversary develops intelligence and capabilities against a target. To counter this strategy, asset owners need to detect the activities of the intruder. In part, this paper takes the perspective of an engineer investigating a FICTITIOUS incident, using the records and “fingerprints” an attacker would likely leave behind, which we can use to identify when our systems have been compromised. The paper explains how to answer the question using the many tools readily available in devices and systems in service today. These tools include access logs and syslogs, event reports, sequential events reports, information at adjacent stations, alarms, and precision timing. We also investigate some system design choices that make the process of answering the question easier. Finally, we make some recommendations that not only help answer the question “How would we know?” but also make an adversarys job much more difficult.

Whitelist malware defense for embedded control system devices

Malware protection is a necessity for any electric device in modern critical infrastructure. We must all protect our critical cyber assets with antivirus as North American Electric Reliability Corporation (NERC) CIP-007 R4 states, but more broadly, we must protect our assets from malicious code infection regardless of whether they are identified as critical assets or not. Embedded devices and traditional personnel computer devices should be protected. The Stuxnet worm demonstrated that air gaps and unplugged devices are not immune from infection. We must engineer devices and systems to protect against the impact of malware. Traditionally, this protection was accomplished by using blacklist technology, where the technology watched for known bad code and blocked it. This resulted in a race to update malware protection technology when new threats were discovered, before infection happened. With malware statistics topping 83 million pieces of code, based on the August 2014 McAfee Labs Threats Report, and growing every day, the administrative task is impossible to keep up with. This design also can put excessive burden on processors, slowing computations and communications. New malware protection technology is designed using a whitelist architecture that only allows known good code to execute on the device. This simplifies administrative overhead because new updates are not needed when new malware is released. A control system environment is built with application-specific devices that are set to accomplish one or more tasks and left alone to continue accomplishing the same tasks for many years, setting a perfect stage for whitelist malware protection technology. This paper investigates the benefits that whitelist malware protection provides at the application layer (similar to existing anti-malware technology) and explains why embedded devices need architecture-specific malware protection. The paper shows that correctly combining malware protection and embedded architecture improves the reliability and cost of ownership of the whole system. The paper also highlights the enhanced security that whitelist malware protection provides over traditional solutions and how these principles apply to computers and embedded devices. The paper shows how whitelist malware protection meets and exceeds the NERC CIP requirements in Versions 3 and 5.