Use Cases for XDR – Part 3: Improving SOC Effectiveness with XDR

By Trellix · July 15, 2022
This story was written by Deepak Seth.

In part 1 and part 2 of my previous blogs, I explained the capabilities of Trellix XDR (Extended detection and response) platform through two use cases - Phishing email and Threat Intel sharing. In part 3 of this Trellix XDR Blog series, I will be leveraging a live example of Malware playbook and will showcase, how a well integrated XDR platform can help organization around Malware detection, response and remediation. Most of the organizations faces challenges around Malware containment and hopefully this article would give some guidance to the organizations currently evaluating XDR and what they should expect from an XDR platform. Happy reading and feel free to reach out to your Trellix team to further discuss any of these use cases and how they can be customized specifically to your organization.

In the current threat environment, SOC teams continuously face the pressure of detecting an intrusion as quickly as possible before it becomes a major security incident. With so many point products in use in a typical organization, it is often very time consuming and challenging for the SOC team to search through all of the noise to find important alerts that may indicate the presence of a threat in the environment. Recent complex supply chain cyber attacks and critical vulnerabilites in trusted network and security solutions exacerbate the problem, making it even more challenging to find the proverbial “needle in a haystack” and to properly determine how to respond when a security anomaly is detected.

Thus, there is a compelling need for today’s SOC team to have an access to an XDR platform that can enable them to detect, respond to and remediate threats across all attack channels including Email, Endpoint, Network and Cloud without the inefficiencies of switching between multiple point solutions and with the ability to work with relevant data that’s actionable. The XDR platform should automate most of the manual and time consuming (yet important) investigative tasks and present data that’s more relevant to the analyst’s investigation. Additionally, the XDR platform should codify investigation and response playbooks, making it easy for even a less experienced analyst to make the right decisions and take rapid and effective actions to stop an attack and limit the scope of an incident.

Further, the effectiveness of proactive cyber threat hunters and Incident responders will increase when leveraging an XDR platform that is powered by threat intelligence that tracks evolving threats as part of a living and learning ecosystem that grows stronger, smarter and more agile over time.

To better understand the effectiveness of this XDR platform, we should first review the workflow a security team would follow without the use of a well implemented and integrated XDR platform. In most organizations, a team of security analysts would be monitoring alerts from some combination of SIEM, EDR, NDR, SWG, SEG, and CASB solutions and a critical alert from one of these solutions may become the initial data point that prompts an investigation. Take an example of an alert from a firewall where a command and control (C&C) communication channel to a potentially malicious IP address is identified. Unfortunately, as noted in the Mandiant M-Trends threat analyst report from 2022 (https://www.mandiant.com/resources/m-trends-2022), the typical dwell time for detecting an intrusion is around 21 days, which provides the attacker with ample time to infiltrate the environment before the SOC team identifies a potential intrusion, triages the alert, extracts IOC’s, attempts to validate those IOC’s by leveraging threat intelligence data, and makes a determination if the alert is a true positive.

One of the ways to reduce the dwell time is if XDR is able to have the capability to link events together which is where correlation plays a very crucial role specially in detecting intrusions that are low and slow and to tells an analyst what happened during the breach. In order to perform this correlation, Trellix XDR gathers all events that may attribute towards the alert. This way the analyst has visibility on unique events that a vendors trigger may not know about yet. These correlated events are generally posted in a visual, so the analyst can visualize patterns which then allows them to search for additional context that may have affected another system or credential. This is the reason why the correlation is important to tie those events together and help clean up the noise by visualizing the attack. In order for XDR to correlate events, the organization also needs to setup a policy that trigger on weak signal that combines additional weak signals and makes it a bigger alert or to put it simply, weak + weak + weak = Alert!!!. Trellix XDR would leverage these multiple low fidelity events to trigger an actionable alert. Once this alert is triggered, organizations would be able to cut down on the 21 days of dwell time into something that might be few minutes or days specially if the attack is low and slow.

Once an incident is declared, the SOC analyst would need to scope the intrusion. It is very important for a SOC analyst to scope an intrusion quickly and accurately to determine the extent of the attack, including how many other endpoints/servers have been infected by this intrusion. The scoping needs to happen as quickly as possible as the more time the SOC analyst spends on this activity, the more time or window of opportunity is available to the threat actor to continue spreading in the environment and increasing the scope of the attack. To determine the scope, the analysts will likely need to pull information from a variety of point products such as SWG, SEG, CASB, DLP, EDR, SIEM, firewalls, IDS/IPS, NDR, and others and correlate the results.

Another portion of the scoping is to determine if any data has been accessed, and if so, what data and how much data has been exfiltrated. Without a well implemented and integrated XDR platform, security analysts would likely end up working manually with the data protection team that’s managing network and host DLP solutions and sharing IOC’s with them so the team can determine if there are any data or files that may have been sent out of the network as part of the attack. This is usually determined by a Network DLP solution that monitors all data exiting the network to identify files and other data that is being sent out of the network.

It can take a considerable amount of time for analysts to gather and share all the network based IOC’s with the data protection team who then manually create policies in the Network DLP solution to detect and prevent further data leakage. This approach is very time consuming and its effectiveness relies on the speed with which an analyst can share the IOC’s with data protection team and the speed with which the data protection team can then create policies in the network DLP prevent solution. As the attacker changes tactics, the IOCs will likely change causing additional manual steps for the security team to try to keep up with the attacker and eventually overwhelming the security team.

Now, lets see how a well integrated and implemented XDR platform can make this scenario much simpler to deal with. A well implemented XDR platform enables the SOC team by giving them access to all the tools and dashboards to be able to quickly scope an incident so the response and remediation actions can be initiated. This XDR platform should have the necessary information curated from different point products such as SWG, SEG, CASB, DLP, EDR, SIEM, Firewall, IDS/IPS, NDR etc. so that the SOC analyst should be able to quickly find out all the endpoints (remote, mobile, cloud, IOT devices) that have been part of this intrusion via different attack channels such as Endpoint, Network, Email and Cloud. A well integrated XDR solution should also provides all the necessary integration with a DLP solution so the data leakage incidents can be discovered quickly.

In the below simple Malware playbook, I am going to highlight different phases during an intrusion and how a Trellix XDR platform can help the SOC team during each of the phases.

Intrusion Phase	XDR Driven Playbook	Outcome of this step
Detection	Trellix XDR platform would be actively monitoring for alerts/events from various sensors including SIEM, ticketing system, email security, endpoint security, DNS logs, web proxy logs, etc. or even notifications from System Administrators, customers, ISP’s or other third parties about potential malware.	This is part of the 24x7 monitoring of the organization environment and provides an initial pivot point for the investigation to begin.
Investigation / Analysis	From the initial alert detection, Trellix XDR platform would Identify IOC’s such as hashes, links, IP addresses, Domains, URL’s and more.	IOC’s are extracted.
	Trellix XDR platform would validate these IOC’s from sources such as VirusTotal and any other third party threat intel sources.	IOC’s are validated.
	If a malware sample is identified, Trellix XDR platform would automatically run this sample inside an integrated sandbox environment to check the malware behaviour and to extract the following information: network connections; Registry modifications; files dropped, accessed, or modified, processes created or modified; deobfuscated scripts; services created or launched; scheduled tasks created. This step would give additional IOC’s useful for detecting lateral movement and help quickly and accurately scope the incident. Proper scoping of the incident can help reduce the attacker’s overall dwell time by ensuring the attacker is fully removed from the environment during the containment and eradication phase.	Additional IOC’s are identified.
	Trellix XDR platform would also automatically scan/sweep the Enterprise by performing the following tasks: Update endpoint security (e.g. EPP/EDR) engine ruleset and policies. Update network security (e.g. FW, IDS/IPS) rules with IOC’s. Search endpoints for IOC’s with EDR Search SIEM for IOC’s Search FW, proxy, DNS logs for IOC’s.	Identify endpoints that may be impacted by lateral movement and need to be further investigated.
	Trellix XDR platform would request a triage package from all the affected endpoints.	Triage package to be further analysed by the L2 and L3 SOC analysts.
	Trellix XDR platform would also automatically check with the data protection solution to find out what data/files may have been leaked in this incident.	Extent of data leakage is determined in this step.
Containment / Eradication	Trellix XDR platform would automatically contain all the affected endpoints at an endpoint level, remove / shutdown virtual interfaces, place affected endpoints in dirty VLAN or shut down the switch port. The XDR would also create a prevention rule/policy in FW, proxy, AV/EDR, and web filtering solutions so future attempts of the same malware can be prevented/stopped. This containment step can be performed automatically or can be queued up for approval by a Security analyst who can determine whether to perform the containment or policy change or not based on the presented evidence.	The purpose of this step is to immediately contain affected endpoints to stop the further lateral spead of the malware.
	Trellix XDR platform would also check if a EDR solution is running on endpoints in the affected network environment, and if not, then it would install an EDR agent.	Making sure that EDR solution is installed on all potentially affected endpoints.
Reporting	Trellix XDR platform would prepare a report that includes actions taken; affected hosts; investigated URL’s, domains, IP’s, files and hashes; details of data leakage; updated policies across different security solutions; and contained endpoints. This report would be presented to the SOC team for them to review and take further action as necessary.	Report of all the actions taken is presented.
Post Incident	Trellix XDR platform would update SIEM solution with any new detection rules, update EDR solution with new IOC’s, update IPS signatures, update SEG and SWG with any new domains, URL’s, and email addresses.	Ensure the solution is updated with the new IOC’s.

As you can see from the above phases, the activities/tasks that may otherwise take weeks can be completed within a few hours. Further, based on the data presented in the Trellix XDR generated report and triage packages, the SOC team can now take the following actions:

• Determine the context in which the malware was executed. For example if the malware was executed while the user was admin/root of the machine, the system likely needs to be wiped, in the case of a physical system, or deleted in the case of a virtual system. Whereas, if the malware was not executed with admin / root privileges then a different approach may be warranted including cleaning IOC’s from the endpoints. These IOC’s could be files, registry keys, services, scheduled tasks, WMI providers.
• Scan affected systems for vulnerabilities and patch them.
• Restore services and access by removing containment rules that were created during the containment phase.
• Update the following documents as needed – Policies, Processes, Procedures, Playbooks, and Runbooks

As we have seen in the above scenario, a well-implemented XDR platform should have content and well-defined, integrated workflows that support prevention, detection and response use cases which would help in reducing an attacker’s dwell time and the time to contain threats. An organization can acquire multiple point products from different vendors and manually perform integrations and can form a XDR platform but this integration can require lot of manual efforts and not a lot of organizations have time and investment to do this. Organizations are looking for a vendor that has all the necessary integration and well defined workflows in place not only around its own solutions but also other third party solutions and thus making it a combination of Hybrid and Open XDR system.