XSOAR is a powerful platform. Not only does it come with automation playbooks, integrations, incident management, and machine learning to name a few components, but has evolved into one of the finest security management products in the SOAR space.

This article focuses on the trends in XSOAR that readers who are familiar with the platform will likely find helpful for the coming year.

Overview

The recent advances in XSOAR can be understood from two perspectives: macro and micro.

The macro perspective defines the direction of XSOAR as a product. Some of the important trends that can be considered from a macro perspective are listed below:

1. Automation and Orchestration.
2. Cloud Adoption.
3. Artificial Intelligence and Machine Learning.
4. Multi-cloud and Hybrid environments.

The automation playbooks have been a powerful feature that has allowed security teams to automate incident response tasks, standardise incident response procedures, and improve incident visibility. With multi-cloud, XSOAR enables organisations to take advantage of the different features and services offered by different cloud providers and to improve flexibility, disaster recovery, cost management and compliance.

The microscopic developments in XSOAR are concerned with building integrations on XSOAR. Some of these microscopic developments are listed below (and are discussed further in detail in this document):

1. Mirroring integration
2. Developing IAM integration
3. Integration cache
4. Long running containers

Mirroring Integration

A common feature that XSOAR provides is the ability to ingest incidents from a platform integrated with it. These incidents on XSOAR help the security teams to deal better with the issues.

This feature provides outstanding value, but many times the incidents are out of sync and security analysts have to manually keep track of these incidents in their corresponding source systems. To solve this problem one can implement “Mirroring” in the same integration to automate this activity.

The mirroring integration, a recent development, helps enterprises achieve bidirectional sync of incidents/cases/tickets from another system.

1. Configure the connection: First, you will need to configure a connection between the two instances of Cortex XSOAR that you want to replicate incidents between. This is done by creating an API key in the source instance and providing it to the target instance.
2. Select incidents to replicate: Once the connection is configured, you can select which incidents you want to replicate. You can choose to replicate all incidents or only incidents that match specific criteria.
3. Replicate incidents: Once the incidents are selected, they will be replicated to the target instance in real-time or on a scheduled basis, depending on your configuration.
4. View and manage replicated incidents: The replicated incidents will be visible in the target instance and can be managed and worked on just like any other incident.

Note: These are configurable - the sync can be unidirectional as well. Overall, the possible options include: Incoming, Outgoing, Both Directions,

Long Running Containers

Long-running containers can be utilised in making integrations that have the utility of running uninterrupted for long hours or a never-ending interval. Such types of integrations do not need to have automation scripts that need to run for an extended period of time, functionality can be driven through integration itself. The integration can be individual commands or a set of commands called in order.

This functionality is user configurable, meaning, while configuring the integration one can choose the “long running” flag to enable the long running part of the integration. This initiates an instance that starts a long running container. If the user de-selects the option, the container will terminate.

Some of the important points to consider while building integrations with long running containers are discussed below:

1. This integration is a must-have when it comes to Actively Listening or Streaming workflows related integrations.
2. The input data from various sources can be collected on a continuous basis and taken action on. The source can be endpoint security software, intrusion detection systems, and other security tools.
3. The integrations using the long running containers can be used to retain data for long-term analysis and compliance purposes, such as storing data for forensic analysis.
4. Long-running integrations can be used to monitor the security state of an organisation's infrastructure, such as servers, endpoints, and networks, and to alert security teams when suspicious activity is detected.

Long-term data retention: Long-running containers can be used to retain data for long-term analysis and compliance purposes, such as storing data for forensic analysis.

Integration Cache

At times, there is a need to store data between commands. For example, if a command generates a report, but it can be downloaded only after user validation, the report can be stored in an integration cache in the meantime.

Another popular example of an integration cache could be maintaining the OAuth tokens. A lot of modern APIs are built to have OAuth/OAuth2 type of authorisation and authentication. For instance, vendors like Microsoft, HP Aruba, and Box.com, have APIs that authenticate via OAuth2 and in the coming years, a lot of vendors might adopt the same standard.

Where OAuth workflow is concerned, once authorised, the endpoints will yield a set of Refresh and Access tokens which need to be rotated as per the validity. The OAuth tokens can be stored in the integration cache. The cached data can be used in subsequent runs to improve performance and reduce the number of API calls made to the external source.

The cache can be configured with various settings, such as the amount of time that data should be stored before it is considered expired and needs to be refreshed. Following are some of the advantages of integration cache when implemented in an integration environment:

1. No need to go beyond the XSOAR territory. For example, saving the token outside the XSOAR firewall.
2. Safe and easy to access.

IAM Integration

An Identity and Access Management (IAM) integration in XSOAR (also known as Demisto) involves creating a script that allows XSOAR to communicate with an IAM service, such as Okta or Microsoft Azure Active Directory. The script can handle the following tasks:

1. Authenticating XSOAR with the IAM service.
2. Creating and managing user accounts.
3. Handling access control.

Developing an IAM integration in XSOAR requires the IAM service's API to communicate with XSOAR's integration development framework used to create and deploy integrations.

XSOAR provides sample scripts built for specific IAM providers. These scripts can be used as a starting point for the integration to be further built out. Once the script is complete and tested, it can be deployed to your XSOAR instance.

Metron Security provides on-demand and effective approaches to managing third-party integrations for security ecosystems. Metron has delivered automation solutions for over 200 security applications along with several hundred custom automation solutions.

Metron Security is an XSOAR technology development partner. For more information contact us at connect@metronlabs.com