How To Pass An Asv Scan

(1)

Technical Whitepaper 2013

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

PCI ASV Program 2.0 Changes, Impact to your Organization © Critical Watch 2013

(2)

Technical Whitepaper 2013

Conclusion ... 3

Introduction and background ... 3

Impact for Merchants and Service providers... 4

Impact for ASVs. ... 4

Document Change Summary ... 4

Major changes to Whitelisting of ASV and Scan interference ... 5

Overview of important changes. ... 6

Important New Rules on Scan Interference... 7

Details of Changes. ... 11

Notes ... 27

(3)

Technical Whitepaper 2013

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 (https://www.pcisecuritystandards.org/)

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 11.2.2

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

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)

Technical Whitepaper 2013

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ⁱ

• ASV: Fail on Blocked Scan? - a PCI Industry consensus document, Jan 2013 o Initiative, Coordination and Editor : Jesper Jurcenoksⁱⁱ

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

Technical Whitepaper 2013

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 v2.0

2. 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, 2013.

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)

Technical Whitepaper 2013

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 https://www.pcisecuritystandards.org/security_standards/fees.php

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)

Technical Whitepaper 2013

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)

Technical Whitepaper 2013

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)

Technical Whitepaper 2013

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, r a t h e r , 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 o n Internet -facing systems because the scan is blocked by an active protection system, those vulnerabilities w i l l 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)

Technical Whitepaper 2013

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

o Agree on a time for the scan window each quarter to minimize how long changed configurations a r e in place.

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

o Configure t he 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, t h i s 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 s c a n s 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)

Technical Whitepaper 2013

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 m u s t 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 A S V 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¹ (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 A S V 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)

Technical Whitepaper 2013

Every change enumerated and explained.

Color Legend:

Important Change 19 Instances

Traced back to Consensus Suggested improvements for ASV Program Guide 2.0, Jan 2011 12 Instances

Traced back to ASV: Fail on Blocked Scan? - a PCI Industry consensus document, Jan 2013 11 Instances

Traced back to PCI DSS 2.0 3 Instances

(13)

Technical Whitepaper 2013

PCI ASV Program 1.0 – Old PCI ASV Program 2.0 - 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 11.2.2 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

PCI SSC reserves the right to change, amend or withdraw PCI DSS and/or ASV requirements at any time

Right to change

updated to include ASV Documentations and will endeavor to work closely with

its community of Participating

Organizations regarding such changes.

and will work closely with its community of Participating Organizations regarding such changes.

Stronger Language promising corporation with Community

ASVs must implement the

requirements set forth in this document by no later than September 1, 2010

ASVs must implement the requirements set forth in this document effective immediately since no changes

in this document require changes

Grace period reduced none from 6 months

(14)

Technical Whitepaper 2013

to the ASVs’ scanning solution.

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

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.

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

New Clearer Definition of Scan Interference

About PCI SSC

The ASV documents and the PCI DSS define a common security assessment framework that is recognized by all payment brands.

The ASV documents and the PCI DSS define a common security assessment framework that is recognized by the payment brands.

Clarification to show that PCI SSC does not (yet) represent all Payment brands Roles and Responsibilities

The following defines the roles and responsibilities of the stakeholders in the payment application community.

The following defines the roles and responsibilities of the stakeholders in the payment community.

Clarification

Stakeholders are not limited to payment application community Approved Scanning Vendors

ASVs are responsible for the following:

….

ASVs are responsible for the following:

…

Maintaining security and integrity of systems and tools used to perform scans

…

New Responsibility added to ASV’s

Providing a determination as to whether the scan customer’s components have passed the scanning requirement

Providing a determination as to whether the scan customer’s components have met the scanning requirement

“meeting” instead of

“passing” a

requirement is more correct English.

Scan Customers

Scan customers are responsible for the following:

…

Scan customers are responsible for the following:

Responsibility for trusting ASV is put on

(15)

Technical Whitepaper 2013

…

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

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

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.

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.

Changed from the narrow IDS/IPS to broader Active Protection systems

Arranging with ASV to re-scan any non-compliant IP addresses to obtain a passing quarterly scan

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

Clarification that high and Medium Severity vulnerabilities must be resolved to obtain a passing 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.

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.

Clarification of language

The main phases of the scanning process consist of:

• Scoping

• Scanning

• Dispute Resolution

• Reporting/remediation

The main phases of the scanning process consist of:

 Scoping

 Scanning

 Reporting/remediation

 Dispute Resolution

 Rescan (as needed)

 Final reporting

A few more phases included in the overview.

PCI DSS Requirement 11.2

PCI DSS 1.0 verbiage PCI DSS 2.0 Verbiage All Direct quotes from

PCI DSS updated to PCI PCI ASV Program 2.0 Changes, Impact to your Organization © Critical Watch 2013

(16)

Technical Whitepaper 2013

DSS 2.0 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 11.2 .2, 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.

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.

Scanning Vendor Testing and Approval Process

2. The scanning vendor notifies PCI SSC at [email protected] that the ASV company is ready to be tested.

2. The scanning vendor notifies PCI SSC at

[email protected] that the scanning vendor is ready to be tested.

Clarified confusing language

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

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.

Cleaning up the language for the procedure

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

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

Clarification that Annual Vendor testing

(17)

Technical Whitepaper 2013

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.

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 .

System components enhanced specifically to include Virtual

environments.

The cardholder data environment is that part of the network that

possesses cardholder data or sensitive authentication data.

The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data.

Cardholder Data environment (CDE) has been expanded to include People and processes

Scan customers can use

segmentation to reduce the scope of the ASV scanning.

Scan customers may use

segmentation to reduce the scope of the ASV scanning.

Changed “can” to

“may” to emphasize optional measures to reduce scope.

Scan Customers Provide Internet- facing IP Addresses and Domains

…

Scan Customers Provide

Internet-facing IP Addresses and Domains

…

Any other public-facing domains or domain aliases

List of items to be provided by the scan customer enhanced with Domains.

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

Definition enhanced from Web-site to include all of CDE.

(18)

Technical Whitepaper 2013

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 w i t h 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 i n c l u d e but are not limited to DNS servers, email 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)

Technical Whitepaper 2013

that IP address or domain for at least one additional quarter after it was removed from scope or released by the customer.

ASV Scan Interference

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.

Major Rewrite See separate discussion of what this means to you.

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.

Additionally, accurate

operating system and service version identification can help scan customers understand their risks and prioritize remediation activities.

Fixing the language

The ASV scanning solution should, where possible, determine the protocol and service/application version running on each open port.

The ASV scanning solution should also, where possible, determine the protocol and service/application v e r s i o n running on each open port.

Fixing the language

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 is running on a given 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.

Clarification

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.

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.

Changed “ASV scan tool” to the more encompassing “ASV scan solution”

(20)

Technical Whitepaper 2013

Table 1: Required Components for PCI DSS Vulnerability Scanning

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.

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.

Language cleanup

Malicious individuals exploit operating system vulnerabilities to get access to internal databases that potentially store cardholder data.

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.

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.

Clarification: Non- supported OS is automatic failure even if it is not “old”

Malicious individuals exploit

vulnerabilities in these servers to get access to cardholder data.

vulnerabilities in these servers to gain access to cardholder data.

Language cleanup

Web servers allow Internet users to view web pages, interact with web merchants, and make online web purchases.

Web servers allow Internet users to view web pages , interact with web merchants, and conduct online web trans actions.

“Purchases” replaced with broader

“Transactions”.

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

“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.”

New note Text, removed “please”.

Application servers act as the interface between the web server and the back- end databases and legacy systems. For example, when cardholders share account numbers with merchants or service providers, the

application server provides the

functionality to transport data in and out of the secured

network.

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.

Language Cleanup

vulnerabilities in these servers and their scripts to get access to internal

databases that potentially store credit card data.

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.

Language Cleanup

(21)

Technical Whitepaper 2013

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

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

Language Cleanup

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.

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

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, point- of-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.

DNS servers are used to locate resources on the Internet by resolving domain names to their respective IP address.

Clarification of what a DNS server does

If DNS servers are vulnerable, malicious individuals can masquerade as a merchant’s or service provider’s web page and collect cardholder data.

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.

Clarification of Risks

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.

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.

Language simplification and cleanup

Malicious individuals frequently exploit application vulnerabilities to gain access to internal databases that potentially store cardholder data.

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.

Aligned language with PCI DSS 2.0

Remote access software includes, but is not limited to: VPN (IPSec, PPTP, SSL), pcAnywhere, VNC, Microsoft Terminal Server, remote web-based administration, ssh, Telnet.

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.

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.