1 / 22

Payment Card PCI DSS Compliance SAQ Workshop II IT Staff Brian Fackler , Security Coordinator 5/24/2011

Payment Card PCI DSS Compliance SAQ Workshop II IT Staff Brian Fackler , Security Coordinator 5/24/2011. PCI: Technology and Paperwork. Why the second workshop? Shouldn’t the Merchant Managers know everything about PCI now? PCI is Tech heavy. PCI is Policy heavy.

acacia
Download Presentation

Payment Card PCI DSS Compliance SAQ Workshop II IT Staff Brian Fackler , Security Coordinator 5/24/2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Payment Card PCI DSS Compliance SAQ Workshop IIIT Staff Brian Fackler, Security Coordinator5/24/2011

  2. PCI: Technology and Paperwork Why the second workshop? Shouldn’t the Merchant Managers know everything about PCI now? PCI is Tech heavy. PCI is Policy heavy. Management and IT need to work together

  3. What is an SAQ? • Self Assessment Questionnaire • Validation tool to help merchants self evaluate their compliance with PCI DSS. • Required annually by our merchant bank, Wells-Fargo Merchant Services. • An SAQ consists of two parts. • Questions correlating to the PCI DSS • Attestation of compliance.

  4. SAQ D – Exclusions • If you are required to answer SAQ D to validate your PCI DSS compliance, the following exceptions MAY be considered. • The questions specific to wireless only need to be answered if wireless is present anywhere in your network (for example, Requirements 1.2.3, 2.1.1, and 4.1.1). Note that Requirement 11.1 (use of wireless analyzer) must still be answered even if wireless is not in your network, since the analyzer detects any rogue or unauthorized devices that may have been added without the merchant’s knowledge. • The questions specific to custom applications and code (Requirements 6.3-6.5) only need to be answered if your organization writes its own custom web applications. • The questions for Requirements 9.1-9.4 only need to be answered for facilities with ‘sensitive areas’. ‘Sensitive areas’ refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes the areas where only point-of-sale terminals are present, such as the cashier areas in a retail store.

  5. Source Documents Payment Card Industry Data Security Standard (PCI-DSS)- Requirements and Security Assessment Procedures, Version2.0 https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf Commonly referred to as the “PCI DSS” Navigating PCI DSS: Understanding the Intent of the Requirements, Version 2.0 https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf Commonly referred to as “Navigating PCI” or the “Intent” document.

  6. Source Documents PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v2.0 https://www.pcisecuritystandards.org/documents/pci_dss_saq_instr_guide_v2.0.pdf Commonly referred to as the “SAQ Guidelines” PCI DSS SAQ D, v2.0, Self-Assessment Questionnaire and Attestation of Compliance https://www.pcisecuritystandards.org/documents/pci_saq_d_v2.pdf Commonly referred to as “SAQ D” and “Attestation” respectively.

  7. Source Documents Payment Card Industry (PCI) Payment Application Data Security Standard, v2.0 https://www.pcisecuritystandards.org/documents/pa-dss_v2.pdf Commonly referred to as the “PA DSS” PA-DSS Implementation Guide Provided by your payment application vendor Commonly referred to as the “Implementation Guide”. PA-DSS requires vendor to create and update annually.

  8. How to answer an SAQ question. • Read the SAQ question. • Understand the intent of it in: Navigating PCI DSS • Review the Testing Procedures columnin the PCI-DSS • Check the PA-DSS Implementation Guide • Review (create) your departmental policies and procedures, documentation, etc. • Answer the SAQ question (Yes, No, Not Applicable)

  9. Example 2.2.2 1: SAQ Question

  10. Example 2.2.2 2: Understand the Intent As stated in Requirement 1.1.5, there are many protocols that a business may need (or have enabled by default) that are commonly used by malicious individuals to compromise a network. To ensure that only the necessary services and protocols are enabled and that all insecure services and protocols are adequately secured before new servers are deployed, this requirement should be part of your organization's configuration standards and related processes. Text from PCI-DSS The intent

  11. Example 2.2.2 3: Testing Procedures Test procedure 2.2.2.b shows us how this will be accomplished. Some sort of documentation is required to show: What services, daemons, protocols, etc. are “necessary” (2.2.2a). What insecure services are enabled, and how have the been secured (2.2.2.b).

  12. Example 2.2.2 3: Testing Procedures “2.2.2.a For a sample of system components, inspect enabled system services, daemons, and protocols.” Why is “ActiveX Installer (AxInstSV)” not disabled? Where is the documentation showing that either your payment application or sytems need this? Why is “Adaptive Brightness” not disabled? Where is the document...

  13. Example 2.2.2 3: Testing Procedures Why is port 49701 listening on this machine? What documentation shows that this system needs network printing?

  14. Example 2.2.2 4: Implementation Guide

  15. Example 2.2.2 5: Documentation So what documentation do you have to have to answer “Yes”? “this requirement should be part of your organization's configuration standards”(1) listing “necessary and secure services, protocols, daemons, etc., as required for the function of the system”(2). (1) Intent (2) PCI-DSS

  16. Example 2.2.2 5: Documentation So what documentation do you have to have to answer “Yes”? A “config standard” or similar is required that lists out -Software loaded and how configured -Protocols enabled -Ports opened -Services running/enabled/disabled Applies to ALL devices in PCI scope! Ref: PCI-DSS page 10 Base PCI Configvs ‘variants’

  17. Example 2.2.2 5: Documentation How do you create a Config Standard and determine your systems are set up correctly? ALL* software comes with manuals and/or setup guides. Those documents are your config builders as well as supporting documentation. Copy to NetFiles? Applies to your payment application as well as the OS and any other third party software such as Firefox, Adobe, Oracle, etc. *MGA: Massive Generalization Alert!

  18. So, What’s Your Answer? • YES – a ‘Yes’ response indicates that you are fully complaint with the PCI DSS in that area • NO – indicates that you are not PCI DSS compliant in that area. For each ‘No’ entry there must be a corresponding entry in ‘Part 4: Action Plan for Non-Compliant Status’ detailing the issue, how and when it will be resolved. • NA – indicates that a requirement is not applicable to your environment. You must complete Appendix D, ‘Explanation of NA’ for each ‘NA’ entry.

  19. So, What’s Your Answer? • NA – indicates that a requirement is not applicable to your environment. You must complete Appendix D, ‘Explanation of NA’ for each ‘NA’ entry.

  20. So, What’s Your Answer? • NO – indicates that you are not PCI DSS compliant in that area. For each ‘No’ entry there must be a corresponding entry in ‘Part 4: Action Plan for Non-Compliant Status’ detailing the issue, how and when it will be resolved.

  21. Source Documents OIT’s Credit Card Processing web page http://www.oit.umn.edu/security/topics/credit-card/ AccountsReceivable Services’ Payment Cards/PCIDSS Standards web page http://www.finsys.umn.edu/ar/biz_ar_pcidss.html UWIDE Administrative Policy Accepting Revenue Via Payment Cards http://policy.umn.edu/Policies/Finance/Cash/PAYMENTCARDS.html Basic Security for Computers and Other Electronic Devices http://www.policy.umn.edu/Policies/it/Use/SECUREDATA_PROC01.html Enhanced Security for Computers and Other Electronic Devices http://www.policy.umn.edu/Policies/it/Use/SECUREDATA_PROC02.html

  22. Information • For more information: • Greg Miller, PCI DSS Compliance Managergam@umn.edu – 612-625-8760 • OIT Security abuse@umn.edu • PCI – Security Standards Council: • https://www.pcisecuritystandards.org/

More Related