By Eric Byres
In the December issue (Wolves at the Door(s) of the House of Straw), we discussed the flaws in the “bastion” model of cyber security. Savvy IT departments don’t use this one-firewall-fits-all model for the total corporate intranet, much less for the plant floor or the control room. It provides a dangerous single point of failure that just begs the hacker to get breach it, and once it has been broken through, it leaves the entire system vulnerable.
The alternative can be found in the work of a little-known, but influential, nonprofit foundation called the Jericho Forum (www.opengroup.org/jericho/). The Jericho Forum membership, which includes the senior management of some of the largest corporations in the world, propose a security architecture called “de-perimeterization.”
De-perimeterization was probably a poor choice of words by the forum because to many people, it sounds like tearing down the boundaries between systems and mixing the PLC with the receptionist’s desktop in a big homogeneous network. In practice it means anything but—systems continue to be separated into distinct zones and separated by technologies such as boundary firewalls. What is unique about the Jericho philosophy is that the limitations of boundary firewalls are explicitly recognized, and every component in the network is designed to be independently secure. In other words, while boundary firewalls continue to provide basic network protection, individual systems and data must also become capable of protecting themselves. This provides the system multiple layers of security protection or what is often referred to as defense-in-depth.
The Jericho Commandments
Jericho security architectures are based on a number of fundamental design commandments, a few of which we will discuss here. The first is “the scope and level of protection should be specific and appropriate to the asset at risk.”
|
In the control system world, we do a terrible job of this—we put protection where it is easiest to install, not where it is really needed. Since firewall software is easy to install on a desktop, but hard to provide for on a PLC, the average corporate desktop is far more secure than the average PLC. Yet the PLC is the asset that is far more valuable to company.
Even when better security could be easily achieved, we miss opportunities. For example, many PLCs are left with their factory default passwords, a practice never allowed in well-managed IT systems.
The second commandment is “security mechanisms must be pervasive, simple, scalable and easy to manage.”
Unnecessary complexity is a threat to good security. It both leaves openings for the attacker and frustrates the users. This means a single security mechanism that can scale from small objects to large groups is far preferable to separate systems, as users have to learn only one system. In addition, the closer the protection is to the asset, the better the protection is. In other words, protection at the device is better than protection several layers above the device.
The final Jericho command is probably the most important: “All devices must be capable of maintaining their security policy on an untrusted network.” This simply means that any device on a network must be capable of surviving on the raw Internet; i.e., it will not break, regardless of what is thrown at it. This is simply not the case today—too may control products cannot even be scanned without failing—but true security robustness is what we need to work toward.
Protecting Your Plant
What does all this mean to the control engineer trying to protect his or her control system? The first commandment tells us that an asset inventory and risk analysis of all the equipment on the control network is needed to identify the most critical assets. Once you know what is really critical to the safety and operation of your process, you can start to protect the appropriate devices.
Next, following the second commandment, a simple and scalable security strategy needs to be created to protect those critical assets. Ideally it should be deployed in the device needing protection or as close to it as possible. In the case of Windows-based PCs, this is relatively easy to achieve today—most vendors now allow patching, personal firewall and antivirus software to be installed on their process PCs. For non-Windows-based devices, such as PLCs or DCS controllers, things are harder, but not impossible. The new generation of field-deployable security appliances from companies such as MTL and Siemens let users put security protection directly in front of their controllers.
What Needs to Happen in Industry
The third commandment really needs to be addressed by the industry as a whole. Today’s control products and protocols were simply not designed to survive even the most trivial network attack. In order to get them to the point where they are truly robust, three things must happen. First, the concept of security robustness in control products needs to be demanded by the customer and designed in by the vendor. Adding it as an afterthought is not effective.
Second, control devices and applications must start to communicate using open, secure protocols instead of the completely insecure ones we use today. This means that both vendors and industry standards bodies need to revisit the protocols we currently use and start creating truly secure versions. We are seeing some progress in that direction by bodies such as the OPC Foundation and the IEC 61850 committees.
Finally, there needs to be the creation of both standards and open certification processes that can ensure end users that they are purchasing inherently secure control protocols and control systems. Efforts like the ISA-SP99’s Working Group #4 on “Specific Requirements for Industrial Automation and Control Systems” and the ISA Security Compliance Institute (ICSI) are good steps in this direction.
It’s Going to Get Worse before It Gets Better
The controls industry is on the verge of an explosion in the use of Web-based protocols (like OPC UA) that can tunnel through firewalls because of their HTTP wrappings. At the same time, control information is increasingly being sent between business sites and organizations over shared and third-party networks using technologies such as virtual private networks (VPN). This means that the breakdown of the traditional distinction between the “outside” network and the “control network” is inevitable.
As an industry, we know that any design based on a single point of failure is a bad design. We have learned that in the design of our safety systems. Now we just have to take the lesson to heart in the design of security systems. Ultimately, the only reliable security strategy is one that protects the critical device and the control information, rather than the network infrastructure. This can only be achieved through multiple layers of security and truly secure products and protocols.
Part 1 of this story appeared in the December, 2007, issue of Control.
Wolves at the Door(s) of the House of Straw
Eric J. Byres, PE, is principal at Byres Security, Inc. He can be reached at [email protected]
