Accepting Risk with Vulnerability Exceptions

Accepted Risk is the amount of your risk score that is impacted by vulnerability exceptions. An exception allows you to prevent a specific vulnerability from counting against your overall risk score.

Reasons for accepting risk

There are several possible reasons for excluding vulnerabilities from reporting.

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. The following examples describe when 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.

For compliance, document your exceptions

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.

Who can work with vulnerability exceptions?

The ability to work with vulnerability exceptions depends on user permissions. If you do not know what your permissions are, contact your Global Administrator.

The following permissions are associated with the vulnerability exception workflow:

PermissionDescription
Submit Vulnerability ExceptionsA user with this permission can submit requests to exclude vulnerabilities from reports
Review Vulnerability ExceptionsA user with this permission can approve or reject requests to exclude vulnerabilities from reports
Delete Vulnerability ExceptionsA 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
Global AdministratorA user with this permission can approve requests for global vulnerability exceptions

Exception status and associated actions

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:

Exception StatusPermissionAction
Not submittedSubmit Exception RequestSubmit an exception request
Under reviewSubmit Exception RequestRecall the exception request
Under reviewReview Vulnerability Exception RequestApprove or reject the request
Under reviewDelete Vulnerability ExceptionsDelete the request
ApprovedReview Vulnerability ExceptionsView and change details of approval, but not reject
RejectedSubmit Exception RequestSubmit another exception request
Approved or RejectedDelete Exception RequestDelete the request
Excluded for another instance, asset, or siteSubmit Exception RequestSubmit an exception request
Previously approved and later deleted or expiredSubmit Exception RequestSubmit an exception request

Submit exceptions using 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:

ScopeDescription
GlobalAll 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.
Site-specificAll 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.
Asset-specificAll 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.
Asset group-specificAll 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.
Vulnerability-specificA 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.

Submit a global vulnerability exception 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.

  1. From the main menu, click Vulnerabilities.
  2. On the Vulnerabilities page, select the vulnerability for which you want to create an exception.
  3. Create the exception request.
    1. Select All instances if it is not already displayed from the Scope drop-down list.
    2. Select a reason for the exception from the drop-down list.
    3. Enter additional comments.
    4. To create an expiration date, select Select a date from the Expires drop-down list. Specify a date, or use the calendar to select a date.
  4. Submit the request.
    1. Click Submit & Approve to have the exception take effect.
    2. (Optional) Click Submit to place the exception under review and have another individual in your organization review it.
  5. Verify that the request was submitted.
    1. From the Administration menu, go to Vulnerability > Review vulnerability exception requests.
    2. Verify that the exception is listed in the table.

Submit site-specific exceptions

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.

Vulnerability information on a scan page is specific to that scan

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.

  1. From the main menu, click Vulnerabilities.
  2. On the Vulnerabilities page, select the vulnerability for which you want to create an exception.
  3. On the selected vulnerability page, in the Affects section, select the asset for which you want to exclude instances of the vulnerability.
  4. In the Exceptions column, click the Exclude icon.
  5. Create the exception request.
    1. Select All instances if it is not already displayed from the Scope drop-down list.
    2. Select a reason for the exception from the drop-down list.
    3. Enter additional comments.
    4. 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. Submit the request.
    1. Click Submit & Approve to have the exception take effect.
    2. (Optional) Click Submit to place the exception under review and have another individual in your organization review it.
  7. Verify that the request was submitted.
    1. From the Administration menu, go to Vulnerability > Review vulnerability exception requests.
    2. Verify that the exception is listed in the table.

Submit asset-specific exceptions

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

  1. From the main menu, click Vulnerabilities.
  2. On the Vulnerabilities page, select the vulnerability for which you want to create an exception.
  3. On the selected vulnerability page, in the Affects section, select the asset for which you want to exclude instances of the vulnerability.
  4. In the Exceptions column, click the Exclude icon.
  5. On the selected asset page, click the link for the vulnerability for which you want to create an exception request.
  6. Create the exception request.
    1. Select All instances if it is not already displayed from the Scope drop-down list.
    2. Select a reason for the exception from the drop-down list.
    3. Enter additional comments.
    4. 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. Submit the request.
    1. Click Submit & Approve to have the exception take effect.
    2. (Optional) Click Submit to place the exception under review and have another individual in your organization review it.
  8. Verify that the request was submitted.
    1. From the Administration menu, go to Vulnerability > Review vulnerability exception requests.
    2. Verify that the exception is listed in the table.

Submit an asset group-specific exception

  1. From the main menu, click Vulnerabilities.
  2. On the Vulnerabilities page, filter to find the asset group.
    1. expand the Apply Filters section.
    2. Select Asset Group Name.
    3. Select an operator for the filter.
    4. Select an asset group based on the operator.
    5. Click Filter.
  3. Click the link for the vulnerability for which you want to create an exception request.
  4. In the Exceptions column, click the Exclude icon.
  5. Create the exception request.
    1. Select All instances if it is not already displayed from the Scope drop-down list.
    2. Select a reason for the exception from the drop-down list.
    3. Enter additional comments.
    4. 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. Submit the request.
    1. Click Submit & Approve to have the exception take effect.
    2. (Optional) Click Submit to place the exception under review and have another individual in your organization review it.
  7. Verify that the request was submitted.
    1. From the Administration menu, go to Vulnerability > Review vulnerability exception requests.
    2. Verify that the exception is listed in the table.

Create and submit multiple exception requests

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

  1. From the main menu, click Vulnerabilities.
  2. On the Vulnerabilities page, select one or more vulnerabilities for which you want to create exception requests.
  3. Click Exclude for vulnerabilities that have not been submitted for exception.
  4. Click Resubmit for vulnerabilities that have been rejected for exception.

Resubmit a vulnerability exception request

  1. From the main menu, click Vulnerabilities.
  2. On the Vulnerabilities page, select the vulnerability for which you want to create an exception.
  3. (Optional) In the Exceptions column, click the Resubmit icon.
  4. Create the exception request.
    1. Select All instances if it is not already displayed from the Scope drop-down list.
    2. Select a reason for the exception from the drop-down list.
    3. Enter additional comments.
    4. 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.
  5. Submit the request.
    1. Click Submit & Approve to have the exception take effect.
    2. (Optional) Click Submit to place the exception under review and have another individual in your organization review it.
  6. Verify that the request was submitted.
    1. From the Administration menu, go to Vulnerability > Review vulnerability exception requests.
    2. Verify that the exception is listed in the table.

Recall an exception request

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

  1. From the main menu, click Vulnerabilities.
  2. On the Vulnerabilities page, select the vulnerability for which you want to create an exception.
  3. In the Exceptions column, click the Under Review link.
  4. Click Recall.

Recall multiple 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. From the main menu, click Vulnerabilities.
  2. On the Vulnerabilities page, select the vulnerabilities for which you want to create an exception.
  3. In the Exceptions column, click the Under Review link.
  4. Click Recall.

Review an exception request

  1. From the Administration page, go to Vulnerabilities > Exceptions and Investigations.
  2. Click the exception request you want to review.
  3. Review the comments and determine whether to approve or reject the request.
  4. In the Reviewer Comments section, enter your comments.
  5. Click Approve or Reject.

Delete a vulnerability exception or exception request

  1. From the Administration page, go to Vulnerability > Exceptions and Investigations.
  2. Click the exception request you want to delete.
  3. Click the Delete icon. A user can still submit an exception request, but the current request is deleted.

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. 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:

  • 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.