The dimensions of secure development life cycle

In my previous blog post, I discussed how to get more value from security assessments. The main takeaway was that assessments offer good feedback on security work, and it should be used not only to fix any issues, but also to improve the way security work is done. A security expert can give more perspective to this, and a single security expert for a few teams can work well in many environments.

When there are more teams, or security requirements are strict, a single security expert will be a bottleneck. This lowers the quality of security work, negating some of the benefits from a security expert. This will make security work difficult to manage and visibility to security work will suffer. Something more systematic is needed.

SDLC is a systematic way to ensure development produces good, predictable security. SDLC is known by different names, such as SDL (Microsoft), DFSEC (Nokia), CSDL (Cisco), SPLC (Adobe) and SSDL (SAP). They all share common goals and most of the means.

A secure development life cycle needs to address three different dimensions: Process, Culture and Capabilities. All dimensions must be considered for a successful SDLC implementation. Often a company focus on the dimension that is their strength and pays little attention to other dimensions. This leaves low-hanging fruits unpicked.

The SDLC process is the way organization creates a secure product. There are many approaches to the SDLC process and its standardization, such as IEC-62443-4-1. Typically, the process describes some necessary actions and some management practices for security. Most standards specify only a subset of the necessary actions, giving freedom in selecting the approaches in other areas based on risks and other factors.

A key process element is the practice of threat modeling. Many security requirements are abstract and non-functional. These requirements can be difficult to relate to the implementation and thus difficult to address in development. The threat modeling converts difficult security requirements into something that architects and developers can understand and work with. Even if security requirements have not been identified, threat modeling can be used as a starting point for the security work.

SDLC processes include many steps, such as requirement handling, security management, controls applied to dependencies, security testing, etc. Not all steps are equally critical, and importance of steps varies depending on the system to be implemented. It is a good idea to introduce additional steps gradually, as this allows sufficient attention to the execution details and gives early feedback on the progress. Different steps have different benefits and pain points, so the existing challenges in security and working culture should determine the implementation order of the steps.

A good SDLC process implementation can incrementally improve the development process. Aligning the SDLC with the development process reduces need for security specific processes and tools. Sometimes SDLC implementation effort will find that development practices are lacking in ways that harm not only security but also productivity. If development process does not work or development tooling is insufficient, security is probably not the most urgent problem to be solved. For example, unreliable requirement handling can lead to delaying changes unnecessarily too late in the development, increasing schedule pressure and creating need for rework.

A fundamental part of culture is trust: developers must feel that they are trusted and relied on for the security. Only developers can make software secure, and the role of security management and experts is to help them accomplish that. This can be difficult for the security expert if they believe that developers do not care about security. The more security experts criticize developer decisions afterwards, the less co-operative and efficient the development process will become. This is the main drawback of a purely assessment based security culture.

Developers must know they are allowed to use time for security. If developers believe time will not be allocated for identified security work, they will soon learn to actively ignore the security problems, as they are “unsolvable.” If developers have a channel to ask questions and get feedback from decision makers, it will help both sides to understand each other. Consequently, the personnel responsible of project sales and budget estimation must also realize the necessity of security work, and accommodate necessary time.

Developers must feel they are allowed and expected to consider security, even if their skills are not perfect. These attempts must be supported constructively, and help should be given as far as possible. Developer voices must not be ignored, and their thinking is important to understand.

Finally, security mistakes must not be punished, but taken as forward-looking opportunities. Finding (and creating a ticket for) a security problem is an achievement to be celebrated. Even incidents are learning opportunities: Where else could we have the same problem?

The security work requires many capabilities, including technologies, skills and support.

Important security technology decisions concern both an application itself, and tooling used to create, deploy and manage the application. Security is not the most important factor in any of these, but it must be able to influence decisions. New technical solutions and automation can often mitigate security problems while reducing the amount of security work.

The development team must master the key technologies used to make software secure. This also gives a natural learning path for developers, as at times they may need to break out of their comfort zone.

The team must have opportunities to improve their security skills. Good way to improve the skills is to bring a more experienced person to work together with the team. For example, threat modeling is best learned by doing it with a security expert. Continuing the security work within the team helps the team members learn from each other. Training may also be relevant, but the training must have relevance to work immediately at hand.

Sometimes development may face a security problem that it knows it cannot handle. Having an agreed way to ask for support ensures that the problem is not ignored. Support can be for example a security test creation, doing a cryptographic implementation, or evaluation of a threat that is difficult to understand.

Implementing SDLC requires deviation from past habits and attention to change management.

Different groups of people have different interests in the SDLC. For example, overall company risk reduction is unlikely to motivate developers, but developers care about having good development conditions. Typical motivations for SDLC work includes:

• Developers value autonomy and sense of achievement.
• Product owners and project managers want to have visibility and predictability for work.
• Sales need answers to customer concerns about security and visibility to security-related costs. As an upside sales may have new opportunities provided by better security.
• Management wants to reduce concerns due to risks and non-compliance.

The SDLC implementation in an organization should start with a pilot. The pilot should include early wins and establish SDLC as a credible tool. The pilot should not be trivial from security perspective, but picking a really tough target may also be risky. A pilot keeps the SDLC rooted to realities, so that it is not just paper exercise. In the first pilot, it is good to keep focus on the developers. When the developers are comfortable with some of the SDLC work, it will be a lot easier to build security management to guide the work.

A well-timed security training may support SDLC implementation when it gives confidence to do the SDLC tasks. But if new learning cannot be used immediately, training is likely to be wasted. Focusing on learning by doing is a practical approach, especially when gained skills can spread both within and between teams. Security and related tooling evolve continuously, and both developers and development processes must be able to deal with this.

Successful one-size-fits-all SDLC model does not exist. Most practices are universal, but have to be adapted to the target environment and development process. Wapice SDLC Coaching will help your organization to implement a SDLC model that unleashes the full security potential in your development. After defining the desired model, our coaching helps in its roll-out, training and implementation of technical parts. Work can also include improving the development process itself if it needs improvement. Coaching partnership typically spans over a longer period of time and results in an independent SDLC under your ownership.