CSB Guidance on Reporting Accidental Chemical Releases

Yesterday, the Chemical Safety and Hazard Investigation Board (CSB) published their promised guidance document on the reporting of accidental chemical releases under 40 CFR 1604. As with any governmental ‘guidance’ document there is a lot of superfluous verbiage setting the background of the need of, and legal justification for, the base regulation. CSB does a better job than most with making this readable, but the first seven pages of the document can be skipped by all but the most ardent infophiles.

Pages 8 and 9 of the document provide a nicely done summary of what CSB expects when an accidental chemical release occurs. An interesting pull quote from page 9 reflects an unusual amount of bureaucratic naivete about corporate interests in reporting chemical incidents:

“Under the CSB’s Accidental Release Reporting Rule, it is always safer for an owner/operator to report, rather than fail to report. Thus, it is the CSB’s position that if an owner/operator is unsure whether the incident should be reported, the owner/operator should report, rather than risk violating the rule by failing to report. There is no sanction or enforcement action associated with reporting an accidental release, which in retrospect, did not have to be reported. The opposite, however, is not true. Failure to report an accidental release when required by this rule could lead to an enforcement action brought by the EPA.”

The remainder of the document is formatted in a frequently asked questions (FAQ) format. CSB does go beyond just quoting relevant parts of the regulation. For example, at the end of the reply to FAQ 2.11 on pages 10 and 11, CSB concludes the discussion by reminding folks that the intent of the rule is to provide CSB with the necessary information to determine if an investigation is warranted and then states:

“The CSB has and will continue to investigate matters involving the accidental releases of chemicals, petrochemicals, and hydrocarbons of all types, provided that a fatality, serious injury, or substantial property damage is caused by the accidental release at issue.”

Any owner or facility manager for a facility that produces, uses, or handles hazardous chemicals of any sort, ought to have a copy of this document handy, and look at it periodically. Every EH&S manager needs to have read and understood this guidance before a chemical release incident takes place, probably before close of business yesterday.

Review - FDA Publishes Draft Medical Device Cybersecurity Guidance

Yesterday, the FDA published a notice of availability in the Federal Register (87 FR 20878-20875) for a Draft Guidance Document on “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions”. The draft guidance can be downloaded from the Federal eRulemaking Portal.

According to the Summary in the Notice:

“This draft guidance is intended to further emphasize the importance of ensuring that devices are designed securely, are designed to be capable of mitigating emerging cybersecurity risks throughout the Total Product Life Cycle, and to clearly outline FDA's recommendations for premarket submission content to address cybersecurity concerns.”

The summary goes on to remind folks that: “This draft guidance is not final nor is it for implementation at this time.”

Comment Solicitation

The FDA is soliciting comments on this draft guidance. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket FDA-2021-D-1158). Comments should be submitted by July 7^th, 2022.

Commentary

First off, I am not a doctor, not even a medical device engineer, nor have I played one on TV. Having said that, it seems to me that there may be a little too much focus on cybersecurity in this guidance document. I know, that is what the document is about, but it seems to miss the fact that it is not really cybersecurity that we are concerned about when we talk about medical devices, it should primarily be protecting patient safety, secondarily about protecting patient information and confidentiality, and only then protecting the device and medical network.

While a Secure Product Development Framework is certainly important in any software development cycle, it is not sufficient, since we know that what people design is going to be imperfect. This means that there will be vulnerabilities in even well-designed systems. Whenever safety is an issue, and it certainly is in medical devices, we need to go beyond SPDF and look at Consequence-driven Cyber-informed Engineering (CCE). This methodology developed at the Idaho National Laboratory (INL) concentrates on identifying the safety consequences of system errors and vulnerabilities and working to mitigate those consequences. This methodology should be included in any discussion about cybersecurity for medical devices.

For more details about the draft guidance document, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/fda-publishes-draft-medical-device - subscription required.

NHTSA Publishes Request for Comments on Cybersecurity Guidance

Today the DOT’s National Highway Transportation Safety Administration (NHTSA) has published a notice in the Federal Register (81 FR 18935-18939) requesting comments on proposed guidance for motor vehicle and equipment manufacturers in developing and implementing new and emerging automotive technologies, safety compliance programs, and other business practices in connection with such technologies.

Legal Authority

A substantial portion of the notice establishes the legal authority for NHTSA to regulate the safety of the electronic portions of automotive equipment. They specifically note that under provisions of 49 USC 30102:

“With respect to new and emerging technologies, NHTSA considers automated vehicle technologies, systems, and equipment to be motor vehicle equipment, whether they are offered to the public as part of a new motor vehicle (as original equipment) or as an after-market replacement(s) of or improvement(s) to original equipment. NHTSA also considers software (including, but not necessarily limited to, the programs, instructions, code, and data used to operate computers and related devices), and after-market software updates, to be motor vehicle equipment within the meaning of the Safety Act.”

The notice goes on to explain that in accordance with the requirements of 49 CFR Part 573: “Accordingly, a manufacturer of new and emerging vehicle technologies and equipment, whether it is the supplier of the equipment or the manufacturer of a motor vehicle on which the equipment is installed, has an obligation to notify NHTSA of any and all safety-related defects.”

NHTSA explains that it normally uses the performance record for a vehicle to determine if a safety defect exists, explaining that this is done primarily where the engineering or root cause of the defect is not known. The notice goes on to explain that: “Where, however, the engineering or root cause is known, the Agency need not proceed with analyzing the performance record.”

NHTSA goes on to explain that the Safety Act requires a forward looking risk analysis that is designed “not to protect individuals from the risks associated with defective vehicles only after serious injuries have already occurred; it is to prevent serious injuries stemming from established defects before they occur”. They go on to note:

“Moreover, a defect may be considered ‘per se’ safety-related if it causes the failure of a critical component; causes a vehicle fire; causes a loss of vehicle control; or suddenly moves the driver away from steering, accelerator, and brake controls—regardless of how many injuries or accidents are likely to occur in the future.”

Thus, NHTSA concludes that their enforcement authority concerning safety-related defects in motor vehicles and equipment extends and applies equally to new and emerging automotive technologies; including existing automation and crash avoidance technologies and future autonomous vehicle technology.

Software Guidance

NHTSA notes that software on the vehicle or off the vehicle in portable devices presents unique safety risks because such software can interact with a motor vehicle's critical safety systems (i.e., systems encompassing critical control functions such as braking, steering, or acceleration) and states that:

“If software has manifested a safety-related performance failure, or otherwise presents an unreasonable risk to safety, then the software failure or safety-risk constitutes a defect compelling a recall.”

As such the notice provides the following recommendations:

• Manufacturers should consider adopting a life-cycle approach to safety risks when developing automated vehicles, other innovative automotive technologies, and safety compliance programs and other business practices in connection with such technologies;

• Manufacturers should consider developing a simulator, using case scenarios and threat modeling on all systems, sub-systems, and devices, to test for safety risks, including cybersecurity vulnerabilities, at all steps in the manufacturing process for the entire supply chain, to implement an effective risk mitigation plan;

• Manufacturers of emerging technologies and the motor vehicles on which such technology is installed have a continuing obligation to proactively identify safety concerns and mitigate the risks of harm; and

• If a manufacturer discovers or is otherwise made aware of any defects, noncompliances, or other unreasonable risks to safety after the vehicle and/or technology has been in safe operation for some time, then it should strongly consider promptly contacting the appropriate NHTSA personnel to determine the necessary next steps.

Commentary

For those expecting any detailed cybersecurity process or procedures to be outlined in this document will be sorely disappointed. The ‘guidance’ provided is only the most basic and does not even attempt to address routine cybersecurity issues such as authentication and encryption, separation of networks, or authorized access to critical functions. That is the type of discussion I would expect to see in some future motor vehicle safety standard (MVSS) for cybersecurity.

What this guidance document is clearly intended to do is to establish the legal authority of the NHTSA to regulate cybersecurity as part of the Safety Act. It establishes NHTSA’s intent to address cybersecurity vulnerabilities even if few or no actual accidents involving those vulnerabilities have been reported.

Finally, it formally puts automotive manufacturers on notice that they are responsible for the cybersecurity of all on vehicle components and off-vehicle applications designed to affect electronic vehicle components. This is especially important because the major auto manufacturers are no longer manufacturing more than a very small percentage of the component parts (including electronic systems) that go into the vehicle.

The one major part of this overarching guidance that is missing is any mention of the role of independent security researchers. Most computer system related manufacturers have long ago learned that a large portion of the cyber vulnerabilities in their systems have been identified by researchers outside of their organizations.

Coordination between those researchers and the vendors is an important consideration. It would have been appropriate in this document to announce the formation of an office within NHTSA that would provide that coordination or an announcement that NHTSA and the DHS ICS-CERT had signed a memorandum of understanding that ICS-CERT would perform that role in conjunction with the folks at NHTSA.

DHS Draft Mass Chemical Incident Patient Decon Guidance

Today the DHS Office of Health Affairs (OHA) published a notice in the Federal Register (79 FR 18570) announcing the publication of a draft of the “Patient Decontamination in a Mass Chemical Exposure Incident: National Planning Guidance for Communities”. OHA is seeking comments on the draft guidance.

The notice describes this draft document as:

This guidance document is developed for senior leaders, planners, incident commanders, emergency management personnel and trainers of local response organizations and health care facilities; it contains strategic-level, evidence-based best practices for use when planning and conducting patient decontamination in a mass chemical casualty event. The subject matter is focused on external decontamination of living people exposed to toxic industrial chemicals (TICs), toxic industrial materials (TIMs) or chemical warfare agents (CWAs) resulting from either an intentional or accidental release. 

Public comments are being solicited. Comments may be filed via the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2014-0012). Comments must be submitted by May 19, 2014.

Unfortunately, the notice does not provide a link to the guidance. There is nothing on the OHA web site. And there is nothing currently in the Regulations.gov docket. As I noted in an earlier blog post, there is an earlier limited-circulation draft document, but since this is almost two years old, I suspect that some changes have already probably been made.

NOTE: Updated 10:50 CDT 4-2-14 – A copy of the Draft is now available on the Regulations.gov site.