Selecting vulnerability checks

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:

  • Microsoft Windows
  • Red Hat
  • CentOS
  • Solaris
  • VMware

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.

Configuration steps for vulnerability check settings

  1. Go to the Vulnerability Checks page. Note the order of precedence for modifying vulnerability check settings, which is described at the top of the page.
  2. Click the appropriate check box to perform unsafe checks. A safe vulnerability check will not alter data, crash a system, or cause a system outage during its validation routines.

To see which vulnerabilities are included in a category, click the category name.

  1. Click Add categories.... The console displays a box listing vulnerability categories.

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.

  1. Click the check boxes for those categories you wish to scan for, and click Save. The console lists the selected categories on the Vulnerability Checks page.

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.

  1. Click Remove categories... to prevent the application from scanning for vulnerability categories listed on the Vulnerability Checks page.
  2. Click the check boxes for those categories you wish to exclude from the scan, and click Save. The console displays Vulnerability Checks page with those categories removed.

To select types for scanning, take the following steps:

To see which vulnerabilities are included in a check type, click the check type name.

  1. Click Add check types... The console displays a box listing check types.
  2. Click the check boxes for those categories you wish to scan for, and click Save.

The console lists the selected types on Vulnerability Checks page.

To avoid scanning for check types listed on the Vulnerability Checks page, click types listed on the Vulnerability Checks page:

  1. Click Remove check types...
  2. Click the check boxes for those categories you wish to exclude from the scan, and click Save. The console displays Vulnerability Checks page with those types removed.

The following list shows current check types. The list is subject to change, but it is current at the time of this guide’s publication.

  • Default account
  • Local
  • Microsoft hotfix
  • Patch
  • Policy
  • RPM
  • Safe
  • Sun patch
  • Unsafe
  • Version
  • Windows registry

To select specific vulnerability checks, take the following steps:

  1. Click Enable vulnerability checks... The console displays a box where you can search for specific vulnerabilities in the database.
  2. Type a vulnerability name, or a part of it, in the search box.
  3. Modify search settings as desired.

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.

  1. Click Search. The box displays a table of vulnerability names that match your search criteria.
  2. Click the check boxes for vulnerabilities that you wish to include in the scan, and click Save. The selected vulnerabilities appear on the Vulnerability Checks page.
  3. Click Disable vulnerability checks... to exclude specific vulnerabilities from the scan.
  4. Search for the names of vulnerabilities you wish to exclude. The console displays the search results.
  5. Click the check boxes for vulnerabilities that you wish to exclude from the scan, and click Save. 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 check types that include the same check, it will only run that check once.
  6. Configure any other template settings as desired. When you have finished configuring the scan template, click Save.

Fine-tuning vulnerability checks

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:

  • The Microsoft IIS directory traversal check tests 500 URL combinations. This can take several minutes against a busy Web server.
  • Unsafe, denial-of-service checks take a particularly long time, since they involve large amounts of data or multiple requests to target systems.
  • Cross-site scripting (CSS/XSS) tests may take a long time on Web applications with many forms.

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.

Using a plug-in to manage custom checks

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:

1
[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:

1
[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.