Overview of Best Practices for Security on RIO Systems

Publish Date: Nov 25, 2015 | 3 Ratings | 5.00 out of 5 |  PDF


This is the central site for security on the RIO platform from which you can access best practices, associated reference designs, and more. This article will introduce key concepts that form the foundation of security considerations on RIO systems. The related links contain lower-level articles which illustrate the best practices which can be used to better secure RIO systems.

Table of Contents

  1. Security Concerns on RIO Systems
  2. The Nature of Security on RIO Systems
  3. Best Practices for Security on RIO Systems

1. Security Concerns on RIO Systems

 While the application space for the RIO platform is expansive, security concerns with RIO systems can be more narrowly defined.

One key security concern is functional correctness, wherein the I/O of the RIO device is proper. This is a security concern because if functional correctness is compromised, the hardware that the RIO device is connected to can get damaged or malfunction. For example, failed products on an assembly line may pass if the I/O of the RIO device has been compromised, or alternatively, motors and centrifuges controlled by the RIO device may get permanently damaged if they are ramped improperly.

In addition to functional correctness, another key security concern is sensitive data protection. RIO devices often compute, carry, or transmit sensitive data. It's important to ensure that this data is properly protected. Besides the data itself, valuable algorithms are often programmed onto RIO devices as well. Keeping these algorithms safe from theft is also crucial.

The three key security concerns, functional correctness, sensitive data protection, and algorithm protection are seldom considered independently on a RIO system. Often, a compromise in one of these areas leads to a compromise of another.


Back to Top

2. The Nature of Security on RIO Systems

Security is a complex challenge regardless of the system. It's not a measure that can be addressed once and then forgotten. Security is something that must be continually managed. Additionally, definitions of secure can vastly differ, as such definitions are extremely application specific. Security, fundamentally, comes at a trade-off; more secure systems require greater time and cost investments and sacrifice ease of use.

Figure 1: The trade-off between security and time, cost, and ease of use

Given this trade-off, it's necessary to evaluate the proper investment in security for each application. The security required by an application will depend on the scope of the application and the potential risks that are associated. National Instruments recommends that you follow these best practices to help address the challenges that insecurity presents.


Layers of Security

Security can be defined at a number of different levels in most systems. For a RIO system, security can be defined at the following key levels: physical, network, operating system, and application. It's important to have some protection at each level, otherwise, a compromise in one layer can easily lead to a compromise in another. If you invest a lot of time and effort protecting one layer and fail to consider other layers, an intruder may find a way around the well protected layer and manage to compromise your system with little effort.

Given the four layers that pertain to RIO systems, it's meaningful to understand how they are related. The layers farthest away from the application are the physical and network layers. Security threats to a RIO system can emerge from these two layers. The next layer that is impacted is the operating system layer, which is the layer closest to the application. Lastly, the application layer resides at the core, and is what requires protection. Steps can be taken at each of the layers to ensure that the overall application is not compromised.

Figure 2: The layers of security important to RIO systems


Security Vectors on RIO Systems

A typical RIO system is comprised of a host pc and a RIO target, connected over a network, as illustrated in Figure 3. The host pc can be either the development or deployment machine, and in some cases these are the same. The network is often a private local area network (LAN), but can also be as simple as a crossover connection. As mentioned, threats to the RIO system can originate at the physical or network level. The targets can be either the host pc or the RIO device. It's thus important to consider both the threats that can affect the host pc and the RIO device, and not focus solely on the RIO device itself. To avoid redundancy, the best practices documentation will group the network between the host pc and the RIO with the threats to the RIO device and not with the threats to the host pc.

Figure 3: A typical RIO deployment system


Back to Top

3. Best Practices for Security on RIO Systems

The best practices for security on RIO systems are organized into three groups: recommended, optional, and extreme. The best practices presented online are not exhaustive; there are further measures that can be taken. To learn about some of the options for going beyond the best practices presented in these online articles, please contact National Instruments either through support or through your local sales or account representative.

The recommended practices should be adopted by all users before deploying the RIO system. The optional practices take more time and effort to implement, but provide the added security required by some applications. Lastly, the extreme section highlights a few measures that can be taken to further secure a RIO system. Note that the extreme measures require a significant investment in time and effort, and may not be appropriate for all applications.

Links to Best Practices

Best Practices for Security on RIO Systems: Part 1 Recommended

Best Practices for Security on RIO Systems: Part 2 Optional

Best Practices for Security on RIO Systems: Part 3 Extreme


Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No