Craft security policy for mobile devices

Understanding the four variables that shape a cloud mobile security policy

Enterprise users are not bound to one mobile device to access a cloud service: A user can choose to enroll more than one mobile device to an enterprise server for better device access flexibility. This flexibility makes having corporate security policy more critical than ever. To help you understand security for mobile device access to the cloud, the author illuminates the service delivery model view and the device view of the environment and presents service delivery model scenarios with checklists.

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson is a systems architect and engineer. Her areas of interest include enterprise-wide systems, middleware technologies, database technologies, cloud computing, threshold policies, industries, network management, security, RFID technologies, presentation management, and project management.



17 October 2011

Also available in Chinese Japanese Spanish

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See Cloud computing: Build an effective cloud policy

The security policy for mobile devices is shaped by four variables:

  • What operating system is used to run a mobile device.
  • Whether the cloud service is public or private.
  • How much control the consumer has over the operating systems, hardware, and software.
  • Whether the enterprise server is used to administer mobile device remote actions.

The service delivery model view

The service delivery model consists of three layers in order of usage frequency:

  • Software as a Service (SaaS)-oriented mobile devices (often used)
  • Platform as a Service (PaaS)-oriented mobile devices (not as often used)
  • Infrastructure as a Service (IaaS)-oriented mobile devices (least used)

Examples of vulnerabilities with the use of the mobile devices for all three model layers include:

  • Wi-Fi access: To steal corporate data from a SaaS-oriented mobile device.
  • Bluetooth access: To steal corporate email on a PaaS-oriented mobile device.
  • Lost mobile device: No protection for the data on the health of the IaaS.

To mitigate the risks of these and other vulnerabilities, you should include the following as countermeasures in the policy.

  • Lock a mobile device after a certain amount of time or upon shutting down your device.
  • Encrypt all contents including authorized company addresses and the microSD media cards .
  • Turn off Bluetooth and Wi-Fi access.
  • Block all incoming messages except from specific addresses.
  • Report a lost or stolen device as quickly as possible to IT help desk so that the device's memory, contents, and applications can be remotely wiped to prevent data loss.

SaaS-oriented mobile device policy

The policy focus is on managing access to specific SaaS applications.

The user license determines the maximum number of authorized users to concurrently access the SaaS application. The license disallows users to install or uninstall mobile applications and access to system and virtual machine applications.

The user is assigned an authorized password to get into a specific SaaS application.

PaaS-oriented mobile device policy

The policy focus is on protecting data and managing access to applications under development.

The user license determines the maximum number of authorized users to concurrently access all applications in a business life cycle and to build small SaaS applications on their PaaS mobile device.

The users require permission to install or uninstall mobile applications on their mobile devices. They are disallowed access to system and virtual machine applications.

They must use an authorized password to get in and cannot share it to access SaaS application on the dual SaaS/PaaS-oriented mobile devices.

IaaS-oriented mobile device policy

The policy focus is on managing, accessing, and protecting data on virtual machines.

The user license determines the maximum number of authorized users to concurrently access the IaaS and the maximum number of PaaS users to use the IaaS-oriented mobile device.

The IaaS users are disallowed access to the infrastructure of traditional computing resources underlying the virtual machines. They require permission to install and uninstall applications on their mobile devices.

They must use an authorized password to get in and cannot share it with other mobile devices in their possession.

Compare and contrast the policy models

Let me sum up the similarities and differences of the policy models.

Device usage ranges from most frequent to infrequent:

  • Mobile devices to access SaaS applications are often used.
  • Mobile devices to build applications on the PaaS are not as often used.
  • Mobile devices to check the health of the IaaS are least used.

Policy focus ranges from simple to complex:

  • SaaS-oriented mobile devices focuses on managing access.
  • PaaS-oriented mobile devices focuses on managing access and protecting data.
  • IaaS-oriented mobile devices focuses on managing access, protecting data and manging virtual machine scaling and deployment.

SaaS-oriented mobile devices should be set to:

  • Allow access to SaaS applications.
  • Disallow mobile applications.
  • Disallow access to system and virtual machine applications.

PaaS-oriented mobile devices should be set to:

  • Allow development of applications on the PaaS.
  • Require permission to install or uninstall mobile applications.
  • Disallow access to system and virtual machine applications.

IaaS-oriented mobile devices should be set to:

  • Allow mobile applications to check the health of virtual machines on the IaaS.
  • Disallow applications to check the health of infrastructure of traditional computing resources underlying virtual machines.

The device view

Here are the major attributes you should consider in a mobile device policy:

  • Do they have firewall rules you could set?
  • When can Bluetooth be turned off?
  • How strong is the encryption? Not all devices have the strongest encryption.
  • What happens when a certain number of password attempts fail? Lock out? Data wipe?

Other attributes to consider are:

  • What application permissions can you enable or disable?
  • What type of user input? Only touchscreen, only QWERTY keyboard or dual interface?
  • What kind of enterprise server is being used to improve security policy for mobile devices?

Mobile policy decisions for Apple devices

With iPhone and IPad, you can show a soft keyboard on the display screen; a physical keyboard is not an option.

In its Airplane Mode, it disables all wireless features to comply with airline regulations. This prevents you from using the external keyboard and from accessing the SaaS, PaaS, or IaaS.

You can disable videos, photos, MMS, application install and uninstall, and in-app purchases. You can enable data wipe locally after a certain number of failed password attempts.

Contact your administrator to enroll your iPad to iO4 Mobile Device Management server. The server administrator can

  • Configure your mobile device settings.
  • Query device information for a list of enforced restrictions and a list of authorized installation of applications on the mobile device.
  • Manage the device through remote wipe, remote lock, and device password removal.

Mobile policy decisions for Android devices

Android devices include Samsung smartphones with soft keyboard, physical keyboard, or dual interface.

On your Samsung Android mobile device, you can:

  • Choose Microsoft Exchange Server as the corporate email service.
  • Configure lock settings to prevent unauthorized use of your phone.
  • Choose mobile messaging option — email, instant messaging, picture messaging, text messaging.

If you so desire, contact your server administrator on Afaria Advanced Enterprise Security for your Samsung Android devices (Android version 2.3 or later). The administrator can:

  • Enforce mobile device encryption, remote device lock, remote wipe of application and data, strong password security, and blacklists of users and applications.
  • Control application install and uninstall, Bluetooth, WiFi, camera, and microphone.
  • Configure a native email client.
  • Track assets such as SSID of wireless network, hidden networks, installed applications by user groups.

Mobile policy decisions for RIM devices

RIM devices (BlackBerry) come in three input modes: soft keyboard, QWERTY keyboard, and dual interface. Security options include password settings, application install and permission, firewall to block incoming messages except those from specific addresses.

You can set automatic or manual memory cleaning. You can choose to encrypt contents in media cards by device only, password only, or device and password.

You can set the device to:

  • Prevent it from sharing contents with Bluetooth-enabled devices.
  • Encrypt data that you send or receive using the Bluetooth technology.
  • Prevent others using GPS technology to track your location.

You can also set your device to connect to a BlackBerry Enterprise Server that can:

  • Impose a device lock-down.
  • Wipe data from a lost or stolen device.
  • Enforce security settings such as Bluetooth lockouts.

Mobile policy decisions for Windows Mobile devices

Windows Mobile devices can have one-tier or two-tier access. A device with two-tier access has better permission options, as offered in Windows Mobile 6 and above. It restricts application start and run-time permissions. Once a signed application is executing, the application permissions, privileged and normal, are determined by the certificate.

If a user allows an unsigned application to execute, it executes only with normal permissions. However, the user may not be allowed to install unsigned applications on a two-tier SaaS-oriented mobile device. He may be required to request authorization to install unsigned applications on a two-tier PaaS-oriented mobile device.

You need Device Configuration Manager on your desktop to change security configurations on your device.

It may be better to enroll your mobile device to an enterprise server. To allow Windows Mobile devices to connect to BlackBerry Enterprise Server, you need BlackBerry Connect technology.

Mobile policy decisions for Symbian devices

Symbian devices (Nokia) come as touchscreen, QWERTY keyboard, or dual interface. Symbian OS v9 Security Architecture is customizable and can be adapted for use by mobile device users, network operators, and software developers.

Underlying the Symbian OS v9 Security Architecture are two drivers:

  • Firewall to protect key system servers.
  • Data caging to restrict the parts of the filing system that are visible to a specific application or process.

Although Symantec Mobile Security 4.3 for Symbian smartphones is available to protect Symbian OS Version 9.x Series 60, it may be better enrolling your mobile device to an enterprise server. To allow Symbian mobile devices to connect to BlackBerry Enterprise Server, you need BlackBerry Connect technology.


Model users

Let's find out who the model users are and what they are doing with mobile devices to get SaaS on demand, build SaaS application with PaaS, and check the health of IaaS.

Get SaaS on demand

The SaaS mobile end user has the least control while the provider has the most control of mobile use.

  • The SaaS mobile end user: The only control end users have is to access the SaaS application from a mobile device whether they are private individuals, businesses (small or medium) or government agencies. Examples of SaaS applications include billing, customer relationship management, human resource, and spreadsheet.
  • The SaaS provider on mobile use: At a minimum, the provider manages access controls by limiting the number of authorized users who can concurrently access the application as set forth in a user threshold policy (see previous articles on threshold policies in Resources). The provider controls what mobile device applications need to be downloaded and installed in addition to operating systems, servers, and network infrastructure needed to run the SaaS application.

Build SaaS application with PaaS

The PaaS user has more control over the applications than the SaaS user has.

  • The PaaS mobile user/application developer: The developer controls and protects all the applications found in a full business life cycle created and hosted by independent software vendors, startups, or units of large businesses. The developer builds, deploys, and runs a custom retail management application for example. As part of the business life cycle, the developer uses spreadsheets, word processors, billing, payroll processing, and invoicing.
  • The PaaS provider on mobile use: At a minimum, the provider controls what mobile device applications need to be downloaded and installed in addition to operating systems, servers, and network infrastructure needed to run the PaaS. The provider sets the user, resource, and data requests threshold levels.

Check the health of IaaS

The IaaS security policy focuses on accessing and protecting data and managing virtual machines.

  • The IaaS mobile user/infrastructure specialist: The specialist controls the operating systems, network equipment, and deployed applications at the virtual machine level. The infrastructure specialist can scale up or down virtual servers or blocks of storage area.
  • The IaaS provider on mobile use: At a minimum, the provider controls the infrastructure of traditional computing resources underlying virtual machines and what mobile applications are needed to access the IaaS. The provider sets the user, resource, and data requests threshold levels.

Service delivery model scenarios: The checklist

As you can see, mobile policy decisions vary from one mobile device to another. For instance, BlackBerry phones have explicit firewall rules while others are not so obvious. What we need is a security policy that can be applied to all mobile devices.

To craft such a policy, try using a checklist. In this simplified scenario, here are some hints for each checklist item.

  • Purpose: What's it about?
  • Scope: Draw a boundary around your policy.
  • Background: Want to know more?
  • Actions: Roll up your sleeves.
  • Constraints: Work with them.

To reach the goal of implementing the security policy, briefly state what the security policy is intended to do. You can use a template like this to give you an idea how to state the purpose:

Purpose: What's it about?

The purpose of the policy is to help cloud service providers implement security policy for:

  • SaaS-oriented mobile devices for use by end users — private individuals, businesses, and government agencies.
  • PaaS-oriented mobile devices for use by application developers.
  • IaaS-oriented mobile devices for use by virtual machine infrastructure and network specialists.

Scope: Draw a boundary around your policy

Define the scope by "drawing" a boundary around the security policy. Within its boundaries, specify which mobile devices are covered in the policy.

The provider needs to find out if the consumer will stay within the fence (comply with the terms of the security policy on access controls, data protection, and virtual machine management). If the consumer strays out of the fence after agreeing to comply, the mobile device user runs the risk of violating the policy. In this case the provider must indicate the consequences of not complying to make sure the consumer stays within the fence.

Here is a template to use when you state the scope:

This policy applies to all SaaS end users, PaaS application developers, and IaaS infrastructure and network architects who use mobile devices. They must consent to all of the provisions of this security policy and agree to comply with all of its terms and conditions on access controls, data protection and virtual machine management. Any end user, developers and network architects whose actions violate this policy, IT policy and regulations shall be subject to limitations or loss of service with the provider.

Background: Look what's behind the policy

The first things a consumer wants to know are whether the provider is internal or external and what the boundaries of controls management between the provider and a mobile device user are (for example, the SaaS end user has the least control), how the provider would manage access controls, provide data protection, and manage virtual machines and respond to cloud security attacks or incidents on mobile devices.

The mobile device user wants to know how the security policy covers the issues of restoring the system (and threshold levels) to mobile devices and how quickly he gets credits, free time, or the right to terminate as set forth in the SLA.

Here is a template you can use to give you an idea of what to include.

The cloud service provider is hosted externally by IBM®, a member of the telecommunication industry.

If a surge in workload demands will cause system performance to slide down from the guaranteed levels of availability for 30 days, the provider must give consumers credits, free time, or the right to terminate the service as set forth in the SLA. The provider must notify the consumer of the exceptions or constraints to the threshold and security policies.

Actions: Roll up your sleeves

Here are five suggestions for actions to take to make consumers happy:

  • Action #1. Send consumers copies of the security policy for review and questions to be resolved before the consumer signs up for a cloud service for access from their mobile devices.
  • Action #2. Set up firewall rules.
  • Action #3. Permit the PaaS application developers and their SaaS users to subscribe to a co-resident SaaS application.
  • Action #4. Get consumers to enroll in an enterprise device management server.
  • Action #5. Specify what applications to install and uninstall on mobile devices registered with the enterprise server.

Here are some templates you can use:

Device enrollment: The provider registers the consumer's mobile devices in an enterprise device management server.

Firewall rules: The provider sets stronger, more explicit firewall rules than those in mobile devices.

Security training: The provider sets minimum requirements for security training for approved cloud users on security awareness and data labeling and handling.

Scheduled maintenance: The provider sets a schedule of maintenance including upgrades to user access management, data protection technologies and virtual machines.

Service availability: The provider sets the availability of cloud access during normal working hours.

Background checks: The provider sets requirements for background checks for intended cloud users.

There will most probably be some constraints in your way. Here are some templates you can use.

Constraints: Work with them

Due to recent organization change, policy governance group moved from Department FGH to Department RST. This requires an update to the security policy, threshold policies, and the SLA.

Service exceptions currently cover:

  • Scheduled proactive SaaS application behavioral changes or upgrades.
  • Botnet attacks against the mobile devices and the provider's host.
  • Provider's scheduled maintenance.
  • Provider's normal service availability from 7AM to 6PM and restricted service availability from 8PM to 11PM.

In conclusion

Crafting a security policy for mobile devices requires plenty of pre-planning to resolve the issues on how purpose, scope, and background of the policy should be stated. Developers must communicate with both the provider and the mobile device user (Apple, Android, RIM, Windows Mobile, and Symbian) on what the service delivery model view is and what the device view entails, who the model users are and what they are doing with mobile devices. Like anything else in life, the most important thing of all that a consumer can do is to get a copy of the policy from the provider for review and send them any questions you may have before negotiating with the provider.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • developerWorks Labs

    Experiment with new directions in software development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing, Security
ArticleID=765929
ArticleTitle=Craft security policy for mobile devices
publish-date=10172011