Labels

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 Phasec.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