Can you believe it - we are already on day 29?  This month has gone very fast and we are scurrying to the end of the road.

Today's question is Should I Switch Software Vendors? 

This topic was a bit perplexing to me when I first read it.  As I began to think about the question in the realms of Recovery, I began to ponder the answer. 

If we are talking about OS's - does it really help to switch software vendors?  Does it really solve anything?  Is one company really any better than the others?  And how much of the problem was caused by us and our failure to perform the recommended updates, security patches, and close the holes as recommended by the vendor or the Security World? 

If we are talking about applications be it Security or Network Monitoring software that may be a different story. If the application you were using didn't perform as expected perhaps it is a good time to take a look at what the competition is offering.  However, again - we can't blame the application if we didn't do the vendor recommended updates.

There are so many different types of sooftware that could be discussed.  There are pro's and con's to all of them.  What works for me may not work for someone else in their environment.  Another concern that I would have is at the time of recovery - you may not have a lot of time to learn a new product.  This may lead to a failure in securing the system adequately. 

We would like to hear from our reader's.  What is your opinion on this question?  Should you switch software vendors and under what conditions? How do you decide what to switch too and how do you determine that it will be any better than what you were using?

Let us know what you think.

Update

We have received some really good feedback from some of our readers.  I thought I would share some of it.

From Glenn

One important thing to consider during a recovery is if changing any software directly impacts any policy compliance. Do you have product evaluation criteria, customer requirements or documentation requirements? Changing the software may fix a single issue but may open up a whole host of other issues which may knock you out of compliance.

Good DR planning, documentation and procedure will go along way. I think it's better to plan a software change when you are not in an emergency situation and you have time to think about the original requirements you had of your software and results you need.

From Gary K

Changing software vendors, in general is only a benefit if it offers a more robust security venue for your environment. Its not a cure all for all organizations, but it may benefit some. Should your environment need a change because it is tagged by a hacking group who normally can get in with much trouble?

Changing the Router/Firewall company/IOS will make a difference. But as a last line of defense, a software firewall and antivirus combo that works well with each other might be the trick. Dont forget - changing software may not be the issue - it may be the configuration of the software that may be the weakest link. It boils down to Risk Assessment, and budget.

From an anonymous contributor

In terms of InfoSec and Incident Response I seek to build all of the following into SLAs/contracts:

1. Active vendor availability - Real phone numbers answered by real human beings. Call centers in North America, with escalation pathways to product management/engineers when L1 "scripts" are insufficient. I live and work in North America. I expect vendor Support and Response to clearly speak and understand my language, fully understand my culture/customs and be "local" to me (as in be on the same continent). All of these things matter in the real world. The vendor must commit to supporting their products in virtualized operating environments.
2. Active vendor participation - Bug/defect/scenario reporting can be very powerful in this era of virtualized operating environments. My SW licenses must include support for this option of defect reporting as a courtesy. If I can deliver a VM (or set of VMs) that reproduces a critical defect/bug with InfoSec implications, I expect the relevant SW vendors to accept delivery of those VMs and for them to carry on the chase into their lines of code and configuration matrices. No modern software runs in an isolated vacuum. Interoperability is a real-world need and competitive advantage. When more than one SW vendor is involved, I expect multiple SW vendors to co-operate in said BugHunt, across boundaries (company and code), in order to find mitigatations from all materially participating sides of the problem. This can be done without loss of proprietary IP and can be a win-win for all.
3. Active vendor accountability - Delivering timely working patches and/or work-arounds has to be the ultimate result.  ... If a vendor will not agree to mount "Best Effort" on all three fronts, I will not recommend, specify or buy from them. If specific terms of compliance/performance are not carried out in practice, there will be contingency agreements for refunds, credits and/or termination without penalties.

From Chris

Very tough question to answer because it is environment specific. In general, there are two options that should be considered for every project that represent the ends of the spectrum: "do nothing" and "rebuild from scratch". In reality, what usually happens is somewhere in between. My opinion (again in general) is that OS switching is actually easier than most people make it out to be. There seem to be more religious and political reasons than pure technical reasons not to utilize multiple OSs. Well established, effective sys admin and patching procedures are adaptable between AIX, HP/UX, Linux, OS X, Solaris, Windows, etc. Each one has quirks. Each one has strengths and weaknesses. Effective network and sys admins can adapt to these quirks. The problem I have most often seen is that personal, political or <sarcasm> religious </sarcasm> preferences skew choices from objective decision making. Often, the choice is decided by what application is going to be run on that system. Relying too heavily on one OS may diminish the IT/Security group's ability to have choice in what products it elects to use. I think an interesting outgrowth of the singular OS culture is the "appliance" offerings from vendors. The vendors have accepted the OS maintenance (of usually Linux) in exchange for the ease of developing on (and controlling) their OS of choice.