For more than 50 years, Auerbach Publications has been printing cutting-edge books on all topics IT.

Read archived articles or become a new subscriber to IT Today, a free newsletter.

This free newsetter offers strategies and insight to managers and hackers alike. Become a new subscriber today.


Partners




Contact

Interested in submitting an article? Want to comment about an article?

Contact John Wyzalek editor of IT Performance Improvement.

 

Security for the Enterprise Mobile
Device Life Cycle

Jessica Keyes

This article explains the entire life cycle of enterprise mobile device solutions, involving everything from policy to operations. It references a five-phase life cycle model to help organizations determine at what point in their mobile device solution deployments a recommendation may be relevant. Organizations may follow a project management methodology or life cycle model that does not directly map to the phases in the model presented here, but the types of tasks in the methodology and their sequencing are probably similar. The phases of the life cycle are as follows:

Phase 1: Initiation. This phase involves the tasks that an organization should perform before it starts to design a mobile device solution. These include identifying needs for mobile devices, providing an overall vision for how mobile device solutions would support the mission of the organization, creating a high-level strategy for implementing mobile device solutions, developing a mobile device security policy, and specifying business and functional requirements for the solution.

Phase 2: Development. In this phase, personnel specify the technical characteristics of the mobile device solution and related components. These include the authentication methods and the cryptographic mechanisms used to protect communications and stored data. The types of mobile device clients to be used should also be considered, since they can affect the desired policies. Care should be taken to ensure that the mobile device security policy can be employed and enforced by all clients. At the end of this phase, solution components are procured.

Phase 3: Implementation. In this phase, equipment is configured to meet operational and security requirements, including the mobile device security policy documented in the system security plan, installed and tested as a prototype, and then activated on a production network. Implementation includes integration with other security controls and technologies, such as security event logging and authentication servers.

Phase 4: Operations and Maintenance. This phase includes security- related tasks that an organization should perform on an ongoing basis once the mobile device solution is operational, including log review and attack detection.

Phase 5: Disposal. This phase encompasses tasks that occur when a mobile device solution or its components are being retired, including preserving information to meet legal requirements, sanitizing media, and disposing of equipment properly.

This article highlights security considerations of particular interest for mobile device solutions. These considerations are not intended to be comprehensive, nor is there any implication that security elements not listed here are unimportant or unnecessary.

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 mobile device security policy for an organization. The section lists elements that a mobile device security policy should contain and, where relevant, describes some of the factors that should be considered when making the decisions behind each element.

A mobile device security policy should define which types of mobile devices are permitted to access the organization's resources, the degree of access that various classes of mobile devices may have (for example, organization- issued devices versus personally owned devices), and how provisioning should be handled. It should also cover how the organization's centralized mobile device management servers are administered and how policies in those servers are updated. The mobile device security policy should be documented in the system security plan. To the extent feasible and appropriate, the mobile device security policy should be consistent with and complement security policy for non-mobile systems.

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 organization might permit only organization- owned mobile devices to be used. Some organizations have tiered levels of access, such as allowing organization-issued mobile devices to access many resources, BYOD mobile devices running the organization's mobile device management client software to access a limited set of resources, and all other BYOD mobile devices to access only a few Web-based resources, such as e-mail. This allows an organization to limit the risk it incurs by permitting the most-controlled devices to have the most access and the least-controlled devices to have only minimal access.

Each organization should make its own risk-based decisions about what levels of access should be permitted from which types of mobile devices. Factors that organizations should consider when setting mobile device security policy for this include the following:

Sensitivity of work. Some work involves access to sensitive information or resources, while other work does not. Organizations may have more restrictive requirements for work involving sensitive information, such as permitting only organization-issued devices to be used. Organizations should also be concerned about the legal issues involved in remotely scrubbing sensitive information from BYOD mobile devices.

The level of confidence in security policy compliance. Meeting many of an organization's security requirements can typically be ensured only if the organization controls the configuration of the mobile devices. For devices not running the organization's mobile device management client software, some requirements can possibly be verified by automated security health checks conducted by the mobile device management server when mobile devices attempt to connect, but other requirements cannot be verified.

Cost. Costs associated with mobile devices will vary based on policy decisions. The primary direct cost is issuing mobile devices and client software. There are also indirect costs in maintaining mobile devices and in providing technical support for users. Work location. Risks will generally be lower for devices used only in the enterprise environment than for devices used in a variety of locations.

Technical limitations. Certain types of mobile devices may be needed, such as for running a particular application. Also, an organization's mobile device management client software may only support certain types of mobile devices.

Compliance with mandates and other policies. Organizations may need to comply with mobile device-related requirements from mandates and other sources, such as a Federal department issuing policy requirements to its member agencies. An example of a possible requirement is restrictions on using mobile devices in foreign countries that have strong known threats against Federal agency systems; in such cases, it may be appropriate to issue "loaner" mobile devices or to prohibit mobile device use altogether.

Organizations may choose to specify additional security requirements that are tied to factors such as the sensitivity of work. Many organizations require more stringent security controls for work situations that are particularly high-risk, such as permitting the work only from organization- issued and secured mobile devices, and requiring the use of multi-factor authentication for access to the mobile device and to enterprise resources. Another possible security control is to migrate high-risk resources to servers that assume responsibility for protecting them; for example, a mobile device could connect to a server that holds sensitive data that the user needs to access, instead of the sensitive data being stored locally on the mobile device. In high-risk situations, organizations may also choose to reduce risk by prohibiting mobile devices from accessing particular types of information, such as sensitive personally identifiable information.

Every year, there are many changes in mobile device capabilities, the security controls available to organizations, the types of threats made to different types of devices, and so on. Therefore, organizations should periodically reassess their policies for mobile devices and consider changing which types of mobile devices are permitted and what levels of access they may be granted. Organizations should also be aware of the emergence of new types of mobile device solutions and of major changes to existing mobile device management technologies, and ensure that the organization's policies are updated accordingly as needed.

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 these additional security measures and define users' responsibilities for implementing these measures in policy and mobile device agreements.

One possible security consideration involves wireless personal area networks (WPAN), which are small-scale wireless networks that require no infrastructure to operate. Examples of WPAN technologies are using a wireless keyboard or mouse with a computer, printing wirelessly, synchronizing a mobile device with a computer wirelessly, and using a wireless headset or earpiece with a smartphone. The two most commonly used types of WPAN technologies are Bluetooth and near-field communications. For devices within proximity of significant threats, mobile device users should disable these technologies when not needed to prevent misuse by unauthorized parties.

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 be used and to design a solution to deploy. There are many considerations for designing a solution, most of which are generally applicable to any IT technology. This section focuses on the technical security considerations that are most important for designing mobile device management solutions. Major considerations include the following:

Architecture. Designing the architecture includes the selection of mobile device management server and client software, and the placement of the mobile device management server and other centralized elements.

Authentication. Authentication involves selecting device and/or user authentication methods, including determining procedures for issuing and resetting authenticators and for provisioning users and/or client devices with authenticators.

Cryptography. Decisions related to cryptography include selecting the algorithms for encryption and integrity protection of mobile device communications, and setting the key strength for algorithms that support multiple key lengths

Configuration requirements. This involves setting minimum security standards for mobile devices, such as mandatory host hardening measures and patch levels, and specifying additional security controls that must be employed on the mobile device, such as a VPN client.

Application vetting and certification requirements. This sets security, performance, and other requirements that applications must meet and determines how proof of compliance with requirements must be demonstrated.

The security aspects of the mobile device solution design should be documented in the system security plan. The organization should also consider how incidents involving the mobile device solutions should be handled and document those plans as well.

Implementation

After the mobile device solution has been designed, the next step is to implement and test a prototype 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. Users can connect to all of the organization's resources that they are permitted to and cannot connect to any other organization resources.

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.

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.

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 patches and configured following sound security practices. Also, jailbroken and rooted phones should be automatically detected to prohibit their use, for cases in which detection is feasible.

Default Settings. 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 recovered, restored to a known good state, and fully secured before returning it to its user.

Operations and Maintenance

Operational processes that are particularly helpful for maintaining mobile device security, and thus should be performed regularly, include the following:

  1. Checking for upgrades and patches to the mobile device software components, and acquiring, testing, and deploying the updates
  2. Ensuring that each mobile device infrastructure component (mobile device management servers, authentication servers, etc.) has its clock synced to a common time source so that its timestamps will match those generated by other systems
  3. Reconfiguring access control features as needed based on factors such as policy changes, technology changes, audit findings, and new security needs
  4. Detecting and documenting anomalies within the mobile device infrastructure. Such anomalies might indicate malicious activity or deviations from policy and procedures. Anomalies should be reported to other systems' administrators as appropriate.
  5. Providing training and awareness activities for mobile device users on threats and recommended security practices Organizations should also periodically perform assessments to confirm that the organization's mobile device policies, processes, and procedures are being followed properly. Assessment activities may be passive, such as reviewing logs, or active, such as performing vulnerability scans and penetration testing.
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), the organization should remove any sensitive data from the host. The task of scrubbing all sensitive data from storage devices such as hard drives and memory cards is often surprisingly difficult because of all the places where such data resides and the increasing reliance on flash memory instead of magnetic disks. An organization should strongly consider erasing all organization-issued storage devices completely.

Read more IT Performance Improvement

This article is an excerpt from:

This book explains and then helps readers live with the psycho-techno phenomenon that is bring your own device (BYOD). Readers will learn how to understand these new end-users and their demands, as well as the strategic and tactical ramifications of these demands. Next, it covers the broad range of technical considerations such as selection, connectivity, training, support, and security. The text includes best practices and case studies of well-known companies, including IBM, Ford, and CarFax.

About the Author

Jessica Keyes is president of New Art Technologies, Inc., a high-technology and management consultancy and development firm started in New York in 1989. Keyes has given seminars for such prestigious universities as Carnegie Mellon, Boston University, University of Illinois, James Madison University, and San Francisco State University. She is a frequent keynote speaker on the topics of competitive strategy and productivity and quality. She is former advisor for DataPro, McGraw-Hill’s computer research arm, as well as a member of the Sprint Business Council.

Keyes is also a founding Board of Director member of the New York Software Industry Association. She completed a two-year term on the Mayor of New York City’s Small Business Advisory Council. She currently facilitates doctoral and other courses for the University of Phoenix, and is a member of the Faculty Council for the College of Information Systems & Technology. She has been the editor for WGL’s Handbook of eBusiness and CRC Press’ Systems Development Management and Information Management.

Prior to founding New Art, Keyes was managing director of R&D for the New York Stock Exchange and has been an officer with Swiss Bank Co. and Banker’s Trust, both in New York City. She holds a Masters of Business Administration from New York University, and a doctorate in management.