advertisement
advertisement

This is page 2 of:

PCI Compliance: An Updated Version Of The Newlywed Game

July 21st, 2010

After my first encounter, I have informed all of my franchisees that they must have a separate PC for administrative purposes other than the POS server (when it is running integrated credit). A large portion of them have come back to me and told me that I am basically an idiot and that their merchant bank/scanning vendor/POS provider told them such a requirement is not true. Some have already been certified compliant without the second machine. What’s with that?

First let’s look at PCI-DSS 2.2.

Requirement: Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Test: Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening standards–for example, SysAdmin Audit Network Security (SANS), National Institute of Standards Technology.

Anyone have any suggestions on how I use this to help justify the “locked down, single function POS server?” Does anyone carry around a pocket-version of the industry-accepted system hardening guide? No? Let’s go deeper.

Here’s PCI-DSS 2.2.1: “Implement Only One Primary Function Per Server.” How awesomely clear is that?!

First, most of my franchisees don’t think of their back-office PC as a “server.” Second, who defines what is “primary” versus what is not? (“It’s primarily a POS server, but it also serves as my Facebook Central.”) The testing procedures call out obvious E-Commerce systems of DNS, Web servers, etc., none of which applies to a POS environment. But this is the Requirement I have been pointed to. Does it apply or not?

What really bugs me, if I’m being honest, is that it makes me look like an idiot. “Todd doesn’t know what he’s talking about.” “Todd is telling me to spend money that I don’t need to spend.” “My bank has already told me I am compliant and Todd is telling me I need to purchase more equipment and services.”

Now EVERYONE who I have ever spoken to about this topic agrees that the absolute worse sin a merchant can commit, regardless of compliance, is to use the POS server for Web surfing when performing integrated credit. Still, I am guessing that dozens or maybe hundreds of merchants each day are told it is okay.

Why can’t the PCI-DSS standard and the SAQ clearly call out what needs to be done? Why can’t it clearly state the different requirements of integrated credit versus standalone credit versus PED credit devices? If everyone agrees that surfing the Web on a server that is running credit software is a bad idea, why can’t we just come out and make a very clear requirement stating that you can’t do it?

It seems that a lot of conversations are about advanced items like encryption and tokenization or Chip-and-PIN. How about we start with the basics, like no surfing porn near your customer’s credit card data?

Any QSAs out there care to weigh in? Leave a comment, or E-mail me at Todd.Michaud@FranchiseIT.org. You can also follow me on Twitter: @todd_michaud.

As I struggled for breath, I watched a 60-year-old man with some bad-ass looking Blue Blockers power-walk his way past me to the finish line in my first triathlon. Read more at www.irongeek.me.


advertisement

4 Comments | Read PCI Compliance: An Updated Version Of The Newlywed Game

  1. Walt Conway Says:

    As StorefrontBacktalk’s resident QSA, I thought I’d be the first to take Todd’s bait.

    Let’s remember that PCI or any standard cannot and should not explicitly address every possible configuration or situation explicitly. And by the way, you should not want it to.

    QSAs are taught during our training that there is room for interpretation. We need to use our best judgment. There are business requirements to consider. There is new technology or changed configurations that may make yesterday’s “yes” be a “no” today, or vice versa.

    I don’t think you or any merchant would be happy with a DSS that spelled out every single situation, stipulated every technology, or was similarly cast in stone. We would not have compensating controls, for example, and almost all large retailers and processors have at least one of these. And how many standards admit that the world changes, so they actually publish a lifecycle and give advance notice before merchants have to implement changes?

    Lawyers can interpret laws differently; highly trained and educated doctors can disagree with the diagnosis of other equally trained and educated doctors. Is it surprising that every QSA might not have the same conclusion when faced with a complicated situation? I know my colleagues and I have regular assessor meetings where we ask each other for opinions or interpretation of particular situations. Does this make us incompetent? I don’t think so. I think this reflects the complexity of the payment environment and the weird brew of new, old, and downright obsolete technology we encounter daily.

    If you are frustrated by the room for interpretation in PCI today, you would be even more frustrated if it were a straightjacket. Heaven knows – and every QSA does, too – PCI is not perfect, but it is pretty good and it’s the best we’ve got.

  2. Todd Michaud Says:

    Hey Walt!

    I want to clarify a few points that I was trying to make.

    First, with your analogy about laws and lawyers, you have to understand that most laws are negative enforcement. Meaning, they tell you want you “can’t” do. That is not true of the PCI-DSS. In many cases, this policy states the things you “must” do. While subtle, this changes the impact of a judgement call quite a bit. Being specific about what is bad, and having everything else as good, is much easier to enforce. Sure there are different people who interpret laws differently, but they are all working to see if someone was “too bad”, and not were they “good enough.”

    And I think that you would be surprised by the fact that I would want a much higher level of specificity in the standards. Unlike many of my retail brethren who are faced with this issue, I am not a large retailer, I am a loosely tied-together band of small retailers. Each one of these retailers has their own systems and their own processes.

    Most of these merchants do not have their own IT staff. Without specificity and without local IT resources, the result is likely to be poor, and you force a restaurateur to interpret policy they do not understand and implement technology/policy without a lot of understanding of how it works or why it works.

    And since many of my franchise agreements were written before the time of electronic payments, I do not have any contractual relationship with them in the area of PCI compliance. I can educate, suggest and recommend, but that is about it. I rely heavily on the rest of the payment ecosystem (largely the Acquirer) to lay down the law.

    I would benefit greatly, not from specific technologies called out, but from things like: “Do not use your POS for non-POS and payment activities.” That isn’t saying you have to use a certain technology stack, it’s a deeper level standard without going overboard.

    Also, please don’t take my column as an rant about the QSA industry, it was not intended to be so. I think that QSAs do the best job that they can, working within a flawed system. We would all benefit if the system were more clearly defined.

    Thanks for jumping in!

  3. PCIJeff Says:

    I think your legal analogy is a good way to look at this situation and ask yourself this question – would go into court represented by a lawyer with only a few days of training? Of courses the answer is no but when you hire a QSA you are getting a security consultant that has only 3 to maybe 6 to 8 days of training from the PCI Council (Initial training is now 3 days and recertification is 1 day). Yes the PCI Council says that a person must have a minimum number of years’ experience but I know of many QSAs that are actually sales people and have never implemented any security products and never performed a security assessment.

    Now don’t get me wrong, I know of many very good information security consultants that are QSAs but even these people do not get any support from the PCI Council when they have questions. I would suggest you send the question you ask QSAs to the PCI Council and see what the answer is you get back. I would also like to suggest Walt send the same question and then compare answers.

    Based on my past experience your answers should read something like “because of your complex environment we suggest you contact a QSA for assistance”. Walt’s answer should look something like “we empower you as a QSA to review your client’s environment and make the determination yourself”. Also understand that these responses from the PCI Council usually take 6 to 8 weeks to come back to you.

    The problem clearly is with the PCI Council and their ineffective standard, lack of training for the QSAs and lack of support to people that have questions on how to interpret the standard. The QSAs are merely trying to do the best they can for their clients with the limited amount of support they receive and an ineffective standard. My suggestion is that you find a good QSA and partner with them to address the inconsistencies in the PCI standard and reach an agreement on the best interpretation for your environment.

  4. Chris J Says:

    Part of the issue here seems to revolve around the mentality of “compliance as a requirement” rather than “security as an initiative.”

    While I am new to the world of compliance, it is clear to me that compliance is the minimum of what a company should do to protect their business and customers. So just because you ‘can’ do something and be compliant, does not mean that you ‘should’ do that. To go back to Todd’s first question – Is a retailer allowed to run other applications on the POS server if that server processes integrated credit card transactions with PA-DSS certified software? The answer might be ‘Yes, they are allowed.’ However, the more important question that I feel merchants should be asking QSAs is “Am I more secure running other applications on the POS server, or restricting usage to POS/payment applications?”

    The PCI DSS needs to be flexible to account for the vast number and variety of businesses that fall under its umbrella. It is up to the merchants themselves to take responsibility and enact some common sense to decide just how secure they want their business to be.

    Analogy Corner:
    The law says you cannot drive drunk –
    If you go to a bar and you’re worried about compliance you say, “Tell me how many drinks I am allowed to have before driving.”
    If you go to a bar and you’re worried about security you don’t drink.

    PCI DSS gives businesses guidance and a baseline for security but allows a merchant the freedom to choose just how secure they want to be.

Newsletters

StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!
advertisement

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

StorefrontBacktalk
Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.