Document Diff - PCI Watch

Added p. 2

May 2013 2.0 ASV Program Guide updated to provide a number of minor clarifications in response to feedback from the ASV and scanning community, including clarification on resolving inconclusive scans due to scan interference. Changes to formatting, punctuation and grammar also made throughout the document.

This document is intended for use with PCI DSS version 2.0.

Requirement 11.2 of the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures requires quarterly external vulnerability scans, which must be performed by ASV. The PCI DSS provides the foundation for this and all other PCI DSS-related requirements and procedures.

 ASV Program Guide 1.0 ASVs must implement the requirements set forth in this document effective immediately since no changes in this document require changes to the ASVs’ scanning solution.

Added p. 5

Term Meaning ASV (Approved Scanning Vendor) Refers to a company that has been approved by PCI SSC to conduct external vulnerability scanning services in accordance with PCI DSS Requirement 11.2.2. Refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.

External scan Refers to a vulnerability scan conducted from outside the logical network perimeter on all internet-facing hosts that are within or provide a path to an entity’s cardholder data environment (CDE).

Internal scan Refers to a vulnerability scan conducted from inside the logical network perimeter on all internal-facing hosts that are within or provide a path to an entity’s cardholder data environment (CDE).

QSA (Qualified Security Assessor) Refers to an assessor company that has been qualified and trained by PCI SSC to perform PCI DSS assessments. Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.

Added p. 6

PCI SSC reflects a desire among constituents of the Payment Card Industry at all levels to align and to standardize security requirements, security assessment procedures, and processes for external vulnerability scans and ASV scan solutions. The ASV documents and the PCI DSS define a common security assessment framework that is recognized by the payment brands.

Added p. 9

Vulnerability-scanning companies interested in providing vulnerability scanning services in accordance with PCI DSS must comply with the requirements set forth in this document as well as the Validation Requirements for Approved Scanning Vendors (ASVs), and must successfully complete the PCI Security Scanning Vendor Testing and Approval Process.

Added p. 10

11.2.1.b Review the scan reports and verify that the scan process includes rescans until passing results are obtained, or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.

11.2.1.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

Added p. 10

Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), qualified by the Payment Card Industry Security Standards Council (PCI SSC). Scans conducted after network changes may be performed by internal staff.

11.2.2.a Review output from the four most recent quarters of external vulnerability scans and verify that four quarterly scans occurred in the most recent 12-month period.

11.2.2.b Review the results of each quarterly scan to ensure that they satisfy the ASV Program Guide requirements (for example, no vulnerabilities rated higher than a 4.0 by the CVSS and no automatic failures).

11.2.2.c Review the scan reports to verify that the scans were completed by an Approved Scanning Vendor (ASV) approved by the PCI SSC.

Added p. 10

Note: Scans conducted after changes may be performed by internal staff.

11.2.3.a Inspect change control documentation and scan reports to verify that system components subject to any significant change were scanned.

11.2.3.b Review scan reports and verify that the scan process includes rescans until:

 For external scans, no vulnerabilities exist that are scored greater than a 4.0 by the CVSS, and  For internal scans, a passing result is obtained or no vulnerabilities exist ranked greater than “High” per PCI DSS Requirement 6.2 11.2.3.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

Added p. 11

4. The scanning vendor submits a request for solution testing via the ASV Portal.

For ISPs, scan customers need to coordinate with them to allow the ASV scan to be performed without interference from active protection systems. For more details, see the section entitled “ASV Scan Interference.” In a shared hosting environment, the scan customer shares the environment with the hosting provider’s other customers. This could lead to the scan customer’s environment being compromised through security weaknesses in other customers’ environments at the hosting provider. Components commonly hosted by third-party providers include but are not limited to DNS servers, email and web servers, application servers, etc.

Added p. 14

ASV Scan Interference If an ASV detects that an active protection system has blocked or filtered a scan, then the ASV is required to handle it in accordance with the Resolving Inconclusive Scans section of this document. In order to ensure that reliable scans can be conducted, the ASV scan solution must be allowed to perform s canning without interference from active protection systems, where “active” denotes security systems that dynamically modify their behavior based on information gathered from non-attack network traffic patterns. Non-attack traffic refers to potentially legitimate network traffic patterns that do not indicate malformed or malicious traffic, whereas attack traffic includes, for example, malicious network traffic patterns or patterns that match known attack signatures, malware, or packets exceeding the maximum permitted IP packet size. Examples of active protection systems that dynamically modify their behavior include, but are not limited to:

 Intrusion prevention systems (IPS) that drop non-malicious …

Added p. 15

Being able to detect all vulnerabilities is part of the “defense-in-depth” approach of PCI DSS. If the scan cannot detect vulnerabilities on Internet-facing systems because the scan is blocked by an active protection system, those vulnerabilities will remain uncorrected and may be exploited by an attacker whose attack patterns don't trigger the active protection mechanism.

All ASV scans must either be validated by the ASV to ensure they have not been blocked or filtered by an active protection system, or resolved in accordance with the Resolving Inconclusive Scans section of this document.

Temporary configuration changes may need to be made by the scan customer to remove interference during a scan Due to the remote nature of external vulnerability scans and the need mentioned above to conduct a scan without interference from an active protection system, certain temporary configuration changes to the scan customer’s network devices may be necessary to obtain a scan …

Added p. 18

The ASV scan solution must test for known vulnerabilities and determine whether the firewall or router is adequately patched.

Web Servers Web servers allow Internet users to view web pages, interact with web merchants, and conduct online web transactions. Malicious individuals exploit vulnerabilities in these servers and their scripts to gain access to applications and internal databases that potentially store, process or manage access to cardholder data. Permitting directory browsing on a web server increases security risk; for example, it may expose file system contents or provide unintended access to sensitive data.

Because these servers are accessible from the public Internet, scanning for vulnerabilities is essential.

Added p. 20

Web Applications Web applications typically reside on web or application servers and interface with the back-end databases and other systems. Web applications may process or transmit cardholder data as part of the customer’s online transaction, or store such data in a database server. Malicious individuals frequently attempt to exploit web application vulnerabilities to gain access to applications or internal databases that may process, store, or manage access to cardholder data.

The ASV scan solution must be able to detect via automated or manual means the following application vulnerabilities and configuration issues:

2. The National Vulnerability Database, which is maintained by the National Institute of Standards and Technology (NIST). The NVD contains details of known vulnerabilities based on the CVE dictionary. The NVD has adopted the CVSS and publishes CVSS Base Scores for each vulnerability. ASVs should use the CVSS scores whenever they are available.

Added p. 26

 For this report section, the ASV can optionally generate it according to the template at Appendix C: Scan Report Vulnerability Details. If the template is not used, all information specified in Appendix C must be clearly included.

Added p. 27

 Reviews scan customer scoping practices  Detects incorrect, incomplete, or corrupt scans  Detects obvious inconsistencies in findings  Reviews and corrects connectivity issues between the scan solution and scan customer  ASV reviewed this scan report and exceptions.

 Scan customer corrects noted failing vulnerabilities.

 If passing scan is achieved, scan customer submits results according to the “Compliance Reporting” section below.

Resolving Inconclusive Scans For ASV scans that cannot be completed due to scan interference, the scan customer may work with the ASV to implement one or more of the following options until a complete scan is achieved. An inconclusive scan that is left unresolved must be reported by the ASV as a failed scan:

1. Scan customer makes proper temporary configuration changes to remove interference during a scan; the scan customer may seek help from a trusted security professional as needed to determine proper temporary configuration changes to be made. …

Removed p. 1

Payment Card Industry (PCI) Approved Scanning Vendors Program Guide Reference 1.0 PCI DSS Version 1.2

Removed p. 4

Requirement 11.2 of the Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures (―PCI DSS‖) Version 1.2 requires quarterly external vulnerability scans, which must be performed by an Approved Scanning Vendor (ASV). The PCI DSS provides the foundation for this and all other PCI DSS-related requirements and procedures. The following additional documents are used in conjunction with the PCI DSS:

 Technical and Operational Requirements for ASVs, version 1.1  Security Scanning Procedures, version 1.1 ASVs must implement the requirements set forth in this document by no later than September 1, 2010.

Modified p. 4

Note: The requirements in this document apply specifically to the quarterly EXTERNAL vulnerability scans required by PCI DSS Requirement ~~11.2.~~ The PCI SSC recommends, but does not require, that scan customers use ~~the requirements~~ for other vulnerability scanning required by PCI DSS Requirement 11.2, including internal vulnerability scanning, ~~external~~ scanning performed after a significant change to the ~~network,~~ and any ~~external~~ scanning performed in addition to the required quarterly external ~~scans.~~

Note: The requirements in this document apply specifically to the quarterly EXTERNAL vulnerability scans required by PCI DSS Requirement 11.2.2. The PCI SSC recommends, but does not require, that scan customers use this document for other vulnerability scanning required by PCI DSS Requirement 11.2, including internal vulnerability scanning, scanning performed after a significant change to the network or applications, and any scanning performed in addition to the required quarterly external scans/rescans.

Modified p. 4

Note: The PCI DSS Requirements and Security Assessment Procedures list the specific technical requirements and provide the assessment procedures and template used by merchants and service providers to validate PCI DSS compliance and document the review. PCI DSS Requirement ~~11.2~~ specifically requires quarterly external vulnerability scans that must be performed by an ASV. The ASV Validation Requirements defines the requirements that must be met by an ASV in order to perform PCI DSS quarterly external vulnerability scans. ~~All documents are …~~

Note: The PCI DSS Requirements and Security Assessment Procedures list the specific technical requirements and provide the assessment procedures and template used by merchants and service providers to validate PCI DSS compliance and document the review. PCI DSS Requirement 11.2.2 specifically requires quarterly external vulnerability scans that must be performed by an ASV. The ASV Validation Requirements defines the requirements that must be met by an ASV in order to perform PCI DSS quarterly external vulnerability scans.

Modified p. 4

Updates to Documents and Security Requirements Security is a never-ending race against potential threats. As a result, it is necessary to regularly review, update and improve the PCI DSS. As such, PCI SSC will ~~endeavour to~~ update PCI DSS requirements ~~every 24 months.~~ The ASV Program Guide is expected to change when threats evolve or as necessary to incorporate changes in PCI DSS.

Updates to Documents and Security Requirements Security is a never-ending race against potential threats. As a result, it is necessary to regularly review, update and improve the PCI DSS. As such, PCI SSC will update PCI DSS requirements according to PCI SSC’s defined three-year lifecycle process. The ASV Program Guide is expected to change when threats evolve or as necessary to incorporate changes in PCI DSS.

Modified p. 4

PCI SSC reserves the right to change, amend or withdraw PCI DSS requirements at any time, and will ~~endeavour to~~ work closely with its community of Participating Organizations regarding such changes. The final published version of this document supersedes the following PCI DSS supporting documents:

PCI SSC reserves the right to change, amend or withdraw PCI DSS and/or ASV requirements at any time, and will work closely with its community of Participating Organizations regarding such changes. The final published version of this document supersedes the following PCI DSS supporting documents:

Removed p. 5

PCI SSC reflects a desire among constituents of the Payment Card Industry (PCI) at all levels to align and to standardize security requirements, security assessment procedures, and processes for external vulnerability scans and ASV scan solutions. The ASV documents and the PCI DSS define a common security assessment framework that is recognized by all payment brands.

For more information regarding PCI SSC, see the PCI SSC’s website at www.pcisecuritystandards.org (―the Website‖).

Modified p. 5

~~ ―PCI DSS‖ refers~~ to the then-current version of the Payment Card Industry (PCI) Data Security Standard, as available through the Website (defined below).

PCI DSS Refers to the then-current version of the Payment Card Industry (PCI) Data Security Standard, as available through the Website (defined below).

Modified p. 5

~~ ―PCI SSC‖ refers~~ to the PCI Security Standards Council, LLC.

PCI SSC Refers to the PCI Security Standards Council, LLC.

Modified p. 5

~~ ―Payment brands‖ refers~~ to the payment card brands that are statutory members of PCI SSC, currently American Express Travel Related Services Company, Inc., Discover Financial Services LLC, JCB Advanced Technologies, Inc., MasterCard International Incorporated, and Visa Holdings, Inc.

Payment brands Refers to the payment card brands that are statutory members of PCI SSC, currently American Express Travel Related Services Company, Inc., Discover Financial Services LLC, JCB Advanced Technologies, Inc., MasterCard International Incorporated, and Visa Holdings, Inc.

Modified p. 5

 ―ASV‖ (Approved Scanning Vendor) refers to a data security firm that has been qualified and trained by the PCI SSC to use a vulnerability scanning solution to determine compliance of their customers with the external vulnerability scanning requirement of PCI DSS Requirement 11.2  ―Scan Customer‖ refers to a merchant or service provider who undergoes a quarterly external vulnerability scan via an ASV, either through relationship with an ASV, or through a relationship between a scan customer’s acquirer and …

Scan Customer Refers to a merchant or service provider who undergoes a quarterly external vulnerability scan via an ASV, either through a relationship with an ASV, or through a relationship between a scan customer’s acquirer and an ASV.

Modified p. 5

~~ ―ASV~~ scan ~~solution‖ refers~~ to a set of security services and tool(s) offered by an ASV to validate compliance of a ~~merchant or service provider~~ with the external vulnerability scanning requirement of PCI DSS Requirement ~~11.2.~~ The scanning solution includes the scanning procedures, the scanning tool(s), the associated scanning report, the process for exchanging information between the scanning vendor and the scan customer, and the processes used by qualified ASV employees to:

ASV scan solution Refers to a set of security services and tool(s) offered by an ASV to validate compliance of a scan customer with the external vulnerability scanning requirement of PCI DSS Requirement 11.2.2. The scanning solution includes the scanning procedures, the scanning tool(s), the associated scanning report, the process for exchanging information between the scanning vendor and the scan customer, and the processes used by qualified ASV employees to:

Modified p. 5

 Operate the ASV scan solution  Submit the scan report to the scan customer  Review and interpret scan results, as needed ~~ ―QSA‖ (Qualified Security Assessor) refers~~ to a data ~~security assessment firm that has been qualified and trained by~~ PCI ~~SSC~~ to ~~perform~~ PCI DSS ~~onsite assessments.~~

 Operate the ASV scan solution  Submit the scan report to the scan customer  Review and interpret scan results, as needed CDE (Cardholder Data Environment) Refers to the cardholder data environment as defined in the PCI DSS. Refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms.

Modified p. 5

~~ ―CVSS‖ refers~~ to the ~~Common Vulnerability Scoring System~~ version ~~2.0,~~ an open framework for communicating the characteristics and impacts of IT vulnerabilities.

CVSS (Common Vulnerability Scoring System) Refers to the latest version of an open framework for communicating the characteristics and impacts of IT vulnerabilities.

Modified p. 5

~~ ―NVD‖ refers~~ to the National Institute of Standards and Technology (NIST) National Vulnerability Database for known vulnerabilities and vulnerability details.

NVD (National Vulnerability Database) Refers to the National Institute of Standards and Technology (NIST) National Vulnerability Database for known vulnerabilities and vulnerability details.

Modified p. 5

~~ ―CVE‖ refers to Common~~ Vulnerabilities and ~~Exposures,~~ a publicly available and free-to-use list or dictionary of standardized identifiers for common computer vulnerabilities and exposures.

CVE (Common Vulnerabilities and Exposures) Refers to a publicly available and free-to-use list or dictionary of standardized identifiers for common computer vulnerabilities and exposures.

Modified p. 5 → 6

 Customers benefit from a broad selection of ~~Approved Scanning Vendors (ASVs).~~

 Customers benefit from a broad selection of ASVs.

Removed p. 6

 Maintains and updates PCI DSS and related documentation (including this ASV Program Guide) according to a standards life cycle management process.

Modified p. 6

PCI DSS Alignment Initiative and Overview The Payment Card Industry ~~(PCI) has~~ initiated a collaborative effort to address common industry security requirements, including the security of merchants’ and service providers’ cardholder data environments. The creation of PCI DSS to secure cardholder data represents an effort to standardize security requirements relevant to protection of cardholder data environments used to store, process, or transmit cardholder data. PCI DSS Requirement ~~11.2~~ requires that external vulnerability scanning be performed quarterly by an ASV qualified …

For more information regarding PCI SSC, see the PCI SSC’s website at www.pcisecuritystandards.org (“the Website”). PCI DSS Alignment Initiative and Overview The Payment Card Industry as initiated a collaborative effort to address common industry security requirements, including the security of merchants’ and service providers’ cardholder data environments. The creation of PCI DSS to secure cardholder data represents an effort to standardize security requirements relevant to protection of cardholder data environments used to store, process, or transmit cardholder data. PCI DSS …

Modified p. 6

Roles and Responsibilities There are several stakeholders in the payment community. Some of these stakeholders

•ASVs, QSAs, and PCI SSC

•have a more direct participation in the PCI DSS assessment process. Other stakeholders that are not directly involved with the assessment process should be aware of the overall process to facilitate their associated business decisions. The following defines the roles and responsibilities of the stakeholders in the payment ~~application~~ community. Those stakeholders that are involved in the assessment process have those related …

Roles and Responsibilities There are several stakeholders in the payment community. Some of these stakeholders

•ASVs, QSAs, and PCI SSC

•have a more direct participation in the PCI DSS assessment process. Other stakeholders that are not directly involved with the assessment process should be aware of the overall process to facilitate their associated business decisions. The following defines the roles and responsibilities of the stakeholders in the payment community. Those stakeholders that are involved in the assessment process have those related responsibilities …

Modified p. 6 → 7

 Approves and trains ASVs to perform PCI DSS external vulnerability scans in accordance with PCI DSS and the PCI DSS Security Scanning Vendor Testing and Approval Processes, and qualifies, trains, and lists Approved Scanning Vendors on the ~~Website.~~

 Approves and trains ASVs to perform PCI DSS external vulnerability scans in accordance with PCI DSS and the PCI DSS Security Scanning Vendor Testing and Approval Processes, and qualifies, trains, and lists Approved Scanning Vendors on the Website  Maintains and updates PCI DSS and related documentation (including this ASV Program Guide) according to a standards life cycle management process  Maintains a quality assurance program for ASVs Approved Scanning Vendors An ASV is an organization with a set …

Modified p. 7

 Performing external vulnerability scans in accordance with PCI DSS ~~Requirements 11.2,~~ and in accordance with this document and other supplemental guidance published by the PCI SSC  Making reasonable efforts to ensure scans:

 Performing external vulnerability scans in accordance with PCI DSS Requirement 11.2.2, and in accordance with this document and other supplemental guidance published by the PCI SSC  Maintaining security and integrity of systems and tools used to perform scans  Making reasonable efforts to ensure scans:

Modified p. 7 → 8

 Performing PCI DSS assessments in accordance with the PCI DSS Requirements and Security Assessment Procedures, which includes confirming that PCI DSS Requirement 11.2 is ~~―in place‖~~  Providing an opinion about whether the assessed entity meets PCI DSS requirements  Providing adequate documentation within the Report on Compliance (ROC) to demonstrate the assessed entity’s compliance with PCI DSS  Submitting the ROC and the Attestation of Validation (signed by the QSA and in some cases, the assessed entity)  …

 Performing PCI DSS assessments in accordance with the PCI DSS Requirements and Security Assessment Procedures, which includes confirming that PCI DSS Requirement 11.2 is “in place”  Providing an opinion about whether the assessed entity meets PCI DSS requirements  Providing adequate documentation within the Report on Compliance (ROC) to demonstrate the assessed entity’s compliance with PCI DSS  Submitting the ROC and the Attestation of Validation (signed by the QSA and in some cases, the assessed entity)  …

Modified p. 8

 Maintaining compliance with the PCI DSS at all times, which includes properly maintaining the security of their Internet-facing systems  Selecting an ASV from the list of Approved Scanning Vendors ~~at www.pcisecuritystandards.org~~ to conduct quarterly external vulnerability scanning according to PCI DSS Requirement ~~11.2~~ and this document  Defining the scope of external vulnerability scanning, which includes:

 Maintaining compliance with the PCI DSS at all times, which includes properly maintaining the security of their Internet-facing systems  Selecting an ASV from the list of Approved Scanning Vendors from the Council’s website to conduct quarterly external vulnerability scanning according to PCI DSS Requirement 11.2.2 and this document  Perform due diligence in the ASV selection process, per the scan customer’s due-diligence processes, to obtain assurance as to the ASV’s level of trust to perform scanning services  …

Modified p. 8

 Providing the IP addresses and/or domain names of all Internet-facing systems to the ASV so the ASV can conduct a full scan  Implementing proper network segmentation for any excluded ~~external facing~~ IP addresses See the section titled ASV Scan Scope Definition for more information.  Ensuring that devices do not interfere with the ASV scan, including:

 Providing the IP addresses and/or domain names of all Internet-facing systems to the ASV so the ASV can conduct a full scan  Implementing proper network segmentation for any excluded external-facing IP addresses See the section titled ASV Scan Scope Definition for more information.  Ensuring that devices do not interfere with the ASV scan, including:

Modified p. 8

 Configuring ~~intrusion detection~~ systems ~~(IDSs) and intrusion prevention systems (IPSs)~~ so they do not interfere with the ASV’s scan, as required by this document. See the section entitled ~~Perform a~~ Scan ~~without Interference from IDS/IPS.~~

 Configuring active protection systems so they do not interfere with the ASV’s scan, as required by this document. See the section entitled ASV Scan Interference.

Removed p. 9

Vulnerability-scanning companies interested in providing PCI DSS vulnerability scans in conjunction with PCI DSS must comply with the requirements set forth in this document as well as the Validation Requirements for Approved Scanning Vendors (ASVs), and must successfully complete the PCI Security Scanning Vendor Testing and Approval Process.

 Scoping  Scanning  Dispute Resolution  Reporting/remediation

PCI DSS Requirement 11.2 states:

11.2.a Inspect output from the most recent four quarters of internal network, host, and application vulnerability scans to verify that periodic security testing of the devices within the cardholder data environment occurs. Verify that the scan process includes re-scans until passing results are obtained. Note: External scans conducted after network changes, and internal scans, may be performed by the company’s qualified internal personnel or third parties.

11.2.b Verify that external scanning is occurring on a quarterly basis in accordance with the PCI Security Scanning Procedures, by inspecting output from the four most …

Modified p. 9

PCI DSS external vulnerability scans may apply to all merchants and service providers with Internet- facing IP addresses. Even if an entity does not offer Internet-based transactions, other services may make systems Internet accessible. Basic functions such as ~~e-mail~~ and employee Internet access will result in the Internet-accessibility of a company’s network. Such seemingly insignificant paths to and from the Internet can provide unprotected pathways into scan customer systems and potentially expose cardholder data if not properly controlled.

PCI DSS external vulnerability scans may apply to all merchants and service providers with Internet- facing IP addresses. Even if an entity does not offer Internet-based transactions, other services may make systems Internet accessible. Basic functions such as Email and employee Internet access will result in the Internet-accessibility of a company’s network. Such seemingly insignificant paths to and from the Internet can provide unprotected pathways into scan customer systems and potentially expose cardholder data if not properly controlled.

Modified p. 9

Note: To be considered compliant with the external ~~vulnerability-scanning~~ requirement of PCI DSS Requirement ~~11.2,~~ the scan customer infrastructure must be tested and shown to be compliant, in accordance with this document.

Note: To be considered compliant with the external vulnerability scanning requirement of PCI DSS Requirement 11.2.2, the scan customer infrastructure must be tested and shown to be compliant, in accordance with this document.

Modified p. 9

Compliance with the external ~~vulnerability-scanning~~ requirement only represents compliance with PCI DSS Requirement ~~11.2,~~ and does not represent or indicate compliance with any other PCI DSS requirement.

Compliance with the external vulnerability scanning requirement only represents compliance with PCI DSS Requirement 11.2.2, and does not represent or indicate compliance with any other PCI DSS requirement.

Modified p. 9 → 10

PCI DSS Requirement Testing Procedures 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). Note: ~~Quarterly external vulnerability~~ scans must be ~~performed by an Approved Scanning Vendor (ASV) qualified by~~ PCI ~~SSC. Scans conducted~~ after ~~network changes may be performed by~~ the ~~company’s internal staff.~~

PCI DSS Requirement Testing Procedures 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verifies 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring …

Removed p. 10

4. The scanning vendor submits the solution for testing to PCI SSC via the ASV Portal. a. The scanning vendor uses this portal to create the solution for testing. (PCI SSC provides instructions for the portal with Step 3 above.)

Modified p. 10 → 11

3. Security ~~testing~~ of the company’s scanning solution For more information about qualifying the company and the company’s employees (Steps 1 and 2 above), ~~please~~ refer to the Validation Requirements for Approved Scanning Vendors (ASVs) located at ~~www.pcisecuritystandards.org.~~ After completing the qualification process for the scanning company and employees responsible for scanning services, and each year thereafter, as outlined in the Validation Requirements for Approved Scanning Vendors (ASVs) found at ~~www.pcisecuritystandards.org,~~ the company’s scanning solution is thoroughly tested in an …

3. Security Testing of the company’s scanning solution For more information about qualifying the company and the company’s employees (Steps 1 and 2 above), refer to the Validation Requirements for Approved Scanning Vendors (ASVs) located at the Council’s website. After completing the qualification process for the scanning company and employees responsible for scanning services, and each year thereafter, as outlined in the Validation Requirements for Approved Scanning Vendors (ASVs) found at the Council’s website, the company’s scanning solution is thoroughly …

Modified p. 10 → 11

2. The scanning vendor notifies PCI SSC at asv@pcisecuritystandards.org that the ~~ASV company~~ is ready to be tested.

2. The scanning vendor notifies PCI SSC at asv@pcisecuritystandards.org that the scanning vendor is ready to be tested.

Modified p. 10 → 11

3. The PCI SSC notifies the scanning vendor to schedule the ~~test.~~

3. The PCI SSC notifies the scanning vendor to schedule the test, and provides the scanning vendor with instructions for the ASV Portal.

Modified p. 10 → 11

5. Once the ~~scanning solution~~ is received by PCI SSC via the ~~portal,~~ PCI SSC will assign the scanning vendor to one of the ASV Validation Labs.

5. Once the submission is received by PCI SSC via the ASV Portal, PCI SSC will assign the scanning vendor to one of the ASV Validation Labs.

Modified p. 10 → 11

6. Once assigned to an ASV Validation Lab, the scanning vendor will receive notification directly from the ~~lab~~ with the next steps in the process for scheduling the ~~scan.~~

6. Once assigned to an ASV Validation Lab, the scanning vendor will receive notification directly from the ASV Validation Lab with the next steps in the process for scheduling the test.

Modified p. 10 → 11

Note: Scanning Vendor Testing via the ASV Test Bed is an annual ~~process.~~

Note: Scanning Vendor Testing via the ASV Test Bed is an annual requirement.

Modified p. 11 → 12

Category Allowed Changes Vulnerability Coverage Addition of new vulnerability signatures Improvements to the reliability and accuracy of existing vulnerability signatures (including removing individual faulty vulnerability checks for repair) Product Maintenance Maintenance and patching of systems comprising the scan solution Minor updates to the underlying software and UI, including bug fixes Addition of capacity and fault tolerance (new scan engines, data center expansion) Fees for Scanning Vendor Testing and Approval Process Fees will be charged for the various testing stages in …

Modified p. 11 → 12

ASV Scan Scope Definition For the purpose of ASV scanning, the PCI DSS requires vulnerability scanning of all externally accessible (Internet-facing) system components owned or utilized by the scan customer that are part of the cardholder data ~~environment~~ as well as any externally facing system component that provides a path to the cardholder data environment. ~~The scan customer is ultimately responsible for defining the appropriate scope of the external vulnerability scan and must provide all Internet- facing IP Addresses and/or …~~

ASV Scan Scope Definition For the purpose of ASV scanning, the PCI DSS requires vulnerability scanning of all externally accessible (Internet-facing) system components owned or utilized by the scan customer that are part of the cardholder data environment, as well as any externally facing system component that provides a path to the cardholder data environment.

Modified p. 11 → 12

Note: ~~Per~~ the PCI DSS, “System components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that ~~part of the network that possesses~~ cardholder data or sensitive authentication data. Network components include, but are not limited to: firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, …

Note: In the context of PCI DSS, “System components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. “System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include, but are not limited to: firewalls, switches, …

Modified p. 11 → 12

Scope and Network Segmentation Scan customers ~~can~~ use segmentation to reduce the scope of the ASV scanning. In general, the following segmentation methods can be used to reduce the scope of the ASV scan:

Scope and Network Segmentation Scan customers may use segmentation to reduce the scope of the ASV scanning. In general, the following segmentation methods can be used to reduce the scope of the ASV scan:

Modified p. 11 → 12

 Provide physical segmentation between the segment handling cardholder data and other ~~segments.~~  Employ appropriate logical segmentation where traffic is prohibited between the segment or network handling cardholder data and other networks or ~~segments.~~

 Provide physical segmentation between the segment handling cardholder data and other segments  Employ appropriate logical segmentation where traffic is prohibited between the segment or network handling cardholder data and other networks or segments

Removed p. 12

For ISPs, scan customers need to coordinate with them to allow the ASV scan to be performed without interference from IDS or IPS. For more details, see the section entitled ―Perform a Scan without Interference from IDS/IPS.‖ For hosting providers and their shared hosting environments, it is common practice that a single server will host more than one website. In a shared hosting environment, the scan customer shares the server with the hosting provider’s other customers. This could lead to the merchant’s website being compromised through security weaknesses on other customers’ websites on the hosting provider’s server.

• like ―www,‖ ―mail,‖ etc.

Modified p. 12 → 13

 Domains for all web-servers  Domains for mail servers  Domains used in name-based virtual hosting  Web-server URLs to "hidden" directories that cannot be reached by crawling the website from the home page Internet Service Providers and Hosting Providers This section applies to the scan customer’s Internet service provider (ISP) or hosting provider (if used by scan customers to host their ~~website).~~

 Domains for all web-servers  Domains for mail servers  Domains used in name-based virtual hosting  Web-server URLs to "hidden" directories that cannot be reached by crawling the website from the home page  Any other public-facing domains or domain aliases Internet Service Providers and Hosting Providers This section applies to the scan customer’s Internet service provider (ISP) or hosting provider (if used by scan customers to host part or all of their CDE).

Modified p. 12 → 13

Note: If the hosting provider has all Internet-facing IP ranges AND all scan customers’ domains scanned as part of the hosting provider’s own ASV scans, and provides proof to scan customers, the domains do not have to be included in the scan customers’ ASV scans.

Note: If the hosting provider has all Internet-facing IP ranges AND all scan customers’ domains scanned as part of the hosting provider’s own ASV scans, and provides proof of passing scans to scan customers, the domains do not have to be included in the scan customers’ ASV scans.

Modified p. 12 → 13

ASVs Confirm Scope and List Additional Components Identified ~~during~~ “Discovery” ASVs must minimally perform the below actions to identify if any scoping discrepancies exist in the information provided by the customer. Information about any scoping discrepancies must be indicated on the Attestation of Scan Compliance cover sheet (see Appendix A) under heading "Number of components found by ASV but not scanned because scan customer confirmed components were out of ~~scope. "~~ This information should NOT be factored into the compliance …

ASVs Confirm Scope and List Additional Components Identified During “Discovery” ASVs must minimally perform the below actions to identify if any scoping discrepancies exist in the information provided by the customer. Information about any scoping discrepancies must be indicated on the Attestation of Scan Compliance cover sheet (see Appendix A) under heading "Number of components found by ASV but not scanned because scan customer confirmed components were out of scope.” This information should NOT be factored into the compliance status:

Modified p. 12 → 13

 Include any IP address or domain ~~that was~~ previously provided to the ASV that has been removed at the request of the customer.

 Include any IP address or domain previously provided to the ASV and still owned by the customer that has been removed at the request of the customer. o If the customer no longer owns or has custody of the IP address/domain, include that IP address or domain for at least one additional quarter after it was removed from scope or released by the customer.

Modified p. 12 → 13

 For each domain provided, perform a DNS forward lookup of common host-names

 For each domain provided, perform a DNS forward lookup of common host-names •such as “www,” “mail,” etc.

Modified p. 12 → 13

~~• that~~ were not provided by the customer.

•that were not provided by the customer.

Modified p. 13 → 14

 Match domains found during crawling to ~~user supplied~~ domains to find undocumented domains belonging to the customer.

 Match domains found during crawling to user-supplied domains to find undocumented domains belonging to the customer.

Modified p. 13 → 16

 Denial of service (DoS)  Buffer overflow exploit  Brute-force attack resulting in a password lockout  Excessive usage of available communication bandwidth  Perform ~~host discovery~~ The ASV scan solution must make a reasonable attempt to identify live systems, including live systems that do not respond to ICMP echo ~~(―ping‖)~~ requests.

 Denial of service (DoS)  Buffer overflow exploit  Brute-force attack resulting in a password lockout  Excessive usage of available communication bandwidth  Perform Host Discovery The ASV scan solution must make a reasonable attempt to identify live systems, including live systems that do not respond to ICMP echo (“ping”) requests.

Modified p. 13 → 16

 Perform ~~service discovery~~ The ASV scan solution must perform a port scan on all Transmission Control Protocol (TCP) ports. The ASV scan solution must also perform a port scan on common User Datagram Protocol (UDP) ports, including UDP ports related to the following services:

 Perform Service Discovery The ASV scan solution must perform a port scan on all Transmission Control Protocol (TCP) ports. The ASV scan solution must also perform a port scan on common User Datagram Protocol (UDP) ports, including UDP ports related to the following services:

Modified p. 13 → 16

 Authentication services such as RADIUS and Kerberos  Backdoors and remote access applications  Backup applications  Database servers  DNS (Domain Name System)  NetBIOS and CIFS  NFS (Network File System)  NTP (Network Time Protocol)  P2P (peer-to-peer) and chat applications  Routing protocols, including RIP (Routing Information Protocol)  RPC (Remote Procedure Call) and RPC endpoint mapping  SNMP (Simple Network Management Protocol) and SNMP trap  TFTP (Trivial File Transfer Protocol)  VPNs (Virtual …

Removed p. 14

 Perform a Scan without Interference from IDS/IPS In order to ensure that reliable scans can be conducted, the ASV scan solution must be allowed to perform scanning without interference from intrusion detection systems (IDSs) or intrusion prevention systems (IPSs). Such ―active‖ protection systems may react differently to an automated scanning solution than they would react to a targeted hacker attack, which could cause inaccuracies in the scan report.

Modified p. 14 → 17

“Note to customer: As you were unable to validate that the configuration of the environment behind your load balancers is synchronized, it is your responsibility to ensure that the environment is scanned as part of the internal vulnerability scans required by the PCI DSS.” (Special Notes do not cause a scan failure or supersede any established CVSS scoring.)  External Load Balancing Services: The ASV must take into account the use of load balancing services external to the scan customer’s …

Removed p. 15

If an ASV detects that an IDS/IPS has blocked or filtered a scan, then the ASV is required to fail the scan as ―inconclusive‖. All ASV scans must be validated by the ASV to ensure they have not been blocked or filtered by an IDS/IPS.

 Temporary configuration changes may need to be made by the scan customer to remove interference during a scan Due to the remote nature of external vulnerability scans and the need mentioned above to conduct a scan without interference from IDS/IPS, certain temporary configuration changes on the scan customer’s network devices must be completed to obtain a scan that accurately assesses the scan customer’s external security posture.

The changes in this section are considered temporary and are only required for the duration of the ASV scan, and only apply to external-facing IP addresses in scope for quarterly EXTERNAL vulnerability scans required by PCI DSS Requirement 11.2. We …

Modified p. 15 → 17

Note: Scan customers may use the dispute-resolution process documented in this guide if a failure ~~noted~~ is mitigated by compensating controls, etc.

Note: Scan customers may use the dispute-resolution process documented in this guide if a noted failure is mitigated by compensating controls, etc.

Modified p. 15 → 18

Firewalls & Routers Firewalls and routers, which control traffic between the company’s network and external untrusted networks (for example, the Internet), have known vulnerabilities for which patches are released periodically. Another common problem with firewalls and routers is inadequate configuration. To ensure firewalls and routers are protected against these vulnerabilities and are able to protect the network effectively, it is important to apply the patches as soon as possible.

Another common problem with firewalls and routers is inadequate configuration. To ensure firewalls and routers are protected against these vulnerabilities and are able to protect the network effectively, it is important to apply the patches as soon as possible. devices must be included.

Removed p. 16

Web servers Web servers allow Internet users to view web pages, interact with web merchants, and make online web purchases. Malicious individuals exploit vulnerabilities in these servers and their scripts to get access to internal databases that potentially store cardholder data. Because these servers are fully accessible from the public Internet, scanning for vulnerabilities is essential.

Modified p. 16 → 18

Operating Systems An operating system (OS) sits between hardware and applications. Malicious individuals exploit operating system vulnerabilities to ~~get~~ access to internal databases that potentially ~~store~~ cardholder data. New exploits are discovered routinely for ~~OSs~~ and security patches are released for these flaws. To protect operating systems against these exploits and vulnerabilities, it is important to apply vendor patches as soon as possible.

Operating Systems An operating system (OS) sits between hardware and applications. Malicious individuals exploit operating system vulnerabilities to gain access to applications and internal databases that potentially store, process or manage access to cardholder data. New exploits are discovered routinely for OSs, and security patches are released for these flaws. To protect operating systems against these exploits and vulnerabilities, it is important to apply vendor patches as soon as possible.

Modified p. 16 → 18

The ASV scan solution must be able to verify that the operating system is patched for ~~these~~ known exploits. The ASV ~~scanning~~ solution must also be able to determine the version of the operating system and whether it is ~~an older~~ version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV.

The ASV scan solution must be able to verify that the operating system is patched for known exploits. The ASV scan solution must also be able to determine the version of the operating system and whether it is a version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV.

Modified p. 16 → 18

Database Servers Database servers store and manage access to cardholder data. Malicious individuals exploit vulnerabilities in these servers to ~~get~~ access to cardholder data. New vulnerabilities and exploits are discovered routinely for databases, and security patches are released for these flaws. To protect against these exploits and vulnerabilities, it is important to apply the patches as soon as possible.

Database Servers Database servers store and manage access to cardholder data. Malicious individuals exploit vulnerabilities in these servers to gain access to cardholder data. New vulnerabilities and exploits are discovered routinely for databases, and security patches are released for these flaws. To protect against these exploits and vulnerabilities, it is important to apply the patches as soon as possible.

Modified p. 16 → 18

The ASV scanning solution must be able to test for all known vulnerabilities and configuration issues on web servers. New exploits are routinely discovered in web server products. The ASV scanning solution must be able to detect and report known exploits. Browsing of directories on a web server is not a good practice. The ASV scanning solution must be able to scan the website and verify that directory browsing is not possible on the server. Positive identification of directory browsing …

The ASV scanning solution must be able to test for all known vulnerabilities and configuration issues on web servers. New exploits are routinely discovered in web server products. The ASV scanning solution must be able to detect and report known vulnerabilities.

Modified p. 17 → 19

Application ~~server~~ Application servers act as the interface between the web server and ~~the~~ back-end ~~databases and legacy systems.~~ For example, when cardholders share account numbers with merchants or service providers, the application server provides the functionality to transport data in and out of the secured network. Malicious individuals exploit vulnerabilities in these servers and their scripts to ~~get~~ access to internal databases that potentially ~~store credit card~~ data. Some website configurations do not include application servers; the web server …

Application Server Application servers act as the interface between the web server and other systems, such as back-end databases. For example, when cardholders share account numbers with merchants or service providers, the application server provides the functionality to transport data in and out of the secured network. Malicious individuals exploit vulnerabilities in these servers and their scripts to gain access to applications or internal databases that potentially store, process or manage access to cardholder data. Some website configurations do not …

Modified p. 17 → 19

The ASV ~~scanning~~ solution must be able to detect the presence of an application ~~server~~ and/or web application servers and detect ~~any~~ known ~~vulnerability~~ and configuration issues.

The ASV scan solution must be able to detect the presence of application servers and/or web application servers and detect known vulnerabilities and configuration issues.

Modified p. 17 → 19

The ASV scan solution must be able to detect commonly found scripts such as common gateway interface (CGI) scripts, ~~e-commerce~~ related scripts (for example, shopping carts and CRM scripts), ASPs, PHPs, etc. and detect any known vulnerabilities.

The ASV scan solution must be able to detect commonly found scripts such as common gateway interface (CGI) scripts, e- commerce related scripts (for example, shopping carts and CRM scripts), ASPs, PHPs, etc. and detect any known vulnerabilities.

Modified p. 17 → 19

Built-in Accounts Built-in, or default accounts and ~~passwords~~ are commonly used by hardware and software vendors to allow the customer ~~their first~~ access to the product. These accounts may have no password or have passwords assigned by the vendor. These default accounts and passwords are well known in hacker communities and their continued presence leaves systems highly vulnerable to attack. These accounts should be assigned strong passwords or should be disabled if not needed. Note: PCI DSS Requirement 2.1 stipulates …

Built-in Accounts Built-in, or default accounts and passwords, are commonly used by hardware and software vendors to allow the customer initial access to the product. These accounts may have no password or have passwords assigned by the vendor. These default accounts and passwords are well known in hacker communities and their continued presence leaves systems highly vulnerable to attack. These accounts should be assigned strong passwords or should be disabled if not needed. Note: PCI DSS Requirement 2.1 stipulates that …

Modified p. 17 → 19

For testing and reporting on built-in or default accounts in routers, firewalls, operating systems, web servers, database servers, applications, ~~POS~~ systems, or other components, the ASV scan solution, must do the following:

For testing and reporting on built-in or default accounts in routers, firewalls, operating systems, web servers, database servers, applications, point-of-sale (POS) systems, or other components, the ASV scan solution, must do the following:

Modified p. 17 → 19

 Detect the presence of built-in or default accounts and passwords, not by using brute-force or dictionary attacks, but rather by concentrating on known ~~built-in~~ or default accounts and passwords. Any such vulnerability must be marked as an automatic failure by the ASV.  Report on services that are available without authentication (e.g., without usernames or passwords).

 Detect the presence of built-in or default accounts and passwords, not by using brute-force or dictionary attacks, but rather by concentrating on known built- in or default accounts and passwords. Any such vulnerability must be marked as an automatic failure by the ASV.  Report on services that are available without authentication (e.g., without usernames or passwords).

Modified p. 17 → 19

DNS Servers DNS servers ~~resolve~~ Internet ~~addresses~~ by ~~translating~~ domain names ~~into~~ IP ~~addresses.~~ Merchants or service providers may use their own DNS server or may use a DNS service provided by their ISP. If DNS servers are vulnerable, malicious individuals can masquerade as a merchant’s or service provider’s web page and collect cardholder data.

DNS Servers DNS servers are used to locate resources on the Internet by resolving domain names to their respective IP address. Merchants or service providers may use their own DNS server or may use a DNS service provided by their ISP. If DNS servers are vulnerable, malicious individuals can masquerade as •or redirect traffic from

•a merchant’s or service provider’s web page and collect cardholder data.

Removed p. 18

Web Applications Web applications reside on application servers or web application servers (see above), and interface with the back-end databases and legacy systems. For example, when cardholders share account numbers with merchants, the web application may take the cardholder data from a customer to process and complete the transaction, and store the transactions results and cardholder data in a database, all as part of the customer’s online purchase. Malicious individuals frequently exploit application vulnerabilities to gain access to internal databases that potentially store cardholder data.

Modified p. 18 → 20

~~The ASV scan solution must be able to detect via automated or manual means, the following application vulnerabilities and configuration issues:~~  Unvalidated parameters that lead to SQL injection attacks (which must be marked as an automatic failure)  Cross-site scripting (XSS) flaws (which must be marked as an automatic failure)  Directory traversal vulnerabilities (which must be marked as an automatic failure)  HTTP response splitting/header injection (which must be marked as an automatic failure)  Information leakage, including:

 Unvalidated parameters that lead to SQL injection attacks (which must be marked as an automatic failure)  Cross-site scripting (XSS) flaws (which must be marked as an automatic failure)  Directory traversal vulnerabilities (which must be marked as an automatic failure)  HTTP response splitting/header injection (which must be marked as an automatic failure)  Information leakage, including:

Modified p. 18 → 20

 Detailed application error messages  Backup script files (for ~~example~~ home.asp.bak, index.jsp.old, etc.)  Include file source code disclosure  Insecure HTTP methods enabled  WebDAV or FrontPage extensions enabled  Default web server files  Testing and diagnostics pages (for ~~example~~ phpinfo.html, test-cgi, etc.) Other Applications Other applications, such as those for streaming media, RSS ~~Feeds,~~ proxy servers, media content, etc., are exploited by malicious individuals to gain access to cardholder data that may be processed or accessed …

 Detailed application error messages  Backup script files (for example, home.asp.bak, index.jsp.old, etc.)  Include file source code disclosure  Insecure HTTP methods enabled  WebDAV or FrontPage extensions enabled  Default web server files  Testing and diagnostics pages (for example, phpinfo.html, test-cgi, etc.) Other Applications Other applications, such as those for streaming media, RSS feeds, proxy servers, media content, etc., are exploited by malicious individuals to gain access to cardholder data that may be processed or accessed …

Modified p. 18 → 20

Backdoors A backdoor is a malicious software application that is ~~often~~ commonly known in hacker communities. This malicious software should be identified and eliminated.

Backdoors A backdoor is a malicious software application that is commonly known in hacker communities. This malicious software should be identified and eliminated.

Modified p. 19 → 21

Remote Access Often remote access software is visible to the Internet and not established securely. Sometimes the presence of this software is not needed for business purposes or may not be known to the scan customer. In some cases, these tools are used by software vendors or ~~resellers, integrators~~ to provide support for payment applications.

Remote Access Often remote access software is visible to the Internet and not established securely. Sometimes the presence of this software is not needed for business purposes or may not be known to the scan customer. In some cases, these tools are used by software vendors or resellers/integrators to provide support for payment applications. Without strong authentication and authorization controls, remote access software increases risk to the cardholder data environment by allowing unauthorized individuals easy access into a scan customer’s …

Modified p. 19 → 21

The ASV scan solution must be able to detect the presence of remote access software and detect any known vulnerability or configuration issues. Remote access software includes, but is not limited to: VPN (IPSec, PPTP, SSL), pcAnywhere, VNC, Microsoft Terminal Server, remote web-based administration, ~~ssh,~~ Telnet. In addition to reporting any identified vulnerability or configuration issues in the remote access software, the ASV scan solution must note the presence of remote access software with the following Special Note:

The ASV scan solution must be able to detect the presence of remote access software and detect any known vulnerability or configuration issues. Remote access software includes, but is not limited to: VPN (IPSec, PPTP, SSL), pcAnywhere, VNC, Microsoft Terminal Server, remote web-based administration, SSH, and Telnet. In addition to reporting any identified vulnerability or configuration issues in the remote access software, the ASV scan solution must note the presence of remote access software with the following Special Note:

Removed p. 20

The designation of each severity level must allow for an easy comparison between levels. Therefore, a severity ranking that is easy to understand must be presented, with High Severity, Medium Severity, Low Severity.

2. The National Vulnerability Database (NVD), which is maintained by the National Institute of Standards and Technology (NIST). The NVD contains details of known vulnerabilities based on the Common Vulnerabilities and Exposures (CVE) dictionary. The NVD has adopted the CVSS and publishes CVSS Base Scores for each vulnerability. ASVs should use the CVSS scores whenever they are available.

Modified p. 20 → 22

 “Note to scan customer: Due to increased risk to the cardholder data environment when a point-of-sale system is visible on the Internet, ~~please~~ 1) confirm that this system needs to be visible on the Internet, that the system is implemented securely, and that original default passwords have been changed to complex passwords, or 2) confirm that the system has been reconfigured and is no longer visible to the Internet. ~~Please consult~~ your ASV if you have questions about this …

 “Note to scan customer: Due to increased risk to the cardholder data environment when a point-of-sale system is visible on the Internet, 1) confirm that this system needs to be visible on the Internet, that the system is implemented securely, and that original default passwords have been changed to complex passwords, or 2) confirm that the system has been reconfigured and is no longer visible to the Internet. Consult your ASV if you have questions about this Special Note.” …

Modified p. 20 → 22

Vulnerability Categorization To assist customers in prioritizing the solution or ~~mitigation of~~ identified issues, ASVs must assign a severity level to each identified vulnerability or ~~misconfiguration.~~

Vulnerability Categorization To assist customers in prioritizing the solution or mitigating identified issues, ASVs must assign a severity level to each identified vulnerability or misconfiguration, as defined in Table 2 in the next page.

Modified p. 20 → 22

With a few exceptions (see the Compliance ~~Determination-Overall~~ and by Component section below for details), any vulnerability with a CVSS ~~Base Score~~ of 4.0 or higher will result in a non-compliant scan, and all such vulnerabilities must be remediated by the scan customer. To assist customers in prioritizing the solution or ~~mitigation of~~ identified issues, ASVs must assign a severity level to each identified vulnerability or misconfiguration.

With a few exceptions (see the Compliance Determination•Overall and by Component section below for details), any vulnerability with a CVSS base score of 4.0 or higher will result in a non-compliant scan, and all such vulnerabilities must be remediated by the scan customer. To assist customers in prioritizing the solution or mitigating identified issues, ASVs must assign a severity level to each identified vulnerability or misconfiguration.

Removed p. 21

Overall Compliance Determination For a customer to be considered compliant, all components within the customer’s cardholder data environment must be compliant. The cardholder data environment includes the entire network infrastructure unless physical or logical network segmentation is in place.

Modified p. 21 → 23

Table 2: Vulnerability Severity Levels Based on the NVD and CVSS Scoring CVSS Score Scan Results Guidance 7.0 through High Severity Fail To achieve a passing scan, these vulnerabilities must be corrected and the ~~environment~~ must be ~~re-scanned~~ after the corrections (with a report that shows a passing scan). Organizations should take a ~~risk-based~~ approach to correct these types of vulnerabilities, starting with the most critical ~~ones~~ (rated 10.0), then those rated 9, followed by those rated 8, 7, etc., …

Table 2: Vulnerability Severity Levels Based on the NVD and CVSS Scoring CVSS Score Scan Results Guidance 7.0 through High Severity Fail To achieve a passing scan, these vulnerabilities must be corrected and the affected systems must be re- scanned after the corrections (with a report that shows a passing scan). Organizations should take a risk- based approach to correct these types of vulnerabilities, starting with the most critical (rated 10.0), then those rated 9, followed by those rated 8, …

Modified p. 21 → 23

Compliance Determination

• Overall and by Component Reports must indicate compliance determination at two levels: by component and for the overall customer level.

Compliance Determination

• Overall and by Component Reports must indicate compliance determination at two levels: by component level, and for the overall customer level.

Modified p. 21 → 23

The following statements provide the necessary guidance to ASVs to determine compliance at component level and customer level.

The following statements provide the necessary guidance to ASVs to determine compliance at component level and customer level. Overall Compliance Determination For a scan customer to be considered compliant, all components within the customer’s cardholder data environment must be compliant. The cardholder data environment includes the entire network infrastructure unless physical or logical network segmentation is in place.

Modified p. 21 → 23

If the NVD does not have a CVSS base score for a vulnerability identified in the component, the scoring of that vulnerability should be performed in accordance with ~~―Exceptions~~ to Scoring Vulnerabilities with the ~~NVD‖~~ below.

If the NVD does not have a CVSS base score for a vulnerability identified in the component, the scoring of that vulnerability should be performed in accordance with “Exceptions to Scoring Vulnerabilities with the NVD” below.

Modified p. 21 → 23

Exceptions to Scoring Vulnerabilities with the NVD There are four exceptions to the NVD scoring guidance described above in the preceding section titled Component Compliance Determination. Only these exceptions may supersede any established CVSS scores. Document these exceptions under ~~―Exceptions,~~ False Positives, or Compensating ~~Controls‖~~ as noted in Appendix B: ASV Scan Report Executive Summary.

Exceptions to Scoring Vulnerabilities with the NVD There are four exceptions to the NVD scoring guidance described above in the preceding section titled Component Compliance Determination. Only these exceptions may supersede any established CVSS scores. Document these exceptions under “Exceptions, False Positives, or Compensating Controls” as noted in Appendix B: ASV Scan Report Executive Summary.

Modified p. 22 → 24

3. The vulnerability is purely a denial-of-service (DoS) vulnerability. In the case of ~~denial-of- service~~ vulnerabilities (e.g., where the vulnerability has both a CVSS Confidentiality Impact of ~~―None‖~~ and a CVSS Integrity Impact of ~~―None‖),~~ the vulnerability must not be ranked as a failure.

3. The vulnerability is purely a denial-of-service (DoS) vulnerability. In the case of DoS vulnerabilities (e.g., where the vulnerability has both a CVSS Confidentiality Impact of “None” and a CVSS Integrity Impact of “None”), the vulnerability must not be ranked as a failure.

Modified p. 22 → 24

4. The vulnerability violates PCI DSS and may be a higher risk than noted in ~~NVD:~~ The ASV scan solution must score the presence of certain types of vulnerabilities as automatic failures due to the risk of the vulnerability and the possibility to exploit the cardholder data environment. See Table 1: Required Components for PCI DSS Vulnerability Scanning for examples of vulnerabilities which are considered violations of the PCI DSS and must therefore be scored as automatic failures.

4. The vulnerability violates PCI DSS and may be a higher risk than noted in NVD. The ASV scan solution must score the presence of certain types of vulnerabilities as automatic failures due to the risk of the vulnerability and the possibility to exploit the cardholder data environment. See Table 1: Required Components for PCI DSS Vulnerability Scanning for examples of vulnerabilities which are considered violations of the PCI DSS and must therefore be scored as automatic failures.

Modified p. 22 → 24

Scan Reporting ASVs produce an informative report based on the results of the network ~~scan.~~

Scan Reporting ASVs produce an informative report based on the results of the network scan:

Modified p. 22 → 24

 Appendices A, and B are required templates for the Attestation of Scan Compliance cover sheet and the ASV Scan Executive Summary.

 Appendices A and B are required templates for the Attestation of Scan Compliance cover sheet and the ASV Scan Executive Summary.

Modified p. 22 → 24

 Appendix C for the ASV Scan Vulnerability Details provides a suggested format, but ASVs may use a different ~~format,~~ as long as the format is easy to read, contains all of the required elements, and has been approved by the PCI SSC as part of the ASV validation process.

 Appendix C for the ASV Scan Vulnerability Details provides a suggested format, but ASVs may use a different format as long as the format is easy to read, contains all of the required elements, and has been approved by the PCI SSC as part of the ASV validation process.

Modified p. 22 → 24

Table 2 above describes how an ASV scan solution categorizes vulnerabilities and demonstrates the types of vulnerabilities and risks that are considered ~~high-level.~~

Table 2 above describes how an ASV scan solution categorizes vulnerabilities and demonstrates the types of vulnerabilities and risks that are considered high or medium severity.

Modified p. 22 → 24

 The scan customer’s declared business need for the software  The scan customer’s declaration that the software is implemented with strong security controls as well as the details that comprise those controls  Any action taken by the scan customer, including removal, to secure the ~~software~~ as well as the details that comprise those controls The use of a Special Note does not result in an automatic failure on the scan ~~report~~ nor does it override any CVSS scoring.

 The scan customer’s declared business need for the software  The scan customer’s declaration that the software is implemented with strong security controls , as well as the details that comprise those controls  Any action taken by the scan customer, including removal, to secure the software, as well as the details that comprise those controls The use of a Special Note does not result in an automatic failure on the scan report, nor does it override any CVSS …

Modified p. 22 → 24

1. Attestation of Scan Compliance cover ~~sheet- an~~ overall summary for the entire customer infrastructure, and the required cover sheet for the reports below. See Appendix A: ASV Scan Report Attestation of Scan Compliance for template and required format.

1. Attestation of Scan Compliance cover sheet•an overall summary for the entire customer infrastructure, and the required cover sheet for the reports below. See Appendix A: ASV Scan Report Attestation of Scan Compliance for template and required format.

Modified p. 22 → 24

2. ASV Scan Executive ~~Summary - a~~ component summary for each scanned component. See Appendix B: ASV Scan Report Executive Summary for template and required format.

2. ASV Scan Executive Summary•a component summary for each scanned component. See Appendix B: ASV Scan Report Executive Summary for template and required format.

Modified p. 23 → 25

ASVs must produce reports that meet all the reporting requirements in this document. This section contains a summary of the three sections of the ASV Scan Report. For details about the reporting requirements, ~~please~~ see Appendices A, B, and C.

ASVs must produce reports that meet all the reporting requirements in this document. This section contains a summary of the three sections of the ASV Scan Report. For details about the reporting requirements, see Appendices A, B, and C.

Modified p. 23 → 25

 ASV must generate this Attestation of Scan Compliance according to the template at Appendix A

• ASV Scan Report Attestation of Scan Compliance. See ~~―Report Customization‖~~ to the right.

 ASV must generate this Attestation of Scan Compliance according to the template at Appendix A: ASV Scan Report Attestation of Scan Compliance. See “Report Customization” to the right.

Modified p. 23 → 25

 Attestation of Scan Compliance content, ~~please~~ see Appendix A: ASV Scan Report Attestation of Scan Compliance for required template.

 Attestation of Scan Compliance content, see Appendix A: ASV Scan Report Attestation of Scan Compliance for required template.

Modified p. 23 → 25

 Scan customer contact information  Scan customer assertions per the Scan Finalization section  ASV contact information (individual name or corporate contact)  Overall scan results (pass or fail) without IP address or vulnerability details  Number of components scanned, number of identified failing vulnerabilities, and number of components identified but not scanned due to scan customer’s out-of- scope assertion  Dates for scan completion and scan expiration  ASV company assertion per Scan Finalization ~~section.~~

 Scan customer contact information  Scan customer assertions per the Scan Finalization section  ASV contact information (individual name or corporate contact)  Overall scan results (pass or fail) without IP address or vulnerability details  Number of components scanned, number of identified failing vulnerabilities, and number of components identified but not scanned due to scan customer’s out-of- scope assertion  Dates for scan completion and scan expiration  ASV company assertion per Scan Finalization section

Modified p. 23 → 25

2. ASV Scan Report Executive Summary This lists vulnerabilities by components (IP address) and shows whether each IP address scanned received a passing score and met the scan validation requirement. This section shows all vulnerabilities noted for a given IP address, with one line per vulnerability noted. For example, an IP address will show one line when only one vulnerability is noted, but will have five lines if five vulnerabilities are noted, etc.

2. ASV Scan Report Executive Summary This section lists vulnerabilities by components (IP address) and shows whether each IP address scanned received a passing score and met the scan validation requirement. This section shows all vulnerabilities noted for a given IP address, with one line per vulnerability noted. For example, an IP address will show one line when only one vulnerability is noted, but will have five lines if five vulnerabilities are noted, etc.

Modified p. 24 → 26

Executive Summary content

• ~~Please see~~ Appendix B: ASV Scan Report Executive Summary for required template, which includes the ~~following.~~

Executive Summary content

• See Appendix B: ASV Scan Report Executive Summary for required template, which includes the following:

Modified p. 24 → 26

 Scan customer and ASV names ~~(Full~~ contact information does not need to be included here since it is included on the Attestation of Scan Compliance cover page.)  Dates for scan completion and scan expiration  Vulnerability summary for each IP address, including severity, CVSS score, compliance status for that IP address (pass/fail), and any exceptions, false positives, or compensating controls noted by ASV  A consolidated solution/correction plan, provided as a separate line item for each IP address

 Scan customer and ASV names (full contact information does not need to be included here since it is included on the Attestation of Scan Compliance cover page.)  Dates for scan completion and scan expiration  Vulnerability summary for each IP address, including severity, CVSS score, compliance status for that IP address (pass/fail), and any exceptions, false positives, or compensating controls noted by ASV  A consolidated solution/correction plan, provided as a separate line item for each IP address

Modified p. 24 → 26

3. ASV Scan Report Vulnerability Details This is the overall summary of vulnerabilities that shows compliance status (pass/fail) and details for all vulnerabilities detected. This section of the report is in vulnerability order, showing each affected IP address as a separate line item for a given vulnerability.

3. ASV Scan Report Vulnerability Details This section is the overall summary of vulnerabilities that shows compliance status (pass/fail) and details for all vulnerabilities detected. This section of the report is in vulnerability order, showing each affected IP address as a separate line item for a given vulnerability.

Modified p. 24 → 26

Vulnerability Details generation and submission  The ASV Scan Vulnerability Details must be submitted with the Attestation of Scan Compliance cover sheet, and can optionally be submitted with the ASV Scan Executive Summary at acquirer’s or payment brand’s discretion  For this report section, the ASV can optionally generate it according to the template at Appendix C

• Scan Report Vulnerability Details. If the template is not used, however, all information specified in Appendix C must be clearly included.

Vulnerability Details generation and submission  The ASV Scan Vulnerability Details must be submitted with the Attestation of Scan Compliance cover sheet, and can optionally be submitted with the ASV Scan Executive Summary at acquirer’s or payment brand’s discretion.

Modified p. 24 → 26

Note: Use of the template at Appendix C: ASV Scan Report Vulnerability Details is OPTIONAL but all elements from Appendix C must be included in the ASV’s report Vulnerability Detail content

• ~~Please see~~ Appendix C: ASV Scan Report Vulnerability Details for optional template.

Note: Use of the template at Appendix C: ASV Scan Report Vulnerability Details is OPTIONAL but all elements from Appendix C must be included in the ASV’s report Vulnerability Detail content

• See Appendix C: ASV Scan Report Vulnerability Details for optional template.

Modified p. 24 → 26

 Customer and ASV names ~~(Full~~ contact information does not need to be included here since it is included on the Attestation of Scan Compliance cover sheet.)  For each vulnerability, all affected IP addresses are listed, including severity and scoring, industry reference numbers, vulnerability compliance status (pass/fail), detailed explanation, and other information about the vulnerability that the ASV may add.

 Customer and ASV names (full contact information does not need to be included here since it is included on the Attestation of Scan Compliance cover sheet.)  For each vulnerability, all affected IP addresses are listed, including severity and scoring, industry reference numbers, vulnerability compliance status (pass/fail), detailed explanation, and other information about the vulnerability that the ASV may add.

Modified p. 24 → 26

Scan Customer and ASV Attestations Before completion of the scan results and generation of the scan report, each ASV must provide a mechanism within their ASV Scan Solution to capture the following attestations from both the scan customer and the ASV. These attestations (once completed by the scan customer and ASV) are included on the Attestation of Scan Compliance cover sheet.

Scan Customer and ASV Attestations Before completion of the scan results and generation of the scan report, each ASV must provide a mechanism within their ASV Scan Solution to capture the following attestations from both the scan customer and the ASV. These attestations (once completed by the scan customer and ASV) are included on the Attestation of Scan Compliance cover sheet. ASVs may not use the same Attestion of Scan Compliance for multiple quarters. The scan customer attestation must be …

Modified p. 24 → 26

 Scan customer is responsible for proper scoping of the scans and has included all components in the scan that should be included in the PCI DSS scope.  Scan customer has implemented network segmentation if any components are excluded from PCI DSS scope.  Scan customer has provided accurate and complete evidence to support any disputes over scan results. ~~ Acknowledgement that scan results only indicate whether scanned systems are compliant with the external vulnerability scan requirement (PCI DSS …~~

 Scan customer is responsible for proper scoping of the scans and has included all components in the scan that should be included in the PCI DSS scope.  Scan customer has implemented network segmentation if any components are excluded from PCI DSS scope.  Scan customer has provided accurate and complete evidence to support any disputes over scan results.

Modified p. 25 → 27

 ASV Program Guide and other supplemental guidance from PCI SSC was followed for this ~~scan~~  ASV’s practices for this scan included an automated or manual Quality Assurance process that:

 ASV Program Guide and other supplemental guidance from PCI SSC was followed for this scan.  ASV’s practices for this scan included an automated or manual Quality Assurance process that:

Modified p. 25 → 27

 Reviews scan customer scoping practices  Detects incorrect, incomplete, or corrupt scans  Detects obvious inconsistencies in findings  Reviews and corrects connectivity issues between scanner and scan customer  ASV reviewed this scan report and exceptions Scan Customer Attestation Mandatory text (Scan customer name) attests that: This scan includes all components which should be in scope for PCI DSS, any component considered out-of-scope for this scan is properly segmented from my cardholder data environment, and any evidence submitted …

Scan Customer Attestation Mandatory text (Scan customer name) attests that: This scan includes all components which should be in scope for PCI DSS, any component considered out-of-scope for this scan is properly segmented from my cardholder data environment, and any evidence submitted to the ASV to resolve scan exceptions is accurate and complete. (Scan customer name) also acknowledges the following: 1) proper scoping of this external scan is my responsibility, and 2) this scan result only indicates whether or not …

Modified p. 25 → 28

~~ Scan customer corrects noted failing vulnerabilities~~  Scan customer may seek help from the ASV or other security professional as needed to determine proper corrective actions.

 Scan customer may seek help from the ASV or other security professional as needed to determine proper corrective actions.  Scan customer contacts ASV to initiate another scan.

Modified p. 26 → 28

 For failing scans, scan customer repeats this ~~―Resolving~~ Failing ~~Scans‖~~ section.

 For failing scans, scan customer repeats this “Resolving Failing Scans” section.

Modified p. 26 → 29

 The ASV is REQUIRED to investigate false positives with a CVSS Base score at or above 4.0 (failing score). ~~ The ASV is ENCOURAGED to investigate false positives with a CVSS Base score at or below 3.9 (passing score).~~

 The ASV is REQUIRED to investigate false positives with a CVSS Base score at or above 4.0 (failing score).

Modified p. 26 → 29

 Provide written supporting evidence for disputed findings. Scan customers should submit ~~system~~ generated evidence such as screen dumps, configuration files, system versions, file versions, list of installed patches, etc. Such ~~system generated~~ evidence must be accompanied by a description of when, where and how they were obtained (chain of evidence).  Attest within the ASV scan solution that the evidence is accurate and complete.

 Provide written supporting evidence for disputed findings. Scan customers should submit system- generated evidence such as screen dumps, configuration files, system versions, file versions, list of installed patches, etc. Such system-generated evidence must be accompanied by a description of when, where and how they were obtained (chain of evidence).  Attest within the ASV scan solution that the evidence is accurate and complete.

Modified p. 26 → 29

 If remote validation is not possible, then the ASV must determine if the submitted written evidence is sufficient proof to resolve the dispute. This includes assessing the ~~Customer's~~ evidence for relevance and accuracy. If evidence is sufficient, the ASV updates the scan ~~report.~~  Document the ASV’s conclusion and either clearly describe, reference or include the supporting evidence in the report under ~~―Exceptions,~~ False Positives, or Compensating ~~Controls‖~~ as noted in Appendix B: ASV Scan Report Executive Summary.  …

 If remote validation is not possible, then the ASV must determine if the submitted written evidence is sufficient proof to resolve the dispute. This includes assessing the scan customer's evidence for relevance and accuracy. If evidence is sufficient, the ASV updates the scan report accordingly.  Document the ASV’s conclusion and either clearly describe, reference or include the supporting evidence in the report under “Exceptions, False Positives, or Compensating Controls” as noted in Appendix B: ASV Scan Report Executive …

Modified p. 27 → 30

 The ASV’s conclusion should be documented in the scanning report under ~~―Exceptions,~~ False Positives, or Compensating ~~Controls‖~~ as noted in Appendix B: ASV Scan Report Executive Summary.

 The ASV’s conclusion should be documented in the scanning report under “Exceptions, False Positives, or Compensating Controls” as noted in Appendix B: ASV Scan Report Executive Summary.

Modified p. 27 → 30

 The customer must not be permitted to edit the ~~scanning~~ report.

 The scan customer must not be permitted to edit the scan report.

Modified p. 27 → 30

Report Delivery and Integrity The ASV ~~solutions~~ final scan report should be submitted or delivered in a secure fashion ensuring report integrity with clear demonstration that controls are in place to prevent interception or alteration to the final reports. Scan customers ~~should~~ not have the ability to change or alter the final report.

Report Delivery and Integrity The ASV solution’s final scan report should be submitted or delivered in a secure fashion ensuring report integrity with clear demonstration that controls are in place to prevent interception or alteration to the final reports. Scan customers must not have the ability to change or alter the final report.

Modified p. 28 → 31

The ASV will include in the report contact information for inquiries relating to integrity of the specific report. This can EITHER be a generic corporate contact OR a named individual per the ASV's discretion. In either case, whoever is responsible for responding to inquiries, whether ~~it is~~ a generic contact or a named individual, ~~that contact~~ must have been qualified by PCI SSC as per section 3.2 "ASV Staff - Skills and Experience" in the document PCI DSS Validation Requirements …

The ASV will include in the report contact information for inquiries relating to integrity of the specific report. This can EITHER be a generic corporate contact OR a named individual per the ASV's discretion. In either case, whoever is responsible for responding to inquiries, whether a generic contact or a named individual, must have been qualified by PCI SSC as per section 3.2 "ASV Staff - Skills and Experience" in the document PCI DSS Validation Requirements for Approved Scanning Vendors …

Modified p. 28 → 31

 The QA process may be performed automatically or manually. Automatic QA processes should include random sampling of reports for manual review on a regular basis.  The QA process must detect potential connectivity issues between the ~~scanner~~ and the target network, including those resulting from link failure or active security measures such as those implemented in IPS.  The QA process should perform basic sanity tests to detect obvious inconsistencies in findings.

 The QA process may be performed automatically or manually. Automatic QA processes should include random sampling of reports for manual review on a regular basis.  The QA process must detect potential connectivity issues between the scan solution and the target network, including those resulting from link failure or active security measures such as those implemented in active protection systems such as IPS.  The QA process should perform basic sanity tests to detect obvious inconsistencies in findings.

Modified p. 28 → 31

The PCI SSC has determined that the discovery of specific and severe violations of ASV agreements or ~~Validation Requirements~~ may warrant immediate remediation or possibly revocation of the ASV. These violations include, but are not limited to:

The PCI SSC has determined that the discovery of specific and severe violations of ASV agreements or validation requirements may warrant immediate remediation or possibly revocation of the ASV. These violations include, but are not limited to:

Modified p. 28 → 31

 Intentionally deciding not to scan relevant IP addresses  Operating a different solution or methodology than what was validated during the ASV test  Failure to renew specified insurance requirements  Unqualified professionals operating the scan and/or reviewing results  Misrepresentation of the PCI DSS to sell products or services  Removing systems or applications ~~out of~~ scope that directly impact cardholder data  Independent forensic investigations performed by reputable, qualified experts ~~conclusively~~ demonstrating that cardholder data was compromised, …

 Intentionally deciding not to scan relevant IP addresses  Operating a different solution or methodology than what was validated during the ASV test  Failure to renew specified insurance requirements  Unqualified professionals operating the scan solution and/or reviewing results  Failure to complete annual validation to the ASV Test Bed  Misrepresentation of the PCI DSS to sell products or services  Removing systems or applications from scope that directly impact cardholder data  Independent forensic investigations performed …

Modified p. 29 → 32

Revocation When ASV status is revoked, the vendor is removed from the PCI SSC List of ASVs. Once an ASV status is revoked, the vendor cannot perform scans to help merchants and service providers achieve compliance with PCI DSS Requirement ~~11.2.~~ The vendor can appeal the revocation of ASV status but must meet requirements as documented in the Validation Requirements for ASVs and supporting documents.

Revocation When ASV status is revoked, the vendor is removed from the PCI SSC List of ASVs. Once an ASV status is revoked, the vendor cannot perform scans to help merchants and service providers achieve compliance with PCI DSS Requirement 11.2.2. The vendor can appeal the revocation of ASV status but must meet requirements as documented in the Validation Requirements for ASVs and supporting documents.

Modified p. 29 → 32

After a revocation period of at least six months, a vendor can resubmit to become an ASV according to the process and fees detailed in the ~~―Scanning~~ Vendor Testing and Approval ~~Process‖~~ section.

After a revocation period of at least six months, a vendor can resubmit to become an ASV according to the process and fees detailed in the “Scanning Vendor Testing and Approval Process” section.

Modified p. 29 → 32

PCI SSC reserves the right to remove a vendor from the list of Approved Scanning ~~Vendors,~~ when it is clear that the ASV is not performing their services in accordance with the Validation Requirements for ASVs or with the requirements in this Approved Scanning Vendors Program Guide. If PCI SSC intends to remove a vendor from the list of Approved Scanning Vendors, PCI SSC will notify the vendor in writing.

PCI SSC reserves the right to remove a vendor from the list of Approved Scanning Vendors when it is clear that the ASV is not performing their services in accordance with the Validation Requirements for ASVs or with the requirements in this Approved Scanning Vendors Program Guide. If PCI SSC intends to remove a vendor from the list of Approved Scanning Vendors, PCI SSC will notify the vendor in writing.

Modified p. 31 → 34

Scan Customer Attestation (Customer name) attests on (date) that this scan includes all components* which should be in scope for PCI DSS, any component considered out-of-scope for this scan is properly segmented from my cardholder data environment, and any evidence submitted to the ASV to resolve scan ~~exceptions~~ is accurate and complete. (Scan customer name) also acknowledges the following: 1) proper scoping of this external scan is my responsibility, and 2) this scan result only indicates whether or not my …

Scan Customer Attestation (Customer name) attests on (date) that this scan includes all components* which should be in scope for PCI DSS, any component considered out-of-scope for this scan is properly segmented from my cardholder data environment, and any evidence submitted to the ASV to resolve scan excepti ons is accurate and complete. (Scan customer name) also acknowledges the following: 1) proper scoping of this external scan is my responsibility, and 2) this scan result only indicates whether or not …

Modified p. 31 → 34

ASV Attestation This scan and report was prepared and conducted by (ASV name) under certificate number (insert number), according to internal processes that meet PCI DSS requirement 11.2 and the PCI DSS ASV Program Guide. (ASV name) attests that the PCI DSS scan process was followed, including a manual or automated Quality Assurance process with customer boarding and scoping practices, review of results for anomalies, and review and correction of 1) disputed or incomplete results, 2) false positives, and 3) …

ASV Attestation This scan and report was prepared and conducted by (ASV name) under certificate number (insert number), according to internal processes that meet PCI DSS requirement 11.2 and the PCI DSS ASV Program Guide.

Modified p. 32 → 35

The ~~―Attestation~~ of Scan ~~Compliance‖~~ from Appendix A must be included as the cover sheet for the ASV Scan Report Executive Summary. The ASV Scan Report Vulnerability Details from Appendix C can accompany this report as well.

The “Attestation of Scan Compliance” from Appendix A must be included as the cover sheet for the ASV Scan Report Executive Summary. The ASV Scan Report Vulnerability Details from Appendix C can accompany this report as well.

Modified p. 32 → 35

Part 2. Component Compliance Summary IP Address: Pass Fail IP Address: Pass Fail IP Address: Pass Fail IP Address: Pass Fail IP Address: Pass Fail Part 3a. Vulnerabilities Noted for each IP Address IP Address Vulnerabilities Noted per IP ~~address1~~ CVSS ~~Score3~~ Compliance Exceptions, False Positives, or Compensating Controls Noted by the ASV for this Vulnerability Pass / Fail Consolidated Solution/Correction Plan for above IP Address:

Part 2. Component Compliance Summary IP Address: Pass Fail IP Address: Pass Fail IP Address: Pass Fail IP Address: Pass Fail IP Address: Pass Fail Part 3a. Vulnerabilities Noted for each IP Address IP Address Vulnerabilities Noted per IP address2 CVSS Score4 Compliance Exceptions, False Positives, or Compensating Controls Noted by the ASV for this Vulnerability Pass / Fail Consolidated Solution/Correction Plan for above IP Address:

Modified p. 33 → 36

Part 3b. Special Notes by IP Address IP Address ~~Note7~~ Item Noted (remote access software, POS software, etc.) Scan customer’s declaration that software is implemented securely (see next column if not implemented securely) Scan customer’s description of actions taken to either: 1) remove the software or 2) implement security controls to secure the software 4 Include CVE identifier and title and rank in descending order by CVSS score. 5 High, Medium or Low Severity in accordance with Table 2 6 …

Part 3b. Special Notes by IP Address IP Address Note8 Item Noted (remote access software, POS software, etc.) Scan customer’s declaration that software is implemented securely (see next column if not implemented securely) Scan customer’s description of actions taken to either: 1) remove the software or 2) implement security controls to secure the software 5 Include CVE identifier and title and rank in descending order by CVSS score. 6 High, Medium or Low Severity in accordance with Table 2 7 …

Modified p. 34 → 37

The ~~―Attestation~~ of Scan ~~Compliance‖~~ from Appendix A must be included as the cover sheet for the ASV Scan Report Vulnerability Details if submitted without the ASV Scan Report Executive Summary. The ASV Scan Report Executive Summary from Appendix B can accompany this report as well.

The “Attestation of Scan Compliance” from Appendix A must be included as the cover sheet for the ASV Scan Report Vulnerability Details if submitted without the ASV Scan Report Executive Summary. The ASV Scan Report Executive Summary from Appendix B can accompany this report as well.

Document Comparison

Content Changes