Quantcast StorefrontBacktalk » Blog Archive » From The Heartland Breach To Second Guessing Service Providers
advertisement
advertisement

From The Heartland Breach To Second Guessing Service Providers

Written by David Taylor
January 21st, 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.

This week, Heartland Payment Systems, the sixth largest payment processor in the United States, announced it had suffered a security breach that had definitely compromised credit card transaction data, thanks to malware that sniffed decrypted transactions on its processing platform. The details are sketchy at this point, and forensic analysis continues.

Here’s my point: When you add the Heartland breach to the breach of RBS WorldPay a month ago, you have to ask yourself: Are retailers really any safer if they outsource the handling of payment and other confidential data to third parties? Are service providers, on average, any more secure than retailers? Many pundits used the TJX and Hannaford breaches as excuses to question the security of the entire retail industry, so why not use two payment service provider breaches as a springboard to question the security of service providers in general?

  • Taking Data Security Seriously
    Honestly, most companies, as a whole, don’t take data security very seriously. Three years after PCI was first mandated, it’s still most commonly managed in IT, with the goal being to check all the boxes as cheaply as possible. There is very little ongoing education of employees as a whole about the importance of protecting customer data. “PCI Awareness” typically consists of forcing employees to sign a liability-oriented document once a year. To some extent, this is a “cultural” issue, so we expect change to be slow. But one of the fundamental issues with adapting PCI to general employee education purposes is that it is too technology-laden to lend itself to the kind of multi-layered educational program needed for different types/roles of employees.

    The point here is that the problem is exactly the same at service providers as it is at retailers. Retailers have zero reason to assume that when they outsource shopping carts, payment processing, data analysis or even application hosting that the service provider they use will treat their data any better than they do. Frankly, some service providers do a much better job than others when it comes to data security, but they charge more.

  • De-Commoditizing Payment And Security Services
    We have interviewed dozens of companies that provide payment and security management services to retailers. Their number one complaint is that they feel they are wasting money on data security, because their customers don’t seem to care. The ones who also have banking industry clients are spending the most on data security because bankers will do relatively thorough reviews and may even send a team of internal (or third-party) auditors to review them. But retailers, the complaint goes, buy almost exclusively based on price. Even if it’s true that no enterprise can be fully “secure” against sophisticated threats, it certainly makes sense to build a bunch of data security questions and quarterly security audit reviews into service provider contract reviews and vendor selection. A “shorthand” question is to ask a service provider if it also provides services to banks, and pray that its banking customers are doing the kind due diligence that you don’t have the time or money for.

  • Malware Automation Vs. Concentrated High-Value Data
    Malware has two countervailing trends, both of which are likely to continue. The first is that there is a rapidly growing market for highly automated malware that uses basic building blocks and can be easily adapted to identify and exploit new vulnerabilities. This malware exploits unpatched servers, poorly defined firewall rules, the OWASP top 10, etc. It is really aimed at the mass market–SMEs and consumers.

    Then there is the high-end malware that employs the “personal touch”–customized to specific companies and often combined with social engineering to ensure that it’s installed in the right systems. This type of malware got TJX, Hannaford and now Heartland. The point is: The more concentrations of valuable data we create, the more worthwhile it is for malware manufacturers to put the effort into customizing a “campaign” to go after specific targets.

    So if you’re using a service provider that is a “big target,” you need to put in due diligence that is appropriate to the size of the target and to assume that malware manufacturers will be putting in an equivalent amount of effort.

  • Protecting Your Company–Actions Worth Taking
    This advice all sounds pretty depressing as I read it over. But there are a couple of things worth doing in the next few months, when you’re not working on your resume. (1) Review the Web sites of several service providers you use to handle “confidential” data–collecting it, processing it, analyzing it, storing it, etc. See if they are marketing their data security capabilities or if they even mention PCI compliance. (2) Ask an AE or SE at those firms if they offer multiple “tiers” of services, based on the level of protection provided. (3) Try to get some pricing for high vs. low security and compute the percentage difference in price to compare across companies. (4) Ask the providers who in their company was involved in the QSA review that got it on the Visa service provider white list (assuming it is); talk to that person, and see if you can get a copy of the report on compliance (but don’t expect to get the full report). This information will help you justify spending more money on more secure service providers while still ensuring your spending is proportional to the incremental data security delivered.

  • The Bottom Line
    The goal is to take some low-cost actions that will either give you more confidence that your service providers have a pervasive (or, dare I say it, “strategic”) view of customer data security or show you that they just do the bare minimum. If you’re not happy with the results, you should line up a couple of alternative service providers using the same simple tests. There are service providers who take data security seriously, but do not assume that you’re using them, just because they managed to pass a PCI compliance test. If you want to discuss this topic or want more information, visit us at the PCI Knowledge Base, or just send an E-mail at David.Taylor@KnowPCI.com.


  • advertisement

    6 Comments | Read From The Heartland Breach To Second Guessing Service Providers

    1. Dave Says:

      David Taylor seems to have used the Heartland Breach announcement to “vent” on topics apparently near and dear to him. The discussion of retail security based on the TJX and Hannaford breaches makes sense as surprisingly, they are Retail establishments. But using the breaches of two banks to question the security of all service providers in general is patently ridiculous. I don’t know of any bank that offers security services to their customers. There are hundreds of service providers that are not banks, related to banks or provide any merchant services or banking related service.

      There are telecom companies that merely move the data from point to point. They are service providers.

      There are companies that provide the service of connectivity to several banks or processors with different formats using a single format. These are service providers.

      There are companies that provide accounting and reporting of payment information. These too are service providers.

      There are companies that securely store card data for merchants. These are service providers.

      There are companies that provide security technology to keep credit card information out of POS systems and off websites. These are also service providers.

      Which of these service providers is David talking about? Generalization in a forum like Storefront Backtalk is as dangerous as saying “put in a couple of firewalls and your data is safe!” Broad brush one comment fits all articles like this one do not raise the discourse to a level that it deserves.

      A breach is a serious thing. But articles like this do little to improve the situation or to disseminate useful information. Comments like “Most companies don’t take data security very seriously “is as ridiculous as “all consultants are intelligent.” I have thousands of customers that are very serious about security.

      The comment “Frankly, some service providers do a much better job than others when it comes to data security, but they charge more” is another broad brush statement that is just not true. I know our customers receive substantial security functionality and services at no additional charge and I am sure that there are many other service providers that are priced similarly.

      The whole purpose of PCI is to protect as many end points as possible. Basically as more end points are being protected the big boys become bigger targets. Thieves that want to make a big hit don’t want to pick the locks of thousands of homes; they would rather rob a bank. If there were no locks on houses, the lazy crook would open the door and steal what they could and move on. As some “service providers” are protecting individual merchants, thus making stealing a little more difficult, they are forcing the bad guys to work harder. Service providers like Heartland and RBS need to raise their game.

      Malware is not a single thing and to discuss the Malware as such is again more generalization. To dignify crooks and thieves as “malware manufactures” is like the government, the press and the consultants “criminalizing” the victims. Please remember, Hannaford, TJX, RBS, Heartland and their customers are victims; their houses were broken into. Do we treat other victims with such contempt? We need to keep an open mind and not question every answer and every move made by a victim of a breach. These folks have to stand naked in front of the world merely because of a criminal act of some dirt bag. I think to belittle them for tying to stand behind Barak Obama’s Inauguration is unfair. When one is naked the normal reaction is to hide. More people watched American Idol than the Inauguration festivities anyway.

      The four suggestions are reasonable if not obvious. Unfortunately they don’t apply to all payment service providers and they dwell too much on the cost of the service. If providers of payment security services don’t talk about their security prowess run, don’t walk, away. Asking about multiple levels of security protection is truly strange. A little bit secure is useless at any price and completely secure is priceless. Ask about the service provided and ask experts whether it is secure or not. Of course Real Security at a low price or no price is optimal. While I am not sure that any security conscious company will disclose the members of their “security committee; “knowing that members of the executive staff are involved in the service provider’s offering and associated security evaluation is truly important.

      On this we agree; PCI is not the be-all-end-all, but it is a good start. A dedication to Real Security is more important than compliance with any standard including PCI. Lock your doors there are thieves out there!

      J. David Oder

      President/CEO

      Shift4 Corporation

      http://www.shift4.com

      http://www.simplifypci.com

    2. David Taylor Says:

      “In response to Shift4’s corporate position re: my posting. I was attempting to make several points. Here they are, in briefer form, so that they may be easier to understand:

      1) My first point was the greater concentrations of valuable data create greater risk, simply because it is more worthwhile for thieves to expend effort to target these companies. This is true of banks, card processors that are not banks, or any companies that gather and process large volumes of credit card numbers or other identity-related information. This goes back to Willie Sutton’s comment about why he robbed banks: Because “that’s where the money is.” The greater the data concentration by an organization, the greater the potential threat to that data.

      2) My second point was that we have talked to a number of companies who have tons of confidential data. They provide services to merchants, banks, etc. There are huge differences in the level of protection provided to confidential data by some of these firms. Of those who are spending lots of money protecting data, they have to charge to their customers to pay for this security. Their frustration is that their customers often do not appreciate this. Too many customers, particularly retailers, still buy on price, without appreciating the value that the additional security provides to customers. Our goal is to help customers (especially retailers) be more conscious of security as a differentiator among service providers.

      3) My third point was that these are serious criminals. By using the term malware “manufacturing” we are suggesting that this is a “criminal enterprise,” or “organized crime,” if you will. To suggest that these criminals are not organized or that there is not a concerted effort to efficiently break security systems is to understate the impact of their efforts.”

    3. PCI Guy Says:

      David Taylor wrote “greater concentrations of valuable data create greater risk, simply because it is more worthwhile for thieves to expend effort to target these companies.”

      Here, here! How long until Shift4, and/or any number of their competitors, suffer an attack like what Heartland and RBSLynk have experienced? And how many of their customers, who relied on representations of “security,” will be surprised to learn that the banks will go after the merchant, not the service provider, for fines and costs?

    4. Steve Sommers Says:

      There is no such thing as 100 percent security. PCI Guy, my question to you is how much time and money does your average customer spend per year on the above until their next annual PCI audit? (I’m assuming you are a PCI auditor) We can preach PCI all day long until we’re blue in the face, but if you deal with small to medium merchants on a daily basis, you should already know most merchants all but totally ignore PCI after the auditor leaves until about a month before their next annual audit or ROC filing. Until you can squeeze PCI into a can, sell it like anti-virus software, and be able to have merchants install and forget it, reputable gateways have a place in the PCI equation (ignoring other non-PCI features gateways bring to the mix).
      One final analogy using cash:
      Fort Knox – maximum security – no breaches (at least none that I have heard of)
      Banks – strong security – breaches rarely happen
      Merchants – minimum security – breaches occasionally happen (more or less depending on many factors)
      Based on David’s article, Fort Knox is the biggest target and therefore its use should be discouraged; same with banks – merchants should be holding their own money because they are the smallest targets.

    5. PCI Guy Says:

      Actually, the security of Fort Knox is significantly enhanced by the fact that the value it contains (gold) is extermely difficult to transport in large quantities.

      Banks have relatively small amounts of money and basically nothing else worth stealing; the typical payoff from robbing one is a few thousand dollars. Security at banks is actually fairly weak, just hand the teller a note and be on your way…

      A bank computer system, on the other hand, contains billions of dollars that can be “moved” in milliseconds and, therefore, it makes a very attractive target. Banks understand this, and have highly secure computer systems. Unfortunately, acquirers and payment processors are not banks and, evidently, they still have a bit to learn about computer security.

      There is nothing fundamentally bad about payment gateways, but they are not nearly the silver bullet you constantly portray them to be. Gateways do not prevent a merchant’s computer from being attacked, and gateways add another attack vector to the payment processing chain.

      A hacker who has infiltrated a merchant’s computer can easily circumvent your encryption driver. The Shift4 “tokenization” system merely eliminates storing encrypted card numbers on the merchant computer until those transactions have been settled. In other words, your system helps protect against a hacker who (1) gains access to the merchant’s computer and (2) locates encrypted card data awaiting settlement, and (3) locates the required decryption key on that computer. A hacker with that much skill is far more likely to install a sniffer and grab card numbers before your product can encrypt them. That kind of attack could go on for months without being detected.

      Moreover, since the Shift4 servers are holding millions of card numbers, your site is at considerable risk for attack. It happened to Heartland, it happened to RBS Worldpay, and it has happened to many other “secure” computer systems. It can happen to Shift4, too. (You thought your network could not go down, but you had an major outage in December, right?)

      Like I said, there is nothing fundamentally bad about payment gateways, including yours, but they are not without flaws and vulnerabilities, either. I’m concerned your company’s over-the-top marketing hype is doing more harm than good by leading your customers to believe they need not worry about security.

    6. Steve Sommers Says:

      PCI Guy, you are not aware of, or don’t understand the different layers of tokenization Shift4 provides. The tokenization you described is the initial version that we released to the public domain back in 2005 and you are correct, it only addresses storage. Also, no pre-settlement card holder data is stored on the merchants system, only tokens and there is no storage key to crack.

      We have a version of tokenization that encrypts at the swipe, prior to entering the merchant’s POS and is fully encrypted in flight on the merchant’s network. This version of tokenization addresses all the merchant side issues you pointed out and is basically an end-to-end tokenization model.

      I never promote gateways as any sort of silver bullet. On the contrary, I’m the one that always emphasizes that there is no such thing as 100% security. But I also know our system and what the average merchant dedicates to security throughout the year. You would be hard pressed to find any merchant that dedicates as much to security as we do (in time or resources).

      The main argument here is distributed risk vs. consolidated risk. If all things were equal, security was security and everyone has an x% chance of a breach, then your argument would be accurate. But not everyone has an x% chance of a breach. Some have a much higher percent chance of one; others have a much lower percent chance. A big factory in the (x+y)% vs. (x-y)% chance, is the money and resources dedicated to security. The average merchant dedicates minimal amount of time and money to security. Not everyone can afford the thousands, hundreds of thousands, and sometimes millions of dollars it takes to be secure. For the average merchant, I firmly believe that reputable gateway that focus and provides secure solutions will reduce the merchants x% chance of being breached.

    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

    What’s The Rush For New PCI Call Center Requirements?

    And I have not heard anyone mention the impact on companies who provide quality improvement services. Many merchants hire quality improvement companies to review their audio recordings to provide guidance on how to improve their sales staff’s effectiveness in customer service and sales retention. PCI Council needs to rethink this requirement until there is a widely available commercially viable solution. Read more...
    Another ridiculous decision where regulators don't think critically enough about the unintended consequences of their decision. This will be a huge problem for the credit and collections industry. We have to keep all recorded calls for other reasons not related to cc information. We can't purge all of our calls and we don't have the technology to not record part of the conversation. Even if we did, I am not sure we could afford it. Read more...
    This "clarification" is causing a lot of panic with large FS clients who now appear to be non-compliant after spending 7 figure sums on their compliance programs. The only alternative to call recording would now appear to be some sort of IVR/push button type interrupt to take card data away from the contact centre. The council is a position to force that sort of process and technology change and this may backfire on them and the vendors that lobbied hard for this clarification. Read more...
    PCI council has made a one-sided decision; They should have done a much more in-depth research that could have provided more insight on what regards to the implications of such decision. Read more...

    Will Old OS Cause PCI Violation? No, But Marketing Still Says So

    This is an interesting issue, because there's more to it than what's apparent on the surface. PA-DSS requires supported and patched operating systems and other software components (e.g., databases, libraries, Java, etc.) per PA-DSS 7.1.b and 8.1, and the option for compensating controls simply isn't there. Merchants can make use of compensating controls for most PCI DSS requirements, but only when legitimate constraints exist and only in ways that meet the intent and rigor of the requirement and go above and beyond the other PCI DSS requirements. Read more...
    Why would one automatically upgrade to a "new" OS -- some of the older versions of certain OS-es are more stable and more robust than the crap being peddled today. This is yet another clear example of PCI SSC being out of touch with reality. Rather than requiring a "current" OS, the requirement should be to demonstrate the OS in use is stable and robust, and is adequately hardened against threats. Read more...
    There are compensating controls that encrypt the swipe at the driver level as it enter the PC, there are hardware encrypting card swipes so the cardholder data is already encrypted before it comes to the PC -- either of these, especially the second, would remove the OS entirely from a cardholder data risk profile. Read more...
    In my opinion, the only thing the vendor did wrong was they didn’t know of that FAQ entry. Even if they did, it changes nothing about the need for merchants to update software that no longer receives updates. Read more...

    MasterCard Blinks, Drops Dec. 31 Level 2 PCI Deadline

    Reciprocity between MasterCard and Visa was always been a factor in Acquirer merchant level assignments. The brief removal of reciprocity generated a great deal of interest in being able to be classified at a lower level in MasterCard's world. Nevertheless the return of the reciprocity language in the December changes did not effectively create any new Level 2 merchants, but it DID dash the hopes of a lot of them.... :-( Read more...
    Let's given them credit??? For being idiotic in the first place? Not on your life! Everyone has just had to scramble and include the costs of the previously announced M/C requirement in their 2010 budgets, and start negotiating with the QSAs for the additional services. All for naught! Read more...
    "A bunch of Level 3 and Level 4 merchants just became Level 2s". Is this an accurate statement? MasterCard & Visa have historically included the caveat "or is a Level X in another brand" in their level setting criteria. MasterCard appeared to back way from this in the June pronouncement, and have simply returned to the status quo. Have Acquirers have been tracking and reporting merchants at separate levels by brand? Read more...
    I stick by my comment (quoted in the column) about a bunch of L3 and L4 merchants becoming L2s and requiring an onsite. To me, what made MasterCard's original requirement for an onsite assessment for L2s palatable was that they took away their reciprocity provision. That is, they seemed to focus on larger merchants with over a million MasterCard trans/year. With reciprocity in place, a lot of smaller merchants are pulled into the onsite requirement. Rather than causing confusion, I think reciprocity will lead to additional work for processors and acquirers. Read more...

    Retailers Sue POS Vendor, Questions Raised Where PCI Duties Stop

    I would add a couple more questions: "did the breach involve the use of the default passwords?" (The story doesn't say.) And "were the default passwords used by Computer World to remotely administer the store systems?" "where is the PCI auditor in all this?" Did the restaurant group think they didn't need an audit because Radiant was (mis)representing Aloha as PCI compliant? How is a retailer or even a PCI auditor to know otherwise? A PCI auditor is not necessarily a qualified computer forensic investigator capable of finding the card data on the hard drives. They can only base a decision on information given to them by others. Read more...
    There are so many holes in the process it will be difficult to pin blame on just one constituent. It is ridiculous that the technology exists to better secure these transactions (PIN, EMV, etc) yet banks won't use them. Only the banks or government can force this change, and retailers will suffer until then. Read more...
    A major issue in this case will be if the restaurants had any support agreements in place with Computer World and if so what those agreements say. In my experience many single unit/small operators choose to skip the support agreements in favor of a "pay as you go" arrangement. In this scenario I can't imagine how the POS VAR can be held responsible for a system they don't own nor exclusively manage. Read more...
    There is a big difference in having the POS installation guide say "make sure you set this password because the security of your CHD depends on this" vs. a POS application not storing the CHD in the first place. Traditionally only the merchant was liable for breaches and PCI related fees (fines). Maybe dragging some of the vendors into the liability mud fight will open the eyes of some of these vendors. Read more...

    Should Credit Card Transactions Be Free? There May Be A Way

    Here in the Netherlands, where the population is notoriously penny-pinching, credit card acceptance is amazingly low. It's both a result of the consumer not wanting to pay interest on everyday purchases as well as merchants not giving up a slice of the action. It is both legal and common to pass the processing fee onto the customer as a surcharge. Now things are moving to leave the credit cards behind: mobile phone payments are becoming more and more common here, and the transaction fees are minimal. Parking and entertainment (movie/concert tickets, nightclubs) have been amongst the first, and it's rapidly gaining momentum because the market has been hungry for the convenience at a price it is willing to pay. Read more...
    "Free" is an illusion. Don't charge one person but charge double to someone else. I am very skeptical on anyone who says that advertising will create valid cashflow. Just look at the advertising struggles in a TiVo world. And if you sell your customers data, just be warned that the one group that might have issue with that are you customers (which to me is very important to cashflow. Read more...
    Another factor not mentioned here is the impending costs that the processors and issuers are going to incur when someone decides on an end-to-end encryption method, and it then becomes government mandated. I can guarantee that this is a when question and not an if question. The back-end networks are pretty antiquated right now, and it's going to cost billions to replace everything. The cost of tech may be going down, but the cost of replacing millions of servers and hardware, and creating new, proprietary, software is still really expensive. Read more...
    Accepting credit cards are not "risk-free" for merchants, contrary to Jim's comments above. Chargebacks are an expense - both in terms of actual transaction reversals and costs associated with managing the process. Chargeback rules and expenses can be everything from a thorny issue to an onerous expense for some merchants, especially for convenience stores that allow customers to pay for gasoline at the pump, or other retailers that allow in-store self-checkout options. Read more...
    I've wondered for years why the price of transactions has been so high. Phone companies long ago started offering unlimited calling for flat rates because they understood that in many cases it cost more to report on the transactions (calls) than it did to fulfill them. Read more...
    If a home-owner defaults on the mortgage, who is taking the risk? The bank making the loan to the consumer or the person selling the house? It is obviously the bank that takes this risk and is rewarded for that risk through interest rate charges. In my mind, we have mixed together two distinct and unrelated transactions. Read more...
    The one big factor not mentioned in this article is who will take over the risk ? Taking credit cards is risk free to merchants and the issuing Banks take the risk if a customer defaults on the payments ! If you had a "interchange free" payment system will the merchants assume the risk ? Also, if there isn't enough profit for the issuing banks they will stop issuing credit cards which will in turn kill our economy. Read more...

    The Dangerous Out-Of-Scope PCI Charade

    If tokens are ever deemed in-scope, then where does the line stop? I ask this because it would mean that all timestamps, sequential number, random numbers or any other piece of information that may or may not be used to generate a token is within scope -- all data a POS uses and stores, not just payment data. Read more...
    Having the ability to do both Tokenization and End to End Encryption (not mere point to point) can have tremendous scope and risk reduction benefits and agility to adapt to change in this fast moving compliance landscape. Being able to have both on tap from a single platform is a solid approach to avoiding the pitfalls. Read more...
    But the consumer walks into a particular retail chain, gives their payment card to someone wearing that chain's uniform and the card is swiped. If, six months later, there's a breach and that card was misused, it's the retailer who will in the spotlight. They're the deep pocket and, therefore, the target. If the consumer is angry and wants to cut off business, it will hit the retailer. Therefore, if the retailer is going to end up being blamed no matter what, they have to stay involved. Read more...
    True, that someone may be storing a token-to-PAN cross reference. But that would be the bank, not the retailer. If the bank is not sure they can keep their data secure, then there are bigger problems to be addressed than bringing tokens into scope. Read more...
    Good general point, Steve, but for the record, not all tokenization is done the same way. Many tokens are associated with lookup lists that allow for them to re-matched to the card data if it's needed, such as for a chargeback. A token doesn't have to be decryptable (is that a word?) for there to be a way to access the original data. Read more...
    The out-of-scope argument is very valid but in reference to tokens, the premise of temporarily out-of-scope or abruptly deemed in-scope is flawed. Conway was quoted “anything that could be made unreadable can, in various ways, be made readable again,” this statement is true when talking about encryption technologies (all encryption technologies) but not so with true tokens. True tokens are in no way related to the original data other than as a reference key. Read more...