Avoiding the Top 3 Application Security Mistakes

Wednesday, January 26, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

It happens one day, seeming out of nowhere.  Your manager has a revelation (usually inspired by an incident, or the board of directors) and walks into your cubicle and says "We should put together an application security program". 

Now what?

Let's be realistic here for a moment - you're understaffed, overworked, and ill-prepared to roll out a software security assurance (SSA) program overnight so how do you avoid making some of the biggest mistakes? 

Let's look at the 3 most common mistakes hasty organizations make and see if we can't help you avoid these. 

Look, it's bad enough that you're starting up a software security assurance program in January 2011 (while everyone else you know got funded back in 2007!)... let's not make this any more painful than it's already going to be.

Here the Top 3 Mistakes you'll want to avoid...

1. Buy a Tool and Start Testing - Sometimes, the most direct answer is not the right one.  Many security organizations feel like if they could just get some tools bought and in the hands of security analysts it would force the organization to act. 

It all sounds so simple - start scanning and producing results.  Well, in the real world we know that this causes friction, tension and other undesired effects.  Fire, ready, aim is rarely a good battle strategy, especially if you want to declare victory at some point. 

The most important step - before you purchase anything and start scanning away is to develop a process for what's going to happen with the results and how you'll handle the inevitable conversations that will result. 

What if you...no, ...What happens when you find a critical defect that should be a show-stopper?  What happens when each and every application you scan has hundreds of defects?  Are your developers prepared to start remediating the issues you find, and more importantly - do they even understand what they're looking at in that 300+ page results PDF? 

These are all things many security organizations completely neglect before they unleash the dogs of war on their applications.  Finding vulnerabilities isn't that big of a deal, I can virtually promise you that you'll find something in each and every app - more important is what you will do next.  If you're not prepared for that "What now?" conversation, don't even bother evaluating tools or pushing that "Scan Now" button.

2. Don't Engage the Development Organization - You want guaranteed failure in a SSA program?  Ignore the fact that it's the development organization that will be making the software fixes.  Whether you're outsourcing your code development, or you're building your code in-house, or some mix thereof, ignoring your development organization's importance is a sure way to miserably fail. 

You cannot reasonably expect to take application security analysis results and hurl them over the proverbial wall into the developer's world and expect something magical to happen. It won't. In fact, 9 out of 10 times the mass of bits you just sent over will be ignored, or worse, misunderstood. 

You'll either get the "that's not my problem" answer or you'll get millions of excuses why code can't be made more secure.  Experience has taught me that you simply cannot beat, shame or threaten development organizations into producing better quality, more secure code. 

You know how you can make it happen? Engage that organization and make sure that they're a key stakeholder in the process, that they get a say in the company's SSA strategy.

3. Make Uninformed Risk Decisions - The shortest distance between you and zero credibility is the word no...repeatedly.  For many years a security group I used to work in was politely (and sometimes not-so-much) ignored. 

Why?  Because when we weren't around the rest of the business called us the department of "no".  Everything was black or white, there was nothing left to interpretation and no shades of gray.  Either a vulnerability existed and the application was insecure, or it did not exist and the application was secure. 

Insecure applications would not receive the security organization's sign-off for production readiness... this would result in epic battle scenes in hallways as projects fought for the right to go live and meet their business-mandated deadlines. 

The security organization's repeated, uninformed risk decisions put such a hurt on credibility that eventually we were taken out of the critical path of production sign-off... which basically meant that we could formally be ignored. 

All this because we never took the time to sit down on a project by project, application by application, defect by defect basis to determine what the business was going to be able to live with and what needed to be mitigated.  We couldn't make our peace with what was good versus what was good enough ...and that failed us for a long, long time.

So there you go, mistakes not to make... and if you find that you're making these today - even subtly - halt and change course because it may not be too late.  Take it from someone who's been doing this since '99... and failed many, many times over - you don't have to fail to get it right.  Avoiding these 3 most common mistakes is a great way to avoid certain doom.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
13377
Webappsec->General
Application Security Security Strategies SaaS Vendor Management 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.