3 ms·

The "does not support basic security features such as encryption for stored data" unquoted line of reporting is almost certainly not what Mudge wrote and is lik

The "does not support basic security features such as encryption for stored data" unquoted line of reporting is almost certainly not what Mudge wrote and is likely not literally true. That 500k servers in Twitter infra are missing patches certainly is true and what was likely in the original was a statement that stored data that should have been encrypted at rest was not, and/or that acceptable standards for data at rest encryption, a relatively rapidly moving freight train, were not maintained.

hn_throwaway_99 4y ago
I have discovered that there are vastly different definitions of "encryption for stored data" that can mean critically different things for security. One definition is "the underlying disk is encrypted". This is true, by default, of virtually all cloud environments these days. But it really only protects you against physical access to the storage media, which actually is far from the top threat. The other, more useful/meaningful definition, is "we encrypt everything at the application layer before it is placed into the DB, and all decryption requests are logged by user". For example, using an envelope encryption scheme to encrypt data before it is stored in a DB, and upon retrieval decrypting the data with a call to something like KMS. In that environment you can literally give readonly DB access to all your developers and not have to worry about PII being exposed. If hackers somehow got access to your DB, they wouldn't be able to read sensitive data, and if they also managed to get access to your KMS credentials, any attempts to decrypt the data would be tracked and logged. My point is that when many companies say "we encrypt your data", they are usually just talking about the first thing, but that doesn't really provide that much additional security. The second definition is really what you should be doing.
- olliej 4y ago
  I think the good comparison that people encounter day-to-day is full disk encryption. It's the default on macOS, the only option on iOS, (those are the two platforms I use), and I assume the case on windows and android. The thing is FDE essentially only protects your data when your machine is powered off. Once your machine is booted and you've logged in any block level encryption ceases to be relevant, because to get to the point of running your machine has to have loaded in the relevant key material to decrypt. From that point on user space code no longer sees a difference between encrypted and decrypted drives. In other words FDE is not relevant is you lose a powered on device (post login if relevant to the platform), and you're the kind of person people are actively targeting (I recall recently? the content of someone's phone or such being dumped by the FBI because they grabbed it while it was being used). That's why modern OS's have different key classes, there's the lowest level which is just FDE, but you can have higher levels where requesting key material essentially just gives you a handle to that material. Then the OS, or preferably hardware with a much less complex OS, manages those handles and invalidates them according to policy rules. e.g you may want your phone to have access to your address book while your phone is locked, which does not mean you need your call history available as well. The policies provided by OSs tend to be fairly simple because it's better to have an easy to understand API that is easy to use and hard to screw up than a more "powerful" API that is easy to screw up and hard to use (the latter resulting in people simply not encrypting things at all). e.g iOS/macOS only has the following file protections when you create files: "NSFileProtectionComplete", "NSFileProtectionCompleteUnlessOpen", "NSFileProtectionCompleteUntilFirstUserAuthentication", "NSFileProtectionNone", but they're very easy to understand.[1] I tried to find the android equivalent but I don't know the terminology that's used and I just get linked to instructions on using AES, so if someone could link the correct doc I'd appreciate it. [1] https://support.apple.com/guide/security/data-protection-classes-secb010e978a/web https://support.apple.com/guide/security/data-protection-cla... and https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web https://support.apple.com/guide/security/keychain-data-prote...
akkartik 4y ago
No need to speculate, thanks to the links provided by mzs at https://news.ycombinator.com/item?id=32562815#32564900 https://news.ycombinator.com/item?id=32562815#32564900 From https://www.washingtonpost.com/technology/interactive/2022/twitter-whistleblower-sec-spam/risk_committee_issues.pdf https://www.washingtonpost.com/technology/interactive/2022/t..., page 6: "..more than half of Twitter's 500,000 servers are running out-of-date operating systems so out of date that many do not support basic privacy and security features and lack vendor support. More than quarter of the 10,000 employee computers have software updates disabled! More than half of Twitter employees have access to Twitter's production environment -- unheard of in a company the age and importance of Twitter, where nearly all employees have access to systems or data they should not. At Twitter engineers work on live data when building and testing software because Twitter lacks testing and stage environments; work is conducted instead in production and with live data.. "This did not happen overnight. To get where Twitter is today took.. many years.. required repeated downplaying of problems, selective reporting, and leadership ignorance around basic security expectations and practices."

hn_throwaway_99 4y ago

I have discovered that there are vastly different definitions of "encryption for stored data" that can mean critically different things for security. One definition is "the underlying disk is encrypted". This is true, by default, of virtually all cloud environments these days. But it really only protects you against physical access to the storage media, which actually is far from the top threat. The other, more useful/meaningful definition, is "we encrypt everything at the application layer before it is placed into the DB, and all decryption requests are logged by user". For example, using an envelope encryption scheme to encrypt data before it is stored in a DB, and upon retrieval decrypting the data with a call to something like KMS. In that environment you can literally give readonly DB access to all your developers and not have to worry about PII being exposed. If hackers somehow got access to your DB, they wouldn't be able to read sensitive data, and if they also managed to get access to your KMS credentials, any attempts to decrypt the data would be tracked and logged. My point is that when many companies say "we encrypt your data", they are usually just talking about the first thing, but that doesn't really provide that much additional security. The second definition is really what you should be doing.

olliej 4y ago
I think the good comparison that people encounter day-to-day is full disk encryption. It's the default on macOS, the only option on iOS, (those are the two platforms I use), and I assume the case on windows and android. The thing is FDE essentially only protects your data when your machine is powered off. Once your machine is booted and you've logged in any block level encryption ceases to be relevant, because to get to the point of running your machine has to have loaded in the relevant key material to decrypt. From that point on user space code no longer sees a difference between encrypted and decrypted drives. In other words FDE is not relevant is you lose a powered on device (post login if relevant to the platform), and you're the kind of person people are actively targeting (I recall recently? the content of someone's phone or such being dumped by the FBI because they grabbed it while it was being used). That's why modern OS's have different key classes, there's the lowest level which is just FDE, but you can have higher levels where requesting key material essentially just gives you a handle to that material. Then the OS, or preferably hardware with a much less complex OS, manages those handles and invalidates them according to policy rules. e.g you may want your phone to have access to your address book while your phone is locked, which does not mean you need your call history available as well. The policies provided by OSs tend to be fairly simple because it's better to have an easy to understand API that is easy to use and hard to screw up than a more "powerful" API that is easy to screw up and hard to use (the latter resulting in people simply not encrypting things at all). e.g iOS/macOS only has the following file protections when you create files: "NSFileProtectionComplete", "NSFileProtectionCompleteUnlessOpen", "NSFileProtectionCompleteUntilFirstUserAuthentication", "NSFileProtectionNone", but they're very easy to understand.[1] I tried to find the android equivalent but I don't know the terminology that's used and I just get linked to instructions on using AES, so if someone could link the correct doc I'd appreciate it. [1] https://support.apple.com/guide/security/data-protection-classes-secb010e978a/web https://support.apple.com/guide/security/data-protection-cla... and https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web https://support.apple.com/guide/security/keychain-data-prote...

akkartik 4y ago

No need to speculate, thanks to the links provided by mzs at https://news.ycombinator.com/item?id=32562815#32564900 https://news.ycombinator.com/item?id=32562815#32564900 From https://www.washingtonpost.com/technology/interactive/2022/twitter-whistleblower-sec-spam/risk_committee_issues.pdf https://www.washingtonpost.com/technology/interactive/2022/t..., page 6: "..more than half of Twitter's 500,000 servers are running out-of-date operating systems so out of date that many do not support basic privacy and security features and lack vendor support. More than quarter of the 10,000 employee computers have software updates disabled! More than half of Twitter employees have access to Twitter's production environment -- unheard of in a company the age and importance of Twitter, where nearly all employees have access to systems or data they should not. At Twitter engineers work on live data when building and testing software because Twitter lacks testing and stage environments; work is conducted instead in production and with live data.. "This did not happen overnight. To get where Twitter is today took.. many years.. required repeated downplaying of problems, selective reporting, and leadership ignorance around basic security expectations and practices."