Embed Size (px)
Citation preview
Just to lay the groundwork…My Experience With PCI
QSA Acquirer PA-DSS PTS
eCommerce Issuer Service Provider
Card Production
Currently work atLargest eCommerce in Pittsburgh
My experience includes:
A little background informationPCI History
December, 2004 PCI DSS 1.0 released
PCI Council officially forms PCI DSS v1.1 released
September, 2006
October, 2008 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%
like we need more grey areas
and the use of the word “periodic” increase 150%
Driving Changes
Lack of education and awareness
Weak passwords, authentication
Third-party security challenges
Slow self-detection, malware
Inconsistency in assessments
Reporting Structure
Report on Compliance (RoC)Example / v2
Reporting InstructionsExample / v2
Observe system settings, configurationDocument reviews
Interview with personnelObserve process, action, state
Identify sample
StandardExample / v3
Example RoC / v3
Notable Changes
ScopingNew Requirements
“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.”
SamplingNew Requirements (cont.)
“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.
AntiVirusNew Requirements (cont.)
5.1.2For 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.3Ensure 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
New Rules / Effective July 1, 2015Delayed Implementations
6.5.10 Broken authentication and session management
8.5.1Service 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.
9.9 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.9Service 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
CDE
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
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.1Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the
network.
6.6For 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.
2.4 9.9.1
11.1.1
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.
8.6Where 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.
12.2Implement 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.”
Probably.SSL is dead. Or is it?
• 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?
