Purchasing Language for SCADA systems…

Todd Stauffer of Siemens and I were discussing the need for critical engineering understanding when applying cybersecurity tools to plant level DCS and SCADA security the other day. Todd reminded me of the fact that there's a government funded organization called the Multi-State Information Sharing and Analysis Center that has produced a soi-disant set of procurement language for SCADA systems that is intended to help end users and EPCs ensure an appropriate level of cybersecurity when they buy and specify SCADA systems. I assume this also applies to DCS systems and simpler plant control systems. MSISAC is a venture of the State of New York and Idaho National Laboratory (INL). Yes, those people who brought you the Aurora video. MSISAC has posted several iterations of their recommended language document which they hope somebody will take and incorporate into real specifications for how to design and purchase cybersecure SCADA systems. What Todd and I were talking about was the need to actually know something about plant and utility control systems before attempting to use this document, in any of its iterations. Todd pointed out that it is entirely possible to specify ALL of the options in the documents, thus making it impossible to actually procure a system at all. What has to happen, when you use documents like this, is you have to have the engineering expertise and sound engineering judgement to be able to use the documents as a template, a framework, and not a stencil. We also noted in passing Boeing's problems with interconnected networks and the new 787 Dreamliner. I have previously noted, in Sound Off! about the folks from Boeing who spoke at ARC...who said that engineers wanted to be able to flash the solid state memories of the avionics systems anytime they wanted to--- and I hope I'm never on a 787 if they are allowed to log onto the avionics and flash the ROMs when the plane is at 40,000 feet. Walt Boyes
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • <p>Hi Joe,</p> <p>This is going to be a lengthy Post. Unfortunately your comment on the procurement language hits many very raw nerves with me, to put it simply, however, I will try and be as brief as I can.</p> <p>Please understand at the outset this is in no way an attack personal or otherwise to yourself or Todd. It certainly has evoked a response from me. This is possibly your actual intent - to raise more discussion on the document. I think there are better more positive ways to achieve the same outcome!</p> <p>For a start so people don't have to read the entire document, excerpts From the procurement language....</p> <p>“The goal is for federal, state, and local asset owners and regulators to come together using these procurement requirements and to maximize the collective buying power to help ensure that security is integrated into control systems.”</p> <p>“The purpose of this document is to summarize security principles that should be considered when designing and procuring control systems products (software, systems, and networks) and provide example language to incorporate into specifications, which addresses these concerns. The guidance is offered as a resource for informative use—it is not intended as a policy or standard.”</p> <p>“The user should be encouraged to work with the vendor(s) to identify risk mitigation strategies specific to their system that may include solutions outside of those presented in this document. The vendor could be a valuable resource to the purchaser as many are considered industry experts. It is not the intention of this document to discount the expertise of the system vendors.”</p> <p>With these highlighted sections in mind I am puzzled how the conclusion posted is logically reached? I think the comments posted are what I would describe as a blinkered, possibly even a stilted view, completely missing the concepts, intended use and target audience of the document clearly defined in the quoted sections.</p> <p>I am actually quite sad upon reflection that such intelligent people miss the full value and potential of this document, and not appreciate it for what it can be used for. At the very least this is not reflected in your posting.</p> <p>It further detracts completely from what I consider are very valid concerns at the end of your post specifically about how and where the avionics industry, are/may be headed with “connected” flight control systems.</p>


  • <p>First off, Ron, it was MY post, not Joe's.</p> <p>Now, as to your issue. I'm not missing the value of this document. I think it is an excellent document. I, and Todd, am concerned that procurement specialists will do what happens often in the world of purchasing systems and field instruments, and incorporate the document into all procurement specifications...thus making it impossible for a vendor, any vendor, to provide a system, or a piece of hardware or set of software that meets the specs.</p> <p>This is another case of "anybody who works with SCADA systems" should know what they are doing.</p> <p>I don't fault the writers of the document, I was attempting to warn users of the document that they actually DO have to read the thing, digest what it says, and use the recommendations accordingly...exactly what the part of the document you quoted said.</p> <p>My fear is that it will be misused to forestall the process of thought.</p> <p>Walt</p>


  • <p>Hi Walt,</p> <p>I thought UNFETTERED was "Joe's space" and that posting content to this topic area was his editorial decision, as such I directed my comments to him.</p> <p>There is a great deal of negativity in either comment you have posted Walt and to say any further would be a waste of my energy and time.</p>


  • <p>Sometimes I post here, too. Sorry that wasn't clear. And I'm sorry you feel I am too negative. Didn't mean to be.</p> <p>Walt</p>


RSS feed for comments on this page | RSS feed for all comments