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% [?]

People have asked if Virtual Servers can be used in a PCI DSS compliant environment or if they violate requirement 2.2.1 which says, “Implement only one primary function per server”.  The answer is that virtual servers, virtual clusters, and even cloud computing are perfectly acceptable within the confines of PCI DSS compliance as long as they are properly configured.  The operative question when discussing the use of any technology within a PCI DSS compliant environment is always “Yes, but is it properly configured to prevent abuse?”

Hoff and Siebert both posted this question here and here.  People may think that <insert latest technology here> will somehow prevent a company from being PCI DSS compliant, when in reality the compliance program is built around protecting cardholder data.  That technology you want to implement is probably fine as long as it doesn’t put cardholder data at risk.  But people focus in on that one requirement and then everything falls apart.

PCI DSS Requirement 2.2.1 is like the ‘force’ in Star Wars - it can be used for good or for evil.  Unfortunately, it is the single most abused requirement in the standard.  Some people, using it for evil, go as far as to say that DNS and WINS cannot reside on the same server.  This requirement is meant for situations when companies try to pile every service imaginable onto one computer, causing a situation that actually puts cardholder data at risk.  For example, if a retail store manager uses the back office PC that aggregates their credit card transactions as their personal workstation for browsing the Internet.  This is a unsafe practice and violates several PCI DSS requirements.

Virtualization is an emerging technology that enables companies to securely leverage one physical server to run multiple virtual systems.  This is beneficial in areas with limited physical space.  If a company can run four virtual systems and only use the physical space of one server they can reduce the cost of housing and maintaining excessive hardware.

Additionally, virtualization provides a number of administrative benefits such as centralized data storage and security, centralized configuration and patch management, and a number of other processes.  Companies can benefit from using virtualized systems but they must also consider how these systems segment access from one to the next.

Just as with PCI DSS Requirement 2.4 (shared hosting environment) and the question of what defines “adequate segmentation” one must examine the security systems that separate one virtual system from another.  Any form of segmentation, virtualization, or shared hosting environment is acceptable under PCI DSS as long as it prevents one set of systems or people from negatively impacting the security of other systems or people.  The delineation point for what defines “adequate” virtualization is any system that can properly prevent one virtual system from negatively impacting the security of cardholder data on another virtual system.  It is the responsibility of the implementor to verify that such controls are in place.

Virtualization will continue to grow in popularity and, properly configured, can be used to adhere to PCI DSS compliance.  The technology itself is not often the culprit of non-compliance, instead it is how the technology is implemented or installed that can cause both security and regulatory compliance mishaps.

Popularity: 28% [?]

Visa Inc. published their operating regulations (opregs) online.  You can get the following:

• Visa International
• Visa U.S.A.: Volume 1
• Visa U.S.A.: Volume 2
• Visa Asia-Pacific
• Visa Canada
• Visa Central Europe, Middle East and Africa Visa Latin America and Caribbean
• Interlink

MasterCard published their operating rules last year. You can get the following:

• Chargeback Guide
• Cirrus Worldwide Operating Rules
• Maestro Global Rules
• MasterCard Rules
• Merchant Rules
• Excessive Chargeback Program Document

Popularity: 23% [?]

Maxim Emm from Infosec in Russia has translated the PCI DSS, PCI Security Audit Procedures, and Navigating the PCI DSS into Russian.  This is an unofficial copy of these documents but could be helpful to people who would like this resource.

If none of these links work due to your browser not supporting Cyrillic characters, click the page link.

All official copies of the PCI DSS and Security Audit Procedures (SAP) are accessible from the PCI SSC website where they are offered in multiple languages.

Popularity: 30% [?]

One of the terms economists have been throwing around is that of ‘stagflation‘.  This term describes an uncommon situation where both inflation is high and there is a stagnation in terms of production and employment.  You see, inflation typically implies higher production, which implies higher employment.  Currently, unemployment is high and combined with increasing inflation.

‘Stagpliance’ is how I describe the current compliance environment.  We have high compliance numbers (pdf) that should reflect a decrease in data compromises.  The problem is that data compromise numbers are still high. So the question is, why is this seemingly atypical situation happening?

Well, one explanation is that not everyone is compliant, meaning hackers are moving from the low hanging fruit to the next branch up the tree.  This is certainly the case in some large merchants and many small merchants.  Anyone who has investigated cardholder data breaches over the last five years can tell you that attacks are becoming more complex and hackers are moving to smaller merchants. But this is not the only explanation.

What has this experience shown us?  I believe the reason for our current stagpliance is due to the continued need for proper education.  Experience has shown us that (1) technology alone is not enough and that (2) data compromise is not the the result of failing technology but the lack of education.  Data loss is not the result of poor technology, but poorly configured technology.  As more and more people pay attention to compliance, data loss is moving to the edge, where merchants do not know data exists.  It is also continuing to happen in places where merchants do not properly understand their risks - based on active attack patterns.

Last year Visa published a Visa Business Review (VBR) that specifically called for acquirers to address compliance with their Level 4 merchant population using a risk based approach.  This VBR outlined several points, some of which are here blow:

• “Define a process that prioritizes Level 4 merchants into appropriate risk categories or subgroups”
• “Describe plans to educate Level 4 merchants about cardholder data security, storage of prohibited cardholder data and PCI DSS compliance. Include the planned communication channels and approximate frequency.”

The concept here is that acquirers empower their merchants through education to understand the risks facing them, and both address compliance and mitigate those risks appropriately.  This type of grass-roots effort is a great way to give merchants the knowledge to make risk based decisions on their own.

How many merchants that are hacked understand the Top 10 risks (and associated attack vectors) they face?  Large merchants don’t even always understand their risks because they are not aware of the current ongoing attacks.  I’ve always stated that security is not created in a vacuum.   In order to implement proper security you must first understand the current attack landscape.  Many small merchants have no idea of the top attacks they need to protect against.  An equal number don’t even know they are storing something that attackers want.

What has education shown us?   Compliance without education does not equal security.  In 2007, Visa trained thousands of merchants on the intent behind compliance requirements, the top methods of data compromise, definitions of cardholder data and cardholder data environment.  In each of these classes merchants felt empowered to take a risk based approach towards achieving compliance.  They felt empowered to make the right decision instead of the checkbox decision.  This is the kind of empowerment we need to properly address the security of cardholder data.

The problem is that there are many more merchants, millions in the US, and even more globally.  We need to educate those merchants, not just about compliance, but about risk!  I’ve long said that all the information about PCI is freely available to the world today.  It exists on blogs like this, on online forums and other places.  The problem is digesting that information into something useful.  What we need is true experts to assemble risk based, guided education for the large number of merchants globally.

In person training provides the greatest value but is also the most costly form of education.  The Aegenis Group teaches classes for large and medium sized merchants, but there is also training you can obtain from other sources such as Visa’s merchant education program, and industry specific venues like the Treasury Institute.

Stay tuned for more educational assistance from The Aegenis Group.

Popularity: 52% [?]

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 was talking today with someone about the fact that you really don’t need to store the cardholder data (not even the PAN) after authorization and was reminded of the the PDF that’s online regarding something similar.  Eliminating Storage of Prohibited Cardholder Data talks about reasons companies will want to store that sensitive authentication data - but should not! (PCI DSS Requirement 3.2)

It covers different processing procedures including:

• Recurring transactions
• Delayed shipments
• Chargebacks
• Copy requests

My personal favorite (if I can be that much of a geek) are the discussion surrounding recurring transactions and delayed shipping.  The later comes up all the time in e-commerce fulfillment companies (i.e. Amazon.com, Buy.com, etc.) who need to process an order for several items but may ship them separately.

Recurring transactions happen all the time (i.e. gym membership, cable bill, etc.) but should never store the sensitive authentication data after the first authorization.  Merchants should work with their acquirer on how best to handle these transactions.  Some acquirers will set up another merchant ID (MID) fot recurring transactions so they can be properly flagged as such.

Popularity: 29% [?]

Since Visa has been reporting significantly higher compliance levels among Level 1-2 merchants, it is important to focus on the smaller merchant community. I was discussing this with a friend who asked, “What is a Level 4 merchant?” This is a very good question because it shows that some merchants do not understand the merchant level hierarchy and the associated reporting procedures.

The definition of a Level 4 merchant may vary depending on your geographic location and card acceptance type. For example the Canadian arm of Visa Inc. lists both Level 4a and 4b merchants. The other Visa regions (with the exception of Latin American and the Caribbean) define a Level 4 merchant as:

• Any merchant processing less than 20,000 Visa e-commerce transactions per year, or
• Any merchant processing less than 1,000,000 Visa transactions from any other acceptance channel (i.e. in-store POS) per year

MasterCard Worldwide does not have a Level 4 classification, but list them as any merchant that is not a Level 1-3 merchant. If you read the Level 3 definition you will see that they classify Level 4 merchants in much the same way as Visa Inc.

What does this mean?

Well, it simply tells you where you fall in the grand scheme of PCI DSS compliance. Remember that although compliance of the Level 4 community is mostly optional and managed by the acquiring bank or transaction processor, that all merchants regardless of level definition must be compliant.

Level 4 or small merchants should look to their point of sale (POS) system and make sure that it is in compliance with both the PABP and PIN security requirements. If you want more information on validating your compliance, then take a look at the latest self-assessment questionnaire released by the PCI Security Standards Council.

Popularity: 30% [?]

Visa announced in a press release (1/22/2007) that their compliance numbers for 2007 are very high.

Visa Inc. announced today that as of the end of 2007, more than three-fourths of the largest U.S. merchants [Level 1] and nearly two-thirds of medium-sized merchants [Level 2] have now validated their compliance with the Payment Card Industry Data Security Standard (PCI DSS). Merchants in these two categories account for approximately two-thirds of Visa’s U.S. transaction volume.

These are impressive numbers and show that 2007 really was the tipping point for compliance. Look for an even higher rate of compliance as the remaining percentage of merchants complete their compliance projects. Must of this progress is due to the continual critical mass that has been building since September 30, 2007 and the Visa CAP program.

So what’s next? Walt is spot on by pointing to Level 4 merchant compliance. Read the Visa bulletin on Level 4 merchant compliance, and focus on the area requiring education.

Popularity: 24% [?]

Many of you have already heard about the TJX settlement with the Issuing Banks (not-Visa).  Although the case may involve Visa, it is only as an intermediary.  It is the Issuing banks that had to cover fraudulent charges that are being reimbursed.

The discount clothing retailer will pay up to $40.9 million in pre-tax recovery payments to eligible U.S. Visa issuers who issued payment card accounts identified to Visa by Fifth Third or TJX. At least 80 percent of the issuers must accept by Dec. 19 for the settlement to finalize.

I like what Walt says here, “This settlement sort of puts the $880K fine in perspective.“  It does put the card brand fines in perspective.  I have been saying for a while not that for large companies it is not the card brand fines that are the largest cost, instead it is the following:

• Issuer reimbursement (see above)
• Cost of obtaining compliance fast
• Forensic, remediation, etc.

Popularity: 43% [?]