(A preview of the SC Media eBook “Launching MDR: How to configure, deploy and optimize.”)
Deploying a managed detection and response (MDR) service can help organizations achieve the benefits of a modern, high-performing SOC. In Part 1 and Part 2 of this series, we explored important configuration decisions and essential checklist items for ensuring that MDR deployment is successful.
In this latest installation, we’ve compiled raw commentary from various experts who have firsthand experience in helping customers deploy MDR services. They include insights from:
- Mat Gangwer, Vice President of Managed Threat Response, Sophos
- Matt Hickey, Senior Director of America Sales Engineering, Sophos
- Greg Rosenbeg, Director of Sales Engineering, Sophos
Speaking to SC Media, these experts weighed in on six important considerations for deploying MDR effectively, from prioritizing the right data types to delineating responsibilities and business objectives.
Prerequisites for MDR deployment
- Mat Gangwer: "There's a few things that are important for customers to do before deploying. The first is data quality and data sanity, making sure the sorts of things you'll be sending to your vendor are normalized. That makes it a lot easier for your partner to work with that data. Second, I like to see organizations have an incident response plan that's been updated to incorporate how your MDR provider can help you. In our experience, it’s much better when we collaborate with our customers to embed MDR responsibilities into their incident response plan, rather than the alternative of getting into an incident and not having a plan or even knowing if MDR will cover those things. Third, we like to know who’s receiving the escalations and content from the MDR provider, how they plan to receive it, and whether they're capable and ready to be able to handle and do something with those events. Having those internal processes and procedures in place is invaluable.”
Deciding what data to prioritize in deployment
- Greg Rosenberg: “Customers must be able to make decisions about the types of information they’re going to ship off to the provider. For example, if you've got a firewall with a number of optional modules like a threat intelligence platform or IPS or some other plugins, is all of that information going to be sent off? If you have a consumption model for billing and you’re on a fixed budget, how do you choose which logs to prioritize and which types of data gets sent off? At what point do you have to draw a line to say, ‘if you send us that fifth security appliance data, you’re now off our budget?’ The licensing model is something you have to be cognizant of when you're choosing all those sources of different information for your MDR provider.”
- Greg Rosenberg: "The common pitfall I see is that people don't realize all the resources they need, or they don't necessarily know the business objectives of why they're using this data. And either they don't get all the data, or they have to make some kind of trade-offs in the data they use due to the billing model.”
Clarifying shared MDR responsibilities upfront
- Mat Gangwer: As you’re setting up and configuring MDR, it’s important to clarify the partnership between the vendor and customer. For example, if it’s a product that needs to be deployed, in most cases the customer is going to be responsible for deploying that. Or if it’s configuring data sources, the customer is going to be responsible for managing those data sources. Once everything's configured and deployed, though, now the MDR provider has a responsibility in making sense of the telemetry or data coming through the pipeline. We can draw conclusions, process events, create alerts, work cases, perform threat hunts — all the things that you would expect of an MDR provider — to make more sense of that data than the customer would ultimately be able to do on their own. But understanding this shared responsibility model is important because your MDR provider is really only going to be able to go so far in certain situations.”
Tailoring MDR deployment for business objectives
- Greg Rosenberg: “Make sure you map your service back to the original business objectives, and that you remind the vendor and others what those objectives are. This will help inform what your data sources are. For example, if the vendor knows the customer’s objective is to be PCI DSS compliant, they can work with the customer to make sure their firewalls satisfy that objective as part of the MDR service. Whether it be about compliance or a pure security focus — or even just a cyber liability insurance policy — having these items on a checklist where you can say ‘this is what we need to cover’ is a really good starting point.”
- Mat Gangwer: “MDR can be a tool to achieve customer outcomes. For example, if you look at your risk profile and see that your business is really worried about phishing emails and users getting compromised, then it would make sense to incorporate that priority into the MDR service so the provider can synthesize that information, review it, and respond to it. Or maybe you need some networking visibility to get protection within a certain segment of your environment. With certain MDR providers, you can add in that component and begin piecing together the technologies you need to provide protection and detection in those areas of your network.”
Deploying MDR as a sounding board
- Matt Hickey: “When you deploy MDR, you're really leveraging our services to augment the existing services that you have in play. Having been on the ‘threat hunting] frontlines, I look at MDR as a kind of sounding board where — even if the customer doesn’t have all the knowledge in front of them — they now have a stable-full of very competent, experienced threat hunters they can bounce ideas off of.”
Deployment isn't the finish line
- Greg Rosenberg: “When it comes to the mechanism of data, what happens when there's a new alert type? How do you ensure you have a sort of audit function on a regular basis to ensure that new alert types are adjusted as you move forward? These things don’t just stop once you’ve deployed. They need to be checked at a regular interval, in the same way that you might check your firewall rule set once a year. Whatever that frequency is, it’s important to determine it and stick to it.”
