CSB Updates for Majestic Paints Explosion – 4-13-21

Last week there was an explosion and fire at a paint and polymer plant in Columbus, OH. The Chemical Safety Board announced that they would be deploying an investigation team to the incident that involved on death and large scale destruction at the facility. The next day they published their first informational report on the incident and this week followed up with their second update. The investigation is still being conducted and it will likely be some time before the CSB issues its final report.

It looks like this will be the new standard for incident information sharing during incident investigations, since they were also proactive about the information flow on the liquid nitrogen release incident in Georgia in February.

The Incident

According to news reports (here, here, and here) last week the explosion and fire occurred after midnight in one of the units at the facility. Eight people were taken to area hospitals, with two in critical condition and six in stable condition. One person was killed. There were apparently no injuries off-site and only minor damage at neighboring facilities. One of the news reports stated that there were ‘additional explosions’ while fire crews battled the blaze.

CSB Initial Report

The initial deployment update from the CSB provided some basic background information on the facility. It noted that the explosion and fire took place in the OPC Polymer unit at the facility. They reported that there were 21 employees at the site at the time of the incident with one being killed, five hospitalized and four ‘non-serious injuries’. They also reported that the “fire and explosion occurred at approximately 12:30 a.m. EDT”.

Follow-up Report

This week’s report from the CSB provided more information about the incident. The new information includes:

• A review of security video allowed the investigation team to develop a more precise time of the incident. The first event (loss of containment) occurred at 12:02 a.m. EDT (system time) and the video cameras stopped recording at 12:04 a.m. EDT (system time).

• Yenkin-Majestic provided the investigation team with an overview of the resin manufacturing process.  The process is called alkyd resin manufacturing which utilizes the company’s own technology.

• Materials are mixed in a metallic kettle which contains an agitator and is heated by a furnace before it goes to a scale tank and then to product storage. There are a total of six kettles: four are heated by gas furnaces and two are steam heated.

• The incident occurred during the batch production in Kettle #3.

• Kettle #3 has a rated capacity of 20,900 lbs. and is heated by a gas furnace.

• The fire suppression system in a portion of the paint production facility was activated during the event. The investigation team verified there was no fire event in the adjacent paint production facility.

• The east wall of the paint production facility sustained damaged as a result of the explosion event in the adjacent OPC Resin facility.

Alkyd Resin Manufacturing

Alkyd resins are long chain molecules made up of repeating units. Instead of self-reacting monomers making up those units as is seen in polymer manufacturing, alkyd resins are typically made with glycols (molecules with alcohol groups on each end) and poly-basic acids (molecules with carboxylic acid groups on each end). As the molecules grow longer their viscosity increases significantly. To keep the viscosity manageable solvents are typically added to the mixture.

The condensation reaction between the glycol and carboxylic acids requires the application of heat and produces water as a byproduct. The water must be removed from the system, coming off as steam and usually includes significant amounts of solvent as it leaves the vessel. That gas is forced through a condenser and the solvent is returned to the vessel and the water is collected in separate vessel. That produced water is contaminated with solvent and is either disposed of as waste or processed to remove the residual solvent.

All of the alkyd resin production that I have been associated with used steam as the heat source driving the reaction. Steam is easy to use, and the flames used to heat the boiler to produce the steam are typically isolated from the production area in a separate building. According to the CSB, the process involved in the incident used a gas furnace instead of steam. This is almost certainly because the OPC Resin process called for higher temperatures than are typically available from steam.

Commentary

The CSB has a lot of investigating to complete before an official cause of the incident can be determined. Having said that, based upon the very limited information available to date, I can imagine a scenario that could lead to an explosion and fire like that seen at the Columbus facility.

A release (or loss of containment) between the reaction vessel and the condenser would lead to a steam cloud containing solvent vapors. The temperature at the point of release would almost certainly be above the flash point for the solvent. If the vapor/steam cloud reached the flames in the furnace (or another ignition source) an explosion could result.

As we currently understand the facts surrounding this incident, the above scenario is one readily possible explanation for the explosion and fire. We will have to wait and see what other facts the CSB uncovers in their investigation.

One final point that I would like to make is that I greatly appreciate this new information sharing activity on the part of the CSB. The CSB has always done an excellent job of preparing final reports on their investigations, but these preliminary facts help the process industry look at their operations with an eye toward making them safer. It is always better if we can learn from someone else’s mistakes.

NHTSA Publishes Automated Driving ANPRM

Today the DOT’s National Highway Traffic Safety Administration (NHTSA) published an advanced notice of proposed rulemaking in the Federal Register (85 FR 78058-78075) for the “Framework for Automated Driving System Safety”. NHTSA is seeking public input on a framework that “would objectively define, assess, and manage the safety of ADS [automated driving system] performance while ensuring the needed flexibility to enable further innovation.”

The Framework

In this ANPRM NHTSA is not proposing the establishment of a new Federal Motor Vehicle Safety Standard (FMVSS) for ADS as it is too early in the development process to identify the critical safety characteristics that would be necessary to develop a new FMVSS. Instead, NHTSA intends to develop “a framework approach to safety for ADS developers would use performance-oriented approaches and metrics that would accommodate the design flexibility needed to ensure that manufacturers can pursue safety innovations and novel designs in these new technologies.”

In the development of this framework NHTSA plans to focus on four core functions of the ADS. Those functions are:

• How the ADS receives information about its environment through sensors (“sensing”),

• How the ADS detects and categorizes other road users (vehicles, motorcyclists, pedestrians, etc.), infrastructure (traffic signs, signals, etc.), and conditions (weather events, road construction, etc.) (“perception”),

• How the ADS analyzes the situation, plans the route it will take on the way to its intended destination, and makes decisions on how to respond appropriately to the road users, infrastructure, and conditions detected and categorized (“planning”), and

• How the ADS executes the driving functions necessary to carry out that plan (“control”) through interaction with other parts of the vehicle.

NHTSA is soliciting comments on these core functions, including:

• Whether commenters agree that these are the core functions,

• Views on NHTSA's description of these functions, and

• Whether and how NHTSA should prioritize its research as it develops a safety framework.

Additionally, NHTSA acknowledges that they have identified eight other aspects of an ADS that could be of specific interest in the development of their framework. Those include:

(1) Identifying reduced system performance and/or ODD in the presence of failure,

(2) operating in a degraded mode within reduced system constraints,

(3) performing the essential task of transporting occupants or goods from starting point to the chosen destination,

(4) recognizing and reacting appropriately to communications from first responders, including fire, EMS, and law enforcement,

(5) receiving, loading, and following over-the-air software updates,

(6) performing system maintenance and calibration,

(7) addressing safety-related cybersecurity risks, and

(8) system redundancies.

NHTSA is soliciting comments on these other aspects of an ADS described above including:

• Which of these aspects the Agency should prioritize as it continues the research necessary to develop a safety framework,

• Whether it has an appropriate role to play with any or all of these elements outside of research,

• Should NHTSA's role be regulatory or sub-regulatory for each element?

Interestingly, the Agency does note that they are not specifically authorized under the Safety Act “to regulate areas such as general privacy and cybersecurity unrelated to safety”.

Regulatory Mechanisms

Looking forward, NHTSA recognizes that at some point they will be responsible for regulating ADS safety. In this ANPRM, NHTSA looks at potential regulation mechanisms and sees comments on those topics as well. These proposed mechanisms include:

• Mandatory reporting and/or disclosure,

• NHTSA'S FMVSS setting authority,

• Applying the established FMVSS framework to ADS safety principles, and

• Reforming how NHTSA drafts new FMVSS to keep pace with rapidly evolving technology.

NHTSA provides the following examples of possible regulatory action:

FMVSS requiring obstacle course-based validation in variable scenarios and conditions,

FMVSS requiring vehicles to be programmed to drive defensively in a risk-minimizing manner in any scenario within their ODD [operational design domain],

FMVSS drafted in a highly performance-oriented manner,

Timing and phasing of FMVSS development and implementation,

NHTSA Soliciting Comments

As mentioned above, the Agency is soliciting public comments on this proposed rulemaking. In addition to the comments mentioned above, NHTSA includes 24 specific questions to which it is seeking public input. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # NHTSA-2020-0106). Comments should be submitted by February 1^st, 2021.

Commentary

NHTSA continues to run a catchup game on the regulation of automated driving systems. Part of that is the normal regulatory inertia that affects any government operation, but the other is the lack of Congressional direction and authorization to operate in a quickly changing technological environment. Having said that, today’s ANPRM is a significant next step in NHTSA’s effort to keep up with ADS development.

While NHTSA continues to mention cybersecurity in its ADS literature and this ANPRM, I do not think that they are taking the issue seriously enough. Not a single one of the 24 specific questions that NHTSA proposed for response addressed cybersecurity topics.

Furthermore, NHTSA missed the boat by not including a fifth ‘core function’ for ADS; “Protection”. In keeping with the language of the ANPRM, “protection” would refer to the ability of the ADS system to continue to protect the safety of the vehicle’s occupants in the event of an electronic failure due to component failure, communication (internal or external) disruption or cyberattack. In process safety terms, this means that the system has mechanisms and protocols in place to ensure that it fails in an inherently safe manner.

I think that it is important for NHTSA to encourage developers to consider system failure modalities early in the development cycle and include development of ‘fail safe’ mechanisms as a design criterion. As NHTSA moves into the FMVSSA development process it needs to consider identifying common failure modes and specifying minimum standards for engineering responses to those modalities.

This is more than just ‘cybersecurity’, though it certainly embodies a key component of operations technology cybersecurity, failure mitigation. Cyberattacks are one failure mode that must be considered in the design and development process, but other failure modes must also be addressed.  Other failure modes that should be addressed include:

• Loss of signal from external devices,

• Internal communication disruption,

• Physical, mechanical, or electronic interruption of sensors,

• Interrupted or incomplete software updates, and

• Loss of power to either powertrain or electronic systems.

Developers need to demonstrate that they have taken failure mitigation into account in their design process, documenting the failure modes identified and explaining the mitigation measures adopted. Further, they need to have an identified process in place for:

• Detecting new failure modes in development testing and real-world operations,

• Developing appropriate mitigation measures, and

• Communicating those measures to vehicles in the field.

Finally, NHTSA has to have a reporting mechanism in place for reporting newly identified failure modes and the mitigation measures adopted. And NHTSA has to be prepared to (and allowed to) proactively share those failure modes with other ADS and OEM vendors using the same or significantly similar equipment.

A copy of this blog post will be filed as a comment on this ANPRM.

Chemical Plants and Ransomware

There has been an interesting and on-going discussion on TWITTER® related to how chemical plants may be affected by ransomware like WannaCry. It was the result of the publication of two DHS-OCIA FOUO documents about WannaCry (here and here). They were published by PublicIntelligence.

The on-going TWITTER discussion was really based upon one entry in a chart in the second document described above; (U) Table 1—Ransomware Targeting and Susceptibility by Sector. The entry for the Chemical Sector contained the statement: “Chemical plants have manual overrides in place to ensure the safe containment of chemical processes in case cyber defenses fail. In some cases, it may be possible to run the chemical plant independently of cyber controls, otherwise the plant will most likely shut down.”

Most of the discussion has been on where the supporting data for that statement comes (short answer, no one knows) and how accurate that statement is. I cannot provide any information on the first, but a reasonable answer to the second will take more than 140 characters to explain.

Chemical Plant Automation

There is a great deal of variety in the level and sophistication of automation in chemical manufacturing processes. I have worked in a plant where there was absolutely no automation. Sensors were either analog or digital with no connections beyond a power supply. All operations are directly controlled by the operator manually operating various valves and power switches. Plants like this are unusual in this day and age. They are small plants typically running experimental processes on a shoestring budget. They are going to essentially be unaffected by ransomware except on the business process side of the house.

The most sophisticated facilities (and I have seen some of these, but never worked in one) have almost completely automated their chemical manufacturing processes. The extensive and complicated control system requires limited operator oversight; taking a wide mix of sensor data (temperature, pressure, flowrates and valve states for example) processes that data to develop (via a complex process control algorithm) commands to various operations devices (transfer valves, heating, cooling and vacuum controls for example) to control the manufacturing process. The operator actions are fairly limited to starting or stopping the process, making small manual adds of chemicals to the process and watching for process upset conditions.

Most specialty chemical manufacturing (batch processes) have a level of automation somewhere between these two extremes. An operator typically watches sensor data on a human machine interface (HMI) display and operates controls via the same HMI in response to a written set of instructions, training and experience. There may be some manual valve movements made by the operator or his assistants, but most are remotely operated via electrical or pneumatic operations.

Safety systems are in use (hopefully) in all plants regardless of the level of automation. They may be simple mechanical devices such as pressure relief valves or rupture disks. They could be process alarms that require operators to take manual corrective actions. They could be simple interlocks where a specific sensor output generates a direct command to operate a specific valve. Or they could be complex algorithmic responses to a variety of sensor readings resulting is a number of automatic operational changes to the process. These automated safety systems can reside in a stand-alone computer system with dedicated sensors and valves that are not in any way connected to the main process control system (the safest system) or various parts (or all of) the safety system could reside on the same computer system running the chemical manufacturing process.

In a perfect world, what determines the level of sophistication (and thus cost) of the safety system is the potential outcome of the process upset that it controls. The more serious the potential consequence of the process upset (again in a perfect world) the more complex and involved the safety system becomes. Where there are potential catastrophic, off-site consequences one would like to expect to see sophisticated stand-alone safety systems to prevent those catastrophic results.

Ransomware Effects

For purposes of this discussion I am going to assume that the ransomware has effected all networked controls system computers and that any stand-alone safety systems remain operational, these would include sophisticated systems, mechanical devices and most electro-mechanical interlocks (those not controlled through a PLC).

For the least automated systems the affects would be mainly cosmetic; operators would still be controlling the process, it would be more physical control with the operator going out and manually operating controls instead of using the HMI. This is assuming that there are still sensor readouts that do not go through the HMI. This would require either analog gauges or 4/20ma gauges wired to old-style displays.

Double displays with their associated wiring are a pain to maintain and frequently are considered a wasteful duplication of resources. The absence of analog gauges or non-computer sensor-output displays would mean that the operator would have no view of the key process control variables, and thus, no control of the process.

The consequences of going to full operator manual control of processes would be immense. I made the transition from full manual to semi-automated process control. We were able to add more sensors to better understand the process variables and those new sensors were in locations that were not readily accessible by the operator. Just those additional sensors decreased process times (and thus process costs) significantly as well as reducing product variability and off-spec products. We also significantly reduced the number of operators that were necessary to operate multiple processes that typically run at specialty chemical plants. Some plants would be able to operate at significantly reduced capacity, but increased product variability problem could have downstream quality effects on customer operations.

For fully automated chemical facilities (typically found in continuous process facilities like refineries) an instantaneous change to manual operation would not be possible. The lack of analog gauges and local sensor readouts and the relatively inaccessible manual controls would make it physically impossible for operators to coordinate the operation of the connected portions of the process in real time.

Safety Effects

Again, properly designed and implemented safety systems would be expected to stop any catastrophic consequences of sudden loss of control in chemical manufacturing systems. There were a number of very important qualifiers in that previous sentence. The major problem with designing safety systems is that it is very difficult to completely understand catastrophic failure modes in a manufacturing environment.

Typically, one has to use lab scale data to understand the physical parameters of those failure modes (NO ONE wants to do FULL SCALE testing of such failure modes) and then apply various models to try to scale up those test results to be able to plan for preventive actions to stop or mitigate the failures. No matter how sophisticated the modeling efforts they are, in the end, based upon educated guesses as to how the system will behave. Then systems are designed to try to best control those failure modes. And, it is not generally acceptable to really test those systems to see how they actually work in practice (in the emergency environment).

The OCIA Statement

The OCIA statement that started this discussion is almost certainly not based upon any survey of the chemical industry. It is a reasonable brief attempt by outsiders with a non-chemical manufacturing background to categorize the potential consequences of a non-chemical emergency event on generic chemical manufacturing.

If I were to attempt to reword this statement from a chemical manufacturing process point of view, it would read something like this:

“Chemical manufacturing facilities should have safety systems in place to contain catastrophic consequences in the event of loss of control. The efficacy of those systems and their operation in an instantaneous loss of computer control situation would have to be evaluated on a case-by-case basis. Continued commercial production without replacing/fixing affected computer based process controls could be possible is some unknown number of facilities. It would be difficult to accurately predict which facilities could continue commercially viable production.”

ICS-CERT Defense-in-Depth Paper Updated

Today the DHS ICS-CERT published a notice on their web site that they have updated one of their Reference Practice documents; “Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies”. The original document was written in 2009 and this update reflects (according to the official abstract) changes in control systems management, security practices, and change management within the ICS community.

I was not closely following ICS-CERT when the original document was published. I did run into it a number of years later, but did not save a copy of the document because it was clearly dated. This means that I do not have any reasonable expectation that I can write about the changes in the document. That means that I’ll have to deal with it only in its current form.

Real Brief Overview

Both the abstract and the Executive Summary from the actual document provide describe the organization of the revised documents this way:

“Background and Overview” outlines the current state of ICS cybersecurity and provides an overview of what defense in depth means in a control system context;

“ICS Defense-in-Depth Strategies” provides strategies for securing control system environments;

“Security Attacks” outlines how threat actors could carry out attacks against critical infrastructures and the potential impact to ICSs and networks; and

“Recommendations for Securing ICS” provides resources for securing ICSs based on the current state-of-the-art methods and lessons learned from ICS-CERT activities, national and sector-specific standards for ICS security, and tools and services available through ICS-CERT and others that can be used to improve the security posture of ICS environments.

Remember the Objective of ICS Security

I’ll leave a review of the most of the technical aspects of the document to those with the appropriate background in implementing cybersecurity techniques. What I am more concerned about is what is lacking from this discussion; an appreciation that industrial control systems are really only potential targets of attack because of the industrial process which they control. This document mentions this a couple of times in passing (for instance in section 2.2.5 where it states “…or if the ICS controls a process with potential human safety consequences, it may

require special consideration and additional controls.”), but the document fails to address the consequence of this fact of life.

Specifically, it fails to address the fact that the first step in any risk assessment of the security of an industrial control system needs to start with a review of the process being controlled and the consequences of a loss of control or even a loss of view of that process. The level of risk for an ICS that controls the manufacture of widgets, is much less than one that controls the use, storage or manufacture of toxic inhalation hazard chemicals, which is different than one that controls high-speed passenger rail traffic on a high-profile transportation corridor.

Failure to take into account the consequences of a successful attack on a control system means that any cost/benefit analysis of the risk versus the cost of ‘adequate security’ will be grossly misestimated. It is also very likely to lead to a misunderstanding of which controls are actually critical controls that may need additional security protections.

Safety Controls in Defense-in-Depth

The other area where a lack of appreciation of the actual purpose of industrial control systems is found in the discussion of different types of defenses that can be used in a defense-in-depth system. Where ever the loss of control or loss of view of a process can lead to safety concerns for facility personnel or, even more importantly, off-site personnel, an important part of the defense-in-depth process has got to be safety controls that are not part of the industrial control system that may be attacked.

The successful design, application and implementation of these safety controls may go a long way to mitigate a successful attack on the control system. A clear understanding of the design basis for the safety controls and the degree of their integration with or in the industrial control system is absolutely necessary for the proper assessment of the risk of a successful attack on a control system and the proper design and implementation of an effective defense-in-depth strategy.

Probably the most important safety control in many process environments is the skill and knowledge of the operators that oversee the functioning of the process being controlled by the industrial control system. Ensuring that operators have skill and experience to identify non-standard operating excursions (and the methods of identifying those excursions outside of the possibly vulnerable control system) and the ability to assume enough process control without using a compromised ICS to avoid the worst safety consequences of loss of control via the ICS is another defense-in-depth strategy that is missing from the discussion in this document.

Need to Expand the Parochial View of ICS Security

We must at all times remember that industrial control systems (except in honey pots) do not exist in a vacuum. They exist to control an actual physical process. An understanding of that process, and the consequences of that process being upset, must inform all decisions about the security of the industrial control system.

For example, if in a chemical manufacturing facility, we only have one isolatable process that could have significant off-site consequences if we lose control or view of the control system for that process, we should certainly take a long, hard look at making a separate Cell Security Zone (see page 19) for the devices monitoring and controlling that process to build-in an additional layer in the defense of the devices controlling that process.

Now I understand that ICS-CERT is first and foremost a cybersecurity organization focused on industrial control systems. They do not have the expertise in the wide variety of process that may be controlled by such systems, so it is easy for them to overlook that additional level of complexity in looking at cybersecurity for control systems. But, they really do need to ensure that they learn the absolute necessity for including process safety (consequence) analysis in any discussion of analyzing control system security or designing an effective defense-in-depth cybersecurity plan.

Failure to include such process analysis will inevitably mean that security controls will be focused on the wrong things, allowing an attacker a better opportunity to create a successful attack. Or, maybe actually inadvertently decrease the effectiveness of the safety controls and thus end up making the process less safe. Either way, the affected organization could find itself cybersecuritied into a reduced safety environment.

SIS Firewall

I got an interesting email from Eric Byres, CTO of Byres Security Inc, last week about their recent release of a ‘Modbus Read-only Firewall for Safety Systems’. According to Eric this Tofino based ‘Honeywell Modbus Read-only Firewall (HMRF)’ has been tested to work on many major brands of safety integrated systems (SIS).

Now I am not anywhere near technically qualified enough to evaluate the claims that Eric is making for this new security tool. And no one in their right mind would make a purchase of any kind of cybersecurity tool based solely upon my recommendation. So, why am I mentioning this here? Well, it allows me to talk about two things that I have previously only mentioned in passing, first safety integrated systems and second the use safety systems as a security tool.

Safety Integrated Systems

In case anyone has not noticed, chemicals are potentially dangerous. Some of them can kill directly through their toxic effects on the human body. Others will burst into flames with only minor provocation and yet others will explode if not handled properly. These chemical properties make many of them extremely dangerous and potential terrorist targets for release, theft, or sabotage.

What professionals in the chemical process industry don’t talk about too much in public is the fact that the manufacturing processes for a completely different array of frequently innocuous chemicals may pose a threat of a different sort of chemical catastrophe. There are a variety of different ways that mistakes in the chemical manufacturing process can turn the facility into a very large bomb.

Now these are not bombs in the military sense, but rather something that goes wrong in the process that produces a sudden large increase in pressure in a closed system that causes a catastrophic failure in the equipment. While this is not technically an explosion (I prefer the term over-pressure event), the consequences are very similar; a shock wave that can cause extensive damage over a wide area and bits of flying metal that can kill people and damage nearby equipment. Resulting fires may or may not be associated with this type of incident.

For an example of this type of event and its deadly consequences read my blog post describing the December 19th, 2007 T2 Laboratories explosion in Jacksonville, FL or the more detailed report on the causes of that incident by the Chemical Safety Board. That incident killed four employees, injured 28 people in surrounding businesses and threw large pieces of metal over a mile away from the scene.

One of the ways that chemical process professionals prevent this kind of situation is through the use of a Safety Integrated System (SIS). In its purest application, a SIS is essentially a stand-alone industrial control system. It is fully automatic, watching a manufacturing process for certain clearly defined parameters of measured temperature and pressure. When specified limits are exceeded the system automatically takes pre-programmed steps to make the process safe; all of this takes place without (and often in spite of) operator oversight or control.

The sensors it monitors and the controls that it manipulates are completely separate from the ones used by the normal process control system. There are multiple redundancies designed into the system and the components are the typically the most reliable (read expensive), failure free components available.

Now, don’t get me wrong. Chemical processes designers include a number of other controls to prevent such process catastrophes. You design equipment to withstand normal process pressures and temperatures and you provide reasonable pressure relief systems. You have operators and process control systems working hard to keep manufacturing processes within their optimum limits. That’s the only way you can make money in chemical manufacturing.

But, stuff happens. People make mistakes or deliberately try to damage processes, equipment fails, or utilities are disrupted. In the end the SIS stands as the last line of defense to prevent the catastrophic destruction of a chemical manufacturing facility and preventing potential damage to the surrounding community.

But, what happens if the SIS is subverted? What happens if someone changes the parameters that initiate the protective response? What happens if the SIS is re-programmed to ignore the safety critical inputs? What happens if the SIS is re-programmed to cause a safety critical upset? That unauthorized re-programming is what Eric’s firewall is designed to prevent. How well it works; I just don’t know. You need to talk to Eric or his people about that.

Safety as Security

Safety programs and systems are an integral part of modern manufacturing processes. One would like to think that management would view these as a key component of operating a money making concern. Just in case that message has not gotten through, there are a number of federal, State and local safety laws that must be complied with to avoid fines and other sanctions.

For high-risk chemical facilities there are a number of specific chemical safety and process safety rules that may apply to a facility. Many of the systems put into place to comply with these rules should also be considered to be an integral part of the facility security program. OSHA and EPA process safety programs will help to prevent attackers from using chemical processes as weapons. Community right-to-know and hazard communications (HAZCOM) rules will ensure that emergency response personnel will understand the chemical hazards that they might be faced with in the event of a terrorist attack.

In my opinion a facility with an inadequate safety program cannot be a well secured facility. Poor safety programs allow for too many areas where even a well designed security program can be subverted or fail. Protecting your storage tanks from terrorist attack will do little good if a process vessel explodes because of a runaway reaction. Calling on local law enforcement to respond to a potential terrorist intrusion is useless if those responders are inadequately protected from the chemical hazards on-site.

Let’s face it; a terrorist attack on a high-risk chemical facility is a low probability event. In fact, if we just rely on historical extrapolation there is no risk of terrorist attack since there hasn’t been one to date. We do have a well documented history of chemical process accidents causing death and economic disruption. Any reasonable person would be more concerned about the potential for a process accident than a terrorist attack having an effect on the community around a chemical facility.

Chemical Safety and Security

One of the blogs that I follow is Risk-Safety.com. The author provides some interesting insights into chemical process safety; an area that was one of my principal foci while I worked in the chemical industry. Earlier this week he published a brief overview of the CFATS process. This would have been enough to get me to review his posting, but he went one step further and was kind enough to put my name (with a link to this blog) in the post as a reference for ‘detailed information on Chemical Security’. Many authors (my self included) have attempted to briefly summarize the CFATS process. I do believe that Dr. Saraf has produced one of the better very-short (<600 words) summaries that I have seen of this complex topic. As must be expected with such a short treatment, he does gloss over many of the details of the subject. He covers that shortcoming with links to a variety of primary sources (and this blog of course). All in all, for his process safety audience, he does a good job. What is more important that the quality of the summary in this posting is that he is bringing the discussion of chemical facility security to the process chemistry safety community. While the expertise of the security community is important in developing adequate security plans, a detailed knowledge of process chemistry is just as important. Understanding what process upsets can lead to catastrophic consequences is as critical as developing an adequate perimeter barrier plan. Facilities need to put together a security team with a wide variety of backgrounds; much the same way that they put together their process safety teams. In fact, it would not be unreasonable to task the process safety teams that deal with the facility COI to provide support to the facility security team. Since the vast majority of COI are taken from the PSM or RMP chemical lists, there is likely to be a readily identifiable core of chemical subject matter experts available to advise the security people. I hope that we will see more chemical security discussions in Dr. Saraf’s blog. And I hope that some of his readers find their way to this blog; they will certainly be welcome.

Reader Comment 03-19-09 – CSB vs Bayer

Poppy left a comment on my blog from Monday about the CSB vs Bayer controversy. The comment provides links to a couple of articles/editorials on C&E News, a publication of the American Chemical Society about the secrecy-disclosure issue. I would add to that a link to the blog from the editor of the West Virginia Gazette. I was concerned that none of these mentioned the CSB press release from last Friday that announced that the public meeting was going forward. I just went back and confirmed that that press release was still on the CSB web site, so presumably the public meeting is still on. I still have not heard or seen anything that would indicate that there will be any restrictions on what the CSB will discuss about the results of their inspection. While I can understand the Bayer would not want any security details about their facility discussed in a public forum, I do not think that that is their real issue in this case. If it were they could have quietly contacted the Captain of the Port who could have had a quiet talk with the CSB. CSB could have gone forward with their original public meeting while practicing a little discretion about the discussion of security issues. But, looking at the CSB reports from previous incidents I see no indication that they would have had anything to say about security issues. Wait, let me modify that; unless they thought the security issue contributed to the accident. This has not been an issue to date, but it could conceivably be in this or some future case. But there is another way that the CSB could compromise security. Process Safety is Part of Security Process safety and facility security are curiously intertwined. A process that is not adequately protected from a safety stand point cannot be adequately defended from a terrorist attack. If the process controls (physical, electronic and human factors) are not designed to protect against all known and suspected catastrophic process upsets, the process becomes that much more susceptible to a successful terrorist attack. If, for example, there are not multiple redundant systems to protect against a known runaway reaction condition, a terrorist would only have to interrupt only a single control system feed to cause a catastrophic chemical reaction. Now if this is the type security issue that Bayer is trying to avoid having discussed, too bad. It is not something that has been addressed by either MTSA or CFATS. Neither Congress nor DHS is chemically savvy enough to have realized that process safety is part and parcel an integral component of facility security; which is a shame in many ways. I think the people from DHS would be much more aggressive at enforcing process safety rules than either EPA or OSHA has been to date. CSB will Investigate and Report CSB will continue to do what they do best. Investigate chemical related accidents and get to the root cause of the incident. And from their search they will distill the lessons that the chemical community needs to learn to move forward to a safer and more secure future. Bayer needs to do what so many other companies have done before them in this situation; suck it up, say the ‘mea culpa’, and fix the identified problems. If they can’t or won’t do that, security is the least of their problems.