Tuesday, December 31, 2019

FAA Published UAS Remote Identification NPRM

Today the DOT’s Federal Aviation Administration (FAA) published a notice of proposed rulemaking (NPRM) in the Federal Register (84 FR 72438-72524) [Note: this link is very slow to load today, an alternate that works] that would require the remote identification of unmanned aircraft systems.


The new rule would require the classification of nearly all (amateur-built UAS and UAS weighing less than 0.55-lbs would be exempt) unmanned aerial systems (UAS) in the United states into one of three categories:

Limited remote operation UAS (LRO/UAS); and

The application of these categories depends on the ability of the UAS to broadcast its identifying information. Two means of broadcast are being defined in the rulemaking:

• Connecting to the internet (typically via the UAS control station) and transmitting through that internet connection to a Remote ID UAS Service Supplier (USS); and
• Broadcasting directly from the unmanned aircraft.

An SRO/UAS would be capable of utilizing both means of communications. An LRO/UAS would only be capable of using the internet connection mode. Needless to say, the third category would have neither communication mode available; subsequently, they would only be allowed to operate within an FAA-recognized identification area.

All three categories of UAS would be required to be individually registered with the FAA. Those currently exempted from individual UAS registration under 14 CFR 48.100(b) would be required to submit individual UAS registrations including: manufacturer, model, and, if the unmanned aircraft is a standard or limited remote identification unmanned aircraft, the aircraft's serial number.

UAS manufacturers would be required to:

• Issue each unmanned aircraft a serial number that complies with the ANSI/CTA-2063-A serial number standard.
• Label the unmanned aircraft to indicate that it is remote identification compliant and indicate whether the UAS is standard remote identification or limited remote identification.
• Submit a declaration of compliance for acceptance by the FAA, declaring that the UAS complies with the requirements of the proposed rule.

Communications Standards

The FAA has not established a specific communications standard for either of the communication modes required in the NPRM. It would, however, specifically prohibit the use of ADS-B Out and transponders for nearly all UAS operations. The FAA expects the UAS industry to develop the required standards and has provided minimum performance requirements for such systems.

UAS Service Supplier

The FAA would not provide USS services directly. The FAA envisions that the USS would be a service provider qualified by the Administrator to provide remote identification services to UAS. The USS would operate under a contractual agreement with the FAA to provide those services. They would be required to be able to demonstrate the ability:

• To share the remote identification message elements in near real-time with the FAA upon request;
• To maintain remote identification information securely and to limit access to such information;
• To meet contractually-established technical parameters; and
• To inform the FAA when their services are active and inactive.

Effective Date

Because the development of the communications standards and equipment would take some amount of time to accomplish, the NPRM envisions that the effective date of the final rule would be three years after its publication.


The FAA is soliciting comments on this NPRM. Comments may be submitted vial the Federal eRulemaking Portal (www.Regulations.gov; Docket # FAA-2019-1100). Comments should be submitted before March 2, 2020.


The need for the FAA and/or police agencies to be able to identify UAS in flight is becoming ever more apparent. This rulemaking is a rather minimalistic (if very wordy) attempt at making that possible without ruffling too many feathers. The big problem that is not directly addressed in this NPRM is that a large number of UAS of all sizes are flying in US airspace today without the capability to comply with this rulemaking. Commercial UAS makers will probably be able retrofit the requisite communications equipment with relatively minimal costs.

The problem is going to be the very large number (millions?) of small UAS in the hands of private individuals; most of them will never be upgradeable. Even if they were, it is likely that large numbers of the owners would not make the effort to upgrade them and the FAA does not have the enforcement personnel to make a dent in that non-compliance rate.

This is part of the reason that Congress initially exempted ‘model aircraft’ from FAA registration requirements in §336 of the FAA Modernization and Reform Act of 2012. The FAA found a way around that exemption when the published their interim final rule on UAS registration in 2016; instead of registering the actual UAS they required hobby UAS operators to register under §48.100(b). While the courts temporarily nullified that registration requirement, Congress more clearly mandated the exemption in adding 49 USC 44809 and repealed the earlier language. While eliminating the term ‘model aircraft’ §44809 introduced the ‘limited recreational operations’ terminology that the FAA is using in this NPRM.

Now Congress left a way out for the FAA to conduct these registration activities in §44809(f):

(f) Exceptions.—Nothing in this section prohibits the Administrator from promulgating rules generally applicable to unmanned aircraft, including those unmanned aircraft eligible for the exception set forth in this section, relating to—
(1) updates to the operational parameters for unmanned aircraft in subsection (a);
(2) the registration and marking of unmanned aircraft;
(3) the standards for remotely identifying owners and operators of unmanned aircraft systems and associated unmanned aircraft; and
(4) other standards consistent with maintaining the safety and security of the national airspace system.

An attempt was made by the FAA to address this small UAS in ‘limited recreational operations’ by including the proposed rules for the operation of UAS without remote identification equipment in an FAA-recognized identification area. This provision coincides with the congressional mythology of the operation of community-based organizations for the hobby use of model aircraft. While such organizations certainly exist, they support only a very small percentage of small recreational UAS users.

While the FAA has partially addressed this issue by exempting micro UAS (UAS weighing less than 0.55-lbs), that does not address the widespread existing use of recreational quadcopters and other small UAS (larger than 0.55-lbs) that will not be modifiable to meet the communications requirements of this rule. The FAA can say that they will not be allowed to operate in backyards, parks and city streets, but without an effective enforcement effort this rule will be effectively ignored.

There is an old leadership rule that I learned in the Army: Never give an order that you know will be disobeyed. Such an order undermines the authority of the issuer. The FAA, by not specifically addressing this issue, will undermine their authority to regulate small recreational UAS. And this class of aircraft is almost certainly the largest number of UAS in operation.

Monday, December 30, 2019

2019 Cybersecurity Legislation

As 2019 slides to a close, it would seem to be a good time to look back at what the 1st Session of the 116th Congress has accomplished on the OT cybersecurity front. The short story is not much; 60 pieces of legislation have been introduced, five have passed in the House, 1 passed in the Senate, and two have made into law. Okay now for the details.

Cybersecurity Legislation Selection

Here in this blog I try to look at every piece of legislation that is introduced that is going to, could, or will with some suggested tweaks, have an effect on what I generally call ‘control system security’. And I take a pretty broad definition of that ‘control system’; including such things as industrial control systems, building maintenance, security, transportation control, and even medical devices. In general, I do not cover purely IT related cybersecurity bills, or bills that only address government cybersecurity issues. But exceptions are made.

For each the Congress is in session (both active presence and pro forma sessions) the Congress.gov web site publishes a list of each bill introduced; generally the next day. I scan the brief description of the bills introduced and select those that sound like they may have a potential impact on control system security. I try to be very broad in my selection at this point; it is too hard to go back later and find such bills. And I publish a brief blog post identifying those bills.

Later, when the Government Printing Office finally is able to get around to publishing the official text of the bill, I download and read each of the bills that I previously identified as being potential candidates. I end up rejecting about a third of these bills as not fitting my very broad criteria of being a control system security bill. Those bills that do make the cut get a brief (okay sometimes not so brief) blog post about the provisions of the bills, my assessment of the bill’s probability to move forward, and frequently suggestions on how I think that the bill could be improved.

Now sometimes these bills are about nothing but control system security. More frequently, bills are about some larger problem, but do address control system security issues. Less frequently there really nothing in the bill about the topic, but I feel there should have been. In any case, the point I am trying to make is that my list of ‘cybersecurity bills’ is going to be different than anyone else’s. If there are any objections, contact me and I’ll take the matter under advisement.

Before this goes any further, there is one other rather odd thing about the way I treat legislation, I report on bills by their bill number (HR XXXX or S XXXX) where most other reporting agencies go by the bill name or some popular variation on that theme. This makes it easier to ensure we are all talking about the same bill since many bills have the same or similar names.

The Legislative List

The 116th Congress is one of the most prolific bill-writing congresses that I have followed. Already, in the first session (2019) they have introduced 10,168 bills and resolutions. This compares to the 13,563 that were introduced in the complete 115th Congress.

Out of those 10K bills and resolutions, I have identified 60 bills that I consider to be related to control system security. It could be 61, but one bill that I have identified as a potential candidate, HR 5527, has not yet had its language published so I don’t know yet if it actually qualifies by my loose criteria. Of those 60 bills, 38 were introduced in the House and 22 in the Senate. This is pretty close (1.73 vs 1.74) to the same ratio as that of bills introduced in the House and Senate.

Of the bills introduced on my list only the following 18 bills (30% of the total) have been considered in Committee; a general perquisite for eventual passage:

Bill #
HR 359
DOE Cybersecurity
HR 360
Cybersense Progam
HR 370
Pipeline Security
HR 1158
Cyber Response Teams
HR 1668
IOT Cybersecurity
HR 3318
TSA Threat Analysis
HR 3699
TSA Pipeline Security
HR 3710
Cybersecurity Vulnerabilities
HR 4091
ARPA-E Reauthorization
HR 4634
TRIA Reauthorization
S 174
Energy Sector Security
S 315
Cyber Response Teams
S 333
Cybersecurity Consortium
S 715
Smart Manufacturing
S 2095
DOE Cybersecurity
S 2333
Grid Security
S 2556
S 2714
ARPA-E Reauthorization

The links in the ‘Introduced’ column are to my blog posts about the initial bill. Dates in the ‘Hearing’ column reflect the date the Committee report on the bill was published; if there is a link its to my blog post on the Report. Where it simply reflects ‘Hearing’, the report has yet to be published. Usually a report is published before the full body (House or Senate) will take up the bill.

In general cybersecurity bills have done better than average in being considered in committee. Of the 8,675 bills (not counting resolutions) introduced this year, 1,103 have been considered in committee, or 1 in 7.8 bills. For my cybersecurity bills it is 1 in 3.3 bills. On this basis it would seem that cybersecurity is a relative priority in the 116th Congress.

Only one of the bills on the above list made it to being considered by the other body; HR 1158 was considered and passed (after being amended) in the Senate. The House ended up agreeing to the Senate’s language (taken from S 315), but it was included in the second spending bill passed this month, HR 1856, which was signed into law by the President.

That was not, however, the only bill on the list that made it into law. Another bill, HR 4634, was also included as part of the same spending bill. So, 3% of the cybersecurity bills on my list have made it into law. That looks better than the 1% of the total bills introduced during the session that have been signed by the President. I am careful to say ‘looks better’ because I have not tried to determine how many other bills made it into law by being combined into another bill. It is a favorite congress critter trick to get bills into law that would not make it there on their own merits.


So, looking at the number, it would seem that the 116th Congress has been a good one for cybersecurity. Unfortunately, the numbers are misleading. See, one of the two bills (HR 1158) that made it into law just authorized the ‘cyber hunt teams’ that are already employed by the Cybersecurity and Infrastructure Security Agency (CISA). The only thing really new in the law was the authorization to use civilian contractors on those teams; with the permission of the owner/operator of the facility where the team is hunting. The other bill is similarly not a big deal; the ‘cybersecurity’ provisions of HR 4634 consisted of language requiring the Department of Treasury to report to Congress on the advisability of considering cyberattacks as terrorist attacks under the Terrorism Risk Insurance (TRIA) Program. That could be helpful down the road but would still take new legislation to make it happen.

So, in my opinion, the first session of the 116th Congress has been kind of a wash for cybersecurity. Congress appears to be taking more of a look at the problem but, so far has done very little to deal with it

HR 5428 Introduced - Energy Security Research

Earlier this month Rep Lamb (D,PA) introduced HR 5428, the Grid Modernization Research and Development Act of 2019. The bill would direct Federal research on grid modernization and security. While not specifically a cybersecurity bill, there are provisions which could affect cybersecurity research efforts.


Section 9 of the bill would add a new §1313, Definitions, to the Energy Independence and Security Act of 2007 (42 USC 17381 et. seq.). These definitions would only apply to Title XIII, Smart Grid, of the act, including most of the new sections added by this bill. There would be three definitions in that section:

• Critical facility;
• Distribution automation; and
• Resilience

Two of those definitions have potential cybersecurity ramifications:

‘Distribution automation’ means “systems and technologies that exert intelligent control over electrical grid functions at the distribution level” {new §1313(2)}; and

‘Resilience’ means “the ability to withstand and reduce the magnitude or duration of disruptive events, which includes the capability to anticipate, absorb, adapt to, or rapidly recover from such an event, including from deliberate attacks, accidents, and naturally occurring threats or incidents” {§1313(3)}

Regional Demonstration Initiative

Section 2 of the bill would amend 42 USC 17384, Smart grid technology research, development, and demonstration. The revisions would increase the scope of the current smart grid regional demonstration initiative to include “distribution automation, industrial control systems, dynamic line rating systems, grid redesign, and the integration of distributed energy resources" {revised §17384(b)(1)}. It would also add as a new goal for that initiative the encouragement of “commercial application of advanced distribution automation technologies that improve system resilience” {new §17384(b)(2)(F)}.

Section 10(b)(1) would include funding for this research and development effort; sharing in $170 million in 2020 and increasing to $185 million in 2024. DOE would be responsible for deciding the actual allocation of those funds.

NOTE: The definitions in this bill would apply to §17384.

Modeling, Visualization, Architecture, and Controls

Section 3 of the bill would add a new §1304a, Smart Grid Modeling, Visualization, Architecture, and Controls, to the Energy Independence and Security Act of 2007. This section would require DOE to “establish a program of research, development, demonstration, and commercial application on electric grid modeling, sensing, visualization, architecture development, and advanced operation and controls” {new §1304a(a)}.

The new research on modeling would include the development of {new §1304a(b)}:

• Models to analyze and predict the effects of adverse physical and cyber events on the electric grid; and
• Coupled models of electrical, physical, and cyber systems

Situational awareness research would include the “development of computational tools and technologies to improve sensing, monitoring, and visualization of the electric grid for real-time situational awareness and decision support tools that enable improved operation of the power system” {new §1304a(c)(1)}. DOE would “prioritize enhancing cyber and physical situational awareness of the electric grid during adverse manmade and naturally occurring events” {new §1304a(c)(3)}.

Research on grid architecture would cover a wide variety of topics but would specifically include {new §1304a(d)}:

• Increasing use of distributed resources owned by non-utility entities;
• The use of digital and automated controls not managed by grid operators;
• Analyzing the effects of changes to grid architectures resulting from modernizing electric grid systems, including communications, controls, markets, consumer choice, emergency response, electrification, and cybersecurity concerns; and
• Developing integrated grid architectures that incorporate system resilience for cyber, physical, and communications systems.

Section 10(b)(1) would include funding for this research and development effort; sharing in $170 million in 2020 and increasing to $185 million in 2024. DOE would be responsible for deciding the actual allocation of those funds.

Enhancing Grid Resilience and Emergency Response

Section 4 of the bill would add a new §1310, Grid Resilience and Emergency Response, to the Energy Independence and Security Act of 2007. This would require DOE to “establish a research, development, and demonstration program to enhance resilience and strengthen emergency response and management pertaining to the electric grid” {new §1310(a)}. This would include a research and development grant program directed at “improving the resilience and reliability of electric grid” {new §1310(b)}; among other goals with would include {new §1310(b)(3)}:

Developing tools to improve coordination between utilities and relevant Federal agencies to enable communication, information-sharing, and situational awareness in the event of a physical or cyberattack on the electric grid.

Specifically, this would include “development of methodologies to maintain cybersecurity during restoration of electric grid infrastructure and operation” {new §1310(d)(5)}.

There are no spending authorizations in this bill to support this research and development effort.

Grid Integration Research and Development

Section 6(a) of the bill would amend 42 USC 16215(a), Electric Transmission and Distribution Programs. It would add two new paragraphs, (10) and (11):

• The development of cost-effective technologies that enable two-way information and power flow between distributed energy resources and the electric grid; and
• The development of technologies and concepts that enable interoperability between distributed energy resources and other behind-the-meter devices and the electric grid

Section 6(b) would add a new §936, Research and Development into Integrating Renewable Energy onto the Electric Grid, to Energy Policy Act of 2005. It would require DOE to “establish a research, development, and demonstration program on technologies that enable integration of renewable energy generation sources onto the electric grid across multiple program offices of the Department” {new §936(a)}.

Section 6(c) would add a new §137, Research and Development into Integrating Electric Vehicles onto the Electric Grid, to the Energy Independence and Security Act of 2007. It would require DOE to “establish a research, development, and demonstration program to advance the integration of electric vehicles, including plugin hybrid electric vehicles, onto the electric grid” {new§137(a)}. It would also require DOE to conduct a study, and report to Congress, on “the research, development, and demonstration opportunities, challenges, and standards needed for integrating electric vehicles onto the electric grid” {new §137(b)}. One of the report requirements would be to address “the cybersecurity challenges and needs associated with electrifying the transportation sector” {new §137(b)(1)(E)}.

Section 6(d) would add a new §426, Advanced Integration of Buildings onto the Electric Grid, to Energy Independence and Security Act of 2007. It would require DOE to “establish a program of research, development, and demonstration to enable components of commercial and residential buildings to serve as dynamic energy loads on and resources for the electric grid” {new §426(a)}. Among the foci of the program DOE would be required to look at “protecting against cybersecurity threats and addressing security vulnerabilities of building systems or equipment” {new §426(a)(7)}.

Section 10(b)(3) of the bill would authorize $50 million in FY 2020 (rising to $60.8 million in 2024) for the research and development efforts outlined in §6 of the bill

None of the added sections in §6 of the bill would be affected by the definitions described earlier.

Moving Forward

Lamb is a member of the House Science, Space, and Technology Committee to which this bill has been assigned for consideration and is the Chair of the Energy Subcommittee. This means that it is very likely that the bill will be considered in his Subcommittee and probably by the full Committee. I do not see anything in this bill that would engender any organized opposition to this bill, particularly since the bill specifically prohibits DOE from requiring anyone from participating in any of the studies or implementing any of the study proposals.


This is certainly not a cybersecurity bill, nor are the cybersecurity provisions that are included in any way central to the intent of this bill. What this bill does reflect, however, is an increasing awareness upon the part of the Committee Staff that cybersecurity has to be an integrated part of the energy research process if it is to be effective.

I am particularly heartened to see cybersecurity research to be an integral part of research into the integration of electric car charging systems and building control systems into the electric grid.

Saturday, December 28, 2019

LNG by Rail Comments – 12-28-19

Comments continue to be submitted on the PHMSA liquified natural gas by rail NPRM. This holiday week there were a total of 44 comments submitted. I have discussed previous submissions:

As with earlier comments, most submissions were from private citizens with concerns about the safe transportation of LNG gas. Unfortunately, no new information there. The following submissions were move involved and will require PHMSA to address at least some of their comments.


Letter Writing Campaign

I have mentioned a number of times that I have been surprised that there has not been a letter writing campaign organized in opposition to this rulemaking by one of the many environmental groups that would clearly be against any expansion of LNG transportation or production. This week we saw the first such campaign being conducted in an interesting way. The submission from RGV (Rio Grande Valley?) contains 28 identical letters in opposition to the NPRM for environmental, safety and environmental justice reasons.

We have seen a number of comments (LFFD and BFD this week) from small town fire departments that could be impacted by derailments of LNG trains. While there is nothing new in these comments, they still bear reading by anyone concerned with LNG shipments by rail.

Buffer Cars

BLET questions the lack of buffer car requirements (number of non-hazmat carrying railcars between locomotives and first LNG car) in the NPRM. They note that since a locomotive is an obvious ignition source in the event of a derailment, the ability of the train crew to disconnect and remove that potential source of ignition could be the key factor in preventing a catastrophic fire.

Railcar Safety

RSICTC notes that the design criteria for the DOT 113C120 railcars specifically addresses the physical hazards of temperature and pressure found in LNG transport.

RSICTC recommends increasing the maximum filling density to 37.7%, allowing a 13% reduction in the number of railcars needed to transport a given volume of LNG. This density would provide for similar fill characteristics to other cryogenic products authorized for transport in those railcars.

RSICTC recommends decreasing the maximum offering pressure from 15-psig to 10-psig; returning to the industry standard practice of ensuring a 30-day hold time not the 20-day hold time suggested in the NPRM>

Fire and Explosion Risk

DRN reports that “the fact that a BLEVE [boiling liquid, expanding vapor explosion] can occur with LNG has only recently been established” and complains that PHMSA has not taken that into account in its NPRM.

Legal Objections

The 25-page submission from PIT raises a number of legal issues related to this rulemaking including:

• Failure to comply with the Administrative Procedures Act;
• The NPRM’s analysis of affected entities excludes Tribes;
• Violation of EO 12898, Environmental Justice; and
• PHMSA has artificially narrowed the scope of the proposed rules impact;


We still have three weeks in the extended comment period, and we are starting to see more voices raised in at least partial opposition to this NPRM. The few fully supportive commenters to date (NGVA this week for instance) are mainly supportive of the NPRM for economic reasons and have done little to respond or counteract the negative comments. This is, of course, not unusual in any even slightly controversial rulemaking.

The PIT comments this week take an interesting look at the rulemaking. There is no way that I can comment on the legal aspects of their comments (my legal training consists of three undergraduate law courses), but they do raise some interesting complaints. The issues about environmental justice and tribal rights will probably be ignored by PHMSA. PHMSA looks at this as a hazmat shipping issue, with the only people ‘affected’ by the NPRM being shippers and rail carriers. In one sense that narrow focus is justified; that is where PHMSA’s technical expertise rests. This is why the OMB and their Office of Information and Regulatory Affairs get involved in the rulemaking process; they are the ones that are supposed to look out for many of these other issues. Unfortunately, I do not see that as being a major focus for OIRA or OMB in this Administration.

The most serious comments from PHMSA’s point of view this week will be those from RSICTC. This group is the industry’s experts and their suggestions to tighten/change controls suggested by PHMSA will be hard to ignore.

Public ICS Disclosures – Week of 12-21-19

This holiday week we had two vendor disclosures from HMS and Thales Group.

HMS Advisory

HMS published an advisory describing a cross-site scripting vulnerability in their Flexy and Cosy industrial routers. The vulnerability was reported by Ander Martínez from Titanium Industrial Security. HMS has a new firmware version that mitigates the vulnerability. There is no indication that Martinez has been provided an opportunity to verify the efficacy of the fix.

Thales Advisory

Gemalto published an advisory describing a vulnerability in their Sentinel LDK License Manager. Details about the vulnerability are restricted to registered customers only.

Happy Holidays

Friday, December 27, 2019

Nitrogen Explosion in Kansas

News reports (see here and here for instance)  out of Wichita, KS today described a ‘nitrogen explosion’ at an aircraft manufacturing facility. A security video from a nearby facility shows the rapidly expanding vapor cloud and flying debris. As many as 14 people have apparently been injured, but no fatalities were reported.


Reports indicate that a 3” liquid nitrogen line ruptured inside of the plant. No fires were reported. The resulting incident also damaged a nearby liquid nitrogen storage tank. Due to the holidays and the resulting reduced staffing, no one was near the site where the rupture occurred.


While the expanding vapor cloud and flying debris looked impressive and caused significant amounts of damage, what happened cannot really be called an explosion since there was no detonation or fire associated with the incident. What happened was that cryogenic (very cold) liquid nitrogen escaped containment when the 3” line ruptured. As the liquid entered the atmosphere it rapid warmed and boiled. The liquid expanded into a vapor cloud with 694 times the volume previously experienced in the liquid state.

This rapid expansion during the phase change caused an area of high pressure that was lightly contained by the walls of the building. As the pressure rapidly rose, the walls were no longer able to contain the pressure and were blown outwards.

Neither liquid nitrogen nor nitrogen gas are chemically reactive enough (in fact they are generally considered to be inert, or non-reactive) to cause an explosion. If a similar volume of a chemically reactive substance were to explode a large flame wall and much more damage would have resulted.

Having said that, situations such as this are very dangerous and significant damage was done to the building and people were certainly injured. What was not noted in any of the articles that I have seen was that there was also a potential risk for asphyxiation near the leak as the expanding nitrogen cloud displaced oxygen from the immediate area. There was also a potential for severe cold injuries in the immediate area of the leak. From the articles that I have seen it does not appear that anyone was near enough to the initial leak for these to have been a problem.

The white cloud seen in the incident photos and videos was not actually a nitrogen cloud. Nitrogen is colorless and odorless (and actually makes up about 78% of the atmosphere). The visible vapor cloud is water in the atmosphere that has been super cooled by the still very cold nitrogen gas to form a cloud.

Tuesday, December 24, 2019

Accidental-Mixture Chlorine Release Incident – 12-23-19

An industrial mixing accident earlier this week in Berkeley County, WV resulted in a chlorine gas release. No injuries were reported, but a large portion of downtown Martinsburg were evacuated overnight because of the incident. Local news reports of the incident can be found here, here, here, here, here, here and here.

The Incident

Apparently, a truck containing a ferric chloride (FeCl3) solution was inadvertently unloaded into a sodium hypochlorite tank. The resulting chemical reaction released chlorine gas into the atmosphere. It was this chlorine gas cloud that was the reason for the evacuations.

Ferric chloride is used in water treatment facilities as a coagulant to help remove solid particles from the water in a pre-treatment filtration step for drinking water. The sodium hypochlorite (industrial strength bleach) is used for disinfecting drinking water. The bleach used in a water treatment facility is typically 10 to 13 wt% sodium hypochlorite where household bleach is usually about 6%.

Since this is a fairly standard acid-base reaction, in addition to the chlorine gas released, a significant amount of heat was also produced. Because of the large amounts of water in both solutions, this heat was not dangerous from a facility safety perspective, but it probably resulted in a steam cloud being released along with the chlorine gas which would make the event a bit more visibly impressive.


It has been a while since I have talked about this type of incident, but that is not because it is too infrequent. Adding chemicals to the wrong tank happens way too often, particularly in smaller operations where the truck driver is the one responsible for hooking up the unloading connections. Where facilities have dedicated bulk-unloading personnel, these incidents are not as common.

Facilities that handle ferric chloride or sodium hypochlorite solutions are not required to conduct a process hazard analysis (PHA) for unloading or handling these chemicals; neither the EPA nor OSHA regulations provide oversight of reactive chemical hazards. Still any facility handling chemicals should conduct a safety review before bulk handling of any chemicals takes place.

An important part of any such safety review would be to identify chemicals used at the facility that would have dangerous chemical interactions. When such a review identifies a potential chemical reaction that produces chlorine gas, for instance, prudence dictates that steps are taken to ensure that an unintended mixture of the two chemicals does not result. Steps could include physical isolation of the tanks and unloading connections; warning signs at connections, requiring the presence of someone from facility when unloading, or separately keyed locks on each unloading valve. Increased safety would come from combining two or more of the above listed techniques.

Finally, this is one of those types of incidents that local emergency response personnel should plan for whenever there is a facility in their jurisdiction that has bulk storage of sodium hypochlorite. While chlorine gas releases typically require significant evacuation zone (the ½ mile used in this incident is typical) the amount of chlorine gas that is released in this type incident may not actually require evacuations; shelter-in-place is probably more than sufficient for all but the closest structures to the release. Making that type of decision in advance (and notifying potentially affected personnel what it means) is a decision that is easier to make in advance of an incident.

Emergency response planning for this type of incident also means determining what type of chemical detection equipment is needed to evaluate the all-clear call at the end of the incident. One news report indicated that the responders used ‘test strips’ to test for chlorine gas. I am unaware of any test strips that are effective on low concentrations of chlorine vapors; they are designed to test for chlorine concentration in water. A slightly more sophisticated gas detection/measurement system is required. Again, this is best determined before an incident occurs.

S 3045 Introduced – CISA Subpoena Authority

Earlier this month Sen Johnson (R,WI) introduced S 3045, the Cybersecurity Vulnerability Identification and Notification Act of 2019. The bill would provide the Cybersecurity and Infrastructure Security Agency (CISA) with the authority to issue subpoenas “for the production of information necessary to identify and notify the [an] entity at risk”.


Section 2(a)(1) of the bill would add a definition of ‘security vulnerability’ to 6 USC 659(a); taking that definition from 6 USC 1501(17).

Added CISA Function

Section 2(a)(2) of the bill would also add a new function to the list found in §659(c). That new function would entail “detecting, identifying, and receiving information about security vulnerabilities relating to critical infrastructure in the information systems and devices of Federal and non-Federal entities for a cybersecurity purpose” {new §659(c)(12)}.

Subpoena Authority

Section 2(a)(3) of the bill would add a new subsection (n) to §659, Subpoena Authority. This new subsection starts with a definition of ‘enterprise device or system’. That term would mean {new §659(n)(1)(a)}:

A device or system commonly used to perform industrial, commercial, scientific, or governmental functions or processes that relate to critical infrastructure, including operational and industrial control systems, distributed control systems, and programmable logic controllers.

The definition would specifically exclude {new §659(n)(1)(b)}:

Personal devices and systems, such as consumer mobile devices, home computers, residential wireless routers, or residential internet-enabled consumer devices.

Paragraph (n)(2) would authorize CISA to “issue a subpoena for the production of information necessary to identify and notify the entity at risk, in order to carry out a function authorized under subsection (c)(12).” This authority would apply when CISA “identifies a system connected to the internet with a specific security vulnerability and has reason to believe that the security vulnerability relates to critical infrastructure and affects an enterprise device or system owned or operated by a Federal or non-Federal entity.

The information sought under the subpoena would be limited to the information described in 18 USC 2703(c)(2)(A), (B), (D) and (E). That would include:

• Name;
• Address;
• Length of service (including start date) and types of service utilized;
• Telephone or instrument number or other subscriber number or identity, including any temporarily assigned network address; and

Once the subpoenaed entity provides CISA with the requested information, CISA would be required, within 7 days, to “notify the entity at risk identified by information obtained under the subpoena regarding the subpoena and the identified vulnerability” {new§659(n)(5)}.

Moving Forward

Johnson is the Chair, and his sole cosponsor {Sen Hassan(D,NH)} is a member of the Senate Homeland Security and Governmental Affairs Committee to which this bill was assigned for consideration. This bill will almost certainly be considered by the Committee early in the new year. The provision of subpoena powers by Executive Agencies is not taken lightly by Congress, but every effort has apparently been made to develop a bipartisan and bicameral consensus on this measure. I suspect that it will be approved by the Committee. It would most likely be taken up by the full Senate under the unanimous consent process.


Okay, let’s get the definitions rant out of the way. The CISA cybersecurity authority rests heavily upon an IT-restrictive definition of ‘information systems’. While the bill provides language that specifically includes “industrial control systems, distributed control systems, and programmable logic controllers”, it still uses terms such as ‘incident’ that rely on that IT-restrictive definition. To avoid that confusion Johnson (really the Committee Staff) should have used this bill as an opportunity to clarify the definition problems that I outlined earlier this year. Okay, that rant is over, let’s move on….

Much has been made in the more popular press (see here for example) about how this bill would allow CISA to issue these subpoenas to information services providers. This would certainly be helpful where CISA has been able to identify an IP address where a vulnerable system exists, but needs point of contact information from the ISP.

A more effective use of this subpoena power, however, would be to contact control system equipment vendors or integrators about owners of equipment with known cybersecurity vulnerabilities, particularly where those vulnerabilities do not yet have effective mitigation measures available. There is nothing in this bill that would prevent such subpoenas. The reference to the wire fraud statute in this bill only reference the types of information that can be requested, not from whom the information can be requested.

There is one peculiar oddity in the bill that probably needs to be addressed. In the (n)(7) paragraph discussion of procedures that CISA is required to develop to support this subpoena authority it calls for {(n)(7)(C)(i)} “immediate destruction of information obtained through the subpoena that the Director determines is unrelated to critical infrastructure” {(n)(7)(C)(i)}. This apparently conflicts with the requirement in (n)(5) to notify the “entity at risk identified by information obtained under the subpoena" regarding the subpoena and the identified vulnerability. It would seem only fair that an identified entity that was subsequently identified as not being ‘related to critical infrastructure’ should be notified of the vulnerability before the information was destroyed by CISA. That conflict could be rectified by changing the wording of (n)(7)(C)(i) to read:

(i) immediate, subsequent to notification under (n)(5), destruction of information obtained through the subpoena that the Director determines is unrelated to critical infrastructure; and

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