Windows, iPad and Android - Managing and Using Your Office Assets in a Tablet World (Part 4) – Device-based Access Management

Article
10/19/2011

Welcome to part four in the series about managing your Office assets in a world of tablet computing. In part one I mainly introduced the primary ways to consume Office with rich clients, remote rich clients, Office for Mac, Web Apps and Office on the phone. In part two I talked about consuming email on tablets using Exchange ActiveSync, compared the controls you get with other platforms to Group Policy and described options for configuring Office. In part three I wrote about the Office Web Applications as part of the SharePoint 2010 or Office 365 service. That leads me to the present and maybe one of the thornier topics of the series – how to differentiate resource access based on devices.

Device-based Trust and Differentiated Access Models

When it comes to securing Office data, I think about three primary types of controls:

Securing information found locally on the device’s hard drive
Securing information accessed remotely from the device
Securing the passing of data from remote sources to devices

Local device storage protection tends to revolve around methods of encryption and how to lock someone out of local storage until they can provide as many factors of authentication as required to prove they are who they say they are.

Drive Encryption

Windows uses BitLocker™ Drive Encryption and there are scores of third party solutions available to encrypt entire hard drive volumes. iPads also use hard drive encryption to protect local data and Android Honeycomb and newer tablet operating systems add hard drive encryption also. Bitlocker’s design does not store user data in unencrypted partitions of the hard drive whereas other designs are not as proven and may store critical authentication data in unencrypted and accessible areas of the hard drive. Common Android versions 1.6, 2.1 and 2.2 platforms do not include native hard drive encryption and would be vulnerable if devices are compromised. To be clear, with Windows you do need to make sure that people are using encryption and enforce that as IT policy. If not, there are numerous ways of accessing information on the hard drives (removing them or booting into other operating system environments), changing local account passwords (using ERD Commander password reset), etc. Once you do require and enforce drive encryption, it is extremely difficult to access information on local storage without having computer-specific authentication factors (Trusted Platform Module, PIN, Smartcard, USB dongle, or password) at your disposal.

Network Protection

If you do choose to allow unmanaged devices to connect inside your firewall, then you have a few options aside from the usual certificate and proxy setting requirements. Some organizations for security reasons will erect a parallel network infrastructure specifically for unmanaged device access and limit information access to assets controllable via Exchange ActiveSync and related infrastructure. While that may have been a good enough option for many environments, IT is often under increased pressure to allow these devices to connect within corporate firewalls. If this sounds like you, there are a few things you can do to help to differentiate device access based on the device or browser connecting to your SharePoint data.

There have been common methods around for determining the health of a computer object hitting your network resources. We’ve had things like VPN quarantine and Network Access Protection (NAP) for a number of years now. In the NAP solution a device is basically interrogated when attempting to access a network and if it does not meet standards (patch state, up-to-date AV, etc.) it is given reduced-to-zero network access rights. Descriptions of how NAP works with IPsec, VPN, 802.11x and DHCP can be found on TechNet and this illustration represents the process flow of detecting and remediating and non-compliant device with IPsec.

The thing about NAP is that it requires a NAP capable computer like Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows Vista, and Windows XP with SP3. So if we want to enforce health using NAP, we would need to deploy devices with a Windows operating system on them.

Assuming I don’t have the ability to use NAP because my connecting device is a Mac, iPad or Android device, what can I do then? There are some options using Microsoft Forefront Unified Access Gateway (UAG) to enforce standards on non-Windows devices (Mac and Linux), such as requiring antivirus on these devices. The follow image shows the policy editor in Forefront UAG and the non-Windows platforms it supports.

The text above will be displayed to users when a device does not meet health requirements enforced by UAG. Information about UAG client requirements can be found on TechNet. Important for this blog is that Forefront UAG SP1 Update 1 adds support for browsers in iOS 4 and Android 2.3 and 3.0 platforms.

Another way you can help secure files from being downloaded to devices is to use Internet Information Services (IIS) to interrogate connecting devices with information passed up to an IIS server and based on that information, allow or disallow downloading files. Using IIS, I can define rules which will redirect devices attempting to download files. In that case, I can inspect an IIS log and determine the identifiers for the device.

In the log above I see the device type “iPad” and browser connecting to the document. Then I can go into IIS and configure a rule that redirects calls from devices with these attributes to a page telling them they are doing something unauthorized by the network admin.

As you can see from the IIS Manager above, I have created a rule that applies to all DOCX file extensions. When the device matches the pattern and has iPad in the descriptor, then I will redirect the user to the download%20denied.aspx Intranet site. I don’t need to do this for all files individually, but can define one rule that encompasses all files with the DOCX extension (or other extensions). The nice thing here is that we can allow the device to view the document using Office Web Apps, because it is rendered on the SharePoint server and only sending a PNG file back to the device.

When the user attempts to download a copy to a device we do not manage, the user will see a screen like this:

This basically would help prevent someone from downloading the file to the local hard drive and using another service to upload it or email it to an undesired location. In the case of an unencrypted hard drive or a device with removable storage, this could help prevent the file from being stored to an unprotected file system, SD card or similar. While this isn’t perfect, it can help reduce unintended activities by users while still providing viewing rights using Office Web Apps.

Secure Data Transmission

Data transmission was something else I listed in the very beginning of this blog, but the networking stacks of most current iOS and Android devices support the most common Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA) standards to help keep transmissions safe to and from devices. The key here is to use those methods as opposed to unsecured networks.

Conclusions for Part Four

Mobile devices have come a long way and continue to improve, however they are not as manageable as more mature platforms instrumented for defense in depth – from data on the device or connecting to remote data. IT is understandable though given the current climate that certain concessions are made to grant access to devices which would otherwise not meet security criteria. Hopefully, some of the methods described in this blog will help you determine ways to provide limited, yet enough access to unmanaged devices to give you peace of mind and keep your users happy. Of course there are other mechanisms like Information Rights Management (IRM) to help provide access to unmanaged Windows devices to sensitive files via Exchange ActiveSync support in Windows Phone 7.5 and Windows Mobile and Outlook Web Access, but they don’t really help the iPad or Android conversation or provide a basis of comparison like NAP versus UAG and IIS policies, so I didn’t really go into detail with IRM here.

I wanted to start the conversation of enabling remote access using Citrix XenApp and Remote Desktop Services in Windows Server, how to customize the Office UI and Windows shell for access from an iPad or Android device, but I’ll save that for my next and most likely final blog in the series.

Thanks for reading,

Jeremy Chapman

Senior Product Manager

Office IT Pro Team

UPDATE: Now that all of the blogs are complete in the series, here are links to all six completed blogs:

Share via