Understanding the NIST 800-160 SP 1.1 Draft

As cyber attacks gain traction and frequency, as well as intensity, the pressing need for stronger systems has exponentially grown. Soon, attacks like SolarWinds and Kaseya could pale in comparison to future incidents if systems are not proactively put in place today. While the executive order in May 2021 began to take baby steps in the right direction, merely sharing security data publicly wasn’t enough to make a large difference.

In the spirit of proper defense precautions prior to an attack, the NIST SP 800-160 Draft focuses on restructuring standards with the emphasis on engineering-driven perspectives. If systems are built in a way to withstand and defend against future attacks from day one, we create a process that is stronger. Built from the ground up, security is now the focus through the entire system life cycle.

5 Things to Know About the Proposed NIST SP 800-160 Update

The 207-page long document is certainly a lot to digest, so the Black Kite Research Team compiled a list of the most important takeaways./he

1. The NIST SP 800-160 Volume 1 Rev. 1 pushes cyber resilient systems

The National Institute of Standards and Technology (NIST)’s update to NIST 800-160 SP: Volume 1.1, responds to Biden’s executive order with new recommendations to secure the software supply chain with two overarching objectives:

Standardize the language-related software supply chain reporting
Attest to software use and development security procedures

The ultimate goal is clear: proactive risk management. It requires software engineers to pay attention to secure design principles and go through new layers of basic learning in their security training.

The draft has a clear tone of “systems engineering” and aims to provide a basis for that by creating a significant mindset shift within software engineering through the following standards:

Viewing security through a systems engineering perspective and thus firmly positioning Systems Security Engineering (SSE)
Emphasizing that the responsibility for engineering trustworthy secure systems is part of the whole development process
Aligning SSE practices with the risk language: loss of assets and the consequences thereof
Focusing on the assurance of the system’s security capability to achieve intended behaviors/outcomes and control adverse effects
More closely aligning systems security engineering work to international standards

2. The NIST SP 800-160 Volume 1 Rev. 1 promotes asset-based protection

Software engineers must begin to develop a risk and security mindset. These concepts are explained in Section 2 as preliminaries for security risk management, and provide examples of asset loss and how it applies to software engineering.

First, the asset is intended to be solidified, such as intangible assets (reputation, image, trust), data & information, and tangible assets (materials and infrastructure).

Loss forms can change depending on the asset and functionalities surrounding it. A loss can be either physical, such as the loss of hardware, or digital, such as possession of data by unauthorized third parties.

The correlation between an asset and a form of loss determines the level of protection needed. The publication delegates the “asset-based protection” concept to engineers with the following recommendation:

Adopt a proactive and reactive strategy in the form of a concept of secure function that addresses the spectrum of asset loss and associated consequences. This means proactively planning and designing to prevent the loss of an asset that you are not willing to accept, minimizing the consequences should such a loss occur, and positioning your team to reactively recover from the loss should it happen.

3. The NIST SP 800-160 Volume 1 Rev. 1 aims for adequate security over absolute security

The ultimate objective of the publication is to claim sufficient confidence or assurance that systems are adequately secure relative to all stakeholders’ objectives. Any system can be declared insecure by observation, but no observation allows one to declare an arbitrary system secure. Due to the limits of human certainty, the uncertainty that exists throughout the life cycle of every system, and the constraints of cost, schedule, performance, feasibility, and practicality, no system can give absolute security.

As a result, trade-offs should be made regularly between contradictory, competing, and conflicting needs and restrictions to provide adequate security. It has to be done in a risk management context, all incorporating the asset, the loss, and the risk. Naturally, it is the stakeholder or asset owner’s decision.

4. The NIST SP 800-160 Volume 1 Rev. 1 presents a framework for Systems Security Engineering

System security engineering activities are framed in three contexts in the updated publication standard: (1) the problem context, (2) the solution context, and (3) the trustworthiness context.

The problem context includes

Determining life cycle security concepts
Defining security objectives
Defining security requirements
Determining measures of success

The solution context includes

Defining the security aspects of the solution
Realizing the security aspects of the solution
Producing evidence for the security aspects of the solution

The trustworthiness context includes

Developing and maintaining the assurance case
Demonstrating that the assurance case is satisfied

5. The NIST SP 800-160 Volume 1 Rev. 1 reminds us that security is not a one-time job

Systems security engineering is defined as a lifecycle concept to ensure continuous trustworthiness. Security is not a one-time job achieved in an acquisition or the beginning of development. Maintaining security is doing exactly that: continuous maintenance.

Bugs are common in software updates, and there have even been times when fixes to security issues have been released with new bugs. Therefore, trustworthiness and security consist of lifecycle processes from the conceptual level all the way down to retirement.

The standard is published in draft mode, and closed to comments as of February 25. The time is now to begin to restructure the way we approach the system life cycle, bringing cyber resilience into the equation every step of the way. While it remains a full team effort, responsibility for engineering trustworthy secure systems now rests within the scope of software and systems security engineering.