Hacker News Reader

Comment by smiley1437 | Hacker News Reader

In this particular case, it isn't an issue of 'data loss' which could be recovered from good backups.

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?

View on HN

Should you trust them? Well, sort of. It depends on the group. If the group has a rep, then possibly yes, because they trade on making good on the promises. A group that takes the money and still does whatever bad thing they promised not to do isn't going to get paid when word gets out.

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...

>In this particular case, it isn't an issue of 'data loss' which could be recovered from good backups.

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.

Despite the slant of this article, yes.

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.

Right but isn't that why stuff is encrypted? Is there even a way to guarantee this doesn't happen?

No real way to guarantee though you can go to great lengths to reduce the chance it happens.

Because it gets decrypted at some point.

You can't encrypt all your data at all times. It has to be decrypted somewhere along the line to be used, and hackers can gain that access as well unless the security is truly extremely tight.

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".

This isn't quite right.

You don't need to decrypt the entire payload at any time.

You decrypt parts of the data.

Encrypting data while at rest (in storage) as well as in-transit is the way to go. The servers on your infrastructure should be considered hostile at all times.

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.

> 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.

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.

Please see my sibling comment about Translucent Databases.

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.

You are emphatically, logically, ethically, technically, securely, and in all other ways correct.

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...

As others have pointed out, encryption has never worked that way. You can't just encrypt data then throw away the key and somehow have it be useful. You have to store the key. Which if attackers can compromise your data store, they can compromise your key storage infrastructure.

In reality, good basic practices mitigate this risk to almost nothing.

It's either easy and common to protect data or easy and common to steal it. Reality keeps providing evidence of the latter. Can't have it both ways.

I can't imagine how. Please tell me.

Proper password files store the salted and hashed key, not the key.

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.

Medical records are not stored for the patient to access. They are stored for the provider to access and in the event of a legal dispute, for the courts to subpoena.

As a patient, do you think that's satisfactory?

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.)

Authorized members of a patient's care team need to be able to directly share clinical data with each other. Trying to route everything through some sort of patient portal isn't practical, and would lead to delays in care or quality problems. Patients should have access to all of their data but the patient portals are spokes, not hubs.

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.

Yup. We first shipped a Physician's Portal and merely demoed the Patient Portal POC. Our patient facing product was way too early for the market (late-aughts).

as a patient I'd prefer all my records destroyed the minute the doctor is done looking at them.

Almost all of my PII and medical information is in the hands of bad actors because of this needless retention

Ah. In that case, you should employ care givers who accept cash.

Like a shaman. Or a doctor whose license has been revoked.

Good luck!

This doesn't seem to be the right way to handle keys for bulk data at rest, even assuming you were doing it to enforce patient approval.

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?

I think I crossed some wires here, confusing encryption key with database (uuid) key. Let me try again.

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.

I am trying to figure out how hashes being used as indices and password storage has anything to do with the storage and encryption of bulk data at rest. Can you elaborate?

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.

Translucent Databases applies the design of a properly implemented password store to additional use cases. Such as hiding PII.

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.

I was also pointing out hashing is not encrypting. They are not the same thing. You don't "encrypt" passwords by hashing. This is probably why your wires were crossed. It's just terminology, I get what you are saying though.

You can read here https://www.google.com/search?q=hashing+vs+encrypting to further understand.

Reply on news.ycombinator.com