Security in Aternity SaaS

Aternity's security extends to both the server side and the Agent for End User Devices installed on your end user devices, applying a broad set of methods across all access points in the system.

SteelCentral Aternity™ offers secure connections to monitored devices and to users of the system
Tip

For details about end user privacy, see how Aternity stores PII (personally identifiable information).

Aternity's security measures include:

Route Port Description

Agent for End User Devices collects and sends data to Aternity

443

The files (DLLs and EXEs) of the Agent for End User Devices are digitally signed to ensure no tampering. It also uses several anti-hack security measures, including ASLR (randomizing memory addresses), DEP (validating code is run from expected locations) and SEH (ensuring only valid exception handlers).

When sending data, the Agent reports securely to Aternity via HTTPS. The Agent uses TLS 1.1, or TLS 1.2 on devices with .NET 4.5 or later.

Agent setup

N/A

The Agent setup package is digitally signed to guarantee the files are genuine.

Secure installation of the Agent for End User Devices
Aternity Recorder

N/A

The Aternity Recorder located on a monitored device is only active when you gather data to create custom activities, and even then, it is only active on that device for the limited time during the actual recording, with the explicit approval and interaction of the user on that device for that time.

Alternatively, for maximum security, you can configure the setup of the Agent for End User Devices to exclude the Recorder entirely from all monitored devices. If you create your own custom activities, which require the Recorder to find the start and end events of an activity, you can designate a specific device to perform those recordings for that time.

Access to Aternity (local user or SSO)

443

Aternity SaaS users access securely via HTTPS (learn more).

Optionally, for complete control of the security of signing in, you can deploy SSO. Single Sign-On (SSO) brings the most secure access to Aternity by bypassing Aternity's sign in screen, and authenticating with your enterprise's chosen identity provider (IdP) just once using passwords, two-factor authentication (2FA), or even biometrics. Every time you access Aternity as an SSO user, it automatically reroutes you securely to the IdP, and then after authentication, it routes you back to your Aternity home page as a signed in user. SSO uses the secure SAML 2.0 protocol to delegate the entire authentication process to the IdP.

Learn more.

Access your Aternity homepage using SSO

Access to Aternity

Account administrator can decide who can or cannot access Aternity. In other words, from what IP addresses users can connect to Aternity. So, some IP addresses can be filtered and restricted to access Aternity. This way, you control who can see the data in Aternity dashboards.

This configuration can be done in Edit Acounts screen. You can define the allowed subnets or restrict access to residents only.

For more information and configuration, contact Aternity SaaS Administration.

REST API queries

443

Analysts can send REST API queries to view Aternity data directly via HTTPS (port 443).

Automatic emails

587 outbound

With Aternity SaaS, its email server comes automatically configured with Amazon's simple email service (SES).

Aternity sends emails via its configured email server

ServiceNOW

Determined by ServiceNOW server

Integrate Aternity with ServiceNow if you want to automatically route service desk alerts (SDA) to ServiceNow. Enter the details of accessing your ServiceNow, and also the username and password of a special 'service' user which is only for Aternity to send SDAs to the Riverbed SteelCentral Aternity App for ServiceNow.

Aternity communicates with the Aternity App for ServiceNow based on the settings of the ServiceNOW server.

Aternity can send service desk alerts in several formats, including directly to your ServiceNow

Automatic timeout

By default Aternity has an automatic timeout, logging you out if the session has been idle for more than 3.5 hours.