Sunday, March 31, 2019

S 715 Introduced – Smart Manufacturing

Earlier this month Sen. Shaheen (D,NH) introduced S 715, the Smart Manufacturing Leadership Act. The bill would require the Secretary of Energy to develop a smart manufacturing plan and to provide assistance to small- and medium-sized manufacturers in implementing smart manufacturing programs. The bill is nearly identical to S 768 that was introduced in the 115th Congress. The earlier bill saw no action beyond its introduction.


The only differences between the two bills is that the staff added two sub-paragraphs to §4(b) of the bill. That paragraph outlined the actions that Federal agencies would take in support of the smart manufacturing plan required by this bill. The two new actions included in §4(b)(2) are:

• Actions to increase cybersecurity in smart manufacturing infrastructure;
Deployment of existing research results; and

Moving Forward

While Shaheen is not a member of the Senate Energy and Natural Resources Committee to which this bill was assigned for consideration, Sen. Alexander (R,TN) is. Adding Alexander as a cosponsor may see this bill considered by the Committee this session. No regulatory requirements are being added by this bill so there are unlikely to be any philosophical objections to the bill.

The major impediment to passage of this bill is the inclusion of a $10 million authorization for the grant program included in §7. That is small change in the Federal budget, but the money will have to come from somewhere. Shaheen avoided this spending problem in the other portions of her bill by requiring the money for the planning process to come out of Department unobligated funds; this left the spending allocation problem in the hands of DOE not Congress. That would have been difficult to do with a new grant program.


It is interesting to see that one of the new sub-paragraph additions to this bill was similar in intent to a recommendation I made on S 768; readers would be unsurprised to realize that the language was dealing with cybersecurity. Unfortunately, the major cybersecurity suggestion I had for the bill was not adopted in the new version of the bill. I still think that the existing provisions are inadequate, so I would like to re-suggest the following addition be made to the definitions in §3:

§3(10): “VOLUNTARY CYBERSECURITY STANDARDS AND PROTOCOLS -The term “voluntary cybersecurity standards and protocols” means a standard and/or protocol developed by the National Institute of Standards and Technology (NIST) or recognized independent standards setting organizations that an electronic equipment manufacturer, system integrator or system owner may voluntarily apply in the manufacture, integration or operation of an industrial control system, energy management system or information and communication technology system, that would protect such systems from a cyber threat as that term is defined in 6 USC 1501.”

This definition would then be used in new wording for the added §4(b)(2)(D):

“encourage to the development, promulgation and implementation of voluntary cybersecurity standards and protocols in smart manufacturing operations; and”

As I noted in my post on S 768 this simple, generic language could add a significant measure of cybersecurity support to this bill without drawing any significant opposition from manufacturers fearing new government regulations.

Saturday, March 30, 2019

HR 1589 Reported in House – CBRN Intelligence

This week the House Homeland Security Committee published their report on HR 1589, the
CBRN Intelligence and Information Sharing Act of 2019. The Committee amended the bill in a hearing on March 13th.

This bill is currently scheduled to be considered by the full House on Monday, April 1st, 2019 under the suspension of the rules process. There will be limited debate and no floor amendments will be authorized. The bill is expected to be passed with substantial bipartisan support.

Public ICS Disclosures – Week of 03-23-19

This week we have one vendor notification from Phoenix Contact and an update of an earlier vendor notification from Rockwell Automation.

Phoenix Contact Advisory

VDE-CERT published an advisory for an improper access control vulnerability in the Phoenix Contact FL NAT SMx web UI. The vulnerability was reported by Maxim Rupp. Phoenix Contact provides generic control measures to mitigate this vulnerability. There is no indication that Rupp was provided an opportunity to verify the efficacy of the fix.

Rockwell Update

Rockwell provided an update to their advisory published earlier this week. The update provides links to:

• The Applied Risk report on the vulnerability; and
The ICS-CERT advisory

Friday, March 29, 2019

Bills Introduced – 03-28-19

Yesterday with both the House and Senate in session there were 106 bills introduced. Two of these may see future coverage in this blog:

HR 1975 To establish in the Cybersecurity and Infrastructure Security Agency of the Department of Homeland Security a Chief Information Security Officer Advisory Committee. Rep. Katko, John [R-NY-24] 

S 954 A bill to provide grants to State, local, territorial, and Tribal law enforcement agencies to purchase chemical screening devices and train personnel to use chemical screening devices in order to enhance law enforcement efficiency and protect law enforcement officers. Sen. Brown, Sherrod [D-OH]

CISO’s typically have responsibility for operational technology in addition to information technology. It will be interesting to see if the definitions used in HR 1975 reflect that dichotomy.

I suspect that this bill will contain language specifying fentanyl detection. While detection of that dangerous (toxic) drug is certainly important to law enforcement officers, I will be watching for language that includes a broader array of toxic chemical detections in the grant program.

Thursday, March 28, 2019

1 Advisory Published – 03-28-19

Today the DHS NCCIC-ICS published a control system security advisory for products from Rockwell.

The advisory describes a resources exhaustion vulnerability in the Rockwell PowerFlex 525 AC Drives. The vulnerability was reported by Nicolas Merle of Applied Risk. Rockwell has new firmware to mitigate the vulnerability. There is no indication that Merle 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 result in resource exhaustion, denial of service, and/or memory corruption.

NOTE: Is it just me, or does the timeline provided in the Applied Risk advisory seem a little bit long in the preliminary exchange of information?

HR 1592 Introduced – Cybersecurity Training

Earlier this month Rep. Langevin (D,RI) introduced HR 1592, the Cybersecurity Skills Integration Act. The bill would establish a grant program within the Department of Education to provide support to post-secondary education programs that incorporate cybersecurity training or integrate cybersecurity training into existing education programs.


Section 3(h) establishes the definitions used in this bill. The key definition in the bill is for the term ‘cybersecurity education’; it is defined as “education about ensuring the confidentiality, integrity, availability, and safety of information systems used in critical infrastructure sectors, including control systems and operational technology” {§3(h)(2)}.

Grant Program

Program grants of up to $500,000 per year may be made under this program. The bill provides for $10 million to be authorized to support the grant program {§(g)}. There is no time limit on that authorization in the language of the bill.

Moving Forward

While Langevin is not a member of the House Education and Labor Committee, the committee to which the bill was assigned for consideration, one of his cosponsors, Rep. Thompson (R,PA), is a senior member of the Committee. This means that there may be enough influence to see this bill covered in Committee.

There are no provisions in the bill that would draw any serious opposition to the bill. The main impediment to passage will be the price tag.


The general idea that cybersecurity needs to be a topic included in degree and certification programs other than computer science certainly is one worthy of discussion. Money is, of course, one of the impediments to achieving that goal, but it is only one of the problems. The other is that there are only so many classroom hours available in degree programs and adding any new classes mean that something else has to be given up to make room in the schedule.

As should be expected by most readers, I have some problems with the cybersecurity definition used in this bill. I have to acknowledge that the staffers who wrote this bill made an honest effort to ensure that industrial control system cybersecurity issues would be addressed by this grant program. As fairly usual, however, they have taken information technology language (in this case the standard ‘confidentiality, integrity and availability’ measure of security and tacked onto the end ‘including control systems and operational technology’. The fact that the CIA security standards are not directly applicable to control system security is of little matter.

It would be helpful if there were a clear delineation that different types of cybersecurity training are going to be applicable to different types of degree programs. Most students in business and liberal arts programs are going to find information technology security classes most helpful. Students in science and engineering programs, however, are going to be more concerned about protecting physical systems rather than information from cyber-attacks.

Having said that, of course, all students need some basic cyber hygiene training; passwords, two-factor authentication, phishing, etc. I am not sure, however, that these need to wait until post-secondary education. It seems to me that these types of training would be more appropriate in elementary or middle school given the widespread use of cellphones and tablets by people in that age groups.

Wednesday, March 27, 2019

Bills Introduced – 03-26-19

Yesterday with both the House and Senate in session there were 50 bills introduced. Of these, one will receive additional coverage in this blog:

S 876 A bill to amend the Energy Policy Act of 2005 to require the Secretary of Energy to establish a program to prepare veterans for careers in the energy industry, including the solar, wind, cybersecurity, and other low-carbon emissions sectors or zero-emissions sectors of the energy industry, and for other purposes. Sen. Duckworth, Tammy [D-IL]

Tuesday, March 26, 2019

3 Advisories Published – 03-26-19

Today the DHS NCCIC-ICS published three control system security advisories for products from ENTTEC, Phoenix Contact and Siemens.

ENTTEC Advisory

This advisory describes a missing authentication for critical function vulnerability in the ENTTEC Datagate MK2, Storm 24, Pixelator industrial lighting control products. The vulnerability was reported by Ankit Anubhav of NewSky Security. ENTTEC has updated firmware that mitigate the vulnerability. There is no indication that Anubhav has been provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit this vulnerability to reboot this device allowing a continual denial of service condition.

Phoenix Contact Advisory

This advisory describes a command injection vulnerability in the Phoenix Contact RAD-80211-XD radio modules. The vulnerability was reported by Maxim Rupp. The affected products are no longer supported.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to  allow an attacker to execute system level commands with administrative privileges.

Siemens Advisory

This advisory describes an expected behavior violation vulnerability in the Siemens SCALANCE X switches. The vulnerability is being self-reported. Siemens has a new version that mitigates the vulnerability.

NCCIC-ICS reports that an uncharacterized attacker could remotely exploit the vulnerability to allow an attacker to feed data over a mirror port and into the mirrored network.

NOTE: I briefly reported on this vulnerability earlier this month.

S 734 Introduced – IOT Cybersecurity

Earlier this month Sen. Warner (D,VA) introduced S 734, the Internet of Things (IoT) Cybersecurity Improvement Act of 2019. Warner introduced a similarly titled bill last session (S 1691), but this bill is a complete re-write of the earlier effort.


While last session’s bill had a long series of complicated definitions, this new bill only defines three terms: ‘agency’, ‘covered device’ and ‘security vulnerability’. The ‘agency’ definition is a proforma, yet necessary definition that is of little real importance. The definition of ‘covered device’ is new to this bill and replaces the term ‘internet-connected device’ from the earlier bill. The new term is defined as a physical object that {§2(2)(A)}:

• Is capable of connecting to and is in regular connection with the Internet;
• Has computer processing capabilities that can collect, send, or receive data; and
Is not a general-purpose computing device, including personal computing systems, smart mobile communications devices, programmable logic controls, and mainframe computing systems.

Sharp-eyed readers will note that this definition was taken from an amendment to HR 5515 last session that was proposed by Sen. Gardner (R,CO); one of the cosponsors to this bill.

Interestingly the definition of a covered device goes on to provide a requirement that the Office of Management and Budget (OMB) establish a process by which interested parties can petition to have a “a device that is not described in subparagraph (A) to be considered a device that is not a covered device” {§2(2)(B)(i)}.

The term ‘security vulnerability is defined as “any attribute of hardware, firmware, software, or combination of 2 or more of these factors that could enable the compromise of the confidentiality, integrity, or availability of an information system or its information or physical devices to which it is connected” {§(2)(3)}.

NIST Requirements

Section 3 of the bill requires the National Institute of Standards and Technology (NIST) to complete current efforts “regarding considerations for managing Internet of Things cybersecurity risks” {§3(a)(1)} to be completed by September 30th, 2019. Those considerations are to include, at a minimum {§3(a)(2)}:

• Secure Development;
• Identity management;
• Patching; and
• Configuration management.

By March 1st, 2020, NIST would be required to “develop recommendations for the Federal Government on the appropriate use and management by the Federal Government of Internet of Things devices owned or controlled by the Federal Government, including minimum information security requirements” {§3(b)(1)}.

Finally, NIST would be required within 180 days of the passage of this bill to publish a draft report on “the increasing convergence of traditional Information Technology devices, networks, and systems with Internet of Things devices, networks and systems and Operational Technology devices, networks and systems, including considerations for managing cybersecurity risks associated with such trends” {§(3)(c)}

OMB Requirements

Section 4 of the bill outlines the requirements for OMB to address IoT cybersecurity in the Federal Acquisition Regulations (FAR). Within 180 days of NIST’s publication of recommendations on the use of IoT devices, the OMB would be required to “issue guidelines for each agency that are consistent with such recommendations” {§4(a)}. Those guidelines would have to be consistent with the information security requirements of 44 USC Chapter 35, Subchapter II.

OMB and NIST would also be required to undertake reviews of the recommendations and guidelines described in this bill every five years.

Coordinated Disclosure Policy

Section 5 of the bill would establish NIST as the organization responsible for establishing policies and procedures for “for the reporting, coordinating, publishing, and receiving of information about” {§5(a)} security vulnerabilities of covered devices and their resolution. Those policies and procedures would be aligned as much as practicable with ISO 29147 and ISO 30111.

Section 6 of the bill would require OMB to issue guidelines to federal agencies on how to comply with the processes established by NIST.

Moving Forward

While Warner is not on the Senate Homeland Security and Governmental Affairs Committee, the committee to which this bill was assigned for consideration, one of his three cosponsors, Sen. Hassan (D,NH) is. This means that it is reasonable to assume that the bill may received consideration in that Committee. The main holdup is that the Chair, Sen. Johnson (R,WI), has deep-seated concerns about adding anything smacking of regulations concerning cybersecurity. While this bill does not specifically call for cybersecurity regulations, the ‘policies, procedures and guidelines’ that vendors selling covered devices to the government would be required to follow have the same general impact as regulations.

I would not be surprised if this bill did not make it out of Committee. One way that Johnson could ensure this is that after a markup hearing was held, the Committee report on the bill could be delayed indefinitely.


This new version of the IoT cybersecurity bill is much better written than the version introduced in the last session. The limitations on the definition of ‘covered device’ generally make a reasonable distinction between ‘internet connected devices’ and IoT. I do, however, still have some nits to pick on the details of how that limitation/distinction is made.

The sub-paragraph in question removes ‘general-purpose computing devices’ from consideration as ‘covered devices’. It then lists the following examples of those g-p devices:

• Personal computing systems;
• Smart mobile communications devices;
• Programmable logic controls; and
Mainframe computing systems

Since none of these exclusionary terms are defined in the bill, I would suspect that the staffers who crafted this bill wanted to provide NIST and OMB with significant latitude in what would be included in the exclusion from the definition of IoT. Generally speaking, that is a good thing. Having said that, I do have problems with the term ‘programmable logic controls’. First off, I need to get a tad bit anal retentive here; the term should be ‘programmable logic controllers’.

In a broader context, even that corrected term may be an unnecessarily restrictive substitute for the term ‘industrial control system’. While PLCs are certainly very common components of industrial control system, there are a large number of other components of those systems that are not generally considered IoT (or IIoT, industrial internet of things), but could not be reasonably included in the term PLC.

While I am a strong believer in cybersecurity in industrial control system, I do not think that this bill and its loose regulatory framework are the appropriate place to establish standards for ICS cybersecurity and particularly the internet connected devices associated with industrial control systems. With that in mind, I would propose that the term ‘industrial control system’ should be substituted for the term ‘programmable logic controls’ in the definition of ‘covered device’.

Monday, March 25, 2019

Committee Hearings – Week of 03-24-19

With both the House and Senate back in Washington this week after their St. Patrick’s Day recess the budget is the major hearing topic. There will also be three hearings that are related to cybersecurity.


The list below shows hearings that relate to topics covered in this blog. Where ‘Subcommittee’ is noted this refers to a subcommittee of the relevant appropriations committee. There is an interesting article on describing the current budget process.

• House Armed Services Committee – 2020 NDAA Budget Request
• House Energy and Water Development, and Related Agencies Subcommittee - DOE
• House Homeland Security Subcommittee – Coast Guard
• House Budget Committee - DOD
• House Defense Subcommittee – NSA and Cyber Command
• Senate Transportation, Housing and Urban Development, and Related Agencies Subcommittee – DOT
Senate Energy and Water Development Subcommittee - DOE

Cybersecurity Hearings

On Tuesday the Subcommittee on Cybersecurity of the Senate Armed Services Committee will hold a hearing on “Cybersecurity Responsibilities of the Defense Industrial Base”. The witness list includes:

• William A. LaPlante, MITRE National Security Sector;
• John Luddy, Aerospace Industries Association;
• Christopher Peters, The Lucrum Group; and
• Michael P. MacKay, Progeny Systems Corporation

The supply chain security topic will almost certainly be raised. Industrial control system security issues is a more remotely possible topic that could arise.

On Wednesday the Senate Small Business and Entrepreneurship Committee will hold a markup hearing that will include two cyber related bills:

• S 771 - Small Business Cyber Training Act; and
• S 772 - SBA Cyber Awareness Act.

Neither of these bills has been published yet, so I am not entirely sure that either really deal with cybersecurity issues, much less ICS cybersecurity.

On Wednesday the Aviation and Space Subcommittee of the Senate Commerce, Science, and Transportation Committee will hold a hearing looking at “The State of Airline Safety: Federal Oversight of Commercial Aviation”. The witness list includes:

• Robert Sumwalt, National Transportation Safety Board;
• Calvin Scovel, Department of Transportation; and
• Daniel Elwell, Federal Aviation Administration 

Since this hearing is focusing on the Boeing 737 Max fiasco, control system issues are likely to be discussed. It is unlikely that cybersecurity issues related to those systems will be included in the discussion, but we can always hope.

Saturday, March 23, 2019

FMCSA Sends Automated Vehicle ANPRM to OMB

On Thursday the DOT’s Federal Motor Carrier Safety Administration (FMCSA) sent an advance notice of proposed rulemaking (ANPRM) to the OMB’s Office of Information and Regulatory Affairs (OIRA) for review. The ANPRM would address the “Safe Integration of Automated Driving Systems-Equipped Commercial Motor Vehicles”.

According to the abstract in the Fall 2018 Unified Agenda:

“FMCSA requests public comment about Federal Motor Carrier Safety Regulations (FMCSRs) that may need to be updated, modified, or eliminated to facilitate the safe introduction of automated driving systems (ADS) equipped commercial motor vehicles (CMVs) onto our Nation's roadways. FMCSA requests comment on specific regulatory requirements that are likely to be affected by an increased integration of ADS-equipped CMVs. However, the Agency is not seeking comments on its financial responsibility requirements because they are not directly related to CMV technologies and because future insurance requirements will depend in part on the evolution of State tort law with respect to liability for the operation of ADS-equipped vehicles.”

Public ICS Disclosures – Week of 03-16-19

CERT-VDE published an advisory describing nine vulnerabilities in the ENDRESS-HAUSER Field Xpert hand-held devices. These are the KRACK WPA2 vulnerabilities. The vulnerabilities are being self-reported. ENDRESS-HAUSER points to 3rd party mitigations for the affected devices.

NOTE: It is disappointing to note that we can still see original reporting of KRACK vulnerabilities when these were first reported in the ICS environment back in October of 2017. It is particularly aggravating in this case since the vulnerability was already reported in the affected devices by the manufacturer.

Friday, March 22, 2019

S 333 Reported in Senate – Cybersecurity Consortia

The Senate Homeland Security and Governmental Affairs Committee published their report on S 333, National Cybersecurity Preparedness Consortium Act of 2019. The bill was adopted in Committee without amendment. The bill is now cleared for consideration by the full Senate. That consideration will take place under the Senate unanimous consent process if it does occur. HR 1062, the companion bill in the House, has not yet been considered in Committee.

The only thing of interest in the report is the clarification that the actions that would be authorized by the bill are already being undertaken by the Department of Homeland Security. This may be why Johnson’s Committee was so quick to take up a bill that was not sponsored by Committee members

Thursday, March 21, 2019

1 Advisory Published – 03-21-19

Today the DHS NCCIC-ICS published a medical device security advisory for products from Medtronic.

The advisory describes two vulnerabilities in Medtronic MyCareLink Monitor, CareLink Monitor, CareLink 2090 Programmer, and specific Medtronic implanted cardiac devices. The vulnerabilities were reported by Peter Morgan of Clever Security; Dave Singelée and Bart Preneel of KU Leuven; Eduard Marin formerly of KU Leuven, currently with University of Birmingham; Flavio D. Garcia; Tom Chothia of the University of Birmingham; and Rik Willems of University Hospital Gasthuisberg Leuven. Medtronic has provided generic mitigation measures pending development of appropriate updates.

The two reported vulnerabilities are:

• Improper access control - CVE-2019-6538; and
Clear-text transmission of sensitive information - CVE-2019-6540

NCCIC-ICS reports that a relatively low-skille attacker with adjacent access could exploit these vulnerabilities to  allow an attacker with adjacent short-range access to one of the affected products to interfere with, generate, modify, or intercept the radio frequency (RF) communication of the Medtronic proprietary Conexus telemetry system, potentially impacting product functionality and/or allowing access to transmitted sensitive data.

NOTE: The Food and Drug Administration has published a separate advisory for these vulnerabilities.

HR 1493 Introduced – Cyber Sanctions

Earlier this month Rep. Yoho (R,FL) introduced HR 1493, the Cyber Deterrence and Response Act of 2019. The bill is very similar to S 602 introduced last month in the Senate and less similar to HR 5567 introduced last session by Yoho; which was passed by the House, but not taken up by the Senate.


This bill contains the same additions to HR 5567 that I mentioned were seen in S 602. The Senate bill did contain a reference {§3(d)(2)(D)} to Export Control Reform Act of 2018 {50 USC 4813(a)(1))} that could not have been included in HR 5567 since the Act had not been passed when the bill was introduced. That reference is not included in this bill. This means that any successor munitions control list created in accordance with §4813 provisions would not automatically be included in the sanctions applicable under this bill.

Paragraph (f) from S 602 that provided for the applicability of penalties under the Emergency Economic Powers Act {50 USC 1705(b) and (c)} to violations of §3(b)(2)(H) of this bill was not included in S 602. This may be because Yoho’s staff considered those provisions to be included by reference in §3(b)(2)(H). Or, it may just have been an oversight.

Moving Forward

As with last year with HR 5567, Yoho and his cosponsors are influential, bipartisan members of the committees to which this bill was assigned for consideration. Last session this influence was enough to ensure consideration in a Republican controlled House, both in the Foreign Affairs Committee and on the floor of the House. In both places it received strong bipartisan support.

Similar bipartisan support would be expected this year, but it remains to be seen if the priorities of the Democratic leadership will allow for the same consideration of this bill.


I still have the same problems with this bill that I had with S 602; the lack of definition of the term ‘cyber activities’ that could trigger the designation of ‘a critical cyber threat’. While I understand that a certain amount of latitude should be allowed for in that definition as cyber technologies and attack methodologies evolve, but I do think that a definition is required to constrain actions of the President.

Having said that, it is probably incumbent upon me to provide a suggested definition. I would suggest the following changes to the definition of ‘state sponsored cyber activities’:

“The term ‘‘state-sponsored cyber activities’’ means any malicious cyber-enabled activities incident (as defined in 6 USC 659(a) [proposed here]) that directly affected government information systems, a critical infrastructure information system or a control system that affected public safety and was caused by  
“(A) are carried out by a government of a foreign state or an agency or instrumentality of a foreign state; or
“(B) are carried out by a foreign person that is aided, abetted, or directed by a government of a foreign state or an agency or instrumentality of a foreign state.

Wednesday, March 20, 2019

HR 1420 Introduced – Energy Efficient Cyber Tech

Last month Rep. Eshoo (D,CA) introduced HR 1420, the Energy Efficient Government Technology Act. The bill would require the OMB to establish a strategy for the maintenance, purchase, and use by Federal agencies of energy-efficient and energy-saving information technologies at or for federally owned and operated facilities.

This is not one of the bills one would normally expect for me to cover in this blog; it does not address any cybersecurity issues. It does, however, point to a problem of congressional understanding of cyber issues that does have an impact on the legislative process in general and cybersecurity legislation in particular.


The bill would amend the Energy Independence and Security Act of 2007 by adding a new §530, Energy-Efficient and Energy-Saving Information Technologies. A key definition in the bill is for the term ‘information technology’ which is defined as having “the meaning given that term in section 11101 of title 40, United States Code [link added]” {new §530(a)(2)}. This is one of the most IT-limited definitions used in the USC and it is further limited to equipment owned by an agency of the Executive Branch of the Federal Government.

The bill then goes on to require the OMB to develop its strategy for the use of “energy-efficient and energy-saving information technologies” {new §530(b)}. Paragraph (c) then goes on to identify six elements that should be included in that strategy:

• Advanced metering infrastructure;
• Energy-efficient data center strategies and methods of increasing asset and infrastructure utilization;
• Advanced power management tools;
• Building information modeling, including building energy management;
• Secure telework and travel substitution tools; and
Mechanisms to ensure that the agency realizes the energy cost savings brought about through increased efficiency and utilization.

Three of the six elements (1, 3, and 4) deal with operational technology (otherwise known under the rubric of ‘industrial control systems’) not information technologies. Now in the scope of this bill, the confusion between OT and IT is probably of little consequence. There is nothing in the guidance provided in the bill that would be dealt with differently if applied to either OT or IT.

Unfortunately, we see the same failure to differentiate between OT and IT in many pieces of cybersecurity legislation. There the differences between the two types of technology do make a difference in how cybersecurity strategies are applied. In IT cybersecurity the emphasis is on protecting information. In OT cybersecurity the focus is on protecting the physical processes involved with protection of the information (normally intellectual property) being a secondary or even tertiary consideration.

Until Congress (and more importantly it’s staffs) are able to distinguish between the two types of cyber technology, their ability to effectively legislate cybersecurity matters or either technology will be severely lacking. But even in this bill, the failure to understand that the massive information technology complex of the federal government is dependent on a largely misunderstood operational technology component means that the crafters of this legislation almost certainly left some important considerations out of this bill. Energy efficiency is at heart a matter of energy management which rests on OT not IT.

PHMSA Sends Pipeline Safety Final Rule to OMB

Yesterday the DOT’s Pipeline and Hazardous Material Safety Administration (PHMSA) sent a final rule to the OMB’s Office of Information and Regulatory Affairs (OIRA) for review. The rule addresses the safety of hazardous liquid pipelines and has been in the works since 2010. The notice of proposed rulemaking was published in 2015.

According to the Fall 2018 Unified Agenda, this final rule seeks to:

• Extend reporting requirements to gravity lines that do not meet certain exceptions;
• Extend certain reporting requirements to all hazardous liquid gathering lines;
• Require inspections of pipelines in areas affected by extreme weather, natural disasters, and other similar events;
• Require periodic assessments of onshore transmission pipelines that are not already covered under the integrity management (IM) program requirements;
• Expand the use of leak detection systems on onshore hazardous liquid transmission pipelines to mitigate the effects of failures that occur outside of high consequence areas;
• Modify the IM repair criteria, both by expanding the list of conditions that require immediate remediation and consolidating the time frames for re-mediating all other conditions;
• Increase the use of inline inspection tools by requiring that any pipeline that could affect a high consequence area be capable of accommodating these devices within 20 years, unless its basic construction will not permit that accommodation; and
Clarify other regulations to improve compliance and enforcement.

Tuesday, March 19, 2019

2 Advisories Published – 03-19-19

Today the DHS NCCIC-ICS published two control system security advisories for products from Columbia Weather Systems and AVEVA.

Columbia Advisory

This advisory describes six vulnerabilities in the Columbia Weather MicroServer weather monitoring system. The vulnerabilities were reported by John Elder and Tom Westenberg of Applied Risk. Columbia has a firmware update that mitigates the vulnerability. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The six reported vulnerabilities are:

• Cross-site scripting (2) - CVE-2018-18875 and CVE-2018-18880;
• Path traversal - CVE-2018-18876;
• Improper authentication - CVE-2018-18877;
• Improper input validation - CVE-2018-18878; and
Code injection - CVE-2018-18879

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to allow disclosure of data, cause a denial-of-service condition, and allow remote code execution.

AVEVA Advisory

This advisory describes an uncontrolled search path element vulnerability in the AVEVA InduSoft Web Studio, InTouch Edge HMI products. The vulnerability is in a third-party component; Gemalto Sentinel UltraPro encryption keys (separately reported last week). The vulnerability was reported by ADLab of Venustech. AVEVA has updates available to mitigate 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 with uncharacterized access could exploit this vulnerability to allow execution of unauthorized code or commands.

NOTE: I wonder how many other vendors are using the Gemalto product?

NHTSA Publishes Two Automated Driving System Petitions

Today the DOT’s National Highway Transportations Safety Administration (NHTSA) published two notices in the Federal Register (84 FR 10172-10182 and 84 FR 10182-10191) requesting public comments on petitions for exemptions from Federal Motor Vehicle Safety Standards (FMVSS) for two fully-automated-driving vehicles. The first is for an autonomous delivery vehicle from Nuro, Inc. The second is for a driverless passenger vehicle from General Motors.

Nuro Petition

The Nuro petition is for a low-speed delivery vehicle without human occupants. It requests exemption from the following FMVSS standards:

• FMVSS #500 – exemption from rear view mirror requirements;
• FMVSS #250 – exemption from windshield requirements;
FMVSS #111 – exemption from back-up camera requirements.

The petition is limited in scope because the intended Nuro vehicle is already exempt from most FMVSS standards for a normal passenger vehicle because it is a low-speed vehicle as defined under 49 CFR 571.3.

GM Petition

The GM petition is for a passenger vehicle in limited service. It would have no provisions for an occupant to take control of the vehicle during operation. It requests exemption from the following FMVSS standards:

FMVSS #101 – exemption from motor vehicle controls, telltales and indicators requirements;
FMVSS #102 – exemption from transmission shift position sequence, starter interlock, and transmission braking effect requirements;
FMVSS #108 – exemption from headlamp switch requirements;
FMVSS #111 – exemption from rearview mirror requirements;
FMVSS #114 – exemption from parking brake, service brake or transmission gear selection test requirements;
FMVSS #124 – exemption from return of the throttle to the idle position requirements;
FMVSS #126 – exemption from driver loss of directional control requirements;
FMVSS #135 – exemption from human breaking control requirements;
FMVSS #138 – exemption from tire pressure warning requirements;
FMVSS #141 – exemption from gear shift selector test requirements;
FMVSS #203, #204, and #207 – exemption from steering wheel impact test requirements;
FMVSS #208 and #214 – exemption from drivers position crash-test requirements; and
FMVSS #226 – exemption from airbag indicator requirements;

Public Comments

NHTSA is soliciting public comments on the petitions. Comments are required to be submitted by May 20th, 2019. Comments may be submitted via the Federal eRulemaking Portal (; Docket # NHTSA-2019-0017, Nuro petition; and NHTSA-2019-0016, GM petition).


An interesting component of both of these petitions is that they are for electric vehicles. That does not seem to matter much except that both petitions include reference to regulatory exemptions for ‘low emission vehicles’. Congress gave DOT authority (49 USC 30113) to ease the introduction of ‘low-emission vehicles’ by providing temporary exemptions to vehicle safety standards. Both petitions are using the argument from §30113(b)(3)(B)(iii) that “the exemption would make easier the development or field evaluation of a new motor vehicle safety feature providing a safety level at least equal to the safety level of the standard”; the new ‘motor vehicle safety feature’ being the autonomous operation system.

While avoiding the well known and documented safety problems associated with human drivers, autonomous vehicle operating systems are going to present their own problems. Both petitioners are making the point that to be able to identify (the necessary precursor to fixing) problems of their systems in real-world operations is the only way to move these systems into full-scale production. In many ways, this seems to be a valid argument, except….

The big problem missing from the discussion in either petition is the cybersecurity of their operating systems. A major reason for this is that NHTSA (and at base, Congress) have failed to explicate how they expect developers to protect these systems. With no federal regulatory requirements in existence, neither applicant is under any obligation to provide information on how (or even if) they are addressing the cybersecurity issue. This does not provide me with a warm fuzzy feeling.

The current crop of autonomous vehicles undergoing real-world testing still have the capability of human intervention to overcome software issues of malware or bad code. Granted that oversight has not been perfect by any stretch of the imagination, but it is there. These two proposals specifically and graphically have removed that intervention; a necessary next-step in the development of truly autonomous vehicles. The question, however, is are we ready to take that next step when we do not yet have a definition of the cybersecurity requirements for these systems, or a way to evaluate the efficacy of the cybersecurity systems put into play (whatever they are). Before we take the next step, we need to have a handle on, or at least a definition of the cybersecurity of these systems.

Monday, March 18, 2019

S 602 Introduced – Cyber Sanctions

Last month Sen. Gardner (R,CO) introduced S 602, the Cyber Deterrence and Response Act of 2019. The bill would require the President to identify foreign persons or agencies of a foreign state that are ‘critical cyber threats’ and impose sanctions on such persons or agencies. The bill is very similar to S 3378 that was introduced by Gardner during the 115th Congress; no action was taken on that bill.


This new version of the bill makes a large number of relatively minor wording and phrasing changes that would be of interest only to an English teacher. There are, however, two sanction additions found in S 602:

• Allows for the withdrawal, limitation, or suspension of non-humanitarian development assistance from the United States to the foreign state under chapter 1 of part I of the Foreign Assistance Act of 1961 {§3(b)(2)(B)}; and
Allows the President to direct Overseas Private Investment Corporation, the United States International Development Finance Corporation, or any other Federal agency not to provide assistance to a designated critical cyber threat {§3(b)(2)(D)};

Additionally, there are two procedural measures added in the latest version of the proposed bill:

• Instead of publishing a notice in the Federal Register listing the designation of a critical cyber threat, S 602 requires a report to Congress {§3(a)(2)}; and
• Spells out actions that President should take to coordinate sanctions with allies and partners of the United States {§3(g)(2)}.

Moving Forward

Both Gardner and his cosponsor {Sen. Coons (D,DE)} are influential members of the Senate Foreign Affairs Committee, the Committee to which this bill was assigned for consideration. One would normally expect that this would mean that the bill could be expected to be considered in Committee. Last session, S 3378 did not see the light of day after introduction. This may mean that the bill will face a similar fate in this session.


The most critical definition in this bill is for the term ‘state-sponsored cyber-activities’ since this is the key to determining whether a person or agency should be designated ‘a critical cyber threat’. Unfortunately, that term ‘state-sponsored cyber-activities’ is essentially defined as a cyber-activity that is state-sponsored. No attempt was made to establish a definition of ‘cyber-activity’.

NHTSA Barriers to Automated Driving Systems ANPRM to OMB

On Thursday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had received from DOT’s National Highway Traffic Safety Administration (NHTSA) an advanced notice of proposed rulemaking (ANPRM) on “Removing Regulatory Barriers for Automated Driving Systems” for review.

The Fall 2018 Unified Agenda listing for this rulemaking explains:

“This notice seeks comment on existing motor vehicle regulatory barriers to the introduction and certification of automated driving systems. NHTSA is developing the appropriate analysis of requirements that are necessary to maintain existing levels of safety while enabling innovative vehicle designs and removing or modifying those requirements that would no longer be appropriate if a human driver will not be operating the vehicle. NHTSA previously published a Federal Register notice requesting public comment on January 18, 2018.”

Saturday, March 16, 2019

Public ICS Disclosures – Week of 03-09-19

This week we have five vendor notifications for products from Siemens, PEPPERL+FUCHS, and Schneider(3) and four vendor updates of previously published advisories for products from Siemens(3) and Medtronics.

Siemens Advisory

Siemens published an advisory describing a mirror port isolation vulnerability in their SCALANCE X switches. The vulnerability is being self-reported. Siemens has provided generic workarounds to mitigate the vulnerability.


VDE CERT published an advisory describing two vulnerabilities in the PEPPERL+FUCHS ecom mobile devices. The vulnerabilities were reported by Ben Seri and Gregory Vishnepolsky of Armis; the armis 2017 Blueborne disclosure includes exploits. PEPPERL+FUCHS points to (no links provided) OEM vendors for updates for some of the affected products.

Schneider Advisories

Schneider published an advisory describing an uncontrolled search path element vulnerability in their Pelco VideoXpert OpsCenter. The vulnerability was reported by Osama Radwan. Schneider has a new version that mitigates the vulnerability. There is no indication that Radwan has been provided an opportunity to verify the efficacy of the fix.

Schneider published an advisory describing an SQL injection vulnerability in their U.motion Builder software product. The vulnerability was reported by Julien Ahrens (RCE Security). Schneider recommends that customers stop using the their U.motion Builder software product as it is no longer supported.

Schneider published an advisory describing an improper check for unusual or exceptional conditions vulnerability in their Triconex TriStation Emulator. The vulnerability was reported by Tom Westenberg – Applied Risk. Schneider plans to have an update available in July and has provided generic workarounds to mitigate the vulnerability in the mean time.

Siemens Updates

Siemens published an update for their advisory on Spectre and Meltdown Vulnerabilities in Industrial Products. They added an updated solution for their SINUMERIK PCU. NCCIC-ICS is not expected to publish and update for their Meltdown/Spectre alert (ICS-ALERT-18-011-01) since the link in that Alert to the Siemens Industrial Products already takes one to this latest update.

Siemens published an update for their advisory on Foreshadow / L1 Terminal Fault Vulnerabilities in Industrial Products. They added an updated solution for their SINUMERIK PCU. NCCIC-ICS has not published any advisories or alerts about the Foreshadow vulnerabilities.

Siemens published an update for their advisory on Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP. They added 14 new CVE’s to the already lengthy list of CVE’s covered in the advisory. NCCIC-ICS has not published an advisories or alerts on this family of Linux vulnerabilities.

Medtronic Update

Medtronic published an update for their advisory on MiniMed™ Paradigm™ Insulin Pumps. They added:

• Two new affected devices available in the US; and
A link to the field safety notification letter issued in August, 2018.

The NCCIC-ICS advisory (ICSMA-18-219-02) was originally published on August 8th, 2018. I suspect that this will be updated in the coming week.

NOTE: It is interesting that the letter (dated August 7th, 2018; the date of the original advisory) includes the two affected devices that are being added to the advisory via this update. The original Medtronic advisory made special note that none of the affected devices were available for sale in the United States.

Friday, March 15, 2019

S 592 Introduced – Cybersecurity Reporting

Last month Sen. Reed (D,RI) introduced S 592, the Cybersecurity Disclosure Act of 2019. The bill would require the Securities and Exchange Commission to establish rules requiring the reporting of whether there was cybersecurity expertise on the board of directors or other governing body of each company required to file annual reports. The bill is very similar to HR 6638 that was introduced last summer in the 115th Congress. No action was taken on that earlier bill. It looks like Rep. Himes reintroduced that bill in the House earlier this week but it will be a week or two until the bill is printed.

Differences Between Bills

The main difference between S 592 and the earlier House bill is that this bill amends the Securities Exchange Act of 1934 by adding a new §14C which would become 15 USC 78n-3 if the bill becomes law. The earlier bill made essentially the same requirements as a stand alone measure.

The new bill also takes a little bit of puffery out of the final paragraph of the bill. The change is shown below:

“(c) CYBERSECURITY EXPERTISE OR EXPERIENCE.— For purposes of subsection (b), the Commission, in consultation with NIST, shall define what constitutes expertise or experience in cybersecurity, such as professional qualifications to administer information security program functions or experience detecting, preventing, mitigating, or addressing cybersecurity threats, using commonly defined roles, specialities, knowledge, skills, and abilities, such as those provided in NIST Special Publication 800–181 entitled ‘‘NICE Cybersecurity Workforce Framework’’, or any successor thereto.”

Interestingly, this language deletion removes the final faint traces for the need for the definition of the term ‘information system’ that remains in the bill. The control system friendly definition of ‘information system’ was used to support the use of that term in the definition of ‘cybersecurity threat’ that was only used in the phrase deleted above. Both definitions remain in the new bill.

Moving Forward

Reed is a member of the Senate Banking, Housing and Urban Affairs Committee to which this bill was assigned for consideration. Additionally, his cosponsors include Sen. Warner (D,VA), the Ranking Member of the Security, Insurance, and Investment Subcommittee and two Republican members of the Committee. This means that it is very likely that the bill will be considered in Committee.

There is nothing in the bill that would seem to draw any obvious opposition, so it should pass in Committee. Whether or not it will make it to the floor for consideration is very difficult to determine. This bill would normally be considered under the unanimous consent process and a single voice in opposition would prevent it from being considered under that process. And the voice could be raised in ire over something the SEC had done and have nothing to do with this bill.


This is all and good to call for cybersecurity experience on corporate boards, but there are not that many people that would fit the probable description to go around to all of the corporate boards in the country.

The bigger question would be is it really necessary? While it would be hard to find a corporation that did not have at least some level of cybersecurity exposure, do all of them have enough that require board level oversight? With the relative scarcity of board-level qualified cybersecurity experts available, there should probably be mandatory cybersecurity representation on some specific subset of corporations, either size limits or in specific sectors (banking, insurance, energy sector, etc). Of course, that bill would be much harder to write.

More on CFATS Hearing and Emergency Response

It is becoming increasingly obvious that the Democrats on both the House and Senate Homeland Security Committees are concerned about the role of emergency response in the Chemical Facility Anti-Terrorism Standards (CFATS) program. This means that it is becoming increasingly likely that some sort of emergency response provision will find its way into whatever final bill comes out of the 116th Congress reauthorizing the CFATS program. Thus, the topic bears more discussion.


The CFATS regulations are not the base law in the United States for emergency response information sharing and planning for most chemical facilities. The base law for that requirement is found in the Emergency Planning and Community Right-to-Know Act (EPCRA) codified at 42 USC Chapter 116 with the regulations established at 40 CFR 355. Among other things that Chapter establishes the Local Emergency Planning Committees, provides for the preparation of comprehensive emergency response plans, and details what facilities are covered under the provisions of EPCRA.

Under the EPCRA regulations a facility is subject to the emergency planning requirements of the regulation if they have any chemicals on either of the extremely hazardous substance lists {Appendixes A (alphabetical order) & B (CAS # order) to §355} in excess of the threshold planning quantity listed in those appendixes. For chemicals on those lists that were included in the DHS list of chemicals of interest (COI), a large portion of the toxic-release hazard chemicals on the COI list, were taken with the same TPQ (called screening threshold quantity in the CFATS program).

Most of the chemicals on the EPCRA lists were not included in the CFATS COI list. Only the most toxic chemicals from the list were included as DHS concluded that only the most toxic would form the basis for a credible terrorist attack on a facility holding those chemicals.

Interestingly, two other categories of chemicals that are included in the DHS COI as release hazard chemicals are not addressed in the EPCRA emergency planning regulations or statutes; flammable and explosive chemicals. Congress intended for the EPCRA requirements only to apply to toxic-release hazard chemicals.

Actually, the EPCRA regulations do not require companies or facilities holding extremely hazardous chemicals to do any sort of emergency planning. Those facilities are simply required to report the following types of applicable information to their Local Emergency Planning Committee (LEPC) {§355.21 table}:

• Provide notice that the facility is subject to the emergency planning requirements of EPCRA;
• Designate (and provide notice to the LEPC of) a facility representative who will participate in the local emergency planning process as a facility emergency response coordinator;
• Provide notice of any changes occurring at the facility that may be relevant to emergency planning; and
Provide any information necessary for developing or implementing the local emergency plan if requested by the LEPC.

All of the responsibility for planning, training, coordinating and exercising the emergency plan fall to the LEPC {42 USC 11003(c)}. Unfortunately, Congress has provided no funding to, or even provided provisions for funding, the LEPCs. With the Federal government providing no funding for these organizations, there is no effective way for the EPA to regulate the operation of LEPCs or their emergency planning function. Congress has essentially left that responsibility to the States.


The CFATS regulations (6 CFR part 27) were originally authorized as part of a DHS spending bill over 10 years ago, but have been more recently been authorized by 6 USC Part XVI. Nothing in the current authorizing statute specifically mentions ‘emergency response planning’ at CFATS covered facilities. That is addressed, very briefly, in the CFATS regulations at §27.230(a)(9) as part of the risk-based performance standards used to develop and evaluate site security plans. That sub-paragraph states:

“Response. Develop and exercise an emergency plan to respond to security incidents internally and with assistance of local law enforcement and first responders”

The CFATS Risk-Based Performance Standards Guidance manual emphasizes that RBPS #9, Response, is targeted at the response to a security situation and that ‘emergency response’ is only a relatively small part of the response obligation of the facility under the CFATS program. The manual explains the difference this way (pg 84):

“It is important not to confuse a “security response” intended to engage and hopefully neutralize the adversaries with the broader “emergency response” that follows an attack and attempts to reduce the severity of the event and lessen the consequences in terms of loss of life and destruction of property or production capability. The initial “security response” has tactical considerations addressed in RBPS 4 – Deter, Detect, and Delay, whereas the “emergency response” relates to the more traditional efforts to contain the damage and lessen the consequences after a security event. These planning considerations overlap to some degree, and both involve establishing strong, functional, relationships with the various response organizations and personnel that may be needed to support this performance standard. It should be noted that individuals involved in security response activities also often have an integral role in emergency response, and this dual role should be taken into consideration when developing comprehensive crisis management plans.”

In the metrics included at the end of the RBPS 9 that facilities and DHS use to evaluate a CFATS site security plan (SSP), there are only mentions of ‘emergency response’ (Metric 9.1; pg 85):

“Documented agreements and/or written procedures for emergency response, including off-site responder services, such as ambulance support, explosive device disposal support, firefighting support, hazardous material spill/recovery support, and medical support.”

There are other requirements within the RBPS 9 metrics for outreach to ‘local law enforcement and emergency responders’ (including LEPCs), but these are not planning requirements; though the metric does note that facilities can fulfill this measure by participation “in incident response drills and exercises in conjunction with off-site responder organizations” (Metric 9.4; pg 86).

Problems With Current Models

The two regulatory models described above take two different approaches to the emergency response planning problem. The EPA model calls for unfunded agencies, the LEPCs, to conduct the emergency response planning for all facilities in their operations area. The CFATS model calls places the planning responsibility with the covered facility. Both models contain serious disconnects from reality.

The first problem common to both models is the funding issue. Emergency response planning takes time and expertise to accomplish the frontend work; develop the plan. That requires money to pay for the expert’s time. Even if the expert is volunteering their time there is the cost of the time lost to that expert’s normal job. Next, in order to be an effective plan, the plan must be reviewed, revised, exercised, reviewed and revised on a periodic basis. Again, the time involved in the process is costly and limited. LEPCs in large urban areas may be able to absorb this cost by having a full-time professional planner on staff with a local agency, but that is not going to be an option for most communities.

For large CFATS facilities, it may be possible to have a full-time emergency response planner on staff or finances may be available to pay for an emergency response contractor to undertake the planning necessary. At some point, however, as facility’s decrease in size that professional capability is going to be impossible to afford. But even where the facility has the financial resources to fund a planner, the community is still going to have to fund the review and exercise portion of the emergency planning process. Again, smaller communities are going to find this extremely difficult or impossible to afford.

The second problem is the information sharing issue. At first glance, in the EPA model this does not seem to be much of a problem. Facilities are required to provide LEPCs with the required information, either directly by law or by response to requests from the LEPC. Unfortunately, the amount required directly by statute is relatively limited and the LEPC can only request the information that it knows that it needs. There is no incentive for facilities to share additional information such as the presence of other chemicals on site that may complicate the emergency response process.

For CFATS covered facilities this problem is aggravated by the statutory restrictions on the sharing of Chemical-Terrorism Vulnerability Information (CVI). Now the information about CFATS facility holdings of the toxic-release hazard chemicals covered under the EPCRA rules is not generally going to be classified as CVI, at least as that information relates to the type, amount and location of the Highly Hazardous Chemicals listed in the EPCRA regulations. As noted earlier, however, flammable and explosive release hazard chemicals covered under CFATS are not addressed in EPCRA and the sharing of information about those chemicals (which also need emergency response planning under CFATS) is limited to only those individuals that have been trained in handling of CVI materials and have the appropriate means to protect that information. Again, there is a time cost associated with receiving the CVI training (the training is free) and the cost of the physical security and cybersecurity for protecting that information is not negligible.

And the final problem with the current models is that both EPA and DHS have made it difficult to share information with the potentially affected neighbors about the emergency response planning. Both agencies have done this with the intent to deny information to potential attackers. The EPA restricts access to the facility data to people who physically access an EPA reading room (limited locations), and DHS prohibits sharing of CVI information with the public. While done with the best of motives, both agencies have ensured that in most cases the public does not have access to the necessary information to promptly respond to an emergency response situation.

Fixing the Problem

Because of the size of the universe of EPCRA covered facilities, I do not foresee Congress attempting to provide enough funding to allow LEPCs to fix the emergency response planning problems identified above. If they are fixed it will be on a case by case basis where either the local community or large chemical facility is able to provide the necessary funding.

Because the CFATS covered facility universe is much smaller (3,330 as of March 1st) some of these issues may be more tractable. I have addressed in some detail how I would modify the current authorization in a blog post from last year. The money issue still remains, my suggestion to allow (gently require) FEMA to use grant funds for emergency response planning for CFATS covered facilities only partially addresses the issue due to the limited nature of those funds and I did not propose increasing them because that would increase the problems with getting the reauthorization bill passed. Realistically, FEMA needs a specific emergency response planning grant authority and is probably going to have to be required (and funded) to provide professionals to help LEPCs conduct both the planning and exercises of those plans. That will almost certainly have to be addressed in separate legislation.

Finally, none of my suggestions in the earlier post address the issue of information sharing with the local, potentially directly affected population. It is easy to say that information must be shared but legislating that in an effective manner is going to be difficult. Defining who the potentially affected population is will be hard enough. Crafting language describing an effective outreach program that will overcome what is unfortunately in many cases a mistrust of the chemical industry based upon decades of poor, incomplete and often misleading information is going to be difficult.

The best I can suggest at this point is adding an additional sub-paragraph to the end of §636(b) proposed in that earlier blog post:

(6) Conduct an annual outreach class for the immediate neighbors potentially affected by a full release of any toxic-release COI on the facility describing:

(A) What such a release might look and or sound like;
(B) What measures the facility has in place to warn neighbors of such a release;
(C) What immediate actions neighbors should take to best protect themselves in the event of such a waring;
(D) How neighbors will be made aware of an all-clear status after an incident;
(E) What medical treatment should be sought after such a release.
(F) A point of contact for reporting suspicious activities in the neighborhood that may be directed at the facility.

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