Skip to main content
Version: 3.24

Session stages

Sessions are influenced in three main steps: Before, During, and After.

Each step allows different actions to be taken, giving greater control to the Administrator, traceability to the Auditor, vision to the Approver and usability to the Operator.

Actions Before a session

Before a session the Administrator has the control to decide several settings that determine how the operator will log in and take advantage of it:

  • Device connectivity: In addition to being used in Dashboards, connectivity testing, automated password exchange, and other modules, connectivity determines the type of proxy system that will be used to reach the device.

  • Credential activation control: As seen in the Executions module, the credential can be activated and inactivated on demand.

  • The password policy for exchange after session: As seen in the Executions module, the credential can be recycled after use in a proxy session.

  • The access group and workflow configuration: The credential usage workflow into a proxy session, as well as the possibility of emergencial use, is configured by the administrator in the access groups.

  • Macros and RemoteApp credentials: Macros and RemoteApps can be configured and made available on certain credentials.

  • Global and segregated audited commands: Audited commands for SSH sessions can be configured globally or segregated into Device, Credential, Access Group, or Origins. Action Triggers can be linked to commands, and if the command is executed, the action is taken.

  • Security levels per protocol: Each protocol can have version specifications, security level, and encryption algorithm. senhasegura allows the configuration of proxies systems and protocol-specific characteristics at the global and segregated level.

  • Ignoring certificate errors: RDP connections typically present certificate errors during the connection step. The administrator can force only valid certificates or ignore certificate errors at the connection handshake.

  • Session functionality: During the session the user can perform some actions such as transferring text, a file, pressing <Ctrl+Alt+Del>, performing an automated privilege elevation, etc. These actions can be allowed or blocked at the global or segregated level.

  • Indexing input and output texts: If the session requires auditing of the typed texts and displayed texts, you can configure whether this audit is to be recorded at the global level or segregated. By default this feature is disabled, we recommend enabling it only on credentials and devices that require it.

  • Allow wallpaper in RDP sessions: Some companies use custom wallpapers that contain device information, session or security policies. By default wallpaper transferring during RDP sessions is disabled to improve the RDP protocol performance.

  • Types of Linux and Xterm terminals: Some Linux systems have differences in use of client terminals using Linux or Xterm format. This is influenced by the handling of ANSI codes. You can segregate the device configuration for each terminal.

  • Use of personal credentials: Some devices may allow operator users to use personal credentials that are not managed by the platform, but that must still comply with other access, control, and audit rules. Under these scenarios we recommend that you do not index texts typed by the user.

  • Concurrent proxy sessions limit: Security policy can be changed to prevent a user from running more than a certain amount of proxy sessions simultaneously.

Actions During a session

During the session the operator user is passive to other functionalities that have been previously configured by the administrator, and other actions that can be immediately taken by the administrator.

The settings must be configured before a session starts. It set up several aspects of the session that cannot be reconfigured after the session starts.

For example

an audited command created or modified during a running SSH session will not be considered by the current sessions. Only new sessions after the creation of the command will be affected.

Actions that can occur during the session:

  • Execution of audited commands: As we have seen, audited commands that were previously registered will be considered during the session. If the operator executes these commands, the session will be scored with the risk level of the command and the administrators will be reported by SIEM messages. The operator user can still suffer a previously configured action linked to this audited command, such as prohibiting execution, interrupting the proxy session, or even inactivating its senhasegura account.

  • Evaluation of file transfer: Files that are transferred from both the operator's workstation to the target device and from the target device to the operator's workstation can be evaluated through plugins. The demand for these plugins should be forwarded to our Commercial team.

  • Session livestream: Administrators can perform a live view of the ongoing session without the operator's knowledge. From this preview window the administrator can make the decision to stop the user operator's interactivity. So, the operator will be notified that the interaction has been interrupted by an identified user, and cannot start new sessions until that lock is released. The preview and lock action are recorded in the session logs.

Note

Session livestream, is only available in the current server using the proxy session, not on other senhasegura cluster members. Logs and recorded videos are still available to every senhasegura cluster member.

  • Session interruption: The administrator may interrupt without user consent and without notice an ongoing session. This action will be recorded in the session logs.

  • Elevation of privilege in SSH sessions: During the SSH session the user operator can perform elevation of privilege through the SUDO binary. Thus, senhasegura will capture user interactivity and automate authentication without displaying the access credential password.

Actions After a session

Once the session is finished, the administrator user and the auditing user can observe the session details individually and observe the general table of sessions, credentials, and user behaviors. The credential used is available for blocking or recycling actions.

Actions are available:

  • Log session events: During the session, several actions may have occurred. All of these actions are available in the session logs.

  • Session video: Session recording can be played exactly as it occurred.

  • Audit request: The session can be forwarded for one or more users to evaluate the session. This request is made by e-mail and the session will be separated into an audit report. The user requesting the audit can write a short text explaining their reasons.

  • Purge Prevention: By default senhasegura will purge session files at a configurable interval. But when a session is protected from this purge, it will be available for as long as it takes.

  • Video export of the session: If necessary, you can export the session video in MP4 format for an external audit.

  • Risk assessment: Audited commands detected in the session add scores to the session. This score is reflected to the Device, Credential, and User operator. The administrator has a major overview of the risks involved in your business.

  • Text indexing: Text that was typed or presented in the session is available in a report that contains the text of all other sessions that have occurred. This allows the administrator to search for text that has appeared in a period of time on any device.

info

The texts entered will be mapped only in the language configured in the system parameters or parameters segregated during the session.