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.
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
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.
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.
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.
The author discusses threshold policy in the following articles:
- "Balance workload in a cloud environment: Use threshold policies to dynamically balance workload demands" (developerWorks, January 2011)
- "Cloud computing versus grid computing: Service types, similarities and differences, and things to consider" (developerWorks, March 2009)
- "Build proactive threshold policies on the cloud" (developerWorks, May 2011)
- "Change app behavior: From in house to the cloud" (developerWorks, March 2011): The author discusses proactive vs. reactive ways of making application changes when you migrate them to the cloud.
- "Cloud services: Mitigate risks, maintain availability" (developerWorks, March 2011): The author explores cloud service security and how to mitigate risks to cloud services to ensure high uptime availability.
- "Craft a cloud performance metrics policy" (developerWorks, September 2011): The author covers three proactive steps to ensure cloud performance: monitoring, testing, and policy-building.
- "Craft security policy for mobile devices" (developerWorks, October 2011): The author discusses the four variables that shape a cloud mobile security policy.
- Read the datasheet for IBM Endpoint Manager for Mobile Devices
- View the webcast, Help! The Mobile Device Invasion Is Here!
- Find out how to access IBM SmartCloud Enterprise.
- Find out more about IBM mobile software for BlackBerry devices.
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- Follow developerWorks on Twitter.
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.