WO2007146772A2

WO2007146772A2 - Qualification of scanning vendors for implementing payment card industry security procedures

Info

Publication number: WO2007146772A2
Application number: PCT/US2007/070709
Authority: WO
Inventors: Elizabeth M. Foran-Owens; Fernando Lourenco
Original assignee: Mastercard International Incorporated
Priority date: 2006-06-08
Filing date: 2007-06-08
Publication date: 2007-12-21
Also published as: WO2007146772A3

Abstract

A system and method for qualification of security scanning vendor, who conducts security scans and testing of the infrastructure, facilities and procedures of the entities (e.g., merchants, and service providers) involved the payment-by-card industry to ensure compliance with security standards, is provided. Vendors demonstrate their skill in data security validation trials, which present vendors with controlled emulated electronic environments having defined or exact vulnerability lists with weights assigned to specific vulnerabilities according to their criticality.. Vendor processes and services are evaluated and benchmarked so that competent vendors can be approved for conducting the desired security scans and testing of payment-by-card industry entities under the Payment Card Industry Data Security Standard or other standards.

Description

QUALIFICATION OF SCANNING VENDORS FOR IMPLEMENTING PAYMENT CARD INDUSTRY SECURITY PROCEDURES

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application Serial No.

60/81 1,983, filed June 8, 2006, which is incorporated by reference herein in its entirety.

BACKGROUND OF THE INVENTION

Smart card technology is fast becoming commonplace in our culture and daily lives. A smart card is a card that is embedded with either a microprocessor and a memory chip or only a memory chip with non-programmable logic. The microprocessor card can add, delete, and otherwise manipulate information on the card, while a memory-chip card (for example, pre-paid phone cards) can only undertake a pre-defined operation. Smart cards, unlike magnetic stripe cards, can carry all necessary functions and information on the card. Therefore, they do not require access to remote databases at the time of the transaction.

Smart cards, which are also generally referred to by the industry as "microprocessor cards" or "chip cards", offer greater memory storage and security of data than a traditional magnetic stripe cards. Smart cards may have up to 8 kilobytes of RAM, 346 kilobytes of ROM, 256 kilobytes of programmable ROM, and a 16-bit microprocessor. A smart card uses a serial interface and receives its power from external sources like a card reader. The processor uses a limited instruction set for applications such as cryptography. The smart cards are used for a variety of applications, especially those that have cryptography built in, which require manipulation of large numbers. Thus, smart cards have been the main platform for cards that hold a secure digital identity. The most common smart card applications are:

* Credit cards

* Electronic cash * Computer security systems

* Wireless communication

* Loyalty systems (like frequent flyer points)

* Banking

* Satellite TV * Government identification

Delivering security - i.e. ensuring access is granted only for authorized usage by authorized cardholders - is the fundamental attribute of smart cards. The effectiveness of smart cards in delivering security is one of the reasons they have been so widely adopted, especially in financial services and mobile phones, why the growth of smart cards has been explosive, and why their usage is expected to expand rapidly for other applications such as personal identity cards, access to pay TV/entertainment, health care services and transportation. Assignee MasterCard makes a smart card based authentication solutions (e.g., a program called the Chip Authentication Program (CAP)) available to card issuers. CAP can also be used for Internet banking and other applications requiring positive cardholder authorization. (See e.g. International patent publications WO/2005/001618, WO/2003/081832, and WO/2001/027887 all of which are incorporated by reference herein).

For contactless payment card systems to be economically viable and to gain commercial acceptance, the contactless payment cards must be interoperable at all or most RFID-enabled payment terminals, even when the cards and terminals have technological features that are proprietary to specific card providers/issuers, vendors or terminal manufacturers. Industry-wide interoperability is desirable. Towards this end, industry standards organizations and groups (e.g., International Organization for Standards (ISO) and International Electro Technical Committee (IEC)) have formulated voluntary industry standards for implementation of contactless smart card payment technologies. Three such exemplary standards which have been defined by ISO/IEC are the ISO/IEC 10536, ISO/IEC 14443, ISO/IEC 15693 standards applicable to Close Coupling, Proximity and Vicinity cards, respectively.

Recently, assignee MasterCard International Incorporated ("MasterCard") has developed proprietary specifications MasterCard Pay Pass™ ISO/IEC 14443 Implementation Specification ("Pay Pass") for implementation of proximity (contactless) payment card technologies. PayPass is a RFID-enabled contactless payment platform, which lets users tap or wave a device in front of a special reader in order to process a transaction. The use of new technologies creates an environment in which although many transactions still take place in a face-to-face situation, an increasing amount of purchases are made online, over the phone, or through the mail — where there is no card present. This environment requires reevaluation of data security procedures and fraud prevention procedures in the payment-by-card industry. Recently, the payment card industry has adopted a common standard, namely the Payment Card Industry (PCI) Data Security Standard, for the secure handing of cardholder information. All subscribing entities involved in processing e-commerce electronic payment transactions, regardless of size, volume, industry or sales acceptance channel must be compliant with the PCI Data Security Standard. MasterCard provides a program ("SDP program"), which is designed to help members, merchants and service providers - Third Party Processors (TPPs) and Data Storage Entities (DSEs) - to proactively protect themselves and the overall payment system against the threat of compromises. The SDP Program seeks to accomplish this by identifying vulnerabilities in security processes and procedures. The participating members, merchants and service providers' compliance with the PCI Data Security Standard may be verified by onsite reviews, security self- assessments, and third-party security scans. Vendors who can help with the often complex nature of information security may conduct the security scans. The vendors may conduct system penetration testing to ensure compliance with the PCI Data

Security Standard. See e.g., "Security Scanning Requirements for Vendors," March 2005, https://sdp.mastercardintl.com/pdf/srv_entire_manual.pdf., which is incorporated by reference herein in its entirety.

Consideration is now being given to improving procedures for security compliance by entities in the electronic payment-by-card industry. In particular attention is directed to procedures for qualifying vendors who provide security scans for compliance with PCI Data Security Standard or other standards.

SUMMARY OF THE INVENTION

A system and method for qualifying vendors, who conduct security scans and testing of the infrastructure, facilities and procedures of the entities (e.g., merchants, and service providers) involved the payment-by-card industry, is provided. The qualification of vendors can ensure compliance with security standards in the payment-by-card industry.

The system and method present the vendors with simulated data situations (e.g., an emulated merchant site) including defined or exact set of vulnerabilities. The set of vulnerabilities is designed with weights assigned to specific vulnerabilities according to the criticality of the vulnerabilities. The set is updated periodically to reflect contemporary threat situations. The emulation site includes a series of highly defined electronic environments that include Known, Quantified and Ranked series of flaws, misconfigurations and errors.

A candidate vendor is allowed access the electronic environments at a fixed time by the opening of a remote access e-gate for a test period of time in which the vendor must discover as many Known, Quantified and Ranked flaws as the vendor can in the allotted test period using the vendor's own testing systems and procedures. The vendors scan the simulated data situation to identify vulnerabilities therein according to the vendor's capabilities. The vendors' success (or lack of success) in identifying vulnerabilities is evaluated and scored. Vendors are qualified according to their scores.

In an embodiment of the invention, the vendors capabilities are evaluated with respect to and established set of requirements, which is listed in Appendix A.

BRIEF DESCRIPTION OF THE DRAWINGS Further features and advantages of the disclosed subject matter will become apparent from the following detailed description taken in conjunction with the accompanying figures showing illustrative embodiments of the disclosed subject matter, in which:

FIG. 1 is a schematic illustration of a test site, which emulates a merchant site, for testing the capabilities of scanning vendors, in accordance with the present invention.

FIG. 2 illustrates an exemplary process for vendor compliance verification, in accordance with the present invention. FIG. 3 is a schematic illustration of exemplary organizational groups and processes that may be involved in implementing process 200, in accordance with the present invention.

FIG. 4 illustrates further details of the organizational processes involved in implementing the process of FIG. 2, in accordance with the present invention.

FIG. 5 is a schematic illustration of the dynamic characteristics of the accreditation system and process that can accommodate changes in technology and evolving vulnerabilities in or threats to payment-by-card infrastructure and data.

DESCRIPTION QF THE INVENTION

A system and method for qualifying vendors, who conduct security scans and testing of the infrastructure, facilities and procedures of the entities (e.g., merchants, and service providers) involved the payment-by-card industry, is provided. The vendors may seek to conduct security scans and testing to ensure that a particular payment-by-card industry entity is in compliance with the PCI Data Security Standard or other standards.

According to the inventive system and method, vendors are required to demonstrate their skill in data security validation trials. In the validation trials, vendor processes and services are evaluated and benchmarked so that competent vendors can be certified or designated as approved for conducting the desired security scans and testing of entities under the PCI Data Security Standard or other standards. The validation trials present vendors with simulated data situations with defined or exact vulnerability lists and established criteria to select them. The simulated data situations may be presented to vendors electronically via a simulation test site (e.g., FIG. 1, Emulated Merchant Test Site 1 10). The data simulations are designed with weights assigned to specific vulnerabilities, and with a defined methodology for assigning a certification score to a vendor seeking certification or approval. The defined scoring methodology is rigorous and assigns scores based on assessments of the criticality of the vulnerabilities tested. Vendors may be certified or put on a list of approved vendors according to their certification scores.

Exemplary validation trials of the scanning vendors are based on processes that rate performance of software security scanners, methods that rate the execution of passive penetration, and testing and methods that rate the execution of both on-site (i.e. customer site) and remote wireless scans. The validation trials are advantageously designed to allow accurate determination of compliance to the scanning vendor standard and permit objective comparison of vendor capabilities. The validation trials can include or extend assessments of vendor capabilities to web applications, in addition to conventional payment network components. The validation trials of the scanning vendors may include a method to assess the performance of scanning vendors when conducting passive penetration testing at web sites. Passive penetration testing is desirable, as industry entities cannot afford disruptive penetration testing.

Further, the validation trials are designed flexibly to accommodate evolving technology. For example, the validation trials may include assessments of the performance of scanning vendors when conducting wireless security testing at web sites. As wireless security testing requires specific skills and is bound to the topology of the scanned site, a number of constrains must be taken in consideration for effective security scanning. The validation trials structure and methodology are designed accordingly. The simulated data situations used in the validation trials ("Credit Card Transactions Vulnerability System Scoring" (CCTVSS)) by assignee MasterCard include a series of highly defined electronic environments, which are exclusively operated for the CCTVSS. The highly defined electronic environments are designed to include a Known, Quantified and Ranked series of flaws, misconfigurations and errors. Vendors seeking certification (i.e. test subjects) are allowed to enter or access the electronic environments at a fixed time by the opening of a remote access e-gate. The test subjects are allotted a test period of time in which they must discover as many Known, Quantified and Ranked flaws as they possibly can in the allotted test period using their own testing systems and procedures (e.g. their own Vulnerability Testing Systems). The results are scored. The complete IT system configuration, numbered vulnerabilities and methodology of scoring are kept in several binders at Assignees' Waterloo, Belgium facility, which binders are incorporated by reference herein in their entireties. The scoring system is aligned with industry standards. Additionally, the scope of testing may include both testing the security of pure network components as well as that of web applications and wireless configurations. The CCTVSS may be configured using off-the-shelf hardware and software.

An exemplary program ("SDP Vendor Compliance Testing Progam") has been set up to ensure the availability of qualified security scanning vendors to verify security in merchants' web sites, as required by the MasterCard's Site Data Protection (SDP) program. The security scanning vendors may range from global audit or security organizations (such as KPMG, Verisign or Symantec) to independent local firms (such as Secure20 or Secure Verification Services Inc.).

The technical part of the vendor accreditation process includes an assessment of security skills of the security vendors enrolled in the program. Under the program scanning vendors must demonstrate that by means of a remote test scan in an IT infrastructure test bed they are able to identify and report vulnerabilities commonly encountered in web sites. The IT infrastructure test bed may simulate data situations at members, merchants, TTPS, DSEs, and/or other payment-by-card industry entities or organizations. The Third Party Processor (TPP) may be any service provider (e.g., an MSP) that performs transaction and cardholder processing Program Services for one or more members. The Data Storage Entity (DSE) may be an organization, other than a member, merchant, or TPP that stores and has access to MasterCard account data. Examples of DSEs include, but are not limited to, Web hosting companies, payment gateways, terminal drivers and processors. Upon successful or satisfactory demonstration of their vulnerability identification skill, the vendors are posted in MOL and may be subject to a periodic (e.g. a yearly) revalidation process.

SDP Vendor Compliance Testing Progam can be an important element of a security framework for payment card products used in the e-commerce space. The SDP Vendor Compliance Testing Progam requires members/entities to determine compliance of their merchants and services based on reports issued by approved vendors, as prescribed in the SDP mandate. The SDP Vendor Compliance Testing Progam supports the creation of a pool of approved vendors, essential for member compliance to SDP program and the deployment of security programs by members at their merchants and service providers. The SDP Vendor Compliance Testing Progam further ensures vendors are up to the security level required by a payment card association (e.g., MasterCard), and ensures the vendors' continued compliance.

The SDP Vendor Compliance Testing Progam can align of data protection initiatives of an entity in the financial industry with that of other payment associations. The testing program can be the single source of vendor certification for the data protection programs of all global payment associations under the PCI Data Security initiative for e-commerce security and the protection of cardholder data.

The inventive system and method for qualifying scanning vendors deploy a measurable set of criteria to benchmark scanning vendors. The inventive system and method may be used to establish elite of such security organizations/vendors throughout the world.

Under an accreditation program run by a payment card association (e.g. MasterCard), testing services are provided to scanning vendors. FIGS. 1-5 show structural, process and functional aspects of the accreditation program. Under the program, vendors seeking accreditation demonstrate their scanning skills in an emulated test site 110 run by the payment card association. (See FIG. 1). An exemplary test site emulates a merchant site. Vulnerabilities and mis-configurations are deliberately introduced (baseline of vulnerabilities) in the test site from a state of the art e-commerce security flaw database, which is updated regularly (See e.g., FIGS. 4 and 5).

FIGS. 2 and 4 show an exemplary process for checking compliance of scanning vendor capabilities and services. FIG. 3 shows the exemplary entities and organizations that may be involved in implementing the process of FIGS. 2 and 4. FIG. 3 also shows the relationship and the interactions between these entities and organizations. FIG. 5 shows the dynamic characteristics of the accreditation system and process that can accommodate changes in technology and evolving vulnerabilities in or threats to payment-by-card infrastructure and data. In a preferred embodiment of the invention, under the Security Scanning Vendor Program, scanning vendors are tested against and must satisfy an established set of requirements (Set A), which is listed in Appendix A, to be accredited or placed on MasterCard's approved Scanning Vendors list. With reference to FIG. 1, scanning vendors seeking accreditation or placement on the approved vendors list, demonstrate their scanning skills in a test site 110 run by MasterCard. Test site 110, which emulates a merchant site, includes emulations of cardholder data, wireless access points (WAP), web applications, firewalls, and other features, components, and platforms of the merchant site. A base line vulnerability set of merchant site vulnerabilities and mis-configurations is deliberately introduced in test site 1 10. The base line includes state of the art e-commerce security flaws. The set is updated regularly to keep up with new or changing threats in e-commerce and electronic communications. Test site 110, may be accessed remotely (via the Internet) by vendors for application scanning and network scanning. The candidate vendors are expected to discover and identify the base line vulnerability set by scanning the test site. The establishment of a documented set of base line requirements (e.g., Set A) and the accessibility options allows all vendors to be tested competitively on an equal basis, under the same or similar test circumstances. Candidate scanning vendors may be graded on the tests results, and accordingly successful vendors are selected for approval.

FIG. 2 shows an exemplary compliance verification process 200, which may be implemented for placing candidate vendors on MasterCard's approved Scanning Vendors list. At step 210, vendor 10 applies to testing entity 20 (e.g., MasterCard) for compliance testing. At step 215, MasterCard assess vendor 10 eligibility based for example, on general business criteria. If eligible, vendor 10 may be registered as a candidate vendor for testing. At step 220, a vendor customer interface (to the emulated merchant site) is enabled. At step 225, a scanning test is set up. At step 230, candidate vendor conducts test scans of the emulated sites and provides a scan report (e.g., a listing of the merchant site vulnerabilities and mis- configurations that it was able to identify) to testing entity 20. At step 235, testing entity 20 evaluates the scan report and assesses the test results. At step 245, testing entity may provide notification of the test results, for example, via a letter of compliance, and/or web postings.

FIG. 3 shows the exemplary organizational groups and processes that may be involved in implementing process 200 to generate a Compliant Security Vendor list 390. The organizational groups in the testing entity (e.g., MasterCard) may include, for example, a test team 310, a vulnerability management team 320 and an approval team 330. These teams may interact with other organization groups (e.g., Legal, Steering committees, Fraud management groups and SDP program Groups, etc.). Test team 310 may be the organization group responsible for administering tests to vendors (using testing process 200). The vulnerability management team 320, may be responsible for the design and updating of testing process 200, for example, by updating base line vulnerability set in the emulated test site to reflect contemporary threat circumstances. The vulnerability management team 320 may have or develop vulnerability management process 270 for the design and updating of testing process 200. Approval team 330 may be responsible for implementing approval process 250, which may include establishing suitable selection criteria and evaluation of scan reports generated by candidate vendors 10. According to the results of approval process 250, candidate vendors may be placed on the complaint security vendor list. FIG. 4 is a schematic, which shows the interactive relationships between testing process 200, approval process 250 and vulnerability management process 270 for placing candidate vendors on MasterCard's approved Scanning Vendors list. Testing Process 200 includes Test administration, Information Technology (IT) management and Report review functions with reference to the tests given to vendors and resulting reports. Testing Process 200 is based on a pre-established Scanning Vendor standard. Approval Process 250 is based on a pre-established Approval policy. Approval process 250 begins with candidate vendor registration, and includes, for example, vetting, vendor administration, approval determination, financial management, development strategy, scoring setting, and other functions.

Vulnerability management process 270, which is based on a pre established a vulnerability management policy, identifies and updates the base - line set of vulnerabilities in the test for scanning vendors. Vulnerability management process 270 includes, for example, vulnerability maintenance, IT selection, and scoring system maintenance functions.

Testing Process 200 and approval process 250 may exchange test requests and internal reports, and share commonly accessible vendor data stored in a database. Similarly, Testing Process 200 and Vulnerability management process 250 may exchange share commonly accessible vulnerability data stored in a database. FIG. 6 shows further the role of vulnerability management process 250 in vendor compliance testing and approval. Vulnerability management process 250 involves monitoring public domain information to identify nascent, developing and receding threats and security flaws in e-commerce communications. The information may be analyzed on a dynamic cycle or a response to major event basis to determine when the baseline vulnerabilities set used for vendor evaluations should be modified or updated to reflect contemporary circumstances. New vulnerabilities may be identified from candidate vulnerabilities for addition to the set of active vulnerabilities. Similarly, obsolete vulnerabilities may be removed from the active set of vulnerabilities. It will be understood that the foregoing is only illustrative of the principles of the invention and that various modifications can be made by those skilled in the art without departing from the scope and spirit of the invention.

APPENDIX A

SET A: Requirements for Approved Scanning Vendors (ASVs)

PCI Security Scanning Vendor Program

Introduction - 20

Naming Convention - 20

Scanning Procedures for Merchants and Service Providers - 20

Scanning Solution Requirements

This section identifies the general and technical requirements for scanning solutions used by scanning vendors.

General Requirements for Scanning Solutions - 23

Non-disruptive Nature of the ASV Solution - 23

Fingerprinting - 23

Platform Independence - 24

Accuracy - 24

False Positives Management - 24

Load Balancer - 24

Intrusion Detection System/Intrusion Prevention System - 24

Internet Service Provider Blocked Port - 25

Obsolete environment - 25

Built-in Accounts - 25

Sanity Check - 25

Secure Sockets Layer/Transport Layer Security - 25

Technical Requirements for Scanning Solutions - 27

Scope of the Assessment - 27

Router Check - 28

Firewall Check - 28

Operating System Check - 28

Database Check - 28

Web Server Check - 28

Application Server Check - 28

DNS Server Check - 28

Mail Server Check - 28

Other Application Check - 28

Custom Web Application Check - 29

Wireless Access Point Check - 29

General Requirements for Scanning Solutions

This follow section outlines generic functional requirements.

1. ASVs must:

• Request from customers the list of active external-facing Internet Protocol (IP) addresses, including all network components and devices that are involved in e-commerce transactions or retail transactions that utilize IP to transmit data over the Internet.

• Scan the provided list of IP addresses for known vulnerabilities and mis-configuration issues.

Vendors should scan customers in accordance with this document and any supplementary guidance provided in the Payment Card Industry Security Scanning Procedures document.

2. Non-disruptive Nature of the ASV Solution

ASV solutions must never perform tests that result in damage to the customers' systems or data. The following is a non-exhaustive list of test examples that are not permitted:

• Denial of Service (DoS)

• Buffer overflow exploit

• Brute-force attack resulting in a password lockout

• Excessive usage of available communication bandwidth (a) Fingerprinting

Fingerprinting can reduce the load on the customer environment by eliminating tests that are not relevant to the particular environment.

The ASV scanning solution must conduct an exhaustive fingerprinting scan on all Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports.

3. Platform Independence

Customer platforms are diverse. Each platform has strengths and weaknesses. The ASV solution must cover all commonly used platforms.

4. Accuracy

In addition to confirmed vulnerabilities, ASVs must report all occurrences of vulnerabilities for which there is a reasonable level of identification uncertainty. When the presence of a vulnerability cannot be determined with absolute certainty, the potential vulnerability must be reported as such.

5. False Positives Management

The customer may point out to the ASV that vulnerabilities identified in the scanning report are false positives: In this case:

• The ASV must assess the pertinence of the customer statement, and make a final determination. The report should be amended by the ASV as necessary

• The customer must not be allowed to edit the scanning report.

• Any scan must not reduce its search space by discarding any previously reported false positives.

6. Load Balancer

The ASV should obtain the "written" assurance from the customer that the infrastructure behind the load balancers is perfectly synchronized in terms of configuration. The configuration and the customer assurance must clearly be documented in the scan report.

If the assurance could not be obtained, the components must be individually scanned from an internal location (behind the load balancers).

7. Intrusion Detection System/Intrusion Prevention System

Under no circumstance should an IDS/IPS (intrusion prevention system) interfere with the results of a vulnerability assessment.

When the infrastructure contains an IDS, the following options should be considered:

• The IDS/IPS should be disabled for specific IP addresses (the originating IP addresses of the ASV). This is the preferred solution.

Or

• The ASVs should scan from a network location where the IDS/IPS can not interfere with the operation. 8. Internet Service Provider Blocked Port

It is possible that a packet does not reach the customer environment during the scan procedures. The absence of a meaningful reply may result in misleading report conclusions.

This situation may occur when an Internet Service Provider (ISP) that is used to carry traffic during the scanning procedures blocks potentially harmful packets. For example, Network basic input/output system (NetBIOS) ports of Microsoft®

Windows® systems are usually blocked by ISPs.

Prior to scanning, the ASVs must ensure that there is an unfiltered communication path to the customer's environment.

Note The ASV scanning solution must advise when it detects obsolete software

9. Obsolete environment

The ASV must report and determine as non compliant any identified obsolete software (e.g. application software, Operating Systems, etc) when these are no longer supported by the respective manufacturers.

If the SSL version installed on a component is limited to V2, then the component must be considered non compliant

Note A component must be considered non compliant if the installed SSL versi limited to V2

10. Built-in Accounts

The ASV scanning solution used for testing built-in, or default accounts in router, firewalls, OS Web servers, relational database management system (RDBMS) servers, applications, etc., must:

• not use a brute-force attack or dictionary attack, but should concentrate on known built-in or default accounts

• report on services that are available without authentication

11. Sanity Check

The ASV scanning solution must be able to detect and report any backdoor applications and worms installed on the servers.

12. Secure Sockets Layer/Transport Layer Security

The ASV scanning solution must be able to test for the presence of Secure Sockets Layer (SSL)/Transport Layer Security (TLS). The ASV scanning solution should check for the SSL version, certificate validity, authenticity, and matching server name.

Technical Requirements for Scanning Solutions

This section outlines the technical specifications for ASV scanning solutions. 13. Scope of the Assessment

Following is a non-exhaustive list of services, devices, and operating systems that must be tested.

Device Type

Operating _AIχ®_{5 B}SD variants, including FreeBSD, Open BSD,

Systems NetBSD, Linux, Sun Solaris™, Microsoft® Windows®

Web Servers Leading Web servers, including Apache, Lotus® Domino, Microsoft® HS, and Sun One™

Web Application Leading Web application servers, including BEA Weblogic Servers Server®, IBM Websphere®, Apache Jakarta Tomcat, and

JBOSS

Common Web Commonly found scripts (typically, common gateway Scripts interface [CGI] scripts) written in various languages, particularly e-commerce related scripts (for example, shopping carts and CRM scripts), ASP, and PHP

Database Servers Leading database servers, including IBM DB2®, Microsoft SQL Server™, MySQL®, Oracle®, PostreSQL, and

Sybase®

Mail Servers Leading mail servers, including Lotus® Domino,

Microsoft® Exchange, Netscape® Messaging Server, and SendMail™

Firewalls Leading firewalls, including Check Point®, Cisco PIX®,

Gauntlet, Linux IP chains/tables, NetScreen, and Raptor

Routers Leading routers, including Cisco

Wireless Access Leading Wireless Access Points, including Cisco, LinkSys® Points NETGEAR®, Apple®, Intel®, ORiNOCO, and 3Com®

Common Other common services, including domain name system

Services (DNS), File Transfer Protocol (FTP), Simple Mail Transfer

Protocol (SMTP)

Custom Web The e-commerce application itself must be scanned for Applications application vulnerabilities. (a) Router Check

The ASV scanning solution must be able to test the router for known vulnerabilities and configuration issues in the firmware.

(b) Firewall Check

Firewall products have known vulnerabilities for which patches are released periodically. The ASV scanning solution must be able to test if the firewall is adequately patched.

A common firewall problem is inadequate configuration. The ASV scanning solution must be able to detect and report "open" ports.

(c) Operating System Check

New exploits are discovered routinely for the Operating System (OS), and security patches are released for these flaws. The ASV scanning solution must verify that the OS has been patched for these known exploits.

(d) Database Check

The ASV scanning solution must detect open access to databases. It is possible to make a database accessible over the Internet; however, this is generally not a good practice and is typically not in compliance with the PCI-DSS. New exploits are found regularly for database products. The ASV scanning solution must detect these exploits.

(e) Web Server Check

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

It is not a good practice to allow browsing of directories on a Web server. The ASV scanning solution must scan the Web site and verify that directory browsing is not possible on the server.

The ASV scanning solution must also be able to detect all known common gateway interface vulnerabilities.

(f) Application Server Check

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

(g) DNS Server Check

The ASV scanning solution must be able to detect the presence of a domain name system (DNS) server and detect any known vulnerability and configuration issues, (h) Mail Server Check

The ASV scanning solution must be able to detect the presence of a mail server and detect any known vulnerability and configuration issues, (i) Other Application C heck

The ASV scanning solution must be able to detect the presence of other applications and detect any known vulnerability and configuration issues. Q) Custom Web Application Check

ASVs must be able to detect the following application vulnerabilities and configuration issues from the OWASP top ten list.

1. unvalidated parameters which lead to SQL injection attacks

2. cross-site scripting (XSS) flaws

The presence of application vulnerabilities on a component that may lead to any of the above mentioned attacks must result in a non compliant status for that component

Note Components where vulnerabilities that may lead to XSS and

SQL injection attacks are identified, must not be considered compliant

(k) Wireless Access Point Check

Wireless LANs (WLANs) introduce new information security risks to those companies that deploy them. ASVs should be able to detect known vulnerabilities and configuration issues of WLAN Access Points, if visible from the Internet.

Scan Report Requirements

This section identifies the functional requirements for the scan report.

Scan Report Requirements - 32 -

Report Levels - 32 -

Delivery - 32 -

Report integrity - 32 -

Report Content - 33 -

Severity level assignation - 34 -

Compliance determination - 35 -

Component compliance determination - 35 -

Global Level - 35 -

Scan Report Requirements

After conducting a scan, the ASV should produce a report with findings and recommendations. The report must assess compliance with the PCI scanning requirement at two levels:

1. Each scanned component

2. The global customer infrastructure ASVs must produce reports that meet all the requirements below.

14. Report Levels

Each scanning report must include two physical documents:

• An executive summary with compliance statement and ASV information, and

• Detailed findings and recommendations

15. Delivery

• Reports must be available either by download or e-mail in PDF format.

• Reports must be delivered securely

16. Report integrity

ASVs must be able to verify the integrity of any copies of the report, after they have been distributed.

Introduction

The Payment Card Industry has adopted a single set of requirements for cardholder data protection across the entire industry, which is called the PCI Data Security Standard (PCI DSS).

To validate compliance with the PCI DSS, a merchant, service provider and/or financial institution may be required to undergo an onsite security assessment by a Qualified Security Assessors (QSA) and/or a security scan conducted by an Approved Scanning Vendor (ASV).

This document provides guidance and requirements applicable to ASVs in the framework of the PCI DSS and associated payment brand data protection programs. Security scanning companies that wish to provide scan services in conjunction with the PCI program must comply with the requirements set forth in this document and also must successfully complete the PCI Security Scanning Vendor Testing and Approval Process.

1. Naming Convention

The following terms are used throughout this document.

Term Definition

Customer Merchant, Service Provider, or other entity that is undergoing a PCI scan

Component Any physical or virtual device residing on the customer network Service Provider Third party processors, payment gateways and other organizations that store, transmit or process payment card information

ASV Approved Scanning Vendor, Data security firm using a scanning solution to determine PCI compliance of their customers

Scanning solution Set of security services offered by a scanning vendor to validate compliance of a merchant or service provider to the PCI Data Security Standard. The scanning solution includes the scanning procedures, the associated scanning report and the process to exchange information between the scanning vendor and its customer.

Scanning Procedures for Merchants and Service Providers

To be considered compliant with the PCI DSS validation requirement, merchants and service providers must scan their infrastructures in accordance with the Payment Card Industry (PCI) Security Scanning Procedures document. 17. Report Content

The high-level report must include:

• A table of contents

• The following statement:

• "This report was generated by an PCI Approved Scanning Vendor, (insert scanning vendor name), under certificate number within the guidelines of the PCI data security initiative."

• MasterCard expects the ASV to recommend to the member whether or not a merchant meets the scanning requirements of the PCI data security standards, based on the content of the scan report. To clearly facilitate this, the first sentence of the executive summary must contain the following sentence:

"(ASV Name) has determined that (Merchant Name/ Service Provider Name) is (COMPLIANT or NOT COMPLIANT) with PCI scan validation requirement."

• A global statement on the customer compliance (see

"Component and Customer Compliance")

• A table listing each scanned Internet Protocol (IP) address and

Corresponding Compliance Status (see "Component and Customer Compliance")

• A description of the severity level system used by the ASV (to prioritize solutions associated to vulnerabilities and mis- configurations))

• The date when the scan was conducted and the report was generated

The detailed report must be readable and accurate, and it must include:

• A table of contents

• Vulnerabilities sorted by IP address and severity, with the most critical vulnerabilities listed first

• A detailed statement for each vulnerability found on the customer infrastructure, including: name industrial reference numbers such as CVE, CAN or

Bugtraq ID severity level the CVSS¹ base score, as indicated in the NVD² (where available) comprehensive explanation solution or mitigation

References to the companies/organizations that provide the solution for the vulnerability (if available)

• For each IP address, a consolidated solution/mitigation plan

18. Severity level assignation

In order to assist customers in prioritizing the solution or mitigation of identified issues, ASVs should assign a severity level to each identified vulnerability or mis configuration.

The designation of each severity level must enable a easy comparison between levels.

Therefore a severity ranking which is easy to understand must be presented, such as with levels Low Priority, Medium Priority and Urgent.

¹ http://www.first.org/cvss/

² http://nvd.nist.gov/cvss.cfm 19. Compliance determination

(a) Component compliance determination

ASVs must determine component compliance based on the following prioritized list.. To be considered compliant, a component must not contain any vulnerability that:

1. Contributes to the non compliance determination as described elsewhere in this document

2. Has been assigned a CVSS base score equal to or higher than 4.0

3. Could lead to data compromise.

Note Vulnerabilities or mis configurations that may lead to Denial of

Service should not be taken into consideration by the ASV when determining component compliance

(b) Global Level

To be considered compliant, all components within the customer infrastructure must be compliant.

Claims

WE CLAIM:

1. A method for qualification of a scanning vendor who conducts security scans and testing of the infrastructure, facilities and procedures of the entities (e.g., merchants, and service providers) involved the payment-by-card industry to ensure compliance with security standards, the method comprising: presenting the vendor with a simulated data situation with a defined or exact set of vulnerabilities therein; having the vendor scan the simulated data situation to identify vulnerabilities therein according to the vendor's capabilities; evaluating the vendor's vulnerability identification results, and accordingly qualifying the scanning vendor for conducting the desired security scans and testing of entities.

2. The method of claim 1 , wherein presenting the vendor with a simulated data situation comprises presenting an emulated test site to the vendor.

3. The method of claim 1, wherein presenting the vendor with a simulated data situation with a defined or exact set of vulnerabilities therein comprises presenting a set of vulnerabilities designed with weights assigned to specific vulnerabilities according to the criticality of the vulnerabilities, and wherein evaluating the vendor's vulnerability identification results comprises assigning certification scores to the vendor based on assessments of the criticality of the vulnerabilities identified.

4. The method of claim 1, wherein evaluating the vendor's vulnerability identification results comprises evaluating rating performance of any one of software security scanners, execution of passive penetration, execution of on-site (customer site) and remote wireless scans.

5. The method of claim 1 , wherein presenting the vendor with a simulated data situation comprises presenting an emulated merchant test site electronically.

6. The method of claim 1, wherein the simulated data situations include a series of highly defined electronic environments that include a Known, Quantified and Ranked series of flaws, misconfigurations and errors, the method further comprising allowing a candidate vendor to access the electronic environments at a fixed time by the opening of a remote access e-gate for a test period of time in which the vendor must discover as many Known, Quantified and Ranked flaws as the vendor can in the allotted test period using the vendor's own testing systems and procedures.

7. The method of claim 1 , wherein evaluating the vendor's vulnerability identification results comprises evaluating the vendor's capabilities with respect to and established set of requirements, which is listed in Appendix A.

8. The method of claim 1, further comprises updating the set of vulnerabilities to include contemporary vulnerabilities.

9. The method of claim 1, further comprises updating the set of vulnerabilities to include contemporary vulnerabilities.

10. A system for qualification of a scanning vendor who conducts security scans and testing of the infrastructure, facilities and procedures of the entities (e.g., merchants, and service providers) involved the payment-by-card industry to ensure compliance with security standards, the system comprising: an emulated test site presenting simulated data situations to the scanning vendor, wherein the test site includes a series of highly defined electronic environments with a Known, Quantified and Ranked series of flaws, misconfigurations and errors; and means to allow the vendor access to the electronic environments at a fixed time by the opening of a remote access e-gate.

11. The system of claim 10, wherein the highly defined electronic environments include emulations of pure network components, web applications and wireless configurations and any combination thereof.