Chemical Facility Security News

More Waxahachie Emergency Response Notes

2012-01-31T08:47:00.000-05:00

Last October I looked at the fire at the Magnablend chemical facility in Waxahachie, TX as a learning tool for emergency response planners. Recently the facility was once again in the news for emergency response activities related to the aftermath of that fire. According to a news article on WFAA.com recent rains in the area caused containment ponds that collected fire-fighting water (and subsequent rain fall that helped ‘clean’ the facility) to overflow; ponds that “were presumed to still be polluted with chemical residue” according to the article’s author Brett Shipp.

Typically these run-off collection ponds are initially put into place by emergency responders and later improved somewhat by whatever clean-up company comes in to remediate the site. The initial runoff from the firefighting effort would probably have the highest concentration of dangerous chemicals. That is presuming, of course, that teams are able to quickly get into the facility and stop whatever leaks remain.

The initial fill of these ponds is usually emptied quickly in an effort to limit any additional environmental exposure to the chemical mixture involved. Most professional site restoration companies are well experienced in the physical and legal requirements of this process. These operations should be coordinated with local emergency response personnel so that they can respond appropriately to any incidents that occur in the process.

The containment structures are typically left in place until final site clearance is received to collect any subsequent run off from facility clean-up operations or rainfall runoff. The water collected is usually less contaminated than the initial collection in these ponds, but, depending on the chemicals involved at the site, may still harbor dangerous levels of hazardous chemicals. Remember what constitutes ‘dangerous levels’ is dependent on the chemicals involved, some chemicals are still dangerous down to the part per million or even part per billion levels in the environment.

Local emergency response planners need to ensure that these collection ponds are monitored for contaminant levels and liquid level in the ponds. When heavy rains are forecast for the area consideration of draining the current contents before the rain event may prove to be beneficial. Areas of the country that experience frequent short-notice periods of heavy rainfall may want to consider requiring secondary containment facilities to catch any pond overflows.

Provisions need to be put into place to keep these ponds isolated from the community, including restricting access to the ponds. They certainly meet the definition of ‘attractive nuisance’ and may actually be potential targets for fringe elements of the radical environmental movement, particularly if the company involved is already on the hit list for whatever real or imagined environmental slights. Less radical elements may also attempt to include such sites in ‘environmental actions’ designed to call attention to the hazards.

As with all emergency response plans a formal process needs to be put into place to review these situations on an on-going basis. Initial emergency plans for all facilities housing dangerous chemicals need to include run-off management plans. Those plans need to be reviewed and modified as necessary before the incident commander turns the scene back over to the owner or the environmental remediation company designated for site clean-up.

Siemens – The Big ICS-CERT Advisory

2012-01-30T23:54:00.000-05:00

Today the DHS ICS-CERT folks published an unusual advisory. They combined reports of vulnerabilities from four separate researchers; Billy Rios, Terry McCorkle, Shawn Merdinger, and Luigi Auriemma; and combined them into one big (eleven separate vulnerabilities) advisory on the Siemens WinCC application. Not only is the big from the number of vulnerabilities, but the potential consequences of the exploitation of these vulnerabilities is really big. ICS-CERT notes that:

“Successful exploitation of these vulnerabilities could allow an attacker to log on to a vulnerable system as a user or administrator with the ability to execute arbitrary code or obtain full access to files on the system.”

Given the wide range of facilities that this Siemens application is used, an attacker would have a wide range of potential targets that could essentially be exploited at will, shutting down electrical transmission facilities, water treatment facilities, chemical plants, even automotive manufacturing facilities. Simultaneous attacks on a number of targets across a number of manufacturing and utility sectors could have a catastrophic impact on local, state, national, or even world economies.

The catalogue of vulnerabilities includes:

• Insecure authentications;

• Weak default passwords;

• Cross-site scripting;

• Header injection;

• Client-side attack;

• Lack of telnet daemon authentication;

• String stack overflow;

• Directory traversal (two separate vulnerabilities);

• Denials of Service; and

• Arbitrary memory read access.

The good news (and I’m really having to stretch here to call this ‘good news’) is that ONE of the vulnerabilities requires user interaction to exploit. Fortunately for Siemens’ customers there have been so few successful social engineering attacks over the last year or so (pardon the gross sarcasm). The bad news (and it doesn’t come much worse than this) is that there are publicly available exploits for 7 of the 11 (Oh Craps, I know, pardon the pun) vulnerabilities.

The good news (another stretch) is that Siemens has dealt with each of these vulnerabilities. They have

• Patched 5;

• Changed product documentation to explain how to correct one during set up;

• Recommended deactivation of transport mode for four others; and

• Explained that users have the option of disabling the final vulnerability.

The bad news is that no one outside of Siemens has verified if any of the above actions prevent the exploit of any of the eleven vulnerabilities included in this report.

The final good thing is that ICS-CERT put all of these vulnerabilities into a single advisory, making it easier to keep track of what has been fixed or not. It might be a good idea to do the same sort of thing for Siemen’s PLCs.

New Version of HR 3674, ‘the’ House Cybersecurity Bill

2012-01-30T07:24:00.000-05:00

As I noted in my blog post Saturday, there will be a subcommittee markup hearing for HR 3674, the Promoting and Enhancing Cybersecurity and Information Sharing Effectiveness Act of 2011 (PRECISE) Act of 2011. As is usual with markups of bills like this, the hearing will start off with the Chairman, Rep Lungren (R,CA) introducing his revised language for the bill and the subsequent proposed amendments will be made to that new language. So let’s take a look at the new version of his bill.

Overview

First off nothing has been removed from the bill at this point (that could change later this week); so everything I wrote about this bill (then a draft of this bill) still pertains to this revised language.

Most of the changes have been technical wording changes that will be mainly of interest to lawyers and judges if this bill ends up being signed by the President. There were, however a couple of new sections that were added at the end of the bill. They include:

§ 4. Report on Support for Regional Cybersecurity Cooperatives;

§ 5. Pilot Program on Cybersecurity Training for Fusion Centers; and

§ 6. Assessment of Sector by Sector Cybersecurity Preparedness.

Please note that §5 provides for training fusion center personnel in IT security practices to protect their information systems, not about cyber security threat assessment. It would have been nice to see a training requirement here for instance that would direct fusion center analysts to ICS-CERT for assistance in evaluating potential control system threats or attacks.

The bulk of the remaining changes can be found in Subtitle E, National Information Sharing Organization (NISO). Most of these changes have apparently been made to ensure that the NISO is not a ‘threat’ to civil liberties or legitimate information sharing activities.

ICS Coverage?

This bill remains at heart an information system protection bill not an ICS protection bill. The new version does include an additional mention of ‘industrial control systems’. In §226(a)(7) the bill would require the Secretary of DHS to:

“establish, in coordination with the Director of the National Institute of Standards and Technology, the heads of other appropriate agencies, and appropriate elements of the private sector, guidelines for making critical infrastructure information systems and industrial control systems [emphasis added] more secure at a fundamental level, including through automation, interoperability, and privacy-enhancing authentication”.

There continue to be a number of sections of the bill that do not contain the explicit language “critical infrastructure information systems” and these may imply coverage of control systems. These are generally reporting requirements or information sharing requirements and they do not provide any regulatory authority.

For example the new §4 of the bill requires the Secretary to report on:

“the Secretary’s plan to provide support to regional, State, and local grassroots cyber cooperatives designed to decrease cyber disruptions to critical infrastructure, increase cyber workforce training efforts, increase community awareness of cybersecurity, organize community cyber-emergency preparedness efforts, build resiliency of regional, State, and local critical services, and coordinate academic technical and policy research effort”.

There is mention of potential grant program supporting these ‘cyber cooperatives’ (and that term is never defined), but there is no spending authority for such grants. This means that the grant money would have to come out of some existing grant program.

National Information Sharing Organization

The most controversial area of this bill continues to be the establishment of the National Information Sharing Organization which is also the section of the bill that sets up the conflict between this bill and HR 3523 (the bill sponsored by the House Intelligence Committee). Most changes to the NISO sections of this bill address privacy concerns.

For example §244(9) sets for the requirements for the protections of ‘privacy and civil liberties’. The new version of this bill adds subparagraphs (B) and (C) that specify that only ‘cyber threat information’ may be shared within NISO and that all “personally identifiable information not necessary to describe a cyber threat” be removed from information shared by and through NISO.

I noted in my earlier blog on this bill that the private sector board members of NISO did not include anyone from the water, chemical or transportation critical infrastructure key resources (CIKR) sectors. The revised version changes that somewhat in that it adds the water sector to those represented on the Board. The continued lack of chemical or transportation sector representation effective shuts those sectors out of NISO participation.

The new version of this bill also financially guts NISO after FY 2015. Federal funding up until then consists of $20 million each fiscal year (and that comes out of the existing DHS S&T budget, no new money). After FY 2015 the only federal money going to NISO will be the Federal membership fee for NISO. Even that will be limited by §253(b) to no more than “the fee collected from the largest private sector member of the National Information Sharing Organization”.

Since §253(a) prohibits Federal appropriations supporting NISO, that fee will have to come out of the budget of DHS or three other “Federal agencies with significant responsibility for cybersecurity” {§243(b)}. Since none of the four is required to pay the Federal governments ‘fair share’ fee I bet this gets lost in the annual budget shuffle.

There are two new terms specifically defined in the NISO sections of this bill that might increase the applicability of NISO to control system security information sharing (but don’t hold your breath); ‘cyber attack’ and ‘cyber security criminal act’. The inclusive language for ‘cyber attack’ includes the phrase “causes or attempts to cause damage and loss” {§248(f)(1)(B)}. For ‘cyber security criminal act’ the phrase is “efforts to degrade, disrupt or destroy a cybersecurity system or network” {§248(f)(2)(A)}. Neither constitutes a resounding commitment to ICS security information sharing.

Further Amendments

The subcommittee markup hearing that starts on Wednesday (and may become a multi-day hearing) will undoubtedly include many changes to the wording of this bill. Watching the hearing itself will be little help in identifying those changes as the exact wording of the changes is rarely included in the live proceedings. Usually we just get the interpretations of what the various congress critters think the language means.

We will have to wait until the actual amendment language is posted to the House Homeland Security Committee web site. The staff of that Committee usually does a pretty good job of getting that information up quickly. After that we will have the full committee markup (maybe as early as next week). Then we will have to wait for four other committees to act (or more likely fail to act) on the bill.

Congressional Hearings – Week of 01-30-12

2012-01-28T11:51:00.000-05:00

Congress has a full week (for Congress 4 days is a full week) of work ahead of them including two hearings that will certainly be of interest to readers of this blog; ISCD Problems, and Cybersecurity Legislation.

ISCD Problems

The Environment and Economy Subcommittee of the House Energy and Commerce Committee will be holding hearings on the current problems at ISCD on Friday. Actually the title of the hearing is “Evaluating Internal Operation and Implementation of the Chemical Facility Anti-Terrorism Standards program (CFATS) by the Department of Homeland Security”; and I thought that I had a tendency to get wordy.

No witness list is currently available, but I would bet that it includes on the first panel Under Secretary Beers and Director Anderson. If that is the only panel of witnesses, the hearing will be a typical Congressional waste of time. If the second panel is industry reps, it will be almost as much of a waste of time. The only way that this hearing will be meaningful is if it includes sworn testimony from people within ISCD including the facility inspection force; I’m not holding my breath.

What is disappointing is that the first hearing on this topic is by a subcommittee of the Energy and Commerce Committee. First we are certainly past the point where we should be wasting time with Subcommittee hearings since they will certainly have to be duplicated by the full committee before anything can be accomplished. Secondly it is a sign of the utterly stupid organization of oversight of DHS components in Congress that this hearing is not being held by the Homeland Security Committee. Of course Rep King (R,NY) and Thompson (D,MS) have been absolutely silent on the ISCD issue so maybe it is better that someone else does the hearings.

One last rant point here; if the hearing record does not include a public copy (redacted if absolutely necessary) of the internal NPPD report on the problems, the Subcommittee needs to be swept from office in November and the Committee Staff fired on the spot. I know, it won’t happen, but I just had to vent.

Cybersecurity

The Subcommittee on Cybersecurity, Infrastructure Protection, and Security Technologies of the House Homeland Security Committee will be holding a potentially multiple day mark-up hearing on HR 3674 starting on Wednesday. I did a blog post on this bill before it was actually introduced and most of that discussion remains applicable to the bill going into this hearing.

Chairman Lungren (R, CA) will be submitting substitute language for this bill at this hearing. There are some interesting changes being proposed (including some minor but specific control system language), but that is a subject for a separate blog post.

This bill has the hallmarks of being the potential cyber-security bill for this session. The only drawback is that it was also referred to the following committees for consideration:

• House Oversight and Government Reform

• House Science, Space, and Technology

• House Judiciary

• House Intelligence (Permanent Select)

I know the Intelligence Committee has their own bill (HR 3523) that has some conflicting provisions with the current and proposed versions of HR 3674, so we can bet that they won’t hold any hearings on this bill. Similar issues may arise with the other committees as well. The House and Senate leadership are committed to passing cybersecurity legislation this session, but that doesn’t necessarily trump committee politics.

ICS-CERT Publishes OAS OPC Advisory Update

2012-01-27T19:44:00.002-05:00

Today was the day that the DHS ICS-CERT published their updated Advisory on the Open Automation Software OPC Systems.NET vulnerability. As I mentioned in an earlier blog post this update adds a second vulnerability to the one initially discovered by Luigi; the second being discovered by Digital Security Research Group (DSecRG).

The latest vulnerability is this system is a reported buffer overflow vulnerability in the ActiveX control for the system. It would allow a moderately skilled attacker to ….. Hmm ICS-CERT doesn’t say what the vulnerability would allow an attacker to do and neither does the DSecRG report on the vulnerability. Oh well, I guess it doesn’t matter because the updated version of OPC Systems.net released to deal with the Luigi vulnerability also fixes this one. And everyone always updates their systems when a security update becomes available – don’t they?

The long history of this Advisory (dating back to the original Luigi based alert) shows how complicated ICS vulnerabilities can get. This update makes things even more interesting by noting that the new buffer overflow vulnerability in the OAS OCP Systems.NET isn’t really an OAS vulnerability. The vulnerability actually resides in the ActiveX component FlexGrid 7.1, a third-party component of OCP Systems.NET.

As I have mentioned a number of times finding a vulnerability in a third-party component automatically brings a question to my mind; what other ICS systems are using the same component and thus potentially have the same problem. Unfortunately, there is no way for anyone to know since system vendors don’t report if/when/where they use third party component software. Until, of course, a security researcher finds the same vulnerability in another system.

PHMSA Radioactive Tissue Holder Notice

2012-01-27T07:08:00.001-05:00

NOTE: This is not about chemical security, ICS security, pipeline safety, or even chemical safety. Sometimes I just have to vent about government stupidity and I own this space.

Today the Pipeline and Hazardous Material Safety Administration published a Safety Advisory Notice in the Federal Register (77 FR 4398) dealing with radioactive tissue holders; you know, facial tissues, Kleenex®. It seems that Bed Bath and Beyond ® sold some 220+ tissue holders in the United States that were contaminated with Cobalt-60 during their manufacture in India and emit low levels of radiation.

Now having read that information in the Summary section of the notice, I expected to read in the body of the notice that PHMSA was providing shipping instructions for sending these radioactive sources back to somewhere. Since most consumers would not have access to training on shipping hazardous materials or preparation of the paperwork required to accompany such shipments I really expected that PHMSA would provide notice that they were publishing an unusually special Special Permit to allow consumers to get this dangerous material into appropriate hands.

Didn’t happen. It simple tells people to contact Bed Bath and Beyond for “information about proper return procedures”. WHAT? Okay, cool down, read some more, there must be an explanation.

How dangerous is this tissue holder? Here is what the notice says:

“The highest identified radioactivity level on the surface of the tissue holders was approximately 20 mrem/hr, however most of the tissue holders showed much lower levels. A person who spends eight hours in close contact with one of these tissue holders (such as having the tissue on a bedside table next to the bed) could possibly get a maximum yearly dose of about 500-700 mrem. While no unnecessary radiation exposure is desirable, the dose from the tissue holders is not expected to cause any appreciable health effects. To put this into perspective, a person living in the United States receives a radioactive exposure of about 360 mrem/year from naturally-occurring background radiation.”

Okay, it’s really not that big a thing. People should be able to pack these up in a sturdy cardboard box and ship it to some B³ location for appropriate consolidation and disposal. B³ will have some issues to deal with and will be screaming at their Indian supplier. Consumer question, is someone actually making tissue dispensers with steel? What ever happened to plastics for gosh sakes?

Now for the big question: What the Hell is PHMSA doing publishing this notice? Wouldn’t it be more appropriate coming from the Consumer Product Safety Commission? Aren’t they the ones that are responsible for protecting us against unsafe consumer goods????? PHMSA is in the Department of Transportation. They are responsible for transportation issues related to hazardous materials, not radioactive sources sitting on the night stand. How many consumers read the damned Federal Register?

PHMSA is behind enough in their normal work. If it isn’t transportation related, let the appropriate federal agency handle public notices of this sort. Do your work not theirs.

BTW: Did anyone tell the TSA airport security screeners about these dangerous tissue holders that could be used as potential radiological devices aboard aircraft? Do they have pictures to help them identify these devices? Do they have radiological detection devices? I am being sarcastic here, let’s not get carried away.

Rail Borne Chemical Threat to Super Bowl?

2012-01-26T23:50:00.000-05:00

An Indianapolis TV station’s web site is reporting that CSX will halt rail traffic past the Lucas Oil Stadium on Super Bowl Sunday this year. The tracks run within a block of the stadium, and train traffic will not be allowed on those tracks starting about 3 hours before game time until after the Stadium is emptied after the game. The fear is, of course, that a hazardous material leak (accidental or deliberate) that close to the game site could put thousands of people at risk.

Okay, a pause to allow our friends from Green Peace and other environmental activist organizations to ask “What about the thousands of people who live and work along that same line every day?”

Accidental Releases

They are, of course, correct in that anyone living within a certain distance of a railroad track is placed at increased risk of exposure to any hazardous chemical that is being carried in any of the rail cars. The amount of increased risk is infinitesimal; railroads have a very enviable safety record either in the absolute number of fatal chemical incidents or the number of releases per ton-mile of hazardous material transported. Only pipelines have a better overall safety record.

If the risk is sooo small, why are they stopping the train traffic on game day? A small part of the reason is that even an infinitesimal risk is way too high when you are dealing with high-profile events like the Super Bowl. Even a relatively small and hardly dangerous leak of a moderately toxic chemical along the nearest point of approach to the Stadium (named after an oil company, how ironic) would result in the game being stopped and the stadium being evacuated. That would kill Indianapolis’ chance of ever getting another high profile event in their fair city.

Deliberate Attacks

The real reason has nothing to do with accidental releases. If that were the case, those trains would be stopped every time the Colts play at home. It hasn’t happened. It won’t happen. No one is concerned with accidental releases. It is a terrorist attack converting one or more of those railcars to chemical weapons, improvised explosive devices or flame weapon that keeps the CSX security people awake at night as Super Bowl Sunday approaches.

Now the risk of a successful terrorist attack (defined as resulting in a catastrophic failure of the railcar tank resulting in impressive off-site consequences; death and destruction) on a rail car is relatively low. The cars are made of very thick, welded metal, that was designed to resist damage in normal handling and low speed derailments. A portable explosive device designed to take out such hardened targets are not available via Terror-U-Online; it requires the services of an explosives engineer, lots of hands-on time with a stationary vehicle. Oh yes, they have to be large enough to be readily detectable.

Unless, of course, one were to place the device inside of the sealed and filled railcar. But that’s a topic of a completely different post.

Partially Successful Attack

Of course, a successful attack doesn’t really have to be successful to be successful, if you get my meaning (of course you don’t, I’m being entirely too cute, but I will explain). If a targeted release of a chemical (and it wouldn’t even have to be really hazardous) were visible to the news teams covering the game, the security advisors for the event would have to immediately begin evacuation procedures even before they knew the actual nature of the release. There would be wide spread panic resulting in potentially hundreds of deaths or serious injuries; all in front of the eyes of the world.

And that is the reason that CSX is stopping the flow of all rail cars by Lucas Oil Stadium on Super Bowl Sunday, but letting them flow the other 365 days of 2012.

Reader Comment: TSA Video Surveillance Report

2012-01-26T13:49:00.002-05:00

I got a real nice response to yesterday’s TSA Video Surveillance blog post from the President of SightLogix. The comment is posted to the original blog and is well worth reading. The interesting point that he makes (from my point of view) is that the un-redacted TSA video surveillance report (and others like it) is posted on the “TSA’s Secure Webboard”. This is apparently a restricted information (SSI I presume) sharing site that is accessible to registered Airport Security Coordinators; appropriate as that’s who needs this type of information about these security measures.

The interesting comment from him is that he (personally) does not have access to the un-redacted TSA report about the testing of the installation of his company’s equipment. I understand that there is a whole ‘need to know’ issue here, but business decisions and equipment recommendation need to be made based upon reports like. Oh well, I would hope that someone in his organization has access to this web site or was at least allowed to review the report before it was posted.

Now the other point; the ASC web site is great for airport people. But this is not an issue restricted just to airports. Any number of other critical infrastructure facilities have boundaries that need to be surveilled. The information from this testing would be a great piece of information for security managers at these sites as well. I would think that TSA would be able to find a way to share the information with other TSA monitored security programs (a small list to be sure) like railroad facilities.

DHS is going to have to be involved in making this information available to the rest of the non-transportation facilities that have federally mandated perimeter security requirements like CFATS and MTSA. The information about boundary security is applicable to almost any type facility.

Reader Email – Expected Alerts are not Coming

2012-01-26T00:17:00.000-05:00

In my last two ICS-CERT related blogs I noted that the Digital Security Research Group (DSecRG) web site had two additional ICS vulnerabilities reported that had not yet shown up as ICS-CERT alerts. I heard from two different sources today the reason that those alerts are probably not forthcoming. The first came from a semi-anonymous email (it came from a gaming site, but it was signed with a PGP signature) and the second was from a caller claiming to be from ICS-CERT but I didn’t catch the name as I was running between three meetings at the time.

Default Passwords

The DSecRG web site describes vulnerabilities in Tecomat PLCs and the Open Automation Software (OAS) OPC system. According to both sources (in almost identical wording, same person perhaps?) the Tecomat PLC vulnerability is really nothing more than a list of default passwords that should be changed upon system installation; anyone want to venture a semi-educated guess as to how often they are actually changed on PLC’s? I don’t know but I would suspect much less often than security folks would like to see. After all PLC’s are not connected to the internet, so why bother?

Both sources said:

“That is not a vulnerability. If they are not changed than that is a configuration issue. (We can not prevent integrators from being stupid).”

The pejorative aside, I can certainly understand why ICS-CERT and many security professionals would take that attitude. They have enough serious ICS security issues without having to worry about people not changing default passwords.

Having said that, many of these systems were installed before most organizations had even heard the term ‘cybersecurity manager’. Now most critical infrastructure facilities (at least) have a person wearing that hat (okay and maybe a couple others as well) who needs to determine if there are any unresolved vulnerabilities in their legacy systems (all new systems, as we all know, come with sophisticated cybersecurity suites; SARCASM Warning). I would expect that a real common problem in many (if not most) of those older systems is that they were installed without changing any of the default passwords.

If an energetic cybersecurity manager knew which systems came with default passwords and knew what they were, it would be a relatively easy (okay so that is a slight exaggeration, and our receptionist is just slightly pregnant) to go back and check all of those devices to ensure that the default password is not still active. Without lists like this from people like DSecRG or ICS-CERT, it would be nearly impossible to determine what the default password on legacy systems might be to verify that they had, in fact, been changed.

Well, if ICS-CERT isn’t going to worry about the problem, maybe SCADAHacker can just add that to the lists he is maintaining on various ICS security issues.

OAS OPC Advisory

Both sources told me today that ICS-CERT was going to be issuing an update on the recent OAS OPC advisory. That update (already planned apparently) will also address the vulnerabilities identified on the DSecRG web site as they are already being dealt with by OAS. If that update provides appropriate mitigation measures for the DSecRG identified vulnerabilities, that certainly sounds like an efficient way of dealing with the problem. No word on when that will be published; hopefully in the next day or two.

TSA Analysis of Video Surveillance System

2012-01-25T08:02:00.002-05:00

I typically don’t try to promote specific security systems as I am not a ‘qualified expert’ in much of anything that would allow me to make an authoritative evaluation of any particular product. Every once in a while I run across (thanks in this case to a SCADAHacker tweet) an evaluation of a system by someone or an organization that should be qualified to do such an analysis and I think it’s worthwhile to look at such evaluations. I recently ran across a TSA report on the use of a video analytics system used to secure an airport perimeter that falls into this category.

The Report

The report was prepared as part of TSA’s Airport Perimeter Security project that provides a technical evaluation of perimeter security systems currently being employed at facilities around the country. This project should provide security managers with an important independent evaluation of integrated security products to supplement claims made by manufacturers and system integrators. This is apparently the first of 15 (perhaps 21, the wording of the report is sort of vague) such reports that TSA is currently preparing.

The actual evaluation was done by the National Safe Skies Alliance, a non-profit organization formed to “support testing of aviation security technologies and processes”.

Redacted Information

One would expect that an in depth review of a security system would involve the disclosure of some sensitive information that might be useful to someone trying to compromise that system. This report is no exception. TSA has dealt with that by redacting (blacking out) certain information in the report. While protecting the security of the installation being evaluated, it does somewhat compromise the usefulness of the evaluation.

For example the report redacted a site diagram (page 3, 15 Adobe) showing the areas covered by the video system; an understandable exclusion. Partially understandable, but certainly less helpful to security managers, was the redaction of the test intrusion detection rates in reporting the test results for the four individual intrusion techniques tested (with any details of the intrusion technique redacted). What makes this somewhat confusing is that in the summary discussion of the system accuracy the report notes that over 900 intrusion scenarios were performed (four intrusion techniques performed at a variety of locations within the detection range of seven devices) and that “every alarm instance was accurately reported through the primary management software” (page 13, 25 Adobe).

So what is redacted is the rate of failure to detect; darn that could be valuable information for security managers. What is less clear is how this would compromise system security unless the detection rate is extremely poor. If the system had a high rate (say 80% for the sake of discussion) that would warn attackers to stay away since there attack would have an 80% chance of being detected at the perimeter. On the other hand, if the detection rate were low (say less than 20%) that might make the attacker more willing to risk the attack.

Missing Information

While one can understand why much of the redacted information is not available, the information that is specifically missing from the report is much more bothersome. One of the general complaints about automated surveillance systems is their relative high-rate of nuisance alarms (natural environmental movements that set off the detectors) or false alarm (inappropriate detections with no known cause) rates. Those rates are missing from this report.

In the ‘Scope’ section of the report the author notes that the evaluation period was insufficiently long to establish nuisance or false alarm rates or to determine their cause. I find this hard to believe when there was time enough to evaluate 900 intrusion attempts by two field testers. At the very least the report should have included information about the number of nuisance or false alarms observed during the test period. This may not be statistically sufficient to establish a true rate, but it would provide valuable data in any case.

What concerns me more is the fact that the report states the reason the report could not distinguish between nuisance alarms and false alarms (an important distinction) was that the causes of alarms “had not been recorded by BUF (airport security personnel) personnel” so there was no way to verify alarm type. This would seem to indicate that security personnel were not really paying attention to the alarms on their system, or at the very least were not investigating alarms sufficiently to determine if an intrusion were actually taking place. This is not a fault of the report, but rather of the security management at the facility.

Interestingly, in the discussion of the results portion of the report there is a large redacted box in the section dealing with “Nuisance and False Alarm Reporting” (page 12, 24 Adobe). It would be really nice to know what was discussed there.

Overall Report Evaluation

I’m glad to see that TSA is having this type of system evaluation done. Unfortunately the usefulness of the information presented is compromised by the redaction of evaluated data. In most cases I can understand and even agree with the reasoning for the redaction in the public presentation of this data. For this to be worthwhile, however, TSA is going to have to find a way to make the un-redacted information available to airport security managers and security managers at other critical infrastructure sites. Otherwise this report will just sit on a shelf collecting dust.

ICS-CERT – Two New Advisories but Two Alerts from Last Week still Missing

2012-01-24T23:24:00.000-05:00

This afternoon the DHS ICS-CERT published two new advisories, both with multiple vulnerabilities. The advisories are for Ocean Data Systems’ Dream Reports and MICROSYS’ Promotic systems. Strangely missing are the two alerts that I predicted this weekend for vulnerabilities publicly disclosed by the Digital Security Research Group (DSecRG).

Ocean Data Systems Advisory

Rios and McCorkle reported the two vulnerabilities addressed in this advisory. The first is a cross-site scripting vulnerability that is remotely exploitable and does not require much in the way of skills to execute. The second is a write access violation vulnerability that is a tad bit more complicated to exploit, requiring a successful social engineering attack and the creation of a specially crafted data file.

Ocean Data Systems has published a new version of the Dream Report product that has been confirmed to be free of these two vulnerabilities. Separate CVE numbers have been assigned, but are not yet active.

MICROSYS Advisory

While it is not mentioned in this advisory, it is an update of an alert issued last October for three vulnerabilities found in the Promotic HMI. Those vulnerabilities were reported by our friend Luigi. The vulnerabilities identified were:

• Directory Transversal, CVE-2011-4518;

• ActiveX Stack Overflow, CVE-2011-4519; and

• ActiveX Heap Overflow, CVE-2011-4520

All three are remotely executable by a relatively low-skilled attacker. The first could be used to cause some data leakage and the other two could be used as part of a DOS attack. The latest version of Promotic is free of these vulnerabilities and is downloadable from the MICROSYS website. The above listed CVE numbers are not yet active.

Missing Alerts

Last Sunday I noted that in addition to the WAGO vulnerability covert in an ICS-CERT alert from Friday, there were two other system vulnerability reports from DSecRG describing vulnerabilities in Tecomat PLCs and the Open Automation Software (OAS) OPC system. Both of those should have received ICS-CERT alerts on Friday or yesterday. There were still not yet posted as of 20:30 EST today; curiouser and curiouser.

Reader Comment: Basecamp Communications Devices

2012-01-24T08:22:00.000-05:00

It took me a while, but I finally got a chance to ‘moderate’ a response to this weekend’s blog post on the Basecamp disclosure process from Dale Peterson; one of the drawbacks to traveling cross country by car is that you can’t do much work on the internet. Dale explains the reasoning for including the Koyo ECOM100 and notes that the Schweitzer alert was for a wireless communications device, the SEL 2032 Communications Processor.

As Dale points out, vulnerabilities in the communications nodes between the PLCs and the control system are essentially major vulnerabilities for the control system and the PLC; they can allow protected access to both. As such they were clearly fair game for analysis.

The only point that I was trying to make about the ECOM100 being a ‘ringer’ (and the same point should have been made about the Schweitzer device) is that the PLC vendors had clear public notice about what was going to happen with the research into their devices. Since they should have known about the disclosed vulnerabilities (especially the ones that were specifically designed into the systems), they have no cause to complain about the ‘uncoordinated disclosures’. They are the ones that put their customers at risk not Project Basecamp.

Unless the Project Basecamp team provided direct notification to Koyo and Schweitzer about their products being included in the evaluation, the same blanket dismissal of concerns does not apply. On the other hand, the process industry really does need to understand that these types of devices (and I assume that the same types of vulnerabilities will show up in many if not most of these types of devices currently in use) may provide a broad avenue of attack on control systems. This clearly needs to be recognized and addressed.

So with the caveat that the following does not apply if they received advanced notification of inclusion in the Project Basecamp investigation, I think that both Koyo and Schweitzer were poorly treated by an uncoordinated disclosure of their vulnerabilities. More importantly their customers may have been unduly put at risk by not allowing these two manufacturers a chance to correct the system defects before the vulnerabilities were made public.

Twenty lashes with an al dente noodle for each of the uncoordinated disclosures for these two manufacturers (again with an immediate pardon if they received advanced notification of inclusion in the process) to Dale Peterson for his unsportsmanlike conduct. On the other hand, I think that it is time to look at all of the devices and systems that we employ to control critical processes, so a small quiet kudo to Dale as a salve to his wounds for his efforts (and of course the hard work of the entire Project Basecamp team and supporters) to bring formal attention to this problem.

The Disclosure Debate – Basecamp Disclosures

2012-01-23T09:57:00.000-05:00

I have been asked to weigh in on the ongoing debate about the recent PLC vulnerability disclosures by Digital Bond’s Project Basecamp. The apparent assumption behind the request is that since I am not a cybersecurity researcher, but rather a chemical facility security advocate, that I might have a different set of insights into the disclosure process. As I am almost always willing to provide my opinion on just about any topic, I could hardly turndown the request.

Ground Rules

First off I have to make clear that I have a professional relationship with Digital Bond. I periodically post on their blog about cybersecurity legislative matters. Dale Peterson has asked me to do so periodically, but he does not provide any remuneration beyond the access to a wider audience for my musings. He has personally made clear to me that I would have to really work hard to piss him off enough with any Project Basecamp criticisms to harm our professional relationship. That’s good to know, but it doesn’t really influence what I would write; people who know me well realize that I will express my professional opinions almost completely regardless of who will be upset by them or impressed by them.

Second, readers of this blog will almost certainly be aware that I generally come down on the side of full and open discussion of vulnerabilities. Over the last 4½ years I have described a number of potential physical vulnerabilities for chemical targets and discussed how they could most probably be successfully attacked by terrorists. I usually leave out critical details that only a well-trained terrorist or military man would be aware of so as not to encourage wannabes, but those details are not going to affect the response of defenders in any material fashion. And that is the key to the discussion of vulnerabilities on this blog; they are provided so that owners and operators of high-risk chemical facilities might better understand the risks they face.

Finally, I am not now, never have been, nor probably ever will be the owner of a control system. I have been a user as a process chemist, but I have never been responsible for the purchase, set up or protection of an industrial control system. It may be a subtle difference, but I don’t want anyone thinking that my musings in anyway represent the opinions of any portion of the chemical security community beyond the owner of this blog.

The Vulnerabilities Exist

The vulnerabilities that were discovered by Project Basecamp exist and have existed for some time. The Project Basecamp team went looking for these specific vulnerabilities because they exist in other PLCs, specifically the Siemens PLCs. And no one was really surprised that they were able to find these particular vulnerabilities.

The designers of these PLCs knew that these vulnerabilities were there. In many cases the vulnerabilities were apparently specifically designed into the equipment. The vendors could have corrected these vulnerabilities at any time.

Finally, Project Basecamp has been in the works for some time. Dale has been talking about what the team was going to be doing for quite some time. Nobody in the vendor community or the security researcher community or in the regulatory community should have been surprised by the results or the way in which they were communicated at the end of the Project.

Systems are at Risk

The facilities that use control systems that use these PLCs are at risk for potential attacks on their facilities employing the vulnerabilities that were reported by the Project Basecamp team. They have been at risk for such attacks since they first employed these devices. There has been some incremental increase in the level of that risk since Basecamp disclosures were made; how much of an increase no one really knows for sure.

The lack of surety is due to the fact that no one knows who else has been working on discovering the details behind these vulnerabilities and has already developed specific attack vectors using these vulnerabilities. In fact, using the Stuxnet model (or even the Duqu model) we don’t know how many facilities may have already been successfully attacked using these vulnerabilities.

Dale obviously selected a good team, but I would be extremely surprised if there weren’t hundreds of security researchers out there with skills at least as good as this team. Yes, I said hundreds. Do not forget that China and Korea (and probably Russia and India and Israel and …) have specifically gone about developing offensive cyber-warfare capabilities which would require developing thousands of cyber security research specialists; many of which would of necessity be focused on industrial control systems. And that’s not even considering the cyber-criminal underground that certainly exists.

The Upside

What has certainly increased is the awareness that these specific vulnerabilities exist and the methods to exploit them are now generally available. Any cyber-security contractor, ICS owner, or government regulator can use these tools to determine if a specific ICS installation is susceptible to attack using these vulnerabilities.

There will be some installations where other security measures already in place make an outside attack very difficult or perhaps impossible (I wouldn’t hold my breath waiting on that) to attack. There will be others where the local Junior High School computer nerd can own the facility. Most will fall somewhere in the middle between these two extremes.

Knowing the specific level of vulnerability and the mode of attack that could be employed, security controls can be put into place to mitigate (though certainly not eliminate) the risk of attack using these specific vectors. Most of these are well known and understood. ICS-CERT (and Digital Bond) have been talking about them for years.

Regulators should take specific note of the tools made available via the Project Basecamp disclosures. Any security inspection at a power transmission facility or high-risk chemical facility that does not use include the use of these tools to evaluate the security of the control systems employed at that facility cannot be called a real security inspection (Congress please note that this reality should be included in any ‘comprehensive cybersecurity legislation’ being developed in this session). ICS-CERT should immediately develop a training program for Federal, State and local government security inspectors in how to utilize these readily available tools to conduct such inspections.

The Downside

Sorry Dale. Your team has significantly lowered the knowledge threshold required to design and implement an attack on any control system using these devices. You have increased the number of potential attackers with the necessary skills to effect successful attacks using the tools that your team made possible. You are going to continue to catch some heat for that and it is certainly deserved. But you all knew that going in.

The Exception

Dale did slip a ringer in on us. Project Basecamp was advertised as a look at the vulnerabilities in PLCs. Including the Koyo ECOM100 was a bit of a surprise since it is not a PLC by any stretch of the imagination. I am surprised that no one has called Dale out on including this Ethernet connection device in the Project Basecamp investigation.

If they hadn’t found so many critical vulnerabilities in the ECOM100 I would have been one of the first to cry ‘Foul’. Realistically though, the communications between the PLCs and the control system are an important part of the operation of the PLCs. The wide spread implementation of Ethernet connections have made the modern use of the PLC possible; the older method of hardwiring each PLC was just too time consuming and the source of too much system downtime.

I only wish that Dale’s team had included a wireless server instead of an Ethernet device. These are becoming more widespread. In my opinion vulnerabilities in these servers potentially pose a much higher threat to the next generation of control systems as they may provide another undocumented link to the outside world.

The Way Forward

Cyber attackers will always respond quicker than system owners. But maybe we as a society need to have a public, very visible, successful attack on a modern control system. We need to understand that every tool has inherent risks associated with the tool. We require manufacturing facilities to have guards and safety devices in place to protect the workers from the inherent dangers associated with modern manufacturing equipment. Those guards and devices are now an integral part of the machine design, installation and maintenance process at modern manufacturing facilities. We really need to get to that same point with cyber-security tools.

So, maybe Project Basecamp disclosures will become the ICS version of ‘Unsafe at Any Speed’ or ‘The Silent Spring’ or even ‘The Jungle’; making the inherent vulnerabilities in modern industrial control systems more widely known. Industry never did appreciate Nader, Carlson or Sinclair, but society owes them all a large vote of thanks.

Thanks Dale.

ICS-CERT Publishes Five S4 Based Alerts Plus Two Other Alerts

2012-01-22T12:50:00.002-05:00

On Friday the DHS ICS-CERT published 7 separate alerts, five of which referenced vulnerabilities that were publicly discussed at Digital Bond’s SCADA Security Scientific Symposium (S4) in Miami, FL. These alerts, combined with a similar alert published on Thursday, may mark just the tip of the iceberg as Dale Peterson noted on the DigitalBond.com blog that 30 students at a HMI hacking class before the actual symposium “were quickly finding 0days using ActiveX and File Format Fuzzing”.

Oh yes, the two other alerts. They were based upon uncoordinated disclosures by the Digital Security Research Group (DSecRG) for systems produced by WellinTech and WAGO.

S4 Alerts

The five S4 alerts issued Friday included a general alert for disclosures made during the Project Basecamp portion of S4. The alert notes that the reported vulnerabilities in multiple vendor products included “buffer overflows, backdoors, weak authentication and encryption, and other vulnerabilities that could allow an attacker to take control of the device and interfere or halt the process it controls” (page 1). The four other S4 related alerts dealt with specific vulnerabilities in systems from four separate vendors; those vendors were:

• Rockwell Automation

• Schneider Electric

• Koyo (Note: not a PLC vendor, but an Ethernet vendor that provides communications between PLCs and the actual control system)

• Schweitzer

Project Basecamp was a detailed search for and reporting of vulnerabilities in various PLC’s used by industrial control systems. Dale has become increasingly vocal over the last six months or so about his dissatisfaction at cybersecurity community’s disregard of the consequences of the insecure design of programmable logic controllers (PLC). In both his blog and in any other venue that would listen (or even pretend to listen) he has made it clear that everyone in the control system vendor and researcher community has known for at least 10 years that the basic PLC design has inherent cyber-security flaws that make them vulnerable to attack. These vulnerabilities were made painfully clear in the design of the Stuxnet virus.

Because the Stuxnet worm exploited vulnerabilities in the Siemens PLC, many of the Siemens security flaws have been publicly documented, while the rest of the industry breathed a sigh of relief that their systems weren’t being used by the Iran’s nuclear program. The whole point of Project Basecamp was to formally tell the world that Siemens was not alone in their ‘insecure by design’ problems.

That the world, at least the security professional side, has taken notice cannot be doubted. There has been significant discussions in a number of forums (on LinkedIn.com and on the SCADASec list for instance) and in the cyber related press. Unfortunately, most of that discussion has been about the public disclosure of the vulnerabilities (along with some Metasploit® modules published to aid in the exploit of those vulnerabilities) rather than on the potential effects of the vulnerabilities on real world control systems. Hopefully, the fait accompli provided by Dale and the Basecamp team will eventually allow for a more detailed discussion of the vulnerabilities and how to protect control systems from attack using those vulnerabilities.

ICS-CERT does make a valuable contribution (with a forgivable sideways slap at Project Basecamp) to that inevitable discussion in the general Basecamp alert. They note (page 2):

“This public release increases the potential for cyber attack on these devices, particularly if the devices are connected to the Internet. ICS-CERT reminds users that the use of readily available and generally free search tools (such as SHODAN and ERIPP) significantly reduces time and resources required to identify Internet facing control systems. In turn, hackers can use these tools combined with the exploit modules to identify and attack vulnerable control systems. Conversely, owners and operators can also use these same tools [emphasis added] to audit their assets for unsecured Internet facing devices.”

But, less anyone forget, the Iranian PLCs that were the Stuxnet target were not connected to the Internet, nor were their control systems. Many of the vulnerabilities reported by the Project Basecamp team will allow an attacker to exploit the vulnerabilities without having to target an internet connected PLC; it will require a higher skill level and more system knowledge. There are loads of attackers with the appropriate skills and system knowledge can be easily obtained via social engineering attacks. Internet-isolated control systems (if there are really such things in existence) are not safe from attacks based upon these vulnerabilities.

WellinTech Alert

The WellinTech alert provides initial information on a reported password encryption vulnerability in the KingSCADA product that could allow an attacker to read and use a user password, thus gaining user level access to a control system. Exploiting this vulnerability requires access to the SCADA server.

WAGO Alert

The WAGO alert concerns multiple vulnerabilities in the I/O System 750. The vulnerabilities include:

• Remote firmware download;

• Remote data leakage; and

• Remote access.

Interestingly a DSecRG press release notes that the WAGO disclosure of the 750 series controller vulnerabilities was made in support of Project Basecamp. Additionally the DSecRG web site notes two other control system vulnerabilities released by DSecRG on the same day. One deals with a default password vulnerability on Tecomat PLCs (more Project Basecamp fallout?) and an ActiveX vulnerability on an OPC system. I expect that we’ll see ICS-Alerts on these on Monday.

Latest Edition of CRS Report on Chemical Security

2012-01-20T09:23:00.000-05:00

Yesterday Steven Aftergood, over at Secrecy News (a publication of the Federation of American Scientists) published a link to the latest Congressional Research Service (CRS) report on Chemical Facility Security. This is a recurring report on the CFATS program providing Congress with a summary of the issues and options that Congress might have for dealing with those issues.

I’ve written about earlier versions of this report and as is usual for the CRS this latest version provides a good summary of the CFATS program and the political issues currently facing the program. Of special interest is the funding summary chart provided on page 4 (page 8 according to Adobe) and the chart describing the current number of facilities regulated under CFATS by tier on page 5 (9 Adobe). The CRS researchers provide information in these charts that is not generally and/or readily available to the public.

The report also provides the most current numbers (2011 year-end) for the inspection process at CFATS facilities. It reports (page 7 – 11 Adobe) that DHS has conducted 180 pre-authorization inspections, has approved 50 site security plans (presumably a little over half of the current Tier 1 facilities) and has yet to complete a single implementation security inspection (insuring compliance with the site security plan). I suppose that the 180 pre-authorization inspections means that these have started on the Tier 2 facilities, but it could also mean some number of multiple inspections at Tier 1 facilities.

For the first time I find that I am going to have to criticize a portion of the report, the section dealing with the current management issues. The single paragraph describing these problems the CRS report mainly relies on the FoxNews.com article that most of us have also had to rely upon. The only information received from DHS on this subject was personal communications between the report author and the “Department of Homeland Security” on January 5^th that confirmed that Under Secretary Beers had requested the report and that “DHS expects to assess the success of

the action plan and revise it as necessary” (page 8 - 12 Adobe). Obviously the CRS researcher was not given access to the DHS report, a serious DHS shortcoming in my opinion.

Given that only shortcoming (and it is certainly not the fault of the CRS author, Dana A Shea) I still recommend that anyone interested in chemical facility security or its regulation and legislation to get and read this report. Kudos to FAS for making these CRS reports readily (and freely) accessible to the public that paid for them.

EPA Sends Final Rule form 2012 Methyl Bromide Exemptions to OMB

2012-01-20T07:22:00.000-05:00

Yesterday the Office of Management and Budget (OMB) web site announced that the Environmental Protection Agency (EPA) had submitted for approval the final rule for their 2012 Critical Use Exemption From the Phaseout of Methyl Bromide.

As has been the general practice at EPA for some time now, internal delays have pushed the publication of this rule past the time when it needs to be published to allow for industry to properly plan their production and importation requirements. One would assume that once again the EPA has notified by letter the producers and importers of methyl bromide of the actual amounts that will be authorized regardless of the outcome of the rulemaking process. EPA estimates that the final rule will be published in March; I predict after June.

[Insert standard complaint about DHS not including methyl bromide in the CFATS list of chemicals of interest (COI) because EPA was supposedly phasing out the use of this chemical in 2005]

More interesting is the fact that the OMB web site provides information on this rule making progress based upon the Fall 2011 Unified Agenda of Regulatory and Deregulatory Actions. Typically OMB and the various Executive Branch Departments provides notices in the Federal Register when this updated agenda is published; hasn’t been done yet. I will be looking at the Unified Agenda items for DHS that affect chemical and cyber security in more detail in a future blog.

ICS-CERT Publishes Alert for Disclosure at Digital Bond’s S4 Conference

2012-01-19T23:30:00.000-05:00

This afternoon the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published an alert for a vulnerability that was disclosed during today’s presentations at the SCADA Security Scientific Symposium (S4) put on by Digital Bond (full disclosure; I have provided some blog posts for Digital Bond over the last year or so). The alert is based upon information presented by Reid Wightman about the GE D20ME PLCs.

The advisory mentions two vulnerabilities; data leakage and arbitrary code execution. It does not mention the password retrieval tool mentioned in Dale Peterson’s blog post this evening about the day’s presentations at S4 or in the press release from Rapid7.

It is almost certain that more vulnerability alerts will come out of these discussions and classes in Miami this week.

No Hearings on ISCD Issues – Really?

2012-01-19T08:45:00.000-05:00

Alexis Rudakewych, the Government Relations Manager at SOCMA has an interesting guest-blog post over at ChemicalProcessing.com that addresses the problems with the CFATS implementation that were made public a couple weeks back in a FoxNews.com article. In the posting she makes the very predictable (and in very many ways legitimate) argument that the current issues provide further argument for providing the CFATS program with a long term extension of the current authorization without substantial modification. Her arguments are well reasoned and certainly worth reading.

She makes one comment though, that I must take exception to. She states that:

“This news could easily derail the advancement of any of the three pending CFATS bills in the House and Senate, all of which have already been approved by their respective committees, and instead redirect Congress's attention to oversight hearings on the program in lieu of a multi-year authorization.”

While the CFATS program is small potatoes in the great scheme of the federal government (so small that it isn’t even a line item in the budget) it is an important part of defending the United States against potentially serious terrorist attacks. It is arguably the single most important program defending against the terrorist use of WMD against the homeland.

We now have a situation that has developed over the last couple of years where the implementation of that program has virtually stalled because of apparent management issues. I say apparent because it appears that no one, including Alexis, has seen a copy of this internal DHS report. For Congress to continue funding this program without a serious and public look at these management issues (and the Department’s plan for resolving them) would be political malfeasance of the highest order.

Industry has spent a great deal of time, money and other resources preparing for the site security plan approval process. They are almost certainly going to have to spend even more before the process is complete. I would think that industry would want more than just the unsupported assurances of the NPPD management, the same management that apparently failed miserably in its oversight of the program in the first place, that the problems were being fixed.

If industry really wants to have long-term authorization of this program pass, they should be demanding an immediate hearing (maybe even a joint hearing) on this issue in the very near future along with a public reporting of the internal investigation. Hearings should go beyond the routine appearance of Undersecretary Bears and Director Anderson. It should include the full management team of ISCD, union reps (as the unions were apparently blamed for being part of the problems) and at least one regional commander of the chemical facility inspectors. It might not be a bad idea to also include some of the original management of ISCD to see if the current problems actually had their roots in the initial design of the program.

CFATS is too valuable a program to let it die from lack of attention. If something isn’t done soon to correct these problems industry is going to reduce its support for the CFATS program. Money budgeted for security spending will be cut back so that it can be applied to money making efforts that improve their bottom lines.

I have long maintained that the failure of both sides to come to a reasonable compromise on the IST issue has doomed this program to a year-by-year reauthorization standard. This problem is going to make it more difficult to get the necessary support necessary for the long-term reauthorization process to be completed. Failing to publicly deal with the problem will make it impossible.

ICS-CERT Upgrades Schneider Alert and Issues New Luigi Advisory

2012-01-19T00:50:00.000-05:00

Today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published two new advisories covering vulnerabilities in two ICS systems. The first upgrades an alert from December concerning multiple credential vulnerabilities in various Schneider systems and the second addresses a vulnerability in Certec’s atvise SCADA/HMI product.

Schneider Vulnerabilities

This advisory upgrades the information on an alert on various Schneider ICS products that was published last month. As noted in that alert that there were three separate hard-coded credentials in various Schneider applications involving the Telenet port, Windriver Debug port and the FTP service. This advisory confirms the earlier report that Schneider has developed and has now made available patches to deal with the vulnerabilities in the first two services, but the FTP service remains vulnerable to attack on some portion (maybe all, it is not clear in the advisory) of the affected systems. Schneider is continuing to work on a mitigating patch for the remaining vulnerable service.

Interestingly enough, the patches now available remove the vulnerable services (more accurately two of the vulnerable services) from the products. They were apparently included to allow remote maintenance and diagnostics of the products. Again, apparently this was the reason for the hard-coded credentials; it did not allow the owner-operator to inadvertently lock-out Schneider’s access to the system. Of course it did not allow the owner-operator to deliberately lock-out Schneider either and that is a security issue; the lack of access control.

Once again, I want to raise the issue about access to critical systems at high-risk chemical facilities. CFATS requires that anyone with unaccompanied access to critical systems at high-risk chemical facilities must be vetted against the Terrorist Screening Database (TSDB) and have other unspecified background checks completed before they can be given access to the critical systems at the facility. Who is going to ensure that all of the techs at Schneider (and any other vendor with remote access to control systems) have been properly vetted in accordance with the CFATS regulations?

NOTE: The CVE file for these vulnerabilities is already available.

Certec Vulnerability

The second advisory is for a newly reported vulnerability in the Certec’s SCADA/HMI product; atvise. The unnamed vulnerability (The advisory actually calls it a “denial of service (DoS) vulnerability”, but that describes the result of an attack not the vulnerability.) was reported by our old friend Luigi. Since this is an ‘advisory’ instead of an alert and it includes a mitigation, it would appear that Luigi has completed his second or maybe third coordinated disclosure. Actually, that’s not fair; Luigi’s name appears next to a number of upcoming ZDI (Zero Day Initiative) advisories.

This Voldemort vulnerability (okay forgive the Harry Potter® reference; Lord Voldemort is most often referred to in the series as ‘he who cannot be named’ because he is soooo evil) would allow a low skill level attacker to remotely execute a DOS attack. Certec has created a new version of atvise that does not have the vulnerability; it is available on their web site.

NOTE: The CVE link for this vulnerability is provided but the file is not yet active.

The House Calendar

2012-01-18T07:22:00.002-05:00

With the House now officially back in session, they so notified the President and Senate yesterday, it is appropriate to look at the official calendar for the coming year. This document is the plan for when the House will meet in Washington and when individual members will be working back home in their district on the ‘people’s business’ and maybe some time on getting re-elected (Sarcasm alert).

As we saw last year the House plans on ‘working in their districts’ for at least one full week out of every month this year. Additionally we see the Easter recess (Mar. 30^th thru April 13^th) the Summer recess (Aug. 6^th thru Sep. 7^th) and the Election recess (Oct.8^th thru Nov. 12^th). All in all, the House plans on meeting in Washington on only 28 week this year; and only two of those will be five-day weeks (Sep. 10-14 and Oct. 1-5).

Interestingly, this being an election year, the House Majority Leader (who sets and publishes this calendar) already has plans for an extensive Lame Duck session with Washington meetings to be held thru December 14^th with a week off for Thanksgiving.

As always, circumstances alter cases. It would not be unusual for the home week at the end of September or the week before Christmas, for instance, to be interrupted for action on budget bills or continuing resolutions. It would be unusual, however, for any of the Washington days to be eliminated.

ICS-CERT Alert on Another Luigi Vulnerability

2012-01-17T23:03:00.002-05:00

Today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published yet another alert on multiple (two) vulnerabilities reported by Luigi. This time the affected system is the Rockwell Automation FactoryTalk SCADA/HMI. Luigi reported a malformed packet vulnerability and a read access violation vulnerability. Either would allow a remote exploit that could result in a DOS attack. As always, Luigi has provided sample exploit code on his web site.

DHS is Watching – So What?

2012-01-17T07:10:00.000-05:00

Last week Mark Hosenball did an article over at Rueters.com about DHS “operating a ‘Social Networking/Media Capability’”. It seems that he had discovered a Privacy Compliance Review document on the DHS sight describing the fact that DHS was ‘monitoring’ a large number of blogs and social networking sites. A number of activist sites have picked up the story and are chastising DHS for the invasion of their privacy and Cyptome.org has provided a copy of the January 2011 version of that document on their web site.

Sorry folks, this is old news. I blogged about this back in the summer of 2010 when an alert reader notified me that I was on the list of sites monitored by DHS. I wasn’t upset about it then, I am not upset about it now. In fact, I am flattered and pleased. Readers of this blog know that I have been trying to influence DHS policy on a number of matters and I can’t do that if they don’t pay attention to what I write.

Privacy Issue???

The whole point of blogging and tweeting is to share information. Placing these ramblings on the internet is done with malice aforethought. I intend for people, as many as possible, to read and think about my thoughts, opinions and insights. I want to have people read, assimilate, think about and respond to my musings; every political writer (and make no bones about it, this is at heart a political blog) does.

Does it bother me that DHS has monitored my postings about how they are doing or not doing their jobs? Of course not; I want them to. Maybe they will make some minor (or better yet major) changes in their processes and procedures based upon my ideas. Great, I will have helped to make them a better agency.

How can I be concerned about privacy issues with the information posted in this blog? I have deliberately set this up as an open communications device, broadcasting to the world. There is no requirement to sign-up to receive approval to read this stuff. I want everyone with anything to do with chemical and cybersecurity to read this blog. If my ego weren’t so big that I thought my ideas could improve the world I wouldn’t be spending the countless hours that I do on this blog.

I have one last thing to say about privacy and the internet; there is no privacy on the internet. If you post anything on the internet anyone will be able to see it. If you don’t know that in your soul, if you don’t realize all of the potential implications of that, if you don’t accept that, please, just blow up your computer to save yourself the ultimate embarrassment. It will come back to bite you in the most uncomfortable way possible.

Grow up people. This is not Orwell’s 1984 this is Social Media 2012. Even DHS gets that.

ICS-CERT Publishes Two Advisories

2012-01-16T23:53:00.000-05:00

Today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published two new advisories for vulnerabilities in control system programs from 7-Technologies (7T) and Cogent Real-Time Systems. These are not the common, run-of-the mill HMI vulnerabilities that we have become accustomed to over the last year or so. Security researchers are digging a little deeper into these systems.

7T Advisory

This advisory is for the 7T Interactive Graphical SCADA System. It is an unsafe search path vulnerability that would require a social engineering attack to allow a relatively low skilled attacker to gain user privileges on the system via a DLL hijack. The vulnerability was reported by Kuang-Chun Hung of the Security Research and Service Institute – Information and Communication Security Technology Center (ICST).

7T has produced a patch to resolve this vulnerability. It is available on their web site. A CVE number has been assigned to this vulnerability, but it is not yet available.

Cogent Advisory

The same security researcher also discovered two vulnerabilities in the Cogent Data Hub application. Both vulnerabilities (a cross-site scripting vulnerability and an HTTP header injection vulnerability) would require a social engineering attack to effectively exploit either vulnerability. A successful attack would principally affect the user’s web browser which could open doors for other attacks.

Cogent has a patch available on their web site. Separate CVE numbers have been assigned to the cross-site scripting vulnerability and the HTTP header injection vulnerability. Both CVE files are currently available.

WinCC vs MS Security Patches

2012-01-16T07:45:00.000-05:00

I ran across an interesting Tweet today from @siemensindustry about Microsoft security patch compatibility with WinCC. It points us at a page on the Siemens web site that is kind of scary at first glance, but is actually quite valuable for owner/operators of Siemens WinCC control systems.

The Scary

The article on this Siemens page starts out with a warning:

“In response to current events (new Trojan horse / virus), [emphasis added] we recommend consulting the Microsoft Security Bulletin MS10-046 - Critical.”

Now I don’t keep up with MS security bulletins real closely (I do automatic updates on my personal computer to avoid that necessity), but that number did seem kind of familiar. I clicked on the link provided and it became obvious why I remembered that particular bulletin number; the title of the bulletin is “Vulnerability in Windows Shell Could Allow Remote Code Execution (2286198)” and is dated August 24^th, 2010. Yes, it is the update for one of the Stuxnet ‘0-day’ vulnerabilities.

The date for this page is 2012-01-09 (translated from European to American – 01-09-12) so I immediately jumped to the conclusion that Siemens was just now dealing with this basic Stuxnet related vulnerability. A little closer reading would seem to indicate that this is a long standing Siemens page that has just been updated for the latest (December) Microsoft Windows patches.

I would like to think that all Siemens WinCC owner/operators have already installed this particular security patch, making this confusing note on this Siemens page superfluous. That is probably a dangerous assumption on my part and Siemens is playing it safe, but I do wish they would re-word that opening paragraph to make it seem less timely. Oh, and Siemens could at least mention the name of the Trojan (Stuxnet).

The Valuable

Siemens does provide a valuable service to their customers on this web page (and there is a similar page for their PCS 7 system. There is a link to a spread sheet that provides a list of the Microsoft security patches that Siemens has tested for compatibility with their WinCC system. This is important because a minor incompatibility problem between a Windows update and a control system program can shut a manufacturing facility down or even damage equipment.

The latest Microsoft release covered on this spread sheet is the December 13^th release and the earliest is 6-8-2004. At first glance it looks like all of the patches are compatible, but close examination shows some problems (See MS11-025). Siemens does note that a newer version of the patch does work on their system.

Siemens is to be commended on providing this service to their customers and I’m glad to see that they are also using TWITTER to help push this information out to the user community.

I do have a minor concern about the delay (December 13^th to January 9^th) in the publication of the compatibility information, but I do realize that the type of comprehensive system testing that is required takes some time. It would be nice if Siemens and Microsoft could work out some sort of arrangement where Microsoft could give Siemens some type of advance notification on their patches to allow Siemens to begin the testing process earlier.

A Concern

There is a link on this Microsoft Patch Compatibility page to a separate page entitled: “Why should you not install the Microsoft security patches KB2467174, KB2467175, KB2465361 and KB2465367 in WinCC, PCS 7 and WinCC Professional V11?” This is apparently a follow-up to the incompatible patches (MS11-025) that I mentioned above. The page explains that:

“Installation of one of the Microsoft security patches KB2467174, KB2467175, KB2465361 or KB2465367 causes a massive drain on resources (increase in handles) in WinCC Runtime (OS Runtime, WinCC Runtime Professional V11). This consumption of resources can lead to a standstill of WinCC Runtime.”

That certainly is not a good thing for a control system and owner/users would apparently be well advised not to install these patches.

Unfortunately, the vulnerabilities corrected by these patches would still exist in the Windows operating systems and thus make the Siemens control systems vulnerable to attack through those Windows problems (See Stuxnet). There is nothing on this page that indicates what other mitigating steps an owner/operator could take to protect their control systems from the vulnerabilities now made public by Microsoft.

Since Siemens does make the information available on their spread sheet, it is not a total loss, but a mention here would be appropriate. Also there must have been some lag time before those newer patches became available. There must have been some sort of partial mitigation steps that could have been employed to protect the control systems in the interim.

Congress Comes Back to Washington

2012-01-15T23:06:00.002-05:00

While the second session of the 112^th Congress technically started in their pro-forma meetings last week, the practical start will be on Tuesday when the House will return to an abbreviated session that will elect a Sergeant-at-Arms for the Chamber. The only other action on the agenda for the House this week will be consideration of HJ Res 98, opposing the President’s announced intention to raise the National Debt Limit.

There are some House Committee meetings scheduled for this week, but nothing of particular interest to the chemical security or cybersecurity communities.

No word yet on Senate activities on any of the web sites, but they don’t usually do any business until the State of the Union Address, which happen on January 24^th this year. The committees that I typically track don’t even have any hearings listed on their sites yet. Nothing unusual here; it’s just the way the Senate operates.

Updated 112th Congress Legislation Page

2012-01-14T15:19:00.000-05:00

Today I caught up on a large back log of updates to the status of legislation in the 112^th Congress that might be of interest to the various audiences of this blog. Here is a copy of the change notification log for the 112th Legislation page:

“Updated 12-26-11 Added HR 3523 under Cyber; Added 1966 Under Homeland; Added HR 3671, and HR 2055 under Budget; Added S 1952 under Hazmat; Updated HR 908 under CFATS; Updated HR 1540, HR 1892, HR 2112 and S 1867 under Budget; Updated HR 1411, HR 2764 and HR 2838 under Homeland; Updated HR 2845 under Hazmat; Updated HR 2906 under Cyber”

It’s been a busy couple of weeks here with my new job and all. That, plus I’ve been trying to wait for links to a number of bills that were signed at the end of the year. The GPO is still having problems with a couple of the spending bills (I can’t imagine why), but I’ve decided to go forward with what we’ve got. Besides Congress comes back to work next Tuesday and we get to start the second-half.

Electrical Transformer Attack

2012-01-13T08:49:00.000-05:00

It has been a while since I addressed an incident at a chemical facility and the lessons that it might have for security planners, but a brief news article on TheState.com brought to mind a couple of security related thoughts that I want to share.

The Incident

The article reports that a ‘massive transformer’ caught fire at a Finnchem USA chlorine production facility in Richland County, SC. It’s too early to tell what caused the fire, but there is certainly no mention of ‘terrorism’. The 2,000 gallons of oil in the transformer resulted in a very smoky fire, but there is no apparent damage to the plant and no injuries reported.

The economic effects on the chlorine production unit were described as $1.5 million, but I suspect that the longer term consequences will raise that cost substantially. The production of chlorine requires substantial amounts of electricity which was undoubtedly the reason for the oversized transformer being on-site in the first place. This transformer being destroyed effectively shuts down chlorine production for weeks perhaps months; these transformers are not easy to replace.

The Terror Potential

Forget for the moment this as a possible attack mode designed to ultimately release chlorine gas. Chlorine producers take safety very seriously and have certainly taken a hard look at what the sudden loss of their high-voltage power supply would do to process safety. Automatic shutdown processes are certainly in place and the stand-alone safety systems just as certainly have alternative power sources and probably were not served by that power network in the first place.

So why worry about this as a terror target? First off, one needs to remember that the term ‘terrorist’ loosely describes people of a wide variety of backgrounds and motivations. These, in turn, are going to shape target selection and attack methodologies. An al Qaeda type terrorist, for instance, would be more likely to go after a large chlorine release with a resulting large death toll and wide spread panic in their planning of an attack on a facility like this.

Such an attack would more likely be an anathema to an environmental terrorist; the harm to local flora, fauna and innocent humans would far outweigh any potential political advantage gained by the attack. An economic attack on the producer, on the other hand, would certainly be an encouragement to stop the production of the targeted chemical. This would make a ‘massive electrical transformer’ a relatively clean target for such a terrorist.

Potential Attackers Guide Security

Security managers and regulators alike have to remember that the ‘terrorist community’ is truly heterogeneous in its motivations, skills and political objectives. All of these are going to affect target selection and attack methodologies. Likewise the proper identification of the facility’s potential adversaries will go a long way in determining what the facility will need to protect and how it should be best protected.

TSA Publishes 60-Day ICR Notice for Rail Security Program

2012-01-13T06:15:00.000-05:00

Today the Transportation Security Administration (TSA) published in the Federal Register (77 FR 2077-2078) their 60-day notice of intent to renew their information collection request (ICR) for the rail transportation security program operated under 49 CFR 1580. The current ICR authority is scheduled to expire on April 30^th, 2012.

Description of Collection Requirements

This ICR allows TSA to collect information on four separate reporting requirements in that program. Those information collections are:

• Chain of Custody Documentation for transfers of railcars carrying ‘rail security-sensitive materials (RSSM) between shippers, carriers and receivers in High Threat Urban Areas (HTUA) (§1580.107);

• Location and Shipping Information Reporting Burden for railcars carrying RSSM (§1580.103);

• Security Concerns Reporting including security incidents, suspicious activities, and threat information (§1580.105); and

• Rail Security Coordinator (RSC) Annual Reporting RSC designations and contact information (§1580.101).

NOTE: All of the CFR references listed above are only for the freight rail security program. This ICR also includes similar requirements for the last two collections for passenger rail systems.

This notice claims that the total annual burden for this ICR is 54,023 hours. This is a significant change from the original burden estimate included in the initial ICR submission back in 2008. That submission provided the following burden estimates for the four collections:

Original ICR Burden Estimates
Collection	Respondents	Responses	Burden Hours
Chain of Custody Documentation	50	18,200	219,000
Location and Shipping Information Reporting Burden	15	150	150
Security Concerns Reporting	69,483	69,483	69,483
RSC Annual Reporting Burden	945	312	312
Total		88,145	288,945

TSA should have included a more detailed description of the burden estimates in this ICR notice, especially as regards significant changes in those estimates from the current approved ICR.

Public Comments

In accordance with the Paperwork Reduction Act requirements, TSA is requesting public comments on their intent to renew this ICR. Public comments may be submitted by email to the TSA PRA Officer (TSAPRA@dhs.gov). Comments need to be submitted by March 13^th to allow for an appropriate response in the required 30-day ICR notice.

ICS-CERT Closes-out a Luigi Alert

2012-01-12T22:50:00.002-05:00

Today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published an advisory that effectively closes out an earlier alert about a Luigi identified vulnerability on Open Automation Software’s OPC Systems.Net. It actually closes out two alerts, one of which is no longer publicly available, but you’ll have to go back and re-read an earlier blog post for that story.

The vulnerability would allow a malformed packet to be used by a moderately skilled attacker to remotely execute a denial of service attack. A CVE number has been assigned, but is not yet active. A software update is available that corrects this particular problem.

DHS Requests Nominations for HSSTAC

2012-01-12T05:23:00.000-05:00

Today the Science and Technology Directorate (S&T) at DHS posted a notice in the Federal Register (77 FR 1942) requesting applications for appointment to the Homeland Security Science and Technology Advisory Committee. The Committee provides scientifically and technically based advice to both the Under Secretary for Science and Technology and the Homeland Security Advisory Council.

There are a limited number of positions available and the notice states that currently the “strongest need is in the areas of explosives detection and biological defense research and development”. Qualified women and minorities are encouraged to apply; registered lobbyists need not apply.

Applicants should send a biography or resume and CV, along with a Confidential Financial Disclosure Report (OGE Form 450) to Mary Hanson, HSSTAC Executive Director (Mary.Hanson@dhs.gov) by January 30^th 2012.

No Longer Covered by CFATS

2012-01-11T23:58:00.001-05:00

The other day a long time reader asked me what I thought about the claims by DHS that as many as 1300 facilities has essentially opted out of the CFATS program by removing listed DHS Chemicals of Interest (COI) from their facility inventories. This seems like one of those no-brainer questions with an obvious answer of "It’s a good thing". I learned a long time ago that obvious answers frequently hide unintended consequences. So let’s look at this in more detail.

The Requirement

Let’s start by looking at the CFATS requirement for what facilities are covered by the CFATS regulations. Initially it depends on whether or not facilities have (or have had within the last 60 days) more than a screening threshold quantity (STQ) of a listed COI on site. Those facilities have to submit a Top Screen which allows DHS to determine if the chemicals combined with the location and some other undisclosed factors place the facility at high-risk for being a terrorist target. High-risk facilities are then covered by CFATS (okay it’s a tad bit more complicated than that, but it will suffice for this discussion).

Essentially a chemical makes the COI list if it has the potential for a severe off-site consequence if it is released in quantity, or it may be used to make explosive devices or chemical weapons; concentrations of the COI in mixtures and solutions matter. The STQ is set by determining the amount necessary to be a ‘severe consequence’ or a large enough explosion or CW weapon release; details and politics alter cases.

Reduce or Eliminate the Risk

It would seem obvious that if a facility sufficiently reduced their risk of terrorist attack there would be no need for them to remain under the CFATS regulation. It would also seem clear that eliminating the use of a COI or reducing the inventory of a COI still used to below the STQ should by the definition of the CFATS rules removes the facility from the high-risk category.

What is less clear is that since the vast majority of facilities that filed a Top Screen were notified that they were not at high-risk even though they had one or more COI at or above the STQ, there is an amount of a COI that constitutes a high-risk quantity (HRQ) that is equal or greater than the STQ. One would assume that the HRQ would apply only to release type COI (flammable, explosive, or toxic) and would vary depending on the relative location of local population concentrations and other potential terrorist targets.

Theoretically then a facility could reduce their inventory of their COI to below the HRQ for that chemical at that facility and the facility would no longer be at high-risk of a terrorist attack. Unless (or until) DHS is willing to share that theoretical HRQ with the facility there is no practical way of reducing the facility risk below the high-risk threshold beyond trial and error.

Practical Aspects of Risk Reduction

The most obvious way of eliminating a COI is to find a substitute chemical for your process that is not on the Appendix A list of chemicals. This is certainly what the folks at Greenpeace and any number of other environmental organizations are expecting to see if they achieve their goal of including an inherently safer technology (IST) mandate in the CFATS program. Eliminate the most dangerous chemicals and the terrorist threat goes away.

Unfortunately, there are a number of ways that a COI can be eliminated from inventory without materially affecting the risk profile of the facility. For example, I know of at least one chemical supplier that encouraged their customers to switch from 20% ammonium hydroxide to 19%; 20% is covered in CFATS, 19% is not. Does this decrease risk? Probably not since inventory levels will probably be increased because the underlying process still needs the same amount of active ingredient, ammonium hydroxide. BTW: the 20% concentration was picked because that was the standard industrial concentration; the next lower standard commercial concentration was significantly lower and safer.

Another way to effectively eliminate a COI is to reduce the maximum amount in inventory below the STQ. Amounts below that level are not reportable to ISCD on the Top Screen. If the manufacturing process still requires the same level of COI consumption (or production) this becomes a bothersome inventory management issue. With most of the release COI having STQ’s in the 10,000 lb range this would typically result in switching from bulk shipments to smaller packages with more shipments. This, in turn, leads to more handling requirements and increasing the risk of accidental releases; which much more common already than release due to terrorist attack.

Less ethical inventory games are also possible. A manufacturer may want to schedule a year’s worth of production of a product to get in a single week. The greater than STQ inventory quantity (say a rail car) of methyl isocyanate (MIC) arrives on site and is consumed within 7 days. A Top Screen is filed showing the maximum inventory and DHS starts to process the information. Then 60-days after the last MIC is consumed a new Top Screen is submitted shown 0 lbs of MIC. Sometime later the railcar load of MIC is ordered again and the submission cycle is repeated.

ISCD Management of Changing Inventory

Since the CFATS Chemical Security Assessment Tool (CSAT) does not yet have a tool specifically designed to handle the opting-out process (it’s coming in December 2011; hold your breath) ISCD doesn’t really have a way of handling these issues comprehensively. So apparently they just continue to process the new and revised Top Screens from these facilities.

So, ask me again what I think about the 1300 facilities that have disappeared from the CFATS program and I’ll ask a not so simple question in return. How many of them have legitimately reduced their risk of terrorist attack without transferring their risk somewhere else and how many of them have simply gamed the system to avoid the cost of having to install security measures to reduce their risk.

I’ll bet you even money that ISCD can’t legitimately answer my question.

CG to Study Alternatives to GPS Timing

2012-01-11T07:23:00.000-05:00

Today the Coast Guard published a notice in the Federal Register (77 FR 1708-1710) of their intent to enter into a “Cooperative Research and Development Agreement (CRADA) with UrsaNav, Inc., to research, evaluate, and document at least one alternative to Global Positioning Systems (GPS) as a means of providing precise time” (77 FR 1708).

One would assume that this is in response to the studies that indicate that the LightSquared broadband system deployment may cause significant interference with GPS signals; signals that are used in some control system applications to link physically separated timing events. I’m not sure what the Coast Guard’s interest is in these timing services and it is surely not discussed in this notice.

This CRADA envisions the testing of timing signal transmissions on four separate frequency ranges:

• LORAN frequencies (90-110 kHz);

• dGPS frequencies (283.5-325 kHz);

• HA-dGPS frequencies (435-490 kHz); and

• Former international calling and distress frequency (500 kHz).

On-air testing will be conducted with transmissions from former Long Range Navigation (LORAN) sites and “other sites as deemed necessary” (77 FR 1709). Reception will be evaluated at both off-shore and on-shore sites.

Public comment on this CRADA notice is being solicited. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # USCG-2011-1167). Comments should be submitted by February 10^th, 2012. Notice of interest in participating in a separate CRADA addressing the same issue may be submitted to the same place with the same time limit; detailed CRADA proposals would be submitted separately to LT Helen Y. Millward (Helen.Y.Millward@uscg.mil), U.S. Coast Guard Research and Development Center.

Congressional Oversight of CFATS

2012-01-10T07:47:00.000-05:00

I recently had an interesting email from a long time reader closely associated with the CFATS program. The email had a number of interesting points to make about the current problems ISCD is having with the implementation of site security plan portion of the CFATS program. Among those points was the expression of hope that Congressional oversight hearings would go beyond the ‘usual suspects’ and include sworn testimony from members, current and past, of the ISCD staff and chemical facility security inspectors.

I certainly agree that if Congress (the Senate Homeland Security and Governmental Affairs Committee and the House Homeland Security Committee in particular) really wants to get to the bottom of the problems that DHS is having with the effective conclusion of the CFATS program implementation these are the sorts of people that will have to be included in the investigation. I just don’t think that it will happen.

First off the type of whistleblower testimony that would provide the best insight into the program is political and professional suicide. Congress has only provided the standard-generic, ineffective whistleblower protections to anyone associated with the program. While direct retaliation is currently forbidden, the only enforcement provision is the filing of civil suits against the offending agency; a long, expensive and usually fruitless endeavor only designed to enrich lawyers.

Second Congress has a mixed record of oversight of executive branch program execution at best. Typical oversight hearings have senior program managers who have little to do with the hands-on implementation enduring political speeches billed as questions and providing answers that no one really listens to. The only time there is a detailed, probing questioning of witnesses is when the political opponents of a program have found evidence of political or personal malfeasance. There are no political opponents of the CFATS program.

Next there is no Congressional Committee that has oversight responsibility for the CFATS program. Currently authorized as an add-on to a funding bill, the only Committees that have ‘effective control’ over the program are the two appropriations committees and that control is limited to expanding the authorization for another fiscal year; the funding for the program is not even mentioned in the budget or spending bills.

Congressional ‘oversight hearings’ have focused on the political questions of IST not the actual operation of the program. Congress needs to realize that they are responsible for resolving political questions not program managers. Congressional oversight is supposed to focus on ensuring that the administration of programs authorized by Congress are actually fulfilling the intent of that authorization in an effective and economical manner.

That is a major part of the problem that the CFATS program is facing, Congress shares a major portion of the blame for those program failures. The inability to reach a political compromise that would allow for an effective description of the program’s responsibilities and goals has hobbled the Departments implementation efforts. Continued inaction by Congress will only continue to impede CFATS implementation progress.

Chemical Security vs Community Right-to-Know

2012-01-09T22:31:00.000-05:00

As if the EPA hasn’t created enough controversy under the Obama Administration, it is going to re-ignite a philosophical debate that was closed off under the Bush Administration after the 9-11 attacks. That debate centers around the right of a community to know what hazardous chemicals are being stored, produced or used within facilities in and around the community versus the potential consequences of terrorists using that same information to select an ‘appropriate’ target for releasing chemical warfare upon those communities.

RMP Database

Larry Stanton, the Director of the Office of Emergency Management at the EPA, has been sending emails to various organizations (see for example TaoCompliance.com) announcing that the EPA is planning on reversing its 2001 decision to remove the Risk Management Plant (RMP) database from its public web site. That site contained a listing of all facilities that were required to file a RMP because of their possession of a threshold amount of certain highly hazardous chemicals (flammable, explosive and toxic chemicals most of which also made it to the CFATS Appendix A list of DHS chemicals of concern – COI). It was felt at the time that the RMP listings would provide overseas terrorist organizations with a ready list of potential targets.

Starting in July the EPA is planning to once again to make that database available on the internet. As before it would include basic registration data but would not include the Off-Site Consequence Analysis (OCA) data as that information (and its derived analysis and ranking data) was protected from public release in 1999 by §3 of the Chemical Safety Information, Site Security and Fuels Regulatory Relief Act (PL 106-40).

This data has been technically available to the public all along as it could be accessed in EPA Reading Rooms around the country. Additionally, a number of activist organizations have made the same data available on their web sites (see for example RTKnet.org). The same information was also required to be made available directly be facilities to the appropriate State Emergency Response Commission (SERC) and Local Emergency Planning Committee (LEPC). It is also available via Freedom of Information Act requests.

Public Debate

When the EPA removed the RMP database from their internet site, it was done with the minimum of public discussion. In many ways the removal was a kneejerk reaction to the 9-11 attacks and was derided as such by many environmental and process safety advocates. Director Stanton is apparently trying to ensure that the same will not be able to be said about the decision to re-make the information available on the internet. He is publicly inviting stakeholders on both sides of the issue to become involved in the discussion before the move is made. Unfortunately, the organizations within the Executive Branch that might be expected to oppose, or at least question the move (DHS and the FBI for example) have remained mute on the topic.

I am sure that a number of organizations and businesses have already responded in private expressing their support or opposition to EPA’s announced intention to re-post the information. Unfortunately, these private comments do little to further the public debate and raise the specter of various sorts of political and/or economic pressure being applied to the Administration on the issue.

I would like to suggest that open government would be better served by a public comment procedure like that used in the development of rules and regulations. Opening a docket on Regulations.gov and accepting public comments from all sectors would provide a much clearer and open debate.

Having said that, I would like to add my very public musings about the topic to the discussion. Readers of this blog will note that I have been a strong advocate for community involvement in emergency response planning as an active part of the chemical security process for high-risk chemical facilities.

In Favor of the Posting

First let me start off by saying that J.Q. Public has an inherent need to know what highly hazardous chemicals are lurking in his neighborhood. By not knowing about the risks associated with those chemicals in his/her life he/she is at an increased risk of economic or physical injury, even death. Being able to make decisions on avoiding those hazards by moving away or taking personal protection steps depends on know what hazards are faced.

The current law {42 USC 7414(c)} and regulations {40 CFR 68.210(a)} requires that the RMP facility information be made available to the public. The current availability via the EPA Reading Rooms and FOIA requests mean that that requirement is technically fulfilled. Realistically, few people realize that the EPA Reading Rooms exist, much less know where one is. And the filing of FOIA requests is time consuming and tedious.

The provision of the information to LEPC’s is hardly more effective. With a few prominent exceptions LEPC’s are ineffective at best and a large number of covered facilities have no such organizations to report to.

Only with the information being available on the internet will the vast majority of people truly have ‘access’ to the information. Of course having access is not the same as using access or following through on the information provided, but it is an important improvement over the current situation.

In Opposition to the Posting

The reason that the EPA removed the list from the internet in the first place is that the database provided anyone with a desire to turn a chemical facility into a chemical weapon with the ability to effectively search for appropriate targets. While a local wannabe could find much of the information locally without much problem, they would not be able to gather the information necessary to optimize their target selection process. A truly effective national-level chemical facility attack would most by definition require access to such a database.

Additionally, since the RMP list of chemicals was adopted almost entirely into the DHS COI list it would make it easy to determine which facilities would have been required to submit Top Screen filings as a potential prelude to CFATS coverage. That combined with a cursory examination of the surrounding community would probably allow for a pretty accurate guess as to whether DHS had determined the facility to be at high-risk of terrorist attack. That information could easily be used to formulate an effective social-engineering cyber-attack on the facility.

Personal Opinion

Personally, I guess that I am going to grudgingly come down on the side of restoring the database. I would rather see Congress put some teeth into the current right-to-know laws and require FEMA and EPA to ensure active outreach to State and local government officials and surrounding neighbors as part of an effective emergency planning process. Since that isn’t going to happen I would rather see local curmudgeons have the information necessary to force local officials into that planning process.

Besides, I could always use the database information to do an advertising mailing to the listed facilities as a drive to get more readers for this blog.

DHS Updates CIP Landing Page

2012-01-09T08:00:00.000-05:00

DHS maintains a number of ‘landing pages’ where they post links to a wide variety of web pages on their site that might be of interest to specific homeland security audiences. Recently they updated the ‘Critical Infrastructure Protection’ landing page by adding a link to their ‘Cybersecurity’ landing page.

Since all sorts of computer systems are an integral part of each of the 18 Critical Infrastructure Key Resource (CIKR) sectors, adding this link to the CIP page was obviously a smart and somewhat overdue move. Unfortunately the cybersecurity page provides very limited information on a key function of most of the 18 sectors; industrial control systems. In fact, there is only one ICS specific link on the page; it goes to the ‘Control Systems Security Program Training’ page of the CSSP site.

Don’t get me wrong. The inclusion of the training programs page is very important. The CSSP training programs are an invaluable, if severely limited in time and resources, part of increasing the overall security of industrial control systems in the United States.

Two other CSSP programs should be specifically linked to the cybersecurity landing page; the CSSP homepage and the Cybersecurity Evaluation Tool (CET). To aid in identifying the CET as a control systems evaluation tool the listing of that tool on the cybersecurity page should probably include ‘ICS’ or ‘Control System’ in the title. Of course the CSSP homepage includes a link to the CET page, but a specific listing under say ‘Technical Resources’ on the Cybersecurity page would almost certainly increase the visibility of that tool.

Arguably the most valuable part of the CSSP site is the listing of the latest control systems alerts and advisories found on the homepage. This listing helps insure that system owners and operators get the latest information on vulnerabilities that could affect their control systems. Adding this link to the CIP landing page would increase the visibility of CSSP site.

DHS Updates Chemical Security Page

2012-01-08T20:41:00.000-05:00

On Friday the folks at NPPD’s Office of Infrastructure Protection (OIP) updated their ‘Critical Infrastructure: Chemical Security’ web page. Apparently the only intended change was to take out a link in the left column to the ‘Laws & Regulations’ page. At first glance this seems to make some sense as there is a link on the lower right hand side of the page to the ‘Chemical Security Laws & Regulations’. Unfortunately the two pages are not the same.

Removed Information

The removed link took one to a page that included both the specific CFATS related information (also found on the ‘Chemical Security Laws & Regulations’ page) and whole list of other programs, including:

• Ammonium Nitrate Regulations

• Infrastructure Protection

Both of these programs might be of interest to facilities under the CFATS program. In fact, both should be listed on the ‘Chemical Security Laws & Regulations’ page.

Bad Links

While the page was being updated to remove valuable information, OIP web masters should have taken care of two problematic links; one I’ve addressed before and a new problem.

The old problem deals with the link to the ‘CFATS Tip Line’ in the right hand column of the page. That link takes one to the ‘CFATS Knowledge Center’. It used to take one directly to the CFATS FAQ for the CFATS Tip Line (FAQ # 1620), but when the old FAQ page was changed to the Knowledge Center, permanent links to individual FAQ’s were removed. Now one has to know that #1620 deals with the Tip Line or has to search the Knowledge Center for the Tip Line FAQ; most people are just going to give up.

As I have noted on a number of occasions DHS does have a well hidden web site with information about reporting incidents (http://www.dhs.gov/files/reportincidents/index.shtm) and it includes information about the CFATS Tip line (http://www.dhs.gov/files/reportincidents/index.shtm#1). This is the link that should be on this page; not an outdated link to the FAQ.

The other bad link is not actually the fault of DHS. The GPO is changing the way a number of documents are accessed through their system. If one clicks on the link on this page to the “Chemical Facility Anti-Terrorism Standards Interim Final Rule” in the Key Documents section of the page they receive the following message:

“You are accessing regulations.gov using an old bookmark. We plan to stop supporting old bookmarks in near future. If this information is important to you, please update your bookmark. You will be redirected to the new location in 15 seconds.”

Unfortunately, the GPO does not provide a link to the document after 15 seconds. You just get one of those neat little pop-up windows that asks if you want to open or save the document; if you ‘open’ it you get the document in a .PDF window without a link. You can get the document today, but who know what will happen on this link when the GPO stops ‘supporting old bookmarks’ in the 'near future'.

What is strange is that the other four documents listed in the ‘Key Documents’ section do not have links to www.Regulations.com, but rather to pages on the DHS web site. There is no reason the Department couldn’t do the same thing with the CFATS IFR.

BTW: I do pick at the folks handling the chemical security web sites, but they are doing a much better job than just about anyone else in the Department of making valuable information available to the public. Keep up the good work, but keep setting the standards higher. Make it harder for the other folks to catch up.

NMSAC Meeting January 18-19, 2012

2012-01-08T00:14:00.002-05:00

The Coast Guard posted a notice in Monday’s Federal Register (77 FR 1076-1077) available on-line on Saturday) that the National Maritime Security Advisory Committee (NMSAC) will be holding a public meeting in Arlington, VA on January 18^th and 19^th.

NMASC Agenda

The two day meeting will cover a number of topics of interest to the chemical security community. Those topics include:

• MTSA/CFATS harmonization;

• TWIC update (including TWIC Readers);

• MTSA regulation updates;

• Vessel guard requirements in US ports; and

• Underwater Terrorism Preparedness Program.

Public Participation

A public comment period will be provided at the end of each day’s session. A maximum of 5 minutes will be allowed for each speaker. Speakers need to register with Ryan Owens (phone: 202-372-1108 or email: ryan.f.owens@uscg.mil). Written comments need to be submitted by January 9^th via the Federal eRulemaking Portal (www.Regulations.gov; Docket Number USCG-2011-0975).

As with any public meeting the seating will be limited, so advance registration is required. To maximize public participation the Coast Guard will make this meeting available by teleconference (dial 866-717-0091, the pass code to join is 3038389#) or an interactive internet connection (log onto https://connect.hsin.gov/r11254182). It would be helpful if other DHS organizations would follow the lead of the Coast Guard and make their public deliberations truly public.

Small Legal Faux Pax

Federal regulations {41 CFR 102-3.150(a)} require that advisory committee meeting notices are to be published in the Federal Register “at least 15 calendar days prior to an advisory committee meeting”. With a meeting date of the 18^th and an official publication date of the 9^th (or even a public publication date of the 7^th), this deadline was not met.

The crafters of that regulation realized that stuff happens so they made provisions for dealing with exceptions §102-3.150(b) allows for a shorter notice period under ‘exceptional circumstances’ if a clear explanation of the delay is included in publication notice. That did not happen; yet. On Friday a correction to this meeting notice appeared on the Federal Register’s Public Inspection Page; that correction will not actually appear in official Federal Register until Wednesday, January 11^th.

That correction blames the late publication on an “administrative delay due to the Federal holidays”. The Notice was signed by the Coast Guard on December 29^th and should have been published on January 3^rd to meet the GSA deadline. The delay appears to have been within the Coast Guard not the GPO. The other four Coast Guard postings in Monday’s Federal Register were signed as early as December 14^th and as late as December 23^rd.

Fortunately, with the Coast Guard providing remote access, people wishing to participate do not have to make travel arrangements to participate in this meeting. Presuming that the Coast Guard had previously alerted the Committee members and the briefers, it appears that no real harm was done in delaying the printing of this notice.

Multiple Vulnerabilities Reported in CoDeSys by ICS-CERT

2012-01-07T09:39:00.000-05:00

Yesterday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published an interesting advisory for the 3S Smart Software System CoDeSys product. The advisory actually covers 5 separate vulnerabilities in the system, one reported by Celil Unuver (SignalSec LLC; a coordinated disclosure) and five (one reported by both) reported by our old friend Luigi (Unanticipated; a new term being used by ICS-CERT for uncoordinated disclosures).

Political Oddities

Before looking at the actual vulnerabilities, let’s look at some odd things about this advisory that make it interesting. First I thought that it was odd that Luigi would report five vulnerabilities on a particular ICS at the same time that ICS-CERT was preparing to publish an advisory on the same system, containing one of the same vulnerabilities. I went back and re-read the ‘Overview’ section of the advisory to see if there had been a previous alert on the Luigi vulnerabilities and there is no listing of one.

But the CoDeSys vulnerabilities sounded familiar so I searched my blog and sure enough I reported twice (December 3^rd, December 8^th) on an ICS-CERT alert (ICS-ALERT-11-366-01A) on these CoDeSys vulnerabilities. In the latest blog on that alert I posited that it appeared that Celil Unuver had become dissatisfied with the pace of the mitigation development on the vulnerability that he had identified and as a result he publicly disclosed the vulnerability.

Now ICS-CERT normally refers back to alerts when their advisory provides the mitigation for a publicly disclosed vulnerability; no rule says they have to, but that has been their general practice. Does not referring back in this instance have to do with 3S finally getting the mitigation completed so ICS-CERT no longer wants to apply pressure to them? I don’t know, but it looks that way.

Security Implications

The second odd thing about this advisory is related to an issue that I have discussed on a number of occasions, software components. ICS-CERT has previously noted that a couple of their reported vulnerabilities could affect more than just the reported software as that product is used as a component of other control system software products (and never did identify which products were vulnerable by association). This advisory extends that problem into the hardware realm.

According to this advisory “CoDeSys is used across several sectors of the automation industry by manufacturers of industrial controllers or intelligent automation devices [emphasis added]and by end users in different industries including system integrators who offer automation solutions using CoDeSys” (page 2). I’m not sure, but it sounds to me like CoDeSys is incorporated in the firmware or software embedded within the control devices. That could, in turn, make those devices susceptible to one or more of the vulnerabilities listed in the alert. Does that mean that these manufacturers should offer firmware updated to correct the security problems? I think so.

The Vulnerabilities

As noted earlier there are five vulnerabilities listed in this advisory. They all would allow a low skill level attacker to remotely execute a DOS attack and a higher skilled attacker to remotely execute arbitrary code. The vulnerabilities are (with active CVE file links):

• Integer Overflow, CVE-2011-5008;

• Stack Overflow, CVE-2011-5007;

• Content-Length NULL Pointer, CVE-2011-5009;

• Invalid HTTP Request NULL Pointer, CVE-2011-5009

• Folders Creation, no CVE #

Luigi noted in his disclosure that the file folder creation situation wasn’t really a vulnerability since he couldn’t see how it could be used in an attack, but it was an odd enough thing that he wanted to report it. ICS-CERT seems to accept that reasoning and that may be why there is no CVE # associated with that vulnerability.

3S has produced a new version of CoDeSys that does not contain these vulnerabilities and, according to the advisory, Luigi has verified that the new version corrects these problems.

TWIC-HME Compatibility

2012-01-06T07:08:00.000-05:00

A blog post yesterday by Laurie Thomas, a frequent reader of this blog and one of my go-to sources for MTSA information, on her MTSA News blog points out that the TSA is making some efforts to harmonize some of the various background checks that it is responsible for, in this case the Transportation Workers Identification Credential (TWIC) and the Hazardous Material Endorsement (HME) to be issued with State Commercial Drivers Licenses (CDL).

Laurie points us at the ‘Latest News’ section of the TSA TWIC web site for the available information on this new program for Comparable HME’s.

(Oops… Did you know that the term ‘TWIC’ is a registered trademark? According to this web site it is, so we are in violation of trademark law unless we include the ‘®’ when we use the word ‘TWIC’. Too bad TSA, I don’t think anyone will follow this rule; you have wasted the time, effort and money. Failure to enforce trademark enfringement invalidates the registration)

I don’t get to this site often so I don’t know when this news item was posted (and TSA isn’t helpful in this regard, they don’t date entries the way the ISCD folks do over at the CFATS Knowledge Center do), but from the wording it looks like it was probably sometime last month. It says that this program will start in ‘January 2012’ and more information will be provided as the implementation date approaches.

Basically what TSA is doing is that it will use the existing TWIC background check data for the approval of an HME. This should reduce their time and cost. The cost savings will be passed on to the applicant in reduced fees; no information yet available on how much reduction there will be. Of course this requires a State to accept the Comparable HME check. The TSA site promises a list of the States that do accept it, but it’s not there yet.

It would seem to me, though, that there should be an even easier way to accomplish this. If an HME applicant (new or renewal) presents a TWIC at the State DMV office when they apply for an HME, all the DMV officials should have to do is to verify the TWIC is current and the identity matches and no TSA Security Threat Assessment (STA) fee should be required. Of course, the biometric identity verification can’t really be done until the TWIC Reader Rule is adopted in 2010 (oops, the NPRM hasn’t even been submitted to OMB yet).

Oh well, if and when this actually happens it will save drivers some money and hassle; that would be a good thing.

ICS-CERT Updates an Advisory and Issues New Siemens Advisory

2012-01-05T01:04:00.000-05:00

Earlier today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) updated a month old advisory for an Invensys product and issued a new advisory for another Siemens control system product.

Invensys Advisory Update

It’s a good thing that there was a new advisory issued today because the change on the Invensys Wonderware InBatch advisory is a small update that probably would not have been worth a standalone blog entry. ICS-CERT changed the CVE file number (CVE-2011-4870) for the vulnerability. The CVE number (CVE-2011-3141) in the original version of the advisory pointed at a different Invensys vulnerability file from August 16^th of this year.

BTW: Last week ICS-CERT started explaining the delay in activating the CVE files. The explanation is contained in the footnote containing the file link. That explanation has been on every advisory since the Siemens advisory of December 27^th and it reads:

“NIST uses this advisory to create the CVE website report. This website will be active sometime after publication of this advisory.”

New Siemens Advisory

The Siemens advisory deals with two ActiveX component vulnerabilities in the Siemens FactoryLink application. Reported by Kuang-Chun Hung of Taiwan’s Information and Communication Security Technology Center (ICST) was released on the US-CERT secure portal last month.

A buffer overflow vulnerability could allow a moderately skilled attacker to remotely execute arbitrary code via a social engineering attack. The second vulnerability is a data corruption vulnerability that would also require a moderately skilled attacker to use a social engineering attack vector.

Siemens has released a patch to address these vulnerabilities and ICS-CERT is also recommending that owner/operators should install Microsoft Security Advisory 2562937 as another part of the mitigation program for this system.

Second Session of the 112th Congress

2012-01-04T08:36:00.001-05:00

Boy, the folks over at the Congressional Record must have had a glorious drunk on New Year’s Eve since they were apparently still hung over last night. That’s the only explanation that I have for the totally f… er messed up record of yesterday’s first day of the second session of the 112^th Congress.

According to the Daily Digest, the Senate was not in session yesterday, but they will “next meet at 12 noon on Tuesday, January 3, 2012, in a pro forma session and convene the 2nd session of the 112th Congress”. Well, I guess that more than one person has complained that the Senate didn’t do anything when it was there, so yesterday they ‘will meet’ in a session that didn’t happen.

The House apparently did meet in pro-forma session, they adjourned three minutes later and then reconvened 52 minutes later to adjourn Sine Die one minute later. Maybe the Speaker pro tempore’s father didn’t tell him about going to the bathroom before starting something important.

It’s not clear when the two bodies will meet again, though the Constitution does call for them to meet on January 17^th. The last page (D 1408) of the Daily Journal notes that they will both meet next on January 3^rd at 12 noon.

Thank goodness there was no real news to record in the official record of the Congress of the United States for January 3^rd; whenever that will be or was. I just hope that this isn’t an omen of things to come.

NOTE: As of 13:50 pm EST, 1-4-12, the above Daily Digest link now takes one to a new version of the Daily Register for January 3, 2012. The new version makes a lot more sense and starts new page numbering as one would expect for the first entry for the second session of the 112th Congress.

Dow Hack Prediction

2012-01-04T07:30:00.000-05:00

Yesterday I made a late entry into the ‘Predictions for 2012’ game that is standard fare for so many columns and blogs. In the closing paragraph I made prediction that caught a lot more attention than I had expected. I wrote:

“I’ll go out on a very thick limb here and predict that we are going to see major new action in the merger of political activism, the anarchy movements, and computer hacking. This will be the source of major news stories for this year. I would not be surprised to hear that DOW gets major attention for their sponsorship of the Olympics and it could include one or more control system hacks, most likely a DOS type attack shutting down one or more production facilities.”

Dale Peterson over at DigitalBond.com (which I periodically write for) was kind enough to tweet that this was a “bold, specific prediction”. I certainly thank Dale for that comment as it did draw some new readers to this blog, but a closer look at my reasoning will show how easy a prediction it was to make.

Dow as a Target

I have long maintained in this blog that potential threats against high-risk chemical facilities come from far more than just al Qaeda and its loosely linked wannabes. The radical fringes of the environmental movement have long lists of reasons to want to attack chemical companies in general and Dow has got to be high on their list of ‘environmental evil doers’. Dow is a large scale developer, producer, storer and transporter of a number of hazardous chemicals.

When Dow bought Union Carbide ten years ago, they not only acquired new product lines and production facilities, but they also inherited the blame for the 1984 Bhopal ‘gas tragedy’ and the 2,000 to 8,000 deaths associated with that accident. Because of this the International Olympic Committee has come under fire for their accepting Dow’s donations to become an Olympic sponsor for this year’s summer games in London. Demonstrations against, and political attacks on, Dow will certainly continue through the Games this summer.

Finally, Dow is a large multi-national corporation with major amounts of political pull and power in Washington and other capitals around the world. This brings them to the attention of various anarchist movements, making it a potential target for any number of groups with an increasing propensity for small-scale violence and demonstrated capabilities for disruptive behavior and attacks.

Eco-Cyber Attacks

Terrorists always have something of a moral dilemma that they have to deal with; the more successful their attack the larger is the number of innocents that are harmed or killed. When outright psychopathy is not involved this dilemma is resolved by claiming to work for the greater good or even blaming the innocents for complacent complicity in supporting the evil being attacked.

Environmental terrorists have to deal with this quandary as well as the dilemma of their attacks harming the very environment that they are attempting to protect; it’s hard to claim that the environment is complacent. This is one of the reasons that the damage caused by environmental terrorists to date has been physically limited, but this has also limited their political and propaganda exposure.

If a way could be found to limit the environmental consequences of their attacks the number of potential eco-terrorists would increase as more mainstream activists would be able to resolve their moral problems with attacks that cause chemical releases. This favors disruptive attacks more than the ‘conventional’ bomb-throwing, destructive attacks.

This is one of the reasons that I think that we will see the rise of the eco-cyber-attack. Attacks on the control-systems and inventory-management systems of chemical facilities would be just the type of disruptive attacks that could attract larger elements of the environmentalist communities. They would be able to disrupt the production and distribution of objectionable chemicals without causing physical harm to neighboring innocents or the environment.

Anarchists are likely to see the larger benefit from this type of attack as well, but they won’t be as limited in their target selection. Political and economic process controls will also be very susceptible to this type of attack with data centers being prime targets.

Dow as Cyber Security Leader

There is one factor that I did forget to mention in my original post, Dow Chemical has been a leader in the chemical industry for the development of cyber security defenses. I do not know how much of that has been concentrated on the process-control side of their computer systems, but I would suspect that they would have some of the best protected control systems in the industry.

While this would make it more difficult to conduct a DOS style attack on Dow control systems, it would certainly not make such an attack impossible or even unreasonable. With the proliferation of control system vulnerabilities (particularly those favoring DOS attacks), I would be very surprised if a dedicated hacker couldn’t find a way to make it happen.

And don’t ever forget that in the hacker community the more difficult the target the more credit the successful hacker gets for their accomplishment. And the easier it will be for less skilled followers to use the same techniques on less well protected systems.

Welcome to 2012

2012-01-03T08:06:00.000-05:00

Today is the first business day of the New Year and marks the official end of the Holiday Season. It also is a good time to review what is in store for the chemical- and cyber-security communities for the new year.

Congress

In case you hadn’t noticed this is another election year with all of the House members, 1/3 of the Senate and the President up for election. As we proceed with the year the amount of influence that these pending elections will have on Congressional Action will become more and more pronounced.

We finally got the FY 2012 budget settled at nearly the last minute of last year. Today marks the start of the new budget process. The President will submit the FY 2013 budget request later this month. Congress will hold some hearings where the Department Secretaries explain what the President is asking for, but will otherwise ignore the budget request. There will again be major disputes between the House and Senate and most of the budget will be resolved in a lame duck session in November and December.

We may get stand-alone CFATS legislation passed in the House before the Summer Recess, but that might get held-up by hearings on the ISCD report. There are still no indications about which House bill will get considered, but which ever makes it to the floor will almost certainly get passed. I do expect some interesting amendments will come out of the ISCD problems. There will almost certainly not be any Senate action on the bill before the elections. Lame duck action will depend on the election results.

Cyber security legislation will almost certainly pass early this year. The main focus of the legislation will be on IT and personal information security issues as well as the security of federal computer systems. Only minor bones will be thrown to the control system community.

DHS

Problem solving at ISCD will further slow the implementation of site security plan approvals for the first part of the year. It’s hard to tell for sure how long without seeing the actual report, but it could get further slowed by Congressional assistance. Hopefully we will see ISCD action on at least some of the following promised actions:

• CFATS De-enrollment Tool;

• Personnel Surety Tool;

• Update of SSP Tool;

• Update of Appendix A; and

• MTSA Harmonization.

We will almost certainly not see any further action on the Ammonium Nitrate Security Program in 2013.

There may be some movement on MTSA related issues this year as we are expecting to see some new rulemaking for CFATS harmonization, a variety of TWIC issues and the long expected TWIC Reader Rule. Unfortunately, none of that will be final rules.

TSA could be the surprising actor this year with action on the long-overdue trucking and railroad security training rules. There could be more backing into regulatory action on pipeline security. Again we are a long way from final rules on any of that.

Hacktavism

I’ll go out on a very thick limb here and predict that we are going to see major new action in the merger of political activism, the anarchy movements, and computer hacking. This will be the source of major news stories for this year. I would not be surprised to hear that DOW gets major attention for their sponsorship of the Olympics and it could include one or more control system hacks, most likely a DOS type attack shutting down one or more production facilities.

Chemical Inspectors and ISCD Problems

2012-01-01T08:57:00.000-05:00

I got an interesting email from a reader last week who has an interest in becoming a chemical facility security inspector (CFSI) for the CFATS program at DHS. After reading the FoxNews.com story about the problems at ISCD he was concerned about how those problems might affect his prospects for future employment in that area. That question has specific meaning for the reader, but is also of a more generic concern for the chemical security community.

First off, let me make clear that, in my opinion, the CFATS program is going to be around for quite some time. There has been no serious talk by anyone in Congress about disbanding the program and many who want to see the program expanded to include some of the classes of facilities that are currently exempted from CFATS coverage. In fact, the political debate about the CFATS program has always been about the scope and coverage of the program, not the need for a chemical security program.

Shortage of Chemical Security Professionals

One of the weak spots in the CFATS program has always been the CFSI. This is not due to any personal or professional shortcomings of the current crop of CFSI, but rather the fact that until very recently there was no such thing as a chemical security inspector. In fact, there have been virtually no chemical security personnel at all.

Okay, there have been security personnel at chemical facilities for a long time and their number certainly increased after 9-11, but for the most part these have been standard security personnel concerned with standard security matters such as entry control, perimeter patrols, and loss prevention. The number of people that understood the unique security aspects of process chemistry, both as targets and as potential weapons, was extremely small and most were concerned about security of overseas chemical facilities owned by the major chemical companies.

In the same way there were very few people in the chemical processing industry who really understood security; locks, fences, and rent-a-cops seemed to be adequate security to most chemists and engineers. Even then the basic necessities of those programs such as key control, clear zones and gate procedures were beyond the understanding or concern of chemical professionals.

CFSI Training Issues

Because of the lack of chemical security professionals, the bulk of the first CFSI hired and trained by ISCD were in fact security professionals; security managers, inspectors and law enforcement types. Most of them came from backgrounds in the Federal Government since this eased many of the vetting requirements.

This created a bit of a training problem for ISCD. While the training should have been concentrated on CFATS related issues (§550 restrictions, RBPS guidelines, etc) much of the focus of the Chemical Facility Security Academy had to do with chemical process and safety issues. Security personnel had to be trained in the basics of chemical process language, equipment, and chemical handling as well as the standard OSHA mandated training for personnel operating in chemical processing facilities. And there had to be at least a couple of trips to actual chemical processing facilities so that CFSI wouldn’t be totally overwhelmed by the complexity of things when they strolled into their first official inspection.

With all of that on the docket there certainly wasn’t time in the 8 week training program to include such things as the pros and cons of various security and chemical safety devices, cybersecurity fundamentals for both IT and control systems, personnel surety standards (that still don’t exist) and a whole host of other matters that would need to be evaluated in chemical security inspections.

I know that ISCD has attempted to recruit more personnel from the chemical industry to fill vacated and new CFSI positions. I have seen no figures to date on the success of that effort, but even if successful, that only complicates the training problem as people with chemical backgrounds have to be taught all of the standard security stuff about which they are clueless.

This training issue is going to plague the CFATS program for the foreseeable future. Until there is a stable stream of personnel with industry experience as chemical security professionals ISCD will be hiring people that lack significant parts of the skill sets needed to be a CFSI. One of the best places that DHS could put some chemical security grant money is to one of the schools that has an industrial chemistry program (a relatively new discipline of its own) to develop a degree program for chemical security professionals.

CFSI Requirements

In my opinion, a CFSI should first be a chemical professional. This means at least a BSc degree in chemistry or chemical engineering, perhaps industrial hygiene. Experience working in a chemical processing facility would be a plus. This background would provide the CFSI the ability to speak with and understand the engineers and chemists that run most facilities.

I don’t mean to denigrate the skill and knowledge necessary to be a security professional, but a large part of the knowledge base in that profession will not be of much use in a chemical processing environment. Besides, the §550 restrictions on specifying security requirements will get many people from a real security background in trouble in the field.

A law enforcement background will not be particularly useful in this position. The skills and training necessary to be a cop do not really apply to security (though cops will generally understand security better than chemists) and there is little need for the investigational skills associated with law enforcement. Any actual attacks or suspected attacks will be investigated by local police or the FBI not ISCD.

Restricting the hiring of CFSI to people with a chemical background will make the training problem easier for the Chemical Security Academy. They would be able to concentrate on security issues and program requirements.

So You Sill Want to be a CFSI?

So after all is said and done what does it take to become a CFSI? The short answer is you put in an application when a position vacancy is announced on USAJobs.gov. I just did a search and there are no such jobs currently listed. You can set up an account on the site and have them notify you when a vacancy is announced. You’ll have to use the ‘Advanced Search’ option and I would limit the search to DHS and NPPD under the ‘Agency Search’ option.

What qualifications are necessary? Well you have to be a US Citizen and be capable of getting a Secret security clearance. Beyond that you’ll have to look at the announcement in USAJobs.gov. This is still an evolving position and I expect further changes to be made in the job requirements based on the ISCD report (though I still haven’t seen the report).

What are your prospects of getting hired? That’s a good question. There are only a limited number of positions available (160 is the latest figure that I recall) and I believe that most are currently filled. I don’t see a major expansion any time soon. I don’t know how much of a turnover the Department is having (I would hope that the ISCD report touches on that, but we still haven’t seen a publicly released copy), but I don’t expect that it is real high.

Oh yes, expect to have to move. DHS has been advertising these positions as location specific for a regional office and the last listing that I saw said that they would not pay relocation expenses for new hires.

Another Look at ISCD Problems – Who Misled Who?

2011-12-30T00:43:00.000-05:00

There is an interesting piece over at CEN.ACS.org about the recent news that there are problems at ISCD. Since the author, Glenn Hess, has not seen the actual DHS report that started this discussion (nor apparently has anyone outside of Fox News and NPPD) the news focuses on the response of Sen. Collins (R,ME) and Bill Almond, a VP at SOCMA; both of whom have been vocal supporters of the current CFATS structure.

Congressional Oversight

Not surprisingly Sen. Collins is upset that DHS “mislead Congress about the effectiveness” of the CFATS program. Now I don’t know what information DHS provided to Congress in private, but I have watched most of the public testimony before the three respective committees looking at CFATS and any member of Congress that was misled by Under Secretary Beers’ testimony just wasn’t paying much attention.

For almost the last two years now Beers has dutifully reported the painfully slow progress in proceeding with the completion of the site security plan review and approval process. Rather than questioning him in detail about the problems at ISCD almost all of the Congresscritters involved in multiple hearings have focused their questions on the IST debate. Political critters from both sides of the aisle have patiently and persistently tried to get him to make one statement or another in support of their pet stance on that issue. IST, pro and con, has been the focus of Congressional oversight, not the performance of ISCD and progress of CFATS implementation.

For instance, the article quotes Collins as saying that the report “contradict the official testimony of department officials”. She was referring to the March 2010 hearing where Beers told the Committee that ISCD had started the pre-approval inspection process. What no one on the Committee considered asking was why DHS found it necessary to add a ‘pre-approval’ inspection process that was never explicated in the original regulations. The answer to that question (that had been provided to industry in multiple forums) would have nearly completely explained the continued slow pace of site security plan approvals today.

If one were to look back at the first couple of rounds of CFATS hearings that Beers testified at he always had Director Sue Armstrong at his side. As one would expect from one in Beer’s position as Under Secretary for National Protection & Programs Directorate he would answer the questions dealing with overall policy and the grand sweep of the program. When questions were asked about the details of the operation of the program he would let Armstrong provide the answers.

Lately however, he has been a solo act. His role as explicator of the grand strategy has not changed. But the usefulness of his testimony without the active support of a knowledgeable ISCD Director at his side has been limited. Fortunately for him (in the short run), Congress did not notice because they were more interested in political theater instead of overseeing the chemical security program that they handicapped in the first place.

Lack of Leadership

The Chemical Engineering News article notes a couple of interesting points by Bill Almond. He noted that the arrival of the Obama Administration initiated a lot of management turnover in NPPD in general and ISCD in particular. While this type problem affected large portions of the Executive Branch it was particularly devastating at a small, underfunded and understaffed agency like ISCD that was trying to put together a completely new and innovative regulatory program.

I am surprised that Bill did not take his argument one-step further. One of the reasons that DHS had problems finding qualified people to take the slots that kept coming open was that Congress could not find a way to reach a consensus on how to make this critical security program a permanent part of DHS. Imagine how hard it must have been to attract up and coming managers to a program that could die at the end of the fiscal year just because of Congressional inaction. This is yet another reason SOCMA and other industry organizations could use to support their demand for a long-term authorization of the current CFAT program.

Added to that, there was the continued in-fighting within the Administration about how important sub-programs (like the CFATS personnel surety program, the ammonium nitrate security program, and the MTSA harmonization program) would be implemented. Drafts of the ammonium nitrate security program rule were circulated within the Administration for almost three years before the NPRM was introduced this fall.

It was little wonder that there was a lack of effective leadership at ISCD to handle the inevitable problems that would arise with implementing an new regulatory program.

Moving Forward

As a true-believer I am saddened to see the problems that ISCD has been having with the completion of the implementation of the CFATS program. It is somewhat encouraging to hear that they have looked at the problems and come up with an extensive program to correct their shortcomings. I would be more encourage, perhaps, if there were a more public discussion of the details in the report.

I suspect that the appropriate place for that discussion will be before the three congressional committees that have been ‘exercising’ such poor oversight of the program in the first place. That doesn’t provide me with much hope however. This coming year (just a couple of days away now) is an election year and that will encourage more political theater, not less.

DHS Publishes New ICR for IP-SSARSAT

2011-12-29T08:11:00.000-05:00

Today DHS published a 60-day Information Collection Request (ICR) notice in the Federal register for a new ICR to support the NPPD’s IP Sector Specific Agency Risk Self Assessment Tool (IP-SSARSAT). This is the first step in the Department’s efforts to get approval from the Office of Management and Budget for the voluntary collection of information from private sector entities to support the operation of this program.

This program is administered by the Office of Infrastructure Protection’s Sector Specific Agency Executive Management Office (SSA EMO). It is an automated information collection and assessment tool (apparently existing) that allows owner/operators of critical infrastructure and key resource (CIKR) facilities to ‘assess the risk of the evaluated entity’. It allows for the:

• Calculation of a vulnerability score by threat;

• Evaluation of protective/mitigation measures relative to vulnerability;

• Calculation of a risk score; and

• Reporting the threats presenting highest risks.

The only information that is required to be shared with DHS in this evaluation process is “venue identification information (e.g., point-of-contact information, address, latitude/longitude, venue type, or capacity)” (76 FR 81956). The results of the risk assessment may be shared with the SSA EMO at the discretion of the owner/operator.

I’m pretty sure that this is an existing program, but I cannot find any mention of it, or link to it on the Department’s web site. The ICR notice provides point of contact information (Jay Robinson, jay.robinson@hq.dhs.gov) but that POC is typically about the ICR submission not the associated program.

The ICR claims that the start-up costs for this program are $0 with annual operating costs of $14,400. This would tend to support my supposition that this is an existing program. The ICR estimates that there would be 4,000 respondents annually and that each assessment would take about 8 hours to complete.

Public comments on this ICR can be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2011-0069). Comments should be submitted by February 27^th, 2012.

NIAC Meeting Announced

2011-12-29T06:53:00.002-05:00

Today DHS published a notice in the Federal Register (76 FR 81956-81957) announcing a meeting of the National Infrastructure Advisory Council on January 10^th, 2012. At this public meeting the Council will receive a working group report on a recently conducted Public/Private Sector Intelligence Information Sharing Study.

There will be a brief period for public comment after the working group makes its report and recommendations for further work in this area. After that comment period the Council will deliberate on the topic and make decisions on further actions to be taken by this working group.

Written comments on the topic may be submitted through the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2011-0117) and must be submitted by January 3^rd if they are to be considered by the Council in their deliberations.

Individuals wishing to make public comments at the meeting will need to register at the site no later than 15 minutes before the start of the meeting. Comments will be limited to 3 minutes per person and a total of 30 minutes has been allotted for comments. Commenters will be accepted on a first registered basis.

ICS-CERT Upgrades Another Advisory

2011-12-28T23:37:00.000-05:00

Today the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) upgraded another alert to an advisory as the vendor provided appropriate mitigations for the reported vulnerability. This time the vendor was ScadaTec. The original alert described a buffer overflow vulnerability in the ScadaPhone and Modbus TagServer products and was published back in September.

Today’s advisory identifies the researcher as Steve Seeley and notes that ScadaTec has produced a patch to ‘resolve the vulnerability’. It turns out that the actual vulnerability was in the Abbrevia ZIP file handler. Newer versions of that software do not contain the same vulnerability. As always I have to ask what other vendors are still using the vulnerable versions in their software packages.

An interesting side note; the Advisory notes that the affected ScadaTec products are used principally in water treatment facilities in the United States and Australia.

Another Look at CFATS and Weapons

2011-12-28T22:50:00.000-05:00

A topic that comes up from time to time in discussing security plans at high-risk chemical facilities covered under the CFATS program is the question of whether or not security personnel should be armed. Generally speaking chemical facility management is against fire arms and security personnel (myself included) tend to favor their use. The issue came up again in a rather odd context last week in the first of two FoxNews.com reports by Mike Levine.

Mike quoted from the as of yet unseen internal DHS report on problems in the implementation of the CFATS program:

“’Despite their lack of law enforcement authority, some still actively seek the right to carry a firearm,’ the internal report reads.”

The reason that I mention this here is that it is very important that everyone at DHS, especially the CFATS inspection force, understand why chemical facility managers are typically so adamant about no firearms being allowed on their property. It is not because they are anti-gun nuts (I personally know at least a couple that are card-carrying NRA members), but rather they are scared to death of what a gun can potentially do on site.

Flammable Atmospheres

Almost every chemical facility worthy of the name houses one or more flammable chemicals. A very safe chemical facility will take excruciating pains to ensure that those chemicals remain confined in the appropriate storage or processing systems. Even so, they know that small spills and releases are almost inevitable. Less safe facilities will, almost by definition, have more and larger such releases.

Even the smallest spills of flammable chemicals (ones so small that even the most rabid environmentalist would ignore it) result in a small cloud of flammable vapors. Under the right atmospheric conditions even those small clouds can be ignited by stray sparks and open flames. This is the reason that hot work permitting and flammable gas testing procedures are such an important part of chemical safety programs.

Before any work is done at a chemical facility that could produce sparks (drilling, grinding, etc) or introduce open flames (welding or cutting) a gas test meter is used to determine if there is the presence of a flammable atmosphere. A flammable atmosphere is defined as any concentration of a flammable vapor above the lower explosive limit (LEL) and below the upper explosive limit (UEL). Every flammable chemical has its own characteristic LEL/UEL combination.

These are called ‘explosion limits’ for a very good reason. The flammable vapor/oxygen ratio is so favorable for burning that the cloud ignites easily and burns very quickly, producing heat and a rapidly expanding cloud of combustion products that produce a pressure wave that can cause extreme damage at quite some distance for the site of ignition.

Generally speaking the larger the amount of the flammable chemical that is released into the environment the larger is the chance that at least some portion of the vapor cloud will be within the explosive limits for that chemical. And the larger that explosive portion of the cloud is the larger is the area that will be affected by the resulting explosion.

Firearms

Handguns, rifles and shotguns are often generically referred to as firearms. The reason for this is clear; it is the burning of a propellant charge in the chamber of the weapon that causes the expansion of gasses in the barrel that, in turn, cause the projectile to fly towards its intended target at high-speeds.

Anyone that has seen a firearm discharged at night will have had a clear vision of the muzzle flash that accompanies the firing of the bullet. That muzzle flash (and cylinder flashes from revolvers) is nothing more than gasses that are still burning as they leave the confines of the weapon.

Those burning gases are almost certainly hot enough to ignite a vapor cloud that is within the explosive limits for that particular chemical. Depending on the size of the vapor cloud (which is again dependent on the size of the chemical release) the discharge of a single round from even a small handgun could result in a catastrophic explosion.

Bullet Holes

As it that weren’t problem enough, the projectile that leaves the barrel just before the muzzle flash is going to travel some considerable distance from the weapon before air resistance and gravity combine to bring it to earth. That can be quite some distance, something that even the most ardent shooter frequently forgets. Unless, of course, something gets in the way first.

Most people have no concept of the penetrating power of modern bullets. Having seen their favorite cop or detective on television hiding behind car doors in a gun fight, they assume that thin pieces of sheet metal are impervious to bullets. Nothing could be further from the truth. Even the rounds from small pistols can easily penetrate the walls of most storage tanks and smaller chemical storage containers.

If the bullet penetrates the container or tank below the liquid level the chemicals inside are going to come out the bullet hole. The rate will be dependent on the caliber of the bullet and the viscosity and flow characteristics of the chemical. Most really dangerous flammable chemicals will flow out of even a 0.22 caliber hole at quite an astounding rate.

For flammable liquid storage tanks, the higher the liquid level inside the tank above the bullet hole the faster the chemical is coming out. Under the proper conditions of bullet hole size, and pressure the liquid will convert to a vapor upon exiting the tank, greatly increasing the chances for forming a flammable atmosphere.

Consequences

If an armed security guard or responding police officer encounters and armed terrorist who has penetrated the perimeter security measures of a high-risk chemical facility it is very likely that a gun battle will ensue. While every attempt will certainly be made to just hit the intruders with the bullets, the sad truth is that in any gun battle most bullets miss their intended targets.

The larger the chemical facility, the more likely it is that the ‘missing’ bullets will hit storage tanks, containers or process equipment resulting in the release of chemicals. If flammable chemicals are on site, the longer the gun battle runs the more likely it is for a flammable chemical storage tank or container to be hit by a stray bullet. And sooner or later it is likely that a firearm will be discharged within a flammable atmosphere. Then the probability of a successful terrorist attack will increase dramatically.

Guards Must be Armed

I am firmly convinced that if a security force is going to have any chance of preventing a successful armed assault on a high-risk chemical facility it is going to have to be armed. But, as I have explained here, arming them with firearms can be counterproductive to say the least. A security force manager is going to have to look for alternative weapons for facilities with significant amounts of flammable chemicals on site.

Interestingly, just yesterday the folks at PublicInteligence.net published a copy of a DOD Non-Lethal Weapons Reference Book. While many of the weapons discussed in this book are firearms based, most are not. I strongly recommend that any security force manager should look over this reference for ideas for alternative weapons for interdicting terrorist attacks.

Reader Comment – More on PLC’s

2011-12-28T09:28:00.000-05:00

An interesting comment was posted on yesterday’s blog about ICS misconceptions. It seems that I missed one of the underlying points about another way to go about securing control systems at their points of action; the PLC. The Anonymous readers suggest that instead of allowing for reprogramming of PLC’s via the hard wired connection (which is a potential source of attack through the networked control computer) that the reprograming could be done by physically changing the memory card for the PLC like one does with the memory card on a digital camera.

While this novel suggestion would certainly avoid the in situ reprograming of the PLC that was seen in the Stuxnet attack (for instance) it has some limitations on its applicability in large scale control systems like those found in chemical plants. It also ignores the fact that the programing of the PLC memory chip still takes place using the same workstation that would allow the Stuxnet type attack in the first place.

Large Number of PLCs

A large scale chemical manufacturing facility can have thousands of PLC’s in operation. The relatively small specialty chemical manufacturer that I last worked at had one reaction vessel (the one I spent the most of my time working with) with over 100 controllers on it alone. While most of these operated valves (a fairly simple operation) a great deal of time was spent over the years on tweaking the specific interlock rules and valve operation timing (including how fast the valve opened and closed) instructions. And that was with processes that were still largely operator controlled. As we moved to increased process automation the programing got even more complicated and time consuming.

For the vast majority of PLC’s in use in a modern manufacturing facility I don’t think that the physical changing of program memory cards is practical. While the act of switching a memory card is fairly simple when one looks at the number of PLC’s involved in a fairly simple process adjustment the number of card changes involved almost ensures that a wrong card will be put in an inappropriate slot.

Physical Security Issues

There is also a physical security issue that must be addressed, a fact frequently overlooked in discussions of cyber security. If programing changes are now going to be physically implemented at the PLC we now have to provide protections that will prohibit the unauthorized change of cards as a means of cyber-attack. The current centralized programming operation only requires physical security measures for the control computer and its associated hardware. And physical security measures are frequently more expensive than cyber-security measures.

Programming Vulnerability Remains

Finally, the programming still has to be done at the facility level, even if that means hiring an outside consultant to handle that job. This leaves the programing control workstation as the point of attack on the PLC’s. It would avoid the problems associated with the wireless network capabilities that vendors are adding to their PLC’s (and are apparently being sucked up by system owners), but the computer that allowed the networked attack on the PLC in the Stuxnet attack is still the point of vulnerability.

Safety Systems

Having noted all of these shortcomings in this proposed solution, there is certainly one area where a control system owner might want to consider this methodology; safety control systems. These stand-alone systems are tweaked infrequently at worst and are relatively simple systems. Their strong points are reliability and inaccessibility. It would seem that only allowing programing changes via firmware substitution would be ideally suited to these types of systems.

Since these systems backstop security systems by not allowing for catastrophic failure of the process, separating them from the potential for a Stuxnet type attack would seem to be a smart idea. Their limited use and infrequent need for updates would also seem to be ideally suited for the design of a single use programing work station that would only be able to program these devices and have no ability to connect to the internet or corporate networks. Device signing could be used to ensure that only trusted drives and memory cards could be used on the system.

Safety system designers may well want to consider this methodology to increase the reliability and security of those systems.

DHS Announces HSAC Closed Door Meeting

2011-12-28T07:06:00.000-05:00

Today DHS published a notice in the Federal Register (76 FR 81516-81517) that the Homeland Security Advisory Council will be holding a closed door meeting on January 9^th, 2012. The meeting is closed to the public because the sensitive nature of the reports being made by DHS to the Council might disclose information about counter-terrorism plans and activities; reveal intelligence information and techniques; or provide information about on-going criminal investigations.

A number of generic topics (lack of specificity will protect sensitive information) are listed in the agenda portion of the notice. One would be of potential interest to readers of this blog would that they could be flies within the secure walls; cyber-security. According to the agenda in the notice:

“The members will also receive a briefing on recent Cyber-attacks and the potential threat of an electromagnetic pulse attack. Both will include lessons learned and potential vulnerabilities of infrastructure assets, as well as potential methods to improve the Federal response to a cyber or electromagnetic pulse attack.” (76 FR 81517)

One would think that the closed door briefing would not address recent cyber-attacks that have been beat to death in the press and blogosphere. So are there new attacks out there that we don’t know about yet? Or maybe it’s just new information about old attacks? Or maybe they just don’t like airing dirty laundry in public? We’ll probably never know.

ICS-CERT Updates an Advisory and Upgrades an Alert

2011-12-27T22:06:00.000-05:00

The DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published two advisories today. One was an update of a previously issued advisory (Sielco Systemi Winlog) and one was an upgrade of an alert to an advisory (Siemens Automation License Manager).

Sielco Systemi

The original Sielco Systemi Winlog Advisory was published on December 6^th, 2011. The new information in this update is the link to a new release of Winlog that eliminates the vulnerability. Actually, the new link replaces separate links to the two different product (Winlog Lite and Winlog PRO) updates that were listed in the original advisory; that may have been because the earlier links were directly to .EXE files.

To make matters more interesting, the page on the Sielco Systemi web site mentions that the new version of Winlog Pro Scada and Winlog Lite SCADA just became available on December 20^th; not the 6^th and no mention is made of correcting the buffer overflow vulnerability. And there is only a link to the download of Winlog Lite; no link for Winlog Pro. I’m confused.

Siemens

The original alert for this particular Siemens vulnerability (there have been so many of late) was published on November 28^th and updated on December 2^nd, 2011. The original alert was based upon four vulnerabilities in the Siemens Automation License Manager reported by Luigi in an uncoordinated disclosure.

In a very timely manner Siemens has issued a patch for the ALM and the Advisory does provide a tiny bit more information about the vulnerabilities over what was provided in the Alerts.

ICS-CERT continues to have some problems reporting CVE links in this Advisory. Three of the four links provided will eventually link to CVE files on the NIST /US-CERT web site. The third of the four listed has an extra character (an X) that essentially destroys the link. When the CVE report becomes live the legitimate link will be:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4531

BTW: ICS-CERT has quietly corrected their link errors that I reported last week.

Reader Email – ICS Safety Misconceptions

2011-12-27T12:59:00.000-05:00

I got an interesting email from a reader of my post yesterday on Digital Bond’s SCADA Security Portal. I’m not sure what the reader’s background is, but I am assuming that it isn’t control system engineering. The misunderstandings that form the basis of the questions are so important that I thought that I would address them in a post instead of an email reply.

Here is what the Reader wrote:

“We read your blog on Digital Bond about the various legislative efforts to make ICS safe. We would like to ask your opinion about how can any ICS/SCADA be safe when the programmed memories of the controllers are corruptible, that is, endlessly rewriteable?

“Cannot the process control engineer pause the system for, say, 2 minutes to change to another preprogrammed no-write memory?”

There are three basic misconceptions here and I’ll address them in turn. They are:

• Legislation can make something safe;

• Re-writeable memories are corruptible; and

• Un-rewriteable controllers are possible.

Legislation

One of the great misconceptions of the modern liberal era is that government legislation or regulation can make anything safe. At the most legislation or regulation can mandate that something should (or should not) occur, that certainly does not make it happen. A perfect example of that can be found in the illicit drug trade; numerous laws and regulations at the local, State, Federal and international level make the transport of, for example, cocaine illegal. Has it stopped or even seriously slowed that trade? Not hardly.

Even in the safety realm, OSHA regulations have not stopped companies and facilities from allowing unsafe conditions to exist. OSHA, even including State and local inspection officials, does not have enough manpower to go around and ensure that everyone is following the rules. What the OSHA regulations have done to increase workplace safety (and they have certainly done that on a gross basis) is to provide a basic set of guidelines for safe practices and provide sanctions for violations of those guidelines when those violations result in worker injuries and deaths. Avoidance of those sanctions have made most companies follow most of those guidelines on a fairly consistent basis (lots of deliberate weasel wording there). And the worst violators are sanctioned out of business.

ICS security legislation at its best will not make control systems secure or safe. At most it can establish a program for determining minimum standards for security in the design and implementation of control systems and provide incentives for (or disincentives for not) applying those standards. They would help provide a level playing field for those companies that design, install or maintain a secure control system. That would raise the general level of security in the control system community, but it WOULD NOT SECURE CONTROL SYSTEMS. I don’t think that that is actually possible.

Corruptible Memories

Okay, I guess that I will have to concede that re-writeable memories are inherently ‘corruptible’. Whether or not that is a good thing or a bad thing depends on how those memories are deployed. In a “properly” designed system only the owner of the system (through their engineering staff of course) will have the ability to re-write the memory. In an adequately designed system the owner will know when the re-writeable memory is re-written and will be able to react in a timely manner when it is re-written by an unauthorized individual or re-written in an unacceptable manner (either accidentally or purposefully).

PLC’s Require Re-writeable Memories

The modern control system is predicated on the ability of the owner to buy a programmable [emphasis added] logic controller (PLC) and make it perform a specific function in his system (and perhaps change that function as his process changes). There is no way that PLC manufacturers can make a controller for each specific function in every process.

Okay, technically they could. They would be prohibitively expensive (thousands of times more expensive than they now are) and they wouldn’t work. That’s because no design engineer has successfully documented the requirements of more than a single controller system (and I would be surprised if even one single-controller system was successfully specified in advance) without there being a need for tweaking the controllers to perform properly in the real world. Controllers must be programmable at the installation where they are put into use and that requires re-writeable memories.

Even if a controller could be specified and produced for a single purpose application at a reasonable cost, no one would buy it because it would not allow for process improvements or process changes.

Process Control Systems Must be Modifiable

Modern manufacturing processes require control systems that can be modified to meet changing conditions. This means that systems engineers must be able to modify the actions of the various components of the systems. This can only be done with some sort of programmable logic controller.

Security for PLC’s has to be designed to limit communications to and from the PLC’s to routing through a secure network to a protected control system computer. The more levels of protection provided to the system the more likely it will be that an attacker will be unable change the programing of the PLC’s. That is how you protect the operating end of an industrial control system.

PHMSA Pipeline Safety Webinar

2011-12-27T07:39:00.001-05:00

Today the Pipeline and Hazardous Material Safety Administration published a notice in the Federal Register (76 FR 81015-81016) about an upcoming webinar concerning the recently implemented distribution integrity management plan (DIMP; 74 FR 63906) inspection program. As of August 2^nd, 2011 distribution pipeline operators were supposed to have implemented a DIMP program and Federal and State regulators have begun their inspections of these programs. This webinar will allow PHMSA to share general information gleaned from these inspections. The webinar will also address the initial analysis of Mechanical Fitting Failure Reports being submitted under the DIMP regulations.

The webinar will be held on January 25^th, 2012 from 11:00 a.m. to 12:30 p.m. EST via LiveMeeting. The notice provides a link to the PHMSA DIMP web page claiming that there is additional information on the webinar on that page, but as of 7:00 a.m. EST this morning there is no link to any upcoming webinar on that page, only links to old webinars [NOTE: new link on that page now points to registration page PJC 18:25 EST 12-27-11]. The notice also provides a link to a web page for submission of questions before or during the webinar, but that page only provides a link for email submissions to DIMPsupport@cycla.com. The referenced page does request submitters to provide their name, affiliation, as well as phone and email contact information with their submitted questions.

Please note that a Privacy Act notice is provided for information submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # PHMSA-2004-19854) but not for email submitted questions and those are being submitted to a Contractor; Cycla Corporation.

The notice provides contact information for Chris McLaren (phone 281-216-4455; Chris.Mclaren@dot.gov) as the POC for the webinar. Hopefully McLaren will have more information than the links provided in the notice.

Are Control Systems Safe and Reliable?

2011-12-26T14:01:00.000-05:00

Joe Weiss has an interesting blog posting over on ControlGlobal.com that briefly addresses the different issues that affect cybersecurity in IT systems and ICS systems. No new information, just a review of what Joe has been saying for quite some time. What caught my eye though was the title (which has little to do with the subject, BTW); “Industrial control systems are reliable and safe, just not secure”.

In light of recent disclosures about engineering decisions made in the design of control systems from Schneider Electric and Siemens (among others, of course) makes me seriously doubt the assumption explicit in Joe’s title. While there is certainly a long history of system stability and reliability in industrial control systems (and no one would be investing the money in these systems if they didn’t have that history) the basic insecurity of these systems calls that history’s extension into the future in question.

If systems as currently designed, installed and deployed are able to be attacked by attackers with a wide range of skill sets (and just read the ICS-CERT advisories if you think they are not), it is only a matter of time before one or more systems are successfully hacked and manipulated. Once that happens to one system the whole ‘safe and reliable’ mantra of the industry goes out the window.

How can something be safe when anyone with the proper skill set and access to a modem can change (okay a slight exaggeration) whatever settings they want? How reliable is a system that is readily susceptible to a denial of service attack?

Schneider and Siemens have essentially forfeited their right to claim that their systems are ‘safe and reliable’. Other manufacturers are seemingly actively working with independent researchers to correct past errors in their system designs, but is anyone actively working on designing a safe, reliable and secure system? More importantly, would anyone be interested in paying a premium for such a system?

Right now these are academic style questions. As soon as a hacker successfully attacks a control system and causes economic damage to a major manufacturer, a community or the nation; or worse yet uses a compromised ICS to turn an industrial facility into a chemical weapon, the questions will become political questions. And anyone that has looked at the post-911 response by politicians will realize that the answers to those political questions could do as much damage to control systems as the attacks themselves do. They will certainly affect a wider swath of control systems.

Cybersecurity Legislation Reviewed

2011-12-26T12:50:00.001-05:00

Dale Peterson over at Digital Bond’s SCADA Security Portal was nice enough to ask me to write a review of cybersecurity legislation in the first session of the 112^th Congress. I provided and he posted my review of little movement on legislation so far and my prediction of little in the way of ICS cybersecurity legislation for the next session.

ISCD Issues

2011-12-23T09:25:00.000-05:00

Yesterday there was a large spike in readers accessing this blog. I’m pretty sure that it was as a result of the blog being mentioned in a follow-up FoxNews.com article about the problems with the CFATS program and ISCD. I mentioned in a blog post yesterday that I had been reporting on these issues since last January and provided a link to the first such report.

Because of the new found interest in the issue, I’m providing the following list of blog posts that have addressed bits and pieces of the problems.

ISCD Labor Issues

The Real Cause of SSP Approval Delays

ISCD Reorganization

CFSI Pay Problems

Reader Comments – Inspector Issues

Reader Comment – Misguided Information

Reader Comments – Rick Driggers

ISCD Reorganization Continues

Reader Comment – ISCD Problems

Fixing the Site Security Plan – Changing Questions

Reader Comment – ISCD Personnel

New ISCD Director

I would certainly be interested (as would most people in the chemical security community) in seeing a copy of the DHS report on these problems.

ICS-CERT Finally Issues Siemens Advisory

2011-12-23T07:13:00.000-05:00

Yesterday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published an advisory about the Siemens authentication bypass issues that have been widely discussed in the blogosphere since Tuesday when Billy Rios published his response to the Siemens denial of the existence of a problem.

There is more detailed information about the vulnerability in Billy’s blog, but this Advisory does provide two important bits of information. First Siemens publicly admits the existence of the vulnerability and lists the affected systems. Second that Siemens plans to release a Service Pack next month that will resolve the issue.

Reading through the comments on Billy’s blog it seems that the Siemens statement that started the public disclosure process might have been the result of a misunderstanding between the Reuters person and the Siemens person (and I may be overgenerous in that assumption; I wasn’t there), but Siemens has obfuscated so often on their past vulnerabilities that no one is willing to cut them any slack. Siemens PR has a long way to go and a short time to get there.

BTW: There continue to be problems at ICS-CERT with their handling of CVE links beyond the slow posting of information at NIST. The two CVE links in this report have typos in them that make them useless. Both are missing periods [.] between ‘nvd’ and ‘nist’. In the link for CVE-2011-4508 this causes the link to be truncated to Http://web.nvd. In the second CVE link it becomes http://web.nvdnist.gov/view/vuln/detail?vulnId=CVE-2011-4510. Both links are useless. While neither CVE is active yet, the links should be:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4508

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4510

New ICS-CERT Monitor and 2 Advisories

2011-12-22T07:38:00.000-05:00

Yesterday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published the December edition of their Monthly Monitor and two new Advisories for control system vulnerabilities affecting WellinTech’s KingView and 7-Technologies IGSS SCADA systems.

Monthly Monitor

ICS-CERT continues to produce a brief but valuable monthly newsletter that should be widely read in the control system community. The latest issue contains:

• A neat new logo (okay that’s not so important, but it is good graphics design);

• Another overview of the ‘Water System Hack’;

• A good summary of generic malware analysis and mitigation techniques;

• A summary of the ‘latest’ Gleg Agora SCADA release (probably more appropriate here than as an alert)

• A lengthier listing of control system security articles and blog posts (including one by SCADAHacker, a nice response to my comment last month about the lack of bloggers); and

• Their standard listing of Alerts and Advisories and plug for Coordinated Vulnerability Disclosure

WellinTech

This Advisory describes a heap based buffer overflow vulnerability reported by Luigi through ZDI (so it was coordinated) in the WellinTech KingView system. It appears to be a common remotely exploitable vulnerability that allows execution of arbitrary code by an attacker with an intermediate skill level. WellinTech has a patch available. The CVE number provided in the Advisory is not yet active.

Two interesting things here. First ICS-CERT includes a link to the Chinese language instructions for the patch in addition to the English language instructions (multiculturalism at its best). More importantly the Advisory notes that there are no known exploits available. Luigi typically develops and publishes exploit code, though I can’t find a reference to this vulnerability on his web page. Since this is part of the ZDI project I wonder if he provided them with the code and they just haven’t released it.

7-Technologies

7-Technologies seems to be catching it this week. Earlier there was an advisory for their data server and yesterday a new advisory for similar buffer overflow vulnerability discovered by a separate researcher Celil Unuver (SignalSEC LLC). It appears that the same product update will solve both problems. The CVE file on this vulnerability is also not yet active.

Don’t Forget the Accomplishments

While negative reports like this attract lots of public attention and press scrutiny, it is good to remember the good things that have been accomplished by the hard working folks at ISCD. They include:

• Starting a regulatory program from scratch with little guidance from Congress;

• Writing, publishing for public comment and revising the CFATS regulations within the deadline given to the Department to publish an Interim Final Rule without the comment process;

• Developing and beta testing a set of innovative on-line tools for registering potentially affected facilities, collecting chemical inventory and facility data to winnow the facilities that were not at high-risk of terrorist attack;

• Established a training program for a unique security inspection program; and

• Developing, publishing for public comment and revising a Risk-Based Performance Standard (RBPS) guidance document to help facilities to understand the security requirements of the program.

More importantly all of the above were accomplished while maintaining a strong working relationship with the regulated community even while the program was costing facilities large amounts of money to implement the requirements of the program.

Congress Should Share the Blame

When Congress added the §550 authorization for the CFATS program to the DHS Appropriations Act FY 2007, they saddled the folks at ISCD with a lot of unnecessary baggage that may have contributed to the problems the program now faces. Two major problems resulted from that authorization process, regulatory uncertainty and unenforceable standards.

With the program clearly being a stopgap measure because of the political inability to reach a consensus on program goals (conventional security measures vs inherently safer technology being the major sticking point), both industry and the environmentalists have been completely amazed at their inability to convince the other side to acquiesce to their minimal program demands and there has been little effort to find a reasonable middle ground.

Industry finds this particularly galling as they are spending or programming for spending large amounts of money on non-productive projects that could become a complete waste of time and money if long-term authorization of the program is based upon the environmentalist agenda.

The unenforceable standards problem more directly relates to the current delays in the site security plan approval and subsequent inspection programs. With Congress forbidding the Secretary from requiring the implementation of any specific security process or tool, the ISCD program managers cannot tell a facility how to upgrade their programs to meet the requirements of the RBPS. They can only explain the deficiencies in the facility’s plans to meet the loosely defined standards and then hope that the facility will subsequently identify a suitable remedy.

Moving Forward

I would certainly extend my support to the comment by Beers at the end of the Fox article; I too “am presuming that this is a program that the American people and the Congress of the United States want, and that we will continue to improve our ability to (implement it)". I would also like to remind people that if a successful terrorist attack on a high-risk chemical facility occurs during this implementation interregnum, political and corporate heads will roll.

Congress needs to make it a high priority to review this DHS report in detail when they return from the end of year holidays and to resolve who is responsible for the oversight of this program and then conduct some real oversight hearings focusing on program accomplishments and shortfalls.

CG to Change Some TWIC Policies

2011-12-21T07:51:00.002-05:00

Last Friday John C.W. Bennett published a notice on his Maritime Transportation Security News and Views blog about the OMB’s approval of an ANPRM updating the Coast Guard’s Transportation Workers Identification Credential (TWIC) regulations to implement section 809 of the Coast Guard Authorization Act of 2010. That post was an update to his earlier blog (and my blog post) about the rule going to OMB for approval. It appears that John and I both guessed wrong about the document being an ANPRM since yesterday the Federal Register’s Public Inspection page pre-published the Coast Guard’s Notice of Availability of a Policy Letter 11-15 addressing the §809 changes to the TWIC program. That notice will actually be published in tomorrow’s Federal Register (76 FR 79544) [Updated 6:18 EST, 12-22-11].

The Federal Register notice will not contain the actual policy letter, that can be found on the Coast Guard’s Homeport site (for those not used to convoluted military style procedures the Coast Guard’s Homeport is a real treat. There is no permanent link to the letter you have to click through Library > Policy > Policy Letters > Inspection > CG-543 Policy Letter 11-15 to get to the letter). The notice does provide a reasonable summary of the letter’s provisions though.

NOTE: The notice also claims that the letter is available on www.regulations.gov (Docket # USCG-2011-0465) but that docket will not be activated until after the actual notice is published tomorrow.

The letter essentially changes processes not rules. As John pointed out in his blog the rule making process is time consuming and the Coast Guard has found an innovative way to shortcut that process. They are going through the rule changing process to implement §809, but in the meantime they are changing the way that they will enforce two specific provision of the current rules.

TWIC and MMC

The current regulations requires that an applicant (initial or renewal) for a Merchant Mariner Credential (MMC) must first obtain a TWIC. This allowed the Coast Guard to use the TSA TWIC screening process to vet MMC applicants. The new process will only require the applicant to have gone through the TWIC enrollment process, not actually received the TWIC. Since the TWIC fees are paid at the start of the enrollment process this may not seem like a big change, but it will allow applicants to avoid a potentially unnecessary second trip to the TWIC enrollment center to pick-up an unneeded TWIC.

Now the requirement for mariners to have TWICs is still going to apply in many (most?) cases. If a mariner is working on a vessel that is required to have a security plan under the MTSA regulations, a TWIC will still be required. The letter, and the notice, provides a listing of the types of vessels where this new policy will apply.

Inspections

Well, legally, all mariners are still required to have TWICs until the actual regulations are changed. To make this new policy effective what the Coast Guard is doing is providing notice that they are going to “exercise their enforcement discretion” (para 6b of the actual letter) by not pursuing revocation procedures against an MMC holder that does not possess a valid TWIC when they are working on an exempted vessel.

Essentially they are telling their enforcement personnel to not check for TWICs when they inspect vessels that do not require security plans under MTSA. If TWICs are not checked then there is no basis for taking action against the MMC holder that does not have a TWIC.

Consequences

I actually think that the Coast Guard’s action is a relatively innovative solution to a complicated bureaucratic problem. The Commandant is to be commended for putting into writing this policy change; it would have been much easier to either ignore the problem until the rulemaking process was completed or just quietly pass the word to inspectors to stop TWIC checks in appropriate settings.

I am afraid, however, that this could come back and bite the Coast Guard in uncomfortable places. It leaves them open for having a valid TWIC enforcement action challenged on the grounds of ‘unequal enforcement’. Most judges would probably side with the Commandant, but selective enforcement has been successfully used as a reason for appeals in a wide range of cases. I hope the Coast Guard proceeds with their rule making process expeditiously and that the political side of the Administration provides minimal interference in that process.

Unified Agenda

There is an interesting comment in the letter about the Unified Agenda of Regulatory and Deregulatory Actions. It notes that the Coast Guard will complete the rulemaking process “in accordance with the timeline set forth” (para 5b on page 3 of the letter) with the Unified Agenda. Both John and I noted in our earlier blogs that this action was not listed in the Spring 2011 Unified Agenda; so apparently it will be listed in the Fall 2011 Unified Agenda that has yet to be published.

It will be interesting to see what the projected timeline for this rule actually is. Then, of course, few people expect that timeline to actually be met. While I do not claim to have verified the projected timelines of every rulemaking, none of the chemical safety or security rules that I have tracked over the last couple of years have come anywhere near close to meeting the time estimates published in the Unified Agenda.