It is still too early to see anything concrete from NIST on
last week’s 3rd 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 3rd 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 4th
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 4th
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 4th Workshop to be held on September 11th
– 13th (I like the unintended symbolism there) in Dallas. NIST needs
to take the conflicting input received from the 3rd 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.
No comments:
Post a Comment