This is the third in a series of articles on the new “3×3” security model for critical infrastructure cyber security. The first defined the model itself, so if you haven’t read it yet, you may want to read it here before continuing. The second installment delved into the host security needs of SCADA systems and can be found here. This week, we’re going to talk about host security needs in the device network. Depending upon which specific industry that you’re in, you may know this as the device network, the process network, the field, the plant, the floor, and so on. I tend to generalize this as the “Industrial Control System” and call it the ICS network, because it helps distinguish the actual automated control system from the SCADA systems.
In a syntactically-confused environment such as this, it might be easier to forget nomenclature and simply think of this particular environment within Critical Infrastructure, the furthest right column of the 3×3 model, as “automated” portion of the infrastructure. It consists of controllers, data I/O, and any number of intelligent electronic devices or IEDs. This is where the convergence of the mechanical and the digital still weighs heavily towards the mechanical. This is where the human interface resides inside specialized embedded consoles rather than on off-the-shelf servers. This is where the controls provided by such a console provide focused control over a specific device or a specific process, rather than over a larger complex system. This is where the programs that are crated, managed and monitored by SCADA are executed. It is “the final frontier” of the critical infrastructure. Once we cross the divide between SCADA and the automated device networks, we stand in the territory of automation.
The ladder logic within the controllers, once running, reads inputs and sets outputs in perpetua. The goal of such logic is to run automatically, and so, if left to run it will do so without any human interaction. The HMIs, and the SCADA systems themselves, are primarily used to monitor systems, and only rarely to change them (although again, in some industries such as those that utilize flexible line manufacturing, changes can occur fairly often).
Technically, the endpoints of this environment share certain traits, but are hugely differentiated from their cousins in the SCADA or Enterprise networks. The difference comes from the intended use of these devices: they’re designed to run—automatically—for decades. They’re designed around concepts of simplicity and reliability. That means less powerful CPUs that use less power and create less heat. It means using field-tested microprocessors rather than cutting-edge technology. It means running embedded operating systems that can’t be modified by the end user, and embedded applications that are carefully tested and tuned to the limited hardware requirements of the device itself.
Unfortunately, the device network is also extremely vulnerable. The process loops that these systems operate are designed, essentially, to do what they’re told, and they rely upon the input of data (typically from sensors) for the controlled manipulation of outputs (such as motors or conveyers). If an attacker can manipulate the logic, the inputs or the outputs, that attacker can carefully alter the entire process. The fieldbus protocols used here are no longer secure through obscurity, and they make very easy targets. Why attack a device network? The question was asked at a recent ICS cyber security conference: “why do we need to protect a light switch (an input), or a light bulb (an output)?” The answer is: because the light switch could be an alarm switch, and the light bulb could be an emergency beacon. There will probably need to be an article about the various cyber attacks that might occur to embedded devices, but for now it’s sufficient just to know that they are indeed vulnerable.
So how do you secure such an endpoint? Normally, we would propose the use of endpoint security technology: antivirus and HIPS (Host Intrusion Prevention System) in the Enterprise, and Application Whitelistng and Change Control in SCADA. But in the field devices, there may be nothing that an asset owner can do on their own unless the device in question a) has a mechanism to enable the user to install software, and b) has enough CPU and memory capacity to support that software.
The easiest way to secure these devices, of course, is to segregate them from other digital systems. Isolate the device, and there’s no need to harden the device itself … right? Absolutely, but that’s a story for a different day, based upon and different sector of the 3×3 security model. For endpoint security in the device network, however we have to rely upon some sort of host security software, and we have to rely upon some additional mechanism to apply that software to the device themselves.
The good news is that both of these dependencies exist today: the first in the hands of the cyber security vendors; the second in the hands of the Industrial Control System vendors. The even better news is that these two vendor communities are working more closely together than ever before. The result is embedded cyber security, in the device network itself. Like with SCADA systems, whitelisting technology has certain benefits here, as it can be used in isolated areas with little to no patching requirements. However, if the device being secured is using a RTOS (Real Time Operating System) whitelisting as we know it may not be 100% applicable. Luckily, the cooperative efforts of the industry—the security and ICS vendors, the RTOS providers, etc—can solve this issue with time, it’s just that it requires re-thinking the paradigm of “whitelisting” to make it more applicable to an embedded RTOS. This is an area to watch closely over the next 18 months, as it represents an exciting new frontier of industrial cyber security.
These developments are encouraging for a few reasons: one, it means the ICS vendors are taking security seriously enough to work with outside security vendors; two, it means the security vendors are starting to recognize the importance of securing industrial systems; third, and most importantly, it shows an industry-wide solution to the continuing problems that face the security of our critical infrastructures. The lower-right sector of the 3×3 model is that hardest to deal with—without a doubt—but as the industry continues down this path it will be a challenge that can be overcome.