Auditing vs. Secure Software - An Inconvenient Argument

Monday, September 19, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

The world of software security can be a peculiar animal.  Often times we find ourselves arguing with each other over the strangest things. 

Software Security is no stranger to confusion, but the events of the past week between a software titan and a software security service company can only be described as... well, weird.

If you haven't paid attention to Twitter or popular social media recently, you may have missed one of the strangest exchanges I think I've seen in a long while.  An out-of-the-blue scathing blog post by Oracle's Chief Security Officer prompted a swift response from VeraCode's Chief Technology (and Security) Officer. 

What brought this on is anyone's guess... but the fiery tone of the article is fairly typical for Oracle.

Before I get into this post, let me first do a full disclosure in case you don't know.  HP not only sells enterprise software, hardware, and services but we also provide software security assurance technology, education, and services - including auditing of 3rd party code via our Fortify on Demand Vendor Portal application. 

We have many happy customers who have saved themselves headaches and millions of dollars by utilizing our services, and built themselves robust sSDLCs through our technology and services.  OK, enough of that, disclaimer done - we've got a horse in both sides of this race.

I honestly don't care much for the war of words between the two,  it's unprofessional at best to go into this type of drama in public.  So instead I'd like to point out that while the two are firing rockets at each other, they're largely missing the point here.  I think Chris hits the point I'm referring to, but it's way too far down in his post to be useful.

To quote Chris: "There are third-party tests and assessments for perhaps every important purchase in business or in our personal lives." And that is a very powerful statement, I would have opened the post with that. 

Forget whether or not Oracle really gets security and really is unbreakable, or whether VeraCode actually does anything to improve software security in organizations in the long run... the big point here is that when you, you the person, go to spend a wad of money on something you're going to absolutely not take the vendor's word for it that they're doing right by you.  I mean, who's interest is that statement in, anyway?  Certainly not the buyer's.

Let me break this down into a few important points.

Auditing

I absolutely can't believe that Oracle's post completely misses the point on auditing.  If we lived in a society of implicit trust SOX wouldn't be such a big requirement for financial auditing, the Payment Card Industry Data Security Standard wouldn't have spawned a multi-million-dollar auditing industry, and lots of my colleagues would be out of a job. 

The days of implicit trust came crashing down with Enron's failure, and quite frankly should have come down long before that.  You see, I've been around humans, not to mention corporations, long enough to know that while we'd all like to believe they're honest and have our best interests at heart - many of them lie, cheat, and steal every chance they get to make a buck.  I don't need to name names, do I?

Why is it that if we don't trust our financial officers not to "cook the books", we should trust their companies with our security?  Answer: we shouldn't.  This is the same reason when I bought my first used car so many years ago I took it to a mechanic I trusted, and had him look the car over for $100 to make sure it was as sound as the dealer said it was (and it wasn't, shocker). 

I don't expect anyone to buy a house without hiring a home inspector, as Chris points out in his post - so why is this somehow different for a high-dollar software purchase?  Asking a 3rd party to audit your company's code before the buyer signs on the dotted line is just good business practice, and if you're offended at the notion my only logical conclusion is you have something to hide.

This doesn't necessarily mean you should just give your source code over to anyone - there have to be controls over these types of things.  I certainly agree with Oracle's assertion that one company can't just control the wealth of software vulnerabilities without any auditing of them because who's to say their practices are ethical?  There needs to be an established methodology and formalized accreditation for doing this type of auditing, and while it makes me cringe, yes - it should probably be controlled by an independent and (as much as can be) impartial body and audited regularly by that oversight group.

Building

Completely apart and separate from auditing software, is the secure Software Development LifeCycle, aka "building".  Just like you can't audit your way secure, you can't build your way to independent assurance.  Building software requires more than just an audit, and while I don't think Chris's post ever says that auditing magically creates secure software - their service doesn't really do that either... which is weird that the two companies appear to be arguing different points so passionately. 

Anyway, The only way to build secure software is to in-source that, completely.  I believe you can't outsource security, and I stand by that.  A 3rd party can't possibly show up and tell you how to write more secure applications... unless they've become part of your processes and that by definition is a significantly bigger role than auditing.

Building secure software is something that big companies have been getting hammered for... since I can remember.  Look Microsoft was the fist big one to get absolutely pounded for it -and through a lot of hard work, a change in culture, and more importantly a willingness to prioritize security openly they turned that ship completely around. 

They're actually doing quite a good job at it right now, and it's widely acknowledged that Adobe is following the same path.  I'm not sure I'd stretch it and say that Oracle has done anything more than pounded their chest and talked big... their 'Unbreakable' campaign was a perfect example.

All I'm saying is that a little more humility and recognition that we as an industry have a long way to go to reach 'good enough' security in our software is needed ...and less lashing out at people trying to make a business out of it.

So building a Secure Software Development LifeCycle takes stuff... stuff like educated people, the right processes for your organization and business model, and the right technology at the right time.  That means software that helps us manage security requirements, blends into the developer's IDE to help audit code as its being written for bugs, and software and potentially services to double-check our work before we stamp it ready for public sale. 

If you're not involving all that, then yes - all you're doing is piling bugs into reports that don't contain actionable intelligence... which is doomed to fail.

Peanut Butter and Jelly

Building and auditing are like peanut butter and jelly.  You need both to make a tasty sandwich.  You need knowledge and technology to help you build software that has less bugs discovered when your buyers audit it later.  Furthermore, you should have processes that take those 3rd party discovered bugs and feed them into a tracking system that ensures they're identified, verified and remediated in a time that is appropriate to their severity.  Otherwise... why are we even doing this?

Personally, I think they should make up... it's really ugly to see.  Besides if your customers are asking to audit your code, maybe it's because they checked Bugtraq or another bug tracking list and noticed you have thousands of critical issues that are remediated at glacial paces - and I'm talking to everyone out there ...everyone - and maybe, just maybe, your customers are looking out for themselves?

Companies that sell software have a few simple ways to get through this type of audit requirement.  They can fight it, and hope their customers don't go buy from some vendor that is willing to play along, they can do an audit every single time, or they can do regular 3rd party audits by a trusted company and send those out when ever requested. 

Personally, I'd think the 3rd option is cost-effective for the software house, and good enough for most customers.

See, now can't we all just get along?

Cross-posted from Following the white Rabbit

Possibly Related Articles:
9664
Webappsec->General
Software
Oracle Application Security Security Audits Network Security Software Security Assurance VeraCode
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.