Policy-Based Application Management

Abstract

Improved techniques for managing enterprise applications on mobile devices are described herein. Each enterprise mobile application running on the mobile device has an associated policy through which it interacts with its environment. The policy selectively blocks or allows activities involving the enterprise application in accordance with rules established by the enterprise. Together, the enterprise applications running on the mobile device form a set of managed applications. Managed applications are typically allowed to exchange data with other managed applications, but are blocked from exchanging data with other applications, such as the user's own personal applications. Policies may be defined to manage data sharing, mobile resource management, application specific information, networking and data access solutions, device cloud and transfer, dual mode application software, enterprise app store access, and virtualized application and resources, among other things.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS[0001]This application claims priority to: provisional application 61 / 861,736, filed Aug. 2, 2013, entitled “Policy-Based Application Management”; provisional application 61 / 806,577, filed Mar. 29, 2013, and entitled “Systems and Methods for Enterprise Mobility Management”; provisional application 61 / 714,469, filed Oct. 16, 2012, entitled “Policy-Based Control of a Managed Application Derived from an Unmanaged Application”; provisional application 61 / 713,762, filed Oct. 15, 2012, entitled “Conveying Data Between Secure Applications Running on an Electronic Mobile Device”; provisional application 61 / 713,718, filed Oct. 15, 2012, entitled “Secure Data Sharing Among Managed Applications”; non-provisional application Ser. No. 13 / 649,076, filed Oct. 10, 2012, entitled “Gateway for Controlling Mobile Device Access to Enterprise Resources” (which in turn claims priority to provisional application 61 / 546,021, filed Oct. 11, 2011, entitled “Systems and ...

AI Technical Summary

Benefits of technology

The present invention is about mobile applications that can be controlled by independent policy files that define security, feature and resource limitations. These applications can be restricted from communicating with other applications and resources based on user attributes and network location. The technical effect of this invention is to improve security and management of mobile apps on devices, preventing unauthorized access and ensuring compliance with enterprise policies.

Problems solved by technology

Stated differently, by enforcing policies on managed apps, those apps may be restricted to only be able to communicate with other managed apps and trusted enterprise resources, thereby creating a virtual partition that is impenetrable by unmanaged apps and devices.

For example, while some applications may be secured for use on the mobile device, others may not be prepared or appropriate for deployment on the mobile device so the enterprise may elect to provide the mobile user access to the unprepared applications through virtualization techniques.

As another example, the enterprise may have large complex applications with large and complex data sets (e.g. material resource planning applications) where it would be very difficult, or otherwise undesirable, to customize the application for the mobile device so the enterprise may elect to provide access to the application through virtualization techniques.

Unauthorized access attempt detection services may include unauthorized attempts to access devices, applications, data, and the like.

This may cause whatever content is currently displayed on the screen to be hidden, resulting in a blank screenshot where any content would normally reside.

The latter makes a key susceptible to brute force or dictionary attacks.

For example, loss of entitlement to the application, or changes to the allowed uses of the application, may not be maintained or enforced.

Once the application is installed on a device, the enterprise or corporation that distributed it may lose the ability to control access to the application.

One problem is that the data put into the clipboard is not secured in any way, and sometimes there is a need to secure it such that only a defined set of managed applications can share this data, hiding it from other non-managed applications.

Unfortunately, the user of a conventional smart phone is able to simply copy secure data from one app to the general clipboard and then paste that secure data from the general clipboard to another app and thus allowing the secure data to escape.

Even further, two different managed apps whose policy files defined different secure clipboards also would not be able to share data.

Thus, based on policy settings, movement of data can be restricted such that data within the set of managed applications is not comingled with data outside the managed set.

According to another aspect, data sharing may be limited by the fact that a set of applications are included within a same management policy.

Managed applications are typically allowed to exchange data with other managed applications, but may be blocked from exporting data to unmanaged applications.

In an example, applications within the set 820 of managed applications support the use of Open In, but the list of applications displayed for opening a selected data object is limited based on the policies of the respective applications.

In another example, a policy may cause a device to perform dictation blocking.

However, voice features often perform voice transcription in the cloud, because the mobile device might not have enough processing power to efficiently transcribe voice to text on the device.

By using above interception and filtering techniques, data flow in and out of the device as well as on the device is limited to the managed secure space.

Thus, it may be an impossibility for the user to even request certain types of data export operations after application of a policy file.

Because this information can be very sensitive, an enterprise may wish to safeguard such information.

When users in the field experience problems with their mobile devices or could benefit from information, data, software, or coaching on how to perform certain operations using the devices, it can be difficult for the enterprise's IT support to provide highly effective assistance.

These policies may further restrict access to the managed application only during certain times, from certain networks, form certain geo-locations, and only from devices that are in compliance with all organizations security policies.

Further, in some circumstances, such a web browser can make it unnecessary for application developers to develop different versions of a mobile device application for different mobile device platforms.

Further, in some circumstances, such a PIM app can make it unnecessary for application developers to develop different versions of a mobile device application for different mobile device platforms.

Further, in some circumstances, such a client agent can make it unnecessary for application developers to develop different versions of a mobile device application for different mobile device platforms.

The use of obfuscation impairs the ability of others to reverse engineer the security functions added to the application.

Examples of suspicious activity include reading the personal contacts stored on the device, sending an email to a cloud storage service, and sending location information without first requesting user permission.

In addition, a user may be able to attach, open, view, access, use, and / or export an attachment only to, from or within other managed apps, and not be allowed to perform similar activities on or with an attachment using an unmanaged app.

Such tickets may be one-time use and / or time-based, and impose constraints to certain applications, resources and / or privileges (e.g., short-lived vs. longer-lived access).

However, traditional VPNs have the downside that all applications running on the mobile device are granted uniform access to the corporate intranet.

Increasingly, mobile devices used to access enterprise resources are employee owned and not enrolled with an EMM server, and therefore not tightly controlled or managed by a corporate IT department.

As such, there is a real risk of malware and other unauthorized software running on an employee's own mobile device to gain access to the corporate intranet when using traditional VPN software.

But when the employee's device is connected to a foreign network such as 3G / 4G network, home-based WiFi, or other public access point, transparent network access to corporate intranet is problematic without a VPN.

These policies may further restrict access to the managed application only during certain times, from certain networks, form certain geo-locations, and only from devices that are in compliance with all organizations security policies.

However unlike other system level VPN solutions, this VPN tunnel is only available for this specific application to use.

If network access policy dictates no network access, then specialized network software may cause the network APIs to fail to connect.

One of the biggest challenges in managing enterprise applications on an otherwise unmanaged mobile devices is ensuring that information used by the managed application cannot escape from the set of trusted enterprise applications that IT administrators make available to their enterprise users.

However, even with a robust set of information containment policies, there are other threats to the security of the information managed by applications on mobile devices.

One such threat is that applications may store some information persistently on the mobile device by writing files or other data into the flash memory or other persistent storage on the device.

However this sandboxing is trivially defeated with common tools capable of rooting or jail-breaking the device.

The fact that the keys are held on the device and protected by weak cryptographic factors means that the data is not particularly well protected from hacking, particularly if a device is stolen and hacker has ample time to try to unlock the keys.

Also, since the keys are in possession of the device holder, an enterprise is powerless to remove them or revoke access for a terminated employee unless they can recover the device.

Another issue with app sandboxing that occurs on mobile platforms is that it is problematic to have a single repository of documents that are available to all managed applications on the mobile device and potentially synced offline to cloud based storage.

The drawback here is that one ends up with multiple copies of a particular file in each app's sandbox.

If one or more apps wish to edit the file content, keeping track of which app has latest versions is problematic for users.

The drawback here is that these extra steps are easy to forget.

These two facts can lead to data file consistency issues and poor user experience if users are not properly trained.

This has the downside that shared storage is world readable and therefore shared with all applications.

Once information is placed into shared storage, containment of the information is lost since any application on mobile device can read it.

Also the data can trivially be accessed by anyone who gains physical access to the device using standard file viewers and development tools.

However applications will not always be written with such awareness.

Without such a broker, one would not be able to share files transparently.

The use of passcodes (or other types of authentication information) for enterprise applications reduces the likelihood that enterprise resources will be improperly accessed when, for example, the mobile device is lost or stolen, or when the mobile device is used by an employee's children to play games.

Similarly, the enterprise resource may implement SSL with client certificate authentication, but the client device 2505 might not implement SSL with client certificate authentication.

However, the proxy device 2510 might not have control of the client certificate private key.

However, the KDCs themselves may comprise sensitive enterprise resources that should not be directly accessible to some client devices.

In many cases, this will result in the user being challenged to authenticate him or herself (i.e., no SSO).

Still further, complex combinations of requirements may be defined in the policy files.

However, each platform does essentially the same thing and the devices do not work in harmony when used by the same user.

One problem today is that while many devices can interact with each other, the way they interact with each other is hard wired, and not configurable by the users of the system.

The range of behaviors is limited, and often limited to devices from similar vendors, who have already established how devices will interact with each other, based on specific, closed use cases.

Other features of the software described herein, such as triggers that invoke when a user is not physically present, cannot be achieved at the moment, and the user lives without such features.

Limited known previous attempts at this problem involve solutions such as web mashups, including technologies like OnX and IFTTT.

For other situations, such as launching an application from one device onto another, there are no existing solutions in place.

Thus, existing solutions, to the extent they exist, are laborious, manually driven and error prone.

Without the MD software, multiple devices are not able to work together in harmony, in a complementary fashion.

Each device can display applications and content, but there is no coherence or ability to orchestrate across multiple devices.

Collaboration systems such as CITRIX GOTOMEETING do not currently have any particular association for a user's devices, and consequently cannot take advantage of pre-assigned roles for different devices.

Collaboration systems also do not currently have any particular association for a user's devices, and consequently cannot take advantage of pre-assigned roles for different devices.

The software and systems described herein overcome the difficulties that arise when users have several devices that can work together to automate tasks, yet are not configured out of the box to allow such orchestration, or do not allow flexibility of orchestration.

In this example, the television display device may not have an audio input device, and the cellular telephone may not have an adequate video output device.

In particular, the multi-device client may present an unobtrusive notification at the mobile device when another user shares a file.

As set forth above, a device may not have the capability to open a file shared with that device.

A mobile phone may not be equipped with the necessary software to open the 3D file.

In an example, applications within the set 3520 of managed applications support the use of Open In, but the list of applications displayed for opening a selected data object is limited based on the policies of the respective applications.

For example, the less secure managed mode may encrypt communication to and from the selected application, but might not allow access to enterprise resources, such as resources 304.

Accordingly, a jailbroken / rooted mobile device will have a selected application run in unmanaged mode even when the mobile device is connected to a WLAN internal to a company or if the selected application is attempting to access an enterprise account.

The less secure managed mode may encrypt communication to and from the selected application, but might not allow access to enterprise resources, such as resources 304.

The policy may be defined in this way because the encrypted communication with the enterprise email account may be a low risk communication, and allowing access to enterprise resources may be a high risk communication.

Images