Yes, the software would continue to work even though you let your support contract lapse - I would expect something else is happening - perhaps someone set a policy on your removable media to decrypt the data, or changed the policy to set your email application to be able to decrypt the file.
These are the current software policies on a client computer:
Only "Enable padlock icon visibility" is checked, everything else is unchecked including "Allow explict decrypt" and "Enable sending of encrypted email attachements"
Only "Enable network encryption" is checked
"Use McAfee Endpoint Encryption for Removable Media (EERM)" and "Make floppy disk drives Read-Only" are checked
"Preserve File Names" and "Require authentication for listing of encrypted folders" is checked
The rest are default
It's not only USB or email, even if I'm using remote desktop and copy the file from the encrypted workstation to a nonencrypted workstation, the latter can read the file.
thats to be expected - when you move a file using remote desktop, you're not "copying" the file - you are reading the file with the RDP application, and then writing a new file with the RDP application.
If you're copying a padlock file to a USB stick using explorer and the padlock is dissapearing, then there must be a decrypt policy on the stick?
This applies to any method of transfer -- email, USB, remote desktop, instant message, even CD-R.
The file can be decrypted by any client computer automatically, even if the ability to decrypt a file is disabled in the ePO server for that client computer.
As you can see, this is a huge security flaw, and our expensive Mcafee encryption software that we paid thousands for is useless.
actually no - it does not apply to file transfers, like copying with explorer etc - that preserves encryption, and no, encrypted files can not be decrypted by "any computer" - your problem is, you are doing things which are decrypting the files on your machine which DOES have the ability to decrypt them.
The thing you are missing is, sending a file via IM is not the same as copying it to a usb stick - copying a file uses Explorer.exe, sending it via IM uses the IM client.
if you don't allow the IM client to decrypt the file (bypass mode), then the file will get sent encrypted. If you do allow it, then when the IM client reads the file, it's just the same as you opening an encrypted document in Word - Word.exe gets to decrypt the file.
One is helpful behaviour, one is unhelpful. You as administrator need to decide which is which.
I'm sure before your company bought this product, they went through a lot of testing and understood exactly what the product does - perhaps the team involved in the decision can help you understand more how it works, and the features like removable media encryption, and bypass mode which prevent some of the situations you mention?
I just accessed a workstation that does not have McAfee Agent installed nor recongized by the ePo server. I went to an encrypted folder on the network and accessed an encrypted file. I was able to view the file, email the file, even preview the file online using the web gmail app. All on a workstation that does not have McAfee encryption for files and folders installed.
On a station that does have the software installed, the padlock is visible on the folder and file, and under Properties -> Encryption, the key is listed for this particular file.
That would be expected if the computer hosting the shared folder is running EEFF - accessing a file over the network is the same as accessing it locally.
The sharing computer would decrypt the file for you.
The computer hosting the files is not running EEFF.
Interestingly, I just created a new file on a computer with EEEF, manually hit encrypt, went back to the computer without EEFF, and was not able to view it. But other older files that are marked as encrypted are viewable. Is it necessary to go back and manually re-encrypt each file and folder? I thought this process would be automated as long as the folder is marked as encrypted with the padlock visible.
if the file has the padlock on it, then it must be encrypted - for you to be able to access this file from another computer not running EEFF, then the computer sharing the file must be running EEFF.
Somewhere, EEFF has to be there to decrypt the file, or you're not really opening the file from the remote computer (perhaps there's a cached copy somewhere?).
Don't share folders on computers running EEFF - it defeats the protection. You should store files on servers NOT running EEFF, but have EEFF on all the endpoints.
If you share a folder on an computer running EEFF, there's no protection.