PCI DSS: A Practical Guide to Implementing and Maintaining Compliance

PCI DSS: A Practical Guide to Implementing and Maintaining Compliance

STEVE WRIGHT
Copyright Date: 2011
Edition: 3
Published by: IT Governance Publishing
Pages: 253
https://www.jstor.org/stable/j.ctt5hh5z9
  • Cite this Item
  • Book Info
    PCI DSS: A Practical Guide to Implementing and Maintaining Compliance
    Book Description:

    The objective of this revised practical guide is to give entities advice and tips on the entire PCI implementation process. It provides a roadmap, helping entities to navigate the broad, and sometimes confusing, PCI DSS v2, and shows them how to build and maintain a sustainable PCI compliance programme. This latest revision also includes increased guidance on how to ensure your compliance programme is ‘sustainable’ and has been based on real-life scenarios, which should help to ensure your PCI compliance programme remains compliant. Although the guide starts with sections on why and what is PCI, it is not intended to replace the ‘publicly available’ PCI information. This book looks to serve those who have been given the responsibility of PCI, and does not attempt to provide all the answers. It should be read, absorbed and digested only with a good helping of other PCI ‘publicly available’ information. In other words, it will help an organisation or individual, get started, and hopefully furnish the reader with enough of the fundamental basics to create, design and build the organisation’s own PCI compliance framework.

    eISBN: 978-1-84928-187-4
    Subjects: Technology

Table of Contents

  1. Front Matter
    (pp. 1-4)
  2. FOREWORD
    (pp. 5-6)

    The objective of this (revised 2011) practical guide is to give entities practical advice and tips on the entire Payment Card Industry (PCI) implementation process. It provides a roadmap, helping entities to navigate the broad and sometimes confusing Payment Card Industry Data Security Standard (PCI DSS) v2 and shows them how to build and maintain a sustainable PCI compliance programme.

    This latest revision also includes increased guidance on how to ensure your compliance programme is ‘sustainable’ (seeChapter 9). This has been based on real-life scenarios and should help to ensure your PCI compliance programme remains compliant.

    Although the guide...

  3. PREFACE
    (pp. 7-12)
  4. ABOUT THE AUTHOR
    (pp. 13-13)
  5. ACKNOWLEDGEMENTS
    (pp. 14-14)
  6. Table of Contents
    (pp. 15-17)
  7. BACKGROUND
    (pp. 18-63)

    In 2001, VISA and MasterCard each instigated basic levels of credit card security compliance programs, in which both retailers (known as merchants), banks and entities that provided cardholder authentication and authorisation services (known as service providers) were required to demonstrate compliance.

    Visa had created CISP (Cardholder Information Security Programme) and MasterCard had created SDP (Site Data Protection). And each security standard placed a heavy burden on both merchants and service providers; as they had to comply with several different programs. Fortunately, by 2004 VISA and MasterCard had set up a joint data security standard known as the Payment Card Industry...

  8. CHAPTER 1: STEP 1 – ESTABLISHING THE PCI PROJECT
    (pp. 64-68)

    One of the most important and often neglected tasks you should first consider is the project documentation. Any aspect of work that requires resource, time and effort, demands to be treated as a project in itself. Failure to follow this simple advice may lead to serious complications and worse – repercussions for your PCI compliance programme. PCI requires a serious amount of commitment and cannot be treated as business as usual.

    To start, you should ensure an appropriately qualified project manager is assigned the task of overseeing the PCI programme. As any project manager will tell you, all the requirements...

  9. CHAPTER 2: STEP 2 – DETERMINE THE SCOPE
    (pp. 69-74)

    Once the initial project scoping workshop is complete, it is equally important to provide a clear understanding of the objectives and the scope for the PCI target environment.

    Therefore, it is recommended that you hold another workshop. This workshop should be used to better understand the boundaries, exemptions, third parties relationships, and dependencies but it should be recognised that the scope will probably change from the start of the PCI project upon completion of the project.

    It is important to note that an accurate scope is not only essential for your entity to gain maximum benefit from the PCI assessment...

  10. CHAPTER 3: STEP 3 – REVIEW THE INFORMATION SECURITY POLICY
    (pp. 75-76)

    As previous stated, there are six high-level and twelve sub-level objectives, and ironically, the final objective is the starting point of our compliance programme. Before engaging in the gap analysis and risk analysis process, it is important to understand what is contained and implied within the existing information security (IS) policy and what is required from the supporting policies and procedures i.e. anti-virus policy, user acceptance policy, HR vetting process and change management procedure.

    This short but highly significant policy and its family set should be comprehensive and succinct as it will help you build the foundation for a comprehensive...

  11. CHAPTER 4: STEP 4 – CONDUCT GAP ANALYSIS
    (pp. 77-81)

    This activity is the information gathering and analysis part of the PCI project and relies on interviewing staff and assimilating information from existing policies, processes and supporting procedures and includes a technical review of systems, including:

    Network components, such as firewalls, switches, routers, wireless access points, network appliances and other security appliances.

    Servers, including: web, database, authentication, domain name service (DNS), mail, proxy, network time protocol (NTP).

    Applications such as all purchased and custom/bespoke applications, internal and external (Web) applications.

    Business process analysis and reviews must be conducted with security management and support resources, business personnel, and other key stakeholders...

  12. CHAPTER 5: STEP 5 – CONDUCT RISK ANALYSIS
    (pp. 82-100)

    Before proceeding into the risk analysis step, it is worth clarifying what is meant by risk analysis and risk management. Risk management34is concerned with identifying, quantifying and managing the risks that can exist in any given environment. The risks related to key processes, people and key IT services should be identified and recorded in a risk register. These risks then need to be quantified and a decision made as to whether any actions need to be taken.

    For this reason, the process of identifying, addressing and managing PCI related risks should be an integral part of every part of...

  13. CHAPTER 6: STEP 6 – ESTABLISH THE BASELINE
    (pp. 101-112)

    The following chapter details what needs to be done in order to comply with the Standard as a minimum; it is not intended to be complete and should be used in the context of the previous steps – gap analysis and risk management. It is important to note that whilst this book provides some guidance on the interpretations of the PCI Data Security Standard, it should in no way be used in isolation. Therefore, it should be used in conjunction with the Standard and its supporting documentation.

    One of the most critical elements of the PCI Standard is the concept...

  14. CHAPTER 7: STEP 7 – AUDITING
    (pp. 113-126)

    The overall objective of auditing is to check over a specified regular audit period (which should last no more than one year) that all aspects of the PCI compliance programme are functioning as intended and that the minimum requirements, as specified in PCI DSS are being met.

    Like many regulations, PCI can be intimidating because it is a broad-reaching set of requirements potentially including all of your information systems in scope. Unlike other regulations, PCI is highly prescriptive and there is a huge amount of supporting useful and free material available to help you determine if you need to comply;...

  15. CHAPTER 8: STEP 8 – REMEDIATION PLANNING
    (pp. 127-128)

    The remediation plan will integrate all findings from each of the assessments (gap, risk, establishing the baseline and audits) to build a combined remediation plan (also known as SIP). Once again, it is well worth assigning experienced and qualified project managers to build a remediation plan; ensuring key stakeholders and sponsors form part of a project review board.

    The project manager should develop and deliver the project documentation that will demonstrate the rigour of all the processes described in the previous sections and should outline a clear roadmap on how to deliver the PCI compliance plan within the agreed scope...

  16. CHAPTER 9: STEP 9 – MAINTAINING AND DEMONSTRATING COMPLIANCE
    (pp. 129-203)

    Maintaining regulatory compliance requires your entity to be able to demonstrate that the systems are secure, and that adequate processes and procedures are in place to quickly address any gaps in your security posture. For publicly traded entities, this can include detailed reports for financial systems as required by Sarbanes-Oxley (SOX) and corporate governance requirements detailed in the Combined Code 2006.

    All entities need to contend with the growing in number and complexity of legal and regulatory compliance - irrespective of size. FISMA (US), SoX, the Data Protection Act40, the European Directive, California SB 1386 (US); and of course the...

  17. CHAPTER 10: PCI DSS AND ISO27001
    (pp. 204-212)

    The Payment Card Industry Data Security Standard (PCI DSS) isn’t dramatically different to the requirements of the Best Practice Security Standard – ISO27001, except that PCI doesn’t mention any of the prerequisites required for a management framework, e.g. management commitment and ongoing improvement plans, whereas ISO27001 leaves alone a lot of the detail around how controls are actually implemented. So, therefore, one could be forgiven for believing that MasterCard and Visa assumed PCI would be additional security requirements to sit on top of an already established information security management system (ISMS).

    There is no getting away from the fact that...

  18. APPENDIX 1 – PROJECT CHECKLIST
    (pp. 213-217)
  19. APPENDIX 2 – PCI DSS PROJECT PLAN
    (pp. 218-223)
  20. APPENDIX 3 – BIBLIOGRAPHY AND SOURCES
    (pp. 224-225)
  21. APPENDIX 4 – FURTHER USEFUL INFORMATION
    (pp. 226-234)
  22. APPENDIX 5 – PCI DSS MAPPING TO ISO27001
    (pp. 235-250)
  23. ITG RESOURCES
    (pp. 251-253)