Importance of software and security risks in DX

A car is a good example of how important software is. A car is said to consist of about 30,000 parts, and this figure has not changed much. On the other hand, 10 years ago the software installed in a car consisted of about 1 million lines of code, but now it has more than 100 million lines.

“Currently, software is evolving faster than hardware, and the concept of 'software first', in which software is developed first, is spreading. "Internalizing technology." This is the concept of in-house production of electronic components and semiconductors, and making use of new technologies as our own." (Maeno)

This way of thinking also applies to software development to promote DX. It is required to control software technology and use it as a weapon. On the other hand, security is also a very big issue, and if a serious security incident occurs, the service may be stopped or the service itself may be discontinued.

“In order to promote DX, it is necessary to internalize security and other aspects. One of the measures is efficiency.For example, in software development, if security risks are discovered at the requirements definition stage, it is said that the cost of fixing them will be 1/30th of that found after release." (Maeno)

セキュリティリスクの発見が早ければ早いほど、結果的にコスト削減につながります

In this way, we call "DevSecOps" the process of embedding security in a series of development cycles based on the concept of secure-by-design. From the perspective of DX, it is possible to simultaneously promote DX by internalizing software and eliminating factors that hinder DX by internalizing security.

Simultaneous Internalization of Software and Security Moves DevSecOps Closer to Reality

What DevSecOps should be and how it failed

The US CSA defines the “six pillars” of DevSecOps. This can be divided into “organization/culture” and “technology” perspectives. In terms of organization and culture, it is “shared responsibility,” “collaboration and integration,” “bridge compliance and development,” “measurement, monitoring, reporting, and action.” In technology, it is “practical implementation” and “automation.”

“Until now, the development department concentrated only on development and asked the security department when it was necessary to check or make a decision on security. In order to realize this, we will appoint security leaders called "Security Champions" in the development department. Then, the development department will make autonomous security decisions and instill a security culture.” (Maeno)

"Security Champions" need to play a flag and strengthen the security awareness of the development department.

However, even when DevSecOps is actually tackled, there are many cases where it does not go well. Maeno introduced real examples of failures in DevSecOps.

The first case is a company engaged in software package development and system integration business. He was positive, had a vision, and had a deep understanding of the promotion of DevSecOps. As a result, most of the security decisions that should be made by the development side were left to the security department, and the security department was unable to turn around.

The second is IT-related companies. The company turned to DevSecOps with the introduction of container security tools. However, there was an existing rule in the security department that "all vulnerabilities above a certain threshold must be dealt with." As a result of applying this rule to the development side as well, we had to deal with a large number of vulnerabilities discovered during the development stage, and the development speed was slower than before.

The third is companies that provide SaaS services. The company had already practiced DevOps, enabling rapid feature releases. As a listed company, we have a high level of security awareness, so we launched a department that looks at security from a cross-sectional perspective and considered promoting DevSecOps. However, since high-speed release was established as a culture, there was resistance from the development side, saying that incorporating security would slow down the release, and it was difficult to enforce the force of security.

"The essence of the problem lies in the relationship between the 'security knowledge', 'ability' and 'experience' possessed by the development team and the 'complexity and amount of security risks' that the development team faces. However, it is not something that can be easily changed.If we were to change it, we would have to reduce the complexity and volume of the latter." (Maeno)

Ways of thinking to overcome obstacles

To overcome these obstacles, we need to think back to "security risks." Risk can be broken down into probability of occurrence and degree of impact. Breaking this down into security elements, the probability of occurrence is threat and vulnerability, and the degree of impact is asset value. Of these, threats and asset values can be assumed in advance.

As a method of assuming threats, you can use the framework called "STRIDE" advocated by Microsoft. In addition, the asset value is determined by the security CIA, that is, confidentiality, integrity, and availability, to what extent the elements such as servers and containers that make up the application have a security impact on the asset. That's it.

Vulnerabilities also need to be visualized, but when trying to determine risks based on public indicators such as CVSS, a large number of high-level vulnerabilities such as Critical and High may occur. In fact, it is not appropriate to use only the CVSS basic score for risk determination. Therefore other conditions of vulnerability should be considered. For example, a vulnerability can only be exploited if there is exploit code to exploit it. Therefore, the presence or absence of attack code is one of the effective indicators.

Steps to Take to Realize DevSecOps

So what are the steps required to achieve DevSecOps? First, regarding threats and asset value, it is possible to identify "where" and "what kind of" threats exist in applications, and "how much" impact they will have, on a desk, thereby clarifying the location of risks. This is the idea of threat modeling.

Regarding vulnerabilities, it is important to know how to obtain information. For example, you can check what vulnerabilities have been disclosed and whether exploit codes exist on websites in Japan and overseas. However, gathering such information takes some time.

"At the Company, for example, we automatically triage the vulnerability information generated by the tool at the development stage by looking at the essential individual risks and by coloring the status of assets and the degree of impact on those assets. After trying it out, the 18 critical vulnerabilities detected by the vulnerability detection tool were reduced to 1 critical vulnerability to be addressed by automated triage. We are currently conducting these demonstrations with our customers.” (Maeno)

Finally, Maeno concludes by saying, "The DevSecOps approach is extremely important in order to internalize software technology and security. Elements other than tools are important for the realization of DevSecOps, and simply applying practices as they are will not work. The key is to reduce the complexity and volume of the software risks we face so that the development team can make correct understandings and decisions.”

Automate vulnerability triage to speed development and reduce security risks

▼People caption
Macnica Networks Corp.
DX Business Promotion Department DX Business Department 2nd Section Manager
Hideaki Maeno
(as of July 2021)