System Authentication Records

Instance discovery and auto record creation are supported for Apache Web Server, IBM WebSphere App Server, JBoss Server, Tomcat Server, Oracle, and MongoDB. 

System-created authentication records can be used for compliance scans and vulnerability scans.

Note: This feature is not available in subscriptions with SCA only. For compliance, your subscription must have PC and PC Agent enabled.

Jump to: Summary | Steps to get started | How it works | Make records Inactive | Search records | Common questions

Tip - Once you start using instance discovery and auto record creation, we don't recommend you continue to create your own authentication records for the same technologies/instances. We'll automatically create and update authentication records for you.

Summary

These capabilities are available.

- Support scanning multiple instances running on the same host when hosts have varying configurations.

- 2 phased scanning process. First, a discovery scan finds instances of the server applications that you have chosen to scan, consolidates instance data, and creates/updates authentication records in your account. Then a compliance assessment scan or vulnerability assessment scan uses the records saved in your account.

- Compliance scan results show a list of instances discovered by the scan when the instance discovery and auto record creation feature is enabled for the scan. No assessment data is collected during instance discovery scans.

- Auto created authentication records have the owner "System". These records cannot be edited by users. (For Oracle and MongoDB, you do have the option to Save a system-created record as a user record in order to edit it.)

- You can set any system record as "Active" to enable it for authenticated scanning. Set it as "Inactive" to disable it.

 


Steps to get started

1) Create System Record Templates for Oracle and MongoDB 

Create a system record template and enter the login credentials you want to use for the system created records. In the next step, you'll create an option profile for instance discovery, and choose the system record template name. The template will be linked automatically to the system created records created as a result of the discovery scan.

Note: You must complete this step before you are able to enable instance discovery in the option profile.

To create this template, go to Scans > Authentication > New > System Record Templates. Once saved, your system record template will be listed on the Authentication tab with your authentication records.

Set Up Oracle System Record Template

Set Up MongoDB System Record Template

2) Configure option profiles

You'll need to create multiple option profiles:

- In PC, create a profile for instance discovery and system record creation.

- In PC, create a profile for including the system created records in your compliance assessment scans. 

- In VM, create a profile for including the system created records in your vulnerability assessment scans. 

Option Profile 1: Allow Instance Discovery and Create System Authentication Records

Choose "Allow instance discovery and system record creation" and select one or more applications. Use this option profile for instance discovery scans. We’ll discover running instances during the scan, and then use the information collected about your running instances to create authentication records. For Oracle and MongoDB, you must also select the respective system record template with the login credentials you want to apply to system created records.

We support auto discovery of Jboss Server and IBM WebSphere instances on Unix and Windows. For the other technologies, we support auto discovery of instances running on Unix only. Make sure you have Unix/Windows authentication records in your account.

For IBM WebSphere App Server, you'll also need to choose whether you want to discover instances at the installation directory level or the server directory level. See Common Questions below for more information.

Create System Authentication Records

Option Profile 2: Use System Authentication Records in Compliance Assessments

Choose "Include system created authentication records in scans" in the option profile you'll use for compliance assessments. System created records will be used along with user created records. If you have a user created record and a system created record for the same instance configuration we'll use the user record by default. You can change this if you prefer to use the system record.

System Authentication Records

Option Profile 3: Use System Authentication Records in Vulnerability Assessments

Choose "Include system created authentication records in scans" in the option profile you'll use for vulnerability scans. System created records will be used along with user created records. If you have a user created record and a system created record for the same instance configuration we'll use the user record by default. You can change this if you prefer to use the system record.

profile with Include system created authentication records in scans enabled

Authentication must also be enabled in the option profile. Go to the Scan tab and scroll down to the Authentication section. Select each authentication type you’re interested in. Note that only system records for technologies supported in VM will be included in vulnerability scans.

authentication options in profile

3) Launch discovery scan for auto record creation

Launch a compliance scan (using PC or SCA) and choose an option profile with the "Allow instance discovery and system record creation" option enabled. We recommend you schedule instance discovery scans to occur when you expect changes in your infrastructure.

Note that we auto discover instances of respective applications for hosts running on operating systems supported for PC.

Looking for auto discovered instances? Scroll down to the Appendix section of your compliance scan results and you'll see a list of Auto Discovered Instances.

appendix section of scan results showing auto discovered instances

 

We’ll also tell you when we don’t find running instances for scanned hosts.

appendix section of scan results showing hosts with no running instances

 

We’ll tell you when we don’t find an authentication type on any scanned hosts.

appendix section of scan results showing authentication types for which no instances

 

Auto record creation process

Instance scan data consolidation occurs based on authenticated scan data from the scan. Authentication records are created based on consolidated scan data. Record creation starts when the scan is Finished, during scan processing. Records may be created or updated (new IPs added, existing IPs removed).

System created authentication records are identified by a gold lock gold lock icon for system records and Owner “System”. For system created Oracle records you'll also see the template record name. This is the template that contains the login credentials for the Oracle instance.

system created authentication records on Authentication tab

4) Launch assessment scans 

Launch compliance scans (using PC or SCA) and vulnerability scans and choose an option profile with the "Include system authentication records in scans" option enabled.

 


How it works - auto record creation

During scan processing instance scan data is consolidated, mapping record configuration to hosts:

- Single host with single instance configuration

- Single host with multiple instance configurations

- Multiple hosts with single instance configuration

- Multiple hosts with multiple instance configurations

Let's consider a sample Apache authenticated scan with auto record creation enabled. Sample scan data collected from the discovery scan is represented below.

For this scan, 3 Apache authentication records are auto created:

 


Make authentication records Inactive

You can choose to make any record created for these applications Inactive, including system created records and user created records.

Inactive records are not included in scans (even if the "Include system created authentication records in scans" option is selected in the option profile). Simply choose the records you want to make Inactive and pick Deactivate from the Actions menu above the data list. To activate records choose Activate.

Actions menu above the authentication list to activate or deactivate records

 


Search application records

You can search records for these server applications by creation type (System created or User created) and by status (Active or Inactive).

Search by creation type and status

You can search for all Oracle record templates by choosing Record Type: System Record Template.

Search by record type

You can find all system created records that are associate with a particular Oracle record template by choosing Template Record and entering all or part of the template name.

Search by template record name

 


Common questions

What instance parameters are checked when creating a new record for auto discovered hosts?

- Two Apache Web Server instance records on same/different hosts are different if these 2 parameters "Apache configuration file" and "Apache control command" for the two instances have different values.

- Two IBM WebSphere instance records on same/different Unix hosts are different if the parameter "unix_websphere_home_dir" value for two WebSphere instances are different.

Two IBM WebSphere instance records on same/different Windows hosts are different if the parameter "win_websphere_home_dir" value for two WebSphere instances are different.

- Two JBoss instance records on same/different hosts are considered different if values in any of these parameters for JBoss instances are different: jboss_domain_mode, jboss_home_path, jboss_base_path, jboss_conf_dir_path, jboss_conf_file_path and jboss_conf_host_file_path.

- Two Apache Tomcat Server instance records on same/different hosts are different if these 2 parameters "Apache tomcat home directory" and "Apache tomcat base directory" for the two instances have different values.

For Oracle:

- If the Oracle database SID/Service Name and Port are the same as an existing system-created record on the same host, but any of these Unix parameters are different then we'll update the existing record to take the new values: Oracle Home path, init(SID).ora, spfile(SID).ora, listener.ora, sqlnet.ora, tnsnames.ora.

- If the Oracle database SID/Service Name or Port is different than an existing system-created record on the same host, then we consider it a unique instance and will create a new record.

- If the Oracle database SID/Service Name and Port are the same as an existing system-created record on a different host, and any of these Unix parameters are different then we consider it a unique instance and will create a new record: Oracle Home path, init(SID).ora, spfile(SID).ora, listener.ora, sqlnet.ora, tnsnames.ora.

For MongoDB:

- If the MongoDB Database Name or Port is different than an existing system-created record on the same host, then we consider it a unique instance and will create a new record.

- If the MongoDB Database Name and Port are the same as an existing system-created record on a different host, and any of these Unix parameters are different then we consider it a unique instance and will create a new record.

What is the naming scheme for system-created authentication records?

You'll see "Authentication Type [System Created] – ID" for the authentication record name.

For example, "Apache Web Server [System Created] – 100201"

Authentication Type is the name of the application. ID is a unique record ID for the instance discovered.

Changes in scan data for running instances

When new instances are discovered they are added to existing records or new records are created for them, depending on their settings (configuration file, control command, IPs, network if applicable).

What about my user created authentication records?

Your user created authentication records are not changed, and they are included in scans as long as they are Active.

Are new system created authentication records added if I already have user created records with the same settings?

Yes. New system authentication records are always created for all running instances discovered when the option profile for the scan has the "Allow instance discovery and system record creation" option enabled. If you already have a user created record with the same settings, the system makes no changes to it. The user created record is included in scans by default. Edit the option profile if you prefer to use system created records in the case of duplicates.

What happens to existing system records when instances are added and removed?

Instances are reported for the host:

For each instance reported we'll see if a system record exists with the instance configuration.

If a record is found for the instance and it has the host's IP included then there is no change.

If a record is found for the instance but it doesn't have the IP we'll add the IP to the record.

If a record is not found for the instance we'll create a new system record for the instance and IP.

No instances are reported for the host:

The host's IP is removed from all existing system records that have the IP.

Fewer instances are reported than the previous scan (instances are brought down):

The host's IP is removed from system records for the instances that are no longer running.

More instances are reported than the previous scan (instances are brought up):

We'll look at each reported instance to see if a system record already exists. If a record exists then we'll add the host's IP to the record (if not already included). If a record does not exist then we'll create a new system record for the instance and IP.

What if I scan an IBM WebSphere App Server with "Server Directory" discovery mode and then with "Installation Directory" discovery mode?

We don't recommend this as you'll get different instances discovered with each scan. Let's say you first launch a scan using an option profile with instance discovery at the "Server Directory" level resulting in 4 instances discovered and 4 system authentication records created. Then let's say you launch a second scan on the same target but this time you use an option profile with instance discovery at the "Installation Directory" level. This time only 1 instance is discovered. As a result, the IP address will be removed from the 4 previous authentication records and 1 new system authentication record will be created with the new instance information.

IBM WebSphere App Server - Path for Installation Directory matches Server Directory

When creating your own IBM WebSphere App Server authentication record, there's nothing stopping you from entering the path to the Server Directory in the Installation Directory field. The path will be saved as Installation Directory. The instance name is prepended with the label "Installation Directory" like this:

Installation Directory: /opt/IBM/WebSphere/AppServer/profiles/AppSrv02/config/servers/server1

If you auto discover the same instance from the Server Directory, the instance will be saved as Server Directory and the auto-discovered instance name will be prepended with the label "Server Directory" like this:

Server Directory: /opt/IBM/WebSphere/AppServer/profiles/AppSrv02/config/servers/server1

Note: For Windows, only the installation directory is supported.

It's important to note that even though the path is the same in both cases, these are not considered duplicates since one has the Installation Directory label and the other has the Server Directory label. For this reason, both the user-created and the system-created records will be sent at scan time.

Can I use Scan by Policy with “Include system created authentication records”?

Yes, and this is recommended. You can use Scan by Policy to perform compliance assessment on assets in a policy. We recommend you include system created authentication records. This is the only way to ensure that all active authentication records (system and user created) will be used for the compliance assessment.

Can I use Scan by Policy with “Allow instance discovery and system record creation”?

No. These options cannot be used together. Compliance assessment data is not collected for instance discovery scans.

Can I edit system authentication records?

No. System authentication records cannot be edited by users. You can change the record status (Active, Inactive) from the Actions menu above the data list.

Can I save system authentication records as user created?

This option is only available for system created Oracle records. This allows you to change the credentials for individual records without changing the credentials for all records associated with a template. If you want to change the credentials for all instances associated with a template then edit the credentials in the template.

Can I delete system authentication records?

Yes. Users with permission to create/edit authentication records can also delete authentication records, including system records. Tip - You may choose to make system records Inactive. Inactive records are not included in any scans.

How do I turn off auto record creation?

Go to your compliance option profile and clear the option "Allow instance discovery and system record creation" under System Authentication Records. When cleared, new system records will not be created.

What if I don't want to use System authentication records in scans?

No problem. Take one of these actions:

- Deactivate system records. Use the search feature above your authentication records list to find all records with creation type "System created". Then select the records and choose Deactivate from the Actions menu.

- Clear the option "Include system created authentication records in scans" in the PC or VM option profile. When cleared in the PC option profile, only user created authentication records are included in PC scans. When cleared in the VM option profile, only user created authentication records are included in VM scans. Keep in mind that existing scan data will remain in your account. Purge hosts to remove all host information.