When the application fingerprints an asset during the discovery phases of a scan, it automatically determines which vulnerability checks to perform, based on the fingerprint. On the Vulnerability Checks page of the Scan Template Configuration panel, you can manually configure scans to include more checks than those indicated by the fingerprint. You also can disable checks.
Unsafe checks include buffer overflow tests against applications like IIS, Apache, services like FTP and SSH. Others include protocol errors in some database clients that trigger system failures. Unsafe scans may crash a system or leave a system in an indeterminate state, even though it appears to be operating normally. Scans will most likely not do any permanent damage to the target system. However, if processes running in the system might cause data corruption in the event of a system failure, unintended side effects may occur.
The benefit of unsafe checks is that they can verify vulnerabilities that threaten denial of service attacks, which render a system unavailable by crashing it, terminating a service, or consuming services to such an extent that the system using them cannot do any work.
You should run scheduled unsafe checks against target assets outside of business hours and then restart those assets after scanning. It is also a good idea to run unsafe checks in a pre-production environment to test the resistance of assets to denial-of-service conditions.
If you want to perform checks for potential vulnerabilities, select the appropriate check box. For information about potential vulnerabilities, see Setting up scan alerts.
If you want to correlate reliable checks with regular checks, select the appropriate check box. With this setting enabled, the application puts more trust in operating system patch checks to attempt to override the results of other checks that could be less reliable. Operating system patch checks are more reliable than regular vulnerability checks because they can confirm that a target asset is at a patch level that is known to be not vulnerable to a given attack. For example, if a vulnerability check is positive for an Apache Web server based on inspection the HTTP banner, but an operating system patch check determines that the Apache package has been patched for this specific vulnerability, it will not report a vulnerability. Enabling reliable check correlation is a best practice that reduces false positives.
The application performs operating-system-level patch verification checks on the following targets:
Note: To use check correlation, you must use a scan template that includes patch verification checks, and you must typically include logon credentials in your site configuration. See Configuring scan credentials.
A scan template may specify certain vulnerability checks to be enabled, which means that the application will scan only for those vulnerability check types or categories with that template. If you do not specifically enable any vulnerability checks, then you are essentially enabling all of them, except for those that you specifically disable.
A scan template may specify certain checks as being disabled, which means that the application will scan for all vulnerabilities except for those vulnerability check types or categories with that template. In other words, if no checks are disabled, it will scan for all vulnerabilities. While the exhaustive template includes all possible vulnerability checks, the full audit and PCI audit templates exclude policy checks, which are more time consuming. The Web audit template appropriately only scans for Web-related vulnerabilities.
Note the order of precedence for modifying vulnerability check settings, which is described at the top of the page.
A safe vulnerability check will not alter data, crash a system, or cause a system outage during its validation routines.
Tip: To see which vulnerabilities are included in a category, click the category name.
The console displays a box listing vulnerability categories.
Tip: Categories that are named for manufacturers, such as Microsoft, can serve as supersets of categories that are named for their products. For example, if you select the Microsoft category, you inherently include all Microsoft product categories, such as Microsoft Path and Microsoft Windows. This applies to other "company" categories, such as Adobe, Apple, and Mozilla.
The console lists the selected categories on the Vulnerability Checks page.
Note: If you enable any specific vulnerability categories, you are implicitly disabling all other categories. Therefore, by not enabling specific categories, you are enabling all categories
The console displays Vulnerability Checks page with those categories removed.
To select types for scanning, take the following steps:
Tip: To see which vulnerabilities are included in a check type, click the check type name.
The console displays a box listing vulnerability types.
The console lists the selected types on Vulnerability Checks page.
To avoid scanning for vulnerability types listed on the Vulnerability Checks page, click types listed on the Vulnerability Checks page:
The console displays Vulnerability Checks page with those types removed.
The following table lists current vulnerability types and the number of vulnerability checks that are performed for each type. The list is subject to change, but it is current at the time of this guide’s publication.
| Vulnerability types | Vulnerability types |
|---|---|
| Default account | Safe |
| Local | Sun patch |
| Microsoft hotfix | Unsafe |
| Patch | Version |
| Policy | Windows registry |
| RPM |
To select specific vulnerability checks, take the following steps:
The console displays a box where you can search for specific vulnerabilities in the database.
Note: The application only checks vulnerabilities relevant to the systems that it scans. It will not perform a check against a non-compatible system even if you specifically selected that check.
The box displays a table of vulnerability names that match your search criteria.
The console displays the search results.
The selected vulnerabilities appear on the Vulnerability Checks page.
A specific vulnerability check may be included in more than one type. If you enable two vulnerability types that include the same check, it will only run that check once.
The fewer the vulnerabilities included in the scan template, the sooner the scan completes. It is difficult to gauge how long exploit test actually take. Certain checks may require more time than others.
Following are a few examples:
Be careful not to sacrifice accuracy by disabling too many checks—or essential checks. Choose vulnerability checks in a focused way whenever possible. If you are only scanning Web assets, enable Web-related vulnerability checks. If you are performing a patch verification scan, enable hotfix checks.
The application is designed to minimize scan times by grouping related checks in one scan pass. This limits the number of open connections and time interval that connections remain open. For checks relying solely on software version numbers, the application requires no further communication with the target system once it extracts the version information.
If you have created custom vulnerability checks, use the custom vulnerability content plug-in to ensure that these checks are available for selection in your scan template. The process involves simply copying the check content into a directory of your Security Console installation.
In Linux, the location is in the plugins/java/1/CustomScanner/1 directory inside the root of your installation path. For example:
[installation_directory]/plugins/java/1/CustomScanner/1
In Windows, the location is in the plugins\java\1\CustomScanner\1 directory inside of the root of your installation path. For example:
[installation_directory]\plugins\java\1\CustomScanner\1
After copying the files, you can use the checks immediately by selecting them in your scan template configuration.