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

If you build a new deck in your backyard, would you test it out before inviting your friends and family over for a bar-b-que?  Well it turns out that many merchants are documenting compensating controls but not actually testing them to make sure they work.  How could this be?  I’m asking myself the same question.

There is a simple approach to understanding compensating controls that starts with asking the question, “When would I use a compensating control?”  The answer to that is any time that you have a legitimate business or technical reason.  For example, you may have some specialized technology that meets the intent of the requirement but not in the prescribed manner of the Security Audit Procedures (SAP).

Then you should document your findings, so you can show them to people if they ever ask, “what in the world were you thinking?”  This documentation should include those items listed in the Compensating Controls Worksheet.

1. Constraint - the business or technical constraint precluding compliance with the original requirement
2. Objective - the intent of the original control
3. Identified Risk - the risk posed by the lack of the original control
4. Compensating Controls - the controls in place that mitigate the risk to meet the intent that could not be achieved via the constraint

But you cannot stop here!  You actually need to test these compensating controls to make sure they hold up.  It’s not sufficient to say that a company uses RACF security on their Mainframe as a compensating controls for something else if you do not evaluate the security of the RACF configuration.  For each compensating control you must actually TEST it to make sure it is sufficient to mitigate the risk to cardholder data.

As Ronald Regan always said, “Trust, but verify!” (“doveryai, no proveryai”)

Popularity: 18% [?]

One of the more difficult questions to answer about PCI is how to define the scope of a project. This is a topic that does not receive much conversation because it is so very specific to the actual environment. There are things to consider such as:

• Network and operational segmentation
• Type of data stored (i.e. track data vs. just PAN)
• Volume of data stored
• Who has access and how often do they have access
• Format of the data (flat file, database, audio/image file)
• Online vs. offline data stores

As you can see the factors are many, but how deep does an auditor need to look when performing an audit? Here are some factors they may examine:

• Can they sample similar systems?
• Will they rely on third-party reports?
• Do they need to inspect the security of every application?
• Will you need to give them copies of sensitive data for their work papers?
• Who will send the final report to the acquirer or card brand?

Each auditor will vary in how deep they need to go when auditing a company, but most will need to review and examine all settings, configurations, and documents on their own. The reason for this is because they are promising that everything they write in the report is true and accurate at the time of the audit.

This means that a QSA may need to review your system settings even if you had those settings reviewed as part of a different audit several months ago. Also, if the time between the ‘gap analysis’ and the ‘compliance audit’ is very long they may need to update their work papers. This means you will provide them updated copied of the material you gave them previously. The reason for this is to confirm you still have all of the required controls in place.

If you do not want to give them copies of your sensitive data (i.e. firewall rules) they may ask you to sign work papers stating that they reviewed the information and documented any findings. This is an alternative to forking over a large volume of secret information, but comes with the price of filling out large volumes of paperwork.

Sampling is something at the discretion of the auditor, but something that almost everyone does. You need to check with your QSA during the pricing and planning phase to confirm they understand the need for sampling of similar systems. Some companies may price an audit high if they do not know they can sample your similar systems. We could spend another post talking about the details of sampling, but here we will just remind you that it is an option and one you should examine.

Popularity: 36% [?]

PCI is confusing. The requirements themselves are simple enough, and aim to strike a balance between business objectives and prescribing network topology. I have found it a useful guideline at CSO-level, even when engineers find it a little frustrating, and upper management are confused by detail.

What PCI has done well however is not to dictate too precisely, to the point where companies can automatically fail because of their configurations. This is done in the form of “compensating controls”. An example of this reached me today via Martin McKeay’s PCI DSS Yahoo! group. The question was around holding non-encrypted credit card data, and how long it was viable to do it for. Now under strit PCI DSS rules, you shouldn’t do this at all. But compensating controls suggest that if you have issues, such as a mainframe that will not support encryption (as posted by Marting in reply) then there are ways of avoiding the penalties

He then goes on to say: “You cannot put in a series of controls you think are okay and hope it will pass the audit. Compensating controls are something that have to be run through the PCI system on an individual basis. The worst part of that is, what gets an okay for one merchant may not get passed for another simply because of the way your auditor presents it. There’s no standard for compensating controls.”

If there’s confusion over parts of PCI, or you don’t think there’s a way to achieve a part of it in your environment, the chances are there’s a compensating control. Your QSA should be aware of all of these and advise accordingly. Personally I would be wary of any QSA affiliated with or creating their own software/hardware solution to address anything but the audit itself as this will create a bias in the report, but the QSA is there to help.

To get the comments ball rolling, I’d like to know 2 things. Should we be trying to standardise compensating controls in some way? If so, how? And, should QSAs be required to be independent?

OK, that’s 3 things.

Disclaimer: I work for a vendor, but it is in no way associated with Aegenis. I am an associate of Heather’s from a previous job and a friend of Mike’s. I do not sell my wares here, or try to push people towards them in my replies.

Popularity: 38% [?]

If you download the latest QSA list, open it up and do a quick search for “Spain”, you’ll only come up with one name: Daniel Fernandez Bleda of Isecauditors.com, based right here in my home town of Barcelona.

I’d had someone contact me through my personal blog to talk about PCI, he was also based in Barcelona, and needed some pointers. As I am a vendor, I thought it prudent to get an independent expert in to keep his mind at rest. I was in contact with Daniel by email, but had yet to meet in person. He seemed to know what he was talking about, so I invited him in.

So, 5 of us (2 from my company, 2 from Daniel’s, 1 interested consumer) crammed into our offices at 3pm on Thursday afternoon to see what we could arrange. Daniel dealt with the queries as they arose, and very kindly conducted proceedings in English, which was obviously not his preferred method of communication. Still, a lot more natural than me speaking Spanish, so much appreciated. No hablo Espanol.

Backtracking a little, I had contacted Daniel previously to speak about PCI in Spain, thinking he would be inundated with business here, being in his unique position. We wanted to partner with him, being a vendor who might be able to surf the giant PCI wave… apparently this is not the case. Most of Daniel’s business comes from other auditing and compliance work. The QSA status (and soon to be ASV) is there to keep skills up to date and provide a little marketing. He was delighted to have the chance to speak about PCI with a real live opportunity in Barcelona.

The last time I spoke about the lack of interest in PCI in Spain I had someone on this blog (who shall remain nameless because I can’t remember who it was) tell me how they had loads of Spanish work on, but couldn’t tell me anything about them because it would breach NDA. Sorry, but I’m having difficulty believing you now, especially when you can’t provide ANY proof.

I’ve only been here 5 months now, but I’ve picked up PCI customers in the UK and US in that time, and still not a sausage in Spain, not even the scent of chorizo. We even have one of the largest banks in the area trying out our software, and the only PCI account I’ve even heard of over here is an international company getting pressure from their German processors. Caixa Catalunya passed on the pressure, but they aren’t interested for themselves in terms of PCI.

If there’s anyone more qualified to talk about PCI in Spain than Daniel, please let me know. I’d love to hear that I’ve completely missed a rich seam of business opportunity buried deep below the cracked surface of Spanish IT security.

I’m also interested to get more of an overview purely for personal reasons, otherwise I’m going nuts here.

Popularity: 41% [?]

(Please also read: Meet your auditor, Part 1 and Meet your auditor, Part 2)

I read comments like this many times where one QSA says the others are not doing as good a job. There is a quote from an article stating:

But merchants and security auditors criticize PCI DSS for constantly changing its standards and for its ambiguity to unique technology environments. For example, a security lapse flagged by one auditor may not be considered an issue by another.

I don’t believe that any standard can guarantee that all assessors will always interpret the standard and map it exactly the same way to every client environment. This problem of differences in interpretation vary much more for HIPAA and GLBA than they do for PCI, but they go unnoticed because these other compliance requirements do not have as structured an audit program.

The PCI SSC requires that all qualified security assessors (QSA) attend a training class and pass an exam. This means that the assessors have met some minimum level of education and understanding of the PCI DSS. Again, no other compliance program offers such a structured education platform.

I’ve heard the argument that a company may choose one QSA over another because one is easier on the audit. But these variations exist not just between companies but between employees within a company also. You know that even if you hire a Big 4 CPA company you might get someone straight out of college to whom you are their first client ever. You just never know.

I also don’t like this argument because if one QSA company is stricter than another they will most likely better understand the standard (as a whole, and the concepts of compensating controls) thus making it easier for a company to pass the audit. These variances are both a positive and a negative.

Now, if a QSA is concerned that they lost a job because the time or cost they quoted on an RFP, this is just ridiculous. It’s well known that companies may sell the audit at a loss in hopes of getting hired to perform the highly lucrative implementation and remediation services. You cannot simply compare these things against each other.

Popularity: 31% [?]

I’ve been having this conversation with several of the Security Bloggers Network people and have come to a few conclusions. I would like to address some common misconceptions and address the PCI DSS compliance myths.

Myth 1: PCI compliance has no teeth

Read the “multiples” of PCI non-compliance. (It required it’s own post.)

Myth 2: There is no real enforcement of PCI

One might have reason to state this. If you know the history of PCI then you will remember that merchants were required to comply by September 30, 2004. Wow, 2.5 years later and not everyone is compliant? You may recall this is the way all compliance programs work.

GLBA (Financial Modernization Act of 1999) was made a requirement, but took several years to bring the majority of financial institutions into compliance. To date many merchants are working on complying with PCI DSS and most have PCI PIN compliant devices/systems.

In 2007, and starting the PCI month of awareness, Visa’s Compliance Acceleration Program (CAP) will proactively fine merchants that do not comply. How does $100,000 per month sound?

Not enough carrot? Visa USA has eluded to the fact that compliant merchants may receive lower interchange rates. THAT will have a noticeable impact on the bottom line of all large merchants.

Myth 3: Too much ambiguity to PCI compliance

This I will admit is correct. But there are ways to correct this.

• The PCI SSC trains all QSAs on the intent and meaning of each requirement.
• PCI training is available for merchants and service providers
• This blog and its experts answer *every* question that is sent to our email and voice mail (on the top of every page)
• The card associations have web sites and email assresses to ask questions
• There are community forums for discussing PCI with your peers

I just don’t know what other tools one needs to become the most well versed person on PCI.

Myth 4: Credit cards theft is identity theft

One of my great frustrations is when credit card issuers market their products as having “identity theft” protection. If someone steals your social security number they can open multiple lines of credit in your name and it is a very painful process to reverse. If someone steals your credit card number you are not liable for any of the fraudulent transactions, and all it takes to fix is have your bank send you a new card.

The information is not the same and so their theft should be treated differently. Chronicles of Dissent has more on this conversation.

Myth 5: PCI auditors are not independent

I was surprised to hear this argument printed in eWeek. (I wish Evan Schuman would call us next time he has a PCI related article. Evan contacted us and we will engage such media sources more directly with feedback in the future.)

The fact that the auditors in questions are paid by—and are given instructions by—the retailers being audited is the most textbook conflict-of-interest I’ve seen in quite some time.

The fact of the matter is that a PCI auditor must be both an advocate for their customer and an enforcer (and interpreter) of the PCI requirements. If you say that auditors all lack independence because they are paid by their customers then where do you stop? Is SOX auditing all crap because the government doesn’t perform it? When you pay an inspector to examine your house for structural risks, do they lack independence because they want to make you happy with a clean report?

If you want precedent for why a QSA should perform high quality work just look to the CSSI compromise. This was a service provider that was listed as compliant and then hacked - turning into the biggest compromise of the time. Did anyone notice that one of the QSAs was removed from the closed list of assessors? Coincidence?

The argument for lack of independence holds no water. What I think Evan meant to say is that some companies provide both the security solutions and the compliance audit. This is really what toes the line of independence. I mean, how can one company both install the firewall or IDS and then audit the products they installed?

(Thanks to Alex for highlighting some of the concerns felt by the community. Also, read Martin’s take on the issue.)

Popularity: 33% [?]

Each country and geographic region has its own set of quirks and idiosyncrasies. In San Francisco we don’t like it when people say “Frisco” or “San Fran”. In New York City when you ask for a hot dog with “everything on it” you had better be ready for some spicy new tastes. It works the same way for PCI compliance validation.

Although PCI is a global standard, the enforcement of it is left to the individual card brands. For MasterCard and American Express it means all acquirers, merchants, and service providers must perform the same set of validation procedures globally. But Visa, until the IPO, is divided into six regions. This means there are (slightly) different ways of implementing and enforcing the PCI standard across the different Visa regions.

This article focuses on merchant validation procedures and how they differ between regions. The first important difference is that the CISP permits Level 1 merchants the option of hiring a Qualified Security Assessor (QSA) to validate their compliance or to utilize their own internal audit team, so long as the report is signed off by an officer of the corporation. This is not the case for Visa Canada.

With the Canadian region all merchants (Level 1-4) must use a QSA to validate their compliance (as outlined by the helpful Moneris chart). The question is what does the QSA need to do in order to validate the merchant has complied with the PCI requirements?

In the case of Level 1 merchants the QSA must perform an “annual on-site PCI Data Security Assessment”. This is in-line with how other regions must comply. The process changes for Level 2-4 merchants. For these merchants they must complete:

• Self-assessment questionnaire (SAQ), and
• Quarterly network scans from an approved scan vendor (ASV)

These validation procedures must be reviewed by a QSA before submission to an acquiring bank. The QSA is not attesting to the validity of the SAQ or ASV, but simply performing a sanity check and offloading some liability from the acquiring banks.

Of course, the first thing merchants ask is, “what is the cost of something like this?”  QSA validation services will differ from one QSA to another and vary depending on the size and complexity of the merchant.  A Level 2 merchant could be much more complex than a Level 4 merchant.  Also, one merchant may be looking for just the validation check while others want consulting assistance.

The best advice is to requrest multiple quotes from the different QSAs approved to validate reports in Canada (look under ‘Servicing Markets’ for ‘Canada’) and choose the best one for you.  Do not let them over sell you on services.

Popularity: 24% [?]

Max asks:

From the literature i’ve consulted, it seems that the only actions i need to do if i am a level 2 merchant is fill out and submit my self-assessment and my network scan report. However, we have a consulting firm that is telling us that we must first “validate” the questionnaire with them (and of course, this costs in the 6 digits).

Can you confirm or infirm this? I don’t really see anywhere in the VISA or PCI documents that I require to have anyone else “validate” my questionnaire.

You are correct in that Level 2 Merchants (in the US) are only required to submit to their acquiring bank the Self-Assessment Questionnaire (SAQ) and a clean scan from their Approved Scan Vendor (ASV).

That is it. You are not required to hire anyone.

That being said, the SAQ can be difficult for some smaller merchants to validate and it is helpful to hire a Qualified Security Assessor (QSA) to help with this process. It is important to know that the SAQ is a shortened version of the Security Audit Procedures (SAP), which is a great place to find answers to your questions of what a particular requirement means.

THAT being said, I would never pay 6 figures to a QSA to assist a Level 2 merchant fill out their SAQ. That is just way too high to provide some simple consulting skills.

You can find all these forms and more informaiton on the PCI Security Standards Council website. And please post these questions or look for answers in the PCI forum forum.pcianswers.com.

Popularity: 19% [?]

I want to thank Ed at SecurityCurve for posting a clarification on his concerns about PCI. I think his statements are true and something to be discussed. The question is always posed, “Is PCI too detailed or not enough?“PCI is too detailed

Many people claim that PCI is too prescriptive in that it says specifically what actions must be done for security. Ed points out:

For example, PCI says that companies need to have a firewall. And they say that you have have to have anti-virus software, application-level firewall software (new version), etc. It’s up to the assessor to interpret if they have done it and if it is done appropriately.

This is true, and there is not much I can say to help ease the pain of prescription other than to say that, if it was vague people would almost always interpret it to mean the least amount of security. These requirements have the unfortunate role of applying to all companies across the board, large and medium sized.

I wonder if it is easier to pass an ISO 27001 audit or a PCI audit? I don’t know much about the ISO 27001 compliance audit but I’d imagine it would be tough. This is because it’s based on the ISO 17799 which is generally issued as a recommendation, due to the fact that it is not a certification.

From the card associations perspective, they want to: secure data, reduce compromises, increase consumer confidence, and prevent government intervention. How is this best accomplished? Are there changes to the PCI DSS requirements that would make things easier? Maybe a manual that was issued alongside the requirements? I think they need feedback on this issue, because they cannot secure the industry alone, so they look to the security assessors to use their judgement on many issues.

PCI is not detailed enough

People say the opposite is true as well, because of legal reasons rather than technical ones. One of the most common items people ask about is requirements 11.2 and 11.3. These two require (a) vulnerability scanning and (b) penetration testing respectively, but more people ask about them than any other. The question people ask, “How do you define a penetration test?”

Now everyone who asks this question knows what a penetration test is but they ask it because everyone has a slightly different perspective on what a penetration test includes. Does it include war-dialing, social engineering, or dumpster diving? Does it include physical or only electronic testing?

Instead of asking for more detail people should be focused on the intent of the requirements, “Secure Credit Card Data”. If the penetration test shows that credit card data is secured then you are meeting the requirements. If you want to know if a certain firewall configuration is acceptable, then ask yourself, “does it secure the credit card data?”

It is important to understand the goal of PCI and that compensating controls can be leveraged based on your expertise and understanding of the environment. Once people understand this they find the PCI requirements to be more flexible than ever before.

Popularity: 26% [?]