2010 - A Quick Look Back to Look Forward

"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:



  1. 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.
  2. 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.
  3. 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.

(anon) | ‎12-29-2010 11:41 AM

**bleep** it, Raf, get out of my head!!  I was just mulling over all three of these points this week.  Even though IT professionals love to plumb the depths of a topic and specialize, I think we've done ourselves a disservice by making security a separate discipline.  As long as quality and security are different groups from development, then quality and security will be seen as "someone else's problem" to be "solved" after the fact with a piece of software or a box.



(anon) | ‎12-29-2010 12:17 PM

I've been covering the information security world for 12+ years now and the only constant has always been more security issues and not enough security awareness, money and, most importantly, competent people that are allowed to do their job.

I can only agree with you when you say: "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." That basically summarizes what most of the industry has been doing for the past decade, not just during 2010.

451wendy also said it perfectly: "I think we've done ourselves a disservice by making security a separate discipline." I think it will take us another 10-20 years before this changes, if ever. It's actually bizarre that security gets so little attention, but I guess the suits care more about the packaging and the PR stunts, not the quality of the actual product and its final impact on the user.

Will 2011 be better than 2010? Probably not. Will it be the end of days as some are predicting? Definitely not. Except maybe for more DDoS attacks that will get mainstream media attention, I expect the same level of insecurity across the board.

(anon) | ‎12-29-2010 01:10 PM

The separation may be illogical, but it is in itself genius. The commercial success achieved within the "security industry" has been nothing short of phenomenal. It would be great to see some figures comparing security industry earnings to those from other IT sectors. I imagine that it is something which has probably outperformed many other industries over the past years, regardless of how much its practitioners feel it has lacked in attention, spend and so on.


And it is in relation to this point, the commercial interest, which I believe will keep security separate from quality for a long time to come, as it has done for many years now.


I completely agree with trying to get security to work with the other disciplines. Working against or in isolation of, the other disciplines is a major fail. If you want to get someone to care about something, make them own it.  This is the only way to ensure that the security requirements of a company/project/etc are managed more effectively. The security resources then become a support function for other teams, instead of combatants. I've had some success in this area, but I've also seen many failures. Numerous excellent recommendations are available in Peopleware, but not all are suitable ;-)


Many evangelists have come and gone in my time, and maybe you'll have some success. However, don't lose faith if you don't reshape all of the multiverses. When Microsoft pushed their SDL back in 2004 (formally? Might have been a bit before that), many felt that would be the beginning of the end, that soon everyone would have their own tailored-to-fit SDL, and finally we would see light at the end of the tunnel with regards to critical vulnerabilities and so on. It's not just Microsoft which has not got there (get where, of course; destination is unknown, but the journey must be suitably comfortable for the passengers), there are many others that will make progress slower or faster than Microsoft; I've simply used them as an example as a company that went from having major problems, to trying to solve them, and now continues to have said problems, but their processes are better managed and they have nice KPIs and detailed metrics to go with the problems :-) All useful stuff, for sure, and it should make things better in the long run. However, as you say, you'll need some good luck in 2011 and beyond.


Well beyond! And good luck!

(anon) | ‎12-29-2010 08:09 PM

Great Post!


One major thing I have learnt trying to drag an org kicking and screaming towards a better software security program is that we need the developers and QA people a hell of a lot more than they need us. They will continue to meet their business objectives and deliver applications on time, with us, or without us. Kind of frustrating to realize.


Once I realized that I needed to sell them on what I could do for them, my whole game plan changed from trying to fix problems on the tail end, to selling education on the front end.Once they start to see how we can impact the end results of their work in a positive way, the tide starts to slowly shift from them seeing security as a time sink, a hurdle or a straight road block, to them seeking us out because what we help them do makes sense to them. it's a beautiful thing to see that tipping point. that point where the culture shift becomes noticeable and now security is something they WANT to do, actually NEED to do.


i;ve seen it blossom from the ground up several times and its NEVER come from the security team. sure we show them things, we teach them, but the change in a orgs culture to one of proactive software security always comes from the devs and QA folk. regardless of how much we push in security or how much management mandates things, the actual change comes from the Dev/QA folks. it's a special thing to witness in our business when a whole team of people "get it". We might be the catalyst (infact we MUST be) but they progress the change.


So my advice is build relationships with the team leads, managers and especially the devs/QA people in your org. Present to them on software security. Give demonstrations, lunch and learns, brown bags what ever you call them. Show them the places you can make their lives simpler and easier. Show them the tools you use, empower them to scan their own apps, scan their own code. Get elbows deep, side by side in their code. It's these relationships that will help your program progress, not reports with XSS/SQLi etc etc.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
About the Author

Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation