Key Takeaways from 2020 ICS Vulnerabilities

In 2020, ICS-CERT issued 248 cyber security advisories for public consumption on the CISA’s ICS-CERT portal.  Verve analyzed all these advisories, regardless of whether they came from large or small vendors to ensure accuracy even for geographies where the primary vendors are lesser-known.  We compared them to 2019 releases. This report summarizes the conclusions, implications on remediation strategies, as well as a perspective on what 2021 might hold.

ICS-CERT advisories increased by ~30% over 2019 with the number of CVE’s growing by almost 50%, and the average CVSS score of these CVE’s increased to over 8.0 out of 10.  These advisories were equally split between OEM application software and embedded device vulnerabilities.

These vulnerabilities create risks as networks are increasingly connected. Almost two-thirds (63%) are exploitable remotely with little skill required. This is up from 56% in the 2019 total. And the total number of remotely exploitable/low skill vulnerabilities increased by 66% in 2020 vs. 2019. This should raise the hair on the back of the necks of OT operators everywhere, especially in a world of greater remote connectivity to critical infrastructure during COVID and in the future.

These are not just small, minor risks, either. The trend is towards higher risk scores with advisories scored as 8 through 10 increased at roughly twice the rate of those ranked 7 or less. So not only are there more risks, but the severity is growing.

The largest type (~35%) relates to authentication or validation errors which can enable unapproved actors to make changes. And the second (30%) relate to Buffer Overflows. For the security researcher, this term is well-known, but to the operator the implications of this are enormous.  These types of vulnerabilities can be used to:

• Consume/exhaust a device’s or software’s available resources and require a restart.
• Create unsafe conditions where a device is unable to respond deterministically.
• Generate a HALT or a STOP condition due to unexpected communications or commands.
• And potentially be used to compromise the system or application via remote code exploit (RCE).

As in 2019, Siemens constituted the largest number of advisories – in 2020 31% of alerts were related to Siemens whereas in 2019 the percentage was 23%. This is not to say that Siemens devices are “less secure”. In ICS, we need to learn that published vulnerabilities may, in fact, indicate a more mature vulnerability management program rather than more risky software.

One telling fact is that almost three quarters (73%) of vulnerabilities were reported by third parties. It is great that more researchers are diving into the complex world of ICS, but this also means that the adversaries are also diving into these devices and finding vulnerabilities that they are likely not disclosing. The bar for OEMs is going up quickly to begin more aggressive efforts to discover, report, and disclose vulnerabilities.

One of the most significant underlying trends is the increasing threat that emerges as we evaluate the software bills of materials on these ICS embedded devices. In 2020, 36 out of the 248 (15%)advisories were related to these supply chain risks. But we believe this dramatically understates the risks to these hidden vulnerabilities. Through our independent research, we regularly discover embedded devices leveraging insecure software stack elements.

One might surmise from the disclosures from supply chain/third-party component vulnerabilities has not risen, but products are increasingly incorporating vulnerable third-party components.  Similarly, with the increased focus on the supply chain (URG11, Treck, and SolarWinds) – we suspect this to widen the risk theatre, but not in the same profound ways researchers & vendors proclaim.

• 5% of ICS CERT advisories affected multiple products, and 99% affected multiple versions.
• 9% of CVEs from all ICS CERT advisories were generated alone from supply chain vulnerabilities or third-party dependencies.
• And this is just the tip of the iceberg…

Our view is that this will be a major cause of increasing vulnerability disclosures in years to come.

It can seem overwhelming to ICS security teams or OT engineers responsible for keeping track of all of this.

1. Keeping track of vulnerabilities is overwhelming – in the face of nearly constant advisories, the threat of ransomware, breaches, and a continuous flood of CVEs.
2. Expectations and actions upon the data are unclear – it’s great to be informed of risks, but how should anyone prioritize remediations? No workaround is mentioned, what should an organization do? What is a buffer overflow vs. an underflow vs. resource exhaustion?  These are common questions.
3. What you don’t know can hurt you –given the rate of growth and supply chain risks, what else is lurking under the covers of these ICS devices?

So what can you do? We recommend several actions:

1. Ensure you have a robust inventory not only of OS-based devices and their versions but also all of the underlying application software as well as all of your embedded devices with their corresponding firmware. These risks make up over two-thirds of the total vulnerabilities in the OT environment
2. Centralize the tracking of the risk. One of the most challenging parts of these OT vulnerabilities is that they often don’t all make it into a standard database. Many vendors are providing advisories that are not included in the ICS-CERT database privately to their customers. Many supply chain advisories don’t necessarily tie back to a specific OT firmware. Embedded OT devices can be spread across dozens or hundreds of locations. A centralized database and analysis capability is critical to managing these risks efficiently.
3. Assign a centralized resource to get up to speed on ICS vulnerability management. Our “Ultimate Guide to Reading ICS Cyber Security Advisories Like a Pro” is a helpful starting point. This doesn’t necessarily require years of experience, but distributing the analysis across lots of plants or engineers is very difficult. Centralizing this and enabling a small group of people to become experts at reading these and drawing implications for OT is key to efficiently managing these risks.
4. Aggressively pursue compensating controls. We often hear that patching is just not feasible in OT. The reality is true in some cases, but in many cases, there are feasible means to patch effectively to address the most severe risks. Automated tools can help with the labor challenges of doing so. But, we do understand that updating firmware on all the embedded devices can be challenging or impossible. Operators can take a range of compensating controls to address the risks at least partially. We provide a robust list in our longer whitepaper. But in short, apply robust patch management on the HMI/Server layer combined with improved configuration management and user/account management of the OS and embedded devices and strong network protection can provide a range of benefits that can deliver greater security until the upgrade cycle can deliver the updates necessary.

We hope this 2020 review serves to raise the focus and energy on protecting our most critical infrastructure.