Mar 9, 2021
If you find yourself in a hole, stop digging.
Will Rogers
The large amount of insecure legacy ICS and long ICS lifetimes mean we will need to live with this security risk for years / decades. We can argue about how long it should take to replace the deployed insecure-by-design ICS, but there is no disagreement that it is a huge problem. A big hole. Which is why it is so disappointing that we keep digging.
This was brought to mind again in a tweet from Joe Weiss's session at the SANS ICS Security Summit last week.
The key is that less sentence correctly pointing out that almost all systems deployed today add to the "legacy system" problem because they still have insecure-by-design PLC's / controllers and are using ICS protocols lacking authentication.
Back in 2013 in my S4 introduction (see video clip below), I bemoaned the fact we have been hearing it will take decades to address the legacy system security problem in ICS every year since I was first involved back in 2000. By 2013, we had made virtually no progress in dealing with insecure-by-design Level 1 devices or unauthenticated ICS protocols. We were still decades away from solving it, and the problem had gotten much larger with more "legacy systems" being installed over those 13 years.
The theme of S4x13 was NOW!, and the tag line was "If not us, who? If not now, when?"
https://youtu.be/bZLbm7J2E8o
It's now eight years after the NOW! themed S4x13 event, and we can look at what has occurred over those eight years optimistically or pessimistically.
The pessimist's side is easier. Over those eight years 99%+ of the ICS deployed have insecure-by-design PLC's/Level 1 devices and use unauthenticated ICS protocols. Access inside the perimeter = compromise only limited by the engineering and automation skills of the attacker, and the capabilities of the Level 0 connected devices. We have increased the 'legacy system' problem with eight years of ICS deployments. We are still digging that hole.
The optimist's side is some of the Level 1 device vendors and some of the ICS protocol groups have addressed the problem. There are now encrypted and authenticated versions of many ICS protocols. There are also now PLC's that have signed firmware, secure boot, support for secure ICS protocols, and authentication of operation and administrative functions.
Is it perfect? Of course it isn't. In some cases these PLC's carry with them a lot of legacy code. It's analogous to the Microsoft challenge after Bill Gates' Secure Computing memo. Yes, there can be a lot of improvement in the short run, and there is still a multi-year grind until that old legacy code is replaced.
Some of the key vendors have invested in development to have, at a minimum, a non-insecure-by-design offering. And more are near release. Now it is the asset owners' turn. The asset owners have to show they want to move away from insecure-by-design systems and reduce the associated ICS cyber risk.
Is circa 2021 when we stop digging the hole? Stop increasing the "legacy system" problem?
It is too soon to tell, but early signs show very little uptake to the available security capabilities. Asset owners aren't asking for them, integrators are designing them in, and vendors aren't pushing them. Features such as signed firmware do not require asset owner action and will be a clear win, but the secure protocols and user / device authentication do. They add complexity to the project and ongoing operation. The features often make the product more expensive as well.
The answer is likely, if security is deployed at all, to be sector and asset owner size specific. There may be a sector, such as large petrochemical, that may adopt this move away from insecure-by-design while other sectors continue with the status quo. Even this limited progress would be a big step forward as we have seen other ICS security practices trickle down from more security conscious sectors to the less security conscious sectors.
If the asset owners don't purchase and deploy the more secure versions, then there is little impetus for a for-profit vendor to spend resources developing, marketing and supporting security features.
The other option would be for the regulators to step in and require ICS being sold into certain sectors have certain security features. This would be difficult to do well, and it's a whole other article.