Are you working with a Qualified Security Assessor (QSA) and want to make sure they are legitimate?  The PCI SSC just launched “a tool to verify the certification status of representatives from PCI SSC Qualified Security Assessor (QSAs) Companies.”

Lookup your QSA’s employees to verify they are properly qualified.

Popularity: 4% [?]

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

Many people ask about storage of data pre-authorization (that is before the authorization for the transaction has occurred) and what it means for PCI DSS compliance.  First, we should point out that PCI DSS does not address pre-authorization data storage, this is managed by the individual card brand Operating Regulations.

But we know that many merchants will use Store and Forward (SAF) for transactions, “typically ISO 400 messages with many of these containing field 35 (Track II Data)“.  This is where a merchant is offline either intentionally or not, and they queue up transactions that are stored locally.  Later when the merchant goes back online they send these transactions off to their acquirer (and transitively onto the issuer) for processing.  These transactions are also sometimes called “on us” transactions, because if the response from the issuer is ‘denied’ then the merchant must absorb the cost of the bad transaction.

Aside from all this, it’s important to point out that sooner or later the transaction will go through and be completed.  This means that any data stored in a pre-authorization style will eventually be authorized and this the responsibility of the merchant to protect.  If the cardholder data is ever compromised from the merchant and fraudulent transactions are traced back to the merchant, as the Common Point of Purchase (CPP), the responsibility still falls on the merchant.

This is why I advise merchants to protect cardholder data that is stored in pre-authorization transactions the same as they would for other cardholder data (i.e. PCI DSS Requirement 3.4).  Of course they should always check their card brand Operating Regulations for official statements.

The Payment Systems Blog points out:

On May 1st, a payment processor modified their message formats as a part of their PCI compliance to not send Field 35 in SAF Advice transactions and would just send the PAN in field 2 and Expiration Date in field 14, instead of DE 35.

AndrewJ also points out that:

Another update on this (if you are from Australia) - there is a change being made to AS2805.2 to change the track 2 field from mandatory to optional in 04×0 messages. This should be released sometime this month.

Popularity: 6% [?]

I got back last night from presenting at the Treasury Institute PCI Workshop that Walt Conway puts on every year.  It was a great success with over 130 participants from just about every major university and higher education facility.  It was nice meeting both TouchNet and infiNET, sponsors of the event and companies that I performed their first PCI assessment many years ago.  I also saw Breach Security a sponsor and company that helps prevent against bad things.

I gave a presentation talking about “Heroes, Chorus Lines, and Community”.  The three parts translate shortly into:

• Heros: those who have validated compliance, and their foes being those who have not.  Let’s first define the difference between compliance and validation, and then look beyond simply achieving validation and determine how you got there.
• Chorus Lines: The chorus lines are things we remember but how many of us remember the verses? We all know the details of compliance (i.e. requirements 1-12) but do we understand the intent and nuances of these?  Are we looking at the big picture or still asking, “what is a system-level object?” Also, have we moved beyond simple risk management to a state of Attack Vector based Risk Management (AVRM)?  This is where we look at how attacks occur and use that information to better allocate capital resources to mitigation measures.
• Communities: I highlight the importance of knowing who to trust and how to build trusted relationships in order to increase the flow of information and keep the signal-to-noise ratio in tour favor.  “Trust is the only real currency” is the mantra of this section and we outline a few communities for you to follow: SPSP, blog, podcasts. But most important is meeting others who are in the same situation and keeping in touch so you can do a sanity check on your status and actions.

This event was focused around the implementation of PCI DSS compliance projects for Higher Education.  In between were presentations such as mind, those from Benita Kahn on the legal aspects of PCI, and Bob Russo, Chairman of the PCI SSC.

Popularity: 5% [?]

Today the PCI SSC (Council) announced it will host a webinar titled ” “Understanding the Payment Application Data Security Standard” on Thursday May 22, 2008 at 11:30 a.m. EDT and a second session the same day at
7:30 p.m. EDT.

The event will cover the following topics:

• How to get started with PA-DSS;
• Information about the transition of PABP to the Council;
• High level overview of the PA-DSS requirements.

I highly recommend you attend to get all the information you can about this new standard.  Also, if you did not view the last webinar you can see it online at: Navigating and Understanding the PCI SSC Self Assessment Questionnaire.

Popularity: 6% [?]

I’m going to step out on a limb here and contradict what others have been saying about data classification.  Data classification is not dead!

PCI DSS Requirement 9.7.1 says, “Classify the media so it can be identified as confidential.”  This is in reference to distribution of electronic media (i.e. backup tapes).  The previous wording was to “Label media…” but we knew what this meant and didn’t all go out buying label guns to stock along side the duct tape we already had.

Data classification + change control = a great way to get a handle on global/enterprise data access and contain the spread of cardholder data.  I think this is the congruence with what Rich Mogull says on his Securosis blog.  You do not need to meta-tag ever data element, but there should be some process to classify your data.

More importantly you need a way to alert others who are accessing that sensitive data that they need to (1) contact the regulatory compliance person for that group or (2) take  the necessary action to protect how they are storing it that is in-line with corporate and regulatory requirements.  Setting up an initial classification system is only good until the next change control where someone you never thought would access your cardholder data now can.  It was Michael Cook of Wal-Mart who said, “our perspective is, we are always one chance control event away from being non-compliant.”  This can be taken in many different contexts because it can apply to many different contexts.  Having a solid change control program that is tied into your data classification system is critical.

Popularity: 6% [?]

For those 250+ members who have joined the Society of Payment Security Professionals, you can now purchase SPSP schwag!  That’s right, in addition to listening to podcasts, streaming the SPSP community feed, and taking all the eLearning you can get your hands on — you can now order you SPSP schwag (i.e. hats, tshirts, etc.)

That’s right - if you want to be the pimped payment security pro on the block, then you certainly need a hat and tshirt to show it.  Of course, if you are from the UK you may need your SPSP oxford button-down and three piece suit.  Those will have to be made on demand.

Popularity: 10% [?]

Today the PCI SSC issued a press release about their clarification to PCI DSS Requirements 6.6 (web-application firewall vs. secure code review) and 11.3 (penetration testing).  If you check the supporting documents section of the website you will find the PDFs that the Council released at ETA this year.  The paper copies created immediate conversation in the blogging world, but now they are available online for everyone to read and enjoy.

Requirement 6.6 Code Reviews and Application Firewalls Clarified - Requirement 6.6 was really put in place to address the high level of web-application compromises occurring the in industry.  The wording implies there are two options, but one can imagine any compensating control that protects these Internet facing web-applications from compromise may be sufficient.  The information supplement clarifies each of the two options.

Option 1 - Application Code Review - Properly implemented either of the following would be acceptable:

• Manual review of application source code
• Proper use of automated application source code analyzer (scanning) tools
• Manual web application security vulnerability assessment
• Proper use of automated web application security vulnerability assessment
  (scanning) tools

Option 2 - Application Firewalls - This information supplement defines what a web-application firewall (WAF) is and how it should be implemented and the capabilities it should have or leverage.  Again, I would not read too closely into any one word, but instead understand that such a device should prevent the compromise of cardholder data via the Internet facing web-application.

Requirement 11.3 Penetration Testing - This information supplement provides some important insight into the various aspects on penetration testing, especially the scope.  The scope for such testing is in-line with the scope for the rest of the PCI DSS audit.  We state the scope to be anything that “stores, processes, or transmits cardholder data … or connected systems [that could lead to the compromise of cardholder data]“.  The supplement states the penetration testing scope to be:

The scope of penetration testing is the cardholder data environment and all systems and networks connected to it. If network segmentation is in place such that the cardholder data environment is isolated from other systems, and such segmentation has been verified as part of the PCI DSS assessment, the scope of the penetration test can be limited to the cardholder data environment.

This is rather important because the debate continues over if this implies an Internet only testing or if internal testing is required.  Many people have called for internal penetration testing, and they have a point, but it may not be required.

Remember that penetration testing is a VERIFICATION step and as such anything you can do to verify the internal segmentation is sufficient should be sufficient to preclude the need for internal penetration testing.  Tread lightly.

Popularity: 19% [?]

Only if that city is in Poland.  I’m about to hop on a flight to Warsaw, Poland (check my Dopplr) to teach several classes on PCI.  We normally do about 5-10 global countries a year in addition to the numerous PCI classes we teach in the US.  I’m both excited and exhausted.

I’ve been traveling for many weeks straight and the past two weeks have been back to back conferences (RSA and ETA).  I’m about to embark on a 1.5 week trip and I hope I have everything I need.  While there I plan to make a side trip to Krakow for a day.  I have a friend with relatives there that might be able to give me a tour.

Last week at ETA, the PCI SSC released clarification documents about requirements 6.6 and 11.3.  Keep checking the PCI SSC website for the electronic copies.  I’m excited to see what new things and experiences those implementing PCI in Europe and EMEA have been experiencing.  There will be participants from Western and Eastern Europe, and I’m hoping to share the experiences that other PCI assessors are having all over the world.

One of the great advantage of teaching classes all over is the ability to learn and share information.  Also, since ETA was just last week I’ll be able to share more information about programs and information the PCI SSC has recently released.  I’m very impressed with all the people working so hard to churn out documentation.  I think there is more documentation, FAQs, and clarification papers about PCI than any other standard.

While I’m traveling I’m going to share information about the blog, forum, and the Society of Payment Security Professionals (SPSP), our Podcasts, and much more.

We are always looking to expand the list of people who are blogging so if you have an interest in contributing to PCI Answers, please email me.  We are always looking for subject matter experts (SME) and those wishing to blog in non-English languages.  If you already have a blog and want to get it syndicated then join the SPSP and add it to the payment security blog aggregation feed.

Popularity: 20% [?]

It’s almost midnight and I’m back in my hotel room.  What a long day!  I played “booth babe” and talked with prospective clients at ETA.  Seeing that attendance appears to be down from last year, we had a large group by our booth almost the entire time.  Special thanks to the PCI SSC for having a social hour tonight, and special thanks to Discover for hosting the social mixer at the House of Blues.  Rock on!

But I did take a few short trips to attend the PCI sessions.  In these they provided clarification documents surrounding some areas of the PCI DSS.  These were handed out in paper form and will be available electronically soon.  I’m going to respect the Council’s time line and not post the content until they do so on their site, but it seems nCircle is happy to post all about it.

The answers Jeremiah Grossman’s feedback from earlier in this week.  This is a classic example of why you (1) should not believe everything you read in the papers and (2) should focus on intent and not the literal meaning of the word “code” (or any other minor nuance for that matter.)  Thank goodness they have Trey working to control the spin.

Clear? And don’t forget to read all about “web application” vs “web-facing applications”

Popularity: 22% [?]