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.
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:
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.
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.
Pros:
Cons:
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.
Pros:
Cons:
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:
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.
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.
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).
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.
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.
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.
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.