Loyal blog readers know that PLC security is a focus of Digital Bond and a passion of mine. The proponents of defense in depth are selling a mirage if the critical endpoint can’t be secured. Project Basecamp and other researcher disclosures have made this abundantly clear that attackers can use the insecure by design features to compromise the availability and integrity of most deployed PLC’s, RTU’s and other field devices.

Thankfully, this is beginning to change. A number of vendors have announced and are shipping PLC’s with some security features. But we are wary, with good reason, of the actual effectiveness of the security features. A lot more technical detail is required to determine if the security design is sound, and of course independent testing to determine the implementation followed good security practices.

We are trying to use our Unsolicited Response podcast to dig into those technical details and have invitations out to a number of vendors touting new security features. As you can imagine, vendors are a bit wary given our frequent harping on PLC security and vendor shoddy security practices.

Siemens, to their great credit, is the first vendor to step up and answer technical questions regarding the new security features in their S7-1500 PLC and TIA Portal.

Siemens has helpful videos on their site that show at a high level the four new security features:

  • Access Protections
  • Manipulation Protection
  • Know How Protection
  • Copy Protection

In the podcast I tried to dig into these features. There were three themes that came up repeatedly.

  1. Was the security enforced on the HMI/EWS or on the PLC? A common flaw in ICS security design (and client/server design) is to perform the security solely on the client. An attacker can then circumvent the security by going directly to the PLC. While there still is some confusion after the conversation, it appears the authentication happens on both the HMI/EWS and the PLC. Access protection authorization appears to only be performed on the HMI/EWS, which would mean escalation of privilege is possible.
  2. What crypto algorithms and protocols were used? Crypto is hard, and proprietary solutions have a very bad history. The broad approach was sound — use public key algorithms to negotiate a key used in a symmetric algorithm. Tom and Alan didn’t have the details in their heads, which is not surprising unless you live with crypto on an ongoing basis. This is an example of where vendors are going to need to up their security documentation as they roll out security features. I also have a lingering concern on how the public key certificates are handled. Do they have the same problem OPC UA has where the default allows anyone to exchange and trust certificates? What is required for an asset owner to handle certificate life cycle issues?
  3. Are the software components Siemens, 3rd party or a combination. For example, is the web server Siemens or ? This also tied into the crypto components.

Siemens has hit the mark when it comes to the required security features, especially access protection and manipulation protection. They have also done some good and some bad secure by default implementation. For example, the web server is off by default, but the Everybody user has access if the web server is turned on.

The podcast helped provide more technical detail, and hopefully Siemens will identify some gaps in documentation and information from the podcast and fill them. This will allow the security design to be analyzed and a view of the value of the new features.

If you listen to this or other Digital Bond podcasts, you will see we try to elicit information and opinions. They are not 60 Minutes, gotcha interviews. We even let interviewees re-record answers if they don’t feel they said it right the first time. Hopefully we will get more vendors on to discuss technical details of their security in the near future.