markarichards

I like to think of a breach as hole through into the hull... they don't mean the boat will sink or even ever will sink; just that the layers of security protections has been compromised.

In the case you mention it seems that happened too: internal actors could reach plaintext passwords and thus for safety the company responded by forcing password reset and disclosure (commendable as I know of companies that would not).

The term "personal data breach" is useful because it defines the range of breaches that the law focuses on (it's not interested in business data or incidents where the first layer of defence fell but the second kept it secure).

I feel it's a bit like having a determination for "road traffic incident". It helps the public, police, etc identify what is in scope... just because you have one doesn't mean you'll lose your licence or be fined - that depends on a range of factors regarding the lead up to the incident: what happened before, during and after. Similar with data breaches.

If a company has a breach it does not mean much in GDPR unless other factors are considered, so I wouldn't worry about being too focused on the term breach.

It's relatively common for publications to lazily only reference an action that resulted in a legal outcome, rather than the justification provided for the outcome.

For instance, Bob imprisoned for car bomb rather than Bob imprisoned after judgement rules deaths unlawfully resulted from Bob's malicious car bombing. Had Bob's car bomb been on a film set and no one hurt, Bob would hopefully be fine.

If you read coverage with this in mind, then what matters is more a case of how likely an action is to be unlawful and thus how lazy the publication is being.

If someone blows up a car, we'd assume it was unlawful. If a company stores passwords unlawfully we'd assume it was unlawful and hopefully for good reason...

From GDPR: "personal data breach’ means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed"

A typical security policy for securing passwords is to never store them in plaintext.

It would be a rare situation for the storage to not be accessible (what would be the point of storing it).

Thus it would seem fair to assume that in most cases plain text storage of passwords would be a breach of security (internal controls breach) would implicitly also be a breach of personal data (legal definition) as it would at the very least be accidentally accessible to staff, contractors or third parties (whoever hosts the storage).

So, it will likely fit the definition of a breach.

But, it still needs to escalate to a point where it would be recognised as serious enough to warrant action (like reporting to data subjects or regulators).

There are situations where storing passwords in plaintext may not warrant reporting or fines, such as if upon realising the breach it was evident that nobody had accessed the data and it was destructed before harm could be realised; but I doubt anyone would ever know about these situations happening in companies so it's fair to assume they wouldn't reach major news sites.

The technical fix to this exact issue is remove or SRI and review third party code. None of these features are a must have requirement for online banking.

However, the breadth of this problem indicates the fix is bigger, else this will just pop up again without being noticed and should be tackled from two directions.

Technically: in the context of non-repudiation, web browsers are insecure for users. Significant user requests (make a payment, consent to terms, etc) are not stored client side, not signed and were a user to discover an audit log feature there is no distinction between what JS did and what a user did. This should and must change for the web to evolve to protect users.

Business: the failure across most of the banking sector suggests that all who should be holding the banks to account (share holders, creditors, regulators, customers, etc) are failing to monitor the banks and given there has been prior warning of this for some (regulators) failing to act. If a third party uses their remote access to hack customers, then I'm sure they will react but that may be too late. When we want security in our physical environment we have watchdogs whose responsibility is not just to react, but to proactively monitor the environment: spot the river has chemicals in it. Banking is significant enough that it probably needs a watchdog tasked with specific objectives regarding information security.

From the customer's perspective everything has been supplied to them.

However, from the bank's perspective, of their supply chain, the component shown to a customer has not been handled by them: they never received it, to supply it.

At best they can order a copy of it for quality assurance purposes and hope it is identical to what the customer will receive.

Instead, their web page sends an order to the third party for delivery (script src tag refers to a foreign location) and crosses their finger that all will be good.

There are mechanisms to reduce delivery chain risks, such as SRI, but they were not used.

For our systems we run, we have supply chain breaches.

But, when our code runs client side and depends on software artefacts being pulled from elsewhere by the client device, I feel like a supply chain paints a picture of a flow of control for that artefact that doesn't really exist.

Therefore, I phrased this post in the context of a "delivery chain" breach instead of a "supply chain" breach and I am curious to see what discussion flows.

Of course, I'm also trying to raise awareness to this particular breach and the odd events around it.

Sorry, I shortened the original title to fit.

Is it just me or is this like a finance regulator urging companies to adopt cryptocurrencies to harness the power of transactional integrity?