Band aids, Hospitals, and Broken Dreams

I’ve long held that the real measure of a software engineer is about knowing when to put a band aid on a problem and when to take it to the hospital. Bleeding to death from a wound, while musing about how things ought to be different is useless.  In the same way, putting a band aid over internal bleeding will also lead to demise.  The real trick is about knowing when to patch something and when to gut it.  This has long been the hardest part of programming for me.

Luckily I’m not alone.  I also find that this is a common stumbling block for providing valuable software security recommendations.  Some security folk like lament over broken secure software development processes (SSDL), while others still are content with “virtual patches” and WAFs.  Neither of these approaches are 100% right, neither of them are 100% wrong.  Both can be applied equally inappropriately.

To the SSDL camp (of which I am a member), vexing over broken process is fairly useless when some places don’t even have a process to speak of.  Couple that with companies that are facing real security issues and limited budgets/staff and we have a trifecta of poop.

Sadly, many of the recommendations in this camp tend to live in the world of the ideal even though so very few of us actually do.  Most companies aren’t Microsoft or Google, they are more often individuals who were stuffed into a role they weren’t comfortable with and made due.  Therefore, any recommendation that doesn’t account for those realities will fail.  Period.

On the flip side, “virtual patching” as a means of long term fixes to a product can be equally failing.  I just watched a presentation yesterday about attacking a well known CMS system.  Many of the attacks took advantage of problems that have existed for 2 or 3 versions of the product!  The patches offered by the development team tended to focus on shutting down routes to the problem, but didn’t focus on changing the structural and design problems of the code that caused them.  Fail. 

WAFs are whole different topic.  In short, I don’t believe you can fix programming problems by throwing more programs in front of them.  These products have been found equally failing for many of the same reasons.  Making the cost of entry higher, i.e Algebra II instead of Algebra I type vulnerabilities, doesn’t mean you’ve fixed a damn thing.  That said, it’d be unfair to not point out that some WAFs can reduce the total number of garbage an app deals with.  They can, sometimes, buy you the time you need to fix real problems.

This is not the silver bullet you were looking for.

So what does this all mean?  My suggestion is that you have to meet people where they are at.  If a production application is riddled with major issues, that HAS to be the primary focus before we can move on.  High risk problems in an application can be deadly to business. 

If they have more apps then they can fix and address at once, maybe getting some help (such as a WAF, additional staff, consultants, etc…) to buy or reduce time is appropriate.  The goal is to stop running around with your head cut off & fix the first most important problem first.

When world of fire drills are less firey, then what?  How about looking into how a development team might be able to –not- create such a headache for themselves again?  Train them on the most common problems (OWASP Top 10?), review their process (or lack there of) and help give them pragmatic approaches to how they can improve, teach them how test and verify their code so that they don’t get all buggered up again.

Every recommendation is going to be a little bit different.  Canned ham solutions don’t fit well into a world that’s free range turkey.

Post a comment or leave a trackback: Trackback URL.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: