On Scope Shrinkage in PCI DSS

Wednesday, October 20, 2010

Anton Chuvakin

Ebb72d4bfba370aecb29bc7519c9dac2

This was written as a guest post for Branden Williams blog (my co-author for the “PCI Compliance” book) – it is reposted here for posterity.

People who came to PCI DSS assessments and related services (such as compliance gap analysis and even implementation of PCI controls) from doing pure information security often view PCI scope reduction as “a cheap trick” aimed at making PCI DSS compliance undeservedly easier.

They only think of scope reduction as of limiting the area where PCI DSS security controls apply - with negligence, supposedly, reigning supreme outside of that sacred area.

However, PCI DSS scope shrink is not just a cop out aimed at not protecting the data. It is not just “PCI project cost reduction” measure.

Some half-witted analysts propagate this view by saying things like “by reducing the scope, these enterprises can dramatically lower the cost and anxiety of PCI DSS compliance and significantly increase the chance of audit success” [eh… for starters, PCI on-site assessment is not an audit, stop calling it that!]

Well, you will get that – but it is not the point of scope reduction at all.

In reality, efforts to reduce the area of PCI DSS applicability – scope reduction – are one of the most effective ways to reduce the risk of cardholder data theft.

Like we say in our PCI book (Chapter 5, “Protecting Cardholder Data”):

Before we even start our discussion of data protection methods, we need to remind you that “the only good data is dead data.” Humor aside, dropping, deleting, not storing and otherwise not touching the data is the best single trick to make your PCI DSS compliance easier as well as to make the transaction less risky, reduce your liability, chance of fines and breach notification losses.

If you’d like, think of scope reduction as one of the manifestation of the “least privilege” principle – or least data needed to do business principle. You stop the spread of card data and thus become a more compact, harder to hit target.

Along the same line, tokenization, data vaults, virtual terminals, hashing, network segmentation, transient PAN storage all reduce scope and reduce risk – at the same time.

These are the things that make PCI compliance easier WHILE reducing the risk of damaging compromise.

So, reduce scope by changing business process – it will bring more security benefits than THAT FIREWALL you deploy.

And remember that fable about somebody asking a QSA firm that was planning to accept payment cards as payment for PI assessments (oh irony!) – how would they do it?:

“What?! Of course we’d outsource it! We won’t touch that toxic [card data] frak.”

Cross-posted from Security Warrior

Possibly Related Articles:
9923
PCI DSS
PCI PCI DSS
Post Rating I Like this!
C787d4daae33f0e155e00c614f07b0ee
Robb Reck I certainly agree with your point, that reducing the footprint of the sensitive data in your network is a good thing. The problem is one of communication.
If you say: "We want to reduce the amount of sensitive data we house, thereby reducing our risk, costs and overhead." I (and most other InfoSec types, I would wager) would applaud you and encourage the behavior.

But if you say, "I want to reduce what we consider 'in scope' for our PCI assessment." my eyebrows immediately go up. It sounds like a sneaky way of getting around the rules.

I think it comes down to where you put your focus. In the first statement, your focus is obviously on the data and infrastructure, and architecting it in the wisest way. In the second statement you are focusing on the assessment, and seem to be attempting to find a way around it.

Just my two cents.
1287604349
Ebb72d4bfba370aecb29bc7519c9dac2
Anton Chuvakin Thanks a lot for your insightful comment. You are absolutely right - the line is somewhat fine and to me the above two lines will sound exactly like to you: one is legit and the other is shady (at best)

If you are a QSA, you must be a good QSA :-)
1287615334
E68c72e1e8be98215f1fa5155236f5c6
Anthonie Ruighaver Good article. Yes, identifying information flows and changing business process to minimize the risks of these information flows is one of the most cost-effective ways to improve security. And not only in PCI DSS either.
1287633864
Ebb72d4bfba370aecb29bc7519c9dac2
Anton Chuvakin Thanks for the comment. Indeed, people often rush to encrypt, while maybe "remove" is the right answer...
1287674458
298f587406c914fad5373bb689300433
Lynn Wheeler slight x-over from discussion in financial crime, risk, fraud and security (linkedin) group ... note that PCI can be viewed as one of the responses to the (originally cal. more than decade ago) data breach notification legislation. we were tangentially involved having been brought in to help wordsmith the electronic signature legislation ... and some of the parties were heavily involved in privacy issues. they had done detailed citizen surveys and identified identity theft as the NO.1 issue with major type being "account fraud" as a result of data breaches. There seemed to be nothing being done about the problem (especially since the leakage of data wasn't a threat to the operations holding the data ... but to the corresponding account holders). There seemed to be some hope that the publicity from the notifications might motivate institutions to take countermeasures.


re:
http://www.garlic.com/~lynn/2010o.html#8 PCI: Smaller Merchants Threatened

PCI: Smaller Merchants Threatened
http://www.bankinfosecurity.com/articles.php?art_id=3019

i.e.

from above:

The Payment Card Industry's Security Standards Council may be doing a good job helping lock down larger retailers, but the smaller "Mom and Pop" merchants are becoming the new targets of cyber criminals, says a PCI expert.

... snip ...

This somewhat highlights the "security proportional to risk" metaphor ... possibly more easily seen with smaller merchants w/o the scaleup issues. Basically the value to the merchant of the transaction/cardholder information is the profit from the transaction ... possibly a few dollars (or in the case of a processor, a few cents). The value of the same information to the crook is the account balance or credit limit ... as a result, a crook may be able to outspend attacking the system by a factor of 100 times what the merchant/processor can afford to spend defending the system (including things like "buying" insiders).

The real solution is to slightly tweak the paradigm and eliminate information leakage as a risk/threat/vulnerability. Part of this is the dual-use scenario ... the same information that attempts are being made to prevent leakage, ideally by keeping it completely confidential and never divulged, is also information that is required in dozens of business processes at millions of locations around the world
1287679585
298f587406c914fad5373bb689300433
Lynn Wheeler for some additional background ... we had been brought in as consults to a small client/server startup that wanted to do payment transactions on their server. They had also invented this technology they called "SSL", that they wanted to use. The result is now frequently called "electronic commerce".

Somewhat as a result, in the mid-90s we were asked to participate in the x9a10 financial standard working group (which had been given the requirement to preserve the integrity of the financial infrastructure for *ALL* retail payments). Part of the effort involved detailed end-to-end threat & vulnerability studies of the different retail payment products, different kinds of retail payments, different modes of retail payments (debit, credit, stored value, gift card, ACH, POS, face-to-face, unattended, internet, wireless, contact, contactless, high-value, low-value, transit turnstyle ... aka *ALL*). The result was the x9.59 financial transaction standard.

X9.59 did nothing about preventing data leakage ... it just slightly tweaked the paradigm so there was no longer a threat from such leakage. Now the major use of SSL in the world today is this earlier thing we did for "electronic commerce" ... used to hide transaction detail. X9.59 eliminated that need to hide transaction information and so also eliminates the major use of SSL in the world.
1287680126
298f587406c914fad5373bb689300433
Lynn Wheeler ... aka most entities are motivated to take security and/or countermeasures when the risk/threat is to the them.

the card/transaction information leakage is threat to the card holder (not the entity holding the data) ... and prior to breach notification legislation there was little motivation for those entities to do anything.
1287681653
298f587406c914fad5373bb689300433
Lynn Wheeler another metaphor regarding the current environment is "misaligned business process" (this was used repeatedly in the fall2008 congressional hearings into the current financial mess to describe the pivotal roll played by the rating agencies). The cardholder/transaction information is at risk to the cardholder ... who has no control regarding the security provisions. At least before the cal. state data breach notification legislation, the merchants & processors had nothing at risk if the information leaked. The approach taking in x9.59 financial transaction standard was to eliminate the risk (to the cardholder) from such information leakage (eliminating the mis-aligned business process)
1287840314
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.