Craft a security policy for a cloud-based BYOD environment

Back in the day, you could bring your personal Blackberry to work in order to access a Software as a Service (SaaS) application (if you were in a large building with good cellular reception). Now, you have many device choices for accessing the cloud, from iOs-based phones and tablets, Android handhelds, to Research In Motion's (RIM) PlayBook. All come with opportunities for jailbreaking, or gaining root access, by breaking down security to install banned third-party applications. An infected bring your own device (BYOD) connected to the corporate network is another security concern. A war walker could steal corporate data by uploading from your BYOD to a personal device. Learn to protect corporate assets with a security policy for a cloud-based BYOD environment.


Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, RFID technologies, and project management. She is the author of RFID in the Supply Chain and the editor of Enterprise Systems Integration, Second Edition Handbook.

10 May 2013

Also available in Chinese Portuguese Spanish

To stay safe in a cloud-based BYOD environment, you need a thorough and clear security policy. This article explains potential exposures surrounding jailbreaking, issues for tethered devices, and how to protect corporate assets by crafting a security policy that applies to all devices.


Terms in this article

  • BES: Blackberry Enterprise Server
  • BYOD: Bring your own device
  • IaaS: Infrastructure as a Service
  • Jailbreak: To bypass restrictions on a device to install applications and tweaks not approved by the device maker.
  • MDM: Mobile Device Management
  • PaaS: Platform as a Service
  • RFID: Radio frequency identification
  • RIM: Research in Motion, Inc.
  • SaaS: Software as a Service
  • War driver: Someone in a vehicle using a computer, smartphone, or PDA to find wireless insecure networks.
  • War walker: Similar to a war driver but is on foot; a walk-by hacker who connects their device to a Wi-Fi access point.

You wouldn't jailbreak your BlackBerry in the same sense that iPad (and iPhone) users jailbreak their devices. Unlike Apple, BlackBerry allows the use of many third-party applications on its devices. iPad users jailbreak their phones to access the type of applications that Blackberry users already have access to. If Blackberry users cannot find a third-party application they want, they might try to jailbreak their Blackberry Playbook to install Android and Apple software. Of course, they run the risk of voiding their warranties for jailbroken devices.

There are two methods of jailbreaking to break down security on BYOD devices to install third-party applications. The first method involves user interaction with the device. It does not allow remote attackers to compromise user data or the integrity of the device. The user must possess the device and have valid user credentials for the device. At a minimum, the user can make changes that require:

  • The device be tethered to another device or a computer (via MyFi, an iPad application that enables iPad tethering as the WiFi Hotspot, for example)
  • Access, as a root user, to an authorized user account on the device
  • Making changes, as an authorized developer, to the device's default settings by putting it into developer mode. If the user is not an authorized developer, developer mode could compromise security.

The second jailbreaking method involves less interaction on the user's part. A software bug sent by remote hackers may be exploited from a web page to gain root access to any mobile device. This happens only when the user visits the compromised page.

Nightmare scenario #1: Infected BYOD

Bob's company approves his personal Blackberry as an acceptable BYOD to access a SaaS application. The company does not ask Bob if he has other personal devices. Bob does not voluntarily tell the company he has an iPad2, a MacBook, and a laptop at home.

One day at home

Bob jailbreaks his iPad2 and then installs MyWi as the WiFi Hotspot to let him:

  • Use his company-approved personal Blackberry as a wireless modem (via Bluetooth).
  • Link his Macbook and laptop to his iPad2.
  • Connect all his personal devices to the Internet via WiFi.

Bob uses his laptop to visit a web page that contains a malicious software bug. This bug infects all devices using the iPad's unencrypted wireless connection to the corporate network.

After disconnecting all devices from the WiFi corporate network, Bob re-connects his infected personal Blackberry as a standalone modem to an SaaS application. When the application finishes downloading data to his BlackBerry, Bob disconnects the device from the cloud.

Next day at the office

Bob returns to the office building for a meeting with C-level executives. When he turns on his company-approved Blackberry, Bob discovers— too late— the downloaded data and all company information are now garbage. This includes:

  • Company contacts
  • Company calendar
  • SaaS access information
  • Blackberry login

Nightmare scenario #2: War walking

Brenda, an employee of the Acme company, has approval to connect her personal mobile device to the corporate network. Her device, a Blackberry, is loaded with myriad applications pre-installed by RIM and third party applications she installed for personal use. When Brenda connects her device to the corporate network she gets company-approved applications, including a bar code scanner.

Brenda was given time off to walk to a nearby store with excellent cellular reception. She uses her Blackberry to scan bar-coded price tags on office products. If she finds the price is right, she puts the item in the shopping cart. She continues to shop until she gets all the items she needs.

While shopping, Brenda is unaware that she is a victim of a war walker (hint: business competitor in the same store). The war walker uses his device to steal sensitive company data from Brenda's device while she scans the price tags. Brenda's device does not give an alert that a war walker is uploading corporate data. Brenda notices that her device is a little bit warmer than usual.

The next day, the war walker illegally gains access to the SaaS application. He then sends a malicious barrage of data to the application.

Security of tethered devices

When devising a security policy for tethered devices, major attributes to consider are:

  • Can Bluetooth be turned off?
  • How strong is the encryption of wireless connections?
  • What happens when a certain number of password attempts fail? Lock out? Data wipe?

Other issues to address include:

  • What applications can you (and the company) enable or disable?
  • What kind of enterprise server does the company use to improve security policy for mobile devices? Mobile Device Management (MDM)?
  • Can the device be jailbroken, rooted, or hacked?

Tethering policy decisions

When making tethering policy decisions, you need to understand the varied, specific concerns for each device.

RIM devices
RIM has developed an advanced tethering system for the PlayBook and BlackBerry smartphones that can be controlled using policies set by enterprise IT departments. The PlayBook is available in two models: Cellular and WiFi, or just WiFi.

You should enroll your Blackberry devices to Blackberry Enterprise Server (BES) so the IT department can set a policy on the maximum distance between the Bluetooth-enabled phones and the Playbook. If the Playbook is moved beyond the set distance, tethering can be automatically terminated and no data from the phone will remain on the tablet.

You can allow multiple employees in a company to share a PlayBook, with each employee tethering their own BlackBerry to the tablet at different times.

When you tether the Blackberry smartphone to the PlayBook, 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 war drivers who use GPS technology from tracking your location.
Android devices
Consider Afaria Advanced Enterprise Security for your Samsung Android devices and tablets. 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.
  • Enforce tethering polices regarding which devices can be tethered to the Android tablets.
  • Allow the use of radio frequency identification (RFID) reader to read UHF Gen2 RFID directly to a spreadsheet on the Samsung Galaxy Tablet.
Apple devices
In Airplane Mode, Apple devices disable 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 cannot tether your phone to the tablet.

Contact your administrator to enroll your iPad to an iO4 Mobile Device Management (MDM) server (see Mobile Device Management for more details).

Windows® Mobile devices
Windows Mobile devices can have one-tier or two-tier access. A device with two-tier access has better permission options. 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 device. On a two-tier PaaS-oriented device, the user may be required to request authorization to install unsigned applications.

To allow Windows Mobile devices to connect to BES you need BlackBerry Connect technology. Windows RT and Windows 8 tablets became available shortly after the release of iPad3.

Mobile Device Management

With MDM, companies can accommodate employee requests for a large choice of devices and still provide security comparable to a BES. The range of supported platforms has increased to include Apple's iOS and Google's Android. The BES provides the most secure environment for MDM, though Apple's iOS has improved.

IBM Endpoint Manager for Mobile Devices

IBM Endpoint Manager for Mobile Devices offers an integrated approach for managing, securing, and reporting on laptops, desktops, servers, smartphones, tablets, and even specialty devices such as point-of-sale terminals. It can help you address the issues of security, complexity and bring your own device (BYOD) policies that challenge support for an increasingly mobile workforce.

For the Blackberry, MDM comes in two forms: Server and cloud. The cloud version offers Blackberry Business Cloud services.

The MDM 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.

MDM software ensures all users have been registered. It sends an alert to the system administrator (and IT department) about:

  • Which users are and are not registered
  • Which devices have been jailbroken
  • Which devices are running allowed, banned, and mandatory applications
  • What the penalties are for role noncompliance

To communicate with the MDM server, a small client must be installed on the device. The server typically interfaces with the LDAP directory to find out, at a minimum, the employee's location, department, job title, and supervisor.

The client can be used to communicate with BES for Microsoft® Exchange Server, IBM® Lotus® Domino, and Novell GroupWise. As part of the configuration, MDM servers can provision WiFi (and VPN) settings to secure the connection.

If you have multiple MDM domains to administer in your organization, consider Blackberry Mobile Fusion Studio. You can open BlackBerry Mobile Fusion Studio in a browser on any computer. You can share administrative duties with other administrators who can access BlackBerry Mobile Fusion Studio at the same time.

Model users

This section explores who the model users are and what they're doing about tethering mobile devices to get SaaS on demand, build SaaS applications on PaaS, and check the health of the IaaS.

Get SaaS on demand

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

The only control the SaaS mobile 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. End users can tether their smartphone to the tablet to take advantage of the tablet's larger screen.

At a minimum, the SaaS provider manages access controls by limiting the number of authorized users. The provider sets the user threshold levels on who can concurrently access the application.

Build SaaS application with PaaS

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

The PaaS mobile user or application developer controls and protects all the applications on a platform hosted by independent software vendors, startups, or units of large businesses. For example, developers can tether their smartphone to a tablet to build, deploy, and run a custom retail management application on the tablet.

At a minimum, the PaaS provider controls operating systems, servers, and the 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 or infrastructure specialist controls the operating systems, network equipment, and deployed applications at the virtual machine level.

At a minimum, the IaaS provider controls the infrastructure of traditional computing resources underlying virtual machines and which mobile applications are needed to access the IaaS. The provider sets the user, resource, and data requests threshold levels.

Checklist for service delivery models

Tethering policy decisions vary from one device to another. You should be able to apply a security policy to all devices. To craft such a policy, try using a checklist. In this simplified scenario, use the following questions for each checklist item.

  • Purpose: What's the policy's intention?
  • Scope: Put a fence around your policy.
  • Background: Look what's behind the policy.
  • Actions: Protect corporate assets.
  • Constraints: Work with them.

Purpose: What's the policy's intention?

Before implementing a security policy, think through and briefly state what the security policy is intended to do. You can use a template like the one below as one way to state the purpose.

Template for stating purpose
The purpose of the policy is to help implement security policy for cloud-based 
BYOD environment for:     
* End users of SaaS applications.
* Developers of applications on the PaaS.
* Infrastructure and network specialists on the IaaS virtual machines.

Scope: Put a fence around your policy

Define the scope by putting a "fence" around the security policy. Within the boundaries, specify which BYOD devices are covered and how they are administered via MDM servers in the policy.

The provider needs to find out if the consumer will stay within the fence and 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 BYOD user runs the risk of violating the policy. In such a case, the provider and the MDM administrator must indicate the penalties for noncompliance.

The following is a template to use when stating the scope of your policy.

Template for stating scope
This policy applies to all SaaS end users, PaaS application developers, 
and IaaS infrastructure and network architects who use “company-approved” 
BYOD 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 and site administrator.

Background: Look at what's behind the policy

Typically, some of the first things users want to know are whether the provider is private or external, what are the boundaries of controls management between the provider and a mobile device user, and what will the response be to cloud security attacks or incidents on mobile devices.

The BYOD user wants to know how the security policy covers the issues of restoring the system to cloud-based BYOD devices. Other high priority questions involve how quickly the company can give credits or free time, and the right to terminate as set forth in the Service Level Agreement (SLA).

Actions: Protect corporate assets

Here are three suggested actions to take to make BYOD users happy.

  • Send copies of the security policy to the BYOD users for review and to solicit questions to be resolved before they sign up for cloud service access from their devices.
  • Get BYOD users to enroll in an enterprise server (MDM server, for example).
  • Specify what applications are permitted, banned, or mandatory on BYOD devices.

Below are example templates for protecting corporate assets.

Templates for protecting corporate assets
Device enrollment: The provider registers BYOD devices in an enterprise device 
management server.

Security training: The provider sets minimum requirements for security training 
for approved cloud users on security awareness on consequences of jailbreaking, 
downloading banned applications, and theft of data via uploading to personal devices.

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

Background checks: The provider sets requirements for background checks for intended 
cloud-based BYOD users.
  • Device enrollment: The provider registers BYOD devices in an enterprise device management server.
  • Security training: The provider sets minimum requirements for security training for approved cloud users on security awareness on consequences of jailbreaking, downloading banned applications, and theft of data via uploading to personal devices.
  • Scheduled maintenance: The provider sets a schedule of maintenance including upgrades to user access management, data protection technologies, and virtual machines.
  • Background checks: The provider sets requirements for background checks for intended cloud-based BYOD users.

Constraints: Work with them

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

Templates for constraints
Due to recent organization change, the 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.
* Provider's scheduled maintenance.
* Provider's normal service availability from 7AM to 6PM and restricted service 
  availability from 8PM to 11PM.


Crafting a security policy for a cloud-based BYOD environment requires a lot of planning to resolve issues of how to state the purpose, scope, background, actions, and constraints of the policy. BYOD users must communicate with the company on what their tethered device view is, what the MDM view entails, and who the model users are.

The most important thing the BYOD user can do is to get a copy of the policy from the provider for review and ask questions before negotiating with the provider or the MDM administrator.



Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.


  • Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.


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

  • developerWorks Premium

    Exclusive tools to build your next great app. Learn more.

  • Cloud newsletter

    Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.

  • Try SoftLayer Cloud

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

Zone=Cloud computing, Mobile development
ArticleTitle=Craft a security policy for a cloud-based BYOD environment