Enshittification of MDR — Consumer Guide — Part 2
This is the second part in a series where I share recommendations for how to avoid the “enshittification” of Managed Detection and Response (MDR) services. The advice is primarily aimed at somewhat technical security managers tasked with selecting or managing MDR partners, but it can still be helpful to reflect on if you are a service architect or SOC engineer on the other side. As usual, there are no associated products, vendors, solutions, or individuals tied to this post. No sales pitch. No slop. Just personal experience shared.
To quickly recap part 1 — which you can read here — it stated that incremental service degradation, along with associated cost increases, is becoming the norm and seeping into MDR services. Within that theme, the primary focus was the new peak of the enshittification mountain, the “AI SOC.” I provided advice on navigating the use of AI by MDR providers from a customer perspective. I suggest giving it a quick read if you are feeling lost on where to start with all of this Skynet SecOps junk.
Service Scope — Response
In this series of articles, I mostly focus on some tips to help you select and scope your prospective, or current, MDR service. They are not all-encompassing CISO guides or something that dives into vendor management (sorry to disappoint all my fellow CISSP and CISM nerds). Instead, they are a collection of the most common mistakes and trends I have seen personally as someone who has been on both the building and purchasing sides of MDR services. These are key factors that I have seen countless customers complain about, not consider until it is too late, or remain outright unaware of. The intent is to give you a bit more ammunition during service discussions to help avoid an enshittified service. Today I will focus on response capabilities specifically, but in future articles, I will continue on the service scoping and selection theme.
Why is all the “R” gone?
This is jumping the gun in the order of choosing security partners, but personally, I find this to be the most unacceptable trait of low-quality MDR providers that needs to be addressed. MDR is a three-letter acronym representing three core components: Managed Detection and Response. Therefore, there should be response capabilities included in the service… managedly (is that a word?). The confusing part has always been why a large majority of service providers then exclude the R from their services, and why customers historically have been relatively unbothered by it. There are a few components to consider here when talking about response: why it matters, why it is often excluded, and why you should g̶e̶t̶ ̶y̶o̶u̶r̶ ̶p̶i̶t̶c̶h̶f̶o̶r̶k̶s̶ ̶a̶n̶d̶ ̶b̶u̶r̶n̶… demand better.
What is Response?
I think it is valuable first to discuss what response even means, or rather what it should mean. The majority of MDR services offer “response” in the form of just sending a ticket your way after some triage — and in good cases, some analysis. This usually happens both when they know something is malicious and when they are just unsure what to make of an alert. To help visualize my points, I created a diagram showing the typical (so low-mid tier) MDR vendor’s external-facing alarm flow.
The above diagram essentially shows that — typically — after an alarm is generated, a triage layer follows, an analysis layer then dives into the data, a verdict is reached, and the customer receives a ticket or some other contact if the alarm is deemed a true positive or unclear. To quickly dive into the passive-aggressive “sometimes” aspects of my diagram… In some SOCs that are especially low-quality or far too busy with poor detection engineering/service design, they may just skip triage on an alarm. Yes, this really does happen. Yes, it happens at names you would recognize every now and then. Some SOCs also skip the analysis layer in some cases, either due to a lack of data, a lack of time, or a lack of subject area knowledge. These are more common — but not guaranteed — in MDR providers that follow a traditional tiered SOC approach, where the analysts with the least experience are placed in the front making most of the decisions. So yes, this is far more common than you would expect, and many operating models of MDR providers encourage this. You may understand why this setup isn’t ideal as you read more and piece things together, but specific SOC operating models are beyond the scope of this article.
Anyway, back to the response side of things in this “typical” process I have described. Where is the “response” to you — the customer — in that diagram? Well, I can tell you where the average MDR provider considers the response to be. Again, I will combine my unfulfilled desire to be an artist with my lack of actual artistic ability to help visualize this. The average MDR provider would say this is where the line for response is, as shown below:
So basically, everything after alarm generation is, in a way, considered response in the typical description of MDR services. I wouldn’t argue that this is explicitly untrue, especially if we are being pedantic. However, my question is: would you consider that a managed response? Let’s say ACME Co. is offering a service where they manage the detection and response of leaks in your building’s water system. Their monitoring system shows that there is a leak in Pipe 67, and the plumbing expert determines it represents a true leak that needs to be fixed. So, they send you an email telling you about the leak. You had a much more free day than normal, so you saw the email after only 30 minutes and followed up by instructing your own maintenance staff to go fix the leak — or did it yourself. Now, would you consider the service you paid for and received to be an effective response? How about if it was a Friday at 6:00 PM when they detected it, and you finally saw it after snorkeling to your desk through the flooded office? My point is that while you can wordsmith your way into everything being in some way a response to something — shout out Isaac Newton — that does not mean it is an effective response in relation to your actual needs. So, for the purposes of this article, let’s define response by paraphrasing NIST:
Actions taken and processes enabling the remediation, mitigation, and overall handling of cybersecurity incidents to contain damage and/or restore operations.
Effective Response
So, what response is effective? The short answer is pretty much anything that takes work off of your — the customer’s — plate. The slightly more wordy answer is that an effective response is one that appropriately reduces your operational overhead and enhances your capabilities with respect to the service(s) that you pay for. Basically, if you pay people to handle X set of operational overhead for you, they should actually be capable of doing so. I see a lot more organizations than I would like using two external vendors for MDR as a Tier 1, plus their own internal IT/cybersecurity team as an escalation layer (Tier 2/3). In general, I would say that if you are using external vendors for MDR and then have to place your own people to filter through what is junk and what requires action from what they send you, something is not very effective in that design. Google and Deloitte published a set of papers a few years back that have since become harder to find than the Dead Sea Scrolls, but in one part of it which Dr. Chuvakin shared here, they recommended outsourcing capacity instead of capability (for large organizations). To me, this is a key factor for effective response in MDR services. Exceptions exist, like small organizations, but generally you should aim for your MDR provider to act as an extension. For small organizations, as you may not have internal capabilities to extend, I usually refer to this as your MDR provider acting as your internal SOC, not a third party on top of your non-existent operations layer.
An MDR service capable of effective response needs to be authorized and integrated in a way that empowers it to take response actions on behalf of the customer. They should be an extension of your internal team (or act as your internal team in small orgs), not a stand-alone secondary team with completely different operating guidelines and goals. This will often require clear asset management, device/user tagging, rules of engagement (RoE), and application integrations. You would do well to seek out MDR providers that discuss these requirements with you. Being effective at response is not magic; the vendor needs access and prep work to actually do things and gather context. That also requires a certain baseline and participation from the customer in at least the initialization phase of service deployment (clarifying RoE, tagging, topology, asset inventory). Pre-loading this work and investing in these fundamentals allows for faster decisions, clearer scopes, confident analyst decisions, and more context for better outcomes. I created another diagram showing what a more effective example of response to MDR alarms should look like with this approach.
This is, of course, just an oversimplified example, but it should help convey that the core idea here is continuing until you are done or must stop. Effective response is making the maximum impact and reducing customer overhead as often as possible. In this example diagram, there are clear response actions — not just the general idea of responding to something.
Get Daniel’s stories in your inbox
Join Medium for free to get updates from this writer.
So, in practice, what might this look like in a good MDR provider that is effectively responding to alarms? An alarm comes in for atypical travel. An automated triage/enrichment layer may surface user context and related behavior, and the analyst will then conduct analysis to see if this is truly anomalous given the available context and user behavior. The analyst determines that this is abnormal given the normal user properties and surrounding behavior. Within their MDR platform, they can see that all assets are tagged within scope and the RoE clears them for containment actions for suspected compromise. The analyst clicks the button to disable the user, revoke session tokens, and add them to a CA block policy. The customer may be automatically notified of actions being taken (audit trail); meanwhile, the analyst is free to continue their investigation to validate the threat actor was effectively blocked. They conduct further investigation steps on the indicators related to the compromised user and find that one other user received the same phishing email but has not accessed it. They purge the email and quickly review the user history to ensure that everything looks normal. Wider indicator sweeps reveal nothing, and the analyst is confident that they have found the likely phishing email associated with the compromise. A notice is sent to the customer’s IT contact (or internal vendor IT helpdesk) to conduct a validated password reset, provide quick user feedback on how to avoid this in the future, and undo containment policies for the user once confirmed safe. The incident details are provided to the detection engineering team for review to determine if there are any improvements that can be made.
Now, one thing that is really critical in the type of incidents I mentioned is speed. There is a lot of talk about “autonomous response with AI agents” these days, but nothing I mentioned requires any AI capabilities at all. All of this can easily be solved for by platform & tooling engineers, simple automations, and good old-fashioned engineering. Effective security operations engineering, good scoping, integration effort, and clear RoE allow for plenty of speed via both tooling-assisted response and manual human intervention. Speed naturally comes when following good operating models with feedback loops and an engineering first approach. The keys here are clarity, authorization, and effort (from both sides).
Effective response is not taking action until you can stop. It is taking action until you are done or must stop.
What Should You Do?
To be blunt, many customers are completely fine with the lowest-effort MDR services because it, in theory, means that they — the customer — do not have to participate as actively. In reality though, I would argue they just kick the can of accountability down the road and create more work. High-quality MDR providers historically have had quite involved integration periods, regular customer involvement, and quite high-touch services in general. This is again, not something that has to be true and can be greatly simplified. There are plenty of well architected SOCs using purposeful platforms/tooling that keep things to a bare minimum. There is no reason that you must accept that it is either low effort setup with poor results, or extremely long integration timelines with complex administrative overhead. Many people (on both sides) are just interested in checking the regulatory box — something I touched on in Part 1. So, the first step is the same as I previously mentioned: you need to demand more. The MDR providers you consider need to be willing to go further than the minimum effort required to dump liability. You yourself must also be willing to put in this effort to lay the foundation on which a good MDR service can operate. Poor asset inventories, no tagging, no business criticality/operation information, etc. will absolutely not result in you getting the maximum value for your dollars.
To go along with that, you must be willing to risk disruption. Threat actors thrive on the fact that businesses prioritize operations above all else. They can automate attacks — no, still not talking about AI — to take actions long before some big-name machine learning models will even pick up on the behavioral deviation, or before your telemetry is actually hitting the detection logic. Due to this, we must respond quickly. To be able to respond quickly, we must be willing to accept that minimally impactful containment may be required prior to full confirmation of compromised assets. Historically, this has been absolutely unacceptable to customers and MDR providers. When scoping MDR services and choosing providers, though, please take a moment to consider what you care more about: an accounting employee losing access to email for 1 hour due to a suspected compromise, or a threat actor getting an extra hour of access to that employee’s account while the chain of escalation is being run. Just to be clear, if you are in something like a critical ICS environment… this is not me advocating for you to let your SOC vendor isolate the PLC that determines if a power plant explodes or not. RoE and scoping will be 100% based on your specific organization and risk appetite within a given context, so there is no one answer that fits every environment. However, I would encourage you to more actively look for compromises and ways to be minimally intrusive while being maximally responsive instead of simply avoiding disruptive response actions altogether.
Helpful response related vendor questions to take with you:
- What response actions are in scope for your MDR service?
- Automation in use?
- Average time from alert to containment for X type of incident?
- What is NOT in scope?
- How do you handle scoping targets of response actions?
- Tagging requirements or support for users/devices/network segments?
- How do you present that scope to your analysts?
- When do you contact us in relation to alarms?
- What are our (customer) expectations to help with response?
- Access requirements? Integrations/platforms supported?
I’ll continue the series in future articles to discuss more MDR service scoping and selection considerations. If you find these types of articles interesting, have feedback, have a topic suggestion, or just generally think I am a big dummy, please feel free to reach out.
