Responses to NIST RFI – 04-20-13

This is the final post looking at the responses that the National Institute of Standards and Technology (NIST) has received in response to its request for information (RFI) in support of the development of the Framework for Reducing Cyber Risks to Critical Infrastructure as outlined in President Obama’s Executive Order on critical infrastructure cybersecurity (EO 13636). The earlier posts in the series are:

Responses to NIST RFI – 03-30-13

Responses to NIST RFI – 04-06-13

Responses to NIST RFI – 04-13-13

There were only five new responses added in the last week and it seems clear that NIST is no longer adding to the list; it was last updated on the 16^th. There is no new information concerning control system security or chemical-specific cybersecurity in the new posts.

Responses to NIST RFI – 04-06-13

This is part of a continuing look at the responses that the National Institute of Standards and Technology (NIST) has received in response to its request for information (RFI) in support of the development of the Framework for Reducing Cyber Risks to Critical Infrastructure as outlined in President Obama’s Executive Order on critical infrastructure cybersecurity (EO 13636). The earlier posts in the series are:

Responses to NIST RFI – 03-30-13

Responses to NIST RFI – 04-06-13

The period for comments ended on April 8^th but the NIST web site shows that they continued to accept/publish comment through at least Friday. I will check back again next week to see if they accept any more comments after the end of the very short comment period.

In the week since I last reported on comments on the RFI 190 comments were posted to the NIST web site. I will not have time to review and comment on all of them; that is the prerogative of a gadfly. The NIST staff will have to review each and every one; this is one of the things that will make it difficult for them to publish their draft Cybersecurity Framework in the time frame required by the President’s EO.

Control System Manufacturers

Comments were received from four major control system manufacturers (in order of posting on the site):

• Siemens;

• Honeywell;

• ABB; and

• Rockwell

The first three formatted their responses as specific and fairly detailed responses to the questions posed by NIST in their RFI. The Honeywell responses were more focused on their internal cybersecurity responses, though there are some interesting discussions specific to aircraft control systems. Rockwell was certainly the odd-man-out in these vendor responses in that they provided what looked like commercial flyer on cybersecurity; strong on generalities and completely lacking in responsiveness to the questions posed by NIST. The Siemens response most directly addressed the development of the NIST Cybersecurity Framework.

Both Siemens and ABB stress that vendors cannot not solve the cybersecurity problem alone. They both make it clear that any NIST Framework must “set a focus on cyber security awareness, training and developing sustainable cyber security programs within all organizations” (ABB, pg 12). Siemens does, however, offer to be part of a future discussion of about “vulnerabilities that all vendors believe should be absent from new industrial control system products introduced from this point forward” (Siemens, pg 2).

Industry Comments

There are plenty of comments from the electric power, gas transmission and water treatment industries. Clearly these industries will be impacted by the voluntary Cybersecurity Framework and would most likely have their current regulatory regimes updated to include some level of mandatory implementation.

As a commenter on chemical security matters, I am more than a little disturbed that the chemical industry is woefully under-represented in these comments. There is nothing from any of the large chemical companies who are clearly leaders in ICS security. In fact the only chemical facility comments come from two of the large industry organizations:

• American Petroleum Institute

• American Chemistry Council

The ACC document is a large-scale response, short on any detailed information beyond the identification of the CFATS program as the main regulatory scheme that effects the chemical industry. They do point out that the CFATS covered facilities are not necessarily critical infrastructure under the definition of the EO. I will add that this is particularly true for those facilities (the vast majority) that are covered simply because of the presence of theft/diversion chemicals of interest.

The API, on the other hand provides specific answers to the questions posed by the RFI. And the API document is not afraid to point fingers. For example, in response to the question about ‘greatest challenges in improving cybersecurity practices, the first response is:

“Suppliers do not provide "Secure by Design" products. This is particularly true in process control environments where vendors have not certified their systems for various cybersecurity tools that would greatly improve our security posture.” (pg 2)

I think that the API documents may overstate the state of cybersecurity activity in current practice. While the major oil companies almost certainly have vigorous security programs I don’t think that comments like the one below apply to all of the companies in the oil industry.

“Cybersecurity is integrated into corporate risk management processes and business units must report deficiencies and provide mitigation plans to senior management. Senior management is also apprised of key risks and remediation efforts periodically.” (pg 3)

The API comments make an important point about physical security being an important part of cybersecurity:

“Many cybersecurity measures can be compromised if basic physical security measures are not in place; for example, access control to software and hardware, and employee and contractor background investigations are essential to comprehensive security programs.” (pg 6)

The oil industry, like most of the US manufacturing organizations, is a trans-global industry, with most companies operating across a number of international boundaries. The API comments consistently reflect this, but the most important international comment is made at the bottom of page 13:

“The Framework needs to be flexible enough to be implementable worldwide, if so desired. Corporate networks extend around the world and companies cannot have one security model in one part and another elsewhere. Operations are extended across the entire network so creating ‘stronger' protections around one country alone (e.g., the U.S.) is not going to provide adequate protection. If we cannot use a consistent set of tools and practices globally, we will be hindered or impeded from efficiently securing our corporation.”

Moving Forward

As I mentioned earlier, I will be looking back at the RFI Response web site next weekend to see if any additional comments have been posted. I suspect that there will be. As time permits I will also go back and look at some the comments that I have skipped due to the lack of time, particularly looking for comments that specifically pertain to control system security issues.

NIST has the hard task, going back and reviewing all of the comments and distilling the useful bits from each and then trying to weave them into the research that the organization has almost certainly already started upon.

There are going to be more public meetings, but I suspect that they will be less about receiving general comments or recommendations about what should go into the Framework and more about responses to ideas that NIST plans on including in the Framework.

NIST is obviously working hard at their EO assignment, but the October 17^th deadline for having a preliminary version of the Framework published is fast approaching with only five months remaining. Pulling this all together in that time frame will be a major accomplishment.

Responses to NIST RFI – 04-06-13

This is part of a continuing look at the responses that the National Institute of Standards and Technology (NIST) has received in response to its request for information (RFI) in support of the development of the Framework for Reducing Cyber Risks to Critical Infrastructure as outlined in President Obama’s Executive Order on critical infrastructure cybersecurity (EO 13636). The earlier post in the series is:

Responses to NIST RFI – 03-30-13

Topics Discussed

This last week there were 19 new comments left on the NIST web site (though 6 of those were essentially transmission documents not actual comments). Six of those took the form of short answers to the list of actual questions in the RFI (One, two, three, four, five, and six). Others covered a particular topic about cybersecurity in some depth. Those topics included:

• DOE data exchange mechanism;

• Situational awareness approach to cybersecurity;

• 1997 study on critical infrastructure protection;

• Cyclic redundancy checks;

• The use of encryption;

• Software engineering practices; and

• Continuous monitoring of networks.

Interesting Comments

There is a lot of good information provided in the documents listed above, but there were a couple of comments that jumped out of the pages at me. The first comes from Larry Marks at IBM Security and Privacy Services and deals with the idea of requiring certification for people that have a level of access to a system that allows them to make some changes to the actual system:

“The ISC2 CISSP Common Body of Knowledge (CBK) has been carefully mapped to the DoD 8570.1 [link added] directive, which requires every full-and part-time military service member, defense contractor, civilian and foreign employee with privileged access to a DoD system, regardless of job series or occupational specialty, to obtain a commercial certification credential [link added] that has been accredited by the American National Standards Institute (ANSI).”

The second comes from Doug Stoneman at Velocity Partners and is a look at the scope and basis of the current problem:

“In a landscape of breached security and defeated encryption the typical reactive technological security infrastructure response is that more technology is the answer to threats and that one more layer of security technology will solve the security issue. It is that very nature of the reactive security industry and the focus on technology that is the scale and scope of the problem.”

Control System Security

Only two of the comments posted this week specifically deal with control system security issues. The first was from Mike Swearingen at Tri-County Electric Cooperative. His was the piece that looked at situational awareness that I listed above.

Last week I complained about the missing input from well-known names in the ICS security world. The second ICS related comment comes from one of those names, Chris Blask, Chair of the Industrial Control System Information Sharing and Analysis Center (ICS-ISAC). As one would expect from Chris this is a thoughtful and cogent response to the RFI. Interestingly it provides more of a theoretical background to the comments made by Swearingen.

The entirety of Chris’ response is well worth reading, but perhaps his most important point is made in his opening remarks about the complexity of the ICS security problem and the limits of vulnerability reduction:

“Given realistic resources, vulnerability reduction alone cannot reduce aggregate risk to an acceptable level at any point in the foreseeable future

o “Based on the vulnerability research to date which is available in the public domain it is reasonable to assume that virtually every deployed Industrial Control System device or piece of software contains exploitable vulnerabilities

o “The trained workforce of researchers necessary to identify a majority of vulnerabilities in all deployed ICS cyber devices in a reasonable and prudent period of time for these purposes does not exist

o “The necessity to “touch” every individual control system device found throughout every critical infrastructure facility in the nation in order to apply remediation to known vulnerabilities would mandate a workforce which is not available nor will be available under the most optimistic conditions for many years

o “It is unrealistic to assume that a single remediation of each ICS cyber device would be adequate to ensure all knowable vulnerabilities have been addressed in all deployed devices”

There have been public discussions around this topic for some time now, but this is the first time I have seen such a cogent and succinct expression of the totality of the problem. Fortunately, Chris goes on to give an overview of how the use of situational awareness and information sharing can be used to overcome this problem.

In a mere 9 pages, Chris isn’t able to provide a clear blueprint for the implementation of this solution and its scope is certainly beyond the reach of a single person or organization. Having said that, I hope that the folks at NIST responsible for developing the Cybersecurity Framework pay close attention to Chris’ remarks when the begin to look at the control system aspects of their program.

Responses to NIST RFI – 03-30-13

We are finally starting to see some of the responses that NIST has received from their request for information for the cybersecurity framework that they are developing to support the President’s cybersecurity Executive Order. There are as of today 19 responses on the NIST RFI Response web page. Upon quick review they run a wide gamut of ideas, from very technical presentations on technical security issues to almost political manifestos. And it looks like there is currently about a 10-day delay in getting responses posted to this new web page.

Political Manifesto

One of the most radical proposals comes from Jean C (NIST is not providing contact information with these postings unless it is specifically listed in the document submitted). It begins with the statement “Block all international internet access” and goes downhill from there. I will grant that the suggestions in this document will probably limit the number of successful cyber-attacks (limit not eliminate – Stuxnet attacked isolated systems), but it would also completely isolate important sectors of the US economy from the beneficial aspects of information sharing.

Even with all of the political paranoia inherent in this proposal there are some worthwhile suggestions, though none of them are new. Testing of updates before implementing them on control systems and having appropriately trained cybersecurity personnel are hardly new ideas.

Another political approach to cybersecurity takes a little more technical approach. Piltz suggests that all IP addresses be protected by VPNs. The proposal then drops back down into political controls; fining personnel via payroll deductions for violations of protocols and ‘timewasting’ online and the blocking all internet connections after work hours round out the political approach.

Technical Proposals

There are a number of technical proposals that I am hardly in position to evaluate, but that’s what NIST is for. They range from interface standards, to NASH hardware encryption (impressive diagram), to software security evaluations. There is a broad suggestion as to what the framework should include and a link to a foreign cybersecurity national standard.

Information sharing is an important part of a number of the proposals. The development of a standard format for disseminating attack information and an international experiment on the development of an information sharing protocol are some of the ideas discussed.

There is an interesting discussion of the Cyber Security Evaluation Tool (CSET) developed by ICS-CERT. While much of the discussion describes improvements that could be made to CSET, it is an interesting proposal for using this type of tool for evaluating the cybersecurity of systems.

One of the most comprehensive documents provided to date comes from a well-known source, IBM Security Systems. It is an interesting bullet-point style list of things that might be included in the NIST framework. Many of the items deserve more detailed discussion (particularly the various metrics suggested) while others are more of the ‘apple pie and motherhood’ variety (Identify your key / most critical business processes.). As to be expected from IBM this is an IT-centric proposal.

What’s Missing

While it is still early in the RFI process (typically most comments come in the closing days of the comment period) it is disappointing to not see comments from people in the control system security community. To my mind most of the serious work in protecting critical infrastructure from catastrophic events must be focused on control systems. I would really like to think that some of the well-known figures in this community are planning on putting in their two-cents worth.