4 ms·

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

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?

endisneigh 3y ago
Right but isn't that why stuff is encrypted? Is there even a way to guarantee this doesn't happen?
- bombcar 3y ago
  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.
- QuiDortDine 3y ago
  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".
  - boringuser2 3y ago
    This isn't quite right. You don't need to decrypt the entire payload at any time. You decrypt parts of the data.
  - dt3ft 3y ago
    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.
    - duckmysick 3y ago
      > 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.
      - specialist 3y ago
        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.
    - specialist 3y ago
- sidewndr46 3y ago
  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.
  - boringuser2 3y ago
    In reality, good basic practices mitigate this risk to almost nothing.
    - namaria 3y ago
      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.
    - tasuki 3y ago
      I can't imagine how. Please tell me.
  - specialist 3y ago
    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.
    - sidewndr46 3y ago
      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.
      - specialist 3y ago
        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.)
bredren 3y ago
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.
ibejoeb 3y ago
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...
hoppyhoppy2 3y ago
>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.

endisneigh 3y ago

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

bombcar 3y ago
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.
QuiDortDine 3y ago
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".
- boringuser2 3y ago
  This isn't quite right. You don't need to decrypt the entire payload at any time. You decrypt parts of the data.
- dt3ft 3y ago
  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.
  - duckmysick 3y ago
    > 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.
    - specialist 3y ago
      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.
  - specialist 3y ago
sidewndr46 3y ago
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.
- boringuser2 3y ago
  In reality, good basic practices mitigate this risk to almost nothing.
  - namaria 3y ago
    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.
  - tasuki 3y ago
    I can't imagine how. Please tell me.
- specialist 3y ago
  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.
  - sidewndr46 3y ago
    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.
    - specialist 3y ago
      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.)

bredren 3y ago

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.

ibejoeb 3y ago

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

hoppyhoppy2 3y ago

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