Penetration testing is one of many different types of security assessments you can perform to find vulnerabilities in any type of computer system, including control systems found in every nations critical infrastructure. While many of us perform penetration testing on IT systems for several different industries, not  many security professionals have had the opportunity to perform penetration testing on control systems.

Having spent the last five years of my thirteen year career consulting and perform penetration tests in the energy sector, hopefully I can give a glimpse of how this differs from what I could consider traditional penetration tests that we perform on other systems.

One of the biggest differences when assessing control systems is their sensitivity to malformed traffic and the risk of bringing down one of the systems. Because of these issues, penetration testing is rarely done on live production control systems. Instead, penetration testing often focuses on the connectivity to the control systems from corporate networks and other remote access capabilities. This type of penetration testing isn’t any different than what you’d perform in a traditional penetration test.

However we also perform in-depth penetration testing on newly acquired systems before they are placed into production, often as part of the purchasing process.

This type of penetration test often differs significantly from traditional penetration tests because it usually focuses on one type of control system from the master servers to the field/floor devices they control, not an entire network of disparate systems. But the biggest difference from traditional penetration tests is the depth to which we assess these systems.

We don’t stop at assessing the operating systems, their network services, and their web applications. We go beyond this and dig into the control system network protocols, the proprietary RF signaling between field/ floor devices, and the embedded electronics in the field devices.

This allows us to identify and address vulnerabilities not only in the servers running Windows and Linux that attackers can get to through remote network connections, but also allows us to find vulnerabilities in the embedded electronics and non- TCP/IP based networks that many control systems device use that attackers can access through physical proximity.

The field/floor devices in control systems we test are usually embedded, microcontroller based devices that may not be running commodity operating system. This hardware is commonly deployed in areas where attackers could easily gain physical access such as on the sides of people’s homes, on power line pole-tops, in substations found near populous areas, and remote locations hours and sometimes days from human civilization.

These embedded devices contain various electronic components that store data (EEPROM, Flash, RAM, MCU on-chip storage), communicate on buses that pass data between components (parallel buses and serial buses), and expose input interfaces used for administrative or debugging purposes (serial ports, parallel ports, infrared/optical ports).

The overarching goal for testing these embedded devices is to identify vulnerabilities that allow attackers to escalate their control from physical access to remote access or lesser physical access. Often these weaknesses show themselves in unprotected storage or transfer of sensitive information such as cryptographic keys, firmware, and any other information that an attacker can leverage to expand his attack.

For example, in Advanced Metering Infrastructure (AMI) systems, we might successfully retrieve a smart meter’s C12.18 master password, a password that protects the optical interface on the  front of smart meters deployed in the United States,   enabling the tester to directly interface with the optical port on other meters without having to disconnect or dismantle the othe meters.

This assumes that the master C12.18 password is used throughout the smart meter deployment, which unfortunately is often the case in AMI systems.

The diagram below shows the overall process flow of the penetration testing tasks I use to test control systems devices and teach in my new class, Assessing and Exploiting Control Systems with SamuraiSTFU. Performing this work often required specialized tools and techniques. Here is the list of tools I often use to perform this type of work:

• Basic tools such as screw drivers, wire cutters, pliers, tin snips, etc.

• Electronics equipment such as power supply, digital multimeter, and oscilloscope

• Electronic prototyping supplies such as breadboard, wires, components, alligator ?jumpers, etc.

• Specialized tools to communicate directly with individual chips or capture serial ?communications such as a Bus Pirate or commercial equivalent such as Total ?Phase Aardvark/Beagle.

• Universal JTAG tool such as a Bus Blaster, GoodFET, or a RIFF Box

• Surface mount micro test clips

• Electric meter test socket

• Disassembler Software for the appropriate microprocessors to be tested

• Entropy Analysis Software

• Protocol Analysis Software

If you are interested in learning more about this testing methodology, check out my new open source project, the Samurai Security Testing Framework for Utilities (SamuraiSTFU) at http://www.SamuraiSTFU.org or the testing methodology I created for the United States Department of Energy named the NESCOR Guide to Penetration Testing for Electric Utilities, which you can find at http://www.smartgrid.epri.com.

About The Author

Justin Searle, I am the Managing Partner of UtiliSec, specializin in Smart Grid security architecture design and penetration testing