Quantcast StorefrontBacktalk » Blog Archive » Former Hannaford CIO: Avoid Microsoft And Change PCI’s Encryption Rules
advertisement
advertisement

Former Hannaford CIO: Avoid Microsoft And Change PCI’s Encryption Rules

Written by Evan Schuman
July 11th, 2008
Like this story? Share it
To share this story with people in your social network, please click on the network icons below.

Bill Homa, who just stepped down July 1 as the CIO for the 165-store Hannaford grocery chain, considers Microsoft’s OS to be "so full of holes" and describes the fact that current PCI regs do not require end-to-end encryption as "astonishing."

But Homa’s key point is that most retailers handle security backwards: Don’t pour everything into protecting the front door. Assume they’ll get through and have a plan to control them once they’re inside.

One of the most frustrating IT security realities in retail today is the quintessential oxymoron: The more serious the CIO is about keeping data secure and the more sophisticated a defense is deployed, the more points of vulnerability emerge.

For example, an especially risk-averse IT exec might opt for multiple distant off-site backup locations, which only increases the number of potential places and subcontractors that could lose—or maliciously access—those data files. Or security specialists who install a wide range of cutting-edge and redundant security applications may find themselves at the mercy of any crash-causing glitch in any of them.

Consider PCI. The most dedicated PCI program is subject to the whims of a potentially careless assessor, who would also be a potential data leak. Then there’s operating system changes for the sysadmin dedicated enough to immediately download and install every patch and security update, only to find that they open more holes. A less aggressive effort might have been spared that pain, as the community identifies the hole before it’s installed.

This came to mind as I was chatting the other day with Bill Homa, who on July 1 could say for the first time in 12 years, "Today, I am not the CIO of Hannaford."

PCI-compliant Hannaford was, of course, the victim of an especially large data breach (data from 4.2 million payment cards grabbed).

Homa has become a fan of simplification in battling security. "We used a lot of Linux," Homa said. "None of the breach was anything related to Linux. All of it was Microsoft."

Asked whether he believed that Microsoft is less secure because it’s truly less secure software or whether its overwhelming marketshare makes it a cyber thief target, Homa said it was the other way around. Microsoft’s marketshare is not what attracts so many attackers. "Microsoft is so full of holes. That’s why it’s still a target," he said.

Would he counsel other CIOs to avoid Microsoft like the plague? "That’s what I’d do. If you limit your exposure to Microsoft, you’re going to be in a more secure environment," he said, adding that Microsoft’s philosophy is decentralized, forcing IT to manage more points. That means more license fees for Microsoft and more potential security gotchas for the CIO. "Hence, you see my aversion to Microsoft."

As for the oft-repeated song that Hannaford was breached while PCI compliant indicates some sort of a PCI indictment, Homa said it comes down to two things: "Either the standards weren’t strong enough or the assessor wasn’t doing his job."

He finds particular fault in one aspect of the current PCI standard: "All debit- and credit-card transactions should be encrypted from end to end. That should be the minimum. It’s astonishing that isn’t the standard of PCI," which only requires encryption when transmitting over a public network such as IP.

The PCI rationale is that private point-to-point networks—such as the one Hannaford uses—are sufficiently secure that they don’t need encryption. Homa disagrees. "Nowadays, encryption is not that expensive. And there’s no such thing as a secure network," he said. "If you think your network is secure, you’re delusional."

Homa has his own strong security strategy, which seems to be a minority view. It’s futile, he said, to continually pour resources and time into securing the front door and windows of a house that is being relentlessly attacked by well-financed thieves with plenty of time. Instead of spending so much effort trying to keep the bad guys out, assume they’ll get in.

"Most retailers have the philosophy of keeping people out of their network. It’s impossible to keep people out of your network. There are bad people out there. How do I limit the damage they can do? If you don’t do that, they’ll have free reign to do whatever they want."


advertisement

12 Comments | Read Former Hannaford CIO: Avoid Microsoft And Change PCI’s Encryption Rules

  1. stingray Says:

    I work in the IT field, and part of my job is data security for a retail company. Knowing what I know, it just reinforces my motto, “Use cash wherever and whenever possible”. If we as a country would stop being led like sheep into the “use a card; it’s more convenient!” abyss, we would have to worry a hell of a lot less about security breaches of any kind!

  2. Randy Carr Says:

    Thank you Mr. Homa for your candor. Your comments about the futility of “securing the front door and the windows of a house that is being relentlessly attacked by well-financed thieves with plenty of time” is exactly why tokenization is gaining ground as a method of truly securing cardholder data. In addition to making systems secure, never allowing card data to enter the POS helps simplify the PCI compliance process. If the card data is not allowed to ever enter the POS and the entire transaction process takes place with a unique ID or Token, the front door and the windows can be left open. Under this concept, cardholder data is never stored, processed or transmitted. Therefore, if a thief gets in (and we agree they will) all they will find are useless Tokens. They can’t steal what you don’t have.

  3. Patrick Says:

    I find the comments interesting that the issue is either the PCI standard, or the assessor. PCI is a standard for managing security within the payment card world. Its no different than being ISO certified. Yes you go through an ISO assessment and ISO has its holes to be sure. But at the end of the day what occurs between the time your PCI certified, and the next re certification is on you as an organization. You can tell the assessors and show them one thing, and do something else. Microsoft is as insecure as any other OS. You have to care and feed them and it takes work.

  4. PCI Guy Says:

    Randy, you vastly misunderstand the scope of the security breach at Hannaford. The thieves would have read the data from the card swipe readers long before your “tokenization” system would have seen it. As Homa points out, storing card data off-site at a tokenization service just adds another location for hackers to attack.

  5. Steve Sommers Says:

    PCI Guy, Randy is referring to the Shift4 4Go line of tokenization products. 4Go encrypts at the reader prior to entering the POS or network. Tokenization can be used at various levels. The original “public domain” version addresses the storage and with this level of tokenization you are correct — it would not have helped Hannaford. But the 4Go level of tokenization would have.

  6. J.D. Oder II Says:

    PCI Guy/Randy Carr

    Though Tokenization may not have protected the entire transaction flow, it would cut out a major portion of large volume loss which occurs during the nightly batch upload.

    As far as their breach goes the “from the card swipe readers” comment is incorrect as it was the last mile on their networking circuit that really cause the problem. If one clamps onto someone’s leased line and that line is not correctly segmented and firewalled, then exposure might be possible. It of course also depends on the nature of their POS switch software and how it was implemented.

    Anyway, there are other approaches that exist along the same lines of the “Tokenization” that use the data replacement approach that would have solved this type of breach, they just unfortunately where not implemented.

    In addition, this “blame and complain” game against Microsoft is just nonsense. Microsoft is no less and no more secure than any other OS. It seems that one can simply ignore reality and say, “Its Microsoft’s fault” and that somehow makes everything ok.

    A PCI auditor can only do what he can do for a “moment in time”, so the burden is on the merchant to monitor his systems for software add, replace or change and to take appropriate action, not blame Microsoft for holes.

    Humans do make mistakes and without tokenization in place or at a minimum the use of Appropriate Configuration, File Integrity and Change Control Monitoring, breaches like this will continue to occur.

    If someone is “sniffing around” on someone’s infrastructure, then there is an “agent” that is performing that function. That agent is either built into the OS or is a rogue piece of software. Anyone with any networking experience knows that any agent built into the OS either needs to be locked down, disabled or removed (a foundation of PCI) If the software is rogue, then the change control software or file change system should have alerted the merchant of this fact, and the merchant could then have taken appropriate action to remove that rogue software and lockdown their systems

    The goal simply has to be to get as much volatile information out of the Point-of-Sale and each property endpoint as possible. That goal needs to be handled by using outsourced approaches, monitoring systems, by building “gold plated” software and networks and by using data removal or replacement software and techniques whenever possible and/or encryption solutions where those cannot be used.

  7. TheTruth Says:

    Interesting interview, wasn’t he the CIO of the company that was actually hacked? He seems to be blaming MS directly for the breach. I wonder if he ever signed a PO for an MS product during his tenure. If your relying on compliance with an industry or security standard to measure your overall security posture, your missing the boat on risk management and layered security. I don’t think it’s appropriate to take the position or assume that hackers are going to penetrate your perimeter security controls / network. Seems like the only person not to blame was the CIO. IMHO you have to spend in accordance with where your higher population of threat vectors maybe and their impact, whether it’s internal or external and technology isn’t inherently secure or insecure. Without consistent people and process, I believe most companies have a pretty good chance of ending up on page 1.

  8. trw Says:

    He was in charge when they got hacked and he is blaming Microsoft and/or the assessor and PCI? What a joke! He should look in the mirror since he was in charge of thier IT. End to end encryption is very difficult and costly to implement, but a decent (and quite affordable) IPS would have alerted that data was being sent out of their network to where it should not have been going.

  9. No-sale just friendly advice Says:

    Mr. Homa, I’m not buying it. Just as I would fail miserably working with budget/ROI or other business calculations you have failed to understand fundamental security principals. There is no single fix for security issues, it takes a well planned, layered approach to achieve the security level capable of protecting information. I would wager a month’s pay that your systems were not patched, that security logs were not collected (much less reviewed) and that ‘IF’ you had an IPS/IDS that no one monitored the information it reported. All of that sounds like it is defiantly the fault of MS and the PCI auditors. Care to take the wager…How about a rebuttal?
    I’d bet double or nothing that you did the minimum you had to for PCI (if you ran your security programs aiming to pass PCI or other compliance of the week, you missed the boat)
    For patching -absolutely review/assess and prioritize the deployment, but to ignore patches to avoid opening any new holes is beyond belief. Plugging a KNOWN hole is the lesser risk. As for avoiding MS, well be my guest and you’ll be no better off. All Operating Systems have problems and vulnerabilities and are only as secure as you make them. I fully agree with securing the internal areas of your network, but not to invest in protecting your perimeter is foolish (if you invite enough people in to take a crack at your safe, sooner or later someone will crack it). Another fundamental you should learn is that each layer of security serves a supporting role to the other layers. Your obviously and intelligent individual, put your rather obvious personal agendas aside and read some real security literature (not just CIO weekly) and if your half as smart as I give you credit for, you’ll quickly discover what went wrong and why.

  10. JAFO Says:

    I’m sure none of us who have replied have any REAL knowledge of what when down at Hannaford, while Bill Homa does. We can merely speculate.

    However, unless Microsoft had an unknown vulnerability that was being exploited by these attackers specifically – I don’t see how anyone can blame them. I am NOT a fan, but I am also not naive enough to say that MS is “full of holes” and Linux is soo much better. As many have said, all OS’s more pointedly – all Applications will have vulnerabilities, and patches.

    I do agree with Bill Homa, that the PCI DSS needs modification in regards to encryption. The thought that a service provider can “SAY” that a customer is on a private MPLS network – while the customer does not own any of the operation security of that network – is completely unacceptable. All traffic going over copper/fiber that you do not own and have 100% control over should be encrypted!

    That being said, the POS solution is also to blame. In no way is it acceptable for credit card data to be stored or communicated in an unencrypted manor. That needs to be fixed. With today’s level of technology there is no reason that the credit card data could not be encrypted from the moment the card is swiped – remaining encrypted through motion and at rest.

    Again – layered approaches to security.

    Of course, this is only my opinion, I could be wrong.

  11. Lucas Says:

    J.D. Oder II, I agree with what you said 100%. I am glad to see that several others have also left feedback, saying it’s BS that Homa is blaming everyone but himself.

    IMO, it takes two things for card data to get stolen electronically. 1) Poor information systems security, 2) Doing stupid things with card data such as transmitting it in plain text

    Homa wants to blame the PCI DSS because it doesn’t require you to encrypt card data over your private network (VPN between routers, P2P, etc.). I agree that this is a weakness, although not a big one. It will most likely be addressed in 1.2. It’s just plain common sense these days to treat cardholder data like toxic waste. The intent of the PCI DSS isn’t to tell you how to implement infosyssec play by play. Its intent is to provide a framework to start from. If Homa doesn’t “get” that, then I’m glad he’s being replaced. Heck, his “Blame everyone” attitude confirms that they were right to let him go. Personality issues.

    Homa wants to blame Microsoft because there was malware running on the servers. That’s right, it’s “The Man’s” fault and OSS would have saved the day. Please. What happened with PCI DSS requirements 11.4 (IDS/IPS) and 11.5 (File integrity monitoring software)? I’d imagine that something like Tripwire would have alerted them to the presence of malware.

    Now it’s time for some speculation.

    How did the malware even reach all the servers? I’ve heard hints that it may have been a compromised employee workstation (See: http://www.knowpci.com/index.php?option=com_mtree&task=viewlink&link_id=143&Itemid=99999999) that got the attacker past the perimeter into the soft, chewy center. Did they have a properly segmented network with protection from insider threat (i.e. employee workstation downloading free screensavers)? Considering that the malware got installed on over a hundred sites, I’d assume there was little to no network segmentation. Hell, someone could have probably hooked up a rogue AP at any location and had their way.

    I’m very upset that the PCI DSS has taken such criticism from media and community because of the misnomer that Hannaford was PCI compliant. Bullshit. They were PCI validated, but that doesn’t guarantee that they were complaint. Nobody has released the results of the forensic audit. I’d bet just about anything that they were compromised due to a lack of compliance.

    How about someone step up and does an evaluation of PCI validations and report on how valuable their validations are? Hannaford’s QSA was Verizon/Cybertrust. Cybertrust also took care of TJX. (See: http://www.storefrontbacktalk.com/story/042508hannaford)

    If an employee can download a Trojan and that leads to the compromise of over 100 servers spanning multiple sites, only Mr. Homa and his team can be blamed. Even if the PCI validation was crap, they are to still to blame for allowing a crap validation to be performed. How about Homa takes some responsibility, and fess up to what the real problem is. They didn’t do enough to protect cardholder data. How about he simply admit that many companies are only willing to spend a minimum amount of time and money because there’s no direct ROI. It’s an expensive insurance policy and everyone out there gambles that they won’t get hit based on how much they invest. Unfortunately, attitude isn’t changing even with the security breaches, fines, and bad PR. Companies still are unwilling to invest in real security until they are forced to or take a huge loss and learn a lesson first hand. The only difference now is that security companies are selling snake oil and rolling in easy money from companies that aren’t willing to properly invest. They’re just buying marketing and warm fuzzy feelings. Criminals will still compromise insecure networks and get card data.

  12. Steve Sommers Says:

    Can PCI be improved? Yes, definately.

    Is PCI to blame for this incident? No. PCI defines the MINIMUM security requirements and they should not be used as your overall security doctrine.

    As many have said here and in other threads, a PCI audit only reflects a point in time and is no guarantee for any other point in time. In fact, a ex-card association muckity-muck that is currently involved with PCI once told me, “PCI was written to protect the card brands, not the merchants nor the card holders,” and the wording PCI guarantees “any breach of card holder data can be attributed to a compliance failure.”

    If you’re using PCI as your security doctrine, you need to rethink your practices and think REAL security.

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...