NIST Announces CSF 1.1 Webinar

Earlier this week the National Institute for Science and Technology (NIST) announced a webinar providing an overview of the Cybersecurity Framework (CSF) version 1.1. The webinar will be held April 27^th, 2018 at 1:00 pm EDT.

The webcast page describes the webinar as:

“This webcast will provide the audience with a brief history of how the Framework was developed, supply an understanding of basic components of the Framework (Core, Implementation Tiers, and Profiles), demonstrate how the Framework can be used by organizations, highlight the latest features added in version 1.1, and introduce the Framework Roadmap and Industry Resources.  The audience will have an opportunity to ask questions during a Q&A session at the end of the presentation.”

NIST will be using #CyberFramework for its live TWITTER® chat during the webinar.

Register early.

NIST Framework Update – 02-17-18

This week the National Institute of Standards and Technology updated their Cybersecurity Framework web site. Only two things of potential new interest on the redesigned web site; new CSF ‘Online Learning’ and a brief announcement about the date of the next CSF Workshop.

Framework Learning

The new Online Learning page is going to be a disappointment to anyone that expects NIST to provide some new high-tech learning environment. What NIST has provided is three new pages with old-fashioned written discussions with minimal graphics addressing the following topics:

• Components of the Framework;

• Uses and Benefits of the Framework; and

• History and Creation of the Framework.

The information presented is useful and well written. It is just odd to see this presentation format used to address such a modern issue. Actually, I kind of liked it.

Framework Workshop

The new Latest Update page announces that NIST intends to hold their next CSF workshop on September 11^th -13^th, 2018 in the Washington, DC area. Further information will be published in the coming weeks.

Commentary

Back in December NIST published the latest draft version of CSF v1.1 for comments. The comment period closed on January 18^th. NIST has still not published the comments that it has received. The Latest Update page still notes that: “All responses will be published publicly in the coming weeks.”

NIST has chosen not to use the Federal eRulemaking Portal (www.Regulations.gov) to receive comments for a variety of reasons. Most importantly, the justification is that the CSF is not a regulatory regime, so that particular public comment process is not necessary.

In earlier iterations of the CSF process NIST published the responses on the CSF web site as they came in. This allowed interested parties to see what other interested individuals and organizations were saying and add their two-cents worth as appropriate. It also allowed gadflies like myself to conduct on-going analysis and comments (see here for example) as the comments came in. Again, I would like to think that commentators such as myself helped to publicize the CSF discussions and maybe even inspire some additional comments being submitted that would not have otherwise been made.

I am disappointed that NIST did not provide the cybersecurity community to see these comments as they came in. It makes the revision process look much more closed than were the earlier efforts. I am afraid that this type of government activity that is being moved back behind closed doors by an Administration that supposed to be ‘business friendly’. Failing to conduct public business in the public eye is not now, nor never has been ‘business friendly’.

We need NIST to move the CSF modification process fully back into the public spotlight.

NIST Publishes 2nd Draft for CSF 1.1 for Comment

This week the National Institute of Standards and Technology (NIST) published their second draft of version 1.1 of the Cybersecurity Framework (CSF) and a fact sheet that broadly outlines the changes made to the CSF.

The fact sheet makes the point that the revised CSF is applicable to information technology, operational technology, cyber-physical systems, and internet of things. Since the original CSF core already provided references to ISA 62443-2-1:2009 and ISA 62443-3-3:2013 that are found in this revision it does not seem that the new version changes much with respect to OT/IOT security.

OT/IOT Changes

In fact, if you look at the list of changes made to the CSF (starting at page 50) there are only four references to OT/IOT changes:

• Section 1.0 (pg 7): ‘Framework Introduction’ was updated to reflect security implications of a broadening use of technology (e.g. ICS/CPS/IoT) and to more clearly define Framework uses;

• Appendix C (pg 53): ‘Acronyms’ - was modified to include CPS - Cyber-Physical Systems;

• Appendix C (pg 53): ‘Acronyms’ – was modified to include IoT - Internet of things;

• Appendix C (pg 53): ‘Acronyms’ - was modified to include OT - Operational Technology

The introduction section discussion referenced above addresses OT/IOT security issues this way:

“The critical infrastructure community includes public and private owners and operators, and other entities with a role in securing the Nation’s infrastructure. Members of each critical infrastructure sector perform functions that are supported by the broad category of technology, including information technology (IT), industrial control systems (ICS), cyber-physical systems (CPS), and connected devices more generally, including the Internet of Things (IoT). This reliance on technology, communication, and interconnectivity has changed and expanded the potential vulnerabilities and increased potential risk to operations. For example, as technology and the data it produces and processes is increasingly used to deliver critical services and support business decisions, the potential impacts of a cybersecurity incident on an organization, the health and safety of individuals, the environment, communities, and the broader economy and society should be considered.”

Unfortunately, the terms ‘CPS’ and IoT are not used in the revised CSF Core. In short, the CSF does not specifically address the specific cyber-physical consequences of security breaches in OT/IoT systems.

Suggested OT/IOT Changes

Unfortunately, this revision to the CSF still does not adequately address the potential cyber-physical consequences of a cybersecurity incident. At a minimum, the core should have an additional subcategory under Risk Assessment:

ID.RA-X: Worst-case cyber-physical events need to be identified that effect either on-site operations and/or the off-site community.

This would then lead to requiring an additional Risk Management Strategy subcategory:

ID.RM-X: Appropriate emergency response agencies are notified of potential off-site community effects of cyberphysical incidents.

The on-site effects on operations would be addressed by the current IR.RM-4. To clarify that addition, I would reword the subcategory title to read: “Potential business impacts (including on-site and off-site effects of cyber-physical incidents) and likelihoods are identified.”

Broadening Information Security Focus

While the verbiage in the introduction to the CSF would indicate that NIST intends to broaden the focus of CSF to include OT/IoT security, there are still a number of references to ‘information security’ in the CSF core that really should be revised to indicate that broadened focus. For example ID.GV-1 still refers to ‘information security’ when the intent should reflect a broader ‘cybersecurity’; the words should be changed to reflect this. Similar wording changes need to be made to ID.GV-2, ID.SC-3, PR.AT, and PR.AT-5,

Public Input

NIST is asking for public input on this second draft for CSF 1.1. Comments need to be submitted by January 19^th, 2018. Comments can be submitted by email to cyberframework@nist.gov.

NOTE: A copy of this blog post was submitted as a comment to NIST on 12-9-17 14:50 EST.

NIST Publishes CSF Manufacturing Profile

This week the National Institute of Standards and Technology (NIST) published a new implementation document to support the Cybersecurity Framework, the Cybersecurity Framework Manufacturing Profile. In many ways this is similar to the Coast Guard’s draft Framework for Passenger Vessels, so much so that I suspect that the NIST team had some significant input into the CG’s document.

Document Overview

The Profile starts with a brief look at manufacturing systems with a brief overview of the different two very broad types of manufacturing systems (process and discrete) and the types of electronic communications that are employed within the manufacturing and critical infrastructure sectors. It then goes on to provide a quick look at the Cybersecurity Framework, providing some background information about how the Framework was developed and is organized.

Then, as with the CG’s Framework, it provides a brief discussion of the business or mission objectives that are affected by cybersecurity risk. Those objectives (not in prioritized order it is emphasized) (pg8):

• Maintain human safety;

• Maintain environmental safety;

• Maintain quality of product;

• Maintain production goals; and

• Maintain trade secrets.

After providing a series of tables that shows which Framework subcategories support which objective the document proceeds with a discussion of relative potential impact or security levels; Low, Moderate and High. This is includes tables describing impact levels based upon both direct impacts of failure of cybersecurity systems (injury, financial loss, environmental release, interruption of production, and public image) and more generalized impacts based upon products produced or the industry involved.

Finally, we then get to the meat of the Profile; a 26-page table that provides a listing of recommendations for general steps to take for each of the Frameworks sub-categories for each level of impact, along with the appropriate Framework supporting document references for those recommendations.

Commentary

Remembering that the CSF is a risk management or risk communication document and not a technical cybersecurity blueprint, NIST has done a very thorough job of producing a document that is useable by most folks in the manufacturing sector and those critical infrastructure sectors that use industrial control systems. Will people find faults with various specific recommendations? Almost certainly, but that would be true for any document of this type.

I do have one very serious misgiving about this Profile document. The on-line version provides some very good, very specific links to supporting documents. For example, for subcategory DE.DP-5 (Detect, Detection Process #5) the on-line version of the document provides a direct link to CA-2 (Security Assessments) within NIST SP 800-53; very helpful. The problem? Those links are not included in the .PDF document downloaded from the site. I suspect that that is because NIST intends to continually update those links (a thankless task if ever there was one) as the various reference documents are revised. Still, it does limit the effectiveness of the downloaded version of the Profile.

There is a very interesting anomaly in the Profile; there are a number of recommended actions that do not include a reference. For example in ID.GV-1 (Identify, Governance #1) it recommends for all three risk levels: “Ensure the security policy is approved by a senior official with responsibility and accountability for the risk being incurred by manufacturing operations.” This is certainly a good recommendation, but it is interesting that this (and a significant number of similar recommendations) have not been identified in any of the NIST supplied references.

Committee Hearings - Week of 2-26-17

Both the Senate and House will be back in Washington this week. The Senate is still working on cabinet nominations and the House has at least one more regulation reversal to deal with. There are a number of hearings this week, but only two that may be of specific interest to readers of this blog; one on cybersecurity and one on the FY 2018 spending for DHS.

Cybersecurity

On Wednesday, the House Science, Space, and Technology Committee will hold a markup hearing on an as of yet unintroduced bill on “NIST Cybersecurity Framework, Assessment, and Auditing Act of 2017”. There is no draft of this bill publicly available at this time. I expect that the actual bill will be introduced today or tomorrow.

DHS Spending

On Wednesday, the Homeland Security Subcommittee of the House Appropriations Committee will hold a ‘Members’ Day’ hearing to start the hearing process that will eventually lead to the introduction of the DHS spending bill. This hearing is where individual members of the House get their chance to tell the Committee what they would like to see included in the DHS spending bill.

On the Floor

There is nothing of specific interest to readers of this blog currently scheduled on the floor of the House. There are two bill that may have a long-term effect on the regulatory process that will make it to the floor near the end of the week; HR 1009, the OIRA Insight, Reform, and Accountability Act, and HR 1004, the Regulatory Integrity Act of 2017. Both of these bills would combine to try to make the regulatory process more regular and ‘accountable’. Most of the changes will be relatively invisible to the public, but they would provide more chances for Congress to interfere in the regulatory process. Regardless of your political view point, it is easy to see that the regulatory process will become more complex and unpredictable if these bills pass.

Responses to Latest CSF RFI – 02-27-16

This is part of an on-going look at the responses to the National Institute of Standards and Technology (NIST) latest request for information (RFI) on potential updates to the Cybersecurity Framework (CSF). A reminder, the comment period was extended until February 23^rd, 2016. The previous posts in this series include:

Responses to Latest CSF RFI – 01-09-16

Responses to Latest CSF RFI – 01-16-16

Responses to Latest CSF RFI – 01-23-16

Responses to Latest CSF RFI – 01-30-16

Responses to Latest CSF RFI – 02-06-16

Responses to Latest CSF RFI – 02-13-16

Responses to Latest CSF RFI – 02-20-16

This week there were 47 new responses (almost as many as had been posted in total by last week) to the RFI and all but one of them were dated after February 9^th, the original comment cut-off date and one was dated after the new cut-off date. Obviously it was a smart move on the part of NIST to extend the comment period. As I noted last week, I expect that there will probably be one more of these posts to catch any additional late adds to the response list.

The comments posted this week come from:

Navigation Advisors

Don O'Neil

CompTIA

Intel

Financial Services Sector Coordinating Council

BSA

Alberto Piamonte

AGA, UTC, EEI, AAR, ISA and CompTIA

The Providence Group

American Technology Solutions Cyber Technology Alliance

Ernst & Young

FireEye

The Information Technology Industry Council

NASCIO

National Cybersecurity Alliance

The National Laboratory on Cyber Security (Italy)

State of Indiana

Telecommunications Industry Association

The Open Group

Threat Panel

CTIA - The Wireless Association

Electric Power Industry

Global Institute for Cybersecurity and Research

Seymour Mandelcorn

Intellium and Deloitte ERS Italia

Merck

NTCA - The Rural Broadband Association

State of Michigan

American Water Works Association

American Insurance Association

CERT Division of the Software Engineering at Carnegie Mellon University

Dynetics

FIDO Alliance

Information Technology Sector Coordinating Council

Kurt Salmon

Microsoft

National Cable & Telecommunications Association

RSA

Symantec

The Chertoff Group

Krypton Brothers

Alliance for Telecommunications Industry Solutions

AT&T

National Restaurant Association

Rapid7

Robert Lynch

Novant Health

Prevent Duplication of Regulatory Processes

NIST question 9 asks:

“What steps should be taken to “prevent duplication of regulatory processes and prevent conflict with or superseding of regulatory requirements, mandatory standards, and related processes” as required by the Cybersecurity Enhancement Act of 2014?”

One commenter suggested that federal regulators map their cybersecurity regulations to the CSF as the CSF is mapped to various standards. Another commenter suggested instead that NIST conduct such regulatory mapping. Regulatory mapping was addressed by a number (6) of additional commenters.

One commenter noted that the effect of IoT on the CSF should be looked at. Another commenter suggested that there should be more emphasis on acquisition and supply chain issues.

One commenter suggested that regulators use CSF reporting as their regulatory methodology.

Should CSF be Updated?

NIST question 10 asks:

“Should the Framework be updated?”

A number of commenters (1) recommended that the CSF should continue to be updated as existing standards are updated and new standards are published.

One commenter noted that the CSF should be expanded to include cyber threats, insider threats and physical threats. Another commenter suggested that the CSF should involve more detail about technological concepts that effect implementation. Yet another suggested that the CSF should include more detail on creating a target profile. And another suggested more emphasis on state-of-the-art risk management practices. And another requested that the CSF be expanded to include product integrity and supply chain security. Another commenter suggested that medical device and industrial control systems need coverage in the CSF. Big-data and cloud privacy issues were suggested by another commenter as areas that need to be addressed.

One commenter suggested that CSF stability should be a primary concern. Another commented that reducing the frequency of updates would be helpful.

Private Sector Involvement

NIST question 20 asks:

“What should be the private sector’s involvement in the future governance of the Framework?”

A number of commenters (7) noted that the private sector should continue to provide input on CSF improvements. One commenter specifically recommended continued use of RFI’s and regional workshops.

One commenter argued that the users of the framework should provide the governance. Another commenter suggested that the private sector should provide feed-back on implementation issues.

One commenter suggested that NIST should hold semi-annual workshops to address potential changes to the CSF.

Commentary

A total of 100 responses have been posted to the NIST site as of today. Fewer than half of the commenters used the either the spread-sheet format requested by NIST or keyed their responses to specific questions posed in the RFI. I really wish that the commenters that did not have the common decency to take the effort to consider how NIST was hoping to use their responses would sit down and read the 100 responses submitted to date and try to make sense of the data presented.

I am sure that a great deal of effort went into developing these 10 and 20 page responses that went into great detail about how the organization was diligently working on cybersecurity. Unfortunately, those comments were better suited to a press release than being helpful to NIST in charting the future of the CSF.

Over the last two weekends I have spent four hours reviewing responses to look for and analyze information on just three of the twenty questions. And I did not even attempt to read the responses that were not prominently keyed to the specific questions I was looking at. NIST on the other hand is going to have to peruse each of the missives to try to extract the requested information. I do not envy the NIST reviewers who will be required to review each and every submission, no matter how verbose and self-advertising.

It was interesting that out of 47 submissions posted this week, only one mentioned the fact that the CSF needs to be periodically updated to reflect revisions to the various standards referenced in the document. In the long run, I think that it was probably more important that a number of commenters noted that there should be a mapping of CSF and cybersecurity regulations. Comments went both ways; suggesting that regulations reference CSF and vice versa.

Nobody has suggested that new cybersecurity regulations have to be applied; instead they are recommending that regulated industries that are already facing security regulations have the cybersecurity provisions tied into the CSF. That way, commenters suggest, there would not be competing requirements, especially for those organizations facing multiple regulatory schemes.

I was happy to see a number of cybersecurity research organizations included in the responders this week. They had some different insights from those provided by industry organizations.

Responses to Latest CSF RFI – 02-20-16

This is part of an on-going look at the responses to the National Institute of Standards and Technology (NIST) latest request for information (RFI) on potential updates to the Cybersecurity Framework (CSF). A reminder, the comment period was extended and will remain open until February 23^rd, 2016. The previous posts in this series include:

Responses to Latest CSF RFI – 01-09-16

Responses to Latest CSF RFI – 01-16-16

Responses to Latest CSF RFI – 01-23-16

Responses to Latest CSF RFI – 01-30-16

Responses to Latest CSF RFI – 02-06-16

Responses to Latest CSF RFI – 02-13-16

This week there were 37 new responses to the RFI and most of them were dated on or before February 9^th, the original comment cut-off date. This lag has been fairly normal for the NIST RFI’s and is certainly due to the fact that they have to hand process these comments from emails. If NIST stays in the comment reception process they really need to come up with an automated system for receiving/posting the comments.

Since the new comment deadline is this week I expect that I will be doing these posts for at least two more weekends.

The comments posted this week come from:

WTA – Advocates for Rural Broadband

Siemens

HIMSS

Huawei

Genedge Alliance

InfraGard Maryland

Kaiser Permanente

National Association Of Manufacturers

Alion Science and Technology

Morgan Franklin

US Chamber of Commerce

Mikrodots

First 72 Cyber

Educause

CHIME & AEHIS

APCO

American Hospital Association

AdvaMed

American Fuel & Petrochemical Manufacturers

Ascendant

Professional Services Council

American Petroleum Institute

Center for Internet Security

Credit Union National Association

HITRUST

Open Access Technology International

Rofori Corporation

RSA

SCRA

Sustainability Accounting Standards Board

Department of Transportation Federal Highway Administration

CyberEnginuity

Scott J Shackelford, Scott Russell & Jeffery Haut

CISQ

US Telecom

CA Technologies

Coalition for Cybersecurity Policy and Law

Prevent Duplication of Regulatory Processes

NIST question 9 asks:

“What steps should be taken to “prevent duplication of regulatory processes and prevent conflict with or superseding of regulatory requirements, mandatory standards, and related processes” as required by the Cybersecurity Enhancement Act of 2014?”

A couple of commenters recommended that the CSF continue to be voluntary in response to this question.

One commenter noted that DOD, DHS and NSA are developing separate voluntary and mandatory guidelines and approaches which makes compliance more difficult. Another commenter suggested that the CSF be used to harmonize cybersecurity regulatory development. It was suggested by yet another commenter that policy makers should collaborate with federal agencies and the private sector to prevent duplication of regulatory processes and prevent conflict with superseding of regulatory requirements. One health care commenter called for more alignment within the federal government in applying risk management principles. Another commenter suggested that regulators use CSF reporting frameworks as part of their regulatory scheme.

Continued cooperation between standards setting organizations was also suggested. One commenter suggested that a public/private sector guidance body be established.

One commenter noted that the voluntary nature of the CSF implementation was beneficial because it allowed an organization to ignore, add or eliminate processes so that the CSF would be more applicable to the organization.

Another commenter noted that NIST should expand its development of CSF profiles for different regulatory regimes or that regulators could reference the CSF in their rules. One commenter noted that Sector Specific Agencies be required to develop CSF implementation guidelines. Another commenter suggested that the CSF be expanded to an international scope. Another commenter suggested that the CSF should be expanded to include more specific measurable/observable criteria to better support regulatory reporting.

One commenter suggested that continued private sector involvement in CSF updates would ensure that the CSF does not conflict with regulatory requirements.

Should CSF be Updated?

NIST question 10 asks:

“Should the Framework be updated?”

A number of commenters (8) recommended that the CSF should continue to be updated as existing standards are updated and new standards are published. One commenter noted, however, that updates should be limited to allow for adequate implementation experience to guide future updates; this was reinforced by other commenters.

One commenter specifically recommended that health care organizations take an active role in the update process. Another commenter suggested that outdated measures should be removed. A suggestion was made that NIST and industry should work together to develop industry specific implementation guidelines. Yet another commenter suggested that there should be more public safety input into the CSF development process. It was suggested that the CSF remain technology neutral.

An equipment vendor noted that supply chain security issues need to be addressed in the CSF. Another commenter suggested that the internet of things and bring your own device problems should be addressed in the CSF. Yet another commenter suggested that high level control areas for PKI security be included. A government agency suggested that future updates should reflect all stakeholder needs.

One commenter opposed regular updates to the CSF, noting that continuity was more important in the changing field of cybersecurity.

Private Sector Involvement

NIST question 20 asks:

“What should be the private sector’s involvement in the future governance of the Framework?”

A number of commenters (10) noted that the private sector should continue to provide input on CSF improvements.

One commenter noted that the private sector should be providing input to both NIST and standards setting organizations. Another commenter noted that multiple inter-sector dependencies need to be identified. One commenter maintained that private sector involvement leads to a sustainable program. Yet another suggested that the private sector should play a critical role in the CSF governance with another suggesting that the private sector should own the CSF and its governance.

One commenter suggested that private sector input be limited to anonymized input on implementation issues.

Commentary

A total of 53 responses were ultimately received by the end of the original comment period from a broad cross section of responders. This actually ended up being a pretty decent number of responses for this type of non-regulatory request for comments. I was disappointed in the relative lack of responses from security researchers as I know that a number were involved in the original process that led to the publication of the CSF; I expect, however, that they would again get involved in any change process.

Having said that, it should be noted that I did not submit any comments to this RFI. Since the questions were mainly targeted at organizations that had either used the CSF or specifically decided not to use the Framework, I didn’t think that my more philosophical comments would really be appropriate. And that may have been why we saw so few comments from individuals in response to the RFI.

I want to remind folks that the continuing analysis of the responses to the RFI that I have been doing has been limited to those responses that specifically (and clearly) addressed specific questions in the RFI. For the most part I ignored (and suspect that NIST will largely ignore) the more verbose and erudite commentaries on the CSF that were submitted by a large number of the commenters. NIST was looking for specific information and those commenters were not helpful in that regards.

A number of those non-responsive responses were more targeted at the next version of the CSF and may have been more appropriately saved for that process. There was at least one exception to this; the comments submitted by HITRUST both addressed the NIST RFI questions and provided some in depth suggestions for how the next version of the CSF should look. If you are really interested in the future of the CSF I suggest that you take a look at their lengthy commentary; I expect (and hope) that they will be actively involved in the CSF revision process.

Readers of this series of posts will realize that I am a big fan of the NIST attempts to get commenters to use the spread sheet format for submitting responses to the questions that they asked. This makes the compilation and analysis of those comments so much easier. I would like to suggest that NIST continue to work at the development of this process and include the development of a methodology of automating the reception of those spread sheets.

OMB should be actively working with NIST on developing this process of automating the collection and analysis of public comments. This would go a long way to making the regulatory process more effective and reduce the time necessary to complete the regulatory process.

Responses to Latest CSF RFI – 02-13-16

This is part of an on-going look at the responses to the National Institute of Standards and Technology (NIST) latest request for information (RFI) on potential updates to the Cybersecurity Framework (CSF). A reminder, the comment period will remain open until February 9^th, 2016. The previous posts in this series include:

Responses to Latest CSF RFI – 01-09-16

Responses to Latest CSF RFI – 01-16-16

Responses to Latest CSF RFI – 01-23-16

Responses to Latest CSF RFI – 01-30-16

Responses to Latest CSF RFI – 02-06-16

This week there were ten new responses to the RFI. This is almost the same as the total number that had been submitted by last Saturday, and they all came before the original deadline. This week’s responses came from:

America's Health Insurance Plans

American Institute of Certified Public Accountants

American Chemistry Council

Boeing

City of Toronto

Clearwater Compliance

iconectiv

Paramount Computer Systems

Telos

Utilities Telecom Council

Prevent Duplication of Regulatory Processes

NIST question 9 asks:

“What steps should be taken to “prevent duplication of regulatory processes and prevent conflict with or superseding of regulatory requirements, mandatory standards, and related processes” as required by the Cybersecurity Enhancement Act of 2014?”

One commenter recommended that the Federal government should consolidate the Federal cybersecurity effort to avoid having multiple requirements from separate agencies. Similarly, another commenter suggested that if the CSF were to become the regulatory standard, that all agency regulations should be based upon that standard. On the other hand, a separate commenter noted that regulatory requirements should be included in the CSF. Alternatively, another commenter suggested that NIST should have greater outreach to Federal, State and local regulators to aid them in developing consistent regulatory schemes.

One commenter noted that as new industry and international standards are developed they should be incorporated in the CSF. Another commenter suggested that the relationship between the CSF and the NIST Risk Management Framework should be clarified.

Should CSF be Updated?

NIST question 10 asks:

“Should the Framework be updated?”

One commenter noted that the CSF should be cautiously updated to reflect changes in evolving cyber technology and the risk landscape. Another commenter suggested that the CSF needs an implementation plan and an assessment tool like DHS’ Cyber Resilience Review tool. Yet another commenter recommended that newer versions of the CSF should focus on critical areas and key mitigation plans like perimeter defense strategies.

Private Sector Involvement

NIST question 20 asks:

“What should be the private sector’s involvement in the future governance of the Framework?”

One commenter suggested that while NIST should maintain responsibility for CSF governance, ISACS should become directly involved in CSF changes. Another noted that industry Organizations like CHIME should become involved in the CSF process. One commenter suggested that the NERC CIP process has shown that a period of stability is needed between revisions of the CSF, so that lessons learned can be properly identified and incorporated.

Commentary

While the number of commenters that have provided input during the initial 60-day comment period is staggeringly inadequate, the latest batch has a number of interesting and provocative ideas for NIST to consider.

I would like to point out that the majority of the comments received this week were in the CSF comment submission format. This makes the review of the comments much easier. Commenters need to realize that if their intent is to actually influence the CSF improvement process, then making it easier for the reviewers to understand and collate the responses increases the efficiency of the influence.

There were a couple of commenters that seemed to have confused the management tool that is the Cybersecurity Framework and cybersecurity regulations. The CSF is a tool that can be used to analyze the current state of an organizations cybersecurity practices and to figure out what the organizational goals in the field should be and how to achieve them. Regulatory schemes are designed to set minimum standards, establish compliance measures for those standards and ensure that those compliance standards are met. One would like to think that an organization, while having to meet regulatory requirements, would aspire to a higher standard performance. The CSF provides a tool to establish that higher performance level and outline a means to achieve that goal.

Regulatory agencies could certainly use the CSF as a tool for ensuring that their minimum standards reflect industry standards and capabilities. It also provides the necessary references for finding appropriate measurement tools to gauge the effectiveness of responses to regulatory requirements.

But, the CSF is not a regulatory framework. It was never intended to be such and would lose much of its effectiveness if it became one. Probably the greatest advantage of the CSF verses cybersecurity regulations is that it should be easier to update the Framework to reflect changes in the cybersecurity landscape than it would ever be to update regulations. In large part this is because it’s voluntary nature makes organizations much less resistant to changes in the Framework.

Responses to Latest CSF RFI – 02-06-16

This is part of an on-going look at the responses to the National Institute of Standards and Technology (NIST) latest request for information (RFI) on potential updates to the Cybersecurity Framework (CSF). A reminder, the comment period will remain open until February 9^th, 2016. The previous posts in this series include:

Responses to Latest CSF RFI – 01-09-16

Responses to Latest CSF RFI – 01-16-16

Responses to Latest CSF RFI – 01-23-16

Responses to Latest CSF RFI – 01-30-16

This week there were five new responses to the RFI. This is the largest number of responses in a single week, but it is still a remarkably small number of responses. This is even more concerning because the comment period ends on Tuesday. This week’s responses came from:

SABSA Institute

Nippon Telegraph and Telephone Corporation

BSI America

University of Pittsburg

National Association of Federal Credit Unions

Prevent Duplication of Regulatory Processes

NIST question 9 asks:

“What steps should be taken to “prevent duplication of regulatory processes and prevent conflict with or superseding of regulatory requirements, mandatory standards, and related processes” as required by the Cybersecurity Enhancement Act of 2014?”

Only three of the responders addressed this question in their response. One recommended that the CSF continue to be a voluntary program until such time that there was an industry wide consensus that the Framework should be adopted. Another commenter suggested that various cybersecurity regulatory standards be included in the reference standards. The final commenter on this questions suggested that a cross-functional group (including representatives from industry and standards organizations) be formed to establish a CSF change control process

Should CSF be Updated?

NIST question 10 asks:

“Should the Framework be updated?”

The same three commenters also addressed this question. One suggested that change for change sake should be carefully avoided. A second recommended that the next update should address risk management decisions and prioritization processes in more detail. The other responded that updates should be responsive to industry feedback.

Private Sector Involvement

NIST question 20 asks:

“What should be the private sector’s involvement in the future governance of the Framework?”

Again comments on this question were only receive from the same commenters that responded to questions 9 and 10. One expressed support for continuing NIST control of the CSF process with advice from industry. Another suggested that industry support should be specifically restricted to an advisory role to avoid conflict of interests. The third commenter suggested that NIST continue with using the RFI process and holding open public meetings and workshops when updating the CSF.

Commentary

Only two of this week’s commenters used the NIST spreadsheet for submitting comments. The third that responded to specific questions used a standard WORD® format with responses specifically keyed to the RFI questions. The remaining two commenters used the old-style letter format that pressed their organizational agenda rather than specifically respond to the RFI questions.

I suspect that that out-of-date response style means that what may have been legitimate and perhaps useful concerns will likely be given little consideration in moving the CSF update process forward. NIST has established a history of moving forward quickly in response to RFIs and that can only happen when specific responses are given to specific questions.

I really hope that there will be a much larger number of responses received in this last week of the response process. If we continue with the same level of response it is hard to imagine that NIST will be able to continue forward with a rigorous update process for the CSF.

DOE Publishes DRAFT CSF Implementation Guidance

Yesterday the Department of Energy (DOE) published a notice in the Federal Register (79 FR 54695-54696) announcing that it had published a draft guidance document for the energy sector that describes how organizations in that sector could be expected to implement the NIST Cybersecurity Framework (CSF) that was published last February.

DOE had earlier developed a Cybersecurity Capability Maturity Model (C2M2) for the energy sector. According to the introduction to that document the C2M2 was designed to focus on “the implementation and management of cybersecurity practices associated with the information technology (IT) and operations technology (OT) assets and the environments in which they operate” (pg 1). Like the CSF this is a high-level document that allow for the development and documentation of a cybersecurity risk management program. One major difference between the C2M2 and the CSF is that the C2M2 does not specifically tie Maturity Indicator Levels (MILs) back to established standards and practices.

DOE made an earlier attempt at tying the CSF to the C2M2. It published a two page document that highlighted the similarities between the CSF and the C2M2, but it lacked any specific guidance on how the two programs could be used to support each other.

The new guidance document is a much more detailed look at the alignment of the two cybersecurity management programs. For example, Appendix A shows each of the CSF’s Functions, Categories and Subcategories and then lists each of the C2M2 practices that support that effort at each of the MILs.

DOE is requesting detailed public feedback on the draft Guidance document. DOE is not using the Federal eRulemaking portal; responses will be emailed directly to DOE (Cyber.Framework@hq.doe.gov). To make handling of the comments easier to manage, DOE is requesting that commenters use a specific Word® format form that requires the provision of the Section, Page and Line number for each comment. This should expedite the handling of comments and ensure that each commenter’s input is considered in the appropriate review area of the Guidance.

DOE has set a very unrealistically short comment period for the review of this document. They are asking for comments to be submitted by October 14th. Most large organizations will not be able to get internal reviews conducted in that short a time frame; much less prepare detailed responses. May be that is what DOE is trying to accomplish here; fewer comments means less rewriting of the Guidance.

NIST Updates CSF Web Site – 03-08-14

As promised, NIST is continuing to work on the Cybersecurity Framework (CSF). This week changes to the CSF web site reflect those continuing efforts. You have to click through a couple of links to find the actual change, but NIST will be holding another CSF Workshop next month. This one will focus on the privacy aspects of the CSF that were not fully addressed in CSF v1.0.

While privacy is not a major focus for most industrial control systems, the privacy processes will almost certainly be at least of some concern to managers of cybersecurity security programs. Part of any security program must include some form of vetting of personnel with access to computer systems. Vetting programs require the collection of personally identifiable information (PII) and thus privacy issues abound.

The current draft agenda for the April 9^th Privacy Engineering Workshop at the NIST headquarters in Gaithersburg, MD does not include any specific discussion of security program privacy issues. That is not surprising since this is an engineering workshop, not a policy workshop. It will be interesting to see if the issue comes up in any of the discussions.

CSF - Control System Security and CFATS

Yesterday I wrote a post describing a new process control system security program developed for the Water Sector. The program is broadly based upon the recently published NIST Cybersecurity Framework (CSF). Since large portions of the Water Sector are federally regulated (usually under State supervision) it was to be expected that an attempt would be made to incorporate the CSF into the loose regulatory scheme for drinking water security.

CFATS and CSF

Chemical facilities covered under the CFATS program might also be expected to face the inclusion of a CSF based cybersecurity program under the terms of §10 of the President’s Executive Order on Improving Critical Infrastructure Cybersecurity (EO 13636). Risk Based Performance Standard (RBPS # 8) of the CFATS regulations already {6 CFR §27.230(a)(8)} governs cybersecurity at covered facilities and requires that those facilities:

Deter cyber sabotage, including by preventing unauthorized onsite or remote access to critical process controls, such as Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), Process Control Systems (PCS), Industrial Control Systems (ICS), critical business system, and other sensitive computerized systems;

Thus it would appear that DHS through the Infrastructure Security Compliance Division (ISCD) of the National Protection and Programs Directorate (NPPD) has the requisite “clear authority to establish requirements based upon the Cybersecurity Framework to sufficiently address current and projected cyber risks to critical infrastructure.

Furthermore, the non-directive nature and the lack of specificity found in the CSF would mesh well with the CFATS program’s congressional mandate to allow covered facilities the widest latitude in developing security procedures and processes that would achieve the broad requirements of the RBPS.

The CFATS program already has an RBPS Guidance document that was adapted through a formal publication and public comment process. It provides very-broad, non-specific guidance on all 18 of the separate RBPS that govern the CFATS security processes. It contains 9 pages (pgs 71 – 81) of broadly written guidance on what the facilities site security plan must cover with respect to cyber security. Those pages includes nearly four pages of vaguely worded metrics that may be keyed to the (Risk) Tier ranking of the facility. An example is given below.

Metric 8.2.5 – Password Management - The facility has documented and enforces authentication methods (including password structures) for all administrative and user accounts. Additionally, the facility changes all default passwords and ensures that default passwords for new software, hardware, etc., are changed upon installation. In instances where changing default passwords is not technically feasible (e.g., a control system with a hard-coded password), the facility has implemented appropriate compensating security controls (e.g., physical controls).

Appendix C (pgs 162 – 173) includes another discussion of cybersecurity and how it impacts some of the other RBPS. That discussion also includes a listing of cybersecurity references similar to those found in the CSF. The RBPS reference list is not keyed to allow the facility to determine what areas of what standard apply to which parts of their cybersecurity program.

CSF Style Cybersecurity Guidance

A cybersecurity guidance tool like that developed for the Water Sector would fit in very nicely with the CFATS general security program. It would provide a general discussion of the various details that should make up a cybersecurity program and provide specific references that could be expected to provide more detailed information about that specific portion of the program.

The CFATS cybersecurity program is targeted not so much at protecting information as it is designed to protect access to and control of chemicals. Thus most of the systems covered are control systems, though some of the order placement and tracking systems could be a CFATS concern if the facility were regularly shipping covered DHS chemicals of interest (COI). Additionally any automated security systems, including video detection, security alarms and chemical release mitigation systems would also require protection under the CFATS site security plan.

The CFATS program already has a series of on-line tools that it uses in administering the evaluation of the implementation of the site security plans as well as the administrative aspects of the program. This Chemical Security Assessment Tool, CSAT, could easily be expanded to include a cybersecurity tool.

CFATS Cybersecurity Framework Tool

The Cybersecurity Framework Tool (CSFT) would encompass three closely related cybersecurity tasks:

• Define and catalogue those components of the facility computer based systems that would have direct impacts on the security of the chemicals of interest made, used or stored at the facility;

• Provide a reference based description of the security measures that would be necessary to protect those cyber assets; and

• Provide a method for recording the security activities that the facility has taken and plans to take to protect the security of their chemical security related cyber assets.

CSFT and the Security Vulnerability Assessment

ISCD makes a preliminary determination that a facility is at high risk of terrorist attack based upon the initial information provided in the Top Screen, a data submission tool that provides DHS information about the types and quantities of DHS chemicals of interest (COI) stored, used or produced on site and general geophysical information about the facility. Once that preliminary determination is made, ISCD directs the facility to complete a security vulnerability assessment (SVA).

The first portion of the CSFT would become a portion of that SVA. The facility would provide a brief description of the major components of its chemical and security related cyber systems. The tool would be constructed in a similar manner to the way the current SVA tool is designed with a series of questions with multiple choice types of answers and a limited number of fill in the blank responses.

For facilities that had release hazard COI (chemicals that if released on site in a terrorist attack could be expected to have serious off-site consequences) would be required to list the types of computer or electronic systems used to monitor or control the movement or physical status of those release COI on site. These would be primarily industrial control systems, but could also include automated safety systems and release detection systems.

For facilities that had theft/diversion hazard COI (chemicals that could be used to make improvised explosive devices (IED) or chemical weapons (CW) would be required to list the types of computer or electronic systems used to control the inventory and shipping of those chemicals. This would include any security systems used to control access to those chemicals.

All facilities would also be required to provide information about the electronic security systems that were used to monitor the facility or key area perimeters or control facility or key area access.

Once the major cyber components were identified there would be a series of questions about each of those components. Those questions would be designed to solicit the information necessary to determine the Use Cases similar to those shown in Table 3-1 of the AWWAC Process Control System Security Guidance for the Water Sector. Those use cases would be used to determine the level of cybersecurity risk at that the facility related to the electronic systems used to control or protect the COI at the facility.

More to Come

This post has gotten a little bit longer than I like, so this seems to be a reasonable stopping point. In future posts in this series I’ll look at how the CSFT can be used as part of the site security plan development, authorization and approval processes for CFATS facilities. I’ll also discuss how DHS can use the provided information to provide specific cybersecurity support to the facility.

Framework for Improving Critical Infrastructure Cybersecurity

As most people concerned with cybersecurity are well aware, the National Institute of Standards and Technology published the Framework for Improving Critical Infrastructure Cybersecurity on Wednesday. In a very real way there is nothing new in the Framework; it was designed to be a compilation of existing standards brought together in a way that would be more accessible to an organization wishing to evaluate and improve its cybersecurity profile.

Framework Core

The big benefit of Framework is that it puts much of the cybersecurity problem in language that most business executives are comfortable with and understand. The Framework Core (Appendix A) breaks cybersecurity down into five functional areas (Identify, Protect, Detect, Respond, and Recover). In turn, each of those is broken down into Categories (actions to be taken in each functional area) and Subcategories (management tasks that would be undertaken to support the cybersecurity mission of an organization).

Informative References

To this point in the Framework Core, everything is written in language familiar to most business executives with little or no cyber-expertise needed. The only real technical information provided in the Framework is the listing (Informative References) of the various existing cybersecurity standards (down to the section or paragraph level) that support each of the Subcategories in the Core.

This list of ‘Informative References’ is not designed to be comprehensive. It only lists information from six documents:

• CCS CSC;

• COBIT 5;

• ISA 62443-2-1;

• ISA 62443-3-3;

• ISO/TEC 27001; and

• NIST SP 800-53

A separate, more comprehensive listing of documents that provide some sort of technical information on cybersecurity programs is available [EXCEL download link] on the NIST web site. There is no indication on the NIST web site that this Compendium is being maintained as a current, up-to-date comprehensive listing of cybersecurity programs.

Shortcomings

There are a couple of major shortcomings with the Framework. First by design it is a completely voluntary program. The President has not been given the legislative mandate to create a critical infrastructure cybersecurity program, so he does not have the general authority to mandate that this program be implemented. There are ongoing discussions within the Administration to determine which limited areas current legislative authority has been given that might be applied to the Framework.

The second drawback is that this is a management document, not a technical document. Even the six standards that are listed in the Informative References column are more cybersecurity management documents than detailed technical descriptions of how to implement the specific controls that will actually secure the various aspects of an organization’s cyber assets. Again this is by design as no single document could possibly identify the technical details and be of useable size or remain up-to-date past the time it was drafted much less published.

An organization is still going to have to have access to the technical expertise to put the management guidance provided in the Framework into practical application. What is missing in this document (and realistically can’t be put into such a document) is some method of ensuring that there is adequate communication between management and the technical expertise to allow for a proper assessment of the organization’s specific risk and the resources necessary to mitigate that risk.

Information Sharing

The final problem with the Framework is that it exists in an informational vacuum. There are no mechanisms in place for the sharing of operational information or intelligence information that would allow organizations to adapt to the changing cybersecurity environment. Again, this is due to the lack of congressionally provided authority to establish and maintain the information sharing mechanisms that would make such an adaptation process viable.

Moving Forward

The Framework does not exist in a vacuum. As I mentioned in an earlier post DHS is establishing a program to support organizational implementation of the Framework by critical infrastructure organizations. In the coming weeks and months I would assume that we will see other federal programs addressing how they will support implementation of the Framework by the critical infrastructure organizations that they support and or regulate.

Cybersecurity Framework Roll-Out at DHS

While most of the cybersecurity community was focused over at the NIST web site today to see the official roll-out (on time I reluctantly add) of the Cybersecurity Framework, there was an equally important set of cybersecurity information being rolled out over on the DHS web site. DHS is, after all, is going to be the federal agency responsible for ‘overseeing’ the implementation of the Cybersecurity Framework.

The Blog

It started off this afternoon with a blog post by Suzanne Spaulding, the Acting Under Secretary for the National Protection and Programs Directorate. In that post she recapped the evolution of the Cybersecurity Framework under the auspices of NIST and announced the DHS supporting program the C³ Voluntary Program.

The three C’s of C³ represent actions to be taken by DHS to support industry in increasing cyber resilience, to increase awareness and use adoption of the Cybersecurity Framework, and encourage organizations to manage cybersecurity as part of an all hazards approach to enterprise risk management. They stand for:

• Converging critical infrastructure community resources;

• Connecting critical infrastructure stakeholders; and

• Coordinating critical infrastructure cross sector efforts

C³ Voluntary Program

This new DHS effort is outlined in a new web site under the auspices of US-CERT. This site is intended to be an information resource for the cybersecurity community. The landing page provides a brief overview of the program and links to the other pages on the site. They include:

Getting Started;

Getting Started for Business;

Getting Started for Federal Government;

Getting Started for State, Local, Tribal, and Territorial (SLTT) Governments; and

Self Service Tools

There is a lot of information on these six pages, and I expect that more will be coming. Over the next couple of days, I will be looking at some of that information in more detail.

NIST Updates Cybersecurity Framework Page – 12-16-13

Earlier this week NIST did a complete revamp of their Cybersecurity Framework (CSF) home page. There is less information directly on the page but there are still active links to all of the developmental information from the old site.

It looks like NIST is getting ready for the publication of the final version of CSF. No word yet when that will be (to be fair the comment period just ended a little over a week ago) but the deadline that was established in EP 13636 was one year or February 19^th, 2014. That deadline does not carry the force of law; the Director of NIST only has to keep his boss, the Secretary of Commerce, happy. In this case that means the keeping the President satisfied that work is progressing with reasonable dispatch.

We’ve already seen how much the President is holding the chemical folks to their deadlines on the Chemical Safety and Security EO, or the National Archives and Records Administration on the Sensitive But Unsecure Information  EO deadlines. If NIST can get a document into the Federal Register by June, the President will probably be real happy. Unless, of course there is a major critical infrastructure breach, then all bets are off.

QUESTION: Why isn’t 40 million compromised bank accounts (ala Target)  a major breach? It’s only money.