Enforcing the President’s Cybersecurity Plan

The Obama cybersecurity plan would establish extensive regulations for the security of cyber systems at selected critical infrastructure entities. As I have noted on several occasions in this blog trying to regulate anything without some sort of inspection and compliance verification mechanism is a waste of time. The Administration’s plan addresses this in §6 of their critical infrastructure plan.

Private Sector Evaluators

The proposal avoids the problem of the government having to hire and maintain an expensive cybersecurity inspection workforce by establishing a private sector inspection program. Similar in many ways to the way TSA regulates the inspection process for freight going on to passenger aircraft, the proposal would establish a two-tier system of accreditors and evaluators. The accreditors would be contracted by DHS to “conduct such activities as the Secretary determines to be necessary to effectively carry out accreditations of evaluators and oversee the evaluation process” {§6(b)(2)}.

This is appropriately vague for a legislative proposal and the details would have to be worked out during the process of developing the supporting regulations. Some of the details need to be worked out, however, in the legislative process. For example, it seems obvious to me, but it is never mentioned in the proposal that it will be the covered entities that somehow pay for the evaluation process. What is less clear is how the administration plans on paying for the accreditation process.

How Many Evaluators

As I mentioned in my earlier blog post over at Digital Bond's SCADA Security blog, Larry Clinton of the Internet Security Alliance raises an interesting issue about this evaluation force. On page 10 of his written testimony for last week’s House hearing he states:

“Moreover, it is acknowledged on all sides that we face a critical shortage of qualified cyber security personnel, and so the army of evaluators created under this proposal will almost by definition not be adequately trained.”

The situation will be even worse for industrial control systems evaluations. There is nothing in the President’s proposal that addresses the differences between IT and ICS cyber systems. This is especially critical establishing an evaluation force. Even a well trained and experienced IT security expert will have difficulties evaluating a security plan and its implementation for control systems. A less well trained evaluator trying to apply a generic set of cyber security standards to a control system will cause more problems than most cyber attacks.

Nobody knows how large an evaluation force will be needed to enforce these proposals. The reason is that no one knows how many entities will covered by the critical infrastructure cybersecurity program. From a control system perspective it could be just a relatively small number of pipeline systems and electrical transmission systems if a restrictive view of the “dependent upon information infrastructure to operate” requirement of §3(b)(1)(B) is used to designate covered entities. If Mr. Clinton’s fear of a more expansive definition is realized the ICS inspection force could be quite large.

Conflicts of Interest

One of the easiest ways to expand the size of the potential evaluator work force is to utilize existing security contractors. This, of course, sets up the potential for some interesting conflicts of interest. A contractor that advises a facility on establishing a security program could find itself evaluating that same program. While one would expect that regulations should address this, many would expect this to be specifically addressed in any legislation mandating such a private sector inspection force.

Personnel Surety

The Internet Security Alliance testimony raises another interesting concern about this inspection force. Again on page 10 of the testimony Mr. Clinton says:

“The single largest vulnerability of our cyber systems comes not from hackers using technology to break into systems, but from “insiders” with approved access to the systems. This proposal creates a virtual army of insiders crawling through our most critical infrastructure’s security systems on an annual basis.”

The failure of the President’s proposal to address the personnel surety issue is completely unacceptable. This is especially true since historically much of the cyber workforce is foreign trained. From the experience that DHS has had with the personnel surety issue in the TWIC program, the Hazmat Endorsement for CDLs and the CFATS program certainly demonstrates that this controversial area needs to be addressed in the legislative proposal.

For control systems inspectors there is an additional area about personnel surety that will have to be addressed. Depending on how expansive the coverage of critical infrastructure actually is, there will be a number of CFATS covered facilities included in the program. The CFATS program has some very specific personnel surety requirements that are currently being rolled out. That program exempts the DHS inspection force (as well as first responders and law enforcement personnel) from the requirement for facilities to complete background checks before allowing these personnel to have unaccompanied access to facilities. Since the cybersecurity evaluators are not DHS employees this exemption will not apply to them.

Actually, I guess that IT evaluators for entities that own or operate CFATS covered facilities will probably have to undergo the same background check process if the IT systems are included in the facilities list of critical or restricted systems. Will evaluators dealing with MTSA covered facilities need to have TWICs? Probably. Water facilities, don’t worry about it, EPA has no personnel surety concerns. Railroads? The FRA don’t care.

Yes, we can clearly see why the cyber security proposal for critical infrastructure needs to specifically address the personnel surety issue.

Who Speaks for the ICS Community?

Joe Weiss has an interesting commentary about the blog post I recently did for Dale Peterson over at Digital Bond's SCADA Security blog. He is concerned (and Joe and I have talked about this) about the fact that the Internet Security Alliance (ISA, the other ISA) has no ICS security members and I recommended that my readers read their President’s testimony. He closes by saying: “Larry did not understand the unique issues associated with ICSs. This is another case of why it is important for the ICS community to speak for itself.”

My Response

I posted the following response on the Unfettered Blog site; last I saw it was awaiting moderation so it may not be up yet.

“Actually Joe, the post you quoted was one that I posted on Digital Bond's SCADA Security blog. While Larry Clinton may not know squat about ICS security (and to be fair his comments were not about ICS security) he made some very interesting points about what types of ‘entities’ would be covered by the President’s proposed legislation. I certainly don’t agree with all of his points as readers of my blog are aware (see Monday’s post), but the points that he does make need to be discussed before they get incorporated in legislative language that ends up making ICS security even more difficult.

“I certainly agree that the ICS community needs to speak for itself in this matter (and I hope my blog posts on this topic are helping to generate that discussion) but we do need to know what others are saying about cyber security issues that will certainly directly effect what we do or have done to us.”

Expanded Discussion

The issue is important enough that I think it deserves more than just the response I provided on the Control Global site.

First everyone needs to understand the President’s proposals (and the critical infrastructure proposal, pages 31-37 of 52 pages, is just one of a series outlined by the Administration in a single document) do not directly address industrial control system security. They do provide for the establishment of regulations that would address cybersecurity requirements for critical infrastructure. ICS security would be a small but important sub-set of the cybersecurity that could be addressed in those regulations.

The very important issue that Mr. Clinton addressed was how DHS would determine what private sector entities would be regulated and which would not. This is an important part of the proposal; systems are not regulated, ‘entities’ are. So if a regulated entity has industrial control systems, their cybersecurity plan would have to address security issues associated with their ICS. Likewise, no matter how ‘critical’ a control system was or how vulnerable it was, if it is not owned by a regulated entity then DHS would have no say in the security of that system.

So this is yet another issue where the ICS community, the IT community and the corporate security community are all going to have to get together to adequate address. If we have to listen to an IT type explain the overall issue, so be it. Where their issues are different, we need to speak up. But we should still listen.

Opposing Views on Cybersecurity and DHS

Earlier today I had a post appear on Digital Bond's SCADA Security blog discussing the testimony of Mr. Larry Clinton, President, Internet Security Alliance (ISA; as Dale noted not The ISA of cyber standards renown), before the Subcommittee on Cybersecurity, Infrastructure Protection, and Security Technologies of the House Homeland Security Committee last week in a hearing about the President’s cybersecurity proposal.

In that post I looked at two of the problems that concerned Mr. Clinton about that proposal; the expansive definition of ‘covered critical infrastructure’ and the lack of qualified people to enforce the annual review requirements. I would like to take a closer look at the first issue here.

Expansive Definition of Critical Infrastructure

In reviewing the standards that the President’s legislative proposal provides for determining which critical infrastructure entities would have to comply with the new cybersecurity standards Mr. Clinton notes that “a careful reading of the legislative language indicates that it provides essentially unfettered authority to DHS to mandate technical standards for almost any aspect of the private sector” (pg 8). While there is more than a hint of political paranoia in that statement, the underlying concern rests clearly on the vague terms and lack of definitions included in the President’s proposal.

Clinton’s testimony looks at the two criteria that a facility must meet before the Secretary can label is ‘covered critical infrastructure’. These two criteria are found in §3(b)(1) on page 32 of the proposal. They are:

● The incapacity or the disruption of the reliable operation of the entity, a system or asset it operates, or a service it provides would have a debilitating impact on national security, national economic security, national public health or safety; and

● The entity, a system or asset it operates, or a service it provides is dependent upon information infrastructure to operate, or is a part of information infrastructure and critical to its operation.

Mr. Clinton focuses on the word ‘debilitating’; quite correctly noting that it is undefined in this context. He goes on to give the example of the recent cyber security breach at Sony; an attack that he notes “reportedly will cost more than a billion dollars in damage” (page 9) and makes the point that that would certainly be ‘debilitating’.

What he fails to understand is that this wording comes almost directly from the current definition of ‘critical infrastructure’ found in 42 USC 5195c(e). The Secretary has already been given considerable regulatory authority over critical infrastructure and few observers would point to the Department as being overly expansive in the reach of their regulations. In fact, I have complained on a number of occasions about their failure to write regulations that they are required to promulgate.

In the second section of the requirements he targets the term ‘information infrastructure’ and claims that “virtually all modern systems that are reliant on some form of information infrastructure to operate” (page 8). That term is not defined in this rule, a glaring oversight in view of its central nature to the regulatory scheme. We can, however, go to 44 USC 3502(8) for a definition of ‘information systems’ to find a better term for what Clinton describes.

An information system is defined as “a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information”. Again this is not referenced in this proposal (and it should be), but if we use this definition to describe networks within a facility for the management of information or process control, then we would use the term ‘information infrastructure’ to describe the inter-facility communications media that allows for transmission of that information or coordination of process control at multiple facilities.

Mandating Technical Standards

Mr. Clinton’s concern about the authority given to the Secretary to establish technical standards would be a legitimate concern, if in fact there were such authority provided in this proposal. What this proposal does do in Section 4 it to require the Secretary to identify one or more ‘standardized frameworks’ for appropriately addressing each of a variety of cybersecurity risks.

Again, this terminology is not defined in the proposal or even particularly well described. What is made painfully clear (to those of us who work with the CFATS regulations) that what ever these ‘frameworks’ are, they are not standards. Section 4(b)(5) clearly states that:

“Frameworks shall not require the use of a particular measure, but shall leave the choice of particular measures to an entity to which the framework applies.”

After watching the regulatory development process that accompanied the publication of the Risk Based Performance Standards for the CFATS program, I can assure anyone that industry will jealously guard against any suggestion that a particular measure is even becoming close to being a requirement in this type of regulatory scheme.

While this gives the maximum amount of flexibility to an entity that has an effective cyber security staff, it also has its downside. For entities that do not have the requisite level of expertise in house, this effectively removes the technical resources of DHS as a source for recommendations on how to adequately secure a cyber asset.

Other Issues Remain

While I don’t agree with Mr. Clinton’s assessment of these two areas of the President’s proposal there are other areas that I am in agreement with his testimony. I will address these in future blog posts.

More President’s Cyber Security Legislation

Okay, I finally got around to reading the President’s proposed language for cyber security legislation. While there is nothing in the proposal that specifically addresses control system security measures, there are enough ambiguities in the proposed language that regulations developed under these provisions could be used to regulate control system security.

No ‘Stuxnet’ Coverage

A couple of security researchers have taken objection to the wording of the change to §1030A of 18 USC that describes what would be included in the offense, ‘Aggravated Damage to a Critical Infrastructure Computer’. They note that the wording of §1030A(a)(1)(A) would limit that offense to actions that resulted in the substantial impairment “of the operation of the critical infrastructure computer”. They note that attacks like Stuxnet do not actually target these computers but the linked control devices. They then reason that a Stuxnet like attack would not fall under the definition of this offense.

Someone with a control systems background would certainly have included a listing of specific control systems devices in this definition. The problem with that approach would be that when a new class of control devices is developed a change in legislation would be required to include that in the definition of ‘Aggravated Damage’.

The crafters of this document took a different approach. In §1030A(a)(1)(B) it includes the impairment “of the critical infrastructure associated with such computer”. This should address the concern about whether or not a Stuxnet type attack would fall under this offense.

Critical Infrastructure Cyber Security Regulations

One area of this proposed legislation that could allow for the regulation of some industrial control systems can be found on page 20 in the addition of Subtitle E to Title II of the Homeland Security Act of 2002. The coverage by this section of control systems rests on a broad definition of ‘critical information infrastructure’ found in §242(5) that includes any “physical or virtual information system that controls, processes, transmits, receives or stores electronic information in any form including data, voice or video” if it is “vital to the functioning of critical infrastructure” {§242(5)(A)}.

An argument could certainly be made that any computer is an ‘information system’ and that ‘electronic information’ is used to control physical processes that are vital to the functioning of critical infrastructure. If I were writing the supporting regulations, I would use this interpretation to establish ICS security regulations. I doubt, however, that DHS will take that approach. They are going to have enough problems dealing with the regulation of information systems without taking on the additional problems involved in control system security regulation.

ICS Regulation

For arguments sake, let’s assume that I am wrong about the DHS interest in regulating control systems in critical infrastructure. With that assumption made what affect might this proposed regulatory language have on industrial control system security?

Information protection: Section 245 provides that any cyber security information voluntarily provided to DHS will be protected against disclosure under the Freedom of Information Act. This is significantly less protection against disclosure provided by other security programs like CFATS (CVI) or MTSA (SSI). The wording would not provide protection from disclosure of any information required to be submitted to DHS by subsequent regulations. Section 246 weakens that protection further by prohibiting prosecution of non-Federal government employees for disclosure of the information voluntarily provided to DHS. There is no provision for protecting sensitive business information. Personal information is provided significant protections.

Response to cyber incident: Section 249 provides the Secretary of DHS with the authority to order a wide range of responding actions, but is provided that authority only with respect to Federal information systems. There is no mention in this section of authority to order private sector entities to do anything.

Covered Critical Infrastructure

Starting on page 32 we see another piece of legislative language, the “Cybersecurity Regulatory Framework for Covered Critical Infrastructure Act”, that could effect industrial control system security. Section 3 of this language would require the DHS Secretary to write regulations to designate ‘covered critical infrastructure’. There are a number of restrictions on this authority constraining what can be designated. The two main ones are that:

● A successful attack could result in “a debilitating impact on national security, national economic security, national public health or safety; and” {§3(b)(1)(A)}

● The designated entity “is dependent upon information infrastructure to operate” {§3(b)(1)(A)}.

For high-risk chemical facilities, the failure to modify the word ‘safety’ by preceding it with ‘national’ may allow an aggressive DHS to include CFATS facilities under any regulations developed under this section. This is not significantly impacted by the second requirement as the term ‘information infrastructure’ is not specifically defined in this ‘act’. This means that the presence of an industrial control system could be argued to be, de facto, part of an information infrastructure.

Again, I doubt that DHS would expansively interpret this rule to cover high-risk chemical facilities, but pipelines and elements of the electrical grid would certainly fall under the descriptions in this section.

Covered Infrastructure Requirements

Section 4 of this ‘act’ would require the Secretary to establish a ‘process’ to determine which cyber security risks would have to be ‘mitigated’. A list of ‘covered’ risks would be published and periodically updated. The Secretary would also be required to ‘consult’ with standards setting organizations and ‘private sector representatives’ to determine an appropriate ‘framework’ to enhance security practices.

Taking a page from the CFATS authorization this legislative language would maintain that such frameworks “shall not require the use of a particular measure, but shall leave the choice of particular measures to an entity to which the framework applies” {§4(b)(5)}. This has worked out so well for CFATS (SARCASM Alert) that we might as well try it on cyber security as well.

Covered critical infrastructure organizations (and it is not clear at what level; corporate, business group, individual facility) will be required to develop a ‘cybersecurity plan’ on one of those ‘applicable frameworks’ I discussed above. The plan would have to be signed by someone of authority in the organization.

Annual certification of the existence of an updated plan would have to be made to the SEC (or DHS if privately held) and a ‘high-level summary’ would have to be publicly disclosed. Detailed ‘security and vulnerability-related information’ would be protected against disclosure under the Freedom of Information Act.

The DHS Secretary is given limited authority to enforce regulations under this ‘act’. Specifically the Secretary shall not “issue a shutdown order, require use of a particular measure, or impose fines, civil penalties, or monetary liabilities on the owner or operator of the covered critical infrastructure” {§8(a)(1)(C)}. With no teeth to this regulation some companies will comply, others won’t, and most will fall somewhere in the middle.

Finally, the Secretary, in consultation with the Director of the OMB, may exempt individual critical infrastructure, in whole or part, from provisions of this ‘act’, if “Secretary determines that a sector-specific regulatory agency has sufficient specific requirements in place to effectively mitigate identified cybersecurity risks.”

Missing from Proposal

There is nothing in this proposal that identifies any kind of vender responsibility for providing secure software, firmware or hardware to critical infrastructure or the government. Neither is there any mention of dealing with reports of vulnerabilities in such ‘ware by independent security researchers. Nor are there any provisions to protect whistleblowers in either the private or public sector from retaliation for reporting cybersecurity problems.

The biggest problem, other than specifically and unequivocally addressing control system security, is the lack of protection provided to security information and protected business information in the system.

Oh well, it is a step forward in the discussion, and there is certainly a level of detail missing from previous recommendations made by the administration. Lots of work will need to be done before this sees the first committee vote, much less gets to the floor of the House or Senate.