What ARE the vendors really building?

The major control system suppliers are claiming they provide tested secure DCS and SCADA systems. To my knowledge, at least four major control system suppliers, in this case 3 DCS and one SCADA, are providing less security than advertized. In one DCS case, the vendor told me how secure their system was and specifically identified one showcase utility. Unfortunately for them, I knew the utility and the utility engineer. The engineer was so disappointed in the vendor not listening to his needs he made a presentation on security deficiencies the vendor would not address. In the second case from a different DCS vendor, the vendor recently performed factory acceptance testing without security being addressed even though I was told by the supplier that security testing is standard procedure. In the third case from another DCS vendor, the DCS is currently being procured and staged. The vendor claims they automatically secure their systems. However, when the utility engineer questioned the vendor, the vendor stated they would need additional funding for security and even asked the utility to delay the implementation to address security. In the SCADA case, the vendor was using the full suite of Microsoft web services without recognizing the security implications. What is really going on with our vendors? Joe Weiss
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>There are certainly claims by vendors that they are providing some security features and have taken some steps to enhance system security. Some of the claims are specific to firewalls, anti-virus, and operating system patches. I’ve not personally seen a claim that any vendor sells a “tested secure DCS or SCADA” system. I’d object to that claim, making the argument that there is no rubber stamp for a secure system. I have seen marketing material for various vendors advertising security features, but not a completely secured system “out of the box.”</p> <p>Sure, vendors love to showcase some of the installations in which security technologies were deployed, but I doubt they intend to claim the entire system is “secure.” I for one have presented on several architectures we have deployed at various clients – never using that ole “This system made secured by XYL” stamp.</p> <p>On the issue of acceptance testing, vendors and their clients need to work together to develop the security criteria for the FAT/SAT process. Some vendors do normal check-out steps such as updating the latest operating system patches and anti-virus clients. Admittedly, there is much work to be done by all. Despite the best check-out procedures and acceptance criteria, the system having been through these processes cannot be stamped secure. Security needs to be built into the project lifecycle early on and continued throughout the duration of the system’s existence.</p> <p>If a vendor claims they automatically secure their system, the question needs to be asked to determine what criteria they’re using to claim “secure” status. Many times an assumption is made by people within a vendor who are not even remotely well-versed in security that their system is secure. Sometimes that assumption is made because anti-virus is installed, patches are being tested, and unfortunately, even because UNIX is being used. The lesson here – making assumptions about security leads to heartache and disappointment.</p> <p>Sometimes it’s the end user that makes an assumption that security is built into the system. Maybe they heard a vendor talking about security features at a conference or maybe they read a white paper from a vendor. Often, the people who become the asset owners in the long-term don’t get to make their voice heard that security should be inherent in the system. When the delivered system comes to them, they ask “where is the security?” The answer, which is not often pretty, is that security was not put into the procurement language. Maybe the 300+ page specification contained four paragraphs under the guise of “security,” if the end-user is lucky.</p> <p>Something to be considered is that securing the DCS/SCADA system does not mean securing the overall infrastructure. The DCS/SCADA system is only a piece of the assets that comprise the facility. When vendors talk about their systems, some of them are referring to the traditional DCS components while others look at it more holistically. There are vendors who are strictly system focused and there are others who do look at the infrastructure around their systems.</p> <p>So what needs to be done? - Clients should clarify with the vendors what security means to them (both directions). - Clients need to clearly state their security requirements in their RFP’s. - Vendors should be up-front about what security features are installed in the default system. - Vendors need to respond to customer RFP’s honestly with regards to security requirements and specifications.</p>


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