Mar 11, 2022

※日本語版はこちら（For the Japanese version, please refer to here.）

This blog focuses on the theme of how to work on secure development by reference to the NIST SP800-218 Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities[1].

Secure development is often conducted based on the Shift-Left approach[2], which suggests that implementing security measures in the early stages of the software development lifecycle can lead to cost savings in various aspects. However, in actual secure development scenes, I guess it might be proceeded only with little forethought such as “as long as we do this much, it should be fine for now.”

Through this article, let’s think about how we should work on secure development by reference to SSDF.

What is SSDF?

As its name implies, SSDF is a framework which focuses on secure software development. The efforts necessary for the secure software development are summarized as Practices, as shown in Figure-1 and Figure-2. These Practices are compiled with reference to documents listed in References. Furthermore, Tasks and Notional Implementation Examples which give more details to Practices are also outlined.
For instance, one of the Practices is “Define Security Requirements for Software Development” and Notional Implementation Examples describes “Review and update security requirements at least annually” as a implementation example of how to carry out this Practice.
Like in this way, those who work on secure development can consider and create their own requirements for secure software development by referring to SSDF Practices as well as the Tasks, and Notional Implementation Examples.

Premise of Secure Development Concept

Here is a quote from SSDF. I personally recognized this part is the key point in considering the ideal concept of secure development.

The risk-based approach is a method of deciding security measures on the basis of risks. As shown in Figure-3, this refers to determining the response method based on two axes: the probability of risk occurrence and magnitude of damage in the event of risk occurrence. For a software development project, once the response method for the risks shown in Figure-3 is determined, the secure software development method for the project will be determined. Therefore, the secure development concept is premised on a risk-based approach.

Next, I consider how to interpret the statement "the intention of SSDF is not to create a checklist to follow". Let’s say one organization created a checklist in the form of minimum security measures (baselines) to be addressed using SSDF as a reference. In this case, it could be said it is the result of the planning and implementation of a risk-based approach. I initially thought that the content of the above quotation might be contradictory. However, while there is a subtle difference, the intention of SSDF is to be the basis for the risk-based approach to secure software development. The above quotation would indicate that a checklist may be created as part of the process of a secure development, but it is not mandatory or the main intention. In other words, I came to the idea that the sentence conveys the caution and insistence on not confusing the means with the ends, and the importance of the premise of a risk-based approach.

Approach to Secure Development

Now, under the premise of this risk-based approach, how should we approach secure development? It is practically difficult for practitioners to adopt the risk-based approach from scratch without any development concepts or baseline every time a development project arises. Therefore, in practice, organizations are likely to establish secure development concepts, policies, and rules as baselines. Then, practitioners on-site will decide on the necessary secure development approach for the development project based on risks and proceed. As an example, an internal security department creates tools like the one above, and practitioners adjust and optimize security measures depending on the characteristics (risks) of the development project.

Baselines can be created by scoping and tailoring. Scoping is the process of cutting out the necessary parts for the organization from the security requirements in a framework such as SSDF, while tailoring is the process of adjusting the content of the cut parts to fit the organization’s environment. However, since it is preferred to reinforce the versatility of baselines to make it applicable to any development project, the level of abstraction in the content may be high. It is the role of the practitioners to incorporate this into specific requirements according to the characteristics of the development project and to execute it.

Summary

As shown in SSDF as a reference, the basic idea of secure software development is to identify the risks in the development project, determine the approach, and then work on those approaches. However, in the field of development project, there may be many situations where the consideration and implementation of security measures themselves (the means) tends to be prioritized. And it often leads to the neglect of proper determination and implementation of risk response, which is the intention of secure development.

When working on secure development, an approach that involves implementing some kind of security measures (the means) without going through the process of identifying risks and deciding on a response method is a “stopgap response” which is not appropriate as a risk-based approach. However, there may be such cases in reality. There are various reasons behind this, but one factor could be the lack of understanding of risk-based approach that I explained in this blog.

I have summarized the concept of approaching secure development based on SSDF in this blog. Risk-based approaches, baselines, scoping, and tailoring can be applied to all situations involving of security, not just secure development. I hope this blog will bring you more interests in the concept of security, be some help to everyone, and contribute to a safe and secure society.

References

Read More at NEC Security Blog