File and Removable Media Protection 4.3.0 Best Practices · PDF fileProduct and feature names and descriptions are subject to change without notice. ... File and Removable Media Protection

Best Practices Guide

McAfee File and Removable MediaProtection 4.3.0For use with ePolicy Orchestrator 4.6.6, 4.6.7, 5.0.1, 5.1 Software

COPYRIGHTCopyright © 2014 McAfee, Inc. Do not copy without permission.

TRADEMARK ATTRIBUTIONSMcAfee, the McAfee logo, McAfee Active Protection, McAfee DeepSAFE, ePolicy Orchestrator, McAfee ePO, McAfee EMM, Foundscore, Foundstone, PolicyLab, McAfee QuickClean, Safe Eyes, McAfee SECURE, SecureOS, McAfee Shredder, SiteAdvisor, McAfee Stinger, McAfee Total Protection, TrustedSource,VirusScan, WaveSecure are trademarks or registered trademarks of McAfee, Inc. or its subsidiaries in the United States and other countries. Othernames and brands may be claimed as the property of others.

Product and feature names and descriptions are subject to change without notice. Please visit mcafee.com for the most current products and features.

LICENSE INFORMATION

License AgreementNOTICE TO ALL USERS: CAREFULLY READ THE APPROPRIATE LEGAL AGREEMENT CORRESPONDING TO THE LICENSE YOU PURCHASED, WHICH SETSFORTH THE GENERAL TERMS AND CONDITIONS FOR THE USE OF THE LICENSED SOFTWARE. IF YOU DO NOT KNOW WHICH TYPE OF LICENSE YOUHAVE ACQUIRED, PLEASE CONSULT THE SALES AND OTHER RELATED LICENSE GRANT OR PURCHASE ORDER DOCUMENTS THAT ACCOMPANY YOURSOFTWARE PACKAGING OR THAT YOU HAVE RECEIVED SEPARATELY AS PART OF THE PURCHASE (AS A BOOKLET, A FILE ON THE PRODUCT CD, OR AFILE AVAILABLE ON THE WEBSITE FROM WHICH YOU DOWNLOADED THE SOFTWARE PACKAGE). IF YOU DO NOT AGREE TO ALL OF THE TERMS SETFORTH IN THE AGREEMENT, DO NOT INSTALL THE SOFTWARE. IF APPLICABLE, YOU MAY RETURN THE PRODUCT TO MCAFEE OR THE PLACE OFPURCHASE FOR A FULL REFUND.

2 McAfee File and Removable Media Protection 4.3.0 Best Practices Guide

http://mcafee.com

Contents

1 Introduction 5How File and Removable Media Protection works . . . . . . . . . . . . . . . . . . . . . . 5Purpose of this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 General recommendations 7Deployment and activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Database sizing considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Policy assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Moving machines with FRP installed from one McAfee ePO server to another . . . . . . . . . . 9Compatibility with other encryption products . . . . . . . . . . . . . . . . . . . . . . . 9Delegated administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Encryption options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Blocking processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Key request exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 File and Removable Media Protection use cases 13Secure sharing with USB devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Enforce Encryption (onsite access only) . . . . . . . . . . . . . . . . . . . . . . 14Allow Encryption (with offsite access) or Enforce Encryption (with offsite access) . . . . . 14Device exemptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Secure sharing with CD/DVD/ISOs . . . . . . . . . . . . . . . . . . . . . . . . . . 16Protecting sensitive folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

General encryption guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 16Removing a folder encryption policy . . . . . . . . . . . . . . . . . . . . . . . 17Encrypted parent folder — decrypted subfolder . . . . . . . . . . . . . . . . . . . 17

Protecting sensitive files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Enable search encrypted option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Protecting network share folders . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Securing email attachments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Encryption keys 21Regular and user personal keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21User local keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Index 23

McAfee File and Removable Media Protection 4.3.0 Best Practices Guide 3

Contents


1 Introduction

McAfee®

File and Removable Media Protection (FRP) delivers policy-enforced, automatic andtransparent encryption of files and folders on PCs, file servers, emails, and removable media such asUSB devices and CD/DVDs.

FRP is managed by McAfee® ePolicy Orchestrator (McAfee ePO), creating a central point ofmanagement that ensures your data is safe wherever it goes.

Typical FRP use cases include encrypting files such as spreadsheet and sensitive documents, andenabling secure access to a specific folder on a network file share, enabling users to securely copyinformation on removable media and send self-extracting files in email attachments to partners orclients.

Contents How File and Removable Media Protection works Purpose of this guide

How File and Removable Media Protection worksFRP encrypts files and folders on local drives, network shares, and removable media devices accordingto the policies enforced by the McAfee ePO server.

FRP supports both user and system-based policies, and provides a single point of control to protectdata in your environment through integration with McAfee ePO. FRP relies on Microsoft Windowscredentials, so both registered domain users and local system users can be assigned product policiesand encryption keys.

When the FRP client is installed on the system, the system synchronizes with the McAfee ePO serverand fetches product policies and encryption keys. The FRP client acts like a filter between theapplication creating or editing the files and the storage media. When a file is saved, the FRP filterexecutes the assigned policies and encrypts the data if applicable. The product is transparent to theend user, ensuring a seamless experience.

File and Removable Media Protection is available as part of the following suites:

• McAfee Complete Endpoint Protection - Business (CEB)

• McAfee Complete Data Protection - Advanced (CDA)

• McAfee Complete Data Protection (CDB)

1


Purpose of this guideThis guide suggests best practices for deployment and management. It also discusses optimizationand maintenance before and after deployment.

This document encapsulates the professional opinions of FRP certified engineers, and is not an exactscience. You must understand both the product and the environment where it will be used beforedeciding on an implementation strategy. Calculations and figures in this guide are based on fieldevidence and not theoretical system testing; they are our best advice at the time of writing. Reviewthe best practices and use the guidelines that best fit your environment.

This is not intended to serve as a product guide.

• For details on how to deploy and use FRP, see the McAfee File and Removable Media Product Guideand the McAfee File and Removable Media Migration Guide.

• For customized recommendations and optimizations for your environment, contact McAfeeProfessional Services.

• To discuss product use cases and recommendations on feature usage and to obtain the latestinformation, visit the McAfee Community Forum: https://community.mcafee.com/community/business/data/epoenc

• For issues related to the product, contact McAfee Support.

1 IntroductionPurpose of this guide


https://community.mcafee.com/community/business/data/epoenc

https://community.mcafee.com/community/business/data/epoenc

2 General recommendations

Contents Deployment and activation Database sizing considerations Policy assignments Moving machines with FRP installed from one McAfee ePO server to another Compatibility with other encryption products Delegated administration Encryption options

Deployment and activationThis section provides general recommendations for the deployment of FRP.

Client operating systems

• Verify operating system support — Make sure that the client operating system, includingservice pack levels, is officially supported. For details, see KB81149.

• Prevent deployment to non-supported client operating systems — Use McAfee ePO toprevent deployments to unsupported operation systems such as Windows XP 64 bit and WindowsVista 64 bit. McAfee ePO together with McAfee® Agentwill ensure that the FRP client is run only onendpoints with supported operating systems.

VDI environments

For the latest information on support for VDI environments, including installation details andapplicable constraints, see KB81478.

Deployment using third-party tools

You can manually install FRP 4.3.x locally or in conjunction with a third-party deployment tool usingthe command line interface.

To upgrade from McAfee® Endpoint Encryption for Files and Folders, you must first uninstall theexisting version. You must install a supported version of McAfee Agent before using the command linemethod.

The specific command depends on the operating system:

• 32-bit operating system: msiexec.exe /q /i eeff32.msi

• 64-bit operating system: msiexec.exe /q /i eeff64.msi

2


https://kc.mcafee.com/corporate/index?page=content&id=KB81149


After executing the command line instruction, you must restart the client to complete the installationprocedure. For details on installing FRP from the command line, see KB81433.

Deployment through McAfee ePO is the recommended approach.

Encryption key deploymentInitial key delivery following deployment to a large number of client systems can subject the Tomcatprocess on the McAfee ePO server to high load, as it has to process secure data channel messages toand from the client. To reduce the risk of overloading the Tomcat process, adopt a phased deploymentstrategy so that the key delivery can be evenly distributed. Although the number of systems that canbe supported consecutively depends on a number of factors (server performance, number of keysgranted to each client, whether database is local to McAfee ePO server, and so on), we recommendstarting at 100 systems per hour and monitoring the load. Alternatively, consult McAfee ProfessionalServices to determine the optimal rate for your environment.

Database sizing considerationsThis section provides recommendations regarding database sizing.The main database sizing considerations for FRP relate to:

• Encryption keys that are generated on McAfee ePO — regular and user personal keys

• Removable Media Events (USB and CD/DVD) that are generated on FRP clients and sent to McAfeeePO for the purpose of auditing or reporting

Encryption keysFRP creates three tables to maintain encryption key information. For an environment with 10,000users where a user personal key is assigned to every user (10,000 keys) and 1000 regular keys, acombined total of ~20 MB of index space and ~6 MB of data space are required.

EventsRemovable Media events are lightweight. This generic formula can be used to calculate the spacerequirements:

Data Space = Number of events/per node/per day * Number of Nodes * Number of Days * 0.3 KB

Index Space = Number of events/per node/per day * Number of Nodes * Number of Days * 0.002 KB

For example, for an environment with 10,000 nodes with an average of 10 events per node per day,for a period of 30 days:

• Data Space required = ~900 MB

• Index Space required = ~6 MB

Policy assignmentsThis section provides recommendations regarding the effective implementation of policy assignments.

Pragmatic policy assignment rulesWe recommend that you simplify policy assignments by defining a baseline or default policy for yourorganization, and implementing it as a system-based policy. Then, for any exceptions to the policy,create a user-based policy assignment rule. This rule will always supersede system-based policies

2 General recommendationsDatabase sizing considerations



(both those assigned via the System Tree and those assigned by system-based policy assignment rules),making this the easiest way to implement complex policies. This also minimizes the amount ofprocessing on the McAfee ePO server.

For further information on policy assignments, see KB81441 and KB72775.

Moving machines with FRP installed from one McAfee ePOserver to another

Encryption keys and policy information must be exported and imported to the new McAfee ePOserver.

For user personal keys to continue to function seamlessly, ensure that the user domain and user namedetails do not change.

If you are using Role-Based Key Management, ensure that you create equivalent roles on the newMcAfee ePO server before importing the keys. If matching roles are not found, the key import processwill fail.

Compatibility with other encryption productsFRP is not compatible with other file-level encryption products such as Microsoft Encrypted File System(EFS).

Both FRP and products such as EFS are file encryption products that work at the same file systemlevel, therefore a driver conflict would occur.

Delegated administration Role-based key management provides the ability to logically separate and compartmentalize keymanagement across multiple administrators. This functionality is critical for separation of duties acrossbusiness functions and subsidiaries, and also helps protect the activities of different groups from oneanother.

This functionality is enabled in three steps (performed by the Global Key Administrator):

• Creation of a role (for example, Finance)

• Creation of a permission set (with the necessary privileges) and its assignment to a role

• Creation of a McAfee ePO user to serve as the Key Admin (for example, Finance Key Admin) andassociating the user with the appropriate permission set

The permission set binds the role (Finance) with the McAfee ePO user (Finance Key Admin).

Any McAfee ePO Global Administrator can play the role of Global Key Administrator. The Global KeyAdministrator is assigned the "Default" role and does not have access to keys associated with otherroles. If, for example, the HR Finance Key Admin leaves the organization, Global Key Administrator cancreate a new McAfee ePO user and assign the user the necessary role and permission set required formanaging the HR Group.

General recommendationsMoving machines with FRP installed from one McAfee ePO server to another 2




An audit trail is created to enable the monitoring of key management and policy assignment functionsperformed by administrators to ensure compliance and prevent abuse by administrators.

Encryption options

Blocking processesFRP acts as a persistent encryption engine. When a file is encrypted, it remains encrypted even if thefile is moved out of an encrypted directory.

Nonetheless, in certain scenarios encrypted data might be unintentionally exposed in plaintext. Forexample, when uploading files to an FTP server, encrypted files are uploaded in plain text format. Thisis because socket communication is used for the file operation instead of Windows I/O file operation.

To allow encrypted data to be uploaded with persistent encryption, you can configure the FTP processas a blocked process. Blocked processes (applications) always receive files in cipher text from the FRPfilter driver, meaning that the files are not decrypted for the blocked processes.

The main purpose of process blocking is to prevent encrypted data from being unintentionally exposedin plaintext; this is done by circumventing the FRP encryption engine. Consider the process exemptionfeature as a prevention feature, a part of the concept of digital rights management, rather than a wayfor users to share encrypted data over Internet or web-mail.

2 General recommendationsEncryption options


Processes that can be safely blocked

• FTP processes

• File sharing processes

• File backup processes

Processes that are risky to block

• Internet browser processes

• Email client processes

The data remains encrypted, but the applications might alter the file and render the data unreadablewhen sent to a network resource or email recipient. The source file remains intact at all times.

Processes that must never be blocked

• Data compression applications like WinZip • FRP client processes

• Windows Explorer • Virus scanning processes

• Windows processes • Processes for other McAfee products

Key request exclusionsYou can define key request exclusions so that specific processes are not stopped when they trigger anauthentication prompt and an encryption key is not available.

For example, if there are encrypted files for which the key is unavailable (or there are files encryptedusing user local keys), applications like virus scanners might get "stuck" on encrypted files because itcannot access the files, and the scanning process stops. To avoid such situations, make sure that youdefine key request exclusions for any process that automatically gets an Access Denied message if keysare unavailable.

Key request exclusions should never be defined for Windows Explorer and FRP client processes.

General recommendationsEncryption options 2


2 General recommendationsEncryption options


3 File and Removable Media Protection usecases

Contents Secure sharing with USB devices Secure sharing with CD/DVD/ISOs Protecting sensitive folders Protecting sensitive files Enable search encrypted option Protecting network share folders Securing email attachments

Secure sharing with USB devicesFRP offers a number of protection options for USB devices. Select the protection level based on therequirements of your environment.

• To restrict access to the encrypted USB devices to within the company's environment only, selectthe Enforce Encryption (onsite access only) option.

• To enable users to access encrypted USB devices on systems without having to install any McAfeeencryption software, select either Allow Encryption (with offsite access) or Enforce Encryption (with offsite access)options.

• The Enforce Encryption (with offsite access) option allows a file to be copied to the USB device only when itis encrypted, otherwise the device is rendered read-only. If the User Managed option is selected,files can be copied only to the encrypted portion of the device.

• To define the use of USB sticks as read-only, select the Block Write Operations option.

3


Enforce Encryption (onsite access only)These encryption options are relevant for the Enforce Encryption (onsite access only) setting.

• No automatic decryption of existing files — If a removable media device is already subject toan Enforce Encryption (onsite access only) policy, the data on the USB device remains encrypted even ifyou disable it by setting the policy to Allow Unprotected Access. To decrypt the data on the device, setthe Key Field option to Decrypt. Changing the policy to Allow Unprotected Access affects new devices only(devices not previously subject to the Enforce Encryption (onsite access only) policy).

• New files keep getting encrypted — Disabling the Enforce Encryption (onsite access only) option doesnot mean that new files created on a removable media that have been subject to the removablemedia encryption policy will be in plaintext. New files are still encrypted when written to the media(the encryption policy is still applied to the USB device itself). To remove an applied encryptionpolicy on removable media, set the Key Field option to Decrypt.

• Ignore existing content on media — When the Ignore existing content on media option is disabled, allexisting files on the attached removable media become encrypted (not ignored). Therefore, theycan no longer be read from systems without FRP. Beware of leaving this option disabled. When thissetting is enabled, only new files are encrypted when placed on a USB device where this policy isapplied.

Allow Encryption (with offsite access) or Enforce Encryption(with offsite access)It is possible to initialize the entire device or part of it based on the selected Protected Area setting.

With the full device policy in place, if the end user chooses to back up the existing data, the data onthe device is first copied to the system drive on the local computer. An encrypted container is thencreated on the removable device, and finally the data is copied back from the local computer to theencrypted container (removable device). In this process, there might be limitations in terms of freespace on the local machine and the time required for the copy operations (back and forth) might besubstantial.

We recommend that the Administrator select the User Managed option. This allows the end user todetermine the size of the encrypted container. The maximum size of the encrypted container that theuser can create is equal to the free space on the USB device.

Using the user personal key as the recovery keyWe recommend that the recovery key be configured as a recovery method, and that the user personalkey be used for this purpose.

Using a regular key as the recovery key allows all users with access to that recovery key to performrecovery on other users’ devices where the same recovery key is in use. Assigning the user personalkey as the recovery key for removable media encryption ensures that the USB media can be recoveredonly by the user who encrypted it.

Support for large files in the encrypted containerEnable the Allow large file support (> 4 GB) option to allow files of size larger than 4 GB to be copied to theencrypted container.

When a device that is initialized with EEFF 4.2 or below is inserted on to a FRP 4.3 client with the Allowlarge file support (> 4 GB) option enabled, the container format is automatically updated to support largerfiles (wherever applicable). There is no need to reinitialize the device.

3 File and Removable Media Protection use casesSecure sharing with USB devices


Clients running on EEFF 4.2 or below cannot recognize the new FRP 4.3 container format. Start byupgrading clients to FRP 4.3 with the Allow large file support (> 4 GB) option turned off. Once a critical massof clients is on FRP 4.3, apply the new container format by enabling the policy.

Machines running an earlier version FRP (EEFF) do not have the intelligence to detect the new containerformat. Files on the encrypted device can be read on these machines using the offsite application butthis is not advisable.

Mac OS X offsite browser for USB mediaOffsite support on Mac OS X clients has been introduced in FRP 4.3. Any encrypted device using theoffsite access options (formerly known as EERM) can now be accessed on Mac OS X clients.

In addition to being able to read files on the device, it is possible to do in-place edits and copy files toand from the encrypted USB device.

Previously encrypted devices are automatically provisioned with the Mac offsite browser when the USBdevices are inserted on to a FRP 4.3 client. There is no need to reinitialize existing encrypted devices.

Auditing and reportingFRP provides rich auditing and reporting capabilities where end-user activity related to the use of USBmedia is captured and transmitted back to McAfee ePO.

The product provides a rich reporting framework that allows administrators to run custom queries onthe audit event database.

Device exemptionsDevice exemptions are based on the Device Instance Path ID. Devices are exempted based on a substringmatch.

For example, if the Device Instance Path ID was identified as USBSTOR\DISK&VEN_KINGSTON&PROD_DATATRAVELER_G3&REV_1.00\001CC0EC321DFBC0B717268 6&0,then these strings can be configured to exempt devices:

• KINGSTON — Exempts all KINGSTON devices

• DATATRAVELER — Exempts all DATATRAVELER models regardless of whether the MAKE isKINGSTON

• G3 — Exempts any device with G3

• DISK&VEN_KINGSTON&PROD_DATATRAVELER_G3&REV_1.00, and so on

The example above demonstrates the use of a single entry in the exclusion list to indicate string-basedmatching. For more details, see KB81519.

File and Removable Media Protection use casesSecure sharing with USB devices 3



Secure sharing with CD/DVD/ISOs The protection level options offered for CD/DVDs are similar to the ones provided for USB devices.Select the protection level based on the requirements of your environment.

Enforce Encryption (onsite access only)

• Burning applications — Make sure that the burning software is on the list of supported CD/DVDburning applications in the FRP documentation. Using a non-supported burner can render CD/DVDsas plaintext, even though the policy stipulates encryption. For more details, see KB81450.

• CD/DVD format limitations — Make sure that the CD/DVD media is on the list of supportedCD/DVD formats. For more details, see KB76478.

Protecting sensitive foldersFRP enables you to encrypt the contents of entire folders thus protecting any sensitive data theycontain.

Encryption can be either policy-driven or user-driven. When encryption is policy-driven, theAdministrator can enforce encryption of a folder by specifying the location and selecting the encryptionkey that is to be used for that folder. The Administrator can specify several folders (and select thecorresponding encryption keys) in the same folder encryption policy. Alternatively, the Administratorcan allow users to selectively encrypt or decrypt folders by enabling the Explicit Encrypt and Explicit Decryptoptions.

A folder encrypted by an Administrator-enforced policy cannot be decrypted by the end user using theExplicit Decrypt option.

Folder encryption policy is single slot in nature. You can specify only one folder encryption policyreferencing a particular system or a particular user. However, both of these can co-exist. For example,if user X logs in to system Y, the folder encryption policy applicable to system Y and user X is enforcedprovided that they do not conflict. If they do conflict, the user-based policy overrides thesystem-based policy.

General encryption guidelines• Local volumes — Do not encrypt entire local volumes and in particular the system volume; doing

so can cause deadlocks on the client systems.

• Do not encrypt entire local drives — FRP is file and folder encryption software, not full diskencryption software. Thus, except for removable media, we do not recommend its use to encryptentire drives.

For full disk encryption with McAfee ePO management, review the capabilities of either McAfee®

Drive Encryption or McAfee®

Management of Native Encryption (MNE).

• Program Files directory — Do not encrypt the Program Files; doing so can cause deadlocks onthe client systems.

• Microsoft Outlook data directories — Do not encrypt the Microsoft Outlook data directoriescontaining the OST and PST files. Instead, we recommend the use of Windows EFS for thispurpose.

3 File and Removable Media Protection use casesSecure sharing with CD/DVD/ISOs




• User profile folder — Do not encrypt the entire “User” profile. Although the User profile is a folderper se, it is not recommended to encrypt that entire folder with a folder encryption policy as itmight cause deadlocks. Instead, try to isolate the folders that actually might contain sensitive data.If this is a real concern, consider deploying McAfee HostDLP to assess the content of each file andhave sensitive files encrypted via the FRP-HDLP integration.

• Desktop folder — Be careful if you plan to encrypt the Desktop folder. Only do this if you’re sureyou don’t have static links to other drives on the desktop. LNK-linked shortcuts are fine, but statichard links to other drives will render these targets being encrypted if the shortcuts are on theDesktop. It is a best practice to specify specific directories in the FRP folder policy screen. This isdone by selecting [Desktop] and then adding the specific paths like [Desktop]\FolderA and[Desktop]\FolderB. Choose [Desktop] only if you’re sure that there are no static links to otherdrives on the desktop.

• Whenever possible, select only folders containing sensitive files — Always try to pinpointthe folders containing sensitive data rather than generalizing on a high directory level. If this is areal concern, use file extension encryption or consider deploying McAfee HostDLP to assess thecontent of each file and have sensitive files encrypted via the FRP-HDLP integration.

Removing a folder encryption policyRemoving a folder encryption policy does not automatically decrypt the content of that folder.

To decrypt an encrypted folder, you must specify a policy pointing to the folder location and selectDecrypt in the Encryption key field.

Encrypted parent folder — decrypted subfolderBy default, all sub-folders in a folder that is assigned an "encrypt" policy are also encrypted. However,it is possible to set a subfolder as decrypted even if (any) parent folder is set to be encrypted. Forexample, it is possible to encrypt the My Documents folder through a folder encryption policy and haveit contain the My Video subfolder in plain text format using the Decrypt option.

Protecting sensitive filesFRP enables you to encrypt the contents of files based on the file extension.

As with folder encryption, file encryption can be either policy-driven or user-driven.

It is possible to add as many processes and extensions as you like within a single file encryptionpolicy. It is also possible to mix encryption keys for different processes, as long as it is done in arational manner.

File encryption policy is single slot in nature similar to Folder encryption policy.

Example of policy-driven file encryption

This example assumes that you want to encrypt files created by Microsoft Excel.

Enter both the process name and the [exe] extension, for example, “excel.exe”. Process names caneasily be identified by starting the corresponding application and then locating the process name inthe Windows Task Manager. Only the extension should be entered ("xls"); wildcards or dots (*.xls", or".xls") should be omitted.

Specify the encryption key with which files created by the Excel application should be encrypted.

File and Removable Media Protection use casesProtecting sensitive files 3


Avoid using the wildcard (“*”) as extension

The wildcard (“*”) extension in file extension encryption is very powerful — every file created by thestated application will be encrypted, including templates, index files, and so on. Despite its appeal, westrongly recommend that you carefully define the file types might be created and contain sensitivedata worth encrypting. Make a serious attempt to list the file types created in your organization thatmight contain sensitive data. For example, a template file (e.g., <text>*.dot) does not normallycontain any sensitive data. If this is a real concern, consider deploying McAfee HostDLP to assess thecontent of each file and have sensitive files encrypted via the FRP-HDLP integration.

Enable search encrypted optionFRP policy includes the Enable search encrypted option, which makes it is possible to list files encrypted byFRP.

The Search encrypted option is available as a context menu option on the FRP client. In the search dialog,if <any key = encrypted> is selected, all encrypted files/folders in the selected location are listed.

Protecting network share foldersFRP enables you to protect your network share folders by applying encryption policies to these shares.There are a number of steps that can be taken to optimize network and system performance in theprocess.

Explicitly encrypt large shares in advance

For large network folders that require encryption, apply a folder encryption policy that points to thenetwork share location on a single dedicated machine where FRP is already deployed.

Initiating encryption from this single machine prevents multiple systems from attempting toenumerate, fetch, encrypt and upload files simultaneously over the network, thus minimizing the riskof network bandwidth failure and file server payload overflow.

Depending on the size of the share folder, this initial encryption task may be set to run overnight, atthe weekend, or whenever typical network usage will be minimal.

Tune network parameters

When encrypting large folders on a network share through a policy, we strongly recommend adjustingthe following policy options for optimal performance. These values are recommended:

3 File and Removable Media Protection use casesEnable search encrypted option


• I/O utilization: 20% (set in Encryption Options policy). This option controls the amount of I/Obandwidth used by each system during encryption, and while not specific to network shares, thebandwidth will be higher when large encrypted folders are processed.

• Bandwidth limit: 100 KB/sec (set in Network policy. This option controls the network bandwidth usedby each system during encryption. Introducing a limit helps distribute the encryption load of anetwork share between the client systems, while also preventing network overload).

• Network latency: 600 ms (set in Network policy). This option prevents encryption attempts when thenetwork performance is already degraded.

Enable file size limitation

The Enable limiting of file size... option enables you to exclude (very) large files from encryption throughpolicy enforcement. This is particularly important for network shares where the encryption of largefiles can cause heavy network traffic.

This option applies only to files contained in folders encrypted according to a Folder Encryption policy.Explicitly encrypted files are not subject to this limitation, nor are files encrypted by a file extensionencryption policy. Files drag-dropped to encrypted folders and files saved to encrypted folders are alsonot affected.

Restrict maximum number of clients

You might want to tune the network folder encryption based on the capacity of the client machinesand the overall network traffic. For example, you might set the parameter Maximum number of clients allowedto encrypt folder to 10 to increase the encryption intensity if there is generous network capacity.

Securing email attachmentsFRP enables you to secure email attachment using self-extractors.

• Use Allow creation of Self-extractors or Enable sending of encrypted email attachments to help end users secureemail-attachments.

The Enable sending of encrypted email attachments restricts the encrypted attachments to be accessed withinthe company's environment. Self-extractors can be used to share information with an external party.

• Maximum data input size — The maximum data input size for a self-extractor is 10 MB. Although largerdata input can be used, the recommended maximum input is 10 MB because the self-extractorcode is optimized for this maximum data input.

File and Removable Media Protection use casesSecuring email attachments 3


3 File and Removable Media Protection use casesSecuring email attachments


4 Encryption keys

This chapter provides best practice recommendations related to the use of encryption keys.

Contents Regular and user personal keys User local keys

Regular and user personal keysFRP enables the use of regular and user personal keys.

Deactivate encryption keys instead of deleting them

In McAfee ePO, we strongly advise against deleting keys. Instead, it is sufficient to just deactivatekeys. This is to safeguard against any eventuality where a document is encrypted with a key that is nolonger in the system. A deleted encryption key cannot be restored.

User personal keys

User personal keys give the Administrator the ability to create unique keys for users. These keys arecreated on the McAfee ePO server when the user logs on to the client system for the first time afterthe policy is enforced. User personal keys can be referenced in the Grant Key policy generically (as asingle key), but create unique keys for each of the assigned users.

Use personal keys and multiple McAfee ePO databases

Avoid using user personal keys in a multi-database McAfee ePO environment. This is only safe to do ifa user only registers with one McAfee ePO database and always gets policies and keys from the samesingle McAfee ePO instance.

User local keysA local key is limited to the user and client system where it was created.

Permission to create local keys must be assigned to the users by the Administrator as part of a policy.

User local keys vs. user personal keys

Note the differences between user local key and user personal key features. Users manually createtheir own user local keys on their local machines and share them via export and import processes.These user local keys are not uploaded to the McAfee ePO database and therefore do not transfer withthe user to other computers via default FRP functionality.

4


The availability of the user local key functions is subject to policy control. User personal keys areindividual keys for each user automatically created in McAfee ePO and also managed centrally inMcAfee ePO. The user is never engaged in creating and managing user personal keys – user personalkeys are managed in McAfee ePO.

Delete user local keys with caution

Exercise caution when allowing users to delete local user encryption keys. Once deleted, there is noway to restore that key or any data encrypted with that key.

4 Encryption keysUser local keys


Index

AAllow Encryption

onsite access only 14

with offsite access 14

auditing 15

Bblocking processes 10

CCDs 16

compatibility, other encryption products 9

Ddata input size, self-extractors 19

decryption, automatic 14

delegated administration 9deployment 7Desktop folder 16

device exemptions 15

drives, encryption 7DVDs 16

Eemail attachments 19

encryptiongeneral guidelines 16

encryption keysdeactivating vs. deleting 21

key request exclusions 11

encryption keys, deployment 7Enforce Encryption 14

enforce encryption, CD/DVD/ISOs 16

exemptions, device 15

Ffile extension encryption 17

file size limitation, network share folders 18

folder encryption 16

guidelines 16

parent and child folders 17

removing from policy 17

format limitations 16

Gglobal key administrator 9

II/O utilization 18

ISOs 16

Kkey request exclusions 11, 21

keysencryption 7, 21

recovery 14

user local keys 21

user personal 14

user personal keys 21

Llarge file support 14

latency 18

local volumes 16

MMac X OS offsite browser 15

Microsoft Outlook data directories 16

migration, between ePO servers 9

Nnetwork parameters

tuning 18

network share encryption, intensity 18

network share foldersbandwidth limit 18

explicit encryption, large folders 18

file size limitation 18

maximum number of clients 18

protection 18

Ooperating systems 7


Ppolicy assignment rules 8process blocking 10

Program Files directory 16

purpose 6

Rrecovery keys 14

removable media 13

reporting 15

role-based key management 9

Ssearch encrypted option 18

secure sharing 13, 16

self-extractors 19

System Treepolicy assignment rules 8

UUSB devices 13

Allow Encryption (with offsite access) 14

auditing 15

Enforce Encryption (onsite access only) 14

Enforce Encryption (with offsite access) 14

exemptions 15

ignore existing content 14

large file support 14

Mac X OS offsite browser 15

user local keysdeleting 21

user personal keys 14, 21

multi-database environment 21

Wwildcards, file extensions 17

Index


00