The QSA Conundrum
July 13th, 2009 by cmark Posted in PCI DSSRecently we have been hearing reports of QSAs requiring merchants and service providers to implement controls that are not required by the PCI DSS. One example that was passed on to our company by a merchant is that their QSA is requiring scanning desktops that are not in the Cardholder Data Environment. The scanning is intended to find Cardholder Data and sensitive authentication data that may be present. If true, this demonstrates a troubling trend within the industry.
?When we were training QSAs, we used to call this ‘inventing requirements through implication’. It basically works like this. Mr. or Mrs. QSA is reviewing a company’s environment and says: “although the PCI DSS does not say you have to do X, it does say that you have to do Y, and I don’t believe you can do X sufficiently without Y, therefore X is a requirement.” While there is always a temptation to create requirements through implication it is often just the work of a technically adept, and overzealous QSA that has no malicious intent.
?The feedback the Society of Payment Security Professionals is receiving shows an even more disturbing trend. When merchants are asking the QSAs about the ‘new requirements’ the response appears somewhat universal. They are being told by their QSAs that the PCI SSC is requiring such strict QA and there is so much liability that the QSAs are airing on the side of caution to try to limit their exposure.
It is difficult to argue with such a position. Many of the QSAs within the market make a lion’s share of their revenue from PCI related work. Losing their ability to conduct assessments could have the very real impact of putting quickly out of business. From a risk management perspective it simply makes more sense to be too thorough than risk not being thorough enough. As a business owner I can understand this position.
A couple of months ago a large bank filed suit on a company that was a former QSA alleging that they (the QSA) was negligent when they assessed a processor in 2003 that was subsequently compromised in 2005. We are seeing a number of lawsuits being filed against other QSAs for negligence when in fact, it is more often than not the fault of the company that experienced the data compromise.
QSAs are hired to validate compliance against a standard. As they are security professionals and as such would likely be expected to provide advice if they saw something that was posing a risk whether is was a PCI requirement, or not. That being said, a QSA validating compliance is not the same as a company having a security or risk assessment. Companies can be fully compliant and still be exposed to risk of compromise. The risk is certainly reduced as the PCI DSS amounts to good information security practices but it is ridiculous to blame every compromise on the failings of a QSA.
It is important when hiring QSAs to understand their role as well as their limitations. As merchants, service providers, and other organizations that store, transmit, and process cardholder data, it is you, not the QSA that has responsibility to ensure the data is protected. Your QSA is often in a position of providing advice and guidance but they cannot force you to comply with the standard and they cannot ensure your systems stay secure. In the same vein, we need to be careful about pointing the finger at the QSA that is unlucky enough to have a client have a compromise until we understand the facts. I have been guilty of this and I am sure others have been, as well.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
21 Responses to “The QSA Conundrum”
By Anton Chuvakin on Jul 14, 2009
“The scanning is intended to find Cardholder Data ”
Eh…. would those systems be in-scope if data is found?
By jplee3 on Jul 15, 2009
Question about this as I’m a bit conflicted between both sides - our consultant advised us, at one point, to use DLP software (i.e. Vericept, Vontu, etc) to “scan” and monitor for CHD. His reasoning wasn’t that it was a “requirement” in the PCI DSS, but more so along the lines of this:
“If you know 100% exactly where ALL your CHD exists, then no need to scan. But, if you can’t answer to where ALL of your CHD exists, then you should really be scanning your environment for CHD using these tools…”
So, I’m wondering then (and perhaps Anton was getting at this…?), what about the CHD we don’t “know” about?
By kilauea on Jul 15, 2009
jplee - security is never a 100% maintained state anyway. Yes, there may be bits of CHD in corners of your network. So you remain vigilant, you monitor and constantly improve. You don’t go out and make a huge investment because it makes a QSA’s job easier.
PCI compliance is been driven far too much by vendors right now. And not enough good security practice.
By jplee3 on Jul 15, 2009
Right… I figure there’s at least got to be less expensive ways to do the same type of “scanning” and “monitoring” without spending hundreds of thousands of dollars (aka: use Snort and opensource tools like CCSearch, Spider, etc). But using those tools in an enterprise situation can be really tricky due to system/network limitations.
Unfortunately, usually the people who will listen to anything the QSAs say without scrutinizing are the often ones ‘in charge’ of driving PCI. Politics stink.
By kilauea on Jul 15, 2009
Your right of course. And far too many orgs put a lot more faith in the word of external consultants than they do their own staff. Something I am coming to terms with having left consultancy to take a full-time ISM role.
For me, strong policy, continued awareness and a competent audit function beat data discovery tools every time.
By Anton Chuvakin on Jul 15, 2009
And, there is always that famous case where QSA charged more for NOT buying a solution: http://chuvakin.blogspot.com/2007/08/is-your-pci-auditor-scammer.html
By Kevin Rowney on Jul 21, 2009
We’re one of those DLP vendors (i founded Vontu) and before you start throwing rocks…please listen. We do scans for CHD in environments that are PCI certified and just about every time we do, we find _massive_ amounts of exposure.
From this perspective, its hard to claim that the current audit procedures are that much in line with very real unaddressed risks.
So it’s clear: there’s hard forensic evidence that exactly this type of exposed CHD is the underlying cause behind numerous large scale breaches. From that perspective, doesn’t the industry have to change to acknowledge these risks?
Kevin
By cmark on Jul 22, 2009
Kevin, thanks for your comments. You state in your comments that when you scan environments you find exposure. I am guessing the exposure comes from your finding cardholder data. Companies are allowed to retain cardholder data and even authentication data (pre authorization). The issue is not whether companies do or do not have such data. The blog post was referring to the increased scrutiny (and creation of non-existent requirements) being applied due to the QSAs being in a very difficult position. We are seeing an increase in requirements through implication. The challenge becomes that if a company is in violation of the card brand rules and the QSA is not lucky or savvy enough to catch the company then the QSAs are being held to account in the event of a compromise. This, I think is troubling. I do agree with your statement however. There needs to be some changes within the industry and to the programs.
By Anton Chuvakin on Jul 22, 2009
Well, in defense of over-diligent QSAs and Kevin, if QSA suggests a tool that helps find prohibited data and thus the scope of PCI validation increases [with all the correspodning hatred from the merchant in question :-(], isn’t it a good thing for security?
By Kevin Rowney on Jul 22, 2009
@cmark
Yes, our scans nearly 100% of the time find mass exposure of cardholder data out on file shares with no access control protection and no encryption. Although these systems are often deemed “out of scope” of a PCI audit, they are a primary target of hacker activity.
What’s the best way for the DLP vendors to collaborate with QSAs and retailers on this front. From what we can see, this problem of PAN exposure from the action of well-meaning insiders represents a very significant risk. Its a risk we’ve seen for years and we seem to be having trouble getting the QSAs to notice.
Kevin
By cmark on Jul 22, 2009
I am a big proponent of DLP type technologies. In fact, I have recommended Vontu to my own clients over the years. The challenge is with the standard, and the expectations of the QSAs. While called qualified Security assessors (small caps for emphasis) in truth they are to validate compliance. As many likely agree, compliance is not the same as security. The challenge we have in the industry today (one of the challenges) is that QSAs are now being expected to not only validate compliance but to also make statements about a company’ security posture in general. This is problematic. If the QSAs are expected to scan all systems for cardholder data, then that is fine. It should be written into the standard and the QSAs should be trained. Currently the environment creates a moving target with an increasingly high bar for merchants and service providers to jump over. There is increasing liability on the QSAs part and this creates a situation in which the QSAs are asking for controls that are not in the standard.
My post was not intended to be a debate on the efficacy of the standard or security in general. The topic was intended to demonstrate some of the challenges related to the QSAs having increasing amounts of liability for situations that are not in their control.
For quite a few years I, and a number of others, have been pushing DLP type scanning for merchants. As you can imagine, this creates other issues. Consider the example of an acquirer that gets a report of their merchant storing magnetic stripe data today. According to the card brand rules, this can result in a fine of $25K per month until this is addressed. If I were an acquirer I might consider ignorance as bliss in this situation.
By cmark on Jul 22, 2009
Anton, I am defending the QSAs. Your statement says “suggest”. I have heard of clients that are being “forced” to scan for data on systems that are out of scope. Additionally, there are a lot of measures that are much better for security than the PCI in general. A QSAs job is to validate compliance against a standard and not to make a determination or statement on the security posture of a company. As professionals they should make suggestions that increase their client’ security but as long as the client is in compliance the QSA’s opinion on their security is secondary. We have a consistently moving target within our industry and it is largely due to the varying degrees of subjectivity applied to the standard.
By Anton Chuvakin on Jul 22, 2009
>being “forced” to scan for data on systems
>that are out of scope
‘FORCED’ sounds kinda bad, actually. Maybe it is indeed the case where “QSA shopping” is appropriate.
Maybe this QSA forgot that the ultimate responsibility is with the merchant; if merchant wants to pretend they don’t have those CVV2s stashed on laptops in Excel sheets, it is their call (and their loss, of course!)
By Kevin Rowney on Jul 22, 2009
> Maybe this QSA forgot that the ultimate
> responsibility is with the merchant
Granted, QSAs don’t want to be thrown under the bus on liability and merchants don’t want to pay for more security software; but what are we going to do to get these risks under control?
Seriously.
This is a big open gap on risks of breach. We’re willing to collaborate in many different ways. As an industry we can’t just stand by and let this problem continue on.
All of the hoopla around wifi access points and encryption means virtually nothing compared to the vast extent of cleartext exposure of CHD out on the LAN. Don’t mean to sound breathless here, its just a clear and obvious gap that can be closed.
Kevin
By Kevin Rowney on Jul 23, 2009
Kilauea-
So I know I am vulnerable to the FUD accusation (because I work for a vendor) so am not sure how to convince you I am genuinely interested in the debate about risk management (instead of just marketing spin.)
I’ll try.
We see consistent evidence that this exposed data is in fact a primary target. We have on staff numerous people who have been involved directly with the forensic investigations on some of the highest profile breaches out there. This theme of hackers targeting data exposed by well meaning insiders is - at least anecdotally - a very common outcome.
Additionally, the Verizon Data Breach Investigations report (pg. 34) clearly documents that data exposed on systems unknown to the security team was implicated in over 66% of the breached records.
Seems like that’s pretty hard evidence and lines up with what we see.
Kevin
By Kevin Rowney on Jul 23, 2009
@kilauea et al-
Honestly do want to have this debate…if you have refuting evidence, am very open to hearing it.
K
By kilauea on Jul 23, 2009
Kevin, I appreciate you have a hard job convincing the sceptical. The problem the security industry has, is that is has been using fud for far too long to sell its wares.
Even the evidence you give here, is partly anecdotal and partly from a survey written by a security vendor. The only other surveys I can think of (Ponemons springs to mind), are all gathered or sponsored by security vendors. We need independent figures.
I know you can see how this looks. Another issue we have is the disparity between the US and the UK. There just isn’t the same number of card data breaches here. Our biggest to date was a government department a few years ago who lost 52,000 records.
So when US stats are quoted over here they just are not meaningful. We have a smaller population. We have chip and pin. We have had data protection laws for years. Our businesses were relatively slow on accepting card payments - we had a supermarket chain that took cash only up until a few years ago. Most (the vast majority) of our retailers use outsourced payment services.
We do have issues with data being “lost”. As in unencrypted disks being posted or misplaced. But outside of that you can count our card “thefts by hacking” on one hand. And the records involved are in the thousands (combined), not millions.
It’s a different country with different problems. But we are being fed the same FUD and the solutions.
By jplee3 on Jul 23, 2009
Overall, I think hackers have thought through these very issues and are probably reading this thread as we are this very moment. It’s not unforeseeable that they will be hunting for ‘treasure troves’ on any network they can gain access to regardless of whether or not that data is in a flat file or in a database. Whatever they deem as a “low-hanging fruit” they’re gonna go for. I do believe DLP products can help out a lot in the end with identifying places on your network where you may not have known CHD exists. Especially if it’s within the context of a company that may have hundreds to thousands of servers or workstations where it would be impossible to scrutinize by hand or memory. What it gets down to is how effectively you can (with or without “DLP” tools) scan, or monitor your network for CHD treasure troves. I would tend to agree that if you had a breach and claim you didn’t know the data existed where it was stolen, you will still be held responsible.
By Kevin Rowney on Jul 23, 2009
@kilauea:
Agreed, the nature of breach is different over there. Patterns of CHD exposure are different with chip&pin, but I think the point still stands that data exposed by well meaning insiders is data at risk. Breach reports from UK MOD seem to back me on this, no? Perhaps its time for PCI to acknowledge the differences between US payment card infrastructure and other parts of the world…
@jplee3
Yes, its likely hackers read this thread. I guess its “Kerckhoffs’ Law”: if you rely on your adversary to be ignorant of your defenses, they can’t actually be that strong. I think hardened primary systems combined with disciplined hunt for renegade copies of CHD outside the primary systems is a great defense. A defense that would withstand attack even if the attacker knew the setup.
K
By kilauea on Jul 23, 2009
@Kevin:
I agree it is well meaning insiders losing our data. But it tends to be when that data is moved from one system to another using optical or removable media.
Policy, process, education and awareness are the best controls to prevent this. As detailed in the Poynter report from the HMRC data loss.
By Kevin Rowney on Jul 23, 2009
For sake of other readers, would like to wrap up the debate or take it off line. Switch to email?
FWIW — We *do* have hard data on the effect of classroom format security education. Our results indicate employees show zero measurable change - in terms of their treatment of sensitive data - after completion of class.
Feel free to take the last word.
K