Thoughts on Software Security Assurance from a Like Mind

Friday, June 10, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

Every once in a while I run into someone so like-minded it feels like they've been running around in my head... a recent dinner was just such an enlightening experience.  

We started talking about the 'problem' Information Security professionals face actually getting business and organizational buy in on SSA.  

Since we both work for vendors in this space, it's not often we get to sit down and just talk outside the confines of work and just really discuss the heart of the problems we face.

Over dinner, we figured out collectively that there are 3 big issues here...

  • problems are forced to fit solutions
  • technology isn't adapting to actual use-cases
  • developers still don't care about security

Strangely enough, only the second issue is fixable by making adjustments to products from major technology vendors.  The other two are basically psychology cases.

Problems are forced to fit solutions

Have you ever heard anyone say this phrase? - "When all you have is a hammer, everything looks like a nail"... it refers to a condition where due to some limitation you don't actually have a flexible solution, and aren't able to adapt to unique situations -therefore every solution is identical in nature.  

I can recall a situation that illustrates this perfectly living in a condo a number of years back. I walked out one morning into the hallway headed to work when I noticed one of my neighbors hammering away at something.  

Trouble is, she had a wrench in her hand. When I stopped and asked what she was doing, and why she was using a wrench she replied that she didn't have a hammer so this would do the job just fine.

The problem here is that a wrench, while it sure can act as a blunt object, isn't as effective as a hammer at driving nails. So applying this to Software Security Assurance programs what we may run into is an organization that only marginally understands the value of information security and instead runs heavy on software quality controls.

Outfitting that organization with the latest and greatest black box testing tool won't help your cause, and the solution will fail, almost guaranteed.

Yet I've seen some people sell organizations on the idea that they need to be 'externally penetration tested' regularly as a substitute for an actual SSA program likely because they weren't able to deliver what the customer actually needed... an in-house SSA program! As a customer or organization don't forget that your needs most closely resemble no one else's!

Technology isn't adapting to use-case

Being able to tie exploitable issues in a running application to source code is the Holy Grail of security testing... but it's unlikely you'll get good adoption and success if you're trying to hand a bunch of developers black-box security testing technology.  

Conversely, it's equally unlikely that if you hand a never-wrote-code-in-my-life application security analyst a source code analysis platform he or she will have a snowball's chance at success.

This brings me to an interesting point - what types of application security analysts do you have in your organization?  (*Note to self... expand on this issue in a later post).

The challenges of adapting to business and use-cases is difficult, and no one who's ever been a product manager will disagree that it can be daunting - but - there are vendors who aren't even trying anymore!

Excluding the edge cases, I think there are but a handful of use-case specific enhancements that could be made to the application security technologies out there. These changes wouldn't be drastic but would require thinking about how people actually work, and what they do to achieve more secure software.

A great concrete example is bug tracking. Most of the testing technologies out there are pretty good stand-alone, but what if you actually want to turn that critical security vulnerability into a critical security defect that you want to go into the bug tracking system for remediation.

Do you find yourself doing that work manually? If so, you need better technology to waste less time and create less hazard for error.

The next time you find yourself using application security-related technology ask yourself if its adapted to the way you work... or has it been the other way around?

Developers still don't care about security

So what? The interesting question is - "Do you believe in unicorns?"  If the answer is yes then you also likely believe in some magic technology which will allow developers to continue to write poor code, feed that code through a magic 'security box' which will then sprinkle fairy dust and without effort create a 'secure' version of that code.  

If you're nodding thinking how awesome this would be, slap yourself for a quick wake-up. Do you really think this sort of thing is a good idea even in theory?  Here's a hint: no.

So with so many developers out there still apathetic to the plight of the security analyst - what do we the security professionals do to make them care?  Do we create negative reinforcement strategies and threaten to get them fired if they produce poor metrics?

What about positive reinforcement and training?  What about rainbows and unicorns?

After thinking about this, debating with some of you, and thinking some more - I've come to the conclusion that there isn't a good resolution here. While I'd love to just let developers do what they do and write code and now have them worry about this 'security' thing... I just can't.  

Alternatively, as much as it sometimes seems like a good idea to beat developers over the head with security failures -that isn't going to work either. I guess this one just requires more thought. 

So, in the end, when all is said and done, we vendors still have a long, long way to go. Too bad patent law here in the US is strangling innovation.  On the other hand, there are still so many broken processes out there... technology is the least of some organization's worries.  

I'll sum it up like this- technology should enable and empower, it should also adapt to the way you work... and if you find even one of these aren't true go talk to your vendor. You might be pleasantly surprised to hear they have options... or you may find out it's time to go talk to someone who actually understand this space.

Good luck out there!

Cross-posted from Following the White Rabbit

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