Policies and Procedures on Data Security

Data Security – PCI, FACTA and Breach

Program Management

Policies & Procedures

Workbook

ATMIA-WestSeptember 2007

Disclosure: This document is Copyrighted by ThoughtKey, Inc. ATMIA Members are entitled to a copy of this document however are restricted from reselling this document and the related contents in any manner without prior written consent from ThoughtKey, Inc. For questions regarding distribution please email [email protected].

Page 1 of 42

September 2007 v 1.0 ThoughtKey, Inc. Copyright

mailto:[email protected]

Data Security - PCI, FACTA and Breach Program ManagementPolicies & Procedures

Workbook

Purpose............................................................................................................................................................3Reference Information...................................................................................................................................3

I. VISA Rules for Card Acceptance – Transaction Receipt Requirements (Card) Present...................3II. FEDERAL AND STATE LAWS......................................................................................................3III. Payment Card Industry Data Security Standard (PCI DSS) (Version 1.1, Release September 2006)

4IV. On-Line Resources.............................................................................................................................5

..........................................................................................................................................................................5Overall Policy Statement...............................................................................................................................51.0 General......................................................................................................................................................61.1 Sample Policy Statement – Management Ownership...........................................................................62.0 Defining Data Security Scope..................................................................................................................72.1 Sample Policy Statement – Defining Scope:...........................................................................................73.0 Third Party and other Vendor Selection Requirements.......................................................................83.1 Sample Policy Statement – Selection and Tracking..............................................................................83.2 Sample Policy Statement – Periodic Reviews........................................................................................83.3 Sample Policy Statement – Assessor and Scan Vendor Criteria..........................................................94.0 Compliant Hardware.............................................................................................................................104.1 Sample Policy Statement – Compliant Hardware...............................................................................105.0 Implementing Payment Applications (PCI DSS, PABP, State Laws and FACTA).........................105.1 Sample Policy Statement – Implementing Payment Applications.....................................................115.2 Sample Policy Statement – Hardcopy Receipts Requirements (Rules for VISA Merchants, FACTA and State Laws)..............................................................................................................................12

........................................................................................................................................................................12PCI Data Security Standard Compliance..................................................................................................126.0 Build and Maintain a Secure Network.................................................................................................136.1 Sample Policy Statement - Requirement 1...........................................................................................136.2 Sample Policy Statement - Requirement 2...........................................................................................147.0 Protect Cardholder Data.......................................................................................................................157.1 Sample Policy Statement - Requirement 3...........................................................................................157.2 Sample Policy Statement - Requirement 4...........................................................................................178.0 Maintain a Vulnerability Management Program................................................................................178.1 Sample Policy Statement - Requirement 5...........................................................................................178.2 Sample Policy Statement - Requirement 6...........................................................................................188.3 Sample Policy Statement - Requirement 6 (6.5 to 6.6)........................................................................199.0 Implement Strong Access Control Measures.......................................................................................209.1 Sample Policy Statement - Requirement 7...........................................................................................209.2 Sample Policy Statement – Requirement 8..........................................................................................219.3 Sample Policy Statement - Requirement 9...........................................................................................2210.0 Regularly Monitor and Test Networks...............................................................................................2310.1 Sample Policy Statement - Requirement 10.......................................................................................2310.2 Sample Policy Statement - Requirement 11.......................................................................................2411.0 Maintain an Information Security Policy...........................................................................................2511.1 Sample Policy Statement - Requirement 12.......................................................................................2512.0 Reporting...............................................................................................................................................26


Page 2 of 42




Workbook

12.1 Sample Policy Statement – Inventory.................................................................................................2613.0 Data Compromise/Breach....................................................................................................................26Table 1 – Data Types....................................................................................................................................28Table 2 - Payment Card Industry (PCI) Data Security Standard Compliance Levels for Merchants 29Appendix A – Data Security Vendor Checklists........................................................................................29Appendix B - Definitions..............................................................................................................................32

Purpose

The purpose of this policy is to establish rules, procedures and resources to achieve and operate security compliance in accordance with FACTA 1681 c(g) (federal law), state laws, PCI DSS, PCI PED, PABP, and privacy/breach laws. This policy governance shall protect the organization from unauthorized access to sensitive cardholder data thus reducing the risk of federal and state law violations, card network fines and excessive fraud activity.

This document emphasizes the following three (3) business objectives:

Ensure the cardholder environment is protected from unauthorized access. Educate personnel on duties and responsibilities related to cardholder data security. Define business requirements on securing, communicating, maintaining, retaining, and

disposing of cardholder information.

Reference Information

I. VISA Rules for Card Acceptance – Transaction Receipt Requirements (Card) Present

Per the Rules for Visa Merchants, 2006 – Card Acceptance and Chargeback Management Guidelines, Section 5, “Transaction Receipts Requirements – Card Present Merchants”, “all transaction receipts generated from electronic point-of-sale terminals (including cardholder-activated terminals)” shall truncate/mask all but the last four (4) digits of the PAN and effective July 1, 2006, the expiration date also must be truncated/masked on the consumers receipt. The expiration date may also be completely eliminated from the receipt.

The requirement further states that the PAN truncation/masking requirement applies only to “new electronic POS terminals”.

Consumer/Cardholder Receipt (all but the last 4 PAN digits + expiration date)

PAN - XXXXXXXXXXXX5220 or ************5220


Page 3 of 42




Workbook

Expiration Date – XX/XX or ****

II. FEDERAL AND STATE LAWS

FACTA Section 1681 c(g)

The Fair and Accurate Credit Transactions Act (“FACTA”) added sections to the federal Fair Credit Reporting Act (“FCRA,” at 15 U.S.C. Section 1681 et seq.) as of December 4, 2003. The FACTA law is designed to reduce the risks of consumer fraud and identify theft created by improper use or disposal of consumer credit information focused specifically on the PAN combined with the card expiration date on electronically printed consumer receipts. (Note: Excluded from FACTA are transactions in which a card receipt is generated by handwriting or by an imprint or copy of the card).

The FACTA law preempts all individual state laws regarding the consumer receipt PAN and expiration date thus rendering the related state laws unenforceable.

Requirements -

FACTA law contains several provisions, however the “truncation” section specifies two (2) phased effective dates.

Machines or devices in use on or after January 1, 2005 – must be compliant by January 1, 2005

Machines or devices in use before January 1, 2005 – must be compliant by December 4, 2006

The PAN and expiration date on a consumer receipt shall be truncated/masked to at least but the last five (5) digits and the entire expiration date as noted below, at a minimum:

Consumer/Cardholder Receipt (all but the last 5 PAN digits + expiration date)

PAN - XXXXXXXXXXX55220 or ***********55220Expiration Date – XX/XX or ****

Failure to comply with the FACTA law may entitle consumers to the actual damages from merchants as a result of a violation of the Act, as well as statutory damages of not less than $100 up to $1,000.

California Law – Senate Bill 1699


Page 4 of 42




Workbook

Senate Bill 1699 became effective January 1, 2007 adding to the truncation requirements of FACTA by prohibiting the printing of the last five (5) digits of a card number on the merchant receipt.

Merchant Receipt (all but the last 5 PAN digits + expiration date)

PAN - XXXXXXXXXXX55220 or ***********55220Expiration Date – XX/XX or ****

III. Payment Card Industry Data Security Standard (PCI DSS) (Version 1.1, Release September 2006)

Compliance with the twelve (12) Payment Card Industry Data Security Standards (PCI DSS) is required for all entities that stores, processes and/or transmits cardholder data. On-site validation, per the Card Network rules, is required by an independent qualified security assessor for acquirers, processors, service providers, Level 1 merchants, and any breached entity. Remote validation (scans and self assessments) is required as indicated in Table 2 - Payment Card Industry (PCI) Data Security Standard Compliance Levels for Merchants.

Build and Maintain a Secure NetworkRequirement 1 Install and maintain a firewall configuration to protect cardholder dataRequirement 2 Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder DataRequirement 3 Protect stored cardholder dataRequirement 4 Encrypt transmission of cardholder data access on open, public networks

Maintain a Vulnerability Management ProgramRequirement 5 Use and regularly update anti-virus softwareRequirement 6 Develop and maintain secure systems and applications

Implement Strong Access Control MeasuresRequirement 7 Restrict access to cardholder data to a by business need-to-know basisRequirement 8 Assign a unique ID to each person with computer accessRequirement 9 Restrict physical access to cardholder data

Regularly Monitor and Test NetworksRequirement 10 Track and monitor all access to network resources and cardholder dataRequirement 11 Regularly test security systems and processes


Page 5 of 42




Workbook

Maintain an Information Security PolicyRequirement 12 Maintain a policy that addresses information security

IV. On-Line Resources

www.PCISecurityStandards.orghttps://SDP.MastercardIntl.comwww.VISA.com/cispwww.VISA.com/pinwww.Aegenis.comwww.ftc.gov/bcp/edu/pubs/business/alerts

TIP: To request future updates to this document and/or to provide feedback please email ThoughtKey, Inc. at [email protected] or contact Susan Kohl at (678)522-2466.

Overall Policy Statement

“All cardholder information, including PAN and expiration date, payment devices and related applications will be protected in accordance with the Payment Card Industry DSS, PCI PED, PCI PIN, PABP, federal laws, and state requirements”.

1.0 General

1.1 Sample Policy Statement – Management Ownership

“Securing cardholder data will be an ongoing priority of management and emphasized through the policies noted below”.

Ownership for security of cardholder data shall be defined within the following departments, referred to as the “PCI Leadership Team”:

o Information Technologyo Financeo Risko Operationso Sales and Trainingo General Counsel


Page 6 of 42




http://www.ftc.gov/bcp/edu/pubs/business/alerts

http://www.Aegenis.com/

http://www.VISA.com/pin

http://www.VISA.com/cisp

https://SDP.MastercardIntl.com/

http://www.PCISecurityStandards.org/


Workbook

Overall data security ownership will remain with one executive member designated explicitly in the policy.

PCI Team shall read and research all PCI documentation, federal laws and state requirements applicable to protection of cardholder data.

All employees will attend annual cardholder data security training. Such training shall be documented and statistics reported to and governed by the PCI Leadership Team.

PCI Team will develop and maintain data security policies. Such policies shall be reviewed annually, at a minimum, and any modifications properly documented.

Securing of cardholder data will be integrated into department procedures.

Procedure Prompts: Identify PCI leaders and team members. Maintain a list of all resources used to address data security requirements with PCI,

federal laws and state requirements. Such a list can be used as a “toolbox” for other policy and procedure steps. (See Reference Information above.)

Identify all business activities that control and/or access cardholder data. Develop procedures for business activities that controls and/or accesses cardholder data.

Maintain an audit log of each department and procedure. Develop employee cardholder data security training. Ensure all impacted departments’

needs are addressed during training development – a specific training can be prepared separately for each department, if needed.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


Page 7 of 42




Workbook

2.0 Defining Data Security Scope

2.1 Sample Policy Statement – Defining Scope

“The cardholder environment shall be clearly defined, documented and approved by the PCI Leadership Team”.

Procedure Prompts: Prepare a listing of all business areas where cardholder data is stored, transmitted and/or

processed including record retention data. Map the flow of such cardholder data identifying the various departments and personnel

with access to such data. Identify within the map external access points (both incoming and outgoing). Identify what type of cardholder data (see Table 1 – Data Types) is included at each step

and what systems/devices where cardholder data can be accessed. Identify all third parties that have access to cardholder data. Each environment should be

documented using the steps above. (See also Appendix A – Data Security Vendor Checklists)

All documentation will be reviewed at least annually and upon any significant changes in the environment.

TIP: The above steps may also be used in conjunction with your Sarbanes-Oxley, FDICIA, and Privacy Protection control programs.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

3.0 Third Party and other Vendor Selection Requirements


Page 8 of 42




Workbook

3.1 Sample Policy Statement – Selection and Tracking

“All third parties and/or vendors that may have access to or impact security of cardholder data shall meet the minimum standards as defined in the “Data Security Vendor Checklist” (See .)

Procedure Prompts: Business owners shall complete the “Data Security Vendor Checklist” for each third

party and/or vendor with access or impact to the cardholder environment. Such Checklists shall be reviewed by the appropriate PCI Team.

“Data Security Vendor Checklist” shall be reviewed, initially and at least annually, by PCI Teams for each third party and vendor.

Maintain a list of all third parties that may have access to cardholder data. Maintain a list of all vendors whose products are being purchased and implemented into

the cardholder environment. Maintain a centralized status list of all Checklists required, submitted, pending, approved,

and next review date. Contracts will be executed with each party that has access cardholder data on our entities

behalf. Such contracts will include PCI and Federal and State Law requirements.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

3.2 Sample Policy Statement – Periodic Reviews

“Periodically, at a minimum annually, all third parties and/or vendors that may have access to or impact security of cardholder data shall be reviewed and approved in accordance with the “Data Security Vendor Checklist” to ensure policy compliance.” (See .)

Procedure Prompts: Maintain a centralized status list of all Checklists required, submitted, pending, approved,

and next review date.


Page 9 of 42




Workbook

Business owners shall complete and update the “Data Security Vendor Checklist” for each third party and/or vendor with access or impact to the cardholder environment. Such Checklists shall be reviewed by the appropriate PCI Team member.

The updated “Data Security Vendor Checklist” shall be reviewed by the PCI Team for each third party and vendor at least annually.

Prepare notification letters to third parties and/or vendors for periodic review information needed. This can be combined with your “Vendor Management Program” if one is required.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

3.3 Sample Policy Statement – Assessor and Scan Vendor Criteria

“The PCI Team shall engage a qualified security assessor (QSA) and/or approved scan vendor (ASV), as defined by the PCI and Card Networks requirements, as soon as it is determined cardholder data is stored, process and/or transmitted.” (See www.pcisecuritystandards.org or for a list of such QSA and ASV vendors.)

Procedure Prompts: Select an assessor and/or scan vendor from the approved list. See

www.pcisecuritystandards.org. Evaluate at least 2 assessors/scan vendors for quality and cost. Collaborate with the qualified security assessor to define the PCI DSS scope based on the

steps in 2.1 Sample Policy Statement – Defining Scope.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


Page 10 of 42



http://www.pcisecuritystandards.org/



Workbook

4.0 Compliant Hardware

4.1 Sample Policy Statement – Compliant Hardware

“All payment devices and hardware will be compliant with the various PCI (PCI DSS, PCI PIN, and PCI PED) and other terminal security requirements”.

Procedure Prompts:

For PCI PIN requirements and policy workbook examples refer to the ATMIA’s ATM Policy and Procedure Workbook.

All PED devices should be verified for compliance against the Visa’s approved device list and published PED vulnerable lists (www.visa.com/pin). Only compliant devices will be installed and active in the card environment.

Written attestation will be requested from all device manufacturers 1not listed on the VISA approved lists regarding their compliance with PCI PED, PCI DSS (data storage) and truncation requirements. If such an attestation cannot be obtained, the device will be decommissioned.

An inventory of invoices, serial number of all payment devices (POS terminals, PIN Pads, ATMs, & EPP, attestations from manufacturers, print-out of the various PCI list (identifying the device as compliant), etc. will be maintained for one (1) year beyond the date of such devices being decommissioned.

Installation manuals will be obtained for all devices to ensure the device is installed into the card environment and upgrades performed in a PCI compliant manner.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

1 If the payment device(s) was received directly from an acquirer, processor or other third party, an attestation may be requested from these parties. In some cases the independent third parties will install custom programs on the devices preventing the manufacturer from having sufficient information to attest to the PCI compliance.


Page 11 of 42



http://www.visa.com/pin


Workbook

5.0 Implementing Payment Applications (PCI DSS, PABP, State Laws and FACTA)

5.1 Sample Policy Statement – Implementing Payment Applications

“Only data security compliant applications shall be purchased and implemented in the cardholder environment.” (See www.visa.com/cisp.)

Procedure Prompts: Only payment applications that have been validated in accordance with the PABP

standards will be installed/used. See www.visa.com/cisp - payment applications. An inventory of invoices, payment application name, manufacturer, application version,

(full version, updates, patches, etc) and installation location (both the name and type of device installed in and what physical merchant location/store) will be maintained in a centralized location for all payment applications.

Require a PABP and/PCI attestation from payment application vendors (or the distributor if one is used), and print-out the PABP list (identifying the application version as compliant).

Obtain and utilize the payment application vendor-supplied implementation manual to install the related payment application into the card environment in a PCI compliant manner.Tip: If a 3rd party installs or upgrades the payment application, require them to sign an attestation confirming the application was installed in accordance with the PABP compliant installation manual and the PCI DSS standards (provide them with a copy of such requirements at the time of installation).

Ensure that the proper version and patch numbers have been cross referenced as a validated product on the PABP list. (If the version and patch number purchased is in the process of being PABP validated, obtain a written attestation from the vendor stating the specific payment application (including version) is PABP/PCI compliant. If such an attestation cannot be obtained such an application should not be installed until PABP validation is completed.

Designate a business owner within your business to monitor updates to the payment application that may impact PCI compliance in your cardholder environment. Sign up for vendor application alerts and newsletters.Tip: Discuss with the payment application vendor their plans for modifications/upgrades in the near future. Budget for the costs and/or negotiate the upgrades in your purchase price to minimize future costs (such an installation costs, version compatibility, etc.). Ensure the purchased version will be compatible with future required upgrades (in other words to meet the future defined requirements).

All vendor payment application updates will be installed as soon as practical, no later then thirty (30) days, with the proper testing performed before installation.

All updates (changes, upgrades, modifications, etc.) will be tracked in an audit log.


Page 12 of 42



http://www.visa.com/cisp



Workbook

All PABP and PCI documentation will be retained in a centralized location and disposed of one (1) year after decommissioning the software.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

5.2 Sample Policy Statement – Hardcopy Receipts Requirements (Rules for VISA Merchants, FACTA and State Laws)

“All hardcopy payment (credit and debit) receipt information shall be masked/truncated in accordance with VISA requirements, FACTA federal law and the state laws of which such receipts are provided”.

Procedure Prompts: All electronic card present payment devices/applications will be programmed to mask the

all but the last four (4) digits of the cardholder number (PAN) AND the entire expiration date on the cardholder receipt.

All electronic card present payment devices/applications in California will be programmed to mask the all but the last four (4) digits of the cardholder number (PAN) AND the entire expiration date on the cardholder and merchant receipts.

All payment devices/applications will be reviewed quarterly to for proper programming to truncate/mask the appropriate data. A review log will be maintained and reviewed by the appropriate PCI Team member. The log will be maintained for a minimum of two (2) years.

Tip: The risk associated with non-truncated expiration dates are only increased when combined with exposed in combination with more than 5 digits of the PAN, full PIN, CVV/CVC, etc. The expiration date alone creates very little, if any, risk. Your Procedure:____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


Page 13 of 42




Workbook

____________________________________________________________________________________________________________________________________________________________________________________

PCI Data Security Standard Compliance

The following sections identify policies specific to the twelve (12) PCI Data Security Standards. Most of these requirements focus on a network/server based cardholder environment and do not reflect the specific standards required under the PABP, PCI PIN, PCI PED or federal and state laws. Please refer to the other policy sections of this document which cover each standard.

6.0 Build and Maintain a Secure Network

6.1 Sample Policy Statement - Requirement 1

“A firewall configuration will be installed and maintained to protect access to cardholder data including a firewall at each internet connection and between any demilitarized zone (DMZ) and the internal network zone”.

Procedure Prompts: Develop, document and maintain the following:

o a formal process for reviewing (at least quarterly), approving and testing all external network connections and change to the firewall configuration,

o a current network diagram with all connections to cardholder data, including any wireless. The diagram should be reviewed and approved, at least annually, by the PCI Team,

o a description matrix of all groups, roles and responsibilities for logical management of network components.

Justification and documentation will be maintained within a centralized list for any of the following:

o services and ports necessary for business. Such information may be integrated into the network diagram,

o available protocols besides HTTP, and SLL, SSH and VPN,o risky protocols allowed (such as FTP), which includes reasons for use of protocol

and security features implemented,o all firewall and router rule sets including configuration standards for routers.

Build a firewall configuration that:o denies all traffic from “untrusted” networks and hosts, except for protocols

necessary for the cardholder data environment,


Page 14 of 42




Workbook

o restricts connections between publicly accessible servers and any system component storing cardholder data, including any connections from wireless networks include:

Restricting inbound internet traffic to IP addresses within the DMZ (ingress filters)

Not allowing internal addresses to pass from the internet into the DMZ Implementing stateful inspection, also known as dynamic packet filtering

(that is, only “established” connections are allowed into the network) Placing the database in an internal network zone, segregated from the

DMZ Restricting inbound and outbound traffic to that which is necessary for

the cardholder data environment and denying all other traffic Securing and synchronizing router configuration files Installing perimeter firewalls between any wireless networks and the

cardholder data environment, and configuring these firewalls to deny any traffic from the wireless environment or from controlling any traffic (if such traffic is necessary for business purposes)

Installing personal firewall software on any mobile and employee-owned computers with direct connectivity to the Internet which is also used to access the company network

Prohibit direct public access between external networks and any system component that stores cardholder data (for example, databases, logs, trace files, etc.) including:

o Implementing a DMZ to filter and screen all traffic and to prohibit direct routes for inbound and outbound Internet traffic.

o Restrict outbound traffic from payment card applications to IP addresses within the DMZ.

Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT).

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


Page 15 of 42




Workbook


“System passwords and other security parameters will be changed, before installation, from the vendor-default settings to unique settings restricted to those within the business on a need-to-know basis”.

Procedure Prompts: Vendor supplied defaults will be changed before installing a system on the network. For wireless environments, change wireless vendor defaults including but not limited to

the following:o WEP keyso SSIDo Passwordo SNMP community stringso Disable SSID broadcastso Enable WiFi protected access (WPA and WPA2) technology for encryption and

authentication when WPA-capable Develop configuration standards for all system components. Assure that these standards

address all known security vulnerabilities and are consistent with industry-accepted system hardening standards2.

o Implement only one primary function per server (web services, database servers, and DNS should be on separate servers)

o Disable all unnecessary and insecure services and protocols (not needed to perform the devices’ specified function)

o Configure system security parameters to prevent misuseo Remove all unnecessary functionality, such as scripts, drivers, features,

subsystems, and unnecessary web servers Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or

SSL/TLS (transport layer security) for web-based management and other non-console administrative access.

Hosting providers must protect each entity’s hosted environment and data. These providers musts meet specific requirements ass detailed in the PCI DSS version 1.1, Appendix A, “PCI DSS Applicability for Hosting Providers”

Your Procedure:____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

2 As defined by SysAdmin Audit Network Security Network (SANS), National Institute of Standards Technology (NIST), and Center for Internet Security (CIS).


Page 16 of 42




Workbook

____________________________________________________________________________________________________________________________________________________________________________________

7.0 Protect Cardholder Data


“All stored cardholder data shall be protected by using the proper level of encryption, not storing cardholder data, or truncating/masking such data.”

NOTE: See 5.2 Sample Policy Statement – Hardcopy Receipts Requirements (Rules for VISA Merchants, FACTA and State Laws) of this document for hardcopy card receipt requirements of which are not addressed in Requirement 3 of the PCI DSS.

Procedure Prompts: Develop, document and maintain a data retention and disposal policy that limits

cardholder data storage to a minimum as defined by your business, legal and/or regulatory purposes3.

The following data will not be stored4 subsequent to authorization (even if encrypted):

o The full track data (also known as track 1, track 2, track and magnetic stripe data) from the magnetic stripe (that is on the back of the card, in a chip or elsewhere).

o The CVV, CVC, CVV2 codes (three and four-digit number printed on the front or back of a payment card and included in the magnetic stripe data) used to verify card-not-present transactions will not be stored subsequent to authorization.

o The PIN or the encrypted PIN block will not be stored.o TIP: The PAN and expiration date may need to be retained on a network for

business purposes; however the duration of maintaining such information should be limited to the lowest retention period and encrypted in accordance with the standards in Requirement 4.0.

ATM electronic journals shall be configured to log only the last 4 digits of the PAN and not storing PIN data or expiration date of the cardholder.

On networks and on hardcopy documents (excluding customer or merchant receipts) PAN will be masked5 (the first six and last four digits are the maximum number of digits to be

3 Best practice recommendation, mainly for fraud and chargeback recovery, for cardholder data retention (excluding magnetic stripe, CVV, CVC, CVV2 and PIN data) is 2 years.4 Systems components that should be reviewed for data storage requirements include incoming transaction data, transaction logs, history files, trace files, debugging logs, several database schemas, and database contents.5 Other approaches may be used to protect stored cardholder data including strong one-way hash functions (hashed indexes), index tokens and pads (pads must be securely stored), storing cryptography with


Page 17 of 42




Workbook

displayed, however best practice is the last four digits only) or rendered unreadable in the following situations:

o displayed on internal networks/servers, except when the full PAN is needed for business purposes (such as fraud investigation, chargebacks, and data compromise research)

o portable digital mediao backup mediao all logso data received from or stored by wireless networks

Encryption keys used for encryption of cardholder data will be protected against both disclosure and misuse by restricting the access to keys to the fewest number of custodians and storing keys securely in the fewest possible locations.

Document, review and maintain key management processes to include the minimum standards noted below:

o Key generationo Secure key distributiono Periodic changing of keys, at least annually (select an application that perform

automatic key rotation)o Destruction of old keyso Split knowledge and establishment of dual control of keys (must have at least two or

three people, each knowing only their part of the key, to reconstruct the whole key)o Prevention of unauthorized key substitutiono Immediate replacement of known or suspected compromised keyso Revoking old or invalid keyso Each custodian will be required to sign a custodian agreement.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


associated key management processes and procedures.


Page 18 of 42




Workbook

“Encrypt transmissions of cardholder data across open, public networks6. Such transmissions will be limited to business necessary activity”.

Procedure Prompts: Transmission of cardholder data across open, public networks will be encrypted using

cryptography and security protocols such as SSL/TLS and IPSEC. For wireless networks transmitting cardholder data, encryption will include WPA or WPA2, IPSEC VPN, or SSL/TLS.

Cardholder information communication procedures shall be created to include the following rules: Magnetic stripe data such as CVV, CVC, CVV2, and track data will not be

communicated to external parties (other than to appropriate parties as part of transaction authorization using strong encryption).

Truncate all PAN’s and/or encrypt such files (using the minimum encryption standards noted in Requirement 4.0) prior to sending transaction data to external parties which contractually require transaction information transmission (such as acquirers, payment processors, card issuers, independent sales organizations, payment service providers, card networks, etc.).

PAN’s required to be transmitted by email shall be encrypted using one of the methods noted above.

External parties will be encouraged to transmit incoming cardholder data using the same standards noted above.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8.0 Maintain a Vulnerability Management Program


“Anti-virus software will be installed, maintained and used to protect all systems commonly affected by viruses”.

6 Open, public networks include the Internet, WiFi, global system for mobile communications (GSM), and general packet radio service (GPRS).


Page 19 of 42




Workbook

Procedure Prompts: Document procedures for installing and maintaining an anti-virus program. Such

procedures will be reviewed an approved at least annually. Identify and document all systems commonly affected by viruses.

Tip: This information can be integrated on the data map/flow performed in earlier step - 2.1 Sample Policy Statement – Defining Scope.

Select an anti-virus software program capable of detecting, removing, and protecting against other forms of malicious software, including spyware and adware.

Install anti-virus software on all identified systems. Anti-virus software shall be maintained current (set for “automatic updates), actively

running (periodic scans), and capable of generating audit logs.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


“Secure systems and applications shall be developed and maintained to ensure the most recently released, appropriate vendor-provided security patches are installed”. 7

Procedure Prompts: Document procedures to monitor and assign ownership for security patch management. Business critical vendor-supplied security patches will be installed within one (1) month

of release. For developed software applications, such applications will be developed based on

industry best practices and with information security incorporated throughout the software life cycle. Procedures for software application development shall include:

o Document and test security patches and system and software configuration changes before deployment.

o Test and development environments will be separated from the production environment, with access control to enforce separation.

7 For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.


Page 20 of 42




Workbook

o Duties between personnel assigned to the test and development environments and those assigned to the production environment will be segregated.

o Production data (live PANs) will not be used for testing and development, or are sanitized before use.

o Test data and accounts will be removed before a production system becomes active.

o Custom application accounts, usernames and/or passwords will be removed before a system goes into production or is released to customers.

o Custom code will be reviewed (by personnel other than the originating code author) prior to production release or to customers to identify any potential coding vulnerabilities.

Document change control procedures will be established for all system and software configuration changes including the following activities:

o Impact of the changeo Change control documentation will be signed by the appropriate management

personnel defined in the procedureo Operational functionality testing procedureso Clearly defined back-out procedureso Assigned roles and responsibilities

8.3 Sample Policy Statement - Requirement 6 (6.5 to 6.6) “All web applications will be developed based on secure coding guidelines8 including reviews of custom application code to identify vulnerabilities”.

Tip: For externally developed and/or purchased web applications, obtain a written certification/attestation from the vendor that all elements under the PCI Requirement 6 are properly met. Such attestations should be reviewed annually with your vendor or during each significant upgrade of the web application.

Procedure Prompts: Document procedures to include application code reviews for the following

vulnerabilities, at a minimum:o Unvalidated inputo Broken access control (malicious use of User IDs)o Broken authentication and session management (malicious use of account

credentials and session cookies)o Cross-site scripting (XSS) attackso Buffer overflowso Injection flows (SQL injections)

8 See Open Web Application Security Project Guidelines.


Page 21 of 42




Workbook

o Improper error handlingo Insecure storageo Denial of serviceo Insecure configuration management

All web-facing applications will be protected against known attacks by either of the following methods9:

o Custom application code will be reviewed for common vulnerabilities by a vendor that specializes in application security or

o An application layer firewall will be installed in front of the web-facing application.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

9.0 Implement Strong Access Control Measures


“Access to cardholder data will be limited to authorized personnel that have a business need-to-know”.

Procedure Prompts: Access to computer resources (networks, databases and applications) and cardholder

information will be limited to only those personnel whose job requires such access (such as authorization processing, risk, chargebacks, and exceptions).

Access controls will be documented and reviewed regularly, at a minimum annually, to ensure:o Access rights to privileged User IDs are restricted to least privileges necessary to perform

job responsibilities.o Assignment of privileges is based on individuals’ job classification and function.o An authorization form is signed by management that specifies required privileges (such

authorization can be defined and approved by management in a defined policy and/or procedure document or using electronic signature/approval).

9 This step is considered a best practice until June 30, 2008, after which it becomes a PCI DSS requirement.


Page 22 of 42




Workbook

o Access control systems are not set to the default “allow-all” setting.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

9.2 Sample Policy Statement – Requirement 8

“Unique user IDs will be assigned and proper user authentication set for each person with computer access”.

Procedure Prompts:

Document steps and assign responsibility to identify all users, the systems and access levels assigned to each person.

A unique user ID will be assigned to each person with computer access. Each user will be authenticated using either a password, token device (SecureID,

certificates, or public key), or biometrics. All passwords will be encrypted during transmission and storage on all system components.

In addition to password or other authentication methods, two-factor authentication 10for remote access to the network by personnel and third parties will be implemented.

Contract terms with payment service providers will be reviewed to include the requirements noted above.

User authentication and password management procedures for non-consumer users and administrators on all system components will include:

o Controls for addition, deletion and modification of user IDs, credentials, and other identifier objects (only administrators will have access to management consoles for wireless networks).

o User identity will be verified before password resets are performed.o First-time passwords will be unique for each user and be required to change

immediately after the first use. Passwords will follow the minimum requirements:

10 Use technologies such as remote authentication and dial in service (RADIUS) or terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates.


Page 23 of 42




Workbook

Minimum password length of at least seven (7) characters (must contain both alphabetic and numeric characters).

User passwords will be set to require change every 90 days. The password change may not match the any of the last four (4)

passwords used by the individual.o Terminated users access is immediately revoked (within 24 hours). Application

owners and the PCI Team should review access control list regularly against new, terminated and transitioned employees list at least quarterly. Any necessary updates should be made within one (1) month of the review.

o Inactive users will be reviewed and removed accordingly at least every 90 days.o Accounts used by vendors for remote maintenance will be enabled only during

the time period needed.o Group, shared, or generic accounts and passwords will not be used. o Repeated access attempts using a User ID will be locked out after six (6), or less,

attempts.o Lockout duration will be set to thirty (30) minutes or until the administrator

enables the User ID.o A user session idle for more than fifteen (15) minutes will require the user to re-

enter the password to re-activate the terminal.o Access to any database containing cardholder data will require authentication

including access by applications, administrators and all other users.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


“Physical access to data or systems that house (store, process and/or transmit) cardholder data shall be appropriately restricted”.

Procedure Prompts: Document a physical access building policy and procedure including responsibility for

implementation and monitoring as well as the following, at a minimum:


Page 24 of 42




Workbook

o Areas where cardholder data is stored, processed and/or transmitted, electronically or in hardcopy, will be restricted using badge access controls and lock and key, where necessary.

o Cameras will be used to monitor entry/exit points of data centers where cardholder data is stored or present. These cameras shall be internal to the data center and protected from tampering or disabling. Data from the cameras will be stored for at least three (3) months.

o Badge assignment procedures will be defined to clearly distinguish between employees, visitors, and contractors by providing color coded badges.

o Visitor and contractors will be required to sign in when entering the building. Logs of visitors and contractors will be retained for at least three (3) months.

o Steps will be defined for granting new badges, changing access requirements, and revoking terminated employee and expired visitor/contractor badges.

Publicly accessible network jacks, wireless access points, gateways, and handheld devices will be restricted for use only when needed by authorized personnel.

Media back-ups will be stored in an off-site secured facility. Internal and external distribution of any kind of media that contains cardholder data will

be classified/noted so it is easily identified as confidential, sent only via secured courier or other delivery method that can be accurately tracked, and properly approved by management personnel.

An audit log and inventory of all media distribution will be maintained for a minimum of two (2) years, or in accordance with record retention policies.

All paper and electronic media (including computers, electronic media, networking and communications hardware, telecommunication lines, paper receipts, paper reports, audit logs, and faxes) that contain cardholder data will be physically secured in a badge accessed restricted area and/or in a secured locked area.

Media containing cardholder data will be destroyed in accordance with the record retention and destruction policy(ies). The destruction policy defines that such media will be destroyed using one of the required approaches:

o Cross-cut shred, incinerate, or pulp hardcopy materialso Purge, degauss, shred, or otherwise destroy electronic media so that cardholder

data cannot be reconstructed.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


Page 25 of 42




Workbook

10.0 Regularly Monitor and Test Networks


“All access to network resources and cardholder data will be tracked and monitored using audit logs retained for a minimum of one (1) year”.

Procedure Prompts:

Audit logs, per User ID, will be enabled and active (including connected wireless networks) on all system components. Audit logs will be implemented such that the following events can be reconstructed:

o Individual access to cardholder datao Actions taken by any individual with root or administrative privilegeso Initialization and access to all audit logso Invalid logical access attemptso Use of identification and authentication mechanismso Creation and deletion of system-level objects

Audit logs will include at least the following entries for all system components for each event:

o User identificationo Type of evento Date and timeo Success or failure indicationo Origination of evento Identify or name of affected data, system component, or resource

Audit logs will be secured so they cannot be altered by limiting access, backing up the audit logs (to a centralized server that cannot be altered), and use file integrity monitoring.

All critical system clocks and times will be synchronized using NTP or similar technology.

All logs will be reviewed at least daily. Logs will include those servers that perform security functions like IDS and authentication, authorization, and accounting protocol (AAA) servers.

Your Procedure:__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


Page 26 of 42




Workbook

______________________________________________________________________________________________________


“Security systems and processes will be tested regularly in accordance with ISO standards”.

Procedure Prompts:

Security controls, limitations, network connections, and restrictions will be tested annually to assure the ability to adequately identify and stop unauthorized access attempts within the cardholder environment.

Internal and external network vulnerability scans will be run quarterly and after any significant change11 in the network. Scan processes will be rerun until “clean” results are obtained. External scans will be performed quarterly by a PCI qualified scan vendor.

External scan results will be retained for one (1) year. Penetration testing will be performed at least once a year and after any significant

infrastructure or application upgrade or modification and will include both network-layer and application-layer penetration tests. Vulnerabilities will be corrected timely.

Network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems will be used to monitor all network traffic and alert personnel to suspected compromises. All intrusion detection and prevention engines will be kept up-to-date per vendor instructions to ensure optimal protection.

File integrity monitoring software will be deployed to alert designated personnel to unauthorized modification of critical system or content files, and configure the software to perform critical file comparisons at least weekly.

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

11 Such as new system component installations, changes in network topology, firewall rule modifications, and product upgrades.


Page 27 of 42




Workbook

11.0 Maintain an Information Security Policy


“An information security program will be defined and communicated to all employees and contractors”.

Procedure Prompts: An annual, and when the environment changes, formal information security risk

assessment will be performed, documented and vulnerabilities addressed. Daily operational security procedures will define all requirements within this document

and include administrative and technical procedures for each of the requirements. Policies will be required for critical employee-facing technologies (such as modems and

wireless) to define proper use of the technologies and contains the following:o Explicit management approvalo Authentication for use of the technologyo A list of all such devices and personnel with accesso Labeling of devices with owner, contact information and purposeo Acceptable uses of the technologyo List of company-approved productso Automatic disconnect of modem sessions after a specific period of inactivityo Activation of modems for vendors only when needed by vendors, with immediate

deactivation after useo When accessing cardholder data remotely via modem, prohibition of storage

of cardholder data onto local hard drives, floppy disks, or other external media. Cut-and-paste and print functions during remote access will be prohibited.

All information security responsibilities will be clearly defined and updated at least annually to include the following:

o Establish, document and distribute security policies and procedures.o Monitor and analyze security alerts and information and distribute to appropriate

personnel.o Establish, document, and distribute security incident response and escalation

procedures to ensure timely and effective handling of all situations.o Administer user accounts, including additions, deletions, and modifications.o Monitor and control all access to data.

A formal security awareness program will be implemented to make all employees aware of the importance of cardholder data security.

o Employees will be educated upon hire and at least annually. o Employees will be required to acknowledge in writing that they understand the

company’s security policy and procedures. Employees will be screened upon hire to minimize the risk of internal attacks.


Page 28 of 42




Workbook

Service Provider(s) will be contractually required to adhere to and acknowledge adherence to the PCI DSS requirements.

An incident response plan will be implemented with roles and responsibilities clearly defined to include the following:

o Specific incident response procedures and trainingo Business recovery and continuity procedureso Data backup processeso Test procedures/plan at least annuallyo 24/7 designated personnel availability to respond to alertso Modify incident response plan based on lessons learned and to incorporate

industry developments Document and maintain policies and procedures to manage the following:

o A list of all connected entitieso Perform proper due diligence prior to establishing entity connectivityo Validate the entity is PCI DSS Compliant. See www.visa.com/cispo Connect and disconnect entities by following an established process

Your Procedure:________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

12.0 Reporting

12.1 Sample Policy Statement – Inventory

“A list of all payment device(s) information and modification history will be maintained to ensure proper accountability and inventory of PCI compliant information and status”.

Procedure Prompts: Develop, maintain and review an inventory of all payment device (s) and software for all entities

connected to the cardholder environment (directly or indirectly). Inventory listing(s) will be reviewed and approved annually and used to assess necessary

decommissioning plans.


Page 29 of 42





Workbook

A decommissioned list will be retained for at least three (3) years from the date of decommissioning.

ATM and Kiosk Terminals –

Name (Acquirer, Processor, Service Provider, ISO, Merchant Name)

Physical Location Terminal ID Vendor/Distributor Date purchased and installed Type Manufacturer Firmware Serial number PIN Pad used in the terminal (see the

inventory requirements under PIN Pad/Devices below)

POS and Kiosk Terminals –


Physical Location Terminal ID Vendor/Distributor Date purchased and installed Type Manufacturer Firmware Serial number

PIN Pads/Devices -


Physical Location Vendor/Distributor Date purchased and installed Device Type Manufacturer Firmware Serial number Software versions Updates Patches

Payment Applications –


Device Type Vendor/Distributor Date purchased and installed Device installed in (cross reference to the

ATM, POS or other terminal information) Manufacturer Firmware Serial number Software versions Updates Patches

Your Procedure:__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________


Page 30 of 42




Workbook

______________________________________________________________________________________________________

13.0 Data Compromise/Breach

-UNDER CONSTRUCTION-


Page 31 of 42




Workbook

Table 1 – Data Types

PCI DSS requirements are applicable if a PAN is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.

Data Element Storage Permitted

Protection Required

PCI DSS

Req 3.4

FACTATruncation (Consumer

receipt only)

California Law

(Merchant receipt + FACTA)

Cardholder Data

PAN YES YES YES YES YES

Cardholder Name YES YES NO NO NO

Service Code YES YES NO NO NO

Expiration Date YES YES NO YES YES

Sensitive Authentication Data

Full Magnetic Stripe

NO N/A N/A N/A N/A

CVC2/CVV2/CID NO N/A N/A N/A N/A

PIN/PIN Block NO N/A N/A N/A N/A


Page 32 of 42




Workbook

Table 2 - Payment Card Industry (PCI) Data Security Standard Compliance Levels for Merchants

Compliance Actions Validation Actions

Level(s)Comply with

PCI DSS

Identify all Third Parties with Access to Cardholder Data

On Site Security Audit

Performed

Complete a Self -Assessment

Questionnaire

Conduct Network

Scans

Level 1

Any merchant processing over 6,000,000 transactions per year per a single credit card association; or Any merchant that has suffered a “hack” or an attack that resulted in an account data compromise.

Required for all Levels

Required for all Levels –

communicate all such parties to your

processor and/or Sponsor Bank

Required Annually

Optional

Required Quarterly for Levels 1 - 3

Level 2

Any merchant processing 1 million to 6 million transactions per year per a single credit card association.

Optional for Levels 2 - 4

Required Annually for Levels 2 - 3

Level 3

E-commerce merchant processing 20,000 to 1 million e-commerce transactions per year per a single credit card association.

Level 4 (changes expected late 2007)

Any merchant processing less than 20,000 e-commerce and all non-ecommerce transactions channel up to 1 million per year per a single credit card association.

Recommended Annually

Recommended Quarterly

Appendix A – Data Security Vendor Checklists

Question Yes No N/A1. Is a third party vendor (manufacturers, distributors, payment


Page 33 of 42




Workbook

processors, ISOs, etc.) providing a software application to be installed onto your payment network?

2. If the answer to question 1 is “Yes”, have you verified the payment/software application version is listed on the PABP listing as compliant? (See www.visa.com/cisp.) OR a PABP and/PCI attestation provided from payment application vendors. Such information should be verified at least semi-annually (changes are constant and can be critical to your PCI compliance).

Tip: If the vendor does not cooperate, request assistance from your Payment Processor and/or Sponsor Bank.

3. All PED devices are verified for compliance against the Visa’s approved device list and published PED vulnerable lists (www.visa.com/pin). Only PCI PED compliant devices have been installed and active in our card environment.

Tip: If the vendor does not cooperate, request assistance from your Payment Processor and/or Sponsor Bank.

4. If the answer to question 1 is “Yes”, does the third party vendor have access to cardholder data in your environment (including storing, processing and/or transmitting)?

5. If the answer to question 4 is “Yes”, the vendor will be reported to your Payment Processor and/or Sponsored Bank (Tip: both your Processor and Sponsor Bank name can be obtained from your Payment Processing Agreement) as a “Service Provider”. The Processor and/or Sponsor Bank should follow up with the vendor to ensure proper registration.

6. If the answer to question 4 is “Yes”, documentation has been provided from the vendor of their proper registration with the required Card Networks. Verify the registration status with your Processor and/or Sponsor Bank. The list of registered service providers is listed on Visa’s website at www.Visa.com/cisp. See “Service Providers” tab and launch the pdf file. (If such proof of registration cannot be provided AND the Processor and/or Sponsor Bank require registration, your organization will not use this vendor.)

7. A contract has been executed with each vendor that has access to cardholder data relative to our customer base. The contract includes terms requiring full compliance with PCI DSS, PCI


Page 34 of 42



http://www.Visa.com/cisp

http://www.visa.com/pin



Workbook

PED, PABP (for those vendors who do not have access to cardholder data in the authorization and/or settlement process) and federal and state laws.

Tip: Request the vendor provides updates to you immediately when the status of their PCI or PABP or PCI PED changes.

8. The terminals, POS applications and devices in our payment environment print properly truncated receipts in accordance with the Visa and FACTA truncation requirements and other applicable state laws.

9. If the answer to question 8 is no, all terminals, POS applications and devices are identified and updated immediately to limit liability. The date of such updates have been properly logged and retained for our records in accordance with our record retention policy.

10. Installation and/or implementation manuals were provided by all vendors providing applications and/or devices for our payment environment. Default settings were reviewed against the PCI DSS requirements.

(Tip: Payment Application vendors are now required to provide an Implementation manual to customers to ensure all applications are installed in a PCI DSS compliant manner. If your vendor does not have such a manual and/or will not provide the documentation, contact your Processor, Sponsor Bank or Visa directly. In the interim, evaluate the risk associated with using this vendor.)

11. Discussed with the payment application vendor their plans for modifications/upgrades in the near future. Negotiate the upgrades in your purchase price to minimize future costs (such an installation costs, version compatibility, etc.). Ensure the purchased version will be compatible, to the extent possible, with future required upgrades (in other words to meet the future defined requirements). (See www.visa.com/cisp for alerts/updates on requirements.)

12. The selected scan vendor, self-assessment questionnaire review and/or on-site PCI auditor is listed on the qualified/approved listing. (See www.pcisecuritystandards.org or for a list of such QSA and ASV vendors.)

Tip: If the vendor is not listed do not engage this assessor even if they are in the process of obtaining certification – using the vendor will prevent your organization from


Page 35 of 42






Workbook

achieving compliance with the quarterly scan requirements by a qualified assessor/vendor.


Page 36 of 42




Workbook

Appendix B - Definitions

Term DefinitionsApplication Includes all purchased and customer software programs or

groups of programs designed for end users, including both internal and external (web) applications.

Audit Log Chronological record of activities. Provides a trail sufficient to permit reconstruction, review and examination of sequence of environments and activities surrounding or leading to operation, procedure, or event in a transaction from inception to final results. Sometimes specifically referred to as security audit trail.

Cardholder Customer to whom a card is issued or individual authorized to use the card

Cardholder Data Full magnetic stripe or the PAN plus any of the following: Cardholder name Expiration date Service code

Cardholder data environment Area of computer system network that possesses cardholder data or sensitive authentication data and those systems and segments that directly attach or support cardholder processing, storage, or transmission. Adequate network segmentation, which isolates systems that store, process or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment and thus the scope of the PCI assessment.

Card Networks Entities in the payment industry such as Visa, Mastercard, JCB, AMEX, NYCE, PULSE, STAR, CU24, FiServe, ACCEL/Exchange, etc.

Card Validation Value or Code Data element on a card’s magnetic stripe that uses secure cryptographic process to protect data integrity on the stripe, and reveals any alteration or counterfeiting. Referred to as CAV, CVC, CVV, or CSC depending on the payment card brand.

CAV, CVC, CVV and CSC The following list provides the card validation value/code terms for each card brand:

CAV Card Authentication Value (JCP payment cards)

CVC Card Validation Code (MasterCard payment cards)


Page 37 of 42




Workbook

CVV Card Verification Value (Visa and Discover payment cards)

CSC Card Security Code (AMEX)(Data) Compromise Intrusion into computer system where unauthorized

disclosure, modification or destruction of cardholder data is suspected.

Cryptography Discipline of mathematics and computer science concerned with information security and related issues, particularly encryption and authentication and such applications as access control. In computer and network security, a tool for access control and information confidentiality.

PCI DSS Payment Card Industry Data Security Standard

Encryption Process of converting information into an unintelligible form except to holders of a specific cryptographic key. Use of encryption protects information between the encryption process and the decryption process (the inverse of encryption) against unauthorized disclosure.

Magnetic Stripe Data (Track Data I and/or II)

Data encoded in the magnetic stripe used for authorization during transactions when the card is presented. Entities must not retain full magnetic stripe data subsequent to transaction authorization. Specifically, subsequent to authorization, service codes, discretionary data/Card Validation Value/Code, and proprietary reserved values must be purged; however, account number, expiration date, name, and service code may be extracted and retained, if needed for business.

Members Financial Institutions who pay to be institution members with the Card Networks and may be eligible to sponsor third party agents such as Independent Sales Organizations (ISOs), Encryption Service Organizations (ESOs), service providers, payment processors, etc.

Monitoring Use of system that constantly oversees a computer network including for slow or failing systems and that notifies the user in case of outages or other alarms.

Network Security Scan Automated tool that remotely checks merchant or service provider systems for vulnerabilities. Non-intrusive test


Page 38 of 42




Workbook

involves probing external-facing systems based on external-facing IP addresses and reporting on services available to external network (that is, services available to the internet). Scans identify vulnerabilities in operating systems, services, and devices that could be used by hackers to target the company’s private network.

PABP Payment Application Best Practices. The requirements of the PABP are derived from the PCI DSS and the PCI DSS Security Audit Procedures. These documents, which can be found at www.pcisecuritystandards.org , detail what is required to be PCI DSS compliant (and therefore what a payment application must support to facilitate an application user’s PCI DSS compliance) and should be used as a reference for the PCI DSS and supporting documentation.

Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of full magnetic stripe data, card validation codes and values, PINs and PIN Blocks, and the damaging fraud resulting from these breaches.

Payment Cardholder Environment

That part of an organizations network that possesses cardholder data or sensitive authentication data.

PAN Primary Account Number is the payment card number (credit or debit) that identifies the issuer and the particular cardholder account. Also called Account Number.

PED PIN Encryption Device – refers to both the encryption equipment in a PIN pad on a POS or ATM terminal.

PIN Personal Identification Number

Policy Organization-wide rules governing acceptable use of computer resources, security practices and guiding development of operational procedures.

POS Point-of-Sale

Procedure Descriptive narrative for a policy. Procedure is the “how to” for a policy statement and describes how the policy is to be


Page 39 of 42





Workbook

implemented.

Public Network Network established and operated by a telecommunications provider or recognized private company, for specific purpose of providing data transmission services for the public. Data must be encrypted during transmission over public networks as hackers easily and commonly intercept, modify, and/or divert data while in transit. Examples of public networks in scope of PCI DSS include the Internet, GPRS and GSM.

QSA Qualified Security Assessor is required to perform an on-site PCI DSS assessment, where required, network scans quarterly and forensics related to data compromises. These organizations are approved by the Card Networks and PCI SSC and must complete a certification training course.

For a list of the QSA’s see www.PCISecurityStandards.org.

Sensitive Authentication Data Security-related information (CVC/CVVs, complete track data, PINs and PIN Blocks) used to authenticate cardholders, appearing in plaintext or otherwise unprotected form. Disclosure, modification, or destruction of this information could compromise the security of a cryptographic device, information system, or cardholder information or could be used in a fraudulent transaction.

Separation of Duties Practice of dividing steps in a function among different individuals, so as to keep a single individual from being able to subvert the process.

Service Code Three- or four-digit number on the magnetic-stripe that specifies acceptance requirements and limitations for a magnetic-stripe read transaction.

Service Provider Business entity that is not a payment card brand member or a merchant directly involved in the processing, storage, transmission, and switching or transaction data and cardholder information or both. This also includes companies that provide services to merchants, services providers or members that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and


Page 40 of 42



http://www.PCISecurityStandards.org/


Workbook

other services as well as hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.

Split Knowledge Condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptographic key.

Strong Cryptography General term to indicate cryptography that is extremely resilient to cryptanalysis. That is, given the cryptographic method (algorithm or protocol), the cryptographic key or protected data is snot exposed. The strength relies on the cryptographic key used. Effective size of the key should meet the minimum key size of comparable strengths recommendations. One reference for minimum comparable strength notion is NIST Special Publication 800-57, August 2005 (http://csrc.nist.gov/publications/) or others that meet the following minimum comparable key bit security: 80 bits for secret key based systems (for example

TDES) 1024 bits modulus for public key algorithms based

on the factorization (for example, RSA) 1024 bits for the discrete logarithm (for example,

Diffie-Hellman) with a minimum 160 bits size of a large subgroup (for example, DSA)

160 bits of elliptic curve cryptography (for example, ECDSA)

Tamper-resistance System that is difficult to modify or subvert, even for an assailant with physical access to the system.

TDES Triple Data Encryption Standard also known as 3DES. Block cipher formed from the DES cipher by using it three times.

Truncation Practice of removing data segment. Commonly, when account numbers are truncated, the first 12 digits are deleted, leaving only the last 4 digits.

Two-factor authentication Authentication that requires users to produce two credentials to access a system. Credentials consist of something the user has in their possession (for example, smartcards or


Page 41 of 42



http://csrc.nist.gov/publications/


Workbook

hardware tokens) and something they know (for example, a password). To access a system, the user must produce both factors.

Vulnerability Weakness in system security procedures, system design, implementation, or internal controls that could be exploited to violate system security policy.

WEP Wired equivalent privacy. Protocol to prevent accidental eavesdropping and intended to provide comparable confidentiality to traditional wired network. Does snot provide adequate security against intentional eavesdropping (for example, cryptanalysis).

WPA WiFi Protected Access (WPA and WPA2). Security protocol for wireless (WiFi) networks. Created in response to several serious weaknesses in the WEP protocol.


Page 42 of 42



Documents

Policies and Procedures on Data Security