S 4.278 Secure use of EFS under Windows Server 2003

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: User, Administrator

The Encrypting File System (EFS) in Windows Server 2003/XP is an easy-to-use tool that users can use to work with encrypted files regardless of the application. It is best suited for use on stand-alone user computers and exposed client computers that are sometimes used outside of the protected IT environment. The main purpose of the EFS is to ensure the confidentiality of the dedicated local data. Basic information can be found in S 4.147 Secure use of EFS under Windows.

EFS is less suitable for wide-scale encryption of centralised user data on remote servers such as file servers, for example. This can only be achieved through special planning of the key management.. In this case you must also accept the fact that more time and expense is required to secure and protect the large amounts of data and number of user keys

Differences in implementations

At the beginning of the planning phase, you must decide if you want to offer EFS for the encryption of files stored on servers in the network or if you just want to encrypt session data and confidential administrative data locally on the server. In the latter case, the server operates like a client computer with EFS enabled, and safeguard S 4.147 Secure use EFS under Windows should be implemented in this case. However, encryption should be used very sparingly for system status information (e.g. DNS zone files, printer queues on print servers), log files (e.g. IIS logs), and the shared temporary folders (C:\WINDOWS\Temp). It is recommended in this case to perform tests under typical load conditions before enabling encryption for such critical files. Otherwise, the whole server can be impaired by T 4.54 Loss of protection via the encrypting file system EFS.

One way to increase the security of administrative sessions on the server using EFS is to encrypt the session data (e.g. temporary directories, Desktop folder, My Files, printer queues) and confidential working data such as documentation files. This method is less critical to security since only the profile will cease to function properly while central services continue to operate. Applications regularly create temporary copies of files during runtime. It must be examined which folders are used by applications for temporary files. EFS can then be enabled for these folders so that the data cannot be read by unauthorised parties when the data is being processed.

EFS should only be enabled as an encryption service for remote files (files stored on servers in the network) when the data on the server has a very high protection requirement in terms of its confidentiality and the additional risks, time, and expense are justified. This must be specified in a policy for the IT environment. The areas of application for EFS must be precisely defined. You must also take the threats stated in T 4.54 Loss of protection via the encrypting file system EFS into account in this context.

If EFS is used in conjunction with WebDAV shares, then files are encrypted on the client instead of on the server. The encrypted files can then be stored on the WebDAV share via an HTTP transfer. EFS does not need to be enabled on the server for this. The user is subject in this case to the same risks as when the data is encrypted locally on his client. In the policy mentioned above, you must state the extent to which the administrator must provide central resources for the maintenance, securing, and restoration of such data when the key is lost. The more extensive these requirements are, the higher the requirements, time, and expense for central key management.

Enabling EFS in government agency or corporate environments is only recommended in conjunction with the use of a public key infrastructure (PKI) and recovery agent configurations.

Disabling EFS

EFS is enabled in a standard Windows Server 2003 installation. A recovery agent is not configured. EFS should be disabled in the security policy of the server for normal operation:

In an Active Directory environment, this setting should be specified in a group policy for all server and client computers.

If EFS is subsequently disabled on a system in operation, then it is recommended to search the system for any databases still encrypted. This can be done using the EFSinfo.exe programme from the Support Tools for Windows Server 2003, for example.

An example of a command on the command line is: efsinfo /s:c:\

Separating roles for the DRA

Suitable separation of the roles prevents administrators from having unrestricted access to encrypted data. The Data Recovery Agent (DRA), with which the data can be recovered centrally and independent of the encrypting users, plays a critical role in this. Data recovery agents can be created in the form of special security certificates. The following conditions must be met by a DRA:

The predefined administrator account must not be provided a DRA certificate.
User accounts assuming the role of a DRA generally should not possess administrator rights.
You should create as few data recovery agents as possible.
A separate account should be used for the DRA.

The private key of the DRA should be exported to an external data medium with password protection and then deleted from the system. The data medium containing the private key is to be stored in an area with access protection (e.g. in a safe). To increase security, the passwords can be stored separately from the data media.

Consideration should be given to the use of a hardware security module (HSM, see module 1.7 Crypto-concept) to increase the security of the private key of a DRA.

Data backups

The service account for backing up data should not possess any EFS or restoration certificates, and therefore should only be able to read and write data in encrypted form on the backup medium.

Expired DRA certificates

Expired DRA certificates remain critical to security because they

make it possible to access all data encrypted up to now (confidentiality at risk), and
they are the only way to restore the databases encrypted on the server up to now (availability at risk).

A new DRA certificate must be added before the old one expires because otherwise encryption will not work any more immediately after the old certificate expires. The same security safeguards must be implemented for the new DRA as for the old one (see above). This must be taken into account in planning and during operation.

It is only recommended to dispose of an old DRA certificate after decrypting all encrypted databases and then encrypting them again with a new DRA. Depending on the amount of data encrypted and how it is organised, this may require significant time and expense and may come in conjunction with a significant risk to the availability and integrity of the data, and should only be done in exceptional cases, e.g. when the key strength of the present DRA certificate is no longer deemed sufficient.

Central key management

EFS requires defined central key management. It is urgently recommended to use a public key infrastructure (PKI) so that no self-signed certificates from the local server or clients can be used. Additional information on this subject can be found in the Resources for IT-Grundschutz (see Protection of certificate services under Windows Server 2003 in the Resources for Windows Server 2003).

It is also recommended to allow the EFS certificates to be extended automatically because otherwise self-signed certificates will be used after an EFS certificate expires.

It is necessary to define a recovery agent to counteract threats such as T 4.55 Data loss relating to password resets under Windows Server 2003 and XP and higher. The wizard for this can be called under

The risk of losing the user key can be further reduced by allowing the private keys to be stored on the certification authority issuing the EFS certificates. However, there is a higher risk of misuse of the keys when they are stored centrally. This in turn means significantly higher organisational and administrative expense for the certificate services, especially for the key recovery agents, separation of roles, and general protection of the certification authority.

Recovery station

In larger IT systems, consideration should be given to installing a recovery station in an area with secure access control that is only used when actually needed. The files to be encrypted can be transferred to the recovery station using a backup tool like ntbackup and then restored there using the DRA key. The DRA key can be kept on the recovery station. Another advantage of using a recovery station is that the key stored on the recovery station is not threatened by untrustworthy software.

Virtualisation technology can be used for the recovery station. This means that the entire operating system is installed in a simulated hardware environment. This virtual environment can be stored easily on a removable data medium, which can then be placed in safekeeping.

Training

The users must receive training on the operation of EFS and the risks associated with its operation. With trained users and key management, EFS can be used to obtain improved security.

Review questions:

Are the means for maintenance, securing, and restoration of EFS data defined for administrators in case of lost keys?
Is it ensured that the pre-defined administrator account is not furnished with a DRA certificate?
Is it ensured that the user accounts having the role of a DRA do not have administrator rights in general?
Is the number of data recovery agents limited to the required minimum number?
When using DRA, is a separate account always used?
If old DRA certificates expire, is a new DRA certificate issued in due time?
Are the users trained on using DRA and on the inherent risks?
Are expired DRA certificates stored securely?