ISA Server 2004 UNLEASHED [Electronic resources] نسخه متنی

Preparing for an ISA Server 2004 Design

When designing ISA Server implementations of any size, it is important to establish and utilize a design methodology that is proven to have successful results. There are many different ways of approaching this, and different methodologies have varying levels of success, depending on the specific needs of the organization. In general, it is best practice to follow whatever design methodology has proven to work best in the past. That said, a common design methodology for ISA Server that works well is one that focuses on outlining current security needs and goals and matches them to specific ISA functionality.

Identifying Security Goals and Objectives

While seemingly straightforward, it is often difficult to define what goals or objectives ISA Server 2004 is meant to achieve. Many organizations are looking for "better security," but have a tough time identifying specifically what they mean by "better." Without knowing the question it is impossible to properly define the answer, so it is important to properly outline these goals and objectives in advance.

Every organization has different needs in this category, and it is impossible to list them all. However, some of the more common goals and objectives of an ISA Server design project are the following:

Secure access to Internet-facing services

Provide for the capability to monitor traffic between network segments

Provide for the capability to report on Internet traffic patterns

Reduce the amount of Internet bandwidth consumed

Enable employees to securely access network resources from remote locations

Design an infrastructure that is compliant with government regulations such as HIPAA or Sarbanes-Oxley

Reduce the overhead and complexity associated with managing security infrastructure

The first stage in a design process is to map out these goals and objectives in advance to provide for a common roadmap. This information is then used for later portions of the design project.

Documenting and Discovering Existing Environment Settings

It's often surprising how many organizations do not maintain an updated set of diagrams or documentation about their existing network and security infrastructure. When it comes down to it, there is often not enough time available for IT organizations that are already stretched thin to maintain these types of materials. Unfortunately, however, it is very important to keep this type of information handy, particularly in light of new governmental regulations such as Sarbanes-Oxley, which stipulate the need for identifiable documented processes.

Before designing an ISA implementation, it is therefore important to gather any and all updated documentation to determine the nature of the environment in which ISA will be installed. During deployment of an ISA server is not the time to discover that there are multiple previously unidentified networks attached via ad-hoc routers in dusty closets.

If a network diagram is not available, it is highly recommended to create one, using Microsoft Visio or another similar network diagramming tool. This will make it easier to visualize the project and logically design the location of ISA Servers.

In addition to mapping out the locations of routers, switches, and the logical network as a whole, it is a good idea to match up the network design with the overall location of computers and computer services. Understanding where critical servers are logically located on a network, and where client workstations are located can be useful in determining where to place ISA Servers. For example, if a client network is composed of workstations from a department that is prone to virus infestations or exploits, it might prove helpful to place an ISA Server between that network and a separate network of mission-critical servers.

When all is said and done, an ISA Server design process is only as complete as the knowledge that was used to create it. It is therefore important to understand how the current environment is structured before you try to decide where and how to utilize ISA.

Matching Goals and Objectives to ISA Features

It may seem trite, but many ISA design sessions start with a lack of understanding of what the organization needs to get out of ISA. Or, in other cases, ISA is required for a specific reason, such as to secure Outlook Web Access from the Internet, but the fact that it can be used for more than this is never realized. It is therefore important to maintain a list of what types of functionality are necessary in an environment and what ISA features correspond with this functionality. For example, Table 4.1 depicts several common goals and objectives and what ISA features correspond to those particular needs:

Managing a Deployment Project

One of the most difficult parts of deploying a technical solution is managing the project itself. Often, security solutions, particularly Microsoft security solutions, become part of a politicalor even an almost religioustopic for many of the organizations who seek to deploy them. In addition, care must be taken to manage and control other aspects of ISA design and deployment. The following are areas of particular note for ISA Server 2004 deployments:

Defining the project
It is not enough to simply define what will be deployed, but rather it is necessary to explain the "why" of the project. What critical functionality does ISA bring into an environment? Why should management shell out the money necessary to deploy yet another set of servers? Defining and documenting the project at an early stage can help it get out of the gates early on.

Outlining the project scope
Determining the size, complexity, and level of deployment are critical factors in the success of an ISA project. A well defined set of boundaries to which the project will be limited helps to minimize the amount of testing that will need to be done and also helps to sell the project to a targeted audience.

Organizing technology champions
If no one champions a new product, the technology dies, either before it is implemented or shortly afterwards. Technologies such as ISA Server require those who use it to be at least somewhat interested in the type of functionality that it can provide. For example, creating champions may simply involve showing an Exchange administrator what is possible with ISA mail publishing rules for Outlook Web Access. Or, a manager evaluating the plethora of expensive VPN solutions may become an ISA technology champion after he or she finds the low-cost and highly functional ISA VPN solutions tempting. The more support ISA can get, the easier it is to manage the project to completion.

Convincing the skeptics
The reality today is that there is a great deal of skepticism regarding Microsoft security technologies. This skepticism is partly based on the bad experiences many security admins have had in the past with exploits and security holes in Microsoft products. This makes a product such as ISA Server a tougher sell to this audience. In this scenario, ISA is often best sold as an additional layer to existing security technologies, rather than as a replacement for them. In addition, as with any technology, if the impression is that a fundamental redesign of existing network or security architecture is necessary to deploy ISA, it will have a more difficult time gaining approval.

Controlling the costs
Although a full ISA Server 2004 deployment with multiple arrays of ISA Enterprise Edition servers running on robust multi-processor systems can end up being quite expensive, most ISA deployments are actually quite low cost, particularly when they are compared to similar solutions. A single-processor ISA Server 2004 Standard system running on server hardware, for example, can easily be contained to a small licensing charge (around $1300 per processor or so) and the price of the hardware. Because there are no client licenses to purchase, this makes ISA itself a fairly inexpensive solution to deploy.

Containing the impact
It is critical that the level of impact that the deployed solution will have is mitigated as much as possible. The success of an IT project is often defined by the level of "pain" that the end users end up feeling after the migration project. Fortunately, ISA deployments are easy to set up in parallel to existing deployed environments, reducing the risk that they have and allowing for an extensive pilot of the technology before it is fully deployed.

Training the resources
Because ISA is a new technology, the skills to administer and maintain the environment are not always present in an IT infrastructure. Formal training in ISA Server administration may be warranted, but are not necessarily required if using references such as this book. The key to a successful project post-implementation comes down to how smoothly the new environment dovetails with existing processes and environmental procedures. Training in advance the people who will work with the product is key toward reaching this goal.

Documenting the Design

Although often the most important step in a design process, the documentation of an ISA design is often overlooked. It cannot be stressed enough that good documentation is critical for IT projects, particularly ones involving security and remote access considerations.Chapter 20, "Documenting an ISA Server 2004 Environment."

CAUTION

Documentation for ISA Configuration and deployment should be highly restricted, and not made available to anyone who does not absolutely need the information in it. Spreading information on how an ISA environment is configured is akin to giving the war plans to an enemy army in advance of a battle.