Skip to main content

Cato Networks

Bring your Cato Networks SASE account into the JupiterOne graph. The integration always ingests the Cato account and the Cato SASE Cloud service it provides. On top of that you can turn on three data sources: access governance, with the account administrators, the access roles defined in the account and which admin holds which role; sites, with the connectivity, operational and high-availability status of each site and the Socket appliances behind it; and SDP users, the remote users who connect through Cato, with their point-in-time connectivity status and the device they connect from. Use it to review who administers your Cato account, find admins without MFA, and keep an inventory of your sites, Sockets and remote users next to the rest of your environment. Cato events and audit trail feeds are not ingested.

Installation​

This integration connects to the Cato API (https://<API Host>/api/v1/graphql2) and ingests your Cato account, its administrators and roles, its sites and Sockets, and its SDP users. It authenticates with a Cato API key, sent in the x-api-key header, and every request is a read-only GraphQL query. The integration is managed by JupiterOne and runs in the JupiterOne cloud, so no collector is needed.

Prerequisites​

  • A Cato Networks account and access to the Cato Management Application (CMA).
  • A CMA administrator who can create Service Principals and service API keys.
  • Access to JupiterOne with permission to configure integrations.

Configuration in Cato Networks​

The integration uses a service API key. Service keys belong to a Service Principal rather than to an individual admin, so they keep working when people change roles or leave, and they cannot be used to sign in to the CMA. A service key inherits the permissions of its Service Principal.

Create a Service Principal​

If you do not have a Service Principal for JupiterOne yet:

  1. In the CMA, open Account > Administrators and click New.
  2. Select Create New and Create as Service Principal.
  3. Enter the General settings, for example the name JupiterOne.
  4. Select the Role for the Service Principal. A role with view (read-only) access to the account is enough, because the integration never changes your configuration.
  5. Click Apply.

Create the service API key​

  1. In the CMA, open Resources > Service API Keys and click New.
  2. Select the Service Principal you created.
  3. Enter a Key Name, such as JupiterOne.
  4. Select Downgrade to View. This limits the key to query (read-only) API calls, whatever role the Service Principal has.
  5. In Allow access from IPs, leave Any IP, or select Specific IP list to restrict the key to known addresses. See IP allowlisting below.
  6. Optionally, select an Expires at date. When the key expires, the integration stops ingesting until you add a new key to the instance.
  7. Click Apply, copy the key from the pop-up and store it somewhere safe. Cato shows the key value only once.
  8. Click OK.

Find your Account ID​

The integration needs your numeric Cato Account ID. In the CMA, open Account > Account Info and copy the Account ID. In older versions of the CMA, the same value is under Administration > General Info.

Find your API host​

The API host depends on where your CMA is hosted. Look at the address you use to sign in to the CMA:

  • cc.catonetworks.com (no prefix): the API host is api.catonetworks.com, which is the default.
  • A regional prefix, such as cc.us1.catonetworks.com: use the same prefix for the API host, for example api.us1.catonetworks.com.

IP allowlisting​

If you restrict the API key with Specific IP list, Cato rejects requests from addresses that are not on the list. Contact JupiterOne support to get the egress IP addresses the integration uses, and add them to the key before you create the instance.

Configuration in JupiterOne​

To install the Cato Networks integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Cato Networks. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the Cato Networks account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • The Authentication fields below.

Authentication fields​

FieldRequiredDescription
API KeyYesThe Cato service API key created above. It is masked in JupiterOne and sent in the x-api-key header.
Account IDYesThe numeric Cato Account ID, from Account > Account Info in the CMA.
API HostNoThe Cato API host for your CMA region. Defaults to api.catonetworks.com. Accounts on a regional CMA set the regional host, for example api.us1.catonetworks.com.

When you save the instance, JupiterOne checks that API Key and Account ID are set and sends a test query to the Cato API for that account. A wrong key, a key for a different account, a wrong API host or a blocked IP address fails the check.

Click Create once all values are provided to finalize the integration.

Data Sources​

Each data source can be enabled or disabled on its own. All data sources are disabled by default, so a new instance ingests only the cato_account and cato_service entities until you enable the ones you want. To enable them, open the instance, turn on the data sources under Data Sources, and save. They are ingested on the next run.

Data SourceDescriptionEntities Created
Access Governance (Admins & Roles)Account administrators, with their status, admin type (person or Service Principal) and whether MFA is enabled; the access roles defined in the account, predefined or custom; and which admin holds which role.cato_admin, cato_role
Sites & SocketsSites configured in the account, with their connectivity, operational and high-availability status, and the Socket appliances behind each site, with their version, connection state and whether they are the primary Socket of an HA pair.cato_site, cato_socket
SDP UsersSDP (remote) users who connect through Cato, with their connectivity status and the device they connect from.cato_vpn_user

To ingest everything the integration supports, enable all three data sources.

Relationships are built only when the data source they need is enabled:

RelationshipRequires
cato_account PROVIDES cato_serviceAlways created
cato_account HAS cato_adminAccess Governance (Admins & Roles)
cato_account HAS cato_roleAccess Governance (Admins & Roles)
cato_admin ASSIGNED cato_roleAccess Governance (Admins & Roles)
cato_account HAS cato_siteSites & Sockets
cato_site HAS cato_socketSites & Sockets

SDP users are not linked to the account by a relationship, because an account can have a very large number of them. Each cato_vpn_user carries the Cato account ID in accountId instead.

Required permissions​

The API key only needs to read your account. A key created with Downgrade to View, or a Service Principal with a view-only role, is enough: Cato limits view permissions to query API calls, and the integration only sends queries.

Notes​

  • Connectivity status is a point-in-time value. Site, Socket and SDP user status comes from the Cato account snapshot taken during the run. Cato reports SDP users in the snapshot only while they are connected, so connectivityStatus and deviceName are set only for SDP users who were connected when the integration ran. Users who were not connected are still ingested, without those values.
  • Events and audit trail are not ingested. The integration does not read Cato events, the audit trail or network metrics.
  • Every run is a full sync. Admins, roles, sites, Sockets and SDP users that Cato no longer reports are removed from the graph on the next run.

Rate limits​

Cato applies rate limits per query and per account, and every API key that calls the same query on your account shares one counter. If another tool, such as a SIEM or log forwarder, uses the Cato API on the same account, it shares those limits with JupiterOne. Most queries allow 120 calls per minute, accountSnapshot allows 30 per minute, and entityLookup, which the integration uses to list sites and SDP users, allows 30 per minute and 1,500 per 5 hours. The integration reads up to 1,000 entities per entityLookup call. When Cato reports a rate limit, the integration waits and retries. If runs hit rate limits often, lower the polling frequency or schedule them away from other tools that use the Cato API.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​