The July breach may have exposed cardholders' personal information -- so why did the bank wait more than 2 months to notify state officials and affected customers?

Mathew J. Schwartz, Contributor

December 6, 2013

5 Min Read

When consumers lose their credit or debit card, they're expected to notify the card issuer in a timely fashion to minimize any related fraud or other lasting damage. But in the case of JPMorgan Chase, which this week began warning that hackers may have obtained prepaid card data and personal information for 465,000 of its cardholders, the same notification rules don't appear to hold true.

While the breach of JPMorgan Chase bank's systems occurred in July and the bank detected it in the middle of September, bank officials waited two and a half months before they began warning affected consumers.

{image 1}

All told, the July breach reportedly affected 2% of the bank's 25 million users of UCard, which is a prepaid card. Bank officials said that immediately after detecting the breach, they fixed the problem that had been exploited by hackers and notified both the FBI and Secret Service about the breach. They also said that information relating to the bank's debit card, credit card, and prepaid Liquid card holders wasn't compromised.

[Security researchers have recovered a stash of stolen access credentials to Facebook, Google, and other sites. Read 2 Million Stolen Passwords Recovered.]

State officials in Connecticut this week said that the stolen information may have included names, social security numbers, bank account numbers, card numbers, dates of birth, security answers, passwords, addresses, and phone numbers. Such information, of course, would be useful for anyone seeking to commit identity theft.

According to some news reports, however, bank officials this week said that no personal information was stolen during the hack attack. Bank officials didn't immediately respond to an emailed request for clarification, nor did they respond to questions about how attackers gained access to the UCard systems or why the bank chose to wait so long before warning consumers. But according to news reports, while the stolen data was normally encrypted, it was being temporarily stored in plaintext format as a result of automated logging activity.

Bank spokesman Michael Fusco told Reuters that because there are no signs that attackers have employed the UCard data that may have been stolen, the bank has chosen to not issue replacement cards to the 465,000 affected consumers. However, the bank is offering them two years of free credit monitoring, according to Connecticut state officials. (Some news reports have said the monitoring will be offered for just one year; bank officials didn't immediately respond to an emailed request for clarification.)

State officials in Connecticut and Louisiana said they were first alerted to the UCard breach by the bank this week. Multiple states use the cards to provide services to residents, including child support payments, tax refunds, and unemployment benefits. Some businesses also use them to pay their employees.

Connecticut state treasurer Denise Nappier, in a statement issued Thursday, criticized the bank for not more warning about the breach, which affected 14,000 of the state's residents. "I am dismayed that JPMorgan Chase delayed informing my office of this security breach for two and a half months -- from mid-September, when they first learned of it, until this week," she said. "They should have picked up the phone immediately and called us. That the company failed to communicate this security breach in a timely manner raises concerns over its culture of compliance and broader governance issues."

Similarly, Kristy Nichols, the commissioner of administration for Louisiana -- where about 6,000 residents were affected by the breach -- said in a statement that the state would "hold JPMorgan Chase responsible to make certain that the rights and personal privacy of these Louisiana citizens is protected."

While full details of the breach haven't been released, Paul Ducklin, head of technology for Sophos in the Asia Pacific region, said that hackers gaining access to temporary files that the bank had failed to encrypt appeared to be to blame. "Financial transactions need scrupulous auditing, and that means keeping an accurate record somewhere of what happened, and when," he said in a blog post. "But logging can be a security risk as well as a benefit. Accordingly, businesses should keep all personal data encrypted, regardless of whether it's being stored to disk, or sent across a network."

In other words, the bank may have erred by failing to properly encrypt all sensitive data. "If you're logging sensitive data, don't wait until it reaches its final destination before encrypting it," Ducklin said.

The UCard breach is only the latest in a string of regulatory sanctions and attendant customer relations setbacks for JPMorgan Chase. For starters, in September the bank agreed to refund $309 million to 2.1 million consumers -- and pay $80 million in related fines -- after it enrolled consumers in additional credit card services for which they hadn't signed up, and which carried a monthly cost of between $7.99 and $11.99.

In October, the bank was ordered to pay $920 million in fines to settle a "London whale" trading mess involving derivatives trading losses worth $6.2 billion, which triggered investigations by both US and UK regulators, who slammed the bank for its poor internal controls.

And last month the bank was forced to cancel an #AskJPM Twitter marketing campaign that gave consumers the chance to question investment banker Jimmy Lee, who was behind Twitter's recent public valuation. But many consumers embraced the two-way communication in an unexpected way, using it to vent their rage at both the bank and Wall Street at large.

There's no such thing as perfection when it comes to software applications, but organizations should make every effort to ensure that their developers do everything in their power to get as close as possible. This Dark Reading report, Integrating Vulnerability Management Into The Application Development Process, examines the challenges of finding and remediating bugs in applications that are growing in complexity and number, and recommends tools and best practices for weaving vulnerability management into the development process from the very beginning. (Free registration required.)

About the Author(s)

Mathew J. Schwartz

Contributor

Mathew Schwartz served as the InformationWeek information security reporter from 2010 until mid-2014.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights