The focus of this series has really been talking about the evolution of vulnerability management from a tactical tool to a much more strategic platform to provide decision support for those folks needing to more effectively prioritize their security operations and more allocate resources. But you can’t ignore the reality that some of the vendors in the space may not be able to effectively broaden their platform sufficiently to remain competitive and meet the longer term needs of their customers. And that means at some point you may face a replacement decision or to put it more kindly, a decision of evolution or revolution on your vulnerability/threat management platform.
Last year we did a research project specifically focused on navigating the decision of whether to replace your SIEM/Log Management offering. That research presented an in-depth process to revisit your requirements, evaluate your existing offering relative to those requirements, make a decision about whether to replace or not, negotiate the deal, and migrate to the new platform.
As you face a similar decision at some point, the process will be largely the same, so check out that research for a lot more detail on the replacement process. The exception being most organizations are not totally dissatisfied with their current vulnerability tool, as they were with their SIEM. Again, in most cases, a revolution decision will result from the need to utilize additional capabilities added with a competing platform, as opposed to not being able to make the existing tool work.
The Replacement Decision
Let’s start by stating the obvious, you aren’t really making a decision regarding the vulnerability management offering – it’s more of a recommendation. The final decision will likely be made in the executive suite. That’s why you’ll see a process initially focusing on gathering data (quantitative where possible) – you will need to defend your recommendation until the purchase order is signed. And probably afterwards, especially if a big “strategic” vendor currently provides your VM scanner.
This decision generally isn’t about the facts – especially since there is an incumbent in play – which may be part of a big company with important relationships with heavies in your shop. So you need your ducks in a row and a compelling argument for any change. And even then, you may not be able to push through a full replacement. In that case, the answer may be to supplement. In this scenario, you still scan with the existing tool, but do the value add capabilities (like web app scanning, attack path analysis, etc.) on the new platform.
The replacement decision can be really broken up into a few discrete steps:
Introspection: You start by revisiting your requirements, both short term and long term. Be particularly sensitive to how your adversary’s tactics are changing. Obviously you don’t have a crystal ball, but you’ll want to think about how your infrastructure is provisioned and will be provisioned (cloud computing). What your applications will look like and who will manage them (SaaS). Interactions with your business partners. Most importantly, 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 data sheet. That doesn’t mean you’ll really use the capability.
Current Tool Assessment: Does your current product meet your needs? Be careful not to let emotion enter into the analysis, as 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? You don’t want to be overly skeptical, but if a vendor has a poor track record of shipping new functionality, that needs to be factored in.
Alternatives and Substitutions: You should also be surveying the industry landscape to learn about other offerings that can meet your needs. It’s OK to start gathering information from the vendors, since if a vendor can’t convince you their platform will do what it needs to, they’ve got no shot to actually solve your problem. But don’t stop with the vendors. Talk to other folks using the product. Talk to resellers and other third parties that can provide a more objective perspective on the technology. Do your due diligence because if you push for a revolution, it’ll be on you if it doesn’t meet expectations.
Evaluate the Economics: Now that you know which vendors could meet your requirements, what will it cost to get there? How much to buy the software, or is it a service? How does that compare with your current offering? What kind of concessions can you get from the new player (given it’s a replacement) and similarly, what will the incumbent do to keep your business? Don’t make the mistake of just evaluating the cost of acquisition. You should factor in training, integration and support costs. Also face the reality that you may need to run both offerings in parallel during a migration period, just to make sure you don’t have a gap in assessment.
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 may be required amongst the folks affected by the decision. And don’t be surprised by pushback if the decision is replacement. You never know who plays golf with whom or what other big deals are on the table that may have an impact on your project.
And ultimately understand that you may not get what you want. It’s an unfortunately reality of life in the big city. Sometimes decisions don’t go your way, no matter how air tight your case is. That’s why we said at the beginning of this post that you are really only making a recommendation. A lot of factors go into a replacement decision for a key technology, and most of those factors are out of 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 logically map out your budgets and funding requests, as well as work through the politics with your peers, as the platform will impact the network, security, and application teams.
But if your decision involves moving to another platform, then you’ll need to be far more planned and savvy about the migration. So let’s delve into some of those considerations in a bit 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 really gets down to the amount of customization you’ve done. Have you built your own dashboards and reports? Have you scripted the interaction with your help desk system? Are third party data feeds integrated into your 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 best case that takes time. It also may require additional investment and resources to get there.
Let’s be clear, a flash cutover never really is for a tool you use every day. If you are only using the scanner for weekly or monthly scans, let’s have a different discussion. Kidding aside, if you aren’t using the scanner every day, then cutover is less complicated. You’ve got 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 those that discover continuously and scan more frequently, not providing an adequate window for cutover will need to take a different approach. In this case, we recommend you start deploying the new vulnerability/threat management platform long before you get rid of the old. At best, you’ll 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 own 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 the old systems to the new, and who performs the work. Especially who performs the work, as we’re pretty sure you don’t get to forget about your other operational responsibilities as you migrate tools.
Planning: First start the planning process by reviewing the requirements and prioritizing the functions to implement. Focus your migration plan on getting some quick wins, as you want to migration process to build momentum early in the process and show demonstrable success. Once the major functions and associated milestones are defined, next you allocate resources, define timelines, and prepare for the migration. By prepare, we mean define scanning rules, revisit device configuration policies, aggregate topology information, design the dashboards and reports, etc. You want to do as much work as possible ahead of the actual implementation, so once you start moving you can minimize the amount of recalibration required during the process.
Implementation: Once the plan is locked and loaded, then it’s time to move. That involves deploying the devices (or virtual devices), installing policies, dashboards and reports, testing and verifying the functionality (remember false positives out of your shiny new tool don’t look very good), acceptance from the stakeholders, and finally decommissioning any other tools in use.
Once you’ve navigated the gauntlet of migration, you can kick back and enjoy the capabilities of your new platform to help you prioritize your efforts, improve efficiency, and generally increase the security of your environment. Or so you hope anyway.
And with that, we’ll put a wrap on our Vulnerability Management Evolution research project. As with all the research built using the [Totally Transparent Research] methodology, we’ll factor in the great comments we’ve already received on the posts and package up the series as a white paper. We’ll give you a couple more days to comment, so check out the posts in the series and let us know what you think.
- Introduction
- Scanning the Infrastructure
- Scanning the Application Layer
- Core Technologies
- Value-Add Technologies
- Enterprise Features and Integration
