Instance discovery and auto record creation are supported for Apache Web Server, IBM WebSphere App Server, JBoss Server, Tomcat Server, Oracle, MongoDB and MySQL.
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 automatically create and update authentication records for you.
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, MongoDB and MySQL, 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.
Create a system record template and enter the login credentials you want to use for the system created records. In the next step, you 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 are listed on the Authentication tab with your authentication records.
Set Up Oracle System Record Template
Set Up MongoDB System Record Template
Set Up MySQL System Record Template
You 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.
Choose Allow instance discovery and system record creation and select one or more applications. Use this option profile for instance discovery scans. We discover running instances during the scan, and then use the information collected about your running instances to create authentication records. For Oracle MongoDB and MySQL, 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, Apache Web 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 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.
Choose Include system created authentication records in scans in the option profile you 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 use the user record by default. You can change this if you prefer to use the system record.
Choose Include system created authentication records in scans in the option profile you use for vulnerability scans. System created records are used along with user created records. If you have a user created record and a system created record for the same instance configuration we use the user record by default. You can change this if you prefer to use the system record.
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 are interested in. Note that only system records for technologies supported in VM will be included in vulnerability scans.
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 see a list of Auto Discovered Instances.
We also tell you when we do not find running instances for scanned hosts.
We tell you when we do not find an authentication type on any scanned hosts.
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 
and Owner System. For system created Oracle, MySQL records you also see the template record name. This is the template that contains the login credentials for the MongoDB instance.
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.
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:
|
Apache config file |
Apache control command |
Hosts |
|
conf1 |
bin1 |
host1, host2 |
|
conf2 |
bin2 |
host1 |
|
conf3 |
bin3 |
host2 |
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.
You can search records for these server applications by creation type (System created or User created) and by status (Active or Inactive).
You can search for all Oracle record templates by choosing Record Type: System Record Template.
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.
- 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.
You 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.
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).
Your user created authentication records are not changed, and they are included in scans as long as they are Active.
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.
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.
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.
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.
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.
No. These options cannot be used together. Compliance assessment data is not collected for instance discovery scans.
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.
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.
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.
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.
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.