Legacy System Problem Keeps Growing
Dale Peterson
ICS Security Catalyst, Founder of S4 Events, Consultant, Speaker, Podcaster, Get my newsletter friday.dale-peterson.com/signup
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?"
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.
It's The Asset Owners' Turn
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.
Consultant
3 å¹´As Nietzsche said: "And if thou gaze long into an abyss, the abyss will also gaze into thee.â€
Leader in Product Security and Incident Response. RSAC Device Security & Accessibility Program Committee Co-Chair.
3 å¹´I feel like this graphic was aimed at getting my attention for this article personally
Head of Products, OT/IoT Security, Zscaler
3 å¹´The CIO of Siemens Hanna Hennig address this exact challenge with a clear playbook for OT/IT convergence. Key Takeaways from the article But what does it take to connect the virtual and physical worlds? 1. Cultivate a software first approach 2. Consider connectivity & brownfield landscapes 3. Enable the common sharing of data 4. Cybersecurity is non-negotiable 5. Cultural alignment is paramount https://www.dhirubhai.net/pulse/convergence-ot-physical-meets-virtual-world-hanna-hennig/
Cyber-Physical Risk Expert | Founder Cyber-Physical Risk Academy | Consultant, Speaker, Trainer, Publisher | Operational Technology | Masterclasses | Training | 45+ years in process automation. OT security focus.
4 年The term legacy system suggests we have “old†insecure systems and “modern†secure systems. This just doesn’t exist. A rip and replace strategy followed by Foxboro 40 years ago changed them from market leader to a name in the history books. Automation is a world of continuous evolution, building a new system on the foundation of the previous releases while maintaining support for the solutions of the earlier generations. Therefore the vulnerabilities of yesterday propagate into the solutions of today. To change this requires a different approach than followed today Today we create piles of standards prescribing security requirements to meet. But generally using terminology that all stakeholders can accept without any impact on their product portfolio Key is to approach the problem from the asset owner side and develop clear security procurement language. Today’s RFP are generally very bad allowing a response meeting RFP but not providing a secure solution. I have seen hundreds of RFPs of small and very big asset owners, with big differences in the security paragraphs but none enforced the delivery of “secure†solutions. RFPs are just not selective enough to push the vendor community to improve their products in a faster pace
Industrial cybersecurity Consultant, Performed Cyber Risk Study of the ICS used in the NATO CEPS.
4 å¹´The regulator route has worked at the high level. Aircraft industry is an example and maritime is another. Unfortunately the positive change comes in many cases after some tragedy. After each plane crash there is an investigation and the findings affect the owners and the manufacturers. Lifeboats and life jackets became mandatory for each passenger after the Titanic disaster. Lives and property could be saved pro-actively if warnings are heeded and problems thought through. Management could take a big step in heeding the warnings and acting. Just the opposite of what the captain of the Titanic did when he ordered no change in course or speed after hearing from his fellow ship captains that they stopped to wait out the night because of icebergs in their path. Engineers could have come up with a better design but they need to be an integral part of a team (with management, vendors, regulators) that is working from the same page. Probably too much to ask until something bad happens.