Tips · 9 MIN READ · PAUL LAWRENCE · DEC 5, 2024 · TAGS: MDR
TL;DR
- We’re unveiling the truths behind ten common myths managed detection and response (MDR) providers often hear
- The truths behind these myths help differentiate DIY, MSSP, EDR, XDR, and MDR options
- We also explore metrics you can focus on to achieve leadership and stakeholder buy-in for an MDR investment
Cybersecurity is a complicated topic that exists for one simple reason: at the end of the day, everybody just wants to protect their businesses so they can focus on achieving other goals. And in today’s market, there are four main ways you can do that.
The first is do-it-yourself, or DIY. This is a great approach if you want to focus on a security solution that’s completely customized to your tech stack. But you’ll also need a lot of money, a ton of recruiting effort, and the people (and the patience) to build, deploy, and maintain your solution.
The second option is a managed security service provider, or MSSP. This can be a great option because it outsources your alerts and allows your team to just focus on triaging bigger threats. But if you want tons of transparency and context for investigations, you’ll need additional tech or headcount.
Your third and fourth options deal with managed detection and response (MDR) providers, which generally come in two flavors: with fixed tech and a co-managed security incident and event management (SIEM) tool, or as BYO-tech with security operations center (SOC) services.
While MDR is the most comprehensive of these security options, it doesn’t come without its own set of preconceived notions. Here are some of the most common MDR myths we hear; debunked.
-
“MDRs are just a newer brand of MSSP.”
Truth: MSSPs augment your staff, but perform inconsistently and lack visibility.
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 a 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.
-
“MDR is just an add-on service to EDR.”
Truth: MDR started as EDR add-ons, but has since evolved to cover multiple threat surfaces.
MDR did get its start in the endpoint detection and response (EDR) market, but in today’s world, MDR providers cover multiple threat surfaces, including on-prem, SaaS, cloud, endpoint, network, identity, SIEM, and Kubernetes. Additionally, some MDR providers can even go a step further and work with cloud detection tools—like AWS CloudTrail and GuardDuty—and protect the cloud via the control plane within cloud workloads.
This can include cloud native application protection platforms (CNAPPs), cloud workload protection platforms (CWPPs), cloud security posture management (CSPM), and cloud infrastructure entitlement management (CIEM), so that you’re one step closer to a single dashboard—and metrics—for all alert processing.
-
“MDR is out; XDR is in.”
Truth: XDR and MDR are not the same.
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 you 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 you integrate with my 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 you 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.
- How much of your workflow is human vs. automation? 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 alerts that require the kind of context only internal team members can provide.
- How much do you remediate? Most MDRs do urgent work, like isolating a host or blocking 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.
- Do you 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.
-
“We already have a 24×7 SOC—an MDR won’t add any value.”
Truth: MDR providers are about SOC augmentation and optimization—not replacement.
Even with an MDR in your tech stack, 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 enjoy—leading to higher retention and a happier SOC overall. Alert fatigue is real; ignore it at your own peril.
-
“Our SIEM is well-honed and MDRs won’t leverage it.”
Truth: MDR providers come in lots of shapes and sizes. How they use your SIEM depends on the provider—there’s no universal standard.
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.
-
“MDRs lack necessary context to be effective.”
Truth: MDR providers that aren’t truly MDR, or that depend too heavily on people or software and not both, can have context limitations.
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 have tried this approach for years, and have 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 to help prioritize incident criticality.
-
“New open-source data lakes and security orchestration, automation, and response (SOAR) tools mean we can build our own MDR.”
Truth: This is technically true. But just because you can doesn’t mean you should.
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. There’s no economic benefit to building your own security machine, especially when someone else has already solved the problem. Building your own cybersecurity solution is like building a house and insisting the general contractors also build the materials themselves, instead of purchasing them from other experts in lumber, plumbing, and electrical. (And it takes exponentially longer to complete.)
-
“MDRs won’t work with all the processes we’ve already built.”
Truth: A good MDR provider integrates with your existing systems.
Many MDRs have integrations that work with your ticketing systems, either by email or API. Some SaaS-centric MDRs make their platform extensible via API, so they can connect right to the automations and tools you already built. There’s also 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 digitally transform your SOC, and what forward-thinking IT leader isn’t focused on that? MDR—especially one that integrates with the tech you already have—can save money (and even create ROI) down the line.
-
“Analysts will think we’re replacing them with MDR and want to leave.”
Truth: Even security analysts find alert triage and investigation tedious—but MDRs free up their time for more interesting work.
Just like in any other type of work, no one wants to do the same thing day in and day out. Your analysts want to continue to level up their skills, and work on advanced threat detections, posture improvements, or complex, downstream automation. The average tenure of a security analyst is 18–24 months, and investing in MDR will expand that, not shorten it.
When asked what advice or best practices you’d give to other security professionals to effectively manage burnout and stress in a recent survey, Leon Schmitz, CISO at OneStream Software, said “Reliance on a third party can be a good thing. Leaning on the skillset of Expel for our initial first defense has been a great experience, freeing us up to focus on other critical items.”
-
“MDRs don’t have a compelling enough ROI to persuade management.”
Truth: Good MDR providers deliver ROI—it’s just about finding the right metric to illustrate it.
MDR is one of the easiest security investments to justify in our industry. Forrester has done several total economic impact (TEI) studies at the behest of vendors, and after interviewing customers, calculated ROI ranging from 292–610%.
Depending on your situation, here are some key areas and metrics to help quantify MDR ROI:
- Reducing costs associated with recruiting security talent. 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.
- Reducing staff loss risks and costs. 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.
- Increasing performance metrics and lowering dwell times. Lower dwell times mean lower breach probability, which can be worth its weight in gold from a leadership perspective.
- Decreasing 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.
And if you have more questions about the facts and fiction of MDR, you can chat with one of our experts here.
