Security the Manual Way

Rather than intersplicing the two or three different ways of securing files, communications, wireless, or email within each section of the balance of this Short Cut, this section will address the standard manual method of encryption all at once, and very briefly. The goal is not to educate you on how to do security the manual wayrather, by describing the manual process, it will make the automated processes, assisted by Windows 2003 autoenrollment of certificates, much clearer. Those who want to jump right in to the certificate-based autoenrollment method of encryption can skip this section and proceed directly to the "Installing a Windows Certificate of Authority Server" section.

Creating Basic Shared Folder Security

Basic security for shared folders is done by adding users from a directory list into the file permissions section of a shared folder. When a user is added to the file permissions, she can be given full control, change, or read access rights for a shared folder. To add access rights, do the following:

1.	Double-click on My Computer from the desktop of a computer system from which files will be shared.
2.	Navigate to the folder you want to share (for example, double-click on Local Disk (C:) and select a folder you might have created, such as Shared Files).
3.	Right-click on the folder and select Sharing and Security.
4.	Select the Share This Folder option, and in the Share Name field, type in what you want to call this shared folder (for example, Shared Files, Accounting Files, Marketing Documents, or Company Info).
5.	Click on the Permissions button and add or remove users you want to have access to this shared folder. You can select individual users (such as Rand, Chris, or Mike), or you can select groups of users (such as Everyone, Accounting Group, Marketing Group, or Domain Administrators).
6.	For each user or group you add, select the permissions you want them to be able to access. For example, you might want the group Everyone to only have Read and Change access to the folders, as shown in Figure 1. Figure 1. Setting share permissions on folders.
7.	Click OK to set the permissions.
8.	Click OK to enable file sharing.

Caution

Read and Change permissions allow a user or a group of users to access a folder, subfolders, and files within the folder. The user can read the file, modify it, and add more files in the shared folder. A user with Full Control can allow or deny access to other users and effectively become the administrator for the shared folder, which you likely would not enable as a default for other users.

Users or groups of users can be added to the permissions for access to the files and shares, and access rights can be allocated for access to the information. However, for file permission access to data, the problem is that information data is not encrypted, so no privacy or information security is ensured. The only way to revoke a user's access to the information is to remove the user from the permission rights for the entire share. The security options are limited, but more details are provided in the section on "Implementing Encrypted File System (EFS)" later in this text.

Manually Configuring IPSec-Encrypted Communications

Internet Protocol Security, or IPSec ("eye-pee-sehk"), provides encrypted communications between computer systems. IPSec provides privacy of information, and limits who has access to information from a communications access perspective. With IPSec enabled on a server, the only way a user can access information over the network is to have IPSec enabled on his workstation. The encryption key used on the workstation needs to be the same as the encryption key on the server for the workstation user to successfully decrypt the communications and access the information.

The encryption and decryption keys used on the source and destination system can be created manually or automatically. In the "Creating a Group Policy for IPSec Encryption for the Server" section later in this text, the preferred automated method using group policies will be addressed. In this section, however, the manual method will be used to describe the process for server administrators to create an encryption key, and provide that information to a user who must enter the encryption key information into her computer in order to access the information on the server.

To enable manual IPSec encryption on a server, do the following:

1.	Launch the IPSec Microsoft Management Console (MMC) by clicking Start | Run and typing mmc.exe; then click OK.
2.	Click File | Add/Remove Snap-in, and then click Add.
3.	Select IP Security Policy Management, and then click Add.
4.	Assuming you are running the MMC tool on the server on which you are configuring IPSec, choose Local Computer, and then click Finish.
5.	Click Close, and then click OK.
6.	Expand the IP Security Policies on Local Computer.
7.	Click on the Server (Require Security) option, and then right-click Properties.
8.	Click on All IP Traffic to highlight the item, and then click the Edit button.
9.	Click the Authentication Methods tab, and then click the Edit button.
10.	Select the Use This String (Preshared Key) option and, in the text box, type in an alphanumeric key (09, AF) that will become your common IPSec security key, as shown in Figure 2. Figure 2. Creating a preshared key for manual IPSec authentication.
11.	Click OK | OK | Apply | OK to set the preshared key.
12.	Right-click on the Server (Require Security) option again and select Assign so that the IP Security Policies screen looks like what is shown in Figure 3. Figure 3. IP Security Policies screen with Secure Server enabled.

By following the preceding steps, IPSec will be configured and enabled on the server. In order for a workstation to access this server, the workstation will also need to configure and enable IPSec using the exact same shared key.

Note

We have configured the server with the Server (Require Security) option instead of the Secure Server (Request Security) option. If you do not want to force IPSec encryption on all communications, select the Secure Server (Request Security) option so that not all communications will be encrypted. However, in order for a server to successfully operate as a Secure Server, the system cannot be a domain controller, DNS server, or other utility server that has to communicate with non-IPSec systems, such as other domain controllers or an external DNS source. By requiring security, all communications must be IPSec encrypted. Therefore, to require security, the system should be a dedicated application server, and any devices that it needs to communicate with should at least have Secure Server (Request Security) enabled.

Note

The steps for configuring IPSec on a workstation are nearly identical to configuring IPSec on a server with the exception of configuring and enabling the Client (Respond Only) option.

To configure IPSec on a workstation from a Windows XP desktop or laptop, do the following:

1.	Launch the IPSec Microsoft Management Console (MMC) by clicking Start | Run and typing mmc.exe; then click OK.
2.	Click File | Add/Remove Snap-in, and then click Add.
3.	Select IP Security Policy Management, and then click Add.
4.	Assuming you are running the MMC tool on the workstation on which you are configuring IPSec, choose Local Computer and then click Finish.
5.	Click Close, and then click OK.
6.	Expand the IP Security Policies on Local Computer.
7.	Click on the Client (Respond Only) item, and then right-click Properties.
8.	Click on Dynamic to highlight the item, and then click the Edit button.
9.	Click the Authentication Methods tab, and then click the Edit button.
10.	Select the Use This String (Preshared Key) option and, in the text box, type in the exact same alphanumeric key (09, AF) that you entered for the server IPSec configuration.
11.	Click OK | OK | Apply | Close to set the preshared key.
12.	Right-click on the Client (Respond Only) option again and select Assign to enable IPSec on the client workstation system.

Once IPSec has been enabled on both a server and a client system, the communications between the two devices will be secured and encrypted using a 168-bit encryption algorithm.

To confirm that IPSec-encrypted communications is working, run the IP Security Monitor to view the traffic between devices. To run the IP Security Monitor, do the following:

1.	Launch the IP Security Monitor Microsoft Management Console (MMC) by clicking Start | Run and typing mmc.exe; then click OK.
2.	Click File | Add/Remove Snap-in, and then click Add.
3.	Select IP Security Monitor, and then click Add.
4.	Click Close, and then click OK.
5.	Expand the IP Security Monitor console.
6.	Expand the server you are monitoring.
7.	Click to expand the Quick Mode, and then click on the Security Associations folder to view the connections (both encrypted and unencrypted). You will see a list of connections similar to the ones shown in Figure 4. Figure 4. IP Security Monitor connection status.

Note

Connections that are encrypted will show ESP Confidentiality with 3DES or another encryption method noted for the connections setting. Because the server is configured with requested security and not required security in this example, you can have some connections that have <None> as the ESP Confidentiality (note that those connections are not encrypted).

The problem with manual IPSec encryption is that the key is static, meaning that if the key information is accidentally or purposely shared with someone who should not have access to the information, although the information will be encrypted, virtually anyone can have access to the information. By automating encryption using certificates, if a key is compromised, new keys can be automatically issued to computer systems, thus enabling access to any computer that has the new encryption key. The automated process will be covered in the "Implementing IPSec-Encrypted Transport Communications" section later in this text.

Using Wired Equivalent Privacy (WEP) for Wireless Security

Wireless communication security using the Wired Equivalent Privacy, or WEP ("wehp"), is very similar to the shared key system in IPSec. Effectively, a wireless access point has a static key entered into the security table of the device. In order for laptop or wireless devices to connect to the wireless access point, the client needs to enter the static key into her computer system. The shared information provides a common secured link between the wireless client and the wireless network.

To enable WEP on an access point device, you would enter a series of numbers and letters (09, AF, no spaces or punctuation) into the access point WEP configuration page. Every access point device has a slightly different configuration page option; however, a sample page is shown in Figure 5.

Figure 5. Sample access point WEP configuration page.

In this example, WEP has been configured with 128-bit encryption, thus requiring 26 hexadecimal digits in the encryption key.

After WEP is configured on the access point device, the user needs to manually enter the exact same WEP key into the wireless configuration settings on his laptop or mobile device. In Windows XP, the process is as follows:

1.	From the Windows XP desktop, click on Start | Control Panel | Network Connections.
2.	Right-click on the wireless network adapter connection for the device, and select Properties.
3.	Click on the Wireless Networks tab.
4.	Click on the wireless network that you want to connect to (this is known as the SSID of the access point you are connecting to), and then click on the Properties button.
5.	For Network Authentication, choose Open. For Data Encryption, choose WEP.
6.	Unclick the The Key Is Provided for Me Automatically check box. This will allow you to enter your security key.
7.	In the Network Key field, enter the 26-hexadecimal WEP key that was associated with the access point. Re-enter the same key in the Confirm Network Key field. The completed screen should look similar to what is shown in Figure 6. Figure 6. Wireless configuration setting on the Windows XP laptop.
8.	Click OK and then OK to set and enable the WEP encryption settings for the system.

Unfortunately, just like shared-key IPSec, if the WEP key is compromised by someone providing information to people who should not have access to the key, virtually anyone with the key will then have access to the wireless access device. The only way for the organization to resecure wireless access is to change the WEP key on the access point device, and then tell all users what the new access key is for wireless access. It could be just a matter of days or hours before that wireless access key is compromised, and then the process starts all over again for reissuing a new key.

Basic Encrypted Communications Using Outlook

Encryption is also used for email communications to enable users to send and receive secured communications between each other. In Microsoft Exchange, there is an encryption system built in that allows users within an Exchange environment to send email messages to other users within that environment in an encrypted manner. The problem with the default encryption in Exchange is that it does not provide encryption outside of the company's Exchange environment. So most organizations do not use the built-in email encryption in Exchange, but rather a more standard method of encrypted communications built on the Public Key Infrastructure (PKI) standard.

There are several methods of providing encrypted communications between users within and external to a Microsoft Exchange and Outlook email system. Users can each get a certificate from an organization such as VeriSign and perform encrypted communications. Or an organization can purchase an enterprise license of Pretty Good Privacy (PGP) that provides encryption between users and organizations also using PGP email security. In the following example, the use of individual VeriSign certificates will be explained.

A user who wants to encrypt messages between herself and another user needs to get an individual email certificate and install it in her Microsoft Outlook email client software. The user would go to http://www.verisign.com/products-services/security-services/pki/pki-application/email-digital-id/index.html and, for approximately $20 a year, both users can purchase a certificate. The individuals share the public portion of their certificates with the others with whom they want to communicate using encrypted messaging.

To acquire a certificate, do the following:

1.	Go to a certificate provider such as VeriSign (http://www.verisign.com/products-services/security-services/pki/pki-application/email-digital-id/index.html), and sign up and purchase a Digital ID.
2.	Follow the instructions to download and install the certificate in your Outlook client.
3.	Have the user you want to communicate with do the same.

This process of purchasing, downloading, and installing a certificate only needs to be done once a year.

Note

If you use multiple computers, you need to install the certificate on each machine that runs the Outlook client in order to send and receive encrypted email messages.

After you have downloaded and installed the certificate on your computer, you need to configure Outlook to support the certificate. To do so, do the following:

1.	Launch Outlook.
2.	Choose Tools | Options, and then click on the Security tab.
3.	Click the Settings button.
4.	Enter Email Encryption for the Security Settings Name, choose S/MIME for Cryptographic Format, and then select the check boxes for Default Security Setting for This Cryptographic Message Format and Default Security Setting for all Cryptographic Messages.
5.	Choose SHA1 for Hash Algorithm and 3DES for Encryption Algorithm.
6.	Select the Send These Certificates with Signed Messages option.
7.	The settings should look similar to the ones shown in Figure 7. Click OK to accept these settings, and then OK again. Figure 7. Configuring Microsoft Outlook to support the encryption certificate.

Depending on the user's computer sophistication, he might have difficulties signing up, downloading, and installing the certificate, as well as configuring his Outlook client to send emails. Additionally, because the certificates are individual-based, each individual user has to do this process himself every year and for every system on which he conducts email communications. As you will see in the "Implementing Secured Email Communications with Exchange 2003" section, the issuance of certificates and the configuration of the user's Outlook client can be completed automatically using autoenrollment of certificates, as well as using group policy objects in Windows 2003 Active Directory.