Are you serious?
Why is anyone storing these details in the clear in 2023. Why is this data not securely encrypted? If there are payment card details, are they not completely in contravention of PCI-DSS?
Purfoods has notified more than 1.2 million people that their personal and medical data — including payment card and bank account numbers, security codes, and some protected health information — may have been stolen from its servers during what sounds like a ransomware infection earlier this year. Purfoods bills itself as a …
"PCI-DSS is toothless
Too darned right. One of my erstwhile clients spent the first decade of PCI-DSS submitting quarterly reports of 'progress towards compliance', making it up each time on the fly without checking any facts (but not actually implementing anything required by the standard). Ten years out they were no nearer actual compliance, but the first and only time they were challenged was solely because they'd forgotten to sign the (utter nonsense) report.
So.... Your client was never actually PCI-DSS compliant then. Were they even claiming that they were? A Del-boy approach to PCI-DSS isn't going to improve data security - Why would it?
PCI-DSS is only toothless in the sense that the PCI-DSS police aren't going to come after you for breaking their rules - They'll just remove your compliance certification. And if that happens then you lose any contracts you may have had that depended on that compliance.
And on the plus side, when done "right", the PCI-DSS framework can massively mitigate against the likelihood and/or impact of a significant breach.
As someone that is in charge of cybersecurity for a mid-sized company, and also responsible for our PCI compliance, I totally disagree.
PCI DSS has been out of touch with reality since it's inception. There is a big disconnect between what the Payment Card Industry thinks are good security practices, and what in reality makes a company actually secure. I won't waste time here detailing all of the places where PCI is out of touch with reality. It their defense, they are starting to see a little of the real world these days, but it is very slow progress.
PCI DSS has always had the stench of coming from a group of academic researchers with absolutely no real world IT background. I deal with numerous security compliance frameworks (ISO, SOC2, etc.), and PCI DSS is the most disconnected from reality of them all.
@ChHag
Updated "correct question": Are there ANY databases, ANYWHERE AT ALL, which are not susceptible to hacking or ransomware?
It would seem, from the pages of The Register, that unless a database is air-gapped, ALL databases are susceptible!!
Equifax, NHS Trusts, SolarWinds (and SolarWinds clients), AWS databases, Purfoods.....the lst is endless......
P.S. Suppose an encrypted database is the target of ransomware........that data is still out of action!!!
"Are there ANY databases, ANYWHERE AT ALL, which are not susceptible to hacking or ransomware
Probably not, but there could be if the database were properly isolated (doesn't necessarily need an air gap). Strict control over query content, access rights and authentication, network segregation and activity monitoring are all parts of an all too seldom implemented protection framework. Particularly in the case of "cloud" services such as AWS, too may folk assume the provider does their security. In fact, the provider does its own security, but you are still responsible for yours.
One of the most serious fragilities is the prevalent web services approach that puts too much of the processing client side where it can be subverted to attack the server (every site is an 'app'). Carefully restricted and validated queries to a server side portal, behind which the database sits invisibly to the outside world, would go a long way to limiting data breaches, but I've not infrequently encountered GET URL parameters with SQL in them.
I know I'm going to get down-voted for saying this, but most of our information security problems come from poorly trained (and lazy) developers. As Mike 137 above says, databases can be much better secured if the developers take the time, and have the training to do it.
The problem is that we have armies of "developers" out there that do not understand security at all, or care really. It's easy for an unskilled developer to string together a few frameworks, past in some code from Stack Overflow, and build a website for someone. The result will be a security nightmare.
I think we should entertain the idea of licensing developers like we do with civil engineers. You need a license to design a bridge or a tall building. As a professional engineer, your license and reputation depends on the safety of the structure you are designing. With so much of our daily lives (and in some cases safety) depending on software now, why aren't the people building it licensed?
As I understand it, in engineering, it's common for non-licensed engineers to do a lot of the design work, but the whole project has to be reviewed and signed-off by a licensed engineer. Maybe that is where we should start with software?
."The big difference between storing data for money and storing data for free is that storing data for money usually costs the corporate vendors a lot less." - an updated Brendan Behan quote, back from the old days when we were much more concerned about sex than we worry about data hacking these days.