How Organizations Can Operationalize MDR Successfully

Like many terms in cybersecurity, managed detection and response (MDR) can mean different things to different organizations. Talk to ten IT leaders and you might hear ten different interpretations. At its core, MDR requires organizations to look beyond the technology itself and ask: What does the organization need MDR to accomplish?

That starts with understanding the business outcomes the organization needs to protect, where its critical assets reside and how managed detection integrates with business continuity planning and business impact analysis. It’s easy to get caught up in managing garden-variety detections. Ultimately, though, organizations are trying to prevent a bad day for business, and every organization has a slightly different definition of what that bad day looks like.

Successful MDR is therefore about building confidence: confidence that the organization has the tools, people and processes in place to detect bad actors before they can cause serious damage.

Working with an MDR provider requires collaboration. That means an organization’s IT team must do a little warranty work. They need to understand their environment, identify their critical assets and determine what the impact would be if those assets were compromised.

They should also establish clear roles and responsibilities. Who is going to do what, when and how? Those decisions should be mapped out early. The most successful MDR engagements offer room for the organization and the service provider to build the operating model together from the start rather than trying to force an existing model onto the organization.

Understanding roles and responsibilities is the first layer of warranty work. Next, is deciding what to delegate. One way to make that distinction is to look at how mature and repeatable an activity is.

• Is there a standard operating procedure?
• Is the task documented well enough so that someone qualified could pick it up and perform it?
• Is it primarily tactical rather than strategic?

As a general rule, decisions that could materially affect the business and its performance should remain with the organization. IT leaders and their team should stay actively involved in higher-level security activities and strategic initiatives.

That doesn’t mean the dividing line between the organization and the provider will always stay in the same place. Some organizations outsource a significant portion of their security operations. Others purchase and operate the technology themselves. The right place is often somewhere in the middle.

The most successful relationships with MDR providers involve the customer actively engaging and collaborating. The shared responsibility lines can then move as the engagement matures.

You don’t necessarily need to redesign your entire operating model before adopting MDR, but you do need a solid foundation.

Why? MDR isn’t a set it and forget it service and can’t run effectively in a bad environment. Simply layering on a service isn’t going to fix foundational problems. For example, an organization that receives a high volume of alerts but lacks the capacity or processes to respond to them won’t solve its operational challenge by adding a service provider. First, you need enough foundational security maturity to participate in the process and a willingness to collaborate with an MDR provider on an ongoing basis.

Once the foundation is strong, however, organizations can iterate and mature the program over time.

Any decisions that impact an organization at a high risk should remain with the organization. Isolating an executive’s laptop or taking a production server offline, for example, can have consequences well beyond the security operations center. There must be boundaries around the actions a service provider can take independently.

Those boundaries are becoming increasingly complicated as automation, orchestration and AI agents enable security operations teams to take action faster. It’s a big discussion that the industry needs to have and address.

The question of importance is: What can a service provider do versus what can a customer retain for themselves?

One of the biggest MDR mistakes organizations make is getting bedazzled by the demo. IT leaders sometimes buy technology instead of building an operational program. Then they’re disappointed when the technology doesn’t perfectly fit in with their environment.

Another problem is underestimating the amount of time and effort the organization itself needs to invest. Hiring a service provider doesn’t eliminate the need to continually evaluate and improve the organization’s security program.

And perhaps most important is the nature of the relationship itself. If an organization approaches MDR primarily to transfer risk or have someone else to blame when something goes wrong, the partnership can quickly become adversarial.

Strong programs take the opposite approach. The provider and customer work shoulder to shoulder to build a better security operations program over time.

Traditional metrics such as service-level agreements and mean time to respond can be useful, but they don’t necessarily tell the complete story. For example, an organization may ask for a 15-minute mean time to respond to a critical detection. But what does “respond” mean?

Does it mean that a ticket was automatically created and the client received a notification? Does it mean an analyst acknowledged the ticket? Or does it mean an analyst investigated the alert, performed initial triage and came back with an informed assessment of what is happening? Those are very different outcomes.

Ultimately, operational confidence comes from knowing the service provider is reviewing alerts quickly, conducting the appropriate investigation and triage, taking appropriate response actions and helping blunt what bad actors are attempting to do within the environment.

That can be difficult to distill into one metric because detections, investigations and attacker tactics aren’t all the same. What matters is having a documented operational model for handling alerts and maintaining active communication between the provider and client as an investigation unfolds.

A mature MDR operating model comes back to one fundamental principle: Know what’s important to the organization.

You need to identify the high-value assets that have a real impact on your ability to do business. That often starts outside security operations with a business impact analysis. Think of it as giving the security operations team a treasure map. If you don’t show the team what’s important, then everything becomes important. And when everything is important, nothing is important.

From there, your organization can take a tiered approach to security operations based on critical assets and the tactics and techniques most likely to affect them. Invest the time to create a detailed client profile, onboard correctly and establish strong escalation processes.

You can also test the program before a real crisis occurs through tabletop exercises, penetration testing and red team-blue team exercises. The purpose is to determine whether the operating model works under pressure and then continue improving it.

That’s ultimately what separates mature organizations from those taking a “set it and forget it” approach. Mature organizations continually evaluate what they have in place. MDR isn’t something they implement and wait to see whether it works when a bad day arrives. It’s a continuous improvement cycle built around collaboration, testing and confidence.

MDR can fall show when organizations focus on technology without considering the people, processes and partnership needed to operationalize it. Discover how to build a stronger path to MDR and get more value from your approach in the CDW webinar, “How MDR Deliver Immediate Value for IT Teams.”