BYOD: Bring Your Own Disaster?

The mobile phone has, for many, become no longer a “nice to have,” but a “must have” capability. Not only do we make and receive calls most anywhere, but we can access our calendars, check email, surf the web, update social media status, take pictures, play music, store contacts, play games, check scores, get directions, find restaurants … you get the idea. In a word it’s “indispensable.”

It is precisely because these mobile devices are easily portable, always connected and do about everything, but make toast for you in the morning, that they have also find themselves squarely in the middle of both our personal and professional lives. Most people are unwilling to carry separate phones for each persona because:

1. it’s cumbersome
2. it’s expensive (multiple wireless contracts, hardware acquisition costs)
3. it’s not necessary — since we know a single device can handle the chores of the workplace as well as the household seamlessly.

The problem from a security standpoint is that these handy devices, which most people already own and want to connect to the corporate network, represent a significant loss of control over traditional computing platforms.

So how do you keep “bring your own device” from becoming “bring your own disaster” from an IT security standpoint?

There are basically three different approaches to reign in what would have seemed to us 30 years ago as a data center in your pocket:

1. Mobile Device Management: install a client on the device which enforces security policies for things like password strength, encryption, remote device wiping, blacklisting and whitelisting of apps, etc.
2. Containerization: Install a client which includes APIs that app vendors can leverage to create isolated versions of email, calendar, contacts, etc. so that threats to the personal side (e.g. Facebook, SMS, etc.) won’t impact the business side (e.g. corporate email).
3. Virtualization: Install a client which essentially divides the device into multiple, virtual devices — meaning you basically have a personal phone with its apps and a business phone with its apps and never the twain shall meet.

Mobile device management provides the most seamless experience with virtualization providing the most isolation, which helps from both a security as well as privacy standpoint.

For the most part the vendors in this space fit into one of these three categories. But what about a hybrid/best of both worlds approach?

I’ve been espousing this tactic for a while so I was especially pleased to see an example of just such a union. In this case it’s between IBM’s Endpoint Manager (mobile device management) and Enterproid’s Divide (virtualization).

Now you don’t have to choose either/or but can do both/and. This way you get the isolation that guards against personal apps stealing business data while keeping the big brothers at corporate HQ from keeping tabs on your Angry Birds addiction. The mobile device controls can be added to the business container/virtual device for finer-grained policy enforcement so that the company gets to insist on your use of that irritatingly long and complicated password to secure their data while you can choose the security policy of your choice for your own personal data, which may or may not be more valuable to you.

For more info on this hybrid approach, take a look at:

http://www-01.ibm.com/software/tivoli/beat/07162013.html

You can download trial versions of the tools and try it out for yourself. I suspect we will see more of this sort of integration moving forward in order to gain back some of the control that corporate IT is losing when BYOD enters the picture.

 

 

 

Advertisement

A zero day jolt from Java

If you’re a security geek, chances are you’ve already heard plenty about the latest “hair on fire” scenario involving Java 7. If not, here’s a very brief discussion of what all the fuss is about…

First of all, Java is a programming language than was designed to allow for execution on a wide variety of platforms without recompiling. Its “write once, run anywhere” value proposition has been compelling in an age where we want to connect all sorts of operating systems and hardware platforms into a unified experience over a worldwide Internet. As a result it has proliferated to the point where it runs on everything from large servers to medium-sized desktops/laptops to small handheld phones.

However, like all software, Java has bugs and, not surprisingly, some of them are security-related. The current fuss involves a type of vulnerability called a “zero day” because it involves a previously unknown weakness for which there was no readily available patch. This means that an attacker could potentially exploit this hole and systems would be defenseless until a fix was developed (in this case, by Oracle, who owns Java) and the fix applied to all vulnerable systems. Sounds scary, right?

Well, it is, but there are some things you can do to lessen the odds you will be victimized, and since some security experts are claiming it could take two years to develop a “real fix” to the problem (as opposed to some more stop gap measures), we had probably think about this problem strategically and settle in for the long haul.

In addition to applying the newly available patch many are advising that Java be disabled in web browsers to lessen the risk. The well-respected US Computer Emergency Response Team (US-CERT) put it this way in their recent alert:

“This and previous Java vulnerabilities have been widely targeted by attackers, and new Java vulnerabilities are likely to be discovered. To defend against this and future Java vulnerabilities, consider disabling Java in web browsers until adequate updates are available. As with any software, unnecessary features should be disabled or removed as appropriate for your environment.”

So, what can you do after applying the latest patch(es)?

• Disable Java in the browser: You can see instructions on how to do this in the US-CERT alert  or in this ZDNet article.
• Remove Java entirely: Some advocate the more drastic option of removing Java entirely from your system. I’m not a fan of this approach, though, because, at least in my experience, there are too many things I need to do that require Java so this really isn’t practical.
• Selectively enable Java in the browser: My personal preference is to use a a Firefox as your browser along with the NoScript extension. This option allows you to turn off client-side functions such as Java, JavaScript, Flash and others by default and then select which trusted sites you’d like to enable these capabilities on. It won’t guarantee safety but it also won’t cripple your system in the interest of security.

Oh, and if you’re responsible for securing your organization against these types of vulnerabilities, it would be worthwhile considering a more holistic, end-to-end approach that would allow you to push patches out automatically to all systems as well as tweak  settings to disable Java (or similar capabilities) temporarily in a way that requires no intervention by end users. IBM Endpoint Manager is one such tool that allows for this sort of centralized management.

Of course, the usual advise regarding avoidance of sketchy web sites and not clicking indiscriminately on links in emails and SMS text messages applies as even the best security tools will eventually be vulnerable to the next zero-day exploit. So rather than looking for a quick fix, think of this as the “new normal” going forward because there will be plenty more similar situations to come…

 

Mobile device security

Here’s an interview I did earlier this week at the IBM Impact Conference in Las Vegas with developerWorks Managing Editor, Tom Young, on the subject of mobile device security.