Your customer has expressed an interest in unified threat management. The next question is when and how. How much follows pretty soon after that, but that's a story for another day. Let's focus on how to get customers from where they are today to a UTM solution, while being respectful of the fact that they already have network devices and unplugging them may be problematic (either operationally or politically).
Regardless of who the customer is, they already have some type of network security posture. It can be as simple as a firewall/virtual private network set-up or it can be four or five different devices that make up the network perimeter. Whatever the answer, going in with guns blazing, and taking a slash and burn attitude will not win you any points with the customer.
The goal is to achieve what I call a "customer-controlled" migration, where the customer makes the call about how the new capabilities are deployed in his/her environment. Since you are the reseller and presumably a trusted party, you can certainly have a say and provide some perspective as to the best practices – but ultimately the customer needs to decide what makes sense for their environment.
In general, I recommend getting everything migrated to the new platform as quickly as possible. This provides the fastest ROI by integrating functions as quickly as possible, but depending on the nature of the environment (very distributed, politically charged, cost averse), you may need to work out a phased implementation plan with the customer.
Plan A is to turn off and unplug everything the day you install the new box. The UTM box has pretty much all the features the customer needs, and keeping the other stuff around just introduces the opportunity for confusion and misconfiguration. So pitch the customer on migrating as quickly as possible, and in a vast majority of cases, the customer will opt to do a clean cut-over.
Alas, life is not always clean and tidy. So there will be situations where the customer makes it very clear that a quick cut-over is not feasible. At this point, you'll need to ask some questions (to which you may already know the answers) to figure out the best path for the customer.
- Why UTM now? – Basically you need to figure out whether the customer is using a financial or a protection/security catalyst to buy the equipment. If it's financial in nature, try Plan A (the quick cut-over) again. Keeping the other devices in place does nothing but increase cost and effort. But if it's protection, we need more information.
- What is a bad day for the customer? – Maybe it's the email going down. Or a zero day attack cratering the network. Or perhaps the CEO not being able to download email from Asia through the VPN. Whatever it is, basically there is a box that the administrator has working and they don't want to mess with it. Pulling out the other stuff is fine. But your first job is to figure out which box is the sacred cow.
Once the sacred cow is identified, then you can build a migration plan to work around the issue and get the UTM device deployed. If the sacred cow is the firewall or VPN, put the UTM box behind the existing device and engage the IPS and content filtering capabilities. Over time, the customer will get comfortable with the integrated firewall/VPN (you could connect another ingress point directly into the UTM to test it), and they'll be able to shut down the old firewall regime. Make sure you have a defined timeframe for turning the other stuff off and a test plan defined to allay the customer's fears about the new UTM device.
If it's another device (like IPS, antispam or Web filtering), then it's pretty easy to work around that issue. Basically you front end the device(s) that the customer doesn't want to turn off with the UTM device. You turn on all the UTM capabilities, but keep the other devices operational, just in case. That way, if the UTM misses anything (or the policies need to be tuned), there is a net and the existing device will clean up any mess.
Speaking of having a net, another key part of the implementation process needs to be a roll-back process. When working through the implementation details with the customer, make sure a clear set of criteria is defined for when the implementation may be aborted. Of course, that is a crappy outcome for everyone, but having the network either down or exposed because the new box isn't working is worse.
Which brings up another important point -- how you make sure the customer knows they are as secure as before the implementation. I recommend doing a "before and after" test as part of the implementation process. Run a vulnerability scanner against the existing environment, and get the results. Hopefully there aren't gaping holes, but in any case it provides a baseline for the status quo.
Once the install is done, run the same battery of vulnerability tests again. The answer needs to be the same (which is no apparent holes) or better than the existing equipment. Customers like reports with fancy charts, and if you can show them that you've actually improved their security posture or at a minimum kept it constant while saving significant money – that's all good.
So basically, try to get the customer onto the new UTM device as quickly as possible. If that's not practical, then work with the customer to map out a feasible (and quick) migration plan to implement some UTM functions now, and define a timetable to add the others and decommission the existing equipment. Ultimately, your goal as a VAR is to make sure the customer feels in control of the process.
About the author
Mike Rothman is President and Principal Analyst of Security Incite, an independent information security research firm. Having spent over 15 years as an end-user advocate for global enterprises and mid-sized businesses, Mike's role is to educate and stimulate thought-provoking discussion on how information security contributes to core business imperatives. Prior to founding Security Incite, Mike was the first network security analyst at META Group and held executive level positions with CipherTrust, TruSecure, and was a founder of SHYM Technology. Mike is a frequent contributor for TechTarget and a highly regarded speaker on information security topics.
