Tuesday 7 May 2013

A SDL Story


I want to put forth one of my onsite audit experiences with you. It came after successfully completing a secure code review activity for a mid-sized e-commerce company in United States. This visit was special as it laid the foundations of SDL (Secure Development Lifecycle) process in that organization.
The important goals of my visit were to:

1) Plan out a process to audit their applications on a continuous basis
2) Render some crucial secure design solutions to their design teams
3) Address any key security issue raised by the development team

To meet all my objectives I had to be in close proximity to the development teams. I had to understand their development process, internal team structures, identify key people involved in their team and interact with them. A series of meetings with module leads and design teams got me very close to their entire operational structure. The development teams had just received our initial audit report and they were busy toiling with it. On the other hand I was trying to put all the efforts to ensure that they were comfortable in implementing the corrections. Their internal security team did not understand much of the application code layout and I was the only key point of contact for their development teams to solve security related issues of the application. I was working very closely with their internal security team and had become a trusted security advisor to their development teams by then.  It was getting a very fruitful engagement for all of us day by day.

To meet my first and very important objective of planning a process for a periodic audit of their applications, I had to understand -
  • Where to look for the code changes?
  • Who makes the code changes?
  • How to understand the code changes?
  • When should the audit team start auditing the code changes?
  • Whom should the audit team present the security suggestions?
The best way for me was to dig into their SDLC process and get my hands onto their change management systems and repositories. I understood that they maintained their code changes in a tabular format in an online portal, which was called as “release grids”. I requested for an access to all of their repositories, including their release grids. I found the grids very helpful as they maintained all the code changes for any release in it. And it was something that would have been very helpful for me and my audit team. They tracked code changes in the form of tickets (an ID number for the change).

However, just having the change information would have not solved my problem. Each release had thousands of code changes including ones like minute UI modifications that do not require to be reviewed for security considerations. So my aim was to identify a way for my audit team to pick out important code changes (like important bug fixes and feature changes) from the vast pool of changes for any release. I knew that this step was important as manually reading the grids would be tough and would result in unnecessary wastage of time during periodic audits. Moreover, for any 3rd party auditor to understand the terminology used by the development teams and identify the code changes would have been cumbersome. On pondering on this point I concluded that the best solution for this problem was to integrate security audits in their development process. And this initiative then marked a need to establish a secure SDLC there.

At that time to my revelation even their management teams were taking efforts to streamline their development process. Their main challenges areas included:

1)       Establishing correlation between development teams of different modules
2)      Bringing accountability in code checkout (there was no authorization work flow in place at that point of time)
Looking at the momentum generated within their teams to revamp the development process even I approached them with my notion of integrating development process and security reviews. I highlighted my problem areas and proposed an integrated secure development process for them. I presented my plan on the following grounds:
1)      Need to integrate with the development process – To give an ongoing security support to their application, the audit team should be able :
a.       Know when the ticket (ID for a code change) is initiated – Requirement Phase
b.      Understand the proposed change for the ticket – Design Phase
c.      Suggest security requirement for the change – Development Phase
d.      Perform overall review and give our inputs – QA Phase
I explained them the importance of this integration and showcased a need to adapt a secure development approach and work flow within their team.
2)      Build adaptable and centralized security solutions - As per my observation as the application design was complex, incorporating a security requirement at the end of the development was tedious. It was leading to extra efforts to the design and development teams. Hence, there was a need for the security auditors to work closely during the end to end development of the feature and give the security suggestions wherever needed.
3)      Build a strong security knowledge base – I highlighted a need to develop application specific security best practices to waive out repetitive errors.
4)      Mandate Security Reviews - As per my observation in the current SDLC the security reviews were being carried out randomly and in order to bring overall security of the application it was crucial to review every important code change.
The management was all thrilled and impressed with this initiative and was eager to kick-off this new secure development process. They wanted me to guide them in putting this whole thing in action within their teams. This was a novel and exciting experience for me too; I was now venturing into putting my ideas to practice. However, as they say challenges never end, the next big road block for waiting for me. The internal teams knew less about security and making them adapt to this practice seemed like a challenge. The best solution to this problem was to spread security awareness to all their internal teams and make them understand security vulnerabilities and best practices. However, though the plan was good but it didn’t seem to be doable quickly. The management on the other hand insisted on having an immediate phase out of the integrated development process. On further brainstorming I came to a conclusion of building a repository of all security requirements/practices that the design and development teams could follow.

With my knowledge of the applications I could build:
1)       Overall secure best practices and guidelines for the applications
2)      List of possible and predictable feature changes in their key applications and their corresponding security requirements.
The management for very receptive to this unique and suitable documentation and decide to launch the secure SDLC process with it. Thus the security requirements became a part of their development specs and showed up in their release grids.
I was very happy about the whole activity as my efforts could bring security more close to the development team in an organization and help change their perception towards security.

Though SDL requires a great amount of discipline and coordination across different team and it must be done diligently to get a secure output at the end. SDL is a wonderful concept and more and more organizations must step towards it J