Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Billington 4th Annual Cybersecurity Summit Keynote Remarks

Thank you very much. Good morning, everybody.

I understand you've had a busy morning already. It's a delight to be here. Tom, thanks for the invitation. It's always great to attend one of your events, because you bring together such a great group.

I want to make a few remarks today mostly on the Executive Order process. But before I start with that, let me step back a little bit.

This may sound a little bit odd coming from the NIST guy, the technology guy, but when you think of the Internet, you may be tempted to think of it in terms of its underlying technology. It's built on a powerful engine of communication and computational technology. But if you really think about what's happening in our society and the world around us, the digital economy that it's enabling, more than anything, is built on trust. It is predicated on, for business success and for consumers, on the understanding that if they provide data, it will be used correctly, that business-sensitive data will be protected, that e-commerce transactions are reliable and trustworthy, and that even government users who use digital technology and the Internet will meet their mission needs and still protect the public trust. So cybersecurity, of course, is a fundamental building block of ensuring that trust. It's what enables us to ensure that the digital information has the required confidentiality, integrity, and availability to meet the needs that we are after.

So, ensuring that trust is actually everyone's responsibility. It goes all the way from every end user on the system and includes the companies that develop, own, and use these technologies. It depends on the community—the multi-stakeholder organizations that govern and manage the Internet, that set the standards, that shape this technology. And it certainly includes the role of governments as well--governments around the world. And it certainly, within the governments, includes law enforcement and national security organizations, because there are those that can, will, and do seek to use this technology to do us harm.

So in that broad, sort of everyone-on-deck role, what does NIST do?

NIST, as many of you know, is part of the U.S. Department of Commerce. It is probably the nation's oldest national laboratory; going back in 1901. It was known until the late 1980s as the National Bureau of Standards. And it really contributes to this enterprise in three ways.

First, as the nation's measurement laboratory, we are responsible for providing the underlying science and engineering that underpins our measurement system. So in the context of cybersecurity, we contribute our science, engineering, and technical support to how do you measure success and look at cybersecurity performance.

We also have two other roles that are standards related. The first is under the Federal Information Security Management Act, or FISMA. Under FISMA, NIST has the responsibility to issue what are called Federal Information Processing Standards, or FIPS. These are mandatory standards for all non-national security federal IT systems. The corresponding role to protect national security systems is given to the National Security Agency. So within government use, NIST actually has a standards-setting role.

And one of the things I want to emphasize to you is this is very unusual. In fact, this is one of the only areas that NIST is actually a standards-setting body. This is not widely understood. In the United States, almost all standards are set by the private sector. And in fact, by law, federal agencies look to private-sector standards-setting bodies for their own use.

So the third role that NIST contributes is actually a much more common role, which is, we support standards-setting organizations; we provide that technical support and consulting, and we act as an interface between federal agencies and those standards-setting bodies. I'll come back and touch on that.

So in the context of these three roles, let me touch on something that's been in the newspapers a lot over the last couple of weeks in the context of the leaks.

First of all, you can see by our mission, NIST is designed to collaborate. It's a key part of our role. And that includes collaboration with every technical contributor to the work. We are part of the scientific research community, and to carry that out, we have to be a full and vibrant part of that.

So this means, yes, we collaborate with the National Security Agency, for two reasons. One, they are a deep reservoir of technical know-how in cybersecurity activities. But also, they have this unique parallel role to ours in protecting federal systems. So there is not a problem with NIST collaborating with NSA.

But NIST's role is to provide the technical evaluation of methods and practices. And when NIST says that something is a sound practice or a good practice, that conclusion should be based on the technical merits alone, and nothing else. That integrity and process is critical to our mission.

To support that integrity, we must be transparent. We have to operate and seek full peer review, and we are fully committed to doing that. So let me be clear: NIST is fully committed to the highest levels of scientific and technical quality and integrity. This is in our bone marrow at NIST. And that includes supporting the strongest possible encryption cybersecurity methods. And I am completely confident that our integrity is fully intact. It is sound.

But in light of all the concerns and press, we are redoubling our efforts to look at our transparency and make sure that we operate so openly that everyone else can be as confident with our integrity and process as we are.

And so in that light, if we find anything and there is any question about whether any given technical document or standard doesn't meet this high quality of standard that we have internally, we will do what we've done: we will reopen it for public comment and address it in an open and transparent way. Because after all, if we are to contribute to this dialogue of securing and providing trust in the Internet, everyone has to be confident that our technical work stands on its own merits.

Let me also, then, talk a little bit about the standards-setting processes, and in particular, one that has been also much talked about. And that, of course, is the Executive Order to look at cybersecurity practices to protect critical infrastructure.

This is an interesting role, because if you're a cybersecurity person, you may see this as a new role for NIST, because you're probably thinking of us in a FISMA context. If you're in NIST, this is actually a traditional role for NIST, because what the Executive Order 13636 called upon me to do, it directed me, was to lead an effort, in collaboration with the private sector, to develop a framework of practices that would be protective of critical infrastructure.

The Order directed us to work with industry, academia, and other government agencies to develop a voluntary framework of standards. In fact, specifically the EO states, "It is the policy of the United States to ensure the security and resilience of the nation's critical infrastructure and to maintain a cyber environment that encourages efficiency, innovation, and economic prosperity, while promoting safety, security, and business confidentiality, privacy, and civil liberties. And we can achieve these goals through a partnership with the owners and operators of critical infrastructure to improve cybersecurity, information sharing, and collaboratively develop and implement risk-based standards." It was quite clear. 

With regards to me, the Executive Order directed to me to develop a cybersecurity framework that shall include a set of standards, methodologies, procedures and processes that align—this is quite important—align policy, business, and technological approaches to address cyber risks.

So what I'm going to do is give you a quick update on where we've been on this 8-month journey on the cybersecurity framework process and what happens next. So immediately after the President signed the Executive Order last February, NIST issued a Request for Information—a public call for input. That produced 245 comments from individuals; companies, large and small; federal agencies and laboratories; local governments; utilities; critical infrastructure. And those comments helped us establish the starting point. For example, we heard it was important for the framework to be flexible enough to work with companies of all sizes. We heard that the framework had to be scalable in the global marketplace, because these companies were operating and selling goods and services around the world, and we should keep in mind that it will have a global impact.

Industry told us that the framework should be risk based and not prescriptive, not compliance based. It should leverage existing approaches, standards, and best practices to avoid duplication and new conflicting requirements.

And industry also stressed the importance of senior management engagement.  This could not be confined to the CISOs and CIOs, this had to be integrated in the actual practice of running an organization. 

And those responses led us to start the framework and then build on that input with a series of workshops. And we've been really pleased, in fact delighted, with the amount of input and participation we've received. I will tell you this. It would not be successful if that had not happened.

So far more than 1500 people have attended our workshops in person—many of you, I know, have. I want to thank you for that. Another 2,000 have participated through webinars and through online streaming of workshops or through online participation.

We've heard many different points of view, and they have all been considered in developing the draft. In fact, at each point in the process, we have openly published the current state of the draft, and it served as a building block so that the development of the effort would build on the previous conversation. So there are no secrets about this in the framework either.

Today, the drafting phase that was called for in the executive order is, essentially, complete. The NIST team has completed their work reflecting the last input from the Dallas workshop, and it will shortly go into a clearance process in time for a release that is called for in the executive order.

So let me talk about what happens after that preliminary framework goes out, because two things will happen. First of all, it goes out for public comment. And second of all, we need to begin talking about putting it into use. So let me talk about each of those steps.

First of all, what is the framework, and what does it look like?

The framework, basically, does exactly what the executive order says: it lays out a series of practices and methods and so forth, and it is designed for adoption. Because in the framework, it was this collection of practices that, if put into practice, would be protective of our nation's critical infrastructure. And it has to have this holistic view and this integrated-with-business view that we heard in the public comments.

There are really two major moving parts to the framework. One is a collection of existing standards and practices. You will recognize many of them. They are there by reference, and they are reflecting all of the input. And the second major element is a structure—a framework in the true sense of the word that organizes those practices and provides really a set of tools that support the use and adoption of those standards and practices.

So what does the structure look like?

Well really, there are three structures in the framework. The first is an organization by type of activity. There are five functional categories in the framework: identify, protect, detect, respond, and recover. And various best practices in each of those functional categories are indicated. Furthermore, each of those functions is further subdivided into categories of actions that can be selected and used to implement those functions.

The other organizational premise in the framework is regarding implementation maturity. It identifies a set of implementation tiers. Now these are a way of looking at the maturity of adoption from a early adopter, low-maturity organization that may be very rule-based, to a high-maturity organization that has integrated risk management in all levels. In other words, you could think of it as analogous to a cultural approach much like we've seen in safety management and other risk-management activities within business. You go from a compliance, rule-based approach to a fully integrated risk management culture within the organization. And the framework supports that.

And finally, the framework includes profiles, which is a way, a tool for companies and organizations to assess themselves and identify ways to move either up the tiers or to address weaknesses in the implementation levels.

A key concept to the framework is that there is no threat proofing. There is no magic bullet here. This is not about eliminating the problem, this is about managing it.

What is different in the framework from previous approaches? It re-emphasizes the concept of risk management, and it points out very emphatically that that risk management must be integrated throughout the organization, from the C suite all the way down to everybody in the organization. And it also points out that this really is a continuing improvement process. This isn't a "do something and you're done," this is about basically continuing to self improve all the time and moving up that maturity so it becomes baked into the way the organization operates.

As the executive order points out, the framework, no matter how good it is, if it only exists on paper, we haven't done our job. It has to be put into practice, and the adoptive phase begins really now, and it has three major parts.

First, organizations have to adopt it within themselves. Businesses and organizations have to take these practices, map it into their own situation, find out where they're at, use the profiles, and put it into practice. This can't simply live on the shelf in the IT security department. It is vital that it permeate all levels of the organization, and in principle, we are quite focused on engaging the business leadership and C suite executives who have an overall responsibility in these companies, and a large part of our effort now will focus on outreach of that adoption.

The second thing the framework has to do is it has to be integrated into the marketplace. In other words, good cybersecurity really has to be aligned with good business. This means that the framework has to also be integrated into business-to-business transactions—contracts, service-level agreements. It has to look at customers' engagement.

It also means that we have to look a global adoption. Our framework should be integrated into worldwide standards practices so it is compatible with activities around the world.

This may include conformity assessment vehicles, things like conformance testing or certification or other types of product identification so that businesses understand and can identify conforming practices in the market.

And it also includes the discussion that many of you heard about, of course, which is the incentives. In other words, what are the barriers to adoption? Where are the places where the market doesn't behave, and how do we promote that?

And finally, the framework itself needs to evolve based on input from early adopters. In other words, if this framework process we just did over the last eight months is a once through and we're done, we also failed. The technology is too dynamic.

I don't believe the framework is perfect. We expect companies that adopt it and have put it into use are going to identify places where it makes no sense, it has to be adjusted, where there are gaps that have to be addressed. And so we have to now operationalize this collaboration we've built and turn the framework into a continuous process.

So right away, we need to start thinking about framework 2.0. And those early adopters, those companies and organizations that take up the challenge and start putting this into use, are going to play a key role, because they are going to shape the frame work, and I think, will shape and drive the governance of that framework process. This has to be an industry-led effort.

Now of course, you're not alone if you're adopting. The executive order calls for a whole set of actions in support of this. It directed all federal agencies to look at incentives that could include a legislative agenda to address key barriers. The executive order directed regulatory agencies that are already regulating certain parts of critical infrastructure to evaluate their practices. And the executive order directed DHS to develop a program to support volunteering adoption. So, the support system is there.

Let me just finish by saying we are at the end, but we're only at the end of the beginning. So really, this is much closer to the beginning of this process, and now we are really focused on taking what has been a remarkable effort and translating it and driving it into practice.

For me, the litmus test of success is going to be the extent to which this framework becomes integrated with the way we operate--it just becomes part of doing business. It's not going to end with a splash, it's going to end with being baked in. And for that to work, all of our work in trying to align with business practice is going to be a key ingredient. I know many of you contributed very directly in this effort, and I want to thank you for that, and I look forward to the next phase.

With that, let me conclude and see if there are any questions.

Thank you.

Created November 4, 2013, Updated October 4, 2016