Cybersecurity Framework – Update 07-27-13

This week the National Institute of Standards published a link to a new update document on its Cybersecurity Framework page. The document provides an overview of the results of the 3^rd Cybersecurity Framework Workshop and briefly explains some changes that are being made in the Framework document based upon feedback received at that workshop.

As one would expect at this point in the process there are no earth shattering changes being made. For example they are changing the names of the proposed functions that will act as the backbone of the document, but not what those functions represent. I’ve listed the old and new function names below.

OLD: Know, Prevent, Detect, Respond, and Recover

NEW: Identify, Protect, Detect, Respond, and Recover

Small Business Concerns

There are a couple of points in this update document that reference small businesses concerns. In some ways this is surprising because it did not seem to me that the definition of ‘critical infrastructure’ in §2 of the Cybersecurity Executive Order (EO 13636) would apply to many (if any) small businesses. So, either NIST’s interpretation of that definition is much wider than most commentators have accepted, or NIST is truly trying to make this a framework that can be adopted by a much wider range of organizations than the President envisioned.

If it is the former, I think that we need a wider and more vocal discussion of the types of organizations that will fall under the coverage of the EO. Since making that determination is actually a DHS tasking {at least as far as identifying the specific organizations that are Critical Infrastructure at Greatest Risk, §9(a)} it would be helpful if DHS were to publicly explain the process by which they have selected organizations to be on the list of “critical infrastructure where a cybersecurity incident could reasonably result in catastrophic regional or national effects on public health or safety, economic security, or national security”.

If the small business concerns in the update document are instead based upon producing a Framework document with the widest possible voluntary application, I applaud NIST’s vision. I do, however, have to question whether this expansion of purpose (however laudable) will interfere with the core mission of developing a cybersecurity framework for critical infrastructure.

International Engagement

Another area addressed in the update document that is of potential concern is the emphasis on the international context of the Framework. It is clear to anyone with a modicum of sense that modern businesses of a certain size almost always operate in an international arena. And it is certainly hard to argue that separating the computer systems between the international and domestic operations of such businesses is a practical way for most organizations to operate.

But, if the Framework is not to be prescriptive or establish new standards, but is simply a method by which businesses can organize and evaluate their cybersecurity practices, then it is hard to see why cyber-systems would have to be separated at the international border. I don’t see anything in the way this is supposedly being laid out that would require any consultation or coordination with any international body.

I am not saying that the US is the font of all knowledge cybersecurity. There are certainly good sources of information about best practices and international standards (which multi-national businesses will have to include in their cybersecurity programs) outside of our borders. International standards certainly need to be included in the compendium of information sources about cybersecurity.

I do, however, have some concerns when NIST says that they need more vigorous international outreach to “ensure greater awareness of and standards harmonization [emphasis added] with the Cybersecurity Framework” (pg 2). This is supposed to be a national critical infrastructure cybersecurity framework, not one that addresses protecting French, Nigerian or Chinese cyber infrastructure.

Now if the intent is to actually make this Framework a new cybersecurity compliance standard to which even a limited number of Critical Infrastructure at Greatest Risk organizations must comply, then yes, we need to ensure that the organizations that are required to comply with the standard must still be able to operate in an international environment. But, if that is the case, NIST and the Administration needs to make that perfectly clear so that the appropriate discussions can take place during the development. And, the current timeline needs to be immediately scrapped.

Public Involvement

As I have mentioned on a number of occasions, NIST is doing an outstanding job of pulling a wide number and variety of folks into the development of the Framework. Pulling in hundreds of self-anointed experts into these workshops and guiding them through productive discussions has got to be harder than herding a cloned army of Schrodinger’s cats.

As we’ve come to expect from NIST’s Information Technology Laboratory (the NIST action agency here) the closing section of the update document is titled “Stay Engaged” and encourages concerned folks that cannot attend the next Cybersecurity Framework Workshop (this time in Dallas, TX, September 11^th – 13^th) to provide feedback, comments and suggestions to email them to cyberframework@nist.gov.

I understand NIST’s intent here and even applaud it, but there is an underlying problem that needs to be addressed with these email communications. This Cybersecurity Framework is for all intents and purposes a regulatory process. The Administration can declaim its voluntary nature as much as it wants, but as soon as it starts providing incentives for participation in the framework it becomes a de facto regulation that organizations must adhere to to receive those incentives.

This means that NIST must ensure that the public record of the discussions that are taking place during the development of the Framework is complete. This includes the emails sent to the cyberframework address.

Input Data Analysis  

Having complained about a minor incompletion of the record in the preceding section of this post I have to now complain about the embarrassing wealth of data that is currently available in the public record on this project. We now have three multi-day workshops of public discussions about various aspects of the development of the Framework and the fourth workshop is fast approaching. Most of the discussions were webcast to an unknowably large audience and have been archived for the record.

Unfortunately, the complexity of the record ensures that any number of good ideas may have been overlooked. The breakout organization of the workshops has compounded the problem. A suggestion that might have met with a lukewarm reception in one group may have had profound implications in another if it had only been introduced there. A few years ago this would have been a problem relegated to historical discussions as only historians would have the time and inclination to delve into the records in that depth.

NIST, in their meta analysis of the public comments on the original cybersecurity framework request for information, showed us that modern computer technology provides a much better way of pulling bits of information out of large volumes of public data. I would like to suggest that it would be appropriate for NIST to attempt the same sort of analysis of the suggestions made during these workshops and the subsequent email suggestions received on the same topics.

I understand that encoding verbal ideas is more than slightly more complicated than entering written records, but the OTHER government agency with responsibility for cybersecurity apparently has extensive experience and technology capable of cataloging verbal records. Marrying the two efforts in this way would be a profoundly useful example of the application of heretofore classified techniques.

Even if the not so secret agency were to share a not quite up-to-date version of their analysis system with NIST I still think that it would make a valuable contribution to science of public data analysis. It would also make workshops like this a more valuable technique for developing technically challenging rules and regulations.