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

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 ( www.bsimm.com/community ). 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 www.bsimm.com

OpenSAMM

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 www.opensamm.org.

 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.