Automation Scoping

Overview

In an MSSP deployment, different client organisations may require access to different Automation instances. For example, one client may run Automation on-site to keep observables within their infrastructure, while others share a central Automation instance operated by the MSSP.

Energy SOAR lets you configure multiple Automation instances and control which organisations can use each one. This is done through the cortex.servers configuration key in /etc/energysoar/application.conf.d/cortex.conf.

How scoping works

Each entry in cortex.servers represents one Automation instance. Two optional fields control which organisations can reach it:

• includedTheHiveOrganisations — list of organisation names that may use this Automation instance. Defaults to ["*"], meaning all organisations.

• excludedTheHiveOrganisations — list of organisation names explicitly denied access. Applied after the include check. Defaults to empty (no exclusions).

When a user submits an observable for analysis, Energy SOAR checks all configured Cortex instances and forwards the job only to those accessible to the user’s active organisation.

Configuration

Edit /etc/energysoar/application.conf.d/cortex.conf and add a cortex.servers block. Each server entry requires at minimum a name, a URL, and an authentication block.

Authentication types

Type	Fields	When to use
bearer	key	Automation API key; key is sent as Authorization: Bearer <key>
key	key	API key sent without a prefix
basic	username, password	HTTP Basic credentials
none	(none)	Unauthenticated access (not recommended in production)

Shared Automation for all organisations

This is the default when no scoping is applied. All organisations can submit jobs to the configured Automation instance.

cortex.servers = [
  {
    name = "cortex-shared"
    url = "http://127.0.0.1:9001"
    auth {
      type = "bearer"
      key = "YOUR_API_KEY"
    }
  }
]

Per-client Automation instances

To give each client organisation a dedicated Automation instance, list each server with includedTheHiveOrganisations set to the corresponding organisation name:

cortex.servers = [
  {
    name = "cortex-clientA"
    url = "https://cortex.clienta.example.com:9001"
    includedTheHiveOrganisations = ["clientA"]
    auth {
      type = "bearer"
      key = "CLIENTA_API_KEY"
    }
  }
  {
    name = "cortex-clientB"
    url = "https://cortex.clientb.example.com:9001"
    includedTheHiveOrganisations = ["clientB"]
    auth {
      type = "bearer"
      key = "CLIENTB_API_KEY"
    }
  }
]

With this configuration, analysts in clientA can only submit jobs to cortex-clientA, and analysts in clientB can only submit jobs to cortex-clientB.

Mixed model: shared and dedicated

You can combine a shared instance for most clients with a dedicated one for clients that require data residency:

cortex.servers = [
  {
    name = "cortex-shared"
    url = "http://127.0.0.1:9001"
    excludedTheHiveOrganisations = ["clientA"]
    auth {
      type = "bearer"
      key = "SHARED_API_KEY"
    }
  }
  {
    name = "cortex-clientA"
    url = "https://cortex.clienta.example.com:9001"
    includedTheHiveOrganisations = ["clientA"]
    auth {
      type = "bearer"
      key = "CLIENTA_API_KEY"
    }
  }
]

Here cortex-shared is available to everyone except clientA, while clientA has exclusive access to its own on-site Cortex instance.

Remote Automation at client site

Automation does not need to run on the same host as the Energy SOAR Base component. A client can operate Automation within their own infrastructure. Energy SOAR Base connects to it over HTTPS using the configured URL and credentials.

Requirements for a remote Automation instance:

• The Energy SOAR Base server must be able to reach the Automation URL on the configured port.

• The Automation instance must have an API key created and provided in the auth.key field.

• If the connection traverses a firewall, ensure the Automation port (default 9001) is permitted inbound to the Automation host.

Applying the configuration

After editing cortex.conf, restart Energy SOAR Base:

systemctl restart energysoar

Energy SOAR reconnects to all configured Automation instances on startup. The current connection status for each instance is visible at Admin > Automation.