Takeaways from 2020 ICS vulnerabilities report

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.

Courtesy: Verve Industrial

ICS-CERT advisories increased by ~30% over 2019 with the number of common vulnerabilities and exposures (CVEs) growing by almost 50%, and the average common vulnerability scoring system (CVSS) score of these CVE’s increased to over 8.0 out of 10. These advisories were equally split between original equipment manufacturer (OEM) application software and embedded device vulnerabilities.

Courtesy: Verve Industrial

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. 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).

Courtesy: Verve Industrial

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 Siemens devices are “less secure.” In ICS, we need to learn published vulnerabilities may, in fact, indicate a more mature vulnerability management program rather than more risky software.

One telling fact is almost three quarters (73%) of vulnerabilities were reported by third parties. It is great more researchers are diving into the complex world of ICS, but this also means the adversaries are also diving into these devices and finding vulnerabilities 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…

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?

Four preventive actions for OT operators

1. Ensure a robust inventory. This is not only for 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 they often don’t all make it into a standard database. Many vendors are providing advisories 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. 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. Many believe patching is 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. In the short term, apply robust patch management on the human-machine interface (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 necessary updates.

This story originally appeared on Verve Industrial’s website. Verve Industrial is a CFE Media content partner. Edited by Chris Vavra, web content manager, CFE Media and Technology, cvavra@cfemedia.com.

Original content can be found at verveindustrial.com.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.