IT Security Procedural Guide: Securing Mobile Devices and

Office of the Chief Information Security Officer

Revision 5

June 16, 2022

IT Security Procedural Guide:

Securing Mobile Devices and

Applications

CIO-IT Security-12-67

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration

VERSION HISTORY/CHANGE RECORD

Change

Number

Person

Posting

Change

Reason for Change

Page

Number of

Change

Initial Release

N/A

Initial Release

Mobile Device Security

Guidance

N/A

Revision 2

Eaton

Integrated ILs and added additional

language

Required revisions

Revision 3 – May 20, 2014

Eaton

Made revisions per 2013 audit

findings

OIG Audit findings – 2013

Pages 4 and

22-24

Heard

Made revisions per 800 53, Rev 4

SC-9 has been incorporated

into SC-8 800-53 rev 4. SC-9

was withdrawn

Heard/

Atwater

Verification of links and attachments

Throughout

Revision 4 – January 26, 2018

Dean/

Feliksa

Changes made throughout the

document to reflect current

procedural guide format

Throughout

Revision 5 – June 16, 2022

IS/ISDT

Primary changes are:

- Updated references and

links

- Added Google MDM

- Major revisions to the

process sections

Changes in GSA process and

products used to manage

mobile devices.

Throughout

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration

Approval

IT Security Procedural Guide: Securing Mobile Devices and Applications, CIO-IT Security 12-67,

Revision 5, is hereby approved for distribution.

Bo Berlas

GSA Chief Information Security Officer

Contact: GSA Office of the Chief Information Security Officer (OCISO), Policy and Compliance

Division (ISP) at [email protected].

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration i

Table of Contents

1 Introduction ............................................................................................................................... 2

1.1 Purpose .......................................................................................................................................... 3

1.2 Scope .............................................................................................................................................. 3

1.3 Purpose .......................................................................................................................................... 3

1.4 References ..................................................................................................................................... 4

2 Mobile Device Management (MDM) Architecture ........................................................................ 4

3 GSA Mobile Device Website ........................................................................................................ 6

4 GSA Mobile Device Process ......................................................................................................... 7

4.1 GSA’s Bring Your Own Device (BYOD) Policy ................................................................................. 7

4.2 Mobile Device Solution Lifecycle ................................................................................................... 8

4.3 Mobile Device Acquisition Procedures .......................................................................................... 8

4.4 Mobile Device Operations and Maintenance ................................................................................ 9

5 Mobile Device Security Best Practice Resources ........................................................................... 9

5.1 GSA Mobile Security ...................................................................................................................... 9

6 Providing Assurance of Security Controls ................................................................................... 10

6.1 Google MDM Device Policy Settings ............................................................................................ 10

6.2 Mobile Device Inventory/Compliance Report ............................................................................. 10

7 User Compliance Requirements ................................................................................................. 10

8 Mobile Device Applications ....................................................................................................... 11

8.1 Mobile Application Review and Approval.................................................................................... 12

8.2 Application Sources ..................................................................................................................... 13

8.3 Terms of Service (ToS) and Privacy Discipline ............................................................................. 14

8.4 Inventory and Application Blacklisting ........................................................................................ 15

8.5 GSA App Development, Assessment, Authorization and Deployment........................................ 16

Figure 8-1: Mobile Application Working Group Review Process ......................................................... 12

Notes:

 Hyperlinks in running text will be provided if they link to a location within this document

(i.e., a different section or an appendix). Hyperlinks will be provided for external sources

unless the hyperlink is to a web page or document listed in Section 1.4.

 It may be necessary to copy and paste hyperlinks in this document (Right-Click, Select

Copy Hyperlink) directly into a web browser rather than using Ctrl-Click to access them

within the document

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 2

1 Introduction

Mobile devices, like all enterprise devices, need to support the security objectives of

confidentiality, integrity, and availability. To achieve these objectives, mobile devices should be

secured against a variety of threats. General security recommendations for any IT technology

are provided in National Institute of Standards and Technology (NIST)Special Publication (SP)

800-53, Revision 5, “Security and Privacy Controls for Information Systems and Organizations.”

Specific recommendations for securing mobile devices are presented in this publication and are

intended to supplement the controls specified in NIST SP 800-53. Additional specific guidance

on mobile devices and applications can be found in the current NIST SP 800-124, Revision 1,

“Guidelines for Managing the Security of Mobile Devices in the Enterprise.” This guide is built

upon the framework outlined in each.

NIST SP 800-124 provides recommendations for securing particular types of mobile devices,

such as smartphones and tablets. Laptops are specifically excluded from the scope of the NIST

publication and this guide because the security controls available for laptops today are quite

different from those available for smartphones, tablets, and other mobile device types. Mobile

devices with minimal computing capability, such as basic cell phones, are also out of scope

because of the limited security options available and the limited threats they face.

Centralized mobile device management (MDM) technologies are used to control the use of

both organization-issued and personally-owned mobile devices by enterprise users (i.e., Bring

Your Own Device [BYOD]). In addition to managing the configuration and security of mobile

devices, these technologies offer other features, such as providing secure access to enterprise

computing resources. There are two basic approaches to centralized mobile device

management: (1) use a messaging server’s management capabilities (sometimes from the same

vendor that makes a particular brand of phone); (2) use a product from a third party, which is

designed to manage one or more brands of phone. GSA has implemented the latter approach

with the use of the Google MDM (as part of Google Apps for Government) and the cloud based,

MaaS 360 MDM by IBM.

Below is a summary of how GSA is addressing the strategic goals as listed in NIST SP 800-124:

 Organizations should have a mobile device security policy: The details are documented

in this guide.

 Organizations should develop system threat models for mobile devices and the

resources that are accessed through the mobile devices: GSA uses MaaS360 and

Google MDM to satisfy this requirement. MaaS360/Google MDM have the ability to

provide detailed software listings for all devices so that Administrators and

Management are aware of applications in use. Additionally, any application found to

provide an unacceptable risk to Enterprise data or assets can be restricted based on that

threat, for both Android and iOS smartphones and tablets.

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 3

 Organizations deploying mobile devices should consider the merits of each provided

security service, determine which services are needed for their environment, and then

design and acquire one or more solutions that collectively provide the necessary

services: GSA has determined that all devices (iOS and Android) must have MaaS360

AND Lookout mobile security to satisfy this requirement. As such, all devices are

monitored to ensure once installed, they remain active and updated to provide an

adequate level of security for all mobile smartphones and tablets.

 Organizations should implement and test a prototype of any mobile device solution

before putting the solution into production: All mobile devices must be tested by the

Mobile Device team and/or the Office of the Chief Information Officer (OCIO),

Information Systems Security Manager (ISSM). Subsequently, they must be approved for

use by the OCIO, ISSM, and Mobile Device Team with a published configuration guide,

before being issued to GSA users or approved for use under the BYOD guidelines.

 Organizations should fully secure each organization-issued mobile device before

allowing a user to access it: MaaS360 must be provisioned and activated on a device

(Government or BYOD) before being approved in the Google Administrative console

(CPanel) to allow the syncing of GSA data by the Mobile Device Team.

 Organizations should regularly maintain mobile device security: The GSA ISSM,

Security Operations Division (ISO) Team, and the GSA Mobile Device Team, are charged

with the periodic monitoring of all mobile devices and shall implement a methodology

of periodic reporting that shall be archived for review and adjustment of the overall

security strategy for mobile devices in GSA.

1.1 Purpose

The purpose of this guide is to outline how GSA centrally manages and secures mobile devices,

such as smartphones and tablets and the applications loaded on them. This publication also

explains the security concerns inherent in mobile device use and provides direction on securing

mobile devices throughout their life cycle.

1.2 Scope

The requirements outlined within this guide apply to and must be followed by all GSA Federal

Employees, contractors and associates of GSA issued a mobile device or who have a personally

owned device approved to be in GSA’s BYOD program.

1.3 Purpose

Securing Mobile Devices is covered in Chapter 4, paragraph 6 of CIO 2100.1 as stated in the

following paragraphs.

“GSA users must secure mobile devices, like all enterprise devices, against a variety of threats.

This includes handling PII/CUI. Included in the definition of ‘Mobile devices’ are smartphones

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 4

and tablets. Excluded in the definition of mobile devices are laptops since the security controls

for laptops are quite different from smartphones. Also excluded in the definition are basic cell

phones due to the limited security options available and their limited threat. GSA has outlined

information on mobile devices at https://sites.google.com/a/gsa.gov/mobileinfo/. GSA CIO-IT

Security-12-67 is designated as the GSA policy on mobile devices and applications and provides

specific information security requirements.”

Additional information related to mobile devices and self-help for employees and contractors

can be found on the Mobile Devices (phone, tablets) InSite webpage.

1.4 References

Federal Laws, Standards, Regulations, and Publications:

 Public Law 113-282, “Federal Information Security Modernization Act of 2014”

 NIST SP 800-53, Revision 5, “Security and Privacy Controls for Information Systems and

Organizations”

 NIST SP 800-124, Revision 1, “Guidelines for Managing the Security of Mobile Devices in

the Enterprise”

GSA Policies, Procedures, and Guidance:

 GSA Order CIO 2100.1, “GSA Information Technology (IT) Security Policy”

 GSA Rules of Behavior for Personally Owned Mobile Devices

 CIO-IT Security-06-30, “Managing Enterprise Cybersecurity Risk”

 CIO IDTI-15-01, “GSA IT Procedural Guide: Oversight and Management of GSA’s Mobile

Device Program”

 InSite – Mobile Devices (Phones, Tablets) – link to information on mobile devices

 InSite – Information Technology: Security – link to additional IT security guides

2 Mobile Device Management (MDM) Architecture

GSA implements a defense in depth concept in MDM with the use of the Google MDM feature

set as well as the MaaS360 MDM platform for security of mobile devices in the Enterprise.

The security services provided by Google MDM and Maas360 provide the ability to implement

security of the following categories identified in NIST SP 800-124. The list contains complete

capabilities of the MDM platforms, however not all items listed have been configured for use as

GSA’s deployment of mobile devices is still being tested and developed. GSA’s current settings

are found as embedded documents at the end of this section and are boldfaced at the end of

each bullet.

 General Policy: General policy restrictions for mobile device:

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 5

o GSA does not restrict user and application access to hardware, such as the digital

camera, GPS, Bluetooth interface, USB interface, and removable storage.

o GSA does not restrict user and application access to the built-in web browser,

email client, application installation services, etc.

o GSA does not restrict the use of wireless network interfaces (Wi-Fi, Bluetooth,

etc.)

o GSA automatically monitors, detects, and reports when policy violations occur

using MaaS360/Google MDM.

 Data Communication and Storage:

o Strong encryption of data communications between the mobile device and the

organization is managed by MaaS360/Google MDM. This is most often in the

form of a VPN, although it can be established through other uses of encryption.

o Strong encryption of stored data on both built-in storage and removable media

storage is managed by MaaS360 and Google MDM, as well as device

configuration policies implemented during initial device configuration.

Removable media can also be “bound” to particular devices such that encrypted

information can only be decrypted when the removable media is attached to the

device, thereby mitigating the risk of offline attacks on the media.

o Remote wiping of mobile devices (to scrub its stored data) if it is suspected that

the device has been lost, stolen, or otherwise fallen into untrusted hands and is

at risk of having its data recovered by an untrusted party is managed by

MaaS360 and Google MDM and device configuration policies. A device often can

also be configured to wipe itself after a certain number of incorrect

authentication attempts.

 User and Device Authentication:

o GSA MDM policy requires a password/passcode and/or other authentication

(e.g., domain authentication) before accessing the organization’s resources. This

includes basic parameters for password strength and a limit on the number of

retries permitted without negative consequences (e.g., locking out the account,

wiping the device). All managed devices have a passcode with a min. of a 6

character passcode.

o If device account lockout is enabled or the device password/passcode is

forgotten, an administrator can reset this remotely to restore access to the

device using MaaS360/Google MDM in addition to device configuration policies.

o MaaS360 and/or Google CPanel as well as device configuration policies ensure

that the device automatically locks itself after it is idle for a period (e.g., 5 -15

minutes).

o Remote locking of the device, if it is suspected that the device has been left in an

unlocked state in an unsecured location, is configured and managed by MaaS360

and/or Google CPanel as well as device configuration policies.

 Applications:

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 6

o GSA currently restricts applications that may be installed through blacklisting

using Lookout for Work.

o Installs, updates, and removal of applications are configured and managed by

MaaS360 and/or Google MDM as well as device configuration policies.

o The use of synchronization services (e.g., local device synchronization, remote

synchronization services and websites) is monitored by Cisco Umbrella for URI

restriction and Lookout for Work for Applications. These solutions allow GSA to

ban or block malicious apps or websites from being loaded to the mobile device.

o Digital signing of applications to ensure that only applications from trusted

entities are installed on the device, and that code has not been modified, is

managed by MaaS360 and/or Google MDM as well as device configuration

policies.

o Limiting and preventing access to the enterprise based on the mobile device’s

operating system version (including whether the device has been

jailbroken/rooted) or its mobile device management software client version (if

applicable), is managed by MaaS360 and/or Google MDM as well as device

configuration policies.

 The MDM Policy Settings Google folder contains the following settings:

o Google Cpanel Settings - Administrative Console

o MaaS360 Android Policy – for Android devices

o Google Android for Enterprise Settings

o MaaS360 iOS Policy – for iOS devices

3 GSA Mobile Device Website

GSA has outlined, for users and administrators, all approved devices (government and

personally procured), the hardening requirements for each, as well as all policies and programs

for users & administrators can be found on the GSA Mobile Support Site.

Found on the site are:

 A listing of all approved devices – these devices are tested by the Mobile Device team

and certified/approved by the OCIO, ISSM before release to users

 End of Life Devices

 Blacklisted Mobile Apps

 Mobile Device/Application policies

 Rules of Behavior for use of approved personally owned devices

 Use of the “Application Specific Password”

 An outline of policy for procurement of government mobile devices

This site is maintained by the Mobile Device Management team under the supervision of the

Director of Applied Solutions, OCIO, and the GSA Infrastructure ISSM who is charged with

overall management of GSA’s mobile device security strategy.

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 7

4 GSA Mobile Device Process

The following sections provide information on mobile devices, their lifecycle, and their

procurement, implementation, and maintenance.

4.1 GSA’s Bring Your Own Device (BYOD) Policy

GSA has implemented a BYOD policy that allows users to connect their non-GSA procured

devices, which have been previously approved by IT security, to GSA resources in a native

fashion. This policy only applies to smartphones/tablets. There should be no expectation of

reimbursement to the user by the Federal Government when this policy is enacted at the

request of a user for either the cost of the device or the wireless service running on it.

GSA will not pay for the replacement or repair of any personally owned devices even if they are

used for work purposes. The BYOD Program is strictly voluntary, employees may choose to use

their personal mobile device for work, but no one is required to do so. Use of personally owned

devices in addition to, or instead of, GFE is the employee’s choice, under management

discretion.

The following guidelines outline the current BYOD Policy for GSA employees and contractors:

 The user (owner of the personal device) must agree to and sign the Rules of Behavior

(ROB) for personally owned devices.

 In signing the ROB, the user understands that the device will become a GSA managed

system with a GSA policy managing the overall operation of the device.

MaaS360/Google MDM, and all other required security settings/policies will be enabled

on their device.

 Users acknowledge there is no expectation of privacy under BYOD.

 The user understands that if the device is lost or stolen, it must be immediately reported

to the IT Service Desk upon discovery of the loss or theft.

 The user understands that the device may be wiped, if deemed necessary by GSA IT

Security officials, without prior notification to the user.

 The mobile device should be protected in the same manner as a valuable personal item

and should not be left unattended in public places, automobiles, etc.

 The user will not install, transfer, or access classified information with the device. The

mobile device shall automatically lockout within 15 minutes of inactivity.

 The session lock shall remain in effect until the user reestablishes access using

appropriate identification and authentication.

 The device will automatically wipe after 10 unsuccessful attempts at logon.

 The device will maintain a minimum passcode length of 6 characters.

 Encryption must be enforced on the device at all times.

 The device must support a remote wipe capability and be configured to allow remote

wiping in the event the device is lost or stolen.

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 8

 The device’s operating system (OS) must be maintained and kept up to date, with such

updates occurring not later than 30 days after release.

 GSA will not be liable for any loss of personal data due to a remote wipe required under

any circumstance.

 The device owner is responsible for any and all maintenance, repairs, warranties,

accessories, and the like for their personally owned device.

 The GSA OCIO is not responsible for supporting personally owned devices or training

users on the devices.

 GSA funding for devices/services may be allowed for certain exceptions to allow for

Reasonable Accommodation or other special circumstances. OCIO will review requests

for exceptions on a case-by-case basis.

4.2 Mobile Device Solution Lifecycle

NIST SP 800-124 outlines how the concepts presented in this guide should be incorporated

throughout the entire life cycle of enterprise mobile device solutions, involving everything from

policy to operations. The section references a five-phase life cycle model to help outline at what

point in their mobile device solution deployments a recommendation may be relevant. The

phases of the life cycle are as follows:

 Phase 1: Initiation. This phase is considered complete with the publication of this guide

and all supporting documentation.

 Phase 2: Development. In this phase, the OCISO and the OCIO, ISSM shall coordinate

activities to outline new guidelines, security requirements, and best practices as they

evolve. They shall be incorporated into this guide, the SOPs of operational staff and the

Mobile Device site referenced in Section 4.4 below.

 Phase 3: Implementation. In this phase, equipment is configured in accordance with

published hardening guides and is managed utilizing the procedures outlined in Section

2 above.

 Phase 4: Operations and Maintenance. This phase is outlined in Section 4.5 below.

 Phase 5: Disposal. All mobile devices shall be either remotely wiped or local reset to

factory defaults (under settings) for both internal storage and any/all media cards prior

to excess or reissue to meet the requirements of this phase.

4.3 Mobile Device Acquisition Procedures

Procedures to acquire a mobile device can be found on the Procurement of Mobile Devices

webpage. OCIO will manage and provide technical support for smartphones and tablet devices

within the current infrastructure support environment. Service and/or Staff Offices (S/SO) may

purchase subject devices, in accordance with applicable law and regulations, when it has been

determined that a business need can support such a purchase. It is imperative that all aspects

of the Federal Acquisition Regulation (FAR) be followed when purchasing mobile devices,

including brand name justification requirements. OCIO has determined that there is no

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 9

requirement for centralized acquisition of smart phones or tablet devices on an enterprise basis

beyond what is provided under the current enterprise contract for no cost.

All smartphones and tablets must be assessed for security prior to approval and use by GSA

users. This includes both Government furnished equipment and those implemented under the

BYOD guidelines addressed elsewhere in this guide. This assessment, once completed, should

constitute approval for as long as devices of this type are in use throughout the Enterprise.

4.4 Mobile Device Operations and Maintenance

The OCIO staff is charged with the lifecycle maintenance of all mobile devices in GSA as

described in GSA IT Procedural Guide: Oversight & Management of GSA’s Mobile Device

Program v7.0 Guide CIO-IDTI-15-01. This includes:

 Proper provisioning of all devices (both Government and personally owned) in

accordance with applicable hardening guides and this publication

 Management of the MaaS360 and Google MDM platforms, configuration settings,

administrator alerts, remote wiping of devices and application management

 Proper device wiping to sanitize media, including internal and external storage, on all

devices prior to disposal or reuse.

5 Mobile Device Security Best Practice Resources

The security objectives of mobile devices are accomplished through a combination of security

features built into the mobile devices and additional security controls applied to the mobile

devices and other components of the enterprise IT infrastructure, as described throughout this

guide and the Mobile Device site, as well as steps taken by end users. Additional resources

available for administrators and users alike are listed below:

 United States Computer Emergency Readiness Team (US-CERT), "Cyber Threats to

Mobile Phones"

 US-CERT TIP-10-105-01, “Cyber Threats to Mobile Devices”

 US-CERT ST04-017, “Protecting Portable Devices: Physical Security”

 US-CERT ST04-020, “Protecting Portable Devices: Data Security”

 US-CERT ST05-003, “Securing Wireless Networks”

 US-CERT ST05-017, “Cybersecurity for Electronic Devices”

 US-CERT ST06-007, “Defending Cell Phones and PDAs Against Attack”

 US-CERT Podcast Episode, “Mobile Device Security: Threats, Risks, and Actions to Take”

5.1 GSA Mobile Security

GSA has solutions that protect mobile devices for malicious activities that include web browsing

and application behavior.

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 10

 Cisco Umbrella

o GSA implementation of Cisco Umbrella on iOS devices allow GSA OCISO to

protect mobile devices and applications from attempting to connect to malicious

URI. The rules are in sync with Enterprise Firewall Rules.

 Lookout for Work

o Mobile Threat Defender service that identifies potential threats for the

Enterprise Android and iOS devices. The solution allows GSA to deny or allow

applications. If a denied application is installed the user’s internet access is

denied until the application is removed from the device.

6 Providing Assurance of Security Controls

The following sections provide information on security controls and the tools used

to manage them:

6.1 Google MDM Device Policy Settings

The documented settings in the MDM policy settings docs Google folder provides a listing of

the device configuration and policy settings for Mobile Devices that GSA/MaaS360 manages.

Included in that folder are the following files with settings information:

 GSA_MDM_Android

 GSA_MDM_NON DEP IOS

 GSA_MDM_DEP_LFW

 Google Cpanel Settings

6.2 Mobile Device Inventory/Compliance Report

The Mobile Device Team reviews the compliance dashboard in MaaS360 routinely and takes

action as appropriate to include sending an email to individuals who are out of compliance with

MDM policies.

7 User Compliance Requirements

A user may NOT connect a mobile device to GSA resources (Mail, Drive, VPN, etc.) or store ANY

GSA data on any device (personally owned or government furnished) without complying with

all aspects of this guide.

It is expected that all users, whether using government issued mobile devices or personally

owned devices using the BYOD program, are to comply with all aspects of this guide. User

compliance is mandatory and deviation from standards addressed here constitute a violation of

GSA policy and shall be addressed by Administrators or IT Security personnel as outlined below,

depending on the actual non-compliant event and its seriousness. Recurring violations of

compliance standards are grounds to potentially remove access to GSA resources without prior

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 11

notification, whether issued a GSA owned device or a personally owned device under the BYOD

program. These compliance enforcement steps are taken in the order listed below and are

enforced, based on the situation and severity of the issue:

 Contacting the user to notify them of non-compliance and rectifying actions required

 Blocking the user’s access to GSA resources via either the Google or MaaS360 MDM

solutions

 Locking the user’s device remotely, forcing the user to contact the IT Service Desk to

correct the non-compliant event

 Remotely wiping the device, whether it be a selective (GSA data only) or full wipe

Both Android and iOS (Apple devices) have certain user controlled functions that must also be

adhered to at all times. The following are mandatory settings and apps for all devices, whether

they are government owned or under the BYOD program. These settings/apps must be set by

the user and not changed/removed at any time.

For Android devices:

 All devices must have the Lookout Mobile Security app loaded and kept up to date

 All devices must have the MaaS360 app loaded and kept up to date

 Unknown Sources must remain unchecked in the device settings

 Auto-update of apps must be enabled (this also ensures all non-security related apps are

kept updated for user benefit)

For iOS (Apple) devices:

 All devices must have the MaaS360 app loaded and kept up to date

 All devices must have the MaaS360 Security Profile (in mail) loaded and kept up to date

 All apps must be kept up to date from the “App Store” icon. NOTE: A small red number

will appear next to the icon when an app requires updating.

8 Mobile Device Applications

A mobile application, most commonly referred to as an app, is a type of application software

designed to run on a mobile device, such as a smartphone or tablet computer. Mobile

applications frequently serve to provide users with similar services to those accessed on PCs.

Apps are generally small, individual software units with limited capabilities and isolated

functionality. The simplest apps are developed to utilize the web browser of the mobile device

to provide a feature set integration much like what is found on a user’s PC. However, as mobile

app development has grown, a more sophisticated approach involves developing applications

specifically for the mobile environment, taking advantage of both its limitations and

advantages. For example, apps that use location-based features are inherently built from the

ground up with an eye to mobile devices given that you do not have the same concept of

location on a PC. With this new paradigm in both mobile platforms and the applications loaded

on them, GSA will concentrate security focus on the following goals:

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 12

 All apps loaded have a policy in place (this guide) to accurately describe when an

assessment by GSA for acceptability is required and then a security assessment &

authorization, when deemed as a requirement.

 All apps are deployed from only trusted sources, following their security/assessment

process – This presently is the Apple ITunes store for iOS and the Google Play store for

Android.

 Terms of Service (ToS) discipline is adhered to, based on acceptability of an app – either

as an individual user or for GSA as an Agency.

 Apps deemed to be unacceptable are denied, using Lookout for work

 Mobile app inventory for all devices is maintained using MaaS360 /Google MDM

 GSA developed apps are assessed, evaluated, and approved by the Authorizing Official

(AO) for the system they support before deployment.

8.1 Mobile Application Review and Approval

Mobile apps are generally categorized, shown in the figure below, in the following manner:

Figure 8-1: Mobile Application Working Group Review Process

 GSA (or other Federal Agency) Apps that have undergone an assessment and

authorization process by their AO as outlined in GSA IT Security 06-30, Managing

Enterprise Risk and have been published in either the ITunes or Google Play store.

(Approved)

 Apps that have undergone a review, ToS validation, security assessment and final

approval by the GSA CISO. (Approved)

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 13

 Apps that required a review, ToS validation & security assessment and were deemed

unacceptable by the CISO based on any/all of the criteria. (Unapproved)

 Apps that were determined not to require further ToS validation or assessment.

(Acceptable).

*Mobile applications are still subject to periodic review by the Mobile Device Team and the

Enterprise ISSM and staff. Mobile applications may be re-categorized into one of the above

categories if deemed appropriate.

The initial mobile app review performed by a user wishing to install an application, or any other

party within GSA determines the above criteria based on whether the app itself might in some

way compromise the integrity of GSA’s network, user credentials or GSA data. In the initial

review, a user performing the review physically loads the app onto a device to:

 Validate its function

 Verify accessibility to either the GSA infrastructure or data.

 Determine if GSA user credentials are required for the apps function.

 Determine if data is stored, is then placed in an unapproved location (such as an

unauthorized cloud storage server farm).

Apps intended to be procured using Government funds must also undergo a full assessment,

ToS validation and approval by the CISO. A process flow on the following page denotes this

process.

The apps reviewed originate from two sources:

 A periodic review of the Mobile App Inventory taken from MaaS

 An app requested by a user to the Mobile Device team, or any IT security member of the

GSA CISO’s office

Once the app has been categorized and an assessment completed and/or approval has been

received (if required), this status shall be noted to assist users in determining apps that are

already allowed in the environment.

8.2 Application Sources

Allowing mobile apps to be loaded from an unknown source presents one of the greatest risks

to GSA’s environment when using mobile devices. “Side loading” of apps is a process where a

user installs an application from a source other than the Apple ITunes store or Google Play

store. Jailbreaking, or rooting, is a process where an OS of a mobile device grants a user or

application root level access to the OS. DEP allows for visibility and management of the mobile

devices, so if jailbreaking occurs on a device, the device can be “bricked”. While the risk is low,

monitoring for jailbreaking is still in place. If a user jailbreaks a device, side loading can occur as

well. While iOS devices that are not jailbroken/rooted protect against sideloading, the Android

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 14

OS allows a user to turn such protection on/off (allow unknown sources) if not managed by

MDM.

As such, the following policies apply to all GSA devices (Government and BYOD) used in the

environment to protect against side loading of apps:

 Devices shall not be jailbroken/rooted by users or apps loaded by users. GSA’s MDM

solution shall immediately notify an administrator of all such incidents immediately for

remediation.

 Unknown sources shall not be enabled by users or applications. GSA’s MDM solution

shall immediately notify an administrator of all such incidents for remediation.

 GSA developed apps may be sideloaded for testing purposes only on test devices, but

production deployment of GSA developed apps may only be done via the policies

outlined below for Apple iOS and Google Android. The GSA MaaS store may be

employed for enterprise deployments, but only after the app has undergone the

review/approval processes outlined at the links below:

o Apple ITunes App Review Guidelines

o Google Play

8.3 Terms of Service (ToS) and Privacy Discipline

Many terms found in commercial TOS or End User License Agreements (EULA) are not

acceptable when the Government is the end user. OCIO requires that software and services

within the GSA Enterprise have approved TOS or EULA.

Apps deemed to be acceptable: are loaded at the discretion of the user for either personal use

or as a personal productivity tool to further enhance the work experience. As such, use of the

app is not mandated by the agency and therefore acceptance of the ToS falls upon the user as

an individual. This is true even if the app is loaded using a gsa.gov domain account or registered

with a user’s gsa.gov email address.

Apps that are approved after formal assessment: and include a formal review by GSA Counsel

as part of the review/approval process, where the ToS was found to be acceptable to the

government or a modified ToS was negotiated as part of the approval review, prior to final

authorization. When loaded and activated, the user is accepting the ToS (often a technical

function required of the user), not as an individual, but as an employee or contract employee

assigned to perform work functions for GSA.

Privacy considerations must be addressed for commercial applications and applications

developed by GSA for use by GSA personnel or for the general public.

As such, the following guidelines are to be adhered to:

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 15

 Commercial applications – When reviewed for acceptability, consideration should be

given to whether Personally Identifiable Information (PII) is collected. The app

developer/sponsor should complete and submit a Privacy Threshold Assessment (PTA)

to the GSA Privacy Office. This review will help ensure an adequate privacy notification

is given to users prior to their installation and use of the app. Such notification should at

a minimum include links to what data is being collected and for what purposes, as well

as how it might be disclosed by those collecting it.

 If the app collects, maintains or disseminates PII or other sensitive GSA data, a Privacy

Impact Assessment (PIA) must be generated for the app and filed for consideration by

the GSA Privacy Office (see GSA Privacy Program website). If the GSA Privacy Office

determines that a Statement of Records Notice (SORN) is also required, the app

developer or sponsor must draft it as well.

 GSA developed applications – A GSA developed mobile app should undergo all the same

reviews, procedures, and practices given to any developed application on any other

platform. This should be documented in the PIA and System Security and Privacy Plan

(SSPP) for which the mobile app is a part of and a Privacy Notice must be included on

the home screen of the mobile app itself.

 If the app does NOT collect PII, at a minimum, the Privacy Notice should indicate that to

the user. This can be done by taking the user to another screen on the app prior to

launch, or by any means that allows a user to close the app prior to use before they are

taken to an interactive screen.

o If the mobile app DOES collection PII, the following minimum guidelines should

be adhered to:

 The app must provide a Privacy Policy that is easily accessible to users

through the commercial app store before installation as well as within

the app itself, after installation. This Privacy Policy should be app-specific

and cannot merely reference the GSA website Privacy Policy (see below

for an example/template).

 The Privacy Policy must briefly describe the app’s information practices

including the collection, use, sharing, disclosure, and retention of PII or

other sensitive information.

 Example Privacy Notice: This mobile application does collect your

personal information. We collect (developer insert information here). Your

personal information is collected so we can (developer insert information

here). Your personal information is stored in (developer insert information

here) GSA system. For additional information, please visit GSA’s [insert

appropriate SORN] and [insert appropriate PIA] for this app.

8.4 Inventory and Application Blacklisting

MaaS360/Lookout for Work will be the authoritative source for mobile app inventory, by device

and version history. This inventory will be used by the Security in their ongoing application

review/assessment program for both iOS and Android platforms. It will also be used to review

the overall health of the application security program by the OCISO and ISSM.

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 16

Application monitoring is a function of the MaaS360 platform and shall be managed by the

Mobile Device Team under the direction of the OCISO and the ISSM. If an app is deemed high

risk and has current deployments already existing on devices, it is the responsibility of the

Mobile Device Team to coordinate its removal with the user.

8.5 GSA App Development, Assessment, Authorization and Deployment

The Mobile Device Team along with the Enterprise ISSM and staff take input from sources such

as Lookout, Inc., DHS, Law Enforcement, and other publicly dispersed assessments and provide

recommendations to the CISO on improving the mobile device/application environment in GSA.

GSA developed custom applications in support of business line functions follow the process

outlined below for Android and iOS deployments:

 Initial request to the Mobile Device Team for development environment access (if

necessary).

 Security Engineering Division (ISE) team conducts static application security testing/

Dynamic application security testing (SAST/DAST) code reviews of completed application

code

 Security Operations Division (ISO) team reviews and approves operational tasks and

internal/external connections, level of access to internal GSA systems, and overall risk

rating.

 Enterprise Application and Infrastructure Support Branch (ISTE) Security Team provides

final security approval for production deployment and ensures that mobile application is

called out in applicable system SSPP(s).

GSA developed apps are designed to take advantage of the concept of Anytime, Any Where,

Any Device (A3) to allow GSA users and customers to access GSA data while mobile. As such, as

GSA business lines develop apps for use on the iOS and Android environment, these apps must

undergo an assessment and authorization process before being deployed. With that in mind,

the following guidelines are to be followed:

 A GSA developed app that supports a GSA Federal Information Security Modernization

Act of 2014 (FISMA) system must be documented in the SSPP and authorized to operate

as part of a current ATO letter from the respective AO before deployment. IT Security

Procedural Guide CIO-IT 06-30, “Managing Enterprise Cybersecurity Risk”, is to be

followed for this process. Any app that is not directly tied to an already existing system

authorized to operate must have an assessment performed and subsequently approved

for release by the CISO.

 Any mobile app development shall result in a minimum of the release of both an iOS

and Android version of the app. This ensures coverage to all users within GSA and the

maximum coverage for apps released to the public. Any additional application versions

for alternate OS mobile platforms may be developed for such apps, but iOS and Android

shall remain as the core base OSs for GSA developed mobile apps for all releases.

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 17

 All GSA developed apps must follow the respective application review and publication

guidelines for the OS to which they were developed.

 Other than for testing purposes on non-user provisioned mobile devices, side loading of

apps in the environment is not authorized.

 The GSA MaaS360 Store is authorized for enterprise deployment of apps to GSA user

devices once that app has been assessed, authorized, and published according to the

guidelines outlined in this section.

 Mobile code scanning throughout the development cycle is critical, but before release

by the Mobile Device Team, a mobile app must be scanned by the ISE Team within the

OCISO. This scan is a source code scan using an approved code scanner. As with all

applications in GSA, no High/Critical findings are allowed from these scan results.

Moderate findings should be documented in the respective Plan of Action and

Milestones (POA&M) for the system by which the app is authorized and accepted by the

AO; Low and Informational findings should be taken into consideration by the

developers for their next iteration of app development. A detailed process for mobile

app release is documented at the end of this section.

 All mobile application development should take into consideration the Open Web

Application Security Project (OWASP) Mobile Security Project in developing mobile apps

either within GSA or for use by the general public.

o OWASP Mobile Security Project Home Page

o OWASP Mobile Security Testing Guide

 GSA developed mobile apps must undergo an assessment review and approval process

before being released for use. These apps fall into two categories that have slightly

different processes for approval, with many common steps.

o Mobile apps that are developed as part of another system with a current ATO

and provide access to an application using a different form factor than the

common steps outlined below, such apps must be documented in the SSPP for

the system they support.

o Mobile apps designed for a specific purpose that are not part of a current ATO

and therefore, stand alone in their authorization to operate. As these apps do

not have a parent system they support, the below listed process is the complete

assessment process required for these apps.

 Common to both approval processes, all apps must

o Be scanned prior to release by the ISE Division of the CISO using an approved

code scanner. No Critical/High findings may remain for approval to be received

and any moderate/medium findings must be contained in a POA&M, either for

the system the app is a part of, or a separate POA&M if a standalone mobile app.

o Have a PTA/PIA completed and if applicable, tied to either an existing SORN or

have a new SORN initiated and approved by the GSA Privacy Office and Office of

the General Counsel.

o A mobile application security assessment review must be completed and signed

by the mobile app owner, mobile app assessor, mobile app ISSM, a

representative of the IST division of the OCSIO and a representative of the ISE

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40

CIO-IT Security-12-67, Revision 5 Securing Mobile Devices and Applications

U.S. General Services Administration 18

division of the OCISO, to denote a proper assessment and review was conducted

of the mobile app prior to release.

DocuSign Envelope ID: 9A696EAA-0C51-462A-8CCC-5A47BF5F4B40