Digital Walkabout

Use BYOD policies to integrate personal devices securely

Perhaps no trend is more disturbing to IT managers and network administrators than bring your own device. The concept of end users bringing personal devices into the office and using them to connect to various network resources would have been unthinkable just a few short years ago. Today, however, BYOD policies have become the norm, and users routinely access corporate data from personal devices inside and outside the office.

 

Healthcare organizations have had an especially difficult time coping with the bring your own device (BYOD) trend. Because of mandates under the Health Insurance Portability and Accountability Act (HIPAA), the industry is heavily regulated with regard to the ways information systems must be secured and maintained. The concept of allowing end-user-owned devices to connect to network resources containing sensitive data at first seems to be a direct contradiction to numerous HIPAA requirements. Even so, some healthcare organizations are actively embracing BYOD policies.

 

Things to consider before BYOD policies are established

When it comes to allowing the use of end-user devices in a healthcare organization, there are a number of considerations that must be taken into account and some questions that must be asked. Among them are these:

• Which users will be allowed to use their personal devices?
• Which resources will be accessible from those devices?
• How can the organization ensure that data and network resources remain secure?
• How will BYOD impact HIPAA compliance?
• What special policies need to be put in place before employee-owned devices can be used?
• How will end-user devices be supported?
• Will allowing employees to use their own devices do anything to increase operating costs?

The answers to these and other questions will vary from one healthcare organization to another. In addition, those answers will largely depend on the nature of your organization, and what your plans are for BYOD. Even so, there are a few things that you should be thinking about.

 

The first thing you should consider is that although HIPAA places numerous requirements on the way data must be handled, those requirements apply only to systems that contain or are used to access electronic protected health data. That being the case, you probably won't have to worry about HIPAA compliance if you have users who want to use their personal devices only to access email or other resources that are not specifically related to patient healthcare data. Depending on the nature of your organization, however, there probably will be some employees who want to use personal devices to access protected electronic health data. For example, doctors might like the convenience of being able to access patient records from a tablet. Needless to say, this type of access does pose a challenge with regard to maintaining HIPAA compliance. However, there are a few different things you could do that will keep both end users and the government happy.

 

One option is to provide specific users with company-owned devices. For example, if you have certain doctors who want to be able to access patient health data from a tablet, you might be able to provide those doctors with an organization-issued tablet that has been preconfigured with all the necessary security settings. Of course, this isn't exactly BYOD. Another option is to allow access to electronic protected health data only from the organization's wireless network. That way, doctors can use tablets on-premises to access patient health data, but you won't have to deal with the legal complexity of remote access.

 

Data security begins with server configurations

Regardless of who is allowed to access electronic protected health data, and from where, it's a good idea to configure such devices to run healthcare-related applications but not to store data. Data should always be centrally stored, either in the cloud or on the organization's servers. That way, if someone loses a mobile device, data isn't compromised.

 

Just because a mobile device doesn't contain any actual data doesn't mean you can get away with skimping on security, however. HIPAA very clearly states that most of its security requirements apply both to devices that contain electronic protected health data and to the devices that are used to access that data. That being the case, any user who wants to access sensitive data from a personal device will have to consent to various security policies being imposed on it. An example of such a policy is to protect a device with a strong password that will prevent someone from stealing it, turning it on and using an installed application to access patient health data that is stored elsewhere. Likewise, the device's storage should be encrypted to prevent the risk of cached data being exposed.

 

Allowing end users to connect to network resources using their own personal devices is a concept that should never be taken lightly. In a healthcare environment, however, administrators must be exceptionally diligent to ensure that HIPAA mandates are not violated when employees use their own devices.

 

 

Modern mobile development techniques: The Y-shaped methodology

When the end goal is creating the highest quality of user experience possible on a mobile device, there's no debating the fact that native application development is the only way to go. But with at least four major platforms to target in a Bring-your-own-device world, each with its own platform-specific development kits and APIs, how can an organization effectively deliver mobile applications that are specifically targeted to each of the mobile platforms without completely blowing the entire IT budget?

The wrong approach to mobile development
The wrong thing to do is to go all in and dedicate a team for each platform, but sadly, that's exactly what many organizations are doing. The end result is an inevitable duplication of efforts as separate teams independently develop essentially the same services and features as everything gets developed in parallel.

"Many organizations approach mobile by setting up independent teams," said Giles Alexander, lead developer and consultant who specializes in mobile application architecture and strategy at ThoughtWorks. "You'll have an Android team outsourced, your iOS team in-house, and then you'll contract to an entirely external team for BlackBerry or Windows Phone development. These teams are basically delivering the same features, but they're doing it entirely in parallel."

Anyone who has worked in the IT field knows that there's always a strong probability that any one application development project will fail. With four projects going on at the same time, your chances of any one project failing quadruples. Furthermore, with four different projects supporting four different platforms, fixing bugs and enhancing features become increasingly untenable as time goes on. Fortunately, though, there is a better approach, and more organizations are adopting it.

A new trend in mobile development
In what is becoming a successful trend, forward-thinking organizations are moving away from a fragmented-by-platform mobile development process and are instead adopting a feature-based approach that stresses commonality. Divergences and differences between platforms only end up coming into play as UI development issues come into focus.

This evolving approach is known as the Y-shaped development method because the development stream looks more like the letter Y than it does a bunch of independent columns or silos that stand alone independently. "The Y-shaped delivery method aligns your teams along features rather than along platforms," said ThoughtWorks' Giles Alexander. "You don't restrict your teams to just working on the mobile front end, but you also allow the team to be aligned across a feature throughout the organization."

The end result is that one team efficiently develops a feature from end to end rather than four teams duplicating efforts. It certainly sounds more like common sense than it does a revolutionary idea, but sometimes common sense gets pushed aside in the frenzy of rushing mobile products to market.

Getting started with the Y methodology
Given the sensibility of this methodology, how does an organization that's interested in getting its feet wet in the mobile development space adopt this particular approach? "You're probably going to have to pick some boundary at the back end to start," said Giles. "Say you have a set of services that expose the data that is critical to your product, and you want to deliver a new mobile feature around this. You should be able to put together a team that can work on those services and work on exposing those services in a way that is suitable for mobile. You then have that same team work on the UI and the actual delivery of those features into your Android, iOS, Blackberry or mobile web -- whichever you feel is most suitable to support." 

Of course, you can't completely ignore the reality that there are unique differences between the three or four most popular mobile platforms on the market. Furthermore, it's inevitable that certain members of a given team will have skills that align more strongly with either Android, iOS or Windows Phone. Any good development strategy needs to embrace this reality. This is where the linear-based, feature-driven development approach branches out a bit, giving us the idea of a Y-based development methodology. "There may be some division at the front end of the team. Some people may  prefer to be Android developers as opposed to iOS developers, so you may  end up with some slight division at the top -- hence the Y," explains Giles.

In the end, taking this slightly newer approach to mobile application development is going to save time and money and make feature enhancements and long-term maintenance of the applications more manageable. Organizations should start thinking about breaking down the silos and taking a more streamlined, feature-based approach to lean mobile development. "It's about focusing on features, delivering features and learning from that feature delivery.

How to remotely wipe iPhone and Android devices

BYOD security best practices for enterprises should include setting a PIN and/or password and remote data wiping. That's a given. However, the efficacy and reliability of remote-wipe capabilities varies from one mobile device to another. In this tip, let's look at what invoking a remote wipe really does on today's smartphones and tablets, and steps that IT organizations can take to increase their confidence in what is often a critical stop-loss measure.

Why wipe a locked, encrypted mobile device?

A lost mobile device exposes both employee and employer to the risks of identity theft and breach of data. Locking a mobile device with a PIN or password can deter casual data loss, but it's not enough to prevent criminals or law enforcement from using forensic tools to dump any data stored in flash memory. For example, someone in physical possession of a lost iPhone can run F/OSS Lantern Lite (a common open source UI tool for iOS device imaging), connect to the iPhone, enter DFU mode and dump the phone's file system. From there, tools can be used to recover deleted files and crack short passcodes. Similar forensic tools exist for Android and even BlackBerry.

 

Remote data wipe helps manage the risk of data loss. You might think remote wipe is an easy way to remove all user files from flash memory. However, many devices support more than one kind of wipe. "Enterprise wipe" removes business applications and files installed by a mobile device manager (MDM) product, while "device wipe" removes all files without differentiating between business and personal. However, even "device wipe" may not really obliterate all files.

 

From factory reset to forensic destruction

To wipe iOS devices, including the iPhone, a command can be invoked locally or remotely to erase all content and settings. This actually overwrites the block storage encryption key saved in the device's effaceable storage, rendering all data stored in the encrypted file system user partition cryptographically unreadable. However, an iOS device must be reachable for mobile device management software or iCloud to invoke this action remotely. Wipe can also be auto-invoked after N passcode failures, but someone in physical possession of an iOS device that's been disconnected from the Internet can easily avoid remote wipe until flash memory has been dumped.

 

On Android devices, a factory data reset command can be invoked to reset all settings back to factory default, and remove all apps and associated data, along with any email and text messages and contacts stored in flash. However, flash storage is not overwritten: Any data that was not encrypted can still be forensically recovered. Furthermore, data stored on an SD card may not be removed, depending on the device make and model. If flash storage was encrypted, wipe efficacy also depends on the manufacturer's key management. Like iOS, Android also supports a "maximum failed password attempts" setting after which factory reset is invoked, but disconnected Android devices can be dumped before wipe.

 

On BlackBerry smartphones, users can invoke its Security Wipe function to selectively delete application data (e.g., email, contacts), user-installed applications and/or SD card contents. Administrators can remotely invoke an "erase data and disable handheld" command that removes all user data, references to encryption keys and device transport keys, and authentication information from its non-volatile or NV store protected memory, flash memory and on-device memory. When a BlackBerry is reset to factory default, references to device password hashes are also removed, along with third-party applications and associated data. On devices configured to protect (encrypt) content, a NIST-compliant memory scrub can be performed to resist forensic analysis. BlackBerry supports not only a maximum password attempts policy, but also "secure wipe delay after IT policy received," "secure wipe delay after lock" and "secure wipe if low battery." The latter help a long-lost and disconnected BlackBerry auto-wipe itself.

 

Going beyond remote wipe

Given this understanding of how remote data wipe works, it's easy to see that it should never be an organization's only defense against a potential data breach. Remote wipe is designed to complement other security measures, the strength of which significantly affects overall effectiveness. Supplement a well-tested, validated and documented remote wipe capability with the following tactics:

• Start with a strong password. Not locking devices leaves data vulnerable to immediate access by strangers, but short PINs are not much better because PIN or password cracking can facilitate forensic analysis of encrypted data dumps taken from lost devices.
• Combine passwords with full-device encryption. While device encryption may not be entirely infallible, skipping encryption leaves a lost device wide open to file system dumping by anyone in possession of the phone.
• Beware of data left behind after device wipe. If a worker's Android offers SD card encryption or wipe options, administratively enable them. Similarly, if workers back up their own iPhones onto laptops, configure device settings to encrypt those backup files. If workers back up data onto a consumer cloud server (iCloud, Google, etc.), realize that data won't be touched by remote wipe and will remain accessible indefinitely to anyone with the user’s cloud account.
• Add secondary encryption. When remote wipe isn't successful and forensic analysis is attempted, the best defense against beach can be another layer of protection: specifically, applying software encryption to safeguard business data or other sensitive application or user data. When employers deploy business files onto mobile devices, they should store those files in a secure container. When employers deploy business files onto mobile devices, they should store those files in a secure container. When employers develop enterprise apps for mobile devices, they should encrypt associated data and pay attention to key management. And so on.
• Enable remote wipe and find. An organization's administrators may use corporateMDM software to issue confirmed "enterprise wipe" commands, but employees may still be concerned about personal location privacy and loss of personal data. In such cases, suggest that workers register their devices with a consumer cloud service such as iCloud Find My iPhone or Samsung Dive. Doing so may allow them a chance to quickly locate a lost smartphone or tablet, and perhaps invoke their own device wipe when warranted. Users must enroll their devices and enable remote wipe beforehand, otherwise this last resort will not be an option.

What to ask when comparing Cloud Storage services

So you've decided to pursue public cloud storage for a particular data set and use case. If you're a developer building a Web-enabled application, then you'll likely be interested in a cloud object store such as Amazon S3 or OpenStack Object Storage. If, on the other hand, you're an enterprise data storage professional looking to take advantage of the cost-effective scalability of the cloud to protect traditional block or file data for backup or disaster recovery (DR) purposes, then chances are you'll want to deploy an on-premises appliance as a gateway to back-end cloud storage. One of the key decision points for each of these use cases -- and a large range of others -- is the choice of a public cloud storage service provider.

While each usage scenario is a bit different, there is a core set of evaluation criteria common to all use cases that you should consider when choosing a cloud storage provider. Here are 10 questions that will help you compare cloud storage services:

1. Does the provider accommodate and support my primary use case(s)? In our example above, companies looking for an object store may find Amazon S3 attractive, but to support the storage of traditional block or file data, an AWS Storage Gateway will also be required. Not all cloud storage providers offer capabilities tailored to use cases such as backup, DR, or archiving, so you'll need to carefully compare the details of each provider's offering.

2. Where will my data be stored? The answer to this question is important for several reasons. First, you'll want to be sure that the provider's datacenter facilities are state-of-the-art, meeting high standards of operational control and security. Look for SAS 70 type II and similar certifications. Knowing the geography in which your data is stored can be important for compliance as well, and may have an impact on data access times: Depending on your data set and use case, you may achieve faster access if storage nodes are located near your corporate or branch offices.

3. What kind of security mechanisms are in place? Look here for strong encryption methods, such as AES-256 and SSL, to secure data at rest and in transit, and sufficient access control and authentication mechanisms to ensure that the wrong person won't gain access to your information. Ask for a published description of the provider's security policies and processes.

4. How does the provider ensure data durability, reliability and availability? You should look for offerings that provide redundancy across multiple facilities and systems within each facility. The provider should perform regular data integrity checks to protect against corruption. Versioning enables additional protection, by allowing multiple versions of objects to be stored, retrieved and restored in case of failures or unintended user actions. Finally, the provider's service-level agreement (SLA) will spell out storage availability commitments. Look for a minimum of three nines (99.9%) availability over each monthly period and 10 or 11 nines of durability over a year, with the ability to withstand and sustain the concurrent loss of data in one or two facilities.

5. How easy is it to upload my data, especially when moving large data sets into the cloud? For this purpose, check out whether the provider offers a data shuttle (portable storage device) or dedicated high-speed connection for seeding initial data into the cloud.

6. How easy does the provider make it to transfer data out of the storage cloud? The answer to this question hinges in large part on the application programming interfaces (APIs) the provider supports: Industry standard REST APIs will ensure that your data is portable, while proprietary APIs may be the first step to vendor lock-in. The overwhelming majority of cloud storage providers now support a REST-like API, so it's worth looking for that in particular. One other thing to qualify upfront is the cost of transferring data out of the cloud. Most providers charge little to nothing to move data into their clouds, but do charge for data transferred out.

7. What kind of access performance does the provider support? Speed of access will be based in part on the location of your data, as mentioned above. If you're planning to store primary data in the cloud, you should evaluate the use of an on-premises cloud storage gateway, which will provide local caching of frequently accessed data and may also compress and deduplicate data before it is sent to the cloud.

8. Will the provider help me to comply with key industry regulations? If your business is subject to major regulations, such as HIPAA or PCI DSS, you'll need to know the geographic location of your data, and you'll likely also need evidence of various certifications before sensitive data can be moved to the cloud. Compare each cloud storage providers' offerings to understand what level of regulatory compliance is built into their cloud storage services.

9. Can I be certain that the provider will still be in business five years from now? If you're considering working with someone other than a major, well-known provider, you'll want to check out the provider's financial stability and track record, to ensure that your data will be in good hands.

10. Can I count on a quick response from the provider's technical support team, in case I run into problems? Many providers now offer multiple tiers of support, including across-the-board 24x7x365 access, as well as named contacts.

 

How should NFC security risks affect a BYOD security policy?

Securing mobile devices that access the corporate network is hard enough, but now one reads of the security holes with the near field communication (NFC) technology built in to many of these newer devices. Are there any methods enterprises can use to secure NFC in mobile devices? Should one consider banning such devices in BYOD security policies?

 

Charlie Miller's security research for Accuvant Labs details the many vulnerabilities he found in NFC implementations. These vulnerabilities allowed him to access photos, send text messages, make calls and browse the Internet. If an attacker is able to force access to the Internet over NFC, they could potentially root the phone. The security risk from NFC attacks could be minimized by using an app that only enables the feature for a short period when its use is absolutely necessary. Keeping mobile devices updated with the most recent patches also helps reduce any NFC security risks, but, of course, this depends on the wireless carrier ecosystem used to deploy the patches.

 

In most environments, banning any device as a part of a BYOD policy would be impossible to do consistently. If a company has the sufficient resources and enough control to search everyone who enters your buildings or check the configuration of all devices connecting to your systems or network, it might be possible.

 

Many enterprises have fretted over any new wireless technology that they don't think they can fully control, including WiFi, Bluetooth, RFID and now NFC. Enterprise fears over wireless security even created a market for anti-WiFi paint, so special phone cases that block NFC are probably the next cell phone accessory to be marketed along with RFID blockers. For some enterprises, security concerns over NFC technology are legitimate, but for the majority of enterprises that don't have such stringent security requirements, worrying about NFC may not be a good use of information security resources.

SAFE-certified devices make Android work for businesses

The Samsung Approved for Enterprise program adds IT administration features to certain Android smartphones and tablets, which could make managing and securing devices significantly easier.

Samsung Approved for Enterprise (SAFE) is one of several efforts by manufacturers to beef up Android devices, overcome the OS' shortcomings and increase its enterprise appeal. SAFE offers proprietary extensions IT administrators can use to assert broader, deeper control over some Android smartphones and tablets.

Filling Android's gaps
Many consumers love Android, but IT often fears it. Although Google continues to improve Android's enterprise-readiness, this mobile OS is still playing catchup on remote administration and platform security. Some highly sensitive organizations narrow the gap by installing custom Android builds, such as Security-Enhanced Android, to find and address gaps in security, but that approach requires significant IT effort and won't help on user-owned devices. Organizations that want more advanced control over off-the-shelf Android devices may prefer ones that ship with manufacturer and carrier-blessed enhancements. That's where SAFE comes in.

SAFE-certified devices, including the Galaxy Note II, Galaxy S III and Galaxy Tab 2, contain proprietary Samsung capabilities and application program interfaces (APIs) that go beyond industry standards. The APIs are tested for interoperability with third-party mobile device management (MDM) software and virtual private networks (VPNs). There is no need to load a SAFE-certified device with alternative firmware, although you may choose to install a third-party MDM agent or VPN client to get the most out of SAFE.

SAFE features
Some of the enhancements you'll find in SAFE-certified devices include:

• Deeper device management: Using SAFE APIs, admins can permit and disable features, such as camera, voice recording, screen capture and removable storage that IT administrators can't control through ordinary Android Device Admin APIs. Admins also have better control over Bluetooth and Wi-Fi network use. Employers who are concerned about expenses can also use SAFE to define and enforce voice and short message service (SMS) budgets.
• Broader application management: SAFE APIs let third-party MDM clients silently install and remove applications (including those pulled from app stores), add and remove widgets, configure the home screen and notifications, and disable certain keys to create kiosk-mode devices. These enhancements help IT enable consumer-grade smartphones for business use without ever physically touching the devices.
• Enhanced Exchange ActiveSync: One common Android challenge is that consumer-grade native mail clients can have limited Exchange ActiveSync (EAS) support. SAFE-certified phones support 50 EAS attributes and client capabilities such as out-office responses, message flags, download limits and SMS/voicemail synchronization. They also let users view messages by category or conversation. Some employers will still prefer third-party enterprise email clients such as NitroDesk TouchDown for Android or Good for Enterprise, but SAFE extensions yield a native client that is more business-friendly than most from original equipment manufacturers.
• Stronger data encryption: A major Android security concern is the lack of full-device encryption. Android 3.0 Honeycomb (for tablets) and Android 4.0 Ice Cream Sandwich (for smartphones) added OS encryption features, but most currently deployed Android devices still lack hardware support for encryption. SAFE-certified devices not only support Federal Information Processing Standards (FIPS) 140-2 certified Android device encryption, they also provide Samsung On-Device Encryption (ODE), a hardware-accelerated second layer of protection for preferences, databases and Secure Digital card contents. ODE can be turned on using MDM software, EAS or manual settings. To better protect data in motion, SAFE also offers enhanced control over native and certified third-party VPN client configurations.

Tapping into SAFE extensions
End users can configure some SAFE enhancements, such as ODE, but most require a third-party server. This is not a limitation of SAFE, but rather a key part of SAFE's appeal. SAFE's goal is to help IT remotely secure and manage off-the-shelf Android devices by integrating with existing enterprise infrastructure. For example:

• MDM agents can remotely read or write device attributes, install or remove applications, or initiate actions such as remote wipe, find and lock. With SAP Afaria, Juniper Junos Pulse MSS, MobileIron MyPhone@Work, SOTI Mobicontrol or AirWatch, companies that use MDM can access many of the above-noted SAFE extensions. MDM vendors constantly adapt to new APIs from Samsung and other OEMs, so expect to find differences in SAFE controls that will surface through each MDM agent's graphical user interface. All SAFE-certified MDM products have passed rigorous interoperability tests with Samsung.
• Companies that use VPN tunnels to authenticate and encrypt mobile enterprise access will find that IT can remotely configure quite a bit more on SAFE-certified devices. Notably, businesses that use Cisco, Juniper or F5 VPN gateways can benefit from SAFE-tested VPN clients and configuration settings, including Cisco AnyConnect client extensions.

Businesses that use any of the above-mentioned third-party servers to manage and secure Android devices can freely use SAFE to gain deeper, broader control over some Samsung phones and tablets. Unfortunately, SAFE can't be used on other Android devices, or with other third-party MDM software.

Think about SAFE as a way to raise the bar for certain users, groups or use cases. You might not be able to take advantage of SAFE on every personal device, but you might offer better support or additional apps to devices that are SAFE-certified. You might also procure SAFE-certified Android devices in situations that warrant enterprise ownership or platform standardization, such as tablets used in kiosk scenarios or phones field workers share to replace old, ruggedized Windows CE devices.

Finally, Samsung isn't the only Android vendor to offer proprietary device management or EAS extensions. Other examples include Motorola, with its Enterprise Device Management, and Nitrodesk, with TouchDown. Don't assume you're limited to industry-standard Android APIs. If you're looking for tighter control over Android devices that employees use for business, dig further and take a hard look at enhancements such as SAFE.

Cloud backup, BYOD challenges challenge IT control over data

Protecting more data that is scattered in more places than ever before is the biggest challenge to backup administrators today, according to IT executives at a data management symposium this week. IT executives at the symposium, hosted by backup software vendor CommVault, discussed their policies for dealing with bring your own device (BYOD) and cloud backup -- two trends that threaten IT's control over critical corporate data.

 

Several of the execs said they deal with the challenges that BYOD presents by supplying workers with endpoint devices such as smartphones and tablets so they can monitor data on the devices. "One of our biggest challenges is to know where all the data is, and that it's in places where we want it," said Branndon Kelley, CIO at American Municipal Power (AMP) in Columbus, Ohio. "We're staying away from BYOD. We're saying, 'We don't want you to bring your own device, but we'll buy you whatever device you want,' and let people get comfortable. Or else we won't be able to retain talent, and our workplace is not going to be a place that invites people who want to stay."

 

Tracy Riggio, IT manager of Temple University Health Systems in Philadelphia, N.J., said her hospital also provides devices for its users, who are mainly physicians. "A lot of our physicians use iPads to connect to Epic [an electronic health record system], so they have it right with them," she said. "We've had doctors ask to buy their own, but we tell them, 'It's not going to work. You like your email? OK; use ours.'"

 

Gail Bymun, director of enterprise storage and data protection for Brookfield, Wis.-based financial services firm Fiserv, said her company's security department mandates that all corporate data resides on Fiserv-owned hardware. "Data is not allowed to go to a personal device," she said. "They are very strict on that. We're starting to branch out and support more devices. We're seeing iPads and iPhones, where in the past it was all Blackberries. There was pushback from employees because of the slow adoption of some tools."

 

Other experts at the symposium emphasized the importance of strict control over devices for data security. "People want to bring in their own devices, and they have zero concept about backup and recovery," independent backup consultant W. Curtis Preston said. "It's a mess."

 

Dealing with cloud backup challenges

The same can be said for people who set up their own cloud backup, another issue the IT execs have to deal with. Cloud use is difficult to control because users can go to cloud providers and provision their own storage online with credit cards. "I'm never going to give up the storage side to the cloud," said Ed Donakey, vice president of strategic relations for genealogy organization FamilySearch International. "The compute side makes sense for the cloud; that's commodity-based. But for backup and recovery, we'll continue to monitor that ourselves."

 

Riggio said regulations in health care make it important for Temple Health Systems to keep its data on its own disk and tape. "We don't use the cloud yet," she said. "It's still a security issue. We're a highly regulated industry, and we're held responsible. Should that cloud infrastructure go away, it would be a problem."

 

For security, she said Temple Health encrypts all of its data. Primary data gets encrypted on EMC VMAX arrays and she uses CommVault Simpana to encrypt data that gets backed up to disk and then moved off to tape. "If a tape gets lost, we don't know if there's patient data on there, so we have to report it," she said.

 

Fiserv's Bymun said there are "pockets" of people in her company who use the cloud. Fiserv is an umbrella group of smaller companies, and there are different approaches to the cloud. "Some businesses have gone out to the cloud on their own because we could not react quickly enough [to their request for capacity]," she said. "Now we have a focus group working at providing cloud and hybrid solutions for end users."

 

AMP's Kelley said he is worried about legal ramifications of "Joe User" going out and provisioning his own cloud backup. "I can't imagine any CIO would say, 'That's a good idea.' I would say, 'No, I invested half a million dollars in this infrastructure, let's do it this way.'"

 

Kelley said APM has a tiered approach to the cloud. It keeps critical "heart and lungs" data in-house, but has moved some important applications such as email to the cloud. The utility company also uses the Oxygen Cloud for file sharing. "Cloud is a big part of our strategy," he said, but some things must stay internal because "we lose flexibility once we go to the cloud."

 

Kelley attributes the rise of BYOD and the cloud in the enterprise to users demanding the same level of technology at work as they have in their personal lives. "What we're dealing with is the first generation coming into the workforce that's grown up around IT and computers their whole lives," he said. "The Internet has been part of their lives since inception. When I got into IT 13 years ago, you used to go to work and the technology was better there. The Internet was faster; the computer was nicer; they had better printing.

 

"You go into work today, and there are environments still running [Windows] XP and old technology that barely works. You have this new workforce saying, 'You can just leave me at home and I can do a whole lot better.' As IT leaders, we have to take responsibility for that," he said.

 

How iOS encryption and Data Protection work

Apple's Data Protection and built-in iOS encryption provide a powerful system for securing information, but only if those technologies are properly implemented.

If workers don't enable Data Protection on their devices, or if they use apps that don't utilize it, devices rely on basic iOS encryption to protect sensitive data, which only makes the devices easier to wipe. Making sure that users have Data Protection and associated settings enabled will help you take advantage of the robust encryption that Apple's system provides.

When Apple released iOS 4, the company added an important new feature: Data Protection, an architectural enhancement that beefs up iOS encryption on devices. It works in conjunction with the encryption mechanisms built into devices' hardware and firmware to protect data better. In iOS 5, Apple enhanced Data Protection to provide more flexibility for file access even if a device is locked, without putting data at risk.

Built-in iOS encryption
Since the release of the iPhone 3GS, Apple has built encryption into the hardware and firmware of its iPads and iPhones. Every iOS device now has a dedicated Advanced Encryption Standard (AES) 256-bit crypto engine that sits between the flash storage and main system memory. The engine works in conjunction with the SHA-1 cryptographic hash function – which is implemented in the hardware as well -- to reduce overhead for cryptographic operations.

Also built into the device's hardware is the unique identifier (UID), an AES 256-bit key fused into the application processor. The UID is specific to the device and is not recorded anywhere else. No software or firmware can read it directly. They can see only the results of the encryption and decryption operations. Plus, because the key is burnt into the silicon, it cannot be tampered with or bypassed. Only the crypto engine can access it. As a result, data is cryptographically tied to a specific device and cannot be related to any other identifier or device.

Building encryption into the physical architecture makes it easier to encrypt all data stored on an iOS device. In fact, Apple enables this level of encryption by default and does not permit it to be disabled. But such iOS encryption provides little in the way of real protection, other than to facilitate a fast, secure wipe of the system. This is an important feature, especially if a device is lost or stolen and remote wipe has been configured beforehand. Under such circumstances, a device's data can theoretically be erased before someone can hack or jailbreak it. But if a device can't be wiped quickly enough, a hacker can crack the security and get at sensitive data.

Enabling iOS Data Protection
That's where iOS Data Protection comes in. Data Protection is implemented at the software level and works with the hardware and firmware encryption to provide a greater degree of security.

When Data Protection is enabled, each data file is associated with a specific class that supports a different level of accessibility and protects data based on when it needs to be accessed. The encryption and decryption operations associated with each class are based on a complex key hierarchy that utilizes the device's UID and passcode, plus a class key, file system key and per-file key. The per-file key is used to encrypt the file content. The class key is wrapped around the per-file key and stored in the file's metadata. The file system key is used to encrypt the metadata. The UID and passcode protect the class key.

Fortunately, this operation is invisible to users. They access their apps as they always have. The important thing to take from this is not the specifics of how the encryption-related mechanisms work together (unless you're a developer), but that for a device to utilize Data Protection, a passcode must be used when accessing that device. The passcode not only unlocks the device, but also becomes inextricably enmeshed with the UID to create iOS encryption keys that are more resistant to hacking efforts and brute-force attacks. In fact, users need to enable passcodes on their devices to enable Data Protection.

Protecting data in iOS
If you support iOS devices in your organization, your policies should direct workers to use passcodes to help protect sensitive data. But remember that not all passcodes are created equal. On an iOS device, passcodes come in two types: the simple, four-digit, numerical passcode and the more complex alphanumeric passcode, which is normally much greater in length. Not surprisingly, the more complex the alphanumeric passcode, the better.

For example, according to Apple documentation, a brute-force attack on a device that uses a nine-digit numerical passcode will take 2.5 years to try all possible combinations, in part because iOS enforces escalating time delays to help discourage such attacks. On the other hand, a six-character passcode that mixes numbers and lowercase letters will take 5.5 years. As you would expect, a four-digit numerical passcode should take no time at all. Of course, if users set their devices to be automatically wiped after 10 failed attempts, the number of tries is not an issue (unless the passcode can be discovered within those 10 attempts). Even if a hacker were able to jailbreak a device and bypass the passcode, the data would still be inaccessible because the hacker would not know the passcode.

Yet passcodes are not the only consideration if you want to take full advantage of iOS Data Protection. An app must be designed to use the Data Protection application program interfaces to ensure that data is protected when it's accessed by the application. The app must also ensure that data can't be moved to apps that don't use Data Protection. In other words, an unsecure app should not be able to access the data in a secure app. Keep in mind that, even if an application is designed to protect all its data, it can run up against limitations out of its control. For example, Data Protection can't be used on files that participate in iCloud storage.

With the release of iOS 6, users have a bit more control over apps being able to access secure data in other apps. Although the encryption mechanisms themselves did not change in iOS 6, the operating system now requires a user's permission before a newly installed app can access private data, such as calendars, reminders and contacts. Users can now also modify data access for certain application in the device's settings (under Privacy).

The key to taking full advantage of iOS encryption resides not only in enforcing passcode policies, but also in maintaining complete control of the apps implemented on iOS devices, or at least those apps that deal with your organization's sensitive data. Anything less can amount to practically no protection at all.

NFC and other reasons Enterprise IT needs a next-gen mobile strategy

 

Like many CIOs this year, Jeff Harvey, IT director at Regis Corp., has a major mobile deployment in the works. He's dispensing iPads to 1,000 regional supervisors at the company. For Regis, the undisputed heavyweight of the hair salon business (with more than 12,700 locations worldwide and annual revenue of $2.3 billion), the mobile strategy represents a leap forward. Not so long ago, many supervisors at the Minneapolis-based chain didn't use email at work, Harvey said. "This is a big step in increasing the flow of information."

 

What the iPad deployment is not is a second-generation mobile strategy, according to Gartner Inc. In fact, if your current mobile strategy revolves around dispensing smartphones and tablets, or hammering out a BYOD (bring your own device) policy, or replicating the company's Web offerings for mobile devices, or focusing on developing native apps, you're strictly a "first generation" CIO when it comes to mobile innovation. Not that there's anything so wrong with that, said Hung LeHong, research vice president on the Executive Leadership and Innovation research team at Gartner Inc.

 

"When we talk to first-gen CIOs, it's more tactical reaction than strategy: Users are clamoring to use iPhones so they have to figure out BYOD, or marketing wants something fast," LeHong told CIOs at the consultancy's annual CIO Forum this spring. These CIOs are responding to urgent business needs.

 

What this first-gen mobile approach fails to account for, however, are advancements in technology -- from near field communication (NFC) and visual recognition technology to objects with IP addresses -- that can optimize business processes and could make some business models obsolete in just a few years. A second-generation mobile strategy is not about devices or replicating services for mobile devices, LeHong stressed, but about finding mobile capabilities that the business was never able to do on the Web or a mainframe, or with client/server computing. And the time to do that is right now. "There are very few times when we have a new technology that we haven't fully innovated to maximum potential," LeHong said.

 

NFC is a standards-based wireless connectivity technology that enables two-way interactions over short ranges (about four inches) between electronic devices. It shares technology with radio frequency identification (RFID) tags and contactless smart cards, and allows users to perform contactless transactions, access digital content and connect electronic devices with a touch. Unlike RFID technology, where enterprises have determined how widespread (or not) adoption will be, the bellwether for NFC will be consumer adoption.

 

NFC-enabled phones can interact with objects -- notably, cash registers -- so consumers can tap to pay. Macy's, Bloomingdale's, Pinkberry and a host of other retailers are pairing with Google Wallet at select locations. McDonald's is testing cloud-based NFC payments in Austria. But use cases extend well beyond payment:

• Hotels can send your room key to your phone, allowing you to bypass the front desk. BMW is using NFC technology that will enable drivers to book hotel rooms from their car, access their rooms using their car keys and receive special offers available only to BMW drivers. Just as mobile phones basically rendered the hotel room obsolete for long-distance calls, NFC could render obsolete room charges for movies, because the entertainment streaming on your small screen can be ported to the big screen.
• Mobile network provider Orange is partnering with home health care providers to track and monitor home health visits by having nurses tap their NFC phones to a patient card or to an NFC mailbox sticker as they enter and leave a house.
• NXP Semiconductors recently demoed an RFID- and NFC-enabled smart washing machine. Using an NFC-enabled phone, an authorized maintenance technician performs diagnostics on the washing machine, changing its status, updating firmware and launching an app that communicates with the manufacturer's service center.

The value of NFC in a mobility strategy

Rather than viewing NFC as a payment technology, CIOs should take advantage of its "pairing and sharing" capabilities. For example, BMW's NFC-enabled keys are not only a tool to open a car or hotel room door, but also a way to provide BMW customers with promotions and other added-value perks. How this technology will be adopted in specific industries is still up in the air. At the CIO Forum, for example, a CIO from a luxury hotel chain wondered whether hotels should start developing their own NFC keycards or whether there soon will be an industry-standard keycard adaptable to all hotels.

 

Security and privacy issues abound with this technology, of course, and there is always the possibility of consumer backlash. Although the NFC Forum, a nonprofit industry association formed in 2004 to advance NFC, is developing standards, Gartner's LeHong cautioned there is "no one standards body." CIOs will have to pair NFC standards with their industry's standards -- PCI standards in retail, the Health Insurance Portability and Accountability Act in health care -- to incorporate NFC into their mobile strategies, he added. As for whether an investment in NFC pays off? NFC will generate $74 billion in sales by 2014, Jupiter Research estimates. Last year, Gartner estimated that by 2015, 50% of smartphones will be NFC-based, but Gartner analyst Mark Diodati recently said he believes that estimate is conservative.

Enterprises eye maturing IaaS

Companies can get just about any application as a service, but conservative IT shops that want their infrastructure firmly planted in their data center continue to use public cloud only for the apps they don't care about. At least for now.

 

The public cloud services market is expected to grow 18.5% this year to total $131 billion worldwide, up from $111 billion in 2012, according to Gartner Inc. research released last month. Infrastructure as a Service (IaaS) continues to be the fastest-growing segment of the market. It grew 42% in 2012 to $6.1 billion and is expected to grow 47% this year to $9 billion, according to Gartner's report.

 

Companies may warm to IaaS this year because these public cloud platforms have matured and pricing has improved -- thanks to competition among Amazon Web Services (AWS), Microsoft, Google, Rackspace, Hewlett-Packard and others. "Many of our clients think their internal costs are cheaper than cloud, but cloud is getting cheaper because Amazon [and its competitors] keep lowering prices,"said Dave Bartoletti, an analyst with Forrester Research Inc. "A lot of companies are analyzing their application portfolio to determine which [apps] will drive cloud economics."

 

Moving to the cloud can be refreshing

Many companies move to the cloud during a software refresh cycle, at which point IT determines if upgrading hardware and software and managing those environments are worth the headache and the cost versus moving to a cloud service, one analyst said. "The question people need to ask is, 'Do you want to get rid of the app, the infrastructure, or all of it?'" Bartoletti said.

 

If the answer is "the app," there are plenty of Software as a Service, or SaaS versions of on-premises apps. IT can also migrate legacy apps to a public cloud platform -- if they're apps that lend themselves to cloud. The best workloads for cloud are scalable apps that take full advantage of cloud elasticity; apps with fluctuating demand and those that are already virtualized and componentized are good candidates, Bartoletti said.

 

Email, collaboration and other apps that aren't necessarily critical to business are also good for cloud -- and those are the systems that IT pros plan to put into the cloud this year. Of the companies that use cloud services, 52% said they will provision their email services to the cloud in 2013; 38% will use cloud-based productivity apps; and about 42% will use a cloud-based file-sharing app, such as DropBox, according to a recent TechTarget Inc. survey of more than 1,500 IT professionals.

 

Because cloud allows developers to quickly spin up a new software version, enhance it, then turn the cloud instance off when they're finished, companies will continue to put their test and development environments on IaaS platforms, analysts said.

 

Back-office apps remain in the back office

Meanwhile, back-office applications that don't change very often remain unpopular candidates for the cloud, analysts said. "The app that can't automatically scale isn't a good cloud app -- a monolithic ERP [enterprise resource planning] transaction processing system, for instance," Bartoletti said. And some apps simply aren't good candidates because of cloud data security concerns.

 

"In a banking environment, regulations are stringent regarding customer privacy, so even to outsource email is a little dicey," said Christopher Green, vice president for IT infrastructure systems at Washington Trust Bank, a large commercial bank based in Spokane, Wash. "We hold things close to the vest." The bank does use AWS for backup archiving, but they encrypt the data before sending it to the cloud, he said.

 

Others continue to forgo public cloud altogether in favor of total control. "I have worked in the cloud before; and like they say, when your Internet is down, that is one thing, but [if] your phones and other things are on there, it's a problem," said Tom Likely, IT manager at Billion Automotive, a large automotive dealership based in the Midwest.