Understanding the Components of an Extended Microsoft MDR Service

This blog originally appeared on the site, Managed Sentinel - now a BlueVoyant Company.

During our engagements with customers we are always in a situation where we have to explain the differences between various flavors of MDR services and sometimes even the difference between an on-time deployment of security monitoring solution and the day-to-day maintenance that such solutions require. This is not because our customers don’t understand such services but mostly due to the perception that cloud-based security controls are maintained by the cloud vendor. To an extent that is true, the vendor does commit to keep the cloud-based service up and running and provide totally transparent upgrades, however, the full configuration and tuning of these solutions is still something that has to be done by the customer. In many cases, one can just go with the out-of-the-box policies and configurations but in 99% of the cases, these will lead to a poorly configured product that most likely will fail to deliver the expected value.

In this article, we will attempt to describe some of these components of the typical MDR service and highlight the division of responsibilities between service providers and their customers. This article is using the Microsoft security solutions (XDR + Sentinel SIEM) as an example but the same is true for any combination of products.

The first phase is the initial setup and when onboarding into an MDR service, that has to happen regardless of the current status of the security solution in scope of the service. The MDR provider needs to align the current config with their standard deployment that integrates with their backend and support infrastructure. If the engagement includes a yearly service, some, if not all of initial setup costs could be embedded in the monthly costs.

For both the initial configuration and the monthly service, there are 3 areas that can be seen as high-level categories:

1. SIEM – This is typically used to collect logs from all security devices with the exception of endpoints (though some may very well do that as well). This would include firewalls, IPS/IDS, network devices, Windows AD logs, various SaaS/Cloud apps (depending on the capabilities of the SIEM solution). In case of Azure Sentinel, Microsoft currently provides 60 types of data connectors and at Managed Sentinel we built an additional 65 that can bring data from virtually any type of log source. Some customers may choose just a managed SIEM service that is not considered an MDR as it only covers the maintenance of the SIEM platform and the development of tuning of detections, alerts and SOAR playbooks.
2. EDR – Management and collection of alerts from an endpoint detection and response product such as Microsoft 365 Defender for Endpoints (previously known as Microsoft Defender ATP). In most cases this is the main source of security events as the focus of threat detection has long moved to endpoints. The data collected from perimeter controls like firewalls still has value but the endpoints are the final attack target and that’s where “interesting” things take place. Some vendors only provide DR for the endpoint. The differentiator for Microsoft security stack is that the EDR part should cover not just the traditional EDR (Microsoft 365 Defender for Endpoints) but also the other complementary controls: Defender for Identity, Defender for Office 365 and Microsoft Cloud App Security. In addition to that, the service provider might also need to cover the “defender” components that are part of Azure Security Center.
3. Incident Response (IR) – With the security controls in place, logs collected and alerts tuned, the notifications for various security events are first received by the MDR provider’s SOC that will acknowledge, triage and escalate them based on the IR playbooks that were build with the customer during the initial setup phase. While this is normally considered the MDR service, one can see that it is just a part of the whole infrastructure that is needed in order to reach this phase. The IR is typically 24×7 and requires substantial resources from the provider as they have to ensure 3 shifts of highly trained security analysts that have to continuously deal with security incidents. Most of the costs of the MDR service go against this effort and depending on the level of involvement required from these analysts, a different price model could be applied. As an example, the MDR provider might just offer a basic triaging and review of the alert before forwarding to the customers, while others may provide the option to escalate to their own tier 3 analysts that can take a deep dive into the alert and only engage the customer when they suspect a breach. Some MDR providers charge per incidents, other per endpoint monitored. The later provides better estimation of the MDR costs for budgeting purposes.

The “R” in MDR indicates that the service provider is willing (and capable) of reaching back into your environment to respond or remediate the detected event, all depending of the type of security controls in place as they have to provide specific capabilities. Some older technologies may require that the MDR provider have a virtual presence in your environment so they can act as if they are local security admin.

The main takeaway from this is to make sure that the type of service offered as MDR does indeed match your understanding. If the price seems low, then verify the service details, how many analysts are used, what is the coverage, etc. This is not the place to look for bargains and if it looks too good to be true, then most likely something is missing from the service.