1. Kevin R Perry August 12, 2014

2. Part 1: High Level Changes & Clarifications

3.  Service Provider: ◦ Any entity which stores, processes, or transmits cardholder data on a merchant’s behalf OR ◦ Any entity which manages components such as routers, firewalls, databases, physical security, and/or servers.  If you use a service provider(s), compliance is a shared responsibility ◦ Clarify roles & responsibilities requirement by requirement ◦ If relying on a service provider Report on Compliance, ensure it covers relevant requirements 3

4. 4

5.  NOT a change, but a clarification  PCI DSS has always been about continuous compliance  Business objective should be liability mitigation, not passing an assessment ◦ Breach Prevention ◦ Early Detection and Containment ◦ ‘Safe Harbor ’ “…enables an entity to monitor the effectiveness of their security controls on an ongoing basis, and maintain their … compliance … between assessments.” 5

6.  PCI DSS 2.0 requirement -> Testing procedure + Navigating the PCI DSS ◦ Testing procedures = Secret PCI DSS decoder ring ◦ Testing procedures are more prescriptive ◦ Testing procedures dictate the proper interpretation of the requirement ◦ Navigating the PCI DSS provided useful guidance and clarification of intent  PCI DSS 3.0 has reconciled requirements with testing procedure language  PCI DSS 3.0 now includes intent column 6

7. Navigating the PCI DSS 7

8. 8

9. Part 2: New/Evolving Requirements

10. 5.1.2: Evaluate evolving malware threats for any systems not considered to be commonly affected by malicious software 8.5.1: Service providers with remote access to customer premises must have unique auth for each customer 12.8.5 & 12.9: Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity 9.9.x: Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution New Requirements Effective 1/1/2014 10

11. 11.3: Implement a formal methodology for penetration testing 12.9: Service providers must provide a written agreement/ acknowledgement to their customers as specified in 12.8 New Requirements Effective 7/1/2015 11

12. 1.1.3Current diagram that shows cardholder data flows across systems and networks 2.4Maintain an inventory of system components in scope for PCI DSS to support development of configuration standards 5.3Ensure that anti-virus solutions are actively running (formerly in 5.2), and cannot be disabled or altered by users unless specifically authorized by management on a per-case basis 8.6Where other authentication mechanisms are used (for example, physical or logical security tokens) that the mechanisms must be linked to an individual account and ensure only the intended user can gain access with that mechanism New Requirements 12

13. 9.3Control physical access to sensitive areas for onsite personnel, including a process authorize access, and revoke access immediately upon termination 11.1.2Align with an already existing testing procedure, for incident response procedures if unauthorized wireless access points are detected 11.3.4If segmentation is used to isolate the CDE from other networks, perform penetration tests to verify that the segmentation methods are operational and effective 11.5.1Implement a process to respond to any alerts generated by the change-detection mechanism 6.5.10Coding practices to protect against broken authorization and session management* New Requirements 13 * Effective 7/1/2015

14. MYTH! System inventory only includes the main application servers Correct: It includes ALL network devices (routers, firewalls, switches), servers, etc. within the CDE network segments MYTH! Vulnerability scans are only required quarterly Correct: They’re also required after any “significant” change – you should define “significant” in your procedures! 14

16. Within Our Organization All IT resources  Desktop & Security  Network & Server  Applications & Database  Development Non-IT  HR & Legal  Accounting & Finance  Customer Service & Training  Executive Team Use External Resources  To guide your internal resources  All security reviews  QSA for scans  Penetration testing 16

17. 17

18. 18 Evolving Requirements Details (For your reference – Not discussed in seminar)

19. PCI DSS 3.0 Requirement ChangeComment 1.1.3Include Cardholder Data Flows on Network Diagram Generally Required to Properly Scope CDE 2.4Maintain Inventory of In-Scope System Components One of the First Questions An Assessor Should Ask 5.1.2Requirement to Evaluate Threats to Systems Not Commonly Affected by Malware Implicit in PCI DSS 2.0 5.3New Requirement to Ensure AV is Actively Running and Cannot Be Disabled/Altered by Users Implicitly Covered By PCI DSS 2.0 Given Requirement 1.4 Testing Procedure 6.5.10New requirement for coding practices to protect against broken authentication and session management Back-to-the-Future – This was included in PCI DSS 1.2. 3.0 has more rigor on testing procedures than 1.2 version. 19

20. PCI DSS 3.0 Requirement ChangeComment 8.2.3Combined minimum password complexity and strength requirements into single requirement, and increased flexibility for alternatives that meet the equivalent complexity and strength. Using alternatives of equal strength was one of the most common compensating controls NIST SP 800-63-1 for understanding equivalent password strength variability for passwords/phrases of different formats. 8.5.1New requirement for service providers with remote access to customer premises, to use unique Authentication credentials for each customer. Effective July 1, 2015 Logical application of PCI DSS v2.0’s Requirements 8.1 and 8.2. 20

21. PCI DSS 3.0 Requirement ChangeComment 8.6New requirement where other authentication mechanisms are used ( For example, physical or logical security tokens, smart cards, certificates, etc.) that the mechanisms must be linked to an individual account and ensure only the intended user can gain access with that Mechanism. Logical extension of PCI DSS v2.0 Requirement 8.1 and 8.3 guidance. 9.3New requirement to control physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination Logical application of PCI DSS v2.0’s Requirements 9.1 and 8.5.4. 21

22. PCI DSS 3.0 Requirement ChangeComment 9.9New requirements to protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution. Effective July 1, 2015 Significant new requirement which will involve training personnel to look for evidence of skimming attacks. 10.2.5Enhanced requirement to include changes to identification and authentication mechanisms (including creation of new accounts, elevation of privileges), and all changes, additions and deletions to accounts with root or administrative access. Clarification of a rather ambiguous logging requirement. 10.2.6Enhanced requirement to include stopping or pausing of the audit logs. Could be a significant change or a nonevent depending on what your applications support. 22

23. PCI DSS 3.0 Requirement ChangeComment 11.1Enhanced requirement to include an inventory of authorized wireless access points and a business justification (11.1.1) and added new requirement 11.1.2 for incident response procedures if unauthorized wireless access points are detected. Detecting unauthorized wireless access points (11.1) implicitly requires an inventory of authorized ones. PCI DSS v2.0 already covered 11.1.2 under Testing Procedure 11.1.e. 11.3 / 11.3.4 New requirement to implement a methodology for penetration testing. Effective July 1, 2015. Significant expansion of penetration testing requirement. Almost certain to require budget increases for testing and remediation. 23

24. PCI DSS 3.0 Requirement ChangeComment 11.5.1New requirement to implement a process to respond to any alerts generated by the change-detection mechanism (supports 11.5) Clarification. Covered as part of the 12.9.3 Testing Procedure. 12.2Expanded frequency of the risk assessment from at least annually to include updates after significant changes to the environment. Most organizations will need to update change management/governan ce procedures. 12.8.5New requirement to maintain information about which PCI DSS requirements are managed by Each service provider, and which are managed by the entity. Knowledge previously required for compliance. Formal documentation now required. 24

25. PCI DSS 3.0 Requirement ChangeComment 12.9New requirement for service providers to provide the written agreement/ acknowledgment to their customers as specified at requirement 12.8. Effective July 1, 2015 Service Provider requirement only. Should facilitate compliance with 12.8.2 25