File Share Encryption

I've been playing around with SEMS fileshare encryption over the past few days.  The USP for this product is that it protects important files from inside abuse by encrypting the contents whilst its at rest.  At least this is how its been sold in the past.  So even admins of the file shares themselves won't be able to view the encrypted data (HR files, intellectual property are prime examples)

So I have created a centrally controlled encrypted file share environment on our test environment with a 3.3.2 SEMS managing it.  My endpoint is 10.3.2.

I created a fileshare called 2014Test on one of our file servers, and forced encryption of all files and folders inside it. 

So i create a text file on my endpoint, and paste it into the fileshare, and all works as normal:

I then log onto the fileserver posing as an admin who wants to read the secret files and load up the same share:

When I try and load up encryptiontext.txt I get this:

When I load up the other file, PGPFS.INI, I get this:

This is all great, the contents are encrypted and is all complete garbage.  What I do next is DELETE the PGPFS.INI file.  I then upload another file into the fileshare from my workstation:

Then, I try and open up the newly input file from my "insider abuse" admin perspective and I get this:

So from the simple act of getting access to the fileshare, I can bypass the encryption in a matter of seconds.  From any sort of compliance perspective this doesn't bode well.  What sort of measures can be put in place to stop this from even happening?  I can't believe the deletion of a system file thats within the share itself is enough to render the entire share completely open.

Alex,

I understand your concern here. While the existing encrypted files are still safe, it does appear that someone could place a file in the folder, and have that file NOT encrypt, if the PGPFS.ini file is removed.

Currently, it looks like it is up to the administrator of the environment to ensure the security of file permissions within that fileshare and prevent the deletion of that file.

There is a feature request out there already, so our developers are definitely aware of this. I'll include the link here :
http://www.symantec.com/docs/TECH216868 
 

• "What sort of measures can be put in place to stop this from even happening?"

There are a number of ways that may address this concern. Speculatively, an admin could use a piece of monitoring software to notify if/when that file has been deleted. 

• "I can't believe the deletion of a system file thats within the share itself is enough to render the entire share completely open."
   

To be clear, it's not completely open. All previously encrypted data is still encrypted. However, I understand your concerns about future data being written unencrypted. As mentioned previously, there is a feature request out there for this, and it is possible that it may be resolved in a future release.

In your test, it does not make sense that you are able to open the first encryptiontest.txt file...
My guess is that in your final screenshot, you have the key for that encryptiontest file, which is still encrypted, and the encryptiontest2 file (uploaded after deletion of the inex) is not encrypted. So you may want to look those over again.

This isn't what I am experiencing in testing.  The play-by-play went like this:

1. Upload encryptiontest.txt, it encrypts and is unreadable by 3rd party
2. Delete PGPFS.INI file
3. Upload encryptiontest2.exe, it doesn't encrypt and is readable by 3rd party
4. Load up encryptiontest.txt and it is readable.

It is as if the endpoint software on the legit pc and decrypted it.

All of the notepad opening screenshots were conducted on a machine which does NOT have any encryption product of any kind installed on it.

This is what I saw in my testing:

Upload Test1.txt from client system.

Check from system without SED installed

Delete PGPFS.INI

On client system (SED installed), add Test2.txt

On system without SED, access the two files

My testing worked as expected.  Files uploaded after the removal of PGPFS.INI were not encryted, but the original file remained in an encrypted state.  I made sure to include the directoy path on each screenshot for clear reference of which system I was on, client with SED installed vs. on the server hosting the share.

After testing this, I also opened the encrypted file on the client system, nd saved it to the hare.  It remained encrypted through that as well.  I had to 'Save As...' to get it to save in an unencrypted format, which would be expected.

If you can replicate your results I would be very interested in following up with you.  PM me with the results, and then we can keep this post updated with our progress.

Thanks,

Mike