This article introduces the 'optional' set of best practices for securing RIO systems. These are practices that many users should follow. The 'optional' practices require a little investment in time and cost, and provide more protection than the 'recommended' practices 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.
One security vector that's often overlooked is the media that one can plug and play on the host pc. Malicious code can be carried on USB drives, CDs, DVDs, and other portable media. Carefully managing the I/O on a host pc can be useful in denying attacks which originate from portable media devices.
For more information about disabling the USB ports, refer to How can I prevent users from connecting to a USB storage device? from Microsoft Support. For disabling the auto-run feature on CD-Drives, refer to How to disable the Autorun functionality in Windows from Microsoft Support.
In addition to carefully managing the I/O on the host pc, it's also meaningful to physically secure both the host pc and the RIO device. Physical access can allow determined attackers a direct avenue to disrupt or reverse-engineer your application.
Locate the host pc in a secure, access controlled room. Grant access to only those who need to use the host pc to limit physical access. Set policies to manage user interaction with the host pc to mitigate security risks.
For the RIO device, consider a locked enclosure to limit physical access. The console out, ip reset, and safe mode DIP switches provide vulnerabilities that attackers can otherwise exploit. In addition to enclosing the RIO device in a locked container, locate the device difficult to reach or restricted access environment.
In addition to taking the steps provided in the Recommended Best Practices article to mitigate network threats, it's useful to host the RIO device behind a VPN firewall. Given that the real-time operating systems used on RIO devices (Pharlap and ETS) don't have software firewalls, it's useful to have a VPN capable hardware firewall protecting the real-time controller.
A VPN capable firewall would enable secure deployment of code to the RIO device, secure access to the RIO device from an external network, and the ability to filter out unused ports and monitor network traffic to detect and prevent common attacks. One consideration in investing in a VPN firewall is that VPN is not a protocol itself, but is a concept. Different VPN firewalls rely on different protocols to achieve the security. Choosing an appropriate VPN firewall will depend on budget, security needs, and application needs.
Refer to Configuring Software and Hardware Firewalls to Support NI Products to understand which ports are used by NI hardware and software and which ports you can filter out.
Similar to implementing an FPGA watchdog over the real-time controller, it is meaningful to implement a status signal between the host pc and the real-time controller. Given that both the host pc and the real-time controller have the ability to alert a user over the network of a failure, it's useful to have each act as a watchdog over the other.
It's best to use an SSL enabled web service to pass a status signal from each device to the other. If the real-time controller doesn't receive the proper status signal from the host, or doesn't receive the signal in a timely manner, you can program it to alert the user and enter a 'safe state'. Similarly, you can program the host pc to alert the user and enter into a safe state if the proper status signal isn't sent from the real-time controller or if the signal doesn't arrive in a timely manner.
A simple technique to prevent basic attacks is to change default communication ports. Combined with a VPN capable hardware firewall, changing the default ports can provide an effective screen against many network based attacks.
If using an SSL enabled web service to transfer data between the host pc and real-time controller on the RIO device as detailed in the recommended best practices, you can change the SSL enabled application web server to a different port through the Web-based Configuration and Monitoring interface.
Refer to Configuring Software and Hardware Firewalls to Support NI Products to understand which ports can be changed.
The best practices presented here are meant to be employed by security-conscious users when developing a RIO system consisting of a host pc and a RIO device that has a real-time controller. More basic best-practices can be found at Best Practices for Security on RIO Systems: Part 1 Recommended. For additional security needs, please refer to the Extreme Best-Practices: Best Practices for Security on RIO Systems: Part 3 Extreme. 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.