Expert Advice on Payment Card Industry Data Security Standard 3.0

by Kathleen Hughes on May 1, 2015

Article written by Charles Denyer, cdenyer@ndcpa.com. It originated as a handout at The Innovative Users Group Conference, held on April 16, 2015, in Minneapolis, from a program that also featured Derek Brown, Director of IT at the Rochester Hills Public Library, derek.brown@rhpl.org. Used with permission.

Say Hello to PCI DSS Version 3.0

PCI DSS compliance & certification for libraries regarding the newly updated version 3.0 PCI DSS standards can be an incredibly challenging and complex undertaking, one that needs to be clearly defined and understood for ensuring a smooth and seamless transition from version 2.0 to 3.0. With many software vendors, payment processors, and other parties now heavily involved in the world of PCI compliance for libraries, it’s important to understand roles, responsibilities, and overall scope requirements for all parties involved in the entire PCI DSS lifecycle.

Migration from PCI DSS 2.0 to 3.0 | what’s the Difference?

Many consider the changes from 2.0 to 3.0 to be better in some regards, but also changes that require libraries to place a greater focus on the concept of risk, developing additional policies and procedures, along with other important measures. More  specifically, the biggest differences I see from 2.0 to 3.0 are the following:

• Increased clarity and transparency on reporting in regards to the requirements and the actual testing procedures. Thus, a removal of the “vagueness” that one plagued the standards.
• More detailed than before, which is probably the single reason why organizations now consider 3.0 much more  comprehensive, ultimately requiring more effort than 2.0.
• Enhanced Flexibility in reporting, along with a clarification on the all-important topic of “scope”.
• Additional requirements for documentation (i.e., more policies, procedures, and more).
• Ultimately, reporting with a greater emphasis on the concept of risk, but one that still comes with a laundry list of “prescriptive” mandates, such as policies, security awareness training, password rules, along with many other items.
• Changes in the options provided for answering all questions regarding compliance. Simply stated, gone are the simple “yes” or “no, “in place” answers.
• In summary, version 3.0 is larger, more technical, requiring more time and effort.

Information security evolves over time, and with that, the various benchmarks, standards, and frameworks change also, hence the reason from 2.0 to 3.0, but changes for PCI also came about because of concerns noted within the payments industry.  Specifically, the PCI council noted that the following challenges and compliance concerns still persisted, years after the launch of the initial PCI DSS framework:

• Inadequate, missing, and inconsistent security awareness training mandates.
• Weak access control initiatives.
• Weak documentation in regards to information security and operational policies and procedures.
• No initiatives for assessing risk.
• Third-party security concerns.

Understanding all origins of entry, transmission, and storage of cardholder data

You can’t protect what you don’t know, thus knowledge is power in the world of PCI DSS compliance, and it means assessing and understanding the entire cardholder data lifecycle. Libraries provide numerous services (i.e., public use computers for rental, printing, copying, and fine payments, along with general library services), resulting in numerous origins and points of entry where cardholder data can come from, such as the following:

• Online payments
• Kiosks, self-payment and self-checkout stands
• General Services (Over the counter purchases for goods and services)

Therefore, one of the most important tasks any library can undertake is to document the cardholder data flow, from point of entry, how it traverses the network, where is it sent for authorization, payment and settlement, along with any other “pit stops” along the way. And remember to be on the look-out for two additional critical sources of cardholder data: (1). Legacy systems and (2) Hard copy documents.

Integrated Library Systems (ILS) and Essential Software Vendors

Today’s ILS platforms are very robust indeed, allowing for scalability and integration into many of the e-commerce, point of sale, and self-service software solutions offered by various vendors that effectively allow libraries to take credit card payments. Companies such as EnvisionWare or Comprise Technologies are often see as the industry leaders, with many other viable providers also. It’s important to note that organizations offering point of sale and patron interaction software solutions should be compliant with the Payment Application Data Security Standards (PA-DSS), as these software solutions are responsible for “authorization” and “settlement” functions relating to cardholder data. Thus, your first goal is to ensure that you’re using a PA-DSS approved software. Simply visit pcisecuritystandards.org and click on “Approved Companies & Providers”, the “Validated Payment Applications” on the left hand side. You can then simply enter the name of the software vendor to see if their solution has undertaken PA-DSS compliance.

Assessing Roles and Responsibilities for PCI Compliance for Libraries

Everyone has a seat on the bus – as the old saying goes – so let’s assess everyone’s role within the credit card lifecycle for  libraries. The more you clearly understand who’s doing what, the greater one’s chances of achieving compliance with PCI DSS version 3.0 quickly, cost-effectively and comprehensively.

• PCI Experts. If you need help with PCI compliance, then leaning on expert is a really good idea, especially considering the new reporting requirements with version 3.0. That means contacting a PCI-QSA or even a PCIP – professionals carrying th
• I.T. Personnel at Libraries. One of the most important tasks I.T. personnel can accomplish in terms of PCI compliance is helping libraries understand the technical scope considerations – where does cardholder data originate from, what systems does it touch, what information is kept from the patron’s card, and many other important issues.
• Library Personnel. Along with working with I.T., library personnel will need to be heavily involved in the “qualitative” aspects of PCI compliance, which is ensuring all policies have been created, security awareness training is undertaken, the correct SAQ is being completed, and other essential issues.
• Payment Gateways | Payment Processors | Acquirers. Though primarily responsible for facilitating a large part of the credit card transaction lifecycle, particularly authorization and settlement, these organizations also are the front-line enforcers for PCI compliance. They can assesses fines, but they can also be your friend, possibly reducing PCI scope in some circumstances.
• Software Vendors. The software being used for point of sale and patron interaction solutions should be compliant with the Payment Application Data Security Standards (PA-DSS), as these software solutions are responsible for “authorization” and “settlement” functions relating to cardholder data.

Qualitative Ingredients for PCI Success for Libraries

While utilizing PCI DSS and PA DSS compliant software solutions and providers is great – and a step in the right direction – it’s only one small piece of the puzzle, as numerous other initiative still need to be conquered. Call it the “qualitative” side of PCI compliance – critical mandates libraries need to be implementing for ensuring annual PCI DSS certification.

• Policies and Procedures: Quite possibly the biggest and most demanding mandate for PCI compliance is developing  comprehensive information security and operational specific policies, procedures, and other supporting documentation. Sure, PCI is technical, as discussions on firewalls, encryption, audit logs and other technical considerations always seem to be high on everyone’s list, but don’t lose sight of the need for in-depth policies and procedures. Authoring PCI specific documentation is incredibly time-consuming, so the obvious choice is sourcing high- quality PCI templates and compliance toolkits. And if libraries are using SAQ C or SAQ D for reporting, there’s a large amount of policies required within each of these specific Self- Assessment Questionnaires.
• Security Awareness Training: Libraries are often looked upon by the untrained eye as a leisurely, informal, and relaxed atmosphere for patrons visiting such institutions. But dig a little deeper, and they can be potentially hazardous in many ways, from petty theft incidents to more dangerous crimes. It’s why security awareness training – an explicit mandate for PCI DSS certification – should be undertaken annually – at a minimum – for all library employees and other workforce members. Additionally, it’s important to find training specific to libraries, as most general security awareness programs are void of necessary best practices needed for ensuring the safety and security of cardholder data, library assets, personal, and patrons.

Companies spend massive amounts of money on the latest and greatest hardware and software solutions for protecting cardholder data – and that’s fine – but don’t lose sight of the fact that security awareness training is mandated, relatively inexpensive, and highly beneficial. When it comes to ROI in terms of PCI certification, security awareness training – when done properly – is a real winner. Also, it’s important to test one’s knowledge on security awareness training subject matter, so a
short quiz is a really good idea for ensuring employees and other workforce members truly understand and retain critical information.

• Risk Assessments. Assessing one’s risk on an annual basis – while a mandate for PCI DSS compliance with specific SAQ’s – is also a best practice that just makes sense for libraries. Think about it – isn’t is just a good idea for libraries to assess and evaluate critical risks, issues, and other factors that could potentially jeopardize short-term and long-term growth, profits, and viability? More important, assessing risks for libraries doesn’t have to be a laborious and time-consuming process, just obtain an easy-to-use, yet comprehensive tool designed specifically for libraries. You’ll be amazed at the number of helpful tips, recommendations, and action plans that come out of a comprehensive readiness assessment, no question about it. SAQ D, which is often the Self-Assessment Questionnaire used by libraries, mandates an annual risk assessment.
• Penetration Tests: Much has been discussed about penetration testing regarding PCI DSS compliance for libraries, due in large part to their expense (tests can range from $2,500 to $5,000 or more) and time commitments. The key for considering to undertake such a test – while a specific mandate for PCI with specific SAQ’s – is to dig a little deeper and ask yourself “where is the cardholder data actually residing for all the credit card information traversing my network”. If, like most libraries, payments are being accepted via any number of entry points (i.e., kiosks, swipe readers, online via library website), then being directly transmitted to the gateway, with no cardholder data storage, then it’s plausible to start having discussions about penetration test responsibilities being that of the actual payment processor/payment gateway, and NOT the library.
• Quarterly Vulnerability Scans: Both internal and external network scans are also mandated for PCI compliance, thus it’s important to properly define scope, from an IP perspective, and also utilize tools and services that provide scanning on a regular basis, preferably on a monthly basis. Remember that a notable area of PCI compliance is passing quarterly scans, but it’s important to run such scans prior to the quarterly deadline for ensuring any vulnerabilities have been identified, giving Libraries much-needed time to correct any issues. While external scanning is relatively straightforward, internal scanning often proves challenging as vulnerabilities arise from outdated systems and applications. It’s therefore a good idea to patch all internal systems – possibly even purchasing a configuration management tool – for helping pass internally mandated PCI DSS vulnerability scans.
• Reach out to an Expert. Speaking with a Payment Card Industry Qualified Security Assessor (PCI-QSA) or a PCIP is a good idea, particularly when it comes to important scope and technical issues regarding PCI compliance. Remember also that the Self-Assessment Questionnaires (SAQ) can be challenging and confusing at times, so getting good advice and some straight-talk from a PCI-QSA or PCIP is highly recommended, especially with all the changes in the PCI standards.

PCI Best Practices for Libraries

• Picking and completing the correct Self-Assessment Questionnaire: There seems to be some general confusion on which of the Self-Assessment Questionnaires (SAQ) should be completed by libraries. First and foremost, libraries are considered a “merchant” in the eyes of PCI compliance – why – because libraries, according to the official PCI definition of a “merchant”, are entities “…that accept(s) payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services…”

Source: https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3.pdf

Great, so that’s settled, but which of the alphabet soup Self-Assessment Questionnaires are to be completed, you might be asking. Take note of the following eight (8) SAQ’s and their applicability to Libraries for purposes of PCI DSS self-reporting:

• SAQ A: Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Not applicable to face-to-face channels.
  • Analysis: Cannot be used by Libraries, with the biggest reason being it’s limited to “card not present”.
• SAQ A-EP: E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Applicable only to e-commerce channels.
  • Analysis: Cannot be used by Libraries, as this is primarily for e-commerce merchants.
• SAQ B: Merchants using only (1) Imprint machines with no electronic cardholder data storage; and/or (2) standalone, dial-out terminals with no electronic cardholder data storage. Not applicable to e-commerce channels.
  • Analysis: Technically, this can be an option for libraries if they’re using the good ole “knuckle buster”, brick style swipe machines, and if they’re using a dial-out terminal for processing payments. There are probably just a handful of libraries still functioning in this manner.
• SAQ B-IP: Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage. Not applicable to e-commerce channels
  • Analysis: The key word is “only” as an “approved PIN Transaction Security Device” would have to be the ONLY type of method for payment processing, which is clearly not going to be the case with Libraries, as USB enabled swipe readers are commonly used for accepting payment. Thus, SAQ B-IP cannot be used by libraries.
• SAQ C-VT: Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage. Not applicable to e-commerce channels.
  • Analysis: Libraries generally use card reader swipe devices via a USB connection with the actual payment processing software that connects out to the payment gateway, so SAQ C-VT would not seem to be an option for libraries.
• SAQ C: Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.
  • Analysis: SAQ C is definitely in the mix for libraries, so long as cardholder data is NEVER stored in electronic format. As to not “storing” cardholder data, let’s define what that means. According to the Payment Card Industry Data Security Standards, “At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code.” Also, you definitely should not be storing sensitive authentication data (SAD), such as card verification codes and PIN information.
• SAQ P2PE-HW: Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce channels
  • Analysis: This is an interesting new twist in the world of Self-Assessment Questionnaires (SAQ), but one that libraries may find challenging because of the following: There are only a small number of actual point-to-point encryption platforms that are currently validated as P2PE-HW compliant. Also, libraries cannot have any other method for the input of cardholder data other than the POI device listed as part of the P2PE solution. Additionally, you are also required to implement all the controls in the P2PE Instruction Manual (PIM) as provided by your payment solution provider.
• SAQ D: Merchants that do not meet the requirements of any of the aforementioned Self- Assessment Questionnaires (SAQ).
  • Analysis: With some few exceptions, all signs point back to SAQ D, which is an incredibly lengthy and complex questionnaire, so say the least. This is the hand libraries are dealt in the game of PCI DSS compliance, so it’s time for libraries to roll up their sleeves, effectively completing SAQ D in the most efficient, timely and cost-effective manner possible.

• Communicating with the Acquiring Bank, if possible: Remember also to communicate with your acquiring bank, payment processor, and any other entity requiring you to become PCI DSS compliant. Why – because meeting their expectations for compliance is important, and being in the “know” regarding their PCI compliance mandates just makes sense from a best practice. As for an acquirer, which can be many different organizations, it’s best defined as the following: The organization
  that receives authorization requests from merchants, and then forwards the request to the issuing entity (issuing entity is the financial institution that issued the card) for approval. It’s important to note that acquirers are responsible for merchant compliance, that is, they ensure that their merchants are aware of PCI DSS compliance by tracking and mandating compliance on them.
• Tips for reducing cardholder compliance scope and footprint: The very best strategy for reducing  scope for any organization in terms of PCI DSS compliance is not storing cardholder data, along with seeing what cost and time savings can be gained in terms of removing requirements for penetration testing. Remember we spoke earlier that if no real platform exists where cardholder data is being stored, then the possibility of placing the Requirement 11 penetration testing mandates onto the payment processors and gateways is something to consider. Careful consideration and communication with all relevant parties is a logical step to take for such an endeavor.
• Train employees: Here’s a little-kept secret: The very best defense for ensuring the safety and security of cardholder data is having well-trained & highly-aware employees – individuals who are aware of security threats, concerns, issues, and best practices. It means that security awareness training – an explicit mandate for PCI DSS compliance – is also an incredibly value initiative every library should be undertaking on an annual basis. Sure, firewalls, anti-virus and many other industry leading hardware and software solutions are highly essential, but don’t lose sight of the need for the human factor in protecting cardholder data.
• Don’t store cardholder data in hard copy format: In today’s digital word, electronic cardholder data is much more prevalent than a decade ago, as the old “knuckle buster” carbon copy machines are fading away. Even with that said, hard copy documentation still exists containing cardholder data – and if it must – then strict policies and procedures need to be in place for shredding such material regularly. Imagine opening a file cabinet only to see thousands of carbon copied credit card receipts that haven’t been properly disposed of – sounds extreme – it still happens all the time, unfortunately.
• Completing the Self-Assessment Questionnaire: The single, fundamental biggest difference between version 2.0 and version 3.0 for purposes of the Self-Assessment Questionnaires are the responses you can give. In version 2.0, compliance was simply a “yes” or “no” – it’s “in place” or it’s not. The game has changed for version 3.0, as the any of the following five (5) responses can be chosen:
  • Yes: The expected testing has been performed, and all elements of the requirement have been met and stated.
  • Yes, with CCW: The expected testing has been performed, and the requirement has been met with the assistance of a compensating control.
  • No: Some or all of the elements of the requirement have not been met, or are in the process of being implemented, or require further testing before being met.
  • NA: The requirement does not apply to the organization, therefor its NA.
  • Not Tested: Just as it implies, it was not tested because it was not included for consideration in the assessment. Great, so what’s the difference between “NA” and “Not Tested”? “NA” means just that – it is not applicable. Not tested means it simply was not tested without any consideration as to whether it was truly in scope or not. Try and not use “not tested”, relying instead on “NA” and giving good reasons why.

Let’s take a look at a few examples and how libraries can best respond when answering an SAQ:

• Requirement 5 mandates anti-virus be installed on all in-scope system components, thus if a general services checkout center that takes credit card payments is running on a windows server, you’ll need to have anti-virus installed on the system, ultimately marking “yes” as in place. Additionally, in the same scenario, if no anti-virus was installed on such computers, you would have to mark “No”.
• Requirement 6 has numerous testing requirements for software development, yet most libraries have little to nothing to do with developing applications for purposes of PCI compliance. As a result, items falling under Requirement 6.3 would be marked as “NA”.
• You then stumble upon Requirement 10 and the various provisions for audit logs and audit trails – not caring to delve into the technical merits of it – you simply mark “Not Tested”. Marking “Not Tested” is not recommended as it just leave the requirement open to all types of assumptions – most of them not favorable to libraries – so strive for “NA” when possible over “Not Tested” as this implies some degree of consideration was given as to why it’s actually not applicable.

• PCI Policy Packet for Libraries: PCI DSS compliance is highly dependent upon having documented policies and procedures in place, along with ensuring merchants implement annual security awareness training for all employees, and possibly even undertaking risk assessments. To be more specific, documented policies, procedures, and annual security awareness training account for a large part of the mandates for annual PCI compliance. The key is finding a customized policy packet specifically for libraries containing all essential documentation for promoting rapid and comprehensive PCI compliance. Libraries can now download the following customized policy packets from pcipolicyportal.com:
  • PCI Policy Packet & Compliance Toolkit for Libraries – Platinum Edition
  • PCI Policy Packet & Compliance Toolkit for Libraries – Standard Edition

Note: Platinum Edition includes five (5) hours of consulting, whereas the Standard Edition provides all necessary documentation, yet without consulting time.

• Hire a PCI DSS Expert: Version 3.0 of the PCI DSS standards has brought about new complexities regarding compliance for libraries, no question about it. From enhanced documentation requirements to numerous testing answers that can be chosen from, PCI seems to be more challenging than ever, therefore, reaching out to a PCI DSS expert is a good idea.

7 Step PCI DSS Compliance Roadmap for Libraries for Version 3.0 of the PCI DSS Standards

1. Begin by asking yourself the right questions. Understand what you’re getting into from a scope perspective – specifically – ask yourself the following questions, answering them confidently:
   1. “Where are ALL of the origins and entry points for cardholder data into my library, and do we have the cardholder data flow DOCUMENTED with a flow chart or some other type of diagram?” (Remember, think kiosks, general help desk services, self-serving machines, online payments on your website, etc.)
   2. “Are we storing ANY cardholder data in ANY systems – and if so – WHY, and what can we do to remove it  completely?”
   3. “Did we go through PCI compliance last year – and if so – what lessons were learned and what areas do we need to be improving upon for ensuring the safety and security of cardholder data?”
   4. “Did we do any internal and external vulnerability scans and/or penetration tests for PCI reporting last year – and if so – have we been scanning every quarter as required?”
   5. “Who was primarily responsible for completing and officially signing off on the actual PCI Self-Assessment Questionnaire (SAQ) last year?”
   6. “Have we developed all mandated policies and procedures for PCI compliance?”
   7. “Do we have a security awareness training program in place for all employees as mandated by PCI?”
   8. “If we have elected Self-Assessment Questionnaire (SAQ) D, do we have an actual risk assessment program in place for assessing risks as mandated by PCI?”
2. Pick the CORRECT Questionnaire. Easier said than done, as there are a number of questionnaires that technically can be used, but most libraries will fall into the SAQ C or SAQ D buckets, unless they use a very specialized encrypted point-to-point PCI compliant solution (of which there are not many) or they use the old “knuckle busters”, and/or a dial-out terminal. Remember that SAQ C, while still lengthy, is smaller in scope than the granddaddy of them all, which is SAQ D, so cost savings can be had, especially if you can remove the requirements for an annual risk assessment along with a penetration test.Don’t forget that the SAQ has two components, (1). The actual lengthy series of questionnaires, along with the official (2). Attestation of Compliance (AoC), so when downloading the SAQ from pcisecuritystandards.org, choose the document that actually says “SAQ”, (i.e., “SAQ C for Merchants” MS Word document).
3. Communicate with Relevant Third Parties: Remember that the “acquirer” is technically the organization responsible for ensuring merchants – such as libraries – are PCI compliant, so any questions you have regarding reporting should be brought to their attention. Issues such as scope, what questionnaire to use, do all requirements within the SAQ have to be met (remember the penetration testing issue discussed earlier), can hopefully be resolved with a quick call to such organizations. Word to the wise – some acquirers can be very helpful, while some provide little guidance, if any, on PCI compliance, it really just depends who picks up the phone on the other end.
4. Turn the SAQ document inside out and learn it. It means not just checking the box, but understanding each and every component of the actual Self-Assessment Questionnaire. This is probably a good time to hire an actual PCI DSS expert, somebody who can spend 3 to 5 hours helping clarify and distill any issues or concerns you may have. Remember that 2.0 to 3.0 is a game changer, so be ready for the challenges and get help when needed.
5. Compliance is about documentation, so get it now. Did you know that probably half of the mandates of meeting PCI DSS compliance via the Self-Assessment Questionnaires (SAQ) comes down to documentation – policies, procedures, training material, etc.? That’s right, which means obtaining professionally developed documentation is highly essential regarding Payment Card Industry Data Security Standards (PCI DSS) compliance. Why spend hundreds of hours authoring policies and procedures when there’s documentation available specifically for libraries from pcipolicyportal.com?
6. Train employees on security awareness and conduct an annual risk assessment. SAQ C requires security awareness training as a mandate for PCI compliance for libraries, while SAQ D requires both security awareness training and an annual risk assessment to be performed. Both are much more than policy edicts – they’re mandates calling for specific initiatives to be implemented. Much like policies and procedures, pcipolicyportal.com also provides training material and risk assessment documents specific to libraries, so visit pcipolicyportal.com to learn more.
7. Continue to aim for the moving target. PCI compliance, though technically required only one a year, requires constant attention – policies have to be updated, scanning has to be conducted quarterly, changes in scope have to be assessed for PCI compliance, and more. It’s never a “one and done” scenario, so it means now’s the time for making PCI compliance a part of one’s culture, and for the long-term.

About Charles Denyer

Charles Denyer is one of North America’s longest licensed Payment Card Industry Qualified Security Assessors (PCI-QSA), working with merchants and service providers all throughout the globe in achieving PCI DSS compliance efficiently, cost-effectively, and in a comprehensive manner. He is the recipient of numerous accounting and technology certifications along with a Masters in Information and Telecommunication Systems from the Johns Hopkins University and a Masters in Nuclear Engineering from the University of Tennessee at Knoxville. Expertise includes information security, cyber security, national security and homeland defense, and conducts independent research projects on specific subject matter for various entities. Charles can be contacted at cdenyer@ndbcpa.com or at 800-277-5415-ext.705.

---

Tags: payment card industry data security standard, PCI DSS 3.0 Compliance