Former Hannaford CIO: Avoid Microsoft And Change PCI’s Encryption Rules
Written by Evan SchumanBill 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."
-Marc
July 11th, 2008 at 6:57 am
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!
July 11th, 2008 at 11:15 am
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.
July 11th, 2008 at 11:22 am
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.
July 11th, 2008 at 2:29 pm
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.
July 11th, 2008 at 6:03 pm
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.
July 11th, 2008 at 7:43 pm
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.
July 11th, 2008 at 8:00 pm
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.
July 12th, 2008 at 10:02 am
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.
July 14th, 2008 at 9:46 pm
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.
July 15th, 2008 at 2:39 pm
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.
July 21st, 2008 at 10:39 am
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.
July 23rd, 2008 at 2:58 pm
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.