Use Cases for XDR – Part 2: Threat Intel Consumption and Sharing

By Trellix · May 13, 2022
This story was written by Deepak Seth.

In my previous blog, I used email phishing as an example to explain how the Trellix XDR solution can help an organization respond effectively to threats by seamlessly integrating solutions in the organization’s security stack.

In this instalment, I will cover a second use case - Threat Intel Consumption and Sharing. In the current threat environment, organizations rely on accurate threat intelligence to identify and understand threats targeting their industry. This enables the organization to tune and focus their detection processes and security controls to promptly detect and respond to targeted threats.

Organizations typically derive threat intel from the following activities and channels:

Security Analysts’ Investigations – New threat indicators may be discovered when a security analyst reviews data collected from a compromised endpoint. Indicators of Compromise (IOCs) that may be discovered include malicious files, processes or URLs. While conducting static and dynamic analysis on the malicious files, the security analyst may identify additional traits that could be used to create IOCs

Commercial Threat Intel Feeds – Many organizations purchase verified threat intelligence feeds, some of which may have a specific focus such as nation-state actors, deep and dark web threats, or industry-specific threats.

Open-Source Threat Intel Feeds – Organizations also often rely on feeds from Open Source threat intel sources, including free information from vendor blogs and publicly available deny or allow lists from security researchers.

Threat Sharing Groups – There are also various threat sharing groups such as ISAC (Information Sharing and Analysis Center) groups that share industry relevant thread data with vetted members.

The typical methods that organizations use to share threat intel between different security controls often consist of manual processes that are time and labour intensive. Security analysts spend lot of time analysing and manually maintaining IOCs in an Excel spreadsheet or in a threat intelligence platform such as MISP and share these IOCs with different teams in their organization through emails, chat messages, or other manual and error prone methods. In most cases, the security solutions team would then take these IOCs and manually create rules in their firewall solution to detect and block those IOCs. If the IOCs contain email addresses, those would be shared with the email security solution administrator who would then create rules to block emails coming from those suspicious email addresses. This manual method can be very labour intensive, especially if the organization processes thousands of indicators on a daily basis. This method also opens a security window for threat actors to continue to move laterally while the team is busy sharing IOCs manually with different teams.

Assuming each indicator can take about 2 minutes of time to process and an organization is handling approximately 2000 indicators per week from different sources such as those listed above, it would take about 66.6 hours per week of analyst time or about 1.66 full time employees to process and distribute these indicators to different solutions. As we can see in this example, the manual threat intel sharing process not only consumes additional analyst time but it is also error prone and it creates a window of opportunity for the threat actor.

It is not easy to quantify the cost of not sharing the threat intel with the different security controls available inside the organization. There might be more infected endpoints that could be used by threat actors to get additional leverage inside the environment without the organization knowing about it. This could lead to data exfiltration, ransomware, and extortion, which can have significant direct and indirect costs. Depending on the organization’s industry and/or operating location and applicable compliance regulations, the implicit cost of delaying the distribution of threat intelligence can be substantial.

To mitigate the above challenge and to ensure threat intel is available to all solutions in the security stack as soon as it is available, we implemented a Threat Intel Consumption and Sharing use case so that different solutions would have access to the IOCs as soon as they are verified. This would allow the security controls to take action as soon as possible to detect and block further attempts of the attacks and prevent the threats from spreading laterally.

Continuing with our example, when a security analyst finds a malicious file or process on an endpoint, the Trellix XDR solution would immediately share this information with the EDR solution so all endpoints can be scanned for the malicious file or process. If any infected systems are identified, the solution can immediately contain these endpoints so they can be investigated further by the analyst. Then, these potentially compromised endpoints cannot be used by the threat actor to launch additional attacks or to move laterally to other critical assets and thus lateral movement is immediately controlled from these endpoints.

For threat intel received from a feed, the Trellix XDR solution can read these indicators automatically at a regular internal from a centrally maintained file or threat intelligence platform and push these indicators to different security controls.

In the case of email, Trellix XDR would immediately push the relevant indicators, such as email addresses, malicious URLs, or MD5/SHA256 hashes for malicious files to the email security solution so it can block any new emails with based on those indicators before the email is delivered to the end user’s inbox.

At the network level, Trellix XDR would push the relevant indicators such as IP addresses, URLs, or MD5/SHA256 hashes to the network IPS, firewall, and proxy solutions so that any attempts for threat actors to enter the organization at the network level can be detected and stopped immediately.

From a Cloud security perspective, it is important for relevant indicators to be pushed immediately to the different security controls in cloud platforms such as AWS and Azure. For example, in AWS, GuardDuty monitors the security of the AWS environment by analysing and processing VPC flow logs and AWS CloudTrail event logs. Trellix XDR integrates with AWS GuardDuty so it can push indicators such as IP addresses into the deny list, so any traffic from those IP addresses can be monitored and alerted on specifically by GuardDuty. Additionally, Trellix XDR would also push these malicious IP addresses to the web application firewall (WAF) module as well as network ACL rules for AWS so that any connection attempts from these IP address can be blocked at the WAF and Security Groups/VPC level.

As we have seen from this use case, quickly sharing threat intelligence with different security controls is crucial to ensure an organization is able to detect and respond to threats immediately as they are discovered. Providing accurate and timely threat intel to various security solutions, including Network Security, Email Security, Endpoint Security, and Cloud Security ensures they are integrated and working together to provide effective, layered defence for the organization.

Want to read on? Read Part 3.