PCI Blog - Compliance Demystified

Podcast: ROI of Reporting Data Compromise

We just published another podcast, this time on the ROI of Reporting Data Compromises.  This is a topic I’ve long loved presenting and feel energized about.  When most people think about security breaches and data compromises, they often forget about data ‘exposure’.

Also, when hackers get in some companies try the cover-up approach.  Sometimes it can be financially detrimental to NOT report a data compromise.  This podcast walks you through the reasons you should report and what could happen if you don’t.

What percent complete is your PCI project?

Everyone from politicians to economists track metrics and statistics.  It’s the core of how we analyze the word and mentally quantify the world around us.  Visa tracks merchant compliance statistics within the USA, but what about other regions?  What’s happening around the world?

Rob Newby had some things to say about a recent survey performed of European companies.  (To which I replied here.) Walt Conway just published his NABCU survey results.  These surveys are all good, but many of them focus on the “percent complete” issue.  It reflects the lethargy within a company if they are waiting to make a move before they see others around them doing anything.

Really, what does it mean to you as a company if others within your geographic region are 50% done with their PCI compliance project?  Do you feel more momentum to do something if your company is on the tail end of a statistic and less if you’re on the leading edge?  I suppose in Malcolm Gladwell’s book The Tipping Point is apropos here as he argues for the theory of critical mass in the adoption of any fad.

The difficulty is that these statistics mean little to the security of your company.  How many Level 1 merchants were compliant when TJX, Hannaford, or Card Services were compromised?  Did it really have an affect on their security that 20%, 50%, or 90% of similar companies had addressed their compliance requirements?

When it comes to compliance the only statistic that matters is yours!  What have you done to reduce the risk of cardholder data loss at your company?  What are you doing to protect your customers’ data?  Do you even know where to start and what to do?  If you have questions post them in the SPSP Forum.

Update: Gideon Rasmussen of Bank of America wrote the document “Beyond Minimum Compliance“. Documents named as such should show that, at least in the US, we reached critical mass long ago and people are not working now phase 2.

iPhone to bring wave of wireless woes

Tomorrow, like so many others around the world I’ll be getting up early and waiting in line to purchase my new iPhone 3G when the stores open at 8 AM.  And like so many other giddy users I’ll head off to work and want to use and configure my device ASAP.

The problem this creates is an entirely new attack vector (ok, not so new) by deploying millions of Wi-Fi based cell phones that are now connected directly to corporate owned laptops.  Another way to think of this is that we are installing millions of wireless attack vectors into a corporate environment that will be undetectable from simple wired-side scanning.

When people look at PCI DSS requirement 11.1.b they think it may not apply to them because they have not purposefully deployed wireless devices.  Or they may think they can simply scan the wired network looking for wireless access points.  The hidden vector they are missing are devices that come enabled with wireless access.  Everything from laptops with radio (Wi-Fi) cards, to iPod Touch, and now the iPhone 3G.

You see the requirement states that people should use a “wireless analyzer” to find wireless attack vectors, but this only tells half of the story.  Historically, people did this via war-driving with Pringles can antennas attacked to Netstunbler or Kismit enabled laptops.  (I know @dacort and I did our fair share of this in a past life.)  But what happens when you have 1,000 or 5,000 retail stores?  What happens when you walk into one store and 50 access points show up on your screen?  How do you know the difference between the good and the bad?  How do you protect against not just rogue but also unauthorized access points?

That is why we wrote this lengthy FAQ on Wireless.  I’ll also be presenting on this topic next week in New York City (be sure to register.)

Not going to be in NYC?  How about Chicago, IL (July 30, 2008) or Columbus, OH (July 31, 2008)?

SPSP on LinkedIn

The Society of Payment Security Professionals (SPSP) now has a group on LinkedIn.  I joined because I’m a payments industry and social networking junkie.

Also, there’s also the Facebook PCI group.

If you want to add your blog to the SPSP RSS feed then apply here (you must be a member.)

IT Blog Award - IT Law and Governance

I’m not on the shortlist, but still shamelessly and transitively pimping ComputerWeekly by asking you, the reader, vote for one think is best (and tell them they missed the most important.)  Regulatory Compliance should be a category in and of itself, since that is what drive the majority of IT and security capital these days.  If it was, I also believe that PCI Compliance would be at the top of that list, and this blog would be one of the top on that list.

in Law Blogs

So, here’s my list of PCI Compliance blogs that I read.

• Society of Payment Securty Professionals: this feed includes PCI Answers, Rob Newby’s blog, Walt Conway’s blog, Aegenis podcasts, and much more.
• PCI Answers: this blog which includes non-nonsense clear answers to questions and issues surrounding PCI compliance.  I travel the world teaching classes and provide that experience right here.
• Walt Conway: his is one of the few blogs that focuses entirely on PCI within a certain vertical - the higher education field.  I have presented at his conferences and know him to be highly focused on the impact of regulatory compliance.
• Rob Newby: who focuses his blog on PCI and IT security.  He covers PCI and security throughout the UK and Europe.
• Trey Ford: who covers PCI from an application security perspective
• Ed Bellis: one of the SPSP Advisory Board members and application security lead.  He writes on relevant topics to security and regulatory compliance.

Are there others that I’ve missed?

PCI 6.5 and the OWASP Top 10

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.

PCI Adoption in Europe and Asia Pacific

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.

CPISM certification classes filling up

I just checked the SPSP website under Events and noticed the CPISM certification training and exam are filling up.  The list of people attending includes Fortune 500 companies and lots of people from the Payments Industry.

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.

Wireless and PCI - executive dinner in NYC

AirDefense and Motorola have partnered to hole an executive dinner on wireless security in NYC on July 17th, 2008.  They invited us to present and I’ll be talking about wireless security as it relates to PCI DSS compliance.  I’ll also be discussing the difference between compliance and validation as it pertains to current data compromises.

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.

PIN Theft

We have blogged before about attacks on PIN terminals, but here’s another blog post and interesting video on that theft in action.  It seems The Real Hustle has a number of YouTube videos on a variety of scams ranging from technical to strictly social engineering.