Running Robust Managed Detection and Response Services

Information security practitioners have published a lot of articles around topics like how to build and run a security operations center (SOC) and specific SOC functions such as incident response and threat hunting. These topics are always important, as threat actors are constantly coming up with more sophisticated attack strategies and vectors.

We, too, want to share some of our experiences in Managed Detection and Response (MDR) with the community, and specifically highlight the factors that have had the most positive impact on our operations.


    • Set a clear vision: Establish specific, reachable security goals. 
    • Choose the right model: Explore the pros and cons of each option instead of defaulting to the popular tiered model right away.
    • Engineer your operation: Look at all sides when creating your detections and response. 


At Cybereason, our company-wide vision is to “protect people and information in the new and open connected world,” where our mission is to “reverse the adversary advantage by empowering defenders with ingenuity and technology to end cyber attacks.”

The Cybereason Global SOC, which delivers managed detection and response services to its customers on every continent, distills this larger vision to: “To provide our customers with effective and timely monitoring, proactive detection, and timely response that protects customers’ networks against the threats of today and tomorrow.

We accomplish our vision through:

    • Persistence: We are always learning and becoming subject matter experts in our sub-specialties. The threat may change, but we will always rise to meet it.
    • Humility: Cybersecurity is a complex and rapidly changing field. No one is an expert in everything. We respect that we may not know something and our product and services may not address every set—but we own these problems and strive to better ourselves, our services, and our product.
    • Honesty: Cybersecurity is a human problem, not just a technical one. And all human relationships are built on trust, and trust, on honesty.

Running MDR with a clear and practical vision is crucial, as your vision sets the stage for successful execution and helps your organization define and reach its goals. 


When you've established your vision, you can consider which way you want to run your MDR operation (whether it's a stand-alone operation or part of a bigger SOC operation). The two main models or layouts are the tiered model and the open model. 

The Tiered Model 

Perhaps the most common layout in the industry, the tiered model entails having a hierarchy with multiple roles scoped to specific tasks. Tasks are usually not shared and are strict to the dedicated role. The most familiar and adopted hierarchy is a two- or  three-tiered model: 

Tier 1: The person that meets the alerts, filters out the noise, and escalates the significant events further up the hierarchy.

Tier 2: The person that typically receives the escalations from Tier 1, and focuses on high-fidelity alerts. 

Tier 3: The person who focuses on critical escalations, engages in advanced services, such as incident response, and applies additional pillars to the analysis and investigation, such as threat hunting and digital forensics.

Tiered Model Pros and Cons


    • Scalability and Speed: This model distributes different types of alerts and their respective action plans among several different tiers, allowing complex operations while not jeopardizing time to remediate (TTR). Such complex operations ingest a vast amount of alerts from different sources, and require a high level of competence to handle, and possibly by a different MDR function. The tiered model enables all of these operations to happen without clogging the flow and slowing down the overall response.


    • Bottlenecks: Alerts can get stuck in a tier level because of insufficient competence or technical failures.
    • Disharmony: Workers on each tier may think that work on other tiers is easier or more interesting: “The grass is always greener on the other side”. This natural issue is very common, especially when a large number of alerts flood the system. For tier 1 analysts, the threat hunting or the incident response work of tiers 2 and 3 could seem like a much better place to be.

The Open Model

The opposite of the tiered model, the open model does not limit specific tasks to certain tiers or levels of analysts. There is a shared pool of assignments and everyone engages with everything, end-to-end. An analyst in this model picks up the initial alert, triages the threat, performs advanced functions such as threat hunting or incident response, and closes the loop by performing remediation.

Open Model Pros and Cons


    • Harmony: As people are more involved in each stage of such a model, the chances of dissonance are low.
    • Scalability and speed: As the people working in such a model have to be highly skilled, the speed with which they can triage and resolve events or incidents could be faster than in the tiered model.


    • Talent: You cannot have a weak link in an efficient and robust open model. It is challenging to find “Swiss army knives”—individuals that are equipped with an equally high level of knowledge in the different domains of InfoSec. 
    • Scalability and speed: While the open model can lead to increased scalability and speed, it can also have the opposite effect: "Swiss army knife" analysts who have to detect, triage, investigate, and respond to alerts face a high degree of pressure that can reduce both overall speed and quality.

What Works for Us

Although many organizations default to the tiered model, each organization should look into how the SOC or MDR fits into its business. For example, a small infosec team that is responsible for protecting an organization might use the open model, while an organization that has a large team that provides "SOC as a service" solutions might use the tiered model.

Our approach is a balance between the tiered model and the open model. Bottlenecks and disharmony are addressed by technical mechanisms, fitted operational processes, and career plans: 

    • Introduce a “Tier 0”,or "automation tier" into the model: Automation can reduce signals and eventually the load from analysts, reducing burn-out while also providing opportunities for analysts to analyze high-fidelity detections and feel involved. This tier can not only automate the filtering of false positives and other redundancies but also genuine though insignificant alerts and their action plans. 
    • Create a concrete career path for each tier: Try not to keep any analyst in a tier for too long, and consider internal mobility as well as temporary job rotations to refresh. Also, keep training and a continuous development plan in place.
    • Engage lower tier analysts in high-end projects, where they can be mentored by the senior tiers. 

image1-2Cybereason Model


For many organizations, one of the main challenges still remains sorting through a high volume of detections to identify alerts that are high-confidence and high-priority.

What Works for Us: To scale and adapt to the ever-evolving threat landscape, we apply discipline and concepts from engineering. 

Complement Out-of-the-Box (OOB) Alerts with Rule-less Logic

While we use the Cybereason Detection Platform and base our actions on the detection the platform generates, we are also proactive, whether by conducting threat hunting exercises or by creating and deploying out-of-band, rule-less detections in our customers' environments that are yet to be fully incorporated into the standard detections database of our platform. 

Break DTIR into Stages

Instead of applying all of our detection, triage, investigation, and response (DTIR) logic and corresponding action plans into one single stage, we have multiple stages: one stage per difficulty and complexity level of both detections and response. We also recommend that you run your alerts through a so-called obstacle course.

Your goal is to convict the initial detection as a significant one. You may choose to apply simple DTIR logic to the initial stage, and raise the complexity of the DTIR logic as the alert passes through the obstacles (that is, from stage to stage).

Focus on Both Potential and Impact

The severity of a detection plays a key factor in the response to that detection, but assigning severity can be inexact and lead to unwanted outcomes. A severity assessment that only takes the potential of the threat into account, and ignores the actual impact, can hurt business continuity and slow down the response process. 

For example, an organization might detect a remote access Trojan (RAT)—on paper, a substantial malware type that can provide full control over an endpoint—and classify the threat as “High” or “Critical” and consequently isolate a system. However, if the organization later discovers that the RAT didn’t execute successfully—for example, the RAT couldn't contact its command and control (C2) server—the organization could have needlessly endangered business continuity.

Ameliorate False Positives

We recommend that you write your DTIR logic to scale by recognizing the consequences of low-quality DTIR logic. For example, when you define DTIR, consider not just how to best possibly catch or respond to the attacker, but also how to cope with breakages in case weak logic leads to false positives or other issues. We recommend that you anticipate such situations and have robust feedback and suppression mechanisms in place to address them. 

Resurrect “Traditional” IOCs

Organizations commonly prioritize Indicators of Behavior (IOB) over traditional static Indicators of Compromise (IOCs). With the development of Extended Detection and Response (XDR), the large variety of ecosystems and data sources that complement endpoint detection inflate the number of logs and alerts. As many XDR detections are based on network and identity elements under the hood, we recommend that you consider using reputation checks for traditional IOCs such as IP, domains, and hashes.

For example, cross-correlating IP addresses, domains, and usernames from Google Workspace events (such as the “download” event) with a known bad database or evidence of suspicious activity in the Cybereason Defense Platform could be a quick way to identify a potential data exfiltration attempt and avoid additional redundant checks, including behavior checks.

As there is no one-size-fits-all approach to running MDR or a SOC, looking into how the operation fits into the business in addition to identifying the specific use-cases will help a team define and create an effective operation and service delivery. The team can also think of the two operational models as a continuum: most organizations can start with the open model, and when the size and complexity of the operation grow, shift to the tiered model.



image2-2Vlad Ogranovich, Director Cybereason Global SOC, EMEA

Vlad Ogranovich has been in the industry for over 10 years, providing large-scale incident response, digital forensics, threat intelligence, and malware analysis services for large organizations. Today, Vlad leads and oversees the Global SOC business unit in the EMEA region.

Cybereason Global SOC Team
About the Author

Cybereason Global SOC Team

The Cybereason Global SOC Team delivers 24/7 Managed Detection and Response services to customers on every continent. Led by cybersecurity experts with experience working for government, the military and multiple industry verticals, the Cybereason Global SOC Team continuously hunts for the most sophisticated and pervasive threats to support our mission to end cyberattacks on the endpoint, across the enterprise, and everywhere the battle moves.

All Posts by Cybereason Global SOC Team