Update on Deadly Methyl Mercaptan Incident – 11-30-14

The Houston Chronicle is reporting that the four DuPont workers who died earlier this month during a methyl mercaptan leak at the LaPorte, TX facility were asphyxiated (died because of lack of oxygen) and did not die because of methyl mercaptan poisoning. To be sure, this is a technical difference because the relative lack of oxygen was due to the large amount (23,000 lbs) of methyl mercaptan released into the building.

Unanswered Questions

This raises a number of interesting questions, most of which I would assume that the CSB is asking and/or answering:

• Did anyone at the site know about the magnitude of the ‘leak’ before any of the four employees entered the building? If they did, this should have been a full-blown hazmat response team involved, not four piecemeal employees responding to a ‘leaking valve’.

• If no one knew the magnitude of the leak, why not? That amount of material should have registered as a very significant change in tank/vessel level/weight. That alone should have set off significant alarms on site.

• Was this a leak from a process vessel or a storage tank? There would have been different types of safety instrumentation and safety controls on a storage tank for a toxic substance like methyl mercaptan that should have been able to been able to isolate the leak without anyone entering the building.

• What type respirators were the four wearing when they entered the building. There was at least one news report early on that talked about one of the brothers trying to share his air with his overcome younger brother. So at least one person had a supplied air respirator. For the others to die of asphyxiation that would seem to indicate that they were wearing cartridge respirators which don’t help at all if there is a lack of oxygen in the atmosphere.

From the news reports to date we can guess at some of the answers to the above questions. It would seem that as many as three individuals entered the facility wearing cartridge type respirators. This argues that the people in charge of the unit were not aware of the magnitude of the leak. No one in the chemical industry with a modicum of sense or training would send anyone into a building where that volume of toxic, volatile chemical had spilled without doing serious gas testing, both for the presence and concentration of the toxic gas and the oxygen levels in the air.

From the news reports available to date I suspect that something like this happened (entirely supposition on my part and I have never seen the facility):

A gas detector goes off in part of the building that people are not normally working in. The gas detector reports the presence of methyl mercaptan but not the level. Two employees in proper PPE for a small leak (probably a cartridge respirator) are sent to investigate/fix the problem. When communications are lost with those individuals another person is sent in to find out what happened and is also overcome. A senior operator goes in wearing an air supplied respirator to rescue his younger brother who was one of the three original responders. He reports the extent of the problem and is then overcome while trying to resuscitate his brother with his supplied air respirator. A properly informed response team is then formed and deployed, too late to rescue the four earlier responders.

The Question Not Asked

The Chronicle article mentioned above also reports that the LaPorte facility also manufactures and uses methyl isocyanate (of Bhopal and Charleston, WV fame). This is a deadly toxic chemical and much less ‘friendly’ than methyl mercaptan. I would like to think that a facility run by DuPont that handled toxic chemicals like this had properly instrumented control systems and safety systems that would prevent incidents like this.

Giving DuPont the initial benefit of doubt there is another ugly possibility that should also be considered, was this accident the result of a cyber-attack on the facility. This could explain why a stand-alone chemical detector alarm could go off and no one in the control room could see the cause for the alarm or detect the extent of the leak. That would explain the completely inadequate preparation done to enter the facility to correct the ‘leaking valve’; all indicators would have shown a minor leak, not a massive release.

I am not sure if the Chemical Safety Board has control system security experts on the team. If not, they may not be able to detect the incursion that would have precipitated this incident. I would propose that the following might be non-technical indicators of a possible attack:

• Discrepancies in the amount of methyl mercaptan reported on site (via the automated inventory management system) before, during and after the attack;

• Discrepancies in the indicated flow rates of methyl mercaptan reported by the process control system versus the computed rate of the leak;

• Discrepancies between the control system commands initiated by the operator (either in the data historian or the operator testimony) and the control states of the equipment recorded in the data historian.

If any of those discrepancies are noted, the CSB ought to call in the ICS-CERT fly-away team to help investigate the potential for control system problems (‘problems’ covers a multitude of sins) contributing to or as the source of the massive methyl mercaptan release.

ICS-CERT Publishes Siemens and MatrikonOPC Advisories

Yesterday the DHS ICS-CERT published two new advisories; one for the Siemens WinCC application and another for the MatrikonOPC for DNP application.

Siemens Advisory

This advisory is for two vulnerabilities in SIMATIC WinCC, both as a stand alone application and as implemented in SIMATIC PCS7 and TIA Portal. These are apparently self-identified vulnerabilities for which Siemens has updates for some of the affected products and is working on updates for the others.

ICS-CERT identifies the vulnerabilities as:

• Remote code execution - CVE-2014-8551; and

• Transfer/extract files - CVE-2014-8552.

Interestingly this tells us what the exploit of the vulnerability is not what the vulnerability is. The Siemens ProductCERT advisory is not any more forthcoming on this topic than is the ICS-CERT Advisory. I suspect that any more detailed description of the actual vulnerability would make it easy for the average hacker to figure out how to exploit these vulnerabilities.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit these vulnerabilities. ICS-CERT reports that a exploits for these vulnerabilities may already be available and these vulnerabilities “may have been exploited during a recent campaign”. Siemens acknowledges assistance from Symantec Deepsight Intelligence which may substantiate that claim.

Siemens published their advisory on Friday. I noted in a TWEET® on Friday morning the unusual lack of description of the type of vulnerability. With the apparent level of risk involved and the wide spread use of these applications I am very surprised (and disconcerted) that ICS-CERT took this long to publish this advisory.

MatrikonOPC Advisory

This advisory reports an unhandled C++ exception vulnerability in the MatrikonOPC DNP3 application. The vulnerability was reported by Crain-Sistrunk and was discovered under their Project Robus using their Aegis Fuzzer (I ought to charge these guys advertising fees, but I like their chutzpah too much). It looks like this is now 26 reported of 31 disclosed for the DNP3 protocol and this is a different vulnerability than most of those previously reported by this team.

ICS-CERT reports that MatrikonOPC has produced a new version that mitigates this vulnerability but does not say that Crain-Sistrunk have verified the efficacy of that mitigation.

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability to effect a denial of service attack that would require a manual reboot of the system. The MatrikonOPC Security Notification that a successful exploit would “require expert knowledge of both the DNP3 protocol and an in-depth understanding of the vulnerability that exists in the affected versions of the MatrikonOPC Server for DNP3”.

MatrikonOPC published their notice on October 22^nd, over a month ago. There is no indication in the ICS-CERT advisory that this had been released on the US-CERT Secure Portal, so I wonder why it took so long for this advisory to be published? Could they have been trying to convince MatrikonOPC to allow Crain-Sistrunk to verify that their update worked?

Fall 2014 Unified Agenda – DHS

Last Friday the OMB’s Office of Information and Regulatory Affairs (OIRA) published the 2015 Fall Unified Agenda, what is supposed to be a comprehensive listing of regulations that the Executive Branch is working on.

DHS Unified Agenda

Last May I reported that there were there were 11 rulemaking actions being undertaken by the Department of Homeland Security that might be of specific interest to readers of this blog. This update only lists six of those rulemakings; one rulemaking (the ANSP) was moved up from the Long-Term Agenda. Those rulemakings include:

OS	Final Rule	Ammonium Nitrate Security Program	1601-AA52
OS	Proposed Rule	Petitions for Rulemaking, Amendment, or Repeal	1601-AA56
USCG	Proposed Rule	Updates to Maritime Security	1625-AB38
USCG	Final Rule Stage	Transportation Worker Identification Credential (TWIC); Card Reader Requirements	1625-AB21
TSA	Proposed Rule	Security Training for Surface Mode Employees	1652-AA55
TSA	Proposed Rule	Standardized Vetting, Adjudication, and Redress Services	1652-AA61

Current DHS Rulemakings of Interest

Long-Term Agenda

Three of the items from the 2014 Spring Agenda were moved to the Long Term Agenda. Typically this list is for those items that have been required to be completed either by Congress or the Courts, but that the Administration (in most cases successive administrations) have no intention to work on because of the complexity of the issues, the impossibility of reaching a consensus on how the regulations should work, or it just does not fit within the current political agenda. Those three rulemakings are:

OS	Chemical Facility Anti-Terrorism Standards (CFATS)	1601-AA69
USCG	Revision to Transportation Worker Identification Credential (TWIC) Requirements for Mariners	1625-AB80
TSA	Protection of Sensitive Security Information	1652-AA08

Long-Term DHS Rulemakings of Interest

It is unusual to see the CFATS update move off the Unified Agenda. DHS just finished taking public comments on the advanced notice of proposed rulemaking last month and this was the first of the rulemakings initiated under the President’s Improving Chemical Safety and Security Executive Order. This may reflect a decision that any further rulemaking at this time is counterproductive since we may likely to see a comprehensive chemical security bill pass either next month (remotely possible) or early in the next Congress. Any such legislation would require an entirely different rulemaking process.

Three items slipped completely off the agenda:

TSA	General Aviation Security and Other Aircraft Operator Security	1652-AA53
TSA	Freight Railroads and Passenger Railroads--Vulnerability Assessment and Security Plan	1652-AA56
OS	Classified National Security Information	1601-AA68

The first two have certainly disappeared because, while they were required by Congress, there is little appetite to take on the potentially regulated community. Since there is little indication that anyone currently sees general aviation of rail transportation as being actively threatened by terrorists and any effective security measures would be quite expensive, I think that the Administration is hoping to let these rulemaking activities die a quiet, unnoticed death.

Allowing the last one to pass quietly into that good night is more than a little odd. This rulemaking was based upon requirements set forth in the President’s Classified National Security Information Executive Order, so you would have expected this to be taken to completion by the Administration. It looks like this is following the same rule fate as the similar regulations governing sensitive but unclassified information. Just another case of an Administration’s being unable to follow through on their regulatory agenda.

Remote Exploit of Vulnerabilities

I was reading an article over on ThreatPost.com about this week’s ICS-CERT advisory for the Advantech WebAccess buffer overflow vulnerability and I was struck by the following statement that Dennis Fisher made:

“The vulnerability is mitigated by the fact that it cannot be triggered remotely.”

Now Dennis was clearly reading the ICS-CERT advisory that clearly said: “This vulnerability is not exploitable remotely”. Normally, I take the same approach when I write up my blog posts on ICS-CERT advisories, but this time I cheated and ignored the whole issue of remote exploitability. The reason was that Core Security labeled this vulnerability (at least in one place in their advisory) as remotely exploitable in their report on the vulnerability and I wanted to think about the whole issue of what is and isn’t remotely exploitable.

Remote: Yes and No

Let’s go back to that Core Security Advisory. In Section 2 they clearly state: “Remotely Exploitable: NO”. Down in Section 4, however, they clearly state:

“Advantech WebAccess is vulnerable to a Stack-based buffer overflow attack, which can be exploited by remote attackers to execute arbitrary code, by providing a malicious html file with specific parameters for an ActiveX component.”

Why the difference? Well the successful attack starts with an operator (or anyone with authorized access to the WebAccess application) opening a specifically designed html file. An attacker can only do this if they have system access. Thus: remotely exploitable; no.

It becomes remotely exploitable, however, when the attacker causes an authorized user to open that html. If that html code included providing remote access to the attacker, then it becomes remotely exploitable.

CAVEAT: Please remember, I have not coded in over a decade (fast approaching two) and I have never written code for anything as complicated as an HMI. So I cannot craft the exploit code described above and make no claim to be able to do so.

So what we have here is an attack that must be locally executed and may be remotely exploitable. Am I just playing with semantics or is this a real difference?

Remotely Executable

A remotely executable vulnerability would be one that an attacker could initiate and be in complete control of from a remote location. It requires some sort of remote access to the system; via a backdoor, stolen credentials or exploit of some other vulnerability. But once given that access the initiation of the actions necessary to exploit the vulnerability are completely under the control of the attacker.

In this case an authorized user has to be the one to initiate the sequence of events that starts the exploit of the vulnerability. Depending on the general level of vulnerability of a particular system this distinction may be a matter of terminology only. Some systems are so holely that anyone with a modicum of skill can become an authorized user, but that does not change the significance of this definition.

Systems that have reasonable degrees of access control would seem to have a reasonable level of protection against exploits of vulnerabilities that are not remotely executable. Having said that any number of studies on phishing or spear phishing attacks have shown that it is almost ridiculously easy to get someone to open a corrupted html file. And there are well known and well-practiced methods of convincing or coercing an insider to deliberately open such a file. These social engineering exploit tools make the ‘not remotely executable’ attack that much easier to remotely initiate.

I suppose that it is theoretically possible that a system could be constructed that a reasonable systems engineer would claim (while keeping a straight face) is immune to social engineering attacks. The people responsible for our nation’s various information systems protecting classified information would certainly like to be able to make that claim. Realistically though, I can’t think of anyone that would make such a claim for an industrial control system.

Make the Distinction

It would be nice if ICS-CERT and other vulnerability reporting agencies would make the distinction between remotely executable and remotely exploitable. Claiming that a vulnerability is not remotely exploitable when it clearly is misleads many people into thinking that their system is immune to a successful attack via that vulnerability.

For my blog, I will attempt to differentiate between the two levels of vulnerability whenever the data available to me allows me to make the differentiation.

Interesting Vulnerabilities Reported on US-CERT Secure Portal

This is  just a quick note that I have been informed that there are a couple of interesting control system related advisories that have been released on the US-CERT Secure Portal. These may/will make there way to the ICS-CERT page in the not-too-distant future, but it would help affected system owners if they could check them out now.

ICS-CERT Publishes Third Advantech Advisory

This morning the DHS ICS-CERT followed up yesterday’s publication of two alerts for Advantech products with an advisory that I described yesterday for a stack-based buffer overflow vulnerability in the WebAccess product.

ICS-CERT reports that a relatively unskilled attacker could exploit this vulnerability to execute arbitrary code or crash the system. ICS-CERT reports that there is no publicly available exploit for this vulnerability, but Core Security has clearly printed proof of concept code in their advisory [7:49 CST 11-23-14 Corrected link to go to Core Security site not ICS-CERT] for this vulnerability.

As I mentioned yesterday, ICS-CERT acknowledges that the latest version of WebAccess does not contain this vulnerability, but that updating to that version does not specifically remove the vulnerable file from the system. The owner/operator has to take specific action to remove that file that is not covered in the Advantech documentation, but has been identified by Core Security.

Waste Treatment Facility Fire

There have been a number of interesting news stories (here, here and here for instance) about an explosion and resulting fires at a Southern California waste treatment facility, Southern California Waste Water. It seems that a vacuum truck delivering what was supposed to be non-hazardous waste exploded at the site, spewing an as of yet unidentified chemical mixture on site that ignited various organic materials (including tires of a fire engine and boots of fire fighters; how ironic) on site.

The Business

Looking at the company’s web site it looks like they take in wastes from a variety of customers across the Southern California, de-water the material and prepare a solid material that can be used as a daily cover in selected solid waste disposal facilities. This is a somewhat unattractive, unexciting (on most occasions) and very necessary side of the chemical industry. The company relies on its customers to properly characterize the waste streams that are picked up by various trucking companies specializing in non-hazardous waste hauling.

The vacuum truck goes out to a customer facility and sucks up the waste material from treatment ponds, storage tanks and the like and then delivers it to the SCWW facility. From photographs from the various news articles it appears that the solids in the waste are separated from the bulk of the water (which then is probably sent to a water treatment works). The solids are then combined with other material to form a material that can be used to cover other debris and trash at a landfill.

The Accident

What apparently happened on Tuesday morning was that a large vacuum truck pulled into the facility that contained some material that was reacting chemically within the truck. We don’t know yet what the material was but it seems obvious from the pictures that some sort of gas and maybe heat was being generated by the reaction and the pressure built-up in the tank. While sitting at the facility apparently waiting to unload the pressure built up to the point where the back of the truck flew off and sprayed the contents all over the facility.

As the material dried in contact with air it formed a material that would ignite organic material that it came in contact with; organic materials like plastic, rubber or wood. From the news stories and photos it would seem that a fire truck pulled up on the scene, rolled into the liquid spill and at some point the tires caught on fire as did the boots of some of the fire fighters.

Not know fully what chemicals were involved, and having a river nearby where any fire-fighting run-off would go, the fire departments involved decided not to fight the various fires that sprung up on site and concentrate of confining the incident to the facility.

Injuries

There was a relatively minor injury to a truck driver from the initial explosion (I don’t really like that term in this context as it does not appear there was any fire involved initially, just a pressure build up and catastrophic failure of containment), but there are no real reports of serious chemical injuries on the scene.

Unfortunately, there were some complications at a local emergency room. Some people from the site showed up at the ER complaining about chemical exposure issues. Since they were apparently self-transported they were not decontaminated before arriving at the ER. As a result news reports indicate that there were 12 ER employees that were treated for ‘respiratory distress’. Since we don’t yet know what chemicals were involved these may have been caused by chemical exposure reactions or just a very typical and understandable psychological reaction of people to an unknown and unpleasant odor associated with a potential chemical hazard.

This points out a problem that all ER’s must prepare for when there is an incident at a nearby chemical facility. While we expect the local hazmat team and ambulance teams to ensure that transported individuals are decontaminated before leaving the scene, people that self-transport are usually not so careful. It would be a good idea to set up a triage area outside with decontamination equipment and appropriate PPE for the decon team to avoid contaminating the ER when a chemical incident takes place in the local area.

Investigation On-Going

The investigation into this incident is on-going with local agencies, the EPA and OSHA probably being involved. Since there were no deaths or serious injuries reported to date, it is unlikely that the Chemical Safety Board will be involved.

A major focus of the investigation will certainly be the facility from which the truck load of waste originated. Also sure to be looked at will be the clean out procedure used on that truck before the last load was picked up to see if cross contamination of waste streams may have been the culprit.

ICS-CERT Publishes Alerts for 2 of 3 Reported Advantech Vulnerabilities

Today the DHS ICS-CERT published alerts for two different Advantech products; EKI-6340 and AdamView. Adam Greenberg at SCMagazine.com reports that there is the same researchers also reported a vulnerability in WebView.

EKI-6340 Alert

This alert addresses a command injection vulnerability that was discovered by Facundo Pantaleo and Flavio Cangini of Core Security Engineering Team. The disclosure was coordinated thru ICS-CERT but when Advantech announced that they would not be fixing the vulnerability since the product would be discontinued next year, Core Security published the vulnerability on their web site.

The Core Security notice also includes suggested fixes for the vulnerability. Too bad Core Security can’t charge for Advantech’s laziness (considering the ease of the fix that could have been announced by Advantech).

AdamView Alert

This alert addresses a buffer overflow vulnerability that was discovered by Daniel Kazimirow and Fernando Paez from Core Security Engineering Team. The disclosure was coordinated thru ICS-CERT but Advantech has not supported this product “for a while” and will not fix the vulnerability. Unfortunately, outdated products do not usually get fixed.

Core Security notes that since this is a client-side vulnerability there are only limited fixes that can applied to mitigate this vulnerability.

WebView Vulnerability

The Core Security Team also reported a stack-based buffer overflow vulnerability in the Advantech WebView application. I suspect that ICS-CERT has not issued an advisory on this vulnerability since they may be working to get Advantech to fix the fix found in version 8.0 that Core Security says does not correct the vulnerability when applied to existing systems.

It seems that the vulnerable file "webeye.ocx" (version 1.0.1.35) is not in the newest version, but when a system with an earlier version is upgraded the existing webeye.ocx is not removed from the system, so the vulnerability remains.

Not So Coordinated Disclosure

Now I fully understand (and support) the Core Security Team publication of the first two vulnerabilities since the vendor told ICS-CERT that they would not be issuing a fix. That makes the vulnerability fair game for publication in my opinion, especially when Core Security stepped up and suggested mitigation measures.

The question on the third is a tad bit more vague. Core Security reports that they notified ICS-
CERT on October 1^st about the vulnerability (actually all three vulnerabilities) and then advised ICS-CERT that the fix Advantech reported did not actual fix existing system vulnerabilities on October 21^st. Their advisory reports that ICS-CERT notified them about why it did not work on October 27^th, but do not indicate that Advantech refused to revise the fix.

I would hope that ICS-CERT was working with Advantech to get them to revise the Version 8.0 fix so that it did remove and/or modify the exiting file. Lacking a specific notice that Advantech refused to fix the fix I think that a responsible researcher (in my definition) would give ICS-CERT a little more than just 23 days to get a recalcitrant vendor to see the error of their ways. But, that is just my opinion.

Bills Introduced – 11-17-14

Both the House and Senate are back in town for week two of the lame duck session. Seventeen bills were introduced yesterday including one that may be of specific interest to readers of this blog:

S 2934 - A bill to prohibit trespassing on critical infrastructure used in or affecting interstate commerce to commit a criminal offense. Sponsor Sen. Schumer, Charles E. [D-NY].

This bill was publicized by Schumer during the election hiatus as a bill targeted at preventing the recent spate of publicity stunts involving bridges and other landmarks in New York City. We will have to wait to see what the bill actually says to be sure, but this sounds like an attempt to stifle free speech. Having said that, this could be used as a tool to federally prosecute recon actions that would be a precursor to a terrorist attack; details will make the difference.

NOTE: This bill has little chance of being considered in the lame duck session. It will be interesting to see if/when it is re-introduced in the 114^th Congress.

Reader Comments 11-17-14

It is rare for me to get a reader interchange in the comments section of this blog and rarer still for those comments to be about my politics. But, an anonymous reader (apparently the owner of a small CFATS covered chemical facility) responded to my Sunday post about the chemical accident this weekend in Texas. Actually I think that maybe his comments were to/about me and were merely connected to the most recent blog. In any case, he noted:

“People like you have made America a regulatory nightmare. You're an apologist for a CFR police state, and when confronted about this you drop fear bombs to justify your point of view.”

He then goes on to complain about “Soviet-style bureaucrat from DHS” and the unconstitutionality of the CFATS program under the 4^th, 5^th, 9^th, and 10^th Amendments. I have some objections to both claims. First and foremost, the CFATS inspectors that I have talked with and corresponded with were not bureaucrats in any form, but were rather hardworking, caring and professionals who were primarily interested in helping facility owners keep their facilities safe from terrorist attack in the most efficient manner possible. There may be bureaucrats in ISCD Headquarters (though the ones that I have met certainly do not meet the classical soviet stereotype), the folks in the field are so far from that description to bear comparison by the most near-sighted citizen.

As to the second, [STADARD LEGAL CAVEAT: I AM NOT A LAWYER] that does not bear close scrutiny either:

4^th Amendment – Search and Siesure – The Supreme Court has often held that regulatory inspections do not constitute searches.

5^th Amendment – Self-incrimination – CFATS regulations are not criminal in nature so there can be no self-incrimination. Upheld in numerous instances for all sorts of regulatory programs.

9^th Amendment – Rights not enumerated are protected – See next comment.

10^th Amendment – States rights. Commerce clause and common defense clause of the constitution both provide the legal framework for the CFATS program.

The second anonymous commenter (with the nom de chem of Common Sense from the South) was rather blunt in responding to the first commenter and certainly more personally directed than I would have done. I do appreciate the characterization of this blog as “a respected professional blog”.

‘Friendly’ Toxic Chemicals

Yesterday 4 employees at the LaPorte, TX DuPont plant died, apparently as a result of exposure to methyl mercaptan (CH3SH, AKA ethanethiol, or MeSH); another employee was taken to the hospital for exposure. News reports (here and here) indicate that they were responding to a leak due to a malfunctioning valve. The Chemical Safety Board is deploying a team to initiate an investigation.

Methyl Mercaptan Standards

MeSH is a toxic chemical that is widely used to ‘odorize’ natural gas and propane. It has a strong, easily detectable odor that can be added to odorless flammable gasses to make leaks more easily detectable. It is this very strong odor that makes it a ‘friendly’ toxic gas. With a human detection limit somewhere in the neighborhood of 1 ppb, very small amounts of this material are very easily detectable.

There are some conflicts between the OSHA and NIOSH short term exposure limits for this chemical (10 ppm and 0.5 ppm respectively), but all government sources agree with the current IDLH (Immediately Dangerous to Life and Health) limit of 150 ppm. What is not readily available is the level at which the human gag reflex makes it uncomfortable to be around the odor; almost certainly below 10 ppm. Thus anyone approaching a leak site without personal protective equipment (PPE) is almost certain to turn around and leave the area well before the 150 ppm IDLH is reached.

Avoiding Deadly MeSH Concentrations

Which leaves the question as to how someone could enter an area with lethal concentrations of MeSH? One way (speculation on my part, the CSB will determine the actual root cause) would be for the responders to be wearing cartridge respirators (the most common kind of respirator used in the chemical industry). Those cartridges are typically activated charcoal. According to a 2002 article by Svetlana Bashkova, et. al., the three types of adsorbents that they investigated all had break through times greater than 100 minutes. This should be more than long enough for an initial look at the situation to determine if an easy fix (close the valve, for instance) was possible.

Of course, if anyone knew or suspected that the concentration of MeSH was 150 ppm or greater, the use of a cartridge respirator should not have been authorized; any respirator failure would have placed the wearer in a potentially deadly situation. A supplied air respirator should be required in those circumstances.

I have long advocated in this blog that any CFATS covered facility include toxic gas detectors at any site with a toxic release hazard DHS chemical of interest (COI) on site. These detectors would be deployed as an array of gas detectors on (and off) site as part of their immediate response plan for their site security plan. This would allow responders to know where the toxic gas cloud was heading and determine what level of protection would be needed for security and safety responders.

EPA vs DHS Regulations

Looking at this incident I ran across an interesting discrepancy between how EPA and DHS look at methyl mercaptan. The EPA lists methyl mercaptan as a toxic chemical under their Chemical Accident Protection regulations (and that include the Risk Management Plan regulations), but DHS lists it as a flammable release COI under the CFATS program. It is certainly a flammable liquid (flammable gas at temperatures above 45°F) and apparently DHS figures that the risk from an explosion of a methyl mercaptan storage tank attack is greater than the risk from a toxic release from the same successful attack. EPA, on the other hand, is more concerned with the toxic release.

As DHS looks at updating their COI list (Appendix A to 6 CFR Part 27) they might want to reconsider the either/or dichotomy of this and other flammable toxic chemicals and list them under both hazards. This would ensure that chemical security efforts deal with both concerns. Similarly, EPA should consider also listing the flammability characteristics in 40 CFR Part 68 so that safety efforts are formally required to be targeted at both characteristics.

Moving Forward

We should start to hear some informal information from CSB and the other investigating bodies in the weeks to come. The formal determination of the root cause of the deaths will, unfortunately be months or years in coming.

Bills Introduced – 11-14-14

The Senate was already on the way home for the weekend but the House introduced 18 bills yesterday. Only two of those may be of specific interest to readers of this blog:

HR 5712 - To authorize the Private Sector Office of the Department of Homeland Security to improve private sector engagement in protecting the homeland, and for other purposes. Sponsor - Rep. Clawson, Curt [R-FL-19].

HJ Rest 129 - Appointing the day for the convening of the first session of the One Hundred Fourteenth Congress. Sponsor - Rep. McCarthy, Kevin [R-CA-23].

The current title of HR 5712 is written broad enough to cover a number of potentially interesting possibilities. I suspect that this may be the last mention of the bill in this blog, however.

HJ Res 129 is a procedural resolution that was introduced and passed yesterday in the House. It would set January 6^th as the first date for the new Congress. Typically the Senate will meet to swear in new members and then adjourn until the State-of-the-Union. The House will meet that day (a Wednesday) and have a couple of additional days in session taking care of mainly procedural matters before heading back home.

Bills Introduced – 11-13-14

Yesterday was the second day of the lame duck session and all sorts of stuff has to be addressed by this Congress; including the FY 2015 spending bill. With that said, there were 22 bills introduced yesterday including just one that may be of specific interest to readers of this blog:

HR 5705 To modify certain provisions relating to the Propane Education and Research Council. Rep. Latta, Robert E. [R-OH]

According to a press release from Latta’s office this bill will modify the Propane Education and Research Act (15 USC 6401 et seq) to help the propane industry avoid pricing spikes and to avoid misinterpretation of the training program requirements of the original act by the Department of Commerce. It will be interesting to see what other things may be included.

NOTE: Readers will note that the link to the bill no longer goes to the old Thomas.LOC.gov web site. That site is being phased out and the new Congress.gov site will be the source of information. It looks like the new site is slower to post bills, so these ‘Bills Introduced’ posts will be coming out later in the day than normal. For those that like the old Thomas.LOC site it will be up through at least a portion of next year.

NASA Announces PNT Advisory Board Meeting – 12-10-14

Today NASA published a meeting announcement in the Federal Register (79 FR 67469) for the National Space-Based Positioning, Navigation and Timing (PNT) Advisory Board in Washington, DC on December 10^th, 2014. Readers of this blog may be interested in this meeting because the GPS system is used for timing coordination in many control systems.

The agenda includes:

• Examine emerging trends and requirements for PNT services in U.S. and international arenas through PNT Board technical assessments.

• Update on U.S. Space-Based Positioning, Navigation and Timing (PNT) Policy and Global Positioning System (GPS) modernization.

• Prioritize current and planned GPS capabilities and services while assessing future PNT architecture alternatives with a focus on affordability.

• Examine methods in which to Protect, Toughen, and Augment (PTA) access to GPS/Global Navigation Satellite System (GNSS) services in key domains for multiple user sectors.

• Assess economic impacts of GPS on the United States and in select international regions, with a consideration towards effects of potential PNT service disruptions if radio spectrum interference is introduced.

• Explore opportunities for enhancing the interoperability of GPS with other emerging international GNSS.

The meeting is open to the public and no advanced registration is required, but there is limited seating. There are no indications that the meeting will be web-cast or be made available via other electronic means; odd from a technology based organization like NASA.

ICS-CERT Publishes Rockwell Advisory

Today (a Federal Holiday in case you didn’t notice) the DHS ICS-CERT published an advisory for twin ActiveX component vulnerabilities in the Rockwell Connected Components Workbench (CCW) application; actually the way the advisory is written and CVE’d it is a single vulnerability in two separate Active X components. The vulnerability was reported by Andrea Micalizzi (working through ZDI) in a coordinated disclosure. Rockwell has produced a new software version that mitigates the vulnerability and apparently self-certified its efficacy instead of inviting rgod (okay nom de hacks are not necessarily classy) to do so.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit this vulnerability to execute arbitrary code.

There are a bunch of minor oddities about this advisory:

1. It was published on Veterans Day. I was going to commend ICS-CERT for working on a holiday to get this information out, but it had been previously released on the US-CERT Secure Portal earlier in the month so another day would not have made an appreciable difference.
2. The advisory does not name the two ActiveX components and the Rockwell information is locked in a customer only section of their web site.
3. Looking at the ZDI site it looks like these ActiveX components were identified/reported on different days under different ZDI file numbers (ZDI-CAN-2417 and ZDI-CAN-2418). I can’t tell for sure because it is still listed on the “Upcoming Advisories” page.
4. ICS-CERT is very careful not report that the two unnamed ActiveX components do not have to be open or running for their vulnerability to be exploited.

From the way things are written and not said, it sounds like these ActiveX components were from an outside source. That might mean that they are in other vendor systems as well. Having the component names might make it easier for other vendors to search for and repair the vulnerabilities in their products.

BTW: ICS-CERT missed yesterday’s announcement by Siemens ProductCERT of their Poodle vulnerability. This was particularly interesting because of how difficult the SSL3 vulnerability would reportedly be to exploit and Siemens was reporting mitigation measures anyway (deactivate SSL and use TLS instead).

ICS-CERT Publishes ABB Robot Advisory

This afternoon the DHS ICS-CERT published an advisory for a dll hijack vulnerability in the ABB RobotStudio and Test Signal Viewer applications. This vulnerability was reported by Ivan Sanchez of WiseSecurity Team in a coordinated disclosure. ABB has produced new versions of the affected applications and ICS-CERT reports that Sanchez has validated the efficacy of the fix.

ICS-CERT reports that a moderately skilled attacker with local access could exploit this vulnerability to execute arbitrary code.

ABB reports (in separate advisories for RobotStudio and Test Signal Viewer; both .PDF files) that the vulnerability is in a third-party component of the applications. The question this raises is what third-party component and who else uses the same component with the same vulnerability.

DHS Publishes CFATS Update for October

Today the DHS Infrastructure Security Compliance Division (ISCD) published their CFATS Update for the month of October. As we have been seeing for the last year or so there is a steady increase in the number of CFATS facilities that have an authorized or approved Site Security Plan (SSP).

October’s rate is slower than August and September but that almost certainly reflects the variability of the facilities that are having their programs evaluated. Each facility has a unique security situation and plan that must be evaluated on its own merits; some facilities take more time than others to properly evaluate.

An interesting note this month; we have stopped the steady decline in the number of facilities covered by the CFATS program that we have been seeing since November. We actually had 7 more facilities on November 1^st than we did on October 1^st. Still no information about what is driving the changes in numbers. This month we can positively say that there were more new facilities added than dropped off, but still no indication of how many actually dropped off or why.

ISCD is still not telling us anything about the number of facilities that have undergone compliance inspections or how many have passed or failed those inspections. That will be the next item of Congressional interest.