Set up Device Security and XSOAR for Aruba Central Integration
Focus
Focus
Device Security

Set up Device Security and XSOAR for Aruba Central Integration

Table of Contents

Set up Device Security and XSOAR for Aruba Central Integration

Set up Device Security and Cortex XSOAR to integrate with Aruba Central.
Where Can I Use This?What Do I Need?
  • Device Security (Managed by Strata Cloud Manager)
  • (Legacy) IoT Security (Standalone portal)
One of the following subscriptions:
  • Device Security subscription for an advanced Device Security product (Enterprise Plus, Industrial OT, or Medical)
  • Device Security X subscription
One of the following Cortex XSOAR setups:
  • A free, cohosted, limited-featured Cortex XSOAR instance
    AND
    A Cortex XSOAR Engine (on-premises integration)
  • A full-featured Cortex XSOAR server
You must configure Cortex XSOAR with an Aruba Central integration instance and a job to import device data from the Aruba Central server. You can set the job to run at regular intervals or on demand. The configuration requires the following information from the Aruba Central:
  • Domain URL for a cloud-hosted Aruba Central instance, or an FQDN for an on-premises Aruba Central server
  • Username and password of the read/write user account that Cortex XSOAR uses when logging in to the Aruba Central API or else an authorization code
  • Customer ID for Aruba Central
  • Client ID and Client Secret for Aruba Central
To set up Device Security to integrate through a cloud-hosted Cortex XSOAR instance with an on-premises Aruba Central server, you must also add a Cortex XSOAR engine to your network.

Cortex XSOAR Engine Installation

An on-premises XSOAR engine facilitates communications between the Cortex XSOAR cloud and Aruba Central server. Although it's possible to install an XSOAR engine on machines running Windows, macOS, and Linux operating systems, only an engine on a Linux machine supports Device Security integrations. For more information about operating system and hardware requirements, see the Cortex Administrator’s Guide.
We recommend downloading the Cortex XSOAR engine using the shell installer script and installing it on a Linux machine. This simplifies the deployment by automatically installing all required dependencies and also enables remote engine upgrades.
When placing the XSOAR engine on your network, make sure it can form SSH connections to your Aruba Central server. By default, SSH uses TCP port 22.
The on-premises firewall must allow the Cortex XSOAR engine to form HTTPS connections on TCP port 443 to the Cortex cloud at https://<your-domain>.iot.demisto.live/. You can see the URL of your Cortex XSOAR instance when you log in to Device Security and click Integrations and then click Launch Cortex XSOAR. It’s visible in the address bar of the web page displaying the Cortex XSOAR interface.
To create an Cortex XSOAR engine, access the Cortex XSOAR interface (from Device Security, click Integrations and then click Launch Cortex XSOAR). In the Cortex XSOAR UI, click SettingsEngines+ Create New Engine. Choose Shell as the type.
For Cortex XSOAR engine installation instructions, see Engine Installation.
For help troubleshooting Cortex XSOAR engines, including installations, upgrades, connectivity, and permissions, see Troubleshoot Engines and Troubleshoot Integrations Running on Engines.

Configure Device Security and Cortex XSOAR

  1. Log in to Device Security and from there access the Aruba Central settings in Cortex XSOAR.
    1. Log in to Device Security and then click Integrations.
    2. Launch Cortex XSOAR.
      The Cortex XSOAR interface opens in a new browser window.
    3. Click Settings in the left navigation menu, search for Aruba Central to locate it among other instances.
  2. Configure the Aruba Central integration instance.
    1. Click Add instance to open the settings panel.
    2. Enter the following settings:
      • Name: Use the default name of the instance or enter a new one.
        Remember the instance name because you are going to use it again when creating a job that Cortex XSOAR will run to gather device data from the Aruba Central instance specified in this integration instance.
      • Server URL: Enter the domain URL of a cloud-hosted Aruba Central instance or the FQDN of an on-premises Aruba Central server.
      • Customer ID: Copy and paste the customer ID that you copied from Aruba Central.
      • Optional Username: If you use single sign-on (SSO), you can skip this field. Otherwise, enter the username of the read-only user account that you previously created for Cortex XSOAR to use when connecting to the Aruba Central API.
      • Optional Password: If you use SSO, you can skip this field. Otherwise, enter the password associated with the user account.
      • Customer ID: Enter the customer ID that you copied from Aruba Central.
      • Client ID: Enter the client ID that you copied from Aruba Central.
      • Client Secret: Enter the client secret that you copied from Aruba Central.
      • Optional Auth Code: If you use SSO, enter the authorization code for Cortex XSOAR to access your Aruba Central instance.
        If you don't enter a Username and Password, you must enter an Auth Code.
      • Device Details for the Cortex XSOAR job: Select the device details that you want the Cortex XSOAR integration job to learn. You must select at least one of the options or else the job will not import any information.
      • Use single engine: When using a cloud-based Cortex XSOAR instance and an on-premises Aruba Central server, choose the Cortex XSOAR engine that you want to communicate with the Aruba Central server.
    3. When finished, click Test or Test resultsRun test to test the integration instance.
      If the test is successful, a Success message appears. If not, check that the settings were entered correctly, and then test the configuration again.
    4. After the test succeeds, click Save & exit to save your changes and close the settings panel.
  3. Enable the Aruba Central integration instance.
  4. Create a job for Cortex XSOAR to query Aruba Central for device details and import them to Device Security.
    You can create multiple jobs if you have multiple integration instances.
    Device Security updates devices that are in its database and whose MAC address matches that returned by Aruba Central. If Aruba Central returns device information for a MAC address that’s not in the Device Security database, then Device Security creates a new entry and adds the imported MAC address to its database along with any associated device information about it.
    1. Click Jobs in the sidebar, and then click New Job to create a new Cortex XSOAR job.
    2. Configure the following settings in the New Job panel:
      • Recurring: Select this if you want to periodically import device information from Aruba Central. Clear it if you want to import data on demand.
      • Every: If you select Recurring, enter a number and set the interval value (Minutes, Hours, Days, or Weeks) and select the days on which to run the job. (If you don’t select specific days, then the job will run everyday by default.) This determines how often Cortex XSOAR queries Aruba Central for information about its devices.
      • Name: Enter a name for the job.
      • Playbook: Choose Import Aruba Central Device Data.
      • Integration Instance Name: Paste the instance name you copied a few moments ago.
    3. Click Create new job.
      The job appears in the Jobs list.
  5. Enable the job and run it.
    Check the Job Status for the job you created. If it's Disabled, select its checkbox and then click Enable.
    You can immediately run the job by selecting it and clicking Run now. Otherwise, if you scheduled a recurring job, then the enabled job will run as scheduled.
  6. Return to Device Security and check the status of the Aruba Central integration.
    An integration instance can be in one of the following four states, which Device Security displays in the Status column on the Integrations page:
    • Active — the integration was configured and enabled and is functioning properly.
      Disabled — either the integration was configured but intentionally disabled or it was never configured and a job that references it is enabled and running.
    • Error — the integration was configured and enabled but is not functioning properly, possibly due to a configuration error or network condition.
    • Inactive — the integration was configured and enabled but no job has run for at least the past 60 minutes.
    When you see that the status of an integration instance is Active, its setup is complete.