Rob Newby blogs about the statistics and studies on the adoption of PCI compliance in Europe, based on the data points from a Register article with the same focus.  The article states:

European merchants are behind their US counterparts in getting up to speed with the Payment Card Industry’s Data Security Standard (PCI DSS), according to a survey by management tools firm NetIQ.

Rob points out that with a sample population of 65 data points:

… all I can conclude from this survey is that NetIQ customers are ignorant, which isn’t a great advert for them.

There’s a little bit of truth in both opinions (read the NetIQ comments on Rob’s blog.)  It is true that PCI adoption in Europe is slower than that of merchants in the USA, and Asia Pacific is even further, but there a very good reason for this.

You have to factor in that organizations such as APACS has been pushing Chip-PIN for many years now.  France implemented Chip-PIN for the past six years.  This is not to say that the risks are lower, but many different factors play a role.

European PCI DSS Adoption Factors

The first factor is that of education.  Whenever you talk with someone about PCI in Europe this is how the conversation goes:

“I’d like to talk with you about PCI DSS.”
“PCI DSS? What is that?”
“Well it has to do with credit card security…”
“Oh, I don’t need that, I have this Chip-PIN infrastructure.”

It’s hard to get merchants over the fact that they cannot mitigate all the risk of storing credit card data simply by rolling out Chip-PIN terminals.

The second factor affecting merchant compliance in Europe is that in countries such as Spain and Italy a merchant will not have just one or two acquirers but more like 10-12 acquiring banks.  Since each bank only does 1/10 or 1/12 of that merchant’s business it’s a hard business proposition for one of them to take the first step forward and require the merchant to validate their compliance.  The risk is high that a merchant may simply drop that acquirer from their transaction processing channel.

Asia-Pacific PCI DSS Adoption Factors

Within the Asia-Pacific (AP) region merchant adoption of PCI DSS has been slow due to the risk factors.  Each country is different, but as a region the amount of fraud happening “in-country” is rather low.  This means that credit cards compromised and used fraudulently within S. Korea is very low.  The fraud of note is that which is classified as “cross border” fraud.  This is where a credit card compromised within the USA is then used in Australia fraudulently.  Due to these fraud factors, and the historic emphasis on driving service provider compliance within the region, merchants are slower to the game.

That said, I was just in Australia and the number of QSA companies operating in the region is considerably higher both there and in Japan (two of the largest AP countries by transaction volume.)  This increase in auditors shows an increasing demand for compliance validation on behalf of merchants.  Articles that show the “slow” adoption are like trying to buy a car without looking under the hood.  You may look at an older Honda Civic and think you can beat it in a race, but not if it’s got a turbo-charged Acura engine under the hood.

I think the key to remember is that all merchants are at risk and that risk varies by industry, vertical, infrastructure, and so many other factors.  I like Rob’s reminder that:

I am prepared to admit that the spotlight will be on the Tier 1 merchants in the first instance. However, its a bit like relying on everyone else being fatter to avoid heart disease, i.e. stupid.

Popularity: 6% [?]

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

Many people know by now that PCI DSS Requirement 6.6 is going into effect (meaning you must be compliant) on June 30, 2008.  What these same people are asking is, how does this apply to me and my business?  And how can or should I comply with this requirement?  There have been a number of blog posts about this requirement and even more discussions about what it all really means.

What does it mean?

In order to understand this you have to take my Attack Vector based Risk Management (AVRM) approach towards the intent behind this requirement.  One could easily reference that the intent behind this requirement is to prevent Internet-facing web-application compromises and you would be correct, but also missing the deeper meaning and back story.

Although card-present (typically IPOS) systems account for a greater number of credit cards stolen, about half of all account compromises are a result of web-application data breaches.  Of this population, about 90%+ of the data compromises are a result of the top 5-10 web-application vulnerabilities.  These include, but are not limited to, SQL injection, cross-site scripting, cross-site request forgery (CSRF) and other input/output validation issues.  Knowing this you can now imagine that if we could mitigate the risk of these top attacks we could reduce the population of credit card data breaches by almost half!  (This does not reduce the number of credit cards stolen by half.)

The consideration here is not just to protect against the OWASP Top 10 but to consider those that apply to your web-application and understand those that cause the highest risk to your application.  Consider the risk you could mitigate simply by properly validating the input/output on your application.  Would this address all risk?  No, but it would get you significant progress towards that goal.

Also, remember there is a difference between compliance and validation.  If you validated your compliance prior to June 30 you do not need to re-validate for 12 months, but you do need to be compliant with the standard at all times.  Compliance is a state of being that you must maintain at all times; for this requirement it means on or after June 30, 2008.

How can I comply?

The best part about this (and other) requirements is the large number of ways to comply.  Remember, the goal is to meat the intent - so how can we do this?  Well the standard states two options, and the intent leaves it open to many others.  Let’s list the two given options first:

• Have all custom application code reviewed for common vulnerabilities by an organization that specializes in application security.
• Install an application-layer firewall in front of web-facing applications

First, remember that it is not comparing apples to apples here, but providing options that different enterprises can implement depending on their specific needs and abilities.  We are still aiming to meet the same intent.  Notice that, agnostic of technology, we can meet the intent using either of the prescribed methods.

Second, we should use the ‘intent’ defined above, via the AVRM model, to understand what “common vulnerabilities” means.  To clarify the meaning of “an organization that specializes in application security” they are saying you should use a company that can identify the “common vulnerabilities” and remediate them, rather than your 8 year old nephew who just took her first computer programming course.

Now people are always asking what is an “application-firewall”.  They know what it is, but want to know what you think it is.  We should no longer have to answer that question again, because agnostic of technology an “application-layer firewall” should satisfy the intent behind this requirement as outlined above.

Still not enough?  Well, the PCI SSC has released an Information Supplement that clarifies Requirement 6.6.  Among other things, this supplement offers four additional alternatives towards meeting the intent of this requirement:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

Still not enough to meet your business requirements?  Then document a compensating control and write up how it mitigates the risk, to meet the intent, that could not be accomplished due to a legitimate business or technical issue.

Popularity: 20% [?]

If you build a new deck in your backyard, would you test it out before inviting your friends and family over for a bar-b-que?  Well it turns out that many merchants are documenting compensating controls but not actually testing them to make sure they work.  How could this be?  I’m asking myself the same question.

There is a simple approach to understanding compensating controls that starts with asking the question, “When would I use a compensating control?”  The answer to that is any time that you have a legitimate business or technical reason.  For example, you may have some specialized technology that meets the intent of the requirement but not in the prescribed manner of the Security Audit Procedures (SAP).

Then you should document your findings, so you can show them to people if they ever ask, “what in the world were you thinking?”  This documentation should include those items listed in the Compensating Controls Worksheet.

1. Constraint - the business or technical constraint precluding compliance with the original requirement
2. Objective - the intent of the original control
3. Identified Risk - the risk posed by the lack of the original control
4. Compensating Controls - the controls in place that mitigate the risk to meet the intent that could not be achieved via the constraint

But you cannot stop here!  You actually need to test these compensating controls to make sure they hold up.  It’s not sufficient to say that a company uses RACF security on their Mainframe as a compensating controls for something else if you do not evaluate the security of the RACF configuration.  For each compensating control you must actually TEST it to make sure it is sufficient to mitigate the risk to cardholder data.

As Ronald Regan always said, “Trust, but verify!” (“doveryai, no proveryai”)

Popularity: 18% [?]

Walt reminded me today of a conversation being had about the cost of PCI compliance.  Him and Scott have been calculating the cost of compliance within the USA.  They say it’s about $2 billion or more, give or take.  I cringe whenever someone calculates the cost of anything with so much variance.  It’s so difficult to determine the actual numbers because of the variance within each factor.  For example, within Level 1 merchants some are very, very large and others are very small.  Also, there is a variance in the mindset about compliance and the risk tolerance someone is willing to accept so they may implement different levels of each requirement.

It boggles the mind to think of how varied these numbers can be.  But what if.  What if you *could* calculate the total cost of compliance?  What good is that information?  Do you want to balance it against the cost of other alternatives for the industry?  The problem with such big numbers is that they rarely apply to the industry, but should apply to the individual.  It’s the old saying of “think globally, act locally.”  For example, companies quote the cost of card replacement, in the event of fraud, anywhere between $1 and $25 per card.  What does this large variance mean to the industry?  Not much, but it should mean something to the individual.  It should mean that, cumulative with other costs, it makes business sense for companies to comply with the PCI DSS.

I think the more interesting question is, “Why is the cost of compliance so high?” The answer here is that companies do not look to reduce the scope of compliance before pulling the trigger on security.  If business people drive the audit they look at cost and balance business requirements against security.  If security people drive the audit they will secure the hell out of a bad business process.  A part of defining scope is understanding the rules of compliance and your options for getting there.  Too often companies do not understand the intent behind each requirement, the attack vectors being used to perpetrate fraud, and thus do not understand how best to allocate security capital.

The resources are out there.  The truth is out there.  It’s your job to find it.  It’s our job to help you get there.

Popularity: 25% [?]

Yes, you knew it would happen eventually.  We are launching the Aegenis PCI Podcast via iTunes and plan to distribute such content continually.  Our goal has always been to increase the level of knowledge within the industry and help merchants better understand compliance so they can feel empowered to make their own, well informed, decisions about risk management.

If you have not already, check out our eLearning platform.

Popularity: 26% [?]

As you may know, my company, The Aegenis Group specializes in education services for PCI DSS and other regulatory compliance areas.  I’m happy to announce to announce we have taken it to the next level.

The Aegenis Group recently introduced an eLearning Solution specifically developed to meet the unique learning needs of the Payment Card Industry. The solution also allows Acquiring Banks to meet the education requirement mandated by certain card brands. The mandate requires Acquiring Banks to educate Level-4 merchants regarding their responsibilities for the protection of Cardholder Data and compliance with the Payment Card Industry Data Security Standard (PCI DSS).

This means that we are now offering merchant training for all merchant types, with a focus on educating the Level 3-4 (smaller) merchants.  It’s both scalable and global in its reach.  You can check it out online, and visit our booth at ETA in a few weeks.

Are you interested in educating your merchant base?  If you are an acquirer, large service provider, franchise, merchant association, etc. then contact us directly for more information.

Popularity: 27% [?]

Should I accept CVV2/CVC2 or not?  That is the question.  Long time readers may notice I link to Walt’s content, but he offers up some great information, especially to Higher Education.

Checking the security code does not affect the interchange fee and, therefore, doesn’t (or shouldn’t) affect costs. It only has a role in a chargeback.

Popularity: 32% [?]

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