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.
This Part 3 covers what PLC vendors should do.
Tomorrow the final part will cover what governments and standards organizations should do.
PLC Vendors
Eric Byres and others have written that it is not solely the vendors fault since they are in the business to sell product and make money. They will provide customers with what Asset Owners will pay for, and to date this has not been security. Our hope is that Project Basecamp will be a catalyst that will have large numbers of Asset Owners demanding a robust and secure PLC.
Security should actually be a boon for PLC vendors because Asset Owners will need to replace existing PLC’s much sooner than they normally would. Someday, hopefully soon, a smart VP in a PLC vendor will wake up and say we have a big upside opportunity here. Individual vendors cannot be individually blamed for the current situation because almost all have the same problem. What is required is an option for their customers to move forward if they care about process availability and integrity. The lack of a credible plan by most vendors, even three years out, is very depressing. Siemens has no announced plan, neither does Schneider or Rockwell. These three vendors alone have a massive installed base in the critical infrastructure.
So what should a vendor do?
- Figure out if the current products have a future in a world that requires a robust and secure PLC.
- If the software, hardware and architecture support upgrade, define the security controls that will be offered, when they will be available, what the cost is, and how the upgrade will occur. It may be a phased upgrade with tiers of security controls available over time. The Asset Owners can then decide when and if to upgrade.
- If a new product is required, hello GE, define the security controls in the new product, when it will be available, and what the cost is. The security bar is higher if an Asset Owner is going to retire a PLC made obsolete by security early. I would highly encourage a threat model be developed to drive the security control design.
- Document and implement your security development lifecycle (SDL). Customers and prospects will want to see the documentation and proof that is actually being followed.
- Insure the SDL includes fuzz testing for communication stack robustness.
- Consider submitting the product to ISASecure testing at Level 2. It’s by far the best PLC certification to date.
It’s all basic, right? Time to get started. We would be pleased to publicize any vendors efforts to add security to their field devices.
We need to provide another article on threat modeling and required and recommended PLC security controls, but at this point we are at zero with PLC security so substantial near term improvement in product capabilities shouldn’t wait until the entire ICS community agrees on every security control required in a PLC.
The most important item for vendors is to have a credible security plan moving forward, be straightforward about what it is, and implement it.
Image by MShades