As more executives and business users access governance, risk and compliance applications and data from their mobile...
devices, the IT department is on the hunt for better ways to defend mobile GRC applications against hackers. At the same time, IT must meet mobile data security, encryption, storage and retention requirements stipulated by compliance regulations.
A policy engine should be implemented to allow the device owner to manage the different policy agreements required to establish access rules for multiple information owners.
The problem is that many mobile devices lack the full range of secure hardware Roots of Trust (RoT) that are built into laptops and desktops to protect boot firmware, isolate applications and protect storage, and in turn prevent hackers from modifying or accessing security-critical software and firmware components. In all BlackBerry devices, for example, hardware RoT are inherent -- any BlackBerry device trying to boot up or connect to the BlackBerry infrastructure must complete the self-verification process before the user is granted access. Counterfeit devices cannot connect to the BlackBerry infrastructure.
For mobile devices without RoT built in, the following four steps will allow IT to enable hardware-rooted security.
Step 1. Implement security capabilities
For the first step, implement three mobile data security capabilities as defined in NIST publication SP 800-164:
Device integrity, to guarantee hardware, firmware and software are not corrupted. Counterfeited devices will not connect, store data or run applications.
Isolation, to separate one application or one data set from another to prevent unintended interaction between applications and information.
Storage protection, to preserve the confidentiality and integrity of data on the device at rest, in use and upon access revocation.
Step 2. Verify security components
In order to provide security capabilities for bring your own device and company-issued devices, verify whether the mobile devices contain a set of security components. These include RoT, an application programming interface, or API, to expose the RoT to the platform and a policy engine.
More on mobile data security
The four essential rules to ensure effective mobile data management
Achieve defense in depth of mobile GRC apps using these three steps
Hardware RoT are preferred over software RoT due to their smaller attack surfaces and more reliable behavior. They are trusted to perform such security-critical functions as software verification, cryptographic key protection, device integrity and device authentication. They are expected to discourage or prevent hackers from accessing the firmware when a mobile device is powered on.
Mobile applications interface with services offered by the various information owners who will frequently utilize the security functions provided by the RoT. An information owner uses these functions to locally store cryptographic keys, authentication credentials and other sensitive data. It can be an application-specific provider, a digital product provider or an enterprise that allows access to these resources from mobile devices.
A policy engine should be implemented to allow the device owner to manage different policy agreements. These agreements are required to establish access rules for multiple information owners.
Step 3. Verify Roots of Trusts categories
The next step is to verify RoT for mobile devices as specified by NIST guidelines:
- Roots of trust for storage (RTS) to store and manage cryptographic keys.
- Roots of trust for verification, or RTV, to verify digital signatures associated with software/firmware and create assertions based on the results.
- Roots of trust for integrity (RTI) to manage device integrity assertions.
- Roots of trust for reporting (RTR) to generate device integrity reports.
- Roots of trust for measurement, or RTM, to provide trusted measurement functions to be used by assertions that are protected via the RTI and attested to with the RTR.
Any device that does not meet the criteria of five RoT categories does not meet the National Institute of Standards and Technology's mobile data security standards.
Step 4. Mitigate risks of exposure
The last step is to mitigate the risk of exposing encryption keys.
Roots of trust for storage contain two classes of keys: Data encryption keys (DEKs) and key encryption keys (KEKs). While RTS protects KEKs, DEKs will remain at risk for exposure because DEKs are often unwrapped for use outside the RoT. For example, bulk encryption and decryption operations are executed outside the RTS by the application processor on a mobile device.
One way of mitigating this risk of exposure is to implement security capabilities that isolate one application from another. This capability is discussed in the first step mentioned above.
About the author:
Judith M. Myerson is the former ADP Security Officer/Manager at a naval facility, where she led enterprise projects for its Materiel Management System. Currently a consultant and subject matter expert, she is the author of several books and numerous articles on cloud use, compliance regulations, mobile security, software engineering, systems engineering and risk management. She received a Master of Science degree in Engineering from the University of Pennsylvania and holds the Risk and Information System Control, or CRISC, certification.