ICS Vendor In Denial?
What Is A Vendor’s Security Responsibility?
Joe Weiss wrote last week about an ICS product “vulnerability” and what he viewed as an inadequate vendor response.
MSI performed a demonstration of hacking an SEL751A relay and then taking control of a motor. The demonstration not only showed how the system could be hacked and the operator “blinded” but also offered a solution. Attendees asked if SEL was informed of this vulnerability. Both MSI and myself contacted SEL. What was very disappointing was an SEL conference attendee, under the pretense of asking a question, told the audience the test was rigged to make the relay fail. This was absolutely not the case! The next presentation was by Indegy of a vulnerability in the Schneider Modicon PLC software-based simulator. This was a success case as Indegy found the vulnerability, disclosed the vulnerability to Schneider and, Schneider provided a fix in an expedited time frame. Without intending to, the back-to-back presentations illustrated the difference between an ICS vendor and security researcher working together to resolve a vulnerability and an ICS vendor in denial.
The SEL-751A is not a secure product. It relies on insecure by design protocols for monitoring and control, and it uses the cleartext Telnet protocol for management. Bad things will happen if an adversary can access this device. This is not in dispute.
SEL has addressed this by introducing a number of security products that can secure the communication to one or more SEL-751A. In fact they have been a leader in introducing security solutions for substation and other environments their products serve. The company that presented the SEL-751A vulnerability and which Joe is an advisor, MSI, apparently makes a product that also can layer security on top of communications to an insecure relay. It may or may not be better than what SEL offers; we have not done a head-to-head analysis.
This leads to the question: What are a vendor’s responsibilities for securing their ICS offerings? There are at least two.
Responsibility 1: Provide clear and honest security claims
While most loyal readers are security true-believers, the majority of ICS asset owners do not care about security today. They will not spend an extra dime for security and even if you provide it for free they will choose to leave it in the insecure default or even turn it off.
Hopefully security is part of an informed risk management decision, but the vendor cannot force that. The best the vendor can do is provide the information clearly so the customer can select and purchase the security they determine is required. When we get involved on either the vendor or asset owner side we break this down into security claims and then evidence to prove the claim is met.
There are lies of commission and lies of omission. Is a vendor required to tell you that there product is insecure? Or are they covered simply by not stating it is secure?
Reid went through a teardown of serial-to-ethernet gateways at S4xJapan, see the video. It was ugly as you can see in the summary chart below. The Digi One SP had some serious issues, although it was not the least secure. The Digi response to the vulnerabilities was that it “was not meant to be a secure device”, they were not going to fix the vulnerabilities, they continue to sell the product, and customers should purchase one of their other devices if security was important.
While I don’t like this answer, it would meet Responsibility 1 if it is clear that this product offers no security / has no security claims. Unfortunately the Digi site is silent on this, at best a lie of omission.
Going back to the SEL-751A example, how clear is it that the SEL-751A does not have security claims and another product should be purchased if security is required? Much like the Digi example, the SEL-751A information is largely silent on security, there is one vague reference to “integration and communications features for secure remote access”.
While you could unknowingly buy a vulnerable relay if you looked at the SEL-751A documentation, a utility that was looking to see what secure solutions are available from SEL would find a lot of information to help them design and purchase a secured solution.
Responsibility 2: Offer A Secure Solution
And the subhead should probably be — and you can charge for it. There is a cost to the vendor in developing, installing and supporting cyber security features. It is entirely appropriate for a vendor or integrator to charge for security. Responsibility 2 only requires that the secure solution be available for purchase.
We are seeing this as a huge issue in deployments. The vendor does not work securing the ICS throughout the project lifecycle into the project cost and gets caught in a bad business situation. It often results in the ICS vendor’s deployment team violating their company’s documented security recommendations. It would again be entirely appropriate for secure deployment to be one or more line item in the contract.
SEL is meeting Responsibility 2. In fact, they have been a leader in their segment in offering secure solutions and supporting research efforts.
Vendor(s) In Denial
Joe, in my view, is wrong in this case. SEL is not in denial. They understand the SEL-751A is not secure and provide security solutions to address its deficiencies.
SEL could be more clear in their products that are known to be insecure and are not being directly fixed. For example the datasheets could have a security section stating the product is not secure and products x and y should be purchased to add security if required. SEL is far from the worst offender in the omission area, and it may be an area where some sort of standard disclosures might be helpful.