If this was a test question on a college exam, you would have a set of multiple choice answers, such as:
A.
-
- The device manufacturer that initially builds the device.
B.
-
- The device integrator, who builds the device into an end-user product.
C.
-
- The value added reseller that distributes the device to consumers.
D.
-
- The customer, who installs or sets up the device or third-party product in the end-user environment.
E.
- All of the above.
The answer may be surprising to some, but it is of course “E. All of the above.” Everyone along the chain from manufacturing to integrating and using the product plays a role in ensuring that the device is properly set up to thwart improper access, device hacking and malware attacks.
Many people believe that security can be fully implemented by the device manufacturer, or that it’s possible to install a security-focused software program to detect and thwart hacking. But in fact, true device security is a combination of technologies, processes and best practices.
Why Device Security Requires a Multi-Pronged Approach
There are several key reasons why device security requires multiple technologies and practices across the chain from manufacturing to end-use:
- Each enterprise has a different security requirement. Retail and financial institutions that process transactions need a high level of security to protect customer data. Healthcare organizations that handle sensitive personal information also require a very high level of security. At the other end of the spectrum, there are many use cases in which extreme security is not required, and it does not make sense to take the extra measures, as it results in additional cost to the consumer.
- The threats change. The technologies and practices in use today may not be enough to thwart the attackers of tomorrow. See our previous post, Lessons Learned from the KRACK Vulnerability, for additional insights.
- Consumers do not want to pay for the amount and type of built-in security that businesses require.
Device Security from the Manufacturing Perspective
In this post, we will talk specifically about the key security measures that should be designed into the product by your device manufacturer if you are a product integrator or value added reseller, so that others further down the chain can implement proper security. For example, if you are seeking to incorporate one or more vendors’ embedded modules and radio frequency products into your product design, it is important to review the security measures taken in the manufacturing phase.
In these instances, the devices must enable secure functionality. The device manufacturer’s responsibility is to build in secure features, which can then be implemented by the integrator or end-user. As a best practice, the manufacturer should include a comprehensive set of controls that can be enabled as needed. These controls are essentially the laws that govern the product and ensure it behaves in a secure manner. In this article, we refer to this set of controls as a “manufacturer security framework.”
To demonstrate, let’s look at some specific examples.
Example 1: A Security Feature Implemented Within a Device
In this example, we will discuss a feature called “secure boot.” The intent of secure boot is to make sure no unauthorized code ever runs on the device. At Digi, for example, we have defined a number of controls within our manufacturer security framework for this purpose.
The controls we have assigned to secure boot include the following:
- When the device boots, all code objects that are loaded are cryptographically verified as coming from the device manufacture.
- When software is updated, all updates are cryptographically verified as coming from the device manufacturer.
While we require the secure boot control, our developer has many technical options for how to implement it. For example, when sourcing a manufacturer’s CPU, our developer must first evaluate the capabilities of that component to determine how to implement the control. In the case of secure boot, if the CPU offers the High Assurance Boot (HAB) feature, the Digi developer can implement the HAB on the product under development to meet the secure boot control requirement.
This security framework ensures that a full range of critical security controls is built in during the development of the product, but still provides the developer with some choice as to the method. When all security controls are in place and development is complete, each of these controls must then be tested and validated.
Example 2: A Security Feature Implemented by the End User
Another example of a secure code feature is the ability to do code validation on end-user code that runs on a device. With the future trend of edge computing, code validation and the infrastructure to support this on an edge device is becoming critical. Validating scriptable end-user objects does not happen at the manufacturer’s level, but at the end-user level. The manufacturer needs to support the functions to make this happen. End-users must then enable these functions on their devices and code upon deployment.
It is important to note that it is the validation of a control that ensures secure operation. This happens not only at the manufacturing level, but across all phases of product implementation. For a set of framework controls for end users to implement for device security, see the Center for Internet Security (CIS) site at www.cisecurity.org.
Digi’s framework of manufacturer security controls, called Digi TrustFence™, includes:
- Secure boot
- Authentication and secure connections
- Encrypted storage
- Secure updates
- Certificate and policy management
- Protected hardware ports
- Device identity
- Ongoing monitoring and support
The Digi TrustFence™ solution is not a single security feature, such as a software program that can be hacked. It is a multi-pronged approach designed to ensure that devices are secure from common attacks, and that device integrators and end users have the ability and functions needed to establish a secure configuration in deployment.
The intent of Digi TrustFence™ is to start the secure IoT story from the manufacturing perspective. If you are an integrator, or application developer, there are similar security frameworks such as the OWASP top 10 (www.owasp.org) for security controls on IoT devices. These frameworks provide controls that can be implemented at multiple phases from the manufacturer to the end user.
To continue this story, your own organization must assess what you have in place for a security framework. Does your organization have a set of published best practices? Does your supplier offer a security framework for its customers? Are you fully implementing all available controls to avoid any single point of failure?