The HSBC Breach and Data Classes
On November 2nd 2018, HSBC filed a mandatory notification of breach with the US state of California. It sent letters informing an unknown number of affected customers of the breach around the same time. According to the notification, the bank had discovered unauthorized access to customer data between October 4, 2018 and October 14, 2018 and has since mitigated the issue.
No details on what systems were breached, how many users were affected, and how the attack happened were provided.
Who is affected by the breach?
This is a tricky question, as legislation around notifications differs strongly between jurisdictions. The notification filing with the state of California indicates that at least some of the affected users had US-based accounts. The lack of similar filings in other jurisdictions with similar legislature indicates that the breach might have been contained to US accounts - however further victims in jurisdictions with either laxer or non-existing reporting requirements cannot be ruled out.
Why it matters.
A breach of an unidentified but supposedly small number of victims may seem almost trivial when compared to massive breaches such as the ones that hit Cathay Pacific and British Airways. However the data that was accessed makes this incident both significant and interesting. According to the notification, accessed data includes full name, mailing address, phone number, email address, date of birth, account numbers, account types, account balances, transaction history, payee account information, and statement history. Unlike the other breaches that stole credit card numbers directly from the customers’ browsers (and thus avoided the need to bypass many security safeguards), these complete data-sets can only reasonably be stolen from an actual bank database.
Databases used to store core financial data are defended much more strongly and subject to many more policies and regulations than those running common websites or even online-store frontends. This makes the breach of such a database a significant event.
How could it have happened?
Since no corroborating information is available, all educated guesses for what was breached are just that - educated guesses. Within this context, three broad scenarios come to mind.
The second scenario is a leak of analytical data. Banks occasionally use a subset of their customer data for analytical purposes, such as establishing patterns for fraud detection or generating general business intelligence. Data used for such projects should be treated with the same level of care as the data stored in databases. However experience shows that in practice, security is often laxer, allowing for accidental or purposeful leaks.
The third scenario is an accidental or incidental insider attack. An insider with access to the high-security systems would stand a reasonable chance to inject attack code. Code reviews and automatic deployments are methods to prevent such scenarios, but are often not proactively used, or poorly implemented. Alternatively, an employee with access to the highly sensitive data may simply have made a mistake when managing it, ultimately leading to the breach.
Time will tell what actually happened in HSBC’s case.
The HSBC breach is more interesting because of what was stolen than because of how much was stolen. Even as cyber attacks escalate, successful attacks against the core systems of major banks remain rare. If you are a customer of HSBC, there is no reasonable need to worry about your account’s security unless you received a breach notification. As always, the applicable recommendations and good practice of regularly changing passwords and careful use of online banking apply.