Part 5 of 5 - Attaining a High Level of SDLC Maturity

In order to achieve a high-level of SDLC maturity, an organization needs to define a set of security engineering activities, processes and policies that can be layered on top of whatever development process currently in place. These can be applied in waterfall, iterative, agile or any type of development process. They key is to perform the correct activities and employ the right checkpoints at the right points in your process.

A successful approach to security engineering involves explicit security objectives (aka requirements), a good understanding of the threats to your application, and an iterative approach that allows you to bake security in early and improve security over time rather than trying to add it in at the end.

It can be useful to think of security as yet another aspect of software quality. Just like you think about performance, reliability and usability during software design and implementation, you should be thinking about security at the same time. Security decision may require trade-offs between acceptable risk vs. performance and usability; thus, it makes sense to consider these qualities holistically so that you can make reasonable decisions in context.

Below are five levels of AppSec Maturity (derived from CMMI) and that were included in our joint Ponemon research study on Application Security Maturity. As your organization’s program evolves, consider what activities, skills or best practices you need to adopt in order to get to the next level.

Level 1 (Initial)

Lack of discipline and maturity in the SDLC; no focus on security

Level 2 (Repeatable)

Disciplined and repeatable SDLC but security is purely reactive

Security is addressed by patching issues based on penetration testing results and public incidents

Level 3 (Defined)

Security in the SDLC is standardized and defined

Corporate application security policies are defined

Formal security requirements are defined during the development process

Secure coding standards are in place and the code is reviewed to these standards

Security testing is part of the normal testing cycle

Level 4 (Managed)

Predictable process that is measurable and managed

Threat modeling is used to assess and prioritize risk in each phase of the SDLC

Secure architecture standards are in place and the design is reviewed to these standards

Development teams and the code they produce are measured against compliance security requirements as well as secure architecture and coding standards

Application security risk is measured and well understood across the application portfolio

Third party security audits are conducted for all high-risk applications

Level 5 (Optimized)

Continuously improving process that is mature and optimizing

Risk metrics are used to guide application security decision making

Vulnerability discoveries are used to update requirements and standards

Security Innovation offers a free Secure SDLC Self-Assessment questionnaire that consists of twenty questions around tools usage, development team knowledge and security best practices. Upon completion, you will see a plot of where your organization resides on our Application Security Maturity (ASM) graph that consists of three common categories:

Panic scramble

Pit of despair

Security as a business enabler

After the survey you can review recommendations for improvement and you will have the opportunity to view and print all of your answers.

Comments

You can follow this conversation by subscribing to the comment feed for this post.

"Security decision may require trade-offs between acceptable risk vs. performance and usability; thus, it makes sense to consider these qualities holistically so that you can make reasonable decisions in context."

Excellent point. It's hard to have 100% of three or four things at the same time, so you need to understand what you are getting and what you are giving as you go through the development process.