How To Pass An Asv Scan

Transcription

1 PCI ASV Program Guide 2.0 Changes, Impact to your organization Jesper Jurcenoks Director of Security Research and Chief Evangelist Critical Watch May 20, 2013

2 Conclusion... 3 Introduction and background... 3 Impact for Merchants and Service providers... 4 Impact for ASVs Document Change Summary... 4 Major changes to Whitelisting of ASV and Scan interference... 5 Overview of important changes Important New Rules on Scan Interference... 7 Details of Changes Notes... 27

3 Conclusion Easier Compliance for Merchants and Card Acquirers - An updated,, less rigid - rule set for scan interference and active blocking makes it easier for merchants and card acquirers to be compliant while staying safe. New requirements for the ASVs mandate changes to procedures. PCI SSC does not require that changes to the Scan Solution stemming from the new requirements be implemented at this time. The new PCI ASV Program Guide is effective immediately. Introduction and background PCI (Payment Card industry) is governed by a number of security standard created and maintained by the PCI Security Standards Council ( The PCI ASV Program Guide is the authoritative document on how ASVs must conduct the quarterly external scans required by PCI DSS 2.0 Requirement The program guide is intended to be updated on regular intervals, synchronized with technological developments and emerging threats. The PCI ASV program guide was last updated on March The ASV program guide is important because every merchant independent of merchant level must produce a passing ASV scans report every quarter in order to stay PCI compliant. PCI compliancec of the merchantm is determined by the card acquirer based on the findings of the report and the recommendation (Pass or Fail) made by the ASV.

4 Many of the changes in the new program guide can trace their original back to these three documents: Consensus Suggested improvements for ASV Program Guide 2.0, Jan 2011 o Initiative, Coordination and Editor : Jesper Jurcenoks i ASV: Fail on Blocked Scan? - a PCI Industry consensus document, Jan 2013 o Initiative, Coordination and Editor : Jesper Jurcenoks ii PCI DSS Requirement and Security Assessment Procedures, Version 2.0 o Published by PCI DSS Impact for Merchants and Service Providers The new rules make it safer and easier for merchants, card acquirers, hosting providers and other Scan Customers to pass an ASV scan. Some of the active defense mechanisms that had to whitelist ASV s originating IPs, no longer has to be changed. Previously active defense mechanisms required by PCI to pass PCI DSS 2.0 like Web-application firewalls, had to be disabled during ASV scans resulting in paradoxical scan failures. The Scan Customers now have additional options to resolve ASV scans that fail as inconclusive. Impact for ASVs Changes to procedures for handling inconclusive scans Minor changes to mandatory texts in reports Significant changes to how tools should detect scan interference New requirements effective immediately but changes to scan solutions not required. (see section Required Timeline for Implementation for details)) Required Timeline for Implementation Scan Customers:

5 Merchants, Card acquirers and other scan customers are free to start using the new rules at any time they want, the new rules are less stringent that the previous rules and transitioning to the new rules is optional and at the scan customer s discretion. ASVs: The changes in the requirements to the ASV fall into 3 categories: 1. Minor text changes to mandatory text in reports. Contents, and context wise the changes are not significant and considered optional at this time. e.g. leaving the mandatory text ad verbatim to the ASV program Guide v1.0 for the time being will not invalidate the scan solution under ASV Program Guide v ASV Needs to change procedures and training of ASV personnel, including Qualified ASV Engineers (QAE), for new escalation of inconclusive scans procedure. There is no set deadline; changes should be made using normal business priority as business demands. 3. Changes to the way the Scan solution detects active blocking and when it reports inconclusive scans. No specific deadline date for changes to scan solution, tools, or procedures. PCI SSC expects the individual ASV to prioritize these changes in coordination with their customers and implement accordingly. Document Change Summary The new PCI ASV Program Guide G is effective immediately (May 20 th 2013) This document provides a comprehensive overview of all the changes between PCI ASV Program Guide 1.0 released March 2010 and the ASV Program Guide 2.0 Released May 20 th, Major changes to Whitelisting of ASV and Scan interference 1. Critical protection that keeps scan customers compliant does not have to be disabled anymore during ASV Scans. a. Still allowed systems: Systems that only record but does not interfere with traffic b. Still prohibited systems: Systems the block perceived good traffic based on traffic trends, previous attack from same IP etc. c. New allowed systems: Systems that block packets with perceived malicious contents, but allows perceived good traffic pass, even right after malicious traffic from the same source

6 2. More options available to ASVs and Scan Customers to resolve Failing Scans. Including: a. Scan Interference dispute resolution procedures b. Ability to consolidate overlapping inconclusive scans to create a conclusive report c. Ability to perform part of scan behind Active defense mechanisms For details of changes, see section Important New Rules on Scan Interference. Overview of important changes 1. PCI promises more cooperation with PCI community in regards to evolving standards 2. No grace period before new rules are in effect 3. ASVs are now explicitly responsible for: Maintaining security and integrity of systems and tools used to perform scans 4. Scan Customers are now explicitly responsible for: Perform due diligence in the ASV selection process, per the scan customer s due-diligence processes, to obtain assurance as to the ASV s level of trust to perform scanning services and To the degree deemed appropriate by the scan customer, monitor Internet -facing systems, active protection systems, and network traffic during the scan, to assure an acceptable level of trust is maintained 5. Clarification: Scan customers cannot perform their own ASV scan, not even if the use the same scanning software that the ASV uses 6. Current ASV program fees are now moved to the PCI SSC program fee schedule 7. List of items for the scan customer to provide enhanced with Domains 8. ASV report additional components list now only required to list relinquished IP addresses for 1 additional scan (but can list them longer) 9. New text for Directory Browsing noten 10. New text for Remote Access noten 11. New text for POS System noten 12. A somewhat obscure requirement that severity levels must be easy to compare and rank has been removed

7 13. Only rescan of failed affected systems is now required and not rescan of the entire environment to obtain passing report 14. Clarification that Attestations must be made for each report 15. Changes to the Scan Customer Attestation Mandatory Text 16. Scan customer can now dispute the detection of scan interference 17. ASV is now required to investigate disputed inconclusive scans 18. Requirement that ASV should assess accuracy of compensating controls, changed to the achievable applicability 19. Clarification that ASVs can get decertified from failing to be complete annual recertification Important New Rules on Scan Interference Background: In the fall of 2012 two parallel efforts started to address problems regarding Whitelisting of ASV s IP addresses and problems around Scan interference: 1) an initiative by ASV Jesper Jurcenoks within the ASV community and 2) an initiative by Jody B. Lee from TSYS within the Payment processing community. In November 2012 the two initiatives where merged and together produced a consensus recommendation for PCI SSC called ASV: Fail on Blocked Scan a PCI Industry consensus document This document was the basis for a major rewrite on the PCI rules for Scan interference. 3. Critical protection that keeps scan customers compliant does not have to be disabled anymore a. Still allowed systems: Systems that only record but does not interfere with traffic b. Still prohibited systems: Systems that block perceived good traffic based on trends, previous attack from same IP etc. c. New allowed systems: Systems that block traffic with perceived malicious contents, but that allows perceived non-malicious traffic pass even right after malicious traffic from the same source 4. More options available to ASVs and scan customers to resolve failing scans, including: a. Scan interference dispute resolution procedures b. Ability to consolidate overlapping inconclusive scans to create a conclusive report c. Ability to perform part of scan from behind the active defense mechanisms

8 Updated Section - ASV Scan Interference If an ASV detects that an active protection system has blocked or filtered a scan, then the ASV is required to handle it in accordance with the Resolving Inconclusive Scans section of this document. In order to ensure that reliable scans can be conducted, the ASV scan solution must be allowed to perform scanning without interference from active protection systems, where active denotes security systems that dynamically modify their behavior based on information gathered from non-attack network traffic patterns. Non-attack traffic refers to potentially legitimate network traffic patterns that do not indicate malformed or malicious traffic, whereas attack traffic includes, for example, malicious network traffic patterns or patterns that match known attack signatures, malware, or packets exceeding the maximum permitted IP packet size. Examples of active protection systems that dynamically modify their behavior include, but are not limited to: Intrusion prevention systems (IPS) that drop non-malicious 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 blacklist a sending IP address based on certain previous SMTP command s 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.

9 Systems that consistently block attack traffic, while consistently allowing non -attack traffic to pass (even if the non-attack traffic follows attack traffic) typically do not cause ASV scan interference. Examples of these security systems (that do not dynamically modify their behavior, rather, they maintain consistent, static behavior based on rules or signatures) include, but are not limited to: 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, but let non-attack traffic from the same source pass Firewalls that are configured to always block certain ports, but always keep other ports open VPN servers that reject entities with invalid credentials but permit entities with valid credentials Antivirus software that blocks, quarantines, or deletes all known malware based on a database of defined signatures but permits all other perceived clean content Logging/monitoring systems, event and log aggregators, reporting engines Logging/monitoring systems, event and log aggregators, reporting engines. Being able to detect all vulnerabilities is part of the defense-in-depth approach of PCI DSS. If the scan cannot detect vulnerabilities on Internet -facing systems because the scan is blocked by an active protection system, those vulnerabilities will remain uncorrected and may be exploited by an attacker whose attack patterns don't trigger the active protection mechanism. All ASV scans must either be validated by the ASV to ensure they have not been blocked or filtered by an active protection system, or resolved in accordance with the Resolving Inconclusive Scans section of this document. Temporary configuration changes may need to be made by the scan customer to remove interference during a scan Due to the remote nature of external vulnerability scans and the need mentioned above to conduct a scan without interference from an active protection system, certain temporary

10 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). 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 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: o o o Agree on a time for the scan window each quarter to minimize how long changed configurations are in place. Conduct the scan during a maintenance window under the scan customer s standard change control processes, with full monitoring during the ASV scan. Configure the active protection systems to either: Monitor and log, but not to act against, the originating IP address(es) of the ASV, or 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 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 a scan can be completed as quickly as possible. However, this type of approach can also lead to a high rate of reaction by active intrusion-prevention systems. An attacker will generally attempt to restrict the volume of their scans so they are stealthier and less likely to trigger a log event that may be noticed. Thus, the high-volume scans typically performed by ASVs are significantly more likely to trigger an active protection mechanism than those of an attacker. Temporary configuration changes do not require that the scan customer provide the ASV a higher level of network access. Rather, the scan customer must ensure that any triggers, such as volume-based or correlated IP address thresholds, are not activated by the ASV scan and the scan is allowed to complete. The intent is that the ASV be provided the same network level view as an actual attacker.

11 New Section - Resolving Inconclusive Scans For ASV scans that cannot be completed due to scan interference, the scan customer may work with the ASV to implement one or more of the following options until a complete scan is achieved. An inconclusive scan that is left unresolved must be reported by the ASV as a failed scan: 1. Scan customer makes proper temporary configuration changes to remove interference during a scan; the scan customer may seek help from a trusted security professional as needed to determine proper temporary configuration changes to be made. Scan customer then contacts ASV to initiate another scan 2. Scan customer provides the ASV with sufficient written supporting evidence to support their assertion that the scan was not actively blocked. Scan customer and ASV work together to resolve scanning issues and schedule additional scan(s), as necessary, in order for the scans to cover all ports on all applicable systems. Note that if the ASV agrees that a scan was not actively blocked, the ASV may determine that all ports on all applicable systems have been scanned and that additional scans are not necessary 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 requ irements. For example, a secure connection (such as an IPsec VPN tunnel) could be implemented between the n 1 (s 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. 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). 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. Details of Changes.

12 Every change enumerated and explained. Color Legend: Important Change 19 Instances Traced back to Consensus Suggested improvements for ASV Program Guide 2.0, Jan Instances Traced back to ASV: Fail on Blocked Scan? - a PCI Industry consensus document, Jan Instances Traced back to PCI DSS Instances

13 PCI ASV Program 1.0 Old PCI ASV Program New Change Type Footer PCI DSS, v1.2 ASV Program guide Reference, V1.0 ASV Program Guide v2.0 Simplification of title Approved Scanning Vendor Program Guide Introduction PCI DSS Payment Card Industry Data Security Standard (PCI DSS) Clarification PCI DSS Requirement 11.2 PCI DSS Requirement Clarification The PCI SSC recommends, but does not require, that scan customers use the requirements for other vulnerability scanning required by PCI DSS Requirement 11.2, including internal vulnerability scanning, external scanning performed after a significant change to the network, and any external scanning performed in addition to the required quarterly external scans. 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. Clarification Updates to Documents and Security Requirements As such, PCI SSC will endeavor to update PCI DSS requirements every 24 months. As such, PCI SSC will update PCI DSS requirements according to PCI SSC s defined three-year lifecycle process. Update to PCI DSS s new 3-year lifecycle PCI SSC reserves the right to change, amend or withdraw PCI DSS requirements at any time and will endeavor to work closely with its community of Participating Organizations regarding such changes. ASVs must implement the requirements set forth in this document by no later than September 1, 2010 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. ASVs must implement the requirements set forth in this document effective immediately since no changes in this document require changes Right to change updated to include ASV Documentations Stronger Language promising corporation with Community Grace period reduced none from 6 months

14 Terminology ASV(Approved Scanning Vendor) refers to a data security firm that has been qualified and trained by the PCI SSC to use a vulnerability scanning solution to determine compliance of their customers with the external vulnerability scanning requirement of PCI DSS Requirement 11.2 About PCI SSC The ASV documents and the PCI DSS define a common security assessment framework that is recognized by all payment brands. Roles and Responsibilities The following defines the roles and responsibilities of the stakeholders in the payment application community. Approved Scanning Vendors ASVs are responsible for the following:. Providing a determination as to whether the scan customer s components have passed the scanning requirement Scan Customers Scan customers are responsible for the following: to the ASVs scanning solution. 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 Refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms. Scan interference Refers to interference including (but not limited to) active protection systems blocking, filtering, dropping or modifying network packets in response to scan traffic, such that the view of the environment would be changed and the ASV scanning solution would no longer see what an attacker would see. The ASV documents and the PCI DSS define a common security assessment framework that is recognized by the payment brands. The following defines the roles and responsibilities of the stakeholders in the payment community. ASVs are responsible for the following: Maintaining security and integrity of systems and tools used to perform scans Providing a determination as to whether the scan customer s components have met the scanning requirement Scan customers are responsible for the following: Changes to definition of ASV, Important to note that an ASV is no more required to be a Data Security Firm, only that they have to be approved by PCI SSC New Clearer Definition of Scan Interference Clarification to show that PCI SSC does not (yet) represent all Payment brands Clarification Stakeholders are not limited to payment application community New Responsibility added to ASV s meeting instead of passing a requirement is more correct English. Responsibility for trusting ASV is put on

15 Perform due diligence in the ASV selection process, per the scan customer s due-diligence processes, to obtain assurance as to the ASV s level of trust to perform scanning services customer, away from PCI SSC Configuring intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) so they do not interfere with the ASV s scan, as required by this document. See the section entitled Perform a Scan without Interference from IDS/IPS. Arranging with ASV to re-scan any non-compliant IP addresses to obtain a passing quarterly scan Scan Process Overview Vulnerability-scanning companies interested in providing PCI DSS vulnerability scans in conjunction with PCI DSS must comply with the requirements set forth in this document as well as the Validation Requirements for Approved Scanning Vendors (ASVs), and must successfully complete the PCI Security Scanning Vendor Testing and Approval Process. The main phases of the scanning process consist of: Scoping Scanning Dispute Resolution Reporting/remediation PCI DSS Requirement 11.2 To the degree deemed appropriate by the scan customer, monitor Internet -facing systems, active protection systems, and network traffic during the scan, to assure an acceptable level of trust is maintained Configuring active protection systems so they do not interfere with the ASV s scan, as required by this document. See the section entitled ASV Scan Interference. Arranging with ASV to re-scan any non-compliant systems to verify that all high severity and medium severity vulnerabilities have been resolved, to obtain a passing quarterly scan 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. The main phases of the scanning process consist of: Scoping Scanning Reporting/remediation Dispute Resolution Rescan (as needed) Final reporting Changed from the narrow IDS/IPS to broader Active Protection systems Clarification that high and Medium Severity vulnerabilities must be resolved to obtain a passing scan. Clarification of language A few more phases included in the overview. PCI DSS 1.0 verbiage PCI DSS 2.0 Verbiage All Direct quotes from PCI DSS updated to PCI

16 Can a merchant or service provider perform their own external vulnerability scanning? Only ASV scan solutions can be used to perform the PCI DSS quarterly external vulnerability scans required by PCI DSS Requirement 11.2, and an ASV scan solution must be run by the ASV. Some ASV scan solutions may, under the control and management of the ASV, be started remotely by a scan customer via an ASV s web portal to allow a scan customer to select the best times to scan their cardholder data environment. However, only an authorized ASV employee can be allowed to configure any settings (e.g., disable any vulnerability checks SQL injection, XSS checks) or modify the output of the scan. Merchants and service providers must use only PCI SSC Approved Scanning Vendors (ASVs) to perform the quarterly external vulnerability scans required by PCI DSS Requirement , and an ASV scan solution must be executed and managed by the ASV. Some ASV scan solutions may, while still under the control and management of the ASV, be started remotely by a scan customer (for example, via an ASV s web portal and/or ASV s scan solution) to allow a scan customer to select the best times to scan their cardholder data environment and define which of the customer s IP addresses are to be scanned. However, only an authorized ASV employee is permitted to configure any settings (for example, modify or disable any vulnerability checks, assign severity levels, alter scan parameters, etc ), or modify the output of the scan. Scanning Vendor Testing and Approval Process 2. The scanning vendor notifies PCI SSC at asv@pcisecuritystandards.org that the ASV company is ready to be tested. 3. The PCI SSC notifies the scanning vendor to schedule the test. 4. The scanning vendor submits the solution for testing to PCI SSC via the ASV Portal. a. The scanning vendor uses this portal to create the solution for testing. (PCI SSC provides instructions for the portal with Step 3 above.) Note: Scanning Vendor Testing via the ASV Test Bed is an annual process. 2. The scanning vendor notifies PCI SSC at asv@pcisecuritystandards.org that the scanning vendor is ready to be tested. 3. The PCI SSC notifies the scanning vendor to schedule the test, and provides the scanning vendor with instructions for the ASV Portal. 4. The scanning vendor submits a request for solution testing via the ASV Portal. Note: Scanning Vendor Testing via the ASV Test Bed is an annual requirement. DSS 2.0 Important clarification: Some Scan customers incorrectly believed that buying and installing the same scanning product that the ASV used would enable them to perform their own ASV scan. ASV scans have to be done by the ASV. Clarified confusing language Cleaning up the language for the procedure Clarification that Annual Vendor testing

17 is a requirement Fees will be charged for the various testing stages in accordance with the PCI ASV Compliance Test Agreement, Schedule 1. Fees will be charged for the various testing stages in accordance with the PCI SSC Programs Fee Schedule. Fees for Certification of the ASV is now removed from the Test Agreement and put in a separate Fee Schedule in the PCI SSC web-site (here) ASV Scan Scope Definition Note: Per the PCI DSS, System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Scan customers can use segmentation to reduce the scope of the ASV scanning. 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/desk tops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Scan customers may use segmentation to reduce the scope of the ASV scanning. System components enhanced specifically to include Virtual environments. Cardholder Data environment (CDE) has been expanded to include People and processes Changed can to may to emphasize optional measures to reduce scope. Scan Customers Provide Internetfacing IP Addresses and Domains Scan Customers Provide Internet-facing IP Addresses and Domains Any other public-facing domains or domain aliases Internet Service Providers and Hosting Providers This section applies to the scan customer s Internet service provider (ISP) or hosting provider (if used by scan customers to host their website). This section applies to the scan customer s Internet service provider (ISP) or hosting provider (if used by scan customers to host part or all of their CDE). List of items to be provided by the scan customer enhanced with Domains. Definition enhanced from Web-site to include all of CDE.

18 For ISPs, scan customers need to coordinate with them to allow the ASV scan to be performed without interference from IDS or IPS. For more details, see the section entitled Perform a Scan without Interference from IDS/IPS. For 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. Updated wording to Reflect new policy on scan interference. For hosting providers and their shared hosting environments, it is common practice that a single server will host more than one website. In a shared hosting environment, the scan customer shares the server with the hosting provider s other customers. This could lead to the merchant s website being compromised through security weaknesses on other customers websites on the hosting provider s server. 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 thirdparty providers include but are not limited to DNS servers, and web servers, application servers, etc. Clarified definition of shared hosting environment. Note: If the hosting provider has all Internet-facing IP ranges AND all scan customers domains scanned as part of the hosting provider s own ASV scans, and provides proof to scan customers, the domains do not have to be included in the scan customers ASV scans. Note: If the hosting provider has all Internet -facing IP ranges AND all scan customers domains scanned as part of the hosting provider s own ASV scans, and provides proof of passing scans to scan customers, the domains do not have to be included in the scan customers ASV scans Clarification: it is not enough that the Hosting provide has an ASV Scan, it must be a passing ASV scan. ASVs Confirm Scope and List Additional Components Identified during Discovery Include any IP address or domain that was previously provided to the ASV that has been removed at the request of the customer. Include any IP address or domain previously provided to the ASV and still owned by the customer that has been removed at the request of the customer. o If the customer no longer owns or has custody of the IP address/domain, include Change to avoid list of IPs not scanned previously growing indefinitely.

19 ASV Scan Interference that IP address or domain for at least one additional quarter after it was removed from scope or released by the customer. In order to ensure that reliable scans can be conducted, the ASV scan solution must be allowed to perform scanning without interference from intrusion detection systems (IDSs) or intrusion prevention systems (IPSs.. If an ASV detects that an IDS/IPS has blocked or filtered a scan, then the ASV is required to fail the scan as inconclusive. All ASV scans must be validated by the ASV to ensure they have not been blocked or filtered by an IDS/IPS. If an ASV detects that an active protection system has blocked or filtered a scan, then the ASV is required to handle it in accordance with the Resolving Inconclusive Scans section of this document. The intent is that the ASV be provided the same network level view as an actual attacker. ASV Scan Solution Required Components Additionally, accurate operating system and service version identification can help scan customers in understanding their risks and prioritizing remediation activities. The ASV scanning solution should, where possible, determine the protocol and service/application version running on each open port. Since services may sometimes run on nonstandard ports, the ASV scanning solution should, where possible, not rely solely on a well- known port number to determine which protocol is running on a given port. Thus, the ASV scan tools must accommodate external load balancing scenarios to ensure that all IP addresses and ranges provided by the scan customer are successfully scanned. Additionally, accurate operating system and service version identification can help scan customers understand their risks and prioritize remediation activities. The ASV scanning solution should also, where possible, determine the protocol and service/application version running on each open port. Since services may sometimes run on non-standard ports, the ASV scanning solution should, where possible, not rely solely on a well - known port number to determine which protocol or service is running on a given port. Thus, the ASV scan solution must accommodate external load balancing scenarios to ensure that all IP addresses and ranges provided by the scan customer are successfully scanned. Major Rewrite See separate discussion of what this means to you. Fixing the language Fixing the language Clarification Changed ASV scan tool to the more encompassing ASV scan solution

20 Table 1: Required Components for PCI DSS Vulnerability Scanning Language cleanup Firewalls and routers, which control traffic between the company s network and external untrusted networks (for example, the Internet), have known vulnerabilities for which patches are released periodically. Malicious individuals exploit operating system vulnerabilities to get access to internal databases that potentially store cardholder data. Firewalls and routers, which control traffic between the company s network and external untrusted networks (for example, the Internet), have known vulnerabilities for which patches are periodically released. Malicious individuals exploit operating system vulnerabilities to gain access to applications and internal databases that potentially store, process or manage access to cardholder data. Language cleaned up and enhanced to be in line with PCI DSS 2.0 requirement. The ASV scanning solution must also be able to determine the version of the operating system and whether it is an older version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV. Malicious individuals exploit vulnerabilities in these servers to get access to cardholder data. Web servers allow Internet users to view web pages, interact with web merchants, and make online web purchases. Note to scan customer: Browsing of directories on web servers can lead to information disclosure or potential exploit. Due to increased risk to the cardholder data environment, please 1) justify the business need for this configuration to the ASV, or 2) confirm that it is disabled. Please consult your ASV if you have questions about this Special Note. Application servers act as the interface between the web server and the backend databases and legacy systems. For example, when cardholders share account numbers with merchants or service providers, the application server provides the functionality to transport data in and out of the secured network. Malicious individuals exploit vulnerabilities in these servers and their scripts to get access to internal databases that potentially store credit card data. The ASV scanning solution must also be able to determine the version of the operating system and whether it is a version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV. Malicious individuals exploit vulnerabilities in these servers to gain access to cardholder data. Web servers allow Internet users to view web pages, interact with web merchants, and conduct online web trans actions. Note to scan customer: Browsing of directories on web servers can lead to information disclosure or potential exploit. Due to increased risk to the cardholder data environment, 1) justify the business need for this configuration to the ASV, or 2) confirm that it is disabled. Consult your ASV if you have questions about this Special Note. Application servers act as the interface between the web server and other systems, such as back-end databases. For example, when cardholders s hare account numbers with merchants or service providers, the application server provides the functionality to trans port 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 s tore, process or manage access to cardholder data. Clarification: Nonsupported OS is automatic failure even if it is not old Language cleanup Purchases replaced with broader Transactions. New note Text, removed please. Language Cleanup Language Cleanup

21 The ASV scanning solution must be able to detect the presence of an application server and/or web application servers and detect any known vulnerability and configuration issues. Built-in, or default accounts and passwords are commonly used by hardware and software vendors to allow the customer their first access to the product. The ASV scan solution must be able to detect the presence of application servers and/or web application servers and detect known vulnerabilities and configuration issues. Built-in, or default accounts and passwords, are com m only used by hardware and software vendors to allow the customer initial access to the product. Language Cleanup Language cleanup For testing and reporting on built-in or default accounts in routers, firewalls, operating systems, web servers, database servers, applications, POS systems, or other components, the ASV scan solution, must do the following: For testing and reporting on built-in or default accounts in routers, firewalls, operating system s, web servers, database servers, applications, pointof-sale (POS) systems, or other components, the ASV scan solution, must do the following: Clarified POS systems. DNS servers resolve Internet addresses by translating domain names into IP addresses. If DNS servers are vulnerable, malicious individuals can masquerade as a merchant s or service provider s web page and collect cardholder data. Web applications reside on application servers or web application servers (see above), and interface with the back-end databases and legacy systems. For example, when cardholders share account numbers with merchants, the web application may take the cardholder data from a customer to process and complete the transaction, and store the transactions results and cardholder data in a database, all as part of the customer s online purchase. DNS servers are used to locate resources on the Internet by resolving domain names to their respective IP address. If DNS servers are vulnerable, malicious individuals can masquerade as or redirect traffic from a merchant s or service provider s web page and collect cardholder data. Web applications typically res ide on web or application servers and interface with the back-end databases and other systems. Web applications may process or trans m it cardholder data as part of the customer s online trans action, or s tore such data in a database server. Clarification of what a DNS server does Clarification of Risks Language simplification and cleanup Malicious individuals frequently exploit application vulnerabilities to gain access to internal databases that potentially store cardholder data. Remote access software includes, but is not limited to: VPN (IPSec, PPTP, SSL), pcanywhere, VNC, Microsoft Terminal Server, remote web-based administration, ssh, Telnet. Malicious individuals frequently attempt to exploit web application vulnerabilities to gain access to applications or internal databases that m ay process, s tore, or manage access to cardholder data. Remote access software includes, but is not limited to: VPN (IPSec, PPTP, SSL), pcanywhere, VNC, Micros oft Term inal Server, remote web-based administration, SSH, and Telnet. Aligned language with PCI DSS 2.0 Clarification, remote access software is an and list not an or list Note to scan customer: Due to increased risk to the cardholder data environment Note to scan customer: Due to increased risk to the cardholder data Updated Note Text.

22 when remote access software is present, please 1) justify the business need for this software to the ASV and 2) confirm it is either implemented securely per Appendix C or disabled/ removed. Please 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, please 1) confirm that this system needs to be visible on the Internet, that the system is implemented securely, and that original default passwords have been changed to complex passwords, or 2) confirm that the system has been reconfigured and is no longer visible to the Internet. Please consult your ASV if you have questions about this Special Note. Vulnerability Reporting To demonstrate compliance, a scan must not contain high-level vulnerabilities, or any vulnerability that indicate features or configurations that are in violation of PCI DSS. If these exist, the ASV must consult with the client to determine whether these are, in fact, PCI DSS violations and therefore warrant a noncompliant scan report. Vulnerability Categorization To assist customers in prioritizing the solution or mitigation of identified issues, ASVs must assign a severity level to each identified vulnerability or misconfiguration. environment when remote access software is present, 1) justify the business need for this software to the ASV and confirm it is implemented securely per Appendix D of the ASV Program Guide, or 2) confirm it is disabled/ removed. 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. To demonstrate compliance, a scan must not contain high or medium severity vulnerabilities, or any vulnerability that indicates features or configurations that are in violation of PCI DSS. If these exist, the ASV must consult with the scan customer to determine whether these are, in fact, PCI DSS violations and therefore warrant a noncompliant scan report. To assist customers in prioritizing the solution or mitigating identified issues, ASVs must assign a severity level to each identified vulnerability or misconfiguration, as defined in Table 2 in the next page. Removed 2 x please Appendix Reference updated to point to the correct appendix. Updated Note Text. Removed 2 x please Changed from high level or high or medium severity to be in line with rest of requirements. Changed client to scan customer to be in line with rest fo document. Cleaned up language and added reference to existing table on next page. The designation of each severity level must allow for an easy comparison between levels. Therefore, a severity ranking that is easy to understand must be [intentionally left blank] Requirement that the Severity ranking must be easy to understand

23 presented, with High Severity, Medium Severity, Low Severity. and easy to compare has been removed. Severity is to always be presented, easy or not. 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. Table 2: To achieve a passing scan, these vulnerabilities must be corrected and the environment must be re-scanned after the corrections (with a report that shows a passing scan). Organizations should take a risk-based approach to correct these types of vulnerabilities, starting with the most critical ones (rated 10.0), then those rated 9, followed by those rated 8, 7, etc., until all vulnerabilities rated 4.0 through 10.0 are corrected. 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 us e the CVSS scores whenever they are available. 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, 7, etc., until all vulnerabilities rated 4.0 through 10.0 are corrected. Redundant abbreviations moved to definitions section. Vulnerability Severity Levels Based on the NVD and CVSS Scoring Important change only rescan of affected systems is now required and not the entire environment. Compliance Determination Overall and by Component Reports must indicate compliance determination at two levels: by component and for the overall customer level. Overall Compliance Determination For a customer to be considered compliant, all components within the customer s cardholder data environment must be compliant. Scan Reporting Table 2 above describes how an ASV scan solution categorizes vulnerabilities and demonstrates the types of vulnerabilities and Reports must indicate compliance determination at two levels: by component level, and for the overall customer level. For a scan customer to be considered compliant, all components within the customer s cardholder data environment must be compliant. Table 2 above describes how an ASV scan solution categorizes vulnerabilities and demonstrates the types of vulnerabilities and risks that Cleanup Language customer changed to scan customer for alignment with definitions in rest of document. Clarification of severity levels

24 risks that are considered highlevel. are considered high or medium severity. Generating, Reading, and Interpreting Scan Reports Attestation of Scan Compliance content, please see Appendix A: ASV Scan Report Attestation of Scan Compliance for required template. Attestation of Scan Compliance content, see Appendix A: ASV Scan Report Attestation of Scan Compliance for required template. Removed a please to signify that the Report template is mandatory 2. ASV Scan Report Executive Summary This lists vulnerabilities by components (IP address) and shows whether each IP address scanned received a passing score and met the scan validation requirement. Executive Summary content Please see Appendix B: ASV Scan Report Executive Summary for required template, which includes the following. Scan Customer and ASV Attestations 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. Executive Summary content See Appendix B: ASV Scan Report Executive Summary for required template, which includes the following: Clarification Removed a please to signify that the Report template is mandatory These attestations (once completed by the scan customer and ASV) are included on the Attestation of Scan Compliance cover sheet. Acknowledgement that scan results only indicate whether scanned systems are compliant with the external vulnerability scan requirement (PCI DSS 11.2) and are not an indication of overall compliance with any other PCI DSS requirements. Reviews and corrects connectivity issues between scanner and scan customer Scan Customer Attestation Mandatory text this scan result does not represent (Scan customer name) s my overall compliance status with PCI DSS These attestations (once completed by the scan customer and ASV) are included on the Attestation of Scan Compliance cover sheet. ASVs may not use the same Attestion of Scan Compliance for multiple quarters. The scan customer attestation must be generated each quarter for the scan identified in the Scan Report, and must be completed before each Scan Report is finalized. Acknowledgement that scan results only indicate whether scanned systems are compliant with the external quarterly vulnerability scan requirement (PCI DSS ) and are not an indication of overall compliance with any other PCI DSS requirements. Reviews and corrects connectivity issues between the scan solution and scan customer this scan result does not represent (Scan customer name) s overall compliance status with PCI DSS Clarification that Attestations must be made for each report. Clarification Cleaned up Language Removed an extraneous my from the mandatory text