Skip to content
English
Sign in
Contact us
  • There are no suggestions because the search field is empty.

Integration with external platforms

Overview

Cydarm can be integrated with many types of external platforms, including:

  • SIEM
  • SOAR
  • Notification
  • Threat intelligence
  • ITSM

Cydarm provides four methods to integrate with external platforms:

  1. Case creation and appending via email
  2. Case creation via webhook
  3. Triggered actions
  4. Direct API access

In this article we provide an overview of each of these methods.

Architectural considerations

Before planning an integration, it is useful to consider the following:

  1. How is the external platform required to interact with Cydarm? Will it send data, receive data, or both?
  2. If the external platform is both sending and receiving data, how do we prevent the same data being inadvertently sent back and forth in a loop?
  3. Does security policy permit Cydarm to store credentials for a service account to access the external platform?
  4. Does security policy permit the external platform to store credentials to access Cydarm?
  5. Does the external platform have a mechanism for pushing data to Cydarm?
  6. Does the external platform have a mechanism for receiving data from Cydarm?
  7. What firewall or micro-segmentation rules will have to be modified to enable connectivity between Cydarm and the external platform?
  8. What data formats does the external platform produce or ingest?

Email integration

Email is simple and ubiquitous, making it the quickest way to get started with ingesting data into Cydarm. The Email Poller service, described on this page, polls an IMAP service, scanning for unread messages and using these to create new cases or append to existing cases. To append to an existing case, the username part of the email address should include a label with the case locator, eg. soc-alert+KSUFV6@yourcompany.com.

Webhook integration

Webhook integration is suited to SIEM and SOAR products that are able to push alerts or correlated events. Webhooks can be used to start cases by configuring the external platform with a URL, as per this article describing Splunk integration. Data sent to Cydarm via webhook is sent to a translation engine for conversion into Structured Threat Information eXchange format (STIX), then this data used to create a new case.

Triggered actions

Triggered actions are useful for pushing data out of Cydarm. Triggered actions enable an administrator to associate a particular REST operation against an API endpoint (the "resource") with an action that follows. For example, when a HTTP POST request is submitted to add new data to a case, we may want to scan that data to find observables, send the observables to an external SOAR platform for enrichment, then submit the enriched results back into the same case. Actions can also be triggered to run on a schedule, using the TIME resource as a trigger. An example of how to trigger an action can be found here. Triggered actions will often need to perform direct API access (described in the next section) to post results onto the platform.

Direct API access

For precise control over interaction with the platform, direct API access is the most flexible of the integration options. The Cydarm API covers every aspect of the functionality of the platform. Direct API access is used for . Some examples of direct API usage are presented in this article. Two examples of how the API can be used with external platforms follow.

Example 1: journaling SOAR actions

A Cydarm customer needed to record the outcomes of manual, automated, and hybrid workflows. The manual incident response workflows were being captured using Cydarm cases, as the SOC analysts worked on cases. For the automated workflows, an external SOAR platform had been configured, but the SOC manager wanted to maintain records of what SOAR actions had occurred, how long they took, and what the outcomes were, and to ensure that this information was available in the same system of record as the manual cases, for convenient aggregation of metrics. A hybrid scenario was also presented, where the SOAR platform would enrich observables to produce a complete analysis, then the SOC analyst would inspect the result and determine whether Containment or Remediation steps should follow.


The SOAR workflow was realised by sending a SIEM alert directly to the SOAR platform, causing the SOAR platform to perform automated response actions to the alert. Towards the end of the SOAR workflow, a Python script was used to send result data to Cydarm via the API, opening a new case and attaching information about the actions performed by the SOAR platform. The SOC analyst could then pick up where the SOAR platform left off, deciding what next steps (if any) needed to be performed.

Example 2: tracking ITSM tickets

A Cydarm customer wanted the ability for SOC analysts to task IT teams with remediation activity. Rather than copy and paste information into an external ITSM tool, or engage in a lengthy email chain, Cydarm was configured with a trigger action to enable SOC analysts to send ticket creation requests from a Cydarm case thread to an external ITSM tool. The details of the ticket created were recorded in the Cydarm case, and then the ITSM poller software continued to monitor the ITSM ticket, posting updates in the Cydarm case view. In this way, the SOC analyst was relieved from the burden of having to constantly check the progress of remediation activities, switching to the external ITSM platform.


For more detailed technical information please refer to our Cydarm API documentation.