Securing connected embedded devices using built-in RTOS security

In high-threat military environments, it is mandatory that connected devices have built-in security. Moreover, these devices must comply with security standards before they can be connected. Since much of the function of these devices is defined in software – including the security access controls – it makes sense that much of this security should be built into the software, specifically into the operating systems that control the operation of the software. All of this calls for a secure operating system, or more specifically for embedded systems, a secure real-time operating system (RTOS). The military has been using secure OSs for years, and many of them have been used only for Department of Defense (DoD) deployments. As the DoD has moved towards commercial-off-the-shelf (COTS) hardware and software solutions to reduce cost, however, the need for security to be built into COTS operating systems has emerged.

The secure RTOS was initially built to meet the needs of military deployed systems, but is now available to any industry that requires security functionality for its connected systems. New cyber attacks are particularly worrying to any industry that is in some way connected to human life; a recent report from U.S. security firm IID predicted the first murder via “hacked Internet-connected device” would happen by the end of 2014. Potentially vulnerable industries include critical infrastructure/industrial-control systems, connected medical devices, connected vehicles, and even smart homes.

Embedded systems have traditionally been less exposed to cyber attacks than mainstream computer systems, in part due to the proprietary nature of the RTOS and software that runs on these systems. Additionally, because many of our embedded systems have been connected to proprietary networks as opposed to the Internet, and therefore are less available to cyber attacks. However, the Stuxnet Worm –the computer worm that was discovered in 2010 – is a good example of how these proprietary embedded systems can still be attacked. In the Stuxnet attack, a microcontroller system connected to a proprietary network in a locked-down facility in Iran was subverted and controlled by the computer virus targeted specifically at this application, using traditional malware techniques such as phishing emails and USB sticks to reach its intended target.

If a microcontroller system in a locked-down facility in Iran can get cyber attacked, then what can be done to stop this sort of cyber terrorism being used to attack all sorts of connected embedded systems?

Security built into system

The use of a military-grade secure RTOS is a very good starting point; this type of RTOS builds security into the system at the lowest level and can help prevent attacks at the point of entry, whether the network or other physical devices. This secure RTOS introduces a number of key security concepts that help the OS protect against malicious attacks, regardless of how they enter the system. An RTOS with these built-in security features is the best protection for the embedded connected device, as it still offers the real-time characteristics, supports the required network functionality, and typically has a smaller footprint than a general purpose OS like . An RTOS with built-in security also offers advanced security protection including discretionary access control for file-system objects, fine-grained user-access control using roles and capabilities, identification and authentication control of users, device and system quotas to help thwart distributed denial-of-service (DDoS) attacks, trusted path mechanisms for guaranteed communication links, and residual information protection to stop attacks by reusing or viewing used memory. To get an understanding of how a system can adequately protect against malicious attacks, it’s best to get into more detail on some of these key security features.

Protecting against malicious attacks

Identification and authentication refers to a security process whereby a device on the network recognizes a valid user’s identity and can verify (authenticate) the claimed identity of the user. If users are not properly identified and authenticated, then the embedded device is potentially vulnerable to access by unauthorized users. The industry standard for the authentication of users is called OpenPAM (Pluggable Authentication Modules), which provides a generalized (API) to allow applications to use various authentication modules that are dynamically invoked. A strong identification and authorization mechanism significantly reduces the risk that unauthorized users will gain access to embedded devices.

Discretionary access controls () are a means of restricting access to objects (such as files, applications, directories, and devices) based on the identity of the user or group to which they belong. When implemented using access-control lists (ACL) as defined by the Posix.1e standard, DAC can provide a very fine-grained control over who can access an object. DAC gives a networked device the ability to carefully control who can access and execute files and data on the device. Roles and capabilities rules provide fine-grained privilege levels for different users. Historically, in UNIX and similar systems, the privilege to perform administrative tasks is reserved for the root user, who has complete autonomy to see or modify the entire system, whether or not those privileges were required by the original task at hand. Normal users, conversely, had no administrative privileges whatsoever.

In general, the all-encompassing privileges of the UNIX root user makes it susceptible to abuse, whether unintended or malevolent. With DAC, roles and capabilities move from an ”all-powerful root user” to one that can create multiple administrative “roles,” each with a subset of privileges (called “capabilities”) specific to the task at hand. Embedded devices that implement distinct roles, each with limited capabilities, will be more secure against attacks that target and compromise a specific “user” account on the system.

Don’t run out of space

Quotas are a security control that is implemented to protect the device from running out of disk, memory, or CPU. As an example, if a DDOS attack is made against the system with the intent of overusing the CPU, an unprotected device could essentially appear to freeze up. By being able to set limits on the amount of critical resources –such as CPU – a task is able to consume, the overall system is protected from such an attack. Likewise, if a process tries to allocate memory or disk resources and the usage of the user or group exceeds the quota, then an error will be returned and the allocation will fail.

Residual information protection is another security feature, one that insures that whenever a resource is allocated or freed, the content of the resource can be made unavailable to others’ processes. A secure RTOS makes user memory and file-system data unavailable to others when it is freed, resulting in a more secure system. Whenever a file-system object is removed, all the blocks allocated to that file-system object will be filled with zeros.

Audit facilities allow an embedded device to capture significant system events and perform security monitoring of these events. Examples of fine-grained event auditing include events like login, logout, object accesses, and administrative tasks, all of which can be logged to an audit trail. The audit trail contains valuable information that can be used to review security-critical events, discover attempts to bypass security mechanisms, and perform forensic analysis. The audit trail thus provides a deterrent against attempted attacks since audit logging captures any intrusion attempts. A security task can be provided to monitor the live audit events as they are occurring and to analyze the audit records written to the audit trail helping to make connected devices much more secure.

Figure 1: A diagrammatic representation of a secure RTOS offering a number of built-in security features.
(Click graphic to zoom)

As more embedded devices are becoming connected to the ubiquitous Internet, and the more sophisticated cyber threats become, the greater the need for built-in security at the OS level, as many cyber threats work their way into our devices through OS vulnerabilities. The LynxOS 7.0 RTOS from Lynx Software Technologies has built-in security functionality. It is available on the Curtiss-Wright Defense Solutions rugged single board computers: the VPX6-187, which is based on Freescale’s Power Architecture P4080 processor; and the VME-1908 and VPX6-1958 SBCs, which are based on the Intel Core i7 fourth-generation quad-core processor.

Robert Day is Vice President of Sales and Marketing at Lynx Software Technologies, Inc.

Michael Slonosky is the Product Marketing Manager for Power Architecture Single Board Computers in the C4 Solutions group at Curtiss-Wright Defense Solutions.

Lynx Software Technologies, Inc. 408-979-3900

Curtiss-Wright Defense Solutions


Topics covered in this article