PCI

This is part two in a conversation that I had with Ben Tomhave (@falconsview) last week over Twitter. What started out as a quick question about busting PCI myths turned into corporate responsibility. If you haven’t seen this article about a company who is facing massive penalties, give it a read. It will help set up my position on corporate responsibility for promoting longevity. My position:

Companies must make security and compliance a core part of their competency if they choose to operate in a manner that puts them in the cross-hairs of regulation.

During the conversation, we moved to overall organizational competency around areas that arguably sit on the fringe of their core business. Restaurants that make pizza should do that well, and not focus on other things as much. While on the surface I agree with this, I also think that being in business is inherently risky, and business owners should have good knowledge (or hire people that do) about the risks that apply to them.

Take the business to consumer environment for example. If you want to get money from a customer, you have a few options to do so. If you choose to accept payment cards, you need to understand how that acceptance affects your risk model. Is it overly-complex? Definitely. Is ignorance an excuse? Never. This was something that used to drive me nuts as an assessor. The role of a QSA is to see how your company stacks up against PCI DSS, not be a liability transfer in case of a breach. If your organization faces compliance with PCI DSS, HIPAA, Health Codes, or local town ordinances, it must understand what those things mean to the business and build internal competency around it.

On to the discussion (again, slightly edited):

Ben: That statement also ignores that, while PCI may be your full-time job, it’s certainly not an organization’s (in general).

Me: If it’s that impactful to an organization’s bottom line, they should have the competency to handle it.

Ben: I think that’s a backwards and incorrect attitude. Audit/Compliance/Security is *not* their business. Business is. Audit/compliance/security/etc are merely attributes or emerging properties of their overall business…

Me: I think any company that doesn’t fully understand their business is backwards. PCI is a reality if they choose to accept CCs. Businesses choose to do things a certain way which causes audit/compliance/security.

Ben: While all this focus on audit/compliance/security may be good for you, it may not be so good for businesses. Focusing on the wrong things detracts from the right things (building a successful business that is resilient/survives)

Me: I’m not saying that audit is good because I might make money at it, I’m saying businesses choose to take risk, therefore they must live with the consequences, whatever they may be. Otherwise, divest/change.

Part of building a resilient business that will survive is good corporate risk management. Both Ben & I agree on this point. Executives need to know the level of risk they carry, and be able to make decisions on future actions based on how that affects their risk. For example, an over-leveraged company probably wouldn’t choose to take on more debt to expand (solvency risk), and a company relying on credit cards for customer revenue should know how banking rules affect their business (compliance risk).

Many merchants that are compromised usually are told about PCI DSS, but they never invest enough time and energy to know if what they are doing increases or decreases their compliance risk. Not only are they notified by their banks (albeit not uniformly or consistently), but most of these folks participate in an industry consortium that no doubt bring up the PCI topic often to their membership. Yet when merchants are breached, they blame everyone but themselves.

The best businesses are managed at a detail level. I’m not talking about micro-management by an executive—I’m talking about using detailed information to empower employees with competency and skill to drive the business forward, or by outsourcing things to third parties that are qualified experts and will accept the liability on the business’s behalf. Visibility into the risk you carry at any given time isn’t required to make a decision about what comes next, but if you want to know how your decision will affect the future you need to have a clear picture of what today looks like. You don’t HAVE to know anything about PCI DSS, but if you actually read (decoded is probably more accurate) the contracts you signed when you got your merchant account, you would know that you have to comply with certain security standards. You obviously can choose to ignore these standards, but you look ridiculous when you point the finger at someone else after a breach.

Of course, it’s getting harder for business owners to learn about their risks thanks to complex software packages being offered as a service. Business owners are attracted by the glitz and glamor of a fancy piece of software, yet they don’t really understand how to use it or understand the liabilities associated with the information stored—that is, until a breach happens.

Citizens of a civilized society are expected to follow the rules of that society. Ignorance is never a defense. If you choose to operate a vehicle on the road, you are expected to know all of the rules for performing that action and risk fines if you operate outside those rules. Do most of us push the speed limits when we drive? Yep, but we also accept that those flashing blue and red lights behind us mean we’re going to pay for breaking the rule. Claiming you didn’t know that certain information needed to be protected is like telling a cop that you didn’t know the speed limit, therefore you should be excused from responsibility. It doesn’t have to be something like a speed limit either. What about passing a school bus when its red lights are flashing? That’s illegal around here, and you deserve a ticket if you do this.

Ultimately, it comes down to choice. We all choose how involved we get in certain parts of our business, but that means we have to be responsible when things get away from us in areas where we stayed an inch deep. There is always an alternative. For example: how many cash-only businesses with on-premises ATMs have you seen pop up over the last few years? I’m certainly seeing a few more. Talk about a fast way to solve a PCI DSS problem and lower your compliance risk!

Curious on what Ben has to say? Check out his piece here!

Possibly Related Posts:

• Myth Busting with Ben Tomhave
• We Must Hunt
• Contextual Deep Content Inspection for Security
• 2011, A Year in Review
• Guest Post: Functionality and Benefits of WAF

{ Comments on this entry are closed }

I love our industry! There is no shortage of truly talented and smart folks, and one of the best parts of being in this industry is getting to have conversations with these folks often. Ben Tomhave (@falconsview), a noted security pro and blogger, kicked off a fury of tweets that really went into two directions. First was for a common myth about PCI DSS validation which I will address here (and ensure it is much clearer in the next edition of the book). “Can merchants (including Level 1) self assess?” lead us to a conversation about the functions of audit, the industry in general, and corporate responsibility. We’ll get into THAT discussion next week.

The discussion on Twitter began with this tweet:

Here’s a basic summary of the conversation (fyi, the tweets are all public if you want to go back and look—some were edited to help the conversation flow in this format):

Me:  That is correct. Merchants have always been able to self certify. Service providers cannot. (brand rules)

Ben: what do you mean “always”? where is that written? thought it was mandatory for L1/L2 merchants to have a QSA?

Me: It’s written in the payment brand level definitions and required validation procedures. MC now requires ISA/QSA for L2.

Ben: if that’s true, then I don’t understand how we need so many QSAs…? why would anybody opt 2 pay more when cutting corners?

Me: Because merchants incorrectly believe that hiring a QSA accounts for a liability transfer. Plus, with corp accountability, an officer’s signature on the Attestation of Compliance is usually required.

Ben: regardless, it seems to me that there is good financial motive to foster confusion around whether or not QSA is a req.

Me: I argue that anyone who says it’s required probably isn’t intelligent enough to do it right anyway #proposalintrashcan

Ben: Wow, that’s quite a statement. I would argue that people listen to their auditors+consultants+QSAs a little too much.

Me: I’m right there with you. That’s why those folks should become ISAs so they can call bullshit instead of driving off a cliff.

This is the first part of the discussion which I really enjoyed because not only did we discuss some of the false perceptions around PCI DSS (like using a QSA is a requirement), we also got to rehash some roles and responsibilities. We cover this in the book and I reviewed it in this post. Here’s a summary:

• 

  Bad-Boys, by davidsonscott15

  The PCI Council (Intent): Only answers questions about the intent of PCI DSS.  Don’t ask about fines, complain merchant levels or the requirement to use a QSA or ISA, or ask if Bit9 will comply with Requirement 5.

• Payment Brand (Enforcement): Only answers questions about their specific compliance program.  Visa’s CISP, MasterCard’s SDP, American Express’s DSOP, Discover’s DISC, and JCB’s DSP all refer to PCI DSS as the common set of controls, but all have different requirements to comply.  You should ask them about fines or when to submit an SAQ.  Don’t ask them about the intent of a PCI requirement (though they will likely answer to assist you) or if RSA’s SecurID is the only thing that will satisfy Requirement 8.2.  While they may try to assist, I typically see (with one exception) payment brands avoid those discussions, especially when their competitors are present.
• Acquirer (Enforcement): Most compliance questions are better suited for your acquirer because they are responsible for your actions on the payment network.  Acquirers don’t have all the answers, and you should not ask them if <Insert Your Vendor Here> EV-SSL will comply with Requirement 4.1 (hint… it will) or the intent behind a particular requirement.  Again, they may try to point you in the right direction, but Payment Brands are responsible for enforcement of PCI, and they enforce it on your Acquirer who then enforces it on you.
• QSA/ISA (Interpretation): Your QSA (or ISA) is an important step in the PCI DSS process.  If you don’t like her, the process is going to be a pain.  Alternatively, if she works well with your company, things will work out much better for everyone in the end.  It’s your QSAs job to weigh all the guidance from the Council and apply it to your individual environment to determine it’s compliance with PCI DSS.  Ask her questions about specific technologies and their compliance in your environment.  Don’t forget to tell her EVERYTHING about the solution.  Context is a real issue with these types of questions.

The Council is viewed as the place where the buck stops simply because they are the focal point of everything that has popped up around this industry. To make matters more complicated, members of the Council work for the payment brands! I’ve had numerous discussions with various members whereby a question posed by me is only asked after I specify if they should answer with their Council hat on, or their day-job hat?

So, to review the myth busting, all merchants have the option to self assess, QSAs may get things wrong from time to time, and becoming an Internal Security Assessor (ISA)—regardless of your plans to self assess—is hugely beneficial to your company.

Possibly Related Posts:

• We Must Hunt
• Contextual Deep Content Inspection for Security
• Guest Post: Functionality and Benefits of WAF
• Guest Post: Virtualization Makes Everything Easier – Including Burning Bridges
• Guest Post: Getting Management to Buy into ITSM

{ Comments on this entry are closed }

Well, that depends on who is responsible for safeguarding your credit card information. This is a case study of how Point is providing better protection to its customers, merchants in Europe. Organization Point is the leading provider of electronic payment solutions in Europe, serving every type of business that require multi-channel payment capabilities: from small [...]

{ Comments on this entry are closed }

By Rob Sadowski – Director, Marketing, Payment Solutions

One of my favorite holiday tales is A Christmas Carol. During the season, you can take in numerous retellings of Charles Dickens’ classic on television, the movie theater, on stage, and perhaps, if you’re unlucky, at a local retailer. If that last one doesn’t make sense, let me try to explain.

In the story, as you are probably familiar, the main character, Ebenezer Scrooge is visited by three ghosts who help him resolve to change his life for the better. The first of these, the Ghost of Christmas Past, shows Scrooge how his actions in the past have made him the unpleasant person he is in the present.

In the past several weeks, I have read two recent data breach accounts that suggest that many retailers may need their own visits from the ghosts of the past to realize that they need to change their ways. In early December, the US Department of Justice charged four individuals who “conspired to remotely hack into more than 200 U.S.-based merchants’ point-of-sale (POS) or “checkout” computer systems in order to steal customers’ credit, debit and gift card numbers and associated data.” According to the indictment, the individuals “compromised the credit card data of more than 80,000 customers, and millions of dollars of unauthorized purchases have been made using the compromised data.” Two weeks later, another retailer disclosed that unauthorized individuals had gained access to their network and “obtained the names of cardholders, credit or debit card numbers, card expiration dates, and verification codes that were on the magnetic stripes” of more than 200,000 cards.

The pattern for these attacks is well known. It’s the same MO used most (in-)famously by Albert Gonzales and others back in 2005. Gain unauthorized access via insecure wireless networks, poorly secured remote access gateways, or by exploiting common vulnerabilities. Install malware capable of capturing data on the wire or from POS system files or memory. Intercept cleartext card transaction data, aggregate and exfiltrate. There’s even a best-selling book written about it! The PCI DSS guidelines were revised to address it!

Yet the criminals keep using the same old strategies, because they apparently still work very well. We’ve spoken in the past about how encryption in the payment terminal and use of tokens removes the value of card data for criminals in the event of a compromise, and how this technology has been proven and available for over a year in the market. My hope is that in the coming year, we don’t need any more visits from the ghosts of compromises past to keep reminding us about the need to address this continued threat.

Rob Sadowski leads RSA’s go-to-market efforts with partners in the payments industry. He has confidently used payment cards at numerous card-present and card-not-present retailers during this holiday season.

{ Comments on this entry are closed }

Cybercrooks presumed to be operating from Russia hacked into the Restaurant Depot database last month and accessed the credit and debit card details of more than 100,000 customers.

In a Nov. 25 notice, Stanley Fleishman, the chief executive officer of Restaurant Depot and supermarket wholesaler Jetro Cash & Carry, informed affected customers that “unauthorized persons obtained the names of cardholders, credit or debit card numbers, card expiration dates, and verification codes that were on the magnetic stripes of credit and debit cards used at our stores from September 21 through November 18, 2011.”

Click to read full article >>

{ Comments on this entry are closed }