The different trusted computing and cyber security approaches for embedded computing and enterprise systems
By David Sheets
ASHBURN, Va. – When discussing trusted-computing, and cyber security, it is important to understand which of two types of computer systems that needs protection -- enterprise or embedded.
Enterprise systems manage the information technology (IT) and infrastructure of large organizations the world over. These systems often are distributed and connected, and typically are upgraded at a comparatively frantic pace.
Embedded systems, on the other hand, typically are deployed in the field. They tend to be much more rugged and much more tightly integrated than enterprise systems, and commonly undergo more rigorous certification and verification processes.
Enterprise systems normally are made up of all-commercial components, networked together potentially over long distances and often connected via firewalls to public networks. These systems often integrate normal desktop and laptop computers, switches, routers, and firewalls, as well as other commercial market products that usually are produced in large volumes.
For each of the products that comprise an enterprise system there are specific security considerations that systems integrators must address. Most enterprise hardware will use standard interfaces, such as Ethernet and USB. They will run a version of a common commercial operating system like Microsoft Windows or RedHat Linux, and depend on support from commercial vendors for security updates.
In contrast to enterprise systems, embedded computing systems exist within a defined environment. They normally are more rugged, which enables the electronics to operate in the harsh physical environments that fielded military hardware must endure. They also are much more closely integrated, perhaps using interfaces that are less common in commercial architectures, such as MIL-STD-1553.
Embedded systems typically also use purpose-built hardware, often in response to the difficult tradeoffs that designers make regarding size, weight, and power consumption (SWaP). Also, because of the lower production volumes, these systems often will have much different vendors and support structures than do enterprise systems.
It is important to consider the history of cyber security when choosing trusted computing approaches for enterprise systems and embedded computing.
The criticality of cyber security emerged as a major concern as systems became more connected, and opened the door to potential attackers via remote access. Because they connect disparate geographically isolated heterogeneous systems together, enterprise architecture designers consider requirements for authenticating endpoints, encrypting communications, locking down interfaces, and controlling the flow of information.
The community of cyber security professionals has developed many products, tools, and frameworks geared specifically to address the needs of enterprise systems. Some common examples of these are virus scanners, firewalls, and intrusion-detection systems.
A virus scanner is a relatively simple tool that can look at code and data to determine if it has nefarious intent. One important facet of using a virus scanner is ensuring that the definition of what constitutes a virus stays up to date. If not, new viruses can circumvent the scanner.
This tool relies on the connectivity of the enterprise system to ensure it stays current and effective. Using such a tool in a disconnected, or even infrequently connected embedded environment can be problematic. In comparison, a firewall that filters network traffic, or an IDS that monitors a system for anomalous behavior, might not require as updates as frequently as a virus scanner does to stay relevant, but may still require the ability to trigger warnings that instigate investigation and response when necessary.
In an enterprise environment, the person handling the resulting investigation and response often will be an IT professional. In comparison, in an embedded environment it can be difficult to say where that needed update information can be reliably stored and processed in a timely and effective manner.
One difficulty of applying cyber security to embedded systems revolves around assumptions and practices concerning with a specific type of environment. An example is the Risk Mitigation Framework (RMF). The U.S. military often relies on RMF to ensure that U.S. Department of Defense (DOD) systems go through sufficient cyber security scrutiny to operate securely on DOD networks.
Because the RMF process is applied to many different types of systems, from enterprise to small embedded systems, however, there are many possible controls that systems designers must analyze and document that may not apply to embedded systems.
For instance, there are RMF controls related to login credentials and password length that do not apply to embedded systems. For a small embedded system without a login, systems designers may mark many of these kinds of controls safely as inapplicable.
Related: Trusted computing and the challenges of cryptographic algorithms in quantum computing
Still, it takes time to analyze, document, verity, and monitor the embedded system to ensure that none of the assumptions change. It's also important not only to prevent any backdoors into the system, but also to understand that additional work may be necessary to secure DOD approval for these sorts of systems.
The RMF was developed with the understanding that it applies across a wide variety of systems. As a result, the concept of overlays was designed to help address this concern.
An overlay is a selection of controls specific to a particular type of system. An overlay can either add or remove controls from the required set used to analyze the system security risks. It adds and removes controls when necessary. It also can refine controls, add additional text for clarity.
Although systems designers have discussed developing an overlay that makes it easier to apply the RMF to embedded systems, that hasn't happened yet. Still, there is progress in developing overlays specific to weapon systems or mission computers that may apply to embedded systems. Programs should look to the military services to understand if an overlay that is applicable to their type of system has already been developed before they spend unnecessary time going through all RMF controls and documenting their decisions.
Obviously, programs should look at all relevant overlays -- including any overlays for systems that need to process classified or sensitive information. Designers should look at the Joint Special Access Program (SAP) Implementation Guide (JSIG).
Although the RMF does address systems updates, more discussion may be necessary. Enterprise systems often rely on their ability to update to stay safe, such as weekly operating systems patches and periodic virus scan updates.
On the other hand, embedded systems often must go through a robust verification process before being deployed. That means that any frequent updates may require expensive re-verification. What’s more, updating a common shared library potentially could invalidate weapon safety testing, flight safety requirements, or key performance indicators.
Related: Cryptography in trusted computing: an introduction to secure hashing
To bottom line is that re-running all the required certifications often is simply infeasible for complex embedded systems. The challenge of security updates is an area that DOD systems designers still are dealing with to develop appropriate responses.
Although military embedded systems may have minimal connectivity, it’s become apparent that they still have cyber security issues. Additional work is necessary to reduce the overhead on every deployable embedded system while maintaining security metrics.
David Sheets is senior principal security architect at Curtiss-Wright Defense Solutions. Contact him by email at [email protected].
