Building Application Security Program – 3

This is the 3rd post in the series of four posts. In the previous post, we looked at the first step of building an application security program i.e. Assessment.

In this post, we will discuss the proven approach to design an effective and scalable application security program for an enterprise.

By the time we enter the Design phase, we already have an understanding of organization’s security culture including:

  • Software security objectives
  • Security activities being performed and corresponding effectiveness
  • Strengths and weaknesses of existing software development and security teams as well as processes

In design phase, we further process this information to identify the actual gap between the current level and the desired level of software security maturity. We create a plan to fill the identified gaps while leveraging the organization’s development team’s strength. For which, we take the data collected during assessment and mix it with industry best-practices in order to produce lightweight, easy to adopt processes and actionable guidelines that can be easily introduced in the organization.

The artifacts produced during the design phase and the approach to create these artifacts is explained below:

Security Requirements: Almost every organization needs to comply with requirements enforced by one or more government or industry regulatory bodies to stay in the business. Hence, we start with identifying the software security requirements and processes the organization must perform to satisfy compliance mandates. These requirements are then correlated to other security requirements compiled to achieve business objectives. The resultant list is a single comprehensive set of security requirements that the programme needs to achieve through adequate and effective usage of people, process and/or technology. A set of technical controls with implementation instructions is also created to fulfil the defined security requirements.

Secure Software Development Lifecycle:  Next step in the design phase is to create a secure Software Development Lifecycle which is the core of any application security programme. It is not recommended that a new process be created from scratch unless absolutely necessary. Instead, we should take the organization’s existing SDLC process and improvise it by seamlessly weaving the security activities in it while ensuring the process enables the organization to meet the security requirements compiled earlier. The secure SDLC should clearly identify which security activities are to be performed manually and which could be automated.

Roles and Responsibilities: Several application security programmes fail despite having a good, secure SDLC. This is mostly because, although security activities have been defined within the SDLC, no one is made responsible or accountable for the execution of these activities.  Therefore, it is very important to clearly identify the responsibilities and accountabilities for the defined security processes and activities.

In the image below, a sample RACI chart is shown for static code analysis activity. It explicitly defines that the Development Team Lead is accountable for scanning the code, whereas the Information Security Team is responsible for triaging the results of static analysis with the consultation of development teams.



Application Risk Classification Criteria: Not all applications pose the same risk to the organisation hence, it is not viable to perform equivalent security measures on all applications. To overcome this, we create “Application Risk Classification Criteria” in which we can utilise the application attributes such as data being handled by the application, accessibility, business criticality, etc to define the potential risk of the application. This can help development teams identify security requirements the application must comply with and which technical controls are to be implemented to fulfil these requirements.

Software Security Education Matrix: It is a known fact that an application security program requires a thorough, role specific and methodical software security education program to be successful. Hence, we use the assessment results to identify the area of focus and create a training matrix suggesting what role specific trainings are required.

Once all these artefacts have been prepared, we are ready to move into our next phase which is implementing the application security program. This will be discussed in the next and final post of the series. Stay tuned!

This post was originally published by me at .

Building Application Security Program – 2

This is second in a series of 4 posts. In this series, we are discussing the recipe to build and implement an effective application security program. If you haven’t already, I suggest you to start from first post.

The first step of an organization’s application security journey should be “Assess” i.e. Assessment.  In this step, we want to understand:

  • Organization’s Software Security Goals
  • Software Security activities performed in the organization and the depth of the execution of these activities
  • Strengths of the development and operations teams as well as areas requiring attention based upon business goals and objectives.

All this information is then used to design the program which we will cover in the next post.

Assessment can be divided into two phases:

Software Security Strategy Assessment

This is the most important getzonedup PowderCity task in the Application Security Program Lifecycle as the whole program revolves around the results of this phase.

It starts with Identifying organization’s software security goals and objectives. The best way to gather this information is by interviewing the business leadership in order to:

  • Understand organization’s vision and business goals
  • Evaluate executive’s understanding of their software security needs i.e. is there adequate buy-in from management
  • Identify the impact of lack of software security to business goals.

Once business goals have been identified, the data-related, existing software security initiatives and practices are documented. This is performed by:

  • A series of interviews with relevant Software Security Assurance (SSA) program stakeholders involved in project management, security, requirements, design, development (in-house and outsourced), and deployment processes
  • Reviewing existing organizational software security policies, SDLC artefacts, secure coding standards and guidelines.

Interviewing the stake holders provides insight into organization’s attitude towards software security initiatives whereas reviewing the documents help with an understanding of whether the activities are actually being performed and how well they are being performed.

Assessing the security strategy could be a complex (and ambiguous) task unless guided by a proven framework or maturity model and there are few available for this purpose. Two such popular models are described below:


BSIMM is a descriptive maturity model and describes a set of security practices as conducted by global participants, with real-world data from 67 firms including Microsoft, Adobe, Zynga, Salesforce, Citi, Bank of America, Box, Paypal and many others ( ). Results of a BSIMM assessment can be used compare the initiatives with peers and industry leaders already participating in the studies. For more details, refer


OpenSAMM a.k.a. SAMM is prescriptive model to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. For more details, refer

 By mapping the information gathered to these maturity models, a current security state model as well as a future state model can be created for the organization.


Technical Assessment

Although interviewing the stakeholders and reviewing the documents is one of the most effective ways to assess the software security maturity of an organization, it fails to provide two important pieces of information:

  • Technical impact of gaps in security strategy – important for building business case to achieve management support for the next stages of the program
  • Secure coding areas requiring most focus during the trainings to be provided to development teams

This part is easy and can be achieved either by performing the security assessment (Code Review and Penetration Test, in tandem is preferred) and evaluating the results OR by reviewing the recent security assessment reports for some of the major business applications.

 From Assessments we have gleaned three important pieces of information.

  • Where we are
  • Where we need to be
  • Strengths we can leverage and weaknesses we need to overcome

 And once we have these three things, our journey becomes easier…

In the next post, we will look at “Designing an Application Security Program”. We will discuss what needs to be covered in the program and related gotchas.


This post was originally published at my employer’s site by me.

Building Application Security Program – 1

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.


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:



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


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.


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.

Story behind this blog!

Someone once said to me “If you can walk with the crowd, still hold your head high and stand out, then you would have arrived“.

Since that day “to arrive” has been my aim and while walking on the path to achieve this, I found many, left many and then there were few which I kept close to my heart. Not talking about people here (ofcourse it applies to people too) but the software development lessons which I learnt from my peers, teachers and many considerate programmers who share their code with the needy ones through internet. So, here I am to share the good software security practices through this blog with a belief that one day this endeavor of mine will contribute to the secure software development in various organizations around the world hence building the foundation of a vulnerability free cyber world.

In this blog, you will find what programmers should and shouldn’t do to ensure their applications are resilient to attacks in addition to some good practices being followed in various organizations around the world to produce secure software.