PCI Version Three and Thee
May 25, 2015
An overview of PCI DSS 3.0 and how it applies to you and your business.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Why PCI!• In August 2012 an employee of the South
Carolina Department of Revenue opened an email enabling a malware attack.!– Employee’s credentials were lifted.!– Miscreants used credentials in remote login!
• 75GB of backups exfiltrated in September!• Income tax returns of every SC citizen
exposing SSNs, bank account numbers, etc.!• CC numbers exfiltrated but not exposed.!
PCI DSS
QSA ROC AOC ISA
SAQ PA-DSS
P2PE
Acronym soup
ASV
The Acronyms!• Payment Card Industry—the brands!• Data Security Standard has requirements!– Self Assessment Questionnaires have fewer!
• Approved Scanning Vendor—external scans!• Qualified Security Assessor—test and report!– Internal Security Assessor—home grown!
• Report On Compliance—requirements met?!– Attestation Of Compliance—cross my heart!
• Payment Application-DSS—e.g. point of sale!
ATM Security Guidelines Mobile Payment Acceptance Security Guidelines for Developers v1.0 Mobile Payment Acceptance Security Guidelines for Merchants v1.0 PCI DSS 2.0 Cloud CompuBng Guidelines PCI DSS 2.0 eCommerce Guidelines PCI DSS 2.0 Risk Assessment Guidelines PCI DSS Applicability in an EMV Environment Guidance v1.0 PCI DSS TokenizaBon Guidelines PCI DSS v2.0 Wireless Guidelines PCI DSS VirtualizaBon Guidelines v2.0 ProtecBng Telephone-‐based Payment Card Data Requirement 11.3 PenetraBon TesBng v1.2 Requirement 6.6 ApplicaBon Reviews and Web ApplicaBon Firewalls Clarified v1.2 Skimming PrevenBon—Best PracBces for Merchants Understanding the SAQs for PCI DSS v3.0
Information Suppliments!
What’s on the card Cardholder data (CHD) and SAD!
• Primary account number—PAN!• Sensitive authentication data—SAD!– Encoded into the magnetic track!
• Card Verification Code 1—CVV1!– Encoded into “chip and PIN” cards—PIN!– Printed on the front or back on the card!
• CVV2!
• Expiration date!• Cardholder name!
Chiseled in STONE!
✽
— Even if encrypted ✽ SensiBve AuthenBcaBon Data
— Even if it’s sound
1 2 3 4
Call Centers!No !
PCI standard calls for!
a clean desk!
Call Centers!• No PCI standard calls for a clean desk.!– Control physical media, e.g. paper, flash drive.!– Restrict access to handheld devices.!
• Recordings of calls may hold CHD—encrypt.!• But what about sensitive authentication data?!– Avoid it by not collecting CVV2 et al, or pause
recording, or connect caller to Interactive Voice Response (IVR) system; or,!
– Deploy a compensating control.!• Protecting Telephone-based Payment Card Data!
What is a compensating control? 1 of 2!
• Described when the deployed controls are not those specified in the requirement.!
• For each compensating control one must:!– state the technical or business reason
compliance to the requirement as written is not possible;!
– describe what the original control was supposed to do and what the compensating control does;!
– Identify risk cause by lack of original control;!
What is a compensating control? 2 of 2!
– Describe the control and how it addresses the requirement and any increased risk;!
– The QSA must describe how the control was tested to validate; and,!
– Describe how will the control be maintained.!• A compensating control cannot be one that
is already mandated for the asset.!– e.g. integrity checking on the server which
doesn’t have anti-malware software installed.!
Electronic Commerce!• No physical presence so you don’t worry
about point-of-sale systems, skimmers, or track data.!
• Instead, you’re on the friendly Internet using hardy web browsers and servers.!
Store, process, and transmit!• Your web server talks to your customer to
take order and collect CHD for payment.!• To make purchases “easier” for your
customer, you save the CHD, but not SAD, for subsequent purchases.!
• You communicate with your processor to authenticate account and then make the charge.!
• You have a lot of explaining to do.!
Your applications!• May be bespoke—customized to your
business by you or third party.!– This application must be evaluated by the QSA.!
• May be purchased commodity software.!– Purchase PCI-certified Payment Applications
and follow Implementation Guide.!– If not, QSA must evaluate.!
• May be a mélange, e.g. your web services fronting purchased shopping cart software.!
Over there for payment please!What if I get someone else to accept the CHD and process the charge?!I never see CHD.!Do I still have to be PCI compliant? !
That depends!• The PCI DSS 2.0 eCommerce Guidelines
describes several scenarios.!– Shared Management!• Direct Post!• iFrame!• Redirect!
– Wholly outsourced!• A new SAQ, A-EP, is available for version 3!
Embedded APIs with Direct Post!• Use processor-provided
APIs to plug code into customer’s browser window.!
• When data is entered into payment fields, it is sent directly to the processor, not to the merchant.!
• Merchant must ensure that that its website is not compromised.!
Inline iFrames!• Processor’s web page is
embedded within the web page of the merchant.!
• Data entered into iFrame is sent directly to the processor and not seen by the merchant.!
• Compromise of merchant website may result in a compromise of iFrame.!
Hosted-payment page!
• Merchant’s page contains link to payment processor website.!
• Customer is redirected to that site to enter payment information.!
• If the merchant webpage is compromised, the customer could be redirected to a bad-guy site to enter CHD.!
Wholly outsourced!• Customer connects directly to third-party
site for all functions, including payment.!– Merchant can login to manage store content.!
• This is also a good solution for those businesses who collect payment information over the phone.!– The CSR connects directly to the customer or
to the card processor to enter CHD and amount to be charged.!
Oh No!
Not
Another
Version!
Version 3.0 !• Three year development cycle!• Available for compliance in 2014!• Mandatory for compliance beginning 2015!
What did they want to fix!• Divergent interpretations of the standard!• Weak or default passwords!• Slow detection of compromise!• Security problems introduced by 3rd
parties!• and various other areas!
Highlights!• The twelve steps…errr…requirements remain!• Some sub-requirements added!• Policy and procedure requirements proximate
to items each policy and procedure addresses!• Descriptions of tests are more precise!– Aligned language of requirement and test !– Clarified what to do to verify compliance!
• More rigor in determining scope of assessment!
• More guidance on log reviews!• More rigorous penetration testing!
No hiding documentation sins!• Version 2 aggregates all policy and
procedure requirements in one location.!– 12.1.1 Verify that the [security] policy
addresses all PCI DSS requirements. !– 12.2 Verify that [daily operational security
procedures] are consistent with this specification, and include administrative and technical procedures for each of the requirements.!
• Difficult to detect requirements not covered.!
Moved to relevant locations!– 1.5
managing firewalls are
. !– 2.5 managing vendor defaults and other
security parameters are !– 3.7 protecting stored cardholder data are – 8.8 identification and authentication are !– 10.8 monitoring all access to network
resources and cardholder data are !
Eschew Ambiguity!
• Too much variance in interpretation among QSAs!– Clients get different interpretations.!– PCI Counsel’s Quality Control sees too much
variance in the Reports on Compliance (ROC).!• Version 3 removes ambiguities in the
specification that result in inconsistent interpretations of a requirement.!
Guidance for each requirement!
V2 ROC Reporting Instructions!
V3 Report on Compliance Template!
Version 3 SAQs!• Format and content changes!– Expected Testing, a new column !– the Special column has been replaced with
Yes with CCW (compensating control worksheet) and N/A!
– sections reorganized to ensure that an entity’s attestation encompasses all elements of the SAQ and AOC!
• eligibility for, and requirements within, each SAQ have been revised!
There’s some new SAQs in town!• A-EP!
e-commerce merchants who outsource all payment processing to 3rd parties, using a website that doesn’t directly receive cardholder data but that can impact the security of the payment transaction!
• A-IP!merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage !
This is me!
ENIAC!UNIVAC!
New authentication requirement!• If you use identical credentials to
authenticate yourself to all your customers…!• …a compromise of one of those customers
exposes all the other customers.!• New Requirement 8.5.1!Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential for each customer. !
Division of labor with 3rd party!• New requirement, 12.8.5, mandates that
the assessed entity is aware of which DSS requirements are managed by the service provider and which are managed by the entity.!
• How this division is documented and agreed between the assessed entity and the service provider is not specified.!
Service Provider Responsibility1 of 2!New requirement, 12.9, mandates that 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 ofthe customer, or to the extent that they could impact the securityof the customer’s CDE.!
Service Provider Responsibility2 of 2!• The exact wording of that acknowledgement
will depend on:!– the agreement between the two parties;!– the details of the service being provided; and,!– the responsibilities assigned to each party.!
• The acknowledgement does not have to include the exact wording provided in this requirement.!
• Get your lawyers involved!
Service Provider Responsibility2 of 2!• The exact wording of that acknowledgement
will depend on:!– the agreement between the two parties;!– the details of the service being provided; and,!– the responsibilities assigned to each party.!
• The acknowledgement does not have to include the exact wording provided in this requirement.!
• Get your lawyers involved!
They’re getting serious about the CDE!Clause 3.1.1 of the ROC requires documentation of how the assessor validated the accuracy of the PCI DSS scope by describing:!
– The methods or processes (for example, tools, observations, feedback, scans, data flow analysis) used to identify and document all existences of cardholder data.!
– The methods or processes (for example, tools, observations, feedback, scans, data flow analysis) used to verify that no cardholder data exists outside of the CDE scope defined for this assessment.!
– How the results of the methods/processes were evaluated to verify that PCI DSS scope is appropriate.!
– How the results of the methods/processes were documented (e.g. the results may be a diagram or an inventory of cardholder data locations).!
– Why the methods used for scope verification are considered by the assessor to be effective and accurate.!
– Provide the name of the assessor who attests that the scope of the assessment has been verified to be accurate and appropriate.!
A Penetration Test Methodology!• Based on industry-accepted approaches,
e.g. NIST SP800-115!• A new clause 11.3!– Test entire perimeter of CDE & all critical systems!– Validate all scope-reduction controls—segmentation!– Test from inside and from outside of the network!– Test network-function components and OSs!– As a minimum, perform application tests for the
vulnerabilities listed in Requirement 6.5!
Those vulnerabilities are!• Injection flaws, particularly SQL injection. !• Buffer overflow !• Insecure cryptographic storage !• Insecure communications !• Improper error handling !• Cross-site scripting (XSS) !• Improper Access Control, !• Cross-site request forgery (CSRF)!• Broken authentication and session
management. !
If you develop!• Requirement 6.5 mandates that programmers of
internally-developed and bespoke applications must be trained in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory. !
• The QSA must identify the records of training that were examined to verify that software developers received training on secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory. !
Authentication!• Requirement 8.2–6 text recognizes methods
other than password, e.g. passphrases or certificates!– Authentication credentials!
• Minimum password length is still 7 characters!– “Alternatively, the passwords/phrases must have
complexity and strength at least equivalent to the parameters specified above.”!
• A service provider must use a different password for each of its clients.!
Quicker detection of compromise!
• Deploy a integrity change-detection mechanism to alert personnel to unauthorized modification of critical system files, configuration files, or content files !– configure the software to perform critical file
comparisons at least weekly. !
Quicker detection of compromise!
• Deploy a integrity change-detection mechanism to alert personnel to unauthorized modification of critical system files, configuration files, or content files !– configure the software to perform critical file
coparison at least weekly. !• New requirement, 11.5.1, mandates the
implementation of a process to respond to any alerts generated by that mechanism. !
How much work is this?!• Greater effort to move from 2.0 to 3.0 than
from 1.2 to 2.0!• PCI compliance should be continuous!– No frantic preparation before the arrival of the
auditors and a round of drinks after they leave.!
• More stringent testing procedures may find that previously compliant elements are now non-compliant.!
Some new requirements need not be in place until 30 June 2015!
– 6.5.11 Broken Authentication and Session Management !
– 8.5.1 Use of unique authentication credentials for each client of a service provider.!
– 9.9 Protect POS from physical tampering!– 11.3 Penetration test methodology!– 12.9 Written acknowledgement of 3rd party
responsibilities and compliance!
Some breathing room!
If your organization…!• practices good information governance such
that it is aware of what types of data it has and where it stores, processes, and sends that data;!
• properly protects access to its information and its processes; and,!
• defines appropriate policies implemented by self-documenting processes that not only comply with PCI requirements but also create easily discoverable evidence that compliance was continuous throughout the year; then!
Not only do you have…!
A good security and risk posture!
You should be compliant with little additional effort.!
One more thing!• Organizations often spend much effort to reduce the
portion of the enterprise that will be subject to PCI DSS audit.!
• The effort to protect CHD and SAD within the CDE should also be applied to PII throughout the entire enterprise.!
• Had South Carolina done so, it’s likely no PII would have been exposed. !
• A tugboat may lead us to the answer. !
The T. J. Hooper!• Towed barges and cargo lost in storm!• Cargo owners sue claiming negligence!– Radio was a readily available technology!– Couldn’t receive broadcasts warning of storm!
• No other tugboat operators had radios—!the standard of care for the industry!
• In a landmark decision Judge Learned Hand found the tugboat owners liable!
“Indeed in most cases reasonable prudence is in fact common prudence, but strictly it is never its measure. A whole calling may have unduly lagged in the adopBon of new and available devices…Courts must in the end say what is required. There are precauBons so imperaBve that even their universal disregard will not excuse their omission.” —Judge Learned Hand, 1932
Custom is not based merely on old standards. It also must be based
on adapting to new technology. The duty of care is a relative concept
that changes.
?Hoyt L. Kesterson II Senior Security Architect [email protected] 602 316 1985 Scobsdale, Arizona
Related Documents
