I could ask "how could they let this happen" but it's obvious why it happened, and very sad.
We have a major UK institution in crisis through ineffective security and archaic data architecture.
First of all there was a data breach following a system upgrade. This resulted in customers being able to see other people's accounts. Secondly, the same customers then watched helplessly as their own savings were plundered by hackers.
It's evident that something went very wrong here, and then continued to fail because the organisation were unable to contain problem.
There are so many issues here that it's difficult to know where to start but the following is evident.
Good practice around version upgrades and product enhancements
New updates should never be applied to live databases. Legislation in banking precludes it, but it's never good practice in any industry.
Bank databases are huge, and the development overhead of spinning up instances can be overwhelming. It's tempting to flout legislation and simply apply new changes and hope for the best. This is evidently what happened here.
Security Retro-Fit
Simply adding an overlay to an old database with "flat" security around it is chronically insufficient. A minor glitch in one or other of the authenticating tables should never be sufficient to cause records to open inappropriately - such as one user seeing another's private details, as seen during this breach
If security is retro-fitted, it needs to be multi-layered to ensure that authentication is repeatedly checked against various markers, this will render breaches of this type impossible.
Bank Databases are Huge. And Old.
Age is a major factor. Bank databases have been built over many years and new functions have been added over legacy technologies.
The underlying databases haven't evolved. This is predominantly due to the cost and the massive upheaval involved, but as the database is a fundamental tool of the trade, and investment is critical.
We recently implemented multilayer security throughout the architecture of a brand new database environment for a financial institution. It would simply not have been possible to apply the same levels of protection to a legacy system.
What Should have Happened
In most instances a replacement programme would likely be cheaper and certainly have more longevity than papering over the cracks and hoping it doesn't rain. Modern architecture around big data can avoid this problem. Solutions are available which make spinning multiple instances for test and dev quick and easy.
Either way it's a lesson for any institution looking to implement security updates and upgrades, do it properly - if you don't your business reputation, if not your entire business, is at risk.
If you'd like an off the record chat about updating your database security, or anything else security related, you can book into my diary here.
Best wishes,
Liz
