This is part of a detailed look at the recently published Discussion Draft of the Preliminary Cybersecurity Framework (PCF). The NIST Information Technology Laboratory (ITL) published this and supporting documentation to their web site during the week of August 28th in order to allow for public comments and preparatory work for the 4th Cybersecurity Framework Workshop in Dallas, TX next week. The other posts in the series are:
In the introduction to the Discussion Draft the crafters asked a series of questions that they want reviewers to answer. The whole point of releasing this Discussion Draft is to provide a basis for the last Workshop to finalize work on the Preliminary Framework. The next document we see from the NIST authors will be the version of the Preliminary Cybersecurity Framework that will be sent to the President. So the answers to these questions posed on page i will almost certainly provide the direction for discussions at the Workshop and the final edit of the ‘preliminary’ document headed to the President.
The question I would like to address in this post is:
Is the Discussion Draft presented at the right level of specificity?
To completely answer this question I would have to look at all of the Subcategories and that would just be too time consuming for this blog. So what I will do is look at a couple of random subcategories to see if the specificity of needs to be adjusted.
Identify legal/regulatory requirements
This is the 3rd subcategory found in the Identify function and the Governance Category. The purpose of the Governance Category is to (pg 15):
Identify the policies, procedures, and processes to manage and monitor the organization's regulatory, legal, risk, environmental, and operational requirements.
The Informative References listed for this Subcategory are:
• ISA 99.02.01 188.8.131.52
• COBIT MEA03.01, MEA03.04
• ISO/IEC 27001 A.15.1.1
• NIST SP 800-53 Rev. 4 -1 controls from all families (except PM-1)
Unfortunately, the first three references all require the references to be purchased; $215 for the ANSI document, $175/book for the COBIT 5 documents, and CHF (Swiss Franks) 134,00 for the ISO/IEC document. Those are not unreasonable prices from a corporate point if view, but well outside my budget as a blogger. So, let’s assume that one or more of them will provide listings of various regulatory programs that might apply to cybersecurity operations across a wide variety of organizations.
The NIST document is free of charge, but it does not provide any specific information about the various legal or regulatory requirements that might apply to high-risk critical infrastructure facilities.
So why doesn’t NIST just provide a listing of such regulatory programs in an appendix to the Cybersecurity Framework? I would bet that the folks at NIST decided to let the ISA and ISO organizations worry about keeping their documents updated for changes in the regulatory landscape; they are going to be doing that work in any case. That way NIST (or DHS, or whomever is going to be maintaining the final version of the Framework) will not have to fund an on-going operation to keep this part of the Framework current.
Characterize Detected Events
This is the second Subcategory of the Anomalies and Events Category of the Detect Function of the Framework Core. Its complete description is (pg 21):
DE.AE-2: Characterize detected events (including through the use of traffic analysis) to understand attack targets and how a detected event is taking place.
This was not quite selected randomly as I was looking for a subcategory with only one Informative Reference listed, and obviously the free one. That reference takes us to SI-4 (Control Number SI-4, Information System Monitoring, on pages F-219 thru F-223 of the NIST SP 800-53. While that discussion is fairly extensive, it focuses on the methods of detecting attacks and indicators of potential attacks; not on characterizing the events detected.
Update Response Strategies
This is the second Subcategory of the Improvement Category of the Respond Function. The title is all of the information provided in the Subcategory (pg 23), but it does provide an Informative Reference to NIST SP 800-53 IR 8; Incident Response Plan (pgs F-106 thru F-107). There is a single comment in that reference that applies to this particular sub-category (IR-8d):
“Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing”.
That is a concise description of the events that would be expected to trigger an incident response plan update. Assuming that the organization was capable of constructing a reasonably successful incident response plan, this statement would probably suffice to outline what is needed to keep it a living document.
Using these three subcategories as a measure of the specificity of the Framework Core begs a very important question; who will be using the Framework Core? If an organization has the in-house (or consultant) expertise necessary to set up a cybersecurity apparat, then the information provided in these three examples should provide enough guidance. If there is not that basic level of cybersecurity expertise available, then NIST would be hard pressed to prepare an encyclopedic document adequate to the task.
It must be remembered here that the Cybersecurity Framework is envisioned to be an aid to focusing management on conducting a risk management evaluation of the cybersecurity status of an organization and making appropriate adjustments based upon their assessment of the risks and cost-benefit analysis of the situation. This is not intended to be a government mandated set of security standards against which the cybersecurity program of an organization is measured.
Whether or not that differentiation of the goals of the Cybersecurity Framework is the appropriate way of addressing cybersecurity for critical infrastructure organizations is a completely separate question.