The Cost of an ICR

On Sunday I responded to a Reader comment about the abbreviated CFATS hearing before the House Appropriations Committee (it was billed as a Committee hearing, but only the Chair and Ranking Member of the Homeland Security Committee were present). I mistakenly ignored the Reader’s comment about the ire of Rep. Price (D,NC) about the cost of the ICR. I reasoned that the actual cost of preparing the ICR, even the crafting of the personnel surety program that the ICR supported, just could not be that high. After all, we are already paying for the salaries of the people who worked on writing the two documents. And they were obviously not doing anything else in any case.

Then I had a conversation with a long time Reader with connections to ISCD. That Reader informed me that ISCD had made payments to TSA in two fiscal years (I forgot to ask, but I assume FY 2010 and FY 2011) for services in support of the personnel surety program; payments probably in excess of $4 million. Cognoscenti will realize that TSA, who operates the Terrorist Screening Data Base (TSDB) is required to recoup the cost of TSDB checks by charging the requesting agency or individual for those checks.

What is interesting here is not that the money was misspent (while $4 million is a lot of money to most people, it really is small change to congressional spenders), but that it was misspent twice. When ISCD published their original detailed ICR notice describing how they intended to operate the program, industry responded with a firestorm of negative comments. At this point ISCD should have realized that there were problems with their proposed personnel surety program and started doing some revising. And they should have not made any pre-payments for TSA services until the program was closer to actual operation.

A year later (which should have been time to revise the program significantly) when the second notice was published, some revisions in details were made, but the main sticking points for both industry and labor remained the same. Like a spoiled child, ISCD essentially said, we want what we want and we are going to get it. The published responses to that were even less positive than the first batch. Who knows how bad the back-channel complaints to OMB were? Actually we can guess pretty well; they were severe enough and numerous enough for OMB not to take any action on the ICR.

Hopefully, when ISCD goes back to the drawing board on this program, they will start from scratch and develop a clean program that provides a mechanism for checking employees, contractors and unaccompanied visitors against the TSDB and allows for the recognition other programs (TWIC and HME for instance) that vet individuals against that database.

Then, when the ICR is approved, ISCD can make the appropriate payment to TSA. And perhaps the Secretary might want to give them at least partial credit for the unused checks that have already been paid for.

BTW: The Appropriations Committee has yet to re-schedule their hearing on the CFATS program.

Reader Comment – 07-29-12 – OMB Delay

An anonymous Reader left a comment on Sunday’s post about another reader comment about the withdrawal of the CFATS personnel surety ICR. This anonymous Reader (maybe the same one, who knows, he’s anonymous) asked two interesting questions:

“I wonder why OMB took over a year without action? Is that standard practice for OMB?”

Year Long Delays

Let’s look at the second question first. Looking at the Office of Information and Regulatory Affairs (an agency of the OMB) web site we can see that since July 30^th 2009 there have been 13,931 information collection requests filed. Of those ICRs, 228 have been withdrawn by the submitting agency. Of those ICRs, 4 were withdrawn one year or more after their submission. The record was 20 months for an EPA ICR for their turbidity monitoring requirements submitted on January 29^th, 2010.

This is certainly not a common action by the OMB, but it is not unique. Most new ICR’s are processed by OIRA in just a couple of months. But every-once-in-awhile the Office drags their feet until the submitting agency drops the ICR.

Why the Foot Dragging

The first thing that we have to remember is that the OMB exists in the Office of the President. While it has a specific regulatory review authority and purpose it is also a political office. In that arena it is responsible for ensuring that the regulatory actions of the various Executive Branch agencies are kept within the political agenda of the President.

This particular CFATS ICR was a political nightmare. In its two formal iterations the personnel surety program drew negative comments from just about every commenter that submitted comments. Labor and management equally detested the program and a number of Congressmen have questioned. The comments of everyone were practically ignored by the crafters at ISCD who moved forward with the politically flawed program.

My guess is that someone at OMB finally convinced the folks at ISCD (and the new Director, David Wulf, really had nothing to do with formulating either the ICR or the underlying program) that the ICR had no hope for approval. With the November election still in doubt the Administration’s hope for putting its mark on the program might depend on an early approval of the ICR.

We will see how quickly the revised program is rolled out.

Analysis of S 3414 – Protection of Information

This is part of an ongoing in-depth review of the provisions of S 3414, the Cybersecurity Act of 2012, that will be of interest to the control systems community. The earlier posts in the series were:

Analysis of S 3414 – National Cybersecurity Council

Analysis of S 3414 – Critical Cyber Infrastructure

Analysis of S 3414 – Voluntary Cybersecurity Practices

Analysisof S 3414 – Voluntary Cybersecurity Program

NOTE: The GPO now has a copy of this bill available.

This post will look at the provisions of §106, Protection of Information. The public-private partnership outlined in Title I allows for and requires critical infrastructure entities within the private sector to provide information to the Federal government. This section provides for the protection of that information.

Information Protection Program

There is a much overdue on-going (but very much delayed) Executive Branch review of the multitude of sensitive but unclassified information programs within the Federal government. The idea is to reduce the number of such programs to a minimum and to rationalize the requirements of the various programs. To avoid adding another complicating program this bill would add the information collected to support the critical cyber infrastructure program to an existing critical infrastructure information program under 6 U.S.C. 133.

NOTE: The bill actually refers to “section 214 of the Homeland Security Act of 2002” {§106(b)(1)}; this is a common and confusing practice in writing legislation. It is much easier to cite the appropriate US Code entry and much easier for a researcher to find the appropriate reference.

That program is designed to protect voluntarily provided information and specifically limits the coverage to information “that is voluntarily submitted to a covered Federal agency for use by that agency regarding the security of critical infrastructure and protected systems” {6 USC 133(a)(1)}. Since some of the information submitted under this bill is required to be submitted {see specifically §102(b)(4)}, the crafters of this bill provided an exception to the ‘voluntarily provided’ requirement {§106(b)(1)}. It is unusual that this section does not actually revise the existing USC language to provide this exemption; that may create an interesting situation for lawyers to argue the applicability of this exemption.

This established information protection regime protects the provided information from:

• Federal {6 USC §133(a)(1)(A)} and State or local {§133(a)(1)(E)} Freedom of Information Act type disclosures;

• Any agency or judicial rules regarding ex parte communications {§133(a)(1)(B)}; and

• Disclosure in any Federal or State civil action {§133(a)(1)(C)}.

It does not prevent disclosure in:

• Criminal investigations and/or prosecutions {§133(a)(1)(D)(i)};

• Congressional hearings and/or investigations {§133(a)(1)(D)(ii)(I)}; or

• Government Accounting Office investigations {§133(a)(1)(D)(ii)(II)}.

Interestingly I see nothing in this section that would allow the Government to share generalized threat information obtained through data provided under the voluntary critical infrastructure cybersecurity program. There is authority to do so under 6 USC §133(g), but again since this section does not modify that portion of the USC in its inclusion of involuntarily provided information, it could be argued that it doesn’t apply to information obtained under this Title.

This is particularly true since the protections on 6 USC 133 only apply to information provided that includes the statement {6 USC §133(a)(2)}:

‘This information is voluntarily submitted to the Federal Government in expectation of protection from disclosure as provided by the provisions of the Critical Infrastructure Information Act of 2002.”

Cybersecurity Tip Line

An interesting part of this section that in some ways seems out of place is the requirement for the establishment of a Critical Infrastructure Cybersecurity Tip Line. This would be established to allow individuals to anonymously (well it doesn’t actually say ‘anonymously’) report “concerns involving the security of covered critical infrastructure against cyber risks” {§106(c)(1)(A)}. It would also be useable for reporting ‘concerns’ about programs or functions established under Title I involving {§106(c)(1)(B)}:

• A possible violation of any [emphasis added] law, rule, regulation or guideline;

• Mismanagement;

• Risk to public health, safety, security, or privacy; or

• Other misfeasance or nonfeasance.

The program concerns reported to this Tip Line would be investigated by an Inspector General. The definition of ‘Inspector General’ in this section {§106(a)(2)} makes it clear that this is not limited to the Inspector General of DHS. There is nothing that describes how it will be determined which IG will conduct the investigation or who will make that determination.

Any information submitted to the Critical Infrastructure Cybersecurity Tip line would be covered information afforded the protections of this section {§106(a)(1)(E)}. That is probably the reason that this was placed in this section of the bill.

Limitations on Protection

Section 106(d) makes it clear that the crafters of this bill did not intend for the protections to be applied overly broadly. It outlines a number of areas to which this section does not apply or limit. It does not:

• Limit the “right, ability, duty, or obligation of any entity to use or disclose any information of that entity” [thus it prohibits the attempted Bayer CropScience PCII defense];

• Prevent the classification of information submitted under this section;

• Prevent the government from obtaining information that is not covered information;

• Prevent DHS from using the information in enforcement proceedings under this Act (the whole thing not just Title I);

• Authorize the withholding of information from Congress, the Comptroller General or any [emphasis added] IG; or

End of Title I

There are a number of sections of Title I that I have ignored in this series of blog posts. They are:

Sec. 105. Rules of construction.

Sec. 107. Annual assessment of cybersecurity.

Sec. 108. International cooperation.

Sec. 109. Effect on other laws.

Sec. 110. Definitions.

While certainly not unimportant, these sections do not appear that they will have any great impact on the control system community as they do not directly apply to operations in the private sector.

I will try to get a general look at the information sharing provisions of Title VII of this bill written up in a post later this week. A lot will depend on how the debate goes and how many additional amendments are proposed that deal with Title I of this bill. Right now it appears that the bulk of the public opposition to this bill deals with Title I and not the privacy concerns with Title VII that were seen with previous versions of the bill.

Reader Comment – 7-27-12 – CFATS Personnel Surety

I had not intended to discuss the opening comments made by the chair and ranking member of the Homeland Security Subcommittee of the House Appropriations Committee in last week’s CFATS hearing since they didn’t have the political integrity to make a copy of their opening statements (either in writing or video) available for the public record. An anonymous reader, however, posted a question about a comment made by Rep. Price (D,NC), the ranking member, about an important issue, so I will relent.

Anonymous noted that:

“One of the interesting questions asked at the beginning from Mr. Price stated that he wanted to understand how so much money was spent on the Personal Surety program and then OMB can deny it. What step was missed in that process?”

Since I have no way of verifying the remark independently because of the lack of public record on the hearing (the hearing web page only provides links to the written statements from the two witnesses, which are independently available on the GAO and DHS web sites respectively) I can only accept the word of my anonymous reader that Mr. Price made such a politically naïve question. As reader’s of this blog are aware, I wrote back on July 21^st that NPPD had withdrawn the ICR, it was not disapproved by OMB.

Now to be fair to Price, who is an obvious political neophyte (Sarcasm Alert), I’m relatively sure that OMB was never going to approve this ICR because of vocal opposition from both business and labor; a political one-two punch that no Administration can afford to ignore. The fact that OMB had taken no action on the ICR in almost a year was certainly a good indication of the poor chance that it stood of being approved.

Now at the end of his opening statement (that part I did catch) the Ranking Member did make a comment about how disappointed that the ICR was withdrawn without notifying the Committee, especially with this hearing in the works. Deputy Under Secretary Spaulding noted in the off-the-cuff start to her testimony that the failure to do so was an oversight and the timing of the withdrawal was specifically selected so that it could be discussed in that hearing.

As I noted earlier, the meeting was cut way short by a lengthy series of floor votes. We will have to wait for it to be re-scheduled to hear that discussion. As of this morning there is no such hearing scheduled, according to the Committee web site.

S 3414 Actual Debate to Start Monday

On Thursday the Senate held their cloture vote on moving forward with the debate on S 3414, the Cybersecurity Act of 2012. The cloture motion was approved on a vote of 84 – 11. To make sure that everyone realized that a vote in favor of cloture would not necessarily mean a vote for S 3414, Sen. McCaskill (D,MO) spoke on the floor of the Senate immediately after the cloture vote, detailing what she viewed as the shortcomings of the legislation.

Summary of Amendments

On Monday afternoon the Senate will formally vote to adopt the motion to proceed to S 3414. According to the HilliconValley blog, in order to get the early and favorable cloture vote, Sen. Reid agreed to an open amendment process during the floor debate. Thursday’s Congressional record reflects this with 39 newly proposed amendments to the bill. Three of the new amendments were completely unrelated to cybersecurity:

SA 2609 – Add Section  – Limitation on Foreign Assistance to Pakistan – S 5568;

SA 2616 – Add Title - Energy Savings And Industrial Competitiveness – S 5615; and

SA 2619 – Add Section  – Right to Work - S5622

Eight of the 39 amendments are full, or nearly full, substitute language amendments providing variations on the SECURE IT legislation (S 2151 and S 3342) previously offered by Sen. McCain (R,AZ). A brief look at the table of contents for the amendments doesn’t provide any indication that any will address control system security issues, so I haven’t attempted to determine the differences between the eight alternatives.

Of the remaining 28 cybersecurity related amendments that try to modify provisions of the current bill 18 deal with the public-private partnership provisions of Title I (many of which I have already reviewed) and four deal with the information sharing provisions of Title VII. These amendments are the ones that will probably be of the most interest to the industrial control system community.

Further Limiting Government Authority

Anyone that has been following the debate about cybersecurity legislation will be unsurprised to hear that most of the amendments are formulated to restrict what little authority that would be given to the Federal government to regulate cybersecurity in the private sector. The widest erasure would be effected by SA 2597 which would completely delete Title 1, the portion of the bill that establishes the public-private partnership that would allow the minimal regulation of private sector cybersecurity.

Another amendment (SA 2590) would add a requirement to conduct a cost-benefit analysis prior to adopting a cybersecurity practice as proposed under §103(b). A similar requirement would be added by SA 2599 in mandating that a report to Congress on the adoption of any suggested cybersecurity measure by a Federal agency would include the results of a detailed cost-benefit analysis. Oh, and that original requirement in §103(g) was for a report on any suggested cybersecurity measure that was not adopted by the regulating agency.

Two other amendments would limit the authority of regulatory agencies to require the use of the voluntary cybersecurity practices as part of their current authority. SA 2595 would change the current wording in § 103(g)(1)(A) that would authorize the agency to adopt cybersecurity measures as mandatory to specifically disallow that adoption. The substitute language for § 105(1) in SA 2601 removes the authorization for adopting such cybersecurity measures. An interesting situation could arise if only one of these two amendments were to be adopted; it would leave competing requirements in the bill.

Provisions already in the bill that prohibit government agencies from requiring private entities to provide information in support of the voluntary cybersecurity program would be further reinforced by SA 2596. That amendment would prohibit any agency that already had legal authority to compel the submission of security information from using that authority to collect information to support the voluntary cybersecurity program.

Filling Holes

There were a couple of interesting holes in S 3414. In an earlier blog I noted that I thought that the liability protections provided in §104 of the bill were a little weasel worded and weak. That would be partially, if negatively addressed by SA 2587. This amendment would actually provide some liability protection to entities that do not choose to participate in the Voluntary Cybersecurity Program. This is probably necessary, but it certainly does not provide any incentive to join the program.

In my blog post about the identification of critical cyber infrastructure I noted that there was a 60-day window for Congress to act on the notification of the designation of a category of critical infrastructure as critical cyber infrastructure. I failed to note that there was nothing establishing what action Congress could take. Amendment SA 2594 partially corrects that by establishing that a ‘resolution of disapproval’ would result in the category being removed from the list and being kept off the list for at least 2 years.

Moving Forward

Late Monday afternoon, after the Senate deals with a judicial nomination, it will begin dealing with S 3414 and its amendments. Given the reported open amendment deal we can be certain that more amendments will be offered. That and the fact that the Senate does not operate under the ‘5 minute’ rule used in the House means that this will take some time to complete, maybe longer than we have before the summer recess begins.

All bets are off, of course, if the opposition (more or less led by McCain and McCaskill the other cybersecurity odd-couple), comes to the conclusion that the bill is unbearable and can muster the 40 votes necessary to stop further consideration of the bill. Oh well, no one said it would be easy; or even likely.

CFATS Hearing Before Appropriations Committee

Yesterday’s scheduled hearing before the House Appropriations Committee’s Homeland Security Subcommittee on the problems at ISCD and CFATS was cut short by floor votes. There have been reports that it will resume sometime next week, but there is not yet anything about that on the Committee web site.

I completely missed the opening statement by Chairman Alderholt (R,AL)  and saw only the tail end of the statement by Ranking Member Price (D,NC). Unfortunately, the Appropriations Committee does not carry links to the webcast of this hearing nor copies of the opening statements. So I guess I’ll just have to give those comments the public recognition that the Committee thinks they deserve; I’ll ignore them.

GAO Report

As I promised in my earlier blog, the GAO provided the Committee with a report on the problems at ISCD. Actually, that isn’t true, at least in the publicly released version of the report. That report looks at how well ISCD is executing its action plan to correct the deficiencies that ISCD determined existed in the CFATS program execution. According to the GAO, ISCD appears to be executing the ISCD plan well.

An interesting statement is found at the bottom of page 10 of the report:

“Additional details on the human capital, mission, and administrative issues identified in the ISCD memorandum are considered ‘for official use only’.”

Hopefully that means that there is a non-public version of this report that addresses those sensitive, but important issues.

While I think there is a certain justification for keeping the details of the ‘issues identified’ by ISCD hidden from public view from a security perspective, I think that Congress, GAO and DHS have a responsibility to share more information with the public in general and the regulated industry in particular. The chemical industry has been spending millions of dollars on addressing issues related to CFATS at the direction of an apparently fundamentally flawed organization. Surely they deserve to know about the basic problems at that organization that may have caused them to waste significant amounts of that money.

The one thing that does come out in the public GAO report is that the problems that have been affecting the CFATS program are not just within the domain of ISCD. The report notes that the ISCD memo included concerns about “insufficient and inconsistent support by NPPD and IP with regard to human capital needs” (page 10). This problem is certainly removed enough from actual security implications that it can certainly be publicly discussed except that it falls within the much more tightly held classification of ‘politically sensitive’.

Deputy Under Secretary Spaulding

Deputy Under Secretary Spaulding is the NPPD official directly responsible for the Office of Infrastructure Protection which includes ISCD. She is certainly not responsible, however, for the problems leading up to the current fiasco since she just took that post last November. As we have come to expect, however, her prepared testimony does little to look at the actual problems involved with the CFATS, and continues in the tradition of optimistic, forward looking testimony by administration officials from two administrations.

She does report on the current status of the CFATS implementation (page 4):

“As of July 20, 2012, CFATS covers 4,425 high-risk facilities nationwide; of these 4,425 facilities, 3,662 are currently subject to final high-risk determinations and submission of an SSP or ASP. The remaining facilities are awaiting final tier determinations based on their SVA submissions. ISCD continues to issue final tier notifications to facilities across all four risk tiers as it makes additional final tier determinations.”

While she completely ignores the SSP approval process here, she does not later (page 5):

“ISCD is currently utilizing an interim SSP review process [emphasis added] to enable ISCD to move forward with SSP reviews in a consistent, reasonable, and timely fashion. At this time, ISCD has completed its initial review of all Tier 1 SSPs and has begun reviewing Tier 2 SSPs. As of July 16, 2012, of the Tier 1 SSPs reviewed, the Department has authorized or conditionally authorized SSPs for 63 facilities. Of the remaining Tier 1 SSPs reviewed by the Department, we are either validating results or reaching out to these facilities to obtain additional information or action in the hope of resolving the outstanding issues affecting their SSPs.”

If the number of ‘authorized or conditionally authorized’ SSPs seems to be rather small, we can take heart in Spaulding’s ‘pleased’ announcement that “as of July 16, 2012, ISCD has resumed authorization inspections at Tier 1 facilities” (page 6). Of course they still have no guidance on their Chemical Security web site for facilities about the interim process; that guidance was removed back in March.

She does take the Committee to task for their reduction in the funding for the CFATS program in the House passed DHS appropriations bill:

“DHS estimates that, after expending approximately $35 million for salaries and benefits for 242 FTEs, approximately $12 million would remain for implementing CFATS and completing development of the proposed Ammonium Nitrate Security Program. DHS would be forced to cease virtually all activities under CFATS other than those directly related to reviewing SSPs and performing facility inspections—which means those other activities would be significantly delayed. At the proposed $45.4 million funding level, the Department’s ability to conduct the most basic CFATS functions would be impacted. These include maintaining the CSAT and the Chemical-Security Management System information technology systems, and acquiring important technical and subject matter support. Additionally, CFATS-related outreach and engagement with the regulated community would be significantly reduced and some aspects would cease; development and implementation of the proposed Ammonium Nitrate Security Program would be significantly delayed; and many of the managerial improvements outlined in the ISCD Action Plan may be delayed or negatively impacted.”

I can understand how the budget cuts can a real management problem, but ‘significantly delay’ the development and implementation of the Ammonium Nitrate Security Program? How can it be ‘delayed’ more than missing its four year congressionally mandated deadline?

Next Week

It will be interesting to see what happens in the questioning before the Committee next week, if that hearing is actually held. It will certainly not be a friendly hearing.

S 3414 Senate Debate Begins Today

Yesterday, Sen. Reid (D,NV) officially started the Senate debate on S 3414, the Cybersecurity Act of 2012. Actually it is the debate to begin the debate and there isn’t yet any real discussion on the floor of the Senate. Yesterday they did schedule a cloture vote on the discussion to begin debate, a procedural vote that usually gives a good indication of how easy it is going to be to get a bill passed. At the end of the day yesterday Sen. Whitehouse (D,RI) announced that the leadership would be attempting to get a unanimous consent agreement today to proceed to the debate without having to go through the procedural vote on Friday.

In addition to starting the debate, the amendment process was also started yesterday with a number of potential amendments being published in the Congressional Record. Of the seven amendments proposed yesterday, 2 have nothing to do with cybersecurity (not unusual on a high-priority bill like this). Most of the remainder deal with data privacy or data security issues.

There is one amendment that might bear watching, SA 2579, which would add a new Title to the bill, the Cyber Crime Protection Security Act. Section _07 of that title would make it a crime to “intentionally cause or attempt to cause damage to a critical infrastructure computer” {47 USC §1030A(b)}.

Analysis of S 3414 – Voluntary Cybersecurity Program

This is part of an ongoing in-depth review of the provisions of S 3414, the Cybersecurity Act of 2012, that will be of interest to the control systems community. The earlier posts in the series were:

Analysis of S 3414 – National Cybersecurity Council

Analysis of S 3414 – Critical Cyber Infrastructure

Analysis of S 3414 – Voluntary Cybersecurity Practices

NOTE: The GPO now has a copy of this bill available.

As anyone that has been reading the various news stories about S 3414 already probably knows, the heart of the difference between this bill and S 2151, at least for critical infrastructure cybersecurity, is that the program is voluntary. That, along with the incentives to encourage voluntary participation, is addressed in §104.

The Voluntary Program

The National Cybersecurity Council, within one year of the passage of this bill, is required {§104(a)(1)} to establish the Voluntary Cybersecurity Program for Critical Infrastructure. While this is to be specifically designed for designated critical cyber infrastructure, the bill also requires {§104(a)(2)(B)} the establishment of criteria for owners of other facilities to apply for certification under the Program.

Any owner operator applying for certification under the Program will “select and implement cybersecurity measures of their choosing that satisfy the outcome-based cybersecurity practices established under section 103” {§104(a)(3)(A)}. At that point the owner will have one of two options to establish the adequacy of their cybersecurity measures {§104(a)(3)(B)}:

• Certify in writing and under penalty of perjury to the Council that the owner has developed and effectively implemented cybersecurity measures; or

• Submit to the Council an assessment verifying that the owner has developed and effectively implemented cybersecurity measures.

While the first option should be cheaper in the short run, paying someone to conduct the assessment may avoid the problem ‘under penalty of perjury’ might pose if there is a subsequent successful attack on the system.

To ensure that assessments are conducted by reputable and properly skilled professionals, the Council will “enter into agreements with qualified third party private entities, to conduct assessments that use reliable, repeatable, performance-based evaluations and metrics to assess whether an owner certified under subsection (a)(3)(B)(ii) is in compliance with all applicable cybersecurity practices” {§104(b)(1)}.

In either case, when the Council is notified that the owner has an adequate cybersecurity program implemented, it is required {§104(a)(4)}to certify that owner.

Checking Security

While the Council is required to accept either the owner’s self-certification or the third-party assessment, the bill does provide that in the event that Council becomes aware (either through  actual knowledge or a reasonable suspicion) “that the certified owner is not in compliance with the cybersecurity practices or any other risk-based factors as identified by the Council” {§104(b)(3)}, the Council may conduct its own assessment of those security practices.

Once again, though, since there is no authorization for a Council Staff or any specific funding for the Council, any such assessment will have to be done for the Council by some other entity. It does not appear, however, that the wording in this section doesn’t appear to authorize the use of another entity.

Incentives for Participation

Since participation in the Voluntary Cybersecurity Program for Critical Infrastructure is mainly voluntary, the crafters knew that they had to offer some sort of incentives to encourage the participation of as many of the identified critical cyber infrastructure entities as possible. The incentives provided in this bill include {§104(c)}:

• Limitations on civil liability;

• Expedited security clearance process;

• Prioritized technical assistance;

• Provision of cyber threat information;

• Public recognition; and

• Procurement preference.

Much has been made in the press about the civil liability protections provided in this bill. There are, as one would expect, a number of different specifications, limitations and exceptions to that protection. A number of common lawyer type phrases have been added to this paragraph {§104(c)(1)} to limit the applicability of the ‘protections’; they include ‘punitive damages’, ‘substantial compliance’, ‘harm directly caused by’ and ‘additional or intervening acts or omissions’. Still, in the event of a significant attack, the limited protections could be significant.

The other benefits will provide some level of incentive, but it is not clear that they would be enough to justify the costs of the cybersecurity measures that will likely be required. The one possible exception is the last incentive, a Federal procurement preference. Unfortunately, the bill doesn’t actually provide this incentive; it just requires {§104(c)(6)} that a study be conducted about the potential use of such a preference. There is no time limit on conducting the study nor is there any provision for implementing the incentive if the study results are encouraging.

Analysis of S 3414 – Voluntary Cybersecurity Practices

This is part of an ongoing in-depth review of the provisions of S 3414, the Cybersecurity Act of 2012, that will be of interest to the control systems community. The first post in the series was:

Analysis of S 3414 – National Cybersecurity Council

Analysis of S 3414 – Critical Cyber Infrastructure

In today’s posting I will look at §103 and the requirements for establishing voluntary cybersecurity practices. These practices will be those that critical cyber infrastructure facilities will be judged against.

Private Sector Development

The bill gives the private sector the first shot of developing ‘cybersecurity practices’ through each sector coordinating council. The term ‘cybersecurity practices’ is vaguely defined as “voluntary outcome based cybersecurity practices … sufficient to effectively remediate or mitigate cyber risks identified through an assessment conducted under section 102(a)” {§103(a)}.

These practices will be based upon “industry best practices, standards, and guidelines” {§103(a)(1)}. Where such practices don’t already exist, the sector coordinating councils will develop the practices in coordination with appropriate entities within the sector. The bill gives them 180 days to complete this development.

Council Review

Section 103(b) requires the National Cybersecurity Council, as always in consultation with CIPAC and ISAOs to:

• Consult with relevant security experts;

• Review relevant regulations or compulsory standards or guidelines;

• Review cybersecurity practices proposed by the sector coordinating councils; and

• Consider any amendments to the cybersecurity practices and any additional cybersecurity practices necessary to ensure adequate remediation or mitigation of the cyber risks identified through an assessment conducted under section 102(a).

Then, within one year of the passage of this bill, the Council is required to adopt the proposed cybersecurity practices {§103(a)(2)(A)(i)} and amend or add to those practices as deemed appropriate by the Council {§103(a)(2)(A)(ii)}. If no cybersecurity practices are submitted by the sector coordinating councils, the Council is required to develop those practices on its own. Presumably this will be done in consultation with CIPAC and ISAOs, but that is not required {§103(a)(2)(B)}.

In developing these cybersecurity practices the Council is required {§103(d)} to prioritize the development based upon the risk assessment discussed in yesterday’s blog post. This risk assessment will not be available to the sector coordinating councils as it will be developed concurrently with their development of cybersecurity practices. Besides there are no provisions in the bill that would require the sharing of this risk assessment with the sector coordinating councils.

These cybersecurity practices are to be living requirements to be reviewed and adjusted by the sector coordinating councils and the Council no less frequently than every three years.

Technology Neutrality

The crafters of this bill clearly wanted to ensure that no one company or industry unduly benefited from the provisions of this bill as they mandated that the cybersecurity practices be technology neutral. This means that a cybersecurity practice could not require {§103(f)}:

• The use of a specific commercial information technology product; or

• That a particular commercial information technology product be designed, developed, or manufactured in a particular manner.

Existing Regulations

The bill would allow existing regulatory agencies to adopt cybersecurity practices as mandatory {§103(g)(1)(A)}. In fact it actively encourages agencies to do so by requiring them to report to Congress why they have not done so within one year of the enactment of this bill {§103(g)(1)(B)}. Given that the Council has up to one year to adopt/establish the cybersecurity practices and any adoption of those practices as mandatory would have to go through the publish and comment process, there will be a lot of reporting to Congress.

The crafters of this bill were careful to note that this bill does not give any agency any additional authority to regulate cybersecurity {§103(g)(1)(C)}. This means, for example, that the current prohibition under CFATS for DHS mandating any security procedure still applies to these cybersecurity practices.

The bill also specifically does not step on the toes of existing regulatory regimes. The adopted cybersecurity practices may not prohibit an entity from complying with an existing law or regulation {§103(g)(2)}.

Independent Review

The bill requires {§103(h)} that a public review of each cybersecurity practice will be accomplished by CIPAC and the sector coordinating councils. CIPAC meetings are already public (in most instances) and a notice is required to be published in the Federal Register about all such meetings, public or not. Sector coordinating councils are not so closely regulated and it is not clear how the drafters expect to require their review to be public.

Voluntary Technical Assistance

Finally, this section requires {§103(i)} the Council, when requested by an owner/operator, to “provide guidance on the application of cybersecurity practices to the critical infrastructure”. Given that the Council is not provided a staff or funding it is not clear how this guidance will be provided. I would guess that the crafters intended it to come from the existing regulatory agencies that are already understaffed and underexpertised (new word) on cybersecurity matters.

ICS-CERT Publishes Three Advisories – Two for Siemens

Yesterday afternoon DHS ICS-CERT published three advisories; one about a recent coordinated disclosure and two about old vulnerabilities identified by the vendor. The new one concerns a single vulnerability in a variety of Invensys systems. Both of the older problems deal with Siemens systems. Oh, and remember this for later the new Advisory and one of the old ones deal with dll vulnerabilities.

Invensys Advisory

This advisory deals with an uncontrolled search path element vulnerability (otherwise known as a dll hijack) in a variety of products in the Wonderware System platform family. The vulnerability was discovered by Carlos Mario Penagos Hollmann. The advisory was first posted on the US-CERT secure portal on July 5^th.

A moderately skilled attacker could exploit this vulnerability and place a malicious dll in the system. To exploit this vulnerability the attacker must have physical access to the system or be able to manipulate a user with access to the system.

Invensys has developed a patch for the affected systems which is available on the Wonderware web site.

Siemens Advisories

Siemens self-reported two vulnerabilities that are being addressed in separate advisories. The first is an insecure SQL server vulnerability and the second is dll loading mechanism vulnerability. As if self-reporting is not odd enough (to be encouraged to be sure, but odd), the first vulnerability was patched in 2010 (update V5.5 SP1) and the second in 2011 (update V7.0 SP 2 Update 1).  Both vulnerabilities can be remotely exploited and there are publicly available exploits available for both.

No word about why Siemens wanted these vulnerabilities made public at this late date. It does seem obvious that they are the ones responsible for ICS-CERT publishing these now, but for the life of me I can’t figure out why.

MS DLL Advisory

I’m not sure if Chris Jager knew about the two dll vulnerabilities being reported by ICS-CERT, but in a Tweet this afternoon he pointed us at a Microsoft Security Advisory from earlier this month (actually updated the 17^th time earlier this month) about insecure library loading. It discusses the type of dll injection attacks covered in the two advisories published today. It notes that MS has provided guidance to software developers “on how to correctly use the available application programming interfaces to prevent this class of vulnerability”.

More importantly for system owners “Microsoft is releasing a tool that allows system administrators to mitigate the risk of this new attack vector by altering the library loading behavior system-wide or for specific applications”. While this is not a control system specific tool, the fact that this vulnerability has been found in so many ICS systems might make it an important tool that should be in the ICS security tool box.

It might be a good idea for ICS-CERT to partner with Microsoft on making this tool specifically available to ICS owners.

Analysis of S 3414 – Critical Cyber Infrastructure

This is part of an ongoing in-depth review of the provisions of S 3414, the Cybersecurity Act of 2012, that will be of interest to the control systems community. The first post in the series was:

Analysis of S 3414 – National Cybersecurity Council

In today’s posting I will look at the provisions of §103 which deal with the identification of critical cyber infrastructure. This is important as the only private sector entities that will be directly affected by the provisions of this bill will be those so identified.

Risk Assessments

The bill requires {§102(a)(1)(A)} that an agency from within the members of the Council be appointed to conduct high-level risk assessments of cyber risks to critical infrastructure. There are two separate protections provided that ensures that private sector participation in this risk assessment process is voluntary. First the bill states that the participation will be voluntary {§102(a)(1)(A)} and then it specifically states that {§102(a)(1)(B)}:

“Nothing in this subsection shall be construed to give new authority [emphasis added] to a Federal agency to require owners or operators to provide information to the Federal Government.”

Clearly there is a minor conflict between the two provisions. If the Federal Government already has authority to compel the provision of cyber security information, then that information can presumably be used in the conduct of risk assessments. Some sectors that are already compelled to submit cybersecurity data include the nuclear sector and CFATS covered facilities.

It is intended that the lead agency conduct this assessment in a cooperative fashion with other government and private sector agencies. Some of the private sector entities specifically listed in this cooperative requirement are {§102(a)(2)}:

• Critical Infrastructure Partnership Advisory Council (CIPAC); and

• Information Sharing and Analysis Organizations (ISAO)

Readers are reminded that there is an influential control systems organization within CIPAC, the Industrial Control System Joint Working Group (ICSJWG). They will be an invaluable resource for conducting the risk assessment of control systems.

The agency conducting the risk assessment is required to establish a process by which “owners and operators and other relevant private sector experts” {§102(a)(3)(A)} can provide input into this process. Given the tight timeline required for the initial assessment (180 days), it is unlikely that the ‘process’ will be established soon enough for much participation in the initial assessment, but this assessment will be updated on an “ongoing basis” {§102(a)(2)(B)} so we would expect more input at that stage of the process.

The completed risk assessments will be submitted to the President, appropriate Federal agencies, and Congress. The assessment will be submitted in both a classified and unclassified version. Since an unclassified version is being required to be produced, it would seem to me that requiring the public publication of that version should be required in this bill. At the very least  CIPAC, the ISAOs and the owners and private sector entities that participated in the development of the risk assessment should also be included in the distribution of the unclassified version.

Identifying Critical Cyber Infrastructure

Section 102(b) requires the establishment of procedures for the identification of categories of critical cyber infrastructure. Again it is clearly enumerated within this bill {§§ 102(b)(1) and 102(b)(2)(B)} that the process will be a cooperative one involving Federal agencies, CIPAC, ISAOs, owners, private sector entities as well as State and local government agencies.

The definition of ‘critical cyber infrastructure’ is a rather wide ranging operational definition. It is defined by the resulting damage that can be done by damage to or unauthorized access to such critical infrastructure. The bill limits coverage to infrastructure which could result in {§102(b)(3)(B)}:

• The interruption of life-sustaining services;

• Catastrophic economic damage to the United States; or

• The severe degradation of national security or national security capabilities.

Interestingly, most high-risk chemical facilities covered under the CFATS program, even those where large mass casualty events could occur, would not be able to be designated as critical cyber infrastructure under this definition. Water treatment plants could be covered, but chlorine producers could not. It is questionable if even a large petrochemical refinery could be covered because of the vague definition of ‘incapacitation of or sustained disruption of a transportation system’ {§102(b)(3)(B)(ii)(III)}. Even an electrical transmission system entity might not fall under the ‘life-sustaining services’ description because of a lack of ‘a mass casualty or mass evacuation’ outcome {§102(b)(3)(B)(i)}.

There is another significant limitation of critical cyber infrastructure. In order to appease people concerned with the regulation of the internet as an infringement of first amendment rights, the bill specifically prohibits identification of an entity as ‘critical cyber infrastructure’:

• Infrastructure based solely on activities protected by the first amendment {§102(b)(5)(A)};

• An information technology product based solely on a finding that the product is capable of, or is actually, being used in critical cyber infrastructure {§102(b)(5)(B)}; or

• A commercial item that organizes or communicates information electronically {§102(b)(5)(C)}.

Notification

The bill provides that within 10 days of the determination of an entity being identified as critical cyber infrastructure the Council will notify both the owner and Congress of that determination. There is no provision in this section for appeal by an owner of the designation, but there is 60-day window for Congressional action on the designation before the designation takes effect. Under our current and foreseeable situation of Congressional stalemate, it is unlikely that either house of Congress much less both, could take action during that time frame.

Incident Reporting Requirements

There is one paragraph in this section that does provide an affirmative requirement for action to be taken by any entity designated as critical cyber infrastructure. Section 102(b)(4) requires that:

“The Council shall establish procedures under which each owner of critical cyber infrastructure shall report [emphasis added] significant cyber incidents affecting critical cyber infrastructure.”

The definition of ‘significant cyber incident’ is provided in §2(24) of the bill. It defines such an incident in terms of what happened or could have happened as a result of the incident. Two such results are included:

• The exfiltration of data that is essential to the operation of critical cyber infrastructure; or

• The defeat of an operational control or technical control, as those terms are defined in section 708, essential to the security or operation of critical cyber infrastructure.

Nothing in this reporting requirement requires that actual damage of the critical cyber infrastructure takes place or that any outside entity is damaged in any way.

ICS-CERT Updates Tips and Issues Unusual Advisory

Last Thursday the DHS ICS-CERT published an update of a technical information paper (TIP) that they issued in May. They also issued an advisory for a vulnerability for a very common interface used by a wide variety of control systems. The odd thing about this advisory is that the vulnerability was not discovered by an independent security researcher; OSIsoft requested ISC-CERT to examine their product for vulnerabilities.

Tip Sheet

Back in May ICS-CERT published “Targeted Cyber Intrusion Detection and Mitigation Strategies” after the public disclosure of a number phishing attacks on gas pipeline companies. At the time I wrote that:

“As one would expect, there is nothing really new here, but it is a nice summary of the multiple levels of cyber protection that need to be employed to help reduce the effectiveness and impact of a targeted cyber-attack.”

This new addition to the TIP addresses the issue of credential management and it provides a wealth of information that ICS-CERT has not addressed previously. And the topic is important in defending a system that has been breached by a phishing attack.

The information provided in the new two and a half pages added to the TIP covers a wide range of topics about the ins and outs of protecting passwords and their hashes. That isn’t enough to go into a real useable level of detail, but ICS-CERT did provide a number of footnotes to additional information that will provide the level of detail necessary for most administrators.

I’m not sure why this data wasn’t included in the initial publication; the information is not new. Oh well, better late than never.

OSIsoft OPC Interface

This advisory for the PI OPC DA Interface addresses a buffer overflow vulnerability that would allow a medium skilled attacker to write data to OPC items collected by the PI OPD CA Interface. OSIsoft has made a software update available that corrects the problem.

As I noted earlier, this vulnerability was actually discovered by ICS-CERT. Since the discovery was made under contract with OSIsoft they would have retained the rights to allow the publication of the discovery. So I’ll add my kudos to those provided by Dale Peterson at DigitalBond to OSIsoft for their allowing the public disclosure of this vulnerability.

BTW: Dale has a much more detailed look at the importance of this vulnerability on his SCADA security blog. The whole discussion following his post is well worth reading.

NOTE: I made an error in my comment on Dale’s post; I got my days wrong because of a crazy schedule. I downloaded my copy of the OSIsoft Advisory on Thursday evening.

Congressional Hearings – Week of 07-23-12

With two weeks left before the long summer vacation Congress starts to look more at the bills that can pass rather than the legislation that is needed. There are only two hearings that will be of interest to the chemical security community and only S 3414 possibly on the horizon for the cybersecurity community. The two House hearings of interest are a homeland threat assessment and a CFATS Hearing.

Homeland Threat Assessment

The House Homeland Security Committee will be holding a hearing Wednesday on “Understanding the Homeland Threat Landscape”. Secretary Napolitano and the National Counterterrorism Center Director Matthew Olsen are the only witnesses currently scheduled to testify. This is scheduled as an open hearing so there won’t be anything really interesting here.

CFATS Hearing

On Thursday the House Appropriations Committee will be holding a hearing on the Chemical Facility Antiterrorism Standards (CFATS) program. It seems kind of odd timing for such a hearing before this Committee as the DHS spending bill that already passed in the House had the CFATS funding cut in half by the Committee.

Having said that it looks like this may be an important hearing for the future of the CFATS program. No one from ISCD is scheduled to testify. The DHS witness is Under Deputy Secretary Suzanne Spaulding, the number two person at NPPD. She won’t have much personal insight into the source of the problems at ISCD since she just joined NPPD in November, but the Committee will probably be pressing here for info on the steps being taken to correct the problem.

The most important witness, however, will be Director Steve Caldwell, of the GAO’s Homeland Security & Justice Issues. The report that he presents to the Committee will be the first real outside look at this program since its inception in 2007. It will certainly be the first definitive look at CFATS since its problems were publicly identified in December.

It is unfortunate that the first real look at these problems has to come from the Appropriations Committee, particularly after this year’s appropriations process has been almost completed. But the Senate Homeland Security Committee has completely ignored their oversight responsibility and the House Homeland Security and the Energy and Commerce Committees held hearings that were even less effective than the NPPD oversight of the program. So it is left to the Appropriations Committee to take care of a problem that was created in an appropriations bill.

The Appropriations Committee does have one more potential time to affect the CFATS program this session. That is when the DHS spending bill comes before the conference committee to iron out the inevitable differences between the House and Senate versions of the bill. Unless this hearing produces some news of an overwhelming turnaround at ISCD (and there has been no public performance to date that would indicate that) I would expect that this committee’s leadership will insist on their draconian cuts of the funding for the CFATS program; cuts that were not questioned in the House consideration of the bill.

S 3414

The Senate does not publish a weekly schedule of what it will be considering (it doesn’t know itself that far in advance), but it is looking increasingly likely that S 3414 may actually make it to the floor this week. News reports seem to indicate that the privacy advocates are satisfied with this revision and we have heard little from the business community. If they have no serious objections the Senate might start consideration of this bill. If they do there will be lots of amendments to be considered and I doubt that the bill will be passed this week. It still won’t be taken up by the House until after the election (if then) in any case.

OMB Announces Withdrawal of CFATS Personnel Surety ICR

Yesterday the Office of Management and Budget (OMB) announced that DHS/NPPD had withdrawn the information collection request (ICR) necessary to implement the CFATS personnel surety program. This is the program that would have ISCD collect personnel information on facility personnel and visitors with unaccompanied access to high-risk chemical facilities to check those personnel against the Terrorist Screening Database (TSDB). This check is required for Risk-Based Performance Standard #12.

There was no indication in the notice why the ICR had been withdrawn, but this ICR has been opposed by industry as overreaching. It has also been criticized by many members of Congress on both sides of the aisle for not utilizing the TWIC, or at least formally recognizing the TWIC, as the method of vetting personnel with unaccompanied access to high risk chemical facilities. One would hesitate to suggest that political considerations were behind the NPPD action.

One would like to think that the formal withdrawal of this ICR would be an indication that the Infrastructure Security Compliance Division (ISCD) has a new personnel surety program ready for release in the near future. Perhaps there will be an announcement about this program that will be made in association with the Chemical Sector Security Summit at the end of the month.

Of course the problems that we have been seeing with the failure to release new guidance on the SSP implementation process probably argues against any quick resolution to the personnel surety problem. ISCD is getting further and further behind and it is fast reaching the point where if significant progress is not seen in the near future, we should seriously consider disbanding ISCD and re-starting the CFATS program from scratch.

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.