In February 2014 the U.S. National Institute of Standards in Technology (‘NIST’) published the first NIST Cybersecurity Framework, responding to an Executive Order on improving critical infrastructure cybersecurity issued by President Obama. At the end of last year, NIST released draft two of the Framework for Improving Critical Infrastructure Cybersecurity Version 1.1, which incorporates feedback received by NIST since the release of Version 1.0.

While cybersecurity has become an obsession for business and government in the past decade, we are still adrift on selecting the standards needed to build an adequate cyber protection program. Many standards bodies have released proposals, and every profession from auditors to privacy officers propose their own certifications and methods of building secure data architecture. 

And yet, no court case has firmly recognized any set of commercial data protection standards, and no regulatory entity has consistently held with a set of required behaviors, technologies, and procedures. We navigate this ocean without sextant or North Star.

Practical factors influence this uncertain state of affairs. For example, how would a regulator establish a set of requirements to protect an ever-changing set of information, in an ever-changing infrastructure of databases, from an ever-changing world of threats and attacks? Choose one solution and it is obsolete by tomorrow. In addition, how can a government or trade organization require that the billion dollar companies in their midst use the same protective technologies and architectures as the tiniest companies in the same category? Resource availability is the key to a reasonable threat response, and not everyone has the same information to hide or the same amount of resources.

Into this mix, NIST, a creature of the Commerce Department, has been attempting for years to offer a lighthouse beam to help navigate these seas. On 12 February 2013, President Obama issued an Executive Order on improving critical infrastructure cybersecurity. As part of this Order, the Secretary of Commerce was instructed to ‘lead the development of a framework to reduce cyber risks to critical infrastructure,’ to include ‘a set of standards, methodologies, procedures, and processes that align policy, business and technological approaches to address cyber risks.’ The Framework was supposed to incorporate voluntary consensus standards and industry best practices where possible and be consistent with voluntary international standards where practical.

The first NIST Cybersecurity Framework responsive to this Directive was published in February 2014 aimed at helping critical infrastructure organizations - such as banks and electrical power grids - to manage cybersecurity risk. It has subsequently been adopted by organizations of all types in both government and the private sector. In December 2017, NIST released draft two of the Framework for Improving Critical Infrastructure Cybersecurity Version 1.1, which incorporates feedback received by NIST since the release of the first version. Framework Version 1.1 is largely consistent with the original version, with changes made around the edges in response to public comments. However, it would benefit any organization looking to NIST for cybersecurity structural assistance to understand both the revisions and the core moving parts of both versions of the NIST Framework. The Framework in both versions is intended to be neutral in regard to adopting specific technologies, but the new version specifically calls out its effect on information technology, cyber-physical systems and the Internet of Things.

NIST integrated comments from its solicitations as well as comments from attendees at the Cybersecurity Framework Workshop 2016 held at the NIST campus in Gaithersburg, Maryland. The updated text introduces the notion of cybersecurity measurement to bring objective evaluation techniques into the core of cyber security architecture. The new version also clarifies and expands the terms ‘authentication’ and ‘authorisation’ as key concepts for cyber protection of data. The authors also wanted the Framework to be useful in cyber supply chain risk management, so they developed a common vocabulary for organizations to understand each other when sharing cybersecurity information on any given project, including projects involving cloud vendors.

The new NIST draft includes a number of refinements, clarifications, and enhancements from the first draft, many of which are not substantive enough to comment on here. However, significant revisions to cybersecurity measurement language have been produced to emphasize the correlation of business results to cybersecurity risk management through multiple uses of measurement, especially for use in self-assessments. Self-assessment has always been an important part of any thoughtful cyber protection regime and using objective measurements to assess current conditions and make longitudinal comparisons can highlight improvements or degradation in cybersecurity over time. The new NIST draft takes this feature into account and encourages organizations to continue with precision self-testing and assessment if possible.

The 2017 draft’s new emphasis on supply chain cyber security also drives at filling in the vulnerability in the networks for many organizations - the system of vendors that connect to the organization’s computers. A company or government unit may have scores or hundreds of vendors that plug into the enterprise in some fashion. Famously, the devastating Target hack was initiated through a vendor portal when a heating and air conditioning vendor was hacked and brought its infection inside the Target firewalls. So clearly this problem is not simply academic. In Target’s case, a lack of network segmentation allowed the hackers to travel within the company’s system from the vendor portal all the way to the point of sale systems (electronic cash registers) without significant resistance or impediment. So NIST’s newest cybersecurity draft places a new emphasis on how a company manages its vendors, and how a company security department carefully brings vendors into the network without undue risk.

With the publication of US Federal policy, memorandum, and guidance (e.g., Executive Order 13800, OMB Memorandum M-17-25, and the draft NIST Inter-agency Report 8170) on Cybersecurity Framework use, federal applicability statements are no longer needed in the Framework publication, so the newest NIST Cybersecurity Framework removes the entire Federal Alignment Section that was in the former draft. This change is not significantly substantive, as it simply declines to address the federal applicability statements that are covered elsewhere. Similar changes can be seen in the new ‘How to Use the Framework’ section added in 2017.

However, the 2017 version of the Framework includes the same basic provisions that have proven to be useful to organizations in earlier editions. For example, the Framework Core demonstrates activities designed to achieve specific cybersecurity outcomes and includes examples of guidance on how an organization might reach those outcomes. Not a checklist, the Framework Core instead covers Functions, Categories, Subcategories and Informative References that all work together to structure a protection programme. These four elements add an object thought process that can be used for all types of organizations to design the optimal protection program.

Most importantly, the NIST Framework provides five core functions to be performed concurrently and continuously to form an operational culture focused on the constantly changing faces of cybersecurity risk. The core functions seem to be common sense concepts for anyone who has considered the nature of protecting information in a networked setting, and they serve as the tent poles for building security within the enterprise. Familiar to most cyber professionals, the core functions are:

• Identify - understand the business context, resources and related cybersecurity risks to prioritize efforts around business needs
  and management strategy;

• Protect - limit or contain potential cybersecurity events through access control, identity management, awareness and training, and protective technologies; Detect - implement appropriate activities to enable timely discovery of cyber security events, through continuous monitoring
  and detection processes;

• Respond - contain the impact of potential cybersecurity incidents through communications, response planning, mitigation and improvements; and

• Recover - maintain plans for resilience and restoring capabilities or services that were impaired due to a cybersecurity incident through recovery planning and targeted communications.

The NIST Framework is also built upon a profile to align the Functions, Categories, and Subcategories with the business requirements, risk tolerance, and resources of the organization. The Framework Profile helps organizations create a roadmap for reducing cybersecurity risk that is aligned with organizational goals considers regulatory requirements and industry best practices, and reflects risk management priorities. 

An organization can generate a Current Profile describing the present state of information security, and compare it to a Target Profile which describes the outcomes needed to achieve the desired cybersecurity risk management goals. The Framework’s Profiles support business requirements and help to communicate the levels of risk accepted by a company. Comparing the Current to the Target reveals gaps that must be addressed in the next cycle of security spend, and can undergird a roadmap to reach the required level of protection. Managing risk this way helps an organization to estimate the resources needed for next steps and to simplify the priorities.

NIST expects organizations to use the Cybersecurity Framework to manage risk within the network and the business. Of course, an enterprise must calculate and understand its risk tolerance to properly use the Framework. Should the organization mitigate a certain risk, or simply tolerate it? Can the company transfer the risk to another entity or simply avoid it in another manner? Using the Framework, an organization can educate itself and prioritize cybersecurity decisions, validating risk decisions and documenting the legitimacy of the reasons for selecting a certain technology, the level of risk tolerance, or the spending priorities.

While used by all types of organizations to build out risk structures, the NIST Cybersecurity Framework was created to assist in protecting critical infrastructure in the United States. The U.S. Patriot Act describes critical infrastructure as ‘systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters.’ 

As laymen, we generally include power generation, banking, roads, and utilities as the classic examples of critical infrastructure. Regardless of size or resource level, critical infrastructure custodians must consistently manage a cutting edge and solid level of cybersecurity, because the national security of the US depends on the reliable functioning of these entities and the networks they control. 

Like nearly all data security standards, the impact of the NIST Cybersecurity Framework has been influential rather than mandatory. While cyber professionals are often directed to such standards and framework documents as tools to help build a protective architecture as needed, the professionals generally have their pick of tools to apply. However, the recently released Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure from the Trump Administration can be read to require federal agencies to adhere to the NIST Cybersecurity Framework. The Order requires agency heads to present a risk management report to the OMB describing their plans to implement the Framework. Given this current mandate, it is possible that a similar requirement could be made of all major government contractors as well. Lawyers and security professionals should be closely watching future executive pronouncements in this area.

DCMS proposes draft Code of Practice for IoT developers

The UK’s Department for Digital, Culture, Media & Sport (‘DCMS’) published a report on 7 March 2018 entitled ‘Secure by Design: Improving the cybersecurity of consumer Internet of Things Report,’ which proposes a new voluntary draft Code of Practice for the manufacturers of consumer Internet of Things (‘IoT’) products and associated devices for implementation into development processes in order to improve the cybersecurity of the IoT. The Report heralds the opportunities presented by the IoT for citizens and the UK’s digital economy, however it states that many connected devices lack even basic cybersecurity provisions and that this, paired with the proliferation of the IoT, has led to risks to consumer security, privacy and safety, and threats to the wider economy through large-scale cyber attacks to large volumes of insecure IoT devices.

“My initial reaction to the Report is positive, the aims and suggested measures are laudable, well thought out and explained in plain succinct language - but on deeper reflection my reaction is that this voluntary Code of Practice would not assist where there was negligence or hostility on the part of the manufacturer, developer, retailer or service provider,” comments Dan Hyde, Partner at Penningtons. “The key takeaways are the intention to instill best practices and reduce the burden on the consumer by shifting the security responsibility to the manufacturer, service provider, app developer, and retailer. The intention is that cybersecurity should be embedded in the product from the point of design so that consumers are better protected. This, it is hoped, will be achieved through the 13 recommended measures of the Code of Practice.”

The 13 measures put forward in the draft Code of Practice include: that all IoT passwords must be unique and not resettable to factory settings; that all companies must provide a public point of contact for vulnerability disclosure; that all IoT software updates, stored credentials, security-sensitive communications and personal data must be secured; that software verification systems should be verified using secure boot mechanisms; that customers should be able to easily delete personal data and easily install and maintain their devices; and that input data via user interfaces and apps must be validated.

“The Report makes great play of the UK consumer being the best protected in the world, but unfortunately the IoT and the products we seek to design cybersecurity in to are global,” adds Hyde. “Consumers are purchasing products that are manufactured, developed or supported by actors in a plethora of countries. In order to control that process, we must accept two things: that a voluntary Code will be ignored or abused by some; and that a compulsory Code will be difficult to enforce in certain reluctant nations where regulation is lax and there is resistance to what is regarded as an alien jurisdiction/governance. There also needs to be a scheme of compulsory labeling, one that sets out the information that must be included on the product label. This way consumers would be better able to judge the design security of a product and it would potentially expose those products that do not meet best practice standards.”

The Report states that it is the Government’s preference for the manufacturers of IoT products to solve the cybersecurity problems identified, but “if this does not happen, and quickly, then we will look to make these guidelines compulsory through law.”