Can Hardware-based Mobile Security Increase Trust and Reduce Liability?
Security and trust serve as two of the building blocks upon which decisions about risk in the mobile environment can be made. Such decisions ultimately affect the liability that an organization will face as a result of how its employees use mobile technology. Today’s mobile technology, unfortunately, often has weak (or even nonexistent) security and trust. To address this shortcoming, NIST recently released another draft in their excellent 800-series of Special Publication documents (see http://csrc.nist.gov/publications/PubsSPs.html). Entitled “Guidelines on Hardware-Rooted Security in Mobile Devices”, Draft SP 800-164 introduces a framework around which security and trust in mobile devices could be significantly improved.
Draft SP 800-164 establishes up front that various overlapping roles exist related to mobile devices, with the main use case focused on enterprise deployments of technology and, specifically, “bring your own device” (or BYOD). For example, the roles of Device Owner and Information Owner can be played by either the company or the employee, depending on the particular arrangement between the two. Additional roles that come into play include the overall enterprise, technology providers (e.g., mobile carriers, device manufacturers, and operating system (OS) vendors), and users. Interestingly, Draft SP 800-164 does not mention the role of the government or regulators. It also does not talk about the liability that a stakeholder might have as a result of taking on a particular role. Each of the entities that it does discuss, however, has a particular set of interests and identifiable activities within the mobile environment. The resulting liability concerns necessitate a deeper inquiry into the security components and hardware features available (or that should be available) on the particular devices.
From a security perspective, various Roots of Trust (RoTs) exist that provide varying degrees of protection to the mobile environment. These include RoTs for storage, verification, integrity, reporting, and measurement. While often focused on the technical aspects that such RoTs can provide, it should be noted that the RoTs and other associated components can combine to provide an organization with a level of trust that extends beyond the capabilities available today. A future “bring your own device” (BYOD) approach may no longer be limited to a binary “yes, you may bring your device” or “no, you may not bring your own device.” Instead, depending on how much or how little liability exposure an organization may decide to take on, it may want to examine both the security components and the security capabilities in the devices it will be deploying.
Draft SP 800-164 states that three security components are required within mobile devices. First, the Roots of Trust (RoTs) mentioned above must be implemented as “security primitives composed of hardware, firmware, and/or software that provide a set of trusted, security-critical functions.” Second, an Application Programming Interface (API) must be implemented that exposes the RoTs to the device and the OS so that those RoTs can be used to provide a chain of trust. Third, a Policy Enforcement Engine (PEnE) must exist to enable the use of policies on the mobile device. These security components must further be used to implement the three mobile security capabilities of device integrity, isolation, and protected storage.