PCI DSS. CollectorSolutions, Incorporated

Transcription

1 PCI DSS Robert Cothran President CollectorSolutions CollectorSolutions, Incorporated Founded as Florida C corporation in 1999 Approximately 235 clients in 35 states Targeted market focus : utilities, tax collectors, state & local governments, municipal services Currently managing more than $2.5 billion in transactions annually 9/24/

2 PCI DSS History In order to ensure that card holder information was securely managed, Visa instituted the Cardholder Information Security Program (CISP) program in June 2001 In 2004, the CISP requirements were incorporated into an industry standard known as Payment Card Industry (PCI) Data Security Standard (DSS) resulting from a cooperative effort between Visa and MasterCard to create common industry security requirements. Effective September 7, 2006, the PCI Security Standards Council (SSC) owns, maintains and distributes the PCI DSS and all its supporting documents. Visa, however, continues to manage all data security compliance enforcement and validation initiatives. 9/24/ PCI DSS Overview Payment Card Industry Data Security Standard (PCI DSS ) PCI Security Standards Council (CSS) Overall purpose Identify security weaknesses within an organization Minimize the chance of compromise of card information Minimize effects if compromise of card information does occur 9/24/

3 PCI DSS Overview The PCI DSS consists of twelve basic requirements: Install and maintain a firewall configuration to protect data Do not use vendor supplied defaults for system passwords and other security parameters Protect stored data Encrypt transmission of cardholder data and sensitive information across public networks Use and regularly update anti virus software Develop and maintain secure systems and applications Restrict access to data by business need to know Assign a unique ID to each person with computer access Restrict physical access to cardholder data Track and monitor all access to network resources and cardholder data Regularly test security systems and processes Maintain a policy that addresses information security 9/24/ PCI DSS Overview Any merchant that stores, processes or transmits payment card holder data must be PCI DSS compliant Merchants utilizing third party processors must be PCI DSS compliant, although the merchant s exposure and/or compliancy requirements may be greatly reduced 9/24/

4 PCI DSS Overview There are three basic characteristics that must be identified by a merchant in order to ascertain the applicable PCI DSS compliancy requirements: How many Visa transactions are processed annually How are Visa transactions processed Does the merchant have any public facing IPs 9/24/ PCI DSS Overview Merchants will be categorized in 1 of 4 levels depending on the number of Visa transactions processed annually For merchants required to perform annual SAQs, the type of SAQ required is largely dependent on how transactions are processed 9/24/

5 PCI DSS Merchant Levels Merchant Level 1 Merchants processing over 6 million Visa transactions annually (all channels) Merchant Level 2 Merchants processing 1 million to 6 million Visa transactions annually (all channels) Merchant Level 3 Merchants processing 20,000 to 1 million Visa ecommerce transactions annually Merchant Level 4 Merchants processing less than 20,000 Visa ecommerce transactions annually and all other merchants processing up to 1 million Visa transactions annually 9/24/ PCI DSS Validation Requirements Merchant Level 1 Annual Report on Compliance (ROC) by Qualified Security Assessor (QSA) or internal auditor if signed by officer of the company Quarterly network scan by Approved Scan Vendor (ASV) Attestation of Compliance Form Merchant Level 2 Annual Self Assessment Questionnaire (SAQ) Quarterly network scan by ASV Attestation of Compliance Form Merchant Level 3 Annual SAQ Quarterly network scan by ASV Attestation of Compliance Form Merchant Level 4 Annual SAQ recommended Quarterly network scan by ASV if applicable Compliance validation requirements set by acquirer 9/24/

6 PCI DSS Validation Requirements Any merchant that has suffered a breach that resulted in an card holder data compromise may be escalated to a higher validation level All merchants with public facing IPs must perform quarterly, external network scans by ASV in order to achieve PCI DSS compliance 9/24/ PCI DSS SAQ Self Assessment Questionnaire (SAQ) Validation tool to be used for self assessment Current questionnaire version 2.1 (June 2012) There are 5 merchant questionnaire categories each is generally tailored based on how cards are processed 9/24/

7 PCI DSS SAQ Categories SAQ A Card not present No card holder data processed or transmitted by any merchant systems all activities managed by a third party No card holder data stored in any electronic fashion on any merchant system Third party is PCI DSS compliant Example : ecommerce (never face to face) SAQ B Imprint and/or dial out terminal only Dial out terminals are stand alone not connected to the internet nor any other merchant system No card holder data is transmitted over a network (internet or internal network) No card holder data stored in any electronic fashion on any merchant system Example : Brink & Mortar (never ecommerce) 9/24/ PCI DSS SAQ Categories SAQ C VT Payments are processed via browser accessed virtual terminal (payments are processed in no other manner) Virtual terminal solution is provided and hosted by a third party Third party is PCI DSS compliant Virtual terminal does not read data directly from payment cards using connected hardware devices (e.g. card readers) No card holder data stored in any electronic fashion on any merchant system SAQ C Internet enabled payment applications Payment application is local to the merchant POS machine (not accessed via browser) and utilizes an internet connect to transmit card holder data No card holder data stored in any electronic fashion on any merchant system 9/24/

8 PCI DSS SAQ Categories SAQ D All merchants not include in previous categories Such merchants will generally need to validate compliance by satisfying every PCI DSS requirement Storing any card holder information in an electronic fashion would result in a SAQ D categorization SAQ P2PE HW P2PE (Point to Point Encrypted Solution) Merchants using hardware payment terminals included in a P2PE solution Merchants do not have access to clear text account data No card holder data stored in any electronic fashion on any merchant system (including legacy data) All security controls listed in P2PE Instruction Manual (PIM) have been implemented 9/24/ How Do I Become PCI DSS Compliant? What does a small to medium sized business (Level 4 merchant) have to do in order to satisfy the PCI DSS requirements? Complete the applicable SAQ Complete and obtain evidence of a passing vulnerability scan with a PCI SSC Approved Scanning Vendor (ASV) Complete the relevant Attestation of Compliance Submit the SAQ, evidence of a passing scan (if applicable), and the Attestation of Compliance, along with any other requested documentation, to your acquirer Scanning does not apply to all merchants. It is required for SAQ C and D those merchants with external facing IP addresses (if you electronically store cardholder information or if your processing systems have any internet connectivity, a quarterly scan by an approved scanning vendor is required) 9/24/

9 PCI DSS Service Providers Level 1 VisaNet processors or any service provider that stores, processes and/or transmits over 300,000 Visa transactions annually Annual On Site PCI Data Security Assessment (by QSA) Quarterly Network Scan (by ASV) Level 2 Any service provider that stores, processes and/or transmits less than 300,000 Visa transactions annually Annual PCI Self Assessment Questionnaire (by service provider) Quarterly Network Scan (by ASV) 9/24/ PA DSS Payment Application Data Security Standard (PA DSS) Applications that are deployed to the merchant system (as opposed to virtual solutions that are accessed via a webbrowser) should be certified PA DSS 9/24/

10 PCI DSS Basics Never store magnetic strip contents, card code values, and PINs and/or PIN blocks Never store PANs (primary account numbers) in an unprotected manner Secure your systems Firewall and network segmentation Strong user name and password utilization Do not store any data that isn t absolutely required 9/24/ Consequences of Compromise Loss of consumer confidence Litigation (lawsuits) Fines, penalties, or revocation of right to take cards ( blacklisted ) 9/24/

11 Consequences of Compromise Data for 3.4 million credit cards were compromised last year, down from 4.6 million in 2010 Most payment card thefts are from small businesses with only about 5 percent last year from large organizations. More than three quarters of breaches involve losses of fewer than 10,000 records. Just seven breaches have involved more than 1 million records each. Notable Mega Breaches 2012 Global Payments : 1.5 million credit card numbers Zappos : Personal data of 24 million customers 2011 Epsilon : Millions of names and addresses (estimated cost of between $225 million and $4 billion) Sony : 100 million user accounts (estimate cost to Sony of up to $2 billion) 2008 Heartland Payment Systems : 100 million credit card numbers (the company paid about $140 million in fines and settlements) 2007 TJ Maxx : 45 million credit card numbers 9/24/ Best Regards and Safe Travels To All Robert Cothran President CollectorSolutions 9/24/