Implementing Secure Software Development Program – Part 2
This is the third article on Secure SDLC (S-SDLC) and the second on the implementation of Secure SDLC. So far we have covered an Introduction of S-SDLC and Overview of Open SAMM framework. Readers are advised to refer to these articles before getting directly into this article.
The first step in building the S-SDLC program is to gauge the current security stature of our organization. Hence, this article will focus specifically on understanding the approach to take for implementing an S-SDLC program for our organization. Many organizations may have some security program in place, so we’ll also be focusing on how to perform a gap assessment for such organizations, as this will be our first step toward implementation of the program for them.
This article with lead security engineers in mind as prime readers. As I have highlighted in previous article, the intended audience may change from management to technical as we move further into implementation.
This is because these are the people who are directly involved in development and implementation of this framework with inputs from management as per the organization’s needs. Although project and program managers can read this for reference, lead security engineers will benefit the most, as it might assist them as a ready reference during the S-SDLC program implementation.
S-SDLC – Program Implementation Approach:
Any organization can be categorized in one of these two categories:
Organizations that have no security program
Organizations that have some sort of security program
Our approach will depend on the kind of organization we are dealing with. Following is a pictorial representation of the approach:
If an organization does not have any sort of security program in place, we can start afresh and implement one; that’s easy. However, complexity arises when some sort of program is already in place. If an organization has something in place, as per the approach, the first thing we need to do is implement gap analysis. Secondly, we need to calibrate our S-SDLC program, taking into consideration what is already in place and what all are the areas which need further attention.
Why perform Gap Analysis?
It is very important to understand why we are doing a particular activity, irrespective of the activity being conducted, because doing something without having an end goal in mind will not yield the desired result. The same philosophy applies here as well.
Most organizations these days have some security assurance program or other. It may be unstructured and lacking clarity or it may have some level of clarity with documented policies, procedures in place, and appropriate stakeholders associated with these activities. There can be many reasons for such a hodgepodge; e.g., to avoid bad press, to increase stakeholder confidence by having such programs, etc. However, these programs may not be complete and the organization may want to have a proper program in place. In such a situation, given the fact that there is already something in place, we need to understand where we stand. This is where gap analysis comes into picture.
The following picture shows the overall equation:
Activity in the green circle is what we need to focus on to reach the desired state, which is the purple circle, our S-SDLC program.
How to Perform Gap Analysis
We need to measure the status of organization’s security posture against the activities defined in Open SAMM framework. We can identify the gaps. In the long run, this analysis can also be used to derive the road map which meets the security goals of the organization.
Gap analysis process is very simple: fill up the assessment worksheets and associate a score by comparing it against each security activity mentioned in the framework. I’ll cover a sample worksheet for one of the security activities in detail later in the article.
Open SAMM framework supports two kind of gap analysis (or assessment as the framework calls it):
Light Weight Analysis
Light weight analysis is helpful when an organization wants to quickly evaluate where it stands. This is usually good enough if the source from which information is derived is reliable.
To give an example: If senior Management is currently driving the security program, having a discussion with them can be helpful in deriving the gaps, assuming that they present the facts honestly and completely provide all required information. To complete this activity, we can just fill up assessment worksheet and evaluate the scores.
Detailed analysis is normally conducted where an external auditor is hired to implement S-SDLC program. Over and above completing the assessment worksheets, additional audit work is conducted for verification of all the details. This way all the artifacts are verified for authenticity and correctness, there is no confusion, and no decision is based on management’s gut feeling about their S-SDLC program. Each of the security practices in Open SAMM is validated against the artifacts available for existing security assurance program and a proper score is arrived at. Scoring will be covered in following section.
Following is a procedural flowchart which explains both Light weight and detailed analysis process steps.
As seen in above figure, audit work is the only difference between the two types of gap analysis. In a way, audit work is good as it relies only on facts, and decisions on the future road map are taken only based on it. However, the flip side is that it is time-consuming and involves additional cost, as resources will be engaged for a longer duration.
Sample Gap Analysis Worksheet
I’ll cover only one business function to demonstrate how a sample gap analysis worksheet looks like and all the questions it covers. For full worksheet, you can refer to the Open SAMM manual. It lists the whole work assessment sheet with detailed list of questions covering all 12 security practices and all four business functions.
|Governance||Assessment Questions||Response (Yes/ No)|
|Strategy & Metrics||Is there a software security assurance program already in place?|
|Do most of the business stakeholders understand your organization’s risk profile?|
|Is most of your development staff aware of future plans for the assurance program?|
|Are most of your applications and resources categorized by risk?|
|Are risk ratings used to tailor the required assurance activities?|
|Does most of the organization know about what’s required – based on the risk ratings?|
|Is per-project data for cost of assurance activities collected?|
|Does your organization regularly compare your security spend with other organizations?|
|Policy & Compliance||Do most project stakeholders know their project’s compliance status?|
|Are compliance requirements specifically considered by project teams?|
|Does the organization utilize a set of policies and standards to control software development?|
|Are project teams able to request an audit for compliance with policies and standards?|
|Are projects periodically audited to ensure a baseline of compliance with policies and standards?|
|Does the organization systematically use audits to collect and control compliance evidence?|
|Education & Guidance||Have most developers been given high level security awareness training?|
|Does each project team have access to secure development best practices and guidance?|
|Are most roles in the development process given role-specific training and guidance?|
|Are most stakeholders able to pull in security coaches for use on projects?|
|Is security-related guidance centrally controlled and consistently distributed throughout the organization?|
|Are most people tested to ensure a baseline skill set for secure development practices?|
Assigning scores is a fairly straightforward and simple task. Just fill up the assessment sheet and evaluate it. An affirmative answer contributes positively towards achieving the level and a negative answer brings the score down, leading to non-achievement of the level. As discussed earlier, Open SAMM supports three levels for each security activity.
It might also happen that the existing program’s security activity does not fit exactly into our framework’s boundaries – in such a case, we can mark a level with “+” sign.
To give an example: an organization does all the activities that fully satisfy the requirements of Level 1, but it also performs certain activities which fall under the purview of Level 2, without satisfying all Level 2 requirements. In such a case, we can mark our current stature as Level 1+
Based on the available Levels, we our current classification can fall in either one of the following: Level 0, Level 0+, Level 1, Level 1+, Level 2, Level 2+, Level 3, and Level 3+
For example, if all six questions are evaluated to have a “Yes” answer for security practice “Strategy & Metrics,” we have achieved Level 3; however, if only 3 are “Yes,” we may get a Level 1+ rating.
Again it should be noted that these scores are per security activity and ratings will differ from activity to activity.
If the gap assessment or analysis is light weight, these scores are final. However, if it is a detailed assessment, we will revisit these scores after our audit work is completed. If, based on the audit, there are any mismatches between what was analyzed as a part of light weight assessment and the facts found out during the audit, we will calibrate the scores to match facts.
By now, you should have a good understanding of S-SDLC, Open SAMM framework, and conducting gap analysis. In the next article, we will examine how to chart out a road map for an S-SDLC program, based on which future course of actions can be decided.
The road map will help us in categorizing and prioritizing security activities that not only conform to the business requirements, but also satisfy the Open SAMM security activities and their maturity levels, thus achieving dual goals. The internal security team can push their agenda by complying with the agreed upon framework and management can prioritize the activities based on business criticality. Later in the series, we’ll also cover how to mandate these activities such that they become internal compliance frameworks. Stay tuned.