PCI DSS 3.2COMPLIANCE CHECKLISTDEFEND YOURCARDHOLDER DATADSS Requirement 3Protect stored cardholder dataDO: Implement documented data retention and disposalpolicies to minimize cardholder data you collect and howlong it is retained. (3.1) Interview your employees to confirm policies are beingmaintained and quarterly processes are in place to removecardholder data outside of your retention policy. (3.1.b) Make sure the stored data and data in-transitis unreadable. (3.4, 4.1) Encrypt card data and protect the encrypted keys. (3.5) Mask your PAN data when it must be viewed using the fewestdigits possible (under the 6 First, 4 Last display maximum). (3.3) Create a cardholder flow diagram for all data flows throughyour organization. (1.1.3) Use a data discovery tool to find misplaced sensitive data inyour environment.DON’T: Store sensitive authentication data after authorization. (3.2)oException: Your organization is an issuer and hasbusiness justification. Store masked PAN data.oPCI DSS 3.2 Compliance ChecklistSolution: Encrypt it

DSS Requirement 4Encrypt transmission of cardholder dataacross open, public networksDO: Identify where you send cardholder data and ensure yourpolicies are not violated in the journey and only trusted keys orcertificates are used. (4.1) Select a sample of inbound and outbound transmissions andverify cryptography is maintained during transit. (4.1.c)DON’T: Send PANs by end-user messaging tech like email,SMS, or IM. (4.2) Use new technologies that utilize SSL/early TLS.(version 1.0 or earlier) Migrate cardholder data to systems using SSL/early TLS.(version 1.0 or earlier)PCI DSS 3.2 Compliance

DEFEND AGAINST THEEXTERNAL THREATDSS Requirement 1Install and maintain a firewallconfiguration to protectcardholder dataDO: Install a firewall at each internet connection (every device) anbetween any demilitarized zone (DMZ) and internal networkzone. (1.1.4, 1.4) Configure your firewalls with a description of groups responsiblefor network components and business justifications for allservices/protocols/ports in the configuration. (1.1.5, 1.1.6) Review firewall and router configuration at least every 6 monthsand confirm all other, non-config traffic (inbound or outbound)is denied. (1.1.7, 1.2.1) Configure routers to block connections between untrusted partsof the network and cardholder data. (1.2, 1.3) Assign responsibility for someone to check firewall logs daily.DON’T: Store cardholder data in the DMZ or any untrusted network.PCI DSS 3.2 Compliance ChecklistoSolution: Create a secure internal network zone. (1.3.6)

DSS Requirement 2Do not use vendor-supplied defaults forsystem passwords and othersecurity parametersDO: Identify a sys admin to be responsible for systemcomponents. (2.2.4) Maintain an inventory list of all system components in scopefor PCI DSS. (2.4) Document policies to change vendor-supplied default passwords,default wireless settings and remove default accounts beforeinstalling a system on your network. (2.1, 2.1.1, 2.5) Document system component config standards that addresssecurity weaknesses, limit service/protocol access basedon need, and follow hardening standards. (2.2, 2.2.2)DON’T: Implement multiple functions to a single server as this can createpermission conflicts. (2.2.1) Assume your vendors are maintaining anti-virus scanning.oPCI DSS 3.2 Compliance ChecklistRequirement: It’s your responsibility to confirm vendorsare up-to-date and scanning

DSS Requirement 5Protect all systems against malwareand regularly update anti-virus softwareor programsDO: Regularly update ant-virus software on your commonly affectedsystems and evaluate whether additional systems are at risk/need anti-virus. (5.1, 5.1.1, 5.1.2) Automate anti-virus scans and maintain anti-virus audit logs foryour systems. (5.2) Ensure only admins can alter or disable anti-virus. (5.3) Document procedures for protecting against malware. (5.4)DON’T: Wait to identify Malware by observing the damage it causes.oPCI DSS 3.2 Compliance ChecklistSolution: Install software that can observe behavioralanomalies and alert the necessary

DSS Requirement 6Develop and maintain secure systemsand applicationsDO: Establish a process to keep up-to-date with the latest securityvulnerabilities and identify the risk level. (6.1) Install all vendor-supplied security patches. (6.2.a) Document the impact, authorizer, functionality testing, andback-out procedures of all change control procedures. (6.4.5) Use strict development processes and secure coding guidelines(outlined in DSS) when developing software in-house. (6.3)DON’T: Wait longer than 1 month to install vendor-supplied securitypatches for risk levels identified as critical. (6.2.b) Test in-house software in your production environment, useproduction data during testing, or leave test accounts/IDsafter software release. (6.3.1, 6.4.1, 6.4.3)PCI DSS 3.2 Compliance

DEFEND AGAINST THEINTERNAL THREATDSS Requirement 7Restrict access to cardholder data bybusiness need to knowDO: Create a list of roles with access to the CDE that includes thedefinition of each role, their privilege level, and what permissionsare required for each role to function. (7.1, 7.3) Create a least-privilege policy for all employees and a default“deny-all” setting on all access control settings. (7.1.2, 7.2.3) Require documented approval by authorizers for any privilegeassignments or privilege changes in the CDE. (7.1.4)DON’T: Give excessive permissions to a role for that “rainy day” whenthey might require it.oSolution: Use a least privilege model where permissionsare granted only by business need.oSolution: Grant access only for the period of timethat it’s needed.PCI DSS 3.2 Compliance

DSS Requirement 8Identify and authenticate access tosystem componentsDO: Define and document procedures for user identification andauthentication on all system components. (8.1, 8.4) Assign unique IDs to all users, test those privilege controls, andrevoke access on inactive/terminated users. (8.1.1, 8.1.2, 8.1.3, 8.1.4) Monitor all accounts used by vendors and other third parties, thendisable them when not in use. (8.1.5) Lock out users IDs for 30 minutes after six failed accessattempts. (8.1.6, 8.1.7) Follow best practice guidelines outlined in DSS forpassword setting – including strong password composition,encrypting credentials, verifying ID before reset, and mandatoryresets every 90 days. (8.2.1, 8.2.2, 8.2.3, 8.2.4) Incorporate multi-factor authentication for all non-console adminaccess and remote access to CDE. (8.3)DON’T: Use the same password for multiple accounts or devices – onceone is compromised, they all will be. Use shared user IDs or authentication methods in the CDE. (8.5)PCI DSS 3.2 Compliance

DSS Requirement 9Restrict physical access tocardholder dataDO: (if applicable) Document process for physical access to CDE systems anda list of all devices, limiting access to roles that require it andmonitoring all with authorization tokens and surveillance.(9.1.1a, 9.1.1b, 9.2, 9.3, 9.9.1) Create visitor authorization and access controls that ensurevisitors are identified, documented, and monitored in areas thataccess the CDE. (9.4) Establish firm controls for physical media moved within the facility,use tracked couriers when moved outside, and ensure destroyedmedia cannot be reconstructed. (9.5, 9.6, 9.8) Train employees with processes to identify outside vendorsrequesting physical access and identify/report suspiciousbehavior (9.9.2, 9.9.3)PCI DSS 3.2 Compliance

DEFEND AGAINSTCOMPLACENCYDSS Requirement 10Track and monitor all access to networkresources and cardholder dataDO: Implement audit trails for all systems, alerts on suspicious activity,and a response plan for those anomalies. (10.1, 10.2, 10.6.2.b) Track all admin actions, login attempts, account changes, andpauses in the audit trail. (10.2.3, 10.2.4, 10.2.5, 10.2.6) Ensure each audit log captures user ID, event type, date and time,event success or failure, where the event originated from, andwhat resources are affected. (10.3) Keep all audit logs for at least one year with the last three monthsavailable for analysis. (10.7) Prevent audit trail tampering and use software to alert onlog changes. (10.5) Create a process that reviews CHD system logs daily, and onethat reviews all other system components based on your riskassessment results. (10.6.1, 10.6.2)DON’T: Give audit log access to anyone without a role justification. (10.5.1) Leave the daily audit trail review to manual methods – this can bea massive time void. Store audit logs for external-facing technologies on thosemachines – they can be compromised. (10.5.4)PCI DSS 3.2 Compliance

DSS Requirement 11Regularly test security systemsand processesDO: Document each authorized wireless access points with abusiness justification. (11.1.1) Implement processes to test and respond to authorizedand unauthorized wireless access points on aquarterly basis. (11.1, 11.1.2) Run vulnerability scans internally (with qualified personnel) andexternally (with Approved Scanning Vendor) with every quarterand significant network change, correcting and re-scanning allidentified vulnerabilities. (11.2) Run penetration tests internally and externally (with qualifiedpersonnel or 3rd party) annually, correcting and retesting anyexploitable risk found. (11.3) Deploy a change-detection tool that alerts personnel to anyunauthorized mod of critical systems and runs file comparisonsat least weekly. (11.5) Document a process for responding to change-detectionalerts. (11.5.1, 11.6)DON’T: Stick to the bare-minimum for testing.oPCI DSS 3.2 Compliance ChecklistSolution: Run reviews more frequently than thebare minimum – you will respond to threatssooner, before they are

DSS Requirement 12Maintain a policy that addresses infosecurity for all personnelDO: Publish an annually reviewed security policy that documents allCDE critical devices and services, defines appropriateaccess (in role, use of that access, and location), and implementsa risk assessment process. (12.1, 12.2, 12.3, 12.4) Annually complete security awareness training with all personnelwho access the CDE. (12.6) Assign role responsibilities to document procedures,analyze security alerts, administer accounts, and monitoraccess to all data. (12.5) Maintain documentation of service providers that requires lists ofservices provided, due-diligence in selection (including riskassessment), acknowledgement from SP accepting CHDresponsibility, and a process to monitor the providers PCI DSScompliance. (12.8.1, 12.8.2, 12.8.3, 12.8.4, 12.8.5) Create an annually tested response plan for a system breach thatoutlines tasks for each role, specific actions for different threats/alerts, how to cover critical systems and data backup, legalrequirements for reporting, and notifications of card brands. (12.10)PCI DSS 3.2 Compliance