Becoming PCI Compliant
Jason Brown - brownj52@michigan.gov Enterprise Security Architect Enterprise Architecture Department of Technology, Management and Budget State of Michigan @jasonbrown17
History of PCI DSS Began out of five separate programs o Visa s Cardholder Information Security Program o MasterCard s Site Data Protection o American Express Data Security Operating Policy o Discover s Information Security and Compliance o Japan Credit Bureau (JCB) Data Security Program Out of these five programs became the PCI Standards Security Council
Standards Payment Card Industry Data Security Standard (PCI- DSS) o Applies to those who store, process, and/or transmit cardholder data. Payment Application Data Security Standard (PA-DSS) o Applies to those who develop applications which store, process or transmit cardholder data. PIN Transaction Security o Secure management, processing, and transmission of personal identification number data during payment card transactions processing.
PCI DSS Versions Version 1 - Dec 15, 2004 o Aligned the 5 standards into 1 Version 1.1 - Sept. 2006 o Clarity enhancement and minor revisions Version 1.2 - Oct 1, 2008 o Clarity enhancement Version 2 - Oct 2010 Version 3 - November 2013 Version 3.1 - April 15, 2015 o Removal of SSL v3 and weak TLS ciphers
What is the Data Security Standard? Minimum set of requirements to protect cardholder data Applies to merchants, processors, acquirers, issuers, and service providers Applies to all entities which store, process, or transmit cardholder data and/or sensitive authentication data
What Defines Account Data? Cardholder Data Primary Account Number (PAN) Cardholder Name Expiration Date Service Code Sensitive Authentication Data Includes Full Track Data (Magnetic Stripe or chip equivalent) CAV2, CVC2, CVV2, CID PINs or PIN Blocks
Courtesy of pcisecuritystandards.org
Self Assessment Questionnaire Used to assist merchants and service providers in evaluating compliance 9 different questionnaires to choose from based on business process and credit card transactions Used for those who are not required to submit a Report on Compliance
Requirements Goals PCI DSS Requirements Build and maintain a secure network and systems 1. Install and maintain firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder data 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks Maintain a vulnerability management program Implement strong access control measures Regularly monitor and test networks Maintain an information security policy 5. Protect all systems against malware and regularly update antivirus software or programs 6. Develop and maintain secure systems and applications 7. Restrict access to cardholder data by business need to know 8. Identify and authenticate access to system components 9. Restrict physical access to cardholder data 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes 12. Maintain a policy that addresses information security for all personnel
Requirement 1 Install and Maintain Firewall Configuration 1.1 - Establish and implement firewall and router configuration standards. 1.2 - Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. 1.3 - Prohibit direct access between the Internet and systems with cardholder data. 1.4 - Install personal firewall software on mobile and employee owned devices which connect to the Internet. 1.5 - Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to everyone.
Requirement 2 Do Not Use Vendor-Supplied Defaults 2.1 - Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing on the network 2.2 - Develop configuration standards for all system components 2.3 - Encrypt all non-console administrative access using strong encryption 2.4 - Maintain an inventory of system components that are in scope for PCI DSS
Requirement 2 Continued 2.5 - Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties. 2.6 - Share hosting providers must protect each entity s hosted environment and cardholder data.
Requirement 3 Protect Stored Cardholder Data 3.1 - Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures, and processes. 3.2 - Do not store sensitive authentication data after authorization (even if encrypted). If received, render all data unrecoverable upon completion of the authorization process. 3.3 - Mask PAN when displayed (first 6 and last 4 are the max that can be displayed), such that only personnel with legitimate business need can see the full PAN.
Requirement 3 Continued 3.4 - Render PAN unreadable anywhere it is stored, which include digital media, backups, and logs. 3.5 - Document and implement procedures to protect keys used to secure stored cardholder data against disclosure or misuse. 3.6 - Fully document and implement all keymanagement processes and procedures for cryptographic keys used for encryption of cardholder data. 3.7 - Ensure security policies and procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.
Requirement 4 Encrypt Transmission of Cardholder Data Across Open Public Networks 4.1 - Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks. 4.2 - Never send unprotected PANs by end-user messaging technologies such as email, IM, SMS, or chat. 4.3 - Ensure that security policies and procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.
Requirement 5 Protect All Systems Against Malware and Regularly Update AV Software 5.1 - Deploy anti-virus software on all systems commonly affected by malicious software. 5.2 - Ensure that all anti-virus mechanisms are maintained by ensuring they are kept current, perform periodic scans, and generate logs. 5.3 - Ensure that all anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case or limited time period. 5.4 - Ensure that all security policies and procedures for protecting systems against malware are known, documented, in use, and known to all affected parties.
Requirement 6 Develop and Maintain Secure Systems and Applications 6.1 - Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking. 6.2 - Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical patches within 1 month. 6.3 - Develop internal and external software applications in accordance with PCI DSS, based on industry standards, incorporating information security throughout the software-development life cycle.
Requirement 6 Continued 6.4 - Follow change control processes and procedures for all changes to system components. 6.5 - Address common coding vulnerabilities in software-development processes by training developers in secure coding techniques and develop applications based on secure coding guidelines. 6.6 - Public-facing web application must address new threats and vulnerabilities on an ongoing basis. 6.7 - Ensure security policies and procedures are documented, in use, and to all affected parties known.
Requirement 7 Restrict Access to Cardholder Data by Business Need to Know 7.1 - Limit access to system components and cardholder data to only those whose job requires access. 7.2 - Establish an access control system for systems components that restricts access based on a user s need to know, and deny all other access. 7.3 - Ensure that security policies and operational procedures for restricting access to cardholder data are known, documented, in use, and known to all affect parties.
Requirement 8 Identify and Authenticate Access to System Components 8.1 - Define and implement policies and procedures to ensure proper user identification management for nonconsumer users and administrators on all system components. 8.2 - Ensure proper user-authentication management for non-consumer users and administrators on all system components. 8.3 - Incorporate two-factor authentication for remote network access originating from outside the network by personnel and all third parties. 8.4 - Document and communicate authentication policies and procedures.
Requirement 8 Continued 8.5 - Do not use group, shared, or generic ID s, passwords, or other authentication methods. 8.6 - Where other authentication mechanisms are used, authentication mechanisms must be assigned to an individual account and not shared among multiple accounts and physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access. 8.7 - All access to any database containing cardholder data is restricted. 8.8 - Ensure that policies and procedures are documented, in use, and known to all affected parties.
Requirement 9 Restrict Physical Access to Cardholder Data 9.1 - Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. 9.2 - Develop procedures to easily distinguish between onsite personnel and visitors. 9.3 - Control physical access for onsite personnel to sensitive areas. 9.4 - Implement procedures to identify and authorize visitors. 9.5 - Physically secure all media.
Requirement 9 Continued 9.6 - Maintain strict control over the internal or external distribution of any kind of media. 9.7 - Maintain strict control over the storage and accessibility of media. 9.8 - Destroy media when it is no longer needed for business or legal reason. 9.9 - Protect devices that capture payment card data via direct physical interaction with the card from tampering or substitution. 9.10 - Ensure that security policies and operational procedures for restricting physical access to cardholder data are documented, in use, and known to all affected parties.
Requirement 10 Track and Monitor All Access to Network Resources and Cardholder Data 10.1 - Implement audit trails to link all access to system components to each individual user. 10.2 - Implement automated audit trails for all system components to reconstruct events. 10.3 - Record at least the following audit trail entries for all system components; user ID, event type, date and time, success/failure, source of event and the name of the affected resource. 10.4 - Using time-synchronization technology, sync all system clocks and times.
Requirement 10 Continued 10.5 - Secure audit trails so they cannot be altered. 10.6 - Review logs and security events for all system components to identify anomalies or suspicious activity. 10.7 - Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis. 10.8 - Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.
Requirement 11 Regularly Test Security Systems and Processes 11.1 - Implement processes to test for the presence of wireless access points along with identifying all authorized and unauthorized wireless access points on a quarterly basis. 11.2 - Run internal and external network vulnerability scans at least quarterly and after any significant change in the network. 11.3 - Implement a methodology for penetration testing.
Requirement 11 Continued 11.4 - Use intrusion detection and/or prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as critical points in the cardholder data environment. Alert personnel on suspected compromises. 11.5 - Deploy a change-detection mechanism to alert personnel to unauthorized modification of critical system files, configuration files, or content files. Configure software to perform critical file comparisons at least weekly. 11.6 - Ensure that security policies and operation procedures for security monitoring and testing are documented, in use, and known to all affected parties.
Requirement 12 Maintain a Policy that Addresses Information Security for all Personnel 12.1 - Establish, publish, maintain, and disseminate a security policy. 12.2 - Implement a risk-assessment process 12.3 - Develop usage policies for critical technologies and define proper use of these technologies 12.4 - Ensure that the security policy and procedures clearly define information security responsibilities for all personnel. 12.5 - Assign an individual or team to information security management responsibility.
Requirement 12 Continued 12.6 - Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security. Screen potential personnel prior to hire to minimize the risk of attacks from internal sources. 12.8 - Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or could affect the security of cardholder data. 12.9 - Service providers acknowledge in writing to customers they are responsible of the security of the cardholder data the provider possesses. 12.10 - Implement an incident response plan.
SAQ A Card-Not-Present, All Cardholder Data Functions Outsourced Company accepts only card-not-present (e-commerce, mail/telephone) transactions. All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service provider. Company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies on third parties. Company retains only paper reports or receipts with cardholder data, and are not electronically received.
SAQ A-EP Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing Company accepts only e-commerce transactions. All processing of cardholder data, with the exception of payment page, is entirely outsourced to a PCI DSS validated third-party payment processor. Company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party to handle all these functions. Company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.
SAQ B Merchants with Only Imprint Machines or Only Standalone, Dial-Out Terminals. No Electronic Cardholder Data Storage. Uses only imprint machines and/or uses only standalone, dial-out terminals. Standalone terminals are not connected to the Internet. Standalone terminals are not connected to any systems within environment. Does not transmit cardholder data over a network (internal or external). Company does not store cardholder data in electronic format.
SAQ C Merchants with Payment Application Systems Connected to the Internet No Electronic Cardholder Data Storage o Company has a payment application system and an Internet connection on the same device and/or same local area network (LAN). o Payment application system/internet device is not connected to any other systems within your environment. o The physical location of the POS environment is not connected to other premises or locations, and any LAN is for a single location. o Company retains only paper reports or paper copies of receipts, and these documents are not received electronically. o Company does not store cardholder data in electronic format.
SAQ D Applies to SAQ-eligible merchants not meeting the criteria for any other SAQ type. o E-commerce merchants who accept cardholder data on their website. o Merchants with electronic storage of cardholder data. o Merchants that do not store cardholder data electronically but that do not meet the criteria of another SAQ type. o Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment.
Merchant Level 4 Less than 20,000 Visa or MasterCard e-commerce transactions annually Up to 1 million Visa or MasterCard transactions annual - non e-commerce Validation Requirements o Annual Self-Assessment Questionnaire o Quarterly network scan o Attestation of Compliance
Merchant Level 3 20,000-1 million Visa or MasterCard e-commerce transactions annually Validation Requirements o Annual Self-Assessment Questionnaire o Quarterly network scans o Attestation of Compliance Form
Merchant Level 2 1-6 million Visa or MasterCard transactions annually Validation Requirements o Annual Self-Assessment questionnaire o Quarterly network scan o Attestation of Compliance Form MasterCard requires a Qualified Security Assessor or a certified Internal Security Auditor to sign off on the Attestation of Compliance
Merchant Level 1 Process more than 6 million Visa or MasterCard transactions per year Any merchant who has experienced a data breach or attack which resulted in compromised data Any merchant identified by any card association as Level 1 Validation Requirements o Annual Report on Compliance (ROC) by Qualified Security Assessor o Quarterly network scan o Attestation of Compliance Form
When Do I Need a QSA Level 1 merchants are required Level 2 merchants have options (MasterCard) o Train internal employees to become an Internal Security Assessor (ISA) and remains in good standing with PCI SSC o Hire a Qualified Security Assessor o Others can self assess Level 3 and 4 merchants are able to self assess
Developing Scope People, processes and procedures Comprise of systems which store, process or transmit cardholder data - both physical and virtual Systems which contain logs or perform maintenance on the cardholder data environment Network equipment, firewalls, IDS/IPS and other infrastructure components located within or connected to the CDE Network segmentation is not required however it is highly recommended o Without segmentation, entire network and system components are in scope
Documents Assisting in Defining Scope PCI DSS Document - Scope of PCI DSS Requirements ISACA - Open PCI DSS Scoping Document Cisco Systems - PCI Design Guides and Solutions for Retail Along with many others...
What Do I Need To Submit Yearly? Dependent on acquirer (or bank) o AmEx, Discover, JCB or other banks which use Visa or MasterCard Normally o Self Assessment Questionnaire o Quarterly scans by approved scanning vendor (ASV) o Attestation on Compliance signed by executive of company o Other documentation required by the acquirer
Thank you Questions Material provided by: https://www.pcisecuritystandards.org