What's the simplest way to prevent this from happening these days? Daily Backups off site?
It's a problem of 'data leakage' where the bad guys have a copy of corporate data - supposedly 4TB of personal medical information - and threaten to release it to the public which can cause all sorts of reputational or other damage.
Backups don't help much in this situation, you need to convince the attackers to delete the data they copied from your network, usually via lots of money but even then there's no guarantee they'll actually delete it and may extort you for more money in the future with the same data.
Should one trust a criminal to keep their word?
Because it gets decrypted at some point.
Security is not anywhere close to "good" in most corporate environments however, and many things are still stored in plaintext that should not (e.g. passwords), let alone data that is merely "private".
You don't need to decrypt the entire payload at any time.
You decrypt parts of the data.
Put on a hat and pretend you’re a bad actor. Give yourself access to the server where your most important data is stored.
Now look around. Is there anything you can do to extort money?
You could encrypt/destroy the data. (A backup solution saves you here).
You could exfiltrate the data (download or upload to a remote server). What can you do with this data if it was encrypted at rest? Not much.
What else could you do on thisnserver while you have access? This is where things get interesting. Can you force the application to decrypt the data or dump the data somehow? Unlikely, if the cert management is done properly.
The thing is, majority of organisations do not encrypt data at rest. Databases are not encrypted, hard data is not encrypted. If this was not the case, we wouldn’t be hearing about these data leaks.
How do I encrypt a database at rest? How does it work?
Say, I run a hospital and I want to write patient data to a database. Do I have to decrypt the whole database before I add new data? Each time? Do I also have to decrypt the database each time I query data? How does that work when two doctors want to access the database at the same time?
I assume that constant decryption and encryption of large amount of data adds a significant overhead. So in practice, while data is encrypted at rest, most of the time the data isn't resting, but actively loaded and used and unencrypted.
And now, when a bad actor gets access to that live running database, they can exfiltrate the data.
Additionally, proper protection of medical records will require globally unique identifiers (aka PID, MRN).
As you know, today, medical record PII must be stored as plaintext to allow record linking across heterogenous orgs. This is bad.
Yes and:
> Encrypting data while at rest (in storage) as well as in-transit is the way to go.
All PII must be encrypted at rest at the field level.
Just like how passwords are properly stored. This is not rocket science.
The book Translucent Databases demonstrates this technique for common use cases. Highest recommendation.
https://www.amazon.com/Translucent-Databases-Peter-Wayner/dp...
The practical downside is that if the user forgets their password, they lose access to their account. So for medical records, the original key (password) requires offline paper (or equiv) backup.
Have you seen patient portals like (Epic's?) MyChart?
Aside: During the mid-aughts, I created a patient portal POC, to compliment our physician portal product. Customers were very interested. Ditto the clinical (vs diagnostic) quality web-based DICOM viewer I made. (Sadly, the 2008 meltdown /dev/null'd all of our work.)
Patient portals tied to a single vendor like Epic MyChart aren't great, but they work well enough for patients who receive all of their care through a single integrated health system. Attempts to create universal patient portals not tied to a particular payer or provider organization have generally failed because no one wants to pay for them. Apple is trying this again but they only have interfaces with a limited set of data sources.
Almost all of my PII and medical information is in the hands of bad actors because of this needless retention
Like a shaman. Or a doctor whose license has been revoked.
Good luck!
A password wouldn't be appropriate for direct use as an encryption key. So I guess you could hash the password and use that for the key for data encryption and then hash it again and store the second hash for authentication. Salting appropriately of course.
That feels weird to me, I wouldn't trust I saw every angle on that. Regardless, it would drastically lower the entropy of the key space that way unless you have downright draconian password requirements.
How did you implement this in the POC you spoke of?
Very briefly, a proper password store must not use plaintext. Rather it must use ( password + salt ) * hash.
Similarly, PII (name, MRN, etc) must also be salted and hashed.
What Translucent Databases adds is showing how to cleverly use those hashed values for common use cases. Like how to use hashed MRNs as indexes (keys) to other data such as lab results.
It takes some getting acquainted, but designing schemas will start being intuitive after a bit.
Edit: I see you aren't actually encrypting it. So you are as the post said, just throwing away the keys (in a sense). You are talking about storing and indexing metadata.
Sensitive data (passwords, PII) is absolutely encrypted. I apologize for assuming everyone here knows how passwords should be stored. My reference to "hash" is shorthand for "secure one-way hash".
Please refer to the Translucent Databases book for any further questions you may have.
You can read here https://www.google.com/search?q=hashing+vs+encrypting to further understand.
These groups work on reputation. If prior ransoms do not result in seemingly perfect dealing from their end, new orgs won’t consider it.
The significance of the rug pull on affiliates confirms this. It shows fair dealing even with conspirators is the norm, and this example as a major diversion.
The other component is that these situations are usually negotiated by lawyers that are hired by insurance companies that offer cybersecurity policies. They tend have working relationships. It's crazy, but these are actual businesses that do, in fact, have rules of engagement and often abide by their guarantees. That is part of the problem, I suppose...
Do we know that they had good backups in this particular case? The fact that their systems are not yet back online makes me wonder if maybe they didn't.
The phrase to describe this is double extortion.
As for your question, https://www.cisa.gov/stopransomware is a decent start, but it's a complicated issue. In short, if a pentester can get inside your environment and gain privileges, so can an attacker. You want to slow down attackers enough to buy time for detection and response capabilities.
How many organizations have their "encrypted at rest" data in a cloud provider account that's set up to give all developers (or at least all production support engineers) access to decrypt the data, maybe even transparently?
How many have the "encrypted at rest" data on servers that are set up to give all administrators transparent access to the data?
How many only allow application service accounts access to decrypt the data directly, but the credentials for those service accounts are stored as Kubernetes secrets that anyone in IT can read?
Etc.
Executives at UnitedHealth Group told workers to mine old medical records for more illnesses, to identify diagnoses of serious diseases that might have never existed, inflating bills paid by the federal government's Medicare Advantage program.
If you're talking about your own personal hard drive in your home, yes.
But in this case, we're talking about a huge company conducting literally billions of database queries for tens of thousands of clients an hour.
You only have to have a listening post in one small part of the system that can see things in plaintext for a short time in order to accumulate 4TB in a matter of days.
"We estimate more than 90% of the nation’s 70,000+ pharmacies have modified electronic claim processing to mitigate impacts from the Change Healthcare cyber security issue; the remainder have offline processing workarounds," Mason said.
https://www.bleepingcomputer.com/news/security/unitedhealth-...
The pharmacy network, which connects pharmacies and PBMs, is in final end-to-end testing with our partners. We anticipate that our Change Healthcare Pharmacy network will be back online for the vast majority of submitters as soon as Thursday.
Sure, so I've seen this. There's a Veeam server with a backup repo in the main datacenter. And it takes backups to a server "offsite". Let's forget for a moment I've got an environment that take six days to do a full backup.
Then one day the attacker gains a vendor's Teamviewer account and finds themselves on a server console that's been left logged on as a Domain Admin. And they open windows file explorer, and browse to \\offsiteserver\backups, and then press "delete". Noone cares if it's offsite, it's gone.
OK, so when you said "offsite backups" I'm sure you meant something not contactable from an average network machine right? Maybe ACLs only allow access from the backup server itself. Well fear not, the attacker can still just RDP to that Veeam server and repeat.
OK OK so what you really wanted was a properly isolated network for all the backup content and they can't make a connection from the general network to it right? Once again fear not, there's a Group Policy deploying this ransomware, which means it's going on every domain joined machine including the backup server.
Look, now we're getting somewhere, there should be an entirely separate administration domain for backups and infrastructure. Well firstly someone from Microsoft will yell at you because "ESAE" is deprecated, and some overpriced consultant is about to explain to management that you're incompetent because you separated the networks (from personal experience). Fortunately that doesn't matter to the one guy with a popped Domain Admin account on the general domain used the same password on the administrative domain against policy, and the attacker spreads anyway.
Yes you've got options here. For example someone might mention "Veeam Immutable Storage", which is pretty effective. But now you'll find the iLO for that server still presents a forgotten entrypoint to wiping it.
There's absolutely ways to do this properly but it's never simple, and the further you go down the hole the more likely you are to hit pricing or political stumbling blocks.
Security is not a technical problem, it's a sociopolitical problem. That's my main gripe with the business of computer security (even the name cybersecurity rubs me the wrong way... cybernetics is about robotics control systems). All these hard selling seemingly highly advanced stuff, all these script kiddies showing companies how much vulnerability is peppered all over their systems. And in the end you can call up people and they will cheerily give away credentials against vague verbal assurances.
For the data exfiltration issue, there's not much you can do other than paying and hoping for the best, and it depends on their reputation of keeping their word.
You won't get paid much and last long in the ransomware world if you have a reputation of leaking the data when paid.
One way of addressing that is by using a secure vault for sensitive data storage. This is beyond the skillset of most backend engineers, but new products such as Piiano may bridge the gap (proper disclosure: I'm a friend of one of the people behind Piiano)
Simple? Nah, doing this properly is an entire department/role (CISO) plus other groups.
Some quick practical basics.
- The fewer things, the smaller the potential attack surface.
- NIST publishes some good starting points https://www.nist.gov/cyberframework
- Shared credentials are evil. All admins should be operating off their own accounts
- MFA and SSO
- A backup isn't a backup if you haven't validated you can restore it
- Replication isn't backup. You need something that is immutable and has history. To start I would suggest a nightly backup, with each backup retained for 45 days at minimum. GDPR complicates this with right to be forgotten but this is a starting point.