Wednesday, November 30, 2011

Large Propane Tanks – Security Issues

I received an interesting email from a web searcher, David Giacalone, who found my blog post on protection of large propane tanks from October 2007. He was looking for information supporting his active opposition of to the installation (completed) of a large (30,000 gal) propane tank in a local neighborhood. The current stage of the fight includes opposing the issuance of a ‘Certificate of Occupancy’, typically the last regulatory hurdle before tanks such as this are filled.

I won’t go into all of the details of the basis of David’s opposition to this propane storage tank; he has an extensive blog post on the matter. And I certainly don’t want to get involved in a discussion about local zoning ordinances or even State fire codes (okay, sometimes I do, but not in this case). There are, however a couple of issues that do bear discussion on this blog; the first dealing with propane limits for COI determination and the second on when applications for Top Screens should be made. Finally there is the issue of adequate security for such tanks.

Propane COI

Propane is a curious DHS Chemical of Interest (COI) for a number of reasons. First as a flammable release COI it has a much larger Screening Threshold Quantity (STQ) than other similar COI (I’ll forgo that standard rant for now); set at 60,000 lbs vs the normal 10,000 lbs. This was specifically done to avoid coverage of a huge number propane storage tanks; likely outstripping the number of other CFATS covered facilities combined.

The other problem is that people don’t normally refer to ‘pounds’ of propane, it is usually referred to in ‘gallons’. This causes some confusion because the number of pounds of propane in a gallon is dependent on the pressure in the tank; ranging from 2.001 kg/m3 @ 1013 mbar to 581 kg/m3 as a liquid (high pressure).

According to David’s blog, the company that owns this tank contacted DHS (presumably ISCD) about whether this tank would be covered under CFATS and was told no. David later contacted the ISCD Help Desk and they confirmed that a 30,000 gallon tank would hold considerably more than 60,000 lbs and would require a Top Screen submission. I would assume that the discrepancy between the two DHS responses was due to the confusion between gallons and pounds. That discrepancy has apparently been resolved.

Finally we must remember that there are two different security issues with a release of propane, fire and explosions. A non-catastrophic rupture of a propane tank (a reasonable size hole) results in a high-pressure jet of flammable gas coming out of the hole. Nearby ignition sources or even internal static electric discharges will cause this jet to ignite and produce a visually stunning torch. As long as there are no combustible materials within reach of that torch, this is simply (only a slight overstatement) a dangerous yet controllable situation. The fire is typically allowed to consume all of the available propane while keeping the tank is kept cool enough with water sprays that it doesn’t catastrophically fail.

An explosion is much more difficult to cause, but it would have much further reaching consequences. A significant portion of the contents of the tank must be released into the atmosphere under the proper environmental conditions without creating the torch described above. This is required to create the gas cloud necessary for a fuel-air explosion. You need a large enough release to create a gas cloud of sufficient size to create an explosion large enough to create a larger secondary explosion when the remainder of the tank’s content is released catastrophically.

In short, you have to be really skilled or very lucky (from the attacker’s point of view) to cause a propane tank explosion. They do happen from accidental releases from time-to-time, but they really are very rare. There are just too many things that have to go right (wrong?) for the tank to explode.

DHS hasn’t discussed this in public, for obvious reasons, but one would assume that they are more concerned with the latter release situation unless there are significant stores of other COI that could be affected by the torch effect. A propane torch, for example, would be an excellent way to force a catastrophic chlorine release.

When to File a Top-Screen

The CFATS regulations are quite clear. Once a facility has one or more COI on site at or above the STQ for that COI, they have 60-days to file a Top Screen submission via the on-line Chemical Security Assessment Tool (CSAT). Only after that Top Screen is submitted can DHS make an interim determination whether or not that facility will be considered a high-risk chemical facility that is covered under the CFATS program.

From a regulatory perspective this certainly makes a great deal of sense; from a business perspective, not so much. The costs associated with the security requirements for a CFATS covered facility could have a serious impact on the profitability of a company. It would certainly be nice to know if those costs would be required in advance of constructing or upgrading the facility.

Even if one were to call ISCD and ask about the potential coverage of a new facility or even a facility adding a COI to their inventory, the most that the Help Desk, or even the Director, could really tell one is whether or not a Top Screen would be required. And as I described above, that is really cut and dried.

The evaluation of the Top Screen is a complex undertaking, looking at both the COI, the facility in which it is used and the surrounding community. That is one of the reasons that the Top Screen Tool is such a lengthy questionnaire.

Now I suppose that a company could register with DHS and submit a Top Screen for a planned facility; there is nothing in the regulation that would prohibit that. There would be some complications if the facility decided not to go ahead with their COI plans, but those could be worked out (Chime in anytime ISCD if I’m getting anything wrong here). The results from the Top Screen would tell the company that the facility would be covered by CFATS, but it wouldn’t tell them what security measures would be required. As the current CFATS covered facilities are discovering that it is still a long, long road to travel before the security requirements (and resultant costs) become really clear.

As a final comment on Top Screens, I would like to note and suggest that it would certainly be helpful to both the business community and ISCD if there were provisions for filing prospective Top Screens. The form and evaluation would be essentially the same, there would just be the clear understanding that the COI in question was not yet (and may not ever be) on site at the facility.

Propane Tank Security

Now we finally get to the meat of the reason that David contacted me in the first place. What is adequate security for a large propane tank? David sent me a couple of pictures of the tank currently in place in Duanesburg, NY (those and others are posted on his blog) and the tank in question clearly does not meet the security requirements set forth in the Risk-Based Performance Standards guidance document for a CFATS covered facility.

NOTE: The governing phrase in that last sentence is “for a CFATS covered facility”. Remember, CFATS is a counter-terrorism program. If the facility is not at high-risk of a potential terrorist attack (ie: not covered under CFATS), then the security processes and equipment required for a CFATS facility are not necessary. The remaining discussion only applies to a CFATS covered facility.

There are no perimeter barriers, entrance gates, etc protecting the tank. The few fences around auxiliary equipment are too short to be an impediment to any non-geriatric attackers. There is nothing here to ‘deter, detect or delay’ a terrorist attack on this tank.

I am certainly not going to try to engineer a security system for a propane tank (there are more than enough security integrators around willing and more experienced than I to handle that task), but clearly a barrier fence with controlled entrances is a primary requirement. Given the nature of the ‘target’ some sort of protection against vehicle borne improvised explosive devices (VBIED) needs to be in place. Some sort of protection against direct fire weapons would also be a good thing to have (though let’s be honest, a bullet from standard hunting rifle or AK47 is probably not going to penetrate the steel shell of a high-pressure storage-tank) though just hiding the tank behind a screen from the road would probably suffice.

There is, of course, much more that would go into such a security program; see the lengthy RBPS guidance document. More importantly, contact a good security consultant; one that has worked with this specific DHS program. And then wend your way through the CFATS gauntlet.

Tuesday, November 29, 2011

ICS-CERT Publishes Two Luigi Vulns – Old and New

Today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published two reports on two Luigi reported vulnerabilities. The first is an alert for a new vulnerability MICROSYS, spol. sr.o. PROMOTIC, a Czech SCADA HMI. The second is an update on an older advisory on the GE Proficy system.


The PROMOTIC alert is a bit unusual in that it does not involve a remotely exploitable vulnerability. It is a use-after-free vulnerability that requires the loading of a ‘specially crafted’ project file. That file causes the program to terminate allowing an opportunity to execute code after the allocated resources are freed up.

Luigi provides detailed information on his web page about this vulnerability.

BTW: Luigi was kind enough to post a comment to yesterday’s ICS-CERT related post providing a link to the Optima vulnerability information on his web page.

GE Proficy Update

ICS-CERT updated their GE Proficy Historian advisory simply to provide notice that Luigi was the researcher who initially discovered this vulnerability. Since this was technically a coordinated disclosure that Luigi worked through the Zero Day Intiative (ZDI), it is appropriate that he be given appropriate credit.

Looking at the ZDI web site for this vulnerability, it looks like they gave Luigi credit all along, so it seems odd that the folks at ICS-CERT overlooked giving him credit for this long. Oh well, better late than never…


Today the Pipeline and Hazardous Material Safety Administration (PHMSA) published a notice of proposed rulemaking (NPRM) in the Federal Register (76 FR 73570-73581) proposing to make a series of miscellaneous changes to the pipeline safety regulations. According to the summary of the NPRM the changes would “correct errors, address inconsistencies, and respond to rulemaking petitions” (76 FR 73570).

The specific areas to be addressed in the NPRM include:

Transportation of Pipe - §192.65

Threading Copper Pipe - §192.279

Offshore Pipeline Condition Reports - §§191.l27 and 195.57

National Pipeline Mapping System (various sections)

Welders vs. Welding Operators (various sections)

Components Fabricated by Welding - §§192.153 and 192.165

Odorization of Gas - §192.625                                                                               

Editorial Amendments (various sections)

Public comments on these proposed changes are being solicited by PHMSA. Comments may be submitted to the Federal eRulemaking Portal (; Docket # PHMSA-2010-0026). Comments must be posted by February 3, 2012.

Monday, November 28, 2011

Three New Luigi Vulnerabilities and a New ICS-CERT Advisory

Today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published three new Luigi vulnerability alerts and an advisory for the Schneider Electric Vijeo Historian. Luigi (as one would almost expect) would be the first researcher acknowledged under the recently announced revised ICS-CERT policy concerning the identification of researchers who do not coordinate their vulnerability disclosures. Two of the Luigi vulnerability reports are for Siemen’s systems.

Siemens Vulnerabilities

Luigi identified four separate vulnerabilities in the Siemens Automation License Manager. The four vulnerabilities are identified in the ICS-CERT alert as:

• Buffer Overflow;
• Exception;
• NULL Pointer; and
• Memory Write

All four are reportedly remotely exploitable and may be used for DOS attacks. The first and last may allow for remote execution of arbitrary code. Proof-of-concept code is publicly available. Further details are available on BugTraq. ICS-CERT recommends their standard system isolation techniques as interim measures pending development of actual Siemens mitigation measures.

Three additional vulnerabilities were identified in the Siemens SIMATIC WinCC Flexible Runtime system. Those three vulnerabilities are:

• Stack Overflow;
• Directory Traversal; and
• Memory Read Access.

Again, all three are remotely exploitable with POC code published. Only the last can be used for a DOS attack. The first could allow remote arbitrary code execution and the second could allow an attacker to read, write or delete access to the system. Again, Luigi has made further details available on BugTraq.

BTW: ICS-CERT may have decided to acknowledge the un-coordinating researchers, but they did not provide links to either the BugTraq reports of Luigi’s web page for further information on  the vulnerabilities.

Optima APIFTP Server Vulnerabilities

Luigi identified two vulnerabilities in the Optima APIFTP Server system. They are a null  pointer vulnerability and an endless loop hole (okay, I apologize for the play on words, almost). The POC code published for these also would allow for remote execution of a DOS attack and arbitrary code execution.

I could not find this report on BugTraq or Luigi’s home page.

Schneider Electric Historian Vulnerabilities

ICS-CERT is reporting that researcher Kuang-Chun Hung of the Security Research and Service InstituteInformation and Communication Security Technology Center (ICST) has reported, and coordinated the disclosure of, four separate vulnerabilities in three data historian products produced by Schneider Electric. The vulnerabilities include:

• Two separate buffer overflows;
• Cross-site scripting; and
• Directory Traversal

The buffer overflows would allow a low-skilled attacker to execute a DOS attack or execute arbitrary code. The cross-site scripting vulnerability would allow a similarly skilled attacker to inject and arbitrary web script. Finally the directory traversal vulnerability would allow the attacker to read arbitrary files. All are remotely executable and the first three would require a social engineering attack.

Schneider Electric has developed a patch that has been evaluated by ICST and found to provide appropriate mitigation for these vulnerabilities.

Cyber Forensics

The debate about the Illinois Water Hack continued this weekend with two different security experts pointing out that DHS and the FBI did not say that there wasn’t a hack, just that they couldn’t find evidence of a hack. The difference is not that subtle and according to these two unrelated authors may be more than just political correctness.

Lack of Forensics

Joe Weiss, in a short posting on his blog over at, said it most plainly:

The point of the [DHS ICSB-11-327-01.pdf] statement was "no evidence". That means not only could they not confirm a cyber intrusion occurred, they could not confirm a cyber intrusion did not occur.

He goes on to point out that there is no data log for communications with the disabled pump so that there is no way to determine with certainty if the system unnecessarily cycled the pump by command (either a hack or a bug) or if there was some other fault in the system that caused the pump to fail.

Now I have never worked with the control system logs that Joe is talking about, but I have worked extensively with data historians. Our control system had literally thousands of potential data point available. This was simple stuff like valve states (open, closed, moving) and measurement data (temperature, pressure). We had to select which data points we wanted the historian to record because of the memory limitations in our system. Every time we upgraded our control system the available memory expanded as did the number of points that we could monitor; there was always more data available than was recordable.

If you overlay that complexity with a log of the intra-system commands [both within the system itself, with the HMI and any remote access] and data exchanges that occur in a modern control system and I would assume that one would have an even greater problem. Even with today’s cheap memory, a complex control system just produces too much data to record it all.

What to Record

Jake Brodsky in a lengthy comment (he unfairly labels it a ‘rant’) this weekend over on the SCADASEC list (at, registration required) addresses this issue with a high-level summary of the type of information that control system logs should contain to allow for at least some level of forensic analysis of control system anomalies. He doesn’t provide a point-by-point analysis (impossible since it would be different for each systems and installation) but gives a general description of the types of information that should be tracked.

It would be nice if regulatory agencies would specify some minimum level of forensic data recording for systems under their purview. I think NERC CIPs attempt this at some level, but I am not familiar enough with those standards to really comment on their forensic recording status. The CFATS program is stuck with their ‘no requirement’ mandate from Congress. The closest they come is stating:

“Recognizing and logging events and incidents is a critical component of network monitoring.” (Risk-Based Performance Standards guidance document, pg 75)

The EPA is even less helpful to water systems since their mandate from Congress is only to require vulnerability assessments and action plans.

Of course, any forensics data recording requirement would have to be risk based to be effective. It certainly would not make sense to require a blending operation without hazardous materials or DHS chemicals of interest (COI) on site to have the same level of recording as a major oil refinery. Nor for a water system with just 2000 customers to maintain the same records as say the Long Beach, CA water system serving millions.

Cannot Prove a Negative

Of course, we have to remember that it is not possible to prove a negative. If the affected water system in Illinois had had extensive forensic data recorded, DHS and the FBI would still have had to say that ‘no evidence has been found’ rather than ‘there was no cyber-intrusion’. With adequate data you might be able to prove (and even maybe prosecute suspects) that an attack has occurred, but you can never be sure that someone hasn’t come up with a new vulnerability to exploit that you weren’t watching.

One last point to remember; in this case there was some sort of data logging, the communications with the system from a Russian IP was clearly recorded and widely reported. I would almost be willing to bet that it was this data point that caused the Illinois Terrorism & Intelligence
Center (the name for the State fusion center for those who are confused about who the initial report came from) analysts to decide that it was a cyber-attack that needed reporting.

Sunday, November 27, 2011

Control Systems in Odd Places

As a process chemist when someone mentions industrial control systems I first think of the systems at a chemical manufacturing facility, then I may think about the electric grid, but until recently I didn’t think about much beyond that. Recent stories about hacks of control systems in cars and even medical devices have expanded that. Then I ran across a blog post at that expanded that world of control systems in a new direction of potential interest to the chemical security community (and the ICS security community, of course).

Data Center Control Systems

The author, Eric Gallant, reminds us that data centers, those massive banks of servers and data storage devices that are so important to modern society, are not just computer systems. Data centers require lots of support structure; power switching, backup power systems, cooling, air filtration and access control. These systems all work together in an integrated manner because of industrial control systems.

Eric points out in his article that there are lots of reasons that various people might like to shut down such data centers. Since a successful attack on the support systems could effectively disrupt such a facility for quite some time, datacenter engineers need to be concerned about the security of their support control systems.

Corporate Data Centers

While it appears that Eric’s target audience is mainly engineers at the very large data centers supporting internet firms and banks, much of what he talks about would also be applicable for the smaller data centers maintained by large chemical manufacturing corporations and to a lesser extent the server rooms maintained at most modern chemical facilities.

A disruption of the corporate networks, with their interties to SCADA networks and various security related networks, could make high-risk chemical facilities and their control systems more vulnerable during the recovery period. With the inevitable emphasis on rapid recovery, there will be an increase in the number of people with physical access to the network infrastructure, increasing the potential for unauthorized access to the network.

Security Data Centers

With the increasing use of electronic monitoring and access control devices we are inevitably seeing an increase in the number and size of security data centers. With the increase in complexity of these systems we are seeing more and more facilities contracting the monitoring functions out to off-site security companies with centralized security data centers supporting multiple facilities. The economies of scale make this inevitable.

While these security data centers house a slightly different mixture of electronic hardware, they still require much of the same support infrastructure controlled by the same types of ICS systems. A successful attack on these control systems would effectively shut down most modern security services provided by such companies. This would certainly make the supported facilities, including high risk chemical facilities, more susceptible to attack.

Security Manager’s Concerns

Security managers at high risk chemical facilities that are served by either type of off-site data center needs to ask pertinent questions about the security provided for those centers. While the security of the data is important, the security of the control systems supporting those centers also needs to be addressed.

For on-site data centers, the control systems for these centers need to receive the same cybersecurity level of attention provided for the control systems that operate the chemical manufacturing controls for the facility.

Saturday, November 26, 2011

New Flu Strain

Just because there aren’t enough hackers, cyber-vulnerabilities, and just plain terrorists to keep security managers awake at night, according to an blog at the CDC has announced that a new strain of our favorite wet-ware virus has been reported in circulation. The flu bug is always coming up with new ways to cause problems; due in no small part to it plagiaristic attitude towards DNA.

Flu cognoscenti keep track of the basic strains of the flu with a four character code HxNy. Most will remember the H5N1 bird flu concern of a couple of years back (it’s still there floating around killing hundreds of people every year, small potatoes for the flu). Then there was the H1N1 pandemic of just two years ago (a much higher death rate, but not anywhere near the 1917 flu pandemic).

New H3N2 Strain

The new strain of potential concern is a variant of the H3N2 virus that has been found in pigs in North America. Apparently some pig had the temerity to become infected with both the H3N2 and the H1N1 at the same time and the two strains of viruses exchanged gene segments. Typically animal strains of the flu don’t transmit well to humans nor do they make the human-to-human transfer that is necessary for a wide spread outbreak.

Earlier this month this new strain of H3N2 (technically S-OtrH3N2) apparently made the transition to a transmissible form of the bug. Three children in Iowa came down with the bug after appearing at the same event (their only link). More importantly, none of the kids or their families has had any contact with live pigs.

CDC’s Concerns

Now three patients is certainly a far distance away from an epidemic and even further from a pandemic. What has the CDC concerned, however, is that the current flu vaccine did not include this strain (they made the choice of strains for this winter’s vaccine last spring) and it doesn’t appear likely that the vaccine will be terribly effective against this new strain, particularly in children.

To raise concerns further, two of the common anti-viral medications used for treatment of the flu, rimantidine and amantadine are not effective with this strain, though Tamiflu and Relenza both appear to be effective. The folks at the CDC would prefer not to use those two drugs as they don’t want the bugs to build up immunity to these two powerful antivirals.

Flu and Security

Both human resources and security management need to keep an eye on the progress of the flu season in general and new strains specifically. Both are going to find it difficult to keep up minimum staffing levels if large numbers of people are out with the flu. Contingency plans need to be made to deal with the potential shortages of personnel. And remember, while manufacturing can reduce shifts or work days, the security will have to be there regardless.

Friday, November 25, 2011

Russian Hack Explained

On Wednesday I reported on the DHS ICS-CERT bulletin concerning the reported hack of an Illinois water system that apparently wasn’t a hack. The bulletin made very clear that the ICS-CERT flyaway team could find no evidence of a hack of the control system. There was an odd statement in that bulletin, however, relating the Russian connection. It stated that:

“In addition, DHS and the FBI have concluded that there was no malicious or unauthorized traffic from Russia or any foreign entities, as previously reported.”

While we still haven’t seen the Illinois Statewide Terrorism & Intelligence Center (ISTIC) report that started this discussion, Joe Weis was very clear that the copy of the For Official Use Only (FOUO) that he saw clearly indicated that the cyber-attack originated from a Russian IP. Joe specifically reported that;

The IP address of the attacker was traced back to Russia.

Looking at the two statements it seems clear that there must have been access of the system from an IP address in Russia. An article today on explained how that happens; according to the article an unnamed source reported that a contractor “who had remote access to the computer system, was in Russia on personal business”. That would explain how a Russian IP address showed up in communications logs of the control system.

Now it seems clear that an cyber investigator that was less than proficient in control system forensics (and that would cover the vast majority of cyber investigators) sees some apparent irregularities associated with communications from a Russian IP address. Add in some recent news stories about control system related attacks like Nitro and Duqu (I know neither targeted control systems, but you would be hard pressed to know that based upon many press reports) and one can understand by an investigator could jump to a control system hack as an explanation for an unexpected equipment failure.

Contact ICS-CERT

Once again this points out the need for control system owners (and supervisory contractors such as MECO Engineering for Curran Gardner Township PWD) to contact ICS-CERT if they suspect that unusual control system actions may be related to a cyber-intrusion. ICS-CERT maintains the following contact information on their web site.

• E-mail -
• Phone - 1-877-776-7585

ICS-CERT recommends that when sending sensitive information to ICS-CERT, facilities should download their public key to provide secure transmission capability.

Thursday, November 24, 2011

PHMSA Publishes Excess Flow Valve ANPRM

In response to a National Transportations Safety Board (NTSB) recommendation to expand the use of excess flow valves in gas service lines the Pipeline and Hazardous Material Safety Administration (PHMSA) is publishing Friday (available on line today) an advance notice of proposed rulemaking (ANPRM) (76 FR 72666-72671) seeking public comment on several issues relating to the expanded use of excess flow valves (EFVs) in gas distribution systems.


The NTSB recommendation was made on June 22, 2001 in their report on a natural gas explosion at a single family residence in South Riding, VA. Their recommendation SR P-01-2 proposed that “excess flow valves be installed in all new and renewed gas service lines, regardless of a customer's classification, when the operating conditions are compatible with readily available valves” (76 FR 72667).

With a lot of caveats PHMSA required the installation of EFVs on all new or replaced service lines serving single-family dwellings in a final rule published on December 4th, 2009 (76 FR 63934). The authority for that requirement was provided in the 2006 PIPES Act (PL 109-468), but that authority did not extend beyond single-family residences. In this ANPRM PHMSA notes that they have “broad authority under 49 U.S.C. 60102 to prescribe safety standards requiring that EFVs be installed on those lines in appropriate cases” (76 FR 72668).

An EFV is a safety device that is put into (in this case) a gas transmission line. It consists of a flow measuring device and an actuator for a valve. When the gas flow reaches a pre-set volume, the EFV shuts the valve on the line, stopping the flow of gas. The set point is calculated to be some percentage of the maximum possible flow rate through the line at some pre-determined pressure. The idea is that there is some flow rate through the line that can only be explained by a catastrophic leak and shutting off the flow of gas to the leak will limit the potential size of an accidental gas explosion.

Existing Standards

PHMSA notes that there are currently three existing technical standards for the specification, manufacturing and testing of EFVs. They also explain that the existing standards “may not be applicable to all sizes and pressure ratings of EFVs that would be needed if they were mandated for use in applications other than single family residences”. Those three standards are:

• “Manufacturers Standardization Society (MSS) SP-115-2006—Design, Performance & Test.”;

• “ASTM International (ASTM) F1802-04—Standard Test Method for Performance Testing of Excess Flow Valves.”; and

• “ASTM International (ASTM) F2138-01—Standard Specification for Excess Flow Valves for Natural Gas Service.”

If the current gaps in these standards were to be addressed by the two bodies involved PHMSA would consider incorporating these three standards by reference in the final rule if and when it is developed.

Public Comment

In order for PHMSA to complete their work on this regulation they are asking for public input on some specific areas related to the potential rule. These questions fall into four general categories:

• Technical challenges (76 FR 72670);

• Economic (Cost-Benefit) analysis (76 FR 72670);

• Technical standards (76 FR 72670); and

• Review of current industry standards (76 FR 72671).
Public comments need to be filed by February 18, 2012. They may be posted electronically to the Federal eRulemaking Portal (; Docket # PHMSA-2011-0009).

Wednesday, November 23, 2011

ICS-CERT Reports on Water Hack and Published Monthly Monitor

Today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published a bulletin on the cyber security talk of the last week, the report of a water hack of a water control system in Illinois and the latest issue of their Monthly Monitor. Both provide important information on industrial control system security.

No Water Hack in Illinois

All of us who have been talking about the report from the Illinois Statewide Terrorism & Intelligence Center (ISTIC) are going to have to do some explaining about our apparent overreaction to a premature report. According to an Information Bulletin issued today by ICS-CERT the fly away team has looked into situation and cannot find any information to support the preliminary conclusion from the ISTIC that a cyber-attack was involved in the pump failure Curran-Gardner Public Water District. The report states that:

• There is no evidence of a cyber-intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois;

• There is no evidence to support claims that any credentials were stolen; and

There was no malicious or unauthorized traffic from Russia or any foreign entities.

It seems that we all reacted to Joe Weiss’ report about the ISTIC report as if it were established fact. While most of us included appropriate weasel words (I prominently included: ‘If this happened’ at the start of my initial tirade) it was apparent that we took the report at face value. This is probably because most of us know that it is just a matter of time that this will happen for real. Unfortunately, we have some egg on our face with people inevitably talking about the boy who cried wolf.

I still believe that ICS-CERT could have nipped a lot of this yelling and screaming in the bud if they had published an alert on the initial ISTIC report (even though they received it six days after the alert was published) much the same way that they do with initial reports of uncoordinated-disclosures of a new soft-ware vulnerabilities. Then the report published today would have been their follow-up and most of us would have commenting on the over reaction of ISTIC.

The bigger problem, in the long run, is that ICS-CERT is so unknown outside of a relatively small circle of control system security experts that a State intelligence agency did not contact them immediately upon receiving  the initial report of a control system incident. This is an issue that DHS needs to address through its network of fusion centers.

November Monthly Monitor

ICS-CERT published the latest issue of their November Monthly Monitor today. This is one of the tools that ICS-CERT uses to communicate with the control system security community. This issue addresses vulnerability disclosure, researcher acknowledgment, Duqu and internet facing control systems.

They have a nice brief piece on the recent discussions about responsible disclosure that ICS-CERT participated in at the recent ICSJWG fall meeting. With their typical class, they gave recognition to Dale Peterson, one of their vocal critics on this topic. One of the results of the discussion was that ICS-CERT has reviewed and modified their policy on providing attribution for uncoordinated disclosures of newly identified vulnerabilities. They will now provide the name of security researchers (unless the researcher requests anonymity) for all vulnerability discoveries, even if the researcher does not participate in the coordinated disclosure program.

There is a nice summary article about Duqu. There is no new information that has not already been published by ICS-CERT. They do provide a summary of the differences between Stuxnet and Duqu, noting that their analysis of the “code and each malware’s characteristics indicates significant differences between Duqu and Stuxnet, lending more fuel to the debate about common authorship”.

There is a short piece on internet facing systems that notes that Eireann Leverett, at Cambridge
 University has discovered “thousands of Internet facing control system devices throughout the world”. ICS-CERT “responded to reports of over 70 instances of Internet facing control system devices, mostly in the water sector” in the month of April alone.

Tuesday, November 22, 2011

More Amendments to S 1867 – DOD Authorization

I finally had a chance to go through the large volume of amendments proposed for S 1867, the DOD FY 2012 Authorization Act. There are two additional amendments (in addition to the one I mentioned in my post on the introduction of S 1867); both were found in the November 17th edition of the Congressional Record. One deals with control system security and the other addresses IED precursor chemicals.

Control System Security

Senate Armed Services Committee Chairman Leahy (D,VT) has proposed Senate Amendment 1085, that would add a new Division to the bill entitled “Identity Theft And Data Privacy”. As one would sort of expect this deals mainly with IT security issues, but if you scan down to §106 you find a fairly section entitled: “Damage To Critical Infrastructure Computers”.

This section would add ‘‘Sec. 1030a. Aggravated Damage To A Critical Infrastructure Computer” to 18 USC 47. The term ‘critical infrastructure computer’ clearly includes certain SCADA systems in that it is defined as “computer that manages or controls systems or assets vital to national defense, national security, national economic security, public health or safety, or any combination of those matters, whether publicly or privately owned or operated” in §1030a(a)(2). It then provides a non-exclusive list of areas where such computers might be found:

‘‘(A) gas and oil production, storage, and delivery systems;

‘‘(B) water supply systems;

‘‘(C) telecommunication networks;

‘‘(D) electrical power delivery systems;

‘‘(E) finance and banking systems;

‘‘(F) emergency services;

‘‘(G) transportation systems and services; and

‘‘(H) government operations that provide essential services to the public.”

I personally find it disappointing that chemical manufacturing, storage and transport systems are not included in the list, but many of those facilities would fall under the general description that precedes the list; so they should be covered.

This section would make it an offense to intentionally cause, or attempt to cause damage to a critical infrastructure computer that would result in substantial impairment {§1030a(b)}:

“(1) of the operation of the critical infrastructure computer; or

“(2) of the critical infrastructure associated with the computer.”

There is a major flaw in this amendment though. Section 107 provides some pretty strict guidelines for the sentencing of violators of the new rules contained in this amendment. Unfortunately the definition of the covered offenses only applies to IT systems not control systems as it only deals with theft of information.

IED Precursors

Senate Amendment 1215 has been proposed by Sen. Casey (D,PA) and it deals with certification that the Pakistani government is continuing to make progress in controlling the production of improvised explosive devices by controlling the use of important precursor chemicals. What is unusual here is that the only precursor chemical that it lists by name is ‘calcium ammonium nitrate’.

According to ‘calcium ammonium nitrate’ is 5Ca(NO3)2.NH4NO3.10H20. This would give a Nitrogen percentage of 15.5%. That number is important because the DHS Chemical of Interest (COI) list (Appendix A, 6 CFR 27) defines ammonium nitrate (the precursor not the explosive; two separate listings) as having a nitrogen content of 23% or greater.

So it would seem that the military considers calcium ammonium nitrate to be an IED precursor chemical in Pakistan (we pressured Pakistan to outlaw it in the Northwest Frontier Province of Pakistan), but DHS does not consider it to be an IED precursor chemical in the United States. This is obviously explained by the fact that the chemical reaction is more energetic in Pakistan because of local political conditions (pardon the sarcasm).

Consideration of Amendments

Not every amendment proposed will make it to the discussion phase in the Senate and fewer still actually make it to a vote. Two of the three amendments that I have discussed so far (1085, 1215, and 1229) were listed on the ‘pending’ list of amendments to be considered for this bill. Interestingly it is the Levin amendment that has apparently (it could just be an oversight with so many amendments to list) not made the initial cut.

With Congress out of town for the Thanksgiving weekend (the Senate has pro forma sessions scheduled for today and Friday) the next day of debate on S 1867 is scheduled for Monday. This could be a long, drawn out process.

HR 2937 Reported in House

Last week the House Energy and Commerce Committee published their report on HR 2937, the Pipeline Infrastructure and Community Protection Act of 2011. The report provides a copy of their proposed amendments to the bill, but there is nothing new in that language that hasn’t already been addressed in this blog. Moving this bill to the floor of the House waits on action by the House Transportation and Infrastructure Committee which has yet to hold hearings on the bill.

There is one oddity in this report. All committee reports on bills must address the cost of implementation of the bill. This is done by having the Congressional Budget Office conduct a formal review of the various parts of the bill and determining the costs to the Federal government, State and local governments, and the private sector. A letter from the CBO to the Committee Chair is typically included in the report. In this Report the CBO letter on HR 2937 is addressed to Sen. Rockefeller (D,WV), the Chair of the Senate Commerce, Science, and Transportation Committee, not Rep. Upton (R,MI), chair of the House Committee. Now Rockefeller’s Committee is looking at a very similar bill, S 275, but this CBO letter specifically addresses the costs of HR 2937, not S 275; odd to say the least.

There is one typical section missing from this report, the minority view. This is where the Committee Ranking Member outlines the problems the opposition has with the bill. In this case, the Committee passed the bill by a vote of 51 to 0 so there was presumably no alternative actions the Committee Democrats would have preferred.

Sunday, November 20, 2011

Hacked Water System: Disclose or Not

It has been interesting seeing the reporting this weekend on the disclosure by Joe Weiss (I attributed it to Nancy Bartels because her name was on the original post at that an Illinois water system had been hacked. There has been a little new information released:

• The system hacked belonged to the Curran-Gardner Township Public Water District;

• The hack was discovered during a diagnostic check of system communications logs;

• It was apparently a pump that sucked water out of the ground that was damaged; and

• There was a completely separate ‘hack’ of the South Houston water system control network.  

There has still been no public discussion of what control system was involved, what kind of security measures were in place (it was a small water system, so there probably wasn’t much in the way of security in place) or what other systems might be at risk because of credentials stolen from the vendor.


There has been very little discussion in the mainstream press about whether or not the FBI and DHS (both are investigating this incident) should be sharing more information with the public or control system community about this. The discussion has generally been an obligatory quote from Joe Weiss and an official FBI comment that the case is under investigation.

The law enforcement types are reacting true to form. They are doing there investigation and they generally don’t want to discuss ongoing investigations. It certainly makes it easier for them to make a prosecutable case against the perpetrators if they don’t make public the facts in the case during the investigation. This is good police procedures, but not necessarily good public policy.

The discussion in the ICS security community has been a little more robust, but it has generally followed the lines of the discussion of ‘responsible disclosure’ of vulnerabilities. That has been a long running debate about the pros and cons of security researchers working with vendors to correct identified vulnerabilities before publicly releasing the news of the existence of the vulnerability.

There are some interesting and valuable arguments on both sides of that debate. From an outsider’s perspective (I have never been and will probably never be a vendor or security researcher) it generally seem to come down to the experience the individual researcher has had working with vendors on solving the identified problems; good experience equals pro-RD, bad experience equals anti-RD.

Attack vs Vulnerability

The problem with the ‘disclosure’ debate in the cyber security community is that it misses an important point in this instance. We are no longer just talking about a system vulnerability we are talking about an actual cyber-physical attack; just the second known instance in the world (Stuxnet being the first) and the first against a target in the United States. This takes the discussion to the political level in a way that vulnerabilities never did.

In all of the Congressional and DHS discussion to date the vast bulk of the debate about cybersecurity has centered around data security and protection of personal information. As I have noted in discussion of bill after cyber security bill there has been nothing beyond perfunctory mention of industrial control system security in any of the bills. Even where we have existing cyber security regulations governing critical infrastructure (See RBPS #8 in the CFATS Risk-Based Performance Standards guidance document) the rules clearly address IT security not ICS security.

The reason is clear; IT has been attacked it  must be protected, ICS is too difficult to attack so we won’t worry about it. Stuxnet didn’t do much to change that thinking (no matter how many politicians said that it was a ‘game changer’) because the attack has always been attributed to a nation-state. And no one was going to risk going to war with the US by executing a cyber-attack upon our critical infrastructure.

From the reporting to date (mainly from what Joe Weiss is not saying) this does not appear to be a super-sophisticated attack that would require the resources of a nation-state to execute. It seems likely that this is a relatively simple attack utilizing anyone of a number of publicly-disclosed common vulnerabilities in any number of different SCADA systems. Add to that the apparent theft of access credentials (user names and passwords have been reportedly involved) and you have an attack that could be duplicated in any number of systems supplied by that vendor.

Informed Defense

That is the rub; an undisclosed number of other facilities, and not just water treatment facilities, that may be at risk from an attack from the same source. Disclosing the details of this attack will not make it any more likely that the same attacker will (or won’t) repeat the attack with more serious consequences than a damaged water pump at some other facility(ies).

Informing all of the users systems similar to that used by the Illinois water system of their potential vulnerability to this type of attack is an immediate concern. While enough may not yet be known to correct the specific vulnerability, system administrators (or more likely their consultants) can institute a program of closely monitoring system logs for signs of external communications as a method of early detection of an attack. That would seem to be the simplest and cheapest defensive measure that could immediately be put into place for most systems. Sharing the specific indicators that were used to discover the Illinois hack would be a good first step in allowing that effort to move forward.

Don’t Let Them Know You Hurt

The counter argument has been made that telling people about the details of the attack lets the attack know too much information about how successful his attack has been and could allow him (yes, dear, it could have been a woman who was responsible for this attack) to adjust his attack to improve its effectiveness the next go round. This is the old ‘don’t let em know your hurt’ speech given by just about every coach around the world.

I would be very surprised if that was the case here. If this was the worst-case scenario (I’ll describe that below), then the attacker had watchers in place to determine the effect and response to the attack. Even if this was just a case of criminal mischief (and that is possible) the attacker probably would have been sophisticated enough to monitor the pump speed and then note that it did not start up when told to do so. That would have been sufficient notification of the success of the hack. In either case, not making notifications to potentially affected parties protects nothing except the attacker’s ability to do this somewhere else with a high probability of success.

Worst Case

I’ll call this the Richard Clarke Scenario (cyber security aficionados will be able to figure out the reference). A foreign power is planning on executing a force of arms action somewhere else in the world, some where we might be expected to respond effectively. To prevent us interfering with their foreign policy action they stage a cyber-attack on an important piece of critical infrastructure and via back-channels warn the President that interfering with their actions will result in a whole sale attack on that type CI asset around the US.

To make that type scenario plausible, one would want to try out the cyber weapon against a small, unimportant target. The effectiveness of the trial attack would not be gauged in public response in the press, but rather watching to see if the attack was physically successful and how fast the response mitigated the damage. And a serious attacker would want to have people on the ground to watch for that information.

Do I think this is what is happening? No, I really don’t. First, the United States has made clear that it considers a cyber-attack on critical infrastructure to be the same as a physical military attack on the United States.  Second, any American President that acquiesced to that kind of blackmail would impeached by acclimation. Finally, remember Stuxnet? Most of the world thinks that we were responsible for that, no matter how much we claim otherwise. Would you want to risk out Stuxnet-like retaliation? I think not.

Political Issue

In the end I think that this whole thing is a political issue. If the politicians at DHS or the FBI declare this to be a hack/attack then they will have to declare it a foreign state attack (now considered to be equivalent to a military attack under the Obama doctrine) or a terrorist attack (with all of the frenzy-spending that would entail). There is another alternative that they might want to consider, call it a pre-cursor to an extortion plot or call it interfering with a water treatment system and leave the reaction to the law enforcement types.
In the meantime, let everyone with a SCADA system from the same vendor in on the necessary details so that they can protect themselves from a similar attack. Either that or come up with a way for the Federal government to protect them; and that’s just not going to happen.

Saturday, November 19, 2011

S 1867 Introduced – DOD Authorization Bill

The Senate has apparently given up work on HR 2354 due to internal political squabbles and has now started work on the DOD authorization bill for FY 2012. Not content with the three bills that had been introduced in the Senate earlier this year covering the same subject (S 0981, S 1253, and S 1254) Sen. Levin (D,MI) this week introduced S 1867, the National Defense Authorization Act for Fiscal Year 2012.

BTW: Levin, the Chair of the Senate Armed Forces Committee, introduced all three previous versions of this bill.

Cybersecurity Provisions

There are four cyber security provisions in this new bill, but they are substantially the same as those found in S 1253. I discussed them in some detail in my blog on that bill’s introduction. The section titles are:

• Section 913. Review to identify interference with national security global positioning system receivers by commercial communications services [LightSquared provision];

• Section 931. Strategy to acquire capabilities to detect previously unknown cyber-attacks;

• Section 932. Program in support of department of defense policy on sustaining and expanding information sharing [WikiLeaks prevention]; and

• Section 1076. Study on the recruitment, retention, and development of cyberspace experts.

I haven’t had a chance to peruse the Committee Report on this new bill yet, but I would bet it contains substantially the same cyber security discussions found in the report from the S 1253. I did a write-up of that earlier report that might be interesting to re-read here.

Amendments to S 1867

As one would expect for an authorization bill for an agency as large and controversial as DOD, there are a lot of amendments that have been introduced for this bill. I’ll probably be doing a couple of blog posts on the amendments that would affect the chemical and cyber security communities.

One, however, did catch my attention as I was scanning the list; Amendment S 1229, introduced Friday by Sen. McCain (R,AZ). It would add §1088, “Cybersecurity collaboration between the Department of Defense and the Department of Homeland Security”, which would define the cybersecurity relationship between DOD and DHS.

There are not a lot of details in this amendment, but it would require the two departments to exchange officials to aid in the coordination of their efforts.

Friday, November 18, 2011

Live ICS System Hacked?

Yesterday Nancy Bartels over at left a very interesting teaser about a hacked water treatment plant control system. Very few details, but what she posted should have everyone in the control system security community in a tizzy trying to figure out what is going on.

The thing that disturbs me most (it wasn’t my system so the hack ‘wasn’t that big a thing’) is her first bullet point:

“The disclosure was made by a state organization, but has not been disclosed by the Water ISAC, the DHS Daily unclassified report, the ICS-CERT, etc. Consequently, none of the water utilities I have spoken to were aware of it.”

If this really happened (I’m not questioning Nancy’s veracity, but without her sources being disclosed I have to include that “IF”) ICS-CERT has (if they knew about the incident, again not known) completely failed the ICS security community in not spreading the word far and wide.

If ICS-CERT has published this as one of their “FOUO” limited distribution things, they need to be horsewhipped in the public square. An actual attack on a live control system in the United States has both security and political implications. Congress needs to look into this situation before the Thanksgiving weekend.

Thursday, November 17, 2011

House and Senate Approve HR 2112

Today both the House and Senate approved HR 2112 in a substantially bipartisan vote, both in favor and in opposition. The House voted 298 to 121, with the bulk of the Nays coming from Republicans. The Senate voted 70 to 30, with all of the Nays coming from Republicans.

When the bill is signed by the President, probably tomorrow, it will extend spending authority until December 16th. It will provide a similar extension to a number of Federal programs, including the CFATS program.

PHMSA Extends Comment Period on Pipeline ANPRM

Yesterday the Pipeline and Hazardous Material Safety Administration (PHMSA) published a notice in the Federal Register (76 FR 70953) announcing that they would be extending the comment period on their Safety of Gas Transmission Pipelines ANPRM. The original comment period ended on December 2, 2011; this extends it to January 20, 2012.

It is a shame that four months was not long enough for industry to read this relatively lengthy ANPRM (40+ pages) and provide feedback to PHMSA. I’m sure that they will be able to get a lot more work done on this over the holidays (pardon the sarcasm).

Wednesday, November 16, 2011

Simple Rule for HR 2112

The House Rules Committee met today to formulate the rule (House Resolution 467) for floor consideration of HR 2112, the Consolidated and Further Continuing Appropriations Act, 2012. As with the rules for most conference reports, this will be a straight forward closed rule with an hour of debate followed by a vote.

The interesting point in the Rules Committee hearing was when Chairman Rogers (R,KY) was asked about the prospects for completing the remaining spending bills. He responded that he hoped the Senate would complete action on the remaining bills, but he felt there would be a ‘rest-of-the-bus’ bill to finish the spending legislation for the fiscal year. No word yet on if that would include DHS, but it is very likely. One point that he did firmly make, the spending bills would be completed before the end of the year.

Final point, as with all continuing resolutions in recent history, the spending extension will include an extension of the CFATS program authorization; this time thru 12-16-11.

HR 2764 Mark-Not

I noted earlier this week that the Subcommittee on Counterterrorism and Intelligence of the House Homeland Security Committee was to hold a mark-up hearing for HR 2764, the WMD Intelligence and Information Sharing Act of 2011. Well the hearing was held yesterday and nothing was done. Okay, that is totally not fair; the Subcommittee ordered the bill “to be reported to the Full Committee with a favorable recommendation, without amendment by voice vote”.

So, there is no change from the introduced bill. We will now get to wait to see what the full Committee will do with their mark-up.

LightSquared Amendment to HR 2354

HR 2354 is a spending bill for energy and water development and related agencies for FY 2012. It is not really a bill where one would expect to find much in the way of chemical or cyber security issues being addressed. But you do have to watch congress critters and spending bills; lots of things get added to them.

Yesterday, Sen. Roberts (R,KS) proposed amendment #984. It would add one of those neat funding restrictions, this time with the FCC as the target agency. The new section would read:

“None of the funds made available in this Act may be used by the Federal Communications Commission to remove the conditions imposed on commercial terrestrial operations in the Order and Authorization adopted by the Commission on January 26, 2011 (DA 11–133), or otherwise permit such operations, until the Commission has resolved concerns of potential widespread harmful interference by such commercial terrestrial operations to commercially available Global Positioning System devices.”

This is obviously targeted at the broadband internet system from LightSquared which operates at frequencies near enough to the GPS frequencies that it has been demonstrated that there can be interference from the much stronger terrestrial single. The concern from the point of view of the chemical safety community is that the GPS signals may be used for coordinating timing between physically separated yet connected elements. Interference with the signal could cause communications issues.

It is not clear that this amendment will actually be considered by the Senate; most amendments listed in the Congressional Record never make it to a vote or even a discussion about consideration.

ICS-CERT Publishes InduSoft Advisory

Yesterday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published an advisory for the InduSoft Web Studio software. Interestingly, they give Luigi credit for discovering this vulnerability; Luigi coordinated his disclosure with the Zero Day Initiative so this time he did not run afoul of the ICS-CERT disclosure policy.

The vulnerabilities exploit unauthenticated remote code execution capability within the remote agent component of the system. The vulnerabilities would allow a moderately skilled attacker to remotely execute arbitrary code.  There are no publicly available exploits for these vulnerabilities.

NOTE: CVE numbers have been assigned for these two vulnerabilities but the links provided in the Advisory do not actually link to the CVE files. It is not clear whether this continuing problem is a NIST or and ICS-CERT problem.

Tuesday, November 15, 2011

HR 2112 Rules Committee Hearing

The House Rules Committee web site announced that they would be holding their Rule Hearing for the full House consideration of the Conference Report fir GR 2112 on Wednesday, 11-16-11 at 2:00 pm EST. The Rules Committee web site is now calling this the Consolidated and Further Continuing Appropriations Act of 2012. This would allow for consideration of HR 2112 on Thursday under a Rule; plenty of time for the House and then the Senate to pass the CR by the time the current spending authority ends on midnight at the 18th.


A long time reader and MTSA commentator (Maritime Transportation Security News & Views) John C.W. Bennett pointed me at an article over at about some CFATS facilities asking truck drivers to have a Transportation Workers Identification Credential (TWIC) to gain access to the facility to satisfy requirements that visitors have been vetted against the Terrorist Screening Database (TSDB). The article points out that the American Trucking Association (ATA) is recommending that the Hazardous Material Endorsement (HME) also be used for this purpose.

This is going to be a continuing problem for truckers and CFATS facilities that might be partially resolved when the final guidance on the personnel surety program is eventually published. Given the controversies surrounding that program (some dealing specifically with this issue) and ISCD’s attempt to ‘work with’ the regulated community, I wouldn’t hold my breath while waiting for final clearance on this topic. With that said, let’s look at some of the issues involved.

Unescorted Access

First and foremost, the personnel surety requirements in the CFATS regulations only require visitors granted unescorted access to critical and or restricted areas of the facility to have undergone the appropriate background checks. The facility has a relatively large leeway in determining exactly what portions of the facility this encompasses. NOTE: All facility employees must undergo the background checks, but visitors are only required to do so by the regulations if they have unescorted access.

It should be relatively easy for many facilities to define or control loading docks in such a manner as to keep the driver accessible areas outside of the ‘controlled’ area. This will be more difficult if the facility ships or receives theft/diversion chemicals of interest (COI), but it should still be possible. (NOTE: This seriously points out the problem with shipping security, if the COI are not hazardous materials; there are no TSDB background checks required for the driver who hauls this stuff across county.)

Keeping bulk load drivers away from critical/restricted areas may be more difficult, but even this could be addressed by having delivery drivers drop their tank wagons. The facility would then use their personnel to move the tank wagon to the restricted unloading areas.

Of course, the facility security management team may just decide that it is just as easy to make the fence-line the restricted area and require all people, escorted or otherwise to have undergone the requisite background checks.


Both the TWIC and the HME require identical background checks against the TSDB. From there the two different programs are significantly different. Most of these differences mean nothing to CFATS facility compliance requirements. The major difference of significance is that the TWIC is a biometric based identification. If and when the TWIC readers become officially available a facility will be able to verify both the authenticity and currency of the TWIC card and the identity of the person who possess the card. This would give high-risk facility security managers much better confidence in allowing a strange person unaccompanied access to their facility.

The near similarity of these two vetting programs is one of the reasons that there is an on-going move (‘move’ is a relative term) in Congress to ‘harmonize’ these programs with only the TWIC remaining (See HR 1690 blog post) after all is said and done. There is a long way to go for that harmonization to reach reality, if it ever does.

The biggest current problem is that there is no guarantee that any given truck driver will have either identification in their possession. Currently if a truck driver does not plan to pick-up or deliver at an MTSA covered facility or carry hazardous chemical loads, there is no requirement to go through the expense or bother of either process. And, make no mistake; either program is a pain to go through.

Security Management Problem

A CFATS facility manager is faced with a problem if the facility is unable to keep the various truck drivers out of the restricted area. The facility has either got to provide a security escort for each truck driver or make provisions for ensuring that the truck drivers are properly vetted. Since ‘escorting’ trucks is difficult at best, most security managers will find it easiest to resort to requiring all truck drivers are properly vetted.

This breaks down to two general cases; outbound trucks and inbound trucks. Usually a facility has a tad bit more control over the identity or vetting of outbound drivers. If a company has their own drivers or contracts with a specific trucking company for shipping their products, requiring all drivers to be vetted via the CFATS process should be fairly simple and no special government identification requirements will be necessary.

For inbound shipments where the vendor has a similar type of driver arrangement the situation should typically be about as easy. The receiving company lets the shipper know that all drivers coming to the site have to be vetted through the TSDB with the suggestion that they should have either a TWIC or HME.

For inbound shipments where the transporter is a completely independent third party(ies) is where things start to get dicey. A TSDB vetting requirement may be laid upon the vendor with the expectation that it will be transmitted in-turn to the driver that brings the load to the front gate. Unfortunately, anyone with significant real-world experience knows that inevitably the critical shipment that the facility absolutely has to have will show-up with an un-vetted driver. Such are the challenges of a security manager.
/* Use this with templates/template-twocol.html */