CyberArk Dynamic Scanning

You can now take advantage of a significant improvement to Tenable’s CyberArk integration which gathers bulk account information for specific target groups without entering multiple targets. You need to enter only one target in the settings (which is arbitrary and not used as an actual target). This target is used to kick off the process of collection and nothing more. You can configure up to five unique credentials in a scan policy that represent specific target groups.

The integration feature takes advantage of CyberArk’s Password Vault Web Access (PVWA) REST API, by gathering bulk account information for a large volume of hosts, automatically adding them to the scan, and requesting the password on a host-by-host basis from CCP/AIM Web Service application. You must have a CyberArk version that contains the PVWA REST API to use this feature.

Collection

The initial collection of accounts (except the password) is done once and on the arbitrary target/host entered in the target settings of the scan policy mentioned in the beginning of each section (SSH, Windows, and Database). Logs for the collection can be found in the Debugging Log Reporting on this particular host in the following logs:

• Database = pam_database_auto_collect.nbin~CyberArk

• SSH = pam_ssh_auto_collect.nbin~CyberArk

• Windows = pam_smb_auto_collect.nbin~CyberArk

Adding targets to the scan automatically

After the collection process, the integration performs automatic addition of the hosts and necessary host’s knowledge bases (KBs). Before adding hosts to the scan, the integration checks that an address value was present. This process is contingent upon that value. In addition, the integration tries to resolve that host (address value) within your network. Once it determines that a resolvable host (address value) is present, the integration adds the host (and certain data gathered as KBs) used to query the password and/or used for authentication to the host. As a supplemental log for identifying successfully resolved hosts against unsuccessfully resolved hosts, the integration provides logs present on the arbitrary host:

• Database = pam_database_auto_collect.log

• SSH = pam_ssh_auto_collect.log

• Windows = pam_smb_auto_collect.log

Database example:

In the example database log, we have a host auditmsss2016 that Tenable Nessus could not resolve on the network. This host is not added to the scan. An error returned from the function fqdn_resolv() triggers the creation of separate logs that show more detail called:

• Database = pam_database_auto_collect_resolv_func.log

• SSH = pam_ssh_auto_collect_resolv_func.log

• Windows = pam_smb_auto_collect_resolv_func.log

In addition, you can see in the example log that we have a duplicate host. The Tenable Nessus engine handles that naturally, so more than one record does not appear in the host table.

Password collection

After the collection and addition of host and KBs is complete, the authentication process kicks off on each of the hosts. To eliminate the possibility of requesting a password for either the arbitrary host (input by the user) or a host not containing the necessary query parameters, a condition is set in place within logins, ssh_settings, and database_settings to avoid this. Host by host, the integration calls AIM Web Service for the password using four unique query parameters that avoid requesting a password for the wrong target: safe, object, username, and address. As far as logs go, this is no different (on the host level) than “normal.”

• Database = database_settings.nasl~CyberArk

• SSH = ssh_settings.nasl~CyberArk

• Windows = logins.nasl~CyberArk

Configuration methods:

• Database Auto-Discovery
• SSH Auto-Discovery
• Windows Auto-Discovery