EXPEL BLOG

Top 10 MDR myths: debunked

Top 10 MDR myths debunked

· 7 MIN READ · GREGG KALMAN · APR 12, 2024 · TAGS: MDR

The cybersecurity landscape is growing increasingly complex, and the never-ending sea of solutions, categories, and corresponding acronyms (i.e., “alphabet soup”) isn’t helping. Managed detection and response (MDR) is one of those acronyms that might be confusing, especially if you’ve received various mixed messages from vendors. Let’s break down a few of the pervading misconceptions to help you make sense of what your organization really needs to stay ahead of today’s threats.

Here are some of the most common MDR myths we hear; debunked.

  1. “MDRs are just a newer brand of MSSP.”

    Managed security service providers (MSSPs) are good for outsourcing alerts to augment your staff, but the mountains of data you send out for triage typically only land on another set of analysts’ shoulders. Some MSSPs will even prop up and support a SIEM for you, but that doesn’t alleviate alert fatigue for the managing team. Thanks to inconsistent quality and general lack of transparency, MSSPs have largely fallen out of favor. After all, if you’re having difficulty finding, training, and retaining staff on your own team—so is your MSSP.

    In contrast, MDRs (particularly those with a tech-centric approach) offer more visibility and leverage technology to scale, so you can trust their work and outcomes. This innate difference separates MDRs from MSSPs at their core.

  2. “MDR is just an add-on service to EDR.”

    While MDRs may have originated as an add-on to endpoint detection and response (EDR) solutions, they now cover multiple threat surfaces, including on-prem, SaaS, cloud, post-secure email gateway (SEG) phishing investigation, and even some operational technology. In fact, some MDRs offering public cloud protection will not only work with EDRs running on cloud workloads, but also with cloud detection tools, such as Cloudtrail and Guard Duty. Some MDRs also write detections for anomalous control plane activity and integrate with various cloud telemetry tools (think: CNAPPs, CWPPs, CSPMs, and CIEMs) so that you get closer to a single dashboard and metrics for all alert processing. All this moves MDRs firmly out of the scope of EDR add-ons, and into a league of their own.

  3. “MDR is out; XDR is in.”

    Unfortunately these terms are often used interchangeably, which inevitably leads to confusion in the market. Extended detection and response (XDR) offerings gained traction for their ability to ingest all kinds of telemetry, including endpoints, where MDRs were believed to be limited to endpoints. But because this isn’t the case (see myth number two for reference), the value of XDR is increasingly ambiguous and interest is dwindling.

    If you’re interested in MDR but need to know if it’ll fill that XDR-sized gap for your org, your best bet is to understand the following about your potential provider:

    • What attack surfaces do they cover? On-prem, cloud, Kubernetes, SaaS, email or business email compromise (BEC), identity threats, etc.—this list will be specific to the provider in question, but any MDR worth its salt will offer a breadth and depth of coverage.
    • Do they integrate with your tech? MDRs generating their own telemetry don’t typically collaborate with their top competitors in that particular area, so they may lack agility if you’re solely looking for best-in-class solutions. But, that could afford them the ability to offer competitive pricing packages. For example, MDRs with a bring-your-own-tech approach are an excellent option for maximizing your existing investments. Some MDRs provide the tech, kind of like an easy button, but it’s definitely not as high-quality as what you might select in the open market.
    • What parts of the security operations center (SOC) workflow do they perform? Do their operations include triage, investigation, remediation, and resilience recommendations? Some MDRs will even offer post-breach incident response (IR), but we don’t recommend that your MDR also serve as your IR vendor—it could be a conflict of interest. It’s important to understand what you are, and what you aren’t, getting from your provider.
    • Where do humans fit into their SaaS equation? There are providers that reduce noisy alerts, but your team is still left to manually investigate and make the final call. How much involvement do you want to maintain for your team? Especially when they could be focused on other things, like improving posture or working on the alerts that require the kind of context only internal team members can provide.
    • How much do they remediate? Most MDRs do urgent work, like isolate a host or block bad hashes (especially if this work can be automated). But are you going to let them put blocks in your firewalls or reset accounts, for example? Think about what you need your MDR to do, what you want them to do, and what you’ll let them do—and under what conditions. Also consider whether the provider customizes those remediations granularly, like host isolations for workstations only, or file deletions for servers.
    • Finally, do they provide recommendations to improve? Following an incident, know whether your MDR provides a list of recommendations going forward. A good MDR will stop the incident, but a great one will help you get to the root cause to ensure your org continuously improves.
  4. “We already have a 24×7 SOC—an MDR won’t add any value.”

    MDRs are all about SOC augmentation and optimization, not replacement. Effective SOCs will always need people to provide integral context and perform key remediations when necessary. Ideally, your MDR will give your team the space it needs to focus on the problem-solving tasks the analysts are not only better suited for, but actually enjoy—leading to higher retention and a happier SOC overall.

  5. “Our SIEM is well-honed and MDRs won’t leverage it.”

    MDRs are not all alike, which means how they leverage your SIEM will differ. Some MDRs will work with you to co-manage your SIEM and provide detections (as long as it’s one they work with). Others come with their own embedded SIEM—be it one they built or bought, or one that they licensed from a third-party at a below-market price.

    And some MDRs don’t need a SIEM, instead working off a purpose-built SaaS platform that talks directly to your telemetry via APIs. In this scenario, the common misconception is that your SIEM will get tossed out, but MDRs (at least the good ones) can still make good use of all that data you honed for investigative support, including unique custom detections.

  6. “MDRs lack necessary context to be effective.”

    A lack of context was a common complaint of MSSPs, leaving folks unnecessarily suspicious of MDRs for the same reason. MDRs generally address context needs in two ways: one, they dedicate a team of analysts that know enough about you to do detection and response on your behalf. This can certainly work, but can be risky as it’s based heavily on that team’s specific knowledge—i.e., if they lose too many of the original analysts that they dedicated to you, there goes that context. MSSPs tried this approach for years and found humans to be the least reliable part of their service delivery.

    Two, some MDRs save your context information in software, allowing automation to leverage it for noise reduction and leaving humans to use it to make the final judgment calls. Context includes data like who’s who in your system, what credentials they have, which countries they should be in, which apps they use and when, where the most sensitive data is found, and more (kind of like basic UEBA functionality).

    Side bar: future development in this arena will likely include things like synchronizing with other resource visibility tools, like configuration management databases (CMDBs) and tapping vulnerability information for help prioritizing incident criticality.

  7. “New open-source data lakes and SOAR tools mean we can build our own MDR.”

    This is technically true—we’ve seen a few hyper-mature organizations build their own automated MDRs for what’s essentially a customer of one. The catch? It costs tens of millions of dollars to start, tens of millions more to maintain, and even still has challenges. These challenges tend to pop up when companies want to change their core telemetry, acquire a company that has different tech, or lose some of the folks that helped build the internal engine in the first place.

    Good MDRs constantly update their knowledge and automation because it’s their core business—and thus, in their best interest—so they’re going to excel at it. A good adage to remember here is, “Just because you can, doesn’t mean you should.”

  8. “MDRs won’t work with all the processes we built using ticketing systems and SOAR tools.”

    This is false for several reasons. First, many MDRs have integrations that work with your ticketing systems, either by email or API. Second, some SaaS-centric MDRs make their platform extensible via API, so they can connect right to the SOAR automations you already built. And third, there is such a thing as “the sunk-cost fallacy,” where you can end up making poor economic decisions by refusing to rethink the fundamentals. MDRs at the most basic level provide digital transformation of your SOC, and what forward-thinking IT leader isn’t focused on that?

  9. “Analysts will think we’re replacing them with MDR and want to leave.”

    As we mentioned previously, even security analysts would rather be doing more interesting work than alert triage or level-2 investigations that begin with repetitive steps and information gathering. This work is tedious, often leading to burnout and staff turnover. Working with an MDR allows analysts the space to focus on advanced detections that are unique to your org, freeing them up to work on more business-critical tasks.

  10. “MDRs don’t have a compelling enough ROI to persuade management.”

    Security ROI is notoriously difficult to quantify because the primary return for security investment is reduction in risk, which is tough to put a number on. The fact you haven’t been breached (yet) isn’t even an accurate indicator of the effectiveness of your program, but just because it’s difficult doesn’t mean you shouldn’t try.

    Depending on your situation, here are some key areas and metrics to help quantify MDR ROI:

    • Staff scaling costs: we all know about the security skills gap that’s plaguing hiring managers everywhere. MDRs can help augment teams during high-growth periods when hiring is difficult.
    • Risk reduction – staff loss: with macroeconomic shifts making for unpredictable staff retention, MDRs offer a business continuity buffer to ensure you can keep the lights on no matter what happens tomorrow.
    • Risk reduction – lower dwell time: lower dwell times mean lower breach probability, which can be worth it’s weight in gold from a leadership perspective.
    • Risk reduction – better performance: MDRs automate a lot of the tedious tasks that human analysts tend to slip up on—particularly if they’re overworked or bored. Augmented teams mean better performance, which means reduced incident risk.
    • SIEM consumption costs: If your SIEM is more of a cost-center than a value-add (particularly if it’s not necessary for compliance), than MDRs can cut that cost and free-up your budget for other initiatives.

There are a lot of things to consider when looking at an MDR. There are also a lot of different choices out there, with lots of mythology confusing the situation. There’s no one-size-fits-all approach that’s guaranteed to meet your org’s unique needs. But one thing is true: you’d be hard pressed to find a company where some flavor of MDR can’t help lower costs and improve performance.

Want to learn more about how Expel does MDR? Drop us a line.