Security for Networked Devices
Adding Extra Levels of Security for Connected Client Devices
In order to form a secure platform, a combination of the latest hardware and software technologies is needed to protect our computer systems and networked devices from harm even if the network security has been compromised.
ROBERT DAY, LYNUXWORKS
Page 1 of 1
Much of today’s security focus is on securing the network from attack, as this has become a standard path for cyber crime and cyber warfare to infiltrate our computer systems. However, if malicious threats manage to bypass the network security and enter our systems, there is very little left to protect our sensitive data and applications from attack.
As the enterprise attempts to move everything to the “cloud,” offering greater security and flexibility for applications and data, the actual world is struggling with the reality that much of the sensitive information both corporate and personal is being carried around on our multitude of connected mobile, embedded and laptop devices. The protection for this information has largely been reliant on protecting the network that we connect to (such as with VPN connections) or assuming that the operating system that is being used on the device is not ripe for attack. The cyber criminals, however, are working very diligently on new methods for attacking our systems, figuring out ingenious means for stealing or corrupting our sensitive information. Some attacks, for example the recent Stuxnet virus, are targeted on a particular type of device, and for a particular reason. So, we are in desperate need for new technologies to help us protect our sensitive data even if our device is compromised by a malicious attack.
In the enterprise world, virtualization is often seen as a way of isolating and protecting applications and data held on PC clients and cloud servers. While adding a virtualized layer does help to a degree, many of these virtualization systems still run on top of, or with the aid of, traditional desktop operating systems that have a large and well known attack surface for malicious programs to exploit. In fact, many viruses check to see if they are running in a virtualized environment and change their behavior accordingly. In embedded systems the use of traditional virtualization solutions is somewhat limited. In much the same way that regular hypervisors are not built for security, they are also not built with real-time determinism in mind either. An ideal solution to help protect our client devices would be a real-time secure OS with a virtualization scheme built in.
This technology exists today, and has been developed for and used in defense systems that require real-time performance, connectivity and, above all, security functionality that protects our very sensitive military information from real cyber attacks. The heart of this technology is a secure separation kernel. Rather like a safety-critical RTOS, the kernel provides a scheme that partitions applications and memory—hence the separation—but unlike safety kernels it has added security protection and definable security policies that enable developers to build a system that meets their exact security requirements.
The separation kernel has become a fundamental platform for building secure systems to consolidate traditionally physically separate hardware onto a single platform. These systems will often be connected at different levels of security or to different networks that require secure isolation of the communication or data resident on the system. And therefore when these elements are combined onto a single physical environment, a secure separation system needs to be employed. These consolidated systems can be designed to a multiple independent levels of security (MILS) scheme with strict separation and secure communication policies that are enforced by the separation kernel.
This technology gets really interesting and also applicable to the enterprise space when a hypervisor or software virtualization solution is combined with the separation kernel. With this virtualization technology each secure enclave provided by the separation kernel can actually contain a virtualized environment that allows multiple different virtualized “guest” operating systems to reside on a single physical system while still maintaining security for each by virtue of the separation kernel. Because the hypervisor is combined with the separation kernel, it is running directly on the hardware. This is often known as a type 1 hypervisor, which gives significant performance benefits compared to a more traditional “hosted” type 2 hypervisor that requires and runs on a desktop OS like Windows.
This technology could radically change the way developers build and configure both embedded and enterprise systems by allowing the segregation of both applications and operating systems on a single system based on the real-time requirements, the desired user environment and the security needs of different elements of the system. No longer will the compromise of trying to make a desktop OS real-time, or a real-time OS a full GUI-based system be the developers headache. They can simply use a RTOS in one partition for the real-time element and a desktop OS in another partition for the user interface. This greatly simplifies the software architecture of the system, and allows for a more diversified development team with different skills to be used on the project. Figure 1 shows the architecture of the LynxSecure separation kernel and hypervisor, which is a good example of a military-grade secure virtualization solution.
Example separation kernel architecture diagram showing multiple secure partitions running and RTOS, two desktop OSs and small bare hypervisor partitions for smaller applications.
A very key benefit of this new approach is the secure separation of the elements and data held in the system. The secure partitioning system helps protect connected devices from attack, even if malicious code has breached the network security, as it limits the attack to the partition where the malicious code entered the system, and the security within the separation kernel does not give the attacker any visibility or access to the other parts of the system. Using a separation kernel allows not only the configuration of the guest operating systems and their applications, but also the configuration of the physical devices available in the system and the communication policies between the different partitions, allowing for different configurations on the same hardware platform based on the user requirements and defined by the system developers.
To understand how this configuration is applied, the function of the separation kernel needs to be explored first, then the virtualization schemes offered by the hypervisor component, and finally how both of these are linked with the underlying hardware platform.
The separation kernel is a small, efficient real-time operating system that manages both the physical devices and the memory on the system. It offers partitioning and isolation of the memory regions and devices based on a configuration scheme that is put together by the system architect. This same configuration also contains the information about how the different partitions can communicate with one another, allowing two-way, one-way or no-way directional flows. All of the configuration information is held within the separation kernel image, so it is not accessible or hackable from the outside world. The separation kernel itself has limited operating system functionality for programmers, which keeps the kernel small and certifiable when used in security systems.
Much of the high level OS functionality is provided by the guest operating systems that reside on top of the separation kernel, provided by the hypervisor. This means that the desired functionality of the OS is selectable per partition, by choosing the most appropriate guest OS for that part of the system. The hypervisor provides a virtualization interface for the guest OS to run on, with two different virtualization schemes available for the guests to use. Paravirtualization is a scheme where the hypervisor and the specific guest OS are tightly coupled together. Less virtualization support is required from the hypervisor as the guest operating system is modified to make direct calls to the hypervisor. This approach has traditionally offered better performance for the guest OSs as less virtualization code is required to run. The source code of the guest OS needs to be changed and an understanding of the hypervisor functions is required to apply this type of virtualization.
The other virtualization approach is full virtualization, where the guest operating system requires no modification as the hypervisor presents a virtualized environment that looks identical to the native hardware that the guest would normally run on. This approach requires more virtualization code in the hypervisor, which has traditionally resulted in a performance degradation when compared to paravirtualization, but has the advantage of no modifications needed in the guest. This second approach is particularly useful if the source code to the guest OSs is not available for change, and requires little understanding of the hypervisor APIs as the guest just runs as if it was running on a native system. For both virtualization schemes applications that run on the guest OS require no modification, as they are using the normal API of the guest, and hence provide a very effective way of moving legacy applications to hardware platforms, maximizing reuse and shortening porting time dramatically.
Another key component of the separation kernel/hypervisor approach is in the pairing of devices to partitions and guest operating systems. A traditional type 2 hypervisor will typically virtualize all devices in the system, offering a flexible, but often performance limited, environment for guests to use, especially for performance devices like graphics or network functions. The separation kernel approach can offer two schemes for device allocation, the first being direct device assignment. This approach allocates and assigns a specific physical device to a specific guest OS, allowing OSs and applications that require the best performance or the highest security to have full and total control of a physical resource. The second approach is to allocate a physical device to a server partition, and then offer shared virtual devices to other guest operating systems. This approach is particularly useful when physical resources are limited, especially true in embedded and mobile client devices and laptops. Figure 2 shows an example of how devices may be directly assigned and/or shared on the same physical system.
Example of how devices may be directly allocated to secure partitions, or shared between partitions using the secure device server resident in its own partition.
Because the separation kernel and hypervisor are software approaches, there is often a concern that running an OS on top of a kernel or just using virtualization is too much of an overhead for use in real-time, embedded or mobile devices. However, many of the hardware processors have helped to reduce that overhead dramatically by introducing hardware virtualization technologies and processors with multiple cores. The hardware virtualization technologies help assist the memory, device and execution virtualization required by the hypervisor, allowing much of the software virtualization and guest OS switching to be directed to the hardware, increasing performance dramatically. Because of the increased use of virtualization in server and PC client systems, the Intel processor architecture has been innovating with many new hardware features such as Intel virtualization technology (VT) and extended page tables (EPT) that significantly increase guest OS performance. Taking advantage of these hardware technologies has brought the performance of both paravirtualized and fully virtualized guest OSs to within a few percentage points of their native performance on the same hardware.
The security of the separation kernel with the functionality of a hypervisor is providing a platform that developers can use to run embedded and enterprise systems on a single hardware platform, and protect the sensitive information and data from attack by partitioning resources in their own secure enclaves. This approach is performant enough that even with the increased security protection, the users will not notice application degradation and legacy software systems can be ported to new secure environments with having to rewrite a lot of code.
San Jose, CA.