We have discussed the evolution of vulnerability management from a tactical tool to a much more strategic platform providing decision support for folks to more effectively prioritize security operations and resource allocation. But some vendors may not manage to effectively broaden their platforms sufficiently to remain competitive and fully satisfy their customer requirements. So at some point you may face a replacement decision, or to put it more kindly, a decision of evolution or revolution for your vulnerability/threat management platform.

Last year we researched whether to replace your SIEM/Log Management platform. That research provides an in-depth process for revisiting your requirements, re-evaluating your existing tool, making a decision about whether to replace or not, negotiating the deal, and migrating to the new platform.

If and when you face a similar decision regarding your vulnerability management platform the process will be largely the same, so check out that research for detail on the replacement process. The difference is that, unlike SIEM platforms, most organizations are not totally unhappy with their current vulnerability tools. And again, in most cases a revolution decision results from the need to utilize additional capabilities available with a competing platform, instead of because the existing tool simply cannot be made to work.

The Replacement Decision

Let’s start with the obvious: you aren’t really making a decision on the vulnerability management offering – it’s more of a recommendation. The final decision will likely be made in the executive suite. That’s why your process focuses initially on gathering data (quantitative when possible) – because you will need to defend your recommendation until the purchase order is signed. And probably afterwards, especially if a large ‘strategic’ vendor provides your currently VM scanner.

This decision generally isn’t about technical facts – especially because there is an incumbent in play, which may be from a big company with important relationships with heavies in your shop. So to make any change you will need all your ducks in a row and a compelling argument. And even then you might not be able to push through a full replacement. In that case the best answer may be to supplement. In this scenario you still scan with the existing tool, but handle the value-add capabilities (web app scanning, attack path analysis, etc.) on the new platform.

The replacement decision can be really broken into a few discrete steps:

1. Introspection: Start by revisiting your requirements, both short and long term. Be particularly sensitive to how your adversaries’ tactics are changing. Unfortunately we still haven’t found a vendor of reliable crystal balls, but think about how your infrastructure is provisioned and will be provisioned (cloud computing). What will your applications look like, and who will manage them (SaaS)? How will you interact with your business partners? Most important, be honest about what you really need. It’s important to make a clear distinction between stuff you must have and stuff that would be nice to have. Everything looks shiny on a marketing spec sheet. That doesn’t mean you’ll really use those capabilities.
2. Current Tool Assessment: Does your current product meet your needs? Be careful to keep emotion out of your analysis – most folks get pissed with their existing vendors from time to time. Do some research into the roadmap of your current vendor. Will they support the capabilities you need in the future? If so, when? Do you believe them? Don’t be too skeptical, but if a vendor has a poor track record of shipping new functionality do factor that in.
3. Alternatives and Substitutions: You should also be surveying the industry landscape to learn about other offerings that might meet your needs. It’s okay to start gathering information from vendors – if a vendor can’t convince you their platform will do what you need they have no shot at actually solving your problem. But don’t stop with vendors. Talk to other folks using the product. Talk to resellers and other third parties who can provide a more objective perspective on the technology. Do your due diligence, because if you push for a revolution it will be your fault if it doesn’t meet expectations.
4. Evaluate the Economics: Now that you know which vendors could meet your requirements, what would it cost to get there? How much to buy the software, or is it a service? How does that compare to your current offering? What kind of concessions can you get from the new player to get in the door, and what will the incumbent do to keep your business? Don’t make the mistake of only evaluating the acquisition cost. You should factor in training, integration, and support costs. And understand that you may need to run both offerings in parallel during a migration period, just to make sure you don’t leave a gap in assessment.
5. Document and Sell: At this point your decision will be clear – at least to you. But you’ll need to document what you want to do and why, especially if it involves bringing in another vendor. Depending on the political situation consensus might be required among the folks affected by the decision. And don’t be surprised by pushback if you decide on replacement. You never know who plays golf with whom, or what other big deals are on the table that could have an impact on your project.

And ultimately understand that you may not get what you want. It’s an unfortunate reality of life in the big city. Sometimes decisions don’t go your way – no matter how airtight your case is. That’s why we said earlier that you are really only making a recommendation. Many different factors go into a replacement decision for a key technology, and most of them are beyond your control.

If your decision is to stay put and evolve the capabilities of your tool into the platform you need, then map out a plan to get there. When will you add the new features? Then you can map out your budgets and funding requests, and work through the politics with your peers – VM platforms impact the network, security, and application teams.

But if your decision involves moving to another platform you will need much more planning and savvy about the migration. So let’s delve into some of those considerations in more detail.

Migration

Much of the complexity of migrating to a new vulnerability/threat management platform depends on how complicated your current environment is, which comes down to how much customization you have done. Have you built your own dashboards and reports? Have you scripted interactions with your help desk system? Are third-party data feeds integrated into the current tool? Do you send alerts and/or other data to an upstream aggregation point like a SIEM? If so those linkages need to be moved to the new offering, and even if everything goes well that still takes time – it might also require additional investment and resources.

A flash cutover never really works for a tool you use every day. If you are only using the scanner for weekly or monthly scans that might work, though – you get a window to deploy and test the rules, and tune the dashboards and reports, before it’s “go time” on the next set of scans.

But organizations which discover continuously and scan frequently need either an adequate window for cutover or a different approach. We recommend you start deploying the new vulnerability/threat management platform long before you get rid of the old. In the best case you can deprecate portions of the older system after newer replacement capabilities are online, but you will likely want the older system as a fallback until the new functions have been vetted. In our operational days we learned the importance of this staging process… the hard way. Ignore it at your peril – keeping in mind that your vulnerability/threat management platform underlies several key security and network operational functions.

We have broken the migration process into two phases: planning and implementation. Your plan needs to be very clear and specific about when things get installed, how data gets migrated, when you cut over from old systems to new, and who performs the work. Especially who performs the work – you won’t get to forget about your other operational responsibilities while you migrate.

• Planning: First start the planning process by reviewing requirements and prioritizing the functions to implement. Focus your migration plan on getting some quick wins to build momentum early and demonstrate success. Once the major functions and associated milestones are defined, you can allocate resources, define timelines, and prepare for the migration. By ‘prepare’ we mean: define scanning rules, revisit device configuration policies, aggregate topology information, design dashboards and reports, etc. Do as much work as possible ahead of the actual implementation so once you start moving you can minimize the amount of recalibration during the process.
• Implementation: Once the plan is locked and loaded it’s time to move. That involves deploying the (virtual) devices, installing policies, setting up dashboards and reports, testing and verifying functionality (false positives are especially annoying when they are coming from a shiny new tool that was supposed to solve problems), getting acceptance from stakeholders, and finally decommissioning any other tools in use.

Once you have navigated the migration gauntlet you can kick back and enjoy the capabilities of your new platform to help prioritize your efforts, improve efficiency, and generally increase the security of your environment. Or so you hope anyway.

And with that we wrap up our Vulnerability Management Evolution research project. As with all the research built using our Totally Transparent Research methodology, we will factor in the great comments we have already received on the posts and package up the series as a white paper.