Sunday, February 28, 2021

CFATS – Should We Get Rid of 7 RBPS’s?

After writing this week’s review of comments submitted to the CFATS Explosive Removal ANPRM I have been thinking hard about the potential consequences of this ANPRM moving forward. As I continue considering the implications, I think I may be changing my mind about my support for the ANPRM.

General Justification

From the perspective of the 24 facilities that CISA says will be favorably impacted by removing the Division 1.1 chemicals from the Appendix A list of DHS chemicals of interest, support for this rulemaking is easy to justify. They will no longer have to maintain all of the security measures that they put into place for the Chemical Facility Anti-Terrorism Standards (CFATS) site security plans. This will save them significant amounts of money and the time and effort necessary to keep up with the administrative aspects of the program. Easy, peasy.

CISA justifies this deregulatory action by stating that the rules the security and safety rules that the Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF) has in place has ensured that no facility has been placed in the CFATS program for simply for possession of these 49 explosives as a release-security issue. The 24 facilities in the program for just having these explosives on site as a theft/diversion security issue would similarly be adequately protected by those same safety and security measures. Sounds good, but wait.

ATF Generally Aligns with CFATS

Now, all of the recent posts supporting the rulemaking as part of an apparent letter-writing campaign have referenced the same Government Accounting Office report that they claim states that the CFATS program duplicates the BATFE regulations. As I noted in Saturday’s post, that is not what the report actually says.

“ATF’s explosive materials program and TSA’s rail security program contain requirements or guidance that generally align with 11 of 18 CFATS standards.” (pg 21 – .PDF page #)

Now, the key phrase is ‘generally align with’. According to the report (earlier in the same paragraph) that means that they “engage in similar activities”. Later in the report (pg 27) they provide an example of what this means in practice:

“For example, both programs require restricted areas to be secured. Under CFATS, facilities must secure and monitor restricted areas or potentially critical targets within a facility. Security measures may include, for example, physical barriers, guard forces, or intrusion-detection systems. Similarly, ATF requires explosives to be secured. According to ATF, its regulations focus solely on where explosives are stored, rather than the entire facility. In general, ATF requires that its licensees and permittees secure all explosive materials in locked structures meeting ATF-specified criteria.”

If the ATF security rules are adequate for the explosives covered in this rulemaking, would they also not be adequate for all of the other CFATS theft/diversion chemicals of interest? Why should a facility have to pay the cost for the additional security requirements outlined in the CFATS program when cheaper ATF are adequate?

ATF Does Not Address 7 Different RBPS Standards

But remember, the ATF regulations only “generally align with 11 of 18 CFATS standards”. That leaves 7 different risk-based performance standards (RBPS) that the ATF safety and security rules do not address. They are listed on pages 23 thru 26 of the report:

• RBPS #8 – Deter cyber sabotage,

• RBPS #9 – Develop and exercise an emergency response plan,

• RBPS #10 – Maintain effective monitoring, communications, and warning systems,

• RBPS #11 – Ensure proper security training,

• RBPS #13 – Escalate the level of protective measures for periods of elevated threat,

• RBPS #14 – Address specific threats, vulnerabilities or risks, and

• RBPS #17 – Establish officials and an organization responsible for security

Again, if the ATF safety/security program provides adequate security for the Division 1.1 explosives without addressing these seven RBPS, why should any other facility in the program have to comply with these requirements?

Lack of Cybersecurity is Acceptable?

I find it odd in this day and age that the ATF security rules do not address cybersecurity concerns. But what cybersecurity are we really worried about with facilities that store/use the explosives rather than manufacture them? Well, there are two types of cyber systems that a facility that only possesses theft/diversion chemicals would expect to be covered under their site security plan, access control system and the order/delivery systems that route and record sales of the covered chemicals.

Systems that monitor and/or control access to the portions of the facility where covered chemicals or explosives are stored could be a primary target of any adversary that was trying to get unauthorized access to those items. Why wouldn’t these systems have to be protected by adequate cybersecurity? But the ATF does not think that the security of these systems should be regulated (or maybe they were just not given authority to regulate those systems)?

Both the ATF and CISA want their covered facilities to ensure that the facilities vet their customers before delivering chemical/explosives to them. Where that vetting, or more importantly the record of that vetting, is checked on an electronic order approval system, CISA will demand that a CFATS covered facility address the cybersecurity of that system in their site security plan.

How could an adequate security program not address the cybersecurity of these systems? According to this rulemaking, CISA accepts that the lack of cybersecurity in the ATF programs does not affect the adequacy of those security systems. Why then should any other CFATS covered facility be required to address those cybersecurity concerns.

More Comments Coming

We have one more week before the comment period on this ANPRM closes. I will be watching the comment submissions closely over the next week. If I do not see anything that addresses these concerns in that time, I will be submitting a copy of this blog post as a second comment. I think that CISA needs to address these concerns before this rulemaking moves forward to the next stage.

Reader Comments – More on SBOM – 2-28-21

My blog post on software bill of materials (SBOM) sparked a small Twitversation this week. It is always nice to be part of an exchange of ideas. That is, of course, the whole point of writing a blog. So, lets look at what new information surfaced.

Software Component Transparency

SBOM did not rise, phoenix like, from the ashes of my mind. There have been conversations on the topic for sometime now. One extended conversation has been taking place under the auspices of the Department of Commerce’s (DOC) National Telecommunications and Information Administration (NTIA). They, in fact, have a web page dedicated to “NTIA Software Component Transparency” and hold periodic public discussions about aspects of the issue.

Their web page provides a wealth of information on the topic. More importantly, they are actively soliciting participation in various working groups. Those working groups include:

Framing Working Group,

Awareness and Adoption,

Formats and Tooling, and

Healthcare Proof of Concept

It’s Not There

Ron Brash emphasized a point that I tried to make in my post. Just because a vulnerable software component is present in a product does not mean that the product is thus vulnerable. Ron makes the point about Linux kernels; being an open-source product, a developer can take what they want and leave the rest. This is why some sort of vulnerability testing is still necessary.

But, even where vulnerable code does actually exist in the end product, it may not be exploitable in the end product. A lot depends on how the developers access the component and use it in their software/firmware.

Wish List

What would be really nice is if someone could come up with a relatively simple to use Third-Party Vulnerability Tool (TPVT) that could pull data from a database of known vulnerabilities to test and see if vulnerabilities in the known components (from a SBOM) of a product are present in the tested product.

Okay. That means two things on the wish list. First is the TPVT. That will be an interesting development effort. Probably take a 1,000 software engineers. Actually, the database would have to come first, and that, in and of itself, is going to be a monster of a job. I know what a job it is just to keep up with the summaries I do of vulnerability reporting in the ICS field. But a database of all of the versions of all of the potential components (kernels and libraries, oh my) with the associated vulnerabilities, PoC and exploits, that is going to be monumental.

Come to think about it, we may never see this tool. But the NSA might really want one….

Saturday, February 27, 2021

Comments on CFATS Explosive Chemicals ANPRM – 2-27-21

On January 6th, CISA published an advanced notice of proposed rulemaking (ANPRM) for “Removal of Certain Explosive Chemicals From the Chemical Facility Anti-Terrorism Standards”. This is part of a series of blog posts about the public comments submitted in response to that ANPRM. The earlier posts in the series were:

Comments on CFATS Explosive Chemicals ANPRM – 1-30-21

Comments on CFATS Explosive Chemicals ANPRM – 2-14-21

Comments on CFATS Explosive Chemicals ANPRM – 2-20-21

This week there were twelve new comments submitted. All three supported the proposed rulemaking. The comments were from:

Clint Fritz,

James Kinsey, Owen Oil Tools,

Debbie Payne, Owen Compliance Services,

Patrick Valentino, Hunting Titan,

Terry Newton, Nelson Brothers,

Ralph M. Hymer, Nelson Brothers,

Ralph M. Hymer,

Chris Bridges, Owen Oil Tools,

Jason M Ryan, Orica USA,

Jon Southerland, Accurate Energetic Systems,

Lea DeVellis,

Paul E. Smith, Pyrotechnics Guild International

Letter Writing Campaign

The first eleven submissions listed above have very nearly identical wording. This indicates that there is a letter writing campaign that has been initiated to support this rulemaking. Supportive letter writing campaigns are an interesting effort in influencing regulatory action. CISA does not ‘count votes’ in their consideration of the rulemaking; they are required to review and consider the information provided by the commentors in moving the rulemaking. Multiple submissions with no new information means that CISA has less work to do to move this forward.

GAO Study

All eleven campaign comments contain the following comment:

“On January 21, 2021, the Government Accountability Office (GAO) released their study reviewing the CFATS program and overlap with other chemical security programs. The study found that most CFATS Risk-Based Performance Standards (RBPS) directly overlap with ATF regulatory requirements for commercial explosives.”

What the Report actually says is “ATF’s explosive materials program and TSA’s rail security program contain requirements or guidance that generally align with 11 of 18 CFATS standards.” (pg 27). According to the Report (pgs 23-6) the ATF program does not address the following CFATS risk-based performance standard requirements:

• Deter cyber sabotage,

• Develop and exercise an emergency response plan,

• Maintain effective monitoring, communications, and warning systems,

• Ensure proper security training,

• Escalate the level of protective measures for periods of elevated threat,

• Address specific threats, vulnerabilities or risks, and

• Establish officials and an organization responsible for security

The additional CFATS security requirements explain why the CFATS program has a higher security cost at these facilities. None of the commentors to date have explained why these security requirements are excessive for facilities licensed to handle explosives.

Duplicative Inspections

The one whole original submission this week was from Pyrotechnics Guild International. Smith raises a point that I have not seen in any of the comments to date, duplicative inspections. They note:

“The ATF already does unannounced inspections which require taking time away from that day's production duties.  Adding yet another inspection, of the same materials, and adding duplicative documentation increases time spent on the same or very similar regulatory focus.”

Public ICS Disclosures – Week of 2-20-21

This week we have six vendor disclosures from Advantech, Aruba Networks (2), Bosch, Carestream, and VMware. We have researcher a report for products from Secomea (and B&R automation). Finally, there are two remote access exploits for products from ASUS and

Advantech Advisory

Advantech published an advisory discussing the DNSpooq vulnerabilities in their industrial cellular routers. Advantech notes that their routers are only vulnerable to the three ‘cache poisoning’ vulnerabilities. Advantech has new firmware that mitigates the vulnerabilities.

Aruba Advisories

Aruba published an advisory discussing the DNSpooq vulnerabilities in their products. Aruba reports that their products are only vulnerable to the three ‘cache poisoning’ vulnerabilities. Aruba will update the dnsmasq in “future routine maintenance patches”.

 

Aruba published an advisory describing twelve vulnerabilities in their AirWave Management Platform. The vulnerabilities were reported by multiple researchers via the BugCrowd platform. Aruba has a new version that mitigates the vulnerability. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The twelve reported vulnerabilities are:

• Cross-site request forgery (2) - CVE-2021-29960 and CVE-2021-29961,

• Command injection (2) - CVE-2021-29962 and CVE-2021-29963,

• Improper access control - CVE-2021-29964,

• SQL injection (2) - CVE-2021-29965 and CVE-2021-29966,

• Reflected cross-site scripting - CVE-2021-29967,

• Authenticated stored cross-site scripting - CVE-2021-29968,

• Authenticated XML external entity - CVE-2021-29969, and

• Authenticated remote command injection (2) - (CVE-2021-29970 and CVE-2021-29971

Bosch Advisory

Bosch published an advisory describing three vulnerabilities in their ctrlX CORE and the IoT Gateway. These are third-party (Linux kernel and sudo) vulnerabilities. Bosch reports that the next updates for the affected products would include updates for both the kernel and sudo.

The three reported vulnerabilities are:

• Improper locking and use after free - CVE-2020-29661,

• Out-of-bounds write - CVE-2021-3156 (multiple exploits publicly available), and

• Use after free - CVE-2021-3347 (exploit publicly available)

Carestream Advisory

Carestream published an advisory [.PDF download link] describing a heap-based buffer overflow vulnerability in a number of their products. This is a third-party (Chrome) vulnerability. Carestream reports that Chrome will be updated with the next software release for most of the affected products. This vulnerability has been exploited in the wild, but not yet in Carestream products.

VMware Advisory

VMware published an advisory describing three vulnerabilities in their VMware ESXi and vCenter Server. The vulnerabilities were reported by Mikhail Klyuchnikov of Positive Technologies, and Lucas Leong via the Zero Day Initiative. VMware has new versions that mitigate the vulnerabilities. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The three reported vulnerabilities are:

• Remote code execution - CVE-2021-21972,

• Heap-based buffer overflow - CVE-2021-21974,

• Server-side request forgery - CVE-2021-21973

Tenable has published a report on the vulnerabilities noting that these vulnerabilities have been exploited in the wild. NebulabdSec has published proof-of-concept code for the RCE vulnerability.

Secomea Report

Tenable published a report (including proof-of-concept code) describing three vulnerabilities in the Secomea GateManager (also applies to B&R GateManager). The report was coordinated with both Secomea and B&R; Secomea has a new version that mitigates the vulnerability. B&R’s response is pending.

The three reported vulnerabilities include:

• Reflected cross-site scripting - CVE-2020-29028,

• Authentication token exposed in URL path - CVE-2020-29030, and

• Authenticated malicious firmware upload - CVE-2020-29029

NOTE: This is likely to be a third-party vulnerability in products from vendors other than B&R.

Remote Access Exploits

H4rk3nz0 published an exploit for a remote code execution vulnerability in the ASUS Remote Link. There is no CVE# listed and no indication that ASUS had been contacted. This may be a 0-day exploit.

MATTHEW DUNN published a Metasploit module for an authentication timing vulnerability for Remote Desktop Web Access. The is no CVE# and no indication that Microsoft has been contacted. This may be a 0-day exploit.

Friday, February 26, 2021

Reader Comment – Software Bill of Materials

Yesterday, Jake Brodsky, a long-time reader and significant control system commentator in his own right, left a comment on my blog post about detecting third-party vulnerabilities. He suggests that a possible solution to the problem could be found in requiring vendors to prepare/publish a software bill of materials (SBOM) for control system products. The comment should be read by all with an interest in control system security.

SBOM is not a new idea. It is based upon the ‘bill of materials’ concept used in manufacturing where a manufacturer maintains a list of components (and their supplier) used to assemble a product. It allows the vendor to trace back faults reported by customers and identify appropriate corrective actions. Similarly, a software vendor could use a SBOM to track third-party components in its own products and the vulnerabilities reported in those components. This would allow the vendor to update their product with appropriate security fixes. There is an interesting blog post over on Synopsys.com outlining the importance of this use of a SBOM.

What Jake is suggesting, however, is to make the SBOM available to the end user. Legislation (HR 5793) was actually introduced in the closing days of the 113th Congress to require SBOM submissions to federal agencies for any item purchased that contained software or firmware, but no action was taken. It was not subsequently introduced in the next session. I did not review the text because it was published after the session was ended. It is a short bill and worth reading even with the convoluted legislative-speak used by Rep Royce’s staff.

There are a couple of major problems, however, with providing an SBOM to owner/operators. First, there is the problem of tracking vulnerability reporting across the wide spectrum of libraries and software components. The National Institute of Standards NVD database is searchable and it is probably the most comprehensive database, but it does have its limitations. The most notable limitation is described on its search page: “Linux kernel vulnerabilities are categorized separately from vulnerabilities in specific Linux distributions.” The second problem is that there is no reporting capability in the NVD database, you have to physically do a search for each component listed in the SBOM each time that you want to verify that there have been no changes to the vulnerability status of the components. Are you going to do that search once a week, once a month, once a year?

To be fair to Jake, the suggestion that I made in the original blog post for researchers to establish test procedures that would identify the vulnerability they reported has essentially the same problem. How would a manufacturer know when that particular researcher published a new tool that may or may not apply to the equipment they own/operate?

We are starting to see SBOM products for developers (see the Revenera web site for example). These tools help developers track the components they employ in their software. Some even provide the developer with “Actionable alerts for newly discovered vulnerabilities in current and shipped products.” For SBOM to be a useful security management tool for owner/operators similar tracking software would be needed.

Thursday, February 25, 2021

4 Advisories Published – 2-25-21

Today the CISA NCCIC-ICS published four control system security advisories for products from ProSoft Technology, Rockwell Automation, Fatek, and PerFact.

ProSoft Advisory

This advisory describes a permissions, privileges, and access controls vulnerability in the ProSoft industrial cellular gateways. The vulnerability was reported by Maxim Rupp. ProSoft has a new firmware version that mitigates the vulnerability. There is no indication that Maxim has been provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow an attacker to change the current user’s password and alter device configurations.

Note: Interesting Twitversation about this advisory today.

Rockwell Advisory

This advisory describes an insufficiently protected credentials vulnerability in the Rockwell  Studio 5000 Logix Designer, RSLogix 5000, Logix Controllers.  The vulnerability was independently reported by Lab. of Information Systems Security Assurance, Kaspersky, and Claroty. Rockwell describes compensating controls to mitigate the vulnerability. There is no indication that the researchers were provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow a remote unauthenticated attacker to bypass the verification mechanism and connect with Logix controllers. Additionally, this vulnerability could enable an unauthorized third-party tool to alter the controller’s configuration and/or application code.

Fatek Advisory

This advisory describes five vulnerabilities in the Fatek FvDesigner software tool. The vulnerabilities were reported by Francis Provencher and rgod via the Zero Day Initiative. Fatek is working on mitigation measures.

The five reported vulnerabilities are:

• Use after free - CVE-2021-22662,

• Access of uninitialized pointer - CVE-2021-22670,

• Stack-based buffer overflow - CVE-2021-22666,

• Out-of-bounds write - CVE-2021-22683, and

• Out-of-bounds read - CVE-2021-22638

NCCIC-ICS reports that a relatively low-skilled attacker with uncharacterized access could exploit the vulnerabilities to allow an attacker to read/modify information, execute arbitrary, and/or crash the application.

PerFact Advisory

This advisory describes an external control of system or configuration setting vulnerability in the PerFact OpenVPN-Client. The vulnerability was reported by Sharon Brizinov of Claroty. PerFact has a new version that mitigates the vulnerability. There is no indication that Sharon has been provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow for local privilege escalation or remote code execution through a malicious webpage.

Philosophy of Cybersecurity Legislation – Part 2: How to Regulate

This is part of a continuing series on the Philosophy of Cybersecurity Legislation. With all of the calls for improving cybersecurity and the increasing sense that legislation is necessary this series will try to define the necessary parameters for effective cybersecurity legislation. The earlier post in the series was:

Part 1: What to Regulate

Flexibility Needed

The most common complaint about calls for cybersecurity legislation over the last ten years or so has been that the cybersecurity field changes so quickly that any legislative effort is doomed to being out-of-date by the time that it is enacted. New types of threats, the expanding scope of cyber operations in daily life and the ever-changing variety of tools used by both defenders and attackers all make it hard for the crafters of legislation to provide laundry lists of do’s and don’ts in their legislative efforts.

Having said that, there are four key areas that any successful cybersecurity program is going to have to address:

• Identify critical cyber components,

• Limit access to those components,

• Monitor those components for signs of compromise, and

• Have a plan in place to recover operations.

I am not trying to say that an organization can afford to ignore the security of non-critical cyber components, but national-level cybersecurity legislation is going to have to focus on critical operations (CO) of private-sector critical-infrastructure (PSCI). There is just not enough time, money or personnel available to the federal government to worry about the cybersecurity infrastructure of each and every component of the economy.

Identify Critical Cyber Components

The task of identifying the 3Cs, ‘critical cyber components’ is going to be the key to a successful national critical infrastructure cybersecurity program, and it is going to be the most difficult process to define for this legislative effort. Each critical infrastructure sector is going to have different types of economic output that are going to have to be protected and each facility is going to have a different set of cyber controls in place that guides the completion of that output.

The goal of a successful critical infrastructure cybersecurity bill is not going to be to define what the 3Cs are for each and every facility in the United States. The task would be monumental, it would never be complete, and there would be too much resistance from every sector of the economy to ever allow the bill to pass. No, that task is going to have to be passed to the regulators at the Sector Specific Agencies (SSA) that oversee federal efforts to help protect each of the 16 CI sectors.

Even these regulators are going to have a tough time defining how each facility identifies its own 3Cs. One thing is certain however, the regulatory definitions are going to have to be operational in nature, basing the criteria on what systems are absolutely necessary for the continued output of whatever product or service that makes the facility critical infrastructure in the first place.

For example, in the Chemical Facility Anti-Terrorism Standards (CFATS) program DHS defines critical cyber systems as those that directly impact the safe/secure storage, handling or shipping of one or more of the DHS chemicals of interest at the facility which are the basis for the facility being covered by the CFATS regulations. Only those critical cyber systems have to be addressed in the facility’s site security plan. Facilities would probably want to protect their other cyber systems, but that is not the worry of the CFATS program.

Limit Access to 3Cs

Limiting access to 3Cs is one of those areas that legislative efforts are going to have to be carefully directed away from requiring specific types of technology for solving the access problem. The systems across the 16 critical infrastructure sectors are just too diverse for a single solution to be effective. While encrypted communications and two-factor authentication (2FA) will certainly be widely used in securing critical cyber components, requiring their use will be self-defeating when the next adversarial tool defeats 2FA or a new cybersecurity upstart comes up with an easier more effective way to address remote operations.

No, what a national legislative solution to protecting CO-PSCI from cyber-attacks is going to have to do is to authorize the regulators to establish processes by which regulated facilities can propose methodology to limit access to their 3Cs. If those methods achieve the four goals listed below then regulators would be required to accept the methodology:

• Systems in place to administratively identify those who are authorized access to 3Cs,

• Systems in place to confirm that a person attempting access is authorized for that level of access,

• Systems in place to alert appropriate authorities when an unauthorized access is attempted, and

• Systems in place to prevent unauthorized person from manipulating the controls of, or information transiting, a 3C component.

Notice that protecting access to information in a 3C component is not one of the four goals of limiting access. Where a primary purpose of a 3C component is the protection of information from unauthorized access the SSA should be authorized by this legislation to include ‘residing in or’ between the words ‘information’ and ‘transiting’ in the fourth goal above.

Monitoring for Signs of Compromise

This has always been one of those areas of cybersecurity that has caused multiple problems in the past. If the definition of attack is too broad (pinging a connection for instance) there are too many compromises to effectively deal with and if they are too narrow (publication of compromised data for example) then the attacker has had way too much access to the system for effective mitigation.

But again, if we limit the systems of concern to just the 3Cs and limit access in the way’s describe above we can have a better handle on defining signs of compromise. A simple definition could be the transit of data or command into or out of the defined system either via an unauthorized mode of communication, or to/from an unauthorized source or destination.

Another sign of compromise has been suggested by the Coast Guard in a recent Marine Safety Information Bulletin (MSIB 03-21) [corrected # and provided link, 3-16-21 10:17 EDT] where it required any MTSA covered vessel or facility to report a breach of security if:

• They have downloaded the trojanized SolarWinds Orion plug-in (see FBI Private Industry
Notification 20201222-001 https://www.ic3.gov/Media/News/2020/201229.pdf); or
• They note any system with a critical security function displaying any signs of compromise,
including those that may have not originated from the SolarWinds Orion compromise but utilize
similar TTPs (see CISA Alert AA20-352A).

Thus, we could include a requirement to include checking for indicators of compromise published by CISA, the FBI, NSA, the SSA for the PSCI, or the applicable industry or sector information sharing and analysis center (ISAC).

Again, how systems were monitored would be a regulatory matter for the SSA crafting the implementing regulations.

Recover Operations

One thing that is obvious from the SolarWinds breach is that any organization can be breached given an adversary with the appropriate resources and desire. Thus, any cybersecurity plan must contain a response plan for how the system will be recovered when a successful attack does occur. Again, since the scope of a response plan is going to vary from sector to sector, the legislation would not be expected to describe the acceptable parameters of a cyber response plan beyond the goal of returning to operation those parts of the business that are deemed to be the critical operations that were responsible for the facility being regulated as a CO-PSCI.

One thing that the recovery plan will have to include is the identification of outside resources that the facility will need to recover from a successful cyber-attack. SSA’s should be required to compile those lists from CO-PSCI across the sector and periodically report to Congress on those recovery assets that facilities would have to have assistance from the government to obtain in the event of a worst-case attack. FEMA could then be given the task of stockpiling the appropriate assets to aid recovery operations.

Part 3 to this series will address information sharing.


Wednesday, February 24, 2021

Detecting 3rd Party Vulnerabilities

I recently read a research report by Claroty on their work detecting vulnerabilities in various OPC protocol stacks. The vulnerabilities were disclosed and ‘corrected’ last year by the vendors identified in the report. It is an interesting report, though perhaps a little to cyber geek for my level of expertise, but certainly a worthwhile contribution to the cybersecurity literature. It does, however, leave an important question unanswered.

The vendors identified in this report, like those that have been recently reported in TCP/IP stack vulnerabilities, are not vendors (or at least the affected products) that control system owner/operators typically deal with on their plant floors. The vulnerable products are used, however, as third-party components of many of those products in everyday industrial control system settings. We have seen only a limited number of advisories about these vulnerabilities in vendor products that are being bought by industry. Does that mean that these vulnerabilities do not impact the actual owner/operators of control systems? That is the $64 million question.

In some unknown number of cases, vendors may have already included in their equipment design programming ‘fixes’ that mitigate these third-party vulnerabilities. They may not even have known that they were mitigating vulnerabilities. Unrelated design decisions and program utilizations may have already taken care of the problems.

In an equally unknown number of cases, vendors are working hard at correcting the problems caused by these vulnerabilities by either incorporating the updated third-party software or specifically reworking their programming to neutralize the effects of the vulnerabilities.

Unfortunately, the third case, again in an unknown number of cases, the vendor is quietly holding their breath and hoping that no one will notice that their equipment is vulnerable to these third-party vulnerabilities.

How is an owner/operator of a control system to know which case applies to the systems in use on their production floor? There is not a good answer to that question. Aside from taking the proof-of-concept code available in research reports like those in the Claroty UPA paper and crafting a test of their own equipment (and how many owner/operators have that level of engineering support on hand?) there is not currently a good way to know.

The researchers who report these vulnerabilities do not have the time, and most certainly not the resources, to test every possible control system device to see if it is affected by these third-party type vulnerabilities. What they could do, with some unknown level of additional effort, is to provide code testing protocols for owner/operators to use to test their systems to see if they would be impacted by the vulnerabilities. This could even be a product that they could sell to help compensate them for the extra work.

Bills Introduced – 2-24-21

Yesterday with both the House and Senate in session, there were 117 bills introduced. Of those bills, three may receive additional coverage in this blog:

HR 1229 To amend title 18, United States Code, to reauthorize and expand the National Threat Assessment Center of the Department of Homeland Security. Rep. Deutch, Theodore E. [D-FL-22] 

HR 1251 To support United States international cyber diplomacy, and for other purposes. Rep. McCaul, Michael T. [R-TX-10]

S 391 A bill to amend title 18, United States Code, to reauthorize and expand the National Threat Assessment Center of the Department of Homeland Security.  Sen. Grassley, Chuck [R-IA] 

I will be watching the two NTAC bills for language that addresses cybersecurity or chemical security issues. I suspect that these will be companion bills with essentially identical language.

I will be watching HR 1251 for language and definitions that are inclusive of control system security concerns.

 

Because many readers of this blog are intimately connected with the energy industry, I want to mention in passing S 398 that was introduced yesterday by Sen. Kennedy, John [R-LA]. The bill would amend the Homeland Security Act of 2002 to clarify that utility line technicians qualify as emergency response providers. I have not delved into what rights and benefits that this would provide to these brave and selfless folks that support our communities through all sorts of unpleasantness, but I am sure that it will not be enough. Kennedy is not a member of the Senate Homeland Security and Governmental Affairs Committee to which this bill was assigned, so a letter writing campaign to Sen Peters (D,MI), the Chair of that Committee, to urge the Committee’s consideration of the bill might be in order.

Tuesday, February 23, 2021

3 Advisories Published – 2-23-21

Today CISA’s NCCIC-ICS published three control system security advisory for products from Advantech (2) and Rockwell Automation.

Spectre RT Advisory

This advisory describes nine vulnerabilities in the Advantech Spectre RT Industrial Routers. The vulnerabilities were reported by Ilya Karpov and Evgeniy Druzhinin of Rostelecom-Solar and Vlad Komarov of ScadaX. Advantech has a newer version that mitigates the vulnerabilities. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The nine reported vulnerabilities are:

• Improper neutralization of input during web page generation - CVE-2019-18233,

• Cleartext transmission of sensitive information - CVE-2019-18231,

• Improper restriction of excessive authentication attempts - CVE-2019-18235,

• Use of broken or risky cryptographic algorithm (3) - CVE-2018-20679, CVE-2016-6301, and CVE-2015-9261 {3rd party vulnerabilities (BusyBox)}, and

• Use of platform-dependent third-party components (3) - CVE-2016-2842, CVE-2016-0799, CVE-2016-6304 {3rd party vulnerabilities (OpenSSL)}.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerabilities to allow information disclosure, deletion of files, and remote code execution. A number of the NIST CVE reports contain links to publicly available exploits for selected vulnerabilities.

NOTE: I briefly discussed these vulnerabilities back in January.

BB-ESWGP Advisory

This advisory describes a use of hard-coded credentials vulnerability in the Advantech BB-ESWGP506-2SFP-T industrial ethernet switches. The vulnerability was reported by an anonymous researcher via the Zero Day Initiative. Advantech no longer supports this product.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow an attacker to gain unauthorized access to sensitive information and execute arbitrary code.

Rockwell Advisory

This advisory describes a use of password hash with insufficient computational effort vulnerability in the Rockwell FactoryTalk Services Platform. The vulnerability is self-reported. Rockwell has a new version that mitigates the vulnerability.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow a remote, unauthenticated attacker to create new users in the FactoryTalk Services Platform administration console. These new users could allow an attacker to modify or delete configuration and application data in other FactoryTalk software connected to the FactoryTalk Services Platform.

NOTE: I briefly discussed this vulnerability in August of last year.

Monday, February 22, 2021

Committee Hearings – Week of 2-21-21

This week, with both the House and Senate in session, there is a fairly normal hearing schedule on both sides of Capitol Hill. The Senate is concentrating on confirmation hearings, as would be expected. There is one cybersecurity hearing and two others that may touch on cybersecurity issues.

SolarWinds Breach

On Friday there will be a joint hearing of the House Oversight and Reform Committee and the House Homeland Security Committee on “Weathering the Storm: The Role of Private Tech in the SolarWinds Breach and Ongoing Campaign”. It will be a closed hearing and no witness list is currently available. There is a remote chance that there will be some discussion or at least questions about the impact of the Breach on industrial control system security, but we will probably never hear about them.

There will be more hearings on this topic, many of them public with lots of finger pointing and gnashing of teeth. Do not expect more than theater at this point.

Possible Cybersecurity Mentions

There are two hearings this week that may include some discussion about control system cybersecurity, but I will not be holding my breath. I call them out because of multiple mentions in the media about the possibility that the COVID relief bill could include some sort of funding for cybersecurity at water facilities.

This afternoon the House Budget Committee will hold a markup hearing on the “American Rescue Plan Act of 2021”. The text of the bill that the Committee will markup does not include any mention of cybersecurity. This is presumably one of the bills mentioned in last week’s post on TheCipherBrief that would provide funding for water facility cybersecurity. There is a $50 million mention (§3033) of funding for water facilities, but that is targeted to help pay overdue water bills. We might see something added in the markup, but not likely.

The second hearing will be conducted tomorrow by the Water Resources and Environment Subcommittee of the House Committee on Transportation and Infrastructure on “Building Back Better: The Urgent Need for Investment in America’s Wastewater Infrastructure”. No witness list is currently available. Again, there is a rather remote possibility that cybersecurity for these facilities could be mentioned in light of the recent drinking water hack in Florida.

Sunday, February 21, 2021

Philosophy of Cybersecurity Legislation – Part 1: What to Regulate

There has recently been a lot of talk in the national media and political theater about the need for cybersecurity legislation to protect against cybersecurity threats such as the SolarWinds hack and the water facility ‘attack’ in Florida. Before one starts talking about the potential nuts and bolts of such legislation, I think that it is important to consider what I like to call the philosophy of cybersecurity legislation; the what and why of legislative need.

What to Legislate

The first thing that you need to establish is what one wants the federal government to regulate, or more importantly what one wants to accomplish with that regulation. For cybersecurity the most obvious desire would be to stop any foreign adversary from disrupting government and private-sector cyber-operations within the United States. That would certainly fit with the ‘provide for the common Defence’ provision of Article 1, Section 8, Clause 1 of the Constitution.

Unfortunately, short of throwing up a national firewall around the United States where the federal government controls all information and communications flowing into and out of the country, there is no method that the government is going to be able to intercept and prevent all attacks via either the internet or telecommunications infrastructure. Such governmental control of information flow would be an intolerable anathema to most Americans and legislators. So, the scope of the legislative intent will almost certainly have to be reduced.

We already have legislation in place that give the DHS Cybersecurity and Infrastructure Security Agency (CISA) extensive authority for protecting the federal government (except DOD and intelligence agencies) from cyber-attacks. Thus, broad new authority is not needed; just fine tuning and perhaps funding adjustments are all that should be required for preventing future SolarWinds type attacks. (Okay, that is being a tad simplistic as the nuts and bolts of such prevention have yet to be adequately discussed, but for a philosophy discussion that is just left as an exercise for the student – GRIN.)

With a national firewall off the board as a means of defense, we have to decide if preventing all foreign adversary attacks on private-sector cyber-operations is a reasonable goal for our legislative intent. First off, do we really suspect that a foreign government is going to want to target the disruption of the private email between ordinary citizens or the operation of my wife’s jewelry sales site on Etsy (I’ve been trying for weeks to figure out how to get that advertisement into my blog)? And if they did, for some obscure reason, would that really fit within the description of ‘provide for the common defense’?

Limit the Scope to CI

A more reasonable use of the federal government’s cyber resources, both money and personnel are significant constraints on any legislative endeavor, would be to limit non-federal government cyber defense to critical infrastructure. That is still an expansive (and potentially expanding) set of cyber resources to protect, but it would certainly be a more justifiable use of federal resources.

That leaves an important gap in the area needing cyber protection, that is the protection of the cyber resources of State, local, Tribal and Territorial (SLTT) government. Because of the curious constitutional separation of rights and responsibilities of governmental authority in the United States, the current CISA authority over governmental cybersecurity does not directly extend to SLTT government operations. They are currently restricted to providing advice and limited assistance to those governments.

For the purposes of this discussion, I will assume that general SLTT government cybersecurity is going to take separate legislation from that being discussed here due to the wide disparity in the needs and desires for federal cybersecurity support from SLTT governments. I will, however, include in the remaining discussion those SLTT operated pieces of critical infrastructure like drinking water treatment plants and wastewater treatment facilities.

So, for this discussion we are looking to discuss writing legislation that attempt to prevent a foreign adversary from disrupting the cyber-operations of private-sector critical infrastructure (PSCI) including SLTT owned and operated water and wastewater operations.

What Cyber-Operations Will Be Protected?

Are we going to try to protect all of the cyber-operations of these PSCI entities? That is a very wide field of dreams, covering email, payroll, personnel administration, security, and operations. On one hand, the one thing that differentiates PSCI from other private sector entities is typically the output of their operations. The federal government’s interest is in ensuring the continued output of the critical operations (CO) of PSCI so the intent of the legislation is to protect those CO of PSCI from disruption by foreign adversaries. To be sure CO of PSCI protection may necessitate providing protections against disruption of other cyber-operations of PSCI or at least mitigating the effect of those other disruptions on the CO.

Congressional Oversight Impact

So, a critical portion of the any legislative action will be how to identify what facilities in the United States will be affected by the legislation. The problem here is that different sorts of critical infrastructure are regulated by different portions of the federal government. Even when considering security, the different executive departments did not surrender their oversight to the Department of Homeland Security.

Even if new legislation did give CISA authority to regulate cybersecurity at PSCI, there would still be the problem of congressional oversight to deal with. We have specifically seen this with the CFATS program legislation. While there is frequently disagreement between the House and Senate on legislative matters, the larger stumbling block for CFATS legislation has been the conflict between the House Homeland Security Committee and the Energy and Commerce Committee. This has more to do with the different foci of the two Committees than inter-party conflict we typically seen in House-Senate relations. The internecine conflict between House committees would be intense in any PSCI cyber-legislative effort.

The National Infrastructure Protection Plan (NIPP) provides a methodology to overcome the problems identified above. The federal government has already designated which executive departments are responsible for the oversight of security at the 16 different critical infrastructure sectors; these are designated as Sector Specific Agencies (SSA). Thus, our cybersecurity legislation does not need to identify who will be responsible for regulating which sectors, it can simply rely on the oversight designations that already exist.

Identifying Operations to be Protected

With these political considerations and the inevitable push-back by industry against any new regulations, defining what cyber-operations would be covered in different industries would be difficult. The general definition though, should be easier. We would only have a federal interest in regulating those cyber-operations that have a direct impact on the entities capability of providing the critical output for which receive the critical infrastructure definition. While protecting other cyberoperations might be beneficial, the federal interest in ensuring critical output should limit the application of federal influence to just those operations.

Legislation would each SSA to establish by regulations criteria for identifying PSCI entities that require cybersecurity oversight to protect national security and national preparedness. The intent would not be a broad definition to encompass as many facilities as possible, but rather to limit the identification of facilities to those that are the most critical to the economy or national security of the United States. The reason for this limitation is that the government agencies responsible for the oversight have only limited resources for ensuring that the resulting cybersecurity regulations are followed by the identified agencies.

And make no mistake about it, enforcement of cybersecurity regulations will be necessary. We need look no further than the various OSHA and EPA safety regulations to see that without effective enforcement many facilities are going to only have paperwork, check-the-box, cybersecurity programs. Even with the facilities that are going to make an  honest effort to comply with the regulations, the lack of facility cybersecurity expertise will limit the effectiveness of those efforts.

In Part 2, I will look at the philosophy of how to regulate that should drive cybersecurity legislation.

Saturday, February 20, 2021

Comments on CFATS Explosive Chemicals ANPRM – 2-20-21

On January 6th, CISA published an advanced notice of proposed rulemaking (ANPRM) for “Removal of Certain Explosive Chemicals From the Chemical Facility Anti-Terrorism Standards”. This is part of a series of blog posts about the public comments submitted in response to that ANPRM. The earlier posts in the series were:

Comments on CFATS Explosive Chemicals ANPRM – 1-30-21

Comments on CFATS Explosive Chemicals ANPRM – 2-14-21

This week there were three new comments submitted. All three supported the proposed rulemaking. The comments were from:

Institute of Makers of Explosives,  

Jason Rawlings, Austin Powder Company, and

Chris MacDonald

 Cost of Compliance

The comments from IME include the results of an internal 2017 study of the cost of complying with the CFATS regulations for three different (unnamed) facilities. One-time costs ranged from $433,820 to $1,000,000. Recurring annual costs ranged from $70,400 to $125,000. Presumably, the costs cited are over and above the costs associated with BATF security regulations.

Commentary

These comments have done little to explicate why the CFATS security costs are higher than those associated with the BATF regulations, nor have they described why the added security requirements from the CFATS program are unnecessary. If the added security measures mandated by the CFATS program to prevent the theft of explosives from have not provided any additional benefit as suggested by these commentors, then perhaps CFATS program should remove those requirements from other facilities that possess the other non-explosive DHS chemicals of interest with a theft/diversion security concern.

Public ICS Disclosure – Week of 2-13-21

This week we have nine vendor disclosures from Aruba Networks, PEPPERL+FUCHS (3), Dell, Moxa, Philips, QNAP, and Rockwell. There is an update from Mitsubishi. We have three researcher reports for vulnerabilities in products from Advantech (2) and Sytech. Finally, we have an exploit for a product from DDC.

Aruba Advisory

Aruba published an advisory describing eleven vulnerabilities in their ClearPass Policy Manager. The vulnerabilities were reported by Daniel Jensen, Luke Young, Fernando Romero de la Morena, and the Microsoft Security Team. Aruba has new versions that mitigate the vulnerability. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The eleven reported vulnerabilities are:

• Cross-site scripting - CVE-2021-26678,

• Command injection (5) - CVE-2021-26681, CVE-2021-26679, CVE-2021-26680, CVE-2021-26683, and CVE-2021-26684,

• Local escalation of privilege - CVE-2021-26677,

• SQL injection (2) - CVE-2021-26685 and CVE-2021-26686,

• Reflected cross-site scripting - CVE-2021-26682, and

• Buffer Overflow - CVE-2020-7120

PEPPERL+FUCHS Advisories

CERT-VDE published an advisory describing an out-of-bounds write vulnerability in multiple PEPPERL+FUCHS products. This is a third-party (RTA) EtherNet/IP Stack vulnerability. Generic mitigation measures were described.

 

CERT-VDE published an advisory describing a stack-based buffer overflow vulnerability in multiple PEPPERL+FUCHS products. This is a third-party (Hilscher) PROFINET IO Device vulnerability. Generic mitigation measures were described.

 

CERT-VDE published an advisory describing a stack-based buffer overflow vulnerability in multiple PEPPERL+FUCHS products. This is a third-party (Hilscher) EtherNet/IP stack vulnerability.

Dell Advisory

Dell published an advisory describing an exposure of sensitive information to an unauthorized actor vulnerabilty in their EMC PowerProtect Cyber Recovery product. The vulnerability is self-reported. Dell has a new version that mitigates the vulnerability.

Moxa Advisory

Moxa published an advisory describing a heap-based buffer overflow vulnerability in multiple products. This is a third-party (SUDO) vulnerability. Exploits are publicly available. Moxa has upgrades available to mitigate the vulnerability.

Philips Advisory

Philips published an advisory describing three TCP/IP vulnerabilities in their products running on Microsoft Windows. The three CVE numbers (CVE-2021-24074CVE-2021-24094, and CVE-2021-24086) provided in the advisory are listed as ‘Reserved’ by cve.mitre.org so it is not clear what MS vulnerabilities are specifically being reported, but Philips is reportedly reviewing MS patches.

QNAP Advisory

QNAP published an advisory describing a stack-based overflow vulnerability in their QNAP NAS running Surveillance Station. The vulnerability was reported by an unnamed ‘independent security researcher’. QNAP has new versions that mitigate the vulnerability. There is no indication that the researcher has been provided an opportunity to verify the efficacy of the fix.

Rockwell Advisory

Rockwell published an advisory describing an uncontrolled search path element vulnerability in their DriveTools™ and Drives AOP products. The vulnerability was reported by Cim Stordal of Cognite and Claroty. Rockwell has new versions that mitigate the vulnerability. There are no indications that the researchers have been provided an opportunity to verify the efficacy of the fix.

Mitsubishi Update

Mitsubishi published an update for their TCP protocol stack advisory that was originally published (by NCCIC-ICS) on September 1st, 2020. The new information includes updating affected version and/or adding mitigation measures for:

• MSZ-BT20/25/35/50VGK-E1,

• MSZ-BT20/25/35/50VGK-ET1,

• MSZ-AP25/35/42/50/60/71VGK-E2,

• MSZ-AP25/35/42/50VGK-E7,

• MSZ-AP25/35/42/50VGK-EN2,

• MSZ-AP60/71VGK-ET2,

• MSZ-EF18/22/25/35/42/50VGKW(S)(B)-E1,

• MSZ-EF22/25/35/42/50VGKW(S)(B)-ER1,

• MSZ-EF25VGKB-ET1,

• MSZ-FT25/35/50VGK-E1,

• MSZ-FT25/35/50VGK-ET1,

• MSZ-FT25/35/50VGK-SC1,

• MSZ-EF22/25/35/42/50VGKW(S)(B)-A1, and

• BAC-HD150

NOTE: I expect that NCCIC-ICS will update their advisory in the coming week.

Advantech Reports

Talos published a report describing five incorrect default permission vulnerabilities (CVE-2020-13551, CVE-2020-13552, CVE-2020-13553, CVE-2020-13554, and CVE-2020-13555) in the Advantech WebAccess/SCADA installation. The report includes proof of concept code. The vulnerabilities were disclosed to Advantech in October 2020.

 

Talos published a report describing a path traversal vulnerability in the Advantech WebAccess/SCADA installation. The report includes proof of concept code. The vulnerabilities were disclosed to Advantech in October 2020.

Sytech Report

Talos published a report describing an incorrect default permissions vulnerability in the Sytech XL Reporter. The report includes proof of concept code. The vulnerabilities were disclosed to Sytech in October 2020.

DDC Exploit

Kağan Çapar published an exploit for a buffer overflow vulnerability in the DDC dataSIMS Avionics Bus Analysis & Simulation Software Tool. There is no CVE listed and no indication of notification to DDC. This may be a 0-day exploit.

Friday, February 19, 2021

Bills Introduced – 2-18-21

Yesterday with the House meeting in proforma session and the Senate recovering from the impeachment trial, there were 121 bills introduced. Three of those bills may receive additional coverage in this blog:

HR 1119 To codify an Executive order securing the United States bulk-power system.  Rep. Duncan, Jeff [R-SC-3] 

HR 1162 To make supplemental appropriations for the Departments of Agriculture, the Interior, Homeland Security, Labor, and Commerce for the fiscal year ending September 30, 2021, and for other purposes  Rep. Neguse, Joe [D-CO-2]

HR 1178 To establish the National Commission on Domestic Terrorism, and for other purposes. Rep. Speier, Jackie [D-CA-14]

I will be watching HR 1162 for spending related to cybersecurity or chemical security issues.

HR 1178 probably will not fit into any of the ‘normal’ categories of topics that I cover in this blog, but I suspect that it will have future impacts on chemical security and transportation security down the road. It also might have impacts on cybersecurity, but that is less certain.

NOTE: The Government Printing Office is getting further and further behind in publishing official copies of legislation. As I write this the latest bill printed is HR 550 which was introduced on February 5th. As congress continues to accelerate its bill writing efforts, this is going to have an impact on the ability of legislative analysts like myself to provide timely analysis of legislation before it is considered by Congress.


Thursday, February 18, 2021

2 Advisories and 3 Updates Published – 2-18-21

Today CISA’s NCCIC-ICS published two control system security advisories for products from Mitsubishi and Johnson Controls. They also updated three advisories for products from Mitsubishi, Schneider and multiple TCP/IP stack vendors.

Mitsubishi Advisory

This advisory describes two vulnerabilities in the Mitsubishi FA engineering software products. The vulnerabilities were reported by dliangfun. Mitsubishi has new versions that mitigate the vulnerabilities. There is no indication that dliangfun has been provided an opportunity to verify the efficacy.

The two reported vulnerabilities are:

• Heap-based buffer overflow - CVE-2021-20587, and

• Improper handling of length parameter inconsistency - CVE-2021-20588

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to  cause a denial-of-service condition.

Johnson Controls Advisory

This advisory describes a path traversal vulnerability in the Johnson Controls Metasys Reporting Engine (MRE) Web Services. The vulnerability was reported by TIM Security Red Team Research. Johnson Controls has a new version that mitigates the vulnerability. There is no indication that the 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 the vulnerability to allow a remote unauthenticated attacker to access and download arbitrary files from the system.

Mitsubishi Update

This update provides additional information on an advisory that was originally reported on October 8th, 2020 and most recently updated on October 29th, 2020. The new information includes adding updated affected version and mitigation information for R08/16/32/120PCPU.

Schneider Update

This update provides additional information on an advisory that was originally published on January 12th, 2020. The new information includes adding a link to the Schneider advisory.

Embedded TCP/IP Stacks Update

This update provides additional information on an advisory that was originally published on February 11th, 2021. The new information includes adding mitigation measures for FNET.

S 70 Introduced - National Guard Cybersecurity Support Act

Last month Sen Hassan (D,NH) introduced S 70, the National Guard Cybersecurity Support Act. The bill would specifically allow members of the Army and Air Force National Guard to conduct ‘cybersecurity operations’ to protect critical infrastructure.

The Authority

The bill would amend 32 USC 502(f)(1) to add the following language at the end of the paragraph:

“Such training or other duty may include cybersecurity operations or missions undertaken by the member's unit at the request of the Governor of the State concerned to protect critical infrastructure (as that term is defined in the Critical Infrastructures Protection Act of 2001 (42 U.S.C. 5195c)).” {§2}.

Sub-section 502(f) provides authorization for DOD to prescribe regulations for requiring National Guard members to perform duties in addition to monthly and annual drills required by §502(a).

Moving Forward

Neither Hassan, nor her cosponsor {Rep Cornyn (R,TX)} are members of the Senate Armed Services Committee to which this bill was assigned for consideration. This means that they are unlikely to have sufficient influence to have the Committee consider the bill.

I see nothing in this bill that would draw specific opposition if it were considered in Committee or brought to the floor of the Senate. I suspect that the bill would receive strong bipartisan support.

Commentary

The first odd thing about this bill is that it looks like it amends the wrong paragraph in §502(f). Paragraph (1) provides the general authorization and paragraph (2) provides a listing of the types of training or duty that could be included under (f).

The second odd thing about the language in this bill is that §502 applies to regulations for federal service {“operations or missions undertaken by the member’s unit at the request of the President or Secretary of Defense” §503(f)(2)(A)}, not service under State control. If the language were added (in either paragraph), it would require DOD to establish regulations allowing Governors to request to use their National Guard troops under these provisions.

The only reason that I could see for doing this would be to require DOD to fund the cybersecurity operations and assume responsibility for the logistical and administrative support for those units (and/or National Guard personnel) ordered to perform the duty requested by Governors who already have operational control of NG units withing thier State.

OMB Approves Chemical Release ICR Revision – 2-16-21

On Tuesday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had approved a “non-substantive change request” for the information collection request (ICR) from the Chemical Safety Board for “Accidental Release Reporting”. There were no public notices published for this change.

The approved changes consisted of editorial corrections to the reporting form [.docx download link] and associated instructions [.docx download link]. As of this writing, the form and instructions on the CSB site do not reflect the changes approved this week.

Commentary

The editorial changes approved this week are non-substantive for the most part. There was one substantial revision in the opening paragraph in the instructions. The ‘current’ (on the web site) version notes that: “You are required to report an accidental release within eight hours of a qualifying event.” The original version posted to the web site said: “within four hours”; the requirement set out in the notice of proposed rulemaking, but changed in the final rule. According to the documents submitted to OIRA this change from ‘four’ to ‘eight’ was part and parcel of the other revisions made to the form this week. Interesting.

It is always encouraging to see Federal agencies take the time and effort to clean up editorial problems with their publications. Unfortunately, it looks like the CSB is going to have to go back and cleanup some the changes made in this revision. For example, in the explanation for filling out block e, ‘Describe the accidental release’, the revised form includes this exquisitely clear piece of creative writing:

“Description omaterials in process and released prior to and after the incident. and quantity of ,re, temperatureInclude equipment pressu. releasef accidental”

 And in the naming of block g in the instructions we find this editorial nightmare:

“g. Name of the materials involved in accidental release using the Chemical Abstract Service (CAS) ).Add more lines if more than two chemicals(. number(s) or other appropriate identifiersregistry”

 

I am a strong supporter of the CSB and their investigative and reporting efforts, but they have had a lot of administrative problems (see here and here) with this ICR. Someone really needs to get this fiasco under control.

Wednesday, February 17, 2021

Call for Cybersecurity Regulations – 2-17-21

There is an interesting opinion piece over on TheCipherBrief.com calling for real cybersecurity regulation in critical infrastructure and for federal funding for implementing the necessary cybersecurity controls. As I noted on TWITTER® earlier today, there is a basic misunderstanding of the current regulatory authority provided to the Cybersecurity and Infrastructure Security Agency (CISA) evidenced in this piece, but the authors do raise some interesting ideas about the need for cybersecurity regulations.

CISA Authority

When CISA was stood up a bit over a year ago, it was not given authority to regulate cybersecurity outside of the federal government, with one minor, indirect exception: the Chemical Facility Anti-Terrorism Standards (CFATS) program and that was only because the existing program was rolled into CISA. CISA was only given ‘regulatory authority’ over cybersecurity programs in Federal government agencies (outside of DOD and the intelligence agencies).

It would appear that the focus of the CyberBrief piece is the regulation of cybersecurity at water treatment facilties (thus their suggested ‘universal security fee per gallon of water’). The Environmental Protection Agency was given oversight of water treatment and wastewater treatment facility security by Congress when DHS was stood up after 9/11. Even then their regulatory authority was limited to being able to require water treatment facilities to conduct a risk assessment.

Actually, I have not been able to find any where that Congress has given any agency of the Federal government specific authority to regulate cybersecurity in an operational environment. Existing cybersecurity (FERC/NERC, CFATS, and MTSA) regulations rely on general security mandates to ‘obviously include’ cybersecurity in facility security or resiliency mandates.

Funding

The authors make an important point that funding is going to have to come from the Federal government (at least in part) if there are going to be any mandates for cybersecurity in operational environments. State and local governments are quick (rightfully so) to scream about unfunded mandates when Congress sets requirements that those smaller government entities (with MUCH SMALLER pocketbooks and statutory budget constraints) will be required to implement. And remember, most water treatment facilities in this country are run by government utilities.

I have not seen the recovery bill that the authors reference in their article so I do not know where the $14 to $40 billion for “funding to update and modernize the aging, and insecure operational technology that sustains our way of life”. If that is just targeted at small water treatment works cybersecurity (and I would be very surprised to see that kind money targeted so specifically), let’s look at what that would mean per treatment facility.

The EPA says that there are “145,000 active public water systems in the United States” and 97% of them (140,650) serve 10,000 or fewer people. If the $40 billion were targeted at just those facilities, it would make over $284K to each facility. That would provide a pretty robust cybersecurity program. Even the $99.5K from dividing up the $14 billion low-end figure would be significant. I suspect, however, that those funds would be targeted at ‘water infrastructure’ not just the cybersecurity for the same. Just replacing aging and leaking water delivery pipes would eat up those funds quite quickly.

But, if we start dividing that money up to support other critical infrastructure, the amount going to each facility starts to drop off dramatically, not to mention the program costs that would probably come out of those totals.

What is needed?

That is a very open-ended question. We need to have a national discussion about what cybersecurity is needed at these water treatment facilities. Do we want the same level of nearly absolute (there is no such thing as absolute security) cybersecurity that we demand from nuclear power plants? That will be very expensive in both capital and security expertise, but it would give us very strong piece of mind that almost no one would be able to attack a water utility’s customers via their drinking water. Or do we just want to ensure that unsafe drinking water does not leave the facility and enter the drinking water distribution system? That would be much less expensive and would require significantly less cybersecurity expertise. I would expect that something approaching the later would be acceptable to most people.

For regulatory purposes, we would have to define what that type of system would look like and how we would expect to measure adequate performance. I would expect that the regulations would define where in the treatment process we would expect a facility to make the necessary realtime measurements of water quality and set forth the minimum standards for reaction to unacceptable quality parameters, and then define the minimum system safety (including cybersecurity for automated systems) standards that would apply to that portion of the treatment process Finally, we would need to put an inspection force into place to ensure that facilities lived up to the expectations outlined in the regulations.

The EPA certainly has the drinking water expertise to explicate how treatment facilities should be measuring drinking water quality and responding to out-of-standards test results. It would seem that they would therefore be designated as the agency responsible for ensuring that those systems were operating properly without outside malevolent interference. But Congress must give them the responsibility and the authority to require drinking water treatment facilities to meet those standards.

ISCD Updates 5 FAQ Responses – 2-16-21

Yesterday the CISA Infrastructure Security Compliance Division (ISCD) updated the responses to five frequently asked questions (FAQs) on the Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center web page. The same substantive change was made in each case.

The following FAQ responses were 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?

FAQ #1557 What should a facility do if it believes the risk-based tier determination that the Cybersecurity and Infrastructure Security Agency (CISA) has assigned it no longer reflects the actual security risk posed to the facility?

FAQ #1620 How does an individual report a possible security concern involving the Chemical Facility Anti-Terrorism Standards (CFATS) regulation at one’s facility or another facility?

FAQ #1666 Does a covered chemical facility have an obligation to notify the Cybersecurity and Infrastructure Security Agency (CISA) if the facility is closing?

FAQ #1756 What action is required if a facility needs to change owner and/or operator names when it is not related to a transfer of ownership?

NOTE: The links provided for the FAQs in this post were 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 same change was made in each of the five responses, a complete change in the snail mail address for CFATS notifications. The new address is:

Chemical Security, Associate Director

CISA – CHR STOP 0609

Cybersecurity and Infrastructure Security Agency

1310 N. Courthouse Rd.

Arlington, VA 20598-0609

Interestingly, these five FAQ responses were all changed in a similar way last December.

 
/* Use this with templates/template-twocol.html */