Showing posts with label Preliminary Cybersecurity Framework. Show all posts
Showing posts with label Preliminary Cybersecurity Framework. Show all posts

Saturday, December 21, 2013

Cybersecurity Framework Comments – 12-21-13

This is the fifth (and perhaps the last) in a series of posts about public comments submitted in response to the publication of the NIST Preliminary Cybersecurity Framework (PCSF). The earlier posts are listed below.



There were 114 new comments posted to the PCSF comment web site this week, more than double the number from the week before. Actually the number of comments per week has more than doubled every week since NIST started posting the comments. With the number of comments submitted this week, I’m going to have to cut back my comments to those that reflect control system issues.

One thing that we are seeing this week is the ‘corporate comment’ that was obviously written by lawyers. These are old-style format comments (not the NIST requested spread sheet) that speaks in generalities that are of little or no use to anyone trying to clean up or improve the Framework. I’m counting these under the ‘Motherhood’ label.

Repeat of (7x) add three steps to the ‘Getting Started’ discussion; 1) Determine scope of critical infrastructure to protect, 2) Conduct self-assessment of current cybersecurity status, 3) Ensure continuous improvement.
• Motherhood and apple pie comments (37x). Most of these include objections to the Privacy Appendix.
Restrict Framework (4x) to the systems and assets essential to critical infrastructure functions.
Move the Tiers concept to CSF 2.0 after more work.
Address the role of Sector Specific Agencies.
Add additional function; Authenticate.
Address identity management.
Address security design of communications networks.
Add more substance to industrial control system issues
Add ‘Smart Grid’ to control system list.
Add ISO/IEC 27002 as an Informative Reference.
Add an Access Control category to Protect function.
Add a listing of ISACs, CERTs, public private partnerships, NIST special publications, and other resources for recovery.
Add subcategory to governance category to address vendor cybersecurity issues.
Add , ISO/IEC 19770-2 as an Informative Reference.
Add ANSI/AWWA 430: Security Practices for Operations and Management as an Informative Reference for water systems.
Add NIST Special Publication 800.53 Rev4, Security and Privacy Controls for Federal Information Systems and Organizations, Security Control 44 as an Informative Reference.
Add critical infrastructure criticality measurement methodology.
Add priority rankings to Core table for each subcategory.
Address updates, patches and antivirus use in control systems.
Needs to more completely address the current cybersecurity gaps identified in the various workshops.
Include reference to use of Protectced Critical Infrastructure Information (PCII) protocol for sharing information with government agencies.
Expand use of threat assessment.
Include more complete definition of ‘critical infrastructure’ to make it less ambiguous.

Insurance Issues

There is an interesting letter from Lloyds about cyber risk insurance. It is well worth reading in its entirety as there has been a lot of discussion about insuring cyber risk, but they make one, clear and definitive statement that throws that whole discussion into disarray:

“It is clear that the insurance industry’s current capacity to provide insurance coverage for cyber risk is insufficient to meet the anticipated size of the risk.”

Essential Problem with CSF

Jack Whittsitt has a very detailed letter about the current state of cybersecurity, the ineffectiveness of current ‘Best Practices’ and the short comings of the CSF. I urge anyone concerned with cybersecurity to read Jack’s letter submitted to NIST.

Guidance to Legislators

There is a very interesting comment provided by Southern California Edison about state legislatures getting involved in the cybersecurity process. They note:

“If state legislatures and regulators begin independently addressing cybersecurity concerns inconsistent approaches, the lack of cohesion could actually reduce our overall defenses.”

The same could, of course, be said for the Congress, but the Executive Branch has a notoriously hard time controlling them. The proposed solution calls for providing “guidance to state legislatures and regulators regarding how to view the framework and their role with respect to the Framework.” I would love to see how that works out (tiny bit of sarcasm).

Insider Issues

A number of commenters have at least partially addressed the relative lack of coverage of insider attacks in this CSF. One of the broadest statements on this is worthy of a blog post all of its own. It comes from Absio:

“Environmental controls are essential but alone they cannot mitigate the insider problem—and data loss is essentially always an insider problem. Whether attackers get inside via a perimeter breach (hacking or phishing, social engineering) or by invitation (Manning, Snowden), it is from the inside that they do their damage.”

The Big Problem with PCSF

One of the best short-form commentaries on the shortcomings of the PCSF that I have seen comes from the comments submitted by the Department of Defense:

“This framework may be written at too high a level to be executable at the company level. NIST SP 800-37, the Risk Management Framework, is written at a level that can be executed by industry individuals not well-versed in risk management principals.”

Process Commentary

A large proportion of the commenters, and certainly the vast majority of those with specific change suggestions, used the spreadsheet format suggested by NIST in their RFI. With the large number of comments (and some were quite lengthy running to 30+ pages on occasion) this format will make it much easier for NIST to process and review the suggestions. Again, NIST is leading the way among government agencies in innovating the way that it interacts with the public and processes the ideas submitted to it.

The last comment posted to the comment page was placed their on December 20th, a full week after the close of the comment period. It is not clear if that delay was due to it being a late submission or whether NIST handling issues delayed the posting. We’ll have a better understanding of that as we see if additional comments are posted in the coming weeks.

I am still surprised that there hasn’t been more of an outcry about the short time frame that NIST provided for the comment process. On a program of this significance I would normally expect at least a 90-day comment period, not one of 45 days. This is especially true since the comment period included Thanksgiving and December is frequently a time of reduced staffing throughout industry and government.

I understand that NIST has a February deadline to get the CSF published. Even with their better information processing ability they are going to be hard pressed to get all of these comments processed, appropriate editing done and get the document approved through the political and administrative review process in time to meet their deadline. Still, shortened comment period is going to have a political downside as the government tries to get critical infrastructure organizations to voluntarily adopt this Framework.

Saturday, December 14, 2013

Cybersecurity Framework Comments – 12-14-13

This is the fourth in a series of posts about public comments submitted in response to the publication of the NIST Preliminary Cybersecurity Framework (PCSF). The earlier posts are listed below.


There were 51 new comments posted to the PCSF comment web site this week, more than double the number from the week before. This is still a relatively poor showing for a program that will have as wide spread an impact on such a wide range of industries. Since we haven’t yet seen comments posted from the major industrial organizations (American Chemistry Council for instance) that always comment I suspect that the last minute comments have yet to be posted to the site.

Again, please note that the summaries posted below are very broad summaries and the actual comments will provide much more detail.

The most recent set of proposed changes includes:

Repeat of (8x) add three steps to the ‘Getting Started’ discussion; 1) Determine scope of critical infrastructure to protect, 2) Conduct self-assessment of current cybersecurity status, 3) Ensure continuous improvement.
Expand concepts to include operational measures that have impacts on security.
Expand citations of ISA 99.02.01 to include a parenthetical citation to the corresponding section or sections of IEC 62443 Part 2-1.
Adopt current security planning terminology of “Identify Assets, Identify Risks, Create Policies, Implement, Monitor, Recover from an incident”.
Differentiate between security standards for legacy devices and new installations.
Include more requirements for the use of encryption for communications and data protection.
Include discussion of security engineering.
Comment that the lack of specific guidelines may make it difficult for small organizations to implement.
Include ‘External Participation’ category to identify outreach efforts to be used by small organizations to aid in implementation of Framework.
Address cost-benefit analysis as part of the risk assessment process.
Identify how threat information will be shared.
Include SC-44 (from App F, NIST Special Publication 800.53) as an informative reference.
Add additional references including: ITU-T X.1528 - Common Platform Enumeration; ITU-T X.1520 - Common Vulnerabilities and Exposures; ITU-T X.1544 - Common Attack Pattern Enumeration and Classification; ITU-T X.1521 - Common Vulnerability Scoring System; and ITU-T X.1526 - Open Vulnerability and Assessment Language.
Change references to Tier 1 to an unacceptable current state that needs to be improved upon, not an acceptable state.
Add additional references including: Open Systems Interconnection (OSI) model; and ISO/IEC 7498-1.
Include references to existing training certification programs.
Include a voluntary self-assessment tool for determining current Tier status.
Include discussion of the impact of HIPAA and HITECH regulations will impact Framework adoption in healthcare industry.
Add additional references including: ANSI X9.8, X9.112 (D), X9.122 (D), X9.119, X9.117, X9.73, X9.31, and X9.62; and ISO 9564 and 16609.
Include discussion of security layers.
Add ‘Cyber Intelligence’ as a new category under Identify.
Add an appendix that provides guidance on Framework implementation.
Remove privacy appendix from current Framework.
Include definition of ‘Framework Adoption’.
Comment that too many of the categories are so expansive in their scope as to be unattainable.
Limit privacy protection requirements to information assurance activities.
More completely address privacy protection training requirements.
Include closer ties between framework and the National Initiative for Cybersecurity Education (NICE).
Detailed discussion of control system issues.
Does not include a discussion of the role of insurance is risk assessment.
Needs to address cybersecurity workforce issues including training and certification.
Expand characterizations of potential losses in an ICS environment.
Update references to ISA-62443-2-1.
Should include stronger reference to use of Framework by regulatory agencies.
Address more of the HISP Top 20 Mitigating Controls.
Increased need for information sharing.
Needs more emphasis on ‘security by design’ and ‘privacy by design’.
Needs more emphasis on cryptography and digital certificates.
Add subcategories for: "Policies to secure and protect cryptographic keys and digital certificates are established and enforced"; "Cryptographic keys and digital certificates are monitored to detect vulnerabilities and exploits"; and "Trust compromise response plan is established and implemented".
Needs more emphasis on information sharing and taxonomy.
Update Tier model and methodology.
Add discussion of insider threat prevention and response.
Detailed discussion of operational aspects of cyber intelligence.
Detailed discussion of insider threat programs.


There are obviously other submissions that have been made that are not currently posted to the NISC comment site. That means that there will be at least one more of these blog posts in this series.

Saturday, December 7, 2013

Cybersecurity Framework Comments – 12-07-13

This is the third in a series of posts about public comments submitted in response to the publication of the NIST Preliminary Cybersecurity Framework (PCSF). The earlier posts are listed below.



This last week there have been 21 new comments posted to the NIST PCSF Comment web site. The latest comments have done a much better job of using the spread sheet format for comment submission that was requested by NIST.

Interestingly there seems to be a somewhat organized effort to support certain suggested changes with a number of commenters using identical language  supporting certain changes. Where I have seen this I have annotated the description of the change with the number of people that have made the suggestion (eg: ‘8x’).

Please note that my descriptions of the suggested changes are very brief and really don’t fully explain the concepts involved. Please use the provided links to see the details about the changes.

The current set of proposed changes include:

Repeat of (8x) add three steps to the ‘Getting Started’ discussion; 1) Determine scope of critical infrastructure to protect, 2) Conduct self-assessment of current cybersecurity status, 3) Ensure continuous improvement.
Move ‘Tiers and Profiles’ to CSF 2.0 as it needs more explanation and justification.
Items missing: data integrity, cryptography, and cloud services.
Include cross mapping (5x) of security standards; suggests using CSA CCM.
Include references to the Open Group Dependency Modeling (O-DM) standard, Open Group Risk Analysis (O-RA) standard and Open Group Risk Taxonomy (O-RT) standard.
Address CSF certification, incentives to adopt CSF and collaboration/information sharing.
Adopt HITRUST CSF categories, authoritative sources, maturity model, controls and control elements.
Require 2-factor authentication for any external access to critical systems.
Specify that the scope address the delivery of ‘critical infrastructure services’.
Expand the use of framework profiles to use as a tool to convey CSF requirements to supply chain partners.
Suggests that the CSF is not specific enough in its requirements, allowing too much leeway in the implementation.
Consider (3x) using SANS Quick Wins approach for breach analysis.
Expand the definition of privacy data to be protected.
Limit the definition of privacy protections.
Replace implementation tiers with CERT Resiliency Management Model (CERT-RMM)
Add NIST NICE Cybersecurity Workforce Framework as a reference
Revise categories and sub-categories to make each distinct and sufficient to describe a specific cybersecurity activity.
Remove the concept of Tiers and replace with a single description of the characteristics of a robust cybersecurity program


The comment period closes next Friday. Given the way these submissions are posted I expect that I will have two more posts about the submitted comments.

Monday, December 2, 2013

Cybersecurity Framework Comments – 11-30-13

This is the second in a series of posts about public comments submitted in response to the publication of the NIST Preliminary Cybersecurity Framework (PCSF). The earlier post is listed below.


This last week there have been 10 new comments posted to the NIST PCSF Comment web site. Actually, they were all posted to the site on November 25th, so it is very likely that additional comments have been submitted since then. This brings the total to a very disappointing 16 comments so far.

The comments form a very interesting spread of viewpoints. We have one comment from a hospital maintenance chief who wants to see violations of the CSF to be prosecuted as criminal violations (very unlikely to say the least). And we have a ‘good job’ comment from a college CISO. In between the two we have a number of interesting suggestions, including:

Adding a sub-category requiring continuous monitoring of configuration baselines;
Adding a sub-category requiring mitigation of identified vulnerabilities in security controls;
Align the language in the PCSF with that used in the National Preparedness Goal (NPG) and System;
Suggest the use of outcome-focused performance goals;
Incorporate the use of data governance, risk management and compliance in the system design phase;
Consider the use of compliance automation tools;  
Consider the security implications of ‘data-in-use’;
Redefine ‘Framework Profile’ as the desired outcomes and ‘Framework Core’ as a list of key activities and re-order the two based upon those definitions;
Include a discussion of the effects of uncertainty and complexity on cybersecurity; and
Add three steps to the ‘Getting Started’ discussion; 1) Determine scope of critical infrastructure to protect, 2) Conduct self-assessment of current cybersecurity status, 3) Ensure continuous improvement.

We are beginning to see more use of the NIST spreadsheet format for the submission of comments, but it is hardly universal. Part of the problem is that some suggestions for changes or improvements are not able to be directly tied to a specific page or line in the PCSF.


Saturday, November 23, 2013

Cybersecurity Framework Update – 11-23-13

This week the folks at NIST’s Information Technology Laboratory (ITL) got around to posting some of the comments that they have received on the Preliminary Cybersecurity Framework (PCSF); at least I am hoping that the six comments are only ‘some’ of the ones received. There is nothing earth shattering in any of the comments posted to date, but there are some thoughtful and helpful suggestions.

The most ‘radical’ comment comes from Secuilibrium. David Ochel suggests that the current PCSF be scrapped in favor of the proposal from Phil Agcaoil described in Anthony Freed’s article at TripWire.com. Apparently David had some other comments in the NIST spread sheet format, but they did not make it to this comments section.

John Guzman had an interesting point in his comments. He asked why PII gets its own appendix when no other type of data protection does. I would add that control system security deserves as much special attention in the PCSF as does privacy.

Interestingly only three of the commentors (if we count the missing data from the Secuilibrium comment) used the NIST spreadsheet for submitting comments. None of the others are really complicated or long winded so they should not be a problem for the NIST reviewers, but I hope that the corporate lawyers that submit the typical last minute comments will use the spread sheet. The NIST folks do deserver to get some holiday time with their families while they are reviewing and responding to the comments submitted. There is still a January deadline for the publication of the final CSF.


We are now half-way through the comment period. In the remaining three weeks I expect that we will see a much larger number of comments submitted.

Wednesday, November 6, 2013

DHS ITF IdeaScale Cybersecurity Project – ITF Goals

This is another in a series of the blog posts about the latest DHS-IdeaScale project to open a public dialog about homeland security topics. This dialog addresses the DHS Integrated Task Force project to help advance the DHS implementation of the President’s Cybersecurity Framework outlined in EO 13636. The earlier posts in this series were:


Just days after I essentially wrote off this IdeaScale Project another ‘idea’ was posted to site for public comment. This time it was from Jonathan Tabb, who is apparently associated with the DHS Integrated Task Force. Jonathan’s post addresses the recently adopted National Performance Goals supporting the Preliminary Cybersecurity Framework.

I am going to stretch the Free Use Doctrine here a bit with the amount of data I am going to quote from Jonathan’s idea, but it appears that this was lifted intact from an as of yet unpublished DHS ITF document, so I should be okay with the Copyright infringement folks. Here are the National Performance Goals as listed by Jonathan:

1. Critical systems and functions are identified and prioritized and cyber risk is understood as part of a risk management plan.
2. Risk-informed actions are taken to protect critical systems and functions.
3. Adverse cyber activities are detected and situational awareness of threats is maintained.
4. Resources are coordinated and applied to triage and respond to cyber events and incidents in order to minimize impacts to critical systems and functions.
5. Following a cyber incident, impacted critical systems and functions are reconstituted based on prior planning and informed by situational awareness.
6. Security and resilience are continually improved based on lessons learned consistent with risk management planning.

As I commented on the IdeaScale site last night (my comments have not yet been moderated and made public as of 05:30 CST) these goals are even more broadly crafted than the PCF. In fact, they are so broadly crafted that it would be hard to object to anything specific in the goals. Readers that venture a look at the IdeaScale site will note that I did vote ‘Disagreed’ with these goals; that was vote was based upon my disagreement with their being overly broad and without measurable standards.


In the past, I have urged my readers to look at the ideas posted to the IdeaScale site and encouraged them to vote and comment on the ideas. I can no longer in good do that with any enthusiasm for the reasons I outlined in my last post on this topic. Still, if you had hoped that the Cybersecurity Framework, and by extension the National Performance Goals that support the implementation of that framework, would have a measurable effect on the cybersecurity status of the critical infrastructure associated control systems in this county, please join me in disagreeing with this particular idea.

Tuesday, October 29, 2013

NIST Publishes Notice for Preliminary Cybersecurity Framework

Today the National Institute of Standards and Technology (NIST) published a request for comments notice in the Federal Register (78 FR 64478-64480) for the Preliminary Cybersecurity Framework that was published on the NIST web site last week. Alert readers will note that this is a completely different process than that is followed in publication of a new rule or regulation.

The Notice

Today’s notice points back to the NIST Framework web site for both a copy of the Framework to be reviewed and commented upon, as well as a copy of the form that NIST wants people to use to file their comments. Comments are to be submitted directly to NIST via snail mail or email (csfcomments@nist.gov) and must be received by 5:00 pm EST on December 13th, 2013. NIST is not using the Federal eRulemaking Portal for these comments. Comments will be posted in their entirety at http://csrc.nist.gov/cyberframework/preliminary_framework_comments.html.

The notice published today does not mention the alternative format for the listing of “informative references (standards, guidelines and best practices)” provided in the Framework. Apparently there has been some concern expressed about the ease of understanding the table provided in the Framework (pages 13-26). An alternative version is also available on the NIST web site. NIST would like comments on the two versions to be included in any submission of comments.

The Comment Format

NIST has specifically requested that all comment submissions use the form provided on (downloaded from) their web site. Many commenter will find it difficult to adapt their typical verbose expository commenting style to the spread-sheet format provided. I suspect that NIST is expecting a very large number of detailed comments and this format will make it much easier to collect, collate, and analyze a large number of comments.

Given that the President has provided a February deadline for publishing the final version of the Cybersecurity Framework, I think that NIST has made a very astute choice in the way they wish to receive their comments. I also suspect that this request will be widely ignored by many of the organizations that typically comment on federal rules and regulations.

The even larger number of comments from industry (at the operational level) and academia will be submitted by people who are very familiar with the spread sheet format. These commenters will have no problem submitting their comments in the manner suggested/requested by NIST.

The Choice

NIST has made a very interesting choice in the way they have published both the Framework and this request for comments. This request for comments will catch the attention of the people who normally comment of federal rules and regulations and their comments will be very important. The use of the NIST web site as the location for the publication of the rule and comments will attract a completely different set of responses; responses from people at the operational level who deal with cybersecurity issues on a daily basis. It will be interesting to see how effective NIST is in attracting comments from this group of people.

An interesting sidelight to the choice has to deal with the non-regulatory nature of the Framework. One of the reasons that NIST was selected to lead this effort was that they are not a regulatory agency and the Administration has been very careful to publicly reiterate that this is a completely voluntary program. On the other hand, many commentators, me included, have mentioned how easy it might be for regulatory agencies to incorporate this program into their current regulatory regime.


In publishing the Framework document outside of the Federal Register and taking the comment process out of the Federal eRulemaking Portal, NIST has made that inclusion just a little more difficult. Any agency attempting to directly co-opt the Framework will have to first put it through the regulatory wringer of publishing and comment process.
 
/* Use this with templates/template-twocol.html */