Tightening Security for a Caché Instance

To provide increased security for a Caché instance, you can configure it to more tightly constrain user access. This can prevent unauthorized users from using Caché tools or from gaining access to sensitive resources. This appendix describes various actions that reduce the attack surface of a Caché instance or otherwise increase its security.

There are multiple actions for tightening an instance’s security. They are presented here roughly in the sequence in which they should be performed:

Important:

A Caché instance has many interdependent elements. Because of this, it is recommended that you only do what is specified for a change, and not more or less. For example, simply removing UnknownUser from the %All role — without doing anything else — will cause problems for a minimal-security installation.

Enabling Auditing

The primary elements of security are often described as the “Three A’s”: authentication, authorization, and auditing. Auditing, including the auditing provided with Caché, provides two functions:

It provides data about what has occurred if there is a security event.
The knowledge of its existence can be a deterrent for an attacker, given that the attack will be tracked and there will be evidence of any malicious actions.

To enable auditing for key events for a Caché instance, the procedure is:

From the Management Portal home page, select System Administration > Security > Auditing > Enable Auditing. If the choice is not available, auditing is already enabled.
From the Management Portal home page, go to Configure System Events page (System Administration > Security > Auditing > Configure System Events).
On the Configure System Events page, enable the following events if they are not already enabled by clicking Change Status in the event’s row:
- %System/%DirectMode/DirectMode — Provides information on console/terminal use. For sites that extensively use command-line utilities, can create large amounts of data. Recommended if increased data is not an issue.
- %System/%Login/Login — Provides information on logins. For large sites, can create large amounts of data. Recommended if increased data is not an issue.
- %System/%Login/LoginFailure — Provides feedback on possible attempted unauthorized logins. Recommended.
- %System/%Security/Protect — Provides data on attempts to read, write, or use protected data. Recommended.

Changing the Authentication Mechanism for an Application

A key element of restricting access to Caché is configuring the instance to use a stricter authentication mechanism for its applications. This section describes how to perform this procedure, using the Management Portal as an example application and with the change from unauthenticated access (as in a minimal-security installation) to requiring a password as an example of moving to a stricter authentication mechanism.

Important:

Performing the following procedure may affect aspects of the instance being modified beyond access to the Portal. The specifics depend on (1) the instance’s configuration and (2) whether you are performing just this procedure or all the procedures in this appendix. Specifically:

Making %Service_CSP:Use not public means that all users of web applications will need to be granted %Service_CSP:Use by some other means.
Removing UnknownUser from the %All role can have many effects.

To provide properly functioning authentication for an application, there must be consistent authentication mechanisms for both the application and any service that it uses. For a web application, the CSP Gateway must also be configured to match the CSP service. Hence, to provide authentication for the Management Portal, there are three layers that all need to work together:

The %Service_CSP service
The CSP Gateway
The Management Portal application

If these layers do not have matching authentication mechanisms, this usually results in a denial of access — for example, there may be a “This page cannot be displayed” error instead of a login page or access to the Management Portal.

Important:

If (1) a web application uses a more powerful authentication mechanism than the CSP Gateway and %Service_CSP and (2) authentication succeeds, then the system’s security is only that of the less powerful mechanism.

For an instance with a minimal-security installation, the CSP Gateway, %Service_CSP, and the Management Portal application are all set up for unauthenticated access. To provide password-level authentication for the Portal, various Caché elements must be configured as follows:

The CSP service must require password authentication.
The CSP Gateway must provide a username and password for that authentication.
The user representing the Gateway must have sufficient privilege to use the CSP service.
The Management Portal must require password authentication.
All the Portal’s users must have sufficient privilege to use the Portal.

Important:

Complete the following set of procedures during a single session in the Portal. Otherwise, you may lock yourself out of the Portal and have to perform the remaining procedures through the ^SECURITY routine.

An overview of the procedure to make these changes is:

Once this process is complete, then a user’s next attempt to connect to the Portal will result in a login prompt.

Caution:

A Caché instance has many interdependent elements. Because of this, it is recommended that you only do what is specified for a change, and not more or less. Otherwise, you may lock yourself out of Caché or could even render the instance temporarily inoperative.

Giving the %Service_CSP:Use Privilege to the CSPSystem User

The Caché installation process creates a CSPSystem user, which represents the CSP Gateway in its interactions with the %Service_CSP service. Since the service is going to have restricted access, this user needs to hold the %Service_CSP:Use privilege for the authentication process.

Note:

There is a service called %Service_CSP and a resource called %Service_CSP. The resource regulates access to the service. Therefore, to gain access to the service, a user must have Use permission for the resource — that is, the %Service_CSP:Use privilege.

To associate the %Service_CSP:Use privilege with the CSPSystem user, the procedure is:

From the Management Portal home page, go to the Roles page (System Administration > Security > Roles).
On the Roles page, click Create New Role. This displays the Edit Role page, where the Name field is editable.
Enter a name for the role to include the %Service_CSP:Use privilege (such as “GatewayRole”).
Click Save. Caché has now created the role.
In the Privileges section on the General tab of the Edit Role page, click Add, which displays a list of available resources for the role.
From this list, click %Service_CSP and then click Save. The newly created role now includes the %Service_CSP:Use privilege.
Select the Members tab of the Edit Role page.
On this tab, you can assign the CSPSystem user to the newly created role. Click CSPSystem from the users in the Available list and move it to the Selected by clicking the right arrow.
Click Assign to assign CSPSystem to the role. (In other words, CSPSystem is now a member of the role.) This means that CSPSystem holds the %Service_CSP:Use privilege.

Note:

The system creates the CSPSystem user to represent the CSP Gateway. If you prefer, a different user can perform this function. This procedure refers only to the CSPSystem user; if you use a different user, replace CSPSystem with that username where relevant.

Changing the Password of the CSPSystem User

Because a minimal-security installation gives the CSPSystem user a password of “SYS”, it is important to change this to a new password — one that an attacker would not know or be able to guess. The procedure is:

In the Management Portal, go to the Users page (System Administration > Security > Users).
On the Users page, in the row for the CSPSystem user, select the name CSP Gateway User. This displays the Edit User page.
Enter the new password for CSPSystem in the Password field. Since no user has to remember this password, you can make it as long and complex as you wish.
Reenter the new password in the Confirm Password field and click Save. If the Portal does not display an error message or dialog, then the password change has succeeded.

If you wish, you can also confirm that CSPSystem is assigned to the role created for authentication in the previous procedure. To do this, click on the Roles tab. The table with the column heading CSPSystem is Assigned to the Following Roles should list the newly-created role.

Configuring the CSP Gateway to Provide a Username and Password

Because you are going to configure %Service_CSP to require password authentication, the CSP Gateway needs to provide a username-password pair. Having set up a user with the appropriate level of privilege, you have established a username-password pair that the Gateway can provide. The next step is to configure the Gateway to provide this username-password pair when the Caché server challenges it for them. The procedure is:

In the Management Portal, go to the Caché Server Pages - Web Gateway Management page (System Administration > Configuration > CSP Gateway Management).
On the Caché Server Pages - Web Gateway Management page, select Server Access from the list on the left side. This displays the Server Access frame.
In the Server Access frame, the LOCAL server should be highlighted. Click Submit to edit it, which displays a page with Server Access and Error Pages parameters.
On this page, there is a Connection Security section.
Ensure that the Connection Security Level drop-down has “Password” displayed.
In the User Name field, enter CSPSystem.
In the Password and Password (Confirm) field, enter the password that you selected in the previous section.
Click Save Configuration near the bottom of the page.
To return to the Management Portal, click Back to Management Portal from the bottom of the list in the left pane.

Configuring %Service_CSP to Require Password Authentication

Now that the Gateway is configured to provide a username and password and you have given the CSPSystem user the necessary level of privilege, the next step is to configure the service that manages CSP (%Service_CSP) so that it requires password authentication. The procedure is:

From the Management Portal home page, go to the Services page (System Administration > Security > Services).
On the Services page, click %Service_CSP. This displays the Edit Service page for %Service_CSP.
On the Edit Service page, under Allowed Authentication Methods, make sure that Unauthenticated access is disabled and that Password access is enabled (also known as “Caché login”). Click Save.

Removing the Public Status of the %Service_CSP:Use Privilege

With %Service_CSP requiring password authentication and the Gateway able to authenticate with an appropriately authorized user, the next step is to exclude %Service_CSP:Use from public availability. The procedure is:

From the Management Portal home page, go to the Resources page (System Administration > Security > Resources).
On the Resources page, in the row for %Service_CSP, click Edit. This displays the Edit Resource page for %Service_CSP.
In the Public Permission section, clear the Use box. Click Save.

Important:

Once %Service_CSP:Use is not a public privilege, only those users who have been explicitly granted it will be able to use CSP. You may need to assemble a list of these users and grant them this privilege through other means.

Configuring the Management Portal to Accept Password Authentication Only

Once the connection between the Gateway and the Caché server has a new authentication mechanism, the next task is to configure the Management Portal application to use a matching mechanism. In this example, this mechanism is Caché login. The procedure for changing the Portal’s authentication mechanism is:

From the Management Portal home page, go to the Web Applications page (System Administration > Security > Applications > Web Applications).
On the Web Applications page, the /csp/sys application represents the Management Portal home page. Select the name /csp/sys in this row to edit the application. This displays the Edit Web Application page for the /csp/sys application.
Under Allowed Authentication Methods, disable Unauthenticated access and enable Password access. Click Save.
Also disable Unauthenticated access and enable Password access for all the applications that compose the other pages and choices of the Portal. These applications are:
- /csp/sys/bi
- /csp/sys/exp
- /csp/sys/mgr
- /csp/sys/op
- /csp/sys/sec

This configures the Portal to require password authentication (also known as “Caché login”) and not to allow unauthenticated access, and so that all its parts behave consistently. The next step is to ensure that all relevant users have appropriate access to the Portal.

Specifying the Appropriate Privilege Level for the Instance’s Users

When the Portal is configured to accept unauthenticated connections, any user can connect as the UnknownUser. Because a minimal-security installation makes UnknownUser a member of the %All role, there is no danger of being locked out of the Portal. Now that the Portal requires password authentication, its legitimate users need to be members of the %Operator role, the %Manager role, or the %All role.

In a minimal-security installation, SuperUser, Admin, _SYSTEM, and UnknownUser all have this level of privilege; further, these all have passwords of “SYS”.

To properly secure users, the procedure is:

Either disable UnknownUser or remove UnknownUser from the %All role.
- To disable UnknownUser, the procedure is:
  1. On the Users page (System Administration > Security > Users), click UnknownUser under the Name column. This displays the Edit User page for UnknownUser.
  2. Clear the User Enabled field and click Save.
- To remove UnknownUser from the %All role:
  1. On the Users page (System Administration > Security > Users), click UnknownUser under the Name column. This displays the Edit User page for UnknownUser.
  2. Go to the Roles tab on the Edit User page.
  3. In the UnknownUser is Assigned to the Following Roles table, on the %All row, click Remove, then click Save.
Important:

Limiting access through UnknownUser can have widespread effects, particularly if an instance’s users are not sufficiently privileged.
Ensure that any other potentially unauthorized users are not members of %All, %Developer, %Manager, %Operator, %SQL, or any user-defined role that grants privileges. This involves a process analogous to removing UnknownUser from the %All role.
(A user-defined role that grants privileges might have Use permission on any of the %Admin... resources, %Development, or any of the %Service or %System resources, or Write permission on %DB_CACHELIB or %DB_CACHESYS.)
Ensure that any user who should have access to the Portal is assigned to %All, %Developer, %Manager, %Operator, %SQL, or any user-defined role that grants Portal access. The procedure, for each of these users, is:
1. On the Users page (System Administration > Security > Users), click the name of the user under the Name column. This displays the Edit User page for that user.
2. Go to the Roles tab on the Edit User page.
3. Move the desired role(s) from the Available to the Selected list by selecting the role, clicking the right arrow button, and then clicking Assign to assign the user to the role(s).
Change the passwords for SuperUser and Admin users from the default. To do this:
1. On the Users page (System Administration > Security > Users), click the name of the user under the Name column. This displays the Edit User page for that user.
2. Select Enter new password.
3. Enter the new password in the Password field.
4. Confirm it in the Password (confirm) field and click Save.

Important:

Make sure that you know the password for at least one user who administers the Portal. Otherwise, you may lock yourself out of the Portal and have to log in using emergency access so that you can reset one or more passwords using the ^SECURITY routine.

Making the Documentation or Samples Available

Once you finish configuring the service, the CSP Gateway, and the Portal application, you may wish to ensure that the documentation or sample programs are available. The procedure is:

From the Management Portal home page, go to the Web Applications page (System Administration > Security > Applications > Web Applications).
To make the sample applications available:
1. On the Web Applications page, the /csp/samples application represents the Caché sample applications. Select /csp/samples in this row to edit the application. This displays the Edit Web Application page for the /csp/samples application.
2. Under Allowed Authentication Methods, disable Unauthenticated access and enable Password access. Click Save.
To make the documentation available:
1. On the Web Applications page, the /csp/docbook application represents the Caché DocBook documentation application. Select the name /csp/docbook to edit the application. This displays the Edit Web Application page for the /csp/docbook application.
2. Under Allowed Authentication Methods, disable Unauthenticated access and enable Password access. Click Save.
3. Return to the Web Applications page.
4. On the Web Applications page, the /csp/documatic application represents the Caché Documentation class reference application. Select /csp/documatic in this row to edit the application. This displays the Edit Web Application page for the /csp/documatic application.
5. Under Allowed Authentication Methods, disable Unauthenticated access and enable Password access. Click Save.
Note:

Because the documentation is compose of two individual applications — /csp/docbook and /csp/documatic — that are separate from each other and from the Portal, each has a separate password prompt.

If you do not perform this procedure, the service requires a password prompt but the application attempts to use unauthenticated access. This prevents all users — including those assigned to %All — from reaching the documentation or samples.

Beginning Enforcement of New Policies

At this point, the Caché instance is fully configured to operate properly. However, all existing connections are still using unauthenticated access. To begin enforcement of the new policies, the following events must occur:

Establishing an Authenticated CSP Gateway Connection

To force the CSP Gateway to establish an authenticated connection, the procedure is:

From the Management Portal home page, select System Administration > Configuration > CSP Gateway Management. This displays the Caché Server Pages - Web Gateway Management page.
On the Caché Server Pages - Web Gateway Management page, select Close Connections from the list on the left side. This displays the Close Connections frame.
Click Close Connection(s). This displays a message indicating that all connections between the Gateway and Caché server have been closed.

The next time that a user requests a page, the Gateway will reestablish a connection to the Caché server. This connection will use the selected authentication mechanism.

Establishing Authenticated User Connections

At this point, all connections to the Management Portal are still using unauthenticated access. If there is no pressing need to require authenticated access, then there is nothing else to do. Users will gradually end their connections to the Portal and will have to authenticate when they reconnect. (Connections may be ended due to machine reboots, stopping and restarting browsers, clearing browser caches, Portal logouts, etc.)

If there is a need to force connections to use authenticated access, you can stop and restart Caché. For example, on Windows, if you have Caché available through the default Start menu page:

From the Windows Start menu, select Programs > Caché, then the Caché instance to restart.
On the submenu for the instance of Caché, choose Stop Caché.
On the dialog that appears, select Restart and click OK.

Note:

If you are using a production instance of Caché, you may want to choose a low-traffic time for the restart, since users will temporarily not have access to either Caché as a whole or the Portal.

Limiting the Number of Public Resources

Any resource can be specified as a public resource. This means that any user has the ability to read, write, or use the resource, depending on its public settings. The following should always be public:

Required Public Resources and Their Permissions

Resource	Permission
%DB_CACHE	R
%DB_CACHELIB	R
%DB_CACHETEMP	RW

Note:

You may also want to make the Read permission on the %DB_DOCBOOK database public, so that all users have access to the documentation.

To tighten the security of an instance, limit the number of public resources. To do this, the procedure is:

Ensure that all users who genuinely require access to these resources have been given privileges for them.

Important:

If you do not provide privileges for %Service_CSP:Use to the appropriate users, then this procedure can result in a widespread lockout from the Management Portal and other CSP applications.
From the Management Portal home page, go to the Resources page (System Administration > Security > Resources).
On the Resources page, each resource for which there is one or more public permissions has those permissions listed in the Public Permissions column of the table of resources. Select the resource by clicking Edit. This displays the resource’s Edit Resource page.
On the Edit Resource page, clear any checked Public Permission fields and click Save. The resource is no longer public.

Perform this procedure for all public resources.

Restricting Access to Services

There are various pathways by which users can interact with Caché. Services regulate access to these pathways. To limit access to Caché services, the available choices are:

Limiting the number of enabled services to only those required for the applications in use
Limiting the number of public services to only those required for the applications in use
Restricting access to services by IP address or machine name

Limiting the Number of Enabled Services

To limit the number of enabled services, the procedure is:

Determine the required services for the Caché instance. Typically, these are:
- Whatever service is required for each form of user access
- Whatever services are required for any automated access
- Either %Service_Console (on Windows) or %Service_Terminal (on UNIX®), for local programmer-mode access
From the Management Portal home page, go to the Services page (System Administration > Security > Services).
On the Services page, for each service that is not required, select the service by clicking on its name. This displays the service’s Edit Service page.
On the Edit Service page, clear the Service Enabled field and click Save. The service is now disabled.

Once you have disabled all unnecessary services, the only pathways to Caché are the required services.

Limiting the Number of Public Services

Each service is associated with a resource. In most cases, the resource has the same name as the service, such as %Service_CSP; the exception to this is the %Service_Bindings service, which is associated with the %Service_Object and %Service_SQL resources. Services are public because of the settings for the resources associated with them. Because of this, the procedure for making a service non-public is the same as for making any other resource non-public. This is described in the section, “Limiting the Number of Public Resources.”

Restricting Access to Services by IP Address or Machine Name

For certain services, you have the option of restricting access to the service according to IP address or machine name. This is known as the ability to limit “allowed incoming connections.” The services that support this feature are:

%Service_Bindings
%Service_CSP
%Service_CacheDirect
%Service_ECP
%Service_Monitor
%Service_Shadow
%Service_Weblink

By default, a service accepts connections from all machines. If a service has no associated addresses or machine names, then it accepts connections from any machine. If one or more addresses or machine names are specified from which a service accepts connections, then the service only accepts connections from these machines.

This feature is not available for %Service_CallIn, %Service_ComPort, %Service_Console, %Service_DataCheck, %Service_Login, %Service_MSMActivate, %Service_Mirror, %Service_Telnet, and %Service_Terminal.

To restrict access to a service by IP address, the procedure is:

Determine the IP addresses of those machines with legitimate access to the service.
From the Management Portal home page, go to the Services page (System Administration > Security > Services).
On the Services page, for each service for which you are restricting access by IP address, select the service by clicking on its name. This displays the service’s Edit Service page.
On the Edit Service page, in the Allowed Incoming Connections section, click Add New.
In the displayed dialog, enter an IP address for an allowed incoming connection. Click OK.
Click Add and enter other addresses as needed.

Perform this procedure for each service that is restricting the IP addresses from which it accepts connections.

Restricting Public Privileges

Whenever any user logs in, that user receives all the privileges associated with the _PUBLIC user. With a minimal-security installation, the _PUBLIC user is not assigned to any roles, but holds a number of SQL privileges. These have been granted by the _SYSTEM user, which is created by the Caché installation in accordance with the SQL standard as the SQL root user. This means that they must be revoked by the _SYSTEM user.

To revoke SQL privileges from the _PUBLIC user, the procedure is:

Log into the Management Portal as the _SYSTEM user:
1. Enable the _SYSTEM user if that user is not already enabled. (After completing this procedure, you may wish to disable the _SYSTEM user according to the instructions in the section “Limiting the Number of Privileged Users.”)
2. For a minimal-security installation, change the authentication method for the Management Portal so that it requires logins. This is described in the section “Changing Authentication Methods for the Management Portal.”
3. Log in as _SYSTEM. In a minimal-security installation, the default password for this user is “SYS”; in normal and locked-down installations, the default password is whatever was selected during the installation process.
From the Management Portal home page, go to the Execute SQL Query page (System Explorer > SQL > Execute SQL Query) for the SAMPLES namespace. (On the Execute SQL Query page, from the list of namespaces on the left, click SAMPLES.)
Revoke all the _PUBLIC user’s privileges on tables in the SAMPLES database. In the page’s editing form, enter the following SQL command:
```
REVOKE ALL PRIVILEGES ON * FROM _PUBLIC
```
and click Execute Query.
Revoke all the _PUBLIC user’s privileges to invoke stored procedures in the SAMPLES database. In the page’s editing form, enter the following SQL command:
```
REVOKE EXECUTE ON * FROM _PUBLIC
```
and click Execute Query.
To prevent general use of the InterSystems documentation, you can revoke the _PUBLIC user’s privileges to search the DocBook database. To do this:
1. On the Execute SQL Query page, click DOCBOOK from the list of namespaces.
2. Select the SQL Tables tab.
3. In the page’s editing form, enter by the following SQL command:
```
REVOKE ALL PRIVILEGES ON * FROM _PUBLIC
```
  and click Execute Query.

Limiting the Number of Privileged Users

Every instance of Caché must have at least one user who is assigned to the %All role. In fact, if there is only one user assigned to this role, then Caché prevents the user from being removed from the role. However, over time, an instance can end up having more users assigned to %All than are necessary. This can arise from assigned users leaving an organization but their accounts not being disabled, from temporary assignments not being revoked, and so on.

Along with the %All role, the system-defined roles of %Manager, %Developer, %Operator, and %SQL can give users undue privilege. There also may be user-defined roles that do this. Users assigned to such roles are sometimes known as “privileged users.”

To limit the number of privileged users, determine which users are assigned to each privileged role and remove those who are not needed. The procedure is:

From the Management Portal home page, go to the Roles page (System Administration > Security > Roles).
On the Roles page, click the name of the role. This displays the Edit Role page for that role.
On the Edit Role page, click the Members tab, which displays a list of the users and roles assigned to the role.
To remove any user from the specified role, click Remove on the row for the user or role to be removed. Click OK in the confirmation dialog.

Perform this procedure for each privileged role, including %All and the others listed previously. It is also important to disable the _SYSTEM user; the procedure for this is described in the next section, “Disabling the _SYSTEM User.”

Important:

Certain seemingly non-privileged roles may have what could be called “privileges by proxy.” This occurs when a seemingly non-privileged role is assigned to a privileged role. In this case, any user who is assigned to role with privileges by proxy holds all the privileges associated with the privileged role.

Avoid creating privileges by proxy whenever possible. When not possible, have as few users as possible assigned to the roles with privileges by proxy.

Disabling the _SYSTEM User

The Caché installation program creates the _SYSTEM user. This user is created in accordance with the SQL standard as the SQL root user. In a minimal-security installation, the default password for this user is “SYS”; in normal and locked-down installations, the default password is whatever was selected during the installation process. Because this user and the password of “SYS” are both publicly specified by the SQL standard, and because of this user’s SQL privileges, disabling _SYSTEM is important for tightening access to a Caché instance.

To do this, the procedure is:

From the Management Portal home page, go to the Users page (System Administration > Security > Users)).
On the Users page, click the name _SYSTEM to open the Edit User page for _SYSTEM.
On the Edit User page for _SYSTEM, clear the User Enabled field. Click Save.

Note:

If you need to check root-level SQL privileges after disabling _SYSTEM, you will have to temporarily enable the user to perform the required action.

Restricting Access for UnknownUser

In instances that support unauthenticated access, connections that do not use authentication are established with the UnknownUser account. In minimal-security installations, the default behavior is that:

All connections use UnknownUser.
UnknownUser is assigned to the %All role.
UnknownUser holds all SQL privileges.

To restrict access for UnknownUser, disable unauthenticated access for all enabled services. (Other actions may not be effective or may result in a lockout from the Management Portal.)

Potential Lockout Issue with the UnknownUser Account

If an instance has been installed with Minimal security, UnknownUser has the %All role; the instance also has unauthenticated access available for all services and applications. If you simply change the user’s role (from %All to something else) and still allow unauthenticated access, you may be unable to use basic features.

This is because, under these conditions, Caché establishes a connection to the selected tool without performing authentication. When there is no authentication, the system automatically sets the user account to UnknownUser. The next step is to check user privileges. If UnknownUser has insufficient privileges, access to the tool is limited or not available. For example, under these circumstances, the Terminal displays an “Access Denied” message and then shuts down; the Portal displays its main page, but no options can be selected.

To correct this condition:

Start Caché in emergency access mode.
Restore sufficient privileges to the UnknownUser account.

If you wish to prevent use of UnknownUser, you must upgrade the authentication mechanism for the Management Portal.

Configuring Third-Party Software

InterSystems products often run alongside and interact with non-InterSystems tools, including virus scanners. For important information about the effects these interactions can have, see the appendix “Configuring Third-Party Software to Work in Conjunction with InterSystems Products” in the Caché System Administration Guide.