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.

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.

Take a look and see if you can get funding to attend the training and exam on August 13-15, 2008 in Salt Lake City, UT.  I’ll be there along with others to network and discuss the Payments Industry.  After the intensive classes during the day, I’ll be leading up activities in the evening.  Remember, I was married in Salt Lake City, so I can get the lowdown on events and places to go.

This should be a memorable event for all those involved!

Also, if you are interested, the SPSP is looking for other bloggers who write about PCI to get their feeds listed on the SPSP site.

If you’re in the NYC area and care about wireless security, you should register for the event and attend.  I’ve always said that it’s better to have more tools in your toolbox.  Attending this session will broaden your understanding of the standard and help you maximize your security capital by focusing on day-to-day security while saitsfying your compliance needs.

I knew a company once that reverse engineered their database system so they could extract the encryption/decryption keys just so they could print them out and store them under “dual control” in two different safes.  That company successfully increased the risk to cardholder data just to meet a perceived compliance need.

I’d like to help you better understand the standard, especially those surrounding wireless security, so you can be more effective in securing your infrastructure.

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.

The carder underground is not to dissimilar to the e-commerce marketplaces we use such as eBay.  You see once a hacker can compromise credit card data (we’ll get to how very shortly), they want to monetize this data.  But who would trust someone who is selling illegal information in a digital format.  If they are a thief then what keeps them from selling the same data to multiple people and making even more money?  Well, how do you know who to buy from on eBay?  Reputation!  That’s right carders would give each other feedback online to build their reputation.  The enabled people to know who the reputable hackers were and which were not (if that’s even possible to say.)

Historically carders would sell their wares brazenly via online websites such as Boa Factory, CardersMarket, and ShadowCrew. These A-list credit card trading centers gave rise to hundreds of smaller sites such as TheftServices, CCPowerForums, ScandinavianCarding, DarkMarket, DarkPay, and The Grifters.

Boa Factory was run by Roman Vega, a Urkanian national, presently in jail in California.  He was king of the underground making large amounts of money selling passports, travelers checks, plastic cards, and “dumps” (what hackers call Track or Magnetic Stripe Data).  Roman operated unique to all others in that he subcontracted work to lawyers, botnet owners, hackers, traffickers, and carders.

Shadowcrew was a similar operation but operated as a message board for hackers to trade and exchange illegal credit card information such as “dumps”, CVV2 numbers, social security numbers (SSN), and much more.  A hacker with the handle of Iceman ran the bulletin board and policed the illegal activities.  Another member of that board David Thomas (aka. ElMariachi) disliked the operation and broke off forming another site called The Grifters.  Iceman and ElMariachi disliked each other in ways never imagined.  (You can read their banter back and forth in the comments section here.  You can read even more about this via a compilation of news articles from CanWest News Service.)

Once law enforcement took down one message board another would pop up, and the carders and buyers would migrate their operations.  CardersMarket was the largest of the last online carder forums.  It was run by, you guessed it, Iceman.  When the police took down CardersMarket they arrested Iceman (aka Max Ray Butler, Max Vision, Digits, Aphex.)

Law Enforcement (LE) quickly caught on and started shutting down each of these online sites.  They defaced sites such as ShadowCrew telling the hackers they had taken over the website and would not permit this fraud.  Sadly, not all hackers are very smart and some thought it was just a joke.  They kept emailing the Secret Service asking for the stolen cards they ordered.  Instead of credit cards they received jail time.

These days the online message boards have all but disappeared with the carders moving to older technology as their last resistance against law enforcement.  Carders exists in a low-tech world without borders.  They exchange credit card data on IRC (Internet Relay Channel) bulletin boards that have a tiered structure based on your level of access.

Now that we have identified the ‘carders’ of the underground, the next article in this series will focus on the actual flow of credit card data - from the POS to the point of monetization.  We will also explore how this channel is similar to the current housing market and why prices are so low.  Stay tuned.

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.

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.

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.