How to Configure Q-SYS with Security in Mind

Q-SYS Core firmware updates are the only mechanism for distributing security patches, security features, and other updates. (Q-SYS devices do not allow for “side-loading” firmware.) As a general rule, if security features and patches are important to the project, then the system administrator should keep the Q-SYS Core processors up to date with the latest firmware.

For instructions, see Installing and Updating Q-SYS Software and Firmware.

One of the most effective ways to protect the Q-SYS system is to enable Access Control on all Cores and peripheral devices.

• Refer to Core Manager > Access Management > Users for instructions on enabling Access Control and adding users.
• Refer to Core Manager > Access Management > Roles for instructions on creating custom role permissions for users.
• Refer to Peripheral Manager > Device Password for instructions on creating a Device Password, which protects basic settings such as the device's network configuration and host name.

Note: For Q-SYS Core processors based on Dell platforms featuring iDRAC (including the Core 610, Core 5200, and Core 6000 CXR), consider changing the default iDRAC root password to comply with your organization's standards.

Accurate time and date are important in secure network environments because security certificates use time and date in the certificate exchange. Incorrect time and date can result in security certificate negotiation failures. While it is possible to manually set the time and date on the Core and let the internal clock run, this is not recommended. Over time, the clock may drift enough to result in certificate negotiation issues.

QSC recommends configuring the Core to synchronize with a trusted NTP server. This can be a local NTP server available on the LAN or a web-based NTP server.

For instructions on setting the Core's time and date and enabling NTP synchronization, see the Core Manager > Network > Date & Time topic.

An effective way to protect all network-based resources is to restrict access to the network itself. This can be achieved by enabling 802.1X on the network, which is outside the scope of this document. However, in the event that the network is configured with 802.1X, connected Q-SYS components should be configured so that they can be authenticated and granted access to the network.

• For instructions on enabling 802.1X on the Q-SYS Core, see the Core Manager > Network > 802.1X topic.
• For instructions on enabling 802.1X for Q-SYS peripherals, see the Peripheral Manager > 802.1X topic.

Note: Q-SYS PTZ-IP cameras do not support 802.1X at this time.

If VoIP telephony (Softphone) will be used in the system design, QSC recommends only using encrypted Softphone communications and secure ciphers – assuming the third-party SIP infrastructure supports that. In Q-SYS Core Manager:

• Disable Insecure Ciphers
• Enable SRTP
• Enable TLS

For information about these options, see the Core Manager > Telephony > Softphones topic.

The optional FTP server on the Q-SYS Core is disabled by default and is not recommend for use in a secure environment. Due to the inherent security concerns with FTP, it is recommended to verify that it is disabled:

1. In a browser, go to http://core-ip-address/storage_config.html
2. Under the FTP Server section, make sure that the Enabled box is unselected.

The FTP server was deprecated in v9.3. See the What's New in Q-SYS 9.13 section for details.

By default, the SNMP server on the Core is disabled. In situations where SNMP monitoring of the Core and its attached peripherals is required, the user should consider implementing only SNMPv3 and follow the guidance of the InfoSec team responsible for the client network.

For instructions on configuring the SNMP server, see the Core Manager > Network > SNMP topic.

A Device Certificate allows other network resources (for example, web browsers) to confirm that the Q-SYS device is authorized by the IT department to be on the network. With the exception of Q-SYS PTZ-IP cameras, Device Certificates can be installed on all Cores and peripherals.

• For instructions on installing Device Certificates on Q-SYS Cores, see the Core Manager > Network > Certificates topic.
• For instructions on installing Device Certificates on Q-SYS peripherals, see the Peripheral Manager > Certificates topic.

Domain Name System (DNS) allows network devices to determine the IP address of a network resource derived from the URL (for example, www.qsys.com). DNS redirects can be used by bad actors to redirect traffic to compromised network resources. Therefore, it is important that only trusted DNS servers – provided by the client IT team – are specified in the Q-SYS Core's network configuration.

Note: DNS is required for access to Q-SYS Reflect, as well as online activation of perpetual software licenses on the Q-SYS Core.

For instructions on configuring DNS, see the Core Manager > Network > Basic topic.

In situations where an external control system is used to control or monitor the Q-SYS system, it is highly recommended that this integration leverages only secure methods. External control system access should also be protected by configuring a PIN for external control.

• Secure, encrypted external control of the Q-SYS Core is currently scope-limited to the Management APIs over HTTPS. All other external control communications are currently unencrypted.
• Create users (with PINs) in Q-SYS Administrator to control access for External Control. For instructions, see the Users (Administrator) topic.

For systems using Q-SYS User Control Interfaces (UCIs) where security is a high priority, it is recommended that UCI PINs be configured to ensure that only authorized users are able to access the UCIs. As an added layer of protection, a UCI can also be made private, which hides it from Windows and iOS UCI viewer applications.

• For instructions on setting up UCI PINs, see the Core Manager > User Control Interfaces topic.
• To flag a UCI as private, set the Private property to 'Yes' in the User Control Interface Properties in Q-SYS Designer Software. To learn more, see the User Control Interface (UCI) Design Overview topic.

  Note: Q-SYS Core Manager and Q-SYS Reflect do not currently honor the Private setting, so all UCIs will be available through those web interfaces.

If the system is leveraging the PA Paging functionality, particularly with Paging Stations that are installed in public spaces, it is highly recommended to set up PIN-based user access to the Paging Stations. Not only does this ensure that access to the PA system is restricted to authorized users, this also allows the system designer to tailor access to available paging commands based on the user.

Use Q-SYS Administrator to configure users for the PA system, including assigning PA system paging capabilities. For instructions, see the Users (Administrator) topic.

In consultation with the system designer, determine which network services are not required by the design running on the Core processor and can therefore be disabled on the Core. Use the Network Services manager in Core Manager to configure what network services are enabled or disabled for each of the Core's LAN adapters.

• To review a list of network services and their details, including ports and protocols, see the Network Interfaces, Services, & Protocols topic.
• See the Core Manager > Network > Services topic for instructions and use cases for disabling unneeded network services.

Registering the Q-SYS Core processor with Q-SYS Reflect will facilitate aggregated visibility and remote monitoring and management of all Q-SYS-based AV systems, including third-party devices.

During the registration process, consider the appropriate setting for the Maximum Reflect Access Level based on the risk profile of the customer and the amount of value desired from the Q-SYS Reflect service. As a general rule, the more restrictive this setting is, the better the Core is protected but the value of the service will be diminished. For the best experience, QSC recommends granting Q-SYS Reflect 'Administrator' access to the Core. It is then possible to use Q-SYS Reflect Users and Roles to define who has access to each Core and with what permission level.

• To get started with Q-SYS Reflect, see the Q-SYS Reflect topic.
• To learn how to register the Core with Q-SYS Reflect, including setting the Maximum Reflect Access Level, see the Core Manager > Reflect topic.
• To learn about access control in Reflect, see the Reflect Users and Roles topic in the Q-SYS Reflect Help online.