The Five Critical Components of XDR Integration

Alexander Nachaj -

XDR (extended detection and response) platforms come in various formats and capabilities. While some features tend to be common across all implementations - such as hosted marketplaces, the ability to parse and ingest data from 3rd party platforms, and the ability to detect threats in a customer’s environment - the true value of a XDR platform is unlocked when it can interoperate with a wide variety of cybersecurity tools and platforms.

This is where security integrations come into play.

XDR, by its nature, is meant to act as a central hub of your security operations, collecting and correlating data across multiple systems used by your Sec-Ops team. A mature XDR platform also needs response capabilities so that you can automatically remediate threats in your environment. With robust and reliable connections between third-party apps, you can effectively empower your team to focus on the major issues and cases, while minimizing the number of man hours that would otherwise go into review and other manual processes.

Building XDR integrations is, of course, not without its challenges.

In any integration project, there is typically a massive amount of data that has to move between two applications. Ensuring that the architecture can handle the ingest effectively is always a top priority, while also taking care that the data is formatted appropriately between both apps. Other concerns include having the resources to maintain the necessary lab and testing environment throughout the process, while also setting up the infrastructure to enable future scaling.

In this guide, we will detail five critical components of XDR integration along with their potential challenges and resolutions.

The 5 Critical Components of XDR

  1. Data Ingest
  2. Data Filtering
  3. Parser
  4. Response
  5. Reporting and Dashboards

1. Data Ingest

Data ingestion is a core feature of XDRs. An XDR can be integrated with several other security tools (including but not limited to XDRs, EDR’s, SIEM, SOAR platforms, Firewalls, Identity Providers) and data can flow from one entity to another. The integration of two can be bi-directional in nature where data flow is concerned.

Some of the challenges that can be faced when carrying out integrations for data ingestion are:

  1. Large number of platforms that need to be integrated.
  2. Possible duplication of data.
  3. Non-availability of the APIs from the source system.
  4. Sudden spikes in the amount of events received from the source system.

Fortunately, there are ways to alleviate these:

  1. Scripts should be deployed that poll the target platform periodically for new events, and send these new events to the target XDR platform.
  2. Event duplication occurs at the boundary between the time of two consecutive polls. As such, multiple strategies to de-duplicate events received from the source platform should be deployed.
  3. For legacy systems which do not have a REST API, one can still fetch the data using multiple methods:
  • Setting up a syslog listener that the source can stream events.
  • SSH into the source system, run commands and parse the output.

4. Sudden spikes in data can be handled by horizontal scaling of the data ingestion pods.

2. Data Filtering

XDR platforms ingest data from multiple platforms, and this can cause the data storage requirements to grow exponentially. Data storage comes with a cost, and a balance needs to be maintained between how much data is ingested and stored in the platform.

As such, common challenges include:

  1. Large volume of data ingested depending upon how many platforms the customer is integrating.
  2. Ability to filter out events from “chatty” data sources which can overwhelm the ingestion capacity of the XDR platform.

Some of the ways to streamline and alleviate data filtering and ingesting issues are:

  1. Ensuring data ingestion modules are configurable by the end user. Data filtering at the integration level itself can be key to ensuring that unnecessary events are not pushed to the XDR platform at all.
  2. Ensuring end-user/customer with control on what events should be ingested into the XDR platform in the first place.

3. Parser

Parsers are used to convert the source data/events into a format that is useful for the target XDR platform. There are a couple of points where parsers are useful:

  1. At ingest time: Parsers are used to convert the source data into the target schema before storing them in the internal XDR platform. This allows for quick searches across large volumes of data, and is useful when we know the source and target schemas beforehand.
  2. At search time: Parsers can be used in field extraction to view interesting patterns in your data. These searches are slower, but users have the advantage of changing the target schema at runtime.

Like other components, parsers are not without challenges:

  1. Parsers need to be efficient at extracting data, as the parsing logic can take up significant CPU time when the event volume is high.
  2. Most platforms have built in parsers and have their own language for writing parsers.

When troubleshooting the above, it helps to have a holistic view of event types from across all the platforms:

  1. Coordination between product managers and the integration team, such as reviewing certain fields as well as suggesting the mappings to the target XDR platform.
  2. Include efficient parsers in our Data Ingest modules that allow users to transform the data before it even reaches the target XDR platform.

4. Response

Response integrations impart XDRs with the ability to respond to security events in the customers environment. Response integrations have similar functionality to SOAR platforms. At the moment we are seeing simple response logic being built into XDR platforms, but there is a clear direction toward making SOAR as a native part of XDR platforms.

For example, if there is an attack on a system and an alert is triggered which was captured by the native XDR agent, and the alert has some IOC’s associated with it having certain hash values, IP’s etc., then we can send these to the XDR and add it to the EDL (External Dynamic List) to block them. If the alert is associated with a user, we can disable the user in the configured Identity Management platform.

Response actions can also be manual (triggered by SOC Analysts) or automatic (triggered by the XDR platform based on configuration settings provided by the SOC Administrator).

Challenges from the response component are usually fewer but no less pressing than the other components of the project:

  1. Ensuring the response understands the actions that are provided by the target platform. Some examples are:
  • Kill or quarantine a process.
  • Isolate the machine.
  • Quarantine the user.

Typical responses to configure when a platform detects a threat are:

  1. Locate the user that triggered the threat in an Identity Management platform (e.g. Google Workspace, Okta, etc) and suspend them.
  2. Use an EDR endpoint to isolate the machine where the threat originated from, in order to prevent that machine from infecting others.
  3. Add firewall ACL rules to stop traffic from the machine where the threat originated.

5. Reporting and Dashboards

Dashboard-based integration is used for better visualizing and categorizing of the data. Some of the common dashboards include:

  1. Drill Down.
  2. Interactive dashboards.
  3. Responsive dashboards.

Rarely are dashboards one size-fits-all. Each organization has its own playbooks, apps, and workflows that need to be considered in order to ensure the dashboard delivers the most impactful information:

  1. Creating dashboards which will be concise, neat and informative.
  2. Testing the dashboard data with the API data for data consistency.
  3. Curating the data to get meaningful insights.
  4. Selecting the right illustrations to describe the data.
  5. Integrations having large chunks of data to be displayed on the dashboard.

To help meet this criteria:

  1. Drill down dashboards should help the user filter particular sets of data. For example, if we want to see the details of an event, then we can click or hover over the event and see the details in the same dashboard or in a new tab.
  2. Interactive dashboards need to help in simplifying and segregating the data. For example, if there are a thousand events in a table and if we want to see a particular event, one can add filters on the table which will work on the event name, event id or other event details. Further the users can download reports in pdf or csv format as desired.

Considering venturing into security automation and integration - particularly between a SIEM/SOAR and an EDR/XDR? Metron has experience integrating multiple security tools with primary systems, along with setting up automation components.

If you are considering any custom cybersecurity solution that focuses on the resources and needs of your organization, please send a note to connect@metronlabs.com.