Hard disk encryption without OS access?
-
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
It should always be. And if not, like in cases where your hardware doesn't support it (no TPM), then you would be forced to use a password to unlock it.
In essentially all cases, you'd want that anyway. Otherwise the fear of someone just stealing your computer remains. They just take the whole thing, turn it on, and attack it anyway that they want since it is decrypted, violating the intent of the rule.
"Just" stealing someone's computer and turning it on to attack away will not work when protected properly, for example, BitLocker full disk encryption + BitLocker startup PIN + proper DMA attack protection (likely the case by default with modern hardware). The TPM simply won't release the key any other way. So you can't really argue against that. Anyone who cares about the security of data on end-user devices will always enforce proper protection.
With server data, similar rules apply. You also want full disk encryption as well as the other protections, so that "just" taking the whole server and attacking away won't work either.
You're likely referring to the fact that many do not do it properly, but that isn't a valid argument that full disk encryption doesn't work. It does work, when used properly and how it was designed to work. When someone says you should use full disk encryption, it's implied that it's done properly. Any security measure can be done improperly and therefore made useless. That a given, so it must be implied done correctly.
-
@Obsolesce said in Hard disk encryption without OS access?:
"Just" stealing someone's computer and turning it on to attack away will not work when protected properly, for example, BitLocker full disk encryption + BitLocker startup PIN + proper DMA attack protection (likely the case by default with modern hardware).
Sure, but then you are back to having the human interaction again and how much is TPM really doing? It sounds nice, but honestly I don't trust the companies involved with it or how it is rolled out. But the PIN/user pass is what matters here, not the TPM. The TPM plays little value.
-
@Obsolesce said in Hard disk encryption without OS access?:
You're likely referring to the fact that many do not do it properly, but that isn't a valid argument that full disk encryption doesn't work.
Most systems can't allow downtime if a human cannot be present. The problem with full disk encryption is that...
- It protects against very little. It's a newly valueless threat in the server space, it's fear mongering that makes people concerned about it, even in highly critical government systems there is rarely a real threat to be protecting against.
- To be effective at all it requires such an onerous system. You have to have human(s) that hold the keys and are always available to the system to unlock it which means you need multiple people, sharing access, that are always there (or somewhere with access) which is generally costly, often defeats the value of the system, and creates huge risks of its own.
- In a case where most attackers would overcome issues in #1, kidnapping or threatening someone with the password is generally trivial by comparison.
-
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
You're likely referring to the fact that many do not do it properly, but that isn't a valid argument that full disk encryption doesn't work.
Most systems can't allow downtime if a human cannot be present. The problem with full disk encryption is that...
- It protects against very little. It's a newly valueless threat in the server space, it's fear mongering that makes people concerned about it, even in highly critical government systems there is rarely a real threat to be protecting against.
- To be effective at all it requires such an onerous system. You have to have human(s) that hold the keys and are always available to the system to unlock it which means you need multiple people, sharing access, that are always there (or somewhere with access) which is generally costly, often defeats the value of the system, and creates huge risks of its own.
- In a case where most attackers would overcome issues in #1, kidnapping or threatening someone with the password is generally trivial by comparison.
Yes, in the server space I'm with you 100%. It will require extra work and I also agree with the other points. While not impossible to automate using non-human methods, it's likely not going to happen, so yeah.
My main point and concern was in regard to end-user devices where the most relevant cases are lost or stolen devices (laptops/phones/etc.). You leave it in the taxi or it gets stolen somewhere... a proper setup will prevent data access.
But yes, there is the kidnapping and threatening as you say... so why implement any data security at all then? Why have a password for example on any device if someone could simply kidnap or threaten you and get it anyways? I mean while it could happen, but it's generally not the main threat and MOST CERTAINLY is not a reason to never encrypt your disks or use passwords, or lock your house when you leave...
-
@Obsolesce said in Hard disk encryption without OS access?:
My main point and concern was in regard to end-user devices where the most relevant cases are lost or stolen devices (laptops/phones/etc.).
Sure, but that was really the point of the OP
@JasGot said in Hard disk encryption without OS access?:
The software product they use for running their business is the only app on the server and the software vendor will not allow access to the server OS.
This is primarily a server encryption discussion.
-
@Dashrender said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
My main point and concern was in regard to end-user devices where the most relevant cases are lost or stolen devices (laptops/phones/etc.).
Sure, but that was really the point of the OP
@JasGot said in Hard disk encryption without OS access?:
The software product they use for running their business is the only app on the server and the software vendor will not allow access to the server OS.
This is primarily a server encryption discussion.
Yes I get that. But I was really just responding in regard to the "just stealing your computer" bit. That moreso implies personal computer, at least to me. Maybe he meant breaking into a datacenter and just stealing a server, but that didn't seem like that's what he meant.
-
@Obsolesce said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
You're likely referring to the fact that many do not do it properly, but that isn't a valid argument that full disk encryption doesn't work.
Most systems can't allow downtime if a human cannot be present. The problem with full disk encryption is that...
- It protects against very little. It's a newly valueless threat in the server space, it's fear mongering that makes people concerned about it, even in highly critical government systems there is rarely a real threat to be protecting against.
- To be effective at all it requires such an onerous system. You have to have human(s) that hold the keys and are always available to the system to unlock it which means you need multiple people, sharing access, that are always there (or somewhere with access) which is generally costly, often defeats the value of the system, and creates huge risks of its own.
- In a case where most attackers would overcome issues in #1, kidnapping or threatening someone with the password is generally trivial by comparison.
Yes, in the server space I'm with you 100%. It will require extra work and I also agree with the other points. While not impossible to automate using non-human methods, it's likely not going to happen, so yeah.
My main point and concern was in regard to end-user devices where the most relevant cases are lost or stolen devices (laptops/phones/etc.). You leave it in the taxi or it gets stolen somewhere... a proper setup will prevent data access.
But yes, there is the kidnapping and threatening as you say... so why implement any data security at all then? Why have a password for example on any device if someone could simply kidnap or threaten you and get it anyways? I mean while it could happen, but it's generally not the main threat and MOST CERTAINLY is not a reason to never encrypt your disks or use passwords, or lock your house when you leave...
Yes, end user devices which normally have no function without a human present can often use full disk encryption with minimal penalty. That a human must already be present changes a lot.
-
@Obsolesce said in Hard disk encryption without OS access?:
@Dashrender said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
My main point and concern was in regard to end-user devices where the most relevant cases are lost or stolen devices (laptops/phones/etc.).
Sure, but that was really the point of the OP
@JasGot said in Hard disk encryption without OS access?:
The software product they use for running their business is the only app on the server and the software vendor will not allow access to the server OS.
This is primarily a server encryption discussion.
Yes I get that. But I was really just responding in regard to the "just stealing your computer" bit. That moreso implies personal computer, at least to me. Maybe he meant breaking into a datacenter and just stealing a server, but that didn't seem like that's what he meant.
No, we were specially talking about people having to just steal a server instead of taking the time to remove all of the hard drives and reassmble them with the same RAID without taking the chassis or RAID device with them. It's generally less effort to steal the server than to remove all of the drives.
-
@Obsolesce said in Hard disk encryption without OS access?:
Yes, in the server space I'm with you 100%.
Which is the point of this thread.
-
@scottalanmiller said in Hard disk encryption without OS access?:
We use ProxMox. KVM is definitely the leader on the hypervisor side. Which package you use for it is up to you. We've had great luck with ProxMox now, though. We are running a LOT of them
I have been reading about ProxMox, specifically the backup system. It looks like I need to install a client, but I can't install anything on the server managed by others. What other options do I have? Just shut down the VM and make a backup of the Virtual Disk holding the VM?
-
@scottalanmiller on the other hand, it's a hell of a lot harder and questionable walking out the door with a full server than it is with a / some hard drives. Same with virtual disks, can't copy them to another system and extract data if they are encrypted. I'd still err towards encrypting data at rest (full disk encryption). Also, why aren't servers physically secured?
-
@JasGot said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
We use ProxMox. KVM is definitely the leader on the hypervisor side. Which package you use for it is up to you. We've had great luck with ProxMox now, though. We are running a LOT of them
I have been reading about ProxMox, specifically the backup system. It looks like I need to install a client, but I can't install anything on the server managed by others. What other options do I have? Just shut down the VM and make a backup of the Virtual Disk holding the VM?
So you have access to the hypervisor allowing you to turn off the VM, but you can't replace the hypervisor yourself?
-
@Dashrender said in Hard disk encryption without OS access?:
So you have access to the hypervisor allowing you to turn off the VM, but you can't replace the hypervisor yourself?
I'm not sure what you are asking..... I have no access inside what will be the running VM. I may be able to mount the offline VM and inject software or new users, but that may upset the 3rd party vendor.
-
@Dashrender said in Hard disk encryption without OS access?:
So you have access to the hypervisor allowing you to turn off the VM, but you can't replace the hypervisor yourself?
Oh. I see what you are asking. It is a physical machine right now. It is not a hypervisor. What we are talking about is making it a VM under our hypervisor to give us a Full Disk Encryption and the ability to maintain our own backup.
-
@Obsolesce said in Hard disk encryption without OS access?:
Also, why aren't servers physically secured?
They normally are, significantly, as are drives, so that makes the risk of either super low and is a key reason why encryption rarely provides protection as the risk it protects against often effectively doesn't exist.
-
@JasGot said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
We use ProxMox. KVM is definitely the leader on the hypervisor side. Which package you use for it is up to you. We've had great luck with ProxMox now, though. We are running a LOT of them
I have been reading about ProxMox, specifically the backup system. It looks like I need to install a client, but I can't install anything on the server managed by others. What other options do I have? Just shut down the VM and make a backup of the Virtual Disk holding the VM?
- All backups of live systems require clients. All, no expections (see my book, it covers this.) ProxMox uses similar agents to VMware and Windows itself - system tools, but has to interface with the hypervisor.
- You can't do live backups, given your limitations that's off the table regardless of platform. For true backups, you have to power down. That's a given with the chosen software solution. At least with ProxMox you have a mechanism to do that. How do you even attempt an offline backup with a physical server (you can but damn is it a pain.)
-
@JasGot said in Hard disk encryption without OS access?:
Just shut down the VM and make a backup of the Virtual Disk holding the VM?
Exactly, no matter what here, until you can get access not ONLY to the OS but also to the application, that's your only option.
