Unsecured Azure blob exposed 500,000+ highly confidential docs from UK firm's CRM customers A business app developer's unsecured Microsoft Azure blob left more than half a million confidential and sensitive documents belonging to its customers freely exposed to the public internet, The Register can reveal. Information contained in the blob included occupational health assessments, insurance claim documents from US …
This sort of thing really needs to be subject to penalties on a scale that jeopardises the company's viability.
We've had DPAs for decades now and the need for compliance just doesn't seem to register with manglements or at least not to the extent that it compels them to supervise the underlings and make sure stuff is secured. We need to start putting some of the worst examples where they can no longer place data subjects at risk. Seeing a few of their contemporaries go down the tubes would encourage even the most obdurate of the others.
And the penalties should apply to Probase's customers for criminally negligent supplier due diligence - or if they subcontracted due-diligence checks then also to the companies who provided them. I believe the GDPR legislation does not allow companies to just pass the buck to service providers in cases like this.
Actually I think this comment has hit it on the head.
Fine the director - his directors liability insurance pays, everything stays the same.
Fine the company - the products or public liability insurance pays, everything stays the same.
Fine the customers - they cancel contracts, and scrutinise the next provider more carefully.
> Fine the customers - they cancel contracts, and scrutinise the next provider more carefully.
Perhaps you'd like to explain how as a customer I would investigate that sort of thing ?
"I'm looking to buy your CRM (or other AAS product) which comes with various contractual obligations on both sides. I want to see all the IP that is used to build it and all of the config (except usernames)" ?
As a customer you don't "investigate" anything:
you get your lawyers to write waterproof contracts that say something to the effect of "Supplier indemnifies customer against any and all leaks of customer's data caused by any supplier's acts of omission or commission" or similar.
Then when you get fined because your supplier spaffs your data all over the interwebs, you claim from them.
I was thinking along exactly the same line as I clicked through to the comments. Someone or preferably some people at a suitable height in the company or companies owning the data or setting up the storage need to do a term inside and be.prohibited for a very long time and very publicly from doing anything commercial involving IT.
In theory at least, in the UK company directors can be held personally liable for any criminal activity committed on behalf of their company. However, they can be very difficult to hold to actual account as they invariably claim that they were personally unaware of the actions, believed their 'direct reports' were keeping them properly informed, and do not recall their 'direct reports' raising this issue with them (even though said 'direct reports' claim to have done) as it is nowhere to be found in the 'minutes'.
Just look a the phone hacking scandal from News of the World / Murdoch press, or any number of cases of 'corporate manslaughter' which have failed to imprison or even convict a single Director.
This is, however one area of law where the USA beats the UK. The directors of Enron (remember them?) did go to jail. Ernest Saunders in the UK, who rigged the share price of his company to get a takeover deal through on the cheap, did spend time in prison, but it was a low security prison, where he made medical history by being the only person ever to have recovered from dementia.
One law for the rich.
This idea of not knowing what your directs reports are up to, was part of what Sarbanes-Oxley (in the US) was designed to address. The concept is that you (as a director/manager) are responsible for your direct reports and ought to know, and also have controls in place to ensure that you do. ISTR that this was one of the results of Enron's failure, mentioned above.
Prison time and fines (of course) but the latter should not be covered by D&O insurance.
Prison time does inded concentrate the mind but the financial penalties also need to hurt.
And perhaps a bit more commercial law to be also covered by criminal law (commercial criminal law).
“ why is putting company directors inside not do-able? ”
Directors direct, workers do.
Typically directors will issue instructions that can be vague and open to interpretation.
If a director issued a directive to ensure compliance, and something was found that wasn’t in compliance was it the directors fault or the manager responsible for the thing not in compliance or the team or individual who was responsible for the compliance? What if a 3rd party pen test was done that didn’t find it? What if it was secure originally and something changed after and no one noticed?
The director can’t be expected to have expert knowledge in everything they are responsible for, that’s why they have lots of people in their directorate.
If the director deliberately instructed something to be insecure then yes they should go to jail. If the director wasn’t woolly enough in their instructions leading to questions about their leadership then they will be the scapegoat and find hey don’t survive in that job and may not get another directorship.
Damages are limited to contractual caps.
Otherwise you'll find no one willing to do the work.
The bigger problem is the attempt to get E&O coverage because no one knows how to underwrite this and then there would be caps here too.
The truth... think twice before going to the cloud and also add additional layers of security and processes to limit the exposure of data.
This is why you need to look at Enterprise clouds and reduce the reliance on 3rd party developers who work off enterprise or store data off enterprise.
In their own words :
"Probase's methodology to designing and developing databases makes sure that your applications will provide the highest data integrity and security, while our open approach enables efficient and reliable integration with other existing enterprise applications. We deliver this using our proven development methods that provide our customers with transparency and certainty throughout the project."
In some of their other buzzword bingo blurb, they also go on about "agile", which I have found over the years is often the opposite pole of sturdy security. Agile + Cloud = Avoid. The solutions offered by the plastic shed company with the same name as theirs sound more secure.
The Cloud enables the worst extremes of shadow IT. No longer do business buyers have to smuggle a bootleg beige box into the office (where at least it has some physical and network security). With just a company credit card the clueless can cut through any corporate governance.
Though I'm amazed they managed to completely disable the out of the box security to make this a perfect clusterfuck.
You wouldn't sell a knife to a kid - Maybe Azure et al should enforce a competency test, e.g.
"The Cloud is a) A magical paradigm that anyone can use b) A way to free the business from the tyranny of experts c) Bureau computing with a new name d) Someone else's computer."
Even if the buyer guesses a "right" answer, they've been warned ;-)
Teacher is a fool.
This has nothing to do with cloud. Incompetence places data at risk regardless of who owns the box it sits on. It is naive in the extreme to think that because you can physically touch a server, it is safe. A proper security strategy has to assume that the internal network is equally as compromised as a public one.
Disagree. 10 years ago I think it’s safe to say this company would have been dumping uploads in an unsecured Apache directory. Apache and the OS wouldn’t have been patched since installation. The ‘server’ would be located in an unlocked stationery cupboard with unencrypted disks, and there would be no RAID or backup regime.
Using a cloud object store actually fixes or helps with most of these problems rather than exacerbates them, and provides some pretty powerful security constructs to those who are capable of using them. On AWS (not sure about Azure) you will be warned proactively and quite strenuously that your unsecured bucket is probably not a good idea. But ultimately, it can’t fix stupid.
This post has been deleted by its author
Three words that sound ridiculous together.
How is it that multiple customers were using the same cloud storage thingy ? Did nobody think it would be better to have a storage per customer, or was that a more expensive solution ?
Yeah, it was probably more expensive. Couple that with a dev that probably had to set security to the lowest setting that worked with all customers, and a PHB that didn't give a damn, and this is the result : a massive breach of very intimate, personally-identifiable data.
Somebody should be jailed for this, and I'm not talking about the dev.
No, it doesn't cost more to create multiple blobs. This is purely a design decision.
For a multi tenanted application, it would be expected that a separate blob be used for each tenant.
In a single tenant application a single blob for different customer's data would not be unusual, in the same way multiple customer's data would be in a single database.
So who designed and wrote the management code? Probably a student wanting to demonstrate that they were a talented programmer, security is not a concern when you are just demonstrating this - so the company probably gave the author a small fee and let them go in the current COVID environment and started using the app. Management would be happy, "Cheap code that works great, let's start charging people" and they would have just assumed it was all good but never tested it, the author's probably got a job driving for Uber now, at least it's a paycheck.
Unlikely, the lectures on DB security will still be ringing in our students ears.
More likely a dodgey design sent to the cheapest outsource they could find, then run without any QC checks.... thus proving you get what you pay for.
"we need to make a profit"
"But QC"
"get it running, we need to make a profit"
"The design is flawed"
"Who cares... we need a profit"
I think a nice fine would be about £1000 per record exposed.. fat chance of that though
Would not be surprised if the Probase application actually authenticates with Azure, to access the blob...
I suggest this isn't just an issue for Probase, but also for the cloud vendors themselves.
It is clear the default configuration of cloud services is public. In some ways this is like laptops/desktops being shipped with an unencrypted HDD and setup as default as a public (read, write, execute) network share; whilst you need to login to the OS to access the HDD via the installed OS, anyone on the network can access the HDD.
I suggest perhaps cloud vendors themselves need to change their defaults so that new instances are private by default; users have to actively change settings to make them public and then have this red flagged in their admin console...
Thanks, wasn't bashing MS, just noting that there seems to be too many instances of unsecured ie. publicly accessible, cloud instances containing sensitive data.
At least in this instance it would seem it was a deliberate act (by an employee of Probase) to make the instance public - that clarity will not help Probase's data protection defense...
The whole point / purpose of blob storage (initially) was so it could be used as a static web page and similar. It was initially there as the backend of a CDN.
The whole "Lets put other stuff into blob storage" was because it was cheap.
A few years ago blob storage defaulted to accessible and you had to secure it. Yes that has changed, but older blob store still has it's initial config.
If this has records back to 2013 it would put it quite squarely into the "blob storage is open, you need to lock it down"
"Customers trust the companies they deal with to take their security seriously. " - heavens, no! I've had too much evidence for too many years that most companies either don't give a damn abut customer data security, or if they do, are evidently clueless about , or, in one case where I worked for them, had at least one director (wiho had legal training, I might add) who did their damndest to try to circumventt the requirements of the Data Protection Ac, and was only stopped by junior staff refusing to break the law.
The problem is that company's like Probase have most likely always written shoddy software like this, without even so much as a nod to 'secure by design' principles. But the difference is they've got away with it in the past (albeit by the skin of their teeth) because they've hosted it in their own (or co-located) datacentres and on their own managed tin, and the only bit of security that's been saving their bacon has been some Firewall at the edge.
Now, in the cloud they continue to write shoddy software with no regard to security and it' all laid bare. This is the problem when companies go looking for SaaS line of business applications, they often seem only interested in whether the application meets their functionality requirements, and only demand auditable security once they've had their pants pulled down like this!
Enforcing a complex password would be the first obvious thing to do.
It’d stop drive by’s raising the complexity of access and forcing the devs to consider security.
Next would be to enforce access certificates 1 unique cert per accessing system, no cert no access, the dev can revoke the cert for any of the systems that goes rogue.
Yes the complexity goes up but at least they will still be around tomorrow to earn money.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
