In this blog post, i’ll answer the question: What are the expectations of Secure Development Lifecycle at an enterprise level, and how can an application security program be built and implemented to meet these expectations?

It’s been a number of years since we started promoting the Secure Development Lifecycle, which suggests that security activities should be performed at each step of the SDLC. These activities being:

• Security requirements analysis
• Threat modeling
• Security architecture reviews
• Code reviews
• Penetration testing, etc.

Proactively performing these activities enables us to produce secure software most efficiently and at lower costs.

But, things are easier said than done. No two software systems in an organization are the same, and performing all these activities and implementing each and every control in the security book may turn out to be overkill in some situations, while causing unnecessary shake-up in the project cost.

Furthermore, when we are talking about introducing SDLC and associated activities at an enterprise level, we are looking at some investment from the management; and whenever there is an investment, there are expectations. These expectations can be summarized as:

• Reduced risk at low operational cost
• Compliance with regulatory requirements
• Measurable return on investment
• Security culture within the organization

Hence, this enterprise-wide rollout of Secure Development Lifecycle needs to be considered as a program–an application security program with defined objectives and outcomes.

So, where do we start?

What are the various steps we need to follow to build an application security program?

As we all know, there are no two organizations that are exactly the same.

There are no two software development teams that are exactly the same.

And there are no two applications that are exactly the same.

Hence…

There is no silver bullet, no one, boxed product that can be the solution.

The approach that we have seen to work the best is a 3-step approach. The 3 steps being:

Assess

In the assessment phase, we measure the current security maturity state of the organization, which includes assessing:

• Where we are today from a software security perspective
• Where we need to be
• The strengths we can build upon and weaknesses we need to overcome

Design

The intent of this phase is to extract material from first phase, mix with industry best-practices to produce lightweight, easy to adopt processes and actionable guidelines to be used by development and security teams.

This is the phase where we come up with a plan to fill the gaps identified in the previous phase while leveraging the organization and development team’s strength.

Implement

This is the phase where the program is put into practice.

Stay tuned for the next blogs in this series where we explain these three phases in detail.

NOTE: This post was originally published here… by me.