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.
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.
Note: In order to comply with federal regulations, such as the Sarbanes-Oxley Act (SOX), it is often critically important to document the details of a vulnerability exception, such as the personnel involved in requesting and approving the exception, relevant dates, and information about the exception.
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:
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:
| If the vulnerability has the following exception status... | ...and you have the following permission... | ...you can take the following action: |
|---|---|---|
| never been submitted for an exception |
Submit Exception Request | submit an exception request |
| previously approved and later deleted or expired | Submit Exception Request | submit an exception request |
| under review (submitted, but not approved or rejected) | Review Vulnerability Exceptions | approve or reject the request |
| excluded for another instance, asset, or site | Submit Exception Request | submit an exception request |
| under review (and submitted by you) | recall the exception | |
| under review (submitted, but not approved or rejected) | Delete Vulnerability Exceptions | delete the request |
| approved | Review Vulnerability Exceptions | view and change the details of the approval, but not overturn the approval |
| rejected | Submit Exception Request | submit another exception request |
| approved or rejected | Delete Vulnerability Exceptions | delete the exception, thus overturning the approval |
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:
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.
The console displays the Vulnerabilities page.
Create and submit the exception request.
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.
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.
For information about exception reasons, see Understanding cases for excluding vulnerabilities.
These are especially helpful for a reviewer to understand your reasons for the request.
Note: If you select Other as a reason from the drop-down list, additional comments are required.
Note: Only a Global Administrator can approve a global vulnerability exception.
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.
The console displays the Administration page.
Note: If you enabled the option to link matching assets across all sites after the April 8, 2015, product update, you cannot use this Web interface feature to exclude vulnerabilities in sites after enabling the linking option. Site-level exceptions created in the Web interface before the option was enabled will continue to apply. See Linking assets across sites. You can use the API to exclude vulnerabilities at the site level. See the API guide.
Note: The vulnerability information in the page for a scan is specific to that particular scan instance. The ability to create an exception is available in more cumulative levels such as the site or vulnerability listing in order for the vulnerability to be excluded in future scans.
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:
The Security Console displays the Vulnerabilities page.
OR
The Security Console displays the Assets page.
The Security Console displays the Sites page.
The Security Console displays the page for the selected site.
The Security Console displays the page for the selected asset.
Create and submit an individual exception request.
Note: If a vulnerability has an action link other than Exclude, see Understanding cases for excluding vulnerabilities.
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.
For information about exception reasons, see Understanding cases for excluding vulnerabilities.
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.
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.
The Security Console displays the Vulnerabilities page.
OR
The Security Console displays the Assets page.
The Security Console displays the page for the selected asset.
Create and submit a single exception request.
Note: If a vulnerability has an action link other than Exclude, see Understanding vulnerability exception status and work flow.
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.
Note: If you select Other as a reason from the drop-down list, additional comments are required.
These are especially helpful for a reviewer to understand your reasons for the request.
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.
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.
Note: If you are resubmitting multiple vulnerabilty exception requests, the Use existing dates option for expiration date allows you to keep any previously set dates on the exceptions.
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.
Note: If you select all listed vulnerabilities for exclusion, it will only apply to vulnerabilities that have not been excluded. For example, if the Vulnerabilities table includes vulnerabilities that are under review or rejected, the global exclusion will not apply to them. The same applies for global resubmission: It will only apply to listed vulnerabilities that have been rejected for exclusion.
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.
The Security Console displays the Administration page.
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.
Note: The Security Console will not allow a vulnerability exception on dynamic asset groups that contain one or more of the following attributes specified: CVE ID, Vulnerability Title, Validated Vulnerabilities, Vulnerability Exposures, Asset Risk Score, Vulnerability CVSS Score, PCI Compliance Status, CVSS Access Complexity (AC), CVSS Access Vector (AV), CVSS Authentication (Au), CVSS Availability Impact (A), CVSS Confidentiality Impact (C), CVSS Integrity Impact (I), and/or Vulnerability Category.
The Security Console displays the Vulnerabilities page.
The Security Console displays vulnerabilities that meet all filter criteria in the table.
Create and submit an exception request
Note: If a vulnerability has an action link other than Exclude, see Understanding cases for excluding vulnerabilities.
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.
For information about exception reasons, see Understanding cases for excluding vulnerabilities.
These are especially helpful for a reviewer to understand your reasons for the request.
Note: If you select Other as a reason from the drop-down list, additional comments are required.
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.
Create and submit a single exception request.
Note: If a vulnerability has an action link other than Exclude, see Understanding vulnerability exception status and work flow .
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.
If you select Other as a reason from the drop-down list, additional comments are required.
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.
OR
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.
Note: If you select all listed vulnerabilities for exclusion, it will only apply to vulnerabilities that have not been excluded. For example, if the Vulnerabilities table includes vulnerabilities that are under review or rejected, the global exclusion will not apply to them. The same applies for global resubmission: It will only apply to listed vulnerabilities that have been rejected for exclusion.
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.
The console displays the Administration page.
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.
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.
OR
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.
Note: If you select all listed vulnerabilities for recall, it will only apply to vulnerabilities that are under review. For example, if the Vulnerabilities table includes vulnerabilities that have not been excluded, or have been rejected for exclusion, the global recall will not apply to them.
Upon reviewing a vulnerability exception request, you can either approve or reject it.
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).
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.
Note: You also can click the top row check box to select all requests and then approve or reject them in one step.
The result of the review appears in the Review Status column.
Selecting multiple requests for review
Deleting an exception is the only way to override an approved request.
Locate the exception or exception request.
The console displays the Administration page.
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).
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.
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.
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: