Best Practices for Security on RIO Systems: Part 1 Recommended

Overview

This article introduces the 'recommended' set of best practices for securing RIO systems. These are practices that most users should follow. The 'recommended' practices don't require an extensive investment in time or cost, and provide a lot of basic protection to RIO systems. Each best practice is organized into a separate section of this document. Links relevant to each of the recommended best practices, such as reference designs and knowledgebase articles, are presented within the section for each best practice. Each best practice will also be labelled with one of the following four tags to identify which layer as defined in the overview documentation is affected: [Network], [Physical], [OS], [Application]. This article is a part of the Best Practices for Security on RIO Systems documentation. You can return to the overview for this set documentation at: Overview of Best Practices for Security on RIO Systems.

Contents

Network Firewall [Network]

The first recommended best practice is to use a software or hardware firewall to protect the host pc in the RIO system. For maximum security, it's best to use both a hardware and a software firewall. To learn more about firewalls, refer to the following documentation:

Microsoft Knowledgebase: Designing a Windows Defender Firewall Strategy (Windows)

Operating System Updates and Accounts [OS]

In addition to setting up a network firewall, it's important to keep the operating system on the host pc updated with the latest security patches. For Windows systems, the Windows Update feature can be enabled to keep the operating system up to date. Refer to the following documentation:

Microsoft Knowledgebase: Windows Update

It's also important to setup and use a Standard User Account on Windows systems. If using the default Administrative account, intruders able to gain access to the operating system have the potential to do much more to the host pc. By setting up and using a Standard account, users are limited to the functionality they require. A Standard account would make it more difficult for an intruder to compromise the system. Refer to the following documentation:

Microsoft Knowledgebase: Create a local user or administrator account in Windows

Malware Protection [OS]

In addition to using a standard account and updating the operating system, it's useful to setup and run Anti-Virus software on the host pc. Anti-Virus software can detect and clean infections on the host pc. Refer to the following documentation:

Microsoft Knowledgebase: Stay protected with Windows Security

VI Passwords [Application]

Passwords can be set on VIs which contain sensitive data or important algorithms. By setting up good passwords on VIs, it makes it more difficult for attackers to infiltrate and compromise your application. VIs without passwords can be copied by attackers and analyzed to glean implementation algorithms or data, and can aid attackers in disrupting an application. 

To set a password on a VI, open the VI and navigate through File » VI Properties. In the dialog box that opens, select Protection from the drop down Category list. On this page, you can select Password-protected to set a password for the VI. 

Figure 2: Dialog for password-protecting a VI

Build EXEs [Application]

In addition to setting passwords, it's a recommended best practice to build both the host pc code and Real-Time code into EXEs. On the host pc, it's useful to remove the source code and rely solely on the EXE. This way, if an attacker gains access to the host pc, it will take far more work to steal or disrupt the host pc application. If the source code is present on the host pc, an attacker can potentially copy the exposed VIs and use the information to reverse-engineer the host side application or disrupt the host pc application. 

On the Real-Time controller, running the code as an RTEXE offers many security and performance benefits over running the real-time application in interactive mode. When the code is run in interactive mode, the host pc has development access to the RIO device. If an attacker is able to compromise the host pc, running a Real-Time application in interactive mode allows the attacker to very easily modify or disrupt the real-time application. Interactive mode also utilizes a lot more bandwidth on the network as there is a significant overhead in executing a real-time application in interactive mode. The increased network bandwidth used for interactive mode  provides a larger attack space for attackers as well.

To build the host pc code into an EXE, refer to the following LabVIEW help documentation:
Building a Stand-Alone Application

To build the real-time code into an RTEXE, refer to the following LabVIEW help documentation: 
Building a Stand-Alone Real-Time Application (RT Module)
.

VI Server Access [Network]

If VI Server is enabled, it's important to ensure that the permissions and settings are carefully managed to prevent unauthorized users from accessing and executing potentially malicious LabVIEW code on the host pc or real-time target. To access VI Server settings for the host pc, in the LabVIEW development environment, navigate through Tools » Options and select the VI Server category in the dialog that appears.

For the real-time controller, use the project explorer to access the VI server settings. First, add the RIO target to the project, then right-click on the real-time controller and select Properties as shown in Figure 2. You can then the select VI Server category and begin managing the VI Server settings with the dialog shown in Figure 3.

Figure 3: Accessing VI Server properties for a CompactRIO

 

Figure 4: VI Server configuration page

For more information on configuring the VI Server and using VI Server in applications, please refer to the following help documentation: 

Configuring the VI Server

Creating a VI Server Application

Security Settings [Network]

In addition to the VI server, it is also important to manage the security settings on the host pc and the connected RIO device. Security settings help secure access to a device via NI Measurement and Automation Explorer (MAX) and the Web Configuration and Monitoring tool. If your RIO device is unsecured, users can access and edit files on the device and reboot the device using the Web-based Configuration and Monitoring tool.  Users can also  install or uninstall drivers from an unsecured RIO device and reboot the device using MAX. It is critical to configure the Security settings of your system to prevent unauthorized use of MAX and the NI Web-base Configuration and Monitoring Tool.

Note: To enable NI-Web Based Configuration and Monitoring on a RIO device, you must have NI Web-based Configuration and Monitoring and NI System Configuration network support installed to the device.  

This document focuses on Linux RT devices and the default ports are 80 (HTTP), 443 (HTTPS). On Windows systems and some legacy RT targets the default ports are 3582 (HTTP) and 3581 (HTTPS). The easiest way to access and set a password is to use the Web-based Configuration and Monitoring interface. To reach the interface on the RIO device, open a web browser and navigate to http://<address>:<port> or http://<address>, where <address> is the IPv4 address or the host name of the RIO device. To reach the interface on the host PC, open a web browser and navigate to http://<address>:<port> or http://localhost:<port>, where <address> is the IPv4 address of the host PC. 

Figure 5: The NI Web-based Configuration and Monitoring interface to a RIO device

Once you have accessed the Web-based Configuration and Monitoring interface, select the gear icon at the top right, then the security option from the drop down menu. Login from the green banner at the top. You will be presented with a prompt to enter the user name and password. The default user name is "admin" and the default password is blank. 

Figure 6: The default login

After logging in using the default credentials, you will see the Users page. Change the default password for the admin account to something other than a blank password to prevent unauthorized users from gaining access. You can then create other user accounts and organize user accounts into groups. You can set permissions on a user and/or group basis. Ultimately, you want to use security settings to limit user and group access to the Web-based Configuration and Monitoring Tool based on their needs and responsibilities. 

Figure 7: Accessing the security configuration page

Enabling SSL [Network]

It's important to manage the transfer of data between the host PC and your RIO device. By default, data is passed between the host PC and the RIO device without encryption. If an unauthorized user gains access to the network between the host PC and the RIO device, they could use a network packet sniffer to easily read the data being passed between the host PC and RIO device. Furthermore, they could modify the data, or worse insert erroneous data. The recommended method to secure data between the host PC and the RIO device is to use an SSL enabled Web Service because communications between the devices will be encrypted. Note: To use SSL enabled Web Services, you must have NI Application Web Server, Run-Time Engine for Web Services, and SLL Support for LabVIEW RT installed to the RIO device. If you are using the RIO device to connect to an SSL enabled web service, you must also have HTTP Client and HTTP Client with SLL Support installed.

To enable SSL, navigate to the Web Configuration and Monitoring Tool as described in the security settings section. Select the Web server from the gear icon drop down menu and click the “SSL Enabled” checkbox. The System Web Server hosts the Web-based Configuration and Monitoring Tool. Securing the System Web Server secures all communications to the Web-based Configuration and Monitoring Tool, protecting information such as filenames and device locations when uploading or downloading files to/from the RIO device. The Application Web Server hosts your Web Services , and can be used to secure application data that you are passing between the host PC and the RIO device.

This article will not discuss how to build Web Services; please refer to Overview: Web-based Communication with a LabVIEW Application (Real-Time, Windows – LabVIEW Help) and Tutorial: Creating and Accessing a LabVIEW Web Service (Real-Time, Windows – LabVIEW Help) for more information about LabVIEW Web Services. 

Figure 8: Enabling SSL on the System and Application Web Servers

Refer to Securing the Web Server with SSL for more information on setting up an SSL enabled web service to securely transfer data between the host PC and RIO device.

Disable the open FTP Server [Network]

By default, there is an unsecured and open FTP server on VxWorks and Phar Lap RIO devices. Securing the FTP server prevents attackers from otherwise accessing, uploading to, downloading from, or modifying the file system on the RIO device. To ensure the FTP Server is shut down, you can make “Shutdown RT FTP Server VI” part of your startup routine in your RT application.

On NI Linux Real-Time devices, there is no unsecured FTP server by default.

Internal Network [Network]

If you are running a critical process with a RIO device, host the RIO device on an internal, protected network. This denies attackers easy network access to the RIO device. Exposing the RIO device to the Internet opens the door for many more attackers to assault the RIO system. 

FPGA Bounds Checking [Application]

Since the FPGA serves as a gate between all the real-world I/O and the Real-Time controller, it is meaningful to implement bounds checking on the FPGA. This way, if attackers are able to compromise the host pc or real-time applications and begin to send erroneous commands to the FPGA, you can still protect hardware and sensors downstream of the RIO device. By saturating outputs on the FPGA, you can ensure that the outputs fall within safe bounds such that hardware is not damaged. Implementing saturation and bounds checking will vary based on the hardware and sensors downstream of the FPGA. 

FPGA Safe States [Application]

In addition to implementing bounds checking on the FPGA, it is also useful to implement an FPGA watchdog over the Real-Time application. If there is an error in the Real-Time application, you can have the FPGA default to a "safe state". 

Please refer to Fail-Safe Control Reference Design for CompactRIO for an implementation of the FPGA watchdog functionality. 

Summary

The best practices presented here are meant to be employed by most users when developing a RIO system consisting of a host pc and a RIO device that has a real-time controller. The measures outlined here provide basic security on a number of layers in the RIO system. For additional security needs, please refer to the Optional Best-Practices: Best Practices for Security on RIO Systems: Part 2 Optional. You can return to the central site for best practices for security on RIO systems at: Overview of Best Practices for Security on RIO Systems.

Was this information helpful?

Yes

No