What makes patching an Industrial Control System so difficult, when it is easy to patch your phone or laptop? We will look in to three useful methods that help you understand what vulnerabilities to patch, and why. 
But before we dive into that, let's examine why you need a different method for ICS than for personal devices or IT infrastructure.

The CIA Model 

When sitting in the Information Security 101 class the teacher told you about the CIA triangle. CIA stands for Confidentiality, Integrity, and Availability, and can be seen as the direction and focus of your security posture work.. 

How does the CIA Model relate to patching your ICS? 

Each part in the CIA model is prioritized based on the system and data you are protecting. In a classic IT system, for example a medical record system, confidentiality and integrity of data is the most important aspects to prioritize. In case of a breach in classic IT systems, your job is to prevent intruders from accessing data or invalidating integrity. Classic IT systems are not mission critical, and therefore not required to be up and running 24/7. 
The third part of the CIA triangle, Availability, is sacrificed since it is not prioritized. In classic IT systems, pulling the plug and losing the connection is better than losing data. This is the reason why many of the countermeasures to incidents taken from the IT industry does not seem to work in OT.

But what happens if there is a breach in an Industrial Control System?

Things are not that simple in an ICS compared to a classic IT system. Often, it is the other way around - pulling the plug and loosing connection is not an option. The systems are mission critical and must always stay up and running. 

Mission critical means uninterrupted service 24 hours a day, 7 days a week. As shown in the picture above, there might also be safety concerns to consider. An ICS cannot be turned off like other systems that store data. Not only is this a problem in terms of breaches, but it also makes the entire incident response process much more difficult. Many ICS owners do not patch at all, and if they do, they have a very short window of time to do so.

Why is it important to know that uptime and availability are driving forces in an ICS? Essentially, it affects how you patch and work with vulnerabilities.

What do I patch? 
We have established that patching an ICS is hard and time-limited, so what should we patch? 

As you begin to patch vulnerabilities, you should make educated decisions since there are likely to be, if not an endless list, then a fairly large number of vulnerabilities. You might be familiar with the Common Vulnerability Scoring System (CVSS) used to score Common Vulnerabilities and Exposures (CVE). 

CVSS scores can be seen as pathological liars, or at least like that relative who always tells stories at family reunions that seem improbable (and sometimes are). Why should you not trust a CVSS right out of the box? 

There are several reasons not to trust the CVSS:

• It does not take your system into account.
  In particular not OT systems. You are the only person who knows how your system is set up, and how different vulnerabilities can affect it. One advice is to do your own scoring, with your system in mind.
   
• Any threat modelling you have done is not considered.
  If you've done your homework and threat modelled your system, you'll know which vulnerabilities you should patch first and which to leave until later.
   
• Safety is not considered.
  There is no concern regarding people in the different parameters; only the system is addressed.
   

To make the last point clearer, let's look at an example. The following table shows two different CVE:s side by side. 

Suppose you suffer from a bad heart. You have a pacemaker installed that could save your life, and you also own a smartphone running Android OS. 

Which one would you patch first? The one with the highest CVSS score or the one that could potentially affect your lifesaving equipment? 

Clearly there are many reasons not to rely on the simple CVSS metric alone. 

What other methods are there to decide what to patch? 

What to patch - Decision methods 
Following is a couple of suggestions on how to handle the weakness of the CVSS when deciding. 

 
The Decision Tree
A study at Mellon University proposes the use of a standard decision tree to handle vulnerabilities, by putting vulnerabilities into three categories: 

• Now - means you need to patch directly and before the next maintenance window. 
• Next - inserts the vulnerability into the next normal maintenance cycle.
• Never - means that you decide that you are not vulnerable in the current solution. 

Keep in mind, however, that when your system changes, some vulnerabilities may change as well. 

The Risk Matrix

The classic way of handling risks. Neither fancy nor new, but it will consider your system and its impact on it rather than just relying on CVSS alone. 
Remember the two examples above for CVEs. It is likely that they would score very differently in functional impact here, resulting in very different decisions. 
Worth noting is that the risk matrix does not handle probability, which is almost always present. 

The reason is, how do you know how high the probability of an attack is? In essence, it is binary, either you are not under attack, or you are. Therefore, the decision assumes that someone is trying to exploit the vulnerability. Therefore, do not use probability to decide what to patch! 

Summary 
We can never be 100 % secure, which means we need processes in place to handle the vulnerabilities we face. Hopefully this article gave you some food for thought when it comes to deciding how to deal with vulnerabilities. However, even if you have a perfect decision-making process, you still need to work with a trusted supplier that delivers secure software and provides the patch you requested.


This article is written by Niklas Mörth, CISO at Westermo.