Analysis of S 3414 – National Cybersecurity Council

As I mentioned in yesterday’s blog post, this replacement Cybersecurity Act of 2012, is a substantial re-write of S 2105. Before I dive into this first of a multi-post review of the provisions of the new bill, I think that we should first look at the major revisions that are included in the bill.

Overview of Revisions

First off Title I of the bill was completely re-written. The old Title I was ‘Protecting Critical Infrastructure’ and the new Title I is ‘Public-Private Partnership to Protect Critical Infrastructure’. The change in name reflects a wholesale revision in both the processes and focus of this legislation. I will be spending quite some time reviewing the provisions of this title.

Two full sections of the remainder of the original bill were removed:

Sec. 408. Cybersecurity incentives.

Sec. 801. Findings.

And three sections were added to other titles in the new bill:

Sec. 303. Research centers for cybersecurity.

Sec. 304. Centers of excellence.

Sec. 415. Marketplace information.

A number of new definitions were included in §2 of the bill, including:

• Category of Critical Cyber Infrastructure

• Critical Cyber Infrastructure

• Significant Cyber Incident

Industrial Control System Coverage

Probably the single most important change in this bill (at least from the view point of readers of this blog) comes in the definition of ‘information infrastructure’:

The term ‘‘information infrastructure’’ means the underlying framework that information systems and assets rely on to process, transmit, receive, or store information electronically, including programmable electronic devices, communications networks, and industrial or supervisory control systems [emphasis added] and any associated hardware, software, or data.

That makes this the first piece of cybersecurity legislation that I have seen that clearly and specifically includes industrial control systems in its coverage. I’m not sure that I think including control systems in ‘information infrastructure’ was really appropriate from a technology point of view, but it sure made the rest of the bill easier to write.

The National Cybersecurity Council

The very constrained power given to the Federal government to oversee cybersecurity in the private sector is vested in a new organization, the National Cybersecurity Council (NCC). The term ‘new organization’ is slightly misleading in that there will be no new office complex in Washington housing a bunch of new bureaucrats, it is an organization whose members are already in government service performing already existing jobs who will be representing the agencies for which they work.

The President will appoint members to this Council from {§101(d)}:

• Department of Commerce;

• Department of Defense;

• Department of Justice;

• The intelligence community;

• Sector-specific Federal agencies, as appropriate;

• Federal agencies with responsibility for regulating the security of critical cyber infrastructure, as appropriate; and

• Department of Homeland Security.

In this case the last agency listed is not the least; the Secretary of Homeland Security is designated {§101(f)} as the Chairperson (and that term is actually used; a serious throw-back to the days of politically-correct gender-neutral titles) of the Council. The Chairperson has carefully enumerated authority to act without the specific consent or direction of the Council {§101(c)(3)}.

The Council will be responsible for {§101(b)}:

• Conducting sector-by-sector risk assessments;

• Identify categories of critical cyber-infrastructure;

• Coordinating the adoption of private-sector recommended voluntary outcome-based cybersecurity practices;

• Establishing an incentives-based voluntary cybersecurity program for critical infrastructure to encourage owners to adopt voluntary outcome-based cybersecurity practices;

• Developing procedures to inform owners and operators of cyber threats, vulnerabilities, and consequences; and

• Providing any technical guidance or assistance to owners and operators consistent with this title.

Cybersecurity Practices

To ensure that the Council does not step on the regulatory toes of any agency in the Federal government, each sector-specific Federal agency and each Federal regulatory agency will have a representative participating with the Council when they deliberate on matters relating to that agency. That is to ensure that any ‘cybersecurity practice’ (more about those in a later post) adopted by the Council {§101(g)}:

• Does not contradict any regulation or compulsory standard in effect before the adoption of the cybersecurity practice; and

• To the extent possible, complements or otherwise improves the regulation or compulsory standard described above

The wording about ‘in effect before the adoption’ would tend to imply that subsequent regulations or compulsory standards would be expected to comply with the adopted cybersecurity practice. It would certainly be nice if there were no conflict between these security practices and subsequent regulations, but there is nothing in this bill that would give the Council any authority or obligation to review new regulations that might impact cybersecurity.

Coordination with the Private Sector

Since the Council is not given any regulatory power, they have to be very careful to cultivate a cooperative relationship with the private sector entities ‘covered’ by this bill. There are frequent uses of the terms ‘in consultation with’, ‘in cooperation with’ and ‘cooperate with’. In fact, the bill specifically requires the Council to coordinate its activities with {§101(e)}:

• Appropriate representatives of the private sector; and

• Owners and operators.

One of the ‘appropriate representatives’ frequently mentioned throughout Title I of this bill is the existing Critical Infrastructure Partnership Advisory Council. Additionally, sector advisory councils and various industry organizations will certainly play an important part in implementing the coordination requirements of this bill.

This section is one that is going to be a likely target of privacy advocates. I expect that we will see attempts to add language to this coordination requirement to add privacy advocates to the those with which the Council will be required to coordinate.

S 3414 Introduced – Replacement Cybersecurity Act of 2012

Yesterday Sen. Lieberman (I,CT) {and four influential colleagues, Carper (D,DE), Collins (R,ME), Feinstein (D,CA) and Rockefeller (D,WV)} introduced S 3414, the Cybersecurity Act of 2012. This bill is a re-write of S 2105, intended to overcome many of the objections to that earlier bill with regards to regulation of critical infrastructure systems and privacy issues. The GPO does not yet have a copy of this bill on their web site, but the Senate Homeland Security and Governmental Affairs Committee does have a draft posted (you have to click on the link to the ‘revised Cybersecurity Act of 2012’ within the article to download a copy, sorry but I don’t like to provide direct links to downloads).

I have not had a chance to do a line-by-line comparison of the new bill with the old, but according to the SHSGA web site article there are a number of provisions that will be important to critical infrastructure organizations (but it isn’t clear that they specifically apply to control systems) that include:

• Establish a multi-agency council National Cybersecurity Council - chaired by the Secretary of Homeland Security - to lead cybersecurity efforts, including assessing the risks and vulnerabilities of critical infrastructure systems.

• Allow private industry groups to develop and recommend to the council voluntary cybersecurity practices to mitigate identified cyber risks. The standards would be reviewed and approved, modified or supplemented as necessary by the council to address the risks.

• Allow owners of critical infrastructure to participate in a voluntary cybersecurity program. Owners could join the program by showing either through self-certification or a third-party assessment that they are meeting the voluntary cybersecurity practices. Owners who join the program would be eligible for benefits including liability protections, expedited security clearances, and priority assistance on cyber issues.

• Creates no new regulators and provides no new authority for an agency to adopt standards that are not otherwise authorized by law. Current industry regulators would continue to oversee their industry sectors.

• Permit information-sharing among the private sector and the federal government to share threats, incidents, best practices, and fixes, while preserving the civil liberties and privacy of users.

• Require designated critical infrastructure -those systems which if attacked could cause catastrophic consequences - to report significant cyber incidents.

The outline above provided by Lieberman’s staff looks pretty good; no new regulators (it doesn’t say ‘no new regulations’) with ‘voluntary cybersecurity practices’. As always the devil is in the details. I’ll be looking at this in detail over the next day or so. Also we have to remember that when this comes to the floor of the Senate (possibly next week) there will be a large number of amendments offered that may change the complexion of the bill completely.

Information Sharing

I just had an interesting TWITTER conversation with Chris Jager (@chrisjager) about information sharing in a cybersecurity context. Chris makes the very valid point that ‘sharing information’ is more than a simple single activity of providing a piece of information. It is a complex set of actions that include a number of decision points that can validly interrupt the process. Mandating sharing cannot overcome that shortcoming.

A Potential Example

Look at §704 of the bill that might make it to the Senate floor this month (S 2105). It establishes the information sharing standard from the private sector to the Federal government. It says:

“Notwithstanding any other provision of law, a non-Federal entity may disclose lawfully obtained cybersecurity threat indicators to a cybersecurity exchange.”

That clearly doesn’t mandate information sharing, it allows (‘may disclose’) for that sharing {and §707(e) specifically prohibits such a mandate}. If we make a minor word change (substitute ‘will’ for ‘may’), that would require disclosure. Under that regime let’s look at how many places the information sharing could legitimately break down.

Scenario: A cyber-attack on a small-town water-treatment plant control system causes a chlorine vent valve to fail-open. This is a proof-of-concept attack that an eco-terrorist group is planning on using on a larger water system where the chlorine release would have major consequences. Timely sharing of information on this attack could prevent a larger successful attack.

Information Sharing Breakdown Points:

Investigation concludes that this is a simple mechanical valve failure – no information sharing requirement.

Investigation concludes that it is a control system related issue caused by operator error – no information sharing requirement.

Investigation concludes that it is a control system related issue caused by a programing error – no information sharing requirement.

Investigation concludes that it is a control system issue related to spurious commands from within the network. Management determines that it is due to a disgruntled employee and thus not a cybersecurity threat – no information sharing requirement.

Investigation concludes that it is a control system issue related to spurious commands from outside the network. Management determines that this is due to inappropriate security controls on the part of the vendor and thus does not indicate a wider cybersecurity threat – no information sharing requirement.

Investigation concludes that it is a control system issue related to spurious commands from outside the network. Management determines that, since the control system is clearly not an information system under the definition of the law, there is no information sharing requirement.

Investigation concludes that it is a control system issue related to spurious commands from outside the network. Management determines that this constitutes a cybersecurity threat indicator and makes appropriate notifications two week after the successful attack on the larger chlorine storage facility.

Depending on the skills of the initial incident investigators the above information sharing breakdown points could be actual findings for this type of incident. If management has a reason to encourage findings other than a ‘cybersecurity threat indicator’ the above investigation findings could easily be justified by an appropriately dis-motivated employee. And if management has made an active determination not to share information any of the above findings could be the directed results of the incident investigation.

Setting up an Information Sharing Network

Congress has to understand that there is much more to setting up an information sharing network than just establishing one in law. The program must provide incentives for the private sector to participate. The program must also remove disincentives that make it difficult to participate.

‘Incentives’ does not mean that the government must pay for this information; rather it must provide the organization with some other form of benefit. The most obvious example would be that joining the information sharing network ensures that the organization will receive timely cyber-intelligence information that can be used in protecting its networks. There could be a system of rewards for information that leads to the prevention of an attack on another organization.

There are a wide variety of disincentives to sharing information about cyber-incidents. One of the most important is the simple fact of not wanting to look stupid or ineffective. Closely following that are financial disincentives like the fear of losing business, or the fear of fines or other regulatory actions. Requiring the annonymization of information before it is re-shared, even within the government, is an important step in preventing many of these types of disincentives.

Finally, the information sharing process has to be as easy as possible. In many ways the Chemical Security Assessment Tool (CSAT) used by the CFATS regulatory process can be a model for they type systems that could be used for submitting cyber-threat information. This type of on-line tool could be set up for each of the critical sectors for an initial screening and annonymization process. This would allow for people familiar with the types of systems and processes involved in that sector to make the initial analysis of the threat.

Organizations within the sector could register with the information sharing system so that they could receive notifications about specific threats to particular control systems (okay and particular IT systems too) that they use within their organization. More general threat information would be shared throughout the sector. Vendors could also register with these systems, providing specific points of contact for information about particular systems that they sell/support.

Moving Forward

Unfortunately it looks like we have the time necessary to set up a more detailed proposal for an information sharing system as it remains increasingly unlikely that Congress is destined to take any final action on cybersecurity legislation before the November election.

Senate Consideration of Cybersecurity Bill

Yesterday theHill.com reported that Sen. Lieberman (I,CT) was saying that the Senate would consider a cybersecurity bill by the end of next week. The article notes that Lieberman was basing this prediction on a promise from Sen. Reid (D,NV). An as of yet not completed compromise version of S 2105 will be the bill to be considered.

The two ideas in the bill that have been holding up consideration have been the requirements for information sharing (privacy protection) and critical infrastructure protection (burdensome regulations of business). As I noted in my initial blog post on this bill, the critical infrastructure protection provisions would not have been particularly effective in regards to their protection of control systems. Further reducing that effectiveness to overcome objections of portions of the business community will make them practically useless in protecting the country from the potential effects of cyber-attacks on critical installations.

If the bill does come to the Senate floor (and Sen. Reid has been making these promises to bring a comprehensive cybersecurity bill to the Senate floor ‘next week’ for two years now) ‘by the end of next week’, it will certainly take some time to get it through the debate process. Let’s assume that it actually passes by July 27^th; that would only leave one week for consideration of the bill by the House before the summer recess begins on August 3^rd. That is not likely to happen.

Differences Between S 2151 and S 3342

I noted last week Sen. McCain introduced S 3342 and without seeing the bill I expected that it was some sort of compromise between his earlier bill, S 2151, and the Senate bill that has been expected to move forward, S 2105. This weekend the GPO made S 2151 available on-line and it turns out that the new bill is more properly a tweaking of McCain’s earlier bill, falling well short of being a compromise measure.

Changes in the Bill

The new bill adds the following new sections:

§104. Construction.

§106. Inspector General review.

§205. Clarification of authorities.

§307. No new funding.

Only one section was removed; §408. Cybersecurity strategic research and development plan.

Additionally, a number of new definitions were added to §101. They include:

• Federal information system

• Information security

• Local government

• Significant cyber incident

• Tribal

Finally there were a number of wording changes that fine-tuned the privacy provisions and information sharing requirements of the bill. The details of those changes, and the added provisions, will probably only be of interest to lawyers and politicians.

There really are no significant changes in the bill and it still completely ignores the problem of cybersecurity of industrial control systems.

Moving Forward

With both the Senate and the House being on their extended July 4^th holiday next week nothing is going to get done any time soon on the cybersecurity legislative front. This bill is dead in the water as the only bill that has any chance of moving forward in the Senate (after inevitable changes) is S 2105. Even that bill has little chance of passing before the election due to privacy concerns and business opposition to new regulations; too many people on both sides of the aisle oppose the bill, so it is unlikely to come to a vote. In most cases this opposition is not just election year posturing so passage even in the lame duck session is unlikely.

S 2151 Introduced – Alternative Cybersecurity Legislation

Yesterday, as he promised during the hearing on S 2105, Sen. McCain (R,AZ) introduced S 2151 yesterday as an alternative method of regulating cybersecurity issues. McCain’s bill is not yet available on the GPO web site (nor anywhere else that I have looked in a cursory search) so I can’t really comment on the provisions of the bill. To see what the various sponsors think the bill says you can look at the press release on McCain’s Senate website.

An interesting procedural note; when the bill was introduced it was referred to the Senate Committee on Commerce, Science, and Transportation for action, not the Homeland Security and Governmental Affairs Committee. These two committees kind of share responsibility for cybersecurity issues in the Senate, so it isn’t too much out of the ordinary.

In the normal course of events one would suppose that the two bills being referred to two different committees would be a sign of a jurisdictional fight between them. That probably isn’t the case here as Chairman Rockefeller was a cosponsor of S 2105 and testified on its behalf before the Homeland Security Committee.

The bill will probably be available next week and I’ll take a detailed look at it then.

S 2102 Introduced – Cybersecurity Information Sharing

Last week Sen. Feinstein (D,CA) introduce S 2102, the Cybersecurity Information Sharing Act of 2012. This bill was later incorporated into S 2105 as Title VII of that bill, so this bill will be unlikely to be acted upon separately unless S 2105 is defeated or substantially amended. Since this is one of the areas of S 2105 that I have not specifically yet discussed (because of the apparent lack of coverage of industrial control systems) I will look at the provisions of this bill and this discussion will also apply to the provisions of Title VII of S 2105.

BTW: The official version of S 2105 is now available on the GPO web site.

Positive Coverage of ICS

This bill (and by extension Title VII of S 2105) does specifically apply to industrial control systems. You have to read past all of the references to ‘information systems’ in the bulk of the bill until you get to §9(10) [§708(10 in S 2105; this is the last time that I will list S 2105 section number; deducing the remaining section numbers will be left as an exercise for the student] that provides the definition of ‘information systems’ (BTW: bill crafters it would be very nice if definitions were put at the start of a bill or title instead of towards the end). That definition reads:

The term ‘‘information system’’ means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information, including communications with, or commands to, specialized systems such as industrial and process control systems [emphasis added], telephone switching and private branch exchange, and environmental control systems.

There is one minor problem with this definition. It would appear that a direct cyber-assault on a piece of control equipment (a PLC for instance) that bypasses the ‘information system’ would not be covered. Of course one could argue that unless the attack was implemented by a direct physical connection (plugging into a USB port for instance) to the PLC, the use of a wireless connection, for instance, would still be covered under this broad definition of an information system.

I particularly like the phrasing “industrial and [emphasis added] process control systems” as this would include control systems for a variety of non-industrial uses. Thus things like power transmission systems, water treatment systems, which are arguably not ‘industrial’, would be covered. In fact, control systems in medical devices, data centers and automobiles would be covered under this wording. Kudos to Sen. Feinstein’s staff for this particular wording.

If this definition of ‘information system’ had been included in §2(12) of S 2105 it would have been clear that that bill was intended to specifically cover industrial control systems. Instead the definition used there was a reference to 44 USC 3502(8) which uses the generally accepted definition of “a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information”.

Authority to Self-Monitor

Section 2 of this bill provides specific ‘affirmative authority’ for a ‘private entity’ to monitor, and to take protective actions on its own information systems or to contract with a 3^rd party to do that monitoring for them. While this action would seem to be self-evident to ICS owners it was designed to provide legal cover to information service providers monitoring “information that is stored on, processed by, or transiting [emphasis added] such information systems for cybersecurity threats” {§2(1)}.

Section 3 allows the private entity to share the information obtained via monitoring with another private entity. Privacy restrictions on sharing personal information are included. Sharing such information may only be made to protect the ‘information system’.

This will be an area with which the civil liberties folks will probably take issue. The crafters of this bill attempted to deflect such criticism by specifying in their definition of monitoring that the authorized monitoring is “for the purpose of identifying cybersecurity threats” {§9(13)}. There are additional civil liberties protections scattered throughout the bill, but this will continue to be a sticking point for any non-ICS cybersecurity legislation.

Cybersecurity Exchanges

The bulk of the rest of this bill (and Title VII of S 2105) deals with the establishment, operation and regulation of cyber exchanges. Cyber exchanges (CE) are organizations that are established “to efficiently receive and distribute cybersecurity threat indicators” {§4(b)}. The DHS Secretary will establish, by regulation, at least one governmental CE as the lead CE. It will act as “the focal point within the Federal Government for cybersecurity information sharing among Federal entities and with non-Federal entities” {§4(c)(1)}.

The bill allows the Secretary 60 days {§4(c)(3)(A)} to name the lead CE and the bill provides {§4(c)(3)(B)}  that in the interim the National Cybersecurity and Communications Integration Center (NCCIC) will serve as the lead CE. Since the crafters of this bill specifically prohibit the creation of “additional layers of Federal bureaucracy for the receipt and disclosure of cybersecurity threat indicators” {§4(g)} it seems clear that they intend for the NCCIC to be designated the lead CE.

The bill also suggests that the Secretary consider designating as CE other current Federal Cyber Security Centers. Those centers are listed in the definition section of the bill {§9(7)} and they include:

• Department of Defense Cyber Crime Center;

• Intelligence Community Incident Response Center;

• United States Cyber Command Joint Operations Center;

• National Cyber Investigative Joint Task Force;

• National Security Agency/Central Security Service Threat Operations Center, or

• United States Computer Emergency Readiness Team (US CERT)

Observant readers will note that the Industrial Control System Cyber Emergency Response Team (ICS-CERT) is not included in the list. The list is not intended to be an exhaustive list of potential CE’s (though its oversight should certainly be corrected in any subsequent amendment of this bill or S 2105) so the Secretary could still designate ICS-CERT as a CE. Since the organization is already fulfilling many of the requirements of a CE its designation is to be expected.

The bill also allows (it does not require) the Secretary to designate one or more CE’s outside of the Federal Government. Section 2(e) provides the information that the Secretary should take into account in this decision making process. Most of these items deal with the ability to protect and share information, but the last will be the largest hurdle to overcome; the “ability of the non-Federal entity to sustain operations using entirely non-Federal sources of funding” {§2(e)(1)(E)}. This is important because no new Federal funding for CE’s is authorized in this bill.

Voluntary Disclosure

The purpose of this whole bill is to encourage the private sector to share information with the Federal government about cybersecurity threats. As such §5 of the bill is the heart and meat of the matter, it provides for the voluntary disclosure of information to CE’s, prescribes how that information may be subsequently shared, and provides non-monetary incentives for sharing such information.

The main incentive is prevention of cyber-attacks, that is a given and not addressed in the bill. All of the other incentives are actually negations of existing disincentives to such information sharing. They include

• Ensuring that the information provided is only used for cyber-protection purposes {§5(b)};

• Exemption from public disclosure under the Freedom of Information Act {§5(d)};

• Exemption from ex parte communications rules {§5(e)};

• Exemption from waiver of privilege {§5(f)};

• Provides criminal and civil liability protections {§7(a)}: and

• Provides limitations on use for regulatory enforcement purposes {§7(c)}.

Oh, and one relatively small of this section {§5(c)} part deals with information shared by the CE’s with non-Federal entities. At first glance that would seem to mean private sector, but in reality it also includes information shared with State and local governments. As such it seems to be lacking any reference to those governments’ use of supplied information for regulatory or law enforcement purposes. This is only partially corrected in the §7 references. This oversight could chill the information sharing process.

Privacy and Civil Liberties

One of the main impediments to passing a comprehensive cybersecurity bill has been developing adequate protections of privacy and civil liberties. This bill {5(g)(4)}specifically places the onus for developing detailed procedures for these protections on the Secretary of DHS. Other federal agencies that are responsible for CE’s are required {5(g)(4)(B)} to adopt the procedures developed by the Secretary. Then the Attorney General is tasked {5(g)(4)(C)}with reviewing and approving these policies and procedures. Finally, copies of the approved procedures (and any subsequent revisions) will be provided to Congress for political review.

Classified Information

One of the complaints that the private sector (and State and local governments for that matter) has had about threat information sharing of any type is that most of that information developed by the Federal government is classified and that the flow of such classified threat information is practically non-existent. Section 6 of this bill attempts to deal with that complaint.

First the bill establishes a new class of non-Federal entities called certified entities {§9(1)}(oops we’ve already used the CE acronym in this bill). First these are entities that are protected (have contracted for cybersecurity services {§9(18)}), self-protected (provide their own cybersecurity services in-house {§9(19)}) or are cybersecurity providers {§9(4)}. Next they must have, or be able to maintain a security clearance {§9(1)(A)}. Finally they must demonstrate the ability to protect and use classified cybersecurity threat indicators {§9(1)(A)}.

Since ‘protected entities’ and ‘self-protected’ entities are by definition (see referenced paragraphs above) not individuals, and security clearances are only issued to individuals, the definition of certified entities certainly needs some work. Does every member of the entity have to have a security clearance (that doesn’t even happen in DOD) or is a single cleared individual on the payroll suffice (that would be a busy bugger just keeping up with the paperwork requirements for classified documents)?

Actually §6 of the bill attempts to address some of these issues. First it makes clear that classified threat indicators are to be shared only with “a person with an appropriate security clearance to receive such cybersecurity threat indicators” {§6(a)(3)}. It also restricts the use of such shared information by a certified entity “in a manner that protects such cybersecurity threat indicators from unauthorized disclosure” {§6(a)(4)}.

This still doesn’t address industry’s complaint that few of their personnel have such clearance, they are not easy (or timely) to obtain, and they may only be needed for a single communication of threat information. The bill addresses this issue by directing the Director of National Intelligence (DNI) to develop guidelines for issuing temporary security clearances to an employee {§6(b)(1)} or a certified entity {§6(b)(2)}, or to expedite the security clearance process {§6(b)(3)}.

Not Much Affect for ICS Organizations

This bill is an interesting attempt at dealing with the information sharing requirements that will be necessary for increasing the public-private partnership necessary to prevent cyber-attacks on industrial control systems. ICS-CERT already has a pretty impressive record of information sharing and little of it would be affected materially by this bill. I’m not sure how much classified threat information ICS-CERT receives from the intelligence community so it is hard to judge how the classified information sharing provisions would affect the ICS community.

What is absolutely missing from this bill from an ICS perspective is any mention of the relationship between software and system vendors and the owner/operators of industrial control systems. The slow, incomplete, or even non-existent response of vendors to the identification of vulnerabilities inherent in their system needs to be addressed in any information sharing legislation that would have meaningful effects on the cybersecurity of industrial control systems.

Finally, one other non-federal entity needs to be added to the list of providers of cyber threat information, the independent security researcher. In the last year we have seen a remarkable increase in the vulnerability disclosures made by these hard-working and oft maligned individuals and small organizations. Their efforts need to be acknowledged and protected in the information providers provisions of this bill.

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.

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.

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.