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

People complain about many things, but the question is: have you filled out a feedback form?  What, you ask?  There is a feedback form?  Oh yes!  And you should be filling it out and sending it back to the PCI SSC (Council).

Check out the Supporting Documents page on the Council website and make sure you fill out and submit the feedback form to the Council directly.

The feedback form is so merchants and service providers can provide feedback to the Council on what their experience was like.  Did you like your QSA?  Did you like your ASV?  Did you have a positive experience?  They want to hear it all.

If you really want to have an impact on the standard then jump in and become a Participating Organization.  Then you can give your feedback not just on the audit but on the standard itself.

Popularity: 15% [?]

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

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

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

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

Today the PCI SSC added a new standard to the running list of standards and documents it manages (PCI DSS, SAP, SAQ).  We reported this was going to happen back in November of last year.  The Payment Application Data Security Standard (PA-DSS) is now formally a standard that the Council manages.  Check out the press release here.

PA-DSS is the Council-managed program formerly managed by Visa Inc. and known as the Payment Application Best Practices (PABP). The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, other sensitive authentication data or PIN data, and ensure their payment applications support compliance with the PCI DSS. PA-DSS requirements apply to payment applications that are sold, distributed or licensed to third parties. PA-DSS requirements do not apply to in-house payment applications developed by merchants or service providers that are not sold to a third party, but these applications must still be secured in accordance with the PCI DSS.

In addition to the standard itself the Council has also released a frequently asked questions for the PA-DSS.

Will the PCI SSC accept applications that have been previously validated under the existing Visa PABP program?

PCI SSC will recognize PABP validated payment applications and list them with the appropriate PABP version that they were validated against. For payment applications validated against pre-PABP version 1.3, they must undergo a PA-DSS assessment within twelve (12) months after the initial publication of the PCI SSC list otherwise they will expire and will no longer be accepted for new deployments. For payment applications validated against PABP version 1.3, they must undergo a PA-DSS assessment within eighteen (18) months after the initial publication of the PCI SSC list. For payment applications validated against PABP version 1.4, they must undergo a PADSS assessment within twenty-four (24) months after the initial publication of the PCI SSC list. Please refer to the table in the Grandfathering PABP Applications section of the PA-DSS Program Guide for more details.

How will the migration to PA-DSS impact vendors previously validated under PABP? Read the FAQ!

Check out the full FAQ documentation for all the fine details.  I’m happy there is so much infomation being released surrounding every document released by the Council!

Check out all the documents online:

• PA-DSS Security Audit Procedures
• Summary of PABP to PA-DSS Changes
• PABP to PA-DSS Transition
• QSA Validation Requirements - PA-QSA
• Program Guide
• PCI PA-DSS FAQs

Popularity: 25% [?]

I just checked the PCI SSC website and it looks like they have updated their FAQ.  It’s not quite the online searchable database, but one thing at a time people.

They updated the link to point to the real online searchable database.

A few tidbits I learned from this FAQ include:

• A final version of the PA- DSS is expected to be published in the first quarter of 2008.
• PA-QSAs will validate payment applications, and a list of those validated applications will ultimately published by PCI SSC.

Unfortunately, no specific details about the quality assurance program.  I expect the Council is working diligently to review the QSAs and their work for a more uniform message and quality of work.

Update:  Walt is correct, “As for the PA DSS by this quarter, I just want to clarify that this means the Standard will be ready in a few weeks.  We probably can’t expect the list of PA DSS approved apps until 3rd or 4th quarter.“  Until then we would use the PABP list.  Keep checking the PCI SSC and card brand web sites for updates.

Popularity: 33% [?]

The PCI SSC posted a link on their website to the Webinar on “Navigating and Understanding the PCI SSC Self Assessment Questionnaire“.

Free webinar!

Popularity: 24% [?]