JP Morgan Chase is the latest financial institution to own up to a data breach.
According to reports, the breach affected 2% of the customers of one of the bank’s payment card products.
That doesn’t sound such a big deal until you realise that the breach happened against a product called UCARD, of which it seems that 25,000,000 have been issued.
That makes it a pretty big breach when measured in absolute terms, with JP Morgan Chase having to contact 465,000 customers to warn them what has just happened.
Except that it looks as though it hasn’t “just happened”.
JP Morgan Chase’s own sites don’t seem to be saying, but stories already published seem to agree that the breach happened in July 2013; the bank realised in September 2013; and the notification has only followed now, in December 2013.
If, like me, you’re not from the USA, you might never have heard of UCARD – and, like me, you might have struggled to find out anything about it if you tried searching in the obvious places, such as jpmorgan.com, chase.com and jpmorganchase.com.
Not only will you find nothing about the breach, you won’t even find a mention of UCARD:
There’s a site called ucard.chase.com, but it seems to be for people who not only know what UCARD is, but actually already have one:
(One positive thing to report: at least the main page uses HTTPS, thus inviting you to login from a secure page to a secure page, though it doesn’t yet seem to offer forward secrecy.)
All we’ve been able to work out so far is that the UCARD CENTER website shown above seems to have been renamed from EBT ACCOUNT, and EBT stands for Electronic Benefit Transfer, which is pretty much what it sounds like – a way to get paid your food stamps and benefit cheques.
Briefly put, UCARD is welfare done digitally.
Of course, without an obvious official statement from JP Morgan Chase itself, we can only report what others are reporting, which seems to boil down to this:
- Data breach happened in July.
- Noticed and reported to relevant authorities in September.
- Reported to affected customers in December.
- Close to half-a-million cardholders affected.
- Still not sure what data was stolen.
- Most data stored encrypted.
- Some personal data exposed in unencrypted temporary files.
- Only the UCARD product affected.
- Law enforcement investigating.
- Affected customers get 12 months’ free credit monitoring.
Most of this, sadly, is a script you could probably have written yourself, through familiarity with all-too-many previous breach stories.
Sting in the tail
The sting in the tail – and the big lesson to take away in this case – is the issue of unencrypted temporary files.
Reuters suggests that the unencrypted data “appeared in plain text in files the computers use to log activity,” and that is probably a data leakage risk that affects many companies.
Financial transactions need scrupulous auditing, and that means keeping an accurate record somewhere of what happened, and when.
But logging can be a security risk as well as a benefit – you should be encrypting personally identifiable data both at rest (when it is written to disk) and on the move (as it flows across the network).
If you’re logging sensitive data, don’t wait until it reaches its final destination before encrypting it.
Public key cryptography makes it comparatively easy to protect logging data from snoopers and thieves in an end-to-end fashion, thus ensuring that it is encrypted everywhere along the way.
→ By the way, the potential for data leakage via temporary files is one reason why we recommend you use FDE, or Full Disk Encrpytion, for your laptop or mobile device, rather than just encrypting your home directory. If everything is encrypted, you don’t have to worry that one or two odd or out-of-the-way files might not be.
7 comments on “JP Morgan Chase owns up to data breach: 465,000 customers at risk”
Scary to think that much customer data can be leaked at once!
Let’s be real – it wasn’t “leaked” – it was stolen! And you can probably find the information at Paymentech.com – I think that’s the company that issues the UCard – it’s a subsidiary company.
Perhaps “leaked” makes it sound a bit soft. You’re right – it was stolen.
I took your advice and went to paymentech.com (not sure how I would otherwise have known to do that) and it redirects me to Chase Paymentech. Did a search for UCARD. Got the result: “Your search – UCARD – did not match any documents. No pages were found containing UCARD.”
UCard is also used for state tax refunds, at least in Connecticut: e.g., see http://www.ct.gov/drs/cwp/view.asp?a=1462&Q=491676
U Card is also used by some states for getting child support payments to the custodial parent.
U card is also used for unemployment benefits (which are NOT welfare payments FYI-worked & contributed all my life since age 16 for these benefits). And people wonder why I don’t do all my banking online. This is a perfect example. Happy Holidays to all!
I agree that “logging can be a security risk as well as a benefit – you should be encrypting personally identifiable data both at rest (when it is written to disk) and on the move (as it flows across the network).”
It is also concerning that less than 14% of breaches are detected by internal security tools according to the annual international breach investigations report by Verizon. Detection by external third party entities unfortunately increased from approximately 10% to 25% during the last three years. Specifically notification by law enforcement increased from around 25% to 33% during the last three years.
Unfortunately, current approaches with monitoring and intrusion detection products can’t tell you what normal looks like in your own systems and SIEM technology is simply too slowly to be useful for security analytics.
Advancements in Big Data security analytics may help over time, but we don’t have time to wait, so we need to protect our sensitive data itself.
I think it is time to secure the sensitive data in the entire data flow with modern approaches. This approach will secure data also in temporary files and limit the need for logging since this data is no longer sensitive. Sensitive data is even protected in memory in most use cases.
Studies have shown that users of data tokenization experience up to 50 % fewer security-related incidents (e.g. unauthorized access, data loss, or data exposure) than non-users.
Ulf Mattsson, CTO Protegrity