NIST platform security: roots of trust, firmware and secure enclaves SP 800-124 Rev. 1
All1 General policy. The centralized technology can enforce enterprise security policies on the mobile2 Data Communication and Storage3 User and Device Authentication4 Applications
| Ref | Title | Text | |
|---|---|---|---|
| 1 | General policy. The centralized technology can enforce enterprise security policies on the mobile | device, including (but not limited to) other policy items listed throughout Section 3.2. General policy restrictions of particular interest for mobile device security include the following: Restrict user and application access to hardwar | |
| 2 | Data Communication and Storage | Strongly encrypt data communications between the mobile device and the organization. This is most often in the form of a VPN, although it can be established through other uses of secure protocols and encryption. Strongly encrypt stored | |
| 3 | User and Device Authentication | Require a device password/passcode and/or other authentication (e.g., token-based authentication, network-based device authentication, domain authentication) before accessing the organization’s resources. This includes basic parameters fo | |
| 4 | Applications | Restrict which app stores may be used. Restrict which applications may be installed through whitelisting (preferable) or blacklisting. Restrict the permissions (e.g., camera access, location access) assigned to each application. | |
| 4.1 in 4 |
Initiation | The initiation phase involves many preparatory actions, such as identifying current and future needs, and specifying requirements for performance, functionality, and security. A critical part of the initiation phase is the development of a | |
| 4.1.1 in 4.1 |
Restrictions on Mobile Devices and Access Levels | An organization’s mobile device security policy often limits the types of mobile devices that may be used for enterprise access; this is done for a variety of reasons, including security concerns and technology limitations. For example, an | |
| 4.1.2 in 4.1 |
Additional User Requirements | Organizations often have additional security considerations for mobile devices that, while helpful in mitigating threats, cannot necessarily be directly enforced by the organization. Organizations should educate users on the importance of t | |
| 4.2 in 4 |
Development | Once the organization has established a mobile device security policy, identified mobile device needs, and completed other preparatory activities, the next steps are to determine which types of mobile device management technologies should b | |
| 4.3 in 4 |
Implementation | 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 i | |
| 4.4 in 4 |
Operations and Maintenance | Operational processes that are particularly helpful for maintaining mobile device security, and thus should be performed regularly, include the following: Checking for upgrades and patches to the mobile device solution components (includ | |
| 4.5 in 4 |
Disposal | Before a mobile device component permanently leaves an organization (such as when a leased server’s lease expires or when an obsolete mobile device is being recycled) or is reassigned to another user, the organization should remove any sens |
11 of 11.