Attacks/Breaches
4/22/2014
02:21 PM
Connect Directly
RSS
E-Mail
50%
50%

Michaels Data Breach Response: 7 Facts

Could the retailer have done more to spot the eight-month intrusion in the first place?

20 Great Ideas To Steal In 2014
20 Great Ideas To Steal In 2014
(Click image for larger view and slideshow.)

Retail chain Michaels last week disclosed that 2.6 million credit and debit cards may have been compromised at its stores over an eight-month period, beginning in May 2013.

When evidence of the breach came to light in January, Michaels launched a related investigation, with CEO Chuck Rubin issuing a statement to customers, warning them of what may have occurred.

In an April 17 update to customers, Rubin reported that two independent digital forensic investigation firms retained by the retailer found that criminals used "highly sophisticated malware" to infect some point-of-sale (POS) systems at Michaels and subsidiary Aaron Brothers stores, resulting in the theft of card-related information, including payment numbers and expiration dates.

"We have now identified and fully contained the incident, and the malware no longer presents a threat while shopping at Michaels or Aaron Brothers," Rubin said.

Here's what we now know about the breach at Michaels and Aaron Brothers:

1. Breach duration: eight months
Attackers targeted a subset of POS systems in use at Michaels stores from May 8, 2013, to January 27. "Only a small percentage of payment cards used in the affected stores during the times of exposure were impacted by this issue," Rubin said. The same goes for 54 branches of Aaron Brothers, where related data theft began June 26, 2013, and lasted until February 27, 2014.

Given that the Michaels breach was detected only after the retailer was tipped off by a third party, just one month after Target reported experiencing a massive breach that resulted in the compromise of 40 million payment cards, should Michaels have been doing more to ensure that its POS systems weren't infected with malware?

Gartner Research analyst Avivah Litan argues otherwise. "I don't think it's reasonable to expect retailers to have expert forensics team always on call investigating their network for breaches," she says via email. "And even if they did have those teams, they can't always spot various strains of malware."

Rubin said in his letter to customers that neither of the information security firms hired to investigate the breach had previously seen the malware used to infect the Michaels and Aaron Brothers POS systems.

Michaels, of course, is far from the first retailer -- or large business -- to have not detected a breach of its network, but rather to have learned about it from a third party. "Detecting a breach post-facto is unfortunately the norm in the industry," says Anup K. Ghosh, CEO of security firm Invincea, via email. "In most cases, companies find out about data breach and loss from an outside, third party, whether it is the FBI, an investigative reporter, a partner, or a customer."

2. Michaels issued rapid warning to customers
Did Michaels respond to unconfirmed breach reports in a timely manner? The first related information appeared to come from sources cited by security journalist Brian Krebs, who told Krebs that they'd seen evidence of elevated fraud at the retailer.

The administrator of DataBreaches.net, a privacy advocate and data breach information blogger -- who publishes under the handle "Dissent" -- lauds Michaels for responding to that information by quickly warning its customers, thus allowing them to protect themselves. "I stopped using my card/shopping at Michaels immediately because if they couldn't confirm that a breach had occurred, then any breach would still be ongoing. And why would I risk using my card at a store who acknowledged their system may have been compromised?" Dissent says.

In the wake of last week's update from Michaels, however, Dissent now feels "safer" using a credit card in its stores. "But then, I'm not the typical customer, I think," says Dissent.

3. Investigation duration: 80 days
What of the 11 weeks that it took investigators to review the potential breach and issue last week's final report? Dissent says that timeline illustrates how difficult it can be to spot or piece together the particulars of any given data breach. "If it takes two firms with expertise months to identify the malware and compromise, is it realistic for consumers to expect retailers to be able to prevent or catch everything?" Dissent says.

Breach investigations, by their nature, typically take time. "The fraudsters leave few traces and it's difficult to learn just how many cards were actually compromised," says Gartner's Litan, noting that months of digital forensic work are often required to determine exactly how systems were compromised and what may have been stolen.

"This also happened at a major card processor that was breached," she says. "The memory-resident malware is dormant much of the time in order to stay under the radar and not impinge on point-of-sale systems performance so in fact, it often only wakes up a few seconds every half hour or so to capture the payment card data. Figuring out which cards were in fact compromised is therefore a challenging task."

4. Will retail threat sharing reduce breaches?
To help retailers share information on threats, the National Retail Federation (NRF) announced last week that it plans to launch a retail-focused Information Sharing and Analysis Center (ISAC), modeled on the one that now serves the financial services industry. “We believe a heightened and well coordinated information sharing platform such as a retail ISAC is a vital component for helping retailers in their fight against cyber attacks," NRF president and CEO Matthew Shay said in a statement.

The retail ISAC is scheduled to launch in June.

Might the information sharing help prevent future breaches of the Michaels and Target ilk? "Yes, better information sharing about threats is critical," says Litan, who has said that one of the biggest takeaways from the February 2014 RSA information security conference for her was that the retail industry wasn't sharing threat intelligence.

"But it has to be detailed so that it can be acted upon," she says. "The issue today is that detailed threat information that is actionable is not shared for fear of litigation.

5. Don't blame retailers, blame system
Even with a retail-focused ISAC, however, don't expect retail-related breaches to decline until today's outdated -- and arguably still insecure -- payment card ecosystem gets overhauled. That will take much more than just adding EMV chips to cards so that people using their cards in person have to enter a PIN code to authorize the transaction.

To be clear, EMV wouldn't have stopped the Target breach, and likely wouldn't have stopped the malware that Michaels found on its POS systems either. Furthermore, retailers arguably shouldn't even have to handle unencrypted card data in the first place. "You can't count on 20 million plus card-accepting enterprises and retailers to patch an inherently insecure payment system," says Litan. "The answer lies in making the payment system itself more secure and that requires work from the entire ecosystem."

While EMV will help, Litan noted that it may take 10 years to become widespread in the United States. But there are other "solid security solutions" that the industry could put in place to help fix today's "inherently insecure payment system," she says. "These include point-to-point encryption where card data would be encrypted and protected much like PINs are today when they are entered into card readers. The second includes tokenization of the card data which substitutes the card number with an alias."

6. Short-term solution: stop using cards?
Pending more big-picture security fixes, some information security experts are opting out of using cards that don't offer better security. Writing in a recent SANS Institute newsletter, for example, William Hugh Murray, an information assurance professor at the Naval Postgraduate School, said he's shredded up all of his MasterCard and Visa cards, at least until the card providers start using EMV, although he's kept his American Express card.

"I continue to use AmEx only because they send me intraday alerts for all activity on my account," he said. "This is an efficient compensating control for the fundamental vulnerability of credit card numbers to fraudulent reuse. It addresses both card counterfeiting and 'card not present' fraud. It helps to restore user confidence."

7. Payment card providers preview security improvements
On a related note, however, MasterCard and Visa last month announced that they've formed a new, cross-industry group -- composed of "banks of all sizes, credit unions, acquirers, retailers, point-of-sale device manufacturers and industry trade groups" -- to tackle the introduction of EMV in the United States, as well as adding tokenization and point-to-point encryption.

To date, however, the companies have offered no timeline for when related changes might occur.

Private clouds are moving rapidly from concept to production. But some fears about expertise and integration still linger. Also in the Private Clouds Step Up issue of InformationWeek: The public cloud and the steam engine have more in common than you might think. (Free registration required.)

Mathew Schwartz is a freelance writer, editor, and photographer, as well the InformationWeek information security reporter. View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Duane T
50%
50%
Duane T,
User Rank: Apprentice
4/23/2014 | 12:01:44 PM
Irony of sharing
While the point made about sharing is valid, the article also states that the malware had never been seen before. Unfortunately, you can't share what you don't know.

On the other hand, there was little information on any lessons about how the undetected malware was found or identified. The follow up on that is that once the malware was found, was that information shared, and how widely is that information available to help other firms avoid a similar breach.

 
Drew Conry-Murray
50%
50%
Drew Conry-Murray,
User Rank: Ninja
4/23/2014 | 10:39:37 AM
Re: Should Michaels have done more?
Presumably Michael's was required to meet PCI standards, which means regular vulnerability assessments were conducted and IDS/IPS systems were in place. But as the article notes, we'll get more bang for the buck by overhauling the payment card system itself rather than trying to get thousands and thousands of retailers to run rock-solid security programs.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
4/23/2014 | 8:44:49 AM
Re: Should Michaels have done more?
Great questions. I hope the answers will be brought to light overtime & help provide a blueprint for the future.. We know from the Target breach that were both ommissions and commissions of best security practices  (See Be Careful Beating Up Target). But the retail industry can learn a lot from the post mortems. 
Robert McDougal
100%
0%
Robert McDougal,
User Rank: Ninja
4/22/2014 | 9:49:05 PM
Should Michaels have done more?
The article quotes Gartner researcher Avivah Litan stating that it is not fair to expect retailers to have expert forensic teams on call at all times.  While I agree with that statement, (forensic teams, if not part of the in house security personnel should be on retainer for incident response) I do think there is a minimum due diligence to which they should be held accountable.  Did Michael's have a CISO in place, security staff, IDS/IPS, vulnerability management, etc?  Did they follow secure coding practices?  Were risk assessments routinely performed on the POS systems?  These are the questions I would like to see answered.

 
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.