Enshittification of MDR — Consumer Guide — Part 1
My favorite new(ish) term that has been popularized over the past year is “enshittification.” If you haven’t seen the Norwegian Consumer Council’s (Forbrukerrådet) video on it, you should watch it. The general idea will not sound new to you — intentional degradation of products/services to maximize profit once users are locked into an ecosystem — but when Cory Doctorow created this term, he certainly found the perfect and most entertaining way to encapsulate it. Unfortunately, enshittification has become a normal part of our lives, including security operations and managed detection & response services.
Admittedly, enshittification doesn’t exactly fit 100% of the time here — especially since it is not always intentional that service providers make things worse; however, it is a really fun word to use and I will be using this as an excuse to say it.
How to Avoid Enshittified Services
As an engineer who has worked building security programs and MDR services both on the customer and provider side, I feel I can provide some advice on how customers can minimize service degradation in regards to their MDR providers. There is no sales pitch, no “contact X to solve the problem” at the end. I am not an AI engineer, mathmagician, or economist. Based on my experiences, I have a series of semicoherent pieces of advice for those responsible for choosing MDR providers. People that know me — unfortunately — know that I can write dozens of pages on the least interesting of security operations topics. Acknowledging that fact, I will split my thoughts up into multiple articles to avoid publishing some 40 page manifesto. This first installment is focused on two areas I have chosen as a starting point to build a foundation on for later articles.
You Have to Care
The most important first step — and the most increasingly rare to see in practice — is that you first must actually care about the service you receive. It is not that you — the prospective customer — do not care about getting a quality product, it is more so that you have been conditioned to accept a level of indifference. That is to say, the average offering you deal with does not actually meet your needs very well, so that becomes the new normal to you and you stop expecting things to be capable of actually addressing your needs within an acceptable set of parameters. When you are used to paying tens of thousands of dollars per year on MDR providers that take black box detections, add — in better examples— a minimal triage layer, then ship off a ticket back to you to “confirm if this is expected,” it is easy to expect nothing more. Often in my experience this manifests in the customer compensating by purchasing even more tooling/solutions/staffing to compensate for what they already are supposed to be paying the MDR provider for. The net result is a decreased expectation of service quality with ever increasing costs (sound familiar?).
The core operating model of enshittification as described by the Norwegian Consumer Council (Forbrukerrådet) is the concept of drawing in customers with innovative features or artificially low prices (remember this), generally to undercut competitors and disregard any immediate profit. Then comes the incremental degradation of services — quality drops, subtle user feature shrinkage, and increased costs. Right now it probably sounds like I am describing whichever streaming service(s) currently extorts you, but this trend bleeds over into all aspects of our lives and economies. I’ll discuss the most recent example of this in the next section, but the key point is that you — the customer — must demand more. You deserve better. When we are tasked with securing critical infrastructure, core services, and businesses people have poured their lives into, “just checking the box” is simply not acceptable. The engineers are talented enough, the technology is good enough, and the businesses can generate enough profit. Therefore, the first step is that you deeply must care, be willing to advocate, and fight for higher quality services with favorable conditions.
The AI Dilemma
AI feels like the most natural place to start, because nobody will shut up about it. To make it short, please do not choose any of the 4000 new “AI SOC” startups popping up every day. To make it long, you should be asking “How are you specifically using AI in your SOC and what does it solve?” There is a giant difference between “AI SOC Agents” focused on triage/response intended to replace human triage and the use of agentic workflows to speed up operational duties like detection engineering lifecycle stages. I will do my best to express my general opinion succinctly, but this is something I could write extensively on in much more technical detail in the future.
Cost & Sustainability
Despite what you would believe from reading LinkedIn, the use of AI in a SOC (more specifically MDR context) is quite simple on the consumer side. First off, I am no economist, however it is no secret that many are concerned extremely high AI subsidies might not be sustainable. In fact, just in the last year (or months) we have seen increases in token cost, followed by decreases in token cost, and then increase in token consumption per query resulting in a higher net cost. Compute cost in general is possibly trending down, but one thing is almost entirely certain — the sustainability of AI pricing is a very large gamble.
Why does this matter? Well, like I said earlier, the manner in which AI is used is critical. A traditional human SOC may have analysts get more expensive over time as they become more capable, inflation/salary raises, or for other normal reasons that apply to really any other skilled labor. In contrast, an “AI SOC Analyst” tasked with triage can suddenly become 2x, 4x, 10x, or even 100x more expensive for any number of reasons (ingestion, model changes, price changes, workload, etc.). To avoid speculating on the complicated economics of the AI tech oligarchy, we can instead turn to something we know is factually correct; data is increasing year-over-year. It has been for decades and it is an agreed upon fact that it will continue. This means for companies there will year-over-year be more devices, more data, and therefore more signals for detection and response. Anyone that has run a traditional SIEM-based log retention & detection model — or paid for a service offering this — over the past 10 years can attest to the fact that the number going in (logs/signals) has not gotten smaller, often resulting in the number going out (alarms) also being larger (more on that later) and your budget looking less happy. Many of these “AI SOC” companies are simply not modeled around compensating for this and are not transparent. If you get satisfactory answers on a service that meets your needs and risk tolerance, then by all means consider them and ideally create some plans for the worst case. Likewise, if your long-term MSSP and MDR provider suddenly starts to promote “AI” powered features/services heavily, or even worse replaces some staff with it, this is also a good time to start some serious discussions with them and demand transparency.
I would also be foolish to not mention on a more general level the fact that every company is rushing to integrate AI in some capacity into seemingly every single product, platform, and tool they have ever created. This type of mandatory low-cost baiting of users, and in some cases forcing it in their face with no opt-out, with the intent on them becoming reliant on a technology is the calling card of enshittification.
Things that are profitable for service providers are not always beneficial to your security posture or your budget.
Efficient Use of Technology
Efficient use of AI in a detection and response context is a very large topic that is pretty controversial, so I will stick to generally agreed upon takes shared by respected experts in the field. The use of AI is not inherently bad, and the technology itself is probably one of the most misused and misunderstood innovations that I can at least think of. Most of us should remember when everyone was first pushing Security Orchestration, Automation, and Response (SOAR) as the solution to SecOps woes. Lots of companies sold overly complicated tools or integrated limited feature sets with the name SOAR slapped on it, many customers bought it, and then it proceeded to sit untouched because it required engineering effort to actually make use of it. The fact that most people did not properly plan for or make use of SOAR tooling led to the endless loop of “SOAR is dead” posts we are now plagued with. However, SOAR technology as a concept was never the problem, it was a lack of efficient use of the capabilities and tooling that resulted in it having a low perceived value and therefore being an afterthought to most. These days tons of platforms have “SOAR” capabilities baked in and it is exceptionally rare to see any non-leading security teams actually making efficient use of them. The natural new trend of marketing hype? Basically just SOAR again but with the benefit of AI buzzwords now included.
Get Daniel’s stories in your inbox
Join Medium for free to get updates from this writer.
We all, hopefully, know throwing an LLM at a giant alert queue is not exactly going to end in long-term success. Unfortunately, this is exactly what many propose as a viable solution. I will try to help put it into perspective a bit before we dive into some more technical details. You have an overflowing sink and are constantly trying to clean up the mess. Would you purchase an industrial autonomous mop to continuously clean, or would you fix the broken valve causing the flood? Using AI agents for triage due to an overflowing queue is essentially buying an expensive mop with an unknown cost and result instead of fixing the source of the noise. It is far more efficient, effective, and cost resilient, to instead use your funds available on technology/tooling (in this case agentic solutions/tokens) for effective detection engineering and prevention/remediation to reduce the noise at the source.
Furthermore, think how hard it is for an analyst to come to a conclusion on if an alarm is benign or malicious based on the data available. Now put yourself in the metaphorical shoes of an AI agent. Does it know the business context behind the machines and users? Does it have access to the information the analyst does? Is all data stored in an accessible machine-readable format and location so that it can efficiently be an “operator?” In almost every environment that is a resounding no. How much are you really going to trust this AI agent? In many SOCs, this manifests as humans spending more time verifying the work of the AI triage rather than just doing it themselves. The result is more expensive and potentially slower than manual triage to avoid low quality escalations ending up in front of the customer. Data engineering is already massively overlooked in detection engineering, which is itself already underinvested in at most MDR providers. It isn’t about being able to detect new APTs before the giant name research labs can, it is about effective threat detection and response for your business.
The reality is, most businesses are absolutely not covering the fundamentals like asset inventory, data engineering, business context availability, clear frameworks, SOPs, etc. So with that in mind, investing all your resources into managing the symptoms instead of treating the sickness will always be a losing battle. Read whatever breaking news threat report, exploit, or news article you want, but the core security failures resulting in the majority of incidents have largely remained the same for many years. Before considering a flashy new hype product, ask yourself: “Are we already effectively covering the basics? Does this technology directly solve a problem I have?”
Conclusion
There is so much more that I could write about everything, but I felt it is better to keep this as concise as possible and focus on these core pieces of advice first. To summarize as someone that builds security programs/services, demand more. I love when customers are asking hard questions and demand high quality services with more transparency. There are many talented engineers and architects out there that would love for you to force innovation and higher quality services. Please do not be afraid to look at other options if you are not getting answers that you are confident in or feel the quality you receive is not up to your standard (a future article may focus on this). Do your best to avoid industry hype and focus on real, effective engineering. The core drivers of incidents are not so different today than they were 10 years ago, a shiny new tool/service is highly unlikely to magically fix your lack of security fundamentals.
For some clear takeaway questions you may want to ask if you find yourself toiling with AI in relation to your prospective or current MDR provider:
- How do you handle token cost changes and/or model token consumption changes?
- Specifically, how are you using AI in your detection and response service?
* How do you handle context gathering and a lack of business context?
* Where are your humans in the loop and what do they do? - What would happen to your service if you lost access to the model overnight?
Lastly, here is a question to ask yourself:
- Does this cost sufficiently reduce risk and align with business objectives more than spending the equal amount on neglected fundamentals (edge security, patching, asset management, purple teaming, detection engineering, etc.)?
If I continue to write more on MDR service selection, building of MDR services, or similar topics I will do my best to update this with links to the next pieces.
