Security recommendations

Session Recording is deployed within a secure network and accessed by administrators, and as such, is secure. Out-of-the-box deployment is simple and security features such as digital signing and encryption can be configured optionally.

Communication between Session Recording components is achieved through Internet Information Services (IIS) and Microsoft Message Queuing (MSMQ). IIS provides the web services communication link between Session Recording components. MSMQ provides a reliable data transport mechanism for sending recorded session data from the Session Recording Agent to the Session Recording Server.

Warning:

Editing the registry incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

Consider these security recommendations when planning your deployment:

• Ensure that you properly isolate the different administrator roles in the corporate network, in the Session Recording system, or on individual machines. By not doing so, security threats that can impact the system functionality or abuse the system might occur. We recommend that you assign different administrator roles to different persons or accounts. Do not allow general session users to have administrator privileges to the VDA system.
  • Citrix Virtual Apps and Desktops administrators do not grant VDA local administrator role to any users of published apps or desktops. If the local administrator role is a requirement, protect the Session Recording Agent components by using Windows mechanisms or third-party solutions.
  • Separately assign the Session Recording database administrator and Session Recording policy administrator.
  • We recommend that you do not assign VDA administrator privileges to general session users, especially when using Remote PC Access.
  • Session Recording Server local administration account must be strictly protected.
  • Control access to machines where the Session Recording Player is installed. If a user is not authorized for the Player role, do not grant that user local administrator role for any player machine. Disable anonymous access.
  • We recommend using a physical machine as a storage server for Session Recording.
• Session Recording records session graphics activities without regard to the sensitivity of the data. Under certain circumstances, sensitive data (including but not limited to user credentials, privacy information, and third-party screens) might be recorded unintentionally. Take the following measures to prevent risks:
  • Disable core memory dump for VDAs unless for specific troubleshooting cases. To disable core memory dump:
    1. Right-click My Computer, and then select Properties.
    2. Click the Advanced tab, and then under Startup and Recovery, click Settings.
    3. Under Write Debugging Information, select (none).
    See the Microsoft article at https://support.microsoft.com/en-us/kb/307973.
  • Session owners notify attendees that online meetings and remote assistance software might be recorded if a desktop session is being recorded.
  • Ensure that logon credentials or security information does not appear in all local and Web applications published or used inside the corporation. Otherwise, they are recorded by Session Recording.
  • Close any application that might expose sensitive information before switching to a remote ICA session.
  • We recommend only automatic authentication methods (for example, single sign-on, smartcard) for accessing published desktops or Software as a Service (SaaS) applications.
• Session Recording relies on certain hardware and hardware infrastructure (for example, corporate network devices, operation system) to function properly and to meet security needs. Take measures at the infrastructure levels to prevent damage or abuse to those infrastructures and make the Session Recording function secure and reliable.
  • Properly protect and keep network infrastructure supporting Session Recording available.
  • We recommend using a third-party security solution or Windows mechanism to protect Session Recording components. Session Recording components include:
    • On the Session Recording Server
      • Processes: SsRecStoragemanager.exe and SsRecAnalyticsService.exe
      • Services: CitrixSsRecStorageManager and CitrixSsRecAnalyticsService
      • All files in Session Recording Server installation folder
      • Registry values within HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Server
    • On the Session Recording Agent
      • Process: SsRecAgent.exe
      • Service: CitrixSmAudAgent
      • All files in Session Recording Agent installation folder
      • Registry values within HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SmartAuditor\Agent
• As a security best practice, Citrix recommends using HTTPS on IIS.

• Set the access control list (ACL) for Message Queuing (MSMQ) on the Session Recording Server to restrict VDA or VDI machines that can send MSMQ data to the Session Recording Server and prevent unauthorized machines from sending data to the Session Recording Server.

  1. Install server feature Directory Service Integration on each Session Recording Server and VDA or VDI machine where Session Recording is enabled. Then restart the Message Queuing service.
  2. From the Windows Start menu on each Session Recording Server, open Administrative Tools > Computer Management.
  3. Open Services and Applications > Message Queuing > Private Queues.

  4. Click the private queue citrixsmauddata to open the Properties page and select the Security tab.

     

  5. Add the computers or security groups of the VDAs that send MSMQ data to this server and grant them the Send Message permission.

     

• Properly protect the event log for the Session Record Server and Session Recording Agents. We recommend using a Windows or third-party remote logging solution to protect the event log or redirect the event log to the remote server.
• Ensure that servers running the Session Recording components are physically secure. If possible, lock these computers in a secure room to which only authorized personnel can gain direct access.
• Isolate servers running the Session Recording components on a separate subnet or domain.
• Protect the recorded session data from users accessing other servers by installing a firewall between the Session Recording Server and other servers.
• Keep the Session Recording Administration Server and SQL database up-to-date with the latest security updates from Microsoft.
• Restrict non-administrators from logging on to the administration machine.
• Strictly limit who is authorized to make recording policy changes and view recorded sessions.
• Install digital certificates, use the Session Recording file signing feature, and set up TLS communications in IIS.
• Set up MSMQ to use HTTPS as its transport. The way is to set the MSMQ protocol listed in Session Recording Agent Properties to HTTPS. For more information, see Troubleshoot MSMQ.

• Use TLS 1.1 or TLS 1.2 (recommended) and disable SSLv2, SSLv3, TLS 1.0 on the Session Recording Server and Session Recording Database.

• Disable RC4 cipher suites for TLS on the Session Recording Server and Session Recording Database:

  1. Using the Microsoft Group Policy Editor, navigate to Computer Configuration > Administrative Templates > Network > SSL Configuration Settings.
  2. Set the SSL Cipher Suite Order policy to Enabled. By default, this policy is set to Not Configured.  
  3. Remove any RC4 cipher suites.
• Use playback protection. Playback protection is a Session Recording feature that encrypts recorded files before they are downloaded to the Session Recording Player. By default, this option is enabled and is in Session Recording Server Properties.
• Follow NSIT guidance for cryptographic key lengths and cryptographic algorithms.

• Configure TLS 1.2 support for Session Recording.

  We recommend using TLS 1.2 as the communication protocol to ensure the end-to-end security of the Session Recording components.

  To configure TLS 1.2 support of Session Recording:

  1. Log on to the machine hosting the Session Recording Server. Install the proper SQL Server client component and driver, and set strong cryptography for .NET Framework (version 4 or later).
     1. Install the Microsoft ODBC Driver 11 (or a later version) for SQL Server.
     2. Apply the latest hotfix rollup of .NET Framework.
     3. Install ADO.NET - SqlClient based on your version of .NET Framework. For more information, see https://support.microsoft.com/en-us/kb/3135244.
     4. Add a DWORD value SchUseStrongCrypto = 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\v4.0.30319 and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319.
     5. Restart the machine.
  2. Log on to the machine hosting the Session Recording Policy Console. Apply the latest hotfix rollup of .NET Framework, and set strong cryptography for .NET Framework (version 4 or later). The method for setting strong cryptography is the same as substeps 1–4 and 1–5. You can omit these steps if you choose to install the Session Recording Policy Console on the same computer as the Session Recording Server.

To configure the TLS 1.2 support for SQL Server with versions earlier than 2016, see https://support.microsoft.com/en-us/kb/3135244. To use TLS 1.2, configure HTTPS as the communication protocol for the Session Recording components.