Public ICS Disclosure – Week of 11-28-20

This week we have three vendor disclosures for products from BD, Mitsubishi, and Phoenix Contact. There was also an update for a previous disclosure from Yokogawa.

BD Advisory

BD published an advisory discussing the Microsoft Bad Neighbor vulnerability. The advisory provides a list of potentially affected products. BD is testing the MS patch for compatibility.

Mitsubishi Advisory

Mitsubishi published an advisory describing a denial-of-service vulnerability in their Human-Machine Interfaces-GOT and Tension Controller products. This vulnerability is self-reported. Mitsubishi has provided generic workarounds pending development of a new version that mitigates the vulnerability.

Phoenix Contact Advisory

Phoenix Contact published an advisory [.PDF download link] describing an uncontrolled resource consumption vulnerability in their Touch Panels of the BTP series of articles. The vulnerability was reported by y Richard Thomas and Tom Chothia of University of Birmingham. Phoenix Contact provides generic workarounds to mitigate the vulnerability.

Yokogawa Update

Yokogawa published an update for their CAMS for HIS advisory that was originally published on July 31^st, 2020 and most recently updated on September 4^th, 2020. The new information includes adding  Exaopc as affected product.

ISCD Updates 1 FAQ Response – 12-4-20

Today the CISA Infrastructure Security Compliance Division (ISCD) updated the responses to seven frequently asked questions (FAQs) on the Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center web page. There was a minor change in administrative procedures made.

The following FAQ response was revised:

FAQ #1275 What needs to be done with the facility ID in the Chemical Security Assessment Tool (CSAT) when a covered chemical facility is bought or sold?

NOTE: The link provided for the FAQ in this post was copied from the CFATS Knowledge Center but may not work when followed from your machine. This is an artifact of that web site. If the links do not take you to the referenced FAQ you will have to use the ‘Advanced Search’ function on the page to link to the FAQ or download the ‘All FAQs’ document at the bottom of the ‘Advanced Search’ page.

The following changes were made in the referenced responses:

#1275 Minor administrative procedural change – In last paragraph added option to email or surface mail letters to ISCD where only the Fax option was included in the earlier version.

NHTSA Sends Cybersecurity Comment Notice to OMB

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had received a copy of “Request for Comments on Cybersecurity Best Practices for the Safety of Modern Vehicles” for review from the DOT’s National Highway Transportation Safety Administration (NHTSA). This pre-rulemaking activity was not published in the 2020 Spring Unified Agenda, so there are no publicly available details on this document.

It is interesting to note that the title does not appear to restrict the request for comments to just automated driving systems, but we will have to wait for NHTSA to publish the document in the Federal Register to be sure. I do not expect OIRA to approve this document before January 21^st, 2021; nothing to do specifically with the change in administrations, just a normal turnaround time at OIRA.

1 Advisory and 2 Updates Published – 12-3-20

Today the CISA NCCIC-ICS published one control system security advisory for products from National Instruments. They also updated two advisories for products from Wibu-Systems and WECON.

National Instruments Advisory

This advisory describes an incorrect permission assignment for critical resource vulnerability in the National Instruments CompactRIO real-time embedded industrial controller. The vulnerability was reported by Titanium Industrial Security via Incibe CERT. National Instruments has a new driver that mitigates the vulnerability. There is no indication that researchers have been provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit this vulnerability to  allow an attacker to reboot the device remotely.

CodeMeter Update

This update provides additional information on an advisory that that  was originally published on September 8^th, 2020 and most recently updated on October 15^th, 2020. The new information includes links to vendor advisories for products from:

• Eaton, and

• TRUMPF

NOTE: I briefly discussed the Eaton advisory back in early October and the TRUMPF advisory later that month. NCCIC-ICS has not yet mentioned the ENDRESS+HAUSER advisory that I mentioned in the same blog post as the TRUMPF advisory.

WECON Update

This update provides additional information on an advisory that was originally published on August 25, 2020 and most recently updated on October 29^th, 2020. The new information includes:

• Adding a new vulnerability (heap-based buffer overflow - CVE-2020-25199), and

• Adding a new reporting researcher (Peter Cheng from Elex Cybersecurity Inc)

NHTSA Publishes Automated Driving ANPRM

Today the DOT’s National Highway Traffic Safety Administration (NHTSA) published an advanced notice of proposed rulemaking in the Federal Register (85 FR 78058-78075) for the “Framework for Automated Driving System Safety”. NHTSA is seeking public input on a framework that “would objectively define, assess, and manage the safety of ADS [automated driving system] performance while ensuring the needed flexibility to enable further innovation.”

The Framework

In this ANPRM NHTSA is not proposing the establishment of a new Federal Motor Vehicle Safety Standard (FMVSS) for ADS as it is too early in the development process to identify the critical safety characteristics that would be necessary to develop a new FMVSS. Instead, NHTSA intends to develop “a framework approach to safety for ADS developers would use performance-oriented approaches and metrics that would accommodate the design flexibility needed to ensure that manufacturers can pursue safety innovations and novel designs in these new technologies.”

In the development of this framework NHTSA plans to focus on four core functions of the ADS. Those functions are:

• How the ADS receives information about its environment through sensors (“sensing”),

• How the ADS detects and categorizes other road users (vehicles, motorcyclists, pedestrians, etc.), infrastructure (traffic signs, signals, etc.), and conditions (weather events, road construction, etc.) (“perception”),

• How the ADS analyzes the situation, plans the route it will take on the way to its intended destination, and makes decisions on how to respond appropriately to the road users, infrastructure, and conditions detected and categorized (“planning”), and

• How the ADS executes the driving functions necessary to carry out that plan (“control”) through interaction with other parts of the vehicle.

NHTSA is soliciting comments on these core functions, including:

• Whether commenters agree that these are the core functions,

• Views on NHTSA's description of these functions, and

• Whether and how NHTSA should prioritize its research as it develops a safety framework.

Additionally, NHTSA acknowledges that they have identified eight other aspects of an ADS that could be of specific interest in the development of their framework. Those include:

(1) Identifying reduced system performance and/or ODD in the presence of failure,

(2) operating in a degraded mode within reduced system constraints,

(3) performing the essential task of transporting occupants or goods from starting point to the chosen destination,

(4) recognizing and reacting appropriately to communications from first responders, including fire, EMS, and law enforcement,

(5) receiving, loading, and following over-the-air software updates,

(6) performing system maintenance and calibration,

(7) addressing safety-related cybersecurity risks, and

(8) system redundancies.

NHTSA is soliciting comments on these other aspects of an ADS described above including:

• Which of these aspects the Agency should prioritize as it continues the research necessary to develop a safety framework,

• Whether it has an appropriate role to play with any or all of these elements outside of research,

• Should NHTSA's role be regulatory or sub-regulatory for each element?

Interestingly, the Agency does note that they are not specifically authorized under the Safety Act “to regulate areas such as general privacy and cybersecurity unrelated to safety”.

Regulatory Mechanisms

Looking forward, NHTSA recognizes that at some point they will be responsible for regulating ADS safety. In this ANPRM, NHTSA looks at potential regulation mechanisms and sees comments on those topics as well. These proposed mechanisms include:

• Mandatory reporting and/or disclosure,

• NHTSA'S FMVSS setting authority,

• Applying the established FMVSS framework to ADS safety principles, and

• Reforming how NHTSA drafts new FMVSS to keep pace with rapidly evolving technology.

NHTSA provides the following examples of possible regulatory action:

FMVSS requiring obstacle course-based validation in variable scenarios and conditions,

FMVSS requiring vehicles to be programmed to drive defensively in a risk-minimizing manner in any scenario within their ODD [operational design domain],

FMVSS drafted in a highly performance-oriented manner,

Timing and phasing of FMVSS development and implementation,

NHTSA Soliciting Comments

As mentioned above, the Agency is soliciting public comments on this proposed rulemaking. In addition to the comments mentioned above, NHTSA includes 24 specific questions to which it is seeking public input. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # NHTSA-2020-0106). Comments should be submitted by February 1^st, 2021.

Commentary

NHTSA continues to run a catchup game on the regulation of automated driving systems. Part of that is the normal regulatory inertia that affects any government operation, but the other is the lack of Congressional direction and authorization to operate in a quickly changing technological environment. Having said that, today’s ANPRM is a significant next step in NHTSA’s effort to keep up with ADS development.

While NHTSA continues to mention cybersecurity in its ADS literature and this ANPRM, I do not think that they are taking the issue seriously enough. Not a single one of the 24 specific questions that NHTSA proposed for response addressed cybersecurity topics.

Furthermore, NHTSA missed the boat by not including a fifth ‘core function’ for ADS; “Protection”. In keeping with the language of the ANPRM, “protection” would refer to the ability of the ADS system to continue to protect the safety of the vehicle’s occupants in the event of an electronic failure due to component failure, communication (internal or external) disruption or cyberattack. In process safety terms, this means that the system has mechanisms and protocols in place to ensure that it fails in an inherently safe manner.

I think that it is important for NHTSA to encourage developers to consider system failure modalities early in the development cycle and include development of ‘fail safe’ mechanisms as a design criterion. As NHTSA moves into the FMVSSA development process it needs to consider identifying common failure modes and specifying minimum standards for engineering responses to those modalities.

This is more than just ‘cybersecurity’, though it certainly embodies a key component of operations technology cybersecurity, failure mitigation. Cyberattacks are one failure mode that must be considered in the design and development process, but other failure modes must also be addressed.  Other failure modes that should be addressed include:

• Loss of signal from external devices,

• Internal communication disruption,

• Physical, mechanical, or electronic interruption of sensors,

• Interrupted or incomplete software updates, and

• Loss of power to either powertrain or electronic systems.

Developers need to demonstrate that they have taken failure mitigation into account in their design process, documenting the failure modes identified and explaining the mitigation measures adopted. Further, they need to have an identified process in place for:

• Detecting new failure modes in development testing and real-world operations,

• Developing appropriate mitigation measures, and

• Communicating those measures to vehicles in the field.

Finally, NHTSA has to have a reporting mechanism in place for reporting newly identified failure modes and the mitigation measures adopted. And NHTSA has to be prepared to (and allowed to) proactively share those failure modes with other ADS and OEM vendors using the same or significantly similar equipment.

A copy of this blog post will be filed as a comment on this ANPRM.

Publishing Security Advisories

I had an interesting online conversation today with an ICS security researcher. He wanted to know if I had access to a Thales security advisory that I briefly described in one of my weekend ‘Public ICS Disclosures’ blog posts. He was trying to see if it described a vulnerability that he had reported. Unfortunately, Thales (and a number of other companies) only makes its security advisories available to registered customers, so I was not able to help him. In any case, the conversation got me thinking about the whole concept of publishing security advisories.

Anyone who reads this blog knows that I spend a lot of time publishing brief notifications about security vulnerabilities in industrial control systems (with admittedly a WIDE definition of what constitutes an ICS). My reason for doing this is that I want the widest possible dissemination in the user community of information about security vulnerabilities. The information that I publish in a digest-type format is the bare bones that a user might need to determine if their organization might be impacted with links to find more information. I am pretty sure that there are no blackhats out there waiting for my disclosure to provide them with a new cyber weapon.

Corporate Reporting

Can the same be said for vendor security advisories? Most of the advisories that I read are similar in outlook (if in somewhat more detail) to the information that I provide, bare bones about the vulnerabilities, but more information about mitigation measures. While I am certainly not a hacker (or even much of a coder anymore) I have not seen any security advisories that would seem to be nascent weapons platforms. The information might be enough to point a determined attacker at areas to conduct further research, but there is a long way to go from most corporate vulnerability descriptions to useable exploits.

Even so, there are some companies, like the Thales Group, that restrict access to their security advisories to just registered customers. I would guess that they have done some sort of internal risk assessment that leads them to conclude that the information that they provide would be too valuable to an attacker. I would like to think that this is because they provide more details about the vulnerability in their restricted reports. That would be a good thing because more details would allow users to make a better risk assessment of what actions they need to take to protect their systems.

Then, of course, there are those companies that do not publish security advisories of their own. While there may still be some companies out there that are taking a head-in-the-sand approach to security reporting, I suspect that it is more about the lack on internal staffing or perhaps an overly imaginative legal staff that cause many smaller companies to rely on CERTS to prepare their security advisories. This is one of the reasons that I spend so much time looking at CISA-NCCIC-ICS and CERT-VDE for advisories. While I think that this may be counterproductive in the long term, the information is still being made available to the end users, if they know where to look.

Researcher Reports

Finally, we see a significant number of instances where the independent security researcher (or research firm) publishes their report on a vulnerability. In many instances, these reports are the only public notification of the existence of the vulnerability. When that is the case, I wholeheartedly indorse the idea of researchers publishing their vulnerability reports AS LONG AS they have notified the appropriate vendor and provided them a reasonable opportunity to report and correct the vulnerability. This is especially important in cases where the researcher provides details about how they discovered the vulnerability and/or proof-of-concept exploits for the vulnerability. Those actions can make it easier for blackhat hackers to exploit the vulnerabilities in the wild.

From a user perspective I do not see a lot of benefit in the detailed reports that we see from a number of researchers. Details about how the exploit was discovered or how it could be exploited does not provide a lot of useful information for a risk assessment exercise. On the other hand, other white hat researchers can learn new techniques from such reports and vendors can gain valuable insights in how to protect their products from a close reading an understanding of such reports. This is one of the reasons that I continue to discuss such reports in my weekend summary.

Exploit Reports

For a lot of reasons, we see relatively few exploit reports for industrial control systems, but they do exist. The thing that distinguishes these from the researcher reports is that there is typically little information provided beyond the exploit code being published. This means that they provide little new information for the user risk assessment process beyond the known existence of an exploit. A technical review of the exploit by vendors or white hat researchers probably provides some benefit, but these typically exist only as an advertisement of the skill of the exploit writer.

I have been asked on occasion why I keep reporting on these exploit reports. My answer is simple, the existence of these publicly available exploits is information that owners need to have to properly assess their facility risk and determine what/when mitigation measures should be put in place. In all cases to date, I have taken these exploit reports from widely available public sources, so I can sleep well thinking that I have not unduly increased the danger of potential attacks. Again, I do not think that I have a large black hat audience waiting on my word of new exploit tools.

In any case I will be continuing to report on security advisories, researcher reports and exploits. Each weekend I look at 48 vendor sites and 30 researcher sites for new information.. As always, I continue to look for new sources of information about these resources and any suggestions from readers would be welcome.

1 Advisory Published – 12-1-20

Today the CISA NCCIC-ICS published one control system security advisory for products from Schneider.

Schneider Advisory

This advisory describes an improper privilege management vulnerability in the Schneider EcoStruxure Operator Terminal Expert product. The vulnerability was reported by Lasse Trolle Borup, Danish Cyber Defence. Schneider has a new version that mitigates the vulnerability. There is no indication that Borup has been provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that an uncharacterized attacker with uncharacterized access could exploit the vulnerability to allow unauthorized command execution by a local user of the Windows engineering workstation, which could result in loss of availability, confidentiality, and integrity of the workstation where EcoStruxure Operator Terminal Expert runtime is installed.

NOTE: I briefly discussed this vulnerability early last month.