This is part of a detailed look at the recently published Discussion Draft of the Preliminary Cybersecurity Framework (PCF). The NIST Information Technology Laboratory (ITL) published this and supporting documentation to their web site during the week of August 28th in order to allow for public comments and preparatory work for the 4th Cybersecurity Framework Workshop in Dallas, TX next week. This series started off with a brief overview of the documents and the Workshop Agenda:
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
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.
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 22.214.171.124 as one of the Informative References.
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.