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

For some reason, I’ve run into an inordinate number of questions this week regarding vulnerabilities that weren’t addressed directly in the PCI-DSS — or at least only addressed in a cursory fashion. The document that contains many of these gems is one that most may gloss over; the Technical and Operational Requirements for Approved Scanning Vendors.

Some specific entries of note:

On IDS/IPSs:

Under no circumstance should an intrusion detection system/intrusion prevention system (IDS/IPS) be permitted to interfere with the results of a vulnerability assessment.

On unsupported software:

The ASV must report and determine as non-compliant any identified obsolete software (for example, application software or operating systems (OSs) no longer supported by the respective manufacturers.

On CVSS:

Generally, to be considered compliant, a component must not contain any vulnerability that has been assigned a CVSS base score equal to or higher than 4.0.

On web-application vulnerabilities:

The presence of application vulnerabilities on a component that
may lead to SQL injection attacks and cross-site scripting flaws
must result in a non-compliant status for that component

On denial-of-service:

Vulnerabilities or mis-configurations that may lead to DoS should not be taken into consideration by the ASV when determining component compliance

The quarterly perimeter scan is only a small part of PCI compliance, but it’s rife with idiosyncrasies and requirements for all parties involved.

Popularity: 48% [?]

Much like other professions, end-of-quarter is always an interesting time for anyone who works in the PCI space. Working for an ASV allows me purview into a flurry of activity, as a significant number of merchants invariably wait until the last minute to run their compliance scans; not bothering to allow enough time for things like…oh, I don’t know…remediation.

Understandably, the stress-levels run high when merchant X runs their scan, only to find a vulnerability that is particularly complicated to fix (e.g., XSS — well, for most merchants anyway). The natural thing to do? Contest it of course! Never mind the fact that there are more pragmatic and productive options available. I’ve dealt with several individuals who’ve insisted on contesting vulnerabilities for the simple reason that they “just want a clean report“. The most recent of which was when I took an escalation from a large pharmaceutical company.

The problem: The merchant had 2 web-servers that failed to respond consistently to our HTTP tests. This prevented us from accurately/completely evaluating their vulnerability status.

Our contention: As PCI is a compliance standard, failure to effectively evaluate the servers meant that we couldn’t say whether or not the systems were vulnerable. We therefore were unable to certify the servers as being PCI compliant.

Their contention: There were several actually; the most compelling of which was something to the effect of Your scanner can’t find anything wrong with our system!.

The real headache started when I refused to clear them. We needed to find out why the web-servers were inconsistent in their responses so we could get a clean scan. Part of the problem was that they didn’t know why; the other part was that they seemed to lack the technical expertise to investigate the issue. Their solution? Bullying.

They started by becoming rude, they accused me of “intentionally making this more difficult than it is“, they called my intelligence into question (not that my wife doesn’t on occasion, but at least she’s nice about it), they threatened not to renew their license and they demanded to speak with my management. My point isn’t to rant about this particular merchant or complain about the mean people out there in the cold, harsh world. None of this should come as a shock to anyone. It’s simply to point out that some merchants have engaged in this type of behavior, will continue to do so as long as it remains effective, and have doubtlessly succeeded at one time or another, in browbeating some poor support-rep into providing an exception when it wasn’t warranted.

It’s a truism in the infosec space that security is a people problem, and any reasonably robust security policy will address this kind of social engineering. So what will PCI do about it?

Popularity: 34% [?]

A few weeks back I was invited to the Qualys annual conference in San Francisco. Their theme was Software as a Service (SaaS). No sooner had I returned than CIO Magazine has Software as a Service as their cover article. I think they are on to something here, that is bigger than just security or software.

While at the event I had a chance to speak with many on the Qualys team (some of whom I had met just days before in Tokyo.) One of the most interesting characters was Philippe Courtot, the Chairman and CEO. He is a consistent entrepreneur who, aside from being well connected, is well informed about the industry. He is French, a physicist in his prior life, and enjoys extreme skiing as a sport.

He purports that software is moving to a service (or subscription) based economy. For example, take Google with their online service based suite of office tools (word processor, spreadsheet, email, calendar, etc.) We made a bet on Windows Vista being the last operating system that Microsoft makes, with his argument being that all software will move to a service based offering. (Bill, please release another operating system or I loose the bet.)

Qualys has put their company where their mouth is by releasing QualysGuard. One thing you may not know is that Qualys is the approved scan vendor (ASV) of choice for most merchants. Why is this? Because the majority of companies listed on the ASV list actually resell Qualys. This means that Qualys scans a large percentage of all PCI compliant merchants.  This new service offering of theirs delivers another type of SaaS — the Security as a Service.

I’m now wondering how many other companies will follow suit and offer Security as a Service and what other products can be delivered via this method. We already offer this (partially) via managed service companies. These would be your remotely managed IDS and audit log review providers. But managed services are still only partially on-demand security.

The question is: what, when, and how will the security industry move to a service based offering? Is this something we want, need, or could use?

Popularity: 49% [?]

From Dark Reading:

JUNE 27, 2007 | Vulnerability management isn’t just about slapping on the latest patches anymore.

That’s because a vulnerability isn’t always just a publicly identified bug by Microsoft or CERT. “Vulnerabilities can be problems in configurations, missing patches, software that was loaded on a machine that shouldn’t be there, or security mechanisms that are not loaded or up-to-date and should be,” says Eric Maiwald, senior analyst with the Burton Group and author of two vulnerability management reports for Burton, which were published late last week…[more]

Popularity: 27% [?]

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

You’re vulnerable.

Really? Don’t hold back or anything. How can you be so sure?

Because your ASV said so, and if your ASV says so, there’s a 99.999% chance that they’re right. Pretty-much everyone is vulnerable to XSS in one way or another.

Well how do they even test for it?

If they’re a “network” security ASV, then they’re probably just doing a generic “pop-up” test and simply looking at the resulting HTML page for their input to be spit back without being escaped. Not very elegant, but it works. If they’re an “application” security ASV, then their testing is likely a bit more complicated.

Then why can’t I get it to work with my browser? I don’t see a pop-up.

First of all, an attacker isn’t going to make anything pop-up on your screen. A test like that is only used as a proof-of-concept by your ASV. Second, not all browsers are vulnerable. The point of fixing XSS is to protect the end-user. Relying on the end-user to use a non-vulnerable browser is essentially making it incumbent upon them to provide for their own security. While that’s all well-and-good, it’s a bit idealistic. Web-browsers are embedded in all sorts of applications; you can’t just assume that everyone is using the latest version of IE or Firefox.

OK, but XSS isn’t really that important. So a hacker can steal cookies…big deal.

Not so grasshopper. Payloads delivered by XSS are becoming increasingly more malicious: Keylogging…worms…remote control…etc. There are plenty of tools available to demonstrate this.

Got it. So assuming that I wanted to fix it, can my ASV help out a little and tell me how?

Yes and no. They can’t tell you the exact details on how to fix it, because they probably don’t have intimate knowledge of your web-application. As you’re well aware, web-applications can be particularly complex; the XSS vulnerability can be within the web-server, the application server, cgi scripts, the database, etc… All your ASV knows is that they send a particular request to your application and get a response indicating that you’re vulnerable.

So where else can I go to get information on how to fix it?

OWASP is a good place to start; you can also read the upcoming and guru-authored XSS book; or you can even ask a real person. It really just boils down to input validation. Every point within your application that accepts user input — either directly or indirectly — should have mechanisms that filter all input except for that which your application requires. But don’t worry…implementing XSS filters isn’t nearly as difficult as determining where the filters should be implemented.

Popularity: 33% [?]

I’m curious to see if anyone was affected by the 0-day Microsoft vulnerability that was released right before the end-of-quarter.

Did your company wait until the last minute to submit their PCI report to their issuing bank (as many companies tend to do)?

Did you have problems with your ASV or auditor — as there is no official patch available? Here is an unofficial/temporary patch by-the-way.

What compensating controls did you come up with?

How did it ultimately affect your compliance effort?

Popularity: 32% [?]

Compliance standards — PCI included — are intended to foster interest and improvement in data security. While theoretically this seems like a fine idea, in practice the two concepts seem to be continually at odds. The negative deliverable of security means that it’s little more than an afterthought for many organizations. Unfortunately, it also means that with the constant tightening and broadening of PCI standards, compliance-centric merchants are being forced into the information security world; with many experiencing growing pains. Working for a major ASV, I’ve had ample exposure to these realities.

Perhaps the most illustrative — and disturbing — behavior that I’ve seen from compliance-centric merchants, has to do with competitive evaluations between ASVs. Under normal circumstances, the vulnerability assessment that finds the most vulnerabilities with the lowest rate of false-positives or false-negatives would be the clear winner. With compliance however, the win often goes to the path-to-certification that provides the least amount of resistance. The focus of concern is on passing PCI without being fined, over actual security. In one particular evaluation that I had witnessed, ASV#1 missed that SSLv2 was enabled on a number of web-servers in a level-4 merchant’s network, whereas ASV#2 didn’t. Even though the PCI DSS clearly dictates that strong encryption must be used, the fact that there was a false-negative with ASV#1 meant — to the merchant anyway — that PCI certification could be had for far less effort by going with ASV#1 over ASV#2; compliance over security. Though situations like this may not be the norm, they’re certainly prevalent enough. Would the merchant in this case be compliant? The acquiring bank may be fooled into thinking so, but cardholder data wouldn’t be any safer.

PCI isn’t an automatic validation of an organization’s security posture. In-fact, ignoring the intention behind PCI can turn it into a detriment. Compliance is not security.

Popularity: 32% [?]

Max reports that Watchfire has certified as an approved scanning vendor (ASV). Speculation and then confirmation about SPI Dymanics getting into the business.

From their press release:

Watchfire … announced today that its AppScan® product has successfully completed the PCI Security Standards Council Approved Scanning Vendors testing process and is validated as compliant with the Payment Card Industry Data Security Standard (PCI DSS)

Erik from SPI replies saying:

SPI is working to have our WebInspect Direct and assessment services group PCI certified. This is similar to what Watchfire has done but was misleading in their press release with regard to PCI. The PCI group has made it pretty clear that products won’t be certified and they only certify services organizations …

Erik nailed it by saying that “products won’t be certified … they only certify service organizations.”

Popularity: 29% [?]