PCI DSS 3.0: What the New Regulations Mean to You

> www.alertlogic.com

PCI DSS 3.0: What the New Regulations Mean to You

March 4, 2014

> www.alertlogic.com 2

Today’s Presenters

Jeff Tutton, MSc., QSA, PA-QSA

Chief Information Security Officer

Intersec Worldwide

Chris NoellVice President, Product Management

Alert Logic


Today

Agenda• Why Comply?• PCI DSS 3.0 Basics• Preparing Your

Organization• What Next?

Logistics• Ask a question anytime

using the “Question Box” • Look for slides on the

Alert Logic SlideShare account

• You’ll get an email with a link to today’s recording

• Live Tweet today’s event

#AlertLogic_PCI


About Intersec Worldwidehttp://www.intersecworldwide.com/

Tools, technology and people for security & compliance

• PCI qualified QSA, PA-QSA

• Security engineering firm

• Remediation team includes:– Network Engineers (Cisco-

CCIE)– Secure Coding Experts– Penetration Testers– Temp CIO/CISO

• Conduct Incident Response and Forensics

• Managed service offerings– Policy Review and

Development– Managed Network

Discovery– Vulnerability Prioritization– More


Why Comply?


The End Goal of Compliance is SecurityAttacks are going to happen


Most Organizations are Not Fully CompliantSource: Verizon 2014 PCI Compliance Report


PCI DSS 3.0 Basics

Part 1: High Level Changes & Clarifications


PCI DSS 3.0: More Detail, More Precision

Two Constituencies:

Those who have rigorous, third-party PCI DSS assessment

= Business as Usual

Those who don’t (SAQ, assessor who draws scope very narrowly)

= Significant Changes

1. 2.


Scoping Change: Service Providers

• 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

Scoping Change: Continuous Compliance


Continuous Compliance Implications

• 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.”


There are 62 Clarifications in PCI DSS 3.0

• 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


E.g. Requirement 5.2 in PCI DSS 2.0

Navigating the PCI DSS


E.g. Requirement 5.2 in PCI DSS 3.0


PCI DSS 3.0 Basics

Part 2: New/Evolving Requirements


New Requirements: What’s Big?

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


New Requirements: What’s Big?

Implement a formal methodology for penetration testing

Service providers must provide a written agreement/ acknowledgement to their customers as specified in 12.8

New Requirements Effective 7/1/2015

11.3

12.9


Additional New Requirements

1.1.3 Current diagram that shows cardholder data flows across systems and networks

2.4 Maintain an inventory of system components in scope for PCI DSS to support development of configuration standards

5.3 Ensure 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.6 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

New Requirements


Additional New Requirements Continued

9.3 Control physical access to sensitive areas for onsite personnel, including a process authorize access, and revoke access immediately upon termination

11.1.2 Align with an already existing testing procedure, for incident response procedures if unauthorized wireless access points are detected

11.3.4 If 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.1 Implement a process to respond to any alerts generated by the change-detection mechanism

6.5.10 Coding practices to protect against broken authorization and session management*

New Requirements

* Effective 7/1/2015


Avoid These Misconceptions

MYTH! System inventory only includes the main application servers

Correct: It includes ALL network devices, 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!

MYTH! Code reviews are enough for public-facing web applications under Requirement 6.6

Correct: Clarified guidance requires an application vulnerability security assessment tool (or method), or a web application firewall (WAF) after “any” changes – this clarification is important


Preparing Your Organization


Preparation Checklist

1. Produce and validate a full listing of components within the CDE

2. Produce/update cardholder data flow diagrams

3. Perform (or have performed) a DSS 3.0 gap analysis

4. Review and update penetration testing methodology and service provider contracts

5.

Review the requirements under 6.6 to make sure you are meeting them fully


• Review them, learn from them and use as starting point

• Conduct a Gap from 2.0 to 3.0

• Start asap• Keep them!

Store for 7 years

What to do with Existing PCI 2.0 Reports?


Who to Involve?

Within Your Organization

• All IT resources • Network & Systems• Applications & Database• Development

• Non-IT• HR & Legal• Accounting & Finance• Customer Service &

Training• Exec Team

Use External Resources

• To guide your internal resources

• All security reviews• Penetration testing• Secure code reviews


What’s Next?


Next Steps

• Complete gap analysis before formal assessment

• Find your weaknesses and fail points … soon!

• Bring all Security & Compliance “skeletons” out of the closet

• Consider separate PCI Gap & PCI Assessment teams– It’s not required but fresh eyes usually help


Join Us on March 6th PCI DSS Solutions from Alert Logic

• http://http://alrt.co/1jMsIxF

http://alrt.co/ThreatLogDemo

http://alrt.co/1jMsIxF


Good Sources for More Information

• Intersec Worldwide - http://www.intersecww.com/compliance/pci-dss/

• Alert Logic - https://www.alertlogic.com/solutions/compliance/pci-dss-compliance/

• PCI Security Standards Council: https://www.pcisecuritystandards.org/

• Visa Cardholder Information Security Program: http://usa.visa.com/merchants/risk_management/cisp_overview.html

• Mastercard Site Data Protection Program: http://www.mastercard.com/us/company/en/whatwedo/site_data_protection.html

• American Express Data Security Standard: https://www.americanexpress.com/in/content/merchant/support/data-security/merchant-information.html

• Discover Information Security and Compliance: http://www.discovernetwork.com/merchants/data-security/disc.html

http://www.intersecworldwide.com/compliance/pci-dss/




https://www.alertlogic.com/solutions/compliance/pci-dss-compliance/

https://www.alertlogic.com/solutions/compliance/pci-dss-compliance/

https://www.pcisecuritystandards.org/

https://www.pcisecuritystandards.org/

http://usa.visa.com/merchants/risk_management/cisp_overview.html

http://usa.visa.com/merchants/risk_management/cisp_overview.html

http://www.mastercard.com/us/company/en/whatwedo/site_data_protection.html

http://www.mastercard.com/us/company/en/whatwedo/site_data_protection.html

https://www.americanexpress.com/in/content/merchant/support/data-security/merchant-information.html



http://www.discovernetwork.com/merchants/data-security/disc.html

http://www.discovernetwork.com/merchants/data-security/disc.html


Thank you! Q&A

@Intersecww @[email protected] [email protected]

IntersecWW.com/about/bloghttp://www.alertlogic.com/resources/blog/

mailto:[email protected]

mailto:[email protected]


APPENDIX

31

Evolving Requirements Details


Evolving Requirements DetailsPCI DSS 3.0

RequirementChange Comment

1.1.3 Include Cardholder Data Flows on Network Diagram

Generally Required to Properly Scope CDE

2.4 Maintain Inventory of In-Scope System Components

One of the First Questions An Assessor Should Ask

5.1.2 Requirement to Evaluate Threats to Systems Not Commonly Affected by Malware

Implicit in PCI DSS 2.0

5.3 New 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.10 New 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.



PCI DSS 3.0 Requirement

Change Comment

8.2.3 Combined 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.1 New 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.




Change Comment

8.6 New 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.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

Logical application of PCI DSS v2.0’s Requirements 9.1 and 8.5.4.




9.9 New requirements to protect devices that capture payment card datavia 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.5 Enhanced 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.6 Enhanced requirement to include stopping or pausing of the audit logs.

Could be a significant change or a nonevent depending on what your applications support.




11.1 Enhanced 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.


Evolving Requirements


Change Comment

11.5.1 New 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.2 Expanded 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/governance procedures.

12.8.5 New 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.




Change Comment

12.9 New requirement for service providers to provide the written agreement/ acknowledgmentto their customers as specified at requirement 12.8.

Effective July 1, 2015

Service Provider requirement only. Should facilitate compliance with 12.8.2

Date post:	24-Jan-2015
Category:	Technology
Upload:	alertlogic
View:	1,088 times
Download:	4 times

PCI DSS 3.0: What the New Regulations Mean to You

Technology