Skip to content
CA Application Performance Management - 10.3
Documentation powered by DocOps

Additional CEM Security Tasks

Last update November 21, 2016

In addition to CA EEM CEM and Local security authentication and authorization set-up tasks, you can learn about the CA CEM Security link and perform these additional CA CEM security tasks:

The tabs you see on the Security link depend on whether you have installed Introscope or CA APM and whether or not you are using CA EEM.

For example, you can always hide private parameters, regardless of your security solution. However, you can only restrict access to business services if you are using CA EEM for authentication and authorization. This table indicates what you see in the CEM console according to the security solution you have implemented.

Is this CA CEM tab visible? Introscope-only and CA EEM Introscope-only without CA EEM CA APM with CA EEM CA APM without CA EEM
Private Parameters Yes Yes Yes Yes
Access Policies Yes No Yes No
FIPS Settings No No Yes Yes

Defining private parameters

HTTP parameters are the name/value pairs used in HTTP. Common types of HTTP parameters are cookie, query, and post parameters. For more information about HTTP parameters in CA CEM, see the CA APM Transaction Definition Guide.

CA CEM records HTTP parameters as a part of the transaction recording and recognition processes. Normally all HTTP parameters appear for all transactions that are recorded.

CA CEM private parameters allow you to specify HTTP header information that must remain private. CA CEM private parameter values are not visible to the system or configuration administrators, nor to any CA CEM users. Only the end-user knows the value of the parameters.

Tip: Not all private parameter names are obvious (for example, password and pin versus field1 and field2). It is a good idea to review the HTTP parameters on test transactions to ensure that all private parameters are secured before viewing live transactions.

When a parameter is designated as private, the value appears as asterisks in the TIM log and wherever the value would appear in the CEM console.

You can generalize on patterns to match using a "*" wildcard character. The following wildcard strings are allowed:

  • abc* -- start matching
  • *xyz -- end matching
  • abc*xyz -- start and end matching
  • * -- if you create a parameter name pattern of only an asterisk, then all parameters will be private

For example, you might want to make "pin" more generic by adding an asterisk before it so that other entries like "userpin" or "login_pin" are recognized as private parameters.

Note: Only one "*" wildcard character is allowed per private parameter. Regular expressions (regex) cannot be used.

The default CA CEM private parameters are:

  • *access_id
  • pass
  • *passcode
  • pin
  • *password
  • pw
  • *ssn

Modifying a private parameter

Follow these steps to update an existing CA CEM private parameter.

Follow these steps:

  1. Select Security > Private Parameters.
  2. Click on the parameter name, for example, *password. The asterisk indicates that any number of characters can appear before the word password.
  3. Type in a different parameter for password collection. For example, if you know that the word password will always appear in your HTTP traffic without any characters in front of it, change the *password parameter to: password.
  4. Click Save to save the new private parameter.

Adding a private parameter

Follow these steps to create a new CA CEM private parameter.

Follow these steps:

  1. Select Security > Private Parameters.
  2. Click New to create a new private parameter.
  3. Type the private parameter that you need.
  4. Click Save to save the new private parameter.

Protecting HTTP requests and responses on defects

When a defect occurs, if you are logged in as a CA CEM user with permission to read sensitive data, you can see exactly what your user’s browser sent and exactly what was produced. In addition, if permitted, you can view query and post parameters and HTTP request and response body information.

By default, CA CEM users who belong to the CEM System Administrator or CEM Incident Analyst groups have permission to read sensitive data.

Viewing defect information

The defect details page provides various categories of information about the defect, including information about the user, the transaction, and web server. This procedure describes how to view specific HTTP parameter information that is captured for the defect.

Follow these steps:

  1. Select Incident Management > Defects.
  2. Click on the date and time for the defect you want to display.
    The HTTP Information area displays defect information specific to that user’s experience at the time of the defect, including:
    • Host, URL path, TCP port
    • Cookies
    • HTTP headers (except cookies)
    If permitted, you can also see or access this HTTP information on the defect details page:
    For more information about making this HTTP information visible, see Capture Comprehensive Defect Details for more information.
  3. To see the same page that the user was viewing when the defect occurred, you can cut and paste the RequestHeader Referer content into a browser.

About viewing request body information

Viewing the request body information can be helpful in understanding defects. POST requests have request bodies, although they might be empty. GET requests don’t have request bodies.

There are two things you need to know about viewing request body information:

Viewing not well formed XML/HTML

If the XML/HTML associated with the defect is not well formed, then the displayed request is blank or looks incomplete when you click the link to see the HTTP request body.

There is a workaround to display not well formed XML/HTML.

Note: To view any request body information (well-formed or not), the Capture Comprehensive Defect Details check box must be selected and you must have permission to read sensitive data.

Follow these steps:

  1. Select Incident Management > Defects.
  2. Click on the date and time for the defect you want to display.
  3. Right-click the RequestBody link and save the file.
  4. Use a text editor or HTML editor to view the full contents of the request body.

Changing the maximum size of request body information displayed

By default, the first 1,024 bytes of request body information can be viewed with a defect. If permitted, you can edit this value to view more or less information.

Follow these steps:

  1. Access the TIM Setup page.
    1. In the CEM console, select Setup, Monitors.
    2. Click the IP address of the TIM (far right column).
    3. Enter the user name and password.
    The default user name for the System Setup pages is admin.
    The TIM System Setup page appears.
  2. Click Configure TIM Settings.
    The TIM Settings page appears.
  3. Click MaxDefectRequestBodySize.
  4. In the New value field, enter the maximum size (in bytes) that you want to be able to view.
    Do not set this to a larger value than necessary. A large value takes more time for both the TIM and Enterprise Manager to process.
  5. Click Change.
    The change takes place immediately. There is no need to restart the TIM.
  6. If you have multiple TIMs, repeat the above steps for each TIM.

Limiting the display of defect information

You can limit the amount of defect information that appears using either (or both) of two methods:

  • Selecting to collect and view query and post parameters and request and response body information. See Capture Comprehensive Defect Details.
  • Setting specific private parameters to be hidden
    If the parameter name matches one of the private parameters, then post, query, cookie, and URL parameters will be hidden (that is, the value is replaced with "***").
    Using  private parameters, you can hide:
    • Specific parameters by providing the exact parameter name
    • Types of parameters by using a wildcard ("*") with a parameter name pattern
    • All parameters by creating a private parameter with "*" for the parameter name pattern, which means that all parameters are private

Capture Comprehensive Defect Details

The ability to view query and post parameters and request and response body information is disabled by default. If you have not selected the Capture Comprehensive Defect Details check box (on the Setup > Domain page), the TIMs do not capture the query and post information and request and response body information.

Important! If you have security concerns, do not change this default and consider making the Capture Comprehensive Defect Details check box unavailable even to the CEM System Administrator.

However, if you want users who can read sensitive data to be able to view this additional information for defects, select the Capture Comprehensive Defect Details check box.

To enable viewing of query, post, request body and response body information:

  1. Select Setup > Domain.
  2. Select Capture Comprehensive Defect Details.
    If the Capture Comprehensive Defect Details check box does not appear on the page, ensure that at least one TIM is listed on the Domain > Monitors page. (The TIM does not need to be enabled.)
    If the Capture Comprehensive Defect Details check box is unavailable, then if permitted, update the CA EEM or Local permission to make it available using one of these methods:
  3. Click Save.
  4. Synchronize the monitors.

    Note: If you are performing other CA CEM configuration, you might want to complete all your configuration tasks before performing the synchronization so you only have to synchronize the monitors once.

    After you synchronize the monitors, the TIMs begin collecting query and post information and request and response body information for defects. Then, users who have read sensitive data permission can see this data for defects that are captured after the monitors are synchronized.
    If you later deselect this check box, the information for defects that were collected while the box was selected can still be seen.

Making Capture Comprehensive Defect Details check box available or unavailable

By default, any user who belongs to the CEM System Administrator group can select the Capture Comprehensive Defect Details check box. This is because, by default, all members of the CEM System Administrator group have the System Configuration Settings capture comprehensive defect details body access policy.

You can give other users access the Capture Comprehensive Defect Details check box, by adding their groups to the System Configuration Settings capture comprehensive defect details access policy.

Note: At least one TIM must be listed on the Domain > Monitors page for the Capture Comprehensive Defect Details check box to appear on the Setup > Domain page.

Follow these steps:

  1. Follow the instructions in Update CEM Access Policies in EEM to edit the System Configuration Settings capture comprehensive defect details access policy.
    The administrative user or group that you add to the Selected Identities will be able to edit the Capture Comprehensive Defect Details check box -- the check box that allows all users who read sensitive data to see the additionally sensitive HTTP data (query and post information and request and response body information).
  2. Ensure that the user or group has write access for the System Configuration Settings resource class. (This gives the user permission to edit the Domain page.)
  3. Before saving the policy ensure that the capture comprehensive defect details Action is selected.
    The Access Policy Configuration policy has two actions associated with it. The write action and the capture comprehensive defect details action.
Important! Selecting the Capture Comprehensive Defect Details check box can allow CA CEM users to see some potentially sensitive data. If you want to make it extra difficult for this to happen, you can make the check box unavailable to all users, even the CEM System Administrators, who have access by default.

To make the Capture Comprehensive Defect Details check box unavailable:

  1. In the CEM console, ensure that the Capture Comprehensive Defect Details check box is not selected on the Setup > Domain page.
  2. Follow the instructions in Update CEM Access Policies in EEM to edit the System Configuration Settings capture comprehensive defect details access policy.
  3. Clear the capture comprehensive defect details check box and/or delete all entries in the Selected Identities list and save the capture comprehensive defect details access policy.
    If there are no policies with the capture comprehensive defect details Action selected, then no CA CEM users can enable the TIMs to capture of query and post information and request and response body information.

Changing the maximum size of the captured response body

By default, the first 10 KB of the response body can be captured. If you want to capture more or less of the response body, follow this procedure.

Follow these steps:

  1. Access the TIM Setup page.
    1. In the CEM console, select Setup, Monitors.
    2. Click the IP address of the TIM (far right column).
    3. Enter the user name and password.
    The default user name for the System Setup pages is admin.
    The TIM System Setup page appears.
  2. Click Configure TIM Settings.
    The TIM Settings page appears.
  3. Click MaxDefectResponseBodySize.
  4. In the New value field, enter the maximum size (in bytes) that you want to capture.
    The allowed range is between 0 and 200000 (~200 KB).
    Do not set this to a larger value than necessary. A large value takes more time to process and more space to store.
  5. Click Change.
    The change takes place immediately. There is no need to restart the TIM.
  6. If you have multiple TIMs, repeat the above steps for each TIM.

FIPS 140-2 compliant encryption

About FIPS 140-2

The Federal Information Processing Standards (FIPS) 140-2 publication specifies the security standard for the cryptographic libraries and algorithms that are used for the software product and protocol encryption.

Encryption affects these aspects of software security:

  • Storage and verification of passwords.
  • Communication and storage of all sensitive data that is sent between product components and between products.

About CA CEM and FIPS 140-2

Some modifications have been made to CA CEM to increase the security for FIPS 140-2 compliance:

  • Passwords for the email server are encrypted using the FIPS-compliant 128-bit AES and SHA algorithms.
  • The CA Unicenter Service Desk password is encrypted using the FIPS-compliant 128-bit AES algorithm.
  • You can store HTTP information that is contained in defects and user session IDs in the APM database in 128-bit encrypted format instead of in plain text. This HTTP information can be potentially sensitive data.
    HTTP information can contain confidential data such as user names, user session IDs, passwords, credit card numbers, and cookies. A user session ID can be used maliciously to hijack a user session.

FIPS 104-2 encryption features in CA CEM

This table summarizes the kinds of data that are, or can be, encrypted within the APM database. The passwords are encrypted by default.

The algorithms are FIPS certified Pure Java versions (jsafeFIPS) from the RSA Security Inc. Crypto-J 3.5 library.

Encryption of... Find on the UI... Optional? Encryption Type More Information
SMTP password System > Email Settings No FIPS-compliant AES CA APM Configuration and Administration Guide
HTTP information contained in defects, including request and response bodies CEM > Incident Management > Defects Yes FIPS-compliant AES Encrypting HTTP information in defects
User session ID User session IDs are only visible on the UI if displayed with the comprehensive details for a defect Yes FIPS-compliant AES Encrypting user session IDs

Encrypting HTTP information in defects

By default, HTTP information associated with defects is stored in plain text in the defect meta-values table in the APM database. If your organization has mandated use of FIPS 140-2 compliant software, follow the procedure below to encrypt HTTP information stored in the APM database. If captured, response and request bodies associated with defects are encrypted.

Even if the data is encrypted in the APM database, this information is unencrypted when displayed on the CEM > Incident Management > Defect details page.

A screen capture of the HTTP Information showing some response headers and a cookie. The response header information is not encrypted

Important! When you select or de-select encryption, all the HTTP information (stored in the defect meta-values table of the APM database) including http request and response bodies is deleted. This avoids having both plain and encrypted data together in the same database table.

Data in this table is not critical. By default, it is deleted weekly.

Follow these steps:

  1. Select Security > FIPS Settings.
  2. Click HTTP Defect Information.
    When you select or clear encryption, you receive a warning that all the HTTP defect information stored in the APM database will be deleted.
  3. Click Save.
    Previously stored HTTP information will be deleted, and, from now on, HTTP information for defects will be encrypted.

Encrypting user session IDs

By default, user session IDs are stored in plain text in the APM database. For FIPS 140-2 compatibility, you can choose to encrypt this information.

If your organization has mandated use of FIPS 140-2-compliant software, follow the procedure below to encrypt user session IDs stored in the APM database.

Important! When you select or de-select encryption, all the user session IDs (stored in the user session table in the APM database) are deleted. This avoids having both plain and encrypted data together in the same database table.

The implication of this deletion is that any users who are in the middle of a session, when the FIPS setting change is made, will be assigned to the unspecified user group. For this reason, CA Technologies recommends that you change FIPS settings when there is the least amount of user traffic on your system or when restarting the Enterprise Manager immediately after an upgrade.

Follow these steps:

  1. Select Security > FIPS Settings.
  2. Click User Session ID.
    When you select or clear encryption, you receive a warning that all the user session IDs will be deleted.
  3. Click Save.
    Previously stored user session IDs will be deleted, and, from now on, user session IDs will be encrypted.

Configuring TIM communication via HTTPS

By default, the TIMs and the Enterprise Manager that runs the TIM Collection service communicate via HTTP. However, for additional security, you can configure them to communicate using SSL over HTTP (HTTPS) instead.

This is done by adding a property named timTessCommunication.useSsl to the tess-customer.properties file on the Enterprise Manager running the TIM Collection service.

Using SSL may slow down communication between the Enterprise Manager and TIM, therefore consider this before applying this configuration. For example, do not apply it in the typical case where the Enterprise Manager and TIMs are within the same firewall.

However, consider applying it if the TIMs are outside the management VLAN such as in a DMZ (network demilitarized zone) or in non-secured environment where TIM data might be sent over a WAN (wide area network).

Follow these steps:

  1. Follow the instructions in IntroscopeEnterpriseManager.properties for modifying the Enterprise Manager property defaults.
  2. Open the tess-customer.properties file for editing and add this line:

    timTessCommunication.useSsl=1

    Setting the timTessCommunication.useSsl property to 1 configures the Enterprise Manager and TIM to communicate via HTTPS.

  3. Restart the Enterprise Manager.

Restricting Enterprise Manager access via HTTPS only

By default, HTTP communication is allowed between the browser and the Enterprise Manager. You configure the Enterprise Manager web server for HTTPS by setting the introscope.enterprisemanager.webserver.jetty.configurationFile property in the IntroscopeEnterpriseManager.properties file, which is located in the <EM_Home>\config directory.

Was this helpful?

Please log in to post comments.