Local Encryption ... Why Not?
-
I read through that Apple security document. Man, is there a lot of stuff in there that they do. No wonder it costs so much!
-
@scottalanmiller said:
@BRRABill said:
@scottalanmiller said:
Judge: "If the system was secure, why was it encrypted?"
You: "Just in case our users started storing data locally."
Judge: "And you don't feel that encrypting the drive suggests that you support that action and enable it by making it seem like you intend for them to put PHI there?"
You: "Ummm... but I didn't tell them to put it there."Judge: Were you aware that sensitive data was on the machine?
Me: Yes, that is why we installed a self-encrypting drive. As you know, sir, drives with this technology that are lost are not considered breaches.
Judge: Oh, that's right. Thank you and have a nice day!That's fine except for one thing - since when is lost data not considered a breach when encrypted? That's news to me and I'm sure would be big news to most of the American public. Why is encryption considered an exception to security and privacy norms?
Pretty sure the OCR has stated that it is not considered a breach when encrypted drives are lost.
-
@Dashrender said:
Pretty sure the OCR has stated that it is not considered a breach when encrypted drives are lost.
That is what our HIPAA specialists have told us.
A golden ticket, as you (or someone) said.
For $39 (or probably MUCH less in bulk) it's a "why wouldn't we" type of decision.
But ML doesn't feel that way. Hence the purpose of this thread!
-
@BRRABill said:
I read through that Apple security document. Man, is there a lot of stuff in there that they do. No wonder it costs so much!
I have connections to the head of security at Apple too
We've had drinks together but don't regularly hang out. A friend of a friend. Apple does some things great, some things okay and some things poorly. Device security is something that they rock on. Interfaces is where I find them to be poor. -
@Dashrender said:
@scottalanmiller said:
@BRRABill said:
@scottalanmiller said:
Judge: "If the system was secure, why was it encrypted?"
You: "Just in case our users started storing data locally."
Judge: "And you don't feel that encrypting the drive suggests that you support that action and enable it by making it seem like you intend for them to put PHI there?"
You: "Ummm... but I didn't tell them to put it there."Judge: Were you aware that sensitive data was on the machine?
Me: Yes, that is why we installed a self-encrypting drive. As you know, sir, drives with this technology that are lost are not considered breaches.
Judge: Oh, that's right. Thank you and have a nice day!That's fine except for one thing - since when is lost data not considered a breach when encrypted? That's news to me and I'm sure would be big news to most of the American public. Why is encryption considered an exception to security and privacy norms?
Pretty sure the OCR has stated that it is not considered a breach when encrypted drives are lost.
If it data is exposed and compromised? How would they explain that one? "Well there has been a breach, but we don't consider it a breach so screw you people who had your data stolen."
-
@scottalanmiller said:
I have connections to the head of security at Apple too
We've had drinks together but don't regularly hang out. A friend of a friend. Apple does some things great, some things okay and some things poorly. Device security is something that they rock on. Interfaces is where I find them to be poor.I think you would have to admit though, that there are MANY safeguards built into the device to protect the local data.
-
@BRRABill said:
@Dashrender said:
Pretty sure the OCR has stated that it is not considered a breach when encrypted drives are lost.
That is what our HIPAA specialists have told us.
A golden ticket, as you (or someone) said.
For $39 (or probably MUCH less in bulk) it's a "why wouldn't we" type of decision.
But ML doesn't feel that way. Hence the purpose of this thread!
$39 for one type of golden ticket. Not putting data there is a free one as well.
Judge: "How much data was on there."
You: "None"
Judge: "So why are we here?" -
@scottalanmiller said:
@BRRABill said:
I did a few quick Google searches, and it appears you cannot use the password to decrypt it if the drive is not in the device. It has to be in the device.
I wonder how that works. What aspect of the device makes it work that way. Complex encrypted salt on another chip?
TPM
-
@BRRABill said:
@scottalanmiller said:
I have connections to the head of security at Apple too
We've had drinks together but don't regularly hang out. A friend of a friend. Apple does some things great, some things okay and some things poorly. Device security is something that they rock on. Interfaces is where I find them to be poor.I think you would have to admit though, that there are MANY safeguards built into the device to protect the local data.
Oh yes! but none as effective as not putting the data at risk at all.
-
I edited this.
Judge: "How much data was on there."
IT Person: "None"
Judge: "Are you sure? How can you prove that?"
IT Person: "Uhhhhhhh" -
@scottalanmiller said:
If it data is exposed and compromised? How would they explain that one? "Well there has been a breach, but we don't consider it a breach so screw you people who had your data stolen."
The data is inaccessible.
Unless you portend to be able to crack 256-bit encryption.
-
@BRRABill said:
I edited this.
Judge: "How much data was on there."
IT Person: "None"
Judge: "Are you sure? How can you prove that?"
IT Person: "Uhhhhhhh"There are a few things to consider - you'd only be there if you self reported or there was a release of data that was linked back to your company about a breach larger than 500 individuals. So if you didn't already think there was data on there, why are you in front of the judge?
-
@Dashrender said:
There are a few things to consider - you'd only be there if you self reported or there was a release of data that was linked back to your company about a breach larger than 500 individuals. So if you didn't already think there was data on there, why are you in front of the judge?
Surely you aren't implying you wouldn't report a breach!
Of course you wouldn't need to with a SED.
-
@BRRABill said:
@scottalanmiller said:
If it data is exposed and compromised? How would they explain that one? "Well there has been a breach, but we don't consider it a breach so screw you people who had your data stolen."
The data is inaccessible.
Unless you portend to be able to crack 256-bit encryption.
That something is 256bit alone does not imply that it isn't easy to access. That's just one factor. There are cases where it is indeed easy to crack. And cases where it is very hard. But that alone doesn't suggest that a comprise isn't likely.
-
@Dashrender said:
@BRRABill said:
I edited this.
Judge: "How much data was on there."
IT Person: "None"
Judge: "Are you sure? How can you prove that?"
IT Person: "Uhhhhhhh"There are a few things to consider - you'd only be there if you self reported or there was a release of data that was linked back to your company about a breach larger than 500 individuals. So if you didn't already think there was data on there, why are you in front of the judge?
It's when data is linked back to you.
-
@scottalanmiller said:
That something is 256bit alone does not imply that it isn't easy to access. That's just one factor. There are cases where it is indeed easy to crack. And cases where it is very hard. But that alone doesn't suggest that a comprise isn't likely.
But it is that same evidence trail.
Complex (whatever that means to you) password coupled with assurance the encryption was on. That's what they are looking for.
You are correct in that if the password is 1234 it's easy to crack. But it is not so easy if you are using the recommended letters, numbers, etc..
And this is just for the case of "oooops, someone stole my laptop while I was in Starbucks" not some sort of crazy hacker hellbent to get your data.
To a point you've previously made:
this isn't about keeping data the most secure, per se, but rather getting the government off your back -
@BRRABill said:
You are correct in that if the password is 1234 it's easy to crack. But it is not so easy if you are using the recommended letters, numbers, etc..
Studies show that those factors do absolutely nothing to slow cracking. It's purely for duping humans into feeling things are secure, it does nothing to secure against an attack. Only length does that in any meaningful way. Complexity is a direct enemy of security because it makes humans unable to remember it while making it no harder for a computer to crack.
-
@scottalanmiller said:
@BRRABill said:
You are correct in that if the password is 1234 it's easy to crack. But it is not so easy if you are using the recommended letters, numbers, etc..
Studies show that those factors do absolutely nothing to slow cracking. It's purely for duping humans into feeling things are secure, it does nothing to secure against an attack. Only length does that in any meaningful way. Complexity is a direct enemy of security because it makes humans unable to remember it while making it no harder for a computer to crack.
Right.
If you are serious about it not getting cracked, it's gotta be looooooong.
-
I spoke a little bit with @scottalanmiller offline about this.
I now understand that servers under high security, such as in a data center, probably do not need encryption, because the odds of them getting stolen is very small. I also learned some interesting things about data centers.
I also now understand that Server 2012 is still pretty easily hackable if you have access to the physical machine. I guess I thought they would have fixed that by now, LOL.
So my discussion now falls down to locations that might not be as secure as they should be, yet need to have a server on premises. Ideally, these locations would benefit from not having a server on premises, but this is not always possible. Either by using a VPS, or by utilizing cloud options for critical services/data if possible.
The reasoning behind not using encryption on a server (including something like a PIN for Bitlocker) is that
a -- you cannot distribute the password to the staff because it weakens security or they'll put it on a post-it on the screen and
b -- you'd need a high ranking person to be present at every server reboot, which might not be palatable to these high ranking peopleRegarding endpoints, of course we would liek to see no important data located on the endpoint. But if data must be present (such as in the example where a 3rd party software product that cannot use the cloud), it makes sense to encrypt the local hard drive.
I think one of the only sticking points we still have in this discussion is the question as to why not just use a SED in any device in environemnts where there might be sensitive data on the end point. With a strong enough password, I feel it would provide pretty adequete protection to a casual thief/hacker.
@scottalanmiller ... what do you think?
-
What are you paying for SEDs?
