In a recent post by Jeremiah Grossman, he comments on how the PCI DSS Requirement 6.5 mentions the OWASP Top 10 from 2004 when the latest version is from 2007.  Yes, we all know that this to be true, as he notes in his post, but to say that these differences matter is a statement of taxonomical nuance and not one of practical application.

Before I go further I’d like to say that I met with Jeremiah only once (at RSA this year) but from all accounts (Trey Ford) he is a nice guy and technically empowered.  Also, I have a high respect for Andrew van der Stock and the difficult job he has in codifying the OWASP list.  I’ve had conversations with Andrew over the years about the history behind OWASP and PCI and believe I know the reasons things are they way they are.  So let’s go…

To say that the PCI DSS should keep pace with another standard is unjustified.  The PCI DSS requirements have evolved over the years to remove any reference to an outside group or body and genericized its language over things such as file-integrity monitoring and web-application firewalls to accommodate a variety of business processes.  The Council updated the document in 2006 to version 1.1 and virtually eliminated the use of the word “periodically” in place of concrete terms such as quarterly, weekly, or annually.  I understand why this was done as I too thought that periodically meant every 10-20 years (*joke*).

Jeremiah says that due to this usage and reference to prior days we now are in a situation where:

That means you still have to code against Buffer Overflows and Application DoS, but not Malicious File Execution, Insecure Direct Object Reference, and Cross Site Request Forgery (CSRF).

Dare I propose that Cross Site Request Forgery (CSRF) (more info here) and Remote File Execution (RFI) are really both simply “Injection Flaws”?  While trying to understand the OWASP list, a friend of mine, Rnast, gave me this bit of wisdom (and humor).  In fact A1, A2, A3, and A5 are all similar in one form or another and exist due to poorly coded web-applications, which in themselves are exploited via the injection flaws that exist in these applications.  Taxonomicaly these are listed as different vulnerabilities due to the initiation of their attack vector and how or what they exploit, but they have many similarities as well.  (Many thanks to Rnast for walking me through some of the more technical parts.)

So, taken literally, even using the 2004 data, which could not have been in the standard (v1.1) due to it being released in 2006 - one would still have to address Injection Flaws, which I would claim is almost 40% of the OWASP Top 10 in 2007!  To make a change, everyone should submit their feedback directly to the Council and propose they make changes for the next version of the standard.

Popularity: 3% [?]

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

Yes, it’s true, even babies can be PCI DSS compliant.  It appears that having children means integrating them into your life and watching as they integrate into yours.  A good friend of mine, Jacob, blogged about how his baby utilizes two-factor authentication to verify that the person holding him really is “Daddy”.

Some of my colleagues joked with me when we were expecting that he would be born knowing the PCI DSS requirements. I guess he’s got 8.3 down at six and a half months.

Popularity: 17% [?]

In reference to the Certified Payment-Card Industry Security Manager (CPISM) there is a Wiki article now online.   This certification is managed by the Society of Payment Security Professionals (SPSP).  If you have not registered then do so now.  Once you join you can browse the member list and see the wide range of professionals that participate.  Also, you can download the membership demographics analysis showing this distribution and member attributes.

They are currently in progress of upgrading the back-end software to improve all of the current features including the Forum and Blog.  Once updated you will be able to subscribe to individual RSS feeds for every part of the site including the updated online forum.  Look forward to new feature in the future, for even better collaboration.

Popularity: 16% [?]

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

Bryan Sartin invited me to a Webinar last week that summarized the Verizon/Cybertrust data breach analysis. Kokie Tjan informed me there is a PDF summary available online of the Verizon Business Data Breach Investigations Report.

This is the 10,000 foot view of a horizontal industry (payment systems).  Don’t forget to focus on how data breaches and risk applies to your specific vertical industry (i.e. higher ed, hospitality, travel and entertainment).

Sometimes those risks that affect the wider industry apply directly to you and sometimes you have very specific vertical industry threats.  As you may recall, one of my manrtas is “attack vector based risk management”.  In order to understand your risk you must understand the threats and ways an attacker values your data and systems.

It’s not always just the type and volume of data you store.  It’s also understanding how attackers view your exposed systems and what they think is easiest to attack and monetize.  Just like sailing a boat is not only about your skills as a mariner, you are also affected by the wind and water around you.

Popularity: 16% [?]

Have you considered disaster recovery for your payment systems?  Do you know the only thing that PCI DSS compliance requires you to backup?  David Bergert writes about the basics of how to prepare your payment systems in the event of a disaster.  But missing is the one critical element required for compliance.

The phrase “disaster recovery” does not appear in the PCI DSS.  The phrase “business continuity” only appears once in requirement 12.9.1 as, “[verify that the Incident Response Plan includes a] strategy for business continuity post compromise”.  Instead of referencing disaster planning the PCI DSS references backups.

There are a number of PCI DSS requirements relating to backups, such as:

• 9.5 “store media back-ups in a secure location”
• 10.5.3 “Promptly back up audit trail files”

What was that?  The answer is that audit logs are the only thing companies must backup for PCI DSS compliance.  Now, companies will want to continue business and as a result will backup all of their critical systems and corporate information, but this is outside the scope of PCI compliance which focuses on the security of payment card data.

Popularity: 14% [?]

Many people ask me how they can become a Qualified Security Assessor (QSA).  The only want to become a QSA is to work for a QSA company, be accepted by the PCI SSC, and attend industry specific training.  But what about the rest of us who want a badge of legitimacy without changing jobs?  For this there is the CPISM.

The Certified Payment-Card Industry Security Manager (CPISM) is the de facto certification for those within the payment-card industry who want to prove their security and industry knowledge.  To prepare for this rigorous exam there are a few documents available online to assist you.

First there are the CPISM Knowledge Domains.

• Payment card industry structure
• Payment card structure and data
• Payment card transaction processing
• Compromise fraud statistics and trends
• Merchant risk analysis
• Laws and the regulatory environment
• Payment card security programs
• Third party relationships

Check online for the following documents at the Society of Payment Security Professionals (SPSP):

• CPISM Overview Document
• CPISM Bibliography
• CPISM Study Guide

Still not ready?  Enroll in one of the in-person training classes and get direct education to help prepare you for the exam.  Check the SPSP website for dates and locations for the training classes.  The next one is August 13-14, 2008 in Salt Lake City, UT.

Popularity: 16% [?]

David Gamey pointed me to the Register article on yet another scam fraudsters are using to defeat credit card fraud checks.  We have discussed this topic before with pay-at-the-pump, but this new attack really goes to the heart of a fraud check that is called the Address Verification System or AVS.

Because AVS does not check all values in the address (i.e. just the house number or postal code) it is possible that an attacker could use an alternate address that has the same numbers (i.e. same house number but different street).

However fraudsters have begun exploiting the fact that many addresses can have the same AVS code. By making sure billing addresses and delivery addresses used in scams have the same code they make it more likely that purchases will go through.

This is, at best, a weak attack because it cannot be monetized quickly over a large number of card numbers.  In order to perpetrate the attack the attacker would need to have your name, address, and credit card number.  This information is usually obtained from e-commerce compromises, though could originate from other sources.  The attacker would then need to find a drop site that has the same information that is checked for in your address (i.e. same house number but different street).  This could work for one account number.  If they want to replicate it they need to find a new drop site, which is rather difficult and time consuming.

Also, let’s not forget that AVS is not used globally.   For example it is used in the UK, USA and some other regions, but not in continental-Europe and most of the Asia-Pacific region.  This diminishes the potential for attack.  Also, different Issuers may check different information via AVS which means you would need to know what information each Issuer checks, happen upon a card number from that Issuer, that is associated with an address similar to a fraudulent drop site you already have.  These stars do not align so nicely quite as often as one might think.

Popularity: 16% [?]