(A preview of the upcoming SC Media eBook “Launching MDR: How to configure, deploy and optimize”)
Now that all relevant assets and data sources have been properly configured, your organization can finally deploy its managed detection and response (MDR) service.
Scenario: Your organization is preparing for implementation of a new third-party service. All the relevant assets and data sources are properly configured. Now your organization is ready for its chosen managed detection and response (MDR) vendor to deploy the service. (In case you missed it, read our configuration how-to here: “How to properly configure MDR for deployment”).
When you deploy MDR, you’re effectively bringing a full-service security operations center into your ranks, staffed by a remote team of elite threat hunters with the training to find and eliminate the most sophisticated cyber threats. While it’s not uncommon for a vendor to suddenly assume primary detection and response duties in this transfer, that does not mean the customer simply abdicates all responsibility on such matters.
For deployment to work, both sides need to be ‘on their game’ and receptive to each other’s needs. Here’s what that looks like.
The MDR deployment checklist
Depending on the provider, deploying MDR will by default activate many of the features that come as part of the vendor’s package. But there’s other matters beyond the product suite itself that organizations need to take care in addressing.
#1: Identify escalation paths and MDR contacts
There will come a time when identified security threats must be elevated to the relevant individuals or teams.
Identifying escalation paths and MDR contacts is important because it ensures both vendor and organization have a known route of communication to the appropriately designated party. Identifying and sharing points of contact between vendor and organization is also critical in the event that a primary decision-maker isn’t available or in a position to rapidly respond, thus providing the outreach team more options to alert the receiving party for swift action.
There’s a number of ways organizations can accomplish this — keeping email distribution lists on file, sharing phone numbers, and so on. The bottom line is that either party should have the ability to escalate issues as needed to the right individuals, and have access to backup contacts in the event that those primary individuals are not available.
#2: Identify and enforce responsibilities
Another essential step to deployment is establishing the shared model of responsibility. Such expectations are usually formalized in a service level agreement, which can determine how much authority the vendor has when interacting with customer assets. For example, both sides should agree on the type of service being provided, the level of vendor involvement, and the endpoints this service covers.
“In a lot of cases, the person who's the decision maker for the service is not necessarily the practitioner who was involved,” says Greg Rosenberg, Director of Sales Engineering for Sophos. “You want to make sure there's a clear delineation of responsibility for administration of systems, right? Then you need to answer questions like ‘is the provider authorized to actually remediate, or are they only containing threats? Are they allowed to make changes, and if so, then on which devices?’ The deployment window is a good time to identify and enforce these responsibilities.”
#3: Bake in audit functions where possible
As part of this shared responsibility model, organizations should find opportunities to bake in audit functions wherever possible. In other words, if Plan A is no longer an option, make sure Plan B, C, D and so on are viable options should matters come to that. In addition to distribution lists and escalation paths, this could be offering risk management training so that departments are better equipped to weather sudden personnel departures. Or, it might be as simple as establishing a regular cadence of check-ins between the customer and MDR provider.
Whatever those functions are, it’s crucial for the customer and MDR ops team to be aligned so that they can grow and adapt the partnership over time.
“What worries me is this endemic idea that when you buy a managed service you’re just kind of chucking all of your risk over the wall to a third party provider,” says Rosenberg. “True, you may be offloading some management or responsibility [onto the vendor], but this doesn’t mean your risk profile can’t change or that your objectives can’t change. Even the systems you’re using may change on a regular basis, and you have to account for that as you move forward.”
