Architecture and Operation

This chapter provides an overview of the IBM Security software architecture for identity management, privilege elevation, and auditing on Windows computers.

Identity and Privilege Management

In Verify Privilege Server Suite, the authentication service and privilege elevation service provide role-based access control and privilege management for Windows computers. For administration, the services provide tools that help you define and manage access rights and roles for Active Directory users and groups. To enforce the rights and roles you define, you install an agent on each server or workstation to be managed.

Defining Rights and Roles Using Access Manager

When you install Verify Privilege Server Suite, you choose the components you want to enable. For identity and privilege management, the key component for administration is the Access Manager console. Although there are other ways to define and manage access rights, roles, and role assignments, Access Manager is the primary tool for managing all of the IBM Security software information stored in Active Directory. With Access Manager, you can:

Create and manage zones to control access to all of the computers you

support, including Windows, UNIX, Linux, and Mac OS X computers.
Set and modify specific types of access right for users and groups.
Add and customize the role definitions available in different zones,

including any time restrictions on when roles are available or cannot be

used.
Assign and manage roles for individual Active Directory user or Active

Directory groups.
Associate groups of computers that share a common function or attribute with

users who have a specific role assignment.
Generate and view reports describing the users, groups, computers, and

applications you are managing and which users and groups have access to

which computers.
View and manage licenses for servers and workstations.

Enforcement of Rights and Roles by the Agent

For identity and privilege management, the key component for deployment is the Agent for Windows. After you install the agent on a server or workstation and identify a zone for the computer to join, the computer becomes a IBM Security-managed computer. If you have enabled access management features for the agent, you can then define access rights and role-based policies to control what different sets of users can do on those computers in each zone.

After you deploy the Agent for Windows and select access management on a computer, the agent provides the following identity and privilege management features:

Users logging on to the computer must be assigned to a role that allows them

to log on.
Users who are assigned to a role with application rights can run a

specific application with elevated privileges.
Users who are assigned to a role with desktop rights can create new

Windows desktops that enables them to run all local applications with

elevated privileges.
Users who are assigned to a role with network access rights can connect

to network resources with elevated privileges.

The following illustration provides a simplified view of the components for identity and privilege management.

In this illustration, an Agent is installed on an individual user’s workstation and on a server accessed remotely. The administrative consoles that you use to manage zones, access rights, role definitions, and Active Directory accounts are installed on two separate computers. As shown in the illustration, all of these computers are part of an Active Directory domain and have access to an Active Directory domain controller. If you work with other platforms, the architecture is the same but you would have additional platform-specific agents.

To ensure that you can centrally manage access to Windows computers with the privilege elevation service and the Agent for Windows, you should check that your network meets a few basic requirements:

You have at least one Active Directory forest and domain controller.
All of the computers you want to manage must be joined to an Active

Directory domain and can communicate with an Active Directory domain

controller over the network or through a firewall.
You have a basic deployment plan in place that identifies your primary

goals, team members and responsibilities, and a target set of computers.

The Audit and Monitoring Service Infrastructure

The Audit and Monitoring Service is part of Verify Privilege Server Suite. The service captures detailed information about user activity on the computers you choose to audit.

Auditing Captures User Activity

After you deploy audit and monitoring service, the Agent for Windows captures all of the user activity on the computers you choose to audit. Depending on whether you enable identity and privilege management together with audit and monitoring service, or just audit and monitoring service on a computer, the agent starts recording user activity when a user selects a role or logs on to a computer and continues recording until the user logs out or the computer is locked because of inactivity. If you enable identity and privilege management together with audit and monitoring service on a computer, the agent records user activity when a role with audit and monitoring service is used. If you only enable audit and monitoring service on a computer, all user activity is captured by default.

Each record of continuous user activity is called a session, and starts as soon as users log on, whether they log on locally, using a Windows Remote Desktop connection, through a virtual network connection such as Citrix or VNC, or using any other type of remote access software. A session ends when the user logs out, disconnects, or is inactive long enough to lock the desktop. If the user reconnects to a disconnected desktop or unlocks the desktop, the agent resumes recording the user’s activity as a new session. Each session is a video record of everything that takes place on the user’s desktop during a period of user activity.

Auditing Requires a Scalable Architecture

To ensure scalability for large organizations and fault tolerance, audit and monitoring service has a multi-tier architecture that consists of the following layers:

Audited computers are the computers on which you want to monitor

activity. To be audited, the computer must have an agent installed, audit

features enabled, and be joined to an Active Directory domain.
Collectors are intermediate services that receive and compress the

captured activity from the agents on audited computers as it occurs. You

should establish at least two collectors to ensure that audit and monitoring

service is not interrupted. You can add collectors to your installation at

any time, and it is common to have multiple collectors to provide load

balancing and redundancy.
Audit stores define a scope for audit and monitoring service and include

the audit store databases that receive captured activity and audit trail

records from the collectors and store it for querying and playback. Audit

store databases also keep track of all the agents and collectors you deploy.

For scalability and network efficiency, you can have multiple audit stores

each with multiple databases.
A management database server is a computer that hosts the Microsoft SQL

Server instance with the audit management database. The management database

stores information about the overall installation, such as the scope of each

audit store, which audit store database is active, where there are attached

databases, the audit roles you create, and the permissions you define. The

management database enables centralized monitoring and reporting across all

audit stores, collectors, and audited computers.
Audit Manager and Audit Analyzer consoles are the graphical user

interfaces which administrators can use to configure and manage the

deployment of audit components, such as agents and collectors, or query and

review captured user sessions.
A reporting database collects data from audit stores and the management

database and saves the data in a format that is optimized for reporting.

With the reporting database, you can generate event notifications, such as

when an audited system goes offline.

To ensure that audit data transferred over the network is secure, communication between components is authenticated and encrypted.

In addition to these core components of the audit and monitoring service infrastructure, there is a separate Windows service that is optional to collect audit trail events when there are audit store databases that are not accessible, for example, because of network issues or the database server is shut down. This audit management service spools the events on the management database, then sends them to the audit store database when the inaccessible database comes back online.

How Audited Sessions are Collected and Stored

The agent on each audited computer captures user activity and forwards it to a collector on a Windows computer. If the agent cannot connect to a collector—for example, because all of the computers hosting the collector service for the agent are shut down for maintenance—the agent spools the session data locally and transfers it to a collector later. The collector sends the data to an audit store server, where the audit data is stored in the Microsoft SQL Server database that you have designated as the active audit store. As you accumulate data, you can add more SQL Server databases to the audit store to hold historical information or to change the database designated as the active audit store database.

When an administrator or auditor uses the Audit Analyzer console to request session data, the audit management server retrieves it from the appropriate audit store.

The following figure illustrates the basic architecture and flow of data with a minimum number of audit and monitoring service components installed.

In the illustration, each agent connects to one collector. In a production environment, you can configure agents to allow connections to additional collectors for redundancy and load balancing or to prevent connections between specific agents and collectors. You can also add audit stores and configure which connections are allowed or restricted. The size and complexity of the auditing infrastructure depends on how you want to optimize your network topology, how many computers you are audit and monitoring service, how much audit data you want to collect and store, and how long you plan to retain audit records.

Deploying the Audit and Monitoring Service Infrastructure

The multi-tiered architecture of audit and monitoring service requires that you deploy an audit and monitoring service infrastructure to transfer and store the information captured by agents on the audited computers. This auditing infrastructure is referred to collectively as an Auditing installation. The audit and monitoring service installation represents a logical boundary similar to an Active Directory forest or site. It encompasses all of the audit and monitoring service components you have installed—agents, collectors, audit stores, management database, and consoles—regardless of how they are distributed on your network. The installation also defines the scope of audit data available. All queries and reports are against the audit data contained within the installation boundary.

The most common deployment scenario is to have a single audit and monitoring service installation for an entire organization so that all audit data and management of the audit data is centralized. Within a single audit and monitoring service installation, you can have components wherever they are needed, as long as you have the appropriate network connections that allow them to communicate with each other. The audit data for the entire installation is available to users who have permission to query and view it using a console. For most organizations, having a single audit and monitoring service installation is a scalable solution that allows a “separation of duties” security model through the use of audit roles. If you establish a single audit and monitoring service installation, there will be one Master Auditor role for the entire organization, and that Master Auditor can control the audit data that others users and groups can see or respond to by defining roles that limit access rights and privileges.

However, if you have different lines of business with different audit policies, in different geographic locations, or with different administrative groups, you can configure them as separate audit and monitoring service installations. For example, if you have offices in North America and Hong Kong managed by two different IT teams—IT-US and IT-HK—you might want to create two installations to maintain your existing separation of duties for the ITUS and IT-HK teams.

Planning Where to Install Audit and Monitoring Service Components

Before you install audit and monitoring service components, you should develop a basic deployment plan for how you will distribute and manage the components that make up an installation. For example, you should decide how many collectors and audit stores to create and where to put them. You should also consider the network connections required and how many computers you plan to audit. For example, you can have multiple agents using the same set of collectors, but you should keep the collectors within one hop of the agents they serve and within one hop of the audit stores to which they transfer data.

By planning where to install components initially, you can determine the number of collectors you should have for load balancing or redundancy. After the initial deployment, you can add collectors and audit stores whenever and wherever they are needed.

Using Multiple Databases in an Audit Store

Each audit store uses Microsoft SQL Server to provide database services to the installation. When you configure the first audit store, you identify the database instance to use for audit and monitoring service and that database becomes the active database for storing incoming audit data. A single audit store, however, can have several databases attached to it. Attached databases store historical information and respond to queries from the management database. You can use the Audit Manager console to control the databases that are attached and to designate which database is active. Only one database can be active in an audit store at any given time.

Although the audit store can use multiple databases, the presentation of session data is not affected. If a session spans two or more databases that are attached to the audit store, the Audit Analyzer console presents the data as a single, unbroken session. For example, if you change the active database during a session, some of the session data is stored in the attached database that is no longer active and some of it stored in the newly activated database, but the session data plays back as a single session to the auditor.

Using Multiple Consoles in an Installation

A single audit installation always has a single audit management server and database. In most cases, however, you use more than one console to request data from the audit management database. The two most important consoles in an installation are the Audit Manager console and the Audit Analyzer console.

As an installation owner, you use the Audit Manager console to configure and

manage the audit installation. In most organizations, there is only one

Audit Manager console installed.
Auditors and administrators use the Audit Analyzer console to search,

retrieve, play back, and delete sessions. The auditor can use predefined

queries to find sessions or define new queries. Auditors can also choose

whether to share their queries with other auditors or keep them private. In

most organizations, there are multiple Audit Analyzer consoles installed.

In addition to the Audit Manager and Audit Analyzer consoles, audit and monitoring service includes a settings control panel and a collector control panel.

As an administrator, you can use the Audit & Monitoring Service

Settings control panel to configure the agent on Windows. Normal users who

log on and run applications on the audited computer cannot stop, pause,

restart, or configure the agent.
You can use the collector control panel to configure a collector.

The following illustration is an example of the architecture of a medium-size installation.

Basic Operation with Identity and Privilege Management, and Auditing

When you combine identity and privilege management together with auditing on the same computer, you have an audit trail and video record of actions performed with elevated privileges. For example, when you deploy identity and privilege management features, users must be assigned to a role with permission to log on. If they are allowed to log on and audit and monitoring service is deployed, the agent begins auditing their activity. If a user creates a new desktop, opens a protected application, or connects to services on a remote network server with administrative or service account privileges, the action is recorded and can be traced back to the account used to log on.

The following illustration provides a simplified view of the architecture and flow of data when you deploy components for identity management, privilege management, and auditing.

Although it is not depicted in the illustration, the audit trail records every successful or failed attempt to use a role, including the login role. You do not have to enable audit and monitoring service for a role to record this information. Every computer that has the Agent for Windows records the use of elevated privileges by default. If you do enable audit and monitoring service for a role, however, you can record all of the user activity after the user switches to the audited role. With audit and monitoring service enabled, the audit trail and the user activity are stored in the database and available for display and analysis anywhere you install the Audit Analyzer console. Without audit and monitoring service, the audit trail is only available in the Windows event log on the local computer where the activity took place.