Project Basecamp highlights the fragility and insecurity in most PLC’s and provides tools so anyone can demonstrate and prove it. There should be no doubt that after ten years the ICS community needs to deal with this, but how?
Part 1 covered what Asset Owners should do with new projects.
Part 2 covered what Asset Owners should do with already deployed projects.
Part 3 covered what vendors should do.
This article finishes the series with what Government and Standards Organizations should do.
Government Organizations
I’m going to focus on the US Government, but much of this applies to governments around the world. In the US, the government is not responsible for securing the private critical infrastructure — at least not yet. So they cannot be directly blamed for the lack of progress over the last ten years.
The US Government does however have tremendous influence on the conversation and what C-level executives feel they need to pay attention. For the past ten years, INL and the other labs under contract to the US Government have performed security assessments of most of the major DCS and SCADA systems. They have known that the PLC’s and field devices were fragile and insecure. They were unsuccessful in making any progress in this area, as was everyone else in the community. An argument for keeping the problem quiet so the bad guys don’t know about it was reasonable, albeit a mistake with 20-20 hindsight.
This is now over. Stuxnet and Beresford were eye openers to anyone, including the bad guys, looking. Project Basecamp took it the next step by providing easy proof of concept tools to exploit PLC’s. There is no reason for the INL/DHS/USG to be reticent any more.
Which is why the latest ICS-CERT Alert is so unfortunate. It appropriately covers the risk of PLC attacks (Basecamp and others) and Shodan type searches. But nowhere does it actually address the root cause, fragile and insecure PLC’s and other field devices. When is the US Government going to come out and say these are a significant risk and that critical infrastructure Asset Owners should be working on a near term plan (1 to 3 years) to replace them?
As Chris Jager tweeted, perhaps an ICS-CERT Alert is not the place for a major policy change. Wherever they choose to announce this obvious conclusion, it is time. If the US Government, who is supposedly the expert in all things ICS security, refuses to state this as a necessary and urgent step, it is much easier for a C-level executive to continue inaction. They can point to there efforts to follow the ICS-CERT alerts and DHS guidance, and still ignore the PLC problem.
DHS and other government agencies are political arms with political skills. How about flexing those political muscles and get the vendors a bit of heat? When you think of all the Congressional hearings and Presidential edicts, it is always pointed at the Asset Owners. It’s not hard to generate heat at a Senate hearing:
Mr. Vendor, how is it possible that your state of the art PLC that you are selling today for use in power plants, pipelines and chemical plants, that costs 10x more than a laptop computer, doesn’t even have basic security features that prevent an attacker from shutting down the critical infrastructure by sending the simple message ‘turn off’? Why does my ATM card, home PC and smartphone have more security than your product? …
I’m leery of any comprehensive security bill, regulation, or any other programmatic effort by the US Government being effective. The results to date don’t engender confidence to accomplish even simple tasks and goals. But putting out statements and generating heat is achievable, and actually something that Washington DC does well. It may be a bigger help than the other items in Senate 2105, DHS programs on information sharing or even repeating elsewhere published information in ICS-CERT Alerts.
Standards Organizations
In the first edition of this “What Should You Do” series, the obvious question of what security controls should be in PLC’s arose. Regrettably we are not able to point to a good standard or open process guideline document for recommended or required technical security controls in a PLC. Similarly there is no document like this for an HMI, Historian, EWS, SCADA/DCS Server, ICCP Server, Communications Server, … If you know of any efforts please put them in the comments or contact me directly.
This obvious point escaped me until I needed to find one. Most of the standards and guideline efforts to date have focused on broader security program issues, and this makes sense because technical controls on a component are not sufficient. In the correct assessment that administrative controls and system wide issues are important, the need for component level technical specifications seems to have been lost.
One or more standards organizations should jump on this missing part and create Technical Security Requirements for XXX Device standards or guideline documents.
There are some documents out there now for PLC’s:
- ISASecure’s Embedded Device Security Assurance (EDSA) requirement documents and certification program are the best out there today. They actually cover the Functional Requirements, Communications Robustness and Vendor Software Development Lifecycle. Strictly speaking they were not created by a standards body or open process. This doesn’t particularly bother me, but some in the industry give them less credence.
- IEEE P1686 covered security of IED’s in substations, but the requirements were very minimal.
- Our Field Device Protection Profile written for NIST’s PCSRF and the Plain English Equivalent. Note this is an older document and should be used as reference only.