Reader Comment – Not All ICS Are Equal

As I promised earlier I would like to address the second half of Dale Peterson’s comment posted to yesterday’s blog about pay for patch. In the second half of his comment Dale said:

Side thought - we are going to need to stop treating ICS as a single category. Not all ICS is used in critical infrastructure. We shouldn't act as if every HMI vuln has a big consequence. The C3-Ilex is actually used in the electric sector and a few others so that does affect what almost all would label critical infrastructure. I'll have a blog [DigitalBond.com] on a different (not patching) aspect of this up later today.

This is not the first time or venue that Dale has made this point, and from time to time we all need to be reminded that we shouldn’t take all reported vulnerabilities with equal seriousness. Nor should we consider every control system to be equally vulnerable.

ICS Vulnerability Reports

Dale has mentioned on a number of occasions that he is concerned with the fact that it appears that ICS-CERT pays as much attention to vulnerabilities in obscure human machine interface (HMI) applications as it does to PLC vulnerabilities in widely deployed systems. It is certainly true that the vast majority of alerts and advisories concern systems that are not widely used in critical infrastructure in the United States. What isn’t as clear is how much of the limited resources of ICS-CERT is taken up with these lesser used system. That would be an interesting study for the DHS IG or the Congressional Research Service.

Having said that, I think that ICS-CERT is still providing a valuable service in the reports that it provides on these systems. These would be even more useful if they maintained an easily searchable database with these vulnerabilities and responses listed in a way that would allow a small company to investigate the security background of these vendors.

Besides, do we really want a government agency like this picking and choosing which researcher reports it is going to address? Unless some outside agency sets very strict guidelines on how those decisions are made (and who else in DHS has the technical background to set those guidelines), such a system of picking and choosing will quickly devolve into a political process that will serve no one well.

Dale in a blog today, also points to large scale problems that ICS-CERT is under-sourced to handle. He give the example of the Project Shine report of 500,000 internet facing control systems that were recently reported to ICS-CERT. He notes that identifying and notifying the owners of those IPs will take a great deal of time and effort. He also questions if it is worth the time of ICS-CERT to complete that herculean task since it is unlike that more than a small fraction will be associated with critical infrastructure facilities. I will note that I am expecting to see a public announcement in the next week or so from a private group that they are going to accept responsibility for identifying and contacting those IP owners, relieving ICS-CERT of that burden.

No, the real problem here is the ‘limited resource’ side of the equation, not that ICS-CERT takes on the vulnerability communications task on little used systems. I think that the doubling of the budget and manpower for this office would have a minimal impact on the size of the federal budget, and it would provide a substantial improvement in the capabilities of the organization.

ICS Vulnerabilities

The other side of Dale’s comment concerns where these vulnerabilities are found in the field. Two systems with control systems that only differ in the number of PLCs connected to the system will have the system vulnerability, but will have different levels of risk associated with them. And that risk is not determined by size alone; a whole host of other factors including socio-economic and political go into determining the risk of an attack on the system.

This is something that has generally been missing from the discussion of ICS Security. Systems that control the stability of the electrical grid are more at risk of attack than those that control the operation of a small hydroelectric plant. The cybersecurity community needs to start talking about how these risk levels will affect decisions about how to secure control systems. It just doesn’t make sense that a manufacturer of kiddy-widgets would need to worry as much about protecting his control system as a similarly sized chemical manufacturer that is handling toxic inhalation hazard chemicals.

Not only is the level of risk different, but the mode of attack is probably going to be different as well. That chemical manufacturer will probably have to be concerned about the probability of a terrorist attack while the widget manufacturer will be more concerned about the potential of attack by a disgruntled employee. These two different types of risk will require two different types of security planning and execution.

Finally, even though Joe Weis has been pushing this idea for years, there really hasn’t been much discussion about the resilience of control systems to unintended system upsets. Most of the cyber-incidents over the last decade have not had anything to do with deliberate attacks on the systems, but seem to have been the result of human error or inappropriate machine responses to and accidental stimuli.

Insecure by Design

One final area that I would like to address that Dale inexplicably did not include in the comment on this blog is the whole idea of ‘insecure by design’. I don’t know if Dale coined the term, but he certainly uses it often enough that many folks cringe at the site of it. The vast majority of PLCs (as an example of insecure devices) in use today never had any thought to security included in their design process. In the most cases, if an attacker gains administrative access to a control system network they can pretty much re-program the PLC to do what the attacker wants. Worse yet, it has been demonstrated in the wild that it can be done without the system owner being able to detect either the access or the re-programing.

Even if every PLC manufacturer started today to turn out only PLCs with secure communications for programing purposes, it would be 10 to 15 years before all of the existing insecure PLCs were pulled out of processes because of life-cycle issues. But, we really don’t need to concern ourselves with replacing all of the insecure PLCs, again because not all of them are equally at risk for attack.

Instead of beating each other up over whether it is more important to cure insecure by design or post-install secure communications link, we need to be talking about defining a methodology to identify relative risk to attack. With that tool owners could decide which PLCs need to be replaced with an expensive high-security PLC, which PLCs should be protected by less expensive add-on secure communications devices and which PLCs can be just left alone to last out their current useful life.

Priorities Must Be Established

In a perfect world it would not be possible to attack any control system because the design, manufacture and implementation of every control system would take security into account at every step of the process. Unfortunately, this hasn’t been done for the control systems currently in use or even being designed for use. It’s too late to worry over much about that; it is what it is.

What current system owners need are tools to determine the risks of their systems to attack, either from within or without. Those systems at the highest risk level, particularly those that are in critical infrastructure installations, then need to determine which parts of their systems are at the most risk and harden those first and hardest. Then they need a plan to continue hardening their systems as time and resources permit.

 

Once we get well started on this, then we can worry as a society about what kind of security we need to reasonably put into place in the lower risk facilities.