EFS Design for Irresponsible Admins
If you have read some of my other blog posts then you know I have some design philosophies that I abide by. Let me introduce to you a new one. Irresponsibility. If your design takes into account the manual actions of people, then failure is imminent, and failure is further exacerbated by admin turnover.
This leads me to my story. How do I protect user data from workstation admins tasked with supporting workstations? No this is not a rhetorical question. The design takes into account drive-by admins, i.e. connect as local admin and steal the data. I'm not really sure how many of these admins exist, however someone in the IT security department is adamant they are plentiful, and made it clear they must be stopped.
So the usual EFS mantra is that a CA/SubCA should be used for the EFS/Recovery Agent certificates. I wholeheartedly agree, but in many IT shops this is a lot of complexity and headache. In addition to the complexity there is the problem of remembering to renew the data recovery key when it expires, oh and the staff member responsible quit 8 months ago, so through the cracks it goes. In essence, this design is for the smaller sized shops who know the cracks I am talking about.
First step is to create a self-signed data recovery key, which is valid for 100 years. This command creates the DRA.cer and DRA.pfx files.
Take the DRA.pfx file off the network and put it somewhere safe! The private key within DRA.pfx has the ability to decrypt all EFS files created during the next 100 years. The DRA.cer file needs to be added to your domain group policies as a Data Recovery Agent, its sole purpose will be to encrypt the symmetric keys used to protect files.
We also need to ensure the new certificate is trusted in the domain. Open group policy editor and navigate to Trusted Root Certificate Authorities, then import the DRA.cer file which was created with the cipher command. It goes without saying, but this policy should apply to the entire domain.
The next step is to import the DRA.cer file into the Encryption File System object. This setting will enable each file's symmetric key to be stored with the file twice! Once encrypted with the users public key (we're getting there), and the second with the Data Recovery Agents public key.
Now onto the client side. When a user encrypts a file, a locally relevant public and private key pair will be generated in the user's profile. Thus, Jane Doe will have two different sets of encryption keys if she signs into two different workstations. This can be a bad thing. Her encrypted files on one workstation will not be readable on her other workstation. If you require this kind of functionality I recommend looking into something like Work Folders. Regular user files are not the only use case here either. Something else to consider is cached Outlook data files (.ost). Encrypting .ost files can stop so called drive-by admins from snooping in cached email.
The last thing I want to point out is again related to the local significance of the encryption keys. When users are sharing files on SMB network shares, it probably doesn't make sense to copy the file in it's encrypted format. There is a simple group policy object to disable encryption on NTFS volumes. This group policy should be applied to file servers used to share data among users.
This solution isn't for everyone, but will thwart simple drive-by workstations admins from stealing user data. Of course there are ways around this, for example dumping the memory contents which contain the user's private key. I would consider this relatively advanced attack, thus not "drive-by".
This leads me to my story. How do I protect user data from workstation admins tasked with supporting workstations? No this is not a rhetorical question. The design takes into account drive-by admins, i.e. connect as local admin and steal the data. I'm not really sure how many of these admins exist, however someone in the IT security department is adamant they are plentiful, and made it clear they must be stopped.
So the usual EFS mantra is that a CA/SubCA should be used for the EFS/Recovery Agent certificates. I wholeheartedly agree, but in many IT shops this is a lot of complexity and headache. In addition to the complexity there is the problem of remembering to renew the data recovery key when it expires, oh and the staff member responsible quit 8 months ago, so through the cracks it goes. In essence, this design is for the smaller sized shops who know the cracks I am talking about.
First step is to create a self-signed data recovery key, which is valid for 100 years. This command creates the DRA.cer and DRA.pfx files.
Take the DRA.pfx file off the network and put it somewhere safe! The private key within DRA.pfx has the ability to decrypt all EFS files created during the next 100 years. The DRA.cer file needs to be added to your domain group policies as a Data Recovery Agent, its sole purpose will be to encrypt the symmetric keys used to protect files.
We also need to ensure the new certificate is trusted in the domain. Open group policy editor and navigate to Trusted Root Certificate Authorities, then import the DRA.cer file which was created with the cipher command. It goes without saying, but this policy should apply to the entire domain.
The next step is to import the DRA.cer file into the Encryption File System object. This setting will enable each file's symmetric key to be stored with the file twice! Once encrypted with the users public key (we're getting there), and the second with the Data Recovery Agents public key.
Now onto the client side. When a user encrypts a file, a locally relevant public and private key pair will be generated in the user's profile. Thus, Jane Doe will have two different sets of encryption keys if she signs into two different workstations. This can be a bad thing. Her encrypted files on one workstation will not be readable on her other workstation. If you require this kind of functionality I recommend looking into something like Work Folders. Regular user files are not the only use case here either. Something else to consider is cached Outlook data files (.ost). Encrypting .ost files can stop so called drive-by admins from snooping in cached email.
The last thing I want to point out is again related to the local significance of the encryption keys. When users are sharing files on SMB network shares, it probably doesn't make sense to copy the file in it's encrypted format. There is a simple group policy object to disable encryption on NTFS volumes. This group policy should be applied to file servers used to share data among users.
This solution isn't for everyone, but will thwart simple drive-by workstations admins from stealing user data. Of course there are ways around this, for example dumping the memory contents which contain the user's private key. I would consider this relatively advanced attack, thus not "drive-by".
Comments
Post a Comment