In the payments industry there exists the PCI guidelines.  When we refer to PCI we are usually talking about the PCI DSS, although as anyone will tell you there is also the PCI PED, PCI PA-DSS, and others you should be aware of.  But what are the roles and responsibilities within this arena of acronyms?

For many of us we hear things such as PCI DSS, QSA, ASV, SAQ, SAP, and our eyes roll back in our heads.  In fact I was talking with someone to come up with the longest PCI acronym and we came up with head-spinning examples such as “PCI DSS SAQ FAQ”, which is based on the SAP, audited by a QSA.  Baaaaaaaaah!

To clarify some of this we should segment the conversation into compliance documents and validation documents.  The PCI DSS is a set of 12 requirements (the “digital dozen”) that companies must comply with.  If you are a Level 1 merchant (i.e. large company) you are required to validate using the Security Audit Procedures (SAP).  If you are a Level 2-3 merchant (i.e. medium sized company) you are required to validate using the Self-Assessment Questionnaire (SAQ).  Level 4 merchant (i.e. small companies) are not all required to validate, but must comply at all times.

The PCI Security Standards Council (SSC), or the “Council”, is an independent standards body made up of the five participating card brands - American Express, Discover, JCB, MasterCard Worldwide, and Visa Inc.  They oversee the standard itself along with the validation document.  They also qualify a closed list of assessors to perform the PCI audits and the Internet vulnerability scans.  These are called QSAs and ASVs respectively.  More on these later.

The following is a list of documents managed by the PCI SSC:

• PCI Data Security Standard (compliance)
• PCI DSS Security Audit Procedures (validation)
• PCI DSS Self-Assessment Questionnaire (validation)
• PCI DSS Security Scanning Procedures (for ASVs)
• PCI PED Standards (compliance and validation)
• PCI Payment Application Data Security Standard (PA-DSS)
• as well as endless FAQs, information supplemental, and much more

Other acronyms, include those involved in assisting with the PCI DSS audit.  The Qualified Security Assessor (QSA) includes a list of companies, qualified by the PCI SSC, who assist merchants in validating their compliance against the PCI DSS.  Why would you need one of these companies?  Well, technically, Level 1 merchants can perform the audit with their internal audit department so long as the report is signed off by an officer of the corporation.  The reason companies hire QSAs is for the same reason they hire an external Penetration Tester - expertise and experience.

The Approved Scan Vendors (ASV) include a list of companies, qualified by the PCI SSC, who assist merchants in validating their compliance via the use of Internet vulnerability scans.  Merchants must scan their exposed and in-scope Internet connected systems quarterly and remediate any high risk items.

Roles and Responsibilities

As Martin McKeay aptly noted, we must first understand who is in charge of what before asking questions or making accusations.

The PCI SSC is in charge of setting the rules.  That is it.  They manage the standard, the assessors, and provide information and clarity on both.

The card brands are in charge of enforcement of the standard.  This includes setting merchant levels, service provider levels, and working with the acquiring banks to manage compliance of all merchants.  They also get involved in the event of a compromise.

Now here’s the tricky part - not all card brands are alike.  Visa and MasterCard will never deal directly with a merchant.  Instead they will work through Issuing and Acquiring banks.  Whereas American Express, Discover, and JCB can go either way (working via issuing and acquiring banks or working directly with the merchant.)  Why is any of this important?  Because whoever the merchant’s acquiring bank is, be it Bank of America or American Express, they will define your validation deadline and work with you until you fully validate compliance.

If this still doesn’t make sense or you have further questions be sure to email or call us - both are listed on the homepage of this blog.

Popularity: 8% [?]

Today the PCI SSC (Council) announced it will host a webinar titled ” “Understanding the Payment Application Data Security Standard” on Thursday May 22, 2008 at 11:30 a.m. EDT and a second session the same day at
7:30 p.m. EDT.

The event will cover the following topics:

• How to get started with PA-DSS;
• Information about the transition of PABP to the Council;
• High level overview of the PA-DSS requirements.

I highly recommend you attend to get all the information you can about this new standard.  Also, if you did not view the last webinar you can see it online at: Navigating and Understanding the PCI SSC Self Assessment Questionnaire.

Popularity: 25% [?]

Today the PCI SSC added a new standard to the running list of standards and documents it manages (PCI DSS, SAP, SAQ).  We reported this was going to happen back in November of last year.  The Payment Application Data Security Standard (PA-DSS) is now formally a standard that the Council manages.  Check out the press release here.

PA-DSS is the Council-managed program formerly managed by Visa Inc. and known as the Payment Application Best Practices (PABP). The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, other sensitive authentication data or PIN data, and ensure their payment applications support compliance with the PCI DSS. PA-DSS requirements apply to payment applications that are sold, distributed or licensed to third parties. PA-DSS requirements do not apply to in-house payment applications developed by merchants or service providers that are not sold to a third party, but these applications must still be secured in accordance with the PCI DSS.

In addition to the standard itself the Council has also released a frequently asked questions for the PA-DSS.

Will the PCI SSC accept applications that have been previously validated under the existing Visa PABP program?

PCI SSC will recognize PABP validated payment applications and list them with the appropriate PABP version that they were validated against. For payment applications validated against pre-PABP version 1.3, they must undergo a PA-DSS assessment within twelve (12) months after the initial publication of the PCI SSC list otherwise they will expire and will no longer be accepted for new deployments. For payment applications validated against PABP version 1.3, they must undergo a PA-DSS assessment within eighteen (18) months after the initial publication of the PCI SSC list. For payment applications validated against PABP version 1.4, they must undergo a PADSS assessment within twenty-four (24) months after the initial publication of the PCI SSC list. Please refer to the table in the Grandfathering PABP Applications section of the PA-DSS Program Guide for more details.

How will the migration to PA-DSS impact vendors previously validated under PABP? Read the FAQ!

Check out the full FAQ documentation for all the fine details.  I’m happy there is so much infomation being released surrounding every document released by the Council!

Check out all the documents online:

• PA-DSS Security Audit Procedures
• Summary of PABP to PA-DSS Changes
• PABP to PA-DSS Transition
• QSA Validation Requirements - PA-QSA
• Program Guide
• PCI PA-DSS FAQs

Popularity: 25% [?]

Jay from the USA asks:

If our acquirer provided POS systems, do we need to make sure that the acquirer’s equipment and websites are PCI DSS compliant?

I’ve always said that you should “Trust but Verify”!  It is very common for a merchant to receive or be recommended a certain POS system, application, or platform from their acquirer, processors, or franchise manager.  If you are a merchant who receives such a recommendation, be sure to do your homework.

First, you need to check the Visa website to make sure that POS system/software has undergone rigorous security testing and has been validated as secure under the Payment Application Best Practices (PABP).  You can see a list of qualified products here.

Next, you need to obtain the “Implementation Documentation” or “Implementation Guide” from that POS vendor.  Although your POS may have been validated as secure, there are still a number of things YOU NEED TO DO to operate it in a secure manner.  This documentation or guide is the list of thing you need to do.  Follow it carefully and understand how to protect yourself.

Finally, you are 95% of the way there, you need to continually educate yourself about the difference between compliance and validation, the definition of cardholder data and where to find it, who to contact in the event of a compromise, etc.  You may follow this blog or you may enroll in structured learning.  Either way, you need to keep yourself informed.

Popularity: 41% [?]

I really like the reminder that Mike Rothman has to say about compliance, “The sad truth is that compliance is still the engine that is running most security operations.” Let’s not forget that the people who complain about compliance are also those who’s jobs are based on necessity for it.  Business is an easy formula: make more money and reduce your costs.  Is security is perceived as an unnecessary cost, it too will be reduced.

So instead of bemoaning and fighting the various aspects of compliance, why not leverage them to benefit the business.  Mike continues:

As we focus on 2008, the first order of business for security professionals should be implementing a structured security program that is focused on protecting what’s most important to the business, setting goals and milestones to ensure accountability and communicating how and why certain security controls are implemented. The end goal is to distinctly show the value and importance of security to the operations of the business.

So what’s next?  Well, those long time readers of this blog will know that it’s in inclusion of the Visa USA PABP into the PCI suite of standards under the PA-DSS moniker.

“With the PA-DSS managed by the council, we will ensure that payment application providers and their products are subject to data security requirements consistent with the current PCI DSS.”  Bob Russo,
general manager, PCI Security Standards Council

Furthermore, Visa has taken a proactive approach and outlined a series of Payment Application Security Mandates. These mandates outline the phasing out of vulnerable applications and phasing in of validated application with a fine deadline in 2010.

Popularity: 24% [?]

It has come to my attention that software vendors do not fully understand their responsibilities regarding Payment Application Best Practices (PABP) compliance and their customers’ PCI Data Security Standard (DSS) compliance. PABP compliance does not automatically imply PCI DSS compliance and visa versa. What follows is a recent real-life example of how a major vendor handled this situation and how it adversely impacted their customer.

One of my clients is implementing a new point-of-sale (POS) system in one of their operations so that this operation will be PCI DSS compliant. This POS vendor is not only providing the software solution but is also providing remote management and support of the solution.

The first problem my client ran into was their demand that the contract with the vendor contain language to ensure that the vendor’s services being provided were PCI DSS compliant. The vendor explained that their software was PABP compliant and that they were therefore PCI DSS compliant. We explained that the software was only part of the equation because the vendor would be remotely administering the system and that those services needed to be PCI DSS compliant. The vendor continued to argue that their PABP compliance was all that was needed but finally relented to the PCI DSS compliance provision.

We are now assessing the implementation of the vendor’s software for revising their PCI Report On Compliance (ROC). While the software is definitely PABP compliant, we have consistently had difficulty getting information out of the vendor regarding how to assess my client’s implementation of the solution. They have finally, and very reluctantly, admitted that cardholder data (CHD) is stored encrypted on the server at each location. In very tense discussions, they have also finally relented and released the process for managing the encryption keys to my client for their management. My client was relying on the fact that since the software was PABP compliant, they would not have to worry about additional controls. However, my client now has to rapidly make implementation changes to make sure that they meet the PCI DSS requirements for data center monitoring and controls because the new solution stores CHD locally on each server.

All through this process, the vendor has been arrogant and indignant. They have repeatedly stated that as they understood the process, PABP compliance was all they needed to be compliant with all PCI processes.

This has been meant to give software vendors a relevant example of why it is so important for them to be forthcoming with all information regarding their solutions with their customers. There is important information regarding the solution that the customer needs to know so that their implementation will be PCI DSS compliant. PABP compliance means that an application properly protects, manages and controls CHD. It does not mean that your customers will not have to implement their own management procedures and controls at their end to ensure their PCI DSS compliance.

If a vendor is providing management or other services to their customers that are covered by the PCI DSS, vendors need to understand that those services are not covered by any PABP compliance process and that these services need to comply with the PCI DSS.

And this situation will not change with the introduction of the PA-DSS.

Popularity: 47% [?]

So you might have read the recent Visa (USA) timeline for migrating to more secure point-of-sale (POS) technology. Or maybe you are looking at your aging systems and wanting to take the plunge and upgrade to a sexier, and more secure, system.

Here are a few things to consider before taking out the check book and laying new infrastructure.

1. Ask your acquiring bank if your prospective POS is a known vulnerable payment application. As the deadlines loom for payment application security some vendors may be looking to exploit a loophole in the system. You may notice that in 2008 companies cannot board new merchants using known vulnerable payment applications, so some of them may try to offload that technology before the end of 2007. The kicker being that in 2009 those companies may have to upgrade again to remove those known vulnerable systems. (More importantly, you may be installing a system known to make your environment non-PCI compliant.)
2. Confirm that your prospective POS vendor and version number is listed as a validated payment application. Visa publicizes a list of validated payment applications. If the integrated POS (IPOS) is not on that list — caveat emptor — regardless of what the vendor may tell you to the contrary. (This process is to be taken over by the PCI SSC in the coming years [PDF].)
3. Ask your payment application vendor or reseller for the Implementation Guide (or Implementation Documentation).  So you purchased and installed a validated payment application — you may be safe and you may not.  Each validated payment application comes with an instruction manual for configuring that app in a secure manner.  Without this Rosetta stone you may be living in a false sense of security.  It is a requirement that vendors and resellers provide this to you and educate you about it, but sometimes these things are overlooked.  Make sure you read and understand this document.
4. Encrypt data from the POS to the back-end systems.  Even though the payment application may be securing the data on the system itself, many are still transmitting the track data across the network to the back-end systems for authorization.  It is not a PCI requirement to encrypt this data, but recent compromises have shown that hackers are using technologies such as MPACK to sniff track data from the POS to the back-end systems.  Choosing a POS that has the ability to encrypt this data puts you one step ahead of the hacker.
5. Keep your POS network (and retail systems) segmented from the rest of the network (and from the Internet).  Network segmentation sounds like a monolithic task for some companies, but I’m only going to discuss two types here: segmenting one store from another, and within each store the cardholder data from all other systems.  It is well known that if you have stores directly connected to the Internet instead of a totally private network then you are a higher risk for compromise.  Also, if an attacker can compromise the wireless in-store network you want to make sure they cannot use that vulnerability to compromise cardholder data or any other retail store.

Knowing how the attacker thinks will help in defending against their most common attacks.  There is no way to have zero risk but we can limit it enough to have the hacker go elsewhere.

Know their weak points in the same way they know yours.

Popularity: 52% [?]

The PCI Security Standards Council (SSC) has updated their online FAQ to include questions and answers about the newly added PA-DSS.

When will the Payment Application Data Security Standard be available?
The Council has distributed a preliminary version of the PA-DSS for feedback from the PCI SSC Board of Advisors, participating organizations, QSAs and ASVs. A final version of the PA- DSS is expected to be published in the first quarter of 2008.

It also has questions on being a PA-QSA, so keep watching for updates.

See also other posts on the PA-DSS.

Popularity: 44% [?]

In early September the PCI SSC added the PIN Entry Device (PED) standard to its dossier of oversight items. Then at the end of September they announced the success of the first ever Community Meeting for Participating Organizations.

Now in early November they start the transition of the Payment Application Best Practices (PABP) from Visa and rename it the Payment Application Data Security Standard (PA-DSS). This follows the heals of the recently released Visa Payment Application Security Mandates.

It is important to focus on this area as it shows a strong push towards the security of smaller merchants (i.e. Level 2-4). It is widely known that many small merchant use similar point of sale (POS) technology and that the greatest risk to those merchants is from the compromise of those systems that store sensitive authentication information.

By turning the best practice document into a standard and then enforcing it with hard deadlines for compliance, the industry is delivering a 1-2 punch to the insecure systems and helping eliminate fraud in the smaller merchant arena.

Popularity: 58% [?]