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.
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:
- Automation and Orchestration.
- Cloud Adoption.
- Artificial Intelligence and Machine Learning.
- Multi-cloud and Hybrid environments.
The automation playbooks have been a powerful feature which 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 the document ahead):
- Mirroring integration
- Developing IAM integration
- Integration cache
- Long running containers
A common feature that XSOAR provides is to ingest incidents from a platform integrated with it, these incidents on XSOAR helps the Security teams to better deal with the issues.
This feature provides outstanding value but many times the incidents are out of sync and Security Analysts would 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 in achieving bidirectional sync of incident/cases/tickets from another system.
- 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.
- 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.
- 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.
- 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 that 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 for a never ending interval. Such types of integrations do not need to have automation scripts which 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 which 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.
- This integration is a must have when it comes to Actively Listening or Streaming workflows related integrations
- 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.
- 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.
- 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.
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 a user validation, the report can be stored in an integration cache in the meantime.
Another popular example of 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, Box.com, have APIs which authenticate via OAuth2 and in the coming years a lot of vendors might adopt the same standard.
As per the OAuth workflow is concerned, once authorised the endpoints will yield a set of Refresh and Access tokens and they 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.
- No need to go beyond the XSOAR territory, for example saving the token outside the XSOAR firewall
- Safe and easy to access.
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.
- Authenticating XSOAR with the IAM service.
- Creating and managing user accounts.
- 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 150 security applications along with several hundred custom automation solutions.
Metron Security is an XSOAR technology development partner. For more information contact us at firstname.lastname@example.org