hiring
AAA  AAA 

A Legacy of Insecurity & the Control System Lifecycle

The classic definition of the cornerstones of information security are:

  • Confidentiality, meaning that the data that you send or receive can not be read by others.
  • Integrity, the data is valid, has not been tampered with and originates from the authenticate source.
  • Availability, the data is available when it is needed.

When we apply these criteria to control system environments we see that only one of these elements, availability, is present. Control systems were designed with availability as the overriding criteria to such an extent, because of the nature of the environments in which they existed in the past, they seemingly ignore the other two criteria.

The majority of control systems do a very poor job with data confidentiality and integrity. This is especially true when these criteria are applied to the huge legacy system install base.The devices that communicate on the network lack the computational horse power to ensure confidentiality through encryption, and integrity through strong authentication and hashing.

They (the communication protocols “spoken” by control systems) were never designed to provide security, and in their current state of old serial protocols wrapped in TCP/IP wrappers then sent across the network, they are almost universally in some way exposed to outside environments, be it exposure to the corporate network, a DMZ, or in the worst case directly to the internet.

The main impetus for ignoring security considerations was that the communications were not exposed to the outside in any way.  Besides, “no one but system engineers understand these protocols any way.” The old panacea of security through obscurity.

And so the industry is left with Defense in Depth. An approach by which multiple layers or perimeter defense leave control systems like a good piece of candy, a hard crunchy exterior and a soft chewy center. And at times because of mis-configurations, poor planning and poor execution the hard exterior is even missing.

In many situations the most difficult aspect of Defense in Depth based perimeter security is correctly identifying the perimeter and what assets to actually defend. An asset owner may have good firewall policies for both ingress and egress into the control system environment from “normal”channels, yet have poor if any defense for wireless devices installed at a remote substation, or no authentication required on dial in connections.

As most of these products have roughly a 20 year life cycle perimeter control becomes the only remedy against cyber intrusion. A peroiod exacerbated by the fact that the perimeter is vanishing, as stated by many industry pundits [see here & here].

The majority of legacy systems have weak, if any, authentication, clear text password exchanges, rampant use of default passwords and accounts. They have no integrity controls. Because of the nature of the legacy systems once an attacker has a toe hold into a control system network he already “owns” the network. If the Defense in Depth fails, the control system becomes a playground.

And yet little is being done do remedy these inherit weaknesses in upcoming products. As the preponderance of the industry is based on long entrenched legacy systems, new products have to be backward compatible, which ensures, rather than cures the inherent problems in control system security. Some new products even exasperate the situation by offering a myriad of outward looking TCP/IP services in the PR jargon of user friendliness.

The cost to completely revamping these systems and replacing them with systems where true security is a guiding design principle is incredibly prohibitive. And who should bear these costs? Vendors, the federal government, asset owners and in turn consumers? No one wants to shoulder the costs of revamping the infrastructure.

As the consequences to attacks against these systems are so much greater than your normal “hack” (people can actually die as the result of a control system attack, a consequence more disturbing than having to clean up a credit mess in the case of cyber identity theft), the “risk” of such an attack is also greater. 

Is Defense in Depth then sufficient?  Do multiple layers of perimeter defense cure the inherent weaknesses at the core of control system technology?  They seem at best a buffer against a portion of attackers, and at worst when poorly implemented a mere speed bump, but how long until inherently secure communication protocols become the industry standard? 

Comments

Comment from Bryan Owen
Time: July 8, 2008, 7:04 pm

Does an inherently secure communication protocol exist in context of a 20+ year lifecycle?

Good chance that defense in depth, in some form, is a requirement; at least until the application layer is highly serviceable.

It’s good to see standards and mandates that require security servicing of the host layer.

Comment from Ralph Langner
Time: July 9, 2008, 4:30 am

Defense in depth got to be sufficient. Just think about what the field level will look like in 10 years: RTUs, sensors, actuators all connected to Ethernet — using some protocol like Ethernet/IP, EtherCAT, Ethernet Powerlink, or Profinet. Would anybody mandate to authenticate and encrypt communication with a field device? Probably not — we better had made sure that all data exchange is legitimate at a higher level. The same can be argued for PLC access. In my opinion, it does not make sense to target for secure end-to-end communication with every peripheral. Security zones must be established at a higher level.

Besides that, any secure protocol will have to conform to some (yet to be defined) standard, and after that, market players will wait for several more years to see if the standard gets acceptance. (Remember, OPC became widely accepted about 10 years after the first spec, and at a time when DCOM was obsoleted by Microsoft.) Implementation in products will take several more years. So anybody advocating for a secure protocol standard still has to answer the question what to do in the next 10 or 15 years until such a standard will possibly be adopted in the real world.

Comment from Kevin Lackey
Time: July 9, 2008, 9:57 am

Ralph,
In some ways I agree. There is no real need for encrypted communications to field devices, but some strong schema that guarantees integrity & authenticity (ie that the packet hasn’t been tampered with and that it actually originates from an “authentic” source) such as is seen in the ipsec standard would greatly diminish the ease of mim, ip spoofing and such attacks if an attacker penetrates into the control system. Such a schema would also not require the cpu horse power of full encryption and should be in the realm of possibility in the next generation of field devices.

Kevin

Comment from Bryan Owen
Time: July 9, 2008, 11:22 am

There is little doubt industry will eventually adopt new technologies and security is an important premis in design of modern solutions.

Regardless, a given implementation (inherently secure or not) is not immune to bugs, dependencies and flaws over the course of 20+ years.

To reiterate, a highly serviceable design is a prerequisite for realization of security performance over the lifecycle.

I agree there are many opportunities to improve (such as a more secure communications protocol) but risks (and associated cost) of making any change is frequently too high.

Highly serviceable design and implementation needs to be a priority for real progress over the long term. Unfortunately, serviceability solutions likely expose additional attack surface.

The recently disclosed Permanent Denial Of Service attacks further highlight the need to elevate serviceability with respect to security. Sidenote: DHS has a brief on these attacks.

Write a comment