Cybersecurity Framework Update 07-20-13

It is still too early to see anything concrete from NIST on last week’s 3^rd Cybersecurity Workshop. The NIST Framework website does have some additional information available in the form of two of the slide presentations made at the workshop; the opening slide presentation outlines the Framework development process and the closing presentation outlining the next steps.

Framework Development Process

The opening presentation was used to provide the attendees with an overview of the workshop’s part in the framework development process and outline what they would be doing in their working groups. It describes the five functions (Know, Prevent, Detect, Respond, and Recover) that the framework will be based upon and how those will be broken down into categories and sub-categories. In turn those will be used to develop Framework Implementation Levels (FILs).

It looks like the FILs will be the point where actions will be taken and/or evaluated. There will be separate FILs for each role (for example Senior Executive, Business Process Manager and Operations Manager) and each function, category and sub-category. It looks like, even if these are written at a high-level of generality (as I expect they will to allow for the broadest application), this document will get really wordy.

Hierarchy of FILs

There is an interesting hierarchy to the level of complexity to these FILs. The presentation provides an example on slides 19 thru 21.

Under ‘KNOW’ there are a number of FILs for the Senior Executive. The first is “I understand the organizational components that need to be protected. I have provided resources to support corporate knowledge of risk management components such as vulnerabilities, threats, and risk assessment.”

Supporting that at the Business Process Manager Level are a number of categories with their own FILs. One category is ‘Asset Management’ with the first FIL being: “I understand the importance of asset management and assume responsibility for lifecycle accountability.”

Supporting that at the Operations Manager Level are a number of sub-categories for each category. For example, supporting the ‘Asset Management’ FIL is ‘Hardware/Software Inventory’. At this level there is an ‘Informative Reference’ listing (ISO/IEC 27001) with a FIL for “An ad hoc asset tracking process is in place”.

As would be expected there is more detail at the operational level, but (if the detail provided in this example is carried through in the actual Framework) the FILs at that level are still going to be written broadly enough so that they will be broadly applicable throughout critical infrastructure.

Of course, the more broadly written the FILs are the easier it will be for individual organizations to take window dressing actions to be able to say that they comply with the Framework.

Where We Are

The out-briefing presentation started out with a ‘What We Heard’ slide that provides a high-level view of some of the concerns that were expressed during the Workshop. Most of these are expressed on the ‘motherhood and apple’ pie level, but there is at least one fundamental disagreement underlined in the listing. Here is the list:

• The Framework must support the business

• The Framework must enable cost-effective implementation

• The Framework language and communication is critical to success

• The Framework must reflect characteristics of people, processes, and technologies

• The Framework must be inclusive of and not disruptive to those good practices in use today

• The Framework must include the fundamentals

• Determination of risk tolerance for critical infrastructure must be informed by national interests

• Threat information must inform Framework implementation

The first, second and seventh topics define the problem. Business will not spend more money on security measures than they think they can afford and that determination will be made on internal risk-benefit analysis. The whole point of the government getting involved is that there are potential national and societal costs associated with failures of cybersecurity at critical infrastructure. Since the owning organization will not pay these costs, they will not inform the risk-benefit analysis used to determine the appropriate level of cybersecurity spending. Without some mechanism for requiring organizations to internalize the outside costs of failure there is no way to ensure that an ‘adequate level’ of cybersecurity is sought, much less obtained by a realistic risk-benefit analysis.

Areas to Address

The second slide in the out-brief details area that yet need to be addressed in the Framework development process. Again, here is the list from the slide:

• Find the right level of specificity

• Threat informed

• Taxonomy for the Framework

• Identify cross-cutting categories

• Clarify the compendium of Informative References

• Integration of cyber risk into business risk

• Address IT and ICS considerations

• Framework Implementation

• Long term governance

Given my long time misgivings about the whether or not the Framework would explicitly address industrial control system issues and comments I’ve seen on Twitter during and after the 3^rd Workshop last week, I am very happy to see the seventh bullet point; “Address IT and ICS consideration”. Still, with October quickly approaching it is disheartening to see this topic just now appearing in the considerations.

Moving Forward

The third slide in the out-briefing is title ‘Topic-Specific Working Sessions’. I think these are the proposed working sessions for the 4^th Workshop to be held in Dallas, TX in September. Those working sessions would be:

• Engage senior executives and boards through effective communication of the value proposition of Framework adoption

• Provide guidance and resources to aid small business implementations Understand unique privacy and civil liberties needs for Critical Infrastructures

• Define awareness and training needs in context of Critical Infrastructure

• Increase international engagements

• Connect the Framework and the Performance Goals

If these are the working sessions for the 4^th Workshop, then I’m again disappointed about the lack of specific attention to control systems. I understand the political importance of ‘privacy and civil liberties’, but the failure to address ICS issues will ensure that the most dangerous portions of the cyber-vulnerabilities will not be addressed by the Framework.

The final two slides in the out-brief outline what NIST will be doing leading up to the 4^th Workshop to be held on September 11^th – 13^th (I like the unintended symbolism there) in Dallas. NIST needs to take the conflicting input received from the 3^rd Workshop and use it to more fully populate the draft Framework. They plan to publish their draft of the Preliminary Framework sometime next month, probably towards the end of the month if past history is any guide.

NIST continues to solicit input on the Framework development and provide this email address (cyberframework@nist.gov) for communicating such information.

BTW: Since I now live just down the road a piece from Dallas, I am trying to get some sort of press credentials to allow me to observe at least part of the proceedings. If anyone can put in a good word for me with NIST I would appreciate it.