PCI Version Three and Thee

799 views

Published on

An overview of PCI DSS 3.0 and how it applies to you and your business.

Published in: Business, Economy & Finance
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
799
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
19
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

PCI Version Three and Thee

  1. 1. 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.!
  2. 2. PCI DSS QSA ROC AOCISA SAQPA-DSS P2PE Acronym soup ASV
  3. 3. 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!
  4. 4. 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!
  5. 5. 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!
  6. 6. Chiseled in STONE! ✽ —  Even  if  encrypted   ✽  SensiBve  AuthenBcaBon  Data   —  Even  if  it’s  sound   1 2 3 4
  7. 7. Call Centers! No ! PCI standard calls for! a clean desk!
  8. 8. 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!
  9. 9. 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;!
  10. 10. 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.!
  11. 11. 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.!
  12. 12. 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.!
  13. 13. 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.!
  14. 14. 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? !
  15. 15. 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!
  16. 16. 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.!
  17. 17. 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.!
  18. 18. 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.!
  19. 19. 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.!
  20. 20. Oh No! Not Another Version!
  21. 21. Version 3.0 ! •  Three year development cycle! •  Available for compliance in 2014! •  Mandatory for compliance beginning 2015!
  22. 22. 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!
  23. 23. 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!
  24. 24. 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.!
  25. 25. 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 !
  26. 26. 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.!
  27. 27. Guidance for each requirement!
  28. 28. V2 ROC Reporting Instructions!
  29. 29. V3 Report on Compliance Template!
  30. 30. 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!
  31. 31. 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 !
  32. 32. This is me! ENIAC!UNIVAC!
  33. 33. 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. !
  34. 34. 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.!
  35. 35. 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 of
 the customer, or to the
 extent that they could
 impact the security
 of the customer’s CDE.!
  36. 36. 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!
  37. 37. 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!
  38. 38. 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.!
  39. 39. 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!
  40. 40. 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. !
  41. 41. 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. !
  42. 42. 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.!
  43. 43. 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. !
  44. 44. 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. !
  45. 45. 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.!
  46. 46. 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!
  47. 47. 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!
  48. 48. Not only do you have…! A good security and risk posture!   You should be compliant with little additional effort.!  
  49. 49. 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. !
  50. 50. 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!
  51. 51. “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      
  52. 52. 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.
  53. 53. ?Hoyt  L.  Kesterson  II   Senior  Security  Architect   hoyt.kesterson@tvrms.com   602  316  1985   Scobsdale,  Arizona  

×