Schneider Vulnerabilities: Where are the ICS/SCADA End Users?
On December 12, Rubén Santamarta publicly announced details of multiple vulnerabilities affecting the Schneider Electric Quantum Ethernet Module. These are serious vulnerabilities, involving hard-coded passwords that give an attacker complete access to the device. As Reid Wightman puts it
These accounts let a user do *anything* to the device — they all have the same privileges. By anything, I mean: you can upload a new firmware to the device and use the Ethernet module in a Modicon as a general-purpose computer. Want to run Linux on it? That’s possible. Want to install extra tasks in the vxWorks image to, say, randomly twiddle input and output data? Also possible. It takes time, but it isn’t rocket science.
Leaving aside the technical issues involved and how to mitigate these vulnerabilities (I will discuss those in another blog), there are a number of interesting lessons to take from this event.
Vulnerability Disclosure: Getting A Few Things Right
First, this has been one SCADA/ICS vulnerability disclosure where all the parties involved seem to be doing their best with a bad situation. Rubin did share this information in advance with the ICS-CERT and Schneider Electric, giving Schneider several months to produce patches. And as Rubin himself states, Schneider is working hard to fix these bugs:
I would like to thank the ICS-CERT and the Schneider security team, they have taken these issues very seriously and are working on a patch. During the process they have been keeping me updated on every decision/progress.
From my vantage point, I have to agree. When the ICS-CERT Alert was published on Monday, it included a list of other Schneider products that had the same vulnerability, but which Rubin had not discovered. That is a nice bit of openness on Schneider’s part – something that has been lacking from previous disclosures we have seen.
As well, Schneider produced patches for two of the vulnerabilities in several of the products very quickly. It might seem like creating a patch should be easy, but in the embedded controller world it isn't. Since responsible vendors have to follow extensive quality assurance processes to ensure that patches don't impact all the existing products in the field, that takes time. After all, security isn’t the only consideration for a PLC; safety and reliability matter just as much (if not more). If rushed patches make customers nervous around possible downtime, they just won’t install them. That defeats the whole purpose of patches in the first place.
And Some Things Not So Right
Frankly, I am disappointed that Rubin released this disclosure before all the patches were ready. I don’t know what his timeline is, but would another month have made any difference to him? And making a disclosure as serious as this one two weeks before the holiday season? Even if all the patches were ready, most companies would not install them until the new year. So all this will achieve is giving every bad guy in the world three weeks to penetrate their favourite critical infrastructure, knowing that it won’t be secure until 2012 at the earliest.
Where are all the End Users?
But what has me worried the most is not hearing from the end users. They seem to be silent. I hear lots of yelling from the security researcher community, but the users of PLCs have said nothing. They don’t seem to be demanding security in their RFPs and they haven’t called out to their suppliers. The engineering and design teams for any vendor can only spend time on the features that customers demand. Everything else is a “nice-to-have”.
It is time that the ICS/SCADA end users start to make their voices heard regarding security. Until they make security part of their buying decisions, then we can’t expect secure control system products.
(Full Disclosure: The Hirschmann EAGLE Tofino, a product that uses our Tofino technology, is part of the Schneider Collaborative Partner Approved Products program. Schneider Electric also sometimes asks me for advice on ICS security.)
Related Content to Download
Note: you need to be a member of tofinosecurity.com and logged in to have access to the document below. Register here to become a member.
|
Article - "Safety and Security: Two Sides of the Same Coin"
|
Related Links
Other Practical SCADA Security Articles on Security Usability in SCADA and ICS
Comments
Schneider Vulnerabilities: Where are the ICS/SCADA End Users?
Possibly one of the reasons end users are not shouting about security is that, NERC CIP regs apart, there is generally no incentive to address the issue. No regulation stating end users have to develop and maintain a secure architecture. No penalty (other than bad press) if they fail. Under the cosh of other regulations, poor resourcing etc. is it any wonder its not high on anybody's list. They have other things to worry about. The mention of security in the lastest version of IEC61508 is a bit light but may supply some impetus in the long term provided inspectors raise the issue in audits/reviews. In the UK the govt does not want to mandate that this issue is addressed. I have this from the horses mouth so to speak at a recent seminar. If CNI is critical to the population then perhaps govt ought to take an interest and regulate. My tuppence worth.
ICS 'Patch Window'
Even with free and abundant resources to execute patching, scheduling is most often the rate limiting step for an ICS supporting application.
There are well known approaches, such as redundancy, to de-bottleneck this kind of scheduling issue.
In the meantime coordinating full disclosure to lag patch availability is a reasonable policy. Such a policy is not meant as a substitution for early warnings - in fact alerts with patch availability estimates can help with the scheduling issue.
As unpleasant as it is, bad news must travel fast. An early warning including workarounds and compensating controls seems appropriate.
Electric sector is one of the few with a feedback mechanism for alerts. Does anyone know if a NERC Alert was issued and if it required reporting?
Add new comment