1.2 Positioning trusted security infrastructures

To position TSIs, we have to look not only at their logical positioning as part of the security architecture but also at their physical positioning as part of the security design. A security architecture is a high-level specification of security major components and how they relate to each other. A security design specifies the physical placement of components.

From a security architecture point of view, trusted security infrastructures introduce a new layer of security services that is sometimes referred to as the access layer, a concept that was first introduced by the Burton Group. The access layer is between the resource layer and the perimeter layer (as illustrated in Figure 1.1). The resource layer contains applications and data, or, in short, the information and application assets of an organization. The perimeter layer contains all elements that make up the perimeter security infrastructure of an organization. The perimeter layer contains security devices like firewalls, access routers, intrusion detection and prevention systems (IDS), and virtual private networking (VPN) tunnel endpoints.

Figure 1.1: The access or TSI layer.

In the context of this chapter, I will simply refer to the access layer as the trusted security infrastructures, or TSI, layer. The key role of this logical layer of security services is illustrated in Figure 1.2. The TSIs are built upon and used by a set of core infrastructure services like directory, database, messaging, and management services. In turn, the TSIs are—like all other core infrastructure services—used by a set of commercial off-the-shelf (COTS) or custom-built applications.

Figure 1.2: Positioning trusted security infrastructures.

TSIs are created to provide a unified and universal security infrastructure for applications and services that are accessed in different environments and using different communication protocols: be it in a typical office setup (using RPC and SMB-like protocols), across the Web (using the HTTP protocol), in a remote access setup (RAS) (using the PPP protocol), or in a wireless environment (using WAP or any other wireless protocol). TSIs are created to also serve business-to-employee (BtoE), as business-to-consumer (BtoC) and business-to-business (BtoB) environments.

Looking at TSIs from a security design point of view and taking into account their critical security role, it is fair to say that they should be located in a separate security zone. This zone should be governed by a strong security policy. To shield the TSIs from the rest of the world one will typically use a set of perimeter security devices that enforce the appropriate security policies to let the right office, web, RAS, and wireless users in and keep the wrong ones out.

In the introduction I shortly mentioned the security services provided by TSIs. Figure 1.2 shows the key TSI components providing these services:

• Security administration infrastructures, or security management infrastructures, are the administrative engines of a TSI. A security administration infrastructure typically manages security identities, authentication credentials, entitlements, authorization intermediaries, ^[1] and security policies. A security administration infrastructure also takes care of critical tasks such as security patch and security policy management. Often the latter services are also provided by enterprise management systems such as HP Openview, CA Unicenter, and BMC Patrol.

• Authentication infrastructures provide the entry points into a secured IT environment. They verify the identity of entities before they are allowed to use resources. To do so, the TTPs that are making up the authentication infrastructures support a set of authentication methods and protocols. To prove its identity, an entity provides the TTP with a set of authentication credentials.

• Authorization infrastructures are the next level of security guards following authentication infrastructures. Once an entity’s identity has been verified, authorization infrastructures will decide which resources the entity is allowed to access and the level of access it has to those resources. Authorization infrastructures do not necessarily deal with the management of authorization–related objects such as groups, roles, and entitlements. The latter functionality is typically provided by security administration infrastructures.

• Key management infrastructures provide key life cycle management services. A good example of a key management infrastructure is a public key infrastructure (PKI).

• Auditing and accounting systems are keeping track of all events (securityrelated but also other ones) that occur in your infrastructure. Given the high degree of outsourcing in a TSI setup, auditing systems have an even more critical role. Auditing and accounting systems are not considered a separate infrastructure component. They are an integral part of the other TSI components: Every authentication, authorization, and security administration infrastructure includes an auditing and accounting system. Often they are also integrated with enterprise management systems.

Altogether these TSI components are also referred to as the AAAA security services: where the four A’s stand for administration, authentication, authorization, and auditing (or accounting). In the following sections, we will explore the different TSI components in greater detail. We look at how they operate and interoperate. We will also give some examples of TSI software solutions for the different TSI categories. In this chapter we will not specifically focus on auditing and accounting systems because, as I mentioned earlier, these systems are normally bundled with other TSIs or with enterprise management systems.

^[1]Authorization intermediaries are administrative entities that facilitate authorization administration. Examples are groups, rights, and roles.