CFATS and Pulse Connect

It has been nearly a week since the DHS Cybersecurity and Infrastructure Security Agency (CISA) issued their Emergency Directive 21-03, “Mitigate Pulse Connect Secure Product Vulnerabilities”. As with all such emergency directive’s CISA’s authority to require compliance extends only to agencies of the Federal government. To date, there has been no public move by CISA to expand their Alert AA21-110A: Exploitation of Pulse Connect Secure Vulnerabilities by specifically reaching out to CFATS facilities in the same way that they did with the Microsoft® Exchange server vulnerabilities.

Earlier Incident

The importance of the letter that CISA sent to CFATS registrants and covered facilities in the last incident was found in its suggestion that:

“If any evidence of threat actor activity is found, CISA recommends you reach out to CISA [emphasis added] and submit an incident report via CISA’s Incident Reporting Form. When completing the form, indicate you are “critical infrastructure” and within the chemical sector. In the “Incident Description” section of the reporting form indicate you are regulated under CFATS and include your facility identification number.”

Those response would have allowed CISA to reach out directly to affected facilities and organizations as they updated their earlier emergency directive on March 11^th and April 13th as new indicators of continuing compromise and additional mitigation measures became available.

Reach Out Again

Since CISA has repeatedly recommended that industrial control system owners and operators use VPNs like Pulse Connect when they find it necessary to remotely access their control systems, it seems to me that they have a special obligation to reach out to that community, especially that portion of the community affected by the CFATS program when a VPN is affected by vulnerabilities as egregious as these.

They may have already reached out to CFATS covered facilities and those other facilities that have submitted Top Screens as they did in the Microsoft incident. It took them five days that time to announce that they had reached out to those facilities. If they have, great. If they have not, then it is past time that they or the Office of Chemical Security should have made the notification.

Action Without Notification

Of course, non-federal facilities do not have to wait until they are specifically invited to review the CISA Alert and Emergency Directive. Once those were published, any facility, and particularly regulated facilities under either CFATS or MTSA security rules, were free to take the actions outlined in the Emergency Directive. If indicators of compromise are detected as a result, immediate regulatory notification should be made to OCS or the Coast Guard as appropriate. Just as important, however, would be to make notifications to CISA so as to ensure that as new information and mitigation measures become available, they would be sent to the affected organizations.

Expanding Outreach

When agencies of the federal government receive emergency directives like this, they should immediately consider sharing the information with entities in the private sector that they regulate if there is any reasonable chance that those entities could also be affected. This is especially true when the agency includes cybersecurity in their regulatory oversight of the entities. Perhaps, CISA ought to consider making that information sharing a requirement in their emergency directives just to make sure that there is as much information sharing as possible.

S 965 Introduced - Cyber Shield Act of 2021

Last month Sen Markey (D,MA) introduced S 965, the Cyber Shield Act of 2021. The bill would establish require the Department of Commerce to establish the Cyber Shield Program; a program for the voluntary certification and labeling of products that meet industry-leading cybersecurity and data security benchmarks to enhance cybersecurity and protect data. The bill is essentially identical to S 2664 that Markey introduced last session. No action was taken on that bill or its companion bill HR 4792.

The products referenced in the bill only apply to ‘consumer facing objects’ that {§2(3)}:

• Connect to the internet or other network; and

• Collect, send, or receive data; or

• Control the actions of a physical object or system

Moving Forward

Markey is a member of the Senate Commerce, Science and Transportation Committee to which this bill was assigned for consideration. This means that he should have enough influence to see the bill considered in Committee, but he also had that influence last session. I have to wonder if he is really interested in seeing this bill move forward.

There is likely to be some Republican opposition to this bill. Since the Cyber Shield Program would be voluntary, I suspect that there could be some bipartisan support, so this bill could be reported out favorably by the Committee.

This bill is not important enough to make it to the floor of the Senate under normal order with its time consuming debate and amendment process. The expected Republican opposition should be sufficient to ensure that it could not be considered under the unanimous consent process. There remains a possibility that Markey could offer the language as an amendment to a spending or authorization bill.

Commentary

The word ‘or’ between §2(3)(B)(i) and (ii) in the definition of ‘covered product’ could mean that the definition could be stretched to include industrial control systems as they ‘control the actions of a physical object or system’, but I think that was included to address automated transportation systems. Since DHS and specifically CISA were left out of the representation list for the Advisory Committee, there is no one to advocate for that stretching of the definition.

Of course, this bill is really intended to only apply to consumer products not industrial products, thus the ‘consumer-facing physical object’ phrase in the definition of a ‘covered product’. Perhaps we need a separate ‘Industrial Shield Program’.

HR 1539 Introduced – PROTECT Act

Last month Rep Aguilar (D,CA) introduced HR 1539, the Providing Rational Options Toward the Elimination of Catastrophic Terrorism (PROTECT) Act of 2021. The bill would require DHS to develop “guidance relating to domestic preparedness for and collective response to terrorism in order to assist in the development of emergency action and response plans for active shooter and mass casualty incidents in public and private locations, including facilities that have been identified by the Department as potentially vulnerable targets” {new §890B(a)}.

Guidance

Section 2 of the bill would amend the Homeland Security Act of 2002 by adding a new §890B. The guidance for ‘emergency action and response plans for active shooter and mass casualty incidents’ could include {new §809B(b)}:

• A strategy for properly responding to an active shooter or mass casualty incident in a public or private location, including training, evacuating, and providing care to persons in such location, with consideration given to the needs of persons with disabilities.

• A plan for establishing a unified command, including identification of casualty collection points and staging areas for law enforcement, fire response, and medical personnel.

• A schedule for regular testing of equipment used to receive communications during such an incident.

• A practiced method and plan to communicate with occupants of such location during such an incident.

• A practiced method and plan to communicate with the surrounding community regarding such an incident and the needs of Federal, State, and local officials.

• A plan for coordinating with volunteer organizations to expedite assistance for victims.

• A schedule for joint exercises and training.

• A plan for outreach to facilities that have been identified by the Department as potentially vulnerable targets.

• Other planning documents, as determined by the Secretary, including appropriate regionally focused products, plans, training, and outreach.”.

Moving Forward

Aguilar is not a member of the House Homeland Security Committee to which this bill was referred for consideration. However, four of his 21 Democratic cosponsors {Rep Clarke (D,NY), Rep Rice (D,NY), Rep Luria (D,VA), and Rep Correa (D,CA)} are members of the Committee. This means that there should be enough influence available to have the Committee consider this bill.

I do not see anything in the bill that would engender any serious opposition to the bill, especially since the guidance ‘requirements’ I have listed above are permissive not mandated. But the fact that there are no Republican cosponsors, even in this highly partisan 117^th Congress, would seem to indicate that there could be some Republican concerns that I do not see. Still, I suspect that the bill would pass out of Committee with significant bipartisan support and could be expected to move the floor of the House via the suspension of the rules process.

This bill would not be considered under the normal order of business in the Senate, it is simply not important enough to take up the time required for the debate and amendment process in the Senate. If there is any significant Republican opposition in the House, the bill would almost certainly not be considered in the Senate under the unanimous consent process. The only other way this bill could make it to the President’s desk would be as an amendment to an authorization or spending bill.

Commentary

This bill does not really fall into any of the categories of bills that I normally follow here in this blog, but it is here because active shooter planning is a pet peeve of mine. I am certainly in favor of active shooter planning, but I am extremely concerned that no one seems to want take into account the unique problems the response to an active shooter incident would entail at a facility with significant storage of hazardous chemicals. Bullets from most handguns and almost all longarms would penetrate the vast majority of chemical storage tanks and almost all portable containers, resulting in leaks of potentially toxic or flammable chemicals into the incident site. And it does not matter if those bullets come from perpetrator firearms or police firearms, the release will occur and further aggravate the situation. This is one of the reasons that the chemical industry has historically been so resistant to the use of armed guards on their facilities.

Any response guidance that does not take into account this potentially catastrophic problem does a serious disservice to law enforcement and private security guards, as well as the general public. With that in mind, I would like to see the following sub-paragraph inserted in §809B(b):

“(8) A plan for facilities that store hazardous chemicals on site that would include prior notification to potential armed responders to an active shooter incident about the hazards associated with the potential release of those chemicals resulting from penetration of bullets into the storage tanks and portable containers on site.”

Public ICS Disclosures – Week of 4-17-21

This week we have two vendor NAME:WRECK disclosures from Carestream and Draeger. We also have nine other vendor disclosures from Aruba Networks (2), Bosch, Advantech, Meinberg, QNAP, VMWare, and Yokogawa (2).

NAME:WRECK Advisories

Carestream published an advisory discussing the NAME:WRECK vulnerabilities. It also addresses the Urgent/11, Ripple20, Amnesia:33, Number:Jack vulnerabilities. Carestream provides generic mitigation measures.

Draeger published and advisory discussing the NAME:WRECK vulnerabilities. Draeger reports that none of its medical devices use the affected stacks.

Aruba Advisories

Aruba published an advisory describing eleven vulnerabilities in their AirWave Management Platform. The vulnerabilities was reported by rceman and harishkumar0394 via BugCrowd, Daniel Jensen, Erik de Jong, and Vidya Bhaskar Tripathi. Aruba has a new version that mitigates the vulnerabilities. There is no indication that researchers have been provided an opportunity to verify the efficacy of the fix.

The eleven reported vulnerabilities are:

• Authentication bypass - CVE-2021-25147,

• Deserialization (2) - CVE-2021-25151 and CVE-2021-25152,

• SQL injection - CVE-2021-25153,

• Privilege escalation - CVE-2021-25154,

• Authenticated XML external entity (3) - CVE-2021-25163, CVE-2021-25164, and CVE-2021-25165,

• Authenticated remote command injection (2) - CVE-2021-25166 and CVE-2021-25167, and

• Authenticated open redirect - CVE-2021-29137

Aruba published an advisory describing ten vulnerabilities in their ClearPass Policy Manager. The vulnerabilities were reported by Luke Young, hateshape and S4thi5h via BugCrowd, Daniel Jensen, and Xavier Danest. Aruba has patches that mitigate the vulnerabilities. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The ten reported vulnerabilities are:

• Unauthenticated server-side request forgery - CVE-2021-29145,

• Authenticated stored cross-site scripting (3) - CVE-2021-29139, CVE-2021-29142, and CVE-2021-29146,

• Unauthenticated XML external entities - CVE-2021-29140,

• Privilege escalation - CVE-2020-7123,

• Authenticated information disclosure - CVE-2021-29138,

• Authenticated command injection - CVE-2021-29147, and

• Authenticated retrieval of sensitive information (2) - CVE-2021-29141 and CVE-2021-29144,

Bosch Advisory

Bosch published an advisory describing 14 vulnerabilities in their Rexroth IoT Gateway and ctrlX CORE products. These are third-party (operating system libraries and the Linux kernel) vulnerabilities. Bosch has updates for one of the affected products, others are pending.

The 14 reported vulnerabilities are:

• Out-of-bounds read - CVE-2020-27815,

• Null pointer dereference - CVE-2020-27830,

• Path traversal - CVE-2020-28374,

• Release of invalid pointer or reference - CVE-2020-28941,

• Improper restriction of operations within the bounds of a memory buffer - CVE-2020-29568,

• Unchecked return value - CVE-2020-29569,

• Use after free (3) - CVE-2020-29660, CVE-2020-29661, and CVE-2021-20232,

• Incorrect default permissions (2) - CVE-2021-24031 and CVE-2021-24032,

• Incorrect conversion between numeric types (2) - CVE-2021-27218 and CVE-2021-27219 (exploit), and

• Insufficient information - CVE-2021-27803

Advantech Advisory

Incibe-CERT published an advisory describing two file parsing vulnerabilities in the Advantech WebAccess/HMI designer product. The vulnerabilities were reported (here and here) by kimiya via the Zero Day initiative. Advantech is working on mitigation measures.

NOTE: This is likely to be reported by NCCIC-ICS this coming week.

Meinberg Advisory

Meinberg published an advisory describing seven vulnerabilities in their LANTIME products. Meinberg has updated firmware versions to mitigate the vulnerabilities.

The seven reported vulnerabilities are:

• CA certificate check bypass - CVE-2021-3450 (OpenSSL),

• Null pointer dereference - CVE-2021-23840, CVE-2021-23841 (both OpenSSL),

• API overflow of output length - CVE-2021-23840 (OpenSSL),

• Heap-based buffer overflow - CVE-2021-3156 (exploits) (SUDO),

• Cross-site scripting – no CVE, and

• Command line injection – no CVE

QNAP Advisory

QNAP published an advisory describing an improper authorization vulnerability in their NAS running HBS 3 Hybrid Backup Sync. The vulnerability was reported by ZUSO ART. QNAP has a new version that mitigates the vulnerability.

VMWare Advisory

VMWare published an advisory describing a privilege escalation vulnerability in their NSX-T products. The vulnerability is self-reported. VMWare has patches available to mitigate the vulnerability.

Yokogawa Advisories

Yokogawa published an advisory discussing the Meltdown/SPECTRE vulnerabilities in their CENTUM VP Controller FCS products. Yokogawa has new versions that mitigate the vulnerabilities in some of their affected products.

Yokogawa published an advisory discussing the Microsoft® VB6 runtime vulnerabilities. Yokogawa has new versions that mitigate the vulnerabilities.

Pharma and CFATS

I had another interesting social media conversation with a new reader. This one was pointed to me by a long-time reader because of cybersecurity regulatory questions for chemical facilities. They brought up some interesting CFATS questions about foreign owned pharmaceutical facilities.

Pharma as Chemical Facility

For manufacturing facilities, the only program that I know of that regulates cybersecurity is the Chemical Facility Anti-Terrorism Standards (CFATS) program. That program is unique for now in that respect. And yes, pharmaceutical manufacturing facilities and some labs could come under the CFATS program. It would depend on the chemical inventory at the site.

CFATS Process Overview

If the facility had one or more of the 300+ DHS chemicals of interest (COI) on site within the last 60 days in an amount in excess of the screening threshold quantity for that chemical, the facility would have to submit an on-line Top Screen survey about the facility and chemicals used there. The DHS Office of Chemical Security (OCS) would then conduct a risk assessment to determine if the facility was at high risk for terrorist attack. If it did, the facility would fall under the CFATS program and would end up having to submit a Site Security Plan (SSP) to OCS for approval. That SSP would have to address each of the Risk Based Performance Standards outlined in the CFATS regulations. Cybersecurity is one of those standards. OCS would conduct periodic compliance inspections once that SSP was approved.

Overseas Facilities

An interesting question came up in the conversation; would overseas facilities be affected by the CFATS programs. Generally speaking, CFATS is only concerned about facilities in the United States and its territories. There is potentially one exception to that and that needs some background.

Typically, the CFATS program just covers a facility that has chemicals of interest on site. Sometimes, however, off-site facilities have an impact on the covered facility’s site security plans. Records about employee background checks could be held at corporate headquarters. Security system monitoring could be conducted at a third-party facility. Or, a covered computer system could reside off-site.

A covered computer system for the purposes of the CFATS program is one that has direct impact on the protection of the COI onsite. This could include process control systems and security control systems. For COI that present a theft-diversion security issue (explosives, chemical weapons, or their precursors) the order control system for the facility would also be considered a covered computer system since it could be used to divert a shipment of the COI. The protection of those computer systems would be covered under the CFATS programs and chemical security inspectors would be expected to ensure their security measures outline in the SSP were properly implemented.

Now, I do not expect that a CSI would travel outside the United States to inspect a covered computer system. First, that could get a tad bit expensive. Second, the authority of those inspectors would stop once our border was crossed. I do, however, think that OCS would insist on having some sort of way of ensuring SSP compliance. I sure that that would be taken care of in the SSP approval process.

S 914 Being Considered in Senate

Yesterday the Senate began consideration of the motion to proceed to consideration of S 914, to amend the Safe Drinking Water Act and the Federal Water Pollution Control Act to reauthorize programs under those Acts. They will be considering the version reported by the Senate Environment and Public Works Committee last week.

A cloture motion has been filed. That motion to close debate on the motion to proceed to consideration of the bill will take place sometime early next week. According to yesterday’s Congressional Record that cloture vote will come after Kahl nomination vote, which comes after McCabe nomination vote, which comes after the Jason Scott Miller nomination vote, which should happen after 5:30 p.m., on Monday, April 26, 2021.

A reminder, there are cybersecurity provisions in the bill.

There have been no amendments proposed for S 914 yet. That process should start to flow on Monday. 

Use and Misuse of CPE’s

Yesterday’s blog post dealt with problems with the current Common Platform Enumeration (CPE) system in keeping track of vulnerabilities that affect multiple systems. In writing that post I kind of glossed over how the CPE is used and how it could be used and misused in the cybersecurity environment.

Current CPE Use

Yesterday’s post was in response to a Twitversation initiated by Ron Brash (got it right today Ron). He was complaining that when a derivative vulnerability was reported using the CVE number from the original vulnerability, the CPE for the newly identified vulnerable devices were not being attached to the original CVE. This is a problem for folks like Ron because it prevents them from effectively using the intended use of the CPE. Let me explain.

If you own just a single control system device, it may be difficult to keep up with the vulnerabilities that affect that device. Some manufacturers do a good job of posting advisories to their web sites and folks like NCCIC-ICS and other CERTS do a good job of reporting on vulnerabilities coordinated through them or are reported to them by vendors. But if the vendor for your product does not publish advisories (an awful lot do not), and if a vulnerability is not reported through a CERT that you follow, it will be easy to miss vulnerability notices. The CPE system, in that case would help you keep track of your device vulnerabilities.

If you own hundreds of devices (not unusual in a manufacturing environment) with lots of different version numbers (again not unusual as equipment is added or replaced) that system of watching vendor web sites or CERT notifications gets a tad bit tiresome. This is where the CPE system really shines (when it is working right, see Ron’s complaint). All you have to do is to have a list of all of your devices and their respective CPE’s and you can write a script (okay I can’t actually write those scripts, but there are plenty of folks who can and that would be a valuable skill set to have in your security team) to periodically search the National Vulnerability Database (NVD) for vulnerabilities that reflect your specific devices.

Now that will not get all of the identified vulnerabilities as some countries do not fully report through the CVE system. But it will get the vast majority of vulnerabilities and should keep you up to date on the available mitigation measures that affect your devices. Then ALL you have to do is figure out how to implement those security measures.

Researcher CPE Use

Now if I were a cybersecurity researcher looking for vulnerabilities, one of the tools that I would use would be the CPE/CVE system. With a list of the devices that I had available to play with, I would write up the same script that I described above to track vulnerabilities in those devices.

I would then look at the CVEs for those identified vulnerabilities for other devices that had the same vulnerabilities. The CPE’s for those devices would then be added to a new script used to look for target vulnerabilities in those other devices that might also apply to the devices in my lab. There is not going to be a 100% overlap, but by careful reading of vulnerability descriptions you should be able to develop a significant list of potential vulnerabilities to search for.

For example, let’s look at the advisory that started this whole chain of blog posts, the NCCIC-ICS advisory for the Rockwell Automation Stratix Switches. If I had one of those switches in my (nonexistent) lab I would go back to CVE-2021-1392 in the NVD and note that that vulnerability was related to the “CLI command permissions of Cisco IOS and Cisco IOS XE”. Using that information, I would look at the CPE list at the bottom of the NVD CVE listing and then search those CPE’s (probably only a handful of the 214 available CPE’s) to see if there were any other ‘CLI command’ related vulnerabilities. I would place those vulnerabilities on my priority research list for the switch I had in my lab.

Adversary CPE Use

If you think that security tools are only used by the good guys (and yes cybersecurity researchers are definitely the good guys) you should not be working in the cybersecurity field. The same techniques that I outline above can by used by the bad guys. Actually, just remember, that adversarial researchers are considered to be the good guys by their side.