Four Components of a Successful SSA Program

Tuesday, February 15, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

My last post outlined 3 things that virtually guaranteed the swift and untimely demise of any software security assurance program. 

One of you loyal readers (actually, it was eventually more than just one) then pointed out that simply pointing out what was wrong just wasn't my way of doing things - so I had to write a follow up post that outlined the things that I felt that a solid SSA program needed.

Luckily, I just so happen to have a Top 4 handy.  Why top 4, you ask?  Because there really are 4 components that make up a successful software security assurance program. 

More importantly there are 4 things that I have personally witnessed and implemented that have contributed greatly to the success of many programs - and so without further ado here is my list of 4 Components of a Successful Software Security Assurance Program.

1. Process - It bears repeating that "you can't test yourself secure" ... and no one believes that more than I and my team here at HP does.  The foundation for a successful SSA program is process. 

From a "Secure SDLC" (what ever that means to you), to testing strategy, to risk management and remediation - it's all founded on strong process.  You almost have to have a script for the way your business IT functions, and what you and your team will do to influence the outcome every step along the way. 

Process can be simple, and can be outlined in documentation and stored on a network share or published in a booklet on everyone's desktop.  Process can be a workflow-driven project management system that requires a security-infused approach not just pre-release but from requirements gathering all the way through post-release. 

Process includes not just security but PMO (Project Management Office), development, QA and operations organizations in your enterprise.  Don't forget, one of the most subtle and neglected (but critical) processes in software security assurance - incident response!

Planning and developing secure software is just as critical as responding to the eventuality of an incident - when someone breaks in, hacks up the system and steals data... what is your defined, approved and tested process for managing that most critical time?

2. Education - Security folks tend to talk a good game when it comes to SSA, but we often time leave it up to the developers to "figure it out themselves"... which isn't fair. 

Developers aren't security experts, and can't reasonably be expected to have secure software as a target without proper education and training.  You'll need to develop an awareness plan which includes educating not just the developers but also your PMO, QA and operations organizations, and user population. 

You'll need to have developed and proven secure coding guidelines that developers can keep desk-side to refer against when developing critical applications.  Secure coding guidelines should not simply contain a list of "thou shalt not" type items... but rather take a prescriptive approach and define clear design principles based on tested, known-good approaches to securing applications. 

It's OK to refer back to the OWASP guides and other published documents available out there - you don't need to re-invent the wheel.

3. Automation - If you think you're going to tackle large heaps of code, hundreds (maybe even thousands) of applications, and countless projects all manually - you need a reality check. 

There are still plenty of people out there who will argue until they're blue in the face that the only way to be effective at application security auditing/assessment whether you're staring at a million lines of code, or a running application in your browser - is to do it by hand. 

Many of those people are consultants who get paid either by the hour, or have a stake in taking their sweet time. Your reality in the corporate IT team is much different. 

If you're going to tackle as many as 2,000 applications, running on quarterly release cycles (which is being extremely generous, by the way) and manage the whole ball of wax from requirements through post-release it is inconceivable to accomplish this without either an army of consultants, or the acceptance of failure. 

Automation doesn't replace people, rather, automation eneables your existing resources to test smarter, remediate faster and gather metrics and KPIs more intelligently.  After all...

do you want to be sitting at your desk wading through 1,000,000 lines of code ...or having dinner with your family?

4. Governance - Once you've got things going, and have a solid foundation built it's time to make sure the SSA program you've built has sustainability in the long term.  One day (hopefully as a result of this success) you will get promoted and move on, or out of your current role. 

The SSA program you've stood up should have the capability to stand up on its own without you babysitting it.  Governance can take on the form of methodology, documentation or software/tools.  What does "governance" mean? 

It defines what the term security means to your organization in practical and realistic terms.  It defines your organizational risk profile, the organizational structure of the SSA program and overall program strategy. 

Governance means control, audit and visibility of process progression - and knowing how things are moving along and at what stage applications, projects and reviews are. 

Governance means being able to define sign-offs at various stages or toll-gates in the SDLC which security is a part of and then holding projects and project managers accounatble for obtaining those sign-offs.

Governance is what defines the SSA program long-term and really makes it viable as a business-accepted, strategic goal of an enterprise.

There you go - the 4 components of a successful software security assurance program.  You're probably asking yourself ...shouldn't there be 5?  Shouldn't funding be number 5?  My answer - let's talk about that in a future post.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
9295
Webappsec->General
Policy Security Strategy Application Security Governance SSA Software Security Assurance
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.