Mobile Device Management

Behind the Software Q&A with Beachhead Solutions

As we’ve talked about in the past, mobile device proliferation for work purposes isn’t going anywhere, and for good reason, but unfortunately, neither are the associated security risks. With so many devices floating around there’s any number of attack vectors for those who wish to breach security and get at sensitive and/or proprietary data.

Beachhead Solutions, a mobile device management (MDM) company based out of San Jose, California, has been aiming to address the gap in mobile device security for small-to-medium-size businesses, a segment of the market where many organizations simply operate with no security solution at all. In this Q&A with Beachhead Solutions, we talk to Jeff Rubin, VP of strategy and business development, and Cam Roberson, director of marketing and reseller channels, we ask about Beachhead’s dynamic approach to security.

Tell me a little bit about how Beachhead Solutions got started. At the time was there a specific security need that wasn’t being addressed by competitors?

Jeff Rubin: First of all, I will start with a little story. One of my cofounders was working for the federal government at the time as an internal consultant.

He was with a reasonably high level member of the U.S. Army. The guy was worried because he had devices–electronic devices–with disk storage on them. These were PCs or Palm Pilots that could fall off the back of a Humvee in Afghanistan, which the bad guys could then get their hands on. What can you do about that?

Our guy came up with an idea, which he demoed on a little Palm device. The technology was pretty simple. Basically, he set it up so that when he gave the device to someone–let’s assume it was a general–he said, “Go ahead and enter your password on this device.”

The general said, “I don’t know the password for this device.” Our fellow said, “Sure, you’ll be the bad guy who picks this thing up. Try to put one in.” The general typed in two or three wrong passwords, and suddenly he felt that the device was getting a little bit hot in his hands. He had to put it down on the table. Within moments, a little whirly wisp of smoke came flying out of the thing, and it had melted itself into oblivion. What our guy had simply done was put in a way of destroying the data by having this trigger of multiple bad logins. The little agent he put in commanded the device to overclock itself and run as fast as it could, then little faster than that, and then melted itself.

Believe it or not, that little story–although we never built that product–was the genesis of the company. The idea was we needed a way to be certain when a device with some sort of storage was lost or stolen, you needed a way to be certain that whoever it was that picked up the device had no access to that data. When we looked at the marketplace for such a thing, we found PC products that were generally software based and had encryption as a kind of boot lockable drive.

But if the password was known or knowable, encryption is completely useless. It’s designed to decrypt when an authorized user wants to look at the information. Not only that, it was very burdensome. This was a very heavy piece of software that sat on top of the drive, and it locked the whole drive including operating systems, folders and executables. Everything was slow and ponderous.

So we saw the opportunity to do two things then, which was to encrypt what was then the very beginning of regulatory compliance requirements for such; but to do it in a way that would not be burdensome to users at all; and secondarily offer a set of security tools that go beyond the encryption to include what we ultimately referred to as “data quarantine,” which is a way of eliminating access to the data without necessarily eliminating the data itself.

Here’s a hypothetical: Say an employee at financial services organization gets his smartphone stolen. It’s a personal device since this organization has a BYOD policy where he can use it for company data. Say this phone has access to an email client that has spreadsheets of user data on it. What would you be able to do on your end to address that?

Jeff: There are several ways we can handle that. The administrator at the company typically would be the one turning knobs, not Beachhead. Possibly, also the managed service provider (MSP) if they bought it through a channel where the service provider is actually providing the service.

They have a web-based console that they can get on. If the user reports that device stolen, the administrator would change the status flag on it to “stolen.” There are a set of commands normally associated with stolen. If a device is stolen, you would want to take draconian measures. There isn’t any reason to tread softly.

Before the device was ever stolen, encryption had already been enabled on the device. So everything on the device is encrypted. Now the problem is that the unauthorized user may be able to figure out the passcode. That’s why there’s passcode policy enforcement built into our system as well. It may very well be that you are already protected because the bad guy doesn’t know the passcode, so long as it isn’t “1111.” But we want to ensure that it isn’t knowable.

Let’s say that’s not good enough. Let’s say that the user had the passcode written on a note connected to the device. Even if the user didn’t and the thief types in incorrect login criteria it may very well self protect if that’s the way it’s set up beforehand, much like the story of the general. Let’s say that’s not in place, and the administrator sets the device to stolen status. As soon as that phone is connected to the Internet it will phone home –it will check in with the server–for just this purpose. It will see if there is any change in status. In this case it would receive the notice at that moment that it was stolen, and be told to swallow a “cyanide tablet”, which could take on a number of forms. Certainly it could be to wipe all the data from the system. Depending on whether we are talking about an iPhone or an Android it could be a factory reset. Or it could be more destructive than that.

Even if it weren’t a phone–even if it were a PC, we would certainly find it possible to wipe all local copies of the encryption certificate. If the criminals somehow managed to get through the passcode and could open the device and make it work, all the data would still be gibberish. Because there’s no local key. We create a key in escrow, and part of the reason it’s there is because if the rightful owner gets the device back, one push on the console by the administrator, and the key is pushed back onto the device, and all the data comes back in readable form.

My next question is probably one for Cam. What was the motivation behind having a free version for SimplySecure? How does that work as far as being a marketing tool for you guys?

Cam Roberson: As you might guess, it is somewhat of a loss leader to introduce customers and potential customers to our approach to providing mobile device security. We believe that companies, particularly smaller businesses, would prefer not to install or support hardware or software infrastructure and/or manage multiple consoles to protect all their mobile devices. We want to encourage businesses to try it as a very easy to manage web-based tool to protect all their mobile devices.

Laptops are mobile too. They are out there. In fact they may even be a greater data vulnerability. That’s where we cut our teeth. When we developed our endpoint data security strategy it was about encryption first, but it was a managed approach whereby the administrator for the tool has visibility into his or her environment of endpoint devices. They are checking in and providing information on the console about how frequently they are checking in, from where they are checking in, if any security measures have taken place automatically or by administrator action. Most importantly this channel can be utilized by the organization to change policy or control access to a compromised device. The administrator could wipe data or quarantine a device for example as Jeff’s just described.

This approach was unique and a bit before it’s time. Our competitors in the encryption space were not doing that. This communication-focused approach is naturally the approach taken with MDM because communications channels are ubiquitous and they are available all the time. We have always believed in this approach with PCs and Macs and now we have a unique capability to manage all endpoint devices utilizing this same methodology – PCs, Macs, Phones, Tablets and USB Storage.

The free version is there to introduce and to get us into environments that would see those benefits. One console to manage everything without the installation of a great deal of hardware, software and oversight requiring large IT groups to manage it.

Jeff: If I can add one final thing to that: recent studies have come out. I’m thinking of one in particular from SpiceWorks in May where they looked at SMB customers. More than 60 percent of the customers allowed BYOD or encouraged it in their environment. Yet something like less than 20 percent–I think it was 17 percent–actually managed it at all. It’s an enormous vulnerability. You have to ask yourself the question: why the gap? Why would you allow it and then not protect it?

The answer is that protection was viewed as expensive; a big infrastructure undertaking, hardware/software training, installation, perhaps being unable to offer users the ability to use native apps, which would cause a commotion, especially when on their own devices. So that’s one of the reasons we wanted to go and offer a free service that’s not hampered. It isn’t an under-configured service. We wanted to give them a chance to use the real thing on some select number of devices to try to get them over that hurdle because we believe the way we would approach the problem avoids all those terrible things that keep them from trying it and securing their environment.

To what extent do you run into prospective clients who are running either at host solutions that they developed internally or cobble together internally? Is that a challenge in terms of reaching out to people?

Jeff: There are few parts to it. I think the greatest competitor at the moment is inertia. For many doing nothing is much more comfortable than doing something, even though they are well aware that doing nothing is a problem. I do think that’s the hardest part.

The whole MDM business is still relatively young in its development. It’s not very far down that maturity cycle. In fact, to the extent that there is maturity, it’s almost entirely focused on enterprise-level solutions. Almost all of the major players in the industry are there, and it’s logical. It’s where the pain is felt most severely. It’s where you can take an expensive piece of software and amortize it. That’s usually the way things go on security.

The combination of having a relatively limited set of options for SMBs, the newness of the problem and the fear of upsetting users’ satisfaction with their own devices–it’s not like the olden days when you could command and control whatever they did because the company owned the devices as well as the data. There is a trickier game to play now, and they know that.

That said, there’s still quite a bit of competition. Everybody sees the rapid deployment of phones and tablets and their use in business settings. That’s hardly a secret to anyone. The BYOD nature of it makes it very obvious that there is a security problem associated with sensitive corporate data. When those elements are in place a lot of attention and money typically runs right to that problem. That’s the way business works. I would argue that it is not a low-competition field overall, but specifically meeting the needs of SMBs has not been covered all that well, certainly not to the extent of enterprise.

Cam: We’ve got two types of competition really, perhaps uniquely so. Previously we’ve built PC tools by and large and had only one set of competitors. Now we are building MDM management and tools, and we have a whole other set of competitors. We think we’ve carved out a nice differentiator in that we handle all mobile device –PCs, phones, tablets and USB devices as well. We have a rather unique position here in the market.

You mentioned that SMBs are an underserved market for this kind of software. Would it be fair to say that you guys specifically target the SMB category?

Cam: I think that’s a fair assertion. Beachhead has customers who have many thousands of devices under management. By and large, however, I think the focus of our effort is on the SMB. I suppose everybody defines SMB in different ways but we are well positioned with organizations with less than 1000 employees.

We have a customer-managed solution. We sell it as a subscription, as Jeff said. That’s a good solution for even a small IT staff of one. But there are other even smaller businesses that don’t have the wherewithal or the technical bandwidth to manage PC encryption and MDM security and so forth. They might choose to have somebody do it for them – perhaps along with other services that they’re already buying. We have a multi-tenanted solution whereby Beachhead bills our authorized MSPs monthly for only the device licenses they’ve deployed on behalf of their customers. The MSP in turn services those customers and bills them monthly for the service as well.

Our definition of is SMB can go down to as few as five managed by one of our resellers on up to tens of thousands of course. But our sweet spot is anywhere from 10 up to 500 employees/users. It is clearly a direction for us. We believe it is underserved, and we believe that most small businesses, and certainly very small businesses, don’t have the intestinal fortitude to build and support big infrastructure and in-house deployments of server-based software, for instance. They’d much prefer a cloud-based administration console that does it all for them.

What kind of experience have you guys had working with your MSP partners? You have an extensive network just in the United States itself, but also internationally as well.

Cam: We’ve gotten a really good response. We have just come out with the MDM tool and it’s been well received – we are picking up a lot of excitement. There’s a lot of new resellers put it in the hopper quite frankly who aren’t even referenced on the website who are advocating and making this part of their group of services that they are reselling to customers.

We think we have a unique advantage there as well, whereby we can address the parts of the small business market that doesn’t have the appetite for or the bandwidth to manage this kind of thing. Our resellers appreciate the ability to offer this service, and the customers seem to be receiving it well.

What’s the biggest challenge you guys are currently facing? That can be either technology or business. How are you addressing it?

Jeff: There are a few answers to this. Let’s look at both sides. I think from the business side, the challenge is, first off, getting to those players who are in the gap that we talked about before–the players who know they have a need to do something about device security. Getting them to look to embrace something other than status quo is a big challenge for us. I think the biggest challenge for us as a category is moving businesses into action. If they go into action and do some evaluation, we will do very well. But getting them into action is the bigger question.

From a technology perspective, we have always held to and still do cling to a couple of core tenets of how we want the users and administrators to experience our form of control and security. Sometimes that’s a difficult thing to marry with deep security because in general, not necessarily in every case, the tighter you make the security control the smaller the allowances you have for any variability. It becomes more difficult and onerous for users to operate in the way they choose to operate.

We have always felt that if you think about it metaphorically: a river of data flowing down, a lot of security tools put boulders in the river to control its speed–very difficult passwords to crack, which are also very difficult to remember, which also have to be changed frequently if you have a certain kind of security policy. To make their lives easier and more productive, this leads people to find ways to flow around that boulder, often overflowing the bank. They start writing their passwords down and using other tools to store the data that don’t require they live through these difficult conditions. This means that security policy makers may be unintentionally creating data leaks that they cannot find or track.

Our philosophy is always to find a way to not burden those people, to not put things in their way. Let them work they want to work and just make the banks taller rather than put stuff in the center of the river. Sometimes that leads to challenges because we would love to, for example, at the first sign of the security problem, wipe the device clean. That’s the most secure thing to do. That’s also going to tick off somebody in the organization who has brought their own device in and just had a lapse of memory. Six hours later they find the device again and they would really like everything to come back and not have it be a brick. That’s our real challenge – constantly finding a better way to provide that security while still not burdening the users. That is, honestly, tricky. If we had the ability to not care about the burden on the user, it would make things much easier.

Cam: One of our pursuits in trying to achieve this balance is the quarantine feature. That is the ability to change access to any device or preclude access to it and provide the capability to once again restore access to a device remotely and quickly from the administration console. So if a circumstance is less than certain as to whether the device is truly at risk, the company can take this step instantly through these communication channels. That immediately eliminates the risk and it is absolutely recoverable. If the administrator becomes comfortable that she has control of the device she can immediately provide access to it, remotely. It’s done literally with a push of a button on the console.

Jeff: And without having to go through a lengthy backup cycle. This is particularly valuable on a PC with a terabyte drive. You’re not going to be able to pull up a backup restoration on something like that in a reasonable amount of time. There has to be a faster way to restore access to the data.

Where do you see this industry going in the near future? What kind of challenges do you see on the horizon–and what kind of opportunities?

Jeff: Obviously we think that in the future there’s going to be a merging of security, independent of device size, operating system, device type, hard drive size. Whatever laptops become in the future and whatever tablets become in the future, maybe we won’t even be able to distinguish between the two.

BYOD is likely to stick around. There’s going to be a lot of hybrid environments where companies purchase tools, maybe for more specific tasks operating alongside employee-delivered tools. In the future–and today, but even more in the future I think–we will have to handle a hybrid environment where you have the ability to do have control over some kinds of devices and less control over others, but maintain policy consistency.

If you want more information on some of the leading MDM solutions, we’ve compiled the top product reviews, blog posts and premium content on our IT management software research page. Also, be sure to compare some of those solutions on our Top 10 Mobile Device Management Software report, where we give you the lowdown on pricing, key features and technology models.