Session Recording and Playback
How much storage will I need for retaining session recordings?
SSH sessions take a few megabytes per hour.
RDP-session storage depends greatly on the circumstances, i.e. your screen resolution and how much data is processed and moved. Fullscreen video takes several gigabytes per hour (although this type of activity is not expected in most use cases), while administrative use with little animation on medium screen resolution takes approximately 100 megabytes per hour.
Assuming 5 connections per hour with medium resolution 600 MB per hour, around 5 gigabytes per day considering 8 hours day (business hour only) , around 100 gigabytes monthly and if recording needs to be kept for 12 months or so then somewhere around 1.2 TB will be needed. (all dependant on usage and retention needs).
The previous calculation is based on 5 active sessions Mon-Fri 8 hours daily but it could be more or less. Best approach will be to start with around 500 GB and monitor the growth for a few months to gain a more accurate view of the usage.
Where are session recordings stored and how are they secured?
Session recordings are stored in a NFS/EFS filesystem that you specify in the PrivX configuration, recordings are secured using a three-tiered mechanism:
- AES 128 and GCM based encryption
- Each trail file is secured with a unique key
- Each trail in turn within a trail file is also secured with a unique key
The master key is stored in the keyvault while the trail-specific keys are stored in the filesystem. Additionally, the trail-file names and dates are obfuscated on purpose, making it impossible to associate files to sessions.
What is the format of the recordings?
The recordings are native SSH/Guacamole (RDP) protocol streams.
Can the recordings be played on any other application?
No. We will most likely add the capability to download the recordings as video files through the PrivX UI later .
Who can access the recordings from PrivX?
Access to recordings can be granted via a special role. Furthermore, all members of the privx-admin role have access to recording by default.
Can anyone download the recordings from the stored location?
As a PrivX admin, you choose the directory/NFS mount where the trails should be stored by defining it in the PrivX configuration files. PrivX does not manage permissions nor monitor the changes in that directory. You must make sure that the directory is sufficiently protected against unauthorized access.
Are the recordings backed up by PrivX?
No. PrivX admin is responsible for configuring the directory/NFS mount where trails should be stored and ensuring that it is regularly backed up.
Can I move/playback recordings between PrivX deployments?
No. Each PrivX deployment has its own master key that is required for processing the encrypted trail files.
How do I share a specific recording to the audit team in my company?
Make sure everyone in the audit team has the role granting access to the recordings.
What happens if I open a SSH session on multiple browser tabs?
Each session is stored as a separate trail file. We are considering implementing a feature where we can merge the activities by timeline into a single trail file and introduce anomaly detection.
What happens to the ongoing recording when my access token expires?
Consequently, your session also expires, thus ending the recording. A new session will result in a new trail file.
How do I know if a recording has been tampered with?
There is a mechanism to check file tampering. The timing is user configurable, by default it is run once per day. When attempting to playback a tampered recording, UI will notify the PrivX admin about the fact. Such files can no longer be played back by PrivX. The recording sizes and checksums are stored in the database, file system and as audit events. Assuming audit events are propagated from the PrivX host to an external SIEM, the sizes & checksums can be compared against stored values at a later date. PrivX also sends out an audit event to syslog when an audit file has been opened.
What do I do if PrivX throws "Failed to audit" error?
This could be a sign that the designated NFS mount for storing trails is out of space or PrivX does not have sufficient permission to write to that location. Please check the syslogs to debug the situation.
What do I do if PrivX cannot play the recorded file for some reason? Is there a backdoor?
This could happen if the file has been deleted or has been tampered with. In either case, there is nothing one can do about it. There is no backdoor by design.
Is there a way to enable session recording by default when adding a host?
Yes, set tag
privx-enable-auditing=1 for a cloud host or use flag
audit_enabled in deploy script.
Can you separate user audit storage from session recording storage and file transfer storage?
Audit logs and file transfers share the same storage space, whilst recordings are stored separately. Logs are stored indefinitely however retention for recordings can be defined.
Updated about 1 year ago