Document Diff - PCI Watch

Added p. 2

Updated to align with PCI DSS v3.2 and other PCI SSC program documents and provide clarification in response to feedback from ASV, merchant/service provider and acquirer communities.

Added new scan components:

• Anonymous (non-authenticated) key-exchange protocols

• Embedded links from out-of-scope domains

• Virtualization Components Added guidance for aggregating multiple failing scan reports to total one passing scan report.

Increased scan-report retention period from two years to three years to align with ASV Qualification Requirements evidence retention period.

Updated reporting requirements and templates:

• Clarification of passing scan report being the initial scan or the result of multiple failing scans in Appendix A: Attestation of Scan Compliance.

• Allow ASVs to omit Low severity/non-compliance impacting vulnerabilities from Appendix B: ASV Scan Report Summary.

• Require ASVs to report all detected/open ports and services in Appendix C: Scan Report Vulnerability Details.

Added Appendix D: ASV Scan Report Summary Example.

Removed Appendix E: Remote Access Security Features.

Added p. 4

Requirement 11.2.2 of the PCI DSS requires quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) approved by PCI SSC. The PCI DSS provides the foundation for this and all other PCI DSS- related requirements and procedures.

• Payment Card Industry (PCI) Qualification Requirements for Approved Scanning Vendors (ASV)

Added p. 4

PCI SSC updates PCI DSS requirements in accordance with a standards lifecycle management process. The ASV Program Guide may be updated when threats evolve, or as necessary to reflect changes to the PCI DSS.

The final published version of this document supersedes ASV Program Guide v3.0.

ASVs may begin using this document and the included report templates immediately, and must implement the requirements set forth in this document effective 1 July, 2018.

Added p. 5

• Scan customers benefit from a broad selection of ASVs and gain assurance that if they use ASV scan solutions, those solutions have been validated by an ASV Validation Lab as satisfying applicable PCI DSS requirements.

• Consumers gain assurance that merchants and service providers are receiving vulnerability scans from validated ASV scan solutions.

• Acquiring banks and Participating Payment Brands receive consistent reports to help demonstrate merchant and service provider compliance with applicable PCI DSS requirements.

For more information regarding PCI SSC, see the Website.

Added p. 5

PCI DSS Requirement 11.2.2 requires that external vulnerability scanning be performed at least quarterly by an ASV qualified by PCI SSC. The ASV Program Guide sets forth a standard set of:

• Technical requirements for ASV scan solutions

• Reporting requirements for ASV scan solutions

• Processes for determining scan customers’ compliance with PCI DSS external vulnerability scanning requirements using an ASV scan solution

• ASV testing and approval processes

• Quality assurance processes for ASVs

• Scan requirements and guidance for scan customers

Note: The ASV prepares scan reports in accordance with Section 7, “Scan Reporting,” and submits those reports to the scan customer. The scan customer then submits those reports to its acquirers or Participating Payment Brands as directed by the Participating Payment Brands.

ASV Agreement The then-current version of (or successor document to) the PCI ASV Compliance Test Agreement, the current version of which is attached as Appendix A to the ASV Qualification Requirements.

ASV Program …

Added p. 7

NVD (National Vulnerability Database) The U.S. government repository of standards-based vulnerability management data. NVD includes databases of security checklists, security- related software flaws, misconfigurations, product names, and impact metrics.

Participating Payment Brand Defined in the ASV Agreement.

PCI DSS Acronym for “Payment Card Industry Data Security Standard.” Refers to the then-current version of (or successor documents to) the Payment Card Industry (PCI) Data Security Standard and Security Assessment Procedures, as from time to time amended and made available on the Website.

QSA Acronym for “Qualified Security Assessor.” QSAs are companies qualified by PCI SSC to perform PCI DSS on-site assessments. Refer to the Payment Card Industry (PCI) Qualification Requirements for Qualified Security Assessors (QSA) for details about requirements for “QSA Companies” and “QSA Employees.” Scan customer A merchant or service provider that is required to undergo a quarterly external vulnerability scan via an ASV for ASV Program purposes.

Scan interference Interference, including but not …

Added p. 8

• ASVs, QSAs, and PCI SSC

•participate more directly in the PCI DSS assessment process. Stakeholders that are not directly involved with the assessment process should nonetheless be aware of the overall process to facilitate associated business decisions.

The following describes the high-level roles and responsibilities of the stakeholders in the payment community as they relate to the PCI DSS and ASV Program.

• Fines or penalties for non-compliance 4.2 PCI SSC

PCI SSC maintains various payment card industry standards, supporting programs, and related documentation in accordance with a standards lifecycle management process. In relation to the ASV Program, PCI SSC:

• Maintains the ASV Program Guide and ASV Qualification Requirements (including the ASV Agreement)

• Provides training for ASV Companies and ASV Employees

• Evaluates ASV Company and ASV Employee qualifications to perform external vulnerability scans in accordance with PCI DSS and ASV Program requirements

• Maintains the List of Approved Scanning Vendors on the Website

• Maintains …

Added p. 9

• Scanning all IP address ranges, domains, components, etc. provided by the scan customer to identify active components and services.

• Consulting with the scan customer to determine whether components found, but not provided by the scan customer, should be included in the scope of the scan.

• Providing a determination as to whether the scan customer’s components have met the scanning requirements.

• Providing adequate documentation within the scan report to demonstrate the compliance or non-compliance of the scan customer’s components with the scanning requirements.

• Submitting (to the scan customer) the ASV Scan Report Attestation of Scan Compliance cover sheet (an “Attestation of Scan Compliance”) and the scan report in accordance with the instructions of the scan customer’s acquirer(s) and/or Participating Payment Brand(s).

• Including required scan customer and ASV Company attestations in the scan report in accordance with this document and applicable ASV Program requirements.

• Retaining scan reports and related work papers …

Added p. 9

ASV Validation Labs are responsible for the following:

• Configuring and maintaining their ASV testing laboratory environment and Test Bed in accordance with PCI SSC coordination and instructions.

• Assessing and scoring scan test reports submitted by scanning vendors upon completion of the scan test for the vendor’s candidate or approved ASV scan solution.

• Conducting debriefing sessions with the scanning vendor to provide the test results and feedback on the scan solution’s performance.

Added p. 9

• Performing PCI DSS Assessments in accordance with the PCI DSS, which includes confirming that PCI DSS Requirement 11.2.2 is “in place” and that the ASV and ASV scan solution were both on the list of Approved Scanning Vendors on the date when the respective scans were performed.

• Providing an opinion about whether the assessed entity meets applicable PCI DSS requirements in accordance with QSA Program requirements.

• Providing adequate documentation within the Report on Compliance (ROC) to demonstrate the assessed entity’s compliance with the PCI DSS.

• Submitting the ROC and the Attestation of Validation (signed by the QSA and in some cases, the assessed entity).

• Maintaining an internal quality assurance process for its QSA program-related efforts.

It is the QSA’s responsibility to attest to the entity’s compliance with PCI DSS. PCI SSC does not approve ROCs from a technical perspective, but performs QA reviews on ROCs to help ensure that the …

Added p. 11

• Providing sufficient documentation to the ASV to fully enable the ASV’s evaluation of any compensating controls implemented or maintained by the scan customer. See Section 7.8, “Addressing Vulnerabilities with Compensating Controls.”

• Reviewing the scan report and correcting any noted vulnerabilities that result in a non- compliant scan.

• Arranging with the ASV to re-scan any non-compliant systems to verify that all “High” and “Medium” severity vulnerabilities have been resolved, to obtain a passing quarterly scan. See Table 2 of Section 6, “Vulnerability Severity Levels Based on the NVD and CVSS.”

• Submitting the completed ASV scan report to the scan customer’s acquirer(s) and/or Participating Payment Brand(s), as directed by the Participating Payment Brands.

• Providing feedback on ASV performance in accordance with the ASV Feedback Form (available on the Website).

Note: Fees and dates for the ASV’s scanning services are typically established between the ASV and the scan customer. The scan customer typically …

Added p. 12

Vulnerability scanning companies interested in providing vulnerability scanning services for ASV Program purposes must comply with the requirements set forth in this document as well as the ASV Qualification Requirements and related ASV Program requirements, and must successfully complete the PCI SSC Security Scanning Vendor Testing and Approval Process. See Section 5.3, “ASV Testing and Approval Process.”

• Reporting/remediation

Added p. 13

Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.

For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed if the assessor verifies 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring quarterly scanning, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). For subsequent years after the initial PCI DSS review, four quarters of passing scans must have occurred..

Added p. 14

PCI DSS Requirements Testing Procedures 11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.

• For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.

• For internal scans, all “high risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

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

Additionally, the Scan Customer Attestation of Scan Compliance (ASV Program Guide Appendix A) must be completed by the scan customer and may not be outsourced to a third party. If the scan customer receives assistance producing or submitting dispute-supporting evidence to the ASV, the scan customer is still required to review the evidence prior to submittal, and attest to its completeness and accuracy prior to the ASV generating the final report.

Added p. 15

The specific version(s) of the ASV’s full ASV scan solution(s), as tested, approved, and listed in accordance with the ASV Program as part of PCI SSC’s scanning vendor testing and approval process, is the ONLY version of the scan solution that the ASV is approved to use to perform external vulnerability scans in accordance with PCI DSS Requirement 11.2.2 for ASV Program purposes. While significant modifications to the tested and approved ASV scan solution (without undergoing another ASV Validation Lab test) are prohibited, minor modifications that enhance or improve the quality of the scan solution are acceptable. These minor improvements (which do not require another ASV Validation Lab test) fall into categories of vulnerability coverage and product maintenance:

Note: ASVs may have more than one validated scan solution listed on the Website.

PCI SSC charges fees for the various testing stages for candidate and/or approved ASV scan solutions, in accordance with the …

Added p. 17

• Provide physical segmentation between the system components that store, process, or transmit cardholder data and systems that do not.

2. The hosting provider can undergo ASV scans as part of each of its customers’ ASV scans. In either case, it is the responsibility of the scan customer to ensure that their hosted environment receives a passing score from an ASV scan.

Added p. 18

• Identify any IP addresses found during MX record DNS lookup.

• Intrusion prevention systems (IPS) that drop non-malicious packets based on previous behavior from originating IP address (for example, blocking all traffic from the originating IP address for a period of time because it detected one or more systems being scanned from the same IP address)

• Web application firewalls (WAF) that block all traffic from an IP address based on the number of events exceeding a defined threshold (for example, more than three requests to a login page per second)

Added p. 19

• Next generation firewalls (NGF) that shun/block IP address ranges because an attack was perceived based on previous network traffic patterns

• Quality of Service (QoS) devices that limit certain traffic based on traffic volume anomalies (for example, blocking DNS traffic because DNS traffic exceeded a defined threshold)

• Spam filters that blacklist a sending IP address based on certain previous SMTP commands originating from that address Such 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.

• Intrusion detection systems (IDS) that log events, track context or have a multifaceted approach to detecting attacks, but action is limited to alerting (there is no intervention).

• Web application firewalls (WAF) that detect and block SQL injections, but let non-attack traffic from the same source pass.

• Intrusion prevention systems (IPS) that drop all occurrences of a certain attack, …

Added p. 23

The ASV must scan all network devices such as firewalls and external routers. If a firewall or router is used to establish a demilitarized zone (DMZ), these devices must be included.

Added p. 24

Positive identification of directory browsing must be reported and disclosed with the following Special Note:

Malicious individuals exploit vulnerabilities in these servers and scripts to gain access to applications or internal databases that potentially store, process or manage access to cardholder data.

Website configurations that do not include application servers (i.e., the web server itself is configured to act as an application server) are called web application servers.

These accounts may have no password or have passwords assigned by the vendor. These default accounts and passwords are often published by the vendors, 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 or removed if not needed.

Note: PCI DSS Requirement 2.1 stipulates that vendor-supplied defaults, including vendor accounts and passwords, are changed and disabled or removed before installing a system on a network.

• Report on services …

Added p. 27

Wireless Access Points Wireless networks, if not securely configured, allow malicious individuals an easy way to eavesdrop on or tamper with network traffic, capture data and passwords, and gain access to a network from remote and inconspicuous locations, such as a parking lot or adjacent room or building. Wireless vulnerabilities and security misconfigurations must be identified and corrected.

Backdoors/ Malware A backdoor is malicious software that allows an unauthorized user to bypass normal authentication while remaining undetected. Malicious software (malware) must be identified and eliminated.

Per PCI DSS, strong cryptography and security protocols must be deployed•see the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms (available on the Website) for additional details on “Strong Cryptography.” Also refer to industry best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 rev 1 and SP 800-57, OWASP, etc.)

Note: SSL and early TLS are not considered strong cryptography and …

Added p. 30

Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.

If the ASV scan solution detects insecure services or industry-deprecated protocols, the following must be included in the Special Notes section of the scan report:

Note to scan customer: Insecure services and industry-deprecated protocols can lead to information disclosure or potential exploit. Due to increased risk to the cardholder data environment, 1) justify the business need for this service and confirm additional controls are in place to secure use of the service, or 2) confirm that it is disabled. Consult your ASV if you have questions about this Special Note.

Unknown services Ports, protocols and services that cannot be remotely identified by the ASV may indicate a less common but safe protocol or an in-house developed application using a proprietary protocol, but they may also …

Added p. 32

Organizations should take a risk-based approach to correct these types of vulnerabilities, starting with the most critical, until all vulnerabilities rated 4.0 through 10.0 are corrected.

In this case, the ASV 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 that are considered violations of the PCI DSS and must therefore be scored as automatic failures.

Note: When re-ranking a vulnerability’s risk assignment, ASVs are encouraged to utilize industry- recognized resources (such as the CVSS v3.0 Calculator), rather than arbitrarily or subjectively assigning numbers to vulnerabilities.

Added p. 34

2. ASV Scan Report Summary

3. ASV Scan Vulnerability Details The Attestation of Scan Compliance and the ASV Scan Report Summary must follow the format in the templates provided in Appendices A and B of this ASV Program Guide.

• All of the data elements and supporting text will exactly match that provided in the templates;

• The required information will be presented in an order that exactly matches the provided templates;

• The presentation of information is similar to that which is provided in the templates; and

• All variables (for example, "Customer Name" or "Date”) and all fields and check boxes will be completed by the ASV.

Further detail on the requirements of each section is set out below:

• without the ASV Scan Report Summary or ASV Scan Vulnerability Details

• Page orientation of the report (landscape or portrait)

• Addition of the ASV’s logo

• Addition of ASV-specific clauses as long as the added language does …

Added p. 35

Note: Unless otherwise specified by the scan customer or the acquirer or Participating Payment Brand, the ASV may choose to omit vulnerabilities that do not impact PCI DSS compliance (for example, Low severity vulnerabilities) from the Summary. However, all compliance-affecting vulnerabilities (for example, automatic failures, Medium and High severity vulnerabilities)

•including 1) all failing vulnerabilities that have been fixed, rescanned and validated as passing upon rescan, and 2) failing vulnerabilities that have been changed to “pass” via exceptions or after remediation/rescan

•must always be listed in the Summary.

Consolidated solution/correction plan, provided as a separate line item for each component o The ASV must provide a high-level description of the remediation that needs to be performed on a particular system•for example, "Apply available patches" or "Update to a vendor-supported OS version." ASVs are permitted to include pointers/links to specific remediation information and guidance that may exist in either a) an appendix to the …

Added p. 41

The ASV must include contact information in each report for inquiries relating to integrity of the specific report. This can be either a generic corporate contact or a named individual per the ASV's discretion. In either case, the individual responsible for responding to inquiries, whether identified as a generic contact or a named individual, must (when so identified and responding) be qualified by PCI SSC per Section 3.2, "ASV Employee

• Skills and Experience," of the ASV Qualification Requirements.

• The QA process may be performed automatically or manually. Automatic QA processes must include random sampling of reports for manual review on a regular basis.

• The QA process must perform basic sanity tests to detect obvious inconsistencies in findings.

Added p. 41

PCI SSC has determined that the occurrence of various “Violations” (defined in the ASV Agreement and further described in the ASV Qualification Requirements) may warrant (and is grounds for) immediate remediation or revocation of ASV qualification. The list of Violations includes, but is not limited to:

• Intentionally deciding not to scan relevant components.

• Operating a different scan solution or methodology than what was validated during the ASV lab scan test.

• Failure to maintain (and provide evidence to PCI SSC) specified insurance requirements.

• Unqualified professionals operating the ASV scan solution and/or reviewing results.

• Failure to successfully complete annual validation against the ASV Validation Labs Test Bed.

• Misrepresentation of the PCI DSS or supporting documentation to sell products or services, to mislead scan customers or potential clients, to discredit a competitor, or for any other purpose.

• Removing components or applications from scope that may impact cardholder data.

• Independent forensic investigations performed by …

Added p. 42

The ASV qualification of an ASV that remains in remediation without substantial and demonstrable progress on its remediation plan for more than 90 days past its requalification date will be automatically revoked.

See the ASV Qualification Requirements for additional details on Remediation.

Added p. 42

After a revocation period of at least six (6) months, a vendor can reapply to become an ASV according to the process and fees detailed in Sections 5.3, “ASV Testing and Approval Process” and 5.4 “Fees for ASV Testing and Approval Process” of this document, and the ASV Qualification Requirements.

PCI SSC reserves the right to remove a vendor from the list of Approved Scanning Vendors if the ASV is not performing services in accordance with the ASV Qualification Requirements or ASV Program Guide or otherwise is not in compliance with applicable ASV Program requirements. A revoked ASV will be notified by PCI SSC in accordance with the ASV Agreement.

See the ASV Qualification Requirements for additional details on Revocation.

Added p. 43

Figure 1: Overview of ASV Scan Processes 1 Scan customers are ultimately responsible for defining the scan scope, though they may seek expertise from QSAs and guidance from ASVs. If an account data compromise occurs via a component not included in the scan, the scan customer is accountable. 2 To reduce the scope of the scan, network segmentation must be in place to isolate system components that store, process, or transmit cardholder data from systems that do not. ASV still reports these components as not scanned due to scan customer attestation that they’re out of scope. 3 Active protection systems: Systems that block, filter, drop, or modify network packets in response to scan traffic that is allowed through the firewall•for example, intrusion-prevention systems. 4 Component: IP address, domain, FQDN, web server domain, etc.

Added p. 44

A.2 Approved Scanning Vendor Information Contact Name:

City: State/Province: ZIP/postal code:

A.3 Scan Status Date scan completed: Scan expiration date (90 days from date scan completed):

Compliance status: Pass Fail Scan report type: Full scan Partial scan or rescan Number of unique in-scope components4 scanned:

Number of components found by ASV but not scanned because scan customer confirmed they were out of scope:

Added p. 46

Date scan was completed: Scan expiration date:

Part 2. Component 4 Compliance Summary Component: Pass Fail Component: Pass Fail Component: Pass Fail Part 3a. Vulnerabilities Noted for each Component 4 ASV may choose to omit vulnerabilities that do not impact compliance from this section, however, failing vulnerabilities that have been changed to “pass” via exceptions or after remediation / rescan must always be listed.

Component Vulnerabilities Noted per Component 5 CVSS Score 7 Compliance Status Exceptions, False Positives, or Compensating Controls 8 (Noted by the ASV for this vulnerability) Pass Fail Consolidated Solution/Correction Plan for above Component:

Consolidated Solution/Correction Plan for above Component:

Added p. 47

Component Vulnerabilities Noted per Component 5 CVSS Score 7 Compliance Status Exceptions, False Positives, or Compensating Controls 8 (Noted by the ASV for this vulnerability) Pass Fail Consolidated Solution/Correction Plan for above Component:

Added p. 47

Part 3b. Special Notes by Component 4 Component Special Note 9 Item Noted 10 Scan customer’s description of action taken and declaration that software is either implemented securely or removed Part 3c. Special Notes

• Full Text Part 4a. Scan Scope Submitted by Scan Customer for Discovery IP Addresses/ranges/subnets, domains, URLs, etc.

Part 4b. Scan Customer Designated “In-Scope” Components (Scanned) IP Addresses/ranges/subnets, domains, URLs, etc.

Added p. 48

Part 4c. Scan Customer Designated “Out-of-Scope” Components (Not Scanned) IP Addresses/ranges/subnets, domains, URLs, etc.

Added p. 49

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 Report Summary at acquirer’s or Participating Payment Brand’s discretion. See Section 7.1, “Generating, Reading, and Interpreting Scan Reports,” for more details.

Part 2. Vulnerability Details Component 4 Detected Open Ports, Services/ Protocols11 Vulnerability Severity CVE Number CVSS Score 7 Compliance Status Details Pass Fail 11 The ASV must list all detected open ports and, where possible, the service/protocol identified by the ASV.

Added p. 50

Part 1. Scan Information Scan Customer Company: ABC Industries ASV Company: AwesomeScan Date scan was completed: 1 March, 2018 Scan expiration date: 30 May, 2018 Part 2. Component 4 Compliance Summary Component: w.x.y.116 Pass Fail Component: w.x.y.117, www. company1.com Pass Fail Component: w.x.y.118, www.company1.net Pass Fail Component: w.x.y.119, vpn.company1.com Pass Fail Component: w.x.y.119, remote.company1.com Pass Fail Component: w.x.y.120, mail.company1.com Pass Fail Part 3a. Vulnerabilities Noted for each Component 4 ASV may choose to omit vulnerabilities that do not impact compliance from this section, however, failing vulnerabilities that have been changed to “pass” via exceptions or after remediation / rescan must always be listed.

Added p. 51

Component Vulnerabilities Noted per Component 5 CVSS Score 7 Compliance Status Exceptions, False Positives, or Compensating Controls 8 (Noted by the ASV for this vulnerability) Pass Fail Consolidated Solution/Correction Plan for above IP Address: All openssh versions shipped in Red Hat Enterprise Linux 5 include the patch for this issue. This issue was fixed in Red Hat Enterprise Linux 4 via: https://rhn.redhat.com/errata/RHSA-2005-527.html Red Hat Enterprise Linux 3 is affected by this issue. The Red Hat Security Response Team has rated this issue as having low security impact. https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-1483. Recommend applying vendor patch or upgrading version. Automatic Failure: Open access to databases from the Internet. (Vulnerability is not included in the NVD). Restrict access to databases from the Internet. ASV recommends updating software to latest supported version; Apply all current vendor-issued security patches; Configure system security state (for example, per Center for Internet Security (CIS) Red Hat Enterprise Linux 6 Benchmark …

Added p. 52

Part 4a. Scope Submitted by Scan Customer for Discovery IP Addresses/ranges/subnets, domains, URLs, etc.

IP Range: w.x.y.116

• w.x.y.128 Domain: company1.com Domain: company1.net URL: www.company1.com/payment Part 4b. Scan Customer Designated “In-Scope” Components (Scanned) IP Addresses/ranges/subnets, domains, URLs, etc. w.x.y.117, www. company1.com w.x.y.118, www.company1.net w.x.y.119, vpn.company1.com, remote.company1.com w.x.y.120, mail.company1.com Part 4c. Scan Customer Designated “Out-of-Scope” Components (Not Scanned) Requires description for each IP Address/range/subnet, domain, URL w.x.y.121, artwork.company1.com

• Scan customer attests to implementing segmentation via separate physical layer 2 switch with no connectivity to CDE. w.x.y.122 (not active)

• Scan customer attests that this IP address is not issued/assigned to any physical or virtual host. ASV confirmed it is nonresponsive. w.x.y.123 (not active)

• Scan customer attests that this IP address is not issued/assigned to any physical or virtual host. ASV confirmed it is nonresponsive. w.x.y.124 (not active)

• Scan customer attests that this IP address is not issued/assigned to any physical or virtual host. ASV …

Removed p. 4

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.

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.

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

Modified p. 4

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

The requirements in this document apply specifically to the quarterly EXTERNAL vulnerability scans required by PCI DSS Requirement 11.2.2. 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

~~The~~ following additional documents are used in conjunction with the PCI DSS:

In regard to the ASV Program, the following additional documents are used in conjunction with the PCI DSS:

Modified p. 4

 Payment Card Industry (PCI) Data Security Standard and Payment Application Data Security Standard Glossary of Terms, Abbreviations, and Acronyms ~~ Payment Card Industry (PCI) Data Security Standard ASV Validation Requirements~~

• Payment Card Industry (PCI) Data Security Standard and Payment Application Data Security Standard Glossary of Terms, Abbreviations, and Acronyms

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

Note: The PCI DSS provides the specific technical requirements and assessment procedures used by merchants and service providers to validate PCI DSS compliance and document the assessment. PCI DSS Requirement 11.2.2 specifically requires quarterly external vulnerability scans that must be performed by an ASV. The ASV Qualification Requirements define the requirements that must be met by an ASV in order to perform PCI DSS quarterly external vulnerability scans for ASV Program purposes.

Modified p. 4

All documents are available in electronic form on www.pcisecuritystandards.org.

All ASV Program-related documents are available in electronic form on www.pcisecuritystandards.org.

Modified p. 4

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

PCI SSC reserves the right to change, amend, or withdraw the PCI DSS and/or ASV Requirements at any time, and works closely with its community of Participating Organizations regarding such changes.

Removed p. 5

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:

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

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

Internal scan Refers to a vulnerability scan conducted …

Modified p. 5 → 6

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

Term Meaning ASV Acronym for "Approved Scanning Vendor." Refers to a company qualified by PCI SSC for ASV Program purposes to conduct external vulnerability scanning services in accordance with PCI DSS Requirement 11.2.2.

Modified p. 5 → 6

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.

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

Modified p. 5 → 7

~~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 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).

Modified p. 5 → 7

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

PCI SSC Acronym for “Payment Card Industry Security Standards Council” that refers to PCI Security Standards Council, LLC.

Removed p. 6

Both NVD and CVE are sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security.

 Customers benefit from a broad selection of ASVs.

 Customers are assured that they will be using ASV scan solutions that have met the required level of validation.

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 Requirement 11.2.2 requires that external vulnerability scanning be performed quarterly by an ASV qualified by PCI SSC. The ASV Program Guide reflects an alignment of …

Modified p. 6 → 5

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

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

Modified p. 6 → 5

All stakeholders in the payments value chain benefit from the ~~aligned~~ requirements:

All stakeholders in the payments value chain can benefit from the standardized requirements:

Removed p. 7

PCI SSC maintains the PCI DSS and related PCI standards, including the PA-DSS. In relation to the ASV program, PCI SSC:

 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 of security services and tools (“ASV scan solution”) to validate adherence to the external scanning requirement of PCI DSS Requirement 11.2.2. The scanning vendor’s ASV scan solution is tested and approved by PCI SSC before an ASV is added to PCI SSC’s List of Approved Scanning Vendors.

Modified p. 7 → 8

 Requirements, mandates, or dates for PCI DSS compliance ~~ Fines or penalties for non-compliance~~

• Requirements, mandates, or dates for PCI DSS compliance

Modified p. 7 → 8

 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:~~

• Performing external vulnerability scans in accordance with PCI DSS Requirement 11.2.2, this document and other supplemental guidance published by PCI SSC.

Removed p. 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)  Maintaining an internal quality assurance process for QSA efforts It is the QSA’s responsibility to state whether the entity has achieved compliance with PCI DSS. PCI SSC does not approve ROCs from a technical perspective, but performs QA reviews on the ROCs to ensure that the documentation of test procedures performed is sufficient to demonstrate compliance.

 Maintaining compliance with the PCI DSS at all times, which includes properly maintaining the …

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

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 → 12

PCI DSS external vulnerability scans are conducted over the Internet by an ASV, as a remote service that requires scanning from a source external to the scan customer’s network and does not require onsite presence to execute. PCI DSS external vulnerability scans are an indispensable tool to be used in conjunction with a vulnerability management program. ~~Scans~~ help identify vulnerabilities and misconfigurations of websites, applications, and information technology infrastructures with ~~Internet- facing Internet protocol (IP)~~ addresses.

PCI DSS external vulnerability scans are conducted over the Internet by an ASV, as a remote service that requires scanning from a source external to the scan customer’s network and does not require onsite presence to execute. PCI DSS external vulnerability scans are an indispensable tool to be used in conjunction with a vulnerability management program. Vulnerability scans help identify vulnerabilities and misconfigurations of websites, applications, and other information technology infrastructures with Internet-facing IP addresses.

Modified p. 9 → 12

Vulnerability scan results provide valuable information that supports efficient patch management and other security measures that improve protection against Internet attacks.

Vulnerability scan results provide valuable information that supports efficient patch management and other security measures that help improve protection against Internet attacks.

Modified p. 9 → 12

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.

PCI DSS external vulnerability scans may apply to any merchant or service provider with external/ Internet-facing components. Even if an entity does not offer Internet-based transactions, other services may make systems Internet accessible. Basic functions such as email and user 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 → 12

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

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 and applicable ASV Program requirements. Compliance with this 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 or component.

Modified p. 9 → 12

Refer to ~~the flowchart at~~ Figure 1 for an overview of the major phases of the scanning process for both scan customers and ASVs, and for a summary of the flow of activities during these phases. The main phases of the scanning process consist of:

Refer to Figure 1 for an overview of the major phases of the scanning process for both scan customers and ASVs, and for a summary of the flow of activities during these phases. The main phases of the scanning process consist of:

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

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

 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).

Modified p. 10 → 13

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 …

PCI DSS Requirements 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).

Modified p. 10 → 13

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.b Review the scan reports and verify that all “high risk” vulnerabilities are addressed and the scan process includes rescans to verify that the “high risk” vulnerabilities (as defined in PCI DSS Requirement 6.1) are resolved.

Modified p. 10 → 13

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

11.2.1.c Interview personnel to verify 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).

Modified p. 10 → 14

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.a Review output from the four most recent quarters of external vulnerability scans and verify that four quarterly external vulnerability scans occurred in the most recent 12-month period.

Modified p. 10 → 14

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.b Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met (for example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures).

Modified p. 10 → 14

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

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

Modified p. 10 → 14

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.a Inspect and correlate change control documentation and scan reports to verify that system components subject to any significant change were scanned.

Removed p. 11

All fees and dates related to the ASV’s scanning services are typically negotiated between the ASV and the scan customer. The scan customer either pays all fees directly to the ASV, or may pay fees to the scan customer’s acquirer or other aggregating entity (if the acquirer or other aggregating entity has a contract with the ASV on behalf of a group of merchants).

Scanning Vendor Testing and Approval Process The ASV qualification process consists of three parts, which are conducted in the following order:

1. Qualification of the company

2. Qualification of the company’s employees responsible for scanning services

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, …

Removed p. 12

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, 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, proxy, network time protocol (NTP), and Domain Name System (DNS). Applications include all purchased and custom applications, including internal and external (for example,Internet) applications.

Note: The scan customer attests to their scan scope in the ASV Scan Tool prior to the ASV finalizing the scan report.

Modified p. 12 → 15

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 …~~

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 or fault tolerance (scan engines, data center expansion, etc.) For more information about qualifying as an ASV Company or ASV Employee, refer to the Qualification Requirements for …

Modified p. 12 → 16

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 ranges to the ASV. If an account data compromise occurs via an ~~externally facing~~ system component not included in the ~~scan,~~ the scan customer is responsible.

• Any other public-facing hosts, virtual hosts, domains or domain aliases The scan customer must define and attest to its scan scope prior to the ASV finalizing the scan report. The scan customer is ultimately responsible for defining the appropriate scope of the external vulnerability scan and must provide all Internet-facing components, IP addresses and/or ranges to the ASV. If an account data compromise occurs via an externally-facing system component not included in the scan scope, the scan customer is …

Modified p. 12 → 17

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

In general, the following segmentation methods may be used to reduce the scope of the ASV scan:

Modified p. 12 → 17

~~ 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~~

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

Removed p. 13

This includes, but is not limited to:

In either case, it is the responsibility of the scan customer to ensure that their hosted environment receives a passing score from an appropriate ASV scan.

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. 13 → 17

~~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 …~~

Scan customers must coordinate with their ISPs to allow the ASV scan to be performed without interference from active protection systems. For more details, see Section 5.6, “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.

Modified p. 13 → 17

There are two options for ASV scanning of hosting providers that host scan customer ~~infrastructures:~~

There are two options for ASV scanning of hosting providers that host scan customer infrastructures or components:

Modified p. 13 → 17

1) The hosting provider can undergo ASV scans on ~~their~~ own and provide evidence to ~~their~~ customers to demonstrate their compliant scans; ~~or, 2) The hosting provider can undergo ASV scans as part of each of their customers’ ASV scans.~~

1. The hosting provider can undergo ASV scans on its own and provide evidence to its customers to demonstrate their compliant scans; or

Modified p. 13 → 17

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.

Note: If the hosting provider has all Internet-facing IP ranges AND all scan customers’ domains, etc. 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. 13 → 18

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

• Include any IP address or domain previously provided to the ASV and still owned or used by the scan customer that has been removed at the request of the scan customer.

Modified p. 13 → 18

 For each domain provided, look up the IP address of the domain to determine if it was already provided by the customer.

• For each domain provided, look up the IP address of the domain to determine whether it was already provided by the scan customer.

Modified p. 13 → 18

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

•such as “www,” “mail,” etc.

• For each domain provided, perform DNS forward and reverse lookups of common host names

•such as “www,” “mail,” etc.

Modified p. 13 → 18

•that were not provided by the customer.

•that were not provided by the scan customer.

Removed p. 14

 Intrusion prevention systems (IPS) that drop non-malicious packets based on previous behavior from originating IP address (for example, blocking all traffic from the originating IP address for a period of time because it detected one or more systems being scanned from the same IP address)  Web application firewalls (WAF) that block all traffic from an IP address based on the number of events exceeding a defined threshold (for example, more than three requests to a login page per second)  Firewalls that shun/block an IP address upon detection of a port scan from that IP address  Next generation firewalls (NGF) that shun/block IP address ranges because an attack was perceived based on previous network traffic patterns  Quality of Service (QoS) devices that limit certain traffic based on traffic volume anomalies (for example, blocking DNS traffic because DNS traffic exceeded a defined threshold)  Spam filters that …

Modified p. 14 → 18

 Identify any ~~IPs~~ outside of scope reached via web redirects from in-scope web servers (includes all forms of redirect including: JavaScript, Meta redirect and HTTP ~~codes 30x).~~

• Identify any IP addresses outside of scope reached via web redirects from in-scope web servers (includes all forms of redirect including: JavaScript, Meta redirect and HTTP 30x codes).

Modified p. 14 → 18

 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 scan customer.

Removed p. 15

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 that accurately assesses the scan customer’s external security posture. Note that, per above, temporary configuration changes are not required for systems that consistently block attack traffic, while consistently allowing non-attack traffic to pass (even if the non-attack traffic follows directly after attack traffic).

Modified p. 15 → 19

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

If the ASV scan cannot detect vulnerabilities on Internet-facing systems because the ASV 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.

Modified p. 15 → 20

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.2. Scan customers are encouraged to work with the ASV to perform secure quarterly scans that do not unnecessarily expose the scan customer’s network

•but also do not limit the final results of the scans

•as follows:

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 components in scope for quarterly external vulnerability scans required by PCI DSS Requirement 11.2.2. Scan customers are encouraged to work with the ASV to perform secure quarterly scans that do not unnecessarily expose the scan customer’s network

•but also do not limit the final results of the ASV scans

•as follows:

Modified p. 15 → 20

 Agree on a time for the scan window ~~each quarter~~ to minimize how long changed configurations are in place.

• Agree on a time for the ASV scan window to minimize how long changed configurations are in place.

Modified p. 15 → 20

 Conduct the scan during a maintenance window under the scan customer’s standard change control processes, with full monitoring during the ASV scan.

• Conduct the ASV scan during a maintenance window under the scan customer’s standard change control processes, with full monitoring during the ASV scan.

Modified p. 15 → 20

 Configure the active protection systems to either: o Monitor and log, but not to act against, the originating IP address(es) of the ASV, or o Allow non-attack traffic to pass consistently (even if ~~it comes right after~~ attack traffic) ~~ Reapply the previous configurations as soon as the scan is complete.~~

• Configure the active protection systems to either: o Monitor and log, but not to act against, the originating IP address(es) of the ASV, or o Allow non-attack traffic to pass consistently (even if the non-attack traffic immediately follows attack traffic)

Modified p. 15 → 20

Note: The intent of these temporary configuration changes is to ensure that an active protection system, such as an IPS reacting dynamically to traffic patterns, does not interfere with the ASV scan in a manner that would provide the ASV solution with a different view of the environment than the view an attacker would have. ASV scans tend to be “noisy” as they generate a lot of traffic in a short period of time. This is generally to ensure that …

Note: The intent of these temporary configuration changes is to ensure that an active protection system, such as an IPS reacting dynamically to traffic patterns, does not interfere with the ASV scan in a manner that would provide the ASV scan solution with a different view of the environment than the view an attacker would have. ASV scans tend to be “noisy” as they generate a lot of traffic in a short period of time. This is generally to ensure …

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

Modified p. 16 → 21

 Be Non-disruptive ~~Solutions~~ must not be configured with disruptive testing methods enabled that would result in a system crash or reboot, or interfere with or change Domain Name System (DNS) servers, routing, switching, or address resolution. ~~Root-kits or other software~~ must not be installed unless part of the solution and pre-approved by the customer.

• Be Non-disruptive The ASV scan solution must not be configured with disruptive testing methods enabled that would result in a system crash or reboot, or interfere with or change Domain Name System (DNS) servers, routing, switching, or address resolution. Software (such as root kits) must not be installed unless part of the scan solution and pre-approved by the scan customer.

Modified p. 16 → 21

The following are examples of some of the tests that are not permitted:

The following are examples of some of the tests that are not permitted: o Denial of service (DoS) o Buffer overflow exploit o Brute-force attack resulting in an account lockout or password reset o Excessive usage of available communication bandwidth

Modified p. 16 → 21

~~ 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.

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

Removed p. 17

 Localized Load Balancers: The ASV must obtain documented assurance from the scan customer that the infrastructure behind the load balancer(s) is synchronized in terms of configuration.

Modified p. 17 → 22

 Have Platform Independence Customer platforms are ~~diverse. Each~~ platform has strengths and weaknesses. The ASV solution must cover all commonly used platforms.

• Have Platform Independence Customer platforms are diverse and each platform has strengths and weaknesses. The ASV scan solution must cover all commonly used platforms.

Modified p. 17 → 22

 Be Accurate In addition to confirmed vulnerabilities, ASVs must report all occurrences of vulnerabilities that have a reasonable level of identification certainty. When the presence of a vulnerability cannot be determined with certainty, the potential vulnerability must be reported as such. Potential vulnerabilities must be scored the same as confirmed vulnerabilities and must have the same effects on compliance determination.

• Be Accurate In addition to confirmed vulnerabilities, ASVs must report all occurrences of vulnerabilities that have a reasonable level of identification certainty. When the presence of a vulnerability cannot be determined with certainty, the potential vulnerability must be reported as such. Potential vulnerabilities must be scored the same as confirmed vulnerabilities and must have the same effects on compliance determination.

Modified p. 17 → 22

 Account for Load Balancers If a scan customer has deployed load balancers, the scan may only see part of the configuration beyond the load balancer. In these cases, the following applies:

• Account for Load Balancers If a scan customer has deployed load balancers, the scan may only see part of the configuration beyond the load balancer. In these cases, the following applies: o Localized Load Balancers: The ASV must obtain documented assurance from the scan customer that the infrastructure behind the load balancer(s) is synchronized in terms of configuration.

Modified p. 17 → 22

If the scan customer is unable to validate a synchronized environment behind their load balancers, the ASV must disclose the inconsistency with the following Special ~~Note~~ on the scan report:

If the scan customer is unable to validate a synchronized environment behind their load balancers, the ASV must disclose the inconsistency with the following Special Note1 on the scan report:

Modified p. 17 → 22

~~“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 …

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. o External Load Balancing Services: The ASV must take into account the use of load balancing services external to the scan customer’s environment that direct traffic globally or regionally based upon source IP address location. Depending …

Modified p. 17 → 23

Note: Scan customers may use the dispute-resolution process documented in this guide if a noted failure 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.

Modified p. 17 → 23

Scan ~~Components~~ For Scan ~~Customers For ASVs~~ Why must it be scanned? ASV ~~Scan Solution~~ must:

Scan Component For Scan Customers: Why must it be scanned? For ASVs: ASV scan solution must:

Modified p. 18 → 23

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

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.

Modified p. 18 → 23

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.

Operating Systems An operating system (OS) sits between hardware and applications. Malicious individuals exploit OS 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. 18 → 23

The ASV ~~scanning~~ solution must be able to detect open access to databases from the Internet. This configuration is a violation of PCI DSS ~~section 1.3.7,~~ and must be marked as an automatic failure by the ASV. The ASV ~~scanning~~ solution must also be able to detect and report on known database exploits and vulnerabilities.

The ASV scan solution must be able to detect open access to databases from the Internet. This configuration is a violation of PCI DSS Requirement 1.3.6, and must be marked as an automatic failure by the ASV. The ASV scan solution must also be able to detect and report on known database exploits and vulnerabilities.

Modified p. 18 → 24

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

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.

Modified p. 18 → 24

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

The ASV scan solution must be able to test for all known vulnerabilities and configuration issues on web servers.

Modified p. 18 → 24

The ASV ~~scanning~~ solution must be able to scan the website and verify that directory browsing is not possible on the server.

The ASV scan solution must also be able to scan the website and verify that directory browsing is not possible on the server.

Modified p. 19 → 24

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 …

Application Servers Application servers act as the interface between web servers and other systems, such as back-end databases. For example, when cardholders share account numbers with merchants or service providers, the application server may provide the functionality to transport data in and out of the secured network.

Modified p. 19 → 24

Common Web Scripts Common web scripts enable servers to respond to client-side requests (for example, to enable an ~~e-commerce~~ web server to respond to requests from customers’ web browsers).

Common Web Scripts Common web scripts enable servers to respond to client-side requests (for example, to enable an e- commerce web server to respond to requests from customers’ web browsers).

Modified p. 19 → 24

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. 19 → 25

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 …

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.

Modified p. 19 → 25

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:

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. 19 → 25

 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 using default passwords•for example, as published by software vendors or vulnerability reference sources. Any such vulnerability must be marked as an automatic failure by the ASV.

Modified p. 19 → 25

The ASV scan solution must be able to detect the presence of a DNS ~~server~~ and detect any known vulnerability and configuration issues, including unrestricted DNS zone transfer (which must be marked as an automatic failure by the ASV).

The ASV scan solution must be able to detect the presence of DNS servers, perform forward and reverse DNS lookups, and detect any known vulnerability and configuration issues, including unrestricted DNS zone transfer (which must be marked as an automatic failure by the ASV).

Modified p. 19 → 25

Mail Servers Mail servers typically exist in the DMZ and can be vulnerable to attacks by malicious individuals. They are a critical element to maintaining overall ~~website security.~~

Mail Servers Mail servers typically exist in the DMZ and can be vulnerable to attacks by malicious individuals. They are a critical element to maintaining overall security of the technology infrastructure.

Modified p. 19 → 25

The ASV scan solution must be able to detect the presence of a mail ~~server~~ and detect any known ~~vulnerability~~ and configuration issues.

The ASV scan solution must be able to detect the presence of mail servers and detect any known vulnerabilities and configuration issues.

Removed p. 20

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

Wireless Access Points Wireless networks introduce new information security risks to those companies that deploy them. Wireless networks, if not securely configured, allow malicious individuals an easy way to eavesdrop on traffic, capture data and passwords, and gain access to a network from, for example, a store parking lot. Wireless vulnerabilities and security misconfigurations should be identified and corrected.

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. 20 → 26

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

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.

Modified p. 20 → 26

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

The ASV scan solution must be able to detect via automated or manual means current vulnerabilities and configuration issues (for example, OWASP 2 Top 10, SANS CWE Top 25, etc.) including the following web application vulnerabilities and configuration issues:

Modified p. 20 → 26

 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 …

Other Applications Other applications, such as those for streaming media, RSS feeds, proxy servers, media content, etc. may be exploited by malicious individuals to gain access to cardholder data that may be processed or accessed by these applications.

Modified p. 20 → 26

The ASV scan solution must be able to detect the presence of other applications and to detect any known vulnerability and configuration issues.

The ASV scan solution must be able to detect and report the presence of other applications and to detect any known vulnerability and configuration issues.

Modified p. 20 → 27

Common Services Many common services present ~~by default~~ on servers have known vulnerabilities which malicious individuals can exploit to gain access to the network. These common services should either be ~~disabled~~ or patched to properly protect the systems.

Common Services Many common services such as file and print services, email, name resolution, file transfer, etc. (often present on servers by default) have known vulnerabilities which malicious individuals can exploit to gain access to the network. These common services should either be disabled, securely configured, or patched to properly protect the systems.

Modified p. 20 → 27

The ASV scan solution must be able to detect common services known to have vulnerabilities.

The ASV scan solution must be able to detect and report common services known to have vulnerabilities.

Modified p. 20 → 27

The ASV scan solution must scan detected wireless access points visible from the Internet (over the wire) and detect known vulnerabilities and configuration issues.

The ASV scan solution must scan detected wireless access points visible from the Internet (over the wire) and detect and report known vulnerabilities and configuration issues.

Modified p. 20 → 27

The ASV scan solution must detect and report ~~well-known, remotely detectable~~ backdoor ~~applications installed on the servers.~~ The presence of any such malware, including rootkits, backdoors, or Trojan horse programs must be marked as an automatic failure by the ASV.

The ASV scan solution must detect and report all known, remotely-detectable backdoor applications. The presence of any such malware, including rootkits, backdoors, and Trojan horse programs must be marked as an automatic failure by the ASV.

Removed p. 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. 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 environment. Remote access software is a path frequently used for cardholder data compromises.

Modified p. 21 → 29

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:

The ASV scan solution must be able to detect the presence of remote access software and detect any known vulnerability or configuration issues.

Modified p. 22 → 30

If the ASV scan solution detects point-of-sale (POS) software, the following note ~~should~~ be included in the Special Notes section of the scan report:

If the ASV scan solution detects point-of-sale (POS) software, the following note must be included in the Special Notes section of the scan report:

Modified p. 22 → 30

~~ “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.” …~~

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. 22 → 31

Whenever possible, ASVs must use two tools to categorize and rank vulnerabilities, and determine scan compliance:

Whenever possible, ASVs must use two tools to categorize and rank vulnerabilities, and determine PCI DSS scan compliance:

Modified p. 22 → 31

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.

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. 22 → 31

The use of the CVSS and CVE ~~standards,~~ in conjunction with ~~a common vulnerability database and scoring authority (the NVD)~~ is intended to provide consistency across ASVs.

The use of the CVSS and CVE standards in conjunction with the NVD is intended to provide consistency across ASVs.

Removed p. 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.

Modified p. 23 → 32

~~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, …~~

CVSS Score Result Guidance 7.0 through High Severity Fail To achieve a passing ASV scan, these vulnerabilities must be corrected and the affected systems must be re-scanned after the corrections (with a report(s) that shows a passing ASV scan).

Modified p. 23 → 33

~~1. The vulnerability is not included in the NVD.~~ In this case, the ASV must provide its own risk score using the CVSS ~~scoring system~~ and include, where possible, references to other external sources of information about the vulnerability.

In this case, the ASV must provide its own risk score using the CVSS Calculator and include, where possible, references to other external sources of information about the vulnerability.

Modified p. 23 → 33

2. The ASV disagrees with the CVSS score noted in the NVD. In this case, the ASV must provide (in addition to all the other required reporting elements for ~~vulnerabilities),~~ the following information:

2. The ASV disagrees with the CVSS score noted in the NVD. In this case, the ASV must provide (in addition to all the other required reporting elements for vulnerabilities) the following information: o The NVD rating of the vulnerability o The ASV’s rating of the vulnerability o Description of why the ASV disagrees with the NVD rating

Removed p. 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.

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

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

The scan report describes the type of vulnerability or risk, …

Modified p. 24 → 32

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.

Table 2 describes how an ASV scan solution categorizes vulnerabilities and risks that are considered High or Medium severity.

Modified p. 24 → 33

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

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. 24 → 34

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

Report Customization: Note that while the use of Appendices A and B are mandatory as templates for the Attestation of Scan Compliance and the ASV Scan Report Summary, some customization of these documents is allowed, such as:

Modified p. 24 → 34

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 This is the overall summary that shows whether the scan customer’s infrastructure met the scan requirements and received a passing scan.

Removed p. 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, see Appendices A, B, and C.

The ASV Scan Report consists of three sections as follows:

1. Attestation of Scan Compliance This is the overall summary that shows whether the scan customer’s infrastructure received a passing scan and met the scan validation requirement.

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

Report Customization: Note that while the use of Appendices A and B are mandatory as templates for the Attestation of Scan Compliance and the Executive Summary, some customization of these documents is allowed, such as:

 Addition of the ASV’s logo  Addition of ASV-specific clauses as long as the …

Modified p. 25 → 34

~~Note:~~ There is no required template or format for the Vulnerability Details report. ASVs ~~can~~ design their own format for this report as long as ~~the~~ content specified in Appendix C is included.

There is no required template or format for the ASV Scan Vulnerability Details report. ASVs are permitted to design their own format for this report as long as all content specified in Appendix C of this ASV Program Guide is included.

Modified p. 25 → 34

~~Attestation of Scan Compliance Generation and Submission  The Attestation of Scan Compliance can be submitted alone without the ASV Scan Executive Summary or ASV Scan Vulnerability Details,~~ or is also the mandatory cover sheet for the ASV Scan ~~Executive~~ Summary and/or ASV Scan Vulnerability Details, at acquirer’s or ~~payment brand’s~~ discretion.

• or is also the mandatory cover sheet for the ASV Scan Report Summary and/or ASV Scan Vulnerability Details, at acquirer’s or Participating Payment Brand’s discretion.

Modified p. 25 → 35

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.

2. ASV Scan Report Summary This section of the scan report lists vulnerabilities by component (IP address, hosts/virtual hosts, domains, FQDN, etc.) and shows whether each component scanned received a passing score and met the scan requirement. This section shows, at minimum, all compliance- impacting vulnerabilities noted for a given component, with one line per vulnerability noted. For example, a component will show one line when only one vulnerability is noted, but will have five lines if five vulnerabilities are …

Removed p. 26

Executive Summary content

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

 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

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.

 For this report section, the ASV …

Modified p. 26 → 35

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.

Vulnerability Details generation and submission o 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 Report Summary at acquirer’s or Participating Payment Brand’s discretion.

Modified p. 26 → 36

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

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

Removed 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 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 my scanned systems are compliant with the external vulnerability scan requirement of the PCI DSS; this scan result does not represent (Scan customer name)’s overall compliance status with PCI DSS or …

Modified p. 27 → 37

The ~~ASV~~ attestation includes the following elements:

The ASV’s attestation includes the following elements:

Modified p. 27 → 37

 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:~~

• The ASV Program Guide and other supplemental guidance from PCI SSC was followed for this scan.

Removed p. 28

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. Scan customer then contacts ASV to initiate another scan.

3. Scan customer and ASV agree on a method that allows the lab-validated ASV scan solution to complete a scan of the external interface(s) of all hosts without interference. This method must be operated and managed by the ASV in accordance with all ASV Program requirements. For example, a secure connection (such as an IPsec VPN tunnel) could be implemented between the ASV and scan customer, or the lab-validated ASV scan solution1 (such as an appliance or agent) could be installed at the scan customer’s site.

Modified p. 28 → 37

 Scan customer corrects noted failing vulnerabilities.

• Scan customer corrects noted failing vulnerabilities.

Modified p. 28 → 37

 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.~~

• Scan customer may seek help from the ASV or other security professional as needed to determine proper corrective actions.

Modified p. 28 → 38

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

• If a passing scan is achieved, the scan customer submits results according to Section 7.9, “Compliance Reporting.”

Modified p. 28 → 38

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

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

Modified p. 28 → 38

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:

(See Section 7.3 for more information on aggregating multiple failing scans into a passing scan report.) 7.6 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:

Modified p. 28 → 38

The ASV scan solution must complete a full scan of all external interfaces of the in-scope system components, in accordance with all ASV Program requirements, in order for the scan to be considered complete.

The ASV scan solution must complete a full ASV scan of all external interfaces of the in-scope system components, in accordance with all ASV Program requirements, in order for the scan to be considered complete.

Modified p. 28 → 38

Note: Where resolution of inconclusive scans involves ASV personnel, the personnel must be ASV ~~Security Engineers who 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 (ASVs).~~

Note: Where resolution of inconclusive scans involves ASV personnel, the personnel must be ASV Employees qualified by PCI SSC per Section 3.2, "ASV Employee

• Skills and Experience" of the ASV Qualification Requirements.

Modified p. 28 → 38

If the scan cannot be completed due to scan interference, the ASV ~~should~~ record the scan result as a failure, and clearly describe the conditions resulting in an inconclusive scan in the report under “Exceptions, False Positives, or Compensating Controls” as noted in Appendix B: ASV Scan Report ~~Executive~~ Summary.

If the ASV scan cannot be completed due to scan interference, the ASV must record the ASV scan result as a failure, and clearly describe the conditions resulting in an inconclusive ASV scan in the report under “Exceptions, False Positives, or Compensating Controls” as noted in Appendix B: ASV Scan Report Summary.

Removed p. 29

 Determine if the dispute can be validated remotely (from the ASV) and:

 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 Summary.  Not remove disputes from a report.  Not allow the scan customer to edit the scan report.  Not carry dispute findings forward from one quarterly scan to the next by the ASV. Dispute evidence must be verified/resubmitted by scan customer and evaluated again by the ASV for each quarterly scan.  Allow evaluation of disputes …

Modified p. 29 → 39

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

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

Modified p. 29 → 39

 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 inconclusive scans disputed by the scan customer.~~

• The ASV is ENCOURAGED to investigate false positives with a CVSS Base score at or below 3.9 (passing score).

Modified p. 29 → 39

 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 captures, 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)

Modified p. 29 → 40

~~ If remotely validated, update~~ the scan report.

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

Removed p. 30

Compliance Reporting Merchants and service providers need to follow each payment brand’s respective compliance reporting requirements to ensure each payment brand acknowledges an entity’s compliance status. Scan reports must be submitted according to each payment brand’s requirements. Contact your acquiring bank or check each payment brand’s website to determine to whom results should be submitted.

Modified p. 30 → 40

 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 must be documented in the scan report under “Exceptions, False Positives, or Compensating Controls” as noted in Appendix B: ASV Scan Report Summary.

Modified p. 30 → 40

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

• Not allow the scan customer to edit the scan report.

Modified p. 30 → 40

 The ASV scan must not reduce the search space of any scan by discarding vulnerabilities ~~met~~ by compensating controls.

• The ASV scan must not reduce the search space of any scan by discarding vulnerabilities resolved by compensating controls.

Removed p. 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 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 (ASVs).

PCI SSC’s Quality Assurance Program for ASVs The PCI SSC, in accordance with the Validation Requirements for ASVs, reviews work associated with ASV scan reports for quality assurance purposes. As stated in the Validation Requirements for ASVs and the PCI ASV Compliance Test Agreement, ASVs are required to meet quality assurance standards set by PCI SSC.

The PCI SSC has determined that the discovery of specific and severe violations of ASV …

Modified p. 31 → 41

The ASV must implement a QA process that is designed to detect ~~incomplete~~ or corrupted scans. The ASV’s QA process must include the following features:

The ASV must implement a QA process that is designed to detect incomplete, inconclusive or corrupted ASV scans. The ASV’s QA process must include at minimum the following features:

Modified p. 31 → 41

~~ 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.~~

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

Modified p. 31 → 41

The quality assurance of ASV services and reporting includes annual validation via the ASV Test Bed. Additionally, ~~at least every two years~~ the ASV ~~will~~ be validated by reviewing the results of scan reports developed for ~~ASV clients.~~

The quality assurance of ASV services and reporting includes annual validation via the ASV Validation Labs Test Bed. Additionally, the ASV may be validated by reviewing the results of scan reports developed for scan customers; PCI SSC may request the results of such scan reports at any time.

Removed p. 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.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.

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.

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 …

Modified p. 32 → 42

The ASV ~~must~~ also submit a remediation plan to PCI SSC detailing how the ASV plans to improve quality of ~~their reports.~~ PCI SSC may also require an onsite ~~visit~~ with the ASV to audit ~~their~~ QA program, at the expense of the ASV.

The ASV may also be required to submit a remediation plan to PCI SSC detailing how the ASV plans to improve the quality of its performance or ASV scan solution. PCI SSC may also require onsite visits with the ASV to audit the ASV’s QA program, at the expense of the ASV.

Removed p. 33

Figure 1: Overview of ASV Processes The flowchart below illustrates the overall process of the ASV Scan.

Removed p. 34

Contact: Title: Contact: Title:

Telephone: E-mail: Telephone: E-mail:

Business Address: Business Address:

Scan Status  Compliance Status Fail Pass  Number of unique components*scanned:  Number of identified failing vulnerabilities:  Number of components* found by ASV but not scanned because scan customer confirmed components were out of scope:  Date scan completed:  Scan expiration date (90 days from date scan completed):

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 my scanned systems are compliant with the external vulnerability scan requirement …

Modified p. 34 → 44

City: State/Province: ~~City: State/Province:~~

City: State/Province: ZIP/postal code:

Modified p. 34 → 45

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.

A.5 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.2 and the ASV Program Guide.

Modified p. 34 → 45

(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) active scan interference. This report and any exceptions were reviewed by (ASV reviewer name).

(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, 3) compensating controls (if applicable), and 4) active scan interference. This report and any exceptions were reviewed by (ASV reviewer name).

Removed p. 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.

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:

Removed p. 36

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 Common Vulnerability Scoring System (CVSS), http://www.first.org/cvss/, base score, as indicated in the National Vulnerability Database (NVD), http://nvd.nist.gov/cvss.cfm (where available) 8 Use appropriate text for each subject, as outlined within the Program Guide.

Removed p. 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.

Date scan was completed: Scan expiration date :

Removed p. 38

 Change default settings in the remote access software (for example, change default passwords and use unique passwords for each customer).

 Allow connections only from specific (known) IP/MAC addresses.

 Use strong authentication, including unique and complex passwords for logins according to PCI DSS Requirements 8.1 - 8.4 and 8.5.8•8.5.15.

 Enable encrypted data transmission according to PCI DSS Requirement 4.1.

 Enable account lockout after a certain number of failed login attempts according to PCI DSS

 Configure the system so a remote user must establish a Virtual Private Network (VPN) connection via a firewall before access is allowed.

 Enable the logging function.

 Restrict access to customer passwords to authorized reseller/integrator personnel.

Document Comparison

Content Changes