It’s a common — and seemingly benign — business situation today:
CFO: “Hey, boss. The latest draft of the financial report for this quarter is ready for you to review.”
CEO: “Great, send it over. I’m on my way to the airport, but I’ll look it over on my phone.”
This innocent, everyday exchange could have serious ramifications for an organization. And most of us are blissfully unaware of the risk.
BlackBerry VP of Global Sales Engineering, Alex Willis, says this is because we don’t see a lot of big data breach headlines related to mobile devices. But that doesn’t mean they aren’t happening all around us, every day. “If credentials are stolen off a phone and then used elsewhere, the report gets tagged to the ‘elsewhere,’ not the phone.”
This failure to recognize or record the source of an attack leads organizations to believe that damaging cyberattacks and breaches do not occur on or through mobile devices, Willis says. “The reality is, that's not true.” But the perception that our phones are secure creates gaps in many organizations’ cybersecurity defenses, and exposes their valuable data, according to Willis.
In Part 3 of my BlackBerry LIVE interview, I’m speaking with both Willis and Senior Director of Solutions Marketing Baldeep Dogra. Together, we explore the technological aspects of mobile security, including VPN, 2FA, zero trust, and how organizations use BlackBerry® Unified Endpoint Management (UEM) to complement Microsoft® Intune® to fill in security gaps. To learn more, watch the podcast, or read the excerpt below.
UEM really started as a Gartner term. This is their Magic Quadrant, when they expanded the requirements for the MDM, or the mobility Magic Quadrant to include other devices. So Unified Endpoint Manager (UEM) could include mobile phones, laptops, smart glasses — it can be any of these devices. We support all of those.
So that gets us into the UEM category, but when we think about endpoints, we've expanded our scope of what an endpoint is. An endpoint is no longer just a piece of hardware that you must protect. It's protection against data leakage; it's analyzing user behavior; it's the network connectivity. All of these are endpoints that need to be protected; and if it's done well, the users don't even see that it's happening. That gets us into the zero trust discussion, where every action is an authentication, where the friction for users of having to go through some process to access something just goes away.
A good example of it is VPN with two-factor authentication (2FA). That's a painful experience for users if you use it a lot, and when you use it when you're a mobile worker; I've always been a home office worker, my closest office is the airport. I'm in planes all the time, but whenever I would have to VPN, I’d have to start the VPN client, put in my password, get prompted for 2FA, pick up my phone, approve it, and then I'm connected.
Well, if I'm at an airport and I'm doing that while I grab lunch and then I put my machine to sleep. When I'm done eating and I go to another area and resume, then I have to go through that whole process again; it has only been 10 minutes. It's an even worse experience when you're doing it at your home office. Every time I connect, I have to go through this process. Why should I have to do that? My home office is, or should be, a trusted location where I don't have to go through that stuff. I want it to be the same experience that I get at the office. That gets us into UEM. BlackBerry moved squarely into the UEM category when we expanded our support beyond BlackBerry® hardware, to support iOS® and Android™ phones, and laptops including Windows® and Mac®.
Out in the field, people who are maybe using something that's more of a traditional MDM or MAM, let's say Microsoft Intune; they think they're addressing many of these issues already and they don't know what they don't know. Bal, is this something that we see organizationally and something that we're trying to educate people about in the marketplace?
So you know MDM has evolved, you think about the use cases, but what are the customers' needs right now? It's not just devices, there's applications, there's content, MAM, MCM, and UEM as well. UEM is ultimately the evolution of MDM, MAM and MCM. Still, it comes down to the use cases, how they kind of evolve, how the customer needs change. It kind of runs in parallel with how we moved, and how we pivoted from being that device-centric company to a software-centric company.
Interesting. Alex, anything to add to that?
I think it gets back to the “checkbox” issue. You know, those tend to be financial decisions. As you know, almost every organization has a companywide agreement with Microsoft. You need it for Windows, you need it for Office, all these things. So, when something like Intune is included into a bundle, it's difficult as a financial manager to look at a line item and say, “Well, it looks like I have two-line items for UEM.” Then it’s a question of, “Can this Intune thing that we're already paying for meet the requirements?” And if you're looking at the situation with a list of a bunch of checkboxes, you could argue that it could.
We ran into Intune everywhere because every customer has to use Intune at least for part of their strategy. That’s because if you're going to use Office applications and you want the mobile versions of those applications on your phone or tablet, the only way to put restrictions on them is with Intune.
So, we expect customers to have Intune and use it. In almost every conversation I have with companies, it usually comes down to a financial decision. The company says, “Hey, let's consolidate. Why don’t we just use Intune? We're already using it for X, and it's already included in the Microsoft bundle.” The common problem I’ve seen is that when the security team gets that directive, they immediately run into some gaps. This isn't to attack Intune. There’s no silver bullet product, it's just there are clearly gaps.
So, in discussions with customers we never look to displace Intune. What we do though is help them identify the gaps, and then position our products and services to fill those gaps, so they will keep the level of security that they're expecting and also keep the friction for users low. So, everybody's happy.
Then there's the connectivity issue. BlackBerry has a few different connectivity models that provide easy connectivity for users and a high level of security for the organizations. Bal mentioned firewall ports, right? We don't require any inbound ports to facilitate “behind-the-firewall connectivity.” So, how do you give people access to behind-the-firewall resources, like an intranet or database, without having to go through that whole painful VPN process with 2FA? Well, we figured that out 20 years ago. We did it because of the security posture that it allows us to have, and we can help organizations to reduce the attack vector at their firewall.
So, we don't require any inbound ports. We facilitate connectivity through an existing bidirectional outbound-initiated port from the server. So, the service starts up, connects to the BlackBerry infrastructure, and then all the connections come back through the BlackBerry infrastructure, which does a couple of things: One, we then become the first line of defense for our customers. We validate, we authenticate. Any attacks are going to be (handled by) us, and only what should get through will be allowed through. This all happens in a split second, so for the user, it's just seamless connectivity.
There's no need to initiate that connection from the user side with 2FA, because we're already doing certificate-based authentication and validation of the protocols being used to connect. So, from the firewall, it greatly reduces the attack vector, and mitigates the susceptibility to denial-of-service (DoS) attacks, because they don't even have to answer the port call to then be able to fail an authentication. So, it helps on both sides: good user experience, and super-solid secure connection.
That's the connectivity gap that you get with Intune that BlackBerry fills. With Intune alone, there just isn't an easy way to provide that connectivity. The best that you could do is use reverse proxies, which is one way, but it’s complicated and increases the security risk at the firewall.
Alternatively, you're using VPN. And when you think about VPN, the real challenge on a mobile phone is “bring your own device” (BYOD). You don't want to allow a full device VPN connectivity on a personal phone, because who knows what else that they have on that phone? Once VPN is connected, then almost everything's going to go through that connection. You don't want Facebook traffic and other traffic going through your corporate infrastructure, and have to scale and secure all that data.
What you would want to do is have a “pre-app” VPN, so that only work applications are using that VPN connection, and you can tie the VPN client to the application. This way, if there isn't a current connection established with the VPN when the user starts that work application, it will then initiate that VPN connection and use it. You can do that.
The problem is that in order to do pre-app VPN, you have to have MDM on the device, so that's a challenge in BYOD settings. Now, there are ways to have limited MDM, but that goes back to the trust issue, and that users don't want anything that even looks like an MDM on their device.
The other issue I hear from customers a lot is that in practice, VPN breaks down, because a lot of these mobile applications aren't VPN-aware. When you go to start that first app, if the VPN isn't connected, the VPN has to establish the connection, which takes time. Even without having to go through 2FA, sometimes it can take longer for the VPN to establish than the application is willing to wait. And so, it times out and you'll get an error message. It's because the app didn't know that the VPN just needed a few more seconds to establish the connection, and then the app can try again.
So, in essence, to fix the connectivity gap left by Intune with VPN, all you have to do is start the app, get the error, try it again, and it would be fine. But it generates a lot of user unhappiness, phone calls to support, and less user adoption because they don't understand what's going on and just think that the technology doesn't work very well. So, there are a lot of challenges in that type of deployment, that we solve easily.
Another challenge from a security aspect is encrypting data at rest, and storing data separately from what's happening on the personal side of the device. That becomes problematic for companies that are really worried about security and not just “checking a box.” For instance, there's a policy in Intune that you can say, “I want my data encrypted at rest,” and check the box. You think, “Alright, I checked the box for my security team. I'm good.” The reality, though, is that's not what happens. What that does is it forces the device to have a password, because on mobile devices, the operating systems will encrypt data when the device is in a locked state, so you can only get a device into a locked state if you have a passcode.
All that Intune policy is doing is just making sure that the device has a password on it. What it doesn't do is allow you to have complete control over the password policy. You can have some minimum requirements, but you can't match what an MDM can do. So that's a big dependency gap, that when the device is in an unlocked state, that data is not encrypted.
If there are vulnerabilities on that device, and we know there are a lot of CVEs that get published almost daily, if you look at cvedetails.com, you can see iOS has about one CVE a day over the course of a year. Android has maybe twice that. So, you have these potential vulnerabilities there that once the operating system is exposed, then so is all your corporate data. Organizations really need to use applications that have their own encryption built in, or be part of a platform that handles it for you.
That's where BlackBerry UEM comes in. We're proud of the level of security that we go to. So, any application that we support in our marketplace on our BlackBerry Dynamics™ platform follows our strict guidelines on security processes. We handle the task of encrypting your data at rest. It's part of our software development kit (SDK), so you get our secure save and encryption APIs available, secure copy and paste, and how data is shared between work applications. We never unencrypt data when it's being used on the device, whether it's at rest, the device is locked, it's in transit — nothing. And these are validated cryptography methods, and applications of that cryptography. We've got FIPS 140-2. We've gotten about 81 certifications around the world. These aren't just aspirations. I see a lot of platforms that say they comply with FIPS 140-2, or this certification, or that. We don't just say we comply with it; we're certified against it. Those are long, complicated, and expensive processes to go through those certifications, and we have them because security is important to us.
We're not seeing a lot of big headlines of breaches on mobile. People think that's not where mobile breaches happen. But the reality is, that's not true. Breaches are starting on mobile, and I think it's probably underreported, so the vulnerabilities are being exploited. In fact, you can just do a quick Google search and you'll have even recent ones where major CVEs were not only reported, but they were actually being used to steal data. So, threat actors might be stealing data and credentials from your phone. If credentials are stolen off a phone and then used elsewhere, the report gets tagged to the “elsewhere,” not the phone, right? So that's why I think it's a little bit under-reported.
There are a lot of vulnerabilities on phones, not just the encryption of data at rest. It's handling of encryption keys if you're using S/MIME for example, or certificate-based authentication to back-end systems or cloud systems, where are those certificates stored? Where are the keys stored? Are they in (iOS) Keychain storage? Are they on the device? How well are they encrypted? Are they also encrypted at rest? All those things come into play.
It's almost like 10 or so years ago when people would buy a MacBook and they’d say, “Well, I'm buying a Mac because there's no viruses on Mac OS.” That changed really quickly. I think the same thing is happening on phones, where people see the news reports that thousands of applications have been removed from the app store because they were found to be malicious. They might be stealing data, they might be just spreading themselves around, but there are also key loggers, screen scrapers, people listening to the microphones, there are all these dangerous malwares.
The dangers are real, and I think the number of those headlines are going to increase. If you align the landscape with what people are using their phones for these days, I think it's a recipe for big problems unless it's taken seriously.
You know, there’s reputational risk; it’s not just stealing your corporate data, it's also in some cases your client's data.
We hear about the supply chain issues. “Well, it wasn't our problem, it was a partner,” or something like that. The same thing is true for managing client data. You've got some legal exposure in some countries, but reputational damage could mean you could lose clients. I think organizations are now starting to give higher priority to mobile security, as they are starting to realize that the risk is changing rapidly.