SCADA Security Tap Dance

This week Siemens held its Automation Summit in Orlando, and security was heavy on the agenda. In an earlier blog I took to task Byres, Langill and other security guru’s, really top notch talent, for providing cover to a poorly performing vendor by attending, presenting and not focusing on rallying the users to force the vendor to do a better job. (Here is Eric Byres’ response, and I hope to have Eric on the July podcast for a friendly post-event debate because after the event our disagreement is likely even greater.)

I’ve been eagerly following the #AutomationSummit tweets the last 2.5 days. There were a lot of high quality security sessions on how to secure control systems, Stuxnet and other threats to control systems, …  This is to be expected because you had great ICS security talent invited to speak. I’m sure the attendees benefited from their presentations.

Siemens also used the occasion to highlight recent Siemens security initiatives, such as:

  • McAfee Whitelisting solution is compatible with the Simatic Windows components such as WinCC, PCS 7 and STEP 7. A very positive step.
  • Siemens providing ability to encrypt function block both in STEP7 project file and S7 CPU; this could be the most significant announcement — awaiting details
  • A new Siemens Automation Firewall Appliance based on Microsoft’s Threat Management Gateway
  • A Siemens Quick Assessment tool and security consulting service to help customers begin a security program

Sounds like some good items and positive steps there, but the details are needed for any serious analysis.

The tweeting coverage has basically been a Siemens cheerleading session summed up with Walt Boyes of the Automation Press tweeting.

The #siemens #automationsummit is over. Most important result was the highly motivated proactive holistic response to the challenge posed by Stuxnet. Dunno if they would have without the impetus of Stuxnet but #siemens appears to have leapfrogged the competition.

Leapfrogged the competition? I don’t think so. Proactive holistic response? That seemed to be one of the buzz phrases at the event. In fact right out of the keynote address. Yes a holistic approach is needed, as is defense-in-depth and a lot of other Security 101 principles. But given Siemens performance, or lack thereof, over the last year I would have hoped they had presentations that answered the hard security questions that only the vendor can answer. And if not, hopefully the security guru’s that were there held Siemens feet to the fire for answers, rather than just play along that all is well. Here is a partial list:

  • what processes has Siemens changed so they better inform customers on pertinent details of vulnerabilities and exploit code? They failed on Stuxnet to give basic fingerprinting and impact information to clients. Beresford vulnerability detail was misleading, to be charitable. What have they changed to get timely and straightforward information to the customer?
  • what has Siemens added to their security development lifecycle (SDL) so basic issues like malformed http request packets don’t cause an outage?
  • of course, what are they doing to address the vulnerable by design problem in the S7 controller family? Stuxnet, Ralph, Dillon and others have shown if you can ping it you can own it. The brief announcement of S7 encryption and authentication may address this. Details are needed.
  • what has Siemens added to their process so they work better with researchers who find and present them with vulnerabilities? The latest go around with Dillon in recent months was at best a partial fail by Siemens. Other ICS vendors have solved this problem and have a proven successful process in place.
  • Did Siemens go into details on the vulnerabilities and patches from the public Beresford findings? They have lost the credibility to have statements of all is fixed being accepted. Why didn’t they provide the patches to Beresford to verify they fixed the vulnerabilities?
  • Did Siemens prepare their users for the other Beresford vulnerabilities that will be revealed at Black Hat. In our podcast it was clear there were more than two vulns, and he had more to show. Siemens knows this information. Are they going to provide any info to customers?

Hopefully some or all of these questions were asked and answered. Perhaps they were and none of the security contingent chose to mention it. If it is not asked at this event, where would you ask it?

In Eric’s response to my entry he wrote,

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.

Can’t argue with that. However if a bunch of security guru’s and automation press give the impression at the User Group that Siemens is doing a great job on security, and they don’t ask the hard questions that a user, who has security as 10% or less of their job, doesn’t know to ask, aren’t they bailing out the vendor?

By stressing the need for proactive holistic security rather than saying “this is a Siemens User Group meeting and users need to demand Siemens answer these questions, tell us why this happened and how it is being fixed” aren’t they bailing out the vendor?

Too often we hear this isn’t a Siemens problem or security is not just a vendor problem. True if you discuss the overall effort to secure ICS. There are, however, many issues that are just Siemens problem. They should have been a focus at a Siemens User Group event.