A Look Inside NIST’s “Dramatically Reducing Security Vulnerabilities” Report

1. NIST’s Paul Black is one of the authors of the Dramatically Reducing Security Vulnerabilities (DRSV) report.

The technical approaches presented in the report are divided into several categories: Formal Methods, System Level Security, Additive Software Analysis, Software Development Frameworks, and Moving Target Defenses (MTD) and Automatic Software Diversity. The report also features a Measures and Metrics section and a Non-technical Approaches and Summary section. It’s definitely not light reading, but well worth the effort.

What’s also useful is to be aware of what the report doesn’t cover. This includes issues such as operator errors, malware or malfeasance, functional bugs, hardware problems, and the development process. Furthermore, it’s neither an encyclopedia of techniques, nor a list of best/recommended practices. Some of that information can be found in the Common Weakness Enumeration (CWE).

2. Reasoning can get hard as the problem becomes more complex. For example, adding two liquids together may result in the combined volume but the new temperature will be dependent upon the types of liquids involved. This example does not address what chemical reactions might be associated with mixing the liquids.

Paul gave an interesting example of why it’s hard to reason about complex problems like security (Fig. 2). The example starts with two containers of liquid. Add them together and the volume should be the sum of the two, if the liquids are the same. What about the temperature of the combination, though? The answer to that is a bit more complex, and becomes even more complex if the two liquids are different and have different specific heats. And, that’s assuming no chemical reaction is involved. He didn’t even get to the opacity of the system.

Security mirrors this scenario. It might seem simple at the start, but little things can make the job much more complex.

Getting Down to the Programming

Formal methods will be familiar to those involved in safe and secure software development for applications like military and aviation, which employ standards like DO-178/C. Formal methods are often associated with model-based development using tools like the Object Management Group’s (OMG) Unified Modeling Language (UML) or programming languages like SPARK with its Ada 2012 contract support. These tools may involve model checkers and SAT solvers to prove correctness-by-construction.

NIST recognized that cyber retrofitting of all existing code is impractical, so it requires approaches like identifying key components and then hardening them. This could involve recoding or recompilation using more sophisticated tools and error checking.

3. Virtualization (left) provides hardware isolation of operating systems but it adds overhead compared to Linux containers (right) that share a host operating system (OS).

Embedded developers will be familiar with some of the System Level Security tools such as virtualization and Linux containers (Fig. 3). Hypervisors and virtualization are becoming common in embedded applications, but containers are more popular on enterprise and cloud platforms. Containers have less overhead, which allows for more applications to run using fewer resources. An even lighter-weight approach is called microservice or serverless computing—it initiates functions based on events. All three have levels of isolation and security. It’s all a matter of how they’re implemented.

Additive Software Analysis (Fig. 4) is a “comprehensive approach for addressing impediments to the use of multiple, advanced software checking tools. The goal of additive software analysis is to foster a continuing accumulation of highly usable analysis modules that add together over time to continually improve the state of the practice in deployed software analysis.”

4. A standardized interchange API and data exchange format will allow different checkers and analyzers to work together on applications.

The Software Development Frameworks section is especially important these days, with the Internet of Things (IoT) bringing a plethora of frameworks to the fore. Frameworks are rapidly being adopted, which increases the amount of code involved in an application, and in turn increases the attack surface of a system. IoT isn’t the only source of frameworks that might be utilized in a system these days. Language, communication, and operating-system frameworks can also come into play. Composition could cause conflicts, though (Fig. 5).

5. Composition using multiple frameworks can cause conflicts.

The Moving Target Defenses (MTD) and Automatic Software Diversity approach “is a collection of techniques to automatically vary software’s detailed structures and properties such that an attacker has much greater difficulty exploiting any weakness.” One example is random placement of objects within memory or data structure randomization within records, making it more difficult for an attacker to bypass access limits to examine this information. Some of this can be done automatically by the tools or support code involved.

It doesn’t take a degree in security to understand the NIST report, which is under 60 pages. Many of the ideas will be common knowledge, but the collection is worth understanding as a whole. The references are what really make it very useful.

The DRSV report is a good starting point for expanding your understanding of security. It’s free, so why not take advantage of it?