Cybersecurity Framework Update – Conformity Assessment

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 28^th in order to allow for public comments and preparatory work for the 4^th Cybersecurity Framework Workshop in Dallas, TX next week. The other posts in the series are:

Cybersecurity Framework Update – 8-31-13

Cybersecurity Framework Update – Framework Core

Cybersecurity Framework Update – Adequate Specificity?

Langner Criticizes Cybersecurity Framework

Section 4 of the Discussion Draft addresses a number of issues for future action in support of the requirements set forth in §7(b) of Executive Order 13656. The Draft identifies the following areas “that should be addressed through future collaboration with particular sectors and 353 standards-developing organizations” (pg 11):

• Authentication

• Automated Indicator Sharing;

• Conformity Assessment;

• Data Analytics;

• International Aspects, Impacts, and Alignment;

• Privacy; and

• Supply Chains and Interdependencies

Since the third item appears to be related to something akin to regulations, a major concern of industry, I would like to use this post to address ‘Conformity Assessment’.

Private Sector Assessments

The discussion in §4.3 (pg 12) makes it clear that NIST is not referring to government assessments as part of a regulatory scheme. It starts the discussion off with the following statement:

“Industry has a long history of developing conformity assessment programs to meet society’s needs.”

And it closes the discussion with the following statement:

“Critical infrastructure’s evolving implementation of Framework profiles should drive the identification of private sector conformity assessment activities that address the confidence and information needs of stakeholders.”

Programs like the ISO 9000 quality assessment or The American Chemistry Council’s Responsible Care chemical safety program are the types of assessments to which the Discussion Draft is referring as examples of private sector assessment programs.

Conformance vs Security Debate

There has been a long standing debate in the security community about the differences between conformance to standards and actually instituting adequate security. There is a belief common in security professionals that conformance standards promote a culture of check lists and doing just what is necessary to get ‘approval’. I don’t know that anyone has ever done a real study on the relationship between standards conformance and whether or not an organization takes additional security (safety, quality, whatever) measures not required by the standards organization.

The other side of that is that even if there is a tendency to resort to check list security as a result of establishing a cybersecurity assessment program will that improve the general level of cybersecurity in an industry? Will organizations that do not currently have an effective (or any) cybersecurity program make real improvements (if perhaps less than optimal improvements) to their cybersecurity posture as a result of trying to achieve a minimum level of cybersecurity certification?

Right now the answers to these types of questions will largely be apocryphal. The only real user level cybersecurity standard (with assessment) that I know of is the NERC CIP program and I haven’t heard of anyone doing any real studies of the efficacy of that assessment process. It would be interesting to have either NIST or NSF conduct such a study.

Assessment as an Incentive

The reason that most organizations take part in voluntary assessment programs is that it is good for business. Initial organizations that join these standards assessments do so to differentiate themselves from their competition. As more organizations join the programs it becomes a defensive measure as customers begin to ask why a vendor doesn’t take part in the programs with the unasked question; what are you hiding?

Since the Cybersecurity Framework is specifically targeted at high-risk critical infrastructure organizations and facilities people are, over time, going to expect some sort of statement of compliance from such organizations. This will, of course be limited to some extent since DHS is not expected to announce what organizations are going to be targeted by this program. Even so, there will be some obvious facilities and organizations that will be assumed to be on the List (even if they may not be) so there will be an expectation of a need to comply with the Framework.

As cybersecurity becomes more of an obvious need (almost certainly after a publicly successful attack on an industrial control system) more organizations will be expected by the business community to need to comply with the Framework. The best way to gain recognition for compliance will be through one of these compliance assessment programs.

Moving Forward

As the Framework advances (and I still have some doubts about the completion of this process) I think that we will start to see industry organizations developing assessment programs to support facilities that will be expected to comply. I would not be surprised to see the American Petroleum Institute or ACC be among the early implementers. And NERC might be expected to adapt their CIP assessment process to more nearly include the Framework.

Cybersecurity Framework Update – Framework Core

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 28^th in order to allow for public comments and preparatory work for the 4^th Cybersecurity Framework Workshop in Dallas, TX next week. This series started off with a brief overview of the documents and the Workshop Agenda:

Cybersecurity Framework Update – 8-31-13

In this post I’ll take a quick look at the Framework Core and how it could be applied to organizations with critical industrial control systems. But first I would like to take a quick look at what the Framework is intended to be; it is a management tool not a regulatory compliance tool. The Discussion Draft describes it as a common language for identifying and describing cybersecurity objectives for critical infrastructure organizations. The introduction lists five areas for the use of the Framework:

• Describe current cybersecurity posture;

• Describe the target state for cybersecurity;

• Identify and prioritize opportunities for improvement within the context of risk management;

• Assess progress toward the target state; and

• Foster communications among internal and external stakeholders

Framework Core

The primary component of the PCF is the Framework Core. It is a method of describing cybersecurity activities, existing and desired, that will aid in identifying, reducing and managing the cyber risk of an organization. This is conceived of more of a management tool than a compliance tool.

The Framework Core consists of five basic functions; Identify, Protect, Detect, Respond and Recover. Supporting each function are a number of categories and subcategories that describe management objectives supporting the core functions.  Each subcategory is accompanied by a listing of current information resources (Informative References) that include detailed information that may be used to support and implement tasks in the subcategory.

Appendix A (pgs 14-24) provide a detailed list of the currently identified Categories and Subcategories along with their informative references. The PCF does not intend for this to be an exhaustive listing nor will each subcategory apply to every critical infrastructure organization.

To make it easy to identify a specific subcategory a simple alpha-numeric system is used. Each Function and Category is assigned a two letter identifier and each Subcategory under a given Category is assigned a sequential number. The chart on page 25 provides a listing of each of the two letter identifiers.

Informative References

The current informative references list includes (pg 24):

• ISA 99.02.01 (2009), Security for Industrial Automation and Control Systems: Establishing an Industrial Automation and 485 Control Systems Security Program: http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FISA%2099.02.01-2009 486

• Control Objectives for Information and Related Technology (COBIT): http://www.isaca.org/COBIT/Pages/default.aspx 487

• ISO/IEC 27001, Information technology -- Security techniques -- Information security management systems -- Requirements: 488 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=42103 489

• NIST Special Publication (SP) 800-53, Revision 4, Security and Privacy Controls for Federal Information Systems and 490 Organizations: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf 491

• Council on CyberSecurity (CCS) Top 20 Critical Security Controls (CSC): http://www.counciloncybersecurity.org/practice-areas/technology  [Link corrected 9-6-13 17:35 CDT]

Each Subcategory listing of Informative References provides pointers to areas within that standard that are applicable to that Subcategory. So, for example Subcategory “ID.AM-2: Inventory software platforms and applications within the organization” would point at ISA 99.02.01 4.2.3.4 as one of the Informative References.

Tier

The final concept associated with the Framework Core is the Tiering process. These are not risk Tiers like those found in the CFATS process. Rather they are a description of how management intends to implement the Framework Objectives. The explanation of these Tiers needs a little development work as the titles assigned to these Tiers (pg 6) are less than informative; Partial, Risk-Informed, Repeatable, and Adaptive.

The Tiers are used to establish a Framework Profile for the organization. The Profile consists of two parts, the Target Profile and the Current Profile. The Target Profile lists the Tier for each of the five Functions that management has determined to be appropriate (via a risk assessment process) for the organization. As would be expected the Current Profile is an assessment of where the organization is at for each particular function. With the start point and goals established for the cybersecurity framework for an organization, management can more clearly map out how it expects the organization to achieve the appropriate level of cybersecurity.

The PCF indicates that Tiers are only expected to be applied to the Function levels of the Framework. It would seem to me that the same tool could be applied to each of the Categories within each function. If the cybersecurity program of an organization is sufficiently developed Tiers could also be assigned at the Subcategory level. This would give a clearer picture of what would need to be done to achieve the organization’s cybersecurity goals.

Framework and ICS

While there are significant differences between the way information system security programs and control system security programs are implemented there are enough commonalities that all of the Functions and most of the Categories and Subcategories apply to both IT and ICS systems.

In fact, there is only one Category, Data Security (DS, pg 18), that is not clearly associated with ICS system security. Even that can be stretched to include ICS system security if you look at the data held within and manipulated by the ICS. With that in mind there is only one real subcategory of DS that specifically does not apply to (or cannot be twisted to apply to) ICS security; “PR.DS-9: Protect the privacy of individuals and personally identifiable information (PII) that is collected, used, maintained, shared, and disposed of by organizational programs and systems” (pg 19).

Because there are significant (and in some cases conflicting) differences in security procedures for IT and ICS, I think that it needs to be made clear that organizations with critical industrial control systems should maintain a separate Framework Core for their information and control systems.

NIST has provided a Framework Core example adapted to the electricity subsector. There have been no changes made to the Functions or Categories and only inconsequential changes to the Sub-categories. The only real changes that were made were the addition of some new Informative References:

• NERC Critical Infrastructure Protection (CIP) standards;

• DOE Electricity Subsector Cybersecurity Capability Maturity Model (ES-C2M2);

• ISA/IEC Security for Industrial Automation and Control Systems (ISA/IEC 62443); and

• NIST Guide to Industrial Control Systems Security (NIST SP 800-82).

Actually, I think that the last two ought to be added to the general Framework Core because of the number of environmental and security control systems that exist is ‘purely’ IT organizations. The main point that should be taken from this, however, is that specific industry standards can easily be added to the list of references that are used by an organization in the implementation of their Framework.