McAfee Endpoint Encryption for Files and Folders. Best Practices. For EEFF product version 4.0.0

Transcription

1 McAfee Endpoint Encryption for Files and Folders Best Practices For EEFF product version 4.0.0

2 McAfee, Inc. McAfee, Inc., 2821 Mission College Blvd., Santa Clara, CA 95054, USA Tel: (+1) Internet: Document: Endpoint Encryption for Files and Folders Best Practices Last updated: Friday, 12 August 2011 Copyright (c) McAfee, Inc., and/or its affiliates. All rights reserved. McAfee and/or other noted McAfee related products contained herein are registered trademarks or trademarks of McAfee, Inc., and/or its affiliates in the US and/or other countries. McAfee Red in connection with security is distinctive of McAfee brand products. Any other non-mcafee related products, registered and/or unregistered trademarks contained herein is only by reference and are the sole property of their respective owners.

3 Table of Contents Introduction... 5 General Recommendations... 6 Client operating system...6 Log off system when not in use...6 Encryption keys in large deployments...6 Do not encrypt entire local drives...6 Prevent deployment to non-supported client OS...6 Pragmatic policy assignment rules...6 Minimize usage of System Tree based Assignments...7 Self-Extractors: Maximum data input size...7 Self-Extractors: Password rules...7 Folder encryption... 8 Local volumes...8 Program Files directory...8 Drive letters...8 The User profile folder...8 The Desktop folder...8 The Microsoft Outlook data directories...9 Removing a folder encryption policy...9 Only select folders containing sensitive files...9 Encrypted parent folder decrypted subfolder...9 Removable Media Encryption General recommendations Regular encryption recommendations EERM encryption recommendations File Extension Encryption Try to avoid using the wildcard ( * ) as extension Enter process name and extension CD/DVD encryption Supported burning applications CD format limitations EEFF client required to read encrypted CD/DVD User Local Keys User Local Keys vs. User Personal Keys Limited support in EEFF Use Key Request Exclusions Delete User Local Keys with caution Encryption Options Tune I/O Utilization to preserve network traffic Option Use wiping when encrypting and deleting files Blocked Processes Key Request Exclusions Network share encryption Very large network folders Tune Maximum number of clients allowed Tune I/O Utilization to preserve network traffic Consider the option Enable limiting of file size Encryption Keys Deactivate keys instead of Delete keys User Personal Keys and multiple epo databases... 20

4 Troubleshooting recommendations Client Status report Trace files Dump files EEFF files... 22

5 Introduction Introduction This document describes Best Practices for McAfee Endpoint Encryption for Files and Folders v4.0 (EEFF 4). The document is divided into sections where each section represents a policy property page in the EEFF extension in McAfee epo or a specific EEFF topic. For example, if you are considering deploying a folder encryption policy on a network share, the corresponding Best Practices sections in this Guide are Folder Encryption and Network encryption. Likewise, if you are only considering using removable media encryption, all sections except Removable Media and General best practices can be ignored. This is not a Product Guide or Product Description for EEFF 4. For such documentation, please consult the EEFF 4 core documentation set. This document only aims at giving advice and best practice guidelines when deploying EEFF 4. 5

6 General Recommendations General Recommendations Client operating system Assure the client operating system, including Service Pack levels, is officially supported. Log off system when not in use Log off the system when not using it. Locking the screen does not unload the keys. Encryption keys in large deployments In large deployments (30,000 + nodes), you should not deploy the keys to all systems at once. This will overload the Tomcat process on the epo server (since that is the only thing that can process data channel messages and keys are distributed via the data channel). Adopt a phased deployment strategy and keep key delivery to a level suitable to your server; a rough recommendation would be no more than 100 systems per hour. Larger servers could handle more, like 1000 systems per hour but McAfee recommends engaging professional services to determine the optimal rate for your environment. Do not encrypt entire local drives EEFF is a file and folder encryption software, not full disk encryption software. Thus, except for removable drives, it is not recommended to encrypt entire drives with EEFF, e.g. C: Prevent deployment to non-supported client OS Use epo to prevent deployments to Windows XP 64 bit and Windows Vista 64 bit. This can be done by leveraging tagging in epo. Simply create tags to identify a system s operating system, and then instruct the product deployment task to only to go systems with the appropriate operating system tag. Pragmatic policy assignment rules As a general approach, consider creating policies in a way that allows you to create a single default policy for your environment and assign that policy to all systems via a System Policy Assignment rule. Then use the User Based Policy Assignment Rules to create additional exception policies. This minimizes the amount of processing that epo has to do. 6

7 General Recommendations Minimize usage of System Tree based Assignments Try to reduce the usage of System Tree Based Policy Assignment Rules. Instead, it is recommended to use the System Based Policy Assignment Rules and the User Based Policy Assignment Rules. Self-Extractors: Maximum data input size The maximum data input size for a Self-Extractor is 10 MB. Although larger data input can be used, the recommended maximum input is 10 MB since the Self-Extractor code is optimized for this maximum data input. Self-Extractors: Password rules The password rules for Self-Extractors follow the default rules in Windows for complex passwords. These rules are static and cannot be changed in EEFF 4.0. Policy control of these password rules will be implemented in later versions of EEFF. The static password rules are: password is at least six characters long password contains characters from at least three of the following five categories: o English uppercase characters (A - Z) o English lowercase characters (a - z) o Base 10 digits (0-9) o Non-alphanumeric (For example:!, $, #, or %) Unicode characters password does not contain three or more characters from the user's account name Reference: 7

8 Folder encryption Folder encryption Local volumes Do not encrypt entire local volumes and in particular the system volume. Doing this may cause deadlocks in the client systems. Program Files directory Do not encrypt the [Program Files] directory as it may cause deadlocks in the client systems. Drive letters Do not assign folder encryption onto removable devices (e.g. a USB-Hard disk) drive based on the drive letter. As the drive letter assigned to the removable device very well may change each time the device is attached, and other drives may be assigned the letter previously assigned to the removable device, it could lead to unintentional encryption of other devices. The User profile folder Do not encrypt the entire User profile. Although the User s profile is a folder per se, it is not recommended to encrypt that entire folder with a folder encryption policy as it may render deadlocks. Instead, try to isolate what folders may actually contain sensitive data worth encrypting. If this is a real concern, consider deploying McAfee HostDLP to assess the content of each file and have sensitive files encrypted via the EEFF-HDLP integration. The Desktop folder Be careful if you plan to encrypt the Desktop folder. Only do this if you re sure you don t have static links to other drives on the desktop. LNK-linked shortcuts are fine, but static hard links to other drives will render these targets being encrypted if the shortcuts are on the Desktop. It is a best practice to specify specific directories in the EEFF folder policy screen. This is done by choosing [Desktop] and then adding the specific paths like [Desktop]\FolderA and [Desktop]\FolderB. Only choose [Desktop] if you re sure you don t have static links to other drives on the desktop. 8

9 Folder encryption The Microsoft Outlook data directories Don t encrypt the Microsoft Outlook data directories containing the OST and PST files. The McAfee recommendation is to use Windows EFS for this instead. Removing a folder encryption policy Removing a folder encryption policy does not render the content of that folder being automatically decrypted. In order to decrypt a folder listed as encrypted, you need to use the option Folder should be decrypted. Only select folders containing sensitive files Always try to pinpoint the folders containing sensitive data rather than generalizing on a high directory level, e.g. [USER]., If this is a real concern, use file extension encryption or consider deploying McAfee HostDLP to assess the content of each file and have sensitive files encrypted via the EEFF-HDLP integration. Encrypted parent folder decrypted subfolder By default, all sub-folders to a folder being encrypted will also get encrypted. However, it is possible to have a subfolder set as decrypted even if (any) parent folder is set to be encrypted, i.e. it is possible to encrypt the My Documents folder through a folder encryption policy and then have the subfolder My Video decrypted also through a policy. 9

10 Removable Media Encryption Removable Media Encryption General recommendations Definition of Removable Media in EEFF Any device that is attached to the computer and is assigned a drive letter, except for network drives, and that report itself to the operating system as Removable. The media shall also set a flag Removable in the operating system and also report to the operating system whenever a media is inserted. McAfee Encrypted USB devices are exempted by default McAfee Encrypted USB (EUSB) devices are all excluded from removable media encryption in both EERM and EEFF by default. Thus, there is no need to enter them as exempted devices. Policy enforcement for certain drives only upon write For certain devices, where a media is inserted into a reading device attached to the computer, removable media encryption policies will only be applied when there is a write operation initiated to the media. Examples of such devices are: Floppy Disk drives (FDD), and Magneto-Optical (MO) storage drives Floppy-disk drive available space When applying encryption to FDD, the floppy must contain enough free disk space to encrypt the files. If a file is larger than 50% of the floppy, the encryption will fail and the file will be left in plaintext. There is no warning message informing the user about this. Regular encryption recommendations Disabling regular removable media encryption No automatic decryption of existing files If a removable media device has already been subject to a regular removable media encryption policy, the data on the media will remain encrypted even if you disable it by switching the policy to Use no removable media encryption. The only way to decrypt the data on the media is to modify the key used in the policy. It needs to be set to Decrypt. Changing the policy to Use no removable media encryption will only affect new devices (e.g. devices that were never subject to the regular encryption policy). 10

11 Removable Media Encryption New files will keep getting encrypted Disabling the Use regular encryption option does not mean that new files created on a removable media that have been subject to the removable media encryption policy will be in plaintext - new files will still be encrypted when written to the media (the encryption policy is still applied to the removable media itself). In order to remove an applied encryption policy on removable media, the option Make all removable media plaintext must be enabled. Option Ignore existing content on media This option is disabled by default. This means that all existing files on attached removable media will become encrypted (not ignored). When this setting is enabled, only new files will be encrypted when placed on removable media attached to a system that has this policy applied. When this option is disabled, all existing files become encrypted, i.e. not ignored. Therefore, they can no longer be read from systems without Endpoint Encryption for Files and Folders. Be mindful when leaving this option disabled. EERM encryption recommendations Upgrading the EERM client on an encrypted device It is not recommended to copy/paste the new MfeEERM.exe file from an EEFF system onto an existing EERM protected device, because: 1. The new MfeEERM.exe may simply not fit in the available space on an EERM protected device. In particular, this applies when the entire device is protected. 2. If the policy to make Unprotected Files and Folders Read-Only is in effect, it is not possible to paste the new executable on the device in the first place. 3. If the new executable is smaller than the existing one, it means there will be a small space available for plaintext files, i.e. a security hole. The best way to upgrade an EERM client on an encrypted device is to backup all data in the encrypted container, reformat the device, re-initialized it from a system with the latest EEFF client installed and then put the backup data back into the encrypted container on the re-initialized device. Use User Personal Key as Recovery Key If the recovery option Recovery Key is used it is recommended to use the User Personal Key as recovery key. Using a regular key as recovery key allows all users with access to that recovery key to do recovery on other users devices where the same recovery key is in use. Using the User Personal Key as recovery key also allows auditing and forensics in a situation where e.g. an Administrator or Auditor needs to get access to a user s encrypted device. By changing the access rights for that user s User Personal Key to 11

12 Removable Media Encryption also include the Auditor, the devices can be recovered directly by the Auditor and the data content read. Exclude very-high capacity devices Exclude very large capacity devices, say above 128 GB. Although it is indeed possible to also encrypt very large capacity devices with EERM, the initialization will take a very long time. For very high capacity devices McAfee recommends hardware with built-in encryption, e.g. McAfee Encrypted USB. McAfee Device Control can then be used to block all devices that are not encrypted with EERM or are not hardware with built-in encryption. 12

13 File Extension Encryption File Extension Encryption Try to avoid using the wildcard ( * ) as extension The wildcard ( * ) extension in file extension encryption is very powerful. Truly every file created by the stated application will be encrypted, including templates, index files etc. Although attractive to use due to its ease, it is strongly recommended to carefully define what file types may be created with sensitive data worth encrypting. Make a serious attempt to list the file types being created in your organization that may contain sensitive data. For example, a template file (e.g. *.dot) does not normally contain any sensitive data. If this is a real concern, consider deploying McAfee HostDLP to assess the content of each file and have sensitive files encrypted via the EEFF-HDLP integration. Enter process name and extension You need to enter process name and the [exe] extension; e.g. notepad.exe. Process names may easily be identified by starting the corresponding application and then locate the process name in the Windows Task Manager. 13

14 CD/DVD encryption CD/DVD encryption Supported burning applications Assure the burning software is on the list of supported CD/DVD burning applications in the EEFF documentation (Product Release Notes). Using a non-supported burner may render CD/DVDs being plaintext, despite the policy stipulates encryption. CD format limitations Assure the CD/DVD media that is used is on the list of supported CD/DVD formats. EEFF client required to read encrypted CD/DVD An encrypted CD/DVD can only be read on a system that has EEFF installed and the encryption key available 14

15 User Local Keys User Local Keys User Local Keys vs. User Personal Keys Please note the difference between User Local Keys and the User Personal Key features. User Local Keys are keys the users manually can create on their own on their local machines and share manually via export/import. The availability of the User Local Key functions for the user is subject to policy control. User Personal Keys are individual keys for each user automatically created in McAfee epo and also managed centrally in McAfee epo. The user is never engaged in creating and managing User Personal Keys all management for User Personal Keys is done in epo. Limited support in EEFF 4.0 User Local Keys is not fully supported in EEFF 4.0 due to certain deferred issues. Thus, use this feature sensibly. Use Key Request Exclusions If there are files encrypted using User Local Keys, make sure you use Key Request Exclusions for relevant processes that may trigger an authentication prompt. If you don t then applications like virus scanners may get stuck on encrypted files while waiting for the user to authenticate. Delete User Local Keys with caution Be very careful with allowing users to delete local user encryption keys. If deleted, there is no way to restore that key. 15

16 Encryption Options Encryption Options Tune I/O Utilization to preserve network traffic If you want to encrypt large folders on a network share, it is recommended to set this value to 20 30%. Option Use wiping when encrypting and deleting files In general, be careful about using the use wiping when encrypting and deleting files. Basically, do not use this feature unless you absolutely must because it will slow your system down. Blocked Processes The intent of the feature Use blocked processes only if you are sure of why you want to do this. The main purpose of process blocking is to prevent encrypted data from being unintentionally exposed in plaintext; this is done by circumventing the Endpoint Encryption for Files and Folders encryption engine. One example of this is to prevent encrypted data from being uploaded to external FTP sites. By blocking the FTP process, it is not possible for the user to upload data in plaintext to an FTP server. The aim of this feature is not to share encrypted data via e.g. web-mail or the Internet. The Blocked Processes feature is not designed for such usage. Consider the process exemption feature as a prevention feature, a part of the concept of digital rights management, rather than a way for users to share encrypted data. For sharing encrypted files beside regular file shares or removable media, consider using the features of attachment encryption or Self-Extractors. Processes that are OK to block FTP processes File-sharing processes File backup processes Processes that are risky to block Internet browser processes client processes 16

17 Encryption Options Note: The data will remain encrypted, but the applications may alter the file and render the data unreadable when sent to a network resource or recipient. The source file will remain intact at all times. Processes that must never be blocked Data compression applications like WinZip The Windows Explorer Windows processes EEFF client processes Virus scanning processes Processes for other McAfee products Key Request Exclusions Processes that must never be put as exclusions The Windows Explorer EEFF client processes 17

18 Network share encryption Network share encryption Very large network folders Explicitly encrypt large shares in advance For large network folders that shall be encrypted, rather than having the folders encrypted through a folder encryption policy, consider a manual (explicit) encrypt of the network folder(s) in advance, from a machine with EEFF deployed. Initiate the encryption from this single machine, after logging on with an appropriate EEFF user, and then let the encryption run, say, maybe overnight. The reason is to avoid extreme payload on the file server(s) from many clients seeking to 1. Enumerate, 2. Fetch 3. Encrypt and 4. Upload files to/from the server(s). By doing this, the risk of network failure and file server payload overflow is minimized. Tune network parameters When encrypting large folders on a network share through a policy, it is strongly recommended to tune the network encryption intensity. The following values are recommended: I/O Utilization: 20% (Set in Encryption options policy) Bandwidth limit: 100 KB/sec. (Set in Network policy) Network latency: 600 ms. (Set in Network policy) Tune Maximum number of clients allowed You also may want to tune the network folder encryption based on the capacity of the client machines and the overall network traffic. Use the parameter Maximum number of clients allowed to encrypt folder to, say 10, for increasing the encryption intensity if there is generous network capacity. Tune I/O Utilization to preserve network traffic If you want to encrypt large folders using a folder encryption policy on a network share, it is recommended to tune the I/O Utilization value to 20 30%. Consider the option Enable limiting of file size You can use this option to prevent (very) large files from being encrypted by the policy enforcement; particularly for network shares where encryption of large files may cause heavy network traffic. 18

19 Network share encryption Files encrypted with explicit (right-click) Encrypt are not subject to this limitation, nor are files encrypted by a file extension encryption policy. Other files not subject to this limitation are files that are drag-dropped to encrypted folders and files saved to encrypted folders. Again, the option only applies for files in folders being encrypted according to a folder encryption policy. 19

20 Encryption Keys Encryption Keys Deactivate keys instead of Delete keys In McAfee epo it is strongly recommended never to delete Keys. Instead, it is sufficient to just deactivate. This is to safeguard against any eventuality where a document is encrypted with a key that is no longer in the system. A deleted encryption key cannot be restored. User Personal Keys and multiple epo databases Don t use user personal keys in a multi-database epo environment. This is only safe to do if a user only registers with one and the same epo database and always gets policies and keys from the same single epo instance. 20

21 Troubleshooting recommendations Troubleshooting recommendations Client Status report Always collect and submit the EEFF Client Status report (if possible) for all troubleshooting cases. Trace files Submit only when necessary Only create trace files if the issue really can be investigated using these files. Not all types of issues require trace files. See the EEFF Troubleshooting Guide for details. Keep the EEFF driver trace minimal in size When creating an EEFF driver trace file, ensure tracing is started just before the issue is reproduced, and stopped immediately after the issue has been reproduced. All other activities should be avoided when driver tracing is enabled; this is because the driver trace output file quickly grows very large. Don t try to read or interpret trace files Don t attempt to read or interpret/analyze any EEFF trace file as it may damage the file. Only the Engineering teams with the right debugging tools can make any use of the trace files. No secret information in the trace files No encryption key secrets data are ever included in any trace files. The only thing related to encryption keys in the trace files (and the Client Status report) is the name of the encryption key and its identifier (GUID). Give info for trace files For issues where trace files are collected, also provide details about the reproduced issue, e.g. file name, paths etc. This will greatly simplify Engineering s analysis work. Dump files For all system stop errors (BSODs): Get the dump file. Trace files are not relevant when investigating system stop errors. Only the dump file is of any importance for this kind of issue. A full memory dump is normally the best, but usually a Mini dump also gives lots of information. See the Troubleshooting Guide for additional information on how to collect dump files. Do not attempt to open and analyze the dump files as this may damage the dump file. Simply create the file and send it to McAfee Support. 21

22 Troubleshooting recommendations EEFF files For support purposes it may be useful to see in the Windows Explorer what the purpose is of each EEFF client DLL file. A short description can be made visible by enabling the Description column in the Windows Explorer. 22