Software Security Assurance - Getting the Formula Right

Saturday, August 27, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

Hello there, I had an interesting question posed to me recently... one that I didn't have a simple answer for so I thought I would share my thoughts and post it here - soliciting your thoughts too...

The question is as follows:

"Who do you think is more qualified to understand and write 'secure software'... the security professional who understands development, or the developer, who gets security?"

On the surface, the answer should be that as long as both components are represented... it shouldn't matter.  Or should it? 

I think a little deeper digging into this, and some personal reflection and thought made me realize that I'd probably rather have someone that's lighter on the security and heavier on the development background - essentially a developer who's learned 'security'.

Why, you may ask?  I'll explain...

I think there are 3 qualities that I look for when assigning people to critical roles in a software security assurance program:

  • fundamental understanding of programming structure
  • fundamental understanding of offensive & defensive security (as it pertains to software)
  • fundamental understanding of business process, requirements, and test management

...and if I had to rank them in order they would look like they do right there (above). 

That means that I think that having much more than just a solid grounding in development is necessary... I really think that having advanced understanding of the developer mindset is critical since I strongly feel that software security begins and ends at the developer.

Now for the so-what.

If you follow me on my thought process, even if you don't agree 100%, we have a problem.  Technology, that is to say the tools, that are being written and pushed out to help 'secure software' are primarily implemented from the wrong angle. 

What I mean is this - tools that are written and distributed to the enterprise are more geared towards the 'security practitioner' than towards the developer... not everywhere, but on a whole. 

This is a natural extension of the mindset that security is the security team's problem which we all know, I would hope, by now to be false.

What can we do about it?  I think the major thing that has to happen is a re-evaluation of many of the Software Security Assurance programs we're driving across our businesses... and evaluating exactly what we're trying to accomplish. 

We, as security professionals, need to ensure that we're doing what's right for the developers who will be ultimately building more secure software... rather than us security professionals who are adept at bolting on security bits. 

That's the big revelation here... but of course, that hinges on the fact that you believe me in the first place.

Next up... I'll give you a few methods and examples for re-focusing your SSA program on the developers... stay tuned!

Cross-posted from Following the White Rabbit

 

Help Support Infosec Island by Tweeting and Stumbling our Articles - and join our LinkedIn Group HERE - Thanks!

Possibly Related Articles:
11295
Webappsec->General
Software
Development Secure Coding SSA Software Security Assurance Information Security Infosec
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.