Chapter 3: Security and Operational Considerations

As you consider the design of your application integration environment, it is very important to examine the security requirements of your organization. A well-designed application integration environment rapidly becomes an integral part of your organization. Therefore, security vulnerabilities in application integration have the potential to cause wide-ranging problems.

Similarly, your operational practices must be well-defined so that your application integration environment can continue to operate effectively and reliably over time. This chapter covers both the security and operations considerations you need to examine to ensure that your application integration environment continues to operate in a reliable and secure fashion.

Security Considerations

Because different applications have different security requirements and features, it can be quite a challenge to ensure that your application integration environment functions properly without compromising your security requirements. Security is particularly important in application integration because a breach in an integration service may result in security breaches in other integrated systems.

Security Policy

The first step toward effective security in any environment is creating a written security policy. Many factors can affect the security policy, including the value of the assets you are protecting, the threats that your environment faces, and the vulnerabilities that are currently present.

The security policy should form the basis of any security measures you take in your organization. Before you make modifications to the environment, you should ensure that they are consistent with your security policy. You should also examine the policy itself periodically to determine whether it needs to be redefined in the wake of new business requirements and to verify that the procedures and standards that implement the policy adhere to industry best practices.

Note

This chapter examines only security policy that is related to integration technologies. Your policy, however, should cover all aspects of IT security, including physical security.

From an integration standpoint, your security policy should define:

• A mechanism for evaluating and classifying threats. Your evaluation mechanism should ensure that consistent and relevant information is gathered about any threat. This information helps you classify threats to ensure that high-level threats are not ignored and that low-level threats are not unnecessarily escalated.

• A mechanism for acting on threats. This should ensure that the appropriate people are involved in dealing with a threat and that they are equipped to deal with it in an appropriate manner.

• A boundary for information security. Most application integration environments include some form of integration with other organizations or individuals outside the boundary of your own IT environment. It is therefore very important to define the type of information that must be protected within the organization, between business partners, and from the public. You also must determine how that information should be protected in each of the different cases.

• A plan for communication and enforcement. One of the main problems in maintaining good security in an organization is ensuring that individuals are aware of the security policy. It is therefore vital that the security requirements (as defined in the policy) are clearly communicated to your employees, including both IT staff and the rest of the organization. You also need ways of ensuring that people comply with the requirements, including clearly defined disciplinary procedures where appropriate.

• General security guidelines. If you make the security guidelines in your security policy too specific, you run the risk of them quickly becoming obsolete. However, if they are too generic, you run the risk of making them too vague. Therefore, you need to maintain a delicate balance in defining an effective and lasting policy. Ensuring compliance to security guidelines across an entire enterprise can be problematic when different systems are being used. However, it is possible to provide some generic non-technology-specific guidelines that are unlikely to age too quickly. A good example of such a guideline is one that specifies a minimum level of encryption for public key/private key pairs in your environment. Of course, even a guideline such as this is likely to change as technology advances.

• Reference to other documents. Your policy should reference more specific security policy documents and an Incident Response Plan. Linking to other documents enables you to define more specific requirements that are likely to change frequently without having to modify the main security policy in your organization.

• A mechanism for modifying security policies. As your environment evolves and new threats and vulnerabilities emerge, you must modify your policies to make sure that they continue to reflect the requirements of your organization. Therefore, your security policy must define the mechanism for security policy change and must identify the people responsible for making changes.

Security Capabilities

A number of basic capabilities are usually required to ensure effective security in an application integration environment. Table 3.1 shows these security capabilities.

Table 3.1: Security Capabilities

Capability	Description
Authorization	Determines whether a particular connection attempt should be allowed.
Authentication	Verifies credentials when an application attempts to make a connection.
Information Protection	Prevents unauthorized users from easily viewing or tampering with information.
Identity Management	Manages multiple sets of credentials and maps them to the correct application.
Nonrepudiation	Uses digital signatures to verify identity.
Profile Management	Manages principal profiles.
Security Context Management	Determines how credentials are provided to applications.

For more information about each of these capabilities, see the Appendix, "Application Integration Capabilities."

Defining Your Security Requirements

The precise security requirements of your application integration environment depend on a number of factors, including the following:

• Security requirements of your organization

• Business requirements for application integration

• Technical requirements for application integration

• Capabilities of the applications you are integrating

• Platforms on which applications are running

• Budgetary constraints

As a starting point for defining your security requirements, you should perform a risk analysis. Doing so allows you to identify the threats and vulnerabilities that you face and identify the countermeasures you can deploy to keep risk at an appropriate level.

The following paragraphs discuss security requirements that are common to many application integration environments.

Authentication

Multiple forms of authentication are available to you when integrating applications, and these forms provide varying levels of security. For example, HTTP Basic Authentication passes a user name and password back and forth in each request. The user name and password are not encrypted (just encoded), so capturing network traffic could potentially give an attacker easy access to the information.

HTTP Basic Authentication is not appropriate for most environments, although it can be used in some cases where the channel itself is secured (for example, when using Secure Sockets Layer, or SSL). However, because different operating systems implement different authentication protocols, one of the challenges of application integration is finding a secure form of authentication that is used on each of the platforms you need to support.

One common authentication protocol is Kerberos, because it is supported by both UNIX and the Microsoft Windows operating system (Windows 2000 and later). Kerberos is a network authentication protocol, defined by the Internet Engineering Task Force (IETF), that relies on public key cryptography. However, the use of Kerberos for authentication with third parties requires trust relationships to be established and access to the Kerberos key distribution center. The Kerberos key distribution center is where the private keys of principals (users or systems) are kept for encrypting information.

One way of increasing the security of authentication is to use multifactorial authentication. This form of authentication is increasingly used in situations where people interact with systems and is commonly referred to as something you know, something you have, something you are, defined as follows:

• Something you know—for example, a password or PIN number

• Something you have—for example, a smart card

• Something you are—for example, the unique patterns of your iris (the colored part of your eye)

Requiring two or more of these factors for authentication can dramatically increase the security of any environment. However, this form of authentication is not commonly used in system-to-system authentication.

In some cases, applications require authentication that is not integrated with the operating system. In such cases, you should investigate separately how authentication occurs (is the password sent over the network?) and how the password is stored at the target application (is it maintained in a plain text file?). In circumstances where the requesting application must present a password, you should also ensure that the requesting application stores the password securely.

One other important consideration is whether to use the same password across multiple applications. If you change the password in one location, how will that change be reflected in other locations? If you are using different passwords for each application, how can you ensure that the password information is kept current on each system? In complicated situations such as these, your application integration environment may need the Identity Management capability, which enables credentials for multiple applications to be associated with a single identity.

Authorization

Two methods of authorization are most commonly used. One method is to perform authorization based on the user entity obtained through authentication. The other is to perform authorization based on user roles.

Authorization based on user identities is becoming less common in many systems and applications available today because it is more cumbersome to manage, particularly in large-scale implementations. In many cases, when a user changes a job role, or begins work on a new project, he or she requires access to an entirely new group of systems. You may need to do a lot of administrative work to give the user permissions that correspond to the new job role.

Role-based authorization works around this problem by allowing you to decouple user identities from the roles the users assume and resources or services they can access. A role is a category or set of users who share the same security privileges. For example, imagine that today Jane is a credit manager who is allowed to view customer credit details, but next month Jane will be transferring to another department as a human resources manager. With role-based authorization, the credit manager role will still be allowed to access the resource, but Jane will not be able to access the resource when she commences her new role.

From an application integration perspective, authorization can occur at three different levels:

• System. System-level authorization is the more commonly used type of authorization, where the system protects resources. A typical example of resources is files stored in the file system that are protected by the operating system. Systemlevel authorization is also commonly used for network shares.

• Functional. Functional-level authorization protects resources based on functional ability, which usually ties authorization to specific applications or services. For example, an integration application may expose two services named GetCustomerDetailsInternal and GetCustomerDetailsExternal. The former service can only be called by systems located within the organization (internal systems). The latter can be called by internal systems as well as external systems (possibly from a business partner).

• Data. Data-level authorization provides the lowest granular level of authorization. This capability is usually tied very closely to the business logic of the service. The integration application from the previous example may merge the GetCustomerDetails services into a single smarter service. When internal systems call the resulting service, it provides additional data that it excludes when external systems call the service.

In many cases, these different types of authorization are implemented using different technologies and are located in different layers of the systems. For example, the system-level authorization may be performed and maintained by the operating system; the functional authorization level may be performed and maintained by an integration product; and the data authorization may be custom-coded, because it is usually very closely linked with the business logic and requires detailed knowledge of the data to be protected. However, even though the three types of authorization levels may be implemented in different layers of the systems, all of the principals and access control information may be placed within a single security directory.

Security Tokens

Often systems issue unique tokens or tickets after authentication and authorization has been performed. The idea behind token-based security is to allow the system to quickly recognize and trust the requester, which reduces the authentication and authorization overhead. There are a number of different ways to implement tokens, but most of the standard authentication protocols provide token-based security after the initial authentication and authorization. Token-based mechanisms have the advantage that the actual requester's credentials are not always passed around the network.

When you use security tokens, reply attacks can be a problem. These attacks involve the use of specialized software that is able to capture network data packets. The captured packets are then modified and replayed. To protect against reply attacks, you can use rolling tokens, which are changed or renewed within a short interval of time. Limiting the time available to capture, modify, and replay packets greatly reduces the chance of network capture and replay. Kerberos specifically addresses the prevention of replay attacks.

Security Context Management

When implementing security context management, you need to determine whether to use impersonation, consolidation, or both. Impersonation is not commonly implemented in application integration scenarios because of problems with maintaining user identities across the different applications being integrated. In such scenarios, a matching user identity must be present in each of the systems. However, with the increasing availability and capability of identity management systems, this requirement may change. Using exact user credentials to access the various systems provides better ability to track the service requester's request from various systems and allows authorization to occur at the systems that need to implement it. Figure 3.1 shows impersonation using an identity management system.

Figure 3.1: Using impersonation for security context management

If you use consolidation for security context management, a single identity is used to identify the requester to each application. This allows all requesters to have the same level of authority. Composed applications commonly use consolidation because it provides simple user management to the existing systems and a better opportunity for connection pooling capabilities. Figure 3.2 on the next page shows consolidation being used.

Figure 3.2: Using consolidation for security context management

Information Protection

You must determine when it is appropriate to use encryption, hashing, and obfuscation in your application integration environment, and how to implement them.

Encryption is often used in an application integration environment to protect application data as it passes across the network. It may also be used to protect user names and passwords if they have to be passed as plain text.

The two main implementation choices for encryption are secret key encryption and public key encryption. One of the biggest issues with secret key encryption is the requirement for the sender and recipient of the data to have the same secret key. The more parties involved in the communication chain, the more places the secret key has to be distributed and the greater the risk of jeopardizing the key. The encrypted data is usually tied to the exact key used to encrypt the information. If the key is changed, existing encrypted data must be decrypted and reencrypted with the new key. For this reason, public key encryption is often a better choice; however, if you do not currently have a public key infrastructure, you must implement one to support public key encryption.

Web Services Security

As Web services become an increasingly common communication protocol for application integration, it is likely that the Web Services Security (WS-Security) specification and related extension specifications will emerge as the industryaccepted security communication protocol.

WS-Security provides a higher-level protocol but does not provide the ability to perform authentication, it merely provides a common language for a variety of systems on different platforms. You will need to consider the best mechanism for securing the service while ensuring that the target audiences can participate with minimal or no interoperability issues. For now, you may still need to rely on the combination of SSL, user name and password, and tokens to authenticate Web service requests when using HTTP as the transport mechanism.