Encryption and tokenization are great security tools—when executed properly—as they sidestep protecting data and instead attempt to make the data worthless to thieves. It's a great strategy. But when it's executed improperly, it can insidiously weaken security. This happens when IT gets cocky and overconfident that the data would indeed be worthless to attackers and starts to get lax implementing strong prevention tactics, such as firewalls.
What brings this all to mind is Apple's new approach—unveiled June 13—called Differential Privacy. Apple is using mathematical encryption techniques to anonymize data. But Apple is being infuriatingly vague as to the precise mechanics of Differential Privacy. For security professionals, this is a concern. Many will be tempted to try and replicate Differential Privacy in an attempt to anonymize other kinds of data and make them theoretically less attractive to thieves. But if doesn't work, the almost inevitable security complacency from believing that it is working is frightening.
This is how Apple's news release described Differential Privacy: "Starting with iOS 10, Apple is using technology called Differential Privacy to help discover the usage patterns of a large number of users without compromising individual privacy. In iOS 10, this technology will help improve QuickType and emoji suggestions, Spotlight deep link suggestions and Lookup Hints in Notes."
In its developer release notes, Apple got microscopically more specific: "iOS 10 introduces a differentially private way to help improve the ranking of your app’s content in search results. iOS submits a subset of differentially private hashes to Apple servers as users use your app and as NSUserActivity objects that include a deep link URL and have their eligibleForPublicIndexing property set to YES are submitted to iOS. The differential privacy of the hashes allows Apple to count the frequency with which popular deep links are visited without ever associating a user with a link."
Apple has also said: "To obscure an individual’s identity, Differential Privacy adds mathematical noise to a small sample of the individual’s usage pattern. As more people share the same pattern, general patterns begin to emerge, which can inform and enhance the user experience."
Here's where things go off the proverbial rails. Differential Privacy has mathematical limitations, but it's hard to know when those limits have been reached.
This was a terrific writeup on this in Cryptography Engineering, which addressed the programming realities—and limitations of this approach.
"It goes without saying that the simple process of 'tallying up the results' and releasing them does not satisfy the DP definition, since computing a sum on the database that contains your information will potentially produce a different result from computing the sum on a database without it. Thus, even though these sums may not seem to leak much information, they reveal at least a little bit about you," the story said. "A key observation of the Differential Privacy research is that in many cases, DP can be achieved if the tallying party is willing to add random noise to the result. For example, rather than simply reporting the sum, the tallying party can inject noise from a Laplace or gaussian distribution, producing a result that's not quite exact -- but that masks the contents of any given row."
But, the story continued, it gets messy after that.
Although "the amount of information leakage from a single query can be bounded by a small value, this value is not zero. Each time you query the database on some function, the total leakage increases and can never go down. Over time, as you make more queries, this leakage can start to add up. The more information you intend to ask of your database, the more noise has to be injected in order to minimize the privacy leakage," the story noted. "This means that in DP there is generally a fundamental tradeoff between accuracy and privacy, which can be a big problem when training complex ML models. Once data has been leaked, it's gone. Once you've leaked as much data as your calculations tell you is safe, you can't keep going -- at least not without risking your users' privacy. At this point, the best solution may be to just to destroy the database and start over. If such a thing is possible."
Exactly. And that brings us back to the key point. These systems are a convenience and little more. Any of these data-obscuring tactics are, by their very nature, limited. Take payment data tokenization. It's pointless if it can't be reversed, such as to deal with a return. And if it can be reversed, it's foolish to think it's valueless to a thief.
One of the early big data-breach victims in retail—TJX—famously told the SEC back in 2007 that its attackers had stolen the chain's decryption key, making encryption irrelevant. But not to worry, TJX told the feds, because the attacker stole the data before it was encrypted, so all is well.
And nowhere is this fear more needed than when trying to protect apps. App data is where the bulk of data-fraud activity will happen over the next few years and it's the most tempting place to cut security corners. After all, proper security limits what apps can do and how it can do them. It will be irresistible for some to not want to believe that data can be obscured, thereby allowing security corners to be cut.
Don't believe it. There is no replacement for redundant security levels and when anyone starts chattering away about "this makes the data worthless to thieves," ask them if your team can itself access it. And then allow logic and common sense to have their day.
By Evan Schuman
Evan Schuman has covered IT issues for a lot longer than he'll ever admit. The founding editor of retail technology site StorefrontBacktalk, he's been a columnist for CBSNews.com, RetailWeek, Computerworld and eWeek and his byline has appeared in titles ranging from BusinessWeek, VentureBeat and Fortune to The New York Times, USA Today, Reuters, The Philadelphia Inquirer, The Baltimore Sun, The Detroit News and The Atlanta Journal-Constitution.
Security Breach at TJX — Analysis
TJX failure points that require attention
The data breach at TJX had taken place through multiple points of attack, the breach revealed several security vulnerabilities which are discussed below:
TJX used Framingham system in US and Puerto Rico, Watford system in UK and Ireland to process and store debit and credit cards, cheque and unreceipted merchandise-return transactions of customers. The data was encrypted before it was stored using the encryption software WEP. Investigations revealed that the intruders had access to the decryption tool and that data was primarily stolen through a hacking technique called “skimming”. This involves stealing data during the payment card approval process, when data is transmitted to payment card issuers without encryption. Poorly secured in-store computer kiosks were also identified as failure points that led to the breach. TJX allowed people to apply for jobs electronically using the kiosks which ultimately acted as a gateway to the company’s IT systems. It was revealed that intruders used USB drivers located at the back of these terminals to load software and that the firewall was not strong enough to defend against the malicious traffic coming from the kiosks. Improperly secured WI-FI network was another failure point through which hackers decoded data streaming between hand-held devices and store computers and led to hacking of the central database. WSJ quotes “The $17.4-billion retailer’s wireless network had less security than many people have on their home networks, and for 18 months the company had no idea what was going on”.
Initial press releases by TJX stated that 45 million payment cards where effected by the breach but fillings made in federal court of Boston arguing for a class action status showed that the effected numbers where as high as 94 million card holders. Michael Maloof, chief technology officer at Trigeo Network Security Inc says that “The large discrepancy between the numbers supplied by TJX and those from the banks suggest that TJX did not have the log data needed to do a proper forensic analysis of the incident”. All too often, he said, companies that don’t have processes in place for collecting and storing log data wind up losing the telltale tracks left behind by computer intrusions. Further supporting this theory is the investigation by Verizon Business RISK Team on breaches occurring from 2004 to 2008, which revealed, “66 percent of victims had sufficient evidence available within their logs to discover the breach had they been more diligent in analyzing such resources.”
Employees at TJX where not vigilant enough to prevent unauthorized access to terminals. Investigations had revealed that data thieves swapped the store’s PIN-pad terminal with an identical device that had been electronically altered to capture customers’ account numbers and PINs and that the thieves returned to the store, few days later to replace the original terminal, and made off with the altered one containing customers’ account information. All this went unnoticed by the staff. Further TJX was not practicing PCI standards regarding storage of information, encryption, access controls and firewalls.
Recommendations to improve IT security at TJX
According to Verizon Business Risk team, “The majority of breaches still occur because basic controls were not in place or because those that were present were not consistently implemented across the organization”. They add, “Most of these incidents do not require difficult or expensive preventive controls; mistakes and oversight hinder security efforts more than a lack of resources” (NetForensics, 2009). TJX has two distinct areas where they need to focus on: Short-term priorities and long-term plans to prevent another attack of this scale.
Short-term priority of TJX would be to identify all the security loopholes and tighten and improve the systems security. The following are some of the recommendations to improve their security in the short-term:
1) Replace existing Wireless Equivalent Privacy based wireless systems with Wi-Fi Protected Access.
2) Should not save the magnetic stripe contents of customers’ credit and debit cards. (PillsburyLaw, 2009)
3) Should purge all unnecessary customer’s information saved on its systems. Ashley Madison did not delete users data even after the users deleted the accounts and hackers were able to get access to the data. (Wired, 2015)
4) Should change encryption methodology of the data they are using to save personal identification information of their customers.
5) Should review what information gets collected from customers and not ask unnecessary information or not rely on driver’s license number or SSNs to uniquely identify the customers.
6) Should disable USB access to all in-store kiosks. Also should lock down the kiosks so that customers using the kiosks cannot open any other applications on them.
7) Have firewalls that segment the systems that contain sensitive information from other systems traffic and also have access controls in place to prevent unauthorized access to any system. The hack at Target occurred when HVAC system was able to connect to central Target systems. (BGR, 2014)
8) Should also review their ecommerce site to make sure it is secure and has no flaws like SQL injection attack. (Wired, 2015)
TJX needs to realize that spending money on IT security is a business decision rather than a technology issue. Some of the recommendations to improve their systems security:
1) Have a process where they update all their critical software components and also apply any of the security patches released by the software vendors.
2) Hire white-hat hackers to detect loopholes in the systems and fix them before actual hackers detect and exploit them.
3) The current hack at TJX happened due to ineffective logging and also not monitoring the logs. Having log monitoring and doing log analysis to detect anomalies would greatly improve their system. There are many vendors providing such solutions and TJX should invest in it. Software like Fisheye and Splunk Prelert detect malware by analyzing logs at real-time.
4) Put in place a training program for all the associates to not leave terminals unattended, connect their personal devices to in-store network or browse web from in-store computers. Some of the biggest hacks occurred when the employees clicked on links in suspect emails resulting in letting an intruder into the system. (BGR, 2014)
5) Upgrade the POS systems to use “Chip-and-PIN” technology enabled card readers, which protect credit and debit cards. Majority of the retailers got hacked due to POS malware and having Chip and PIN enabled card readers would have protected them. (KasperskyLab, 2014)
TJX role in the security breach
A group of 11 people known as the Gonzalez gang named after the leader Albert Gonzalez was charged responsible for stealing more than 40 million credit and debit card numbers from Framingham, Mass.-based TJX and eight other retailers. These included some of the largest reported hacks of all time, including BJ’s Wholesale Club and DSW. The gang was from Miami, the same city where officials believe the TJX heist began, when hackers broke into the insecure wireless connections at two Marshalls locations. Although the hackers were the main cause for the breach, TJX was equally responsible. Ericka Chickowski, a journalist covering information technology and IT risk management says “The record-breaking breach suffered by the TJX Companies didn’t just happen — it was the result of conscious choices made by the retailer’s IT executives to risk not adopting security best practices, and regulators’ decisions to treat the retailer with kid gloves”. Even though PCI data security standards such as establishing a secure network, encrypting data during storage and transmission and well enforced access control measures were established by credit card processors in 2004, which is two years before TJX announced its data breach, TJX did not establish all the requirements for a long time. For instance, it was storing card numbers, expiration date and card verification value codes, all of which are prohibited by PCI. PCI also states to not rely on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN, it suggests the use of Wi-Fi-protected access (WPA or WPA2) technology, IPsec VPN, or SSL/TLS to encrypt transmissions. Instead of strongly enforcing the rules credit card processors like Visa gave TJX multiple passes. An email from the CIO of TJX that went public indicated that TJX was more concerned with saving money and skipping auditing requirements rather than increasing security. In the mail Butka had suggested that they can be PCI complaint without upgrading to WPA technology and that TJX should take advantage of the leniency to save cash, in spite of the security risks, not all of the staff at TJX agreed with this and a senior level IT staffer forewarned that “The absence of rotating keys in WEP means that we truly are not in compliance with the requirements of PCI. This becomes an issue if this fact becomes known and potentially exacerbates any findings should a breach be revealed.” This went to show the TJX had cut corners.
1) NetForensics Whitepaper, 2009. Think Data Breaches Can’t Happen To You? Think Again. Retrieved from https://developer.cisco.com/fileMedia/download/2f0e334b-d579-4b02-9074-3d9504954c22
2) Pillsbury Law, July 2009. TJ Maxx Settlement Requires Creation of Information Security Program and Funding of State Data Protection and Prosecution Efforts. Retrieved from http://www.pillsburylaw.com/siteFiles/Publications/7F4F43B367B5276B0CFA6D13CFF4044C.pdf
3) Wired, August 2015. Answers to Your Burning Questions on the Ashley Madison Hack. Retrieved from http://www.wired.com/2015/08/ashley-madison-hack-everything-you-need-to-know-your-questions-explained/
4) BGR, Mar 2014. It turns out Target could have easily prevented its massive security breach. Retrieved from http://bgr.com/2014/03/13/target-data-hack-how-it-happened/
5) BGR, Feb 2014. Here’s how the Target hackers pulled off their incredible heist. Retrieved from http://bgr.com/2014/02/06/target-hackers-credentials-theft/
6) KasperskyLab, Dec 2014. 2014: the year of retailers getting hacked over and over again. Retrieved from https://business.kaspersky.com/2014-the-year-of-retailers-getting-hacked-over-and-over-again/3452/