Data Security and Data Availability for End Systems

On This Page

	The Focus of This Paper
	Securing Servers and Workstations on the Web
	Applying the Security Configuration Using Policy
	Creating an Auditing and Monitoring Strategy
	Designing a Fault Tolerance Solution
	Appendix A: User Rights Explained (from Resource Kit)
	Appendix B: Local Security Settings (from Resource Kit)
	Appendix C: HighSecweb.inf File

The Focus of This Paper

Overview

This paper is based on a security engagement Microsoft Consulting Services (MCS) recently completed at a large bank. It discusses MCS best practices in the following areas:

The evaluation and completion of the security tasks outlined in this paper will help a company create a more secure environment and Internet presence.

Top of page

Securing Servers and Workstations on the Web

Common Attacks

There are many different ways that hackers attempt to gain access or do damage to a company system. Most of these attacks are well known and documented on many security Web sites. Some of the more common attacks are listed as follows.

Spoofing User Identity

Spoofing user identity is when a hacker obtains a user's personal information or something that enables the hacker to replay the authentication procedure. Spoofing threats are associated with a hacker being able to impersonate a valid system user or resource to get access to the system and thereby compromise system security.

Tampering with Data

An unauthorized change to stored or in-transit information, formatting of a hard disk, a malicious intruder introducing an undetectable network packet in a communication, and an intruder making an undetectable change to a sensitive file are all tampering threats.

Repudiability

A user performing an illegal operation without the ability to be traced is called "repudiability." Repudiability threats are associated with users (malicious or otherwise) who can deny a wrongdoing without any way for you to prove otherwise.

Information Disclosure

Disclosure of private or business-critical information can compromise an enterprise. Information disclosure threats expose information to individuals who are not supposed to see it. A user's ability to read a file that she or he was not granted access to, as well as an intruder's ability to read the data while in transit between two computers, are both disclosure threats. Note that this threat differs from a spoofing threat in that here the perpetrator gets access to the information directly rather than by having to spoof a legitimate user.

Denial of Service

A "Denial of Service" (DoS) attack prevents legitimate users from using a service. The effectiveness of a DoS attack is measured three ways:

DoS attacks range from mildly annoying to true security risks. In general, a good firewall should prevent them from happening. (For more information on preventing DoS attacks, see "Preventing Denial of Service Attacks" later in this paper.)

Elevation of Privilege

An elevation of privilege threat is when an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. The more dangerous aspect of such threats is compromising the system in undetectable ways whereby the user is able to take advantage of the privileges without the knowledge of system administrators. Elevation of privilege threats include those situations where an attacker is allowed more privilege than should properly be granted, compromising the security of the entire system and causing extreme system damage. Here the attacker has effectively penetrated all system defenses and become part of the trusted system itself and can do anything.

Determining Which Information to Secure

The first step you must take is to determine the level of security needed on each system in the environment. For example, outside Web servers normally contain information that is public and therefore would need a different type of security model than, say, a database server that is storing confidential information. Another type of device that provides security is a firewall. A firewall normally is used to limit access to information from users inside and outside the enterprise. Therefore, how you design and implement a secure firewall is very important to the plan. But before this means anything practical, you must first define information security.

When defining information security for our bank project, we asked the following questions:

The bank outlined all of these issues, created a security team, assigned a security officer, and created an enterprise-wide security policy. After this was complete, we developed the proper security model and completed the details necessary to create a secure infrastructure for the bank.

Determining the Level of Security

It is important to categorize and understand what security is required based on the classification of the information. For example, you could start by determining the level to which the information secured can be accessed. There are two extremes of enterprise security:

In the case of our bank project, we adopted a security policy that straddles these extremes, one that allows us to control yet promote data access so that users can get to the information they need.

Physical Security

Physical security involves protecting the computers used to store and process sensitive and/or valuable data (whether a server or a workstation). Protecting against accidental or deliberate access (including changes to the way the computer is set up), however, should not prevent users from doing their work nor should it erect unrealistic or inconvenient barriers to user resources.

Standard Security

For standard security, the computer system must be protected, as any valuable equipment would be. In the case of our bank project, this involved housing the computer in a building that is locked and out-of-bounds to unauthorized users.

As was mentioned in the previous section, the first step to create a secure infrastructure is to evaluate the current security level of each server and workstation. Some of the key issues from a physical security perspective in a standard security model are outlined below. The next sections after this one goes into more detail on important issues when building a security model. The actual application of these recommendations is outlined in Part 3 of this document, "Applying the Security Configuration Using Policy," which details applying these settings in a Windows 2000 environment. Also, always remember it is imperative to continually check http://www.microsoft.com/technet/security/default.mspx for the latest additions to this list.

The first thing to evaluate on either the server or the client is the physical security of the boxes and the environment. The chart below shows some of the suggestions we made at the bank to protect its clients or servers.

Backups

Regular backups protect data from all sorts of hazards: hardware failures, honest mistakes, viruses, and malicious mischief. In our bank project, because files must be read to be backed up and written to be restored, backup privileges were limited to administrators and backup operators.

Auditing

Often a company does not know about a breach of security until it finds it, usually by auditing the network. Effective auditing can also uncover actions that pose a security risk and identify the user accounts from which the actions were taken. Establishing an audit policy requires that you balance the auditing cost (in disk space and CPU cycles) against its advantages. System setup and capacity may dictate how many functions you can realistically audit. At the very least, the bank decided to audit failed log-on attempts, attempts to access sensitive data, and changes to security settings.

Creating a High-Security Environment

Depending on the level of security required, additional security measures can be implemented to create a high-security environment. To determine the need for additional security measures in our bank project, we first needed to identify which computers, if any, contained sensitive data at high risk for theft or intentional violation and disruption. Security for these machines, or their subnet, we decided to augment with more stringent security features than those used for the rest of network.

Controlling Access

No computer is ever completely secure if people other than the authorized user can sit down and tinker with it. In the case of our bank project, the bank attempted to minimize the impact of a user logging in at the console by:

If possible or practical, the bank will keep unauthorized users away from computer power and reset switches. The most secure computers (other than those in locked and guarded rooms) give users access to only the keyboard, monitor, mouse, and printer. The bank will lock up the CPU and removable media drives and allow only authorized personnel to have access to them.

By default, Microsoft Windows 2000 allows any program to access files on floppy disks and CDs. A highly secure, multi-user environment allows only the person interactively logged on to access those devices, so interactive users can write sensitive information to these drives confident that no other user or program can see or modify it (detailed steps of how to accomplish this are contained in the Appendix). This mode allocates system floppy disks or CDs to a user as part of the interactive log-on process, and then frees them automatically for general use or reallocation when that user logs off. For our bank project, we made it a standard practice to remove sensitive data from the floppy or CD-ROM drives before logging off.

Network-Level Security

By placing a computer on a network, you add an access route to the computer that should be secured against some level of intrusionfrom casual to intentional. User validation and protections on files and other objects are sufficient for standard-level security, but high-level security demands that the physical network be secured.

The main risk is unauthorized network taps. If the network is set up completely within a secure building (a rarity) the risk of unauthorized taps is minimized or eliminated. If the network is not completely within direct physical control, you must decide on a level of realistic protection and institute it, beginning with physical security. If, for instance, cabling passes through unsecured areas, consider using optical fiber links rather than twisted pairit is much harder to tap a fiber and siphon off data.

More common these days is Internet communications. The security issue here cuts both ways, because this sort of connection provides access to and from the Internet community. In essence, this means that just about everyone in the world with access to a computer has possible access to some or all systems contained within an enterprise. To get in, however, we have created a series of moats or security walls that they must defeat before they can gain access.

It is beyond the scope of this document to go into firewall design and implementation, but this would act as our first moat. The rest of this document details the security lockdown and secure architecture MCS created for the bank behind the first firewall.

Important General Security Considerations

KnownStates and Repeatability

Have a process for setting up servers that is repeatable. Start with clean installations of the operating system and always use NTFS. That way you will get a consistent set of files, and their permissions will be set properly. If the extra work of doing clean installations seems daunting, keep in mind that if there is a hardware failure or you are adding or replacing a server, you will most likely have to do a clean installation. If you upgrade a bunch of servers, they will most likely have different sets of files installed. IIS and other components can be configured with scripts. Create a script and use it for all updates. You won't forget a setting, and you can always use that script if you have to add another server.

It can be very difficult to use a server that is completely locked down. For example, unused services should be turned off while a server is in "production" mode. However, it necessary to keep some services running while configuring the server. Create two scripts: one script to lock the server down for "production" mode, and another to put the server in "maintenance" mode. Servers have been hacked because security settings were turned off "temporarily" for maintenance, and not turned back on.

Components

If you are not using a component or feature, do not install it. Delete or disable it. This is very important. Remove everything you can possibly remove and still have your site function.

Set Services to "Manual"

Turn off all services that you are not using. To help determine which services are being used, set the Startup Type of services that you believe are unused to Manual. Restart the server and use all of your applications. Then use the Services MMC snap-in to see which services are started. Services that haven't started probably are set to Disabled.

Passwords

The security of any workstation or server is only as good as its passwords. Use strong passwords and change them frequently based on policy. Recent studies suggest that you choose passwords that are at least seven characters long and contain a mix of letters, numbers, and punctuation marks.

Use the Event Logs Service

The Event Log services will generally have information that will help you debug problems. They also are a great source of information on possible malicious activities that could be occurring on the system.

Keep a Log of Changes

Keep a chronological list of all the changes you make. This will make it easier to configure new machines, and it also provides a record of what you've done.

Confirmation

Always double-check your configuration before connecting a server to the Internet. No server should ever be on the Internet without all security measures in place. Use a checklist to keep track of security measures. Attackers are continuously scanning IP addresses to find new machines. There are many vulnerability detectors available, both commercial and freeware. Use these products to confirm that your security measures are in place and working.

Defense in Depth

Do not rely on a single defense to protect you. Make attackers work their way through a maze of defenses. Design systems like a castle with a moat, drawbridge, outer wall, inner wall, and a keep. This doesn't mean that it must be difficult for the legitimate user to get information from your Web site. Read-only access is usually simple to achieve. All methods for changing, editing, adding, or posting information to a Web site must be carefully secured.

Maintenance

Maintenance is an ongoing activity for any secure Web site. The simplest, and most important, maintenance activity is monitoring security bulletins and implementing any recommendations. Maintenance also includes periodic checks to ensure that all security procedures are still in place and working.

Test All Features Frequently

Stop periodically, reboot the computer, and test your applications. If you find that something has stopped working or its behavior has changed, you can look at the list of changes and figure out which setting caused the change.

Use a Net Sniffer to Detect Traffic

A network sniffer or monitor may give you clues about which services are running. Use the "Well Known Port Numbers" document, http://www.isi.edu/in-notes/iana/assignments/port-numbers , to determine which services are using a port.

Applying the Latest Service Pack and Hotfixes

It is very important to keep current on all security information for all of the products that you are using on both the server and the workstation. Once a security-related issue becomes public, the recommended fixes must be implemented as soon as possible. Attackers monitor this information also and will use it against any client or site that isn't up-to-date. Attackers write scripts that test a system for all known weaknesses. Systems are routinely hacked because of well-known exploits. Therefore, we cannot emphasize enough the importance of staying current on security updates and patches.

Microsoft automatically e-mails security bulletins as issues are discovered. To see previous bulletins, and sign up for future bulletins, go to http://www.microsoft.com/technet/security/default.mspx . After you review all Microsoft Security Bulletins, ensure that all the latest patches are applied to the perimeter network (also known as DMZ or demilitarized zone) servers. Currently, Windows NT 4.0 Service Pack 6 (SP6) is the latest Service Pack and is recommended for secure Internet Information Server 4(IIS4) sites. See the following site:

Also review the latest Microsoft security news at http://www.microsoft.com/technet/security/default.mspx .

Preventing DoS Attacks

Denial of Service attacks are very difficult to defend against. Again, one of the most important things to do is to keep up to date on the latest DoS attacks posted on http://www.microsoft.com/technet/security/default.mspx . Another approach is to harden the TCP/IP stack on a Windows 2000 server or workstation to help prevent common DoS attacks from impacting the performance of your system or bringing it down.

Hardening the TCP/IP Stack

By default, the TCP/IP stack is configured to handle normal traffic and to be robust under normal working conditions. If a Windows 2000 server or workstation is going to be exposed to the Internet, the TCP/IP stack should be reconfigured to handle the various TCP/IP protocol attacks. See the Knowledge Base article, "Internet Server Unavailable Because of Malicious SYN Attacks" ( http://support.microsoft.com/default.aspx?scid=kb;en-us;142641&sd=tech ) for more information.

To harden the stack at the bank, we set the following keys. All of the TCP/IP parameters are located under the registry key

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services

SynAttackProtect

Parameters:

EnableDeadGWDetect

EnablePMTUDiscovery

KeepAliveTime

NoNameReleaseOnDemand

PerformRouterDiscovery

Network Settings

Disable NetBIOS over TCP/IP

Another way to prevent malicious users from gaining access to your workstation or server via some facility other than TCP/IP is to disable NetBIOS (network basic input/output system) over TCP/IP. This will disable the use of all default share and printer access to your computer using the \\Name\Share command set. These operations include directory and printer sharing, NetDDE (network Dynamic Data Exchange), and remote administration.

You can control the use of NetBIOS over TCP/IP (NBT) by going into Advanced TCP/IP Settings and disabling NetBIOS over TCP/IP. This way, no one can try to remote-mount drives or remote-edit registries. Windows NT networking services run promiscuously over multiple transports; therefore, internally your computers can still talk to each other over other internal protocols.

Port and Protocol Configurations

The next important step on any NIC (network interface card) exposed to the Internet is to set up TCP/IP filtering to control what types of traffic are allowed to communicate to the system. Many people fall into the trap of not making these changes if they have a firewall between themselves and the Internet. They make the assumption that the firewall will provide complete protection. This is the kind of thinking that allows hackers to gain access to Web servers, cable, or DSL (Digital Subscriber Line) computers that are connected to the Web. Adding these changes to the exposed NIC creates another moat in your defense that hackers must defeat before they can claim victory. At the bank, we used the advanced TCP/IP settings to set filtering for our Internet NIC. The following illustration shows these settings.

See full-sized image.

Basically, the bank permitted only TCP ports 80 for HTTP access and 443 for Secure Sockets Layer (SSL). They permitted no User Datagram Protocol (UDP) ports and only IP Protocol 6 (TCP). It's important to realize that specific company port requirements need to be identified and validated for individual needs. Also, it's important to understand fully the security implications of enabling a port or protocol.

Unbind Unnecessary Services and Protocols from Your Internet Adapter Cards

Another way hackers gain access to a remote machine is by using some information about services that the local user may not know they have enabled. Therefore, it's important to disable any unused services.

Disable Unnecessary Default Services

The following services should be disabled. These changes are implemented within the bank's security template. If the template is backed out, these services will still remain disabled and will require manual changes in order to enabled them. The services the bank disabled on its IIS servers included:

Note: This service must be running on all DC's if multiple sites are used.

Note: You will need to set this back to manual and start the service to use BackupExec or Netdiags.exe.

Restrict Default NTFS Permissions

For each hard drive on the bank's systems, we modified the ACL on the root directory:

The team modified ACLs on these folders, which do not inherit permissions from the root: (Documents and Settings, Program Files, WINNT) to the following permissions:

We also restricted access to the system's local security account manager (SAM) database by modifying the ACLs on Winnt\System32\config and Winnt\Repair by:

Remove Unnecessary File System Access

The next step was to disable auto-generation of 8.3 names for backward compatibility with16-bit apps. In a secure environment it's important to avoid using 16-bit apps. The team turned off this feature by setting: HKLM\System\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation = reg_dword : 1. Another important step is to disable the build in admin shares by:

Note: BackupExec requires the above share names prior to backing up the server.

Secure Local User Accounts

Another important step is to control the built-in accounts that are a part of Windows 2000. Many hackers exploit this type of information when they are attempting to breach a server's account login structure. Some of the changes our team made include:

Important Note On domain controllers, do not rename the Administrator account. Copy it to create a working "administrator" account and remove all privileges/group memberships from the original. This avoids the well-known admin account RID.

Secure the System Registry

The registry is the heart of a Windows 2000 system and it is essential to restrict anonymous access to the registry to prevent unauthenticated users from doing things like enumerating shares and local/domain users (KB article 143474). See Group Policy or set LM\System\CurrentControlSet\Control\LSA\RestrictAnonymous = reg_dword : 1. Other things to consider include:

Setting User Rights Assignments

The next key component of any server or workstation security strategy is to control the advanced User Rights that are set by default when a Windows 2000 server or workstation is installed. Again, it is important to apply these settings using the steps outlined in the Group Policy section of this paper, "Applying the Security Configuration Using Policy." The settings in the bank's .inf file for its secure Web servers are listed in the following illustration.

See full-sized image.

One of the challenges we faced when adding these settings was to fully understand the impact each setting had to applications that were already installed and running. That is why it's important to understand completely what each setting does before applying the template. A better approach, we discovered, would have been to set the security on all servers, including the development servers, before the server was in production, and then create our application in a secure environment that mimics the eventual production world. It can be challenging to track down which setting caused an issue after the template is applied if the development servers have a different security configuration. Please refer to the Appendix for a complete explanation of each setting.

Tightening Down the System

There are many settings on a Windows 2000 system that can be configured to tighten down the default installation. It is up to the security team to decide what level of security they need to implement and how many of these configuration changes are required. Again, the bank decided to start with the High Security Web site INF file supplied by Microsoft on the Web refer to http://www.microsoft.com/technet/security/default.mspx for the latest version), and custom it to meet the bank's internal needs. The following illustration shows the changes made by the HighSecWeb template (see Appendix C for a copy of the bank's Highsecweb template).

See full-sized image.

Again, it's important to fully understand the impact each configuration change has before applying the template. Refer to the Appendix for an explanation of the settings changed by the preceding template (anything that is not defined is not outlined). It is also important to take the HighSecWeb template and customize it to meet your individual security needs.

Auditing

Auditing of your servers is one of the key components in a monitoring strategy. It is very important to track these on a regular basis and to set up alerts when an incursion occurs. There are many third-party products that assist with this process. Refer to the monitoring and auditing section below for suggestions. A sample of how we configured auditing for our bank project is in the chart below.

Other System Changes

There are other important changes that need to be made at a file and system level. To the default security configuration at the bank, we set the system boot time to zero seconds, as shown in the following illustration.

Set the system boot time to zero seconds.

To prevent unauthorized users from bypassing the default Windows NT boot and secure logon process:

Go to Control Panel | System | Advanced | Startup and Recovery and set the Display List of Operating Systems to 0

See full-sized image.

We also moved all access control list (ACL) critical files. To do this, we placed all commonly used administrative tools in a special directory out of %systemroot% and restricted them as an ACL so that only administrators have full access to these files. Moving ACL critical files is important because hackers could use these tools to gain valuable information and launch rogue programs from the command line. This applies to both the workstation or server.

For example, create a directory called \tools, and place the following files in there:

Policy and Auditing Changes

One of the key components of any security strategy is to ensure the configuration of the servers and workstations meet the policies set by the security committee in the policy document. The following charts outlines the configuration set for the bank. Refer to the section on Group Policy later in this paper, "Applying the Security Configuration Using Policy," to understand the recommended way to apply these policies.

Internet Information Server File System Changes

Another important aspect of the bank's security model was the creation of a secure hosting environment for all Web components. Based on information obtained from the Microsoft Security Web site, the bank set the appropriate virtual directory permissions/Web application space, set the appropriate IIS log file ACLs, enable the logging mechanism, and chose to disable or remove all sample applications.

Setting Directory Permissions/Web Application Space

When setting the appropriate virtual directory permissions/Web application space, it is important to control the IIS application directories. This is application dependent, but the following general rules apply:

These settings would apply to any computer running a Web site.

Rather than setting ACLs on each file, we recommend setting new directories for each type of file and setting ACLs on the directory and allowing the ACLs to inherit to the files. For example a directory structure may look like this:

c:\inetpub\wwwroot\myserver\static (.html)

C:\inetpub\wwwroot\myserver\include (.inc)

C:\inetpub\wwwroot\myserver\script (.asp)

c:\inetpub\wwwroot\myserver\executable (.dll)

c:\inetpub\wwwroot\myserver\images (.gif, .jpeg)

Real ACL inheritance is a feature of Windows NT4 SP4 with the Security Configuration Editor installed.

Also, if you are using FTP and SMTP then their directories need special attention.

Setting IIS Log File ACLs

To prevent malicious users who have deleted files to cover their tracks, set appropriate IIS log file ACLs. We recommend set the ACLs on the IIS-generated log files (%systemroot%\system32\LogFiles) to:

These settings apply to any computer running a Web site.

Enable Logging Setting

Logging is paramount when you want to see if your server is being attacked. You should use World Wide Web Consortium (W3C) Extended Logging format by loading the IIS MMC snap in. Then:

Also, remember to set all required general and extended properties in the Properties box of the log file.

These settings apply to any computer running a Web site.

Disabling or Removing All Sample Applications

Samples are just that, samples, and should never be installed on a production server. This includes documentation (the software development kit [SDK] documents include sample code), the Exploration Air sample site from the SDK, and others. Here are the default locations for some of the samples:

These settings apply to any computer running a Web site.

Top of page

Applying the Security Configuration Using Policy

The goal for creating and applying security policies is to simplify and centralize the process for configuring and managing security within the network perimeter for Windows 2000 Servers. Using organizational units is the best method for separating specific security requirements for certain servers, such as the IIS servers, from the rest of the servers. It is important to plan the policy architecture separating specific security requirements for servers using organizational units because once the infrastructure is in production, a policy may need to be backed out or changed due to problems and only the servers that belong to the organizational unit will be affected and not the rest of the servers within the network perimeter.

Policy Hierarchy and Inheritance

A Group Policy is applied hierarchically, from the least-restrictive container group (local group) to the most-restrictive container group (organizational unit). Lower container groups inherit Group Policies from a higher container group by default. The order in which policies are applied from least to greatest is the local server group, site group, domain group and then the organizational unit. The implementation for the bank was to use a domain-wide policy for the common security requirements and organizational units for the specific server security requirements, which will overwrite the default local server group policies.

Domain Policy

In addition to managing security using organizational units, a domain-wide policy will be implemented assigning common security policies required in the network perimeter, such as account, audit, and user rights to all servers. When the domain is built, a default domain policy is created. The goal will be to not modify the default policy but override it with certain parameters by creating a new policy and linking it above the domain policy. Only the parameters that are defined in the linked policy will override the default domain policy. If there are problems, then the override policy can be disabled, which will ensure that the default domain policy will take control again.

Domain Controller Policy

A separate default policy is created for the domain controllers when the domain is built. Certain security policies will need to be applied to override the domain controller default policies. A new domain controller policy will be built and linked above the default domain controller policy just like the domain policy. By creating new domain policies, it will make it easier to back out the override in case a problem occurs. Backing out the override policy will put the default policies back in place.

Applying Group Policies

A group policy is applied when the server is restarted. By default, the interval at which a group policy is refreshed for Windows 2000 based computers is 90 minutes. A group policy can also be immediately applied to a server by issuing the following command on the computer:

Secedit /refreshpolicy machine_policy

Policy Design and Implementation

Group Policies that modify the security settings for computers are divided into multiple sections:

The domain policy configured for the bank modified the Account Policies and the Audit Policy, which are common to all servers in the network perimeter. In addition, the Security Options Policies and System Services are configured and applied for each organizational unit that was created for each of the specific class of servers. Additional registry modifications may be added too and imbedded in the security template created for the organizational unit, such as the hardening of the TCP/IP parameters for the IIS Servers. The following steps were used to create and implement security policies for the bank:

Document Default Local and Domain Policies

When the domain is initially created, a domain policy and a domain controller policy are created with default settings. Before changes to policies are applied to the network perimeter, the current default policy settings for member servers and domain controllers need to be reviewed and document. See the Appendix for detailed information on default domain policies.

Create Organizational Units in AD for Each Class of Server

Separate organizational units simplify the process for deploying Group Policies in order to apply customized security templates to each class of server. Domain controllers are in a separate organizational unit by default. Four organization units were created for the bank based on the different class of servers in the network perimeter. The following are the names of the organizational units that were created and a brief summary of the security applied to each:

IIS Servers. These servers need the tightest security applied to them since they are on the front line of the network perimeter. The security model created for the IIS servers enforces strong security. This includes hardening of the TCP/IP stack, disabling services not required and overriding the default security options of the group policy with enforced restrictions. See the IIS Template at end of this section.

FTP Servers. The same security model is applied as the IIS Servers with the addition of enabling FTP. See the IIS Template at end of this section.

LDAP Servers. The same security policy created for IIS is applied to the LDAP servers and the same services are disabled. The hardening of the TCP/IP parameters is not applied.

Create a Customized Security Template for Each Class of Server

Each type of server warrants a different security configuration. Although the differences are minor, automated management is best served by creating a distinct template for each type of server. The following templates were created for the bank for each category of server. These templates are stored on the domain controllers in the network perimeter.

To review or make modifications to templates, open the Secure Templates MMC snap-in, expand the default Templates directory, which is located under %systemroot%\security\templates, and select one of the templates listed above to view its current configuration. In order to make changes, double-click on one of the policies within the template and make appropriate changes. To save the template, right-click the template name, such as Bank IIS.INF, and click Save to replace configuration or Save As to create a new template to test with.

Install the Group Policy in Each Organizational Unit Container

Once the security templates are created, a new Group Policy can be created for each of the organizational units, and then the security template (inf file) can be imported into the newly created policy. To accomplish this, open Active Directory Users And Computers and locate the organizational unit that the policy is going to be created within.

The policy is now created and loaded with the correct template. Computers can now be moved into the organizational unit and have the policy applied. Follow the same set of steps to install the Domain Controller and Domain Policies.

Policy Templates

The following parameters and values are the default domain settings for all servers and workstations in the bank's environment that are joined within the domain. The domain controller policy modifies the user rights policy just for the domain controllers. The domain policy modifies only the account policy for all servers that are joined into the domain.

IIS Group Policy Security Configuration

The next step was to create and apply the Web security templates to the organizational unit that represented fro example Web servers in the perimeter network. A security template was created (Bank Secweb.INF) that contains all the parameters in the following table and was applied using the MMC snap-in Security Configuration and Analysis Tool. This template is a customized version of the highsecweb.inf file provided by the Microsoft IIS security team. The following parameters and their associated values are the current configuration for the local policies that are applied to organizational unit for the bank's network perimeter servers.

Lessons Learned

A couple of lessons we learned when applying these policies include:

Top of page

Creating an Auditing and Monitoring Strategy

Security Tools

Now that we have outlined the Windows 2000 Security Model and have an understanding of how to secure the infrastructure, the next important step is to fully understand how a company would proactively detect a security exposure or breach. Since security on our project is of paramount importance, these measures need to be taken to assure resilience against possible intruders.

To address compliance with the defined security policy, many steps need to be taken. The process of validating the security policy settings can be quite tedious because there are many areas to cover. There are several security tools available that can be used to simplify this process. These tools range in functionality from port scanners (a low level tool) to overall security scanners. The following is a list of categories these tools usually fall under: