Thursday, February 16, 2012

Reader Comment – Questions about Language

A reader, Ragnar Schierholz, posted an interesting comment to today’s post about S 2150. He wondered if my detailed language analysis was really necessary to understand the intent of this bill. And he made a very good point that any real serious control system relies on a certain amount of information infrastructure to be effective. In short his entire comment is thoughtful and well worth reading

That being said, I still stand by my comments that, as currently written, the bill does not cover industrial control system security. A point that I did not make clearly in my earlier post was that many facilities and even whole industries will be covered by this legislation due to their potential physical effects on the surrounding community. Unfortunately, it will be their IT systems not their control systems that will have to be protected.

Unnecessary Cost Avoidance


The reason that language is important is that many (probably most) industrial control system owners still do not really believe that their systems are vulnerable to cyber-attack. Thus, in their view, any substantial amounts of money that they would have to spend to comply with this regulation would be money wasted. In current economic environment sending money down a regulatory hole without expectation of positive return appears to be a sure route to economic suicide.

Even in good economic times, the cost of setting up the necessary protocols to document compliance with a brand new Federal regulatory scheme can be high enough to have a negative impact on growth. Especially when the regulations will not be allowed to specify how compliance will be achieved; the learning curve for both the regulators and the regulated community is quite steep.

Given that, companies will find any legitimate way that they can avoid being covered by the regulations. One of the easiest ways is to object that the regulatory agency is overstepping their legislative mandate. In this particular case, since control systems are never specifically mentioned in the bill and the language that might indicate an unstated intention to regulate control systems is so wishy-washy, it will not be hard to convince either the folks at OMB or a federal judge that DHS has no legal justification to regulate the security of privately owned control systems.

Supposed to Cover Control Systems


Now, I am hearing that the crafters of this bill did really intend to include industrial control systems in covered critical infrastructure requirements of this bill. Basically I think that that would probably be a good thing, though I do have some minor reservations that I’ll discuss in a later blog.

If I were to revise the current language so that it unequivocally addressed control systems in covered critical infrastructure I would probably make three basic changes. First I would rewrite the definition of ‘cyber risk’ in §101(a)(1) to include risk to industrial control systems (and I would take out the second reference to ‘information infrastructure’.

Second I would make a change to §102(a)(2)(C) in sub-paragraphs ii, iii, and iv. In each instance I would change ‘access to critical infrastructure’ to read ‘access to critical infrastructure industrial control systems’.

Finally I would modify the language in §103(b)(1)(C) outlining the guidelines for designating critical infrastructure. I would combine §103(b)(1)(C)(i) and §103(b)(1)(C)(i)(II) into a single comment. Then I would promote §103(b)(1)(C)(i)(I) to §103(b)(1)(C)(ii) and add ‘, or serious injuries’ after the word ‘fatalities’.

Those three minor changes should suffice to make it abundantly clear that the bill would authorize the Secretary to develop regulations concerning the security of control systems in covered critical infrastructure.

House Committee Objects to EPA Information Sharing

Readers will probably remember that back in early January I wrote about the EPA’s plans to restore public internet access to certain risk management program (RMP), access that was removed shortly after the 9/11 attacks. Last week the leadership of the House Energy and Commerce Committee finally got around to formally objecting to the plan as it could “compromise the security of manufacturing facilities by handing over sensitive information to terrorists”.

The Committee letter to Administrator Jackson is a long delayed (they were notified of this plan back in December) knee-jerk reaction that completely overlooks the fact that this information has already been posted to a number of environmental web sites. It compounds their delay by demanding that EPA responds by February 24th (two weeks) on its “plans to fulfill its responsibilities to protect non-OCA information”.

The letter notes three current laws that require the sharing of this information with State and local agencies. The Clean Air Act provision cited provides a requirement to share the information, but includes no mechanism to ensure that it is shared or acted upon. The Emergency Planning and Community Right to Know provisions are also toothless, especially since there is a not surprising dearth of local emergency planning commissions (no funding has been made available for them). And the third is a permissive clarification on allowing the sharing of sensitive but unclassified information with law enforcement and first responder personnel.

None of those provisions have had any serious effect on ensuring that individuals living or working near chemical facilities holding significant quantities of dangerous chemicals have access to the information that could save their lives or protect their financial investments in their homes. Nor do they ensure that local activists have the information they need to force local government agencies into the emergency planning process that Congress has only given lip service to.

I’m sorry, I am a strong advocate for chemical facility security, but this planned action by the EPA will do more to increase chemical safety at the community level than it will to increase the risk of a terrorist attack on those facilities. An intelligent risk-benefit analysis (an idea foreign to Congress) would support the EPA’s planned information sharing.

Cybersecurity Act of 2012 and ICS Security

Tuesday Sen. Lieberman (I,CT) {along with co-sponsors Collins (R,ME), Rockefeller (D,WV) and Feinstein (D,CA)} introduced S 2105, the Cybersecurity Act of 2012; the long awaited and much anticipated comprehensive cybersecurity bill. In no surprise to anyone that has been paying attention; the bill never mentions industrial control systems or any of their components. There are provisions, however, that may have an impact on how the Federal government deals with control system security issues.

Large portions of this bill specifically deal with security of governmental information systems, principally Federal information systems. While these efforts are certainly important in the grand scheme of things, I am going to ignore them for all intents and purposes. There are two titles of this bill that will be of specific interest to the control system security and the chemical-facility security communities. They are: Title I, Protecting Critical Infrastructure, and Title VII, Information Sharing. In this posting I will look at the Title I provisions.

To Cover or Not To Cover?


Again there is no specific mention of control systems or their components in this bill. In fact the definition of ‘cyber risk’ in the list of opening definitions would seem to specifically exclude control systems from consideration in this bill. That definition {§101(a)(1)} reads:

“The term ‘‘cyber risk’’ means any risk to information infrastructure [emphasis added], including physical or personnel risks and security vulnerabilities, that, if exploited or not mitigated, could pose a significant risk of disruption to the operation of information infrastructure [emphasis added] essential to the reliable operation of covered critical infrastructure.”

While that definition is relatively restrictive the requirements in the next section of Title I seem to be much more expansive in what would be considered when the Secretary of DHS completes his initial cybersecurity risk assessment. That assessment, to be conducted within the first 90 days after the Act is passed (a time limit that is sure to be missed) will be “a top-level assessment of the cybersecurity threats, vulnerabilities, risks, and probability of a catastrophic incident across all critical infrastructure sectors to determine which sectors pose the greatest immediate risk” {§102(a)(1)}. The inclusion of the undefined term ‘catastrophic incident’ would seem to be included specifically to address systems with effects in the physical realm; a realm much more in keeping with control systems than with information systems.

Later in the same section the bill lists those items that the Secretary is to consider in making this initial threat assessment. It specifically includes the consideration of “the extent and likelihood of death, injury, or serious adverse effects to human health and safety caused by damage or unauthorized access to critical infrastructure” {§102(a)(2)(C)(ii)}; again a specific reference to operations in the physical realm.

Having apparently expanded the area of concern into the physical realm the next paragraph again specifically limits this assessment to information systems. In discussing the methodologies to be employed in making the required assessment the Secretary is specifically directed to “develop repeatable, qualitative, and quantitative methodologies for assessing information security risk [emphasis added]” {§102(c)(1). No other type of security risk is mentioned.

Covered Critical Infrastructure


While control systems may or may not be covered in the Secretaries assessment of relative cybersecurity risk, there is no doubt that industries and facilities and even specific assets within facilities that may employ control systems will be covered by regulations called for in this bill. Section 103 of this bill requires the Secretary to establish procedures to designate ‘covered critical infrastructure’ at “the system or asset level” {§103(b)(1)(A)} with no specific definition of ‘system or asset level’.

The Secretary is only allowed to designate a covered critical infrastructure if it falls within three broad categories. The categories are operationally defined and the one of most concern to the control system community is the first; if damage or unauthorized access to that system or asset could reasonably result in the interruption of life-sustaining services sufficient to cause {§103(b)(1)(C)(i)}:

“(I) a mass casualty event that includes an extraordinary number of fatalities; or

“(II) mass evacuations with a prolonged absence;”

Again, there is some significant confusion in the wording of this section. The ‘interruption of life-sustaining services’ would seem to mean the delivery of food, water, power and medical care for instance. The interruption of those services would hardly result in ‘an extraordinary number of fatalities’ unless they were interrupted over a very wide area over an extremely long period of time. On the other hand damage or unauthorized access to a large chemical facility or nuclear power generation facility could clearly cause a ‘mass casualty event’ or prolonged ‘mass evacuations’.

Cyber Security Regulations


This title requires the Secretary to develop cybersecurity regulations within one year to “enhance the security of covered critical infrastructure against cyber risks [emphasis added]” {§105(a)}. Again, the term ‘cyber risks; only applies to information systems.

In fact, the regulations would require the implementation of ‘risk-based cybersecurity performance requirements’ outlined in §104. Actually the only positive guidance the bill provides for these ‘performance requirements’ is found in §104(b)(1): “require owners to remediate or mitigate identified cyber risks [emphasis added] and any associated consequences identified under section 102(a) or otherwise.

The other requirements for these performance requirements are all negative or restrictive. Section 104(b)(2) does not allow the government to:

• Regulate commercial information technology products;

• Require or forbid the use of commercial information technology products; or

• Regulate the design, development, manufacturing, or attributes of commercial information technology products.

So while §102 and §103 appear to equivocate on the matter of whether or not control systems might be addressed in this bill, §104 and §105 are fairly adamant in their declaration that the systems covered are information technology systems only.

No Effective Enforcement


While it is apparent that the drafters of this bill have ignored a very important part of cyber security, there is an even bigger problem with the critical infrastructure cybersecurity provisions of this bill; there is no effective enforcement mechanism provided for the required regulations. In fact, DHS is specifically prohibited from having an effective enforcement effort.

First off there is no funding for, or establishment of an agency within DHS with responsibility for enforcing the required regulations. Of course, in the current funding environment any money going to a new enforcement agency would have to come out of some other agency’s already depleted budget. The crafters of this bill, instead rely on a tried and failed method of regulatory enforcement; they provide for self-certification of compliance.

Section 105(c)(1)(A)(i) allows each covered critical facility owner to “certify, on an annual basis, in writing to the Secretary and the head of the Federal agency with responsibilities for regulating the security of the covered critical infrastructure whether the owner has developed and effectively implemented security measures sufficient to satisfy the risk-based security performance requirements established under section 104”.

Now if the owner lies, or is even just mistaken, about the adequacy of their cybersecurity efforts, the bill does make provisions for civil penalties for anyone who gets caught violating the regulations and “fails to remediate such violation in an appropriate timeframe” {§105(c)(1)(B)(ii)}. Since no right of inspection is provided for in the bill, the only way that anyone is going to get caught in a violation is if they fall victim to a cyber-attack serious enough to be reported to the Federal government. But that’s kind of too late, isn’t it?

No ICS Coverage


While there will almost certainly be a lot of consternation over various provisions of this bill, the one thing that is abundantly clear, there will be no regulation of control systems under the bill. Control systems might contribute to a facility being designated a covered critical infrastructure, but all of the regulations required by Title I of the bill are solely targeted on information technology systems.

Wednesday, February 15, 2012

S 2105 Available for Download on SHSGAC Web Site

The Senate Homeland Security and Governmental Affairs Committee has a Committee Draft version of S 2105 available for download on their web site. It’s a 205 page document and I just got it, so it will be a while before I have a chance to review it in depth. Hopefully I’ll have a blog post on it this evening.

More Info on Cybersecurity Hearing

Yesterday the Senate Homeland Security and Governmental Affairs Committee published the witness list for tomorrows hearing on their new cybersecurity legislation. There will be three panels; Sen. Rockefeller (D,WV), Secretary Napolitano, and a panel of four private sector (IT not ICS) representatives.

The actual bill was introduced yesterday as well (S 2105) but a copy of it is not yet available from either the GPO or the Committee web site. There is a lot of general discussion in the press about the provisions of the bill, but no clear indication that anyone has yet seen an actual copy (no direct quotes of legislative language that I have seen). Sen. Lieberman (I,CT) is listed as the author with Senators Collins (R,ME), Feinstein (D,CA) and Rockefeller  as co-sponsors.

Interestingly, Feinstein has introduced a separate cybersecurity bill (S 2102, also not yet available at the GPO site) that she reportedly intends to offer as an amendment to S 2105 at some point in the legislative process.

More DHS Budget Request Information

Yesterday, in the lead up to Secretary Napolitano’s appearance before two separate House budget hearings today, the Department of Homeland Security published a 3134 page budget justification document. A quick review (boy I’m glad I took a speed reading course in High School) provides some budget numbers for two important (for readers of this blog anyway) programs and a lot of interesting details about the work of DHS that are not normally readily available to the public.

NOTE: All page numbers are Adobe Reader® page numbers.

Budget Numbers


This document provides program level budget numbers not normally seen in this stage of the budget process. Of particular interest to members of the chemical security and cybersecurity communities it provides numbers for the Infrastructure Security Compliance Program (ISCD) and the Control Systems Security Program (ICS-CERT).

ISCD (pages 2096 and 2103) has no changes to the manpower positions included in the budget request from the FY 2012 budget authorization, but it does have a decrease in funding from $93.348 Million to $74.544 Million. No explanation is given in how the program savings will be achieved.

The ICS-CERT funding request (page 2118), on the other hand, shows an increase in the full-time equivalent manpower positions from the FY 2012 authorized levels from 9 to 12. There is also a very slight funding increase from $28.297 Million to $28.929 Million for the program. Presumably this covers the increased manpower costs.

Misleading Metrics


The document leads off with a number of measures of the effectiveness of the various programs covered in the DHS budget. Of special interest is the one metric mentioned for the CFATS program. On page 13 it notes that ISCD had a FY 2011 target of having 10% of the CFATS facilities “in compliance with the Chemical Facility Anti-terrorism Standards” but only 9.1% achieved that standard. It also noted that they are shooting for 20% compliance in FY2012 and 35% compliance in FY 2013.

No details are given about what constitutes ‘in compliance’ but it certainly cannot be having an authorized site security plan since only four facilities (about 0.1% of the CFATS facilities) have achieved even that standard and all of those were authorized since October 1st. I certainly hope that Secretary Napolitano is questioned about this detail today. I also wonder how many of the other metrics are this misleading.

BTW: The reason that ISCD missed the FY 2011 target was missed was “attributable to scheduled authorization inspections in September 2011 being postponed due to Hurricane Irene”. I don’t recall that being one of the problems mentioned in the ISCD report about program deficiencies.

TSA Surface Security Programs


We don’t typically hear much about the TSA surface security programs as the agencies main focus (in terms of both manpower and money spent) is passenger air travel security. This document does list an number of interesting projects that TSA has worked on over the last year. Not much is provided in the way of detail so I will only list the projects here with the page reference.

• TSA Surface Transportation Rule Making, page 1445;

• Toxic Inhalation Hazard (TIH) Transportation Risk Reduction, page 1450;

• TIH Dispersion Modeling, page 1451; and

• TIH Tank Car Vulnerability, page 1451

The actual test results for the last three items will almost certainly be classified, but they should make their way into the regulatory process over the next decade or so; based upon TSA’s past rulemaking record.

WMD Markup Postponed

The House Homeland Security Committee posted a brief note on their web page yesterday that the markup hearing scheduled for today has been postponed to a date and time to be announced. Readers will recall that this hearing was supposed to include a markup of HR 2356, the WMD Prevention and Preparedness Act of 2011. No reason has been given for the postponement.
 
/* Use this with templates/template-twocol.html */