PCI DSS v3 Justin Leapline justin.leapline@giftcards.com @jmleapline
My Experience With PCI Just to lay the groundwork Currently work at Largest ecommerce in Pittsburgh My experience includes: QSA Acquirer PA-DSS PTS ecommerce Issuer Service Card Provider Production
PCI History A little background information December, 2004 PCI Council officially forms PCI DSS v1.1 released October, 2008 PCI DSS 1.0 released September, 2006 PCI DSS v.1.2 released PCI DSS v2.0 released October, 2010 November, 2013 PCI DSS v3.0 released
number of tests that were added 11% 83% more documentation proof require 48% more interview asks 31% more observation proof increased sampling by 33%
and the use of the word periodic increase 150% like we need more grey areas
Driving Changes Lack of education and awareness Weak passwords, authentication Third-party security challenges Slow self-detection, malware Inconsistency in assessments
Reporting Structure
Example / v2 Report on Compliance (RoC)
Example / v2 Reporting Instructions Observe system settings, configuration Document reviews Interview with personnel Observe process, action, state Identify sample
Example / v3 Standard
Example RoC / v3
Notable Changes
New Requirements Scoping The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.
New Requirements (cont.) Sampling The time of bad sampling is over. -PCI Council Sampling is not a PCI DSS requirement. BUT there are 40 controls that call out sampling. For each instance where sampling is used, the assessor must: Document the rationale behind the sampling technique and sample size, Document and validate the standardized PCI DSS processes and controls used to determine sample size, and Explain how the sample is appropriate and representative of the overall population.
New Requirements (cont.) AntiVirus 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software. 5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period. AV products missed nearly 70% of malware. -Damballa, Feb 2015
Delayed Implementations New Rules / Effective July 1, 2015 6.5.10 Broken authentication and session management 8.5.1 9.9 Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer. Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution. 11.3 Implement a methodology for penetration testing 12.9 Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer s cardholder data environment.
Broken Authentication / Session Mgmt Require secure cookie flag on sessions. Expire sessions after a certain time. May incorporate CSRF and Clickjacking. This could fail a lot of vendor products / old firmware.
Protect POS Devices Periodically inspecting devices to look for tampering or substitution Training personnel to be aware of suspicious behavior and to report tampering or substitution of devices. Use TRSMs when possible Make sure your device is approved on the PCI PTS list
Penetration Testing 1. Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115) 2. Includes coverage for the entire CDE perimeter and critical systems 3. Includes testing from both inside and outside the network 4. Includes testing to validate any segmentation and scope-reduction controls 5. Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5 6. Defines network-layer penetration tests to include components that support network functions as well as operating systems 7. Includes review and consideration of threats and vulnerabilities experienced in the last 12 months 8. Specifies retention of penetration testing results and remediation activities results. FW CDE
Contracts / Service Providers If you are a service provider, you need to have in your contract that you are responsible for PCI DSS, where applicable. Also merchants need to keep track of the specific requirements the service provider is responsible for. 12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
Some Others 2.1 6.6 2.4 9.9.1 11.1.1 8.6 12.2 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks. Special Note: Not the same as vulnerability scans. Maintain an inventory of system components that are in scope for PCI DSS. Maintain an up-to-date list of devices. (POS) Maintain an inventory of authorized wireless access points including a documented business justification. Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows: Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts. Implement a risk-assessment process that: Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.)
SAQ Changes
New SAQ Versions A-EP E-commerce merchants re-directing to a third-party website for payment processing, no electronic cardholder data storage. B-IP Merchants with standalone, IP-connected payment terminals: No e-commerce or electronic cardholder data storage. D-SP SAQ-eligible service providers. SAQ D was split into two.
Difference Between A and A-EP http://www.visaeurope.com/media/images/processing%20e-commerce %20payments%20guide-73-17337.pdf
PCI Community Meeting Minutes
Other Stuff Council clarified that you can submit multiple SAQs for different environments, instead of going to an SAQ D. Open forum question about using others work papers for testing for evidence. Council gave an immediate NO!, followed by a We ll get back to you.
SSL is dead. Or is it? Probably. February newsletter mentioned end of life ing SSL when DSS 3.1 comes out. Afterwards the Council had to make clarifications and sent out a poll to gauge the impact of this ruling. Many are concerned about vendor products, built-in firmware, etc. Also a question of risk if used internally.
to the future.
Future Merchants will struggle with the new standard, as it forces more documentation and accountability on the QSAs. Small to mid-sized business will look to outsource as much as possible. ASV scans will grow, as now stand-alone IP POS terminals locations now require ASV scans. (Square, etc.) With the message of business as usual compliance, assessments may transition into multiple times per year (like SOX) or greater on-going tracking of controls on the merchant.
Questions?
Thank you! Justin Leapline justin.leapline@giftcards.com