Clicky

Header graphic for print
InfoLawGroup privacy. security. technology. media. advertising. intellectual property.

Cybersecurity Effort Moves Forward – NIST Issues Final Critical Infrastructure Cybersecurity Framework

Posted in Uncategorized

Our Senior Counsel Mark Paulding assisted in the preparation of this post.

There is little argument that the issue of information security has bipartisan support in Congress.  It has been some time since we have seen both parties come together for information governance legislation, but they did just that in December 2010, passing the Red Flags Clarification Act that narrowed the scope of the infamous Identify Theft Prevention Red Flags Rule, allowing the FTC to implement the rule after two years of delays.  But battles over other issues have prevented Congress from focusing on cybersecurity since then.  This is despite the recognition of increasing threat to the security of U.S. networks from foreign governments, ”hacktivists,” and terrorists.   Frustrated by the inaction, the Administration issued an Executive Order that called for enhanced cybersecurity measures.  Now, NIST has published the first release of the Framework for Improving Critical Infrastructure Cybersecurity (“Framework”) designed to fulfill one of the mandates set by the Executive Order.

The order and the framework target owners, operators and other entities working within assets that are vital to the U.S. The White House has named a broad swath of critical industries, including:

  • Chemical plants;
  • Communications providers;
  • Water supply facilities;
  • Defense industrial base;
  • Emergency services;
  • Energy and utilities (including nuclear);
  • Financial services;
  • Food and agriculture;
  • Government facilities;
  • Healthcare industry;
  • Information technology;
  • Waste management and transportation systems; and
  • Water and waste-water systems.

The Framework will apply – by extension – to the critical infrastructure owners’ and operators’ service providers.

The Framework shares its “flexible” approach with the Red Flags Rule.  Both are technology agnostic and mandate a process and a goal, not an ultimate outcome.  While this flexibility is likely necessary in the fast-paced cybersecurity environment, the implementation of the Red Flags Rule suggests that this flexible approach may lead to significant and persistent confusion among businesses that, in their legal compliance effort, have in the past been asked mostly to abide by fairly rigid requirements.

NIST has emphasized that the framework is designed to be pro-business: to support business objectives, integrate business and cybersecurity risk, allow cost-effective implementation and provide appropriate tools to senior executives, to be a resource for businesses of all sizes, and not be disruptive to existing practices.  The stated focus on business interests is refreshing, and could encourage participation in and adoption of the voluntary compliance program proposed by the Administration.

There has been criticism, discussed below, that the framework is more of the same.  But, again, looking at the Red Flags Rule, there is an argument that pulling known experience in cybersecurity and lessons learned into one framework is valuable in that it encourages businesses to think about the issue – here, cybersecurity – holistically.  In addition, by mapping several established security standards to a common scheme, the framework may assist organizations that have struggled to define the safeguards needed to comply with multiple standards.

Recognizing that the code is voluntary, the Administration has been considering incentives for business that adopt the framework, including “cybersecurity insurance, federal grants, preference in technical assistance, liability limitation, streamlining with existing regulations and laws, optional public recognition, rate recovery for price-regulated industries, and cybersecurity research for future security issues.”

In this post, we have summarized the key provisions of the Framework.  Skip to the bottom of the post for points to take away.

Framework Development

The Framework was prepared at the direction of White House Executive Order 13636 (February 12, 2013).  The Framework applies to public and private sector organizations that perform critical infrastructure functions that are supported by information technology and/or industrial control systems.  The relevant industry sectors are set out in Presidential Policy Directive 21 (February 12, 2013), and described in greater detail by the Department of Homeland Security.

Compliance with the Framework is intended to be voluntary.  The Framework includes safeguards designed to counteract an array of cyber risks, including network infiltration, interception of confidential communications, compromise of supply chains, and denial of service attacks.

The Framework is mapped to the leading industry security standards, including the following.

Like the security standards it is based upon, the Framework establishes a risk-based approach to security management.  The Framework encourages businesses to manage cybersecurity in a manner similar to other business risks, such as financial, safety and operational risks.  Organizations are expected to identify and prioritize opportunities to improve safeguards, mitigate risks, and measure progress.  In an attempt to encourage innovation and flexibility, the Framework focuses on outcomes rather than specific rules of conduct.  The expectation is that security safeguards will improve over time based on experience and technology.

In response to concerns raised by privacy advocates, the draft Framework included guidelines regarding collection, use, storage, and sharing of personally identifiable information in the conduct of a cybersecurity program that are consistent with the Fair Information Practice Principles (“FIPPs”).  FIPPs are a longstanding privacy framework that has been integrated into a variety of privacy regimes, including the Privacy Act of 1974, Federal Trade Commission jurisprudence, and NIST Special Publication 800-53 Rev. 4.  The final Framework, however, contains only a general methodology for protecting the privacy of personal information handled by cybersecurity programs.  The initial proposal lacked industry support and was omitted.  This is hardly surprising because consensus on privacy continues to be elusive.

Framework Content

The Framework creates a common language that may be used by owners and operators of critical infrastructure to:

  • Describe their current security posture;
  • Describe their target state of cybersecurity;
  • Identify and prioritize opportunities to improve safeguards;
  • Assess progress toward the target state of cybersecurity; and
  • Foster communication between internal and external stakeholders.

It is important to emphasize that the Framework is not a set of rigid requirements – it sets forth what can be described as a process, an approach or a framework for addressing cybersecurity.  The Framework does not mandate cybersecurity measures.

The Framework consists of three elements: the Core, the Implementation Tiers, and the Profiles:

  • The Framework Core is a set of cybersecurity activities and desired outcomes.  Together, the five Core elements provide a “high-level, strategic view of the lifecycle of an organization’s management of cybersecurity risk.”
  • The Framework Implementation Tiers articulate how an organization views cybersecurity risk and the processes in place to manage that risk.
  • A Framework Profile represents the outcomes based on the organization’s business needs. The Profile articulates how an organization’s standards, guidelines, and practices correspond to the Framework Core in a particular implementation scenario.  Profiles can be used to identify opportunities for improving cybersecurity posture by comparing an organization’s existing Profile to the desired Profile.

Using the Framework

The key to using the Framework is understanding that it does not replace organizations’ current processes.  Instead, organizations should overlay the Framework over their current cyber security practices to determine gaps in their current cybersecurity risk approach and develop a roadmap to improvement.  There is a variety of ways in which organizations can use the Framework.  Here are several examples:

  • Benchmarking. Comparing an organization’s current cybersecurity practices with those outlined in the Framework Core.  To do this, an organization would create a Profile that reflects the extent to which the organization is achieving the outcomes described in the Framework Core for the Core’s five high-level functions. The organization can then develop a plan to enhance its practices, if it determines that the practices require improvement with reference to the appropriate Implementation Tier.
  • Establishing a Cybersecurity Program. In this example, an organization would use the Framework to create a cybersecurity program (or improve an existing program).
    • Prioritize and Scope.  Identify business/mission objectives and priorities to make strategic decisions about cybersecurity implementations and the systems that support relevant business processes;
    • Orient.  Identify systems, legal obligations, and general risk approach for relevant business processes, and consider identifying the appropriate Implementation Tier;
    • Create Current Profile.  Develop profile detailing how the Framework Core is currently being achieved;
    • Conduct Risk Assessment.  Discern the likelihood and potential impact of cybersecurity events, including new and emerging threats;
    • Create Target Profile.  Develop Profile detailing the desired outcomes based on the results of the risk assessment;
    • Determine, Analyze, and Prioritize Gaps.  Compare current and target Profiles to identify gaps that should be addressed;
    • Implement Action Plan.  Adopt measures to resolve gaps between the current and target Profiles and address the risks identified in the risk assessment.

More on Core, Tiers and Profiles.

  • Core

The five Framework Core cybersecurity functions are:

  1. Identify.  Identification of cybersecurity risks faced by an entity;
  2. Protect.  Implementation of safeguards to mitigate the identified risks;
  3. Detect.  Implementation of activities to detect incidents;
  4. Respond.  Implementation of procedures to respond to incidents;
  5. Recover.  Implementation of procedures to restore systems affected by an incident and improve safeguards based upon lessons learned from incidents.

The Framework further breaks down the Core functions into categories and subcategories.  Here are some of the key elaborations of the Core:

  • Risk Assessment.  The Framework places strong emphasis on the identification of potential cybersecurity risks.  Organizations should identify all assets needed to achieve business purposes as well as all risks to important business objectives, stakeholders, and activities.  Threats and vulnerabilities should be defined based on internal metrics and information shared among partners.  Risk tolerances should be clearly defined based on the organization’s role in critical infrastructure and sector-specific risks (e.g., a utility should consider the risks that are specific to its business).
  • Incident Detection, Investigation, and Response.  Reflecting a growing consensus among security professionals, the Framework presumes that even the best preventive safeguards will fail on occasion.  Accordingly, significant attention is dedicated to the maintenance of processes and procedures to detect, investigate, and respond to incidents.  Organizations should actively monitor their systems for anomalous activity that may indicate attacks in progress.  These monitoring activities should cover network activity as well as physical access to organizational facilities.  Baselines of ordinary activity and thresholds for anomalous activity should be formally defined.  Organizations should collaborate with partners and share information about anomalous activities and confirmed incidents.  Formal plans for response to anomalous activity and suspected incidents should be established and followed.  Upon detection of anomalous activity, forensic analyses should be conducted.  Confirmed incidents should be contained and eradicated.  Incident response plans and safeguards should updated based on lessons learned from past incidents.  Furthermore, lessons learned should also be communicated with partners and other relevant external parties to improve the overall state of cybersecurity.
  • Service Provider Management.  The Framework expressly applies many of its provisions to the management of service providers.  For example, the risk assessment provisions dictate that risks be identified for external systems (e.g., those maintained by service providers) as well as internal systems.  In addition, the role of all entities within a supply chain should be determined and factored into the risk management process.  The roles and responsibilities of third party stakeholders should be clearly defined and understood by all parties.  The Framework specifically notes that service provider actions should be monitored in order to detect anomalous activity.  Organizations may coordinate incident investigation and response procedures with service providers and other third parties.  Finally, the Framework indicates that there is a great deal of room for improvement in the practice of supply chain security.  Owners and operators of critical infrastructure can expect this area of cybersecurity to evolve in the foreseeable future.
  • Methodology to Protect Privacy and Civil Liberties.  The Framework establishes a methodology to mitigate the effect of a cybersecurity program on civil liberties and privacy.  Organizations should consider privacy concerns while assessing cybersecurity risks and selecting security measures.  Appropriate privacy training and awareness programs should be maintained, including specialized training for those responsible for managing privacy practices for the cybersecurity program.    Organizations should identify the legal obligations applicable to the cybersecurity program.  (It should be noted that these legal obligations may include wiretap and stored communications laws.)  They should also assess and manage sharing of personally identifiable information with third parties for cybersecurity purposes.  The Framework specifically recommends that access management and anomaly detection procedures be managed to minimize collection and use of personally identifiable information.
  • Tiers

The Framework sets out four Implementation Tiers that describe how an organization manages its cybersecurity risks based on the “rigor and sophistication” of risk management practices and “the extent to which cybersecurity risk management is informed by business needs and is integrated into an organization’s overall risk management practices.”  Each Implementation Tier is defined by three factors:  (1) a risk management approach; (2) level of security program integration across the organization; and (3) and collaboration with third parties in response to shared cybersecurity risks.

The Implementation Tiers are:

  1. Partial.  Risk management practices are not formalized, instead managed on an ad hoc basis.  No organization-wide approach to managing risks has been established.  The organization may not have processes to collaborate with other entities.
  2. Risk-Informed.  Risk management practices may be approved by management, but may not be established in organization-wide policy.  Risk-informed processes are implemented and staff has adequate resources.  The organization has not formalized capabilities to collaborate with other entities.
  3. Risk-Informed and Repeatable.  Risk management practices are approved by management and expressed in formalized policies.  Consistent methods are adopted to respond to changes in risk.  The organization collaborates with partners in response to cybersecurity events.
  4. Adaptive.  Cybersecurity practices are adapted based on lessons learned and predictive indicators derived from previous activities.  Risk-informed policies, procedures, and processes are a part of organizational culture.  The organization shares information with partners in order to improve practices before incidents occur.

The Framework leaves organizations with substantial discretion to select the Implementation Tier most appropriate for them (but any owner or operator of critical infrastructure would be hard pressed to justify selecting Tier 1 or 2).  “During the Tier selection process, an organization should consider its current risk management practices, threat environment, legal and regulatory requirements, business/mission objectives, and organizational constraints.”

  • Profiles

The Framework Profiles align the detailed functions, categories, and subcategories of the Framework with the “business requirements, risk tolerance, and resources of the organization.”  Such Profiles can be used to identify a path for managing cybersecurity risks in line with organizational and industry objectives, legal and regulatory obligations, industry best practices, and organizational risk management priorities.  NIST suggests that organizations develop a Current Profile, based on existing security outcomes, and a Target Profile, based on the desired security outcomes.  Gaps between the Current and Target Profiles can be used to create action plans to improve a cybersecurity program.  NIST has noted that it may be appropriate to maintain multiple sets of Profiles for complex organizations, such as conglomerates that include business units that face noticeably different cybersecurity risks.

Takeaways

Owners and Operators of Critical Infrastructure should take advantage of the common language and methodology of the Framework to assess their existing cyber security practices and develop an action plan for continuous improvement.  Organizations that have already adopted comprehensive security programs based on accepted industry standards may use the common language of the Framework to assess and communicate their current cybersecurity practices.

Service Providers to owners and operators of critical infrastructure should strive to be early adopters of the Framework.  Given general affinity for standards in vendor contracting, critical infrastructure owners and operators are likely to require their service providers (and prospective service providers) to comply with the Framework as a condition of doing business, giving compliant service providers a competitive advantage.

Owners and Operators of Non-Critical Infrastructure may also take advantage of the Framework by using it to address cybersecurity holistically within their organizations.

Continuous Evolution.  The Framework establishes the expectation that organizations will continuously monitor, evaluate and adjust their cybersecurity practices.  This includes learning lessons from past security incidents.  Static security programs run the significant risk of being surprised by innovations on the part of cyber attackers.

Collaboration and Communication.  The Framework emphasizes the value of communication and collaboration among owners and operators of critical infrastructure to share experiences and lessons learned.  Such exchanges of information should help entities better protect their information systems.  In the absence of such collaboration, newly developed exploits can be reused against numerous entities with relative impunity.  With collaboration, all participants benefits as soon as one entity detects a new exploit.

Limit Use and Sharing of Personally Identifiable Information for Cybersecurity Purposes.  While continuous monitoring and collaboration are important steps in an effective program to protect critical infrastructure, entities should be cognizant of the privacy of individuals whose information they may collect, use, store, disclose and otherwise process in connection with their cybersecurity programs.

  • Dave Dyk

    Boris –

    What options exist for a service provider or critical infrastructure provider who wants to demonstrate “compliance” with the framework?

    Would they simply do some analysis of their posture relative to the framework, and provide a summary of the results to their customers? Or, would they need to solicit some type of independent audit that would look into their implementation of the framework?

    • Boris Segalis

      Dave

      I would follow the approach proposed by the framework — i.e., (i) using the language/terminology of the framework (core, tier, profile) to assess the service provider’s security posture, and (ii) creating a document that uses the framework’s language to articulate the posture to customers/clients. Something like (in the concept only) a SOC report.