Susan Hall talked with Dave Buchholz, Intel IT technology evangelist, about the company's work on what it calls "BYOC [bring your own computer] done right."
Hall: Tell me about what Intel's doing in regard to employee-owned computers.
Buchholz: I'm the one researching this not only from our perspective, but also other Fortune 500 and below companies. So I've been doing a lot of research in this space for the past year or so.
We are looking at areas that make sense with this. We've gone back through and looked at our user base and segmented our users into categories that make sense instead of the traditional cluster of everyone in one user segment. The thing about BYOC [bring your own computer] that makes it attractive to us, when we look at contractors most of these contracts require that they bring their own computing power. That would really be nice to have them come in and bring their own computers, yet at the same time we have to supply our own environment on top of that device. Ultimately, if people in our environment would like to use a certain device, we'd like to be able to support it, but there's some restrictions, we're finding. So we're trying to identify, are there architectures, technology things that we can do to enable that moving forward.
"To make this work, you have to let people do what they want to do in the personal environment, yet enable them to do the corporate stuff as well. The key to that is keeping the isolation. "
Hall: What restrictions have you found? [Intel and Citrix last January announced a partnership to develop a client hypervisor.]
Buchholz: If a guy comes into Intel and says he wants to use his own laptop, he's got an environment already set up on that laptop that we know nothing about. Has it got viruses? Has it got this, has it got that? So trying to put my company tools on that, I don't know if I'm opening my company to more vulnerability. Am I going to be unnecessarily exposing IP? So I can't control or manage that endpoint, I'm not sure that's a secure computing environment that I want to enable things on. So maybe I could give him a container environment. What I mean by that is a thin client approach or a displayed client approach. But there are Trojans out there that allow you to do screen scraping and so forth. So even if he's displaying it from a Web browser running a Web app going back to my company, he can infect my company with a virus because it can't go back through the Web or back through the display protocol.
Maybe we're working on something that nobody else in the world should know about until we announce it, but with screen scraping or something like that, it could grab that technology. I have no way of preventing that because I'm not managing that endpoint device. So it's all about what kinds of controls we put on those devices, and it's really hard when we don't own them. ...
You know with Windows 7, they've announced XP mode, you can run a compatibility OS underneath your Windows 7 OS, so if your Win 7 won't run your application, it can run on XP. That OS requires specific technologies to exist in the platform, i.e., hardware virtualization of the CPU, to ensure the performance The problem is that now you've got two OSes you're trying to manage and XP OS isn't necessarily secure because it's running on top of another OS. If you're managing the front OS, you can't guarantee the other OS is secure. We're looking at other technology that would move that virtualization down to running on the platform itself. By that, I mean taking a hypervisor and running it on the computer, right on the bare metal of the computer, and putting the OSes on top of it, so if I do have two OSes-maybe one's a personal OS and the other's a professional OS-they're isolated from each other. They might be running at the same time and you'd be able to switch between them, but they'd be isolated-one can't infect the other, one can't take process from the other and when it comes to a screen scraper, it couldn't scrape the other environment because it couldn't even see it.
Hall: So where are you in the process of finding a solution to this?
Buchholz: We're still in the research and proof-of-concept stage. We have a user segment that makes sense [for BYOC] to maybe go out and look at, maybe next year sometime. We're working with some technologies in our lab space that aren't ready for prime time. They'll probably be ready for prime time in the summer of next year. ... At that point, I think we'll be moving forward in testing some of these BYOC concepts into some of these segmented user bases.
Hall: What kind of policy do companies need?
Buchholz: Look at Android, iPhone, Windows Smartphone. People have bought [expensive] smartphones and want to be enabled. That's where we're seeing the biggest push from a BYOC [or bring your own device] perspective. People say, "I just want to get my e-mail, my contacts, my calendar." I want to make sure there's not Intel e-mail sitting on a device that's not password or PIN protected, not encrypted. We've had to put some controls in place. Now we've implemented some architecture so we can say, "If it meets certain guidelines, we'll enable your device." But there will be controls, certain things enabled on the device based on what it can support, but part of that was also those legal areas.
Today we can keep people from doing personal or corporately inappropriate items on their systems because we own them and issue them. When allowing them to use their own systems, how can we control when they do personal stuff, or where or do we? Also, do we do any compensation for use of personal machines and such? It opens a lot of questions. Do we have a right to do an audit of the system? Do we say, "We don't own the device, so here's an end user agreement. You've got to agree to these terms and sign it."
Hall: Can the company ban certain applications, such as peer-to-peer that employees use?
Buchholz: From my research perspective, the one model in BYOC that's not going to work is to take someone's laptop and say, "I'll enable you from a corporate standpoint, but now you can't do anything personal on it." To make this work, you have to let people do what they want to do in the personal environment, yet enable them to do the corporate stuff as well. The key to that is keeping the isolation. ...
When a person comes into Intel, I need to be able to say, "You don't need a network on the personal side. You're on premise, so you need to be doing Intel work, not personal work."
Hall: How would you handle support?
Buchholz: Again, the key is the isolated environment. ...If the 80,000 users I have to support each add a personal environment, my footprint will only get that much bigger. I just can't do that. If there's a problem in your personal environment, then you have to go get that fixed. If you have a problem in your corporate environment, I can fix that, and it's probably copied across everybody in the corporation, so it's probably an easy fix to do.
Not only are we looking for those technologies that provide that isolation, but there's also some synchronization from that corporate environment to our back end, so not only can I audit you if you've done something wrong, but if you drive off with the laptop on top of your car, we can kill that environment on that device that's probably trash now, but you can go get a new one and we can reproduce that environment on it or we can give you some remote connectivity to it. So we're looking at those failovers so we can provide that device-independent mobility.
Hall: So what happens if someone leaves the company?
Buchholz: We're looking for that technology. In today's world, there's no way to control that. If you leave the company, if you wrote something on that device, unless we get that device and wipe it off there ourselves, how do we know that data's gone off that device? If we can develop this container on the device, and that container is controlled by an infrastructure toolset, we can say that the container has to check in every so often. So whether you leave the company or you go get a new computer, we can transfer the container to the new one. We can make sure we killed the container off the old device. Or it can be part of our procedures for leaving the company, to kill the container off the device, so even if it doesn't check in every so often, the next time you log on, it won't be there. The procedure for leaving the company is there; it's just a matter of getting the technology that will support this BYOC concept.
Hall: Could this concept in some ways make IT's life easier?
Buchholz: Right now, we get this big gray blob of data and we don't know if that's apps that we've sanctioned to put on there. If there's some photos on there, we don't know if they're of some engineering samples you took in the lab or your vacation to Hawaii. If it's a Word document, we don't know if it's an Intel design document or your wife's fruitcake recipe. So if we do get BYOC the right way and get that isolation, we believe it will make our IT life much easier.
If I update or change something in that professional environment, I know what that environment is, No. 1, but No. 2, I know you haven't put anything into it or changed anything that isn't company-related. If I'm backing data up, I know it's Intel data. If I'm updating an OS, I know it's not affecting any of your personal stuff. So it should make it a lot easier for the IT shop.