The (Hidden) Cost of Security Fixes in Enterprise Software

Tuesday, May 29, 2012

Rafal Los


Sounds like a simple question, with a simple answer... right?

Who should pay for fixes that are necessary to patch security defects in software?

Without thinking the answer should be - the vendor.  I think the unanimous answer must be that vendors are required to fix security bugs in their code - but as we've seen with Microsoft and other vendors, there is a limit to how long vendors support their code.  

Furthermore, there are issues with implementation of fixes - even critical security fixes - in a production environment.

The question is much deeper than whether security fixes should be made available, free of charge, for software components that are found to contain security issues. There are more costs than simply acquiring the fix here, which is where the conversation changes.

There are processes that vendors have in place to receive disclosure from the community, validate issues and start to prioritize fixes... at least a good majority of large software vendors have these types of mechanisms.  They aren't free, and the cost to operate one of these groups is proportional to how many software packages the vendor has, and how buggy the releases are.  

More bugs, more releases means that more people will be required to staff the CERT-like function... this shoots costs of support up.  So if you're paying support costs for a piece of software, odds are you're actually paying for the security fixes in a round-about way... think about that.

Now, let's factor in all the other things that go with a security fix.  For example, the often forgotten costs of applying fixes into production environments.  The resources required to maintain buggy software, especially with security issues, raise the cost of support internally for an application.  

Now as an organization you're paying twice!  The first cost is the support cost you're paying to the vendor to release security fixes, and the second cost to build expertise into your operations teams for deploying these fixes to a production environment so as not to cause catastrophic failures due to these fixes.  

Let's not even get into what happens when a security fix breaks functionality that your business depends on... that's an entirely bigger ball of wax.

So who's really paying for all the security fixes going into the software you buy?  Odds are it's you.

Identifying the issues isn't nearly as hard as figuring out what to do next.  Working for a large software vendor I can tell you that our customers hold us accountable for not only having minimal security bugs, but also for the stability and cost-efficiency of support both internally and through our support packages.  

This has driven wonderful changes that I'm happy to start talking about.  It's amazing how many times in the last few years I've heard an internal program or product manager ask me for support in finding the right tools, processes, and people to reduce security defects in software they produce.  

You could call this the cost of doing business - but I think it's more than that.  I think it's many of our customers waking up to the fact that security defects in software costs real money and that it's not something that can be brushed under the rug and forgotten.

Over the next few months I will be digging more into the processes and people who are helping build better, more resilient software here at HP Software... but I urge you as the buyer to go to your vendors and ask them what they're doing to produce better software?

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Enterprise Security
Enterprise Security Budgets Application Security Software Security Assurance Costs Critical Patch Updates vendors Debugging updates
Post Rating I Like this!
Mike Harris I highly recommend the book "Geekanomics" by David Rice. In the book, he discusses the costs of software insecurity and how software makers push the costs to the consumer.
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.