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.
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:
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.
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.
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.
- The author discusses threshold policy in the articles "Balance workload in a cloud environment: Use threshold policies to dynamically balance workload demands," "Cloud computing versus grid computing: Service types, similarities and differences, and things to consider," and Build proactive threshold policies on the cloud."
- The author discusses proactive vs. reactive ways of making application changes when you migrate them to the cloud in the article "Change app behavior: From in house to the cloud."
- The author discusses cloud service security and how to mitigate risks to cloud services to ensure high uptime availability in the article "Cloud services: Mitigate risks, maintain availability."
- The author discusses three proactive steps to ensure cloud performance — monitoring, testing, and policy-building — in the article "Craft a cloud performance metrics policy."
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- More developerWorks resources that match this article can be found at SOA and web services at developerWorks and industries at developerWorks.
- Find out how to access IBM SmartCloud Enterprise.
Get products and technologies
- See the product images available for IBM SmartCloud Enterprise.
- Join a cloud computing group on developerWorks.
- Read all the great cloud blogs on developerWorks.
- Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
Dig deeper into Cloud computing on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Complete cloud software, infrastructure, and platform knowledge.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.