CyberArk Integration Helpful Tips

The overall process of the CyberArk integration is like other PAM integrations, as follows:

• TVM or SC pass the policy and credential values down to Nessus. This would include values like the CyberArk host, port, object identifier, and client certificates.

• The Nessus scanner communicates with the API, and the API returns the username, password, and/or SSH key required for target authentication.

• The scanner uses these values for target authentication.

Overall Process with Auto-Discovery

With Auto-Discovery, the integration initiates an initial collection of hosts and the object identifiers that contain their respective credentials. The scan will inject the discovered hosts as new scan targets, and the object identifiers are stored as Knowledge Base (KB) items.

After the collection of hosts and KBs is complete, the authentication process kicks off on each of the hosts. For each host, the integration requests the following target credentials: username, password, SSH private key, private key passphrase, and, if applicable, the elevation command.

Client Authentication

All API authentication occurs directly between the scanner and the PAM API. In other words, neither Tenable Vulnerability Management nor SecurityCenter connect to the PAM API. API authentication occurs using one of the following supported authentication types.

Client Certificate Authentication (recommended)

Customers can configure a client certificate for authentication to the AIM Web Service. After creating and configuring the certificate on the Windows Service, adding the binding to the IIS application, and properly configuring SSL settings on the IIS that hosts the AIM Web Service, customers will need to extract the private key from the certificate and import both the Certificate and Private Key files in the CyberArk scan credential.

Server IP Whitelisting

Customers can add the server IP of the Nessus Scanner host to the “Allowed Machines” of the configured CyberArk Application. This ensures that only specific machines can communicate with the Web Service API server. In addition, the Windows Server Internet Information Service (IIS) that is hosting the AIM Web Service application must be configured to allow this kind of communication.

Note: Whether using Server IP Whitelisting or Client Certification Authentication, customers must add the scanner IP to the list of “Allowed Machines” configuration for the CyberArk Application devoted to the AIM Web Service.

IIS Basic Authentication

Customers may use IIS Basic Authentication, but this is only available with Auto-Discovery. Tenable recommends using Client Certificates instead.

AIM Web Service API

The Tenable integration with CyberArk requires the presence of a self-hosted component called the Central Credential Provider (CCP). The CCP contains the AIM Web Service API that Tenable requests credentials (username, domain, password, private key, and private key passphrase) from. It has one API resource called GetPassword and returns a single password. It cannot be used to return multiple passwords in a single request.

• The default AIM Web Service URL is AIMWebService/V1.1/AIM.asmx

• Tenable recommends leaving CyberArk AIM Service URL blank when using the default path.

• The CyberArk (Legacy) integration uses the SOAP API, everything else uses the REST API. Note that the SOAP API has been deprecated by CyberArk.

• For the SNMPv3 credential type, the scanner needs to make two separate requests if the credential requires both Authentication and Privacy passwords.

When using Auto-Discovery, the integration also interfaces with the Password Vault Web App (PVWA) API. Therefore, Auto-Discovery requires credentials to both PVWA and CCP.

Testing Connectivity with curl

This section contains commands for testing the CCP and PVWA APIs.

Both the commands in this section use the -k option to disable SSL verification. This may not strictly be necessary, and may not be desirable. The commands in this section are split into several lines for readability. When copying it, be sure to copy the backslash (\) characters so that the command executes correctly.

Execute the following command to test connectivity to the CCP:

curl -k -X GET -G \
  https://CYBERARK_IP:PORT/AIMWebService/api/Accounts \
  --data-urlencode 'AppID=APP_ID' \
  --data urlencode 'Safe=SAFE' \
  --data-urlencode 'UserName=USER' \
  --data-urlencode 'Address=ADDRESS' \
  --cert /path/to/client_cert.pem \
  --key /path/to/client_cert_privatekey.pem

Replace the command values with the values in the following table.

Expected Output:

{"Content":"PASSWORD_HERE", "creationmethod":"PVWA","address": "ADDRESS","Safe":"SAFE","username":"USER","object": "OBJECT_ID",[...] }

Hints:

• The various --data-urlencode parameters are different query parameters for how to fetch an account. The example above uses App ID, Safe, User and Address.

• For example, omit --data-urlencode 'UserName=USER' to match any account with the given address regardless of username.

• Another example, to fetch a password by its object ID instead of username/address, replace the --data-urlencode 'UserName=USER' and --data-urlencode 'Address=ADDRESS' lines with --data-urlencode 'Object=OBJECT_ID'.

• This command assumes client certificate authentication, which Tenable strongly recommends.

• This command will return the literal password of the account, which can be useful for verifying its correctness.

For testing Auto-Discovery, test both the CCP as well as the PVWA service. To test PVWA connectivity, execute the following command:

curl -k -X POST --header 'Content-Type: application/json' \
--data '{"username":"USER","password":"PASSWORD"}' \
https://CYBERARK_IP:PORT/PasswordVault/API/auth/Cyberark/Logon

The expected output should be an API token, a long string of random-looking characters.

Get Credential By

The following section only applies to CyberArk without Auto-Discovery.

The CyberArk integration allows users to specify the accounts to use in multiple ways: by username, by address, by object ID, or by parameters. The integration behaves differently in each of these cases. This can be adjusted through the “Get Credential By” drop-down menu.

Username

The integration gets the target account with the given username. It only returns accounts that also match the target IP address or FQDN. This means that different accounts are used across different targets.

Address

The integration gets the target account with the given address. If left blank, it returns the account that matches the target IP address or FQDN.

Identifier

The integration gets the account with the given Account Name, its global identifier. Account names are unique across the entire CyberArk environment, so in this case the integration disregards the value of the current target IP address. In other words, it uses the same account across all targets.

Parameters

The integration will get the account matching the supplied parameters. This option is an advanced option that provides more direct control of the exact API query parameters. In this mode, it is possible to toggle whether or not to include the target’s IP address or FQDN in the API query.

Number of API requests

The overall number of API requests are higher when using a query which returns accounts matching the target IP address or FQDN (for example, “by username”), because each query is different for each target. There is one request per target.

Additionally, although the integration uses a cache to reduce unnecessary requests, the cache is not shared among scan chunks. Therefore, when using “by identifier”, the number of requests will still be one per scan chunk.

CyberArk credential field mapping to the CyberArk Accounts detail view in the CyberArk console: