In the era of the cloud, enterprises house sensitive corporate data outside of the traditional perimeter; employees can access this from any endpoint, including mobile devices, and from any network. This presents a host of new challenges for companies looking to protect their sensitive information.
On this webinar replay, Threatpost’s Tara Seals is joined by Gartner’s Patrick Hevesi, Lookout’s David Richardson, and Google/Android’s Mike Burr to talk about practical strategies for locking down this work-from-anywhere environment, for both the Android and iOS ecosystems.
Hevesi presents a working, vendor-agnostic framework for evaluating risk and determining solution approaches, while Richardson discusses real-world threats and the most common attack vectors that enterprises need to defend against. Burr meanwhile talks about specific aspects of the Android Enterprise ecosystem that organizations can leverage to manage their devices for security.
And finally, a Q&A covers user awareness, two-factor authentication, APT threats, mobile VPNs and more.
** Below is the transcription of this webinar, in its entirety. **
Tara Seals: Hello, everyone. Thank you for attending today’s Threatpost webinar, titled Enterprise Mobility and Post-Perimeter Security: Inside the Evolving Mobile Enterprise Threat Landscape.
Let me introduce myself. I’m Tara Seals, senior editor at Threatpost. I’ll be your moderator today. I’m excited to welcome our panelists. We have a really great set of thought leaders today who are going to give a comprehensive dive into the developing area of mobile enterprise security. There are a lot of challenges in the space, as we know, and it’s proving difficult to address them with a legacy security model. We’ll talk a little bit about the top challenges, some best practices for adjusting to them, and thoughts for the future, what might be coming down the pike.
Today we’re going to hear first from Patrick Hevesi, who is senior director analyst at Gartner. He’s going to frame our discussion by talking about some of the top mobile enterprise security challenges. He’s also going to offer a pretty interesting framework for [helping] administrators to decide how to address them.
Next up, we’re going to hear from David Richardson, who is senior director of product management of Lookout. He’s going to discuss what they’ve been seeing in terms of their telemetry and threat intelligence, and talk about some specific threats, real campaigns and also some best practices for defending against those.
Finally, we’ll hear from Mike Burr, who is the platform specialist for Android Enterprise at Google. He’s going to address some perceived threats to the Android ecosystem, along with some of the best practices for managing Android devices within in the enterprise.
We have a lot to get through, so I’m going to turn it right over to Patrick to get us started. Patrick, over to you.
Gartner’s Patrick Hevesi, Senior Director Analyst
Patrick Hevesi: Hello. Thank you. Can everybody hear me? Yes. Thank you, Tara. Let’s start with talking about what mobile attack vectors look like. In IT, we’ve been accustomed to defending our desktops, PCs and our servers for many, many years, but the mobile attack vectors are slightly different.
See, now we’re just not thinking about these websites that people are clicking on their phones, they’re installing applications from app stores, they’re getting SMS text messages with possible tiny URL links from colleagues or hackers or different sources throughout, and then possibly clicking on them and actually being led to web pages or possible other downloads.
Then you walk into a Starbucks, you walk into an airport café. Are you really on that WiFi? How do you know for sure that you’ve connected to a safe and secure thing?
Government organizations care about things like, are you on the right cellular tower? Is someone trying to listen in and trying to intercept your call, intercept that actual voice traffic and possibly do something malicious? Then, of course, possibly somebody comes in and tries to do a Bluetooth-based or a near-field communication attack. That’s very proximity-based.
Let’s say the device then becomes infected through one of these means and then you come into your organization. You join the VPN, you get onto the corporate WiFi. You plug that device through USB into your PC or your Mac. The hackers are trying to listen for those different aspects to possibly come into your organization as well.
Thinking about these new attack surfaces, how do you actually start trying to address these? What are some of the different threats out there? You’ll hear from our colleagues about some other examples, but we’re starting to see that there are these different malwares and vulnerabilities that are approaching. This is just a short, small list of what we’ve seen, with some historical ramifications as well.
In 2017, we started seeing ransomware on Android. One example was a ransomware that was actually targeting based upon the geographic location of that device. If you were in the United States, it would pop up an FBI warning saying that you need to call the FBI right now because you’re doing something malicious. If you actually did call in, they would ask for Bitcoin. Obviously, the [real] FBI wouldn’t do something like that. But that same ransomware was then used in Canada. They looked at the phones in Canada and a Royal Canadian Mounted Police ransomware screen popped up as well.
[Other threats run the gamut from] kernel privilege-escalation attempts to possibly even opening up SOCKS backdoors inside and looking for proxies as they come onto your network.
And not just on Android, but on iOS. Here are some examples. One of the bigger ones that happened a few years ago was the Pegasus/Trident [incident]. It was actually a Safari-based exploit, a low-level exploit. The attackers were able to send an SMS message to that device, you clicked it, it would start the Safari browser on iOS and then immediately crash.
What would the end user do? What would you have done when that happened? What happened in the background was that exploit found a targeted vulnerability inside the device, actually then installed surveillance software without you knowing anything was happening. We saw people just click that link again, trying to get to that link yet again and again. By that time, that low-level escalation was already done, that everything that was then typed on that device was then being transmitted to malicious sites.
Not only are they attacking the devices, but years ago, there were some Chinese attacks based on the Xcode developer platform, where they actually installed and built a maliciously infected Xcode developer set of tools and they were delivering it to developers all over China rather than coming all the way back to the Apple site. They were actually pushing those out to local developers, and those local developers, and everything written with those XcodeGhost-infected platforms, had malware, over 4,000 apps.
There are malicious profile attacks as well, so thinking about iOS, as you install a management profile. There are also configuration profiles. But you could see here there are many different ways that these different attacks can be leveraged.
What do we do about that? At Gartner, we came up with a mobile security strategy, and there’s some prework that has to be done. You have to start considering what type of data is actually being installed on the devices. Different levels of data will require different types of tools and technologies and security solutions. Higher-secured data won’t require additional security practices, tools, configurations, obviously.
Then you’ll also have to look at possible business requirements: You may have specific mobile applications that only run on a specific platform — as well [as] carrier.
Then we’ll quickly talk about mobile education. Many of you, I’m sure, are already doing phishing training for your employees, but we’ll talk about how it becomes critical for you to also do mobile security awareness. Then as we go through this, as we go through the strategy, we talk about these different areas.
Since we only have a short time, we’ll talk about some of the key areas. How do you define the right minimum OS and hardware versions? We’ll talk about mobile threat defenses, a new set of tools that will come out that will give you advanced mobile security above and beyond what the operating systems might have. That gets into application security, network security, device protection security as well. Then we’ll give you an example of how all this looks together.
Now let’s look at this example. There are many out there. I just picked one that comes up a lot. This is a flashlight app in the Android marketplace. There’s examples of this all throughout both iOS and Android. This flashlight app is yearly updated. You could see here it’s a 4.6 rated, 200,000 reviews on this device. This is a flashlight app.
We all know that all of our mobile devices today, any modern mobile device today, has a flash. It has a flash. You turn it on right inside the operating system. But this particular author has created some variety of lighting. It does SOS, it does music, it does all these different fancy things. But let’s look at what this particular application has access to after you install it. I’m going to read this for those of you that might not be able to see it: “Updates to flashlight may automatically add any additional capabilities within that list on the right.”
Can any of you tell me why a flashlight app needs anything more than access to the flash? You could see here on the right, this app could … It doesn’t mean it’s turned on by default, but could, at anytime, ask for and turn on access to your phone, access to your file system, access to the WiFi, to your pictures, to your video.
Most of our employees today will just install this because it’s got a high set of ratings, it’s downloaded by everybody out there. Think about this as you train your employees. Why does that app need that privilege? Is it actually coming from the real source as well? Does something need GPS access? Does something need access to each of these individual things?
Now there’s nothing malicious about this particular app at this point in time. Google scanned it through their Play Protect, and this particular author hasn’t done anything malicious with it. But this is something that you have to start considering as you train your employees. They need to be aware. They need to think about what they’re installing on that device because it could, at some point in time, later have possible ramifications for your enterprise.
Now we do a year-over-year comparison as we look at the different mobile operating systems. We’re in the process of doing the 2019 update, but here’s the current one. The 2019 update will come out later [in March].
But you need to start thinking about starting with a core-based operating system and a core set of hardware that meets a minimum bar. Think about the devices that you allow onto your network today. If it’s below 6.0 or, in its current monthly Android security patch, the January 2018 security patch actually has the Spectre and Meltdown fixes. You shouldn’t allow anything underneath 6.0 and at least this year’s January patch.
You could see here on the right, there’s some additional recommendations on hardware as well. Mike will talk a little bit more about this in his section, but Google has taken their Pixel devices, added some additional capabilities above and beyond their common definition requirements, and added additional security.
Samsung Knox has government-grade security, BlackBerry Android, and the Google Android Enterprise-recommended program is pushing the bar and adding additional hardware-based, software-based higher requirements to meet enterprise security standards.
On iOS, [you want] 11.2 because that’s where their Specter and Meltdown fixes are. With the iPhone 5S, and you can see the iPad Air equivalents, that’s when they added their hardware-based security called the Secure Enclave, where they start storing keys into that, that helps with some of the kernel-mode protections as well.
Then as you’re looking at Windows, like a Surface tablet, kind of bring-your-own-device, we’re recommending Windows 10 Fall Creators in the past, which is 1709, and obviously the current Windows updates as well.
These are the devices that, at a minimum, should be your requirements for all BYOD and corporate-managed devices coming into your organization.
After you set the baseline, what do we need to look at for possible higher sets of security practices above and beyond that? A few years ago, mobile threat defense (MTD) vendors came out with this additional layer of security. Your employees want to install an MTD agent onto the device, it will provide application layer of protection.
What they’ve done is gone out and done static and dynamic analysis of the mobile applications, looked at those above and beyond, looked at when some authors are trying to update or make changes out-of-band through web service connections. They look to ensure to see if you’re on that right WiFi. Obviously, as attackers are trying to do Pineapple-based attacks or trying to spoof WiFi in your local coffee shop or your airport, there are certain indications that could possibly be detected.
Then what happens if an application installs through a side-load and then tries to instantiate a VPN? Why does that application need it? That’s behavioral anomaly detection. This agent then communicates with the back-end cloud service and then you can manage it that way.
This is great for bring-your-own-device scenarios, MTD or what they call standalone mode. This doesn’t prompt the user to say, “I have to accept this,” and then, like traditional EMM [enterprise mobility management], would require full control, full access so that you could delete data and everything else like that. MTD and standalone doesn’t prompt that user to do that. It’s giving them the power and the ability to secure their device, both from a personal side as well as from an enterprise side.
Now once you do add from a managed perspective the full unified endpoint management [UEM] or EMM or MDM [multi-device management] solution to it, these controls are more around configuration, policy management, device management. MTD is the security solution. EMM, UEM, MDM is really more the management solution. But what the MTD vendors have done is, they’ve actually integrated with that.
For your managed devices, you can install the MTD, integrate it with your back-end, and then once a threat is detected on the device, since you have that back channel, that integration, you could actually create a policy that says, “Oh, I see a malicious device,” or, “something’s going wrong on that.” “Someone’s trying to do a man-in-the-middle attack. Go ahead and force a VPN or require an uninstall of that application,” because you have that management channel.
Now there are a lot of different things going on here. But in the beginning, it’s really important to make sure you set that minimum platform level that we discussed and start thinking about mobile threat defense as that agent. You deploy endpoints today and you’ll always deploy some kind of endpoint protection platform or an EDR or some kind of [anti-malware] on it. It’s starting to become to the same level on mobile devices needing to have this additional more advanced security practice. Just think about it. You’re using your mobile device first, 80% to 90% of the day. The hackers are also realizing that as well.
There are some other capabilities for some organizations that we see: If you have line-of-business applications, actually adding mobile application security where you’re actually doing hardening or locking it down or scanning for certain types of APIs and secure coding practices inside the line-of-business applications.
Then from a management perspective, bringing that UEM, EMM, MDM on there to give you that configuration, management and control aspect. But then in the end, that training, that education becomes so critical. People are aware of what they need to do for emails, but even email phishing goes through.
But think about all the different things they do on their device today. That device has corporate data as well as personal data. As you reach out through the education programs inside your organizations, talk about it that way. You’re not only helping them to be more secure because their banking data is on there, you’re also helping them be more secure with the enterprise data that’s on those devices as well.
The culmination of this Gartner security strategy that we built looks like this: These are some examples of how you can actually start. It goes back to that first part of the discussion that I was talking about. Depending upon the level of data that’s on that device, you may have more requirements.
As we talk to clients all the time, everyone’s saying, “My CEO wants that latest and greatest device.” Well, it depends on what that CEO needs on that device, if he needs corporate-sensitive, very critical data, you can give him a table like this and say, “Fine. If you need that sensitive data, here’s the security requirement.”
You’re not saying, no, he can’t have that greatest, latest, large screen, foldable screen phone that just came out, but you’re giving him some prescriptive guidance on what … If he just wants email, calendar, contacts, some low-sensitive data, you can look at the bottom line and get him quickly on board, giving access to his email, but still protecting your corporate resources.
This menu that you build allows to handle BYOD to fully manage and everything in between. These are recommendations…You can change, obviously, the data classifications, but looking at the operating system separate from the EMM, are you possibly looking at containers? Do you need to have a container for separating the personal data from the corporate data? Device-level, app-level or container-level VPNs? Are you looking at mobile threat defense, looking at hardening those corporate applications?
The other thing that quickly we touched on in a quick survey: Device authentication versus the corporate container authentication. I talked to a CSO recently, and his CIO took his corporate-owned iPad device home and registered his entire family’s fingerprints on that device. That iPad, in this particular case, became that family-use thing, but it had corporate data on it.
This is not just an iPad thing, but anything that has biometrics — there’s no way to really detect that. Thinking about the personal side, device authentication should be different than having to get into the corporate container. That container application, having separate authentication methods so you can make sure that at least that device is not just getting unlocked [and offering] seamless access into your corporate information.
Of course, encryption both at a device-level and a file-level. Then as you start getting into higher sensitive data and use cases, possibly even looking at doing full voice, LTE, SMS and data end-to-end encryption for your mobile strategy.
With that, quickly just running through some of the different recommendations. We all need to start looking at the risk and the tactics that are being [used]. You have people that are looking at threats today for your endpoints and your servers. You need to start thinking about looking at the endpoints and the mobile devices in that same threat-hunting [effort].
Setting that minimum OS, and you could see here for BYOD, obviously you might not have full control of the EMM, but trying to verify what actually is installing. Google, Apple, Microsoft have done a good job about vetting the applications that go into their app stores, but the ones that are going into those third-party app stores where the process of vetting applications is not as good becomes important.
Looking at mobile threat defenses solutions and then adaptive access-based state of control, so thinking about if that MTD detects that device as a high risk, removing it from having access to your cloud and your corporate information, through a manual process. Then, deliver training.
Now the only quick change between that and corporate-managed is once you have the EMM on there, you could actually enforce which applications are being installed and from what sources. Then,, with the mobile threat defense looking at that integration between MTD and EMM it gives you complete control of the security and the management of that device.
With that, I will pass it over to David Richardson.
Lookout’s David Richardson, Senior Director, Product Management
David Richardson: Thank you, Patrick. That was very informative. I’m going to follow up on some of those items and go a little bit deeper into a couple of specific threats. But first let me get started by just explaining a little bit of what’s changed in the landscape in the last couple of years that’s brought us to this point of post-perimeter security.
Your data no longer resides within your four walls, within your own data center. Your data is in the cloud. It is no longer within your physical perimeter, but it’s also no longer within your digital perimeter of firewalls, secure web gateways, access gateways, things like that. This data is up there in the cloud and you fetch it directly from cloud service providers.
Your users have gone mobile at the same time, and so these mobile devices can connect to any network and they can access that data that’s in the cloud from anywhere. Essentially, your corporate network is now the Starbucks WiFi, any hotel WiFi or home WiFi anywhere in the world. These are how your employees are getting work done. They’re connecting to these networks.
Essentially, your perimeter has disappeared. All the controls that you previously built into your network, your VPN, your physical infrastructure, they no longer apply in this new world of mobile plus cloud-delivered software.
In this new perimeter of this world, there’s a couple of things that you need to think about how to do differently. One, you can’t trust the devices accessing your data. Just because the device is able to enter in a username and password and get on your network or try to access the cloud service doesn’t mean that this device should be trustworthy.
Furthermore, bad actors know that users are no longer being protected by your perimeter, so they know which devices to target. They know to target your mobile devices for a variety of reasons. To make things even more complicated, end users are increasingly demanding privacy, free from inspection of their content on their mobile devices. No matter how locked down a corporate device you issue to someone, every single mobile device is inherently a mix of personal and corporate.
There are various percentages depending on how you lock it down, but if you think about it, your mobile device, even if it’s fully corporate device, it knows where you are 24/7. That’s personal data. Your camera roll is most likely a mix of personal data, photos of your family and work data, photos of sensitive whiteboards with IP information on them. These devices are inherently a blend of personal and corporate, and so your traditional security approaches don’t apply.
In this new perimeter of this world, you need to do things a little bit differently. You need to move some of the critical perimeter security services that you used to rely on to the endpoint or to an identity and access management solution or to the cloud service providers directly.
Your access to your data must be based on a continuous assessment of trust, from an assumption of zero trust. Just because a device has the right user name and password doesn’t mean that that’s a device that complies with your corporate policies and should be allowed to access that data. You need to basically assume that all devices should be untrusted by default until you confirm that that device is trustworthy.
There are really three pillars to the way that we look at post-perimeter security, at least here at Lookout. In post-perimeter security, you may have also heard other terms like zero trust or BeyondCorp. These are all very similar concepts. Post-perimeter security is about enabling those types of architectures.
Basically, there’s three main components that you need to think about here. There’s the endpoint itself, whether that’s a mobile endpoint or an IoT [internet of things] device or a traditional desktop endpoint. There are the cloud services that it accesses, and there is the identity solution that allows you to identify who is who.
Those services all need to be in communication with each other through a system called continuous conditional access. They need to all be able to share data with one another about the current health status of this endpoint, this identity associated with accessing this data, and the data itself from the cloud service provider’s perspective. They need to be able to determine whether or not this endpoint with this identity should be able to access that cloud resource.
The continuous part here is crucial. If something changes to the risk posture of this device or the identity or the resource that you’re trying to reach out to, you need to be able to cut off access in real time. You need to not just not allow the user to login the next time that they’re trying to access something from an insecure device. You need to actually cut them off in real time.
Here at Lookout, we’re a mobile threat defense vendor, so we focus mostly on the mobile endpoints. I’m going to talk about the mobile endpoint for a second and some of the threats that we’re seeing there.
First of all, why target mobile? Patrick covered a lot of this already, but if you think about it, if you could only have one device that belongs to someone, the mobile device would be the perfect device for you to have because it’s always connected to the internet. It’s got microphones, it’s got cameras, it’s got corporate data on it, it’s got your location, it’s got your passwords and your multifactor authentication token. If you could just compromise one device, this is the perfect one to do it.
If you think about protecting my devices with multifactor authentication, this is the one device where someone is going to type in their user name, their password and their multifactor authentication token all from the same device. If you could just watch what was going on in that one device, you would have all the keys that you need to compromise that user and access any data that they have access to.
At Lookout, we were thinking about, as you enable more productivity for mobile devices, what are the risks that you need to be aware of, so we created something called the mobile risk matrix. I’m not going to walk through this square by square here, but at a high level, you need to think about the four various vectors, the apps that are on those devices, the device itself, the OS version, the way it’s configured, the hardware manufacturer, et cetera, the security pass level, the networks that that device connects to, whether that’d be WiFi, cellular, VPN, NAT or proxy, et cetera, and the web and content that device consumes.
Then across each of these vectors, we need to be worried about three different components of risk. We need to be worried about threats. Obviously, we need to be worried about malware or rooted and jailbroken devices, man-in-the-middle attacks, phishing sites, et cetera. But you also need to be worried about software vulnerabilities that are introduced by out-of-date applications, out-of-date operating systems, vulnerable SDKs, things like that. You need to be worried about the behavior and configuration of each of these things and how they relate to your corporate policies.
Here you see apps that are collecting way too much data, that flashlight app that is harvesting all this data from your device potentially, or one that’s over-permissioned that you need to worry about there, or devices that are configured in an insecure manner such as the sharing of passcodes or having no passcode, or allowing installation from third-party app stores.
I wanted to dive into just a couple of threat examples in a few of those boxes there and cover some interesting trends that we’re seeing. One trend that we’re seeing is, we’re actually seeing phishing sites that are exclusively targeting mobile, that are built to target mobile.
Here is an example of the WhatsApp campaign that we’ve seen spreading around. This is just one variant of it. But basically your WhatsApp account … someone in your address book will get compromised and they would send you this message that would come from a trusted source. You would know the sender.
It would look like a pretty compelling, normal link. If you click on that link on a mobile device, you would get a phishing page. If you would click on that link on a non-mobile device, you would actually get the real website that it was trying to point you to. This is a case where the attacker has actually decided, “I want to only target the mobile users.”
This technique actually allows these types of sites to go undetected for longer because many of the tools that are trying to detect phishing sites are being fooled by this simple thing of redirecting them to the real site in that case.
Here if you just look very closely, you might have noticed it, but there’s a tiny dot underneath this ‘A’. That is called a homoglyph attack where basically it looks the same to the naked eye as the real URL, but to a computer, that’s a completely different unicode character, and [the URL] sends you to a completely different server. We’ve seen a lot of attacks like that coming up.
We’ve also seen a lot of mobile malware-as-a-service campaigns, so attacks where you can actually essentially just buy malware that will target a specific account type. That malware will be high-quality and it will be branded to look exactly like the real thing.
This threat, BancaMarStealer, the way that it works is it looks at what app is running in the foreground on your device and it presents a popup on top of that application when the target app is running. You open your Capital One app and suddenly a second app creates a popup on top of it that looks exactly like a Capital One login page. Users are easily tricked by that to type in their username and password. They click ‘Sign In’ and they go back into the Capital One app like where they were, before not realizing that they were just phished in that process.
Then another interesting trend is proxy malware that we’re seeing. We’re seeing malware that will actually open up SOCKS proxies on devices that get infected and allow attackers to have access to any of the networks that that device can connect to. You might have someone who downloads malware at home in their free time and then they go and they connect their device to a work network. Now the owner of this proxy malware will sell to the highest bidder access into that corporate network and access into that device that’s associated with that corporate network.
I just want to leave you with two thoughts here again about what you need to do as a result of this. You need to think about your long-term strategy as it relates to the perimeter around your data crumbling, and figure out where you need to move these critical perimeter services.
Our recommendation is that a lot of these need to move to the endpoint, but there are other places that they can move to, such as the identity and access management solution and the cloud provider as well. A combination of those is the best approach. You need to stop assuming that you should trust your devices by default. With that, I’m going to hand things off to my colleague Mike here.
Google’s Mike Burr, Platform Specialist, Android Enterprise
Mike Burr: Great. Thanks, David and Patrick. Let’s see here. Pop this in. All right. Well, thanks again, everyone, for allowing me the opportunity to join today. I think to set the stage, I want to talk first about a couple of things. Then we’ll jump into some of what I see and what we see here at Google, particularly on the Android team, what we see as far as what we call misperceptions. Then also one of the bigger things is around, how do we manage Android devices efficiently.
One of the first things that we like to talk about is obviously that there are a lot of Android devices on the planet. On a rolling 30-day schedule, we see roughly 2.3 billion Android devices checking into Google Play services. Those are obviously devices that have Google services. There could be more.
The other part of the ecosystem is [IoT] — most people think that Android is just for smartphones and potentially tablets. But I think what we’re seeing over the last few years, due to some things like Windows Mobile going out of favor and being deprecated by Microsoft, is that Android’s actually landing on a lot of other pieces of hardware. There are a ton of these devices out there.
The good news is that we have a way to manage these. We’ve removed that management fragmentation and done a lot of things over the past several years to help secure those devices and deploy them and manage them in a very secure way.
One of the areas that I like to get into in the beginning [of these discussions] is what we call misperceptions. Really it all started when, a couple of years back, I think people just stopped looking at Android as a viable enterprise platform for various reasons. However, over the last couple of years, we’ve done a lot in the ecosystem and in asking our ecosystem partners to make these things — these Android devices and the platform and everything that runs on them — secure.
I think one of the couple of areas [where there are misconceptions] is the idea that the updates are slow. That’s a misperception in the modern Android world.
People also think and customers also think that a vulnerability equals an exploit. That is not true. A vulnerability is a chance and an exploit is writing code and getting it onto a device to exploit that chance. I think there’s a big delineation there to make — understanding that just because there’s a chance doesn’t mean anything is going to happen. In fact, history shows us that in those things with the major issues, things really never come to fruition as far as the vulnerability being exploited en masse in the wild.
The second piece is around harmful apps (here at Google we call those potentially harmful apps), and the perception that Google Play is full of malware. We’ve actually done a very good job, and the ecosystem helps us with that as well. We’ll jump into a few things here to move forward.
As far as Android patching goes, this is pretty impressive. I think this is a good key indicator that the devices are getting patched very regularly. We introduced something called Project Treble a year or two ago, which actually helps the ecosystem software and chip manufacturers, OEMs and carriers get updates out faster. It injects a harder extraction layer that makes developing these updates much faster.
In 2018, we actually saw just over a billion devices getting regular updates, and I mean within 90 days of Google releasing those 30-day patches. That totaled 84 percent of devices at the end of last year. Quarter-over-quarter, we’re getting updates more regularly than a year ago. We are seeing this trend change, primarily because we’re driving the ecosystem, mainly OEMs and carriers, to accept those security updates and we’re making it easier for them to do so.
Again, back to the story of where vulnerability doesn’t necessarily mean an exploit. I’m not saying that they’re not there. However, the various of layers of the Android operating system, including the hardware, actually made a lot of, or introduced a lot of, technical best practices in the operating system and the platform that mitigate (even when an exploit does get onto a device), what it can actually get to.
In fact, if you really think about the whole broad picture of Android security, the concept now is that getting a true piece of malware on a managed Android device is pretty rare. Then if it does get on there, does it really get to your credit-card data? Does it really get to critical information or maybe it gets your contacts?
Again, the risk posture there depends on what vertical you’re in and what kind of things you’re doing, but the idea here is that we have so many techniques outside the scope of this discussion that you can actually see used in modern Android. It all starts with secure hardware.
Some of the things that you’re seeing on this screen, I won’t go through them in great detail. However, some of the things we’ve asked and actually mandated that the OEM and carrier ecosystem do, is start building secure hardware into the devices. In fact, in Oreo, it is mandated that devices come out of the box with a secure hardware component.
Even if the device is compromised, you can still very strongly attest that the integrity of the device is preserved. With these particular components here, again this helps with deploying devices in enterprise because all of these things help you prevent allowing bad actors and even malware from taking data off of a device.
Finally, on the PHA side, we at Google call PHAs “potentially harmful applications,” but it’s really important to understand that a PHA does not in any way, shape or form equal malware. It does not equal trojan. There’s all kinds of things that can get on a device. As my colleagues mentioned, screen overlays, which you can now control with modern management capabilities, are just one way. That’s categorized as click-fraud or screen-capturing or clickbait.
[The percentage of] real malware on Google Play is pretty small. In fact, the whole PHA category, at the end of last year, was down to 0.042 percent, which is actually pretty darn good. You can see the blue line at the top there is going down on devices that are loading applications outside of Google Play, i.e., sideloading. One of the reasons for that is just because we’ve strengthened the operating system so that exploits are much harder to actually enable.
Now some of the other pieces … and this is the big part because we’re here in an enterprise stance and an enterprise discussion. One of the biggest things we see is that many customers are still managing Android devices with legacy methods. A device administrator is just not the way to manage Android any longer. We want customers to start using modern Android under the Android Enterprise components.
When you’re using legacy management, you can see here on the screen there’s a lot of problems that come out as far as being able to manage that device. With the new modern management, you have tons of knobs and levers that can actually help you mitigate that.
What at Google do we think the best practices are to help you safeguard Android devices? No. 1 thing is awareness. You’ve heard it from my colleagues and my friends here on the call. You’ve got to educate your users because no matter how good you think you are, they, “they” being the bad actors, will always find a way to try and trick people. Social engineering and phishing is the No. 1 way, so you need to educate your users.
The other way is to start adopting modern Android management. Now one of the ways to do that, obviously from a Google perspective, is to use devices and services that are on the Android Enterprise-recommended sites. Patrick mentioned that earlier. That’s a good way to understand and know that you’re getting devices that have a long runway, so you can select with confidence that these devices will give you consistent deployment and they will get regular updates, and that is under contract by these devices. Then your EMM partners and your managed solutions providers also recommend it.
When you combine all that together and then you look at our partners in the ecosystem like Lookout and some of the other security vendors out there, when you couple all that together and use those protections and use those tools, Android can be managed in a very, very secure method.
One of the other things that I mentioned earlier was using modern Android management, and that comes with the guise of Android Enterprise. Patrick mentioned it earlier, it’s going away from containers to potentially start to look at what we call profiles, that are based on Linux profiles on these devices. Using these modern management tools, you can actually mitigate a lot of the attack vectors that are posed by these type of attacks just because you have the tools to actually control the ways that they get on a device.
One of the best ways is to use a strong Play store strategy. I think my colleagues will agree that installing your apps through managed Google Play and not sideloading and not using third-party app stores is the actual best way to do it. When you used managed Google Play, you get all kinds of benefits. You can’t have apps that get on that device outside of management. There’s no option for a user to sideload an app in any way, shape or form.
By controlling that and then the layering on of some threat detection, you actually can control what gets on the device and what goes off the device as far as data. You can do that with third-party components. But the idea here is use modern management and move away from Device Administrator, because that’s too open.
That’s this statement that I want to make here, is Device Admin has been deprecated or I should say has started being deprecated way back in Nougat, two years back, around December of 2017. All Device Administrator APIs have been marked as deprecated in Pie. Now that does close up a lot of attack vectors based on APIs and things of that nature.
Basically, by the time Q rolls out, whichever dessert name that’s going to be, device administrator APIs will be no more. It behooves you to start migrating your apps over and managing them with Android Enterprise components of modern Android.
Then, finally, I think one of the greatest things about Android is that we have what we call an ecosystem of just really phenomenal security defenders. My colleagues here on the phone, Patrick for education and David for the products that they build, combine that with all the entities that you see here.
Many people say that Android is open, that’s bad. We don’t see it that way. Because it’s open, you have choice. It’s not fragmented anymore. Because we have all these different entities that are banging away to make Android secure, I’d argue it’s one of the securest.
Of course, with that said, I think it’s good to note that we have a good system, we have a good ecosystem and many partners that actually make the system that much better.
With that, I’ll go ahead and pass the ball back over to Tara to close up. Maybe we’ll do some Q&A.
Q&A
Tara Seals: Great. Thank you so much, Mike. Yeah, I know we got started a little bit on the later side, but I think we do have time for a few questions. Let’s kick it off. I think you guys all gave us a lot to think about. Let’s look towards the future a little bit with an eye towards the past.
If we look at the most significant ways that enterprise mobile security has changed in the past five years, I’m curious as to what you guys say that those would be. Then also, do you feel as though there have been any surprising developments within that time frame and what does that hold for the future? Patrick, maybe if you want to start us off with your thoughts on that?
Patrick Hevesi: Yeah, I mean definitely, as I was saying earlier, the mobile device is your primary device. We really need to start looking at it as a full-fledged endpoint. That’s where some of the endpoint-protection platforms have been integrating with mobile threat defense vendors and giving you a holistic look across all devices, be it a laptop, a Chromebook, an iPad, a Surface, an iOS device, an Android device, and start thinking about if something is compromised, if your phone gets compromised, what’s next? What is the hacker going to then possibly do, thinking about what cloud applications you might be accessing as well?
I think that’s probably the biggest thing we’re seeing, and IT organizations are starting to staff that up as well, bringing that mobile security discipline integrated with their traditional endpoint-protection capabilities.
Tara Seals: Great. Thanks. David or Mike, would either one of you like to weigh in on that?
Mike Burr: Sure. I’ll add a little bit there. I think one of the surprising things that I’ve seen is just what’s forcing adoption of enterprise mobile security. One of the main things that we see is that it’s actually geared around a project around enabling mobility usually. For example, an organization is rolling out, say, G Suite or Office 365 to all of their devices, and they’re realizing that in that process, they’re opening up their mobile devices to access more data than they did before. It’s interesting to see how actually enabling mobility is one of the significant drivers for when organizations decide we need to have a more comprehensive mobile security strategy as a result.
Tara Seals: Got it. Okay, great. David, we actually have another question for you from the audience. Allison would like to know if you could expand a little bit on the concept of secure SMS and how it works or would work.
David Richardson: Secure SMS. Obviously, the current ways that SMS are delivered are they weren’t built with security in mind. It was a way to broadcast messages out quite broadly and without necessarily encryption or some of those other things together. Obviously, there’s a bunch of user experience issues with SMS as well, like character limits and read receipts and those types of things that many different players have been trying to expand upon that.
David Richardson: I think SMS as a whole in its current form will shrink in terms of usage. Obviously, it’s already being replaced by whether it’s WhatsApp or Google Hangouts or iMessage or other methods like that. As far as the idea of secure SMS, I think that there’s obviously a lot of trends. I’m assuming secure SMS would be encrypted SMS messages, end-to-end encrypted SMS messages. Obviously, there’s a lot of debate about this at the moment in terms of what should and shouldn’t be done from an encryption perspective.
I obviously don’t want to talk too much about that, but it is interesting how there’s been a whole bunch of tools that have sprung up lately that are enabling end users to form their own fully end-to-end encrypted conversations, which has obviously lots of applications for political purposes as well as insider trading and other things like that. I think that’s going to be a really difficult topic that we’re going to have to wrestle through in the next couple of years here.
Tara Seals: Absolutely. Okay. We have another question from the audience that’s about basically denial of service. They’re asking, for very critical applications, should enterprises be concerned about deliberate jamming, and not just spoofing and sniffing?
David Richardson: Yeah. I think yes. Obviously, as you enable users to do more from mobility, it may become a critical part of your workflow, as critical as cloud services being operational, that your mobile applications are operational and that people are able to get work done as a result of that.
Tara Seals: Okay. Then we have a question for Mike. If someone is using Android Enterprise and they are using it in device-owner mode and everything’s been restricted to Google Play, they’re wondering if there is a need or a benefit to layering on third-party security solutions in that scenario?
Mike Burr: Again, that always comes down to the risk posture and what’s your risk appetite and your mean time for failure is. I think that’s an individual decision. We at Google will never say not to use it. There’s obviously lots of things in the platform that protect the device, but that’s what it does: It protects the device. While things can still get on to devices, depending on your use case and depending on what the device is being used for, how many applications are on it, is it special purpose, is it shared, you have to take into consideration this full picture.
One would argue if it’s fully managed and it’s in kiosk mode and there’s no way to get apps on there, do you need some sort of external or some other service? Maybe, maybe not, because you might want to protect the data that’s going to it. I think at Google, we look at it from a perspective of trying to keep exploits in any way, shape or form off a device, but we’re not protecting the networks per se other than guaranteeing that we’re using the proper certificates and modern TLS or more advanced TLS connections. Again, it boils down to the use case and what your risk posture is.
Tara Seals: Okay, great. Patrick, another question that we had is, if you’re an end user, an employee, what part does end-user awareness play on this? For instance, is using my phone as a second factor of authentication a safe practice? What about using VPN while I’m on public WiFi? Does that protect me from some of those threats? What are your thoughts on that?
Patrick Hevesi: Right. I mean definitely we’re going to see a lot of the cloud-service providers recommending multifactor authentication. The challenge with … using your device as a second factor is, are there any risky applications on there? Have I actually done that self-awareness? Am I actually policing my own device and putting only safe applications on there? MTD and standalone could help with that.
The other thing we see is for government high-risk devices, some of the threat issues we look at are, has someone cloned my phone as well? If you’re starting to look at your bill and all of a sudden you see a whole bunch of different phone calls or things like that that might be happening, that could indicate someone might have done that. But that’s a very targeted, very personal attack. It gets back to [the fact that] you have to understand the health of your device to be okay for it to be used as a second factor of authentication.
The second part of that question was about mobile VPN. Definitely, it’s going to help. If you are on a Starbucks WiFi or the airport WiFi or whatever, having that VPN will definitely secure the traffic. A lot of security-minded professionals are paying for always-on VPN. They have that additional layer of protection, so even if someone is trying to do a man-in-the-middle attack at some kind of coffee shop, that you’ll at least have that encryption.
That also gets back to the corporation. If you have highly sensitive data on that device, possibly instantiating that VPN on that managed device is definitely a good best practice for protecting the network stack.
Tara Seals: Got it.
David Richardson: I want to add one thing at the end there. I agree with what Patrick is saying, but one thing that I want to caution is be careful about what VPN you’re using. There are a lot of free VPNs out there. If it’s a free VPN, [you must realize that] it is impossible for someone to pay for the cost to run a free VPN without somehow monetizing your data. We’re seeing VPNs get built into applications such as the Dolphin browser.
These types of things create risks associated with the device as well. They’re also an avenue for man-in-the-middle attacks. We’ve actually seen VPNs that are better than free, where they pay users. There was a high-profile example recently of Facebook offering to pay I think it was teenagers $20 a month if they would turn on an always-on VPN so that Facebook could watch all their traffic. But we’ve seen that as a trend for a long time, and that is actually a source of man-in-the-middle, a source of enterprise data accidentally flowing through a third-party advertiser in a way that it really should not.
Mike Burr: Yeah, Tara, real quick. I’d like to add one more thing to this. We at Google actually take another approach that seems to work extremely well. It’s not only about authenticating who you are and protecting that authentication with two-factor, but it’s also about trust level.
There are all kinds of signals that come from your device, so when you make a connection to a resource, there are services … not necessarily network access control, but trust models. At Google, we call it BeyondCorp. Looking at signals about the device, where you are, the type of certifications. Do you have a machine cert or do you have a user cert? All these different various signals from a device will give you a trust level. Then that will only allow access to certain resources in your network.
David Richardson: Yeah, absolutely agree there.
Patrick Hevesi: Yeah, agreed.
Tara Seals: Great. Okay, guys. Well, I want to wrap it up. We did have one more question from the audience though that I think is probably worth asking. This person would like to know, in terms of advanced persistent threat activity, nation-state activity, corporate espionage, that type of thing, how common is that? How much should enterprises have to worry about that type of activity?
Mike Burr: Tara, I can speak from the Android perspective. I don’t have specific data. I’ll say it happens. I would say that, again going back to my part of the presentation, what we’ve done in the ecosystem is actually made it much more difficult even for OEMs and carriers to inject malware or bad pieces of data into the system partition. Some of the things that we look at when we certify a device are things like that. Then putting things into the platform itself actually will mitigate that attack.
Then with remote out-of-station services, things like verified boot, we can very strongly attest that the system partition will be intact. When the device is under a management, there’s all kinds of signals that we can look at that are based on hashing and remote out-of-station that can strongly, strongly attest that a system partition truly has not been compromised. I won’t say it hasn’t been tried, I’m sure it has, but from my perspective I don’t see it, but that’s not to say that it doesn’t happen.
Tara Seals: David, did you have any further thoughts on that?
David Richardson: Yeah. Just a couple of thoughts on that. One, I’ll agree with what Mike’s saying about … especially what he was saying earlier about how the vulnerability is not an exploit. These nation-state attacks, the ones that we have seen, they are rare and they’re newsworthy when they happen. They involve chaining multiple exploits together.
I’ll use the Pegasus example that Patrick mentioned earlier. This involves a Safari WebKit exploit on a webpage and then chaining two different kernel exploits in order for you to essentially jailbreak this device and install hooks on it in order to get persistent access to this device.
[But] there are a lot of strong controls, isolation and sandboxing on both iOS and Android to ensure that just because you’ve exploited one vulnerability doesn’t mean you’re going to be able to get full access to the device. You need to chain a number of very expensive vulnerabilities together in order to pull that off.
This does happen. We see it actually. We see it in our user base occasionally. It is not something that happens to every enterprise. It’s definitely on the rare side. What we see more often is more like the broad-based attacks … like the proxy malware I was talking about, where someone will try to target as many users as possible to get them to do something that they should know better not to do, like install an app from a third-party source or install a configuration profile or something like that. Then try to figure out, okay, what information can I glean from these users? What corporate data can I exfiltrate, et cetera? We see more of those types of attacks happening.
Tara Seals: Really interesting stuff. Thank you, David Richardson. Thank you, Mike Burr. Thank you, Patrick Hevesi. We are going to have to leave it there since we’ve got a little bit of a late start. Thank you so much for participating.
Patrick Hevesi: Happy to. Thank you.
David Richardson: Thanks for the opportunity.
Mike Burr: Thank you. Absolutely. Thanks again.
