2010 - A Quick Look Back to Look Forward

Wednesday, December 29, 2010

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

"We can't solve problems by using the same kind of thinking we used when we created them." -Albert Einstein

I think that quote there (one of my favorite Einstein quotes, by the way) is a great way to sum up 2010, a year that saw many changes, many advances - yet the problems with vulnerable web applications remain in large part due to the kind of thinking that quote refers to.  

I can't help but feel as if we in the software security assurance (or application security if you still prefer) space are still addressing the issues with the same eyes that are the cause of the problems in the first place.  

In the final analysis, I feel like we're still missing the point, and since we have a bunch of hammers in our hands every problem appears to be a nail.

So looking back on 2010 and where our footprints in the sand have led us to so far, I can't help but feel like we've been walking around in circles, talking about the same thing over and over again but only changing up the words to make it look more appealing and calling it new.  I'll quit being vague...

A Myopic View

It's easy to claim victory in problem-solving when you're only solving short-term issues. We don't need faster scanners or better developer education, or more outsourced code review or... we need those all together, in concert otherwise we fail.

I've said it before and I'll say it again- a company can't "test itself secure"... it's just not going to happen.  You need a remediation plan, you need to account for developer psychology, corporate politics and culture and then think about how or if a software security assurance program makes sense.  

I've seen SSA programs get shoe-horned into so many companies that just didn't care outside of the security team I've lost count -and what's worse I've watched a vast majority of them fail.  

Failure in these cases is a lack of adoption throughout the corporate culture.  It's possible for the security team to get everything right (ie, "push" security down) and still completely fail the SSA program.  

Why?  It's because the myopic view that many people in our industry still have.

"Slap a web app firewall in front of your apps, you'll be OK" is not only a dangerous statement, it's reckless and in the end will ultimately lead to a compromise or data breach.  The sad thing is... the consultant doesn't get held accountable generally.  

We as an industry seem to be in a thick fog, skipping along a lake of fire but only able to see the stone directly in front of us and not the ultimate goal... which means at any given point in time we could be leading ourselves, our enterprises, or our customers down the wrong path.  I think it's a sad state of affairs, and I'd like to hear some opinions on why I'm wrong... please.

Short-term problem solving, "point solutions", and one-time engagements are going to be the death of application security.  Actually... that may not be such a bad thing in the end.  Application Security still implies that the security team is directly involved in the activity - which I think is the first thing that must change because it's wrong.  

The premise of a good Software Security Assurance (SSA) program is that everyone is involved ...the myopic view is removed and the fog lifts.  Maybe we need a little more failure, but at what cost?

So now what?

I have a 3 point "plan" for looking ahead and what should be done by the security community.  It may not be as glamorous as the predictions people tend to do at this time of year but here goes:

  • Break the Security Silo - Stop thinking that the security teams can make corporate applications more secure.  They can't, they won't, they've failed.  Breaking the security silo involves making a cooperative effort between the security team, the development organization, the QA organization and the business analysts - all governed by the security team - work properly like the gears in a fine Swiss timepiece.  Creating a Software Security Assurance program means that you've got stakeholders from the business and from technology/security - and that you're not just trying to force square pegs into round holes.  Forcing the business to take on more security than it thinks it needs is a guaranteed method of failure, 100% of the time, so let's start with step 1 of understanding the business and the problems it faces with respect to risk, compliance, business climate and then start thinking about how to apply appropriate security measures.
  • Adopt Realism - There are too many application security programs that decide on some very lofty goals and then start to work towards them without any foundational grounding in reality.  This is another sure way to fail.  I suggest that if you're implementing an SSA program in your company right now, you take this holiday break to do a bit of a reality check.  Look at what you're trying to implement - and ask yourself "How does this fit into the business model of my company?"  If you don't know the answer quickly, then it's time to stop the implementation and go do some research.  Go talk to your heads of the business, understanding their goals and how the company survives is important.  What is the primary purpose of your organization?  Is it to sell widgets?  Is it to provide services?  Is it to protect our country?  You need to know these things so that you know what to protect and how much to spend on doing that... and then you can base your SSA program off of the business needs and protocols.
  • Learn Software Quality Psychology - My main focus for the past year, and this will continue for the next several years, is not "security" but rather software quality.  Security must become a component of overall software quality.  This doesn't mean giving security to the QA manager, but rather engaging the quality assurance methodologies that security has been lacking so badly.  I've said it before during my "Into the Rabbithole" talk this past year but security teams are often ill-equipped to analyze and assess web applications.  In fact, most security professionals (when it comes to testing) take the URL, pick up their favorite sledge hammer (metaphorically) and start swinging away until something breaks.  I keep saying that as application complexity continues to rise up that hockey-stick curve of Web 2.0+ if you're not understanding your applications you're lost.  I don't care how awesome you think your scripts and tools are, or how great of a penetration tester you are - the application coverage (of the application attack surface) that you will be reaching will continue to decrease well below the 20%-40% you're hitting today.  Grow up, accept that there's more beyond just 'security' ...and that this is a bigger problem.

So there it is, my plan.  You'll hear me talk about these points into 2011 and beyond, and some of you will see HP Application Security implement these points in your organization.

It's a slow and admittedly painful process... but once you've gotten it right it's beautiful.  

Once you've gotten it right it just works, and your SSA program will continue long after you've been promoted or moved on without the need to push and enforce every day.  

I look forward to the day when security is just another component of software quality, and we can quit talking about which tools are best because eventually it won't matter if they're not being utilized properly.

Good luck in 2011 and beyond.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
13042
Webappsec->General
Software Application Security Vendor Management Development 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.