Identifying and Addressing Known Vulnerabilities in ICS Software

Abstract

Industrial control systems (ICS) support much of the world’s critical infrastructure and manufacturing capacity, making software reliability and security extremely important in this space.

This case study focuses on an arbitrary ICS-focused software development kit from the internet which Synopsys staff downloaded and analyzed. Synopsys discovered the presence of hundreds of known vulnerabilities in third-party components that could have been eliminated prior to release through the use of software composition analysis.

Solution evaluation

Software composition analysis is critical due to the fact that an estimated 70% to 90% of software applications today use third-party libraries. Users of third party components rarely allocate resources to ensure the components they are consuming are secure because they falsely assume that security and quality testing are upstream responsibilities. By applying software composition analysis techniques, you and your organization can verify that third-party components within software are secure and thus avoid absorbing unnecessary security risks.

Synopsys Software Composition Analysis (Protecode Supply Chain™) relieves the burden of software component testing by providing a comprehensive bill of materials containing third-party components, their location, and their version in binary packages. Using the US NIST National Vulnerabilities Database (NIST NVD) and various other databases, Synopsys Software Composition Analysis (SCA) Supply Chain analysis engine enumerates known vulnerabilities within each third-party component. For every known vulnerability found, Synopsys SCA Supply Chain provides its Common Vulnerabilities and Exposures (CVE) number, where details of the vulnerability and a criticality score are provided.

Discovery phase

The engineering and support staff at Synopsys regularly test our SCA Supply Chain by acquiring binary packages and uploading the contents into its cloud services. The results of the scan are analyzed to not only determine the effectiveness of our SCA Supply Chain, but to also assess the results and relay critical findings to the developers of the analyzed package(s).

In 2014, a Synopsys engineer downloaded a SCADA (supervisory control and data acquisition) software package from the vendor’s developer website. The website advertised that there were over 20,000 licensed users globally, and listed some of their marquee customers, who were distributed among multiple critical infrastructure sectors such as airports and water management.
Upon scanning the downloaded software package, it was discovered that over 700 known vulnerabilities affected the product.

Upon scanning the downloaded software package, it was discovered that over 700 known vulnerabilities affected the product:

 

software composition analysis

Of these vulnerabilities, over 300 were deemed critical, mainly through the scoring system used in the US NIST National Vulnerability Database (https://nvd.nist.gov).

The NIST NVD primarily provides the Synopsys SCA Supply Chain with the CVEs. Sponsored by the US Federal Government, MITRE Corporation (https://cve.mitre.org) compiles CVEs and articulates the details of the vulnerability and assigns a criticality score between 0 and 10. A score between 7.5 and 10 is deemed “critical” by the scoring system and means that the vulnerability is remotely executable with no authentication required.

The Java package (jre 1.6.0) within the SCADA system contained over 300 known vulnerabilities and of these vulnerabilities, over 150 scored between 7.5 and 10.

The package was further analyzed and the vulnerabilities were graphed over time, starting with the oldest known component to the most recent. The results were quite startling:

 

third-party software component information

The vertical axis indicates the number of vulnerabilities (CVEs) affecting the SCADA package and the horizontal axis represents the timeline. As shown by the graph, the number of vulnerabilities affecting the system took a massive upturn around 2012.

unique vulnerabilities graph over time

The vendor website provided three release dates between 2012 and 2014. These dates correlate with the sudden sizeable increase in known vulnerabilities affecting the SCADA system, clearly indicating (by our analysis) that the use of third-party components during product enhancement drove the vulnerability count up.

Deployment and benefits realized

The software manufacturer was contacted and presented with the results of the analysis. The initial reaction from the software vendor was one of shock and when asked how this situation came to be, they informed us that the changes they had implemented in the software coincided with the increase in cybersecurity vulnerabilities. The reason they had not addressed these issues is their testing plan did not include testing to enumerate the third-party libraries contained in the software.

The SCADA system vendor addressed the discovered issues and within two months brought the known vulnerability count down to a total of 40, a significant decrease. A large number of the vulnerabilities were addressed by simply updating the Java package to the latest version. The remaining 40 vulnerabilities were the result of one of the software components within the SCADA system having internal dependencies on vulnerable open source libraries which had to be addressed by the component creator.

It is important to note that once the vendor was provided with the information needed to assess the vulnerabilities in their software, they were able to act quickly to fix the issues. However, this does not necessarily mean that end users could update their SCADA systems, since many of these are critical and cannot be taken offline to make such changes. Nonetheless, the vendor was able to inform customers about vulnerabilities that affect their software, giving customers the opportunity to implement mitigating procedures while awaiting the installation of software updates and upgrades.

Within two months the vendor brought the known vulnerability count down to a total of 40, a significant decrease.

Conclusion

As modern society grows increasingly dependent on technology to run our critical infrastructures, security becomes a more critical aspect of control system software. Using Synopsys SCA Supply Chain throughout the development life cycle will help ICS manufacturers and end users identify and mitigate vulnerabilities from control system software, ensuring overall safety in cyber-physical processes.