Solved supporting an office of computers with full drive encryption
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Mike-Davis said in supporting an office of computers with full drive encryption:
The requirement is that temporary files from using the web based software are not left unencrypted. In the suggestion that the
drive is not encrypted so that OS patches can happen I don't think that will work. If the user can launch IE without decrypting the secure drive, it fails the requirementWhy? Does IE store local files in a shared space? That sounds very unlikely. You've tested that?
Of course IE stores it's temp files in the user's profile - but why do you think that is not on the
Drive?If you redirect the profile to the D : drive (good luck actually getting that to fully work) how do you propose unlocking the d : drive? You can't unlock the D : until you get into the OS, but you can't get into the OS until you get access to the profile location, so we have a chicken or the egg problem.
But assuming you do have a solution for this, then assuming IE behaves, then yes, this would solve the problem, because the assumption is that all temp files would be written to the profile, and the profile is on the encrypted drive.
-
@NerdyDad said in supporting an office of computers with full drive encryption:
Coming into the conversation late here.
I have a full enterprise where most, if not all, of my laptops are bitlockered before they are deployed. Security keys are stored in the TPM for boot decryption. I also hold the kyes to the encryption on an IT controlled drive.
There is also a boot up password that must be entered by the user when the boot the computer up from cold. If they are rebooted, the startup password is bypassed automatically by the bios/uefi.
I've never played with Bitlocker. I was unaware that if you had a TPM that you could required a boot time password still - is that password used to unlock the TPM? How do you manage that password? What if a user forgets their TPM password?
-
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
Coming into the conversation late here.
I have a full enterprise where most, if not all, of my laptops are bitlockered before they are deployed. Security keys are stored in the TPM for boot decryption. I also hold the kyes to the encryption on an IT controlled drive.
There is also a boot up password that must be entered by the user when the boot the computer up from cold. If they are rebooted, the startup password is bypassed automatically by the bios/uefi.
I've never played with Bitlocker. I was unaware that if you had a TPM that you could required a boot time password still - is that password used to unlock the TPM? How do you manage that password? What if a user forgets their TPM password?
The boot time password has nothing to do with the TPM or bitlocker but is more of a BIOS/UEFI setting to allow access to the hard drive to boot. You could do the same thing to a computer that is totally un-bitlockered.
-
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
Coming into the conversation late here.
I have a full enterprise where most, if not all, of my laptops are bitlockered before they are deployed. Security keys are stored in the TPM for boot decryption. I also hold the kyes to the encryption on an IT controlled drive.
There is also a boot up password that must be entered by the user when the boot the computer up from cold. If they are rebooted, the startup password is bypassed automatically by the bios/uefi.
I've never played with Bitlocker. I was unaware that if you had a TPM that you could required a boot time password still - is that password used to unlock the TPM? How do you manage that password? What if a user forgets their TPM password?
The boot time password has nothing to do with the TPM or bitlocker but is more of a BIOS/UEFI setting to allow access to the hard drive to boot. You could do the same thing to a computer that is totally un-bitlockered.
Huh - so you've added yet another level of complexity. How do you manage these? Do all users have a different BIOS/UEFI password? Do the BIOS/UEFI allow for both a user level password (for disk booting) and an admin level one in case the user forgets their BIOS/UEFI password?
Also - so Bitlocker/TPM doesn't have an option for a password requirement?
You mentioned that the BIOS/UEFI does not require the password if the system is rebooted. Does this mean only when Windows is properly rebooted? or that a password is only not required when the system isn't coming from a powered off state?
What about sleep/hibernation? Is a password required then to get past the BIOS/UEFI? -
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
Coming into the conversation late here.
I have a full enterprise where most, if not all, of my laptops are bitlockered before they are deployed. Security keys are stored in the TPM for boot decryption. I also hold the kyes to the encryption on an IT controlled drive.
There is also a boot up password that must be entered by the user when the boot the computer up from cold. If they are rebooted, the startup password is bypassed automatically by the bios/uefi.
I've never played with Bitlocker. I was unaware that if you had a TPM that you could required a boot time password still - is that password used to unlock the TPM? How do you manage that password? What if a user forgets their TPM password?
The boot time password has nothing to do with the TPM or bitlocker but is more of a BIOS/UEFI setting to allow access to the hard drive to boot. You could do the same thing to a computer that is totally un-bitlockered.
Huh - so you've added yet another level of complexity. How do you manage these? Do all users have a different BIOS/UEFI password? Do the BIOS/UEFI allow for both a user level password (for disk booting) and an admin level one in case the user forgets their BIOS/UEFI password?
Also - so Bitlocker/TPM doesn't have an option for a password requirement?
You mentioned that the BIOS/UEFI does not require the password if the system is rebooted. Does this mean only when Windows is properly rebooted? or that a password is only not required when the system isn't coming from a powered off state?
What about sleep/hibernation? Is a password required then to get past the BIOS/UEFI?Yes, we did add another level of complexity that was not necessary but something the boss wanted. The boot password is a password convention that the user and IT knows, but something that anybody outside of the company would not/should not know. It should be something fairly easy for them to remember because they have to use it everyday for them to use their computers anyways. No, its not their Windows password either.
The TPM stores the key for bitlocker to begin decryption in order to boot the system.
Lenovo systems detects when Windows is being properly rebooted and does not request the boot up password. We have not yet tested sleep/hibernation as that junk typically has never worked for me in Windows. I've not had a problem with hibernation/sleep in Qubes.
-
@scottalanmiller said
The apps are of little concern, but you can encrypt them too. Some apps, not MS ones, might be vulnerabilities and write to the application space instead of user space. IE should not, not since XP. So it isn't included in any concern that was outlined above.
You always argue from the world where you have total perfect control over everything.
Most of us do not work in this same world, and have to support all manner of things.
Is it right? Should we quit and work for a place that values "pure IT" ... sure, but I bet more companies do weird stuff and use weird apps that might write to the C drive than not.
-
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
Not that I know of, but you can make sure that it only writes to the encrypted user drive.
-
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Mike-Davis said in supporting an office of computers with full drive encryption:
The requirement is that temporary files from using the web based software are not left unencrypted. In the suggestion that the
drive is not encrypted so that OS patches can happen I don't think that will work. If the user can launch IE without decrypting the secure drive, it fails the requirementWhy? Does IE store local files in a shared space? That sounds very unlikely. You've tested that?
Of course IE stores it's temp files in the user's profile - but why do you think that is not on the
Drive?Because that was the fundamental basis for this line of discussion. Put the user's directories on an encrypted D drive, keep C only for the OS. That's the very thing we are discussing.
-
@Dashrender said in supporting an office of computers with full drive encryption:
If you redirect the profile to the D : drive (good luck actually getting that to fully work) how do you propose unlocking the d : drive? You can't unlock the D : until you get into the OS, but you can't get into the OS until you get access to the profile location, so we have a chicken or the egg problem.
That's actually part of the benefit. That part isn't the issue. We are only doing this so that C can run updates even when no one is logged in. So that chicken and egg problem alone isn't a problem unless the OS can't run, either.
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
Not that I know of, but you can make sure that it only writes to the encrypted user drive.
how?
-
@Dashrender said in supporting an office of computers with full drive encryption:
If you redirect the profile to the D : drive (good luck actually getting that to fully work) ....
Weren't you just arguing that you trust MS more than me
-
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@NerdyDad said in supporting an office of computers with full drive encryption:
Coming into the conversation late here.
I have a full enterprise where most, if not all, of my laptops are bitlockered before they are deployed. Security keys are stored in the TPM for boot decryption. I also hold the kyes to the encryption on an IT controlled drive.
There is also a boot up password that must be entered by the user when the boot the computer up from cold. If they are rebooted, the startup password is bypassed automatically by the bios/uefi.
I've never played with Bitlocker. I was unaware that if you had a TPM that you could required a boot time password still - is that password used to unlock the TPM? How do you manage that password? What if a user forgets their TPM password?
The boot time password has nothing to do with the TPM or bitlocker but is more of a BIOS/UEFI setting to allow access to the hard drive to boot. You could do the same thing to a computer that is totally un-bitlockered.
Huh - so you've added yet another level of complexity. How do you manage these? Do all users have a different BIOS/UEFI password? Do the BIOS/UEFI allow for both a user level password (for disk booting) and an admin level one in case the user forgets their BIOS/UEFI password?
Also - so Bitlocker/TPM doesn't have an option for a password requirement?
You mentioned that the BIOS/UEFI does not require the password if the system is rebooted. Does this mean only when Windows is properly rebooted? or that a password is only not required when the system isn't coming from a powered off state?
What about sleep/hibernation? Is a password required then to get past the BIOS/UEFI?Yes, we did add another level of complexity that was not necessary but something the boss wanted. The boot password is a password convention that the user and IT knows, but something that anybody outside of the company would not/should not know. It should be something fairly easy for them to remember because they have to use it everyday for them to use their computers anyways. No, its not their Windows password either.
The TPM stores the key for bitlocker to begin decryption in order to boot the system.
Lenovo systems detects when Windows is being properly rebooted and does not request the boot up password. We have not yet tested sleep/hibernation as that junk typically has never worked for me in Windows. I've not had a problem with hibernation/sleep in Qubes.
What's really funny is that you have the crazy mix of "require encryption" but "trust Lenovo." That makes no sense. Especially as the UEFI being malicious being one of the issues with Lenovo!
-
@BRRABill said in supporting an office of computers with full drive encryption:
@scottalanmiller said
The apps are of little concern, but you can encrypt them too. Some apps, not MS ones, might be vulnerabilities and write to the application space instead of user space. IE should not, not since XP. So it isn't included in any concern that was outlined above.
You always argue from the world where you have total perfect control over everything.
Most of us do not work in this same world, and have to support all manner of things.
I'm speaking to "whoever is the IT manager." Or to "whoever is going to advise them." In those cases, they always have control.
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
If you redirect the profile to the D : drive (good luck actually getting that to fully work) how do you propose unlocking the d : drive? You can't unlock the D : until you get into the OS, but you can't get into the OS until you get access to the profile location, so we have a chicken or the egg problem.
That's actually part of the benefit. That part isn't the issue. We are only doing this so that C can run updates even when no one is logged in. So that chicken and egg problem alone isn't a problem unless the OS can't run, either.
There is still a chicken/egg problem because the user will never be able to log into the computer.
Computer boots, user tried to logon, profile is on encrypted drive, which is still encrypted can can't be unencrypted until after the user logs on. So logon fails because the logon service can't reach the user's profile.
Unless you're saying you know of some process that will decrypt the encrypted volume on the fly during and based upon the user's logon?
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
If you redirect the profile to the D : drive (good luck actually getting that to fully work) ....
Weren't you just arguing that you trust MS more than me
No, if anything, I was arguing that I I trust them the same as you.
-
@BRRABill said in supporting an office of computers with full drive encryption:
Is it right? Should we quit and work for a place that values "pure IT" ... sure, but I bet more companies do weird stuff and use weird apps that might write to the C drive than not.
So you are saying that you think that it's acceptable to have known security design problems with apps exposing user data, but then encrypt them to ignore that there are more fundamental security issues?
What software do you think people have that is doing this? Any why would a shop that claims to be super concerned about security choose to deploy them?
You say that I look at the world from an ideal standpoint, but I'm just looking at it from a logical one. Logically, if you care about security you care, and if you don't, you don't. The encryption is just a farce in your logic and IT isn't there to do a good job, just to cover up stuff.
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
If you redirect the profile to the D : drive (good luck actually getting that to fully work) ....
Weren't you just arguing that you trust MS more than me
Now you've lost me though - profile redirection causes all kinds of problems. Can you make it work, yes. Is it easy ? Heck no. My own personal experience also says it's not that stable either, but I'm willing to take the blame on that bit if needed.
-
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
the files written to the disk are encrypted (or not written at all.)
OK I think I see what Scott is writing here. IE has a setting:
https://i.imgur.com/audFdVc.pngThis will prevent encrypted pages from being saved to disk.
But my question to @scottalanmiller is - What about confidential information that is viewed over a non encrypted connection?
Is there a way to make IE, and all other software, not write temp files to the drive at all? And of course, I never saw any discussion at all about the page file, which as far as I know can only be encrypted when using full disk encryption.
Not that I know of, but you can make sure that it only writes to the encrypted user drive.
how?
By putting the user's directories on D... the thing we are discussing.
Not trusting Windows is a different matter. If you feel Windows simply can't be trusted, the only answer is really to leave Windows.
-
@Dashrender said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
@Dashrender said in supporting an office of computers with full drive encryption:
If you redirect the profile to the D : drive (good luck actually getting that to fully work) ....
Weren't you just arguing that you trust MS more than me
Now you've lost me though - profile redirection causes all kinds of problems. Can you make it work, yes. Is it easy ? Heck no. My own personal experience also says it's not that stable either, but I'm willing to take the blame on that bit if needed.
It's amazing how much the simplest tasks are major issues on Windows
