BizTalk Server 2004 Deployment Guide for Security

Switch View

BizTalk Server 2004 Deployment Guid...

Collapse All

Erwin Abinion; Laura Machado de Wright; Adam Zilinskas

Microsoft Corporation

April 2005

Applies to: BizTalk Server 2004

Summary: The BizTalk Server 2004 Deployment Guide for Security contains information to help architects and information technology (IT) professionals design and deploy a secure implementation of Microsoft BizTalk Server 2004 in a multi-computer environment. (66 printed pages)

Download sample code

Overview

This document provides guidelines about how to deploy Microsoft BizTalk Server 2004 in a secure environment. It provides information to help you assess the potential threats to your BizTalk Server implementation, a sample architecture for small and medium-size companies, and a sample Point of Sale solution.

It is difficult to run a business today without the need to think about security. If you offer online transactions, you want to help protect the credit card information of your customers. If you work for a Fortune 500 company, you want to keep malicious users away from your networks. If you are a desktop user, you do not want viruses and worms to damage your data and limit your ability to do your work. Almost every day you hear or read about new software vulnerabilities; about new worms and viruses that spread fast, are difficult to eradicate, and can do more damage than the previous ones; and about the company Web sites that are defaced by malicious users. Whatever your business is—large or small, a few customers or millions of customers, one computer or hundreds of computers—you must limit the ability of malicious users and programs (viruses, worms) to compromise your data, computers, and ability to do your job.

The following paragraphs describe the sections of this document.

Threat Model Analysis

To help protect your company, you must first identify the critical assets (business data, servers, anything that is valuable to your company) that you want to protect, and how a malicious user or program might compromise them. In other words, you must perform a threat analysis exercise to understand where to concentrate your security efforts. This section introduces the threat model process we use for the sample architecture and the sample solution.

Case Studies

This section provides information about how two companies that participated in the BizTalk Server 2004 Early Adopter Program (EAP) and Joint Development Program (JDP) secure their implementations of BizTalk Server, and the threats they are concerned with.

Sample Architecture for Small and Medium-Sized Companies

After we looked at how companies that participated in the BizTalk Server 2004 EAP and JDP secure their implementations of BizTalk Server, we derived a recommended architecture for small and medium-sized companies. This architecture includes security recommendations while it addresses the needs of these companies.

For information about recommended deployments for large companies, see "Planning a Secure Deployment" in BizTalk Server 2004 Help.

Threat Model Analysis for Sample Architecture

To help you when you design your own BizTalk Server deployment, we show you the threat model analysis for the sample architecture of each identified usage scenario.

Best Practices

This section provides some recommendations and best practices for how to secure your BizTalk Server 2004 environment.

Sample Solution

This section provides a four-computer sample deployment of BizTalk Server 2004. The purpose of this sample is to show you an implementation of BizTalk Server 2004, a threat model analysis of the sample architecture, how we chose to mitigate those threats in the specific scenario of the sample, and detailed steps to replicate it.

As you plan your BizTalk Server 2004 deployment, we strongly recommend that you read the "Planning a Secure Deployment" section of BizTalk Server 2004 Help. The "Planning a Secure Deployment" section provides additional security recommendations for a BizTalk Server deployment, for each BizTalk Server component, and for the ports you have to open in the firewalls.

To guide you as you begin to plan and design an enterprise architecture, see Microsoft Systems Architecture (http://go.microsoft.com/fwlink/?LinkId=27923).

For guidance on how to achieve system reliability, availability, supportability, and manageability, see the Microsoft Operations Framework (http://go.microsoft.com/fwlink/?LinkId=27924).

Threat Model Analysis

A threat model analysis (TMA) is an analysis that helps determine the security risks posed to a product, application, network, or environment, and how attacks can show up. The goal is to determine which threats require mitigation and how to mitigate them.

This section provides high-level information about the TMA process. For more information, see Chapter 4 of Writing Secure Code, Second edition, by Michael Howard and David LeBlanc.

Some of the benefits of a TMA are:

Provides a better understanding of your application
Helps you find bugs
Can help new team members understand the application in detail
Contains important information for other teams that build on your application
Useful for testers

The high-level steps to perform a TMA are:

Collect background information
Create and analyze the threat model
Review threats
Identify mitigation techniques and technologies

Collect Background Information

To prepare for a successful TMA, you have to collect some background information. It is useful to analyze your target environment (an application, program, or the whole infrastructure) as follows:

Identify use-case scenarios. For each use-case scenario for your target environment, identify how you expect your company to use the target environment, and any limitations or restrictions on the target environment. This information helps define the scope of the threat model discussion, and provides pointers to assets (anything of value to your company, such as data and computers) and entry points.
Create a data flow diagram (DFD) for each scenario. Make sure that you go deep enough to understand your threats.
Determine the boundaries and scope of the target environment.
Understand the boundaries between trusted and untrusted components.
Understand the configuration and administration model for each component.
Create a list of external dependencies.
Create a list of assumptions about other components on which each component depends. This helps validate cross-component assumptions, action items, and follow-up items with other teams.

Create and Analyze the Threat Model

After you collect the background information, you should have a threat model meeting or meetings. Make sure that at least one member of each development discipline (for example, program managers, developers, and testers) is at the meeting. Make sure that you remind the attendees that the goal of the meeting is to find threats, not to fix them. During the threat model meeting, do the following:

Examine the DFD for each use case. For each use case identify:
- Entry points
- Trust boundaries
- Flow of data from entry point to final resting location (and back)
Note the assets involved.
Discuss each DFD, and look for threats in the following categories for all entries in the DFD: Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges.
Use the Checklist: Architecture and Design Review (http://go.microsoft.com/fwlink/?LinkId=27925) to make sure that all threat categories are covered.

Create a list of the identified threats. We recommend that this list include the following: title, brief description (including threat trees), asset (asset), impact(s), risk, mitigation techniques, mitigation status, and a bug number.

Note
You can add risk, mitigation techniques, and mitigation status as you review the threats. Do not spend too much time in these areas during the threat model meeting.

Review Threats

After you have identified the threats to your environment, you must rank the risk of each threat and determine how you want to respond to each threat. You can do this with additional team meetings or through e-mail. You can use the following effect categories to calculate risk exposure: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.

After you have a list of the threats to your target environment prioritized by risk, you must determine how you will respond to each threat. Your response can be to do nothing (rarely a good choice), warn users about the potential problem, remove the problem, or fix the problem.

Identify Mitigation Techniques and Technologies

After you identify which threats you will fix, you must determine the available mitigation techniques for each threat, and the most appropriate technology to reduce the effect of each threat.

For example, depending on the details of your target environment, you can reduce the effect of data-tamper threats by using authorization techniques. You then have to determine the appropriate authorization technology to use (for example, discretionary access control lists (DACLs), permissions, or IP restrictions).

Important
When you evaluate mitigation techniques and technologies to use, you must consider what makes business sense for your company, and any policies your company has that might affect the mitigation technique to choose.

After you complete the TMA, do the following:

Document the security model and deployment considerations
Implement and test mitigations
Keep the threat model synchronized with design

Document Security Model and Deployment Considerations

It is valuable to document what you discover during the TMA and how you decide to reduce the effect of the threats to your target environment. This documentation can be useful to quality assurance (QA), test, support, and operations personnel. Include information about other applications that interact or interface with your target environment, and the firewall and topology recommendations and requirements.

Implement and Test Mitigations

When your team is ready to fix threats identified during the TMA, make sure you use development and deployment checklists to follow secure code and deployment standards that will help minimize the introduction of new threats.

After you implement a mitigation, make sure you test it to make sure it provides the level of protection that you want for the threat.

Keep the Threat Model in Sync with Design

As you add new applications, servers, and other elements to your environment, make sure that you revisit the findings of the threat model analysis and do TMAs for any new functionality.

Case Studies

Security is a concern of any company that is serious about making sure that only a select group of people or applications can access its data and resources. Companies approach and implement security in a variety of ways. In this section we document how two companies developed their security architecture to meet their needs.

Company A

Company A is a major supplier of material and services to the industrial sector. Its business model relies on electronic transactions with key customers and suppliers. Company A uses Microsoft BizTalk Server 2004 to manage transactions and communications between internal and external environments.

Potential Threats/Security Concerns

Company A wants to make sure that it processes only messages from authenticated sources. Some of the documents BizTalk Server processes can contain sensitive information such as financial and personnel data. Company A verifies each incoming message by using custom cryptographic APIs. It has also built its physical architecture to handle its security needs.

Company A uses file transfer protocol (FTP) for some of its message traffic. Although FTP is inherently not secure, Company A accepts the associated risks because it has many firewalls to help secure other outward-facing applications. Because Company A receives some of its incoming data through HTTPS, it is concerned about denial of service (DoS) attacks from external sources. If a DoS attack does occur, the company has mechanisms to alert the appropriate people immediately.

Architecture

The following figure shows the security architecture that Company A uses. Notice that it has segmented its environment with firewalls to help protect its front-end application and content servers, its back-end database and business logic servers, and its outgoing message infrastructure.

Figure 1 Company A security architecture

Company A has two main methods to send and receive information to and from BizTalk Server. The first method uses FTP. Company A supports electronic data interchange (EDI) transactions by using a third-party translation service provider to communicate with its suppliers and partners. This third-party translation service provider handles incoming and outgoing orders that BizTalk Server must process in an EDI format.

The second method that Company A uses is HTTPS. Company A also works with a third-party service provider that serves as a hub for its industry and makes the purchase and sale of products Company A sells and consumes easier.

Certificates

Company A implements its own secure digital certificates. It manages only a few certificates. Because it uses a third-party service provider, it is less concerned about digital certificates. Company A realizes that digital certificates are a greater concern for the service provider, because the service provider interacts with many different institutions.

Company B

Company B is a software company. Its business model relies on electronic transactions with key customers and suppliers. Company B currently uses a Microsoft BizTalk Server 2002 implementation for most of its transactions, and has completed a BizTalk Server 2004 pilot to start replacing its current implementation.

Company B uses BizTalk Server 2002 and 2004 to manage transactions and communications between internal and external applications. Company B communicates with approximately 85 internal applications and 2300 trading partners. It currently processes approximately 2.5 million documents per month, and estimates that it will process 6 million documents per month by the end of 2005.

Potential Threats/Security Concerns

Company B wants to make sure that it receives and processes only messages from authenticated sources. Company B also wants to make sure that it can receive and retrieve documents from outside its corporate network as safely as possible. The firewall that separates Company B's corporate network from the Internet only lets through traffic from port 80 and port 443. The firewall rejects all other traffic.

Architecture

The following figure shows the architecture that Company B uses. Company B uses BizTalk Server as a message broker to communicate between internal applications and to process, send, and receive correctly formatted messages to and from its suppliers and customers. Company B has to process internal and external documents in different formats. This includes flat files and XML documents.

Figure 2 Company B security architecture

Company B uses a single firewall to separate its corporate computers from the Internet. As an added layer of security, Company B incorporates Internet Protocol security (IPsec) communication between all its corporate servers and workstations that reside within the corporate network. Company B uses IPsec to encrypt all communications within its internal domain.

Company B uses a file share server to receive flat files. This file share server resides outside its corporate network and domain. A firewall separates the file share server from the corporate network. Company B's external partners post their flat file documents on this file share server, and they communicate with the file share server through an encrypted Point-to-Point Tunneling Protocol (PPTP) pipeline. Company B protects access to the file share server by partner passwords that expire every 30 days.

Company B has created a custom file-movement application that retrieves the flat file documents from the file share server and sends them to BizTalk Server for additional processing. The internal applications for Company B also use the custom file-movement application to pass flat files to BizTalk Server. BizTalk Server transforms these documents and sends them to Company B's trading partners.

Before BizTalk Server transforms the partner data to the internal application formats, it validates that it has an entry for the sender, receiver, and document type. If BizTalk Server receives a message for which it does not have an entry for either the sender, receiver, or document type, BizTalk Server rejects the message, and the operations team of Company B review the message. The internal applications send messages in a variety of formats that include EDIFACT, flat file, XML, and ANSI X12.

Company B also receives documents through HTTPS from internal and external sources. External partners post their documents to a Web server outside the corporate network. A firewall separates this Web server from the corporate network. The custom file-movement application also retrieves the documents posted through HTTPS. Company B uses a third-party product to encrypt and sign messages to its trading partners. As an additional piece of security, Company B performs a nightly audit on all the servers to make sure they have the correct security settings. Company B logs all exceptions for review.

Sample Architecture for Small and Medium-Sized Companies

This section provides a sample architecture to deploy Microsoft BizTalk Server 2004 when you want to help to protect the assets in a small or medium-sized company.

The "Planning a Secure Deployment" section in BizTalk Server 2004 Help (http://go.microsoft.com/fwlink/?linkid=20616) presents four reference architectures. While these architectures encourage defense in depth and separation of services to minimize the impact of an attack, they assume quantities of hardware, software, and human resources that are generally available to large companies.

However, small and medium-sized companies (or large companies with small BizTalk Server deployments) should also be concerned with how to protect their environments. After we looked at how companies in the BizTalk Server 2004 Early Adopter Program (EAP) and Joint Development Program (JDP) deployed or plan to deploy their BizTalk Server 2004 solutions, we derived a sample architecture for small and medium-sized companies that balances available resources with the greatest possible security. As recommended for the sample architectures in BizTalk Server 2004 Help, you should use the information in this section to help you plan your own deployment. After you evaluate your business needs and assets you might decide on a different architecture for your BizTalk Server 2004 deployment.

To make it easier to see how your architecture would look, this section provides sample architectures based on various adapters that you might use in your environment. The figures show you which components of the topology are adapter-independent, and which components depend on the adapter you use in your BizTalk Server environment.

In the next section, we examine usage scenarios based on some of the adapters you can use with BizTalk Server. To help you as you plan and design your own architecture, we provide a threat model analysis of this sample architecture. This analysis gives you a deeper look at the potential security issues that might affect your company, depending on the adapters you use to communicate with your partners.

While this section gives you information to help you design a secure deployment of BizTalk Server 2004, to increase the security in your environment you should also consider securing the communication between the servers in the environment. For more information about securing the communication between the servers, see "Sample Solution" in this document.

Important
This section assumes that you are not using Human Workflow Services (HWS), Business Activity Monitoring (BAM), or Business Activity Services (BAS.) These features require additional security considerations. They are discussed in "Planning a Secure Deployment" in BizTalk Server 2004 Help.

Note
For more information about adapters not described in this document, see the BizTalk Server Developer Center (http://go.microsoft.com/fwlink/?LinkId=46420.)

Base Sample Architecture

This section discusses the base sample architecture. It describes the components in a BizTalk Server deployment that are adapter-independent. We recommend that any BizTalk Server deployment have at least these components.

Base Architecture Components

The following figure shows the components of the base BizTalk Server sample architecture. These components appear in all the adapter-specific BizTalk Server architectures that we discuss in later sections.

Figure 3 Base architecture components

This sample architecture contains:

Perimeter network—Internet. This perimeter network (also known as DMZ, demilitarized zone, and screened subnet) contains servers that provide Internet-related services. There are no BizTalk Servers, BizTalk receive locations, or Enterprise Single Sign-On servers in this domain.
Perimeter network—intranet. This perimeter network contains servers that provide intranet-related services. It provides an additional layer of security between your intranet (for example, a corporate network) and the servers that run the application. Like the Internet perimeter network, the intranet perimeter network does not contain BizTalk Servers, BizTalk receive locations, or Enterprise Single Sign-On servers.

E-Business domain. This domain contains all the infrastructure and applications used by your BizTalk Server implementation. The servers in this domain are:

BizTalk Server. This server has an installation of the BizTalk Server runtime and instances of various BizTalk Hosts. The number of BizTalk Servers in the environment depends on the type of hosts they run and the performance needs. As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your processing hosts.
Master secret server. This server is the Enterprise Single Sign-On (SSO) master secret server. It holds the master secret (encryption key) that the SSO system uses to encrypt the data in the Credential database.

SQL Server. This server contains the BizTalk databases.

Important
For failover protection, we recommend that you cluster each BizTalk database. For more information about Microsoft SQL Server failover clustering, see the Microsoft MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=24773.

Note
Depending on your performance needs, you might have to separate the BizTalk databases into multiple computers that run SQL Server.

Domain controller. This server hosts the E-Business Active Directory domain. It contains information about all the groups and individual accounts that need access to BizTalk Server.
Administration tools. One of the servers in this domain hosts the administration tools: BizTalk Administration console, Health and Activity Tracking (HAT), and Enterprise Single Sign-On (SSO) administration utility.

Firewalls and domains. In Figure 3, Microsoft Internet Security and Acceleration (ISA) Server 2000 acts as a software firewall to help protect and contain each of these domains. Additionally, the E-Business domain has its own domain controller, and this domain does not trust any other domain. For more information about how to configure a firewall for domains and trusts, see the Microsoft Help and Support Web site at http://go.microsoft.com/fwlink/?LinkId=25230.
The sample architecture has two firewalls:
- Firewall 1. This firewall has three network interfaces: It routes traffic from the Internet, the intranet, and the perimeter networks.
- Firewall 2. This firewall is dual-homed: It routes traffic from the perimeter networks (both Internet and intranet) and the E-Business domain.
The computers in the perimeter networks are not members of any domain, and they do not communicate with each other.
IPsec. We recommend that you use Internet Protocol security (IPsec) to help secure the communication between all the servers in the E-Business domain. The IPsec rules are as follows:
- Allow authenticated traffic between BizTalk Server and the domain controller.
- Allow authenticated traffic between BizTalk Server and the administration tools server.
- Allow authenticated traffic between BizTalk Server and the master secret server.
- Allow authenticated traffic between BizTalk Server and the SQL Server.
- Allow authenticated traffic between the master secret server and the domain controller.
- Allow authenticated traffic between the master secret server and the BizTalk Server (isolated, processing, in-process, and tracking hosts.)
- Allow authenticated traffic between the master secret server and the SQL Server (Credential databases).
- Allow authenticated traffic between the domain controller and all the servers in the domain.
- Allow authenticated traffic between the administration tools server and all the servers in the domain.
- If you have other applications in the domain that do not need access to the BizTalk Server, SQL Server, master secret server, or administration tools server, block traffic between those applications and the appropriate servers.

Sample Architecture for HTTP and SOAP Adapters

This section describes the sample architecture when you use the HTTP and SOAP adapters to send and receive messages.

Architecture Components for HTTP and SOAP Adapters

The following figure shows the components of the BizTalk Server sample architecture when you use the HTTP or SOAP adapters.

Figure 4 Sample architecture that shows HTTP or SOAP adapters

Sample architecture for HTTP or SOAP adapter

This sample architecture contains the following:

Perimeter network—Internet. When you use the SOAP and HTTP adapters, we recommend that you use reverse proxy rules (the ISA Server implementation is called Web Publishing) to relay the message from the Internet-facing firewall (Firewall 1) to the firewall that helps protect the E-Business domain (Firewall 2), and from this firewall to the BizTalk Server that runs the isolated host. For more information about Web Publishing rules, see the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=24772.
When you use reverse proxy, you do not need Web servers in the perimeter network.
Perimeter network—intranet. Companies commonly use the HTTP and SOAP protocols for Internet-based communications, and therefore you do not need any servers in the intranet perimeter network to support this scenario. If you have an internal application in the intranet that integrates with BizTalk Server through the HTTP or SOAP protocols, you should follow the recommendations for the Internet perimeter network.

E-Business domain. This domain contains all the infrastructure and applications used by your BizTalk Server implementation. The servers in this domain are:

BizTalk Server (processing and tracking hosts). This server has an installation of the BizTalk Server runtime, and has instances of the hosts that contain the BizTalk orchestrations, pipelines, Business Rule Engine, and other business processes. This server also has a host instance of a host that supports tracking of health monitoring and business monitoring data.

Note
As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your processing hosts.

Note
As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your processing hosts.

BizTalk Server (isolated hosts for SOAP and HTTP adapters). This server has an installation of the BizTalk Server runtime, and has only instances of the hosts that contain the HTTP and SOAP adapters. These hosts run in a separate server because these adapters require that you install Internet Information Services (IIS) on the computer where they run.

Note
As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your HTTP and SOAP adapter hosts. When you do this, you must also configure Network Load Balancing (NLB). For more information about how to configure BizTalk Server for high availability, see the BizTalk Server 2004 Technical Guide for High Availability (http://go.microsoft.com/fwlink/?LinkId=38544).

Note

As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your HTTP and SOAP adapter hosts. When you do this, you must also configure Network Load Balancing (NLB). For more information about how to configure BizTalk Server for high availability, see the BizTalk Server 2004 Technical Guide for High Availability (http://go.microsoft.com/fwlink/?LinkId=38544).

Master secret server. Same as in the base sample architecture.
SQL Server. Same as in the base sample architecture.
Domain controller. Same as in the base sample architecture.
Administration tools. Same as in the base sample architecture.

Sample Architecture for BizTalk Message Queuing Adapter

This section describes the sample architecture when you use the BizTalk Message Queuing adapter to send and receive messages.

Architecture Components for BizTalk Message Queuing Adapter

The following figure shows the components of the BizTalk Server sample architecture when you use the BizTalk Message Queuing adapter.

Figure 5 Sample architecture that shows BizTalk Message Queuing adapter

Sample architecture for BizTalk Message Queuing

This sample architecture contains the following:

Perimeter network—Internet. We do not recommend using the Message Queuing binary protocol over the Internet. You should not let any Message Queuing traffic through Firewall 1. If you want to use the BizTalk Message Queuing adapter to receive messages over the Internet, do the following:

Use a Message Queuing server in the perimeter network.
Use the Message Queuing HTTP protocol over the Internet.

Have a forwarding application in the perimeter network that picks up the messages from the Message Queuing server and forwards them to the BizTalk Message Queuing adapter by using a binary protocol.

Important
Even if you use BizTalk Message Queuing to receive messages from the Internet, the ports that BizTalk Message Queuing uses should remain closed in Firewall 1.

Perimeter network—intranet. When you use the BizTalk Message Queuing adapter to receive messages from the intranet, there is a Windows Message Queuing server that forwards the Message Queuing traffic to the BizTalk Server that runs a host instance of the BizTalk Message Queuing adapter.
If the intranet and the E-Business domain share a common Active Directory, a message goes through a series of Message Queuing routers until it reaches the right destination (the BizTalk Server that runs a host instance of the BizTalk Message Queuing receive adapter). This option is not represented in the diagram because it is less secure than the first one.

E-Business domain. The servers in this domain are:

BizTalk Server (processing, BizTalk Message Queuing adapter, and Tracking hosts). This server has an installation of the BizTalk Server runtime, and has instances of the hosts that contain the BizTalk orchestrations, pipelines, Business Rule Engine, and other business processes. This is where the BizTalk Server ports, receive locations, pipelines, maps, schemas, and assemblies are located to receive, route, process, and send messages. This server also has a host instance of a host that supports tracking of health monitoring and business monitoring data. Additionally, this host contains instances of the host that runs the BizTalk Message Queuing send and receive adapters.

Note
As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your processing hosts. For more information about how to configure BizTalk Server for high availability, see the BizTalk Server 2004 Technical Guide for High Availability (http://go.microsoft.com/fwlink/?LinkId=38544).

Master secret server. Same as in the base sample architecture.
SQL Server. Same as in the base sample architecture.
Domain controller. Same as in the base sample architecture.
Administration tools. Same as in the base sample architecture.

Sample Architecture for FTP Adapter

This section describes the sample architecture when you use the FTP adapter to send and receive messages.

Architecture Components for FTP Adapter

The following figure shows the components of the BizTalk Server sample architecture when you use the FTP adapter.

Figure 6 Sample architecture that shows FTP adapter

This sample architecture contains the following:

Perimeter network—Internet. When you use the FTP adapter, there is an FTP server in the Internet perimeter network.

Note
The FTP server can also be located outside your environment—in the partner's network, or hosted by a third-party independent software vendor (ISV).

Perimeter network—intranet. Companies commonly use the FTP protocol for Internet-based communications, and therefore you do not need any servers in the intranet perimeter network to support this scenario.

E-Business domain. The servers in this domain are:

BizTalk Server (processing, FTP adapter, and tracking hosts). This server has an installation of the BizTalk Server runtime, and has instances of the hosts that contain the BizTalk orchestrations, pipelines, Business Rule Engine, and other business processes. This is where the BizTalk Server ports, receive locations, pipelines, maps, schemas, and assemblies are located to receive, route, process, and send messages. This server also has a host instance of a host that supports tracking of health monitoring and business monitoring data. Additionally, this host contains instances of the host that runs the FTP send and receive adapters.

Note
As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your processing hosts. For more information about how to configure BizTalk Server for high availability, see the BizTalk Server 2004 Technical Guide for High Availability (http://go.microsoft.com/fwlink/?LinkId=38544).

Master secret server. Same as in the base sample architecture.
SQL Server. Same as in the base sample architecture.
Domain controller. Same as in the base sample architecture.
Administration tools. Same as in the base sample architecture.

Sample Architecture for File Adapter

This section describes the sample architecture when you use the File adapter to send and receive messages.

Architecture Components for File Adapter

The following figure shows the components of the BizTalk Server sample architecture when you use the File adapter.

Note
This sample architecture is also applicable when you use the EDI adapter.

Figure 7 Sample architecture that shows File adapter

This sample architecture contains the following:

Perimeter network—Internet. Companies commonly use the File protocol for intranet-based communications, and therefore you do not need any servers in the Internet perimeter network to support this scenario.
Perimeter network—intranet. When you use the File adapter, there is a File server in the intranet perimeter network. This is the server where your partners drop their messages, and the BizTalk File receive adapter picks up messages from this server.

E-Business domain. The servers in this domain are:

BizTalk Server (processing, File adapter, and tracking hosts). This server has an installation of the BizTalk Server runtime, and has instances of the hosts that contain the BizTalk orchestrations, pipelines, Business Rule Engine, and other business processes. This is where the BizTalk Server ports, receive locations, pipelines, maps, schemas, and assemblies are located to receive, route, process, and send messages. This server also has a host instance of a host that supports tracking of health monitoring and business monitoring data. Additionally, this host contains instances of the host that runs the File send and receive adapters.

Note
As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your processing hosts. For more information about how to configure BizTalk Server for high availability, see the BizTalk Server 2004 Technical Guide for High Availability (http://go.microsoft.com/fwlink/?LinkId=38544).

Master secret server. Same as in the base sample architecture.
SQL Server. Same as in the base sample architecture.
Domain controller. Same as in the base sample architecture.
Administration tools. Same as in the base sample architecture.

Sample Architecture for SQL Adapter

This section describes the sample architecture when you use the SQL adapter to send and receive messages.

Architecture Components for SQL Adapter

The following figure shows the components of the BizTalk Server sample architecture when you use the SQL adapter.

Figure 8 Sample architecture that shows SQL adapter

This sample architecture contains the following:

Perimeter network—Internet. Companies commonly use the SQL adapter for intranet-based communications, and therefore you do not need any servers in the Internet perimeter network to support this scenario.
Perimeter network—intranet. When you use the SQL adapter, there is a SQL Server in the intranet perimeter network. This SQL Server has databases that your employees have access to, and from which the BizTalk SQL receive adapter picks up data.

E-Business domain. The servers in this domain are:

BizTalk Server (processing, SQL adapter, and Tracking hosts). This server has an installation of the BizTalk Server runtime, and has instances of the hosts that contain the BizTalk orchestrations, pipelines, Business Rule Engine, and other business processes. This is where the BizTalk Server ports, receive locations, pipelines, maps, schemas, and assemblies are located to receive, route, process, and send messages. This server also has an instance of a host that supports tracking of health monitoring and business monitoring data. Additionally, this server contains instances of the host that runs the SQL send and receive adapters.

Note
As your performance needs increase, you can add more BizTalk Servers to your environment for host instances of your processing hosts. For more information about how to configure BizTalk Server for high availability, see the BizTalk Server 2004 Technical Guide for High Availability (http://go.microsoft.com/fwlink/?LinkId=38544).

Master secret server. Same as in the base sample architecture.
SQL Server. Same as in the base sample architecture.
Domain controller. Same as in the base sample architecture.
Administration tools. Same as in the base sample architecture.

Threat Model Analysis for Sample Architecture

This section provides the steps and results of a threat model analysis (TMA) for each usage scenario for the sample architecture identified earlier. The purpose of this section is to show you the steps of a TMA. This helps you understand how a TMA works, and describes for you the potential threats we identified for the sample architecture and how we recommend that you reduce their effect.

We categorize the usage scenarios based on the different adapters you can use with Microsoft BizTalk Server 2004, and the use of Enterprise Single-Sign On.

For each scenario, we followed these steps to complete the threat model analysis:

Collect background information
Create and analyze the threat model
Review threats
Identify mitigation techniques and technologies

Background Information for All Scenarios

Before the main threat model meeting, we collected the following background information. This information applies to all the usage scenarios we identified for the sample architecture:

Boundaries and scope of the architecture
Boundaries between trusted and untrusted components
Configuration and administration model for each component
Assumptions about other components and applications

Boundaries and Scope of the Architecture

Firewall 2 helps protect the servers and applications in the E-Business domain both from the perimeter network and from any other domains in your environment (for example, a corporate domain or domains for other applications).
Firewall 2 routes all incoming and outgoing traffic to the E-Business domain.
All user groups and accounts that access the BizTalk Server environment must be global groups in the E-Business domain.
Access is limited to the service account for the host instance; any applications that drop messages in the receive server for File, SQL, or Message Queuing; and administrators for BizTalk Server, Enterprise Single Sign-On (SSO), and Windows.

Boundaries Between Trusted and Untrusted Components

Firewall 2 routes all incoming and outgoing traffic to the E-Business domain.
Use different BizTalk Hosts as a security boundary between applications within BizTalk Server.
Use trusted hosts only when you trust the code within the application (for example, do not run third-party components in a trusted host).

Configuration and Administration Model for Each Component

Configuration model:

BizTalk Server runtime components are installed only on the BizTalk Servers.
Master secret server has no additional components.
SQL Server contains all BizTalk Server databases.
Servers in the perimeter networks do not have any BizTalk Server components.
Administration client is used to administer all servers in the E-Business domain.

Administration model:

From a desktop (or laptop), an administrator connects to the computer that has the administration tools (using either Terminal Services or Remote Desktop connection). After the administrator connects to the computer that has the administration tools, the administrator can use the BizTalk Administration tools to manage all servers and applications within the domain.

Assumptions About Other Components and Applications

All other applications and components that interact with the BizTalk Server environment are in a domain other than the E-Business domain (for example, in a perimeter network). The traffic from those applications and components to and from the BizTalk Server environment goes through Firewall 2.

Any third-party applications for BizTalk Server come from a trusted vendor.

Data Flow Diagrams

The final element of background information for each usage scenario is a data flow diagram (DFD). A DFD illustrates how data flows through the architecture. Each scenario has a different DFD. In this document, the data flow diagrams contain the elements shown in the following figure.

Figure 9 Elements of the DFD

Adapter Scenarios

In our sample architecture, we identified the following usage scenarios based on some of the adapters you can use out-of-the-box:

HTTP and SOAP (Web services) adapters scenario
BizTalk Message Queuing adapter scenario
File adapter scenario
SQL adapter scenario
FTP adapter scenario

For each scenario, we followed these steps to complete the threat model analysis:

Collect background information
Create and analyze the threat model
Review threats
Identify mitigation techniques and technologies

For each scenario, we have tried to develop generic ratings of the level of threat that the various attacks might represent. However, your environment or experience might suggest that a particular threat deserves a different rating than we have given it. As with all security scenarios, your own data is the most robust to determine threat levels, and we recommend that you conduct your own analysis, using our analysis and results as a guide.

The background information—except for the data flow diagram (DFD)—is the same for all our usage scenarios, and is described earlier in "Background Information for all Scenarios." In the following sections we show the DFD for each scenario.

HTTP and SOAP Adapters Scenario

This section presents the threat model analysis (TMA) for the HTTP and SOAP (Web services) adapter scenario for the sample architecture.

The following figure shows the sample architecture for the HTTP and SOAP adapters scenario.

Figure 10 Sample architecture for the HTTP/SOAP adapters scenario

Collect Background Information for HTTP and SOAP Adapters Scenario

This section provides the data flow diagram (DFD) for the HTTP and SOAP (Web services) adapters scenario for the sample architecture.

All the other background information is the same for all our usage scenarios, and is described earlier in "Background Information for all Scenarios."

Data Flow Diagram

The following figure shows the DFD for the sample architecture when you use the HTTP and SOAP (Web services) adapters.

Figure 11 DFD for the sample architecture of the HTTP/SOAP adapters scenario

The data flow is as follows:

A partner or customer sends a message through HTTP, HTTPS, or a Web service. The message is routed to the IP address of Firewall 1.
Firewall 1 relays the message through Firewall 2 using reverse proxy.
Firewall 2 routes the message to the BizTalk Server that runs an instance of an isolated host for the HTTP or SOAP receive adapter. The isolated host processes the message and puts it in the MessageBox database.
An instance of the processing host that has a subscription to the message picks it up from the MessageBox database, does any additional processing, and puts the message back in the MessageBox database.
An instance of the isolated host that has an HTTP or SOAP send adapter picks up the message from the MessageBox database. The message goes through any final processing in the send pipeline, and is sent back out to the partner or customer.
As the message is sent to the partner or customer, it is routed through Firewall 2 and through Firewall 1 using reverse proxy.

Create and Analyze the Threat Model for HTTP and SOAP Adapters Scenario

This section provides the results of the TMA we did for the HTTP and SOAP (Web services) adapters scenario for the sample architecture.

Identify Entry Points, Trust Boundaries, and Flow of Data

See background information described earlier in "Collect Background Information for HTTP and SOAP Adapters Scenario" and "Background Information for all Scenarios."

Create a List of the Identified Threats

We used the following categorization for all entries in the DFD to identify potential threats to the scenario: Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges. The following table lists the threats we identified when you use the HTTP and SOAP adapters to send and receive messages to and from BizTalk Server.

Table 1 List of threats

Threat	Description	Asset	Impact
Send infinite-size message	A malicious user can send a message of infinite size.	BizTalk Server environment	Denial of service
Send lots of messages to receive location	A malicious user can send a large number of valid or invalid messages and flood the application.	BizTalk Server environment	Denial of service
Read message bodies over HTTP	A malicious user can intercept the message as it travels from the sender to Firewall 1, and can read the message.	Message payload	Information disclosure
Read user credentials from message	If you use basic authentication, and the message contains user credentials, a malicious user can gain access to the credentials and use them to access the application.	User credentials	Information disclosure Elevation of privilege

Review Threats for HTTP and SOAP Adapters Scenario

This section provides the results of the risk analysis we did for threats we identified for the HTTP and SOAP (Web services) adapters scenario for the sample architecture. After the main threat model meeting, we reviewed the threats and used the following impact categories to identify the risk for each threat: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.

Rate the Risks

The following table lists the risk ratings for the threats we identified when you use the HTTP and SOAP adapters to send and receive messages to and from BizTalk Server.

Table 2 Risk ratings of threats

Threat	Impact	Damage potential	Reproducibility	Exploitability	Affected users	Discoverability	Risk exposure
Send infinite-size message	Denial of service	2	3	2	3	2	2.4
Send lots of messages to receive location	Denial of service	3	3	1	3	3	2.6
Read message bodies over HTTP	Information disclosure	3	3	2	3	3	2.8
Read user credentials from message	Information disclosure Elevation of privilege	3	3	2	3	2	2.6

Identify Mitigation Techniques for HTTP and SOAP Adapters Scenario

This section presents some mitigation techniques for the threats we identified for the HTTP and SOAP (Web services) adapters scenario for the sample architecture.

Mitigation Techniques

The following table lists mitigation techniques and technologies for the threats we identified when you use the HTTP and SOAP adapters to send and receive messages to and from BizTalk Server.

Table 3 Mitigation techniques and technologies

Threat	Impact	Risk exposure	Mitigation techniques and technologies
Send infinite-size message	Denial of service	2.4	Limit the maximum size of an incoming message per URL and reject messages that exceed that maximum.
Send lots of messages to receive location	Denial of service	2.6	The SOAP adapter takes advantage of HTTP to send and receive messages to and from BizTalk Server. Therefore, you must follow the security recommendations to help secure Internet Information Services (IIS). If you use IIS 6.0, make sure that you follow the IIS 6.0 recommendations on how to configure application isolation. For more information, see the Microsoft TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=25222. If you use IIS 5.0 or 5.1, make sure that you follow the IIS 5.0 recommendations to help secure IIS 5.0. For more information, see the Microsoft TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=24776. Use client authentication and party resolution to limit the number of messages being processed to only those that are valid and authorized.
Read message bodies over HTTP	Information disclosure	2.8	We recommend that you use S/MIME to help secure the content of messages sent to and from BizTalk Server. We recommend that you use Secure Sockets Layer (SSL) to help secure the transmission of data to and from BizTalk Server and between BizTalk Server components distributed across your environment.
Read user credentials from message	Information disclosure Elevation of privilege	2.6	When you use basic authentication, or when you do not use encryption at the message level, we recommend that you use SSL both to receive and send messages to make sure that an unauthorized person cannot read the user credentials.

BizTalk Message Queuing Adapter Scenario

This section presents the threat model analysis (TMA) for the BizTalk Message Queuing adapter scenario for the sample architecture.

The following figure shows the sample architecture for the BizTalk Message Queuing adapter scenario.

Figure 12 Sample architecture for the BizTalk Message Queuing adapter scenario

Collect Background Information for BizTalk Message Queuing Adapter Scenario

This section provides the data flow diagram (DFD) for the BizTalk Message Queuing adapter scenario for the sample architecture.

All the other background information is the same for all our usage scenarios, and is described earlier in "Background Information for all Scenarios."

Data Flow Diagram

The following figure shows the DFD for the sample architecture when you use the BizTalk Message Queuing adapter.

Figure 13 DFD for the sample architecture of the BizTalk Message Queuing adapter scenario

The data flow is as follows:

A partner sends a message using Message Queuing or BizTalk Message Queuing. The message is packed in the appropriate format and sent on the network. If you use Active Directory, the message goes through a series of Message Queuing routers until it reaches the right destination (the BizTalk Server that runs a host instance of the BizTalk Message Queuing receive adapter).
An instance of an in-process host for the BizTalk Message Queuing receive adapter regularly receives the message from a Message Queuing router (through Firewall 2), does any initial processing, sends the correct network responses as defined by the network protocol, and puts the message in the MessageBox database.
An instance of the processing host that has a subscription to the message picks it up from the MessageBox database, does any additional processing, and puts the message back in the MessageBox database.
An instance of the in-process host that has a BizTalk Message Queuing send adapter picks up the message from the MessageBox database. The message goes through any final processing in the send pipeline, and is then sent through Firewall 2 over the network to the partner or application.

Create and Analyze the Threat Model for BizTalk Message Queuing Adapter Scenario

This section provides the results of the TMA we did for the BizTalk Message Queuing adapter scenario for the sample architecture.

Identify Entry Points, Trust Boundaries, and Flow of Data

See background information described earlier in "Collect Background Information for BizTalk Message Queuing Adapter Scenario" and "Background Information for all Scenarios."

Create a List of the Identified Threats

We used the following categorization for all entries in the DFD to identify potential threats to the scenario: Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges. The following table lists the threats we identified when you use the BizTalk Message Queuing adapter to send and receive messages to and from BizTalk Server.

Table 4 List of identified threats

Threat	Description	Asset	Impact
Send lots of messages to receive location	A malicious user can send a large number of valid or invalid messages and flood the application.	BizTalk Server environment	Denial of service
Message header travels in the clear on the wire	As the message travels from the queue to the BizTalk Message Queuing receive adapter, the message header is in the clear, and a malicious user can potentially read and tamper with the header.	Message header	Tampering with data Information disclosure
An unauthorized user can make a network connection to the BizTalk Server that runs the BizTalk Message Queuing host	You cannot use a discretionary access list (DACL) to restrict access to the BizTalk Message Queuing receive location. Therefore, anyone that can make a network connection to the BizTalk Server that runs a host instance of the BizTalk Message Queuing receive adapter and to port 1801 can send messages to the BizTalk Message Queuing receive location.	BizTalk Server environment	Repudiation Tampering with data Information disclosure Denial of service Elevation of privileges
A malicious user can tamper with the message before BizTalk Server receives it	A malicious user can intercept the message while it is in transit and modify it.	Message body	Tampering with data Information disclosure

Review Threats for BizTalk Message Queuing Adapter Scenario

This section provides the results of the risk analysis we did for threats we identified for the BizTalk Message Queuing adapter scenario for the sample architecture. After the main threat model meeting, we reviewed the threats and used the following impact categories to identify the risk for each threat: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.

Rate the Risks

The following table lists the risk ratings for the threats we identified when you use the BizTalk Message Queuing adapter to send and receive messages to and from BizTalk Server.

Table 5 Risk ratings for identified threats

Threat	Impact	Damage potential	Reproducibility	Exploitability	Affected users	Discoverability	Risk exposure
Send lots of messages to receive location	Denial of service	8	7	7	7	5	6.8
Message header travels in the clear on the wire	Tampering with data Information disclosure	8	10	8	3	5	6.8
An unauthorized user can make a network connection to the BizTalk Server that runs the BizTalk Message Queuing host	Repudiation Tampering with data Information disclosure Denial of service Elevation of privileges	8	10	9	9	9	9
A malicious user can tamper with the message before BizTalk Server receives it	Tampering with data Information disclosure	5	7	6	5	7	6

Identify Mitigation Techniques for BizTalk Message Queuing Adapter Scenario

This section presents some mitigation techniques for the threats we identified for the BizTalk Message Queuing adapter scenario for the sample architecture.

Mitigation Techniques

The following table lists mitigation techniques and technologies for the threats we identified when you use the BizTalk Message Queuing adapter to send and receive messages to and from BizTalk Server.

Table 6 Mitigation techniques and technologies

Threat	Impact	Risk exposure	Mitigation techniques and technologies
Send lots of messages to receive location	Denial of service	6.8	Use the BizTalk Message Queuing adapter in authentication-required mode. Set the Requires MSMQ authentication flag on the receive location and AuthenticationRequired (Drop messages) on the receive port to true. Configure BizTalk Message Queuing to require certificate-based authentication. This behavior occurs at the adapter level, and is different from the Party Resolution component of a BizTalk pipeline. If configured, the public certificate is included with the incoming message. This is the only client authentication mode available for BizTalk Message Queuing. To use this client authentication mode, you must install BizTalk Message Queuing with Active Directory Integration Mode. When you use this feature, remember to select the Require Authentication check box on the property dialog box for the BizTalk Message Queuing receive location.
Message header travels in the clear on the wire	Tampering with data Information disclosure	6.8	Use Internet Protocol security (IPsec) to help protect the message body and the message header as it travels from one server to another.
An unauthorized user can make a network connection to the BizTalk Server that runs the BizTalk Message Queuing host	Repudiation Tampering with data Information disclosure Denial of service Elevation of privileges	9	Create a custom pipeline with a Party Resolution pipeline component, and then configure the Party Resolution component to use the Sender ID (SID) to resolve the party. Set the Resolve Party By Certificate property to False, and the Resolve Party By SID property to True. For more information, see "Configuring the Party Resolution Pipeline Component" in BizTalk Server 2004 Help. On the receive port, set the Authentication property to Required (Drop Messages).
A malicious user can tamper with the message before BizTalk Server receives it	Tampering with data Information disclosure	6	Use protocol-level authentication to make sure the message was not tampered with while in transit. To use protocol-level authentication, you must have a Message Queuing router in the E-Business domain. Configure BizTalk Server as follows: On the BizTalk Messaging page of the Configuration Wizard, provide the name of the router. For the receive port, set the Authentication property to Required (Drop Messages) or Required (Keep Messages). For the send handler, on the General tab, in the MSMQ Router name box, type the name of the Message Queuing router. For the send port, select Use MSMQ Authentication.

File Adapter Scenario

This section presents the threat model analysis (TMA) for the File adapter scenario for the sample architecture.

The following figure shows the sample architecture for the File adapter scenario.

Figure 14 Sample architecture for the File adapter scenario

Collect Background Information for File Adapter Scenario

This section provides the data flow diagram (DFD) for the File adapter scenario for the sample architecture.

All the other background information is the same for all our usage scenarios, and is described earlier in "Background Information for all Scenarios."

Data Flow Diagram

The following figure shows the DFD for the sample architecture when you use the File adapter.

Figure 15 DFD for the sample architecture of the File adapter scenario

The data flow is as follows:

A partner puts a message (through Firewall 1) in the File server in the intranet perimeter network.
An instance of an in-process host for the File receive adapter regularly polls the File server for new messages (through Firewall 2). After it finds a new message, it retrieves the message, does any initial processing, and puts the message in the MessageBox database.
An instance of the processing host that has a subscription to the message picks it up from the MessageBox database, does any additional processing, and puts the message back in the MessageBox database.
An instance of the in-process host that has a File send adapter picks up the message from the MessageBox database. The message goes through any final processing in the send pipeline, and is then sent through Firewall 2 to the File server.
The partner picks up the message from the File server.

Create and Analyze the Threat Model for File Adapter Scenario

This section provides the results of the TMA we did for the File adapter scenario for the sample architecture.

Identify Entry Points, Trust Boundaries, and Flow of Data

See background information described earlier in "Collect Background Information for File Adapter Scenario" and "Background Information for all Scenarios."

Create a List of the Identified Threats

We used the following categorization for all entries in the DFD to identify potential threats to the scenario: Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges. The following table lists the threats we identified when you use the File adapter to send and receive messages to and from BizTalk Server.

Table 7 List of identified threats

Threat	Description	Asset	Impact
Unauthorized user can retrieve messages from file drop folder	If you have not set strong discretionary access lists (DACLs) for the folders that the File adapter uses, an unauthorized user can drop messages in the file receive location, or pick up messages from the file send location.	Message body	Tampering with data Information disclosure
Unauthorized user can submit messages to BizTalk Server	If a user has write permissions to the file folder from which BizTalk Server picks up messages, an unauthorized user can submit messages to BizTalk Server.	Message body	Denial of service Elevation of privileges

Threat

Description

Asset

Impact

Unauthorized user can retrieve messages from file drop folder

If you have not set strong discretionary access lists (DACLs) for the folders that the File adapter uses, an unauthorized user can drop messages in the file receive location, or pick up messages from the file send location.

Message body

Tampering with data

Information disclosure

Unauthorized user can submit messages to BizTalk Server

If a user has write permissions to the file folder from which BizTalk Server picks up messages, an unauthorized user can submit messages to BizTalk Server.

Message body

Denial of service

Elevation of privileges

Review Threats for File Adapter Scenario

This section provides the results of the risk analysis we did for threats we identified for the File adapter scenario for the sample architecture. After the main threat model meeting, we reviewed the threats and used the following impact categories to identify the risk for each threat: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.

Rate the Risks

The following table lists the risk ratings for the threats we identified when you use the File adapter to send and receive messages to and from BizTalk Server.

Table 8 Risk ratings for identified threats

Threat	Impact	Damage potential	Reproducibility	Exploitability	Affected users	Discoverability	Risk exposure
Unauthorized user can retrieve messages from file drop folder	Tampering with data Information disclosure	4	7	5	4	6	5.2
Unauthorized user can submit messages to BizTalk Server	Denial of service Elevation of privileges	4	7	5	4	5	5.2

Threat

Impact

Damage potential

Reproducibility

Exploitability

Affected users

Discoverability

Risk exposure

Unauthorized user can retrieve messages from file drop folder

Tampering with data

Information disclosure

5.2

Unauthorized user can submit messages to BizTalk Server

Denial of service

Elevation of privileges

5.2

Identify Mitigation Techniques for File Adapter Scenario

This section presents some mitigation techniques for the threats we identified for the File adapter scenario for the sample architecture.

Mitigation Techniques

The following table lists mitigation techniques and technologies for the threats we identified when you use the File adapter to send and receive messages to and from BizTalk Server.

Table 9 Mitigation techniques and technologies

Threat	Impact	Risk exposure	Mitigation techniques and technologies
Unauthorized user can retrieve messages from file drop folder	Tampering with data Information disclosure	5.2	For the folder from which BizTalk Server picks up messages, use a strong discretionary access list (DACL) as follows: For the service account for the host instance for the host that runs the receive adapter, set read, write, delete files, and delete subfolders and files permissions to the directory from which the file receive location picks up messages. For the external user or application that drops files to this folder, set write permissions. For the BizTalk Administrators group, set full control. For the folder to which BizTalk Server drops messages, use a strong DACL as follows: For the service account for the host instance for the host that runs the send adapter, set write permissions. For the external user or application that drops files to this folder, set read permissions. For the BizTalk Administrators group, set full control.
Unauthorized user can submit messages to BizTalk Server	Denial of service Elevation of privileges	5.2	Set strong DACLs in the receive location drop directories as indicated earlier.

Threat

Impact

Risk exposure

Mitigation techniques and technologies

Unauthorized user can retrieve messages from file drop folder

Tampering with data

Information disclosure

5.2

For the folder from which BizTalk Server picks up messages, use a strong discretionary access list (DACL) as follows:

For the service account for the host instance for the host that runs the receive adapter, set read, write, delete files, and delete subfolders and files permissions to the directory from which the file receive location picks up messages.
For the external user or application that drops files to this folder, set write permissions.
For the BizTalk Administrators group, set full control.

For the folder to which BizTalk Server drops messages, use a strong DACL as follows:

For the service account for the host instance for the host that runs the send adapter, set write permissions.
For the external user or application that drops files to this folder, set read permissions.
For the BizTalk Administrators group, set full control.

Unauthorized user can submit messages to BizTalk Server

Denial of service

Elevation of privileges

5.2

Set strong DACLs in the receive location drop directories as indicated earlier.

SQL Adapter Scenario

This section presents the threat model analysis (TMA) for the SQL adapter scenario for the sample architecture.

The following figure shows the sample architecture for the SQL adapter scenario.

Figure 16 Sample architecture for the SQL adapter scenario

Collect Background Information for SQL Adapter Scenario

This section provides the data flow diagram (DFD) for the SQL adapter scenario for the sample architecture.

All the other background information is the same for all our usage scenarios, and is described earlier in "Background Information for all Scenarios."

Data Flow Diagram

The following figure shows the DFD for the sample architecture when you use the SQL adapter.

Figure 17 DFD for the sample architecture of the SQL adapter scenario

The data flow is as follows:

A partner or employee accesses the SQL Server in the intranet perimeter network (through Firewall 1) to modify fields in a database.
An instance of an in-process host for the SQL receive adapter periodically polls for SQL result sets as configured in the SQL receive location (through Firewall 2). After it finds a new result set, it retrieves the data, does any initial processing, and puts a message with this data in the MessageBox database.
An instance of the processing host that has a subscription to the message picks it up from the MessageBox database, does any additional processing, and puts the message back in the MessageBox database.
An instance of the in-process host that has a SQL send adapter picks up the message from the MessageBox database. The message goes through any final processing in the send pipeline, and is then sent through Firewall 2 to the SQL Server in the intranet perimeter network.
The partner or employee reviews the updated data in the SQL Server.

Create and Analyze the Threat Model for SQL Adapter Scenario

This section provides the results of the TMA we did for the SQL adapter scenario for the sample architecture.

Identify Entry Points, Trust Boundaries, and Flow of Data

See background information described earlier in "Collect Background Information for SQL Adapter Scenario" and "Background Information for all Scenarios."

Create a List of the Identified Threats

We used the following categorization for all entries in the DFD to identify potential threats to the scenario: Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges. The following table lists the threats we identified when you use the SQL adapter to send and receive messages to and from BizTalk Server.

Table 10 List of identified threats

Threat	Description	Asset	Impact
A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa	The communication between the SQL adapter and the SQL Server is in clear text.	Message body	Spoofing identity Tampering with data

Threat

Description

Asset

Impact

A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa

The communication between the SQL adapter and the SQL Server is in clear text.

Message body

Spoofing identity

Tampering with data

Review Threats for SQL Adapter Scenario

This section provides the results of the risk analysis we did for threats we identified for the SQL adapter scenario for the sample architecture. After the main threat model meeting, we reviewed the threats and used the used the following impact categories to identify the risk for each threat: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.

Rate the Risks

The following table lists the risk ratings for the threats we identified when you use the SQL adapter to send and receive messages to and from BizTalk Server.

Table 11 Risk rating of identified threats

Threat	Impact	Damage potential	Reproducibility	Exploitability	Affected users	Discoverability	Risk exposure
A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa	Spoofing identity Tampering with data	8	10	8	3	5	6.8

Threat

Impact

Damage potential

Reproducibility

Exploitability

Affected users

Discoverability

Risk exposure

A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa

Spoofing identity

Tampering with data

6.8

Identify Mitigation Techniques for SQL Adapter Scenario

This section presents some mitigation techniques for the threats we identified for the SQL adapter scenario for the sample architecture.

Mitigation Techniques

The following table lists mitigation techniques and technologies for the threats we identified when you use the SQL adapter to send and receive messages to and from BizTalk Server.

Table 12 Mitigation techniques and technologies

Threat	Impact	Risk exposure	Mitigation techniques and technologies
A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa	Spoofing identity Tampering with data	6.8	Use Internet Protocol security (IPsec) to help protect the message as it travels from one server to another.

Threat

Impact

Risk exposure

Mitigation techniques and technologies

A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa

Spoofing identity

Tampering with data

6.8

Use Internet Protocol security (IPsec) to help protect the message as it travels from one server to another.

FTP Adapter Scenario

This section presents the threat model analysis (TMA) for the FTP adapter scenario for the sample architecture.

The following figure shows the sample architecture for the FTP adapter scenario.

Figure 18 Sample architecture for the FTP adapter scenario

Collect Background Information for FTP Adapter Scenario

This section provides the data flow diagram (DFD) for the FTP adapter scenario for the sample architecture.

All the other background information is the same for all our usage scenarios, and is described earlier in "Background Information for all Scenarios."

Data Flow Diagram

The following figure shows the DFD for the sample architecture when you use the FTP adapter.

Figure 19 DFD for the sample architecture of the FTP adapter scenario

The data flow is as follows:

A partner or customer sends a message to the FTP server. The message is routed to the IP address of Firewall 1.
Firewall 1 receives the message, and routes it to the FTP server located in the Internet perimeter network.
An instance of an in-process host for the FTP receive adapter regularly polls the FTP server for new messages (through Firewall 2). After it finds a new message, it retrieves the message, does any initial processing, and puts the message in the MessageBox database.
An instance of the processing host that has a subscription to the message picks it up from the MessageBox database, does any additional processing, and puts the message back in the MessageBox database.
An instance of the in-process host that has an FTP send adapter picks up the message from the MessageBox database. The message goes through any final processing in the send pipeline, and is then sent through Firewall 2 to the FTP server.
The FTP server then routes the message through Firewall 1 back to the partner or customer.

Create and Analyze the Threat Model for FTP Adapter Scenario

This section provides the results of the TMA we did for the FTP adapter scenario for the sample architecture.

Identify Entry Points, Trust Boundaries, and Flow of Data

See background information described earlier in "Collect Background Information for FTP Adapter Scenario" and "Background Information for all Scenarios."

Create a List of the Identified Threats

We used the following categorization for all entries in the DFD to identify potential threats to the scenario: Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges. The following table lists the threats we identified when you use the FTP adapter to send and receive messages to and from BizTalk Server.

Table 13 List of identified threats

Threat	Description	Asset	Impact
FTP protocol is not secure	FTP protocol user ID and password are sent as clear text. A malicious user can monitor the network to access credentials. Data is exposed.	User credentials	Spoofing identity Tampering with data Information disclosure
FTP server is vulnerable to unauthorized DHCP server attacks	If the URI does not contain the password of the user but it is specified on the handler, at run time the password from the handler is currently sent to the FTP server. If there is a rogue FTP server listening for authentication calls, it might steal passwords in this way. One solution is to enable/disable using the password at the handler level.	FTP server	Spoofing identity Tampering with data Information disclosure

Threat

Description

Asset

Impact

FTP protocol is not secure

FTP protocol user ID and password are sent as clear text. A malicious user can monitor the network to access credentials. Data is exposed.

User credentials

Spoofing identity

Tampering with data

Information disclosure

FTP server is vulnerable to unauthorized DHCP server attacks

If the URI does not contain the password of the user but it is specified on the handler, at run time the password from the handler is currently sent to the FTP server. If there is a rogue FTP server listening for authentication calls, it might steal passwords in this way. One solution is to enable/disable using the password at the handler level.

FTP server

Spoofing identity

Tampering with data

Information disclosure

Review Threats for FTP Adapter Scenario

This section provides the results of the risk analysis we did for threats we identified for the FTP adapter scenario for the sample architecture. After the main threat model meeting, we reviewed the threats and used the used the following impact categories to identify the risk for each threat: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.

Rate the Risks

The following table lists the risk ratings for the threats we identified when you use the FTP adapter to send and receive messages to and from BizTalk Server.

Table 14 Risk ratings for identified threats

Threat	Impact	Damage potential	Reproducibility	Exploitability	Affected users	Discoverability	Risk exposure
FTP protocol is not secure	Spoofing identity Tampering with data Information disclosure	9	9	2	10	5	7
FTP server is vulnerable to unauthorized DHCP server attacks	Spoofing identity Tampering with data Information disclosure	5	5	2	10	5	5.4

Threat

Impact

Damage potential

Reproducibility

Exploitability

Affected users

Discoverability

Risk exposure

FTP protocol is not secure

Spoofing identity

Tampering with data

Information disclosure

FTP server is vulnerable to unauthorized DHCP server attacks

Spoofing identity

Tampering with data

Information disclosure

5.4

Identify Mitigation Techniques for FTP Adapter Scenario

This section presents some mitigation techniques for the threats we identified for the FTP adapter scenario for the sample architecture.

Mitigation Techniques

The following table lists mitigation techniques and technologies for the threats we identified when you use the FTP adapter to send and receive messages to and from BizTalk Server.

Table 15 Mitigation techniques and technologies

Threat	Impact	Risk exposure	Mitigation techniques and technologies
FTP protocol is not secure	Spoofing identity Tampering with data Information disclosure	7	The FTP adapter must be used within a secure environment and over a secure line.
FTP server is vulnerable to unauthorized DHCP server attacks	Spoofing identity Tampering with data Information disclosure	5.4	We recommend that you put the remote FTP server in a secure location. You must ensure the physical and network security of this server to minimize unauthorized DHCP server attacks.

Threat

Impact

Risk exposure

Mitigation techniques and technologies

FTP protocol is not secure

Spoofing identity

Tampering with data

Information disclosure

The FTP adapter must be used within a secure environment and over a secure line.

FTP server is vulnerable to unauthorized DHCP server attacks

Spoofing identity

Tampering with data

Information disclosure

5.4

We recommend that you put the remote FTP server in a secure location. You must ensure the physical and network security of this server to minimize unauthorized DHCP server attacks.

Enterprise Single Sign-On Scenario

This section presents the threat model analysis (TMA) for the Enterprise Single Sign-On scenario for the sample architecture.

The following figure shows the base sample architecture, which includes the Enterprise Single Sign-On scenario.

Figure 20 Base sample architecture that includes the Enterprise Single Sign-On scenario

Collect Background Information for Enterprise Single Sign-On Scenario

This section provides the data flow diagram (DFD) for using the Enterprise Single Sign-On scenario when you map Windows credentials to the credentials you use to connect to a back-end network.

All the other background information is the same for all our usage scenarios, and is described earlier in "Background Information for all Scenarios."

Data Flow Diagram

The following figure shows the DFD for the Enterprise Single Sign-On scenario.

Figure 21 DFD for the Enterprise Single Sign-On scenario

The data flow is as follows:

The user or application logs on with Windows credentials.
Enterprise Single Sign-On uses the Windows credentials to request the credentials for the back-end network.
Enterprise Single Sign-On maps the Windows credentials to the back-end credentials stored in the Credential database.
Enterprise Single Sign-On retrieves the back-end credentials, and uses them to connect the user or application to the back-end network.

Create and Analyze the Threat Model for Enterprise Single Sign-On Scenario

This section provides the results of the TMA we did for the Enterprise Single Sign-On scenario for the sample architecture.

Identify Entry Points, Trust Boundaries, and Flow of Data

See background information described earlier in "Collect Background Information for Enterprise Single Sign-On Scenario" and "Background Information for all Scenarios."

Create a List of the Identified Threats

We used the following categorization for all entries in the DFD to identify potential threats to the scenario: Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges. The following table lists the threats we identified when you use Enterprise Single Sign-On (SSO) to send and receive messages to and from BizTalk Server.

Table 16 List of identified threats

Threat	Description	Asset	Impact
Master secret server is a single point of failure	If a malicious user compromises the master secret server, the SSO computer is unable to encrypt credentials (it is able to continue decrypting credentials).	BizTalk and SSO environment	Denial of service
A malicious user can spoof a client or server	If a client or server runs Windows without NTLM authentication, a malicious user can spoof the client or server.	BizTalk and SSO environment	Spoofing identity Tampering with data Repudiation Information disclosure Denial of service Elevation of privileges
A malicious user can tamper with the data as it travels from one server to another	The communication between servers is in clear text, and a malicious user can potentially read the data as it travels.	Data	Tampering with data Information disclosure

Threat

Description

Asset

Impact

Master secret server is a single point of failure

If a malicious user compromises the master secret server, the SSO computer is unable to encrypt credentials (it is able to continue decrypting credentials).

BizTalk and SSO environment

Denial of service

A malicious user can spoof a client or server

If a client or server runs Windows without NTLM authentication, a malicious user can spoof the client or server.

BizTalk and SSO environment

Spoofing identity

Tampering with data

Repudiation

Information disclosure

Denial of service

Elevation of privileges

A malicious user can tamper with the data as it travels from one server to another

The communication between servers is in clear text, and a malicious user can potentially read the data as it travels.

Data

Tampering with data

Information disclosure

Review Threats for Enterprise Single Sign-On Scenario

This section provides the results of the risk analysis we did for threats we identified for the Enterprise Single Sign-On (SSO) scenario for the reference architecture. After the main threat model meeting, we reviewed the threats and used the used the following impact categories to identify the risk for each threat: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.

Rate the Risks

The following table lists the risk ratings for the threats we identified when you use Enterprise Single Sign-On to send and receive messages to and from BizTalk Server.

Table 18 Risk rating of identified threats

Threat	Impact	Damage potential	Reproducibility	Exploitability	Affected users	Discoverability	Risk exposure
Master secret server is a single point of failure	Denial of service	2	3	2	1	2	2
A malicious user can spoof a client or server	Spoofing identity Tampering with data Repudiation Information disclosure Denial of service Elevation of privileges	3	2	2	2	1	2
A malicious user can tamper with the data as it travels from one server to another	Tampering with data Information disclosure	3	1	1	2	1	1.6

Threat

Impact

Damage potential

Reproducibility

Exploitability

Affected users

Discoverability

Risk exposure

Master secret server is a single point of failure

Denial of service

A malicious user can spoof a client or server

Spoofing identity

Tampering with data

Repudiation

Information disclosure

Denial of service

Elevation of privileges

A malicious user can tamper with the data as it travels from one server to another

Tampering with data

Information disclosure

1.6

Identify Mitigation Techniques for Enterprise Single Sign-On Scenario

This section presents some mitigation techniques for the threats we identified for the Enterprise Single Sign-On scenario for the sample architecture.

Mitigation Techniques

The following table lists mitigation techniques and technologies for the threats we identified when you use Enterprise Single Sign-On.

Table 17 Mitigation techniques and technologies

Threat	Impact	Risk exposure	Mitigation techniques and technologies
Master secret server is a single point of failure	Denial of service	2	Use an active-passive cluster configuration for the master secret server. For more information about clustering the master secret server, see "Clustering the Master Secret Server" in BizTalk Server 2004 Help.
A malicious user can spoof a client or server	Spoofing identity Tampering with data Repudiation Information disclosure Denial of service Elevation of privileges	2	If your network supports Kerberos authentication, you should register all SSO servers. When you use Kerberos authentication between the master secret server and the Credential database, you must configure Service Principal Names (SPN) on the SQL Server where the Credential database is located. For more information about how to configure Service Principal Names, see the Microsoft Download Web site at http://go.microsoft.com/fwlink/?LinkId=20797.
A malicious user can tamper with the data as it travels from one server to another	Tampering with data Information disclosure	1.6	Use Internet Protocol security (IPsec) or Secure Sockets Layer (SSL) between all the SSO servers and the Credential database. For more information about SSL, see the Microsoft Help and Support Web site at http://go.microsoft.com/fwlink/?LinkId=16731. For more information about how to use SSL between all the SSO servers and the Credential database, see "Enabling SSL for Enterprise Single Sign-On" in BizTalk Server 2004 Help.

Threat

Impact

Risk exposure

Mitigation techniques and technologies

Master secret server is a single point of failure

Denial of service

Use an active-passive cluster configuration for the master secret server. For more information about clustering the master secret server, see "Clustering the Master Secret Server" in BizTalk Server 2004 Help.

A malicious user can spoof a client or server

Spoofing identity

Tampering with data

Repudiation

Information disclosure

Denial of service

Elevation of privileges

If your network supports Kerberos authentication, you should register all SSO servers. When you use Kerberos authentication between the master secret server and the Credential database, you must configure Service Principal Names (SPN) on the SQL Server where the Credential database is located. For more information about how to configure Service Principal Names, see the Microsoft Download Web site at http://go.microsoft.com/fwlink/?LinkId=20797.

A malicious user can tamper with the data as it travels from one server to another

Tampering with data

Information disclosure

1.6

Use Internet Protocol security (IPsec) or Secure Sockets Layer (SSL) between all the SSO servers and the Credential database. For more information about SSL, see the Microsoft Help and Support Web site at http://go.microsoft.com/fwlink/?LinkId=16731. For more information about how to use SSL between all the SSO servers and the Credential database, see "Enabling SSL for Enterprise Single Sign-On" in BizTalk Server 2004 Help.

Best Practices

This section provides some recommendations and best practices when you work to secure your Microsoft BizTalk Server 2004 environment.

Evaluate Security from Multiple Angles

To maximize the protection of your environment, you must take a multistep approach. You must address your network environment, address communications with customers and partners, and educate end users about security best practices. The following list presents some actions that you might take:

Protect the network environment
- Apply the "defense in depth" philosophy to help protect critical computers, applications, and data
- Keep all computers and applications up-to-date with software updates
- Run only the services you need
- Enforce the use of strong passwords
Protect communications with customers and partners
- Protect in-transit messages from being read and tampered with by malicious users
Educate end users about security best practices
- Use strong passwords
- Do not run with administration user rights
- Run only the services you need
- Keep all client computers up-to-date with software updates
- Do not share security information with others ("social hacking")

As you can see, the best way to help protect your environment is to include security in all aspects of your environment and throughout the product life cycle. When you do this, you can avoid some malicious attacks and, if an attack occurs, you can minimize or contain its effect.

Do a Threat Model Analysis

A threat model analysis (TMA) can help you identify the threats your environment might be exposed to, how to fix them, and how important it is to fix them.

Review Best Practices for a BizTalk Server Environment

In BizTalk Server 2004 Help, "Security Recommendations for a BizTalk Server Deployment" provides best practices for how to secure your BizTalk Server environment, and "Security Recommendations for BizTalk Server Components" provides additional deployment and security recommendations for each BizTalk Server component.

Sample Solution

This section contains a sample solution that illustrates some things that you have to think about when you design your Microsoft BizTalk Server 2004 implementation. This section shows the sample architecture and how to implement the sample solution with Internet Protocol security (IPsec).

The sample addresses a common business problem: "How do I architect a secure application that uses BizTalk Server?" The application starts with a user that sends an order to BizTalk Server for processing. BizTalk Server, in turn, communicates with Microsoft SQL Server to post information and to retrieve information about the order. BizTalk Server then sends a confirmation to the user through the sample application.

This sample is relevant to the subject of this document because of the steps that we took to help reduce the effect of the security risks we identified in the threat model analysis for the sample. For example, we implemented IPsec among all the computers to make sure that certain computers are accessible by only a limited number of other computers. You will also see how to set up specific Active Directory accounts that BizTalk Server uses.

The following sections provide detailed information about the architecture of the sample solution, and instructions on how to configure it. One section documents a threat model analysis that we performed on the sample architecture and how we reduced the effect of the threats identified.

Architecture

This section describes the architecture for the security sample application that is included with this document.

Architecture Overview

The following figure is a high-level view of the sample architecture. The sample is made up of four computers. Three of these computers would typically be server-class computers in a production environment. The last computer would typically be a workstation-class computer in a production environment.

Figure 22 High-level view of four-computer sample

The following paragraphs describe the computers and how they work together.

Domain Controller

This computer hosts the domain controller for the Contoso domain. The domain controller maintains the group, user, and access information that we used in the security sample. The domain controller also enforces the IPsec rules that we created in the sample configuration.

Note
In this sample architecture, the application computer, which would be past the intranet perimeter network, shares the domain controller (and Active Directory) with the BizTalk Server and the SQL Server. In a production environment, we recommend that the client computer be on a different domain.

For more information about how to secure your domain controller, see Chapter 4 of the Windows Server 2003 Security Guide (http://go.microsoft.com/fwlink/?LinkId=45295)

SQL Server

This computer hosts Microsoft SQL Server and its databases. It contains the BizTalk configuration and data databases and the business data for the sample application.

For more information about how to secure SQL Server, see SQL Server 2000 SP3 Security Features and Best Practices: Security Best Practices Checklist (http://go.microsoft.com/fwlink/?LinkId=45296)

BizTalk Server

This computer hosts Microsoft BizTalk Server 2004 and the master secret server. BizTalk Server processes the order received from the application and sends the confirmation to the predetermined Message Queuing (also known as MSMQ) message queue.

For more information about how to secure Internet Information Services, which runs on the BizTalk Server computer when you use HTTP or SOAP, see Checklist: Securing your Web Server (http://go.microsoft.com/fwlink/?LinkId=45294) and Chapter 8 of the Windows Server 2003 Security Guide (http://go.microsoft.com/fwlink/?LinkId=45295)

Application Computer

This computer hosts the test application and the Message Queuing message queue. To start the security sample, you run a sample application from this computer to send an order to BizTalk Server for processing.

Prerequisites

The security sample is made up of four different computers, and each computer plays an integral part in the overall sample. This section describes the hardware and software prerequisites for each computer. The sample was created and tested using Microsoft Windows Server 2003 Standard Edition as the operating system for each computer.

Domain Controller

The recommended requirements for the domain controller computer are:

550 MHz CPU
256 MB RAM
2+ GB of hard disk space
Windows Server 2003 operating system

SQL Server

The recommended requirements for the Microsoft SQL Server computer are:

550 MHz CPU
256 MB RAM
4 GB of hard disk space
Windows Server 2003 operating system
Microsoft SQL Server 2000 with the latest service packs

BizTalk Server 2004

The recommended requirements for the Microsoft BizTalk Server computer are:

450 MHz CPU
512 MB RAM
6 GB of hard disk space
Windows Server 2003 operating system
Microsoft BizTalk Server 2004 and its prerequisite software

Application Client

The recommended requirements for the application client computer are:

450 MHz CPU
512 MB RAM
2 GB of hard disk space
Windows Server 2003 operating system
Microsoft Message Queuing

Threat Model Analysis for the Sample Application

This section provides the steps and results of a threat model analysis (TMA) done for the sample application. It outlines how a TMA works, describes the potential threats we identified in the sample application, and also describes how we mitigated those threats.

Collect Background Information

Before the main threat model meeting, we collected the following background information about our sample application:

Usage scenarios
Data flow diagrams (DFDs)
Boundaries and scope of the application
Boundaries between trusted and untrusted components
Configuration and administration model for the components
Assumptions about other components and applications

Usage Scenarios

The sample depicts a Point of Sale (PoS) application in which a salesperson from Contoso requests inventory items for the store. The salesperson uses a custom application to submit the request for items. The application then submits the request to Microsoft BizTalk Server, where the appropriate orchestration processes the order. BizTalk Server updates the Microsoft SQL Server database that contains business data with the requested information; it does a warehouse inventory check, and then submits an acknowledgement and inventory status back to the salesperson.

This PoS application is used in an intranet environment, and salespeople and managers have access to it. For our sample, the PoS application only has users; administrators have not been defined. Therefore, no user group needs special permissions for BizTalk Server. The users of the PoS application need permissions to put messages in Message Queuing (also known as MSMQ).

We created the user group accounts and individual group accounts in Active Directory.

Data Flow Diagrams

The following figure shows the Level 0 DFD for the sample application.

Figure 23 Level 0 DFD for the sample application

The following figure shows the Level 1 DFD for the sample application.

Figure 24 Level 1 DFD for the sample application

The data flow is as follows:

The salesperson uses a fixed form within the PoS application to choose the number of items to order (inventory request).
The PoS application transforms the fixed form into an XML document. It then sends the XML document to BizTalk Server by using the BizTalk Message Queuing (also known as MSMQT) receive adapter.
After the receive adapter does the initial processing of the message, it puts the message in the MessageBox database. A BizTalk orchestration that has the right subscription picks up the message, processes it, and puts it back in the MessageBox database.
The SQL send adapter then picks up the message and sends it to a stored procedure in the SQL Server database with the business data. The stored procedure enters the data into a database table and sends the message back to the SQL receive adapter. The receive adapter puts the document back in the MessageBox database.
The BizTalk Message Queuing send adapter picks up the message from the MessageBox database, gets it ready to send out, and puts it in the Message Queuing queue that the PoS application uses.
The PoS application picks up the message and displays the acknowledgement to the salesperson.

Boundaries and Scope of the Application

This sample PoS application is used in an intranet environment, and salespeople and managers have access to it.
At this point, only one user at a time can use the application.
The sample application retrieves business data from the business data database.
The sample application is not connected to the Internet.
Only users who have a valid account in the domain can use the sample application.

Boundaries Between Trusted and Untrusted Components

To create boundaries, we followed these recommendations:

Use different hosts as a security boundary between applications within BizTalk Server.
Use Internet Protocol security (IPsec) to restrict communication between servers.

If you use this sample to guide you when you develop your own environment, you should use a firewall to restrict access from the application server to the BizTalk Server computer and the databases.

Configuration and Administration Model for the Component

Configuration

Install only the BizTalk Server runtime, the master secret server, and the administration tools on the BizTalk Server computer. There are no development tools on this computer.
The server that contains the sample PoS application does not have any BizTalk Server components.
The computer that runs SQL Server contains both the business data database and the BizTalk Server databases.
Do not use the default names for the BizTalk Server group accounts and services accounts.
Do not use the default names for the BizTalk Server hosts.
Create a host for the BizTalk Message Queuing adapter (in-process host), a host for the SQL adapter (in-process), a host for processing (in-process), and a host for tracking (in-process).

Administration

Administrators can connect to the BizTalk Server to administer the BizTalk Server components and services.

Assumptions About Other Components and Applications

This issue is not applicable; this is a stand-alone application.

Create and Analyze the Threat Model

This section describes the key steps and findings from the threat model meeting.

Identify Entry Points, Trust Boundaries, and Flow of Data

At the beginning of the meeting, we reviewed the background information we collected prior to the meeting, and identified the entry points, trust boundaries, and the flow of data.

Entry points

PoS application
Message Queuing

Trust boundaries

See "Boundaries and Scope of the Application" in the previous topic.
See "Boundaries Between Trusted and Untrusted Components" in the previous topic.

Flow of data

See "Data Flow Diagrams" in the previous topic.

Create a List of the Identified Threats

We identified the following potential threats to the PoS application by using the following categorization: Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges. Note that all identified threats are listed, even if we already reduced their effect.

Table 19 List of identified threats

Threat	Description	Asset	Impact
An unauthorized user can put messages in the queue.	If a user has write permissions to the queue from which BizTalk Server picks up messages, then that user can submit messages to BizTalk Server.	BizTalk Server environment	Spoofing identity Tampering with data Elevation of privileges
A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa.	By default, the communication between BizTalk Server and the SQL Server databases is in clear text. A malicious user can read the data as it travels from one server to another.	Message	Spoofing identity Tampering with data
A malicious user can tamper with the application binaries.	If a malicious user has access to the network resources, that user might be able to locate the binaries for the PoS application, tamper with them, and cause unwanted behavior.	Test application	Tampering with data Information disclosure Denial of service Elevation of privileges
We cannot prove that we received a message, or that we sent a reply.	If there are no good audit mechanisms in place, then we might not be able to prove that a particular employee submitted an order, or that BizTalk Server sent an acknowledgement.	Message	Repudiation
Employees can order as many items as they want.	There should be a limit on how many items employees can order; require management approval to exceed that limit.	Inventory	Tampering with data Elevation of privileges Note While this is not a standard elevation of privileges threat (employees cannot gain control of the application through this threat), employees currently can order more items than they should, which is a different form of elevation of privileges.
A malicious user can see and retrieve data in the Message Queuing queue.	If users can access the queue to which BizTalk drops messages, then they can read and modify the messages.	Message	Spoofing identity Tampering with data Information disclosure
A malicious user can insert a bad message into BizTalk Server.	Communication between BizTalk Server and the PoS application is in clear text. A malicious user can identify the communication channel, and send unauthorized messages to BizTalk Server.	Message	Tampering with data Spoofing identity
A malicious user can insert a bad message into the test application.	A malicious user can provide invalid data to the PoS application, which can help the user break into the stored procedure that BizTalk Server uses to retrieve business data.	Data in the business database	Tampering with data Information disclosure Elevation of privileges
A malicious user can use the stored procedure as an access point to the business database.	If a malicious user gains access to the stored procedure that BizTalk Server uses to retrieve business data, then the user can use the stored procedure to access and modify the data in the business database.	Data in the business database	Tampering with data Information disclosure
A malicious user can see data in the stored procedure.	If a malicious user gains access to the stored procedure that BizTalk Server uses to retrieve business data, then the user can see and modify the data within the stored procedure	Data in the business database	Tampering with data Information disclosure
An unauthorized user can retrieve data in the business database.	Only the people and processes that must access the data in the business database should have access to the database.	Data in the business database	Tampering with data Information disclosure

Review Threats

After the main threat model meeting, we reviewed the threats and used the used the following impact categories to identify the risk for each threat: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability.

Rate the Risks

The following table lists the threats and their risk ratings.

Table 20 List of threats and their risk ratings

Threat	Impact	Damage potential	Reproducibility	Exploitability	Affected users	Discoverability	Risk exposure
An unauthorized user can put messages in the queue.	Spoofing identity Tampering with data Elevation of privileges	8	8	8	3	5	6.4
A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa.	Spoofing identity Tampering with data	8	10	8	3	5	6.8
A malicious user can tamper with the application binaries.	Tampering with data Information disclosure Denial of service Elevation of privileges	10	5	5	8	4	6.4
We cannot prove that we received a message, or that we sent a reply.	Repudiation	6	10	5	5	4	6
Employees can order as many items as they want.	Tampering with data Elevation of privileges	10	10	10	5	10	9
A malicious user can see and retrieve data in the Message Queuing queue.	Spoofing identity Tampering with data Information disclosure	8	9	7	4	5	6.6
A malicious user can insert a bad message into BizTalk Server.	Tampering with data Spoofing identity	8	7	6	3	4	5.6
A malicious user can insert a bad message into the test application.	Tampering with data Information disclosure Elevation of privileges	8	9	6	3	4	6
A malicious user can use the stored procedure as an access point to the business database.	Tampering with data Information disclosure	8	8	7	3	5	6.2
A malicious user can see data in the stored procedure.	Tampering with data Information disclosure	8	8	8	3	5	6.4
An unauthorized user can retrieve data in the business database.	Tampering with data Information disclosure	10	7	7	10	7	8.2

Identify Mitigation Techniques and Technologies

After we identified the threats and their risks, we proceeded to identify the mitigation techniques for each threat.

Mitigation Techniques and Technologies

The following table lists the threats, the mitigation techniques, and whether we implemented the mitigation for the PoS application. The threats are ordered from greater risk to lower risk.

Table 21 Mitigation techniques and technologies

Threat	Impact	Risk exposure	Mitigation techniques and technologies	Implemented?
Employees can order as many items as they want.	Tampering with data Elevation of privileges	9	Modify the application so that there is a limit to the number of items that a person can order. An additional modification is to enable a manager to order more items, or to require manager approval for an employee to order more than the maximum allowed.	Yes. We implemented an upper limit of 100 items, and a lower limit of 0 items.
An unauthorized user can retrieve data in the business database.	Tampering with data Information disclosure	8.2	Lock down access to the business database by granting permissions in SQL Server only to the members of the SQL User group. Give the SQL User group access to the business database as users only, and only give them permissions to the specific stored procedures they need access to.	Yes
A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa.	Spoofing identity Tampering with data	6.8	Use Internet Protocol security (IPsec) to encrypt communication between BizTalk Server and SQL Server.	Yes
A malicious user can see and retrieve data in the Message Queuing queue.	Spoofing identity Tampering with data Information disclosure	6.6	Use Message Queuing client authentication to restrict access to the queue. Important Message Queuing client authentication only works when the client and the server are on the same domain controller.	No
A malicious user can tamper with the application binaries.	Tampering with data Information disclosure Denial of service Elevation of privileges	6.4	While not part of the sample solution, the data center administrators must limit access to the application binaries. Administrators must remove the binary file after you deploy the BizTalk assemblies. You can also use signed assemblies to help secure assemblies from end to end.	No
An unauthorized user can put messages in the queue.	Spoofing identity Tampering with data Elevation of privileges	6.4	Restrict access to the Message Queuing queue to only the accounts that have to drop (write) and pick up (read and delete) messages from the queue. Allow only the service account for the BizTalk Message Queuing host to write to the Message Queuing queue.	No
A malicious user can see data in the stored procedure.	Tampering with data Information disclosure	6.4	Use different user groups for each BizTalk Host. Have a host dedicated to the SQL adapter. In SQL Server grant permissions only to the members of the SQL user group, and give this group user access to the business database, and permissions to the specific stored procedures they have to run.	Yes
A malicious user can use the stored procedure as an access point to the business database.	Tampering with data Information disclosure	6.2	As with the previous threat, grant the SQL user group permissions only to the specific stored procedures they have to run.	Yes
We cannot prove that we received a message, or that we sent a reply.	Repudiation	6	Use the BizTalk tracking features, and the standard log files. Important While this mitigation can help you prove that you sent or received a message, it might not meet the requirements for a legal audit.	Yes
A malicious user can insert a bad message into the test application.	Tampering with data Information disclosure Elevation of privileges	6	Allow only authorized users to access the PoS application. Processes downstream should verify that the message came from an authorized user.	No
A malicious user can insert a bad message into BizTalk Server.	Tampering with data Spoofing identity	5.6	Do not use default host and group names. Use different user groups for each BizTalk Host. Have a different host for send and receive for each adapter, processing, and tracking. Use the BizTalk S/MIME security features to prove the identity of the sender (from either direction) and to validate that the incoming request is valid.	Somewhat. We have separate, non-default hosts and groups, but do not use S/MIME.

Configuration

This sample uses four computers—a primary domain controller, a computer that runs Microsoft SQL Server, a computer that runs Microsoft BizTalk Server 2004, and an application computer. Each computer plays a role in the sample, and you have to configure each of them for the sample to work correctly.

This section contains procedures to configure the four computers that we used in the Secure Deployment sample solution. Before you configure this sample, make sure that you have sufficient knowledge in the following areas:

Microsoft Windows Server 2003
Active Directory
SQL Server
BizTalk Server 2004

Domain Controller

First you have to create a domain controller for the sample.

To install the Domain Controller server role on the computer

Click Start, point to All Programs, point to Administrative Tools, and then click Configure Your Server Wizard.
Install Domain Controller (Active Directory).
Create a domain in a new forest.
Select the option to install and configure Domain Name System (DNS) on the computer.
The full DNS name for the new domain is contoso.com.
The domain NetBIOS name is CONTOSO.
Accept the defaults for the Active Directory database.
Accept the default for the sysvol folder.
Choose a password for the restore mode.
Complete the domain controller installation and restart the computer.

Now, create the global domain security groups that BizTalk Server 2004 uses for the sample application. Create the following new domain groups:

SSO Administrators
SSO Affiliate Administrators
BizTalk Server Administrators
BizTalk Orchestration Host Users
BizTalk SQL Adapter Host Users
BizTalk Message Queuing Adapter Host Users
BizTalk Tracking Host Users

After you create the BizTalk domain groups, you have to create domain users who are part of these groups. The following table shows the domain user names and the groups to put them in.

Table 22 Domain user names and groups to which they belong

Domain user name	Domain name description	Member of
ssoadmin	SSO Administrator	SSO Administrators
ssoservice	SSO Service	SSO Administrators
ssomaster	SSO Master Secret	SSO Administrators
btsadmin	BizTalk Administrator	BizTalk Server Administrators SSO Affiliate Administrators
btsorch	BizTalk Orchestration	BizTalk Orchestration Host Users
btssqladapter	BizTalk SQL Adapter	BizTalk SQL Adapter Host Users
btsmqadapter	BizTalk Message Queuing Adapter	BizTalk Message Queuing Adapter Host Users
btstrack	BizTalk Tracking	BizTalk Tracking Host Users
btsinstall	BizTalk Installation	Local administrators group on the BizTalk Server computer Local administrators group on the computer that runs SQL Server SSO Administrators

SQL Server

Install SQL Server on the second computer, and add the computer to the CONTOSO domain.

To install SQL Server and configure the SQL Server computer

The sample application assumes that this server is named SQL-SERVER. If you name this computer something different, you have to modify the settings on the BizTalk Server. The instructions to modify these settings appear in step 6 of the procedure "To set up the sample orchestration on the BizTalk Server" later in this topic.
Add the computer that runs SQL Server to the CONTOSO domain.
Install SQL Server on the computer.
Modify Microsoft Distributed Transaction Coordinator (MSDTC) on the computer:
1. Open Administrative Tools.
2. Open Component Services.
3. Right-click My Computer.
4. Click Properties.
5. Click the MSDTC tab.
6. Click Security Configuration.
7. Click Security Settings.
8. Make sure that the Network Client check box is selected.
Close the dialog box and restart the computer.

BizTalk Server

The configuration of the BizTalk Server computer requires several steps. This section describes the following actions:

Configure the BizTalk Server 2004 computer
Install and configure BizTalk Server 2004
Create BizTalk Hosts
Delete unnecessary adapters
Set up the sample orchestration

Before you install BizTalk Server 2004, you have to configure the computer to become part of the domain, and also configure MSDTC. Follow these steps to configure the BizTalk Server 2004 computer.

To configure the BizTalk Server 2004 computer

Name this computer BTS-SVR. The sample assumes that this server is named BTS-SVR. If it is not, you can change the default BizTalk Server that the sample application uses in the sample application program described later in this document.
Add the computer to the CONTOSO domain.
Add the btsinstall domain user to the local administrators group.
Log off and then log on using the btsinstall domain user.
Modify MSDTC on the computer:
1. Open Administrative Tools.
2. Open Component Services.
3. Right-click My Computer.
4. Click Properties.
5. Click the MSDTC tab.
6. Click Security Configuration.
7. Click Security Settings.
8. Make sure that the Network Client check box is selected.
Close the dialog box and restart the computer.

You are now ready to install and configure BizTalk Server 2004.

To install and configure BizTalk Server 2004

Perform a custom installation of BizTalk Server 2004. On the Custom Installation page, remove the following from the standard installation:
- Human Workflow Services Runtime Component
- Base EDI Adapter
- Rules Engine
- Human Workflow Service Administration Tools
- Information Worker Applications/Portal
On the Configuration options page, create a BizTalk Server group. Choose Yes to have the Single Sign-On server hold the master secret key. Choose No to creating a BizTalk Host or Isolated Host Application. Click Next.
On the second Configuration options page, choose No to creating an Analysis database to track aggregations and Choose No to using the Analysis Server for BAM. Click Next.

On the Windows accounts page, configure the following Windows accounts for the following BizTalk Server accounts, and then click Next:

Windows account name	BizTalk Server account
BizTalk Administrators Group	Contoso\BizTalk Server Administrators
SSO Administrator(s)	Contoso\SSO Administrators
SSO Affiliate Administrator(s)	Contoso\SSO Affiliate Administrators

On the Database configurations page, change the settings for each database so that they are created on the SQL Server that you set up earlier. Click Next.
On the Windows Service Configurations page, assign the Enterprise Single Sign-On Service to the Contoso\ssomaster domain user. Click Next.
Click Finish.

After you install and configure BizTalk Server 2004, you have to create BizTalk Hosts for the sample application to use. Follow these steps to create hosts.

To create BizTalk Hosts

Open the BizTalk Administration console.
Create the BizTalkMessageQueuingAdapter host:
1. Name: BizTalkMessageQueuingAdapter
2. Windows Group: Contoso\BizTalk Message Queuing Adapter Host Users
3. Host Type: In-Process
4. Make sure that the Default Host in Group and Host Tracking options are selected.
5. Click OK.
6. Right-click the BizTalkMessageQueuingAdapter host and create a new instance of the host.
7. Click the correct BizTalk Server.
8. Set the Contoso\btsmqadapter account as the logon account for the host instance with the corresponding password.
9. Click OK.
Create the BizTalkSQLAdapter host using the procedures in step 2 with the following information:
1. Name: BizTalKSQLAdapter
2. Windows Group: Contoso\BizTalk SQL Adapter Host Users
3. Host Type: In-Process
4. Set the Contoso\btssqladapter account as the logon account for the host instance with the corresponding password.
Create the BizTalkOrchestration host using the procedures in step 2 with the following information:
1. Name: BizTalkOrchestration
2. Host Type: In-Process
3. Set the Contoso\btsorch account as the logon account for the host instance with the corresponding password.
Create the BizTalkTracking host using the procedures in step 2 with the following information:
1. Name: BizTalkTracking
2. Host Type: In-Process
3. Make sure that the Host Tracking option is selected.
4. Set the Contoso\btstrack account as the logon account for the host instance with the corresponding password.
Clear the Host Tracking option for the BizTalkMessageQueuingAdapter host.

While in the BizTalk Administration console, you should also delete the adapters that the sample does not use. When you delete these adapters, it helps further secure your application. Delete the following adapters:

EDI adapter
FTP adapter
HTTP adapter
SMTP adapter
SOAP adapter

After you delete unnecessary adapters, you have to add the MSMQT adapter.

To add the MSMQT adapter

Open the BizTalk Administration console.
Right-click Adapters.
Create a new adapter by using the following information:
- Name: MSMQT
- Adapter: MSMQT
- Comment: MSMQT Adapter

After you create the BizTalk Hosts, you have to run the installation program to set up the BizTalk Server correctly and to install additional files that the other computers need.

To set up the sample orchestration on the BizTalk Server

Run the Secure_Deployment.msi installation program.
On the License Agreement screen, read the agreement. If you agree to abide by the license agreement choose the I Agree option. Click Next.
Select the location where you want to copy the sample files. Click Next.
Click Next. Click Close to exit the installation program when installation is finished.
If you took the default settings for the location of the installation files, open Windows Explorer and go to the C:\Program Files\WSS Technical Guides\Secure_Deployment\ContosoOrders directory. Otherwise go to the location you specified.
If your computer that runs SQL Server is not named SQL-SERVER or your application server is not named APP-SVR, you will have to run the adjust_setup.vbs file. Otherwise go to step 7.
Enter the names of your computer that runs SQL Server and your application server in the correct locations.
Run the deploy.bat file. This file deploys the BizTalk Server orchestration and starts the sample orchestration. The batch file should finish with success messages as shown in the following figure.

After you set up the sample orchestration on the BizTalk Server you have to copy the sample database to the computer that runs SQL Server.

To set up the sample database on the SQL Server computer

If you took the default settings for the location of the installation files, open Windows Explorer and go to the C:\Program Files\WSS Technical Guides\Secure_Deployment directory. Otherwise go to the location you specified. Select the location to which you want the sample files to be copied. Click Next.
Copy the Database directory to the computer that runs SQL Server.
On the computer that runs SQL Server, continue to the Database directory that you just copied from the BizTalk Server computer and run the mount_db.vbs file. This file mounts the sample database that the sample application uses.
Open the SQL Server Enterprise Manager application and verify that the ContosoOrder database is successfully mounted.

Running the Sample

This section describes how to run the application that starts the security sample. The sample application was written using Microsoft Visual Studio .NET 2003.

Procedure

To run the sample application

Copy the ContosoOrderProcessor directory from the BizTalk Server computer to the Application computer.
On the Application computer, continue to the ContosoOrderProcessor directory that you just copied from the BizTalk Server computer and run the testapp_setup.vbs file. This file creates the message queue that the test application uses.
Run ContosoOrderProcessor.exe in the ContosoOrderProcessor directory.
If your BizTalk Server computer is named BTS-SRV, go to step 5.

If your BizTalk Server computer is not named BTS-SRV, click Setup. Change the entry for the BizTalk Host field to the correct name of your BizTalk Server computer. The Local Queue should be ContosoOrderOutput and the BizTalk Queue should be ContosoInputQueue.
Change the values for Shirts, Pants, Socks, or Shoes. Click Order to send the order to the BizTalk Server. A confirmation XML message is sent from the BizTalk Server and displayed in the Processed Orders text box.

The application sends an order with the quantities that you specified to the BizTalk Server. BizTalk Server processes the order.

BizTalk Server sends an XML document to the application to confirm that it returned the order to the sample application. The sample application displays the XML message in the text box, as shown in the following figure.

Configuring IPsec

Now that you have configured the computers used in the sample, you can implement an additional layer of security if you create and then implement Internet Protocol security rules.

Internet Protocol security (IPsec) is a framework of open standards that helps protect networks from active and passive attacks by securing IP packets through the use of packet filtering, cryptography, and the enforcement of trusted communication. IPsec supports network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection.

One of the main purposes of implementing IPsec rules is to help protect or control access to information between different computers in a network. IPsec rules can control individual point-to-point network connections by individual IP addresses or by a range of IP addresses. This section walks you though the steps needed to create and implement IPsec rules on the computers used in the security sample.

Setup Procedures

The security sample uses four computers. Each computer needs a static IP address so that other computers on the network can identify it. When you set up this sample you will have to plan out the IP addresses for each computer. For simplicity, the following table outlines the address ranges that we used in the sample. You should use this as a reference when you set up the sample.

Table 23 IP address ranges used in the sample

IP address range	Description
Range : 192.168.10.x Netmask : 255.255.255.0	IP address range and subnet used by the sample
192.168.10.1 to 192.168.10.63	IP address range for domain-specific servers (DNS, DHCP, WINS, and so on)
192.168.10.64 to 192.168.10.127	IP address range for applications
192.168.10.128 to 192.168.10.191	IP address range for BizTalk Servers
192.168.10.192 to 192.168.10.254	IP address range for computers that run SQL Server

The following table displays each computer's static IP address and the computer names referred to in the sample documentation.

Table 24 Static IP addresses and computer names used in the sample

IP address	Computer	Computer name
192.168.10.50	Domain Controller, DNS	DC-CTRL
192.168.10.65	Application Host	APP-SVR
192.168.10.129	BizTalk Server	BTS-SVR
192.168.10.193	SQL Server	SQL-SERVER

The first step is to set up Internet Protocol security through the Domain Security Policy Wizard on the domain controller computer with the following procedure.

To set up Internet Protocol security

Click Start, point to Administrative Tools, and then click Domain Security Policy.
In the Default Domain Security Settings screen, in the left pane, right-click IP Security Policies on Active Directory, and then click Create IP Security Policy.
On the Welcome to the IP Security Policy Wizard page, click Next.
On the IP Security Policy Name page, type BizTalk Secure Policy as the name of the policy, enter a description in the Description section, and then click Next.
On the Requests for Secure Communication page, make sure that the Activate the default response rule check box is selected, and then click Next.
On the Default Response Rule Authentication Method page, make sure that Active Directory default is selected, and then click Next.
On the Completing the IP Security Policy Wizard page, make sure that the Edit properties check box is selected, and then click Finish to start creating the IPsec rules.

The BizTalk Secure Policy Properties dialog box appears.

You are now ready to create the first IPsec rule.

The first rule that you create makes sure that any computer that is part of the domain can communicate with the domain services (DNS, DHCP, and so on). Follow these steps to create this rule.

To create the first IPsec rule for the domain server

In the BizTalk Secure Policy Properties dialog box, click Add.
On the Welcome to the Create IP Security Rule Wizard page, click Next.
On the Tunnel Endpoint page, make sure that This rule does not specify a tunnel is selected, and then click Next.
On the Network Type page, select Local area network (LAN), and then click Next.
On the IP Filter List page, click Add.
In the IP Filter List dialog box, enter a name and a description as shown in the following figure, and then click Add.
On the Welcome to the IP Filter Wizard page, click Next.
On the IP Filter Description and Mirrored property page, enter a description for the filter as shown in the following figure, and then click Next.
On the IP Traffic Source page, for Source address, select Any IP Address, and then click Next.
On the IP Traffic Destination page, for Destination address, select DNS Servers <dynamic>, and then click Next.
On the IP Protocol Type page, select Any, and then click Next.
On the Completing the IP Filter Wizard page, make sure that the Edit properties check box is cleared, and then click Finish.
In the IP Filter List dialog box, notice the newly added entry in the IP Filters section, and then click OK.

This returns you to the IP Filter List page in the Security Rule Wizard.

Follow these steps to complete the configuration for the first rule.

To complete the first rule

On the IP Filter List page, select the filter list that you created in the previous procedure (Allow Domain Filter List), and then click Next.
On the Filter Action page, select Permit, and then click Next.
On the Completing the Security Rule Wizard page, clear the Edit properties check box, and then click Finish.

This returns you to the BizTalk Secure Policy Properties dialog box.

After you create an IP filter list so that the computers in the domain can communicate with the domain controller, you have to create other IP filter lists so that only specific computers in the domain can communicate to other specific computers.

Follow these steps to create an IP filter list between the application and BizTalk Server.

To create the IP filter list between the application and BizTalk Server

In the BizTalk Secure Policy Properties dialog box, click Add.
On the Welcome to the Create IP Security Rule Wizard page, click Next.
On the Tunnel Endpoint page, make sure that This rule does not specify a tunnel is selected, and then click Next.
On the Network Type page, select Local area network (LAN), and then click Next.
On the IP Filter List page, click Add.
In the IP Filter List dialog box, enter the name and description for the filter list as shown in the following figure, and then click Add.
On the Welcome to the IP Filter Wizard page, click Next.
On the IP Filter Description and Mirrored property page, enter a description for the IP filter as shown in the following figure, and then click Next.
On the IP Traffic Source page, for Source address, select A specific IP Subnet, type the IP address and Subnet mask as shown in the following figure, and then click Next.

Because this IP filter list is specific to communications between the application and BizTalk Server, the IP subnet that you want is 192.168.10.64 to 192.168.10.127. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration.
On the IP Traffic Destination page, for Destination address, select A specific IP Subnet, type the IP address and Subnet mask as shown in the following figure, and then click Next.

The IP subnet that you want is 192.168.10.128 to 192.168.10.191. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration.
On the IP Protocol Type page, select Any, and then click Next.
On the Completing the IP Filter Wizard page, clear the Edit properties check box, and then click Finish.
In the IP Filter List dialog box, click OK.
On the IP Filter List page in the Security Rule Wizard, select the filter list that you created (App to BizTalk IP Filter List), and then click Next.
On the Filter Action page, select Require Security, and then click Next.
On the Authentication Method page, select Active Directory default, and then click Next.
On the Completing the Security Rule Wizard page, clear the Edit properties check box, and then click Finish.

This returns you to the BizTalk Secure Policy Properties dialog box.

Now you create an IP filter list between the BizTalk Server and the SQL Server. This rule is similar to the rule that you have just created, except that it is specific to the communications between BizTalk Server and SQL Server. Follow these steps to create the IP filter list between BizTalk Server and SQL Server.

To create the IP filter list between BizTalk Server and SQL Server

In the BizTalk Secure Policy Properties dialog box, click Add.
On the Welcome to the Create IP Security Rule Wizard page, click Next.
On the Tunnel Endpoint page, make sure that This rule does not specify a tunnel is selected, and then click Next.
On the Network Type page, select Local area network (LAN), and then click Next.
On the IP Filter List page, click Add.
In the IP Filter List dialog box, enter the name for the new IP filter list as BizTalk to SQL IP Filter List, enter the description as Permit BizTalk to talk to SQL securely, and then click Add.
On the Welcome to the IP Filter Wizard page, click Next.
On the IP Filter Description and Mirrored property page, enter BizTalk Servers to SQL Servers, and then click Next.
On the IP Traffic Source page, for Source address, select A specific IP Subnet, enter information as shown in the following figure, and then click Next.

Because this IP filter list is specific to communications between BizTalk Server and SQL Server, the IP subnet that you want is 192.168.10.128 to 192.168.10.191. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration.
On the IP Traffic Destination page, for Destination address, select A specific IP Subnet, enter information as shown in the following figure, and then click Next.

The IP subnet that you want is 192.168.10.192 to 192.168.10.254. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration.
On the IP Protocol Type page, select Any, and then click Next.
On the Completing the IP Filter Wizard page, clear the Edit properties check box, and then click Finish.
In the IP Filter List dialog box, click OK.
On the IP Filter List page in the Security Rule Wizard, select the filter list that you created (BizTalk to SQL IP Filter List), and then click Next.
On the Filter Action page, select Require Security, and then click Next.
On the Authentication Method page, select Active Directory default, and then click Next.
On the Completing the Security Rule Wizard page, clear the Edit properties check box, and then click Finish.

This returns you to the BizTalk Secure Policy Properties dialog box.

To make sure that only certain computers can communicate with other computers, you have to create filters that prevent some computers from communicating with others in the network. This ensures that if certain computers are penetrated, they cannot communicate with other computers that might contain sensitive information.

Now you create an IP filter list to block communication between the application and SQL Server. We added this security precaution because there is no valid reason for the application to communicate directly with SQL Server. This rule is similar to those you have already created. Follow these steps to create the IPsec rule to block communication between the application and SQL Server.

To create the IPsec rule to block communication between the application and SQL Server

In the BizTalk Secure Policy Properties dialog box, click Add.
On the Welcome to the Create IP Security Rule Wizard page, click Next.
On the Tunnel Endpoint page, make sure that This rule does not specify a tunnel is selected, and then click Next.
On the Network Type page, select Local area network (LAN), and then click Next.
On the IP Filter List page, click Add.
In the IP Filter List dialog box, enter the name and description for the filter list as shown in the following figure, and then click Add.
On the Welcome to the IP Filter Wizard page, click Next.
On the IP Filter Description and Mirrored property page, enter a description for the IP filter as shown in the following figure, and then click Next.
On the IP Traffic Source page, for Source address, select A specific IP Subnet, enter information as shown in the following figure, and then click Next.

Because this IP filter list is specific to communications between the application and SQL Servers, the IP subnet you want is 192.168.10.64 to 192.168.10.127. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration.
On the IP Traffic Destination page, for Destination address, select A specific IP Subnet, enter information as shown in the following figure, and then click Next.

The IP subnet you want is 192.168.10.192 to 192.168.10.254. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration.
On the IP Protocol Type page, select Any, and then click Next.
On the Completing the IP Filter Wizard page, clear the Edit properties check box, and then click Finish.
In the IP Filter List dialog box, click OK.
On the IP Filter List page in the Security Rule Wizard. Select the filter list that you created (Block App to SQL IP Filter List), and then click Next.
On the Filter Action page, click Add.
On the Welcome to the IP Security Filter Action Wizard page, click Next.
On the Filter Action Name page, enter the name and description of the filter action as shown in the following figure, and then click Next.
On the Filter Action General Option page, select Block, and then click Next.
On the Completing the IP Security Filter Action Wizard page, clear the Edit properties check box and then click Finish.
On the Filter Action page, select Block, and then click Next.
On the Completing the Security Role Wizard page, click Finish.
This brings you back to the BizTalk Security Policy dialog box. Click OK.

After you create the rules, you have to assign the policy so that you can use it. Follow these steps to complete the IPsec policy.

To complete the IPsec policy

In the Default Domain Security Settings screen, in the left pane, click IP Security Policies. The right pane displays the IPsec rules that you created.
In the right pane, right-click BizTalk Security Policy, and then click Assign. This activates the policy.
Restart the computers you used in the sample.

Testing the IPsec Rules

The last step in setting up the IPsec rules is to test the communications between the different computers in the sample.

To test the application computer connections

Log on to the application computer.
Open a command-line prompt.
Ping the BizTalk Server computer's IP address. If you followed the sample closely, this IP address is 192.168.10.129. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration. Notice that you can receive a response from the BizTalk Server.
Ping the SQL Server computer's IP address. If you followed the sample closely, this IP address is 192.168.10.193. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration. Notice that you cannot receive a response from the SQL Server.

To test the BizTalk Server connections

Log on to the BizTalk Server computer.
Open a command-line prompt.
Ping the application computer's IP address. If you followed the sample closely, this IP address is 192.168.10.65. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration. Notice that you can receive a response from the application computer.
Ping the SQL Server computer's IP address. If you followed the sample closely, this IP address is 192.168.10.193. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration. Notice that you can receive a response from the SQL Server.

To test the SQL Server connections

Log on to the computer that runs SQL Server.
Open a command-line prompt.
Ping the BizTalk Server computer's IP address. If you followed the sample closely, this IP address is 192.168.10.129. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration. Notice that you can receive a response from the BizTalk Server.
Ping the application computer's IP address. If you followed the sample closely, this IP address is 192.168.10.65. If you did not use the IP address range that was specified earlier, type the appropriate entries for your configuration. Notice that you cannot receive a response from the application computer.