The National Institute of Standards and Technology is developing new cybersecurity standards based on the same principles engineers use to build bridges and jetliners.
NIST Fellow Ron Ross, in an interview with Information Security Media Group (transcript below), says the principles employed by engineers can be used to communicate to all stakeholders the goals for creating new infrastructures. "By integrating the security-engineering processes into those systems-engineering processes, and software engineering, we are now being able to bridge that communications gap between these two disciplines," Ross says.
The draft guidance, NIST Special Publication 800-160, Systems Security Engineering: An Integrated Approach to Building Trustworthy Resilient Systems, recommends steps to help develop a more defensible information technology infrastructure, including the component products, systems and services that constitute the infrastructure.
The NIST computer scientist says the systems security engineering discipline is applicable to each stage of the system life cycle.
In the interview, Ross explains the:
- Genesis of the guidance;
- Role of systems security engineers; and
- Reasons why IT security practitioners should emulate engineers.
NIST is seeking public comments on the draft publication. Comments should be sent by July 11 to firstname.lastname@example.org.
Ross, lead author of NIST's authoritative guidance on risk assessment and risk management, specializes in security requirements definition, security testing and evaluation and information assurance. He leads NIST's Federal Information Security Management Act Implementation Project, which includes the development of key security standards and guidelines for the federal government and critical information infrastructure.
Genesis of Guidance
ERIC CHABROW: What's the genesis of this guidance? What's happening in the information security community to require this new special publication?
RON ROSS: We've been working on this special publication, 800-160, for a little over two years now and it's not something that is brand new. We've been trying to come up with a publication that could define the best practices in cybersecurity which relate to building these more trustworthy products and systems that our customers use. We've been doing an awful lot in cybersecurity over the past decade. We have all the special publications, unified framework, security controls and risk assessments. We've also talked about building security in and baking it in for a long time. And I think what 800-160 does is it gives people a disciplined and structured process to integrate cybersecurity concepts and principles into the development process.
As we build products and systems, we can ensure that best practices are being attended to every step of the way in the life cycle. That's something that we haven't done before in the NIST guidance, and we wanted to base it on international standards. So we started, with the IEEE and ISO systems, software engineering standard 15288 and we infused into every one of the technical processes across the entire lifecycle the best practices with regard to security. This is the way to ensure that when engineers are building systems, they will now have appropriate guidance on what activities and tasks to carry out to ensure that the security is considered early and all the way through the lifecycle.
CHABROW: What is it about engineering principles that make them a model for cybersecurity?
ROSS: When you try to talk about baking security in or building it in, we can't just have security people talking to themselves. In other words, we can define all the guidelines, controls and the best practices, but if we're not communicating security to the mainstream mission and business processes within the average organization today, then we're not going to be able to communicate those best practices to the people that can make a difference. If I'm an enterprise architect or a security engineer, I've got to understand what security is all about and how I can integrate the requirements into the mainstream organizational processes that already exist and have been around for decades.
We speak a different language than enterprise architects and acquisition folks. We speak a different language than a system engineers. One of the goals with 800-160 is that by integrating the security engineering processes into those systems engineering processes, we are now able to bridge that communication gap between these two disciplines. By putting them in the same room, by having that communication, systems and software engineers now will understand more about what good system security engineering is all about. We will also know as security professionals what some of the tradeoffs are that we have to make as that system is developed. You can't get everything that you want any place, whether it's the functional side or the security side. It's all about the stakeholder requirements, their protection needs, what kinds of things you can afford to do, and how you manage risk long-term. And so understanding all of these different factors as they relate to security is part of that tradeoff analysis, that's what 160 is intended to do.
CHABROW: Who is the target audience for this guidance?
ROSS: The first target audience is the security professionals who are actually carrying out system security engineering work, because this is going to be their go-to document as they try to work with the engineers and infuse best practices into the build process. But the secondary audience is very, very broad. It includes everybody from the C-Suite all the way down to the acquisition folks, the people on the operational side. When you look at the 11 technical processes in the 160 document we start with stakeholder and security requirements, definition of protection needs. We analyze the requirements. We go through a development and design process. There is a validation and verification set of processes and eventually you get into the operations and sustainment part which is where the operators live and actually use the technologies that have been built. In some sense we're looking at every stakeholder in every part of the system development lifecycle; the people who have the requirements that go into those systems; the people who have to test and evaluate to make sure they've met the specification; the operators; sustainers; the people who actually bring the system to the disposal point. So it's a very wide swath of customers here who we were trying to address.
Announcing the Guidance
CHABROW: When and where are you announcing this?
ROSS: The University of Minnesota, the College of Science and Engineering, and within the college there is a group called the Technology Leadership Institute. This is the home where the computer scientists live. You have the folks here who can go into chapter two and the processes and can actually understand what they are reading and then apply it. Not only as they learn through the educational system here at the University, it's all across the country. The point is that we need some specialized skills to actually effect how trusted software is built. It's our universities who are producing the skills and the individuals who are going to have those skills, and then industry will employ those individuals as they go out and innovate all the great technology that our industry produces.
CHABROW: What kind of specialized skills may be needed for organizations that may not be there now?
ROSS: Certainly having a job description of the system security engineer. We define that in the publication and the types of skills that are needed and the system security engineer typically is going to be someone who understands how to build either hardware or software. They have a background in computer science, computer engineering. It's the people who can get under the hood and understand some of the subtleties of how software, hardware and firmware are built. We have lots of vulnerabilities that crop up, the most recent one was the Heartbleed vulnerability. These vulnerabilities are sometimes very subtle. When you're designing a protocol or an application, you want the software to do what it's supposed to do, but you're also are concerned with unintended side effects. In the case of things like Heartbleed, where the vulnerability has no intended side effect, there were some bad things that happened when certain conditions occurred and it ended up being a fairly significant vulnerability. So even things like the choice of what computer programming language you select to develop your protocol or your applications. Some languages have what we call strong typing. They're inherently better languages to produce more trusted software, and the development process that you go through, everything from the modular design of software and some of the software engineering techniques that have been around for quite some time. Those are the things that you would get in the engineering and computer science curriculums around the country that are producing the skills that we need to have to be good security engineers.
Final Published Version
CHABROW: What happens next with the draft and when will the final version be published?
ROSS: We're doing this in this four phases. And the reason we're doing it in four phases is that we didn't want to overwhelm our customers with too much information at one time. So we started with the IEEE ISO 15288 standard and focused initially on the first 11 processes, which are the technical processes of lifecycle. Phase two of the document will be filling out all of the appendixes in the back. There's a few there that are actually in the current release in phase one, but there are several appendixes that are going to be rolled out during the summer. That would be things like the acquisition process. We're going to show that all of our publications in the NIST FISMA suite of publications, the risk management framework, the security controls, are complimentary to the systems engineering process. Then you're going to see, there's an actual DOD acquisition process appendix that is going to be put in.
Toward the end of the summer into the fall, you're going to see the last of the 14 non-technical processes rolled out. These are things like risk management, quality assurance process, configuration management, all of the non-technical processes to find in the ISO IEEE Standard will be completed in phase three. So then you'll have 25 of the processes that the engineers use. Security [will be] infused into every one of those processes. And then phase four is a recognition that as we're building to the current 2008 version of the IEEE and ISO Standard, there's also a 2013 version that's being developed. It's out now in a draft, and internationally they are validating on that standard now. So when that 15288 standard gets finalized for the end of 2014, whatever changes they've made to the systems engineering standard, we are going to go back and retrofit into the NIST 800-160. So if they change any of the processes, we're going to make sure that our 160 document aligns exactly with that international standard. That's really important to make sure we stand on well-established systems and software engineering standards that are being adopted around the world, because our industry works in a global marketplace. We want to make sure that we're not reinventing the wheel and we're actually adding value to things that have been already established.
CHABROW: How does the organization feel about this new development?
ROSS: It's a very exciting time. This has been something we've worked really hard on for the last two years or so, and we're very proud of the work. And as always, we look to our customers now to give us feedback. We can build these publications in a vacuum, but this is why we're out in Minnesota today. We want to make sure our customers take a look and give us feedback. As we go through the different phases, by the end of 2014 we hope to finalize the 800-160 and then we'll move on to our next challenge.