Vulnerability exceptions

All discovered vulnerabilities appear in the Vulnerabilities table of the Security Console Web interface. Your organization can exclude certain vulnerabilities from appearing in reports or affecting risk scores.

Understanding cases for excluding vulnerabilities

There are several possible reasons for excluding vulnerabilities from reports.

Compensating controls: Network managers may mitigate the security risks of certain vulnerabilities, which, technically, could prevent their organization from being PCI compliant. It may be acceptable to exclude these vulnerabilities from the report under certain circumstances. For example, the application may discover a vulnerable service on an asset behind a firewall because it has authorized access through the firewall. While this vulnerability could result in the asset or site failing the audit, the merchant could argue that the firewall reduces any real risk under normal circumstances. Additionally, the network may have host- or network-based intrusion prevention systems in place, further reducing risk.

Acceptable use: Organizations may have legitimate uses for certain practices that the application would interpret as vulnerabilities. For example, anonymous FTP access may be a deliberate practice and not a vulnerability.

Acceptable risk: In certain situations, it may be preferable not to remediate a vulnerability if the vulnerability poses a low security risk and if remediation would be too expensive or require too much effort. For example, applying a specific patch for a vulnerability may prevent an application from functioning. Re-engineering the application to work on the patched system may require too much time, money, or other resources to be justified, especially if the vulnerability poses minimal risk.

False positives: According to PCI criteria, a merchant should be able to report a false positive, which can then be verified and accepted by a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV) in a PCI audit. Below are scenarios in which it would be appropriate to exclude a false positive from an audit report. In all cases, a QSA or ASV would need to approve the exception.

Backporting may cause false positives. For example, an Apache update installed on an older Red Hat server may produce vulnerabilities that should be excluded as false positives.

If an exploit reports false positives on one or more assets, it would be appropriate to exclude these results.

Understanding vulnerability exception permissions

Your ability to work with vulnerability exceptions depends on your permissions. If you do not now know what your permissions are, consult your Global administrator.

Three permissions are associated with the vulnerability exception workflow:

• Submit Vulnerability Exceptions: A user with this permission can submit requests to exclude vulnerabilities from reports.
• Review Vulnerability Exceptions: A user with this permission can approve or reject requests to exclude vulnerabilities from reports.
• Delete Vulnerability Exceptions: A user with this permission can delete vulnerability exceptions and exception requests. This permission is significant in that it is the only way to overturn a vulnerability request approval. In that sense, a user with this permission can wield a check and balance against users who have permission to review requests.

Understanding vulnerability exception status and work flow

Every vulnerability has an exception status, including vulnerabilities that have never been considered for exception. The range of actions you can take with respect to exceptions depends on the exception status, as well as your permissions, as indicated in the following table:

Understanding different options for exception scope

A vulnerability may be discovered once or multiple times on a certain asset. The vulnerability may also be discovered on hundreds of assets. Before you submit a request for a vulnerability exception, review how many instances of the vulnerability have been discovered and how many assets are affected. It’s also important to understand the circumstances surrounding each affected asset. You can control the scope of the exception by using one of the following options when submitting a request:

• You can create an exception for all instances of a vulnerability on all affected assets. For example, you may have many instances of a vulnerability related to an open SSH port. However, if in all instances a compensating control is in place, such as a firewall, you may want to exclude that vulnerability globally.
• You can create an exception for all instances of a vulnerability in a site. As with global exceptions, a typical reason for a site-specific exclusion is a compensating control, such as all of a site’s assets being located behind a firewall.

• You can create an exception for all instances of a vulnerability on a single asset. For example one of the assets affected by a particular vulnerability may be located in a DMZ. Or perhaps it only runs for very limited periods of time for a specific purpose, making it less sensitive.
• You can create an exception for all instances of a vulnerability on an asset group. For example, an asset group that contains machines that are not connected to the internet may be excluded as they are less susceptible to intrusion.
• You can create an exception for a single instance of a vulnerability. For example, a vulnerability may be discovered on each of several ports on a server. However, one of those ports is behind a firewall. You may want to exclude the vulnerability instance that affects that protected port.

Submitting or re-submitting a request for a global vulnerability exception

A global vulnerability exception means that the application will not report the vulnerability on any asset in your environment that has that vulnerability. Only a Global Administrator can approve requests for global vulnerability exceptions. A user who is not an administrator but who has the correct account permissions can approve vulnerability exceptions that are not global.

Locate the vulnerability for which you want to request an exception. There are several ways to locate to a vulnerability. The following way is easiest for a global exception.

1. Click the Vulnerabilities icon of the Security Console Web interface. The console displays the Vulnerabilities page.
2. Locate the vulnerability in the Vulnerabilities table.

Create and submit the exception request.

1. Look at the Exceptions column for the located vulnerability. This column displays one of several possible actions. If an exception request has not previously been submitted for that vulnerability, the column displays an Exclude icon. If it was submitted and then rejected, the column displays a Resubmit icon.
2. Click the icon.

Tip: If a vulnerability has an action icon other than Exclude, see Understanding vulnerability exception permissions.

A Vulnerability Exception dialog box appears. If an exception request was previously submitted and then rejected, read the displayed reasons for the rejection and the user name of the reviewer. This is helpful for tracking previous decisions about the handling of this vulnerability.

3. Select All instances if it is not already displayed from the Scope drop-down list.
4. Select a reason for the exception from the drop-down list. For information about exception reasons, see Understanding cases for excluding vulnerabilities.
5. Enter additional comments. These are especially helpful for a reviewer to understand your reasons for the request.

6. To create an expiration date, select Select a date from the Expires on drop-down list. Specify a date, or use the calendar to select a date.
7. Click Submit & Approve to have the exception take effect.
8. (Optional) Click Submit to place the exception under review and have another individual in your organization review it.

Verify the exception (if you submitted and approved it).

After you approve an exception, the vulnerability no longer appears in the list on the Vulnerabilities page.

1. Click the Administration icon.
2. In the Vulnerability section, click Review vulnerability exception requests.
3. Locate the exception in the Vulnerability Exception Listing table.

Submitting or re-submitting an exception request for all instances of a vulnerability on a specific site

Locate the vulnerability for which you want to request an exception. There are several ways to locate to a vulnerability. The following ways are easiest for a site-specific exception:

1. If you want to find a specific vulnerability, click the Vulnerabilities icon of the Security Console Web interface. The Security Console displays the Vulnerabilities page.
2. Locate the vulnerability in the Vulnerabilities table, and click the link for it.
3. Find an asset in a particular site for which you want to exclude vulnerability instances in the Affects table of the vulnerability details page.

OR

1. If you want to see what vulnerabilities are affecting assets in different sites, click the Assets icon. The Security Console displays the Assets page.
2. Click the option to view assets by sites. The Security Console displays the Sites page.
3. Click a site in which you want to view vulnerabilities. The Security Console displays the page for the selected site.
4. Click an asset in the Asset Listing table. The Security Console displays the page for the selected asset.
5. Locate the vulnerability you want to exclude in the Vulnerabilities table and click the link for it.

Create and submit an individual exception request.

1. Look at the Exceptions column for the located vulnerability. If an exception request has not previously been submitted for that vulnerability, the column displays an Exclude icon. If it was submitted and then rejected, the column displays a Resubmit icon.
2. Click the Exclude icon.

A Vulnerability Exception dialog box appears. If an exception request was previously submitted and then rejected, read the displayed reasons for the rejection and the user name of the reviewer. This is helpful for tracking previous decisions about the handling of this vulnerability.

3. Select All instances in this site from the Scope drop-down list.
4. Select a reason for the exception from the drop-down list. For information about exception reasons, see Understanding cases for excluding vulnerabilities.
5. Enter additional comments. These are especially helpful for a reviewer to understand your reasons for the request. If you select Other as a reason from the drop-down list, additional comments are required.
6. To create an expiration date, select Select a date from the Expires on drop-down list. Specify a date, or use the calendar to select a date.
7. Click Submit & Approve to have the exception take effect.
8. Click Submit to place the exception under review and have another individual in your organization review it.

Submitting or re-submitting an exception request for all instances of a vulnerability on a specific asset

Locate the vulnerability for which you want to request an exception. There are several ways to locate to a vulnerability. The following ways are easiest for an asset-specific exception.

1. If you want to find a specific vulnerability, click the Vulnerabilities icon of the Security Console Web interface. The Security Console displays the Vulnerabilities page.
2. Locate the vulnerability in the Vulnerabilities table, and click the link for it.
3. Click the link for the asset that includes the instances of the vulnerability that you want to have excluded in the Affects table of the vulnerability details page.
4. On the details page of the affected asset, locate the vulnerability in the Vulnerabilities table and click the link for it.

OR

1. If you want to see what vulnerabilities are affecting specific assets that you find using different grouping categories, click the Assets icon. The Security Console displays the Assets page.
2. Select one of the options to view assets according to different grouping categories: sites they belong to, asset groups they belong to, hosted operating systems, hosted software, or hosted services. Or click the link to view all assets.
3. Depending on the category you selected, click through displayed subcategories until you find the asset you are searching for. See Locating and working with assets. The Security Console displays the page for the selected asset.
4. Locate the vulnerability that you want to exclude in the Vulnerabilities table and click the link for it.

Create and submit a single exception request.

1. Look at the Exceptions column for the located vulnerability. This column displays one of several possible actions. If an exception request has not previously been submitted for that vulnerability, the column displays an Exclude icon. If it was submitted and then rejected, the column displays a Resubmit icon.
2. Click the icon. A Vulnerability Exception dialog box appears. If an exception request was previously submitted and then rejected, read the displayed reasons for the rejection and the user name of the reviewer. This is helpful for tracking previous decisions about the handling of this vulnerability.
3. Select All instances on this asset from the Scope drop-down list.

4. Enter additional comments. These are especially helpful for a reviewer to understand your reasons for the request.
5. To create an expiration date, select Select a date from the Expires on drop-down list. Specify a date, or use the calendar to select a date.
6. Click Submit & Approve to have the exception take effect.
7. (Optional) Click Submit to place the exception under review and have another individual in your organization review it.

Create and submit (or resubmit) multiple, simultaneous exception requests

This procedure is useful if you want to exclude a large number of vulnerabilities because, for example, they all have the same compensating control.

1. After going to the Vulnerabilities table as described in the preceding section, select the row for each vulnerability that you want to exclude. OR To select all the vulnerabilities displayed in the table, click the check box in the top row. Then select the pop-up option Select Visible.
2. Click Exclude for vulnerabilities that have not been submitted for exception, or click Resubmit for vulnerabilities that have been rejected for exception.
3. Proceed with the vulnerability exception workflow as described in the preceding section.

If you've selected multiple vulnerabilities but then want to cancel the selection, click the top row. Then select the pop-up option Clear All.

Verify the exception (if you submitted and approved it). After you approve an exception, the vulnerability no longer appears in the list on the Vulnerabilities page.

1. Click the Administration icon. The Security Console displays the Administration page.
2. In the Vulnerability section, click Review vulnerability exception requests.
3. Locate the exception in the Vulnerability Exception Listing table.

Submitting or re-submitting an exception request for all instances of a vulnerability in an asset group

Locate the vulnerability for which you want to request an exception. There are several ways to locate to a vulnerability. The following ways are easiest for an asset group specific exception.

1. If you want to find a specific vulnerability, click the Vulnerabilities icon of the Security Console Web interface. The Security Console displays the Vulnerabilities page.
2. In the Vulnerability Listing table, expand the section to Apply Filters.
3. Select Asset Group Name from the drop-down list.
4. Select an operator for the filter.
5. Select an Asset Group based on the operator.
6. You may use multiple filters to narrow your search. Use the + button to add filters. Repeat the steps for selecting the filter, operator, and value. Use the - button to remove filters.
7. Click Filter. The Security Console displays vulnerabilities that meet all filter criteria in the table.
8. Locate the vulnerability in the Vulnerabilities table.

Create and submit an exception request

1. Look at the Exceptions column for the located vulnerability. If an exception request has not previously been submitted for that vulnerability, the column displays an Exclude icon. If it was submitted and then rejected, the column displays a Resubmit icon.
2. Click the Exclude icon.

A Vulnerability Exception dialog box appears. If an exception request was previously submitted and then rejected, read the displayed reasons for the rejection and the user name of the reviewer. This is helpful for tracking previous decisions about the handling of this vulnerability.

3. Select All instances in the selected asset groups from the Scope drop-down list.
4. Select the asset group name from the Asset Groups list.
5. Select a reason for the exception from the drop-down list. For information about exception reasons, see Understanding cases for excluding vulnerabilities.
6. Enter additional comments. These are especially helpful for a reviewer to understand your reasons for the request.

7. To create an expiration date, select Select a date from the Expires on drop-down list. Specify a date, or use the calendar to select a date.
8. Click Submit & Approve to have the exception take effect.
9. Click Submit to place the exception under review and have another individual in your organization review it.

Submitting or re-submitting an exception request for a single instance of a vulnerability

When you create an exception for a single instance of a vulnerability, the application will not report the vulnerability against the asset if the device, port, and additional data match.

Locate the instance of the vulnerability for which you want to request an exception. There are several ways to locate to a vulnerability. The following way is easiest for a site-specific exception.

1. Click the Vulnerabilities icon of the security console Web interface.
2. Locate the vulnerability in the Vulnerabilities table on the Vulnerabilities page, and click the link for it.
3. Locate the affected asset in the in the Affects table on the details page for the vulnerability.
4. (Optional) Click the Assets icon and use one of the displayed options to find a vulnerability on an asset. See Locating and working with assets.
5. Locate the vulnerability in the Vulnerabilities table on the asset page, and click the link for it.

Create and submit a single exception request.

1. Look at the Exceptions column for the located vulnerability. This column displays one of several possible actions. If an exception request has not previously been submitted for that vulnerability, the column displays an Exclude icon. If it was submitted and then rejected, the column displays a Resubmit icon.
2. Click the icon. A Vulnerability Exception dialog box appears. If an exception request was previously submitted and then rejected, you can view the reasons for the rejection and the user name of the reviewer in a note at the top of the box. Select a reason for requesting the exception from the drop-down list. For information about exception reasons, see Understanding cases for excluding vulnerabilities.
3. Select Specific instance on this asset from the Scope drop-down list. If you select Other as a reason from the drop-down list, additional comments are required.
4. Enter additional comments. These are especially helpful for a reviewer to understand your reasons for the request.
5. To create an expiration date, select Select a date from the Expires on drop-down list. Specify a date, or use the calendar to select a date.
6. Click Submit & Approve to have the exception take effect.
7. (Optional) Click Submit to place the exception under review and have another individual in your organization review it.

Re-submit multiple, simultaneous exception requests. This procedure is useful if you want to exclude a large number of vulnerabilities because, for example, they all have the same compensating control.

1. After going to the Vulnerabilities table as described in the preceding section, select the row for each vulnerability that you want to exclude. OR
2. To select all the vulnerabilities displayed in the table, click the check box in the top row. Then select the pop-up option Select Visible.
3. Click Exclude for vulnerabilities that have not been submitted for exception, or click Resubmit for vulnerabilities that have been rejected for exception.
4. Proceed with the vulnerability exception workflow as described in the preceding section. If you've selected multiple vulnerabilities but then want to cancel the selection, click the top row. Then select the pop-up option Clear All.

Verify the exception (if you submitted and approved it). After you approve an exception, the vulnerability no longer appears in the list on the Vulnerabilities page.

1. Click the Administration icon. The console displays the Administration page.
2. In the Vulnerability section, click Review vulnerability exception requests.
3. Locate the exception in the Vulnerability Exception Listing table.

Recalling an exception request that you submitted

You can recall, or cancel, a vulnerability exception request that you submitted if its status remains under review.

Locate the exception request, and verify that it is still under review. The location depends on the scope of the exception. For example, if the exception is for all instances of the vulnerability on a single asset, locate that asset in the Affects table on the details page for the vulnerability. If the link in the Exceptions column is Under review, you can recall it.

Recall a single request.

1. Click the Under Review link.
2. Click Recall in the Vulnerability Exception dialog box. The link in the Exceptions column changes to Exclude.

Recall multiple, simultaneous exception requests.

This procedure is useful if you want to recall a large number of requests because, for example, you've learned that since you submitted them it has become necessary to include them in a report.

1. After locating the exception request as described in the preceding section, select the row for each vulnerability that you want to exclude. OR
2. To select all the vulnerabilities displayed in the table, click the check box in the top row. Then select the pop-up option Select Visible.
3. Click Recall.
4. Proceed with the recall workflow as described in the preceding section. If you've selected multiple vulnerabilities but then want to cancel the selection, click the top row. Then select the pop-up option Clear All.

Reviewing an exception request

Upon reviewing a vulnerability exception request, you can either approve or reject it.

1. Locate the exception request.
2. Click the Administration icon of the security console Web interface.
3. In the Vulnerability section, click Review vulnerability exception requests.
4. Locate the request in the Vulnerability Exception Listing table. To select multiple requests for review, select each desired row. OR, to select all requests for review, select the top row. Selecting multiple requests is useful if you know, for example, that you want to accept or reject multiple requests for the same reason.

Review the request(s).

1. Click the Under review link in the Review Status column.
2. Read the comments by the user who submitted the request and decide whether to approve or reject the request.
3. Enter comments in the Reviewer’s Comments text box. Doing so may be helpful for the submitter. If you want to select an expiration date for the review decision, click the calendar icon and select a date. For example, you may want the exception to be in effect only until a PCI audit is complete.

4. Click Approve or Reject, depending on your decision. The result of the review appears in the Review Status column.

Deleting a vulnerability exception or exception request

Deleting an exception is the only way to override an approved request.

Locate the exception or exception request.

1. Click the Administration icon of the security console Web interface. The console displays the Administration page.
2. Click the Review vulnerability exception requests link next to Vulnerability Exceptions.
3. Locate the request in the Vulnerability Exception Listing table. To select multiple requests for deletion, select each desired row. OR, to select all requests for deletion, select the top row.

Delete the request(s).

1. Click the Delete icon. The entry(ies) no longer appear in the Vulnerability Exception Listing table. The affected vulnerability(ies) appear in the appropriate vulnerability listing with an Exclude icon, which means that a user with appropriate permission can submit an exception request for it.

Viewing vulnerability exceptions in the Report Card report

When you generate a report based on the default Report Card template, each vulnerability exception appears on the vulnerability list with the reason for its exception.

How vulnerability exceptions appear in XML and CSV formats

Vulnerability exceptions can be important for the prioritization of remediation projects and for compliance audits. Report templates include a section dedicated to exceptions. See [Vulnerability Exceptions]. In XML and CSV reports, exception information is also available.

XML: The vulnerability test status attribute is set to one of the following values for vulnerabilities suppressed due to an exception:

exception-vulnerable-exploited - Exception suppressed exploited vulnerability

exception-vulnerable-version - Exception suppressed version-checked vulnerability

exception-vulnerable-potential - Exception suppressed potential vulnerability

CSV: The vulnerability result-code column will be set to one of the following values for vulnerabilities suppressed due to an exception. Each code corresponds to results of a vulnerability check:

Each code corresponds to results of a vulnerability check:

• ds (skipped, disabled): A check was not performed because it was disabled in the scan template.
• ee (excluded, exploited): A check for an exploitable vulnerability was excluded.
• ep (excluded, potential): A check for a potential vulnerability was excluded.
• er (error during check): An error occurred during the vulnerability check.
• ev (excluded, version check): A check was excluded. It is for a vulnerability that can be identified because the version of the scanned service or application is associated with known vulnerabilities.
• nt (no tests): There were no checks to perform.
• nv (not vulnerable): The check was negative.
• ov (overridden, version check): A check for a vulnerability that would ordinarily be positive because the version of the target service or application is associated with known vulnerabilities was negative due to information from other checks.
• sd (skipped because of DoS settings): sd (skipped because of DOS settings)—If unsafe checks were not enabled in the scan template, the application skipped the check because of the risk of causing denial of service (DOS). See Configuration steps for vulnerability check settings.
• sv (skipped because of inapplicable version): the application did not perform a check because the version of the scanned item is not in the list of checks.
• uk (unknown): An internal issue prevented the application from reporting a scan result.
• ve (vulnerable, exploited): The check was positive. An exploit verified the vulnerability.
• vp (vulnerable, potential): The check for a potential vulnerability was positive.
• vv (vulnerable, version check): The check was positive. The version of the scanned service or software is associated with known vulnerabilities.