Solved supporting an office of computers with full drive encryption
-
@DustinB3403 said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
Why do you feel that IE would ever write to the C drive?
Why wouldn't It? The C drive is the default for everything Windows.
No, it certainly is not. IE files always go to the user directory. They are user files. Same as with any normal application. The user processes don't even have permission to write to the public space.
-
@Mike-Davis said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
Standard method is to have all user accessible space on a different volume. Like a D drive (partition.) That way the system can fire up, get patched and be used like a normal system but the data you need to protect can only be accessed with a password (or something) to allow it to decrypt.
I assumed the entire drive had to be encrypted, but you suggested I didn't have to encrypt the entire drive.
Correct. And you've come up with no reason yet as to why that would not be true. So given that, I would assume that it is correct... the C drive does not need to be encrypted as no user data goes there. Just encrypt the drive with the user data.
-
Just a general note about all operating systems made today and as long as I can remember... none of them would care WHERE a binary is run from, that does not affect to where it would write temporary files. IE being moveable or not is certainly not a factor in Windows. Nor would it be in Linux, BSD, Solaris, AIX, Mac OSX, etc. The location of a binary does not have that kind of influence. That's simply the space on disk that it comes from.
-
The requirement from the security policy reads:
*Any devices connected to your computer or network containing or accessing Confidential Information must use encryption software. In addition, any device that is used to login to (application name) or other web based software containing Confidential Information must use encryption software.
Encryption is necessary even if you only access (application name) or other websites. When accessing various types of data, such as viewing a PDF or accessing certain websites, a temporary file containing hidden data from the sources could be saved to your hard drive without your knowledge. Because temporary files are often saved to your computer in these scenarios, the most prudent assumption is that your hard dive WILL include some element of Confidential Information. This is the underlying reason the breach notification laws in some states require you to notify clients when an unencrypted device is stolen.*
This is why I think I need to encrypt the entire drive.
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
Just a general note about all operating systems made today and as long as I can remember... none of them would care WHERE a binary is run from, that does not affect to where it would write temporary files. IE being moveable or not is certainly not a factor in Windows. Nor would it be in Linux, BSD, Solaris, AIX, Mac OSX, etc. The location of a binary does not have that kind of influence. That's simply the space on disk that it comes from.
no, but in a two drive scenario if IE was on the encrypted drive, there would be no way for the user to launch it unless they decrypted the secure drive.
-
@Mike-Davis said in supporting an office of computers with full drive encryption:
The requirement from the security policy reads:
*Any devices connected to your computer or network containing or accessing Confidential Information must use encryption software. In addition, any device that is used to login to (application name) or other web based software containing Confidential Information must use encryption software.
Encryption is necessary even if you only access (application name) or other websites. When accessing various types of data, such as viewing a PDF or accessing certain websites, a temporary file containing hidden data from the sources could be saved to your hard drive without your knowledge. Because temporary files are often saved to your computer in these scenarios, the most prudent assumption is that your hard dive WILL include some element of Confidential Information. This is the underlying reason the breach notification laws in some states require you to notify clients when an unencrypted device is stolen.*
This is why I think I need to encrypt the entire drive.
And, as I think I've made very clear, doesn't apply here for the reasons I've outlined. I've asked over and over why you think that this applies. Repeating the information we already know and believe says that it doesn't need to be encrypted doesn't answer the question, it just avoids it.
We KNOW that you need to encrypt any confidential temp files. No one has questioned that. It's why do you think there is anything to encrypt that I keep asking.
-
@Mike-Davis said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
Just a general note about all operating systems made today and as long as I can remember... none of them would care WHERE a binary is run from, that does not affect to where it would write temporary files. IE being moveable or not is certainly not a factor in Windows. Nor would it be in Linux, BSD, Solaris, AIX, Mac OSX, etc. The location of a binary does not have that kind of influence. That's simply the space on disk that it comes from.
no, but in a two drive scenario if IE was on the encrypted drive, there would be no way for the user to launch it unless they decrypted the secure drive.
What difference does it make if they can launch it, if it can't write temp files?
-
You can always just block IE, too. No reason for someone to be using that, this isn't 2005. It's not all that secure and it is deprecated. So in a company worried about security, I'd assume that that wouldn't be allowed anyway, right?
-
@scottalanmiller said in supporting an office of computers with full drive encryption:
You can include the program files on the D drive. It's not too hard to look at the apps that you will be using and see where they store data.
I was trying to figure out how to make your suggestion work.
-
@Mike-Davis said in supporting an office of computers with full drive encryption:
When accessing various types of data, such as viewing a PDF or accessing certain websites, a temporary file containing hidden data from the sources could be saved to your hard drive without your knowledge.
This is the portion that leads me to believe that you don't need to encrypt it. Because you are making sure that this can't happen.
-
@Mike-Davis said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
You can include the program files on the D drive. It's not too hard to look at the apps that you will be using and see where they store data.
I was trying to figure out how to make your suggestion work.
I think that it "just works." I don't see any conflict as it fixes the problems outlined in the statement. It ensures that the files written to the disk are encrypted (or not written at all.)
-
@Mike-Davis said in supporting an office of computers with full drive encryption:
@scottalanmiller said in supporting an office of computers with full drive encryption:
You can include the program files on the D drive. It's not too hard to look at the apps that you will be using and see where they store data.
I was trying to figure out how to make your suggestion work.
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.
-
Or just encrypt the whole disk and make the system that much harder to use. Not worth the complexity.
-
This especially should not be a problem since users should not be able to log in at all without the user space being decrypted. Which might make this more of a pain than it is worth. but should allow for auto-patching even if no user can log in.
-
@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 requirement
Why? 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.