Download this article in PDF format.
The complexities of computer systems with tens of thousands of individual components, and even more lines of code, introduce many opportunities for oversights in proper system security. Each computer system may be interconnected with several other devices to form a network, and suddenly there are many points that can leave a system susceptible to misuse.
Below are 11 myths to be aware of when securing an embedded system.
Growing use of connected systems has made data security even more of a focal point in embedded systems.
1. When buying a product, such as a hypervisor, the software takes care of all additional security concerns in virtualization.
The hypervisor is a software product that virtualizes hardware so that multiple operating systems (OSs) can be run independently on the same hardware. Part of the responsibility of the hypervisor is to isolate specific Oss; therefore, a breach in one doesn’t necessarily provide access to another.
However, a hypervisor will depend on several hardware features to help ensure that one virtual machine can’t interfere with another. For example, the memory management unit (MMU) will ensure the isolation of specific memory resources that have been assigned to each virtual machine. Also, the hypervisor provides a lot of flexibility, which means that a secure configuration of the virtual environment is necessary to ensure platform security.
2. Security is only a concern for the OS/hypervisor/application.
Each layer of the OSI model needs to be understood and secured. The whole boot process is vulnerable to infiltration in a system. To ensure that the complete boot process is secure, new features have become available. These include Intel TXT - Trusted boot in conjunction with TPM to ensure the boot process is secure and, if there are any changes, the system can be prevented from booting until there’s assurance of a secure boot environment.
3. I have taken care of my hypervisor, OS, application, and boot process, so my system is as secure as it can be.
As everything becomes more interconnected, more and more devices are remotely mounted. What if someone has direct access to the hardware? Steps may need to be taken to ensure that someone could not access a physical communication port to access an otherwise secure device.
4. A secure system is also a safe system.
These are two very different attributes of a system and should not be confused. A secure system is one where the features are relatively inaccessible to unauthorized users, hence the system is protected. A safe system isn’t likely to injure someone if it fails, as in an airplane. There are measures in place for the necessary operations to continue regardless of any malfunctions. A safe system needs to be secure, whereas, a secure system may not need to be safe depending on the application.
Virtualization abstracts the hardware from the application.
5. My system isn’t connected to the outside world, so it’s secure.
A situation could arise where someone has physical access to the unit. Can you fully trust that everyone with access not only remembers to secure everything when they leave, but also has the best intentions? Common protection methods include things like disabling a USB port to avoid the transfer of potentially harmful software to the system using a memory stick. In addition, hardware-based firewalls could provide additional functionality.
6. My computer is isolated from the outside world, so I don’t need to run updates for the OS/Hypervisor/Application.
It’s easy to design a device, deploy, and then forget about it. However, there are many cases where this strategy can lead to problems in security. Companies are constantly providing updates that may affect user controls. Take a quick look around the internet and it’s possible to find many stories about security bugs discovered long after a device was deployed.
A user could inadvertently gain elevated privileges if a bug exists in the hardware, firmware, or other parts of a system on which the security architecture is based. Similarly, who is responsible for the security of each part of the system? It is easy to assume that each vendor has their area covered. However, it may be necessary to understand each company’s processes and communication channels for security updates.
7. Only my most trusted employees have physical access, which means my system is secure.
Like the BYOD—“Bring Your Own Device”—trend forced changes in many company security strategies, it becomes necessary to create a similar environment for users of a remote system. Making sure that the proper user controls are set, and users only have access to the needed portions of the system, can go a long way. If, for example, someone has access to the BIOS and enables certain features, it could be possible for them to inadvertently gain access to admin privileges.
8. My system is relatively secure and physically inaccessible, so it should be safe.
In the modern world, virtualization has enabled a consolidation of hardware. However, there’s still a need for several components to be connected back to the centralized virtual machine. Are each of these connections secured in a way that only the device, which is expected on the other end of the connection, can send information back to the virtual machine? If not, a device may be physically inaccessible, but still be remotely accessible through a device connected to it.
Shown are Hypervisor Type 1 (bare-metal) and Type 2 (on top of operating system).
9. I’m using the latest up-to-date containers, therefore my application is safe.
A container is an abstraction of the operating system. The container relies on Docker and other underlying software layers as well as the hardware. Every layer needs to be secured to ensure the security of each part of the complete system.
10. The data on my device is encrypted, making it inaccessible.
Many of us aren’t handling extremely valuable, top secret information, but it’s possible to break some encryptions when enough resources are thrown at it. In certain applications, it may make sense to take more extreme measures. For instance, very thorough erase features available on the disk market may do the job well enough.
11. Security is only a concern externally to a device.
Depending on the application, there could be data security requirements when moving from one disk or processor on a device to another. Such cases would require a concept for securely passing data from one place within the system to another. This may look a lot like a safe system using a back-channel concept to ensure the integrity of safety-rated data passing through an unsafe layer. Only in this case, one part of the system or electronics may need to ensure the security of data being passed to another part of the system.
In the end, one should remember these main points: Every layer in the OSI model can be involved in the security architecture of a system; always keep the system up-to-date, which includes actively monitoring for updates; and make sure that additional security requirements are understood for each project.
Every myth can be overcome with the right knowledge, best practices and processes, and the willingness to continue learning. This means not being afraid to ask tough questions and challenging every part of the system to be as secure as possible.
