Implementing Secure Software Development Program – Part 3

Background:

In the previous parts we covered the approach for implementing Secure SDLC (S-SDLC) and Gap Analysis. In this part we are going to cover Road Map Design and Implementation.

Intended Audience:

This article is written keeping in mind Senior Management and Lead Security Engineers.

Objective:

The objective of this article is to explain to the users how to build a Road Map for S-SDLC programs. In very simple language, a road map is nothing but a wise approach to reach a expected maturity level – thus boosting the organization's security over a period of time.

Approach to build the Road Map:

We'll systematically follow an approach that will help us build the road map for our S-SDLC program.The following is a pictorial representation of our approach:

There will be 4 major steps in the approach we'll take:

1. Determine Current State
2. Determine End State
3. Perform Delta Analysis &
4. Chart out a Road Map

This Article will elaborate on each one of the above mentioned process steps which will help the reader in creating aroad map based on their requirements and business expectations.

1. Determine Current State

   If you have been reading these articles in series, you'll notice that in the last article I covered how to perform Gap Analysis. Well, the results are going to be of much help to us here in this step when we are trying to understand our current state.

   We'll understand the business requirements from Senior Management so this is where our gap analysis will help us, as we'll have a fair picture of what all security practices are already in place and hence when discussion for business requirements takes place, we'll be able to leverage it well.

   Understanding the Business Requirements:

   Senior Management makes decisions on prioritizing activities and approves cost incurred on heavy weight programs like S-SDLC, which can have big effect the way businesses functions. Lead Security Engineers should work with Senior Management to understand business requirements and identify the Key Management Expectations.

   This step seems to be simple, but it is actually not. Identifying the requirements can be tricky at times. This is because even management will not have a clear understanding of what they are looking for!

   In such cases where expectations are unclear, cross-questioning by giving examples and highlighting expected outcomes can be very helpful.

   What makes this step even more important is the possibility that some of the goals, which need to be achieved during the program lifespan, can be derived based on management's expectation or can at times even be provided as a business requirement itself.

   Integrate Gap Analysis Results:

   Based on the results from Gap Analysis, we should be able to map business requirements directly to security practices mentioned in the Open SAMM framework and accordingly understand what exactly we can advise and/or discuss with key stakeholders. This mapping is very important, as without having a proper linking we'll not be able to reach our goals if this clarity is missing going forward.
2. Determine End State

   Every process step is important; however this process step in particular needs special attention. This is because the outcome of our program will be directly based on what is envisioned in this process step. Having clarity here will also help in performing our next process step smoothly and hence a crystal clear roadmap. If we miss anything or make a mistake here, it will have spiraling effect, as the next process steps will be further dependent on this step and eventually the results will be skewed depending on how skewed this process step is!

   In this process step we will do two important activities – identifying the goals and determining the applicable maturity level.

   Identifying Goals:

   Once we have mapped business requirements to Open SAMM framework's security activities, we need to translate the same into a set of goals. These goals, once identified and listed down, should go for management review & should have management's approval. It may not be very fruitful to go ahead and implement things in full speed for goals which do not confirm to management's expectations – no matter how much trust management puts in its security team.

   When we get the goals approved, we are also setting the management expectation and clarifying our success criteria, which can be expected out of us at the end of this program.

   Developing Supporting Policies and Procedures:

   To get the program going, it is necessary to have supporting policies and procedures to which employees can refer to. These policies and procedures will be helpful, not just to the existing staff, but also to the personnel joining the company after this program is implemented and is functioning well.

   Based on the organization structure, it may depend whether these policies and procedures are written by the security team or a team that looks into other internal non-security related compliance.
3. Perform Delta Analysis

   This process step consists of two major activities – Identification of Missing Security Activities and Prioritization of Security Activities based on business needs

   Identify Missing Security Activities:

   We have 12 security activities in our framework and based on the current stature of the organization, some may be addressed and others may not be;some may even be partially addressed.

   So far, we have received data from various sources – Gap Analysis, Goals, business requirements etc…Based on this data, we should be able to clearly distinguish which security activities exist and which are the missing ones. Out of the existing set of activities derived thus far, few activities need to be dropped and rest of them need to be carried forward.

   It may not make sense to go full throttle when a security activity is not in line with business expectations. In certain cases some of the security requirements mentioned in Open SAMM may not be applicable.

   Example:Let us consider a scenario where one of the departments of an organization is interested in implementing an S-SDLC program and not the entire organization. This department has its own agenda for this program. It can help in improving client's confidence in product developed by them as the marketing team can brag about product's security features and this will eventually boost up the sales and hence the profit for their organization.

   In such a scenario, it may not make any sense for this department to focus on Security Activity - "Environment hardening". This is because the asset for our department in question is their product they develop and deployment of this product will happen in the clients network, so what is the point of hardening the environment when the end goal is to improve product's security?

   Prioritization of activities based on Expectation:

   It should be noted that business drives an organization; hence appropriate importance must be given to business expectations.If there is a need to calibrate the priority of any security activity based on business needs, it should be done.

   This is important because requirement "x" might be more important to the organization when compared to requirement "y". The reason can be anything – boosting stakeholder's confidence, competition from other organizationsor any other reason.

   Example – if a competitor is claiming that his product has undergone security assessment from an external auditor and these auditors have given a green signal on the product's security, however our product does not have any such branding and hence it's taking its toll on sales. In such a scenario, management may be interested in getting this step done as well. In such a scenario, it would make more sense to do this activity in parallel. Security Assessment can be done by internal security or even an external auditor can be called for closing this. Based on the organization, if we have an internal security team, we can get it done internally, otherwise an external auditor can be hired for this activity.

   If there are any risks arising due to prioritization ofsecurity activities – explicit or implicit – these risks should be highlighted to Senior Management.

   This process entire step can be tricky at times and should be handled with due care as we also need to push the security agenda without hurting the business sentiments.
4. Chart out a Road Map

   This is the key process step. However, as highlighted above, we derive this based on previous process steps. This process step consists of 3 major activities – Defining Scope, categorizing security activities that need to be addressed into multiple phases and associating timelines with these phases

   Defining Scope:

   Most organizations will have applications which could be categorized into 2 different sets – Applications which are in progress (or upcoming applications) and other applications which are already developed. We need to work with Senior Management to understand whether they want to roll out the program for upcoming applications only or do they want to cover some of the existing high risk applications in this program. Decisions on expanding the scope of the program to rest of the applications can be taken by management based on program's outcome and confidence that is built over a period of time.

   The following is a sample photo representation of scope. Many things need to be considered when deciding the scope. The figure below mentions only some of the areas that can be considered when scope is charted out.

   

   The scope will differ from organization to organization based on the business's needs. Things will become a lot easier once scope is charted out. Before that, it may seem to be going in too many directions simultaneous. This may happen because of heavy expectations from management.

   Segregation of Security Activities into Phases & Associating Timelines:

   Now we need to segregate all security activities across multiple phases. These two activities normally go hand in hand. Based on the amount of work pending, we need to allocate time to it. The following is how a sample roadmap should look like once ready. Please note that all the activities described in following roadmap are only for demonstration purposes and will differ based on the requirements. The roadmap – by no means can be classified as complete as it only covers certain security activities.

   

   Q1-2013 to Q4-2013 represents the quarters of year 2013 and has been taken as an example to associate a timeline. You can choose a different timeline if required. There is no hard and fast rule for it;it can be in months as well. On the right hand side are the phases and associated activities.

   As you can see the above roadmap is not just mentioning activities listed down in Open SAMM. I have given a sample roadmap which encourages users to extend the framework rather than just sticking to what is explained in the framework.

Word of Caution:

It should be noted that most organizations may prefer evolution rather than a revolution. Trying to do too many things at one shot can lead us nowhere and eventually this will frustrate us as well as management- achieving nothing at the end of the day. Being ambitious is good; however it should be based on cognizance as there will be too many stakeholders involved. Hence, trying to fit our expectations into the business at a proper speed is very important. Consequences of trying to push the agenda too fast may result in unpopularity of the program among the employees and no program can be called successful if people are not willfully embedding it within their day to day activities.

What Next?

In next article I'll cover Governance and each security practice associated with Governance in detail.