After the pauldotcom webcast there were some twitter challenges and questions on what would make a PLC Secure By Design.

RT @chrissistrunk: @joshcorman ask Dale when does a controller device meet the “secure by design” stamp of approval? πŸ™‚ <- @digitalbond ?

β€” Joshua Corman (@joshcorman) October 25, 2013

The more I think about it, more I question – Who determines when “Insecure by Design” is now “Secure by Design”?

β€” SCADAhacker (@SCADAhacker) October 26, 2013

I’ll tackle that good question on when is a PLC Secure By Design in the next article, but the tweets demonstrate that Insecure By Design in ICS is not understood. I’m not surprised because it is hard to comprehend that critical infrastructure controllers are still Insecure By Design twelve years after 9/11.

Insecure By Design is not the defined by a lack of a successful Secure By Design process. No. Insecure By Design is when the vendor intentionally adds documented “features” to a product that provide an attacker with the capability to compromise the availability or integrity of the PLC and underlying process.

Our definition of Insecure By Design would not cover a lack of security coding practices, using vulnerable libraries, poor QA, lack of fuzz testing, threat modeling, etc. Those are real deficiencies that can lead to bugs and exploitable vulns. They are not however the vendor consciously deciding to add features that allow an attacker with logical access to take complete control of the controller or application.

A PLC is Insecure By Design when an attacker can use documented features to achieve his goals. Examples:

  • Stop CPU commands with no authentication for a loss of view and loss of control
  • Write requests with no authentication that allow an attacker to use protocol features to alter a process
  • Unauthenticated firmware and ladder logic upload. This can turn the PLC into an attack platform and change the underlying process a la Stuxnet.
  • Open administrative command shells, documented hard coded support accounts, …

We coined the term of Insecure By Design as part of Project Basecamp. Many in the community were upset that Digital Bond was disclosing so many PLC vulnerabilities, but they weren’t vulnerabilities in the sense of bugs and coding errors that could be exploited. They were documented features. We didn’t consider it vulnerability disclosure if the feature was defined in the protocol specification or user manual.

Ralph Langner gave one of my favorite ICSsec quotes related to this … “The pro’s don’t bother with vulnerabilities; they use features to compromise the ICS”. Most ICS vulnerabilities matter little because most ICS protocols and controllers are Insecure By Design. Great Mr. Vendor, you fixed a cross site scripting vuln in the PLC web interface but I can still upload firmware and logic, stop the device, change the process using published features.

Hopefully if you have made it this far you now realize there is a big chasm between Insecure By Design and Secure By Design. It should be a very low bar to clear to remove Insecure By Design features in ICS devices and applications, yet minimal progress has been made in over a decade.

So to answer Joel “SCADAhacker” Langill’s tweet — anyone who can identify a device or application feature that can be used as designed and documented to compromise the integrity or availability in an ICS can call Insecure By Design. I’m sure there are a couple of features we could argue about, but most of them are straightforward.

A PLC is not Secure By Design once the Insecure By Design features are removed. I’m not bold enough to think Digital Bond or any one organization can stamp a PLC as Secure By Design, but I have some thoughts on how to address this challenge. In the next article, I’ll tackle the question looking at the ISASecure certifications and digging out an older PLC Protection Profile we wrote for NIST/PCSRF.