Paying for Risk: The Hidden Dangers of Software Acquisition

Saturday, April 02, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

First, a little trivia on risk... Here are two facts I'm willing to bet you didn't know...

  • It is more dangerous (for parents) to own a pool than a hand gun if you have children in the house
  • It is more dangerous to walk than drive drunk, if the aim is to keep yourself alive

[Cited from "Super Freakanomics" by Levitt & Dubner]

What relevance to Software Security Assurance or Enterprise Security could those two facts possibly have, you ask? Primarily, they highlight misconceptions, or rather 'common knowledge' that is just plain wrong.

This actually applies to Enterprise Security, more specifically your Software Security Assurance (SSA) program, in the enterprise quite directly in the form of hidden dangers brought on by often-forgotten pieces of the enterprise software story.

While few organizations ignore the obvious need to secure their enterprise software development lifecycle, an all-to-large percentage still largely ignore the software they're paying for and using in their enterprise.

Purchased software is no less risky than software you develop yourself (or have developed for you directly)... so why do executives and purchasing departments seem to assume that there is less risk there? The answer is as complex as it is simple...

First off - when you're purchasing something there is always an unwritten assumption that the party you're purchasing from has sold to many customers (not just you, or so you'd hope) so someone out there must have surely vetted the vendor... right?

This isn't to say that purchasing departments and managers aren't thinking about security - or aren't trying to write it into their contracts (or are they?) but from conversations with people in these roles it is clearly not top-of-mind when it comes to negotiation on delivery.

Security is simply still viewed as 'someone else's job' and what makes this such a dangerous assumption is the risk being assumed, without proper analysis.

Next, there's the issue of analysis capabilities. If you're buying software from a vendor and cannot get that vendor to commit to demonstrating security vigilance... but the business ultimately needs the software, you're stuck doing the analysis yourself as the security professional.

That rarely works out because you probably don't have the source code - OK, you'll probably never have the source code - and don't have the in-house talent to do a thorough assessment on the binaries or running application (in the case of a web application) yourself.

So then what? You're forced to assume risk you can't fully comprehend and hope for the best... not a good situation.

So - here you are, paying for the privilege of assuming more risk... that's just not right!

The obvious question is - What can be done? There are few options in situations like this - but there are options!

There are many opinions and ideas about how to solve this very critical issue for the enterprise - but I think this one makes sense both from an economical, risk and security perspectives.

When all things are considered, the best course of action is to find a trusted partner (an organization with a successful track record testing and securing software in your vertical) to validate risk tolerances and security posture of the software you're acquiring.

There are a number of models that can be used here, I'll address two directly below, but they primarily rely on having a trusted partner who can provide flexible and economical risk analyses on a scale that will satisfy your budget and acquisition rate.

Let's discuss these two approaches here ...

Vendor-driven Assessment

The vendor-driven assessment model states that a vendor provides an artifact of 'risk assessment' to the customer upon purchase of the software in question. In this model, the customer has mandated, usually via a contractual condition of purchase, that the vendor provide hard evidence that the software has been assessed and properly vetted before accepting the software.

Customers typically protect themselves by picking up to 3 trusted assessment partners and giving the vendor a choice of the 3 - but requiring the vendor to use one of those to produce a report, which is obtained directly from the assessing partner. This type of engagement model gives the vendor flexibility and the customer protection against acquiring unnecessarily risky software.

Consequently this is the most popular engagement model. The key constraints and challenges for the customer is finding a set of trustworthy vendors who can assess binary applications, source code, or web applications and provide valuable risk information in the context of their business.

A great model is one in which the assessing vendor essentially is a mediator between customer and vendor by giving the customer a 'risk score' for the application or software being acquired while providing detailed vulnerability and fix information to the vendor.

Look for security partners that have a wide bredth of support for languages, frameworks and business models -and that understand your business and can assist you long-term.

Customer-driven Assessment

The customer-driven assessment model states that a customer accepts responsibility of performing a 'risk assessment' of the software being acquired.

In this model the customer accepts the software or application on a contingency basis -provided that the assessment done by the partner security assessment organization is clean, and when not the vendor is required to mitigate a mutually acceptable amount of defects for customer and vendor.

This engagement model gives the customer full control of the process but is typically less acceptable by the vendors as the vendors will rarely want ot hand over their source code or allow full-on assessments or reverse-engineering of their code to determine security defects present within.

As above, make sure you pick a security assessment partner that has the bredth of support you need, and the analysis speed and capacity required for your business... you don't want to be stuck in limbo for a month while your assessment partner analyzes the code for security defects as that's rarely acceptable to the business.

Benefits

The benefits of either of these models are clear, and mutual to the vendor and customer. In either case the benefit to the customer is a much more quantifiable and sure assessment of risk for the software or application being acquired. There is a welcomed side effect too, as this is multiplied to other customers of the same vendor!

Furthermore, these types of assessments can be used by customers to more favorably negotiate acquisition costs for software or applications... when a larger risk (a known risk!) is being acquired a percentage discount can be asked for... or other concessions can be made intelligently.

The vendors also benefit -more secure and security defect-free software leads to less compromises and chain-reaction lawsuits... which is always a good thing to everyone involved.

Call to Action!

If you're not already assessing the software you're acquiring - now is the time to act. Many organizations forego a Software Security Assurance (SSA) program simply because they don't develop their own software and are missing the risks of the software or applications they are purchasing - don't get caught with this type of risk.

Rather than worry about being the next media headline - trust your software whether you've built it or bought it ...and have better trust in your vendors too!

Cross-posted from Following the White Rabbit

Possibly Related Articles:
14341
Enterprise Security
Software
Enterprise Security Risk Management Vendor Management SSA Software Security Assurance Acquisition
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.