Enterprise mobile security risks prompt revised mobile protection strategy

Enterprise mobile security risks prompt revised mobile protection strategy

Date: Jun 28, 2011

True security is a complete lockdown of a mobile device, according to security luminary Winn Schwartau. Organizations that have open policies for mobile devices are at increased risk for data loss, because native restrictions, including encryption and policy enforcement, can be turned off or bypassed by cybercriminals, Schwartau said. In this interview, Schwartau explains why security policy should be applied differently to devices that leave the company’s network and why sandboxing, a security feature in Google Android and Apple iOS devices, is no silver bullet.  He also describes some mobile data protection best practices.

In addition, Schwartau said the applications running on the devices pose an increased threat because Apple and Google are not conducting a thorough code review to reduce mobile app coding errors, a possible attack vector for a cybercriminal. Schwartau, who is on the board of directors of Mobile Active Defense, was interviewed on mobile security issues at RSA Conference 2011.


Read the full transcript from this video below: 
Security risks prompt retooling of enterprise mobile security strategy

Rob Westervelt: Hi. I'm Rob Westervelt, the News Director of SearchSecurity.com.
Thanks very much for watching this video. In this edition, we're going to
be talking about mobile security, the introduction of mobile devices and
tablet computers into the enterprise. And joining me is Winn Schwartau.
Winn is Chairman of the Board of Directors at MobileActiveDefense.
Winn, thanks very much for joining us.

Winn Schwartau: I appreciate it. Thanks Rob.

Rob Westervelt: Winn, up until now, how have organizations been dealing with the
introduction of mobile devices and tablet computers into the
enterprise?

Winn Schwartau: The consumerization of the enterprise has been exceedingly fast. And
the adaptation of this technology is probably the fastest
technological growth I've ever seen and I've been in security
almost 30 years at this point. The problem is that you've got
the C-level guys coming top down. You've got the users,
employees, bottom up, all saying, "We want these new cool
devices on our networks." What do we do? The IT guys are
going, "Whoa, whoa, wait a minute!" The security guys are going,
"Whoa, wait!" We have to make sure of how we're going to do
this, in some way that's reasonably organized.

The fundamental problem is that when you have an entire new
network enterprise, the mobile population, coming into the
networks, people are tending to over think it a little bit like,
"What do we do?" Well, the answer is actually fairly simple. Why
should you treat these devices with any degree of difference
than you do your fixed enterprise? Why don't you just say, "This
is the security and compliance that we've got in our enterprise?
We need to migrate and treat our mobile enterprise with at least
the same degree of due diligence." The BlackBerry approach of a
server based, cloud-based enforcement is the right model. That
is the correct one. And when you look at iPhones, the i-devices
and the Android devices, you have to take the same approach.

You cannot load these machines up with all sorts of traditional
security tools and firewalls and antivirus, like we've done with
desktops and laptops. An entirely different approach is needed.
Sandboxing is a failed methodology, will not work. MDM, the
companies that are out there trying to push this as security,
just don't get it. They don't understand really what's going on.
So you take the BlackBerry model and say, "How do I enforce
policy to a true mobile environment?"

Something came up at the Mobile Symposium the other day that was
said. They said, "You need to treat your mobile enterprise and
your fixed enterprise as a single, global policy." And I
absolutely disagree with that. And too many of the vendors out
there are taking that approach. Mobile devices are mobile. They
need to be treated and secured as though they are mobile because
they are physically moving around the world. So why should a
policy, an enforced policy, be the same at the hospital as it is
not at the hospital? Why should it be the same in the US, maybe
in China or some other country? We need to be able to have
completely different policy enforcements based upon the physical
location of the device and start treating these things as
mobile.

Rob Westervelt: You mention sandboxing. We're hearing a whole lot about sandboxing,
especially when it comes to Apple and Google devices. Why
doesn't sandboxing work, in your opinion?

Winn Schwartau: If you can remove or bypass security, it's no longer security.
Sandboxing, you can turn it off. You can avoid it. You can get
around it. MDM, you can turn it off. The user can turn it off.
And true security and compliance is a 100% lock down of the
device, whether it's a fixed device or a mobile device. Some
people are deploying sandboxing because it seems really easy.
And well, we know what happens when you try to do things the
easy way and not do them the correct way. You're going to spend
your money now. You're going to deploy now, and 12 months, 18
months, 24 months down the line you're going to have to undo it
because the bad guys are going to find the ways around
sandboxing because you don't have a locked down, compliant
enterprise. It's failed. It's a failed model.

Rob Westervelt: Has the economy had an effect on mobile security? I know that we're
hearing a lot about how companies are letting their employees
purchase their own devices and bring them into the network. Does
that have any effect on how enterprises are addressing mobile
security?

Winn Schwartau: They already have budgets. These organizations that have the
BlackBerrys, they've already got budgets for this, they're
reallocating some funds. But something I noticed that was
unexpected. Traditionally when you have a new technology that
the enterprise is faced with, there is some period of latency
before you start really dealing with some of the security
issues. In this case, we have seen an incredible adaptation of
hard line budgeting in the last six months, because this
technology is moving so fast and people are starting to become
aware of what the risks really are. So I don't see that. I think
the adaptation of the security and understanding the risk model
is faster than anything I've ever seen.

Rob Westervelt: Let's talk about some of the early technologies that are being used
right now by many enterprises to address mobile security, one of
them being encryption and the other being mobile wipe. Is this
really the starting point? What else is out there, in terms of
technology to address security?

Winn Schwartau: Well number one, the remote wipe technology and the encryption is
native to these devices. There is no magic there. A lot of
vendors are trying to take the native Android and i-device
technology called MDM and say, "That's security." It's not. It
is a very small piece of management of the device. Yeah, you've
got some crypto. But one of the things that you just mentioned
was lost devices. In any real security implementation, fixed or
mobile, you have to have the ability to do detection of hostile
activities, whether its application awareness, you're doing the
equivalent of an IPS or a NAC for applications, hostile
behavior, apps behaving badly. Then you have to have a
remediation mechanism. If you don't have an automatic
remediation mechanism, again, you're back to a failed
methodology. And it has to be comprehensive. You need the
management piece. You need the security piece, and there are
many layers of that that are required. You have to have your
remediation. Once those are all glued together and only at that
point, do you end up with something that will allow compliance.

Rob Westervelt: So what person is actually tasked with all of these duties?

Winn Schwartau: There is no single point . . . it varies from company to company.
In some places, you've got the BlackBerry guy who has suddenly
been assigned, "Hey, you're the i-guy. You're the i-device guy."
Some places, it's the network administrators. In other places
it's the firewall guy. It's the CISO. It's all over the place, depending on
their internal organization. And a lot of the organizations
there is a huge amount of cross pollination amongst all the
various stovepipes and you end up talking to 10 or 12 people,
all trying to come to consensus. In the case of the i-devices,
there is a huge business impetus that has been going on because
of the ease of developing and deploying enterprise applications.

Health care is a perfect example. We have a lot of customers
that are doing . . . let's take visiting nurses, for example.
They need to have doctors' info. They need to have x-ray info,
the radiologists' info, and be able to collect it all in one
place. So they're developing apps for this, that they can use on
the iPads or iPhones. (We want a bigger screen for these.) So
there is the business case alone. They say, "We've got to have
this all centralized and mobile." We see this in the financial
sector. We're seeing it in the government sector that the actual
deployment of the apps is actually easier than what they're
doing with HTML4, HTML5 and some of the OWASP problems that are
coming therein. So if you can create a completely secure shell
around the entire mobile environment, whatever apps they choose
to run, they can treat it as though it's the same internal model
that they've been used to for the last 20 years and not have to
worry about the individual security applications, which is
another reason sandboxing presents so many problems.

Rob Westervelt: When you mentioned apps behaving badly, Google has its marketplace.
Apple has its app store. Aren't these guys vetting the
applications for security?

Winn Schwartau: That is a huge misconception on the part of the industry as a whole.
There is no vetting. There is no code review. In the Apple
store, they look for-and this is not critical of Apple at all-
they look at the marketing material. Does the app do what it's
supposed to do? Does it violate some of our fundamental
development terms? If it meets those criteria, thumbs up. Go
have a ball. In the Android stores, there is no review
whatsoever. It's, "Yeah, go put it up. Have a ball."

The problem is, and this goes back 20-25 years with some of the
early programs in the DOS world, what is inside of the apps?
What is the unknown feature set? What is a potential payload
with what sort of trigger mechanism that would launch that
payload? And what we're seeing is adware, hostile-ware, phone
home-ware, steal credential-ware-We're seeing all of these going
on inside of the numbers of these apps right now. Latest
estimate, 20-23% of the apps in the stores have some level of
infection with no vetting process whatsoever.

Apps behaving badly is... you don't want your app to do anything
other than what it's supposed to do. In order to have it behave
badly, they're going to perhaps do some jail breaking. Perhaps
they're going to try to reach across a sandbox, into another
data pool, grab data. Maybe they're going to try to initiate a
data transfer of some sort, over a particular port. For these
reasons, you need the same kind of controls that you've got in
your fixed enterprise - full firewall control, services
controls, port controls - and be able to detect things that are
out of the norm.

So today there's a set of rules and tomorrow those will be
modified. And they're going to grow as the threat grows and as
the bad guys try to use different techniques, we're all going to
have to be evolving it. But at this point, we have a pretty good
suite of detection tools to solve apps behaving badly.

More on Handheld and Mobile Device Security Best Practices

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: