Heartland Sniffer Hid In Unallocated Portion Of Disk
Written by Evan SchumanThe sniffer malware that surreptitiously siphoned tons of payment card data from card processor Heartland Payment Systems hid in an unallocated portion of a server’s disk. The malware, which was ultimately detected courtesy of a trail of temp files, was hidden so well that it eluded two different teams of forensic investigators brought in to find it after fraud alerts went off at both Visa and MasterCard, according to Heartland CFO Robert Baldwin.
“A significant portion of the sophistication of the attack was in the cloaking,” Baldwin said.
Payment security experts pretty much agreed that hiding files in unallocated disk space is a fairly well-known tactic. But it requires such a high level of access—as well as the skill to manipulate the operating system—that is also indicates a very sophisticated attack. One of those security experts—who works for a very large U.S. retail chain and asked to have her name withheld—speculated that the complex nature of the hiding place, coupled with the relatively careless leaving of temp files, could suggest a less-skilled cyberthief who simply obtained some very powerful tools.
But she cautioned against reading too much into whatever clues the culprits left behind, given that some might be deliberately misleading. “Anyone who has access to that level of the machine can make it look like anything they want,” said the retail security manager. “There is virtually no way to tell in a case like that what really happened. If they have a chance to lay down false trails, it’s pretty hard to find out what really happened.”
Consultants agreed that this type of attack would require extensive access and the ability to trick the machine into believing the thief has very significant user privileges. But it wouldn’t necessarily require modification of the OS directly. “They could have done it two ways. You can modify the OS or you can install a modified device driver.”
Another consultant—who also wanted his name left out—said the ability to write directly to specific disk sectors is frightening. “Somehow, these guys went directly to the base level of the machine (to an area) that was not part of the file table for the disk,” he said. “Somehow, they got around the operating system. That’s a scary mother in and of itself.”
More Details Emerge
Baldwin also added more details to the sketchy timeframes that have been revealed thus far about the attacks, specifying that Heartland was contacted by Visa and MasterCard “in very late October,” possibly October 28. The card brands had been unable to find a common point of purchase with a series of bogus cards, so they started to look for a common point of processor, which took them to Heartland.
The processor was then given a pile of problem cards to try and match. Baldwin said he didn’t know how many account numbers they were given, but said “it was at least in the hundreds. Not sure if it was more than a thousand.” Heartland quickly discovered that some of those names hadn’t even used any of Heartland’s networks, although many had.
Some of the problem might not involve common points of purchases or common points of processors as much as common points of high-tech hoodlums. Baldwin said Justice Department and U.S. Secret Service officials have told him “the bad guys they think got us have successfully breached other financial institutions.”
Apparently, federal law enforcement was focusing on suspects in other breaches when the Heartland breach became known, which explains the relative speed of the Secret Service identifying a key suspect, apparently in Eastern Europe.
And Heartland’s civil legal troubles are just starting, with one of the least surprising lawsuits ever filed. The litigation is the start of a class-action lawsuit that accuses Heartland of having “failed to take appropriate measures to adequately protect” its data. This new lawsuit, filed Tuesday (Jan. 27) on behalf of a consumer named Alicia Cooper, will likely run into the same issues that blocked the TJX class-action lawsuits. With zero liability cards, it’s unlikely the plaintiffs will be able to prove monetary damages. In today’s civil courts, that’s the ballgame.
Back to the timeline. After the card brands alerted Heartland in late October, it took about two weeks of internal investigation to conclude that, yes, the company had been breached. The initial internal conclusion was that “it looked most likely that it would be in a certain segment of our processing platform,” said Baldwin, adding that Heartland does not want to identify what that segment was. The company hired a forensic investigation team to come in and focus solely on that one area, an effort that ultimately proved fruitless. “We found issues in a large segment of our processing environment. The one that looked like the most promising turned out to be clean,” he said.
While the first team was working, Heartland had a second forensic team brought in to check the entire system. “That first firm had a very specific scoping of their assignment. The second firm was working in parallel on the rest of that processing.”
That second team “was nearing conclusion” and was about to make the same assessment the first team did: clean bill of health. But one of the last things that external, qualified risk assessor did was to try and match various temp files with their associated application. When some orphans—.tmp files that couldn’t be matched to any application or the OS—were turned over to Heartland’s internal IT group, they also couldn’t explain them, saying that it was “not in a format we use,” Baldwin said. More investigation ultimately concluded that those temp files were the byproduct of malware, and more searching eventually located the files in the unallocated portions of server disk drives.
Heartland officials said it won’t be known for certain who was behind this attack until all the investigations are complete. However, preliminary indications are pushing them to suspect a fully external attack, with no indications at this time of any help from any Heartland employee or contractor. “The existence of a key logger, that could certainly have been by an outsider,” Baldwin said.
Developing End-To-End Encryption
Heartland on Tuesday (Jan. 27) announced that it will be creating a new department that will be “dedicated exclusively to the development of end-to-end encryption.”
“PCI is a good and effective standard, but the bad guys have become more sophisticated to the point where encryption of data in motion appears to be one of the next required steps. There is no single silver bullet that will secure payment systems, and constant vigilance and monitoring of the infrastructure will always be required,” Heartland CEO Robert Carr said in a statement. “Nevertheless, I believe the development and deployment of end-to-end encryption will provide us the ability to implement increasing levels of security protection as they become needed.”
End-to-end encryption is far from a new approach. But the flaw in today’s payment networks is that the card brands insist on dealing with card data in an unencrypted state, forcing transmission to be done over secure connections rather than the lower-cost Internet. This approach avoids forcing the card brands to have to decrypt the data when it arrives.
Given that, most so-called end-to-end encryption approaches leave a small window of opportunity before the card is encrypted, and right after it’s decoded. The goal for most companies is to simply shrink that insecure window to as short a time period as possible.
CFO Baldwin was asked whether a more airtight resolution would be preferable. “The more players you have to get to change their behavior, you grow the challenge to get any change implemented exponentially,” he said, adding that “the actual amount of losses due to fraud is at a very, very low level,” which forces “an appropriate cost-benefit analysis. For the system as a whole, it just may not be worth it (to try and do a complete overhaul). We’re reducing that window rather dramatically, working with a limited number of players.”
Baldwin also said that a more aggressive effort would “slow down some systems in very significant ways. It would be noticeable.”
Clarification From Heartland
After this article was published, Heartland sent us a note and a call to ask us to clarify some details.
The story above reports that, ”after the card brands alerted Heartland in late October, it took about two weeks of internal investigation to conclude that, yes, the company had been breached.” Heartland spokesperson Jason Maloni said that Heartland didn’t conclude that they had been breached at the end of the two weeks, but had concluded that they might have been breached and chose to bring in two forensic teams. The distinction is whether, at the end of the two weeks before they brought in the two forensic teams, Heartland believed that it had been breached or merely suspected that it had been breached.
The story above also reports that the malware “eluded” those forensic teams and that, at the last minute, a cleanup of temp files discovered the rogue program’s trail. Maloni says that given that the trail was ultimately discovered by one of those teams, a better phrasing would have been that the program had temporarily eluded the teams.
The most significant—and vague—clarification request involves the specifics of where the malware was discovered. Maloni now says that “the forensic report with these answers is not yet complete” and that “CFO Bob Baldwin misspoke on this point.” Despite Baldwin’s comments in an interview that the malware “hid in an unallocated portion of a server’s disk,” Heartland is now saying only that some parts of the program were in the unallocated portion of the server’s disk, but that “substantive elements of the malicious software” were also located elsewhere. Maloni didn’t say what parts were where not what percents nor what he considered “substantive elements.”
-Marc
January 29th, 2009 at 9:30 am
If payment authorization data were truly end-to-end encrypted, starting at the chip in the customer’s smart card and protected by an air gap from computers and networks, and ending at the secured decryption equipment in the bank, none of the additional midpoints, including the retailers, networks and the payment processors, would have to do anything extra to protect the data from fraudulent use. No additional encryption would be required, no PCI auditing would be required, nothing. It would be cheaper and faster for everyone.
In addition, not only would the banks would become the primary focus of attack (and they’re better at defense than retailers,) a breached bank could expose only their set of customers. There would be no cases of 100 million unrelated cardholders’ data leaked.
The very idea that six million web sites, one million retailers and hundreds of payment processors can all be 100% airtight 100% of the time is ludicrous. The idea that we all have to spend millions of dollars protecting our systems from something that we shouldn’t even have to concern ourselves over is maddening, and borders on extortion. Rolling over and saying “the status quo is fine” is to continue to pile on the costs with no end in sight.
Even with no costs associated with fraudulent card use, we’re still pouring serious money down the drain on PCI assessments. I believe we could have converted our systems to handle secure payment authorizations for less than 25% of the cost that we’ve spent complying with PCI so far. And our PCI auditors will be back for the 2009 season beginning in a month or so. There goes more money that we can ill afford to waste.
And I should think the payment processors would rejoice in such an upgrade, instead of opposing it. Protectionism shouldn’t enter into the equation. The value they add today is not in the secure handling of data, but in the consolidation of communications to the thousands of member banks and the aggregation of the payment process. In the future, their role might even evolve to become the guarantor of a bank’s legitimacy, protecting merchants from potential fraudulent “pop-up bank” attacks. I know retailers don’t have the capacity to evaluate every new bank that comes along.
Merchants and processors should band together to demand these changes from the card associations and banks, and soon. We have to end the waste while we’re still solvent.
January 29th, 2009 at 11:02 am
Better yet and less expensive would be to require all cards to provide a cvv, expiration date and possibly a zip code. The information could be verified internally and the card number would be verified with the sale as it is today. By requiring information that is on the card and verified before (swiped card) and without transmission for processing and after with confirming information (non swipe application), the card number alone would be totally useless.
Each device or application that takes payment should encrypt data that is being transmitted and should require SSL as well. This isn’t hard to implement and shouldn’t be expensive. Today the information is tranmitted over public lines, phone or internet. to the procesosr. Once the processor receives it, it is transmitted for authorizaton over a secured dedicated network, or it should be. The point of encryption is at the device / application and dencrypt at the
processor.
PCI does have a number of valid regulations, however, PCI is only worried about the Network and the card information, Not how the card number is transmitted and Not what is required for a safe transaction, SSL and SSL2 have been hacked for years.
Multiple databases should be required, one for the card the other for the cardholder and one for the transaction. The cardholder information if stored should be encrypted as the cardnumber. No where should any part of the card information be stored. Transaction data, such as total cost, tax, order number, etc… can be stored unencrypted.
Decisions have to be made on what is required for safe transaction or what is required to identify and market consumers. Both can live in the same world but they are seperate processes that required seperate security.
January 29th, 2009 at 12:11 pm
Given that the same attackers apparently breached other networks and were already under investigation, isn’t the simplest explanation for the forensic teams finding the malware solely in unallocated space simply that it was deleted before they located it, not it was running completely in unallocated space the entire time?
Malware is found in unallocated space. That’s fine, I can buy that, I’ve found plenty before. The article goes on to speculate that the reason for this is some hacker secret sauce, as opposed to the normal reason items end up in unallocated space – *because it is deleted*. I'[ve written more on this here: http://posthumorous.com/article.php?story=20090129104115815
January 29th, 2009 at 2:04 pm
Please keep in mind that the cost to convert the US payments infrastructure to smart card/chip and PIN is in the range of $15 billion. Of the three major participants in the payment chain (banks, retailers, consumers), which one do you suggest is in the best position to pay these days? The fact is, solutions to the present data crisis will need to found in fixing the current infrastructure rather than replacing it with the next new thing.
January 29th, 2009 at 3:02 pm
Howard,
That’s just more of the same “pile on the protection” mentality that leaves us exactly where we are today. So we encrypt data at a few more points, but then we decrypt it just before it leaves our system so it can travel SSL to a processor, who extracts the cleartext data and then reencrypts it. We’ll spend a million dollars to achieve this, we’ll spend another million having the PCI auditor bless and approve it, and the attackers will simply shift their attack to the decryption point. Millions of dollars more will be spent, and hacks will still happen.
But they can be stopped completely.
There is cryptographic technology in use today by some European banks that use a smart card to produce a one-time-use “authorization token”. The token generation happens only when the cardholder enters their PIN into their card — not the merchant’s terminal. The card is hardware owned by the bank, contains a private key injected by the bank, and is quite secure. The decrypting side is also hardware owned by the same bank, and is also secured by them. The authorization data itself is good for a single transaction, and it does not matter if it is sniffed by an attacker — it is only good for a single transaction.
With this change, merchants and processors can hand card numbers around with no particular caution. The card number itself is useless for trade without the authorization to use it.
The security of the system becomes the sole responsibility of the bank, and happens only inside bank-owned and controlled hardware. Neither retailers nor payment processors have to go through heroics to guard the data.
This technology is not ground-breaking. It is in use today. It could theoretically be adopted bank-by-bank with no changes to retailers’ POS systems by using the existing PIN equipment to carry the new authorization data.
What is lacking is the will to change the current process because we don’t think it hurts bad enough, but mostly because we are terrified of making a real change. Well, PCI compliance is taking money from all our pockets. That hurts plenty these days. And the change doesn’t mean the end of easy-to-use credit. It would add immeasurably to consumer confidence in the use of credit, strengthening web sales and reducing customer fears of “will this waiter skim my card?”
January 29th, 2009 at 10:42 pm
“it does not matter if it is sniffed by an attacker — it is only good for a single transaction”
It only takes one transaction for someone to steal your money…Also, its good for a single transaction ANYWHERE (as apposed to per-merchant-passwords). If the data can be sniffed, it can likely be intercepted, so subvert the order information (e.g. product and/or delivery address).
Oh, and I’m sure people will end up losing PINs because of dirty fingerprints left on the keypad that lives on their credit-card! Will make the card itself more valuable, increasing the physical danger to cardholders.
January 30th, 2009 at 9:20 am
The article mentioned a VERY large number of temp file.
What about a very simple tool such as an integrity checker that tells you about new files, deleted files, modified files, or any changes to critical files.
I was taught that was a basic standard to have such tool.
I guess they are not as sexy as IPS and this is why people do not use them. Even the most basic Host Based IDS would have detected such pattern.
Keep it simple
Clement
January 30th, 2009 at 10:25 am
“Some Other Reader” is right – I’ve seen systems utilizing these “authorization tokens” (known as One Time Pads – http://en.wikipedia.org/wiki/One-time_pad) breached, and these were not even systems processing financial details. The attackers were simply after access to the computing resources involved.
However – it would be an excellent security measure to put in place since to deter criminals with a financial motive you simply have to make the cost of acquiring the data illicitly greater than the payoff. Right now attackers are capable of running off with hundreds of thousands of cards by compromising a handful of machines. Riding an existing authorized transaction and adding a fraudulent transaction *should* be exceedingly difficult, time consuming, and of little reward if OTP were implemented properly.
January 30th, 2009 at 1:07 pm
To combat criminals you must have their skills. All you book smart, conference going, straight arrows can argue your point till your blue in the face but unless you have the counter technology security skills AND can execute them your designs are outdated. Given the architecture of the American credit/debit network today a radical change is needed to offer individuals protection from the security knowledge deficient companies ‘touching data’ along the transaction life-cycle. The only way to know security is to live it.
January 30th, 2009 at 1:57 pm
Actually, there are other techniques now available that solve this problem much more completely and easily – and permit true end to end encryption of data without the complexities that plagued us in the past.
Traditional approaches to encryption suffer complexities that hamper success, scale, and meeting end-to-end protection: key management complexity and the diversity and legacy nature of most IT/Processing systems make traditional encryption difficult to deploy (ancient Non-stop systems anyone? :-). In addition, regulatory compliance with e-discovery/forensic and data recovery needs can be make investigations and contemporary real time fraud analysis extremely difficult.
There is a method called “Format Preserving Encryption†of using 256 or 128 bit for that matter AES Encryption which can be used in such a way as to encrypt any field (PAN, Expiry, Name, Address, SSN, National ID number etc) without changing its structure, without sacrificing strength whilst retaining format and referential integrity – even across data stores. Sub fields of a data structure like a PAN eg. Issuer/Routing data can be independently encrypted to the 6 digit account code, last 4 and so on, or certain segments can be left in the clear, and in practical implementation different roles and permissions can be applied to each encrypted field or sub field to permit “need to know†access controls from system or person to data.
This method is also being considered as part of the US NIST AES Standard (FFSEM mode AES). In essence this now enables direct encryption in place with an existing data structure or field and eliminates the need for tokenization databases and lookups – as the 256 bit AES space is the token map per 256 bit key. This allows POS capture to clearer end to end protection – but without impacting intermediate systems – key management and rollover is also completely handled, and in fact stateless. The technique of FPE is provably secure to the same strength as regular block mode AES – hence the NIST interest.
In terms of solving the key distribution issue and handling rollover, there is a public key technique called Identity Based Encryption (IBE). IBE permits any string – e.g. an email address, a serial number, a unique identifier etc or even a variable string like “serial number + date†to be used as a direct public key – the corresponding private key can be derived in near real time from a key server (somewhat analogous to a Root CA in traditional PKI) after authentication. This stateless approach also simplifies operations – no key database to manage or Secure or continuously sync to DR sites and so on.
So, FPE allows direct encryption – e.g. from POS to the back end – clearer/acquirer. IBE combined with FPE can also solve some difficult challenges, such as when POS systems have no ability to secure a key locally, offline POS cases and card capture in low cost mobile devices.
Fortune 500 Firms/Tier 1 merchants do in fact use these techniques to address large scale complex privacy regulations such as PCI DSS, GLBA, HIPAA etc.
So, other than merchants who copy the plastic in the store (small volume threat)- the problem of protecting vast data sources such as transactions systems at rest, in motion, and in use is a solvable problem – and in a practical and economical manner.
January 31st, 2009 at 7:54 pm
Everyone seems to be overlooking the fact that the windows or unix platforms which were undoubtedly in use are relatively amateur operating systems. This type of attack cannot be implemented on a z/OS mainframe.
February 1st, 2009 at 3:20 pm
@Robert Smith
Your reasoning is fun. A box of post-its would not suffer from this attack either, which in no way means it would represent a more secure solution.
If it’s doing any network communication, it’s subject to attacks, and it’s close to certain, that it can be breached. Any design should be aware of this and try to minimize or eliminate the consequences of a breach …
February 1st, 2009 at 7:58 pm
@Robert Smith
Let’s not get into pointless “my OS is better than your OS” arguments.
What I haven’t seen answered here is how the malware was installed on the server in the first place. No matter what the OS, the fundamentals to protecting the server should still apply: uninstall non-essential software (if this server had email/browser installed – shoot that IT “pro”), disable non-essential services, isolate from both public and private networks with firewalls locked down to the barest minimum of open ports and even these ports should only be open to specific IP addresses. Unless this was an inside job (and nobody seems to be suggesting that it was), the opportunity for an external attack is almost nil if best practise is followed. I’m guessing now, but my guess is that the server wasn’t sufficiently protected from the rest of Heartland’s private network and the malware was planted via a compromised end user machine.
February 2nd, 2009 at 11:01 am
@Clement Dupuis
File integrity check systems are a PCI requirement however system operations personnel typically configure to ignore locations with known transient data to reduce false positives.
File intergrity systems that are signature and rules based may seem less susceptable to false positives but that may be because the rules are too simplistic.
It all boils down to due diligence by humans, there is no technological magic bullet.
February 2nd, 2009 at 5:43 pm
Chip and Pin (something you have and something you know) has been used in Europe for several years. It would be interesting to see an article on the results. The various opinions are interesting, but what are the statistics? Did Chip and Pin actually improve the situation or not?
February 3rd, 2009 at 1:04 pm
To “PaymentArchXpert”, can you provide greater insights? I recognize your point and agree. I would like to learn more about what companies like Heatland Payment Systems should know and do to prevent breaches from such sophisticated attacks. I am a consultant to large banks and healthcare organizations. My clients should learn from the Heartland Payment breach. But if all I have to share is that they should add encryption, I’m not sure they will change their way of managing their systems and data. If you prefer to send a private email, that works for me. I have provided my email below.
Regards,
Archie Kline
archiekline@gmail.com
February 3rd, 2009 at 2:01 pm
@Some Other Reader,
Being good for only one transaction means just that: even if it’s sniffed, only the original transaction goes through. A second transaction with the same authorization code is blocked by the bank. Sniffing these transactions is safe.
@Cory Altheid,
These devices do not contain one-time pads, which is a completely different algorithm. These are devices that generate pseudo-random numbers and encrypt them using a private key stored in the smart card. I don’t want to get into a long discussion of the cryptography, but the end result is the only two cryptographic devices used in these transactions are both owned and secured by the bank. The only security required of the retailer is that needed to prevent a third party from collecting the payment from the customer instead of the retailer, and that’s the retailer’s problem, not the customer’s.
@Mark Bower,
Again, your suggestion leaves the burden of handling sensitive data in the retailer’s POS system, although for less time exposed than it does today. It doesn’t stop skimmers from being effective. It doesn’t stop insecure POS systems from leaking data. It doesn’t stop fraudulent merchants from stealing data. By moving it to the card, owned by the customer and protected by the bank, the protection is in place before it hits any of the retailers or processors. All these problems are solved.
February 3rd, 2009 at 2:24 pm
Chip & PIN in Europe.
anecdotally C&P has improved fraud quite a bit (both at point of sale and in payment processing), but not eliminated all hacks and has moved some exploits off-shore.
Hacks have moved to making physical changes to the chip & pin terminal in store to capture the card number from the stripe or chip and the PIN from the keypad. There has even been a batch of terminals with hacker module installed somewhere in terminal supply chain, only easily detectible by weighing the terminal hardware (Google “Shell PIN hack” for some details). And more hacks now happening to card not present commerce like mail order, phone order & support (call centres around the world) & websites.
The main exploit is once you have card number and PIN (from a hacked C&P terminal or by very good video camera observation e. g. at an ATM), you can create a non-chip magstripe card and use it in ATM machines in countries that don’t support Chip & PIN yet or where ATM has fallback to magstripe where chip can’t be accessed, and then draw funds.
So lack of adoption of C&P in USA actually HURTS people in countries that have C&P!
February 4th, 2009 at 1:06 pm
To (anonymous) “A reader Says”: in relation to my comment.
“Again, your suggestion leaves the burden of handling sensitive data in the retailer’s POS system, although for less time exposed than it does today. It doesn’t stop skimmers from being effective. It doesn’t stop insecure POS systems from leaking data. It doesn’t stop fraudulent merchants from stealing data. By moving it to the card, owned by the customer and protected by the bank, the protection is in place before it hits any of the retailers or processors. All these problems are solved.”
First, the approach described encrypts after swipe – it does not require sensitive data to be stored and managed by the POS -this is an inherent property of IBE (a Public Key Technology).
However, anything that sits either photographing the card from above (to OCR read it as its swiped, and perhaps also recording the PIN as its entered) or similar skimming techniques are always feasible if the cardholder data is static and presented to a device as it is today – but that kind of attack is more expensive to mount – each POS line or lane has to be compromised. Contrast this to attacking the core data repository of a vast array of cards then clearly one is more lucrative and more a target than the other.
I’ve even seen cases where entirely fake card readers and POS devices have been installed in merchants to allow payments yet siphoning off cardholder data for later upload – cases in Hong Kong in the 1990’s for example. Its not a new attack vector – its classic interception, clever hacking, and social engineering at play.
The key to managing large scale breaches however is to mitigate risk, and make attacks more expensive, more complex, and easier to detect and thus less attractive than other data targets. Nothing is perfectly secure – security is an issue of time and money of an attack.
In respect to the encrypt at Chip – This is clearly a vision of the card issuers, but the simple fact is that this is a very long term strategy, and until the entire world is uniform, the current problem of mag stripe swipe call back and the related data risks will be ever present. The standards around this also vary – Dynamic vs static authentication of chip, application on chip, POS application, clearing application, and static card identity material – perhaps these need revisiting now against current threats – EMV assumes many trusted environments. This is a **huge** investment – multiple tens of billions – in a hard economic climate.
However, if we are to solve and mitigate threats that exist *now* against systems in place *now* we need to step back from purism, and take pragmatic and tactical steps with an eye on what may come.
I have exprience these systems first hand – right down to the Silicon and OS level with experience in Mondex, Visa Cash, MULTOS, EMV, GSM SIMs, Digicash etc – at a standards level and at implementation level. Chip itself isn’t just the answer, but its a technology that can help. Think also how you use your nice Visa Chip cards or Amex Blue cards to buy on amazon.com for instance….today in your own country that mandates and has implemented C&P….its been the “year of the smartcard” for a couple of decades now!
February 9th, 2009 at 7:07 pm
I’m sorry, you’ll have to do more to convince me that chip & pin is the panacea chip manufactures would have you believe. My guess is that threads identical to this will still be dominating the payments industry even after the $15 Billion+ conversion to chip & pin.
There are much less costly solutions currently available. Someone already mentioned the “format preserving encryption.” There are encryption drivers at the point of the swipe, there are hardware encrypted swipe devices. Heck, simply requiring end-to-end encryption on local networks (hardware or software), most likely would have prevented the Heartland and Hannaford breaches and others.
Lastly, to my knowledge, chip & pin does not address ecommerce, recurring, or hotel environments (check-in/check-out) so you’re still going to need a secure “other” system.
February 13th, 2009 at 3:27 pm
Chip & PIN absolutely is a panacea for PCI issues. Not only does it completely isolate and secure card data from the merchant’s equipment all the way to the card issuer but, assuming someone does get a card number, they can’t use it–the number is no good without the card and the PIN. And it’s fantastic for eCommerce; just add a $10 card reader to the USB port and the transactions are completely secure.
Likewise, regarding recurring & hotel transactions, of course those are supported. Do you think they don’t do those things outside the USA???
February 16th, 2009 at 2:14 pm
Be careful: the Chip & PIN solution deployed in England is not the secure solution I’m advocating. C&P is not fully secure because it still relies on the merchant’s terminal to perform the real PIN entry. Counterfeit terminals are still a real risk with C&P.
The technology I am referring to uses a bank-owned and customer-carried one-time-PIN generator. Not only is it secure in a hostile retail environment, but can also be safely used over the web.
February 16th, 2009 at 5:27 pm
Agreed, there are good and bad ways to implement C&P, and the static authorization approach is not much better than a magnetic stripe. But EMV with dynamic data authorization is very, very good. Under the DDA system, using just the card number with the PIN is not sufficient. A compromised PIN entry device provides little benefit to hackers when the corresponding card is required for generating the appropriate cryptographic signature.
Using a one-time PIN generator is another good approach, but EMV with dynamic data authentication is excellent and it’s already a standard that is being deployed in many markets.
February 17th, 2009 at 8:27 am
You must keep it simple. End to end encyption is not the answer. The cost to the merchant, processor, financial insitution is huge. This is a great solution for software vendors and hardware manufacturers but is not the solution to protect consumer data. The best method of defense is to have a multi-layered security infrastructure not relying on a single technology, firewall, or IPS system.
February 20th, 2009 at 2:27 pm
What amazes me is the lack of shared information after a breach. As a Level I Service Provider I am not aware of any groups or associations that meet routinely to discuss breaches, how to best prevent breaches and alike. Clearly from this blog there are a number of opinions on this topic. Perhaps it it time to put aside the privacy issues (i.e. can not share that information with you mentality) and design a solution that we can all sleep at night.
February 20th, 2009 at 4:12 pm
Editor’s Note: Whether this will prove ironic or merely hypocritical won’t be known for a few months. But I simply love this Jan. 23 statement–just three days after the breach was admitted–from Heartland CEO Robert O. Carr.
“I have talked to many payments leaders who are also concerned about the increasing success and frequency of cyber crime attacks,†Carr said. “Up to this point, there has been no information sharing, thus empowering cyber criminals to use the same or slightly modified techniques over and over again. I believe that had we known the details about previous intrusions, we might have found and prevented the problem we learned of last week.â€
The problem? Since that comment was issued, Heartland’s statements have been interesting, but not fulfilling. We still don’t have explicit details about how they got in and precisely what they did when they got there.
In other words, we still do not have from Heartland the exact kind of details that other processors and retailers would need to prevent this from happening to them. If he’s going to complain about how others didn’t share any info with him, you’d think he would share more with others. Maybe he’s more of a “do unto others as they have done unto you” kind of guy.
March 14th, 2009 at 12:29 am
FWIW, when discussing the costs to convert the current U.S. payment infrastructure, whether it be $15 billion (wherever that number came from) or some other number, keep in mind that a recent report (Unsecured Economies: Protecting Vital Information) suggested that data breaches worldwide cost businesses as much as $1 trillion dollars (US$) in 2008.
Now, the report doesn’t provide us a breakdown of cost to U.S. businesses but if the total costs are even half the reported estimate, it would seem that there just may be a compelling cost-benefit argument to changing the payment infrastructure.