Bienvenido! - Willkommen! - Welcome!

Bitácora Técnica de Tux&Cía., Santa Cruz de la Sierra, BO
Bitácora Central: Tux&Cía.
Bitácora de Información Avanzada: Tux&Cía.-Información
May the source be with you!

Friday, December 12, 2008

Data Protection and Recovery in Windows XP

Introduction Introduction
EFS Enhancements in Windows XP EFS Enhancements in Windows XP
Data Recovery Overview Data Recovery Overview
Data Recovery Using EFS Data Recovery Using EFS
Data Recovery—Best Practices Data Recovery—Best Practices
Data Protection—Best Practices Data Protection—Best Practices
For organizations that are concerned with protecting the data of mobile users in case of theft or loss, the following best practices should be followed:

  • Physical protection of the machine is paramount.

  • Always use the mobile computer as part of a Windows 2000 domain.

  • Store the private keys for users separately from the mobile computer and import when needed.

  • For common storage folders such as "My Documents" and "temporary folders" encrypt the folder so that all new and temporary files will be encrypted when created.

  • Always create new files, or copy existing plaintext files, into an encrypted folder when the data is extremely sensitive. This will ensure that all files have never existed in plaintext form on the machine, and that temporary data files cannot be recovered from sophisticated disk analysis attacks.

  • Encrypted folders may be enforced in a domain through the use of a combination of group policies, logon scripts and security templates to ensure that standard folders such as "My Documents" are configured as encrypted folders.

  • The Windows XP operating system supports the encryption of data in offline files. Offline files and folders that are cached locally should be encrypted when using client-side caching policies.

  • Use SYSKEY in mode 2 or mode 3 on the mobile computer to prevent the system from being booted by malicious users
Note: SYSKEY mode 1 Is enabled by default on Windows 2000 and Windows XP. To invoke SYSKEY, from a command prompt or from the Run line on the Start menu, type "syskey.exe". (See http://support.microsoft.com/default.aspx?scid=kb;en-us;143475&sd=tech for more information on SYSKEY).
Important: Encrypting the system TEMP folder or path may have negative performance consequences on the overall performance of the system. Encrypting all temporary files may increase system CPU usage dramatically and should be carefully considered before enabling.

Remove Formatting from selectionDeleting PlainText Data
Whenever a new data file is created on an NTFS drive, the file system allocates data to it in chunks called clusters. If the file outgrows the clusters it's been allocated, NTFS allocates additional clusters. If the file later shrinks or is deleted, NTFS deallocates the unneeded clusters from the file, and marks them as being available for allocation to a different file, if needed. Over time, de-allocated files are overwritten as new files and data are written to the disk. Understanding how NTFS works is important when implementing a data protection strategy with EFS.
Additional information on NTFS and its operation may be found on the Microsoft Developer Network (MSDN): http://msdn2.microsoft.com/en-us/library/default.aspx
Data Recovery—Best Practices
In general, the best practice for organizations to follow regarding data recovery is to deploy a public key infrastructure (PKI) to issue certificates to users and data recovery agents that are issued from a certification authority. The Microsoft Enterprise Certification Authority makes it easy for users to automatically get certificates for use by EFS.
Other best practices include:

  • Using a certificate generated by a certification authority for DRAs. Certificates issued by CAs are not self-signed and can be more easily managed in terms of revocation, renewal and expiration.

  • Using more than one DRA per domain, and storing the actual private keys for the DRAs on a medium (floppy disk, CD-ROM, etc.) that can be secured and retrieved only when appropriate security policies and practices have been followed. DRAs may be defined at the site, domain or OU like any other Group Policy, and may be combined as an aggregate policy based on the organization of Active Directory.

  • Making DRAs available locally to recover user data. Because of the nature of user profiles and the storage of private keys in profiles, it may be necessary for a DRA to log on locally to a user's machine, import the private keys of the DRA, and then recover files for a user. This method is most useful for organizations that have multiple DRAs that are distributed throughout the enterprise.

Central Recovery Workstation
Another method for data recovery is to use a central recovery workstation in the enterprise. This may be performed by using a backup utility such as ntbackup.exe to perform a raw backup of the encrypted files and then restore those files on a central recovery machine. The DRA private keys may be stored on the recovery machine or imported as necessary. This method is valuable for organizations that maintain a single DRA centrally for recovery.

EFS and Certificate Authorities
Through a Windows XP enterprise CA, users may obtain a certificate employable by EFS using one of the three following methods:

  • Automatically using user certificate auto-enrollment

  • On-demand enrollment using an enterprise CA and properly configured certificate templates

  • Manual enrollment by the end-user
Using an enterprise CA will ensure that users easily get certificates for use by EFS. It will also ensure a very low cost for certificate deployment compared to other technologies and methods.

Auto-enrollment
The easiest and most reliable method of certificate distribution for intranet users is auto-enrollment. Auto-enrollment occurs in the background and ensures that certificates will be available when users need them.
Key advantages of auto-enrollment include:

  • Auto-enrollment can also be used to combine certificate enrollment with data and key recovery methods. A version 2 certificate template can be used to enroll a user automatically in the background and at the same time archive the private key.

  • Auto-enrollment can also use certificate templates that require a certificate request be signed by another certificate. That is, an organization could manually (and securely) issue smart cards through a person-to-person exchange and then require that the smart card certificate be used to sign a request for an auto-enrolled certificate. This is known as "self registration authority" and is a very strong mechanism for securely issuing certificates via an automatic process.

  • User store certificate management (cleanup).

  • Automatic certificate renewal (revoked certificates, expired certificates, etc.).

  • Automatic retrieval of pending certificate requests.

Using Default Domain Configuration
By default, the administrator of a domain is the default DRA in a Windows 2000 domain. When the administrator for a domain first logs in with that account: a self-signed certificate is generated, the private key is stored in the profile on that machine, and the default domain Group Policy contains the public key of that certificate as the default DRA for the domain.

Lost or Expired DRA Private Keys
Although the expiration of a DRA certificate is a minor event, the loss or corruption of the DRA's private keys can be potentially catastrophic for an organization.
An expired DRA certificate (private key) can still be used to decrypt files, however new or updated files cannot use the expired certificate (public key). When an organization has either lost the private keys of a DRA, or the certificate of a DRA has expired, the best practice for an organization to follow is to immediately generate one or more new DRA certificates and immediately update the Group Policy or Policies to reflect the new DRAs. When users encrypt new files or update existing encrypted files, the files will automatically be updated with the new DRA public keys. It may be necessary for an organization to encourage users to update all existing files to reflect the new DRA(s).
In Windows XP, the command line utility cipher.exe has been updated with a /U parameter to update the file encryption key or recovery agent keys on all files on local drives. For example:
Cipher.exe /U
C:\Temp\test.txt: Encryption updated.
C:\My Documents\wordpad.doc: Encryption updated.
Note: When using the default, self-signed certificate in a domain without a certification authority, the lifetime of the. certificate is good for 99 years
Data Protection—Best Practices
For organizations that are concerned with protecting the data of mobile users in case of theft or loss, the following best practices should be followed:

  • Physical protection of the machine is paramount.

  • Always use the mobile computer as part of a Windows 2000 domain.

  • Store the private keys for users separately from the mobile computer and import when needed.

  • For common storage folders such as "My Documents" and "temporary folders" encrypt the folder so that all new and temporary files will be encrypted when created.

  • Always create new files, or copy existing plaintext files, into an encrypted folder when the data is extremely sensitive. This will ensure that all files have never existed in plaintext form on the machine, and that temporary data files cannot be recovered from sophisticated disk analysis attacks.

  • Encrypted folders may be enforced in a domain through the use of a combination of group policies, logon scripts and security templates to ensure that standard folders such as "My Documents" are configured as encrypted folders.

  • The Windows XP operating system supports the encryption of data in offline files. Offline files and folders that are cached locally should be encrypted when using client-side caching policies.

  • Use SYSKEY in mode 2 or mode 3 on the mobile computer to prevent the system from being booted by malicious users
Note: SYSKEY mode 1 Is enabled by default on Windows 2000 and Windows XP. To invoke SYSKEY, from a command prompt or from the Run line on the Start menu, type "syskey.exe". (See http://support.microsoft.com/default.aspx?scid=kb;en-us;143475&sd=tech for more information on SYSKEY).
Important: Encrypting the system TEMP folder or path may have negative performance consequences on the overall performance of the system. Encrypting all temporary files may increase system CPU usage dramatically and should be carefully considered before enabling.
Deleting PlainText Data
Whenever a new data file is created on an NTFS drive, the file system allocates data to it in chunks called clusters. If the file outgrows the clusters it's been allocated, NTFS allocates additional clusters. If the file later shrinks or is deleted, NTFS deallocates the unneeded clusters from the file, and marks them as being available for allocation to a different file, if needed. Over time, de-allocated files are overwritten as new files and data are written to the disk. Understanding how NTFS works is important when implementing a data protection strategy with EFS.
Additional information on NTFS and its operation may be found on the Microsoft Developer Network (MSDN): http://msdn2.microsoft.com/en-us/library/default.aspx

Reducing the Risk of Discovery of Plaintext Shreds
EFS incorporates a crash recovery scheme whereby no data is lost in the event of a fatal error such as system crash, disk full, or hardware failure. This is accomplished by creating a plaintext backup of the original file being encrypted or decrypted. Once the original is successfully encrypted or decrypted, the backup is deleted. Creating a plaintext copy has a side effect; the plaintext version of the file may exist on the disk until those disk blocks are used by NTFS for some other file.
As part of the process of encrypting a pre-existing file, EFS always creates a backup copy of the file it's encrypting. The recommended way to encrypt sensitive data using EFS is to create a folder, set the encrypt attribute on it, and then create files within it. If this is done, the files will be encrypted from the start. EFS will never create a backup file containing plaintext; this ensures that there will never be plaintext shreds on the drive.
Cipher.exe Command Line Utility
The Cipher.exe command line utility may be used to wipe deallocated file clusters off the NTFS disk to reduce the risk of discovery of plaintext shreds left over from file conversion.
C:\>cipher /?
Displays or alters the encryption of directories [files] on NTFS partitions.
CIPHER [/E | /D] [/S:directory] [/A] [/I] [/F] [/Q] [/H] [pathname [...]]
CIPHER /W:directory
/W    
Removes data from available unused disk space on the entire volume. If this option is chosen, all other options are ignored. The directory specified can be anywhere in a local volume. If it is a mount point, or points to a directory in another volume, the data on that volume will be removed.
To run Cipher.exe

  1. Log on as an administrator of the local machine.

  2. Close all applications.

  3. Open a command prompt by selecting Start, then Run, and entering CMD as the command.

  4. Type "Cipher /W:<'directory'>" (without the quotes), where <'directory'> is any directory on the drive you want to clean. For instance, "Cipher /W:c:\test" will cause the deallocated space on the C: drive to be overwritten.

  5. Cipher.exe will begin running, and will display a message when it's completed.
Important: Cipher.exe may take a very long time to run, especially on large volumes. It is not possible to stop it once it has started, so the operation should run until completion. Running the chkdsk.exe command on the volume after completion is a best practice. Also, it is not recommended that the cipher.exe /W be run multiple times; the intent of the process is a one time cleanup of the disk.
Note: NTFS drives can be mounted as directories. For instance, a drive could be mounted as C:\folder1\D_Drive. This usage enables drives of this type to be cleaned.
The new cipher tool is also available for Windows 2000 by downloading from the Microsoft Web site: http://www.microsoft.com/technet/security/tools/cipher.mspx

Encrypting Offline Files
Windows 2000 introduced the capability to cache offline files (also known as client side caching). This IntelliMirror™ management technology allows network users to access files on network shares, even when the client computer is disconnected from the network.
For example, when a mobile user views the share while disconnected, he or she can still browse, read, and edit files, because the files have been cached on the client computer. When the user later connects to the server, the system reconciles the changes with the server.
The Windows XP client now enables offline files and folders to be encrypted using the Encrypting File System. This feature is especially attractive for traveling professionals that need to work offline periodically while maintaining the security of their data.
A common database on the local machine is used to store all user files and to limit access to those files through explicit access control lists (ACLs). The database displays the files to the user in a manner that hides the database structure and format and appears as a normal folder to the user. Other user files and folders are not shown, and are not available to other users. When the offline files are encrypted, the entire database is encrypted using an EFS machine certificate. Individual files and folders may not be selected for decryption. Therefore, the entire offline files database is protected by default from attacks using the native EFS when this feature is enabled. However, one limitation of the encrypted offline files database is that files and folders will not be shown as an alternate color to the user when working offline. The remote server may also be using encryption of files and folders selectively when online, so this may appear as an inconsistency to the user when displaying encrypted files online and offline.
Important: The CSC runs as a SYSTEM process and therefore may be accessed by any user or process that may run as SYSTEM or act as a SYSTEM process. This includes administrators on the local machine. Therefore, when sensitive data is stored in offline folders, administrative access should be restricted to users and SYSKEY should always be used to thwart offline attacks.

To encrypt offline files
Encrypted offline files is enabled by setting folder options which can be found in Windows Explorer by selecting Tools and then Folder Options in the command menu.

  1. Select the Offline Files tab as shown in Figure 17 below.
    Note: This option is only available in Windows XP Professional.
    Figure 17: . Selecting the Offline Files tab
    Figure 17: . Selecting the Offline Files tab

  2. Select Enable Offline Files and Encrypt offline files to secure data.

  3. Click OK.
Offline files will be encrypted when cached locally using a private key and certificate for the user on the client machine.
Important: Never encrypt files that are stored in a roaming user profile as the system will not be able to open the files in the profile when it is loaded at logon.

Permanent Offline Users
In a general sense, offline users of EFS (those not regularly connected to a domain or network) will have little or no special requirements for EFS operations. However, some organizations may choose to allow some offline users to maintain a copy of a DRA's private key and certificate on a floppy disk for emergencies while the user is traveling and offline. It should be noted that this practice is generally not recommended and should only be used in extreme circumstances. When employed, the private key file (*.PFX) should be protected with a strong password and the floppy disk should be kept separate from the mobile computer.

EFS with WebDAV Folders
EFS with WebDAV folders provides simple and secure ways for individual and corporate users to share sensitive data across insecure networks. EFS with WebDAV eliminates the need to purchase specialized software to share encrypted files between users, businesses or organizations in a secure manner. The strong encryption capabilities of EFS, combined with the file sharing functionality enabled in Windows XP, simplifies the process of sharing sensitive data. Files may be stored on common file servers or Internet communities such as the Microsoft Network (www.msn.com) for easy access while maintaining strong security through EFS.
EFS with WebDAV folders also enables numerous business-to-business and collaboration scenarios for organizations looking to achieve simple security solutions without deploying complex infrastructure or expensive product technologies. For more information on EFS with WebDAV folders, see Encrypted Files on a Server later in this article.

Clearing Page File at Shutdown
Ensure that the system page file is cleared before shutdown. This will ensure that memory data fragments will not be paged to disk in clear text form at shutdown. This is enabled through local or domain Group Policy.
To clear page file at shutdown

  1. Click through the following path:

    • Computer configuration

    • Windows settings

    • Security settings

    • Local Policies

    • Security Options

  2. Open the Shutdown: Clear virtual memory pagefile object.

  3. Select the Enabled radio button as shown below in Figure 18 and click OK.

  4. Close the Group Policy MMC snap-in.
Figure 18: . Defining Shutdown: Clear virtual memory pagefile policy setting
Figure 18: . Defining Shutdown: Clear virtual memory pagefile policy setting

Using 3DES Encryption Algorithm
The Windows XP operating system supports the use of a stronger symmetric algorithm than the default DESX algorithm. For users requiring greater symmetric key strength with a FIPS 140-1 compliant algorithm, the 3DES algorithm should be enabled.

To enable the 3DES algorithm in Windows XP
To enable the 3DES algorithm in Windows XP, either enable the local computer policy or the appropriate Group Policy in the site, domain or OU of the targeted computers.

  1. Click through the following path:

    • Computer configuration

    • Windows settings

    • Security settings

    • Local Policies

    • Security Options

  2. Open the System cryptography: Use FIPS compliant algorithms for encryption object.
    Important: System cryptography applies to both EFS and IPSEC.

  3. Select the Enabled radio button as shown in Figure 19 below, then click OK.
Once enabled, a Windows XP client may open files encrypted with both the DESX and 3DES algorithms However, all new files will be encrypted with the new 3DES algorithm.
Figure 19: . Defining the System cryptography: Use FIPS compliant algorithms policy setting
Figure 19: . Defining the System cryptography: Use FIPS compliant algorithms policy setting
Note: If a user needs to access an encrypted file from both Windows 2000 and Windows XP, the 3DES algorithm should not be enabled. The Windows 2000 operating system does not support the 3DES algorithm.
For other EFS best practices, see Microsoft Knowledge Base article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;223316&sd=tech

Show Encrypted Files in Color
The Windows XP client now allows both encrypted and compressed files to be displayed with alternate colors in Windows Explorer. This feature is enabled by setting folder options which can be found in Windows Explorer by selecting Tools and then Folder Options in the command menu.
To show encrypted files in color

  1. Select the View tab in the Folder Options dialog box

  2. Check the box for Show encrypted or compressed NTFS files in color as shown in Figure 20 below. When this is applied to a folder, all encrypted files will be displayed as green in Windows Explorer.

  3. If you would like to have this setting apply to all folders on the machine, select the Apply to All Folders button and choose Yes when prompted.

  4. Click OK to close the dialog box.
Figure 20: . Selecting options for showing encrypted files in color
Figure 20: . Selecting options for showing encrypted files in color
Data Recovery Versus Key Recovery Data Recovery Versus Key Recovery
Troubleshooting Troubleshooting
Summary Summary
Related Links Related Links
Knowledge Base Articles on EFS Knowledge Base Articles on EFS

No comments: