BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

4.3 Implementation

NIST platform security: roots of trust, firmware and secure enclaves SP 800-124 Rev. 1
All changes in this version
first version loaded 4 Applications part of 4

Title

Implementation

Control

After the mobile device solution has been designed, the next step is to implement and test a pilot of the design, before putting the solution into production. Aspects of the solution that should be evaluated for each type of mobile device include the following:

 Connectivity. Users can establish and maintain connections from the mobile device to the organization from the locations they are expected to use. Users can connect to all of the organization’s resources that they are permitted to and cannot connect to any other organization resources.

9 NIST SP 800-21, Second Edition, Guideline for Implementing Cryptography in the Federal Government , presents guidelines for selecting, specifying, employing, and evaluating cryptographic protection mechanisms in Federal information systems. It defines a process for selecting cryptographic products and discusses implementation issues, including solution management, key management, and authentication. [SP800-21] 10 The Cryptographic Module Validation Program (CMVP) at NIST coordinates FIPS 140-2 testing; the CMVP Web site is located at http://csrc.nist.gov/cryptval/ . See http://csrc.nist.gov/cryptval/des.htm for information on FIPS-approved symmetric key algorithms, and http://csrc.nist.gov/cryptval/dss.htm for information on digital signature algorithms. See FIPS 140-2, Security Requirements for Cryptographic Modules , for more information. [FIPS140-2] 11 For more information on incident handling, see [SP800-61].  Protection. Information stored on the mobile device and communications between the mobile device and the organization are protected in accordance with the established requirements.

 Authentication. Authentication is required and cannot be readily compromised or circumvented. All device, user, and domain authentication policies are enforced.

 Applications. The applications to be supported by the mobile device solution function properly. All restrictions on installing applications are enforced. All restrictions on uninstalling applications (such as enterprise mobile device management software) are enforced.

 Management. Administrators can configure and manage all components of the solution effectively and securely. The ease of deployment and configuration is particularly important. Another concern is the ability of users to alter device/client software settings, which could weaken mobile device security.

 Logging. The mobile device solution logs security events in accordance with the organization’s policies. See NIST SP 800-92, Guide to Computer Security Log Management , for additional information on logging. Note that the security logging capabilities of mobile devices vary widely.

 Performance. All components of the solution provide adequate performance during normal and peak usage. It is important to also consider the performance of intermediate devices, such as routers and firewalls.

 Security of the Implementation. The mobile device implementation itself may contain vulnerabilities and weaknesses that attackers could exploit. Organizations with high security needs may choose to perform extensive vulnerability assessments against the mobile device solution components. At a minimum, all components should be updated with the latest available patches and configured following sound security practices. The organization should also take basic measures to prevent the user from circumventing the device’s security features. Also, jailbroken or rooted mobile devices should be automatically detected to prohibit their use, for cases in which detection is feasible.

 Default Settings. On a per-OS version basis, implementers should carefully review the default values for each mobile device setting and alter the settings as necessary to support security requirements. Implementers should also ensure that the mobile device solution does not unexpectedly “fall back” to insecure default settings for interoperability or other reasons.

Organizations should fully secure each organization-issued mobile device before allowing a user to access it. Any already-deployed mobile device with an unknown security profile (e.g., unmanaged device) should be fully secured to a known good state (for example, through deployment and use of enterprise mobile device management technologies). Supplemental security controls should be deployed as risk merits, such as antivirus software and data loss prevention (DLP) technologies.