Blaming Vendors Doesn’t Fix Today’s SCADA Security Issues

Submitted by Eric Byres on Mon, 2011-06-20 09:59

Last week in his blog article, Fix the Problem, Stop Bailing out Vendors, Dale Peterson made an impassioned statement that the SCADA security community:

“needs to put all our efforts and emphasis in the PLC, RTU, controller space on getting vendors to add basic security features to their models available for sale today… We should not say or pretend that any other solution besides this is acceptable. Fix the problem!”

He went on to say that I, (along with Joel Langill of SCADAhacker.com) am mistaken to speak about Stuxnet at the upcoming Siemens Automation Summit since:

“The last message that needs to be delivered at a Siemens User Group is that all will be ok because you can deploy NAC technology, set of IDS signatures, or Tofino field firewall and be secure. This is not to knock those or any other compensating controls. These are worthwhile presentations in other venues, but definitely not the message to deliver at any user group meeting where the vendor continues to ignore designing basic security features into even their flagship, new controller product lines.”

Vendors are NOT off the Hook

I agree that we should not be letting the PLC / DCS / SCADA vendors off the hook with regards to security. Letting Siemens off easy certainly will not be my message to the attendees at the Siemens Summit in Orlando. To their credit, Siemens did not place any restrictions on my talk.

To even invite me to speak at their event is commendable - I have not been particularly kind in my criticism of Siemens disclosure process during the whole S7-1200 vulnerability issue. For example, see my recent blog post “Protecting Siemens S7-1200 PLCs against Security Vulnerabilities, Part 3/3”.  I don’t intend to hold back at this event either.

The Goal is to Improve Overall ICS and SCADA Security

What I want to do is to improve the overall security of SCADA and ICS through as many channels as possible. I believe that Stuxnet has a lot to teach the operators of control systems on where the failings are in typical control system architectures, security processes and products.

Certainly Siemens has to take some responsibility for the security short comings in their product, but the process designer, the integrator, and end-user also must accept their share of responsibility. After all, end-users could have demanded secure systems a decade ago via their RFPs. For a number of reasons they did not and still don’t.

We Need to Learn from Stuxnet – The Bad Guys certainly are!

In my opinion, it is best that we use Stuxnet (and other worms) as an opportunity to learn the realities of ICS security and how the responsibilities for security need to be assigned.

For example, Dale brings up the very valid point of the fantasy of the air gap (which is a topic I plan to discuss in depth in a future blog). Vendors should not hide behind the air gap fantasy in their security notices, but neither should end users when they talk to their management about security risks or integrators when they design a control system. The entire industry needs to move past the myth of air gaps and learn to deal with the reality of connected SCADA and ICS systems. Stuxnet is an excellent vehicle to drive that point home.

In an ideal world, any other solution besides more secure PLC products would be unacceptable. Unfortunately, we all know that creating a truly well-designed and secure product takes a lot of time. It takes even more time for the end-users to deploy these patches and/or new products in the field.

Control System Owners need Compensating Controls

Thus the world is stuck with insecure legacy systems for many years to come. And while we wait for truly secure ICS / SCADA products (a holy grail if there ever was one), the end user needs compensating controls to mitigate the risks present in today’s systems. End users also need to understand where they need to focus their efforts – no one has unlimited resources, so clear guidance in this area is also important.

It is these three messages:

  • what control system owners can learn from Stuxnet,
  • what they can do to mitigate current security failings, and
  • what they need to focus on

that I hope people will take away from our presentation on June 28th.

The bottom line:  I completely agree with Dale that ICS and SCADA vendors need to be held accountable for the security of their products, and they need to fix problems a lot faster.  However, I also believe that control system owners need to be using compensating controls until the day that secure products are available AND deployed.

Related Links

 

RSS Feed Subscribe to the "Practical SCADA Security" news feed

Comments

3
Submitted by Bryan Owen (not verified) on Mon, 2011-06-20 14:53

There are good points on both sides of this issue.

However this closing bit touched a nerve:

"Unfortunately, we all know that creating a truly well-designed and secure product takes a lot of time. It takes even more time for the end-users to deploy these patches and/or new products in the field."

While initially focus on chemical sector issues, IST offers principles that readily apply to generic ICS security.

It's unlikely any technology is inherently more secure with respect to all hazards. We should consider security in context of iterative changes.

o First Order – Completely eliminates a particular hazard. Note that this does not say anything about the impact on other hazards, which may be increased, decreased, or remain unaffected by the change.

o Second Order – Reduces the magnitude of a hazard, or makes a potential accident associated with a hazard less likely to occur, or less severe, by means of equipment and process design but not through add-on safety devices.

o Layers of Protection – When all of the multiple hazards associated with any technology are considered, layers of protection will always be required as a part of the total risk management program. These layers may be made more reliable and robust through the application of principles of inherent safety.

Source: AIChE definition of Inherently Safer Technology http://tinyurl.com/3vdn4f5

Submitted by Joel (SCADAhack... (not verified) on Wed, 2011-06-22 18:16

I agree completely with Eric, and do not understand why Dale thinks the situation can change overnight. Compensating controls are absent from ICS architectures today, and owners need to realize this and implemented them if they want any chance of reducing the risk of a successful cyber attack against their ICS and associated infrastructure.

Unlike changing all PLCs today, or complaining to vendors where you will most like here that there is little that can be done to the massive amount of installed legacy equipment, compensating controls (like industrial firewall solutions and network behavior analysis and IDS tools) can be implemented overnight at a very reasonable price.

Submitted by Amyhngj10 (not verified) on Fri, 2013-12-20 02:27

This is the first time I am reading about this SCADA Security Community. The issues that are being faced can be still solved without blaming the vendors I think. I would love to know in details about the issues. Anyways, thanks for the share.

Add new comment