Quantcast StorefrontBacktalk » Blog Archive » PCI and Fraud Analysis: To Have and Have Not
advertisement
advertisement

PCI and Fraud Analysis: To Have and Have Not

Written by David Taylor
May 26th, 2009
Like this story? Share it
To share this story with people in your social network, please click on the network icons below.

GuestView Columnist David Taylor is the Founder of the PCI Knowledge Base, Research Director of the PCI Alliance and a former E-Commerce and Security analyst with Gartner.

As merchants work to reduce the scope of PCI compliance and the risk due to having credit card data in their environment, some companies are actually taking access to this data away from people who need it to do their job, including the managers who are charged with investigating fraudulent credit card transactions. Instead of PCI controls helping reduce fraud, for some companies, they are making fraud detection more difficult.

We all know that PCI compliance creates dividing lines. Flat networks must be segmented. The number of databases that store—and applications that use—cardholder data needs to be reduced and the number of persons with full card number access needs to be reduced as well. The whole process of separating the “haves” from the “have nots” often leads to arguments and requires extensive justification on the part of those who maintain they must have the ability to see unencrypted card data in order to do their job.

  • Marketing – “Have Not”
    This seems obvious: Why should marketing have access to full, unencrypted credit card data? Yet it still provokes arguments. Not because of the people or policies, but simply because of the applications and the costs of changing them. Two years ago, we talked to merchants who were able to get away with this, using compensating controls that reduced data volumes, logged each access, and restricted access to batches of transactions, etc.

    Today, however, that sort of explanation will not fly with an assessor or processor who reviews an assessment. Although card data is still described by merchants we speak with as being “all over the place,” this is one department that is definitely a “have not.”

  • Loss Prevention – “Have Not,” in Most Cases
    Loss Prevention is a more tricky call. Some LP departments are also responsible for E-Commerce LP (i.e., fraud analysis) as well as physical security, so they do have “caseloads” that include verifying specific transactions with banks. This may be a manual process that is the “back end” to the fraud analytics group, which are the folks who use the automated tools.

    In other cases, the fraud management organization is completely separate from LP. In such cases, LP can probably get away with having “only” the cardholder name, plus the first 6 and last 4 digits of the card number. This will be sufficient for most purposes, especially when the investigation is manual and they’re talking about a specific case with a bank.


  • advertisement

    Leave a Reply

    Newsletter

    Quickly catch-up on the latest in E-Commerce and Retail Tech with our free weekly newsletter, with urgent bulletins as news merits.
    advertisement

    Most Recent Comments

    Kill All The Passwords

    This article does mention, but does not give enough attention to, the fact that the attacks discussed are only feasible when the encrypted password file can be copied and subjected to an offline attack. The trick is to have authentication performed on a separate, much more strongly secured host - such as an Active Directory Domain Controller, or a Kerberos server, or a NIS+ server, or even using something as banal as an LDAP-over-SSL authentication dialog. In these environments, the odds of the "password file" being stolen and subjected to an offline attack go to near zero, and only online attacks may be carried out by the attacker. With sensible exponential backoff between failed password attempts, lockout after a modest number of failed attempts on a single account, and pattern detection, that minimum 7 character password is quite secure enough. Passwords aren't dead yet for security purposes, and they will be with us for a very long while to come for practical purposes. The trick is to employ them correctly. Read more...
    The possibilities you describe are years away from being implemented at best, so for the moment passwords are an ugly reality. Luckily, password managers can easily manage hundreds of passwords of any length. The only thing a user needs to remember is the master password. It seems like an easier task to educate users on how to use password managers rather than implement complex security technology on a global basis. Read more...