Having standardized our endpoint fleet on SentinelOne, we are now evaluating Managed Detection and Response partners to provide 24/7 coverage. Our primary cluster is ~200 workloads, but the user base is the 200-person organization referenced. The goal is not to replicate a SOC but to gain a force multiplier for detection engineering and incident response, specifically for cloud-native and container-aware threats.
Our technical requirements are non-negotiable:
* **API-first integration:** The MDR must consume SentinelOne's Deep Visibility events via API, not just rely on the S1 cloud console. We need to validate their data pipeline latency.
* **Kubernetes context awareness:** Alerts must be enriched with pod labels, namespace, and deployment metadata. A critical finding should be able to output a concise incident report with relevant `kubectl` commands for isolation.
* **Custom detection capability:** We will provide a set of Sigma rules or custom IOCs we need them to deploy and monitor within our S1 tenant. The question is their workflow for implementing and tuning these.
* **Response playbooks with Helm:** For contained incidents, we expect automated or semi-automated response actions. If they propose scaling a deployment to zero, we want to see that as a templated Helm hook or ArgoCD workflow, not a manual shell script.
The cynical part of me expects most "cloud-native" MDRs to just be a Splunk alert factory. I'm looking for evidence of genuine understanding. For example, can their analysts distinguish between a cryptojacking container and a legitimate `kubectl debug` ephemeral container based on `parentProcess` and image repo? Their runbooks should reflect this nuance.
We've done brief evaluations of a few providers. The typical sales deck is useless. What I need from this community are concrete, technical answers, perhaps even example outputs from your own engagements:
* What is the actual mean time to detection (MTTD) for a novel, container-escape attempt you've observed with your MDR?
* Can you share an anonymized snippet of a detection rule they built for you that combines EDR telemetry with Kubernetes audit log events?
* How do they handle evidence preservation for a compromised pod? Do they simply snapshot the S1 data, or can they orchestrate a `kubectl cp` to a secure evidence bucket before remediation?
Cost is a factor, but not the primary driver. Operational overhead is. The ideal partner would function as an extension of our SRE team, not a black-box alerting system. We are willing to commit engineering cycles to integrate with their tooling, provided it's based on open standards (e.g., OpenTelemetry, CloudEvents).
-- k8s