23. 06. 2023 Massimo Giaimo Blue Team, SEC4U

SOC vs. MDR: Understanding the Key Differences for Comprehensive Cybersecurity

Introduction

In today’s increasingly complex cybersecurity landscape, it is crucial for organizations to adopt effective solutions to protect their data and digital assets from ever-evolving threats.

Two commonly used services in this regard are SOC (Security Operations Center) and MDR (Managed Detection and Response). While both aim to ensure cybersecurity, there are important differences that need to be understood to choose the service that best suits your needs.

Let’s start with a high-level basic description.

A SOC is a centralized function within an organization that employs people, processes, and technology to continuously monitor and improve an organization’s security posture while preventing, detecting, analyzing, and responding to cybersecurity incidents.

The key technological element underlying the SOC service is SIEM. According to the definition provided by Gartner, the Security information and event management (SIEM) technology supports threat detection, compliance and security incident management through the collection and analysis (both near real time and historical) of security events, as well as a wide variety of other event and contextual data sources. The core capabilities are a broad scope of log event collection and management, the ability to analyze log events and other data across disparate sources, and operational capabilities (such as incident management, dashboards and reporting).

A MDR, in according to the definition provided by Crowdstrike, is essentially EDR purchased as a service. This service manages endpoint security and focuses on mitigating, eliminating and remediating threats with a dedicated, experienced security team. EDR is the baseline monitoring and threat detection tool for endpoints and the foundation for every cybersecurity strategy. This solution relies on software agents or sensors installed on endpoints to capture data, which it sends to a centralized repository for analysis.

In this article, we will explore the key differences between SOC and MDR, highlighting the unique aspects of each. Our independent position allows us to try to shed some light with respect to the descriptions that in some cases product vendors provide.

1) Monitoring Capabilities
SOC: A SOC service provides comprehensive visibility into security events occurring both inside and outside an organization. It integrates multiple sources of data, including logs from firewalls, switches, routers, access points, printers, IoT devices, OT devices (such as PLCs, Scada Servers, HMIs), access gates, and application logs (e.g., web servers, database queries). This broad monitoring capability allows for a holistic view of the security landscape.

MDR: On the other hand, an MDR service relies solely on an EDR (Endpoint Detection and Response) software as its primary source of events. EDR software, while effective in monitoring the security events on the hosts where it is installed, lacks visibility into the broader network infrastructure. This limitation excludes crucial security event data from various devices and services within the organization.

2) False Positives and Triage
SOC: A well-structured SOC service with human analysts ensures detailed and in-depth analysis of generated alerts. This human touch enables the elimination of false positives and facilitates a focused response to genuine security threats.

MDR: MDR services often rely on fully automated triage processes. Consequently, if the EDR software generates numerous false positives, the MDR service customer may be overwhelmed with a high number of tickets to manage, which can divert resources and attention away from legitimate security incidents.

3) Threat Intelligence
SOC: A SOC service typically incorporates a Threat Intelligence component, which provides up-to-date knowledge and insights into emerging threats, vulnerabilities, and attack patterns. This intelligence plays a vital role in proactive threat hunting and improving the overall cybersecurity posture.

MDR: In contrast, an MDR service often lacks a dedicated Threat Intelligence service, which can be a significant limitation. Without this crucial component, organizations may be more reactive in their cybersecurity approach, potentially missing out on early threat detection and mitigation.

4) Structure and Availability
SOC: A SOC service is typically more structurally organized and operates 24/7, ensuring constant monitoring and timely response to security incidents. The presence of skilled human resources enables detailed analysis of alerts and facilitates effective incident response and management.

MDR: While an MDR service can provide some level of continuous monitoring, it may lack the same level of structural organization and may not always have dedicated human analysts available round-the-clock. This can hinder the ability to analyze and respond to security incidents promptly and comprehensively.

5) Vulnerability Assessment
SOC: SOC services often encompass Vulnerability Assessment activities as part of their comprehensive cybersecurity approach. These assessments help identify weaknesses in the infrastructure, systems, and applications, enabling proactive remediation of vulnerabilities before they can be exploited.

MDR: MDR services typically focus on detection and response rather than proactive vulnerability assessment. While the EDR software may detect certain indicators of compromise, it may not provide the same depth of vulnerability analysis and identification as a dedicated Vulnerability Assessment service.

6) Device Compatibility
SOC: A SOC service accommodates a wide range of devices, including both modern and legacy systems. This flexibility ensures that security monitoring and incident response cover the entire infrastructure, even with devices that do not support agent-based monitoring. Simply for each source you go to evaluate the ability to generate and forward events to the external destination, the SIEM. The various SIEM software vendors typically make available a vast amount of event normalization templates for the most common sources. Where these templates, for specific sources, are not available, the SOC team will be able to develop them themselves, thus being able to effectively integrate any type of event.

MDR: An MDR service often assumes the presence of supported operating system versions within the customer’s infrastructure. This can be problematic for organizations, particularly those operating in industrial sectors, where a significant number of obsolete devices may not be compatible with EDR agent installation.

7) Bypass of security controls
MDR: There are an increasing number of instances of malware being developed with the ability to perform bypass activities against EDR software, rendering the checks performed by it useless.

SOC: For the reason explained above, it is important not to base one’s detection capability solely and exclusively on EDR software, but by flanking other solutions, such as sysmon, which natively at the operating system level allow for the generation and collection of events capable of enabling a high detection capability.

Example of malware not detected by any EDR

8) Incident Response and Mitigation:
SOC: In the event of an incident, a SOC service is equipped to respond comprehensively. It can isolate affected clients, analyze the scope of the incident across the network, and potentially create deny rules on firewall devices to prevent further spread. This proactive approach helps contain and mitigate the impact of security incidents effectively.

MDR: An MDR service, primarily relying on EDR software, may face limitations in incident response. Its ability to isolate the affected client and contain the incident is restricted to the systems where the EDR agent is installed. If the infection has spread to other systems without the agent, the MDR service may lack visibility and control over those endpoints, potentially leaving them vulnerable to further exploitation.

9) Lock-In

SOC: Hardly any SOC can cause lock-in related issues for its customers. In fact, the service is built to be able to integrate heterogeneous sources. Clearly in the event of any migration to a different SOC service provider, migration activities will be most efficient if the SIEM software used by the SOC from which one is exiting provides for exporting events in a readable and usable format (for example: json) for importing all events within the SIEM software used by the new provider.

MDR: being the MDR service provider usually partners with a specific EDR software vendor (e.g.: Crowdstrike, Palo Alto, Trendmicro,…) it is clear that the issue of vendor dependence in this type of service is evident. If the client of the MDR service decides to change the service provider the consequence will be to lose all the event history collected up to that point (unless one chooses an MDR provider that uses the same EDR technology and then in that case there will probably be a possibility to keep the event history).

Conclusion

While both SOC and MDR services aim to enhance cybersecurity, it is essential to consider the specific needs and requirements of your organization. A SOC service offers comprehensive visibility, human expertise, and a proactive approach, making it the preferred choice for organizations seeking complete security event monitoring and incident response capabilities. However, MDR services can still provide value in specific scenarios where endpoint-focused monitoring is the primary concern. An EDR solution can clearly be (and indeed should always be) one of the technology elements integrated within a SOC service. In this case, simply the EDR solution becomes one of many sources of events for the SIEM. Ultimately, the decision should be based on a thorough evaluation of your organization’s infrastructure, risk profile, and desired level of security.

Massimo Giaimo

Massimo Giaimo

Team Leader Cyber Security at Würth Phoenix

Author

Massimo Giaimo

Team Leader Cyber Security at Würth Phoenix

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive