Session monitoring

You can configure Bravura Privilege session monitoring to use one or more collection modules :

When session monitoring is enabled, the smonprocessmeta program processes harvested data and inserts the data into the database in a series of batch operations. If a significant amount of data has been collected, this could result in significant work for the database. smonprocessmeta executes periodically while a session monitoring session is active. Text-based data such as keystroke, clipboard and UI data will not be available to search engines or in zip packages until smonprocessmeta is executed.

The smonsavemeta program creates session data packages when requested, and fires any additional utilities such as smonavi or another video generation utility. Screenshots are aggregated into hour-long video segments.

You can use the Manage the system > Modules > Session monitor menu to control:

Regular users, with appropriate permissions, use the Session monitor app to request and download recorded sessions of activity requiring privileged credentials. They may be able to access recorded data related to their own or another users’ activity. Depending on access controls, they may be able to search and view session data without approval, or via authorization workflow.

Click below to view a demonstration of setting up permissions and authorization for searching, viewing and downloading recorded sessions:

Click below to view a demonstration of viewing and downloading monitored sessions:

The Session monitor app is paired with smonc , which is the high performance CGI program that receives information from workstations .

The Session monitor app uses a powerful search engine to search recorded session data. You control various options for the search engine in the Manage the system > Modules > Session monitor menu.

You can control the range of data that users can search in the Recorded sessions request options tab. See Configuring recorded session access request options for details.

Recorded session data, depending on which recorded session modules are enabled, is compiled into a zip file when requested. The zip file to be downloaded is named as follows: <username> - <target computer name> - <CCYYMM-HHMMSS start time> .zip.

The zip archive includes a general.xml file, at its root, that contains general information about the recorded session; including:

The zip archive contains the following folders and files, depending on which data collection modules are enabled:

Carefully consider the consequences of enabling each of these modules. Enabling all modules would provide the most comprehensive session data; however, this would have the greatest potential impact on user privacy. For example, the web cam module can collect information from the users surroundings. If the user can access managed systems from uncontrolled environments, such as public places or their home, enabling this module may not be appropriate.

You can also tailor access to recorded session data depending upon security policy. For example, you may want to ensure that users know what is being monitored, when monitoring is active, and that they will be able to review recorded sessions of their own activity. Other security policies may require covert monitoring which can be enabled through configuration options. By default, covert monitoring is disabled. Review security and user monitoring policies before enabling covert monitoring.

In addition, Bravura Security Fabric , by default, restricts the screen-shot and keystroke-data-monitoring scope to the terminal only, to protect the privacy of the user; for example, when remote users or contractors are accessing monitored systems from public or personal computers, personal data and applications could also be active. This behavior is controlled by the SMON RESTRICT SCOPE setting, which can be applied globally or per managed system policy.

For disclosure options that allow session recording, having SMON RESTRICT SCOPE enabled would mean:

Disabling this setting allows you to monitor the user’s display and keystrokes on their whole system both inside and outside the terminal when they initiate a privileged session. This provides better security; for example, if a user starts remote desktop, they may be able to copy sensitive data from the remote terminal to an email or another application outside the terminal.

When deploying a session recording system, the first question is which sessions to record. There are several possibilities:

The cost and impact of session recording technology directly affects how this question is answered. If capturing more sessions is relatively inexpensive and does not noticeably slow down the work of the affected users, then it makes sense to record more sessions. Conversely, as the costs of capture, transmission and storage rise, the motivation to more carefully target what is and what is not recorded rises.

In the context of session recording of system administrators, Bravura Security recommends that all logins to sensitive accounts should be recorded.

In the context of session recording of high-risk business users – for example, HR staff or financial trader – Bravura Security recommends that all logins by those users, to any system, should be recorded.

Over time, as the cost of storage and bandwidth continue to decline, it may make sense to record all login sessions by all users to all systems.

Storage capacity requirements can vary greatly depending on:

Storage capacity requirements are also affected by the following session monitoring options:

The data that can be recorded from a graphical user interface is extensive. It includes:

At a minimum, when recording the login sessions of a user into an administrator-level account, it makes sense to capture what they typed and what the system displayed. This means video capture as well as capture of input from both the keyboard and copy buffer.

Regarding video capture, it may make sense to capture the user’s entire desktop, so that – in the event that the user downloaded a file with sensitive data to his computer – the recording will show what he then did with that file. For instance, if a sensitive file was briefly examined – as would be normal in the context of troubleshooting – and then deleted, the action can be taken to be innocuous. On the other hand, if a sensitive file was copied to a USB flash drive or sent to the user’s personal email account, the action can be interpreted as malicious.

Regarding input capture, it makes sense to capture both keyboard events and copy buffer contents. This is because the user may have constructed commands in advance and pasted them into the login session, without generating any keyboard events.

Finally, it may make sense to capture webcam video. This is useful in the event of serious misconduct leading to legal proceedings. When this happens, the user in question is likely to claim that the recorded actions were taken by someone else who stole their access. Webcam capture will show who was performing those actions.

The session monitoring service (idsmpg) attempts to keep a mutex on the recorded session file storage location . That storage location must be accessible to the application in general, and the incoming file updates must be available on that mutex.

For example, when a storage location is mounted as a share (\\server\location) without being assigned to a logical disk drive letter, the OS cannot signal to the session monitoring service when files are being written, so their metadata will not be processed.

When that happens, the sessions' data will not be available for viewing or downloading.

In such cases, smonprocessmeta can be executed manually or on a scheduled task.

Screen captures (including webcam captures), are the most intensive session recording both in terms of storage and network usage. For this reason, the following is an analysis of a variety of variables and how they affect the total storage and network usage.

Unless otherwise specified, Remote desktop / Remote APP RDP (pswxtsvc) is configured. Guacamole uses considerably less disk space, and is not directly analyzed here.

Resolution trend analysis

Resolution does not greatly affect the performance of sessions or their recordings.

The maximum dimension supported is 1280 x 720.

Color depth comparison

By default, sessions are recorded at 32-bit color depth. This can be reduced to 16-bit, and will reduce the raw disk space required by approximately 60%. The compressed disk space, however, will be only slightly less than that of 32-bit.

Frame rate trend analysis

The frame rate directly affects how much storage is required. When the frame rate is doubled (twice as many screenshots are taken per second), the storage required is roughly doubled as well.

Restricted scope comparison

When restricted scope is disabled, more than one monitor can be recorded per session. In this case, the storage is directly proportional to the increase in the area recorded.

The storage required is doubled when two monitors are recorded instead of one, assuming the same frame height and width for both monitors.

Concurrent session trend analysis

The amount of storage required is directly related to the number of sessions being recorded. Recording 100 sessions will require 10 times more storage than recording 10 sessions.

Usage trend

Storage required is strongly related to activity within a session. Activity can range from being idle (0%, where nothing on the screen changes) to constant changes (100%, such as watching a video or running a living screen-saver).

The average user will likely use no more than 10-20%. However, since it is difficult to guess what is changing on a user’s screen, a sample of routine sessions should be measured.

Case studies

Assuming the following:

The following formula can be used to estimate the storage required for raw video:

S = N * (0.5 * A + 2.2)

where

S = Storage in MB/min

N = total sessions

A = percentage of screen activity

Forensic audits

In the event that an IT user is under suspicion or has been found to act unethically or illegally, it is helpful to be able to play back all of that user’s activity, to see what inappropriate actions they may have taken. This data may be required as supporting evidence if the user must be terminated and may be needed in the course of legal proceedings thereafter. This data may also be needed to find and reverse any harmful changes the user has made to systems or data.

In this case, you may consider capturing video data for all IT staff only.

Assuming there are 100 staff in the IT department, and each runs one 8-hour session per day, with 10% screen activity, use the equation above to determine the storage required for 1 year:

S = N * (0.5 * A + 2.2) MB/min
= 100 * (0.5 * 0.1 + 2.2) MB/min
= 225 MB/min
= 225 MB/min * 60 min/hr * 8 hr/day * 220 work days/year
= 23760000 MB/year
= 23760 GB/year

Load balancing considerations

It is recommended that you provision several load balancing replicated servers accessible by a single URL. Multiple replicated servers are required to carry the data load created by the monitored sessions and ensure a quality service. A single URL simplifies configuration and failover situations if a monitoring server needs to be taken down for maintenance or replaced.

Note that an end user needs to be able to access both the direct URL of the server and the load-balanced URL in order to download packages containing video data. When the user attempts to download a session, Bravura Privilege uses the direct URL (not the load-balancing one) to trigger the downloading of the package to the user’s workstation. This means that the user must be able to connect to the direct Bravura Privilege URL using their browser, without it being blocked by a firewall.

Before configuring session monitoring options, you should:

It is recommended that you plan how you will implement session monitoring .

To configure session monitoring options click Manage the system > Privileged access > Options to configure global options, or click Manage the system > Privileged access > Managed system policies > <Policy> > Options to configure policy-level options

To configure web module options click Manage the system > Modules > Session monitor for:

As long as you have prepared your system to meet the requirements listed on on the current page, you can get started with testing the session monitoring feature by setting the following on the Recorded sessions tab:

The default SMON HTTP URL is <BASE IDSYNCH URL>/<virtualdirectory>/smonc.exe. The BASE IDSYNCH URL is set at Manage the system > Workflow > Email configuration .

The following sections describe these options and more in detail.

The following settings affect messages displayed to users when certain events occur when session monitoring is initiated:

If you have trouble connecting to the monitoring server when initiating a session, try using the process explorer program, procexp.exe, to analyze processes on the system. You can download this program from live.sysinternals.com.

If you have trouble connecting to the monitoring server when initiating a session, try using the logutil program to collect logging information from the ActiveX controls. To do this, run the following command on the system where the ActiveX controls are being run from:

logutil.exe -instance "PPM Client ActiveX Controls" -level 6 -maxdelay 2 -makekey

Confirm the URL used in the connection. Most connection failures are the result of a misconfiguration in the URL, SSL, certificate validation, or proxy settings.

If the SMON HTTP URL is incorrect, the ActiveX controls will not be able to connect to the server, and as a result, will not allow the remote connection to the managed resource to proceed.

When a client using pswxcmd or pswxtsvc cannot communicate with the server via the SMON HTTP URL, the following message is displayed on the client:

"Failed to connect to Bravura Security Fabric server. Please contact the Bravura Security Fabric administrator."

Fix the URL so that it resolves for all client workstations. You can test it by copying and pasting the value into the web browser location field in the web browser. If a page loads with an encrypted blob then it worked (encrypted blobs start with {AES} ). Typical errors would be: server not found, or 404 Page Not Found.

The server not found error means the first part of the SMON HTTP URL does not resolve correctly; the hostname or IP of the server is not accessible from client.

The 404 Page Not Found error typically means that the wrong hostname or IP was used (it went to a web server other than the one with the Bravura Security Fabric instance installed). It could also hint that the virtual directory is incorrect, or that HTTP/HTTPS is incorrectly specified. The virtual directory is set during setup.

In order to download a session package, the client workstation must be able to resolve the URL of the server on which the package was created. If clients connect to the server using a load balancer, the client may not be able to download the package.

Alternatively, you can provide a separate, externally addressable name of the server.

The key stroke capture module records keys pressed during a session. When process-specific monitoring is enabled, only the keys pressed in the target process window are recorded. When full system monitoring is enabled, all key strokes are captured.

To enable Bravura Privilege to record keys that were pressed during a session, configure the following in the Recorded sessions options tab:

The information is compiled into a keystroke-data.xml file in the directory set by Manage the system > Modules > Session monitor > SMON TEXT STORAGE PATH.

The following options on the Recorded sessions tab control which keystroke types generate new events:

The screen capture module can take periodic screenshots of either the target process, in the case of process-specific monitoring , or the entire desktop, in the case of full system monitoring.

The module is able to handle multiple monitors, the removal and addition of monitors during recording, and screen savers.

To enable Bravura Privilege to periodically capture screenshots during a session, configure the following in the Recorded sessions options tab:

To help limit storage and network bandwidth requirements, screenshots are aggregated into hour-long videos, which are stored in the path set by Manage the system > Modules > Session monitor > SMON SCREENSHOT STORAGE PATH.

The user interface meta data recording module provides meta data that you can use to enhance the data collection abilities of other modules.

To enable Bravura Privilege to gather data from user interface elements during a session, configure the following in the Recorded sessions options tab:

The information is compiled into ui-editable-data.xml, ui-focusable-data.xml, and ui-title-data.xml files in the directory set by Manage the system > Modules > Recorded session management > SMON TEXT STORAGE PATH.

The clipboard capture module collects copy/paste information during a privileged session.

To enable Bravura Privilege to capture clipboard data during a session, configure the following in the Recorded sessions options tab:

The information is compiled into a clipboard-data.xml file in the directory set by Manage the system > Modules > Session monitor > SMON TEXT STORAGE PATH.

To enable Bravura Privilege to periodically capture still images from any attached webcams during a session, configure the following in the Recorded sessions options tab:

The webcam images are stored in the directory path set by Manage the system > Modules > Recorded session management > SMON WEBCAM STORAGE PATH.

See also

When an auditor or someone with appropriate privileges requests a session recording package, the package is stored in the SMON PACKAGE STORAGE PATH on the Bravura Security Fabric server where that auditor's WebUI session is running. When that created package is downloaded during a WebUI session connected to other servers, Cross-origin resource sharing (CORS) must be configured in order for the downloader's browser to allow retrieval of the compiled video or recording archive. You configure CORS by listing ALLOWED ORIGINS (Manage the system > Maintenance > System variables). Enter a comma-separated list of node-specific URLs of all the user-accessible nodes (see example below).

CORS blocks the retrieval operation -- the HTTP(s) request going to a different server than the one where the rest of the current WebUI is rendered. It is not required for search, nor for viewing recorded session metadata that's loaded in the backend database tables after the session is closed and processed by smonprocessmeta .

The following is an example of the process in detail:

For replicated instances, ensure that:

The file storage needs to allow the WebUI of all nodes to reach all files from each of them, so that disaster recovery can happen fast, without having to move large amounts of data.

The recommended storage method may be more complicated when nodes from different data centers need to reach it.

At "write" time, the latencies and access delays between data centers need to be as small as possible. The smonc CGI that writes the files needs to serialize the writes, and a slow write can be interpreted by the Operating system as a failed write even if it succeeds.

The memory footprint and duration of execution of smonc can increase if it has to "buffer" the writing of the "frames" it receives from the disclosure plugins.

IIS has a limited number of CGI threads that it can keep active at any given time. Any dropped "frames" in the recording tend to interrupt the recording, and with it, the recorded session.

A large number of concomitant sessions sending data to the same Privilege node can overwhelm the node's IIS with incoming calls. If this issue affects your instance, consider reducing the frame rate of the recording or the size of the captured "frames".

The following is a description of the recording process, as illustrated in Session monitoring architecture . This is useful when checking the application logs for issues.

Do not configure the session data storage on the same drive or partition where the application is installed, to prevent it from running out of space and going into DB COMMIT SUSPEND mode.

The text data captured (keyboard and clipboard data), is tiny in comparison with screenshots and packages (zip files) containing videos compiled from those screenshots.

The text data is stored only temporarily on disk; after smonprocessmeta runs, that data is removed and kept only in the application's backend database.

See Screen capture trend analysis for formulas for deciding how much space to set aside in the storage locations for screenshots.

The session monitoring service uses a mutex on the storage location to determine when new files are saved. If the storage method doesn't update the application's mutex when files are being added, smonprocessmeta won't run. If that issue cannot be solved at the operating system level, smonprocessmeta must be scheduled separately to run (every 5 minutes or on the customer-required schedule), in a Windows Scheduler Task similar to the default ones which provide healthcheck monitoring and external database replication.

If there is an issue with session recording or processing:

If the recommended configuration was followed, when a replicated node becomes unavailable, the data it collected will still be available on the shared storage location.

See the Replication and Recovery documentation for more information on recovery.

In this use case, Bravura Privilege is actively managing the credentials for a privileged financial application running on a Oracle server database normally only accessible by high-level employees in the Finance department.

A problem has occurred on the system that requires investigation by an Oracle server administrator. In order to diagnose the issue, the Oracle server administrator requires system access. System access leaves the sensitive financial information vulnerable.

In order to ensure that any attempts to view and/or copy the sensitive information are recorded, the company has deployed session monitoring for this resource.

The process flows as follows:

Since all information regarding the session's activities was recorded, it is possible for an auditor to view the session to ensure that the administrator was not stealing information.

In this situation, a rogue administrator – who is aware of the fact that session monitoring is installed – attempts to prevent recording in order to perform illicit activities:

In this situation, a security breach has been detected on a protected resource. The security investigation team knows that the breach occurred over the past month, but a number of people have had access to the server. The breach consisted of the release of three bank account numbers.

Because the resource was protected with session monitoring, the security investigation team can track down the source of the security breach:

Click below to view a demonstration:

This example demonstrates how to enable session monitoring and restrict the scope of the session recording so that only the Remote Desktop session is recorded; not the user's desktop.

Requirements

This example assumes:

In order to configure and enable session monitoring, the Scenario.pam_sessmon_full component must be installed. To install the component:

When session monitoring is enabled, it records any visible desktop around the open RDP session by default. This could be a privacy issue.

To restrict the recording only to monitor screens within the RDP session:

When onboarding managed accounts, the option to include session monitoring is offered. In this example they were not turned on when accounts were onboarded. To enable these session monitoring options for Windows managed accounts, the existing managed accounts must be modified using the team trustee.

Click below to view a demonstration:

This example demonstrates how users request to check out a monitored account, approve the request and then check out the account using the remote desktop disclosure option.