Local Encryption ... Why Not?
-
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".
-
@Dashrender said:
@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.
Except you don't know that.
-
@BRRABill said:
@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.
that's because it depends on the algorithm, the password length and the hardware used. So there is no easy answer. If you are trying to crack something with a laptop or with a Tesla cluster, you get very different results.
-
@scottalanmiller said:
certain types of risk
Being catastrophic data loss?
But wouldn't a good backup cover you there?
-
@BRRABill said:
@scottalanmiller said:
certain types of risk
Being catastrophic data loss?
But wouldn't a good backup cover you there?
Presumably. If the assumption is that people need data in dangerous places (like laptop endpoints) because they have to work offline then the assumption is that there is data there that might not be easy to back up either.
-
BTW: I get what you mean about a place like a bank. If you are running updates in the middle of the night, and it needs to reboot, someone needs to be there to get it back up.
But for a doctor office, no one is working at 3 in the morning. I understand your feeling that the doctor him or herself won't ant to do it. But if it is important to them, don't they have to be given the option?
Of course for a bank you'd want it in a secured data center if possible.
I'm talking more the fringe cases. Smaller doctor offices. Accountant with tax returns. That kind of stuff.
-
@BRRABill said:
BTW: I get what you mean about a place like a bank. If you are running updates in the middle of the night, and it needs to reboot, someone needs to be there to get it back up.
But for a doctor office, no one is working at 3 in the morning. I understand your feeling that the doctor him or herself won't ant to do it. But if it is important to them, don't they have to be given the option?
Of course for a bank you'd want it in a secured data center if possible.
I'm talking more the fringe cases. Smaller doctor offices. Accountant with tax returns. That kind of stuff.
It's less about updates, you can schedule that. It's blips that cause reboots. You can run into problems if you have regular, unexpected updates because they are inconvenient. You can run into if you want to do scheduled weekly backups as we often recommend. And you can easily run into it if you go two years without a reboot and when it happens no one knows what is wrong with the system and it is just "dead".
-
@scottalanmiller said:
It's less about updates, you can schedule that. It's blips that cause reboots. You can run into problems if you have regular, unexpected updates because they are inconvenient. You can run into if you want to do scheduled weekly backups as we often recommend. And you can easily run into it if you go two years without a reboot and when it happens no one knows what is wrong with the system and it is just "dead".
But how often do servers just randomly reboot? Or do random updates?
So if the server doesn't ever reboot, what's the issue?
-
@scottalanmiller said:
and when it happens no one knows what is wrong with the system and it is just "dead".
Then they call their friendly MSP/Consultant and say "hey it's asking for some Bitlocker password" and you give it to them and all is good in the world.
Why wouldn't this work?
-
@BRRABill said:
@scottalanmiller said:
and when it happens no one knows what is wrong with the system and it is just "dead".
Then they call their friendly MSP/Consultant and say "hey it's asking for some Bitlocker password" and you give it to them and all is good in the world.
Why wouldn't this work?
It assumes...
- Good MSP records.
- That they still have the same MSP or can find the right one.
- They know enough to call the MSP.
- They consider this something for the MSP to fix and aren't mad at the MSP for breaking the system.
- The people who worked with the MSP are still around.
- The MSP is available immediately at the time needed and doesn't need time before responding.
Lots to go wrong there. Look at @Dashrender's description of a doctor's office. They can't even figure out what app to use to open a document. how could they possibly deal with knowing what vendor to call when. They'd far more likely call the NAS vendor and yell at them for not supporting their product.
-
@scottalanmiller said:
how could they possibly deal with knowing what vendor to call when.
There is only 1 vendor to call. The people who helped them with all their computer stuff.
-
@scottalanmiller said:
- The MSP is available immediately at the time needed and doesn't need time before responding.
That's the only issue I see there.
-
But again ... what are the odds a server is just going to reboot in the middle of the day. It doesn't happen on any of my servers. Is this something you see a lot?
-
@BRRABill said:
But again ... what are the odds a server is just going to reboot in the middle of the day. It doesn't happen on any of my servers. Is this something you see a lot?
This would suck in a data center environment. Remote reboots .. Having to hop into the Out of band management to get it booted up. No Thanks.
This is why physical security is important. Have audit trails for server room access.
Also not even sure how you do this with a large scale SAN setup like ours. It's just not practical.
