December 2013 New PCI Standards Enhance Security of Cardholder Data By Angela K. Hipsher, CISA, QSA, Jeff A. Palgon, CPA, CISSP, QSA, and Craig D. Sullivan, CPA, CISA, QSA Payment cards a favorite target of criminals will become more difficult to hack, thanks to new Data Security Standards (DSS) by the Payment Card Industry (PCI) Security Standards Council. Issued in November 2013, PCI DSS Version 3.0 goes into effect Jan. 1, 2014. Depending on the specific requirement, merchants, service providers, and third parties that store, process, or transmit cardholder data must comply with Version 3.0 beginning Jan. 1, 2015. Version 3.0 includes many changes, and clarifications to previous versions of the DSS, including: Scoping and segmentation of the IT systems that handle cardholder data Monitoring and managing these IT systems for potential vulnerabilities Implementing a number of requirements designed to provide greater protection of cardholder data Scoping and Segmentation Previously, PCI Security Standards Council guidance consistently stated that systems that store, process, or transmit cardholder data were subject to the requirements of the PCI DSS. Version 3.0 expands the definition by adding the following words: PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. 1 This change means that systems that attach to or support the infrastructure of the cardholder data environment (CDE) will be considered for inclusion in scope for assessment by an independent Qualified Security Assessor (QSA). Attached systems communicate with CDE systems, while support systems define and regulate the CDE secure environment. In addition, the people and processes that handle cardholder data should be considered for inclusion in scope even if that data is stored on paper. As a rule of thumb, if a system can affect the security of cardholder data, it is considered to be in scope. 1
Crowe Horwath LLP Under Version 3.0, organizations must perform several new tasks affecting scope. These include maintaining a current network diagram that shows cardholder data flows as well as all connections into and out of the environment (Requirement 1.1.3); an inventory of system components (2.4); an up-to-date list of devices (9.9.1); and an inventory of all authorized wireless access points, including justification for those access points (11.1.1). Under Requirement 11, organizations must conduct vulnerability scans on the cardholder data environment on at least a quarterly basis. Recent guidance encourages service providers to not only conduct these tests more frequently but also to test the entire network, not just the cardholder data environment. Under new requirement 11.3.4, organizations that have reduced the scope of PCI compliance efforts through segmentation or isolation will be required, during their annual penetration tests, to verify that the segmentation methods are operational and effective. This means that the third party performing the penetration test will need to validate that it is unable to access the CDE from the organization s operational network. Vulnerability Monitoring and Management To cope with the growing quantity of threats to the customer data maintained by organizations that store, process, or transmit payment card data, these organizations must address the following issues: Identification and ranking of vulnerabilities. Because there is a constant stream of attacks using widely published exploits, many requirements exist to help address the concept of vulnerability management. Under Requirement 6, management must have a process to identify new vulnerabilities, risk-rank them, and quickly address systems with the highest risks. This may require implementing new controls while waiting for software vendors to issue patches. Corrective patches. Requirement 6 also covers the patching requirement, and management should have a detailed, risk-based approach to address critical security patches within 30 days of release. In addition, management should consider patching the most vulnerable systems first. Vulnerability scans. Under Requirement 11, organizations must conduct vulnerability scans on the CDE on at least a quarterly basis. Recent guidance encourages service providers to not only conduct these tests more frequently but also to test the entire network, not just the CDE. 2
New PCI Standards Enhance Security of Cardholder Data Configuration standards. Because common operating systems, databases, and software applications have known weaknesses, organizations have many ways to configure these systems. Requirement 2 encourages organizations to adopt configuration standards for each type of system. This helps ensure that there are consistent methods to address security vulnerabilities, especially as new systems continue to be introduced into IT environments. Malware threats. Under 5.1.2, a new requirement, organizations have to evaluate malware threats for systems not commonly affected by malicious software. This requirement will introduce the increased need for organizations to stay up to date with the industry trends in emerging malicious software. Antivirus controls. Under 5.3, a new requirement, organizations will need to assure that antivirus solutions are actively running (formerly noted in 5.2) and cannot be disabled or altered by users unless specifically authorized by management on a per-case basis. Additional precautions, such as disconnecting IT devices from the Internet and then performing a full scan of those devices before introducing them back into the environment, may need to be implemented. Organizations will want to update IT security policies and procedures to include procedures for enhanced security controls surrounding antivirus solutions. Protecting Cardholder Data Version 3.0 also includes a number of additional enhancements, revisions, and new requirements designed to provide even greater protection of cardholder data. Application coding. Requirement 6.5 provides clarification for coding practices to document how primary account numbers and sensitive authentication data are stored in memory. Software developers need to understand how payment card applications encrypt and/or erase sensitive data and how to prevent other applications from accessing memory where sensitive data might be stored temporarily. Organizations also will need to document how memory is secured and provide evidence that training does include secure memory storage. Protection against broken authentication. To prevent unauthorized access to cardholder data, new requirement 6.5.10 suggests that organizations incorporate secure session tokens in URLs. Evidence of compliance will need to be demonstrated by July 1, 2015. Passwords. Under 8.2.3, there are now more flexible standards for the passwords and passphrases organizations use to protect cardholder data. Organizations may now use stronger passwords and passphrases that may not have met requirements 8.5.10 and 8.5.11 in Version 2.0. 3
Crowe Horwath LLP Unique authentication credentials for service providers. Under 8.5.1, a new requirement, service providers such as third parties that manage point-of-sale (POS) systems for retailers must now use unique authentication credentials when accessing their customers systems. Previously, some service providers used the same credentials for multiple customers, which exposed all of those customers to security breaches when those credentials were compromised. Service providers also can comply with this requirement by implementing twofactor authentication, such as using a password or personal identification number (PIN) sent to a mobile phone when accessing customer systems. Service providers will need to document their compliance with 8.5.1 beginning July 1, 2015. Security considerations for authentication mechanisms. Another new requirement, 8.6, strengthens control over authentication mechanisms that organizations use, such as physical or virtual security tokens, smart cards, and certificates. As in the case of 8.5.1, organizations cannot share these mechanisms with multiple users. Each user must have his or her own mechanism so that activities can be traced to them. Physical access. Requirement 9.3 states that organizations must document an individual s physical access to CDEs. Such access must be authorized and required for an individual s job function. There also needs to be a process in place to revoke physical access immediately when employees resign or are terminated. Protection of POS devices. Under 9.9, a new requirement, organizations must physically secure POS card-reading devices. There have been a number of well-publicized incidents over the last few years where criminals added information-skimming devices to ATMs and other card-reading devices. Organizations will need to document their inspection of POS devices and provide training to individuals who are going to oversee POS systems to make sure that they know how to detect tampering or unauthorized modification or substitution. This requirement becomes effective on July 1, 2015. Removal of devices. In addition to maintaining an inventory of all devices, organizations will need to have a process in place for removing and decommissioning devices under 9.9.1, another new requirement. Logging controls. One of the most challenging requirements always has been the logging of changes to identification and authentication mechanisms. Requirement 10.2.5 always has required logging and identification and authentication mechanisms, but Version 3.0 expands on that to include the account creation, escalation of access privileges, and modifications to accounts with root or administrative rights. For example, anytime someone accesses the root account, that activity will need to be logged and included in the log management and review process. The same requirement applies whenever users are granted administrative rights that they did not have before. 4
New PCI Standards Enhance Security of Cardholder Data Audit logs. Requirement 10.2.6 is a direct answer to the common attacker s practice of turning off or pausing audit logs so systems are unable to capture unauthorized activity. This requirement now goes beyond just the log initialization and includes stopping and pausing events to be written into audit logs. Penetration testing. Under 11.3, a new requirement, organizations must develop and implement a methodology by July 1, 2015, for penetration or intrusion testing of the cardholder data perimeter and critical systems. The testing will have to be conducted from both inside and the outside the perimeter network, and must also validate that the network segmentation methods are operational and effective (11.3.4). Until 11.3 goes into effect, organizations should continue to follow the current PCI DSS 2.0 requirement for penetration testing. Response to alerts. Another new requirement, 11.5.1, was put in place to support file integrity monitoring and change-detection tools. Organizations must have a process to respond to the alerts that that these tools generate. Risk assessments. Version 3.0 states that organizations should conduct risk assessments not only annually, but also after making significant changes to their computing environments. Examples of significant changes include an acquisition or merger with another business entity, a redesign of the network, or a physical location change to a new data center. The role of service providers. Under 12.8.5, a new requirement, organizations have to document which PCI DSS requirements they manage themselves and which are managed by external service providers. This requirement is designed to help organizations understand what steps they should be performing and not assume that their service providers are going to meet all requirements for them. In addition, service providers need to acknowledge in writing that they are responsible for the cardholder data that they store, transmit, or process on behalf of their customers (12.9). 5
Crowe Horwath LLP What s New in PCI DSS Version 3.0? Following are key changes from the last version of the PCI Data Security Standards. Note that there are no changes in Requirements 3, 4, and 7. 1 Install and maintain a firewall configuration to protect cardholder data. 1.1.3 Must include a current network diagram that shows cardholder data flows 2 Do not use vendor-supplied defaults for system passwords and other security parameters. 2.4 New requirement to maintain an inventory of all system components for PCI DSS 3 Protect stored cardholder data. 4 Encrypt transmission of cardholder data across open, public networks. 5 Protect all systems against malware and regularly update antivirus software or programs. 5.1.2 New requirement to evaluate evolving malware threats for any systems not considered to be commonly affected by malicious software 5.3 New requirement to implement controls to make sure antivirus software cannot be disabled or altered by users unless specifically authorized by management on a per-case basis 6 Develop and maintain secure systems and applications. 6.5 Provides clarification for coding practices to document how primary account numbers and sensitive authentication data are stored in memory 6.5.10 New requirement for coding practices to help protect against broken authentication and session management (effective July 1, 2015) 7 Restrict access to cardholder data by business need to know. 8 Identify and authenticate access to system components. 8.2.3 Minimum password complexity and strength requirements combined into a single requirement and greater flexibility for alternatives that meet the equivalent complexity and strength 8.5.1 New requirement for service providers to use different credentials for access to different customer environments (effective July 1, 2015) 8.6 New requirement for security considerations for authentication mechanisms such as physical security tokens, smart cards, and certificates to address authentication methods other than passwords 6 6
New PCI Standards Enhance Security of Cardholder Data 9 Restrict physical access to cardholder data. 9.3 New requirement to control physical access to sensitive areas for onsite personnel, including a process to authorize access and revoke access immediately upon termination 9.9 New requirements to protect POS devices from tampering or unauthorized modification or substitution (effective July 1, 2015) 9.9.1 New requirement to maintain an up-to-date list of devices 10 Track and monitor all access to network resources and cardholder data. 10.2.5 New requirements for more stringent controls over logging of changes to identification and authentication mechanisms including but not limited to creating new accounts and elevating privileges and all changes, additions, or deletions to accounts with root or administrative privileges 10.2.6 Requires logging to include initialization, stopping, or pausing of the audit logs 11 Regularly test security systems and processes. 11.1.1 Requires inventory of all authorized wireless access points (including justification for those access points) 11.3 New requirement to develop and implement a methodology for penetration testing (effective July 1, 2015). Penetration testing requirements from PCI DSS Version 2.0 must be followed until the new requirement takes effect 11.3.4 New requirement, if segmentation is used, to isolate the CDE from other networks. The penetration test will need to verify that the segmentation methods are operational and effective 11.5.1 New requirement to implement a process to respond to any alerts generated by the change-detection mechanism 12 Maintain a policy that addresses information security for all personnel. 12.2 Clarification that the risk assessment should be performed at least annually and after significant changes to the environment 12.8.5 New requirement to maintain information about which of the PCI DSS requirements are managed by the service provider and which are managed by the entity 12.9 New requirement for service providers to acknowledge, in writing to the customer, that they will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes, or transmits the customer s cardholder data or sensitive authentication data or manages the CDE on behalf of a customer (effective July 1, 2015) 7 7
A Rigorous Step Up PCI DSS Version 3.0 is a rigorous step up in protection for cardholder data. The fact that the PCI Security Standards Council is giving organizations a full year to comply with most changes and 18 months for some additional new requirements reflects the significant enhancement that these more stringent security standards represent. As organizations begin the process of adopting Version 3.0, they should recognize new challenges that they may face in achieving compliance and review new software solutions and programs that might help them stay in compliance. Doing so not only might simplify compliance but also could help organizations to become early adopters of these important new security standards. Changing PCI Standards Bring New Challenges, a recording of a Crowe webinar presentation by Angela K. Hipsher, Jeff Palgon, and Craig D. Sullivan, is available at http:///risk14112e. aspx?origref=pciupdate2013 Contact Information Angie Hipsher is with Crowe Horwath LLP in the Indianapolis office. She can be reached at 317.208.2430 or angie.hipsher@crowehorwath.com. Jeff Palgon is with Crowe in the Atlanta office. He can be reached at 404.442.1623 or jeffrey.palgon@crowehorwath.com. Craig Sullivan is a partner with Crowe in the South Bend office. He can be reached at 574.236.7618 or craig.sullivan@crowehorwath.com. 1 Scope of PCI DSS Requirements, Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures, Version 3.0, November 2013, p. 10, https://www.pcisecuritystandards.org/ documents/pci_dss_v3.pdf Crowe Horwath LLP is an independent member of Crowe Horwath International, a Swiss verein. Each member firm of Crowe Horwath International is a separate and independent legal entity. Crowe Horwath LLP and its affiliates are not responsible or liable for any acts or omissions of Crowe Horwath International or any other member of Crowe Horwath International and specifically disclaim any and all responsibility or liability for acts or omissions of Crowe Horwath International or any other Crowe Horwath International member. Accountancy services in Kansas and North Carolina are rendered by Crowe Chizek LLP, which is not a member of Crowe Horwath International. This material is for informational purposes only and should not be construed as financial or legal advice. Please seek guidance specific to your organization from qualified advisers in your jurisdiction. 2013 Crowe Horwath LLP RISK14919 8