Local Encryption ... Why Not?
-
@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?
-
@BRRABill said:
@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.
Every extra character makes it quite a bit longer to crack. Complexity doesn't slow it down in any way.
-
@Dashrender said:
What are you paying for SEDs?
For endpoints, I buy the Samsung EVO line. They are pretty reasonable these days.
The software that manages the encryption is $39. I'm not sure what it costs in a larger scale.
-
@scottalanmiller said:
Every extra character makes it quite a bit longer to crack. Complexity doesn't slow it down in any way.
Do you have statistics on how long it takes to guess passwords of a given length?
I looked through quite a few articles and the estimates are all over the place.
-
@scottalanmiller said:
@BRRABill said:
@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.
Every extra character makes it quite a bit longer to crack. Complexity doesn't slow it down in any way.
That's not entirely true. If you KNOW that the character set doesn't have any special characters, that's like 30 points of entropy per character lost.
-
I think that we are mostly on the same page. In the OP the question was "why wouldn't you" basically asking why every machine everywhere shouldn't be encrypted. Many machines should be, some are a middle ground of it could go either way and many should not be. Encryption adds cost, complexity and certain types of risk while reducing other types of risk, mostly around theft. If your goal is blinding speed, data is not important or you need systems that can restart themselves, encryption is problematic. If you need systems that are highly secure against physical theft, you probably want encryption. It's not that I'm saying you shouldn't have encryption, you just shouldn't have it "everywhere".
