A discussion came up at work recently and a debate ensued regarding choosing a vendor. Several people were of the opinion that it is smarter and easier to choose a single security vendor for all our needs (lets say for example McAfee as they offer a large number of different products(and lets imagine that they don't just buy different companies and re-brand their kit)). I however have always been of the opinion that purchasing for multiple different vendors and buying exactly the device you need for the job your trying to fix is the better way of doing things.

Obviously central management is possible when using a single vendor but at the same time, that single console might control all your security devices which means if its compromised, your really screwed.

What are the pros and cons of choosing multiple vendors vs a single 'partner' vendor from a security standpoint?

  • 3
    Also, 8,000th question! :D Congrats sec.se! – NULLZ Apr 15 '13 at 0:24

In no particular order and off the top of my head:

Single vendor:

  • easier and faster relationships
  • (usually) better integration of different products, provided they're not rebranded kits
  • simpler to "pass the buck" if products A and B don't see eye to eye - they're both the same vendor's responsibility.

Multiple vendors:

  • less risk of vendor lock-in
  • more competition, therefore possibility of lower prices
  • more difficult to keep track of licenses and contacts
  • risk of work duplication between different products (company A has a product that performs 1, 2, 3; company B has another performing 3, 4, 5. Task 3 may in some cases (e.g. antivirus) even lead to conflicts).
  • more possibility of precise tailoring of each product to your needs

As you see, the multiple vendor solution appears to have more "cons" - but these points shouldn't just be counted, they ought to be weighted in every specific situation. Also, most points are hypothetical, they are risks or opportunities, and whether they occur or not depends on the vendor(s) and situation.

I believe that neither option can be recommended a priori.

The man-hours and cost of maintenance is more or less proportional to the number of vendors, all other things being equal, but the savings (in price, resources, maintenance and productivity) are in percent, and therefore proportional to the number of installations and company size.

In a large company, with workforce and procedures to leverage, and a bigger budget, probably the multiple vendor option has chances to be better. A smaller firm, maybe without a true role dedicated to security, would probably find more convenient to negotiate a single offer and forget about it until next year's assessment.

From a security standpoint, I believe that what really counts is the product ecosystem: what products are really from any given vendor (instead of products rebranded and, perhaps, only maintained by the skeleton crews that survived the original company's acquisition), how they are supported and the vendor commitment to those products: best of all would obviously be a company that guarantees strong support to all its products, not only "flagship" or "developed-here" ones.

In my experience, "acquired" products are comparable to the original for the first version, appreciably worse for the next release(s) (when the acquiring company tries to shoehorn the product into its own shape, e.g. changing the UI or moving config files to XML and such), then improve steadily (or get ditched) as the programming teams get their act together.

What really makes the difference (but this is my own limited experience) is how much time (and budget) you can devote to following the products - checking updates, security alerts, browsing the forums, and maybe run some tests yourself on the side. How much the vendor ships a product because it believes in the product, instead of keeping it up so that they can make a "complete offer".

Usually, checking the contact pages and inspecting product and update history is enough to assess the level of commitment that product enjoys.

There is usually an argument about "biodiversity" in security products, that more or less boils down to:

  • several products from the same vendor and code base are likely to share the same vulnerabilities.
  • different products may have a "security overlap" so that what is not protected against by the one, will be intercepted by the other.

I believe that both points are close to moot (except insofar they descend from the vendor's attitude, if you will):

  • several products sharing common code will have that code tested harder, longer and better, and the bugs in there will be fixed once and for all. While different implementations of a same algorithm, sharing a conceptual vulnerability, will likely lead to staggered fixes and several vulnerability windows.
  • two products having an "overlap" is the same thing as either conflicting products or duplication of effort. If I want overlap, I purposely buy two products so that I can control the overlap - instead of relying to a chance duplication, whose extent might not even be fully known (because two products from the same vendor will have two different focuses; the overlap then will likely be in the "peripheral vision" area of both. If it's something that comes for free, an extra, I can enjoy it; but rely on it? Think again).

Here, again, these factors have to be assessed vendor-wise and considered in the light of your company's policy, budget and needs.

| improve this answer | |
  • Okay, that makes sense from a business perspective, but i'm curious about it from a security view. Is either option more or less secure than the other? – NULLZ Apr 15 '13 at 14:21
  • I'm afraid that the answer is still "it might be either"; it will depend on several factors. I've tried to list as many as I could think of, but you'll have to see how, and how far, they fit in each case. – LSerni Apr 15 '13 at 18:29

I work as a vendor in one of the world's biggest company. And the way that company has divided work (Security) is like they have given to multiple vendors designated to one part.
Like they have given the web servers related tasks ( Qualys and other scans) to one vendor.
Web Application Reviews to another and like this.

And I really feel this is a good way to divide your responsibilities.

| improve this answer | |

When you do your product selection the total cost of ownership may lean you towards a single vendor if operations are simplified, but each vendor has their strengths and weaknesses so it is likely your needs will best met by multiple vendors.

Going for the one vendor is no guarantee of seamless integration in any case, since as you point out often these product stables have been cobbled together from a number of separately developed solutions.

| improve this answer | |

It definitely is better to chose a multi-vendor approach. Single-vendor solutions tend to lack in many areas. They ride on the power of a single product that is good and than sell you crap. Since most single vendors also acquire other companies there are no cost savings in single management platform. This article did a great job in summarizing this viewpoint: http://www.drchaos.com/the-great-tragedy-of-single-vendor-solutions-why-best-of-breed-is-best-of-class/

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.