1 / 31

UMASS PCI DSS Compliance Training

UMASS PCI DSS Compliance Training. Payment Card Industry Data Security Standard (PCI DSS) Training Program. Version 5 Larry Wilson January, 2014. 1. PCI DSS Training Course. Contents. Module 1 PCI DSS Introduction Payment Industry Terminology Payment Transaction Flow

kita
Download Presentation

UMASS PCI DSS Compliance Training

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UMASS PCI DSS Compliance Training Payment Card Industry Data Security Standard (PCI DSS) Training Program Version 5 Larry Wilson January, 2014 1

  2. PCI DSS Training Course Contents • Module 1 • PCI DSS Introduction • Payment Industry Terminology • Payment Transaction Flow • Service Provider Relationships • Module 2 • Payment Brand Compliance Programs • SAQ Overview • PA-DSS Overview • PCI Roles and Responsibilities • Module 3 • UMASS e-Commerce Committee & Security Council • Appendix

  3. Module 1 Module 1 Objectives • After completing this module you will be able to • Understand the importance of PCI DSS compliance • Describe the role of the Payment Card Industry Security Standards Council (PCI SSC) • Outline the Payment Card Industry Security Standards • Describe the benefits of PCI DSS training • Discuss myths of PCI DSS • Define Payment Card Industry Terminology • Define card processing: Authorization, Clearing and Settlement • Define service provider relationships • Discuss transaction types: card Not Present and Card Present • Describe credit card security • Compliance with PCI DSS • There are three things to understand about PCI DSS: • Standards are not optional • If you accept payment cards on campus, you are subject to the standards • There are significant financial costs to non-compliance. • Failure to comply with PCI DSS can result in stiff contractual penalties or sanctions from members of the payment card industry, including: • Fines of $500,000 per data security incident • Fines of $50,000 per day for non-compliance with published standards • Liability for all fraud losses incurred from compromised account numbers • Liability for the cost of re-issuing cards associated with the compromise • Suspension of merchant accounts • Non compliance is not worth the risk. • It only takes one incident of data compromise to put the university at risk

  4. Module 1 PCI DSS Introduction • What is PCI SSC? • PCI Security Standards Council (PCI SSC) was created in 2006 as an independent standards body to provide oversight of the development and management of payment Card Industry Security Standards on a global basis • Created to align security programs of MasterCard and Visa • Later was adopted by other major card programs • Founding members of the council included American Express, Discover, JCB, MasterCard Worldwide, and Visa International. • Resources Provided by the Council • PCI DSS, PCI PTS, PCI PA-DSS, P2PE, PIN Security and supporting documents • Roster of QSAs (Qualified Security Assessors), ASVs (Approved Scanning Vendors), validated payment applications, PTS Devices, and P2PE solutions • PCI Security Standards Council FAQs • Education and Outreach Programs • Participating Organization Membership, Meetings, Feedback • PCI Standards • PCI DSS covers security of the environments that store, process or transmit account data • PCI PTS covers tamper detection, cryptographic processes, and other mechanisms used to protect the PIN • PCI PA-DSS covers secure payment applications to support PCI DSS compliance • PCI P2PE covers encryption, decryption and key management within secure cryptographic devices • PCI PIN Security covers secure management, processing and transmission of personal identification number (PIN) data during online and offline payment card transaction processing

  5. Module 1 PCI DSS Introduction • Who does PCI DSS apply to? • UMASS Merchants must be PCI DSS compliant and are responsible for ensuring their compliance: • The program applies to all payment channels, including: in person (Point of Sale), mail / telephone order and/or e-commerce. • The training is applicable to all campus personnel who have access to credit card information, as a processor of credit card transactions or as a reviewer of reports that contain credit card data • How does it work? • University Merchants and Service Providers must adhere to PCI DSS • A single approach to safeguard sensitive data for all card brands • Compliance validation ensures appropriate levels of cardholder data security are maintained • Why is this important? • This training provides knowledge and skills necessary to ensure credit card security at the university • Everyone, not just the credit card companies, benefits from the effective application of credit card security measures • Benefits of PCI DSS Training • Our Customers • Appreciate your ability to reduce the threat of identity theft • Trust you to complete transactions without duplicate or invalid charges • Enjoy peace of mind, knowing that their credit card information is in good hands • The University • Takes pride in a skilled workforce • Values your ability to build customer confidence • Needs your help in limiting potential losses, fines and penalties • … and You • Have confidence in your ability to safely and efficiently do your job • Are alert to the warning signs of fraud • Know you can make informed decisions under pressure

  6. Module 1 Myths of PCI DSS • Myth 1 – One vendor and product will make us compliant • No single vendor or product fully addresses all 12 requirements of PCI DSS. • Myth 2 – Outsourcing card processing makes us compliant • Outsourcing simplifies but does not provide automatic compliance • We must ensure providers comply with PCI standards • Request a certificate of compliance annually from providers. • Myth 3 – PCI compliance is an IT project • The IT staff implements technical and operational aspects • PCI compliance is an ongoing process of assessment, remediation, reporting • Myth 4 – PCI will make us secure • Successful completion of a scan or assessment is a snapshot in time • Security exploits are non-stop and get stronger every day • PCI compliance efforts are a continuous process of assessment and remediation to ensure safety of cardholder data. • Myth 5 – PCI is unreasonable; it requires too much • Most aspects of PCI DSS are a common best practice for security • Myth 6 – PCI requires us to hire a Qualified Security Assessor • PCI DSS provides the option of doing an internal assessment with an officer sign-off if acquirer and/or merchant bank agree • Note: The Commonwealth of Massachusetts Comptroller’s office requires the University to hire a QSA to conduct an independent assessment on an annual basis. • Myth 7 – We don’t take enough credit cards to be compliant • PCI compliance is required for any business that accepts payment cards – even if the quantity of transactions is just one • Myth 8 – We completed a SAQ so we’re compliant • Completion of an annual SAQ is one piece of the ongoing compliance process. However, true security of cardholder data requires non-stop assessment and remediation to ensure that likelihood of a breach is kept as low as possible. • Myth 9 – PCI makes us store cardholder data • Both PCI DSS and the payment card brands strongly discourage storage of cardholder data by merchants and processors • Myth 10 – PCI is too hard • Understanding PCI DSS can seem daunting, especially for merchants without security or a large IT department. • However, PCI DSS mostly calls for good, basic security

  7. Module 1 Payment Industry Terminology • Visa Payment System Participation • A merchant is any business entity that is authorized to accept Visa products for the payment of goods and services. • An acquirer – also known as the merchant acquirer or merchant bank – is a financial institution or other business entity that contracts with merchants to accept Visa products for payment of goods and services. • A cardholder is an authorized user of Visa payment cards or other Visa payment products. • VisaNet - A core component of the Visa system is VisaNet, a secure, centralized, global processing platform. • An issuer is a financial institution or other business entity that issues Visa cards and contracts with its cardholders for billing and payment of transactions. • Visa Payment System Process • A typical Visa transaction that flows through VisaNet – the Visa system – involves two stages: authorization, and clearing and settlement. • Authorization is the process of approving or declining a transaction before a purchase is finalized or cash is disbursed. • Clearing is the process of delivering final transaction data from Visa acquirers to Visa issuers for posting to the cardholder’s account. Clearing also includes the calculation of certain fees and charges that apply to the issuer and acquirer involved in the transaction, as well as the conversion of transaction amounts to the appropriate settlement currencies. • Settlement is the process of calculating, determining and reporting the net financial position of Visa’s issuers and acquirers for all transactions that are cleared.

  8. Module 1 Transaction Processing Overview Authorization Process The following illustrates the basic roles of Visa system participation: The cardholder presents the merchant with a Visa card for payment. The merchant point-of-sale terminal reads the account number and other data encoded on the card’s magnetic stripe or chip. The merchant terminal transmits the card information and transaction amount to the acquirer. The acquirer combines the transaction information into an authorization request message and transmits it to Visa. Visa routes the authorization request to the issuer for review. In certain circumstances, such as when the issuer’s systems are unavailable, Visa may perform stand-in processing and review and authorize or deny the transaction. The issuer sends to Visa an authorization response message either approving or denying the transaction. Visa routes the authorization response to the acquirer. The acquirer transmits the result of the authorization request to the merchant terminal. Clearing and Settlement Process The following diagram illustrates the clearing and settlement process between the issuer and acquirer for a typical transaction processed through Visa’s system. Clearing 1. The merchant transmits sales draft information for the transaction, including account numbers and transaction amounts, to the acquirer. 2. The acquirer formats this information into a clearing message, which it transmits to Visa. 3. Visa routes the clearing message to the issuer and calculates the settlement obligation of the issuer and the amount due to the acquirer, net of certain applicable fees and charges. Settlement 4. The issuer sends funds to Visa’s designated settlement bank in the amount of its settlement obligation. 5. The settlement bank, at the direction of Visa, transfers funds due to the acquirer. Source: Visa International Operating Regulations Core Principles Effective 15 October 2013

  9. Module 1 How Payment Processing Works (Technical Process) Source: MasterCard.com

  10. Module 1 Service Providers • Service Providers • A service provider is a business entity directly involved with the processing, storage, transmission, or switching of transaction data and cardholder data. • Service providers include companies that provide services which control or could impact the security of cardholder data. • Service provider examples: • Transaction processors • Payment Gateways • Independent Sales Organizations (ISOs) • External Sales Organizations (ESOs) • Customer Service functions • Remittance processing companies • Managed firewall and Intrusion Detection Service (IDS) service providers • Web Hosting and Data Center Hosting providers Payment Gateways This diagram illustrates how real-time, electronic credit card processing works using CyberSource Payment Services. Source: CyberSource.com • Purchaser places order • Merchant securely transfers order information to CyberSource over the Internet. CyberSource receives order information and performs requested services • CyberSource formats the transaction detail appropriately and securely routes the transaction authorization request through its payment gateway to the processor. • The transaction is then routed to the issuing bank (purchaser's bank) to request transaction authorization • The transaction is authorized or declined by the issuing bank or card (Discover, American Express). • CyberSource returns the message to the merchant. • Issuing bank approves transfer of money to acquiring bank • The acquiring bank credits the merchant's account

  11. Module 1 Transaction Types & Card Security Credit Card Security Merchant Configurations Card Not Present Transactions Card Not Present Transaction - the credit card information is keyed into a credit card processing system (credit card terminal, software program, or payment gateway) without the credit card or customer present at the time of the sale. Card Present Transactions Card Present Transaction (Point of Sale) - the customer and credit card are present at the point of sale. The card is swiped through a credit card processing system (credit card terminal, POS system or card reader) that obtains the card holder's information by reading the magnetic stripe on the back of the card. **The University does not support the use of imprint machines. Internet Connected Terminal Dial-up Terminal Wireless Terminal Tap & Go Wireless Terminal Imprint Machine** Source: PCI Security Council

  12. Module 2 Module 2 Objectives • After completing this module you will be able to • Understand the PCI DSS Standards Framework • Understand Merchant Compliance Requirements • Describe the Self Assessment Questionnaire (SAQ) • Understand SAQ Instructions and Guidelines • Describe the three step PCI DSS Compliance Approach • Understand Merchant and Service Provider Compliance Levels • Understand Merchant and Service Provider Compliance Validation • Understand Payment Application data Security Standard (PA-DSS) • Understand PCI Roles and Responsibilities PCI DSS Standards Framework Source: PCI Security Council

  13. Module 2 PCI DSS Standards Requirements All requirements referenced from PCI Security Council • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters • Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information. • Requirement 3: Protect stored cardholder data • Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging. • Requirement 4: Encrypt transmission of cardholder data across open, public networks • Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments. • Requirement 1: Install and maintain a firewall configuration to protect cardholder data • Firewalls are devices that control computer traffic allowed between an entity’s networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entity’s internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entity’s trusted network. • A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria. • All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network. • Other system components may provide firewall functionality, provided they meet the minimum requirements for firewalls as provided in Requirement 1. Where other system components are used within the cardholder data environment to provide firewall functionality, these devices must be included within the scope and assessment of Requirement 1.

  14. Module 2 PCI DSS Standards Requirements All requirements referenced from PCI Security Council • Requirement 8: Assign a unique ID to each person with computer access • Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes. • Requirement 9: Restrict physical access to cardholder data • Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, ―onsite personnel‖ refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity’s premises. A ―visitor‖ refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the facility for a short duration, usually not more than one day. ―Media‖ refers to all paper and electronic media containing cardholder data. • Requirement 10: Track and monitor all access to network resources and cardholder data • Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs. • Requirement 5: Use and regularly update anti-virus software or programs • Malicious software, commonly referred to as ―malware‖—including viruses, worms, and Trojans—enters the network during many business-approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. • Requirement 6: Develop and maintain secure systems and applications • Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software. • Requirement 7: Restrict access to cardholder data by business need to know • To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.

  15. Module 2 PCI DSS Standards Requirements All requirements referenced from PCI Security Council • Compliance with PCI DSS • Required by all entities that store, process, transmit cardholder information • PCI Compliance requires an entity to comply with all PCI DSS requirements • PCI DSS compliance is dependent on: • Merchant or service provider level • Payment brand compliance validation and reporting requirements • University requirements for compliance • Non compliance can result in fines levied by credit card companies against merchants, processors and acquiring banks • Merchant Compliance Requirements • Understand the PCI DSS standards and compliance requirements • Sufficient technical knowledge in the security domains covered by PCI DSS • Understand credit card business processes and data flows • Identify systems and processes subject to PCI DSS assessments • Comply with requirements of the PCI DSS standards • Understand and comply with University e-commerce standards • Complete PCI DSS self-assessment and remediate gaps found • Acquiring Bank’s Compliance Requirements (Vantiv) • Meet requirements of individual credit card brand including reporting on service provider and merchant • Processor Compliance Requirements (CyberSource, NelNet) • Payment processors should provide annual proof of PCI compliance • Requirement 11: Regularly test security systems and processes. • Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment. • Requirement 12: Maintain a policy that addresses information security for all personnel. • A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, ―personnel‖ refers to full-time and part-time employees, temporary employees, contractors and consultants who are ―resident‖ on the entity’s site or otherwise have access to the cardholder data environment.

  16. Module 2 PCI DSS Standards Framework SAQ A Card Not Present – All Cardholder Data Functions Outsourced The Self-Assessment Questionnaire (SAQ) The “SAQ” is a self-validation tool for merchants and service providers who are not required to do on-site assessments for PCI DSS compliance. The SAQ includes a series of yes-or-no questions for compliance. If an answer is no, the university must state the future remediation date and associated actions. • SAQ A has been developed to address requirements applicable to merchants who retain only paper reports or receipts with cardholder data, do not store cardholder data in electronic format and do not process or transmit any cardholder data on their systems or premises. • SAQ A merchants do not store cardholder data in electronic format, do not process or transmit any cardholder data on their systems or premises, and validate compliance by completing SAQ A and the associated Attestation of Compliance, confirming that: • Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions; • Your company does not store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions; • Your company has confirmed that the third party(s) handling storage, processing, and/or transmission of cardholder data is PCI DSS compliant; • Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically; and • Your company does not store any cardholder data in electronic format.

  17. Module 2 Self-Assessment Questionnaire (SAQ) • SAQ B has been developed to address requirements applicable to merchants who process cardholder data only via imprint machines** or standalone, dial-out terminals. • SAQ B merchants only process cardholder data via imprint machines** or via standalone, dial-out terminals, and may be either brick-and-mortar (card-present) or e-commerce or mail/telephone order (card-not-present) merchants. Such merchants validate compliance by completing SAQ B and the associated Attestation of Compliance, confirming that: • Your company uses only an imprint machine** and/or uses only standalone, dial-out terminals (connected via a phone line to your processor) to take your customers’ payment card information; • The standalone, dial-out terminals are not connected to any other systems within your environment; • The standalone, dial-out terminals are not connected to the Internet; • Your company does not transmit cardholder data over a network (either an internal network or the Internet); • Your company retains only paper reports or paper copies of receipts with cardholder data, and these documents are not received electronically; and • Your company does not store cardholder data in electronic format. • **The University does not support the use of imprint machines. SAQ B Merchants with Only Imprint Machines** or Only Standalone, Dial-Out Terminals. No Electronic Cardholder Data Storage. • SAQ C-VT • Merchants with Web-Based Virtual Terminals, No Electronic Cardholder Data Storage • SAQ C-VT has been developed to address requirements applicable to merchants who process cardholder data only via isolated virtual terminals on personal computers connected to the Internet. • This SAQ option is intended to apply only to merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution. SAQ C-VT merchants process cardholder data via virtual terminals on personal computers connected to the Internet, do not store cardholder data on any computer system, and may be brick-and-mortar (card-present) or mail/telephone-order (card-not-present) merchants. • Such merchants validate compliance by completing SAQ C-VT and the associated Attestation of Compliance, confirming that: • Your company’s only payment processing is done via a virtual terminal accessed by an Internet connected web browser; • Your company’s virtual terminal solution is provided and hosted by a PCI DSS validated third party service provider; • Your company accesses the PCI DSS compliant virtual terminal solution via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment (this can be achieved via a firewall or network segmentation to isolate the computer from other systems); • Your company’s computer does not have software installed that causes cardholder data to be stored (for example, there is no software for batch processing or store-and-forward); • Your company’s computer does not have any attached hardware devices that are used to capture or store cardholder data (for example, there are no card readers attached); • Your company does not otherwise receive or transmit cardholder data electronically through any channels (for example, via an internal network or the Internet); • Your company retains only paper reports or paper copies of receipts; and • Your company does not store cardholder data in electronic format.

  18. Module 2 Self-Assessment Questionnaire (SAQ) • SAQ C • Merchants with Payment Application Systems Connected to the Internet, No Electronic Cardholder Data Storage • SAQ C has been developed to address requirements applicable to merchants whose payment application systems (for example, point-of-sale systems) are connected to the Internet (for example, via DSL, cable modem, etc.) either because: • 1. The payment application system is on a personal computer that is connected to the Internet (for example, for e-mail or web browsing), or • 2. The payment application system is connected to the Internet to transmit cardholder data. • SAQ C merchants process cardholder data via POS machines or other payment application systems connected to the Internet, do not store cardholder data on any computer system, and may be either brick-and-mortar (card-present) or e-commerce or mail/telephone-order (card-not-present) merchants. • SAQ C merchants validate compliance by completing SAQ C and the associated Attestation of Compliance, confirming that: • Your company has a payment application system and an Internet connection on the same device and/or same local area network (LAN); • The payment application system/Internet device is not connected to any other systems within your environment (this can be achieved via network segmentation to isolate payment application system/Internet device from all other systems); • Your company store is not connected to other store locations, and any LAN is for a single store only; • Your company retains only paper reports or paper copies of receipts; • Your company does not store cardholder data in electronic format; and • Your company’s payment application software vendor uses secure techniques to provide remote support to your payment application system. SAQ D All Other Merchants and All Service Providers Defined by a Payment Brand as Eligible to Complete an SAQ SAQ D has been developed for all service providers defined by a payment brand as eligible to complete an SAQ, as well as SAQ-eligible merchants who do not meet the descriptions of SAQ types A through C, above. SAQ D service providers and merchants validate compliance by completing SAQ D and the associated Attestation of Compliance. While many of the organizations completing SAQ D will need to validate compliance with every PCI DSS requirement, some organizations with very specific business models may find that some requirements do not apply. For example, a company that does not use wireless technology in any capacity would not be expected to validate compliance with the sections of the PCI DSS that are specific to managing wireless technology.

  19. Module 2 SAQ Instructions and Guidelines SAQ Instructions & Guidelines Which SAQ do I complete? SAQ D All other merchants and service providers SAQ C Internet-connected Payment application SAQ A Outsource all CHD SAQ C-VT Virtual Terminals Only SAQ B Imprint or standalone dial-out terminals only Card-not-present, all cardholder data (CHD) functions outsourced Imprint or standalone, dial-out terminals only, no electronic CHD storage Web-based virtual terminals only, no electronic CHD storage POS or payment system connected to Internet, no electronic CHD storage All other merchants and all service providers eligible to complete an SAQ • Third-party hosted virtual terminal only, accessed by an Internet-connected web browser • Merchant computer not connected to any other systems within environment • Isolated in a single location, not connected to other locations or systems within environment (can be achieved with network segmentation) • Virtual terminal solution provided and hosted by PCI DSS validated service provider • No software installed or hardware attached to merchant computer that captures CHD • No other electronic transmission of CHD • Only paper is retained • No electronic storage of CHD • Imprint machine** or standalone dial-out terminals only • Dial-out terminals not connected to any other systems • Dial-out terminals not connected to the Internet, connected via phone line to your processor or acquirer • No CHD over Internet • Only paper is retained • No electronic storage of CHD • **The University does not support the use of imprint machines. • Card not-present only • No CHD on any systems or premises, all outsourced • Third parties are PCI DSS compliant • Only paper is retained • No electronic storage of CHD • POS or payment system and Internet on same device and/or same Local Area Network (LAN) • Payment application system / hardware device not connected to any other systems • Single store location • Only paper is retained • No electronic storage of CHD • POS vendor provides secure support Is this my merchant type? Is this my merchant type? Is this my merchant type? Is this my merchant type? No No No No Yes Yes Yes Yes Yes SAQ A (13 questions) and Attestation SAQ B (29 questions) and Attestation SAQ C-VT (51 questions) and Attestation SAQ C (40 questions) and Attestation SAQ D (288 questions) and Attestation

  20. Module 2 PCI DSS Compliance Approach • Step 1 – Assess • Goal: Identify technology and process vulnerabilities posing a security risk of cardholder data transmitted, processed or stored by the university. • Step 1.1 - Study PCI DSS Standard - Learn what the standard requires of the business • Step 1.2 - Inventory IT Assets and Processes • Identify systems, personnel, processes involved in transmission, processing, storing cardholder data. • Determine how cardholder data flows from beginning to end of the transaction process. • Check versions of personal identification number (PIN) entry terminals and software to ensure they are PCI compliant. • Step 1.3 - Find Vulnerabilities - Use the appropriate SAQ to guide the assessment, and technologies to locate insecure systems • Step 1.4 - Validate with Third-Party Experts - May require a Qualified Security Assessor (QSA) and/or Approved Scanning Vendor (ASV) to execute proper assessment. • Note: Liability for PCI compliance extends to third parties involved with the process flow, so we must confirm that they are compliant. • Step 2 – Remediate • Goal: Remediation is the process of fixing vulnerabilities – including technical flaws in software code or unsafe practices in how the university processes or stores cardholder data. • Step 2.1 - Scan your network with software tools that analyze infrastructure and spot known vulnerabilities • Step 2.2 - Review and remediate vulnerabilities found during on-site assessment (if applicable) or through the Self-Assessment Questionnaire (SAQ) process • Step 2.3 - Classify and rank the vulnerabilities to help prioritize the order of remediation, from most serious to least serious • Step 2.4 - Apply patches, fixes, and changes to unsafe processes and workflow • Step 2.5 - Re-scan to verify that remediation actually occurred • Note: Remediation should occur as soon as practical when a vulnerability is discovered via the Assessment process (Step 1). • Step 3 – Report • Regular reports are required for PCI compliance; these are submitted to the acquiring bank and card payment brands that you do business with. • PCI SSC is not responsible for PCI compliance. • All qualifying merchants and processors must submit a quarterly scan report, which must be completed by a PCI approved ASV. • Businesses must submit an annual Attestation within the Self-Assessment Questionnaire (SAQ).

  21. Module 2 Merchant Levels and Compliance Validation Service Provider Levels and Compliance Validation • Level 1: • All Third Party Processors (TPPs) and Data Storage Entities (DSEs) that store, transmit or process less than 1,000,000 combined MasterCard and Maestro transactions annually. • Additionally, All compromised TPPs and DSE’s • Level 2: • All DSEs that store, transmit or process less than 1,000,000 combined MasterCard and Maestro transactions annually Note: UMASS is designated as a Level 3 Merchant but we report as a Level 2 Merchant

  22. Module 2 Payment Application Data Security Standard (PA-DSS) Assessing Environments with PA-DSS Applications PA -DSS Overview • PA-DSS is a comprehensive set of requirements designed for payment application software vendors to facilitate their customer’s PCI DSS compliance. • Distinct but aligned with PCI-DSS • PA-DSS applies to third party applications that perform authorization and/or settlement. • PA-DSS does not apply to payment applications that are typically sold and installed “off the shelf” without much customization by software vendors. • PA-DSS does not apply to payment applications provided in modules, which typically includes a “baseline” module and other modules specific to customer types or functions, or customized per customer request. • PA-DSS does not apply to a payment application developed and sold to only one customer since this application will be covered a part of the customer’s PCI DSS compliance review. • PCI-DSS does not apply to payment applications developed by merchants and service providers if used only in-house (not sold to a third party). • PA-DSS does not apply to operating systems onto which a payment application is installed, database systems that store cardholder data or back-office systems that source cardholder data. • Use of PA-DSS compliant application by itself does not make an entity PCI-DSS compliant • PA-DSS validated payment applications are included in the scope of a PCI-DSS assessment • The assessor should not challenge the PA-DSS validation • PCI-DSS assessment of validated payment applications should verify the payment application is implemented into a PCI-DSS compliant environment and the payment application is implemented according to the PA-DSS Implementation Guide • All other system components in scope for PCI DSS must still be assessed • The assessor should focus their assessment on the application’s implementation in accordance with the vendor’s implementation guide.

  23. Module 2 Roles & Responsibilities • Merchant & Service Providers • Review and understand the PCI Security Standards • Understand the compliance validation and reporting requirements defined by the payment card brands • Validate and report compliance to acquirer or payment card brand • Maintain ongoing compliance, not just during assessment • Read and incorporate communications from the payment brands, acquirers, and the PCI SSC • Internal Security Assessors • Validate the scope of the assessment • Verify all technical information given by stakeholders using independent judgment to confirm requirements have been met • Provide support and guidance during the compliance process • Be on-site for the duration of any relevant assessment procedure • Review the work that supports the assessment procedures • Ensure adherence to PCI-DSS Requirements • Select business facilities and system components for sampling • Evaluate compensating controls and produce final report • Approved Scanning Vendor (ASV) • Perform external vulnerability scans via PCI-DSS Requirement 11.2 • Make reasonable efforts to ensure scans do not impact normal operation of the customer environment and do not penetrate or intentionally alter the customer environment • Scan all IP ranges and domains provided by the customer to identify active IP addresses and services • Provide a determination as to whether the scan customer’s components have passed scanning requirements • Provide adequate documentation to demonstrate the compliance or non-compliance of the scan customer’s components. • PCI Security Standards Council • Maintain PCI-DSS, PA-DSS, PTS, P2PE, and PIN Security standards and supporting documentation • Define, implement validation requirements for QSAs, PA-QSAs, ASVs, ISAs • Approve companies and their employees to perform PCI –DSS Assessments, Payment Application Assessments, ASV Scanning • Maintain list of validated payment applications, P2PE solutions, PIN transaction security devices, QSA, PA-QSA, ASV companies • Offer training for the QSAs, PA-QSAs, ASVs, and ISAs • Promote PCI security on a global basis • Payment Card Brands • Development and enforcement of compliance programs • Fines or penalties for non-compliance • Endorse QSA, PA-QSA and ASV company qualification criteria • Accept validation documentation from approved QSA, PA-QSA, and ASV companies and their employees • Provide feedback to council on QSA, PA-QSA and ASV performance • Forensic investigation and account data compromise • Qualified Security Assessor (QSA) • Validate the scope of the assessment • Conduct PCI-DSS assessments • Verify all technical information given by merchant or service provider using independent judgment to confirm requirements are met • Be on-site for the duration of any relevant assessment procedure • Review the work that supports the assessment procedures • Ensure adherence to PCI-DSS Requirements and Assessment Procedures • Select business facilities and system components where sampling is used • Evaluate compensating controls and produce Report on Compliance (ROC)

  24. Module 3 UMASS e-Commerce Committee & Security Council • Roles and Responsibilities • UMASS Campus / President’s Office e-Commerce and Information Security Representative • Roles and Responsibilities – Merchant Compliance (Campus and President’s Office) • Manage campus merchant’s inventory spreadsheet and compliance WorkShare site • Manage campus merchant’s annual Self Assessments Questionnaires (SAQs) • Manage campus merchant’s QSA Security Assessments (new implementations) • Manage campus merchant’s Quarterly Scans (if applicable) • Manage campus merchant’s annual PCI DSS training • Manage campus merchant’s ongoing communications and updates (as needed) • UMASS President’s Office e-Commerce and Information Security Representative • Roles and Responsibilities – QSA Contracts and Statement of Work (SOW) • Manage QSA Statement of Work • Manage QSA and ongoing communications and updates (as needed) • UMASS President’s Office e-Commerce and Information Security Representative • Roles and Responsibilities – Service providers • Manage service provider (CyberSource, NelNet) compliance (see note) responsibility • Manage service provider ongoing communications and updates (as needed) • UMASS President’s Office e-Commerce and Information Security Representative • Roles and Responsibilities – Acquiring Bank • Manage acquiring bank (Vantiv Bank) compliance • Manage acquiring bank ongoing communications and updates (as needed) UMASS e-Commerce Committee • UMASS Amherst • Patty Roper • Jacqui Watrous • Erin Zuzula • Jake Cunningham • Chris Misra • UMASS Boston • Jimmy Sam • Terry Phalen • Lisa Moriarty • Katherine Nung • UMASS Dartmouth • Suzanne Audet • Kathleen Eubanks • Rich Pacheco • UMASS Amherst • Jake Cunningham • UMASS Boston • Wil Khouri • UMASS Dartmouth • Andrew Darling • UMASS Lowell • John Perroni • UMASS Worcester • Yi Chen • Sandra Flynn • UMASS President’s Office • Phil Marquis • Terri O’Neil • Kathey White • Jeff Conners • Brian McCormick • Wendy Mulcahy • Larry Wilson • Martha Johnson • UMASS Lowell • Tony Kolodziej • UMASS Worcester • Brian Coleman • UMASS President’s Office • Larry Wilson UMASS Security Council

  25. Appendix UNIVERSITY OF MASSACHUSETTS TREASURER’S OFFICE Treasurer’s Fiscal Procedure No. 08-01 Effective Date: March 1, 2012 Fiscal Standard and Procedure – E-Commerce and PCI • Section A: Operational • Overall • Campus merchants (departments) may not store in any manner full 16 digit credit card numbers (PAN). • Unprotected PAN (Primary Account Number) should not be sent via end-user messaging technologies including but not limited to email, instant messaging, text message, or social media. • All requests for credit card receipt copies and chargebacks must be processed immediately. Failure to respond before the deadline will result in the chargeback being processed by the card company. Credit card copies must mask all but the first six and last four digits of the account number (PAN) prior to transmission. • Point of Sale • Credit card terminals must be batched out daily. • Campus merchants (departments) may not store in any form the magnetic strip, which consists of track data, CVV2 data or PIN data. • University Records Retention Policy states that we must retain all credit card receipts for three years. PCI Standards also require that these records be classified by labeling as “Confidential” and stored securely. These receipts should not contain the full PAN (Primary Account Number). At the end of three years they must be properly disposed of by being cross-cut shredded, incinerated, or pulped. Containers storing documents to be destroyed should have a lock preventing access to its contents. • To process a credit for a point-of-sale terminal, ideally you should have the card present and swipe it through the terminal.  If the card is not present then there should be communication with the cardholder to get the full number to be used to enter into the terminal.  There should not be storage of full card numbers in any format. • Online • Electronic records containing cardholder data should not contain the full PAN. If you receive a report containing the full PAN please contact your campus eCommerce representative immediately for instructions on permanently deleting the file. • All credits specific to CyberSource applications must be processed online through the University Treasurer’s Office within 60 days of the original transaction and are based on a transaction reference number. Card number is not required. Beyond 60 days, credits can be processed manually by the receiving site or as a stand-alone credit through the Treasurer’s Office. • Section B: Inventory • Each campus must maintain a complete and accurate inventory of all credit card processing locations including point of sale and online merchants. The campus is also responsible for maintaining an inventory of documentation regarding third party vendors contracted to process credit cards. Process flows and technology configuration should be documented and updated as needed. • Campus E-commerce representatives must be involved in and approve any decisions to accept credit cards or other electronic form of cash receipts. • It is recommended that each campus maintain an inventory of all outsourced vendors that process credit card payments. Proof of their PCI compliance should be provided no less than annually. • Section C: PCI Compliance • Administrative • Campus E-commerce representatives and Campus Bursars will work with departments to provide the necessary guidance in the areas of PCI Compliance, internal controls (including restricting access to cardholder data), deposit techniques and reconciliation. • E-commerce representatives have the authority to suspend the account of a merchant who is not in compliance with the University of Massachusetts Fiscal Standard and Procedure – E-Commerce and PCI. • Failure to follow the PCI DSS standards for credit card merchants subjects the University to fines and penalties. Any fines will be the responsibility of the campus. • Use of any unauthorized or non-compliant third party credit card processing vendors must be immediately terminated. • Any department accepting credit card payments in any format is required to complete the appropriate PCI SAQ (Self-Assessment Questionnaire) annually. • Transmission of quarterly scan results and the annual SAQ will be sent and tracked by the Treasurer’s Office to the acquiring bank.

  26. Appendix UNIVERSITY OF MASSACHUSETTS TREASURER’S OFFICE Treasurer’s Fiscal Procedure No. 08-01 Effective Date: March 1, 2008 Fiscal Standard and Procedure – E-Commerce and PCI • Section C: PCI Compliance • Point of Sale • All broken and discontinued POS terminals must be returned in a secure manner to the University Treasurer’s Office for disposal. • Departments are responsible for ensuring they only use PCI compliant POS terminals and must replace any non-compliant or obsolete terminals at their own expense. • POS terminals should only be used on campus. If a business need arises to take the terminal off campus departments must obtain approval from their campus eCommerce Representative prior to taking a terminal off campus. The requesting department must be able to confirm the connection type that will be used at the outside venue and agree to monitor the terminal at all times and keep it securely locked when not in use. • Online • CyberSource and NelNet have been identified as the third party vendors of choice for all online activity. Any deviation from the use of CyberSource or NelNet must be approved by your campus Vice Chancellor for A&F as well as the E-commerce Committee. All third party vendors are subject to the same standards for data compliance and security. Proof of PCI compliance must be provided on an ongoing basis. Proof will be provided no less than annually. • Third party installations other than CyberSource or NelNet must be reviewed by a QSA (Qualified Security Assessor) prior to accepting payments. The QSA deliverable should be a written report stating that the installation was installed in a PCI compliant manner. Additionally, campuses should periodically review these installations to confirm ongoing compliance. • All new payment applications must be listed on the PCI list of Validated Payment Applications. If the application is not listed the campus must provide the University Treasurer’s Office with a PABP Implementation Guide to help ensure that once the application is implemented it is in compliance. This will demonstrate that the application was developed under PABP guidelines and that their environment is PCI compliant. • All charge card applications written in-house must be developed using VISA’s PABP, Payment Application Best Practices and validated to be PCI compliant before going live. • Any department processing online credit card payments must work with their campus IT Security Department to determine if they will need to complete and submit quarterly scans. • Section D: Online Third Party Applications • All third party credit card processing vendors are subject to PCI DSS Standards. In addition they may be subject to quarterly network scans that must be performed by an Approved Scanning Vendor (ASV). The completion of annual self-assessment questionnaires is required. It is the responsibility of the campus to monitor and maintain current documentation. • Outside (third party) vendors must be listed on the PCI list of Validated Payment Applications or if not listed, they need to submit documentation from their QSA to the campus stating that they are PCI compliant and the date specific to that compliance. This document must be updated annually. • All new contracts with third party or outside vendors must contain language requiring that the vendor be PCI compliant and they will remain PCI compliant throughout the term of the contract. If the third party vendor is not the payment processor, their contract language must state that they will only use a PCI compliant payment processor throughout the term of the contract. Failure to do so gives the University the right to terminate the contract at no penalty to the University of Massachusetts. • All new contracts with third party or outside vendors must contain language that the vendor acknowledges that they are responsible for the security of cardholder data that they possess. • Campuses are responsible for ensuring that third party vendors remain PCI compliant throughout the term of the contract.

  27. Appendix PCI DSS Terminology Approved Scanning Vendor (ASV) - is a vulnerability assessment provider who provides automated software tools for scanning for vulnerabilities. Cardholder - Non-consumer or consumer customer to whom a payment card is issued to or any individual authorized to use the payment card. Cardholder Data - At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code. Internal Security Assessor (ISA) - The ISA Program provides eligible internal security audit professionals PCI DSS training and certification that will improve the organization’s understanding of the PCI DSS, facilitate interactions with QSAs, enhance the quality, reliability, and consistency of PCI DSS self-assessments, and support consistent and proper application of PCI DSS measures and controls. The Payment Application-Data Security Standard (PA-DSS) - A global security standard created by the Payment Card Industry Security Standards Council, or PCI SSC, formed by the major credit-issuing companies with the goal of delivering an effective and useful data security standard to vendors of payment application systems. The intent of this standard is to effectively prohibit secure data from being illegally accessed by unauthorized parties. Payment processor - An organization that processes payment requests, such as credit card authorizations and settlements, to the appropriate card associations per their guidelines. Your merchant bank’s processor relationship determines which payment processor you will use. Payment gateway - An organization, such as CyberSource, that enables merchants to securely send and receive order information to and from payment processors in the appropriate format. PCI Compliant - refers to an organization that has become compliant with the PCI DSS and has demonstrated this either through a Self Assessment Questionnaire or through formal validation (audit) by a QSA firm. PCI DSS - Data Security Standard – a document consisting of 12 requirements and various principles all designed to provide a framework to protect payment card data and systems. PCI SSC – Security Standards Council - the global governing body for payment card security standards. Responsible for developing, managing, education, and awareness of the PCI Security Standards including Data Security Standard (PCI DSS), Payment Application Data Security Standard (PA-DSS), and PIN Transaction Security (PTS) Requirements. Primary Account Number (PAN) - is essentially a payment card number (16 – 19 digit) which is generated according to the LUHNS algorithm). Qualified Security Assessor (QSA) – is a Information Security and PCI expert who works for a QSA firm and who has been certified by the PCI SSC to be fit and proper to validate whether a company / environment is PCI compliance Report on Compliance (ROC) - the report on compliance refers to a report that shows that an environment has been validated by a QSA in accordance with the PCI DSS. The outcome of the validation assessment may result in a Report of Compliance opinion of Compliant or Not Compliant depending the evidence provided to support the compliance assertions provided by the merchant or service provider to the QSA Self-Assessment Questionnaire (SAQ) – A validation tool for merchants and service providers that are not required to undergo an on-site data security assessment per the PCI DSS Security Assessment Procedures. The purpose of the SAQ is to assist organizations in self-evaluating compliance with the PCI DSS, and you may be required to share it with your acquiring bank. There are multiple versions of the PCI DSS SAQ to meet various business scenarios. Service Provider - An entity that stores, processes or transmits cardholder data on behalf of merchants. Examples of service providers include hosting and payment services for merchants. Such providers do not have direct service provider contractual relationships with acquiring institutions, other than for their own merchant activities, but nonetheless still fall into scope for the PCI DSS where they store, process or transmit payment cards on behalf of merchants. It is the merchant responsibility to ensure the service providers operate in a way that is complaint with the PCI DSS. Validation / Audit - refers to the final stage of PCI compliance whereby a Qualified Security Assessor (QSA) will validate and attest the compliance status of the environment under assessment for compliance with the PCI DSS. Vulnerability Assessment – is a technical security audit that uses automated tools to test for security flaws, mis-configurations and weaknesses in infrastructure and applications (to a relatively limited extent).

  28. Appendix Useful PCI DSS References PCI DSS Overview video http://abcnews.go.com/Video/playerIndex?id=4769169 (How Thieves Are 'Stealing You) Treasurer’s office e-commerce standards http://media.umassp.edu/massedu/treasurer/Principles%20--02272008final%20on%20letterhead[1].pdf PCI Security Standards Council https://www.pcisecuritystandards.org/ PCI Quick Reference Guide https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf Documents Library https://www.pcisecuritystandards.org/security_standards/documents.php?document=2.0#2.0 Certified devices https://www.pcisecuritystandards.org/security_standards/ped/pedapprovallist.html Self-Assessment Questionnaires https://www.pcisecuritystandards.org/saq/index.shtml Prioritized Approach https://www.pcisecuritystandards.org/education/prioritized.shtml Behind a transaction (Visa) http://usa.visa.com/merchants/risk_management/data_security_demo/m1/index.htm Visa Cardholder Info Security Program http://usa.visa.com/merchants/risk_management/cisp.html Bulletins and alerts http://usa.visa.com/merchants/risk_management/cisp_alerts.html Behind a transaction (MasterCard) http://media.mastercard.com.edgesuite.net/video_portal/behind-a-transaction.wm MasterCard Site Data Protection Program https://sdp.mastercardintl.com/ NelNet Compliance Pagehttp://www.campuscommerce.com/page.cfm?p=398 CyberSourcePCI Program http://www.cybersource.com/products_and_services/payment_security/pci-101/ Vantiv PCI Compliance Program http://www.vantiv.com/Products/PCI-Compliance

  29. Appendix Frequently Asked Questions (FAQs) General Information 1. What are the Payment Card Industry (PCI) Data Security Standards?The PCI Data Security Standards are association (Visa®/MasterCard®) and industry mandated requirements for handling of credit card information, classification of merchants, and validation of merchant compliance. Merchants are responsible for the security of cardholder data and must be careful not to store certain types of data on their systems or the systems of their third party service providers. Merchants are also responsible for any damages or liability that may occur as a result of a data security breach or other non-compliance with the PCI Data Security Standards. The information security principles contained within these standards are based on ISO 27002, the internationally recognized standard for information security practices. 2. To whom does the Payment Card Industry Data Security Standards Compliance Program apply? The program encompasses all merchants and third party service providers that store, process, or transmit cardholder data. 3. What are the benefits of being in compliance with the Payment Card Industry Data Security Standards?It is good business practice to adhere to the PCI standards and protect cardholder information. Additionally, Visa, MasterCard, and Discover® Network may impose fines on their member banking institutions when merchants do not comply with PCI Data Security Standards. Weare contractually obligated to indemnify and reimburse Vantivfor such fines. Please note such fines could be significant, especially if your business is compromised and you have not been validated as compliant. 4. What is "cardholder data"?Cardholder data is any personally identifiable data associated with a cardholder. This could be an account number, expiration date, name, address, social security number, etc. The account number is the critical component that makes the PCI Data Security Standards applicable. All personally identifiable information associated with the cardholder that is stored, processed, or transmitted is also considered cardholder data. The PCI Data Security Standards apply to all cardholder data stored, processed, or transmitted. Your Compliance Classification Level and What it Means 5. How is a merchant's compliance classification level determined?A merchant's compliance classification level is determined by annual transaction volume. The volume calculation done for you will be based on the gross number of Visa, MasterCard or Discover Network transactions processed within your merchant account. However, it will not be based on the aggregate transaction volume of a corporation that owns several chains. 6. How is IP-based POS environment defined?The point of sale (POS) environment is the environment in which a transaction takes place at a merchant location (i.e. retail store, restaurant, hotel property, gas station, supermarket, or other point of sale location). An Internet protocol (IP) -based POS environment is one in which transactions are stored, processed, or transmitted on IP-based systems, or systems communicating via TCP/IP. 7. What is a "High Risk" merchant?Currently, merchants that are known to use non-compliant payment applications (applications known to store magnetic stripe, Cardholder Verification Value (CVV), or Cardholder Verification Value 2(CVV2) or Card Validation Code 2 (CVC2) or Card Identification (CID) fall into this "High Risk" category. 8. Can my compliance requirements change?Yes. As your transaction volume changes, and as association and industry rules change, your compliance requirements may change. It is your responsibility to be continuously aware of the data security requirements that currently apply to you. Data Storage Protocol 9. When is it acceptable to store magnetic stripe data?It is never acceptable to retain magnetic stripe data subsequent to transaction authorization. Visa, MasterCard, and Discover Network prohibit storage of the contents of the magnetic stripe as a unit. However, the following individual data elements may be retained subsequent to transaction authorization: Cardholder Account Number Cardholder Name Card Expiration Date

  30. Appendix Frequently Asked Questions (FAQs) • 10. Are there alternatives to encrypting stored data?According to requirement 3.4 of the Payment Card Industry Security Audit Procedures, stored cardholder data should be rendered unreadable. And, if encryption, truncation, or another comparable approach cannot be used, encryption options should continue to be investigated as the technology is rapidly evolving. In the interim, while encryption solutions are being investigated, stored data must be strongly protected by compensating controls. Any compensating controls should be considered as part of the compliance validation process.An example of compensating controls for encryption of stored data is complex network segmentation that may include the following: • Internal firewalls that specifically protect the database. • TCP wrappers or firewall on the database to specifically limit who can connect to the database. • Separation of the corporate internal network on a different network segment from production, with a firewall separation from database servers. • 11. Are there compensating controls that can be used to meet a requirement?If a requirement is not, or cannot, be met exactly as stated, compensating controls can be considered as alternatives to requirements defined in PCI Data Security Standards. Compensating controls should meet the intention and rigor of the original PCI Data Security Standards, and should also be examined by the security assessor as part of the regular PCI Data Security standards compliance audit. Compensating controls should be "above and beyond" other PCI Data Security Standards, and should not simply be in compliance with PCI Data Security Standards. • 12. What if a merchant does not store cardholder data?If a merchant does not store cardholder data, the PCI Data Security Standards still apply to the environment that transmits or processes cardholder data. This includes any service providers that a merchant uses. Approved Software and Applications 13. What processing software/applications are currently known to be compliant?Visa has validated several software / applications to be compliant with the PCI Data Security requirements, including the requirement that after authorization, Security Data will be purged from the records and systems. Security Data is certain security information, including the full contents of any track of the magnetic stripe from the back of a card and the cardholder validation code (the three or four digit value printed on the signature panel of the card). Copies of these software programs that have version numbers older (those with a lower version number) than those indicated must be either upgraded, have a special security patch installed, or be replaced with compliant software to ensure that you do not store Security Data in violation of Visa, MasterCard or Discover Network's rules. If you are using any software programs different than the programs indicated, you must confirm with your software vendor that the version you are using is compliant with current security requirements. Steps You Should be Taking 14. What is a security assessor?A security assessor is an auditing company that specializes in information security. They use card association developed criteria (the PCI Data Security Standards) to validate whether or not a merchant's information security is robust enough to sufficiently protect cardholder data from unauthorized access or malicious parties. 15. Is it a common practice for security assessors to perform a re-assessment?Yes, assessors frequently are asked to revalidate those items that were not in place at the time of the initial review and provide an updated Report on Compliance. 16. Where can the PCI Data Security Standards Compliance Questionnaire be found?The PCI Self-Assessment Questionnaire is available for download on the PCI Data Security Standards Council website

  31. Appendix Frequently Asked Questions (FAQs) 17. What is a System Perimeter Scan?A System Perimeter Scan involves an automated tool that checks a merchant's or service provider's systems for vulnerabilities. The tool will conduct a non-intrusive scan to remotely review networks and Web applications based on the external-facing Internet protocol (IP) addresses provided by the merchant or service provider. The scan will identify vulnerabilities in operating systems, services, and devices that could be used by hackers to target the company's private network. The tool will not require the merchant or service provider to install any software on their systems, and it will not perform any denial-of-service attacks. 18. Is the System Perimeter Scan only applicable to e-commerce merchants?No. The System Perimeter Scan is applicable to all merchants and service providers with external-facing IP addresses. Even if an entity does not offer Web-based transactions, there are other services that make systems Internet accessible. Basic functions such as e-mail and employee Internet access will result in the Internet-accessibility of a company's network. These paths to and from the Internet can provide unprotected pathways into merchant and service provider systems if not properly controlled. If a merchant or service provider does not have any external-facing IP addresses, they will only be required to complete the Report On Compliance or the Compliance Questionnaire, as appropriate. 19. How do merchants determine the cost of compliance validation?The cost of the review varies greatly depending on the size of the environment to be reviewed, the chosen assessor, and the degree to which the merchant is already in compliance when the review commences. The cost of a System Perimeter Scan depends on the number of IP addresses to be scanned, the frequency of the scans, and the chosen assessor. 20. What if a merchant has outsourced the storage, processing, or transmission of cardholder data to a service provider?Merchants should deal only with PCI Data Security Standards compliant service providers. If there are service providers handling cardholder data on a merchant's behalf, the merchant is still responsible for the security of this data and must ensure that contracts with these service providers specifically include PCI Data Security Standards compliance as a condition of business. • 21. Do merchants need to include their service providers in the scope of their PCI Data Security Standards Review?Yes. Merchants are responsible for the compliance of their service providers. • 22. Can a merchant be considered compliant if they have outstanding non-compliance issues, but provide a remediation plan?No. Lack of full compliance will prevent a merchant from being considered compliant. Merchants are encouraged to complete the initial review, develop a remediation plan; complete items on the remediation plan, and revalidate compliance of those outstanding items in a timely manner. • Penalties for Non-compliance • 23. Are there fines associated with non-compliance of the PCI Data Security Standards?Yes. Visa, MasterCard, and Discover Network may impose fines on their member banking institutions when merchants do not comply with PCI Data Security Standards. You are contractually obligated to indemnify and reimburse your acquirer, for such fines. Please note such fines could be significant. • 24. Are there fines if cardholder data is compromised?Yes. If cardholder data that you are responsible for is compromised, you may be subject to the following liabilities and fines associated with non-compliance: • Potential fines of up to $500,000 (in the discretion of Visa, MasterCard, Discover Network or other card companies). • All fraud losses incurred from the use of the compromised account numbers from the date of compromise forward. • Cost of re-issuing cards associated with the compromise. • Cost of any additional fraud prevention/detection activities required by the card associations (i.e. a forensic audit) or costs incurred by credit card issuers associated with the compromise (i.e. additional monitoring of system for fraudulent activity). • Other PCI Compliance Resources • 25. Where can I go online to get more information?For information on association and industry cardholder information security programs, please visit the following websites on a regular basis: • Visa USA — http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html • MasterCard — https://sdp.mastercardintl.com • Discover Network — http://www.discovernetwork.com/fraudsecurity/disc.html • PCI Security Standards Council — https://www.pcisecuritystandards.org

More Related