The economic impact of ICS vulnerabilities

By Denny Wan and Daniel Marsh

Synopsis

The Common Vulnerability Scoring System (CVSS) is used throughout various industries for scoring vulnerabilities based on several metrics. These metrics focus on confidentiality, integrity and availability, the very well known CIA triad ingrained in the mentality of cybersecurity professionals and extends to maturity and environmental when and where the additional information is required. This allows CVSS to have the scores “weighted” based on organisational nuances and discrepancies. For example, a vulnerability with a CVSS score of 10 may could be lowered based on the temporal and environmental factors such as protected by an air-gapped network.

“SCADA & ICS Cybersecurity Workshops – Perth & Sydney, 24-28 June – Click the image to find more information”

When working in industrial environments the context of vulnerability can be vastly different for ICS vulnerabilities. CVSS does not include an estimation for the potential economic impact from the successful exploitation of a vulnerability. Blindly applying CVSS to any environment without addressing context can result in inappropriate prioritisation and resources and effort being misdirected, leading to potentially disastrous consequences. A remote code execution (RCE) vulnerability is critical for any exposed system, however, in a segmented and isolated environment that the same RCE does not have the required exposure factors. The temporal CVSS scores should help to reduce it slightly, but not necessarily enough to reduce it from the highest score for vulnerabilities in the environment. A high CVSS score does not necessarily mean the vulnerability is critical to an ICS and treating CVSS like this can result in massive economic loss, including the loss of life.

This paper explores some recent research in the scoring of Industrial Control Systems (ICS) vulnerabilities to improve its usability. It extends from the approach in our previous paper titled “A New Approach to ICS Risk Assessment” which applies a business based prioritisation approach to scoping an ICS risk assessment based on cyber risk quantification techniques.

The Open Group Factor Analysis of Information Risk (FAIR) Cyber Risk quantification framework is a useful approach for ICS risk professionals to dimension ICS risk in a business language and financial metric, to better explain the business impacts and the remediation prioritisation decisions to the business stakeholders.

ICS Security Basics

ICS exists to ensure the effective operation of facilities and generally to help in providing manageable services such as water, power, transportation and building management. Any service delivered where the loss of life is considered is acceptable should not be a service being operated and these ICS sectors are aligned with this approach, ensuring a safety-first approach is taken to any activities carried out. The first question of ICS security basics should simply be, will this “thing” have a potential to cause loss or harm to life? If yes, how do we remove this potential?

There are a number of regulatory and legislative requirements that these must adhere to, and some that they simply should adhere to. In Australia, the Security of Critical Infrastructure Act requires reporting of all assets deemed as critical infrastructure and to implement and effect changes as deemed appropriate by the Minister. The North American Electric Reliability Corporation (NERC) has the Critical Infrastructure Protection reliability standards, the NIST Cybersecurity Framework and the Cybersecurity Capability Maturity Model (C2M2) of which the Australian Energy Market Operator has based the Australian Energy Sector Cyber Security Framework (AESCSF).

ICS used to be completely isolated and operated over proprietary protocols and interfaces. This significantly limited the attack vectors, however, with the growth of the Internet, open standards and the need for devices to communicate with other vendors the air-gap between ICS and the general IT world has shrunk. Devices have been built with serial to ethernet capability allowing for devices built before the dawn of the Internet to be directly connected and sharing information with anyone who has the knowledge to query them. Simply applying the same controls to an ICS as what is applied in the Enterprise IT environment is daft, disastrous and impossible. Trying to achieve a 99% patch rate within two weeks of patch release throughout Enterprise IT might be a reasonable goal, but achieving even a 50% patch rate in the ICS world could be seen as a lofty goal.

Malware, such as Stuxnet and TRISIS, are engineered to specifically target ICS environments to cause loss, destruction or simply shut down energy distribution and processing. While others are more general such as KillDisk which played part in the Ukraine blackout in 2015, KillDisk destroyed the disks of servers and workstations making recovery more difficult.

The greatest trick the Devil ever pulled was convincing the world he didn’t exist. – Usual Suspects (1995). Making a Human Machine Interface (HMI) or system console to show that everything is OK while everything in the background is going haywire was a wonderful part of TRISIS, the engineers could not identify why the centrifuges were breaking because their monitoring was being tampered with.

Implementing zone models, such as the Purdue Enterprise Reference Architecture (PERA) and applying the concept of zone models in general to environments is still one of the best practices that can be implemented, by doing so correctly the attack vectors are reduced and choke points can be established for thorough and deep investigation of traffic.

In addition to implementing zone models, applying a systems classification plan can greatly assist, such as that of the McAfee 3×3 matrix. Each asset within an environment can be classified in one of the nine boxes with each box applying different controls to protect the asset. By utilising the two approaches of PERA and the 3×3 matrix, a complete strategy for protecting an ICS can be developed effectively.

There also exists a number of standards and guides for securing ICS, NIST 800-82 is a comprehensive guide, while the SANS paper titled “Securing Industrial Control Systems-2017” provides an organisational view to addressing cybersecurity in ICS.

Taking a simple approach of what’s good for IT is good for OT will result in inappropriate priorities and misdirected effort. Each approach, system and technology must be tailored for ICS to ensure the appropriate context is applied.

The problem with using CVSS

The Common Vulnerability Scoring System (CVSS) is a widely used system to prioritise system patching effort on IT system. ICS-CERT publish ICS CVSS to track vulnerabilities specific to ICS. CVSS V3 was released in 2015 to improve the effectiveness of CVSS. However, a 2018 paper from Carnegie Mellon University (CMU) titled “Towards Improving CVSS” spelling out a few key deficiencies contributed to a widely misused for vulnerability prioritization and risk assessment, despite being designed to measure technical severity. The CVSS scoring algorithm is not justified, either formally or empirically. Misuse of CVSS as a risk score means you are not likely learning what you thought you were learning from it, while the formula design flaw means that the output is unreliable regardless.

Not surprisingly, ICS CVSS also suffers from similar problems. For example, a medical system vulnerability that could cause death is rated lower than a vulnerability that could lead to spear phishing (in a zone that doesn’t allow email). Part of the problem is that most users only reference the CVSS Base Score focusing on Exploitability and Impact without contextualising the score with temporal and environmental metrics in accordance with the design of the CVSS scoring methodology: CVSS scoring system consists of three metric groups:

Source: https://www.first.org/cvss/specification-document

The score from the previous group is feed into the next group to contextualise the score to reflect the deployment environment and use case as depicted below:

Source: https://www.first.org/cvss/specification-document

In the recent S4x19 ICS Security conference, Billy Rios (Founder, WhiteScope), Clint Bodungen (Executive VP, Leo Cyber Security) and Art Manion (Senior Vulnerability Analyst, CERT/CC) participated in a panel session titled “A New CVSS For ICS Vulnerabilities” to present their suggested modifications to the CVSS for ICS vulnerabilities. They score the same vulnerabilities and then discuss the pros and cons of each other’s methods.

The “I” have it – IoT and IIToT

Daniel Ehrenreich, ICS Security Expert, challenges the industry to differentiate between Internet of Things (IoT) and Industry Internet of Things in his recent post titled “IoT and IIoT – Are there differences?”. He is still waiting for an answer! I am sure it would have made him a small fortune if he can collect a dollar every time someone failed to respond to his challenge or failed to answer the question properly. Jokes aside, this is a serious matter because “… IIoT endpoint devices are part of the ICS architecture …”.

Moreover, he pointed out in this post titled “Why this chart on IoT is incorrect?” that “… The IIoT is a completely different story, and there is a huge difference between IoT and IIoT. The IIoT devices (smart sensing devices) never communicate directly over the internet (as IoT devices do) as they are part of the ICS architecture which must be cyber secured. When IIoT ecosystem service is required (upon detecting a problematic condition or need for optimized performance), the ICS initiates a communication session through corporate IT with the cloud-based service and vice versa ..”

We look forward to his latest update when he visits Australia in June to deliver his ICS security workshops.

Integrating FAIR to ICS security

As explained in the previous section, contextualising CVSS score (for both ICS and non-ICS vulnerabilities) to the target environment and use case is the key to maturing the application of CVSS score for vulnerability management. The Open Group FAIR cyber risk quantification framework provides a structured approach to break down the risk scenario and use case. This enables stakeholder to explain the rationale behind their analysis and the rating assigned to each CVSS metrics. For example, the FAIR taxonomy breaks down vulnerability into Threat Capability and Resistance Strength:

Because CVSS focus on vulnerability rather than the attacker, there isn’t a direct mapping for “Probability of Action” or “Treat Capability”. These are the domain of threat intelligence analysis e.g. the motive for and capabilities of the attackers. It is intuitive to understand that patching improves “Resistance Strength” where isolation technology such as network segmentation techniques. Similarly, stateful firewall based access controls increases complexity for the attacker to launch their attacks resulting in a lower “Contact Frequency” with the targeted asset.

The other dimension in the FAIR taxonomy is the estimation of potential loss from a cyber incidence:

The presentation “De-Mystifying Cyber Risk” from Mike Radigan, Director, OT Strategy | Strategic Partners at Capgemini Cyber, ICSJWG 2017 Fall Meeting shown how to apply the FAIR framework to model cyber risk in an ICS environment.

A summary of Mike’s presentation has been published on the FAIR Institute blog titled “Case Study: Demystifying ICS Cyber Risk with FAIR normalized with mechanical/industrial operational risk”. While Mike’s analysis did not quantify ICS CVSS score, the quantification approach is a useful template for ICS security practitioners who want to present their technical analysis to the business stakeholders. He had been very helpful and patient in explaining his approach to us. I am sure he would be equally helpful to other ICS practitioners interested in applying the FAIR approach to their analysis.