So far we have covered all the necessary information regarding what is Secure SDLC and strategically how to go about implementing it. Detailed information regarding business functions & security practices we have covered in prior articles can be found in the Open SAMM Framework. For some topics which are not well documented, that can be helpful in implementation of S-SDLC framework; I’ll cover them via separate articles later on, however, not via this series. This is to maintain flow of the series of articles and keep it straight forward and simple. Intended Audience: This article is written keeping in mind Lead Security Engineers and Senior Management who are involved in end to end in implementation of this program and the compliance team which creates new policies and procedures for organization’s internal compliance framework. Objective: This is the last part of in the series of implementing Secure SDLC (S-SDLC) program. In this part, I’ll cover an important step – Mandating Security Framework, which is briefly described in Open SAMM, but needs more explanation. This is because it is this single activity which, if handled properly, can decide on the success or failure of the program. We want to do 3 major things here and we’ll cover each one of it in detail:
Implement checkpoints at regular intervals in SDLC
Mandating the security framework
Measuring our success
Implementing Checkpoints:
This is the first step in our approach. We need to implement phase gates after every phase of the SDLC. Phase gates are nothing but compliance check points; once a phase is completed, the development team will cross verify whether all necessary steps were taken or not and these will be reviewed by the panel which sits for the phase gate review. If any important activity is missed out or addressed only partially, it needs to be completed before moving into next phase of SDLC.
We need to analyze the current model of SDLC and check whether the model in use already has phase gates implemented. If it is not implemented, we can incorporate phase gates, however, that will need additional work and many approvals and not to mention the policies and procedure updates and process updates as well.The following is a pictorial representation of SDLC with Phase gates looks like:
I’ll explain this concept with an example. If, for example, during the requirements phase of the project, non-functional requirements are missed out. When the project goes for Phase Gate review, the review panel will cross verify and see if anything is missed out. Since non-functional requirements are also critical to the software development process, phase gate panel’s review will highlight that it is missing. Based on this review, unless non-functional requirements are taken care of by the application development team, the project will not be allowed to go into the next stage.
So what?
This is the sweet spot for embedding security practices into SDLC. If applicable, security activities(per phase) are embedded into respective Phase Gates.We should be able to mandate our security framework by piggybacking it into the existing process of the organization. We’ll cover how to do this in next section of this article.
So when a project completes, for example, its design phase, the Threat Modeling activity has not been performed, and the Lead Security Engineer who will sit in the review panel will have authority to give a “No Go”, thus pushing the application development team to comply to this framework. The same thing applies to every activity included in this framework.
It should be noted, however, that these Phase Gates, although generally found, need not necessarily be found in every organization’s SDLC process. In such cases, Lead Security Engineers can propose one and see if it can be implemented.
Mandating the Security Framework:
We need to do 2 major things here to mandate our framework. One – Create all necessary policies & procedures for our framework & Two – Modify existing SDLC process document to embed the Security Framework. We should be able to achieve both these targets by working with the compliance team and following a proper Change Management.
Creating additional Policies and Procedures:
As discussed above, embedding security activities in phase gate is a key input to this step. Next, we need to understand existing organization structures to locate the compliance/governance team. Normally this team creates new policies and procedures for the organization. They work with businesses to create the necessary documentation for them and help them in mandating their processes and putting it on intranet for employees to adhere.
In certain organizations, each department drafts their own policies and procedures and then submits these documents to the compliance team for review. The compliance team may then reword or rephrase it to shape into a proper policy / procedure document.
What are Policies & Procedures?
As quoted by Wikipedia:policy is a principle or rule to guide decisions and achieve rational outcomes. In simple words, a policy defines what needs to be done and can be used to understand this “what” factor.
Procedures are supplements to policies and are written to address the factors “Who, What, When, Where and Why”. This way, it stresses on responsibility and accountability of roles as well.
Change Management:
For readers who are relatively new to this concept, Change Management is an organizational process which aims at implementing requested changes by looping in all required stake holders and simultaneously ensuring a smooth transition to the new process without having a significant business impact. All necessary approvals required for implementing the change in existing process framework have to be taken from Senior Management on a need to need basis. There is a proper thought process behind all this. Organizational changes are strategic decisions and the process implementing such changes should be designed by taking into account all these inputs. Changes have to be implemented in a structured manner and hence approvals are required from Senior Management before implementing them to ensure that it is smoothly rolled out.
Once our policies and procedure documents are ready, the compliance team along with the business (in this case the Security Team) will work with Senior Management to approve such process changes by following proper change management procedures and get this approved.
For us, this is the most important step which will help us achieve our aim. If we are able to get this done, the rest is all to support our mandated framework – nevertheless, even that is important and needs to be done.
The following is a pictorial representation of the same:
It should be noted that this process step can take some time and we may have to wait until we get this approved. We need to follow up regularly to check the status of our change request.
Once approved, our major task is completed.We now have an organizational process mandate in place for our security framework. Non adherence to it is non-compliance and we can push concerned people who are not following the process and ensure that all necessary security activities are completed for every software product being developed.
Measuring Success:
We still have much work to do in order for us to track the success of our framework. Without having statistical data on new software products which have embraced the new product development life cycle, it remains unclear as to what extent security activities are performed. We need to proactively collect data for getting our numbers right as programs like this will be tracked by Senior Management as well.
Collecting Data for Measuring:
So, how do we collect necessary data? Well, there are multiple ways to do this. We can send out emails to all project managers to provide data or we can keep track of the information ourselves by requesting Lead Security Engineers to maintain data for each project which goes through the Phase Gate review. We can also maintain a Centralized Dashboard to which all project managers upload information on a regular basis.
There can be many ways in which we can collect data. What method for data collection is adopted depends on the security team & management’s mutual expectations on what information is required, how much information is required and how frequently it is required.
Analyzing the Raw Data:
Data collected with above discussed methodologies is still raw data and needs to be processed. Without processing, this has very little meaning to management, so we need to analyze it. Some of the things which management would be more interested in measuring can be:
Number of projects which have implemented Security Activities,partially or fully
Number of Non-Compliant projects (with further refined info on number and type of non compliances)
Delta Analysis on Security Posture of product before Secure SDLC Process was implemented & After Secure SDLC Program is implanted
Overall improvement of the organization’s security level after this program is implemented
The above is just a sample list and should not be confused with a comprehensive list. There can be many more details which we can record and analyze to present further to management using more attractive visual representation techniques like charts, pivot tables or any other means deemed appropriate.The end goal is to present this data to management in a refined format which can help them take decisions and decide on future course of action. It should be remembered for management that any program is eventually an investment and if they can’t measure the outcome, it can’t be concluded if the program is providing any benefit to the organization. We can provide meaningful and objective data only when we collect & analyze the raw data and put it in a visual format. We need to analyze the current model of SDLC and check whether the model in use already has phase gates implemented. If it is not implemented, we can incorporate phase gates, however, that will need additional work and many approvals and not to mention the policies and procedure updates and process updates as well.The following is a pictorial representation of SDLC with Phase gates looks like:
I’ll explain this concept with an example. If, for example, during the requirements phase of the project, non-functional requirements are missed out. When the project goes for Phase Gate review, the review panel will cross verify and see if anything is missed out. Since non-functional requirements are also critical to the software development process, phase gate panel’s review will highlight that it is missing. Based on this review, unless non-functional requirements are taken care of by the application development team, the project will not be allowed to go into the next stage. So what? This is the sweet spot for embedding security practices into SDLC. If applicable, security activities(per phase) are embedded into respective Phase Gates.We should be able to mandate our security framework by piggybacking it into the existing process of the organization. We’ll cover how to do this in next section of this article. So when a project completes, for example, its design phase, the Threat Modeling activity has not been performed, and the Lead Security Engineer who will sit in the review panel will have authority to give a “No Go”, thus pushing the application development team to comply to this framework. The same thing applies to every activity included in this framework. It should be noted, however, that these Phase Gates, although generally found, need not necessarily be found in every organization’s SDLC process. In such cases, Lead Security Engineers can propose one and see if it can be implemented. Creating additional Policies and Procedures: As discussed above, embedding security activities in phase gate is a key input to this step. Next, we need to understand existing organization structures to locate the compliance/governance team. Normally this team creates new policies and procedures for the organization. They work with businesses to create the necessary documentation for them and help them in mandating their processes and putting it on intranet for employees to adhere. In certain organizations, each department drafts their own policies and procedures and then submits these documents to the compliance team for review. The compliance team may then reword or rephrase it to shape into a proper policy / procedure document. What are Policies & Procedures? As quoted by Wikipedia:policy is a principle or rule to guide decisions and achieve rational outcomes. In simple words, a policy defines what needs to be done and can be used to understand this “what” factor. Procedures are supplements to policies and are written to address the factors “Who, What, When, Where and Why”. This way, it stresses on responsibility and accountability of roles as well. Change Management: For readers who are relatively new to this concept, Change Management is an organizational process which aims at implementing requested changes by looping in all required stake holders and simultaneously ensuring a smooth transition to the new process without having a significant business impact. All necessary approvals required for implementing the change in existing process framework have to be taken from Senior Management on a need to need basis. There is a proper thought process behind all this. Organizational changes are strategic decisions and the process implementing such changes should be designed by taking into account all these inputs. Changes have to be implemented in a structured manner and hence approvals are required from Senior Management before implementing them to ensure that it is smoothly rolled out. Once our policies and procedure documents are ready, the compliance team along with the business (in this case the Security Team) will work with Senior Management to approve such process changes by following proper change management procedures and get this approved. For us, this is the most important step which will help us achieve our aim. If we are able to get this done, the rest is all to support our mandated framework – nevertheless, even that is important and needs to be done. The following is a pictorial representation of the same:
It should be noted that this process step can take some time and we may have to wait until we get this approved. We need to follow up regularly to check the status of our change request. Once approved, our major task is completed.We now have an organizational process mandate in place for our security framework. Non adherence to it is non-compliance and we can push concerned people who are not following the process and ensure that all necessary security activities are completed for every software product being developed. Collecting Data for Measuring: So, how do we collect necessary data? Well, there are multiple ways to do this. We can send out emails to all project managers to provide data or we can keep track of the information ourselves by requesting Lead Security Engineers to maintain data for each project which goes through the Phase Gate review. We can also maintain a Centralized Dashboard to which all project managers upload information on a regular basis. There can be many ways in which we can collect data. What method for data collection is adopted depends on the security team & management’s mutual expectations on what information is required, how much information is required and how frequently it is required. Analyzing the Raw Data: Data collected with above discussed methodologies is still raw data and needs to be processed. Without processing, this has very little meaning to management, so we need to analyze it. Some of the things which management would be more interested in measuring can be: References: http://en.wikipedia.org/wiki/Policy http://en.wikipedia.org/wiki/Procedure http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle http://www.opensamm.org
