Mobile threat trends and what to do about them
Webinar transcript - View the full webinar
Jennifer: Good morning, everybody. Thank you for joining us for today's webinar focused on "Mobile threats and trends and what to do about them." A few quick items to get us started.
This will be about a 50‑minute session, followed by Q&A, as put in the Q&A panel. Of course, the A part is only going to be as good as the Q part, so please do go ahead and use the Q&A panel if you have any questions at all. We'll look forward to making this interactive and answering your questions towards the end of the session.
Additionally, at the conclusion of this session, you'll receive a follow‑up email that will include the recording of this presentation, plus a reference and a link to a report that will be referencing.
Your presenters today are James Plouffe, Lead Solutions Architect, and Chris Dobrec, Vice President of Marketing, both from MobileIron. With that, I'm going to turn this over to James to kick it off. James, over to you.
James Plouffe: Thanks, Jennifer. Thanks, everyone, for joining this morning to talk about threats and what you can do about them, and specifically what we're doing here at MobileIron with MobileIron Threat Defense.
The agenda today is to give you a quick overview of the risks that are out there, show you a few real‑world examples, talk a little bit about the approach that MobileIron is taking to address some of these things, as well as some of the differentiators and some of the next steps that you can take in terms of being able to defend yourself against the emerging threats we keep seeing.
When I'm out talking to customers and various folks in my travels and in my job, I sometimes get confronted with the question of whether or not mobile security really is a problem. People frequently point to the Verizon Data Breach Investigations Report which, of course, is one of the most well known sources of breach information out there.
In 2015 and 2016, Verizon went so far as to say that they couldn't attribute any major breaches to mobile and so they considered mobile security, frankly, a non‑issue. Now, in the 2017 report, they stopped short of saying that, but they also didn't go out of their way to point out any particular risks associated with mobile.
What I would argue is it's not so much what you're seeing already, but what you might see in the future. It comes down to a question of how threats and specifically the tools that exploit those threats have evolved.
When we start to see things like the Vault 7, Vault 8 leaks, the Shadow Brokers leaks and things like that, you find a very different scenario that we haven't had in the past.
What I'm really referring to here is the disclosure of nation‑state tools meant for attacking different security systems. While many casual attackers may not have the wherewithal and the resources that nation‑states do, when those nation‑state tools effectively become open‑source, that increases the opportunity for all sorts of attackers.
Certainly one of the things we've seen just as an overall trend is that vulnerabilities are getting more numerous. What you see here is the chart of common vulnerabilities and exposures for both Apple iOS and Google Android. This chart is not intended to spark any kind of debate about which platform is inherently more secure than the other.
It's merely meant to show you that the trend line is moving the wrong direction, which is up and to the right. Certainly as these systems have become more complex, introduced more features, there's more opportunities for bugs, and any given bug could manifest itself as a security vulnerability at any time.
That said, a raw count of CVEs isn't always the best way to look at what your security exposure is, so here's another way of slicing that same data which actually groups the CVEs according to their severity.
What you can see from this chart is that mobile vulnerabilities tend overwhelmingly toward more severe rather than less severe. If you look at the footnote at the bottom of this slide here you can see that the weight of the average Common Vulnerability Scoring System score is 7.4 out of 10.
We're also seeing quite a lot of data that suggests that mobile threats are getting more pervasive. This data here is from our friends over at Zimperium from their "2017 Mobile Security Report." The map on the right‑hand side is the greater New York area.
These are all the different areas that threats were detected using Zimperium's technology, and if you can see in the little bubbles there you can also see the number of threats it detected ‑‑ were detected.
On the left‑hand side, you can see some information about folks who were actually attacked. Nearly a quarter of organizations suffered some form of attack against their mobile fleet. That was primarily driven by malware or malicious WiFi.
There were another 43 percent of folks who may have observed something suspicious but weren't really sure what happened, which is maybe more alarming than knowing definitively, right?
This slide is just a quick sampling of some of the vulnerabilities and malware and exploits that are out there. You can see we've broken these down into a couple of different categories. Device exploits, network attack, and malicious apps.
On the device side, some of the things we crop up last year were things like Chrysaor, which was actually the Android variant of the Pegasus malware that was discovered for iOS. Last year, we saw some interesting things with the Broadpwn exploit, which affected the vulnerabilities in firmware for Broadcom chipsets.
We'll talk a little bit more about Spectre and Meltdown in just a couple of slides. Then, we saw things like Krack and Blueborne. Malicious apps really don't need much of an introduction. They pop up in many, many, many locations and they are always, always coming. There's definitely no shortage of them.
Taking a look specifically at Spectre, Spectre with disclosed officially on the 3rd of January 2018. It actually exploits something called speculative execution in modern processors. The goal of speculative execution, of course, is to improve the performance of those things.
By attacking it cleverly, it actually gives you access to arbitrary memory locations that may not belong to your process. That lets you read data that doesn't belong to you. It circumvents a number of protections that have been put in place to keep applications from reading other applications' memory space.
It's important to point out that this can be exploited in the absence of any particular software vulnerability. It's something that is specific to processor architecture.
Meltdown was also disclosed about the same time as Spectre. There was a couple of researchers working on this. A lot of the research that led to the disclosure of these vulnerabilities goes back to mid‑2016 and before.
Again, Meltdown abuses a similar behavior inside modern processors, so it can be exploited in the absence of a software vulnerability. The last bullet point here is a quote from the actual paper describing the vulnerability.
"It enables an adversary to read memory of other processes by exploiting a race condition. The practical upshot of both Spectre and Meltdown is one, that they don't require a particular software vulnerability to be exploited and they give an attacker access to arbitrary memory locations. This is widely affecting different hardware platforms and it works across OSes."
Obviously, both of these exploits made quite a lot of headlines and a lot of hay earlier this year and continue to plague us a little bit as we work through the patching required to mitigate them.
Another interesting vulnerability from a while back was the Krack attack. It was actually disclosed in late 2016. Also interesting because Krack is a flaw in the way the standard defines the interaction of the protocol versus anyone's individual implementation.
What you have here is essentially a replay attack against a WPA protocol, which allows disclosure of the keying material. Of course, once you have the cryptographic key material, you can decrypt all the data in flight and look at everything.
There are also certain implementations that allowed manipulation of the encryption keys to all zero, which effectively allows the attackers to just turn the encryption off outright. Again, the key point with all three of these vulnerabilities is that, unlike an Apache Strut that burned Equifax or some of the things we've seen historically in things like OpenSSL with Heartbleed.
There wasn't any particular software vulnerability or bug that folks were able to exploit. They were all things that were independent of individual implementations.
In terms of malware, one of the common things that we see is the faking of well‑known apps. One of the popular ones that popped up last year was a fake WhatsApp. The application was named Update WhatsApp Messenger which, of course, we always want to have the latest and greatest.
The company name in the app store was WhatsApp Inc. with a trailing, no break space. If you were to just glance at the app store entry, it would look perfectly legitimate.
Now this turns out to have been a fake version of WhatsApp. It was targeted primarily for adclick fraud which is driving revenue to bogus ad networks. It's important to note that apps like this request certain privileges.
For example, access to your contact list and other things, and can, therefore, become data leakage vectors. While the implications for this particular WhatsApp clone are fairly benign, that just happens to be a chance rather than an actual intent.
We also saw something called BankBot. What was interesting about BankBots was that it imitated other banking apps and used a technique that is fairly common in a lot of malware called tapjacking which basically puts clear overlaid screens on an app. It is the mobile device equivalent of a keyboard logger. Folks wind up surrendering their credentials.
This was primarily an issue outside the United States, but it's the technique that's interesting here to us because this technique of tapjacking and these clear overlay screens and this notion of touch screen logging is a way for attackers to harvest credentials, and it could easily impact anyone in any vertical, irrespective of what the app actually is.
When we look at the types of attacks that we see, we tend to break them down into device attacks. Of course, those are the ultimate targets because they give attackers that person's foothold that they need to perform the malicious activities that they want to perform their objectives.
When start to look at network attacks, these are common because they are often that first point of entry, the delivery vehicle for a lot of different exploits that can help folks get that foothold on the device.
Then we also look at app attacks. Those are typically untargeted. They typically involve things, like fraud, though they also may involve things, like credential harvesting. What they amount to is crimes of opportunity.
The analogy you might think of is inadvertently leaving your car door unlocked as you park on the street. Someone might walk down the street. They'd not break a window but they check the car door to see if it was open. If they found an open door they might dig around a little further to find something more interesting. That's frequently how we think about application attacks.
We'd like to talk a little bit about some specific examples of how these things manifest themselves. We're going to talk a little bit about device configuration changes. We'll talk about some silent device attacks. Then we'll explore network attacks a little bit.
Device configuration changes are interesting from a threat perspective, because they often involve abusing behavior that's staked into the operating system without needing any particular vulnerability. The example we give here is a traveling consultant that is moving in and out of client networks. They may be subject to different firewall restrictions depending whose facility they're at.
They install a free VPN profile that helps them bypass some of those restrictions. What effectively happens there is that the VPN and the app install the configuration and an SSL certificate that could potentially allow an attacker to encrypt and decrypt all the traffic going to and from the device which allows company data to be intercepted and stolen by the hacker.
The other thing that's interesting here is that Syracuse University recently published some research about free VPN apps and found that a number of them actually didn't even bother to do any encryption of any sort. They were effectively taking control of traffic, but they weren't providing any real protection.
This combination of the ability to steer traffic, the ability to potentially intercept traffic that you think is secure or is maybe not ultimately secure, is really what jeopardizes enterprise data.
The silent device attack is a little bit different animal. This is device exploitation that does rely on a software vulnerability but doesn't necessarily involve any user interaction.
The example here would be Stagefright on Android. There was a similar vulnerability in an image rendering library in iOS not that long ago. It basically involves an attacker sending bulk messages with a malicious payload. In this case of Stagefright, we're talking about a text message.
The device itself processes the malicious image without the user ever actually having to open it. Then the exploit is executed. It's allowed the attacker to escalate their privileges and take control of the device. Once they've done that, they can do just about anything that they want.
Again, looking at some of the data from our friends over at Zimperium we found that the device risks out in the field were pretty pervasive.
There were just about 10 percent of customers had vulnerable devices in their fleet. Six percent had high‑risk configurations. Two percent had extreme risk configurations. Just about one percent had malicious profiles with scenarios like we talked about with VPN and the device configuration changes.
One of the other techniques that's available is, of course, network attacks. The WiFi man in the middle is as old as the hills. One of the interesting things about the behavior of mobile devices is that they remember literally every WiFi network that they have ever seen. If you've restored your device from a back‑up, your new device will remember every WiFi network your old device ever saw.
Because these devices are so hungry for connectivity, they will beacon for these WiFi networks all of the time. This is a great opportunity for someone with physical proximity to use something like a WiFi Pineapple to either spoof or intercept traffic, potentially redirect you to a bogus captive portal to harvest credentials or just intercept data over the air.
Again, the net effect is that the attacker's able to intercept and capture data that doesn't belong to them. Looking again at the body of data, network man‑in‑the‑middle attacks were surprisingly popular. 10 percent of the customers were affected with man‑in‑the‑middle attack.
A fairly surprising 3.5 percent were connected to unsecured WiFi, which of course is pretty common. When we're out in the world and we're jammed up for connectivity, we will search for whatever will get us back on the Net.
Then, I think, the last point that we saw less of it is the SSL stripping, which is a component of a man‑in‑the‑middle attack whereby you degrade the encryption and remove it and revert to clear text. There again, an opportunity for folks to observe data that doesn't belong to them.
On the point of app security, there are a lot of applications out there. We showed you a couple that you might be concerned about, but as we know, there are over 5.4 million apps in the top four official app stores. That's quite a lot of stuff to keep track of. Now to the credit of both Google and Apple, they do a pretty good job screening for malware.
They're not infallible, but they also take it very seriously. When malware is found, they're pretty quick to remove it. What's often an issue is the notion of third‑party marketplaces. Folks who search out apps that would normally be some sort of paid app or have in‑app purchases that they prefer not to do.
Consider kids who download games from third‑party app stores to get essentially unlocked versions of them. There are tens of millions more apps in these third‑party marketplaces which don't have any of the protections of the commercial app stores. The point here is that scaling app security can be very difficult.
Certainly, doing it manually is out of the question. You have to figure out how you're going to protect yourself from all of these things. With all that is our backdrop. Now that I've provided all the doom and gloom in the world, I'm going to turn it over to my colleague Chris, to tell us how we might be able to sleep just a little bit better at night.
Chris Dobrec: Thanks, James. Good morning and good afternoon everyone. I appreciate the doom and gloom there, James. Now we're going to talk about how to handle that. We're going to spend several minutes' folks, talking about the MobileIron Threat Defense solution.
We're coming at this from the point of now that you are aware that these various threats exist, imagine if you would and if you could, you could mitigate the risk of your company's data, your customers data should that be at risk, by being proactive and acting ahead of these mobile threats and not being put in a position where you have to clean up after an attack.
What if you could gain visibility into the potential threats and attacks and make informed and timely decisions to remediate or not, as the case may be.
Again, or if you're in a position where you have to respond to compliance and regulatory security guidelines, and provide reports to management and regulatory bodies in mandates and such, imagine if you could be able to do that through MobileIron.
Finally, imagine if you could handle all this but still at the same time, reassure your users' privacy so that it's not been invaded by the same time those devices are not being entry points for the next major attack.
What I want to do now is talk to you a little bit about the unique approach that we are bringing to the market here. The MobileIron Threat Defense solution that we've introduced recently is really rather clever.
We've taken the base mobile and platform comprised of the back‑end MobileIron Core or MobileIron Cloud in the client side, the EMM agent be it Mobile@Work and MobileIron Go. What we've done is we've actually integrated these capabilities into the EMM client itself. There's no need to deploy the separate app to enact the MobileIron Threat Defense.
We can take advantage of the fact that the EMM agent is resident on the device and it has the additional threat defense capabilities and have that work in conjunction with local compliance actions, for example, that are delivered via EMM.
That also works in conjunction with a management console that gives additional capabilities and dashboard forensic reports and overall administration of the solution. The single integrated client combined with the threat engine in our advanced apps and [inaudible 23:39] its capability are what comprise the overall solution here.
James had talked quite extensively at a high level about the device configuration change problems. I just wanted to go a step further and illustrate what happens here.
Going back to the scenario where a contractor is working in your environment and they've installed a free VPN and that free VPN may be a "Malicious app" that installs, for example, and then traps its SSL so that enables the attacker to encrypt or decrypt traffic and redirect it to their site so they can gather intelligence, they can gather confidential info, they can carry out more exploits in the future.
With the MobileIron Threat Defense solution, we can actually detect that and block it at the time that the free app was installed. The combination of our Threat Defense capabilities along with EMM allows us to recognize that and block it at that particular time.
If you look at the silent device attack test scenario that James had described, Stagefright being the example. That was delivered by a SMS, but imagine that a mass amount of SMS [inaudible 24:48] get sent out.
One of your users is inadvertently sitting there and responds to that and clicks on a link and installs malware on the device, which raises the privilege of the malware on that device. Unfortunately, device is now compromised.
In that regard, hacker has access to all kinds of sensitive data on the device, whether it's the contacts, the phone numbers, any other data there. Probably the more interesting thing is when once that exploit is there, it can remain persistent and effectively is a silent weapon that can be used later on as they as the hacker comes back.
Once again, if you've got MobileIron in place and the MobileIron Threat Defense solution, the attack would have been detected and blocked at the time of the privilege elevation in order to minimize that damage and prevent that from being a silent weapon for future exploitation.
As James had indicated, we see the entry point being network attacks. The proverbial WiFi man‑in‑the‑middle as again, James said, is older than the hills, but this is absolutely the entry point where people come in to attack these devices.
I'm sure you all have users that connect to public WiFi. It's not uncommon for folks to be sitting in the coffee shop with a rogue access point, a pineapple device or such, and basically connect to the employee's device, intercept those communications in the corporate network, harvest username and password information, any other confidential data.
The hacker can even intercept the communication between the employee's device from the hotspot and downgrade the connection from HTTPS to HTTP and then start reading that data. This is definitely a threat that we see.
If with MobileIron and a MobileIron Threat Defense in place, we can actually recognize that and block it at the time the device attempts to connect to that network. We've highlighted just a few interesting use cases here, but the combination of EMM plus MobileIron Threat Defense is really a very powerful solution to help mitigate these particular scenarios.
What's actually different here? What are we doing unique in the marketplace? This is where I want to spend a few moments with you talking about that.
In a typical situation where Mobile Threat Defense is utilized. This is not uncommon with MobileIron and in other third‑party application. Typically, what happens is the Mobile Threat Defense separate app will scan the device.
It will take the data off the device and put it up to a cloud service because they're not doing detection on the device necessarily. The cloud does the detection for unknown threats using whatever deterministic approach is available from that particular vendor.
Then when something is detected, it goes to the cloud‑based console, they notice the problem. It will look at a threat matrix and then it will come back down and connect to something like an EMM, like a MobileIron or other to actually do the remediation.
There's three challenges with this particular approach. First and foremost is delay. Remember when these threats are enacted, it's really a race against the hacker here. Any delay that's involved can be problematic and particularly in the case where you're worried about X for traded data.
That has implications in terms of sensitive data like location, the private side of the device. For those of you who have or subject to GDPR regulation because you're doing business in Europe, for example, this is going to be a problem for you.
The third problem is in a threat situation the man‑in‑the‑middle attack, they could actually cut off access to the network and you can't even perform two, three, four, and five. In that case, the damage is really, really significant.
How we've approached this problem we've said, "You know what? We are going to do this differently. We are going to look to detect the known and unknown threats, DNA, Device, Network, and Application and do that on device, so we can remediate immediately and not lose that race with the hacker."
We think this is a very unique approach to the market and will be anxious to work with you guys on how to get that deployed in your network.
In the end, there are just some differentiators that I wanted discuss with you and reinforce and to summarize our approach. It starts with a single application. The base capability is integrated into Mobile@Work or MobileIron Go so you don't have to deploy a separate app.
Another very important feature here is by deploying in this manner, there's no need for the user to actually be involved in activating the solution. In some other solutions that are out there today, not only do you have to deploy a separate application, but the user have to be involved in activating that app.
In the case of the user not know what's going on, they can actually swipe the app off and take it out of memory preventing the threat defense solution from running. By integrating into the Mobile@Work plan, it's always resident and running in the background.
The method that we've taken has the ability to address zero‑day threat. We know them as they come about and make them available for remediation on the device. We think it's a very unique approach in the market.
With that backdrop as to what we do? Let's talk about your strategies now. We know you have choices and options in how to deploy threats. It depends should you choose to deploy.
What I wanted to do is focus now on what are the key things that you need to think about here? It really comes down to some very important points. If you do nothing at all, the risk of losing critical business data is very high. There are instances where companies have been breached via these on‑ramps and taken a big damage to their overall reputation.
Remember the Target breach not too long ago as well as Expedia, right? Not only did they lose data, but they also damaged their company reputation. There's going to be a commensurate loss of revenue associated with that.
For those of you, again, who are dealing with business in Europe and are going to be subject to the upcoming GDPR regulations that'll be implemented in May, you risk regulatory fines that are actually rather punitive. Doing nothing here can put your business at risk from there. Then it shoots the overall loss of resources and whatnot in terms of data, money, and time.
With that in mind, what we want to reinforce is the benefit of the solution that we're bringing to the table here. It comes down to the following. We're making it very easy to be able to deploy the solution, to detect it and remediate on device with no user action, one single app. You've already deployed Mobile@Work or MobileIron Go on your user's devices.
Having that capability there doesn't require you to deploy another app and then ask the user to do something else. In terms of insight, we're providing quite a bit of visibility into what's going on.
I kindly encourage you to contact your MobileIron representative to begin to explore the solution, because if nothing else, you can look at installing MobileIron Threat Defense and get an idea of what's going on in your network. Then, as you begin to gather this data, you'll be able to see the value of the tool, overall.
Finally, how we executed the technology would be ability to remediate on device is a fantastic solution. With that being said, the product is available for iOS and Android, working with core and cloud respectively.
It's focused on building on top of all the protections that you already delivered with your EMM deployment and focusing on the device, and network, and application threats that are external. One of the things I wanted to leave you with is if you think about how you use EMM today, EMM is a fantastic solution for addressing the known actor, meaning your users that are using your services.
With the addition of MobileIron Threat Defense, we can actually address the unknown users, those threats that are coming externally to those network devices or to the device by the network, I should say, additional exploits on the devices, themselves, and the apps, themselves.
Really exciting, this solution that we're excited to share with you here today. As I wrap today's session, I did want to remind you, all, that coming up this beginning in May, we're going to be hosting MobileIron Live. MobileIron Live is going to be a little bit different for you, guys, this year.
For those of you who have attended in the past ‑‑ you'd come out to California, and we'd hosted one large event ‑‑ this year, we're actually bringing it to you. We're doing three events in the East in New York City, in the South in Austin, and in the West in Los Angeles.
The goal here is to make it more convenient for you to be able to come and meet your peers and talk to other MobileIron experts as you've come to expect from the past. A little bit of a different twist and really looking forward to seeing you, all, at MobileIron Live coming up beginning in May and into June.
With that, I thank you very much. That concludes today's prepared remarks for this session. We'll stay on here and continue to answer questions in the Q&A box. Thank you.