Dont Let Your Data Get Away

Webinar transcript - View the full webinar


Male Moderator:  Hello, everyone. Thank you for joining us on the webinar today. We're excited to have Jake Woodhams, Senior Director of Technical Marketing here with us. As organizations migrate to Office 365, Jake will cover key steps that you must take to effectively secure Office 365 and other cloud services.

Before we get started, I have a few items I want to highlight. We will be shooting for a brief 30‑minute presentation followed by Q&A. We are recording this event, so you'll receive a recording after the presentation in a follow‑up email.

Additionally, we want this event to be as helpful and informative to you as possible, so feel free to ask questions in the Q&A window. We will address the questions as they come in and circle back at the end of the session to be sure all the questions have been answered.

With that, I'd like to welcome Jake to our session today. Jake, thanks for joining us. Let's get started.

Jake Woodhams:  We're asking this question. Do you know where your email data is? This is because email is the foundational use case when it comes to data concerns.

Any kind of protection, any kind of compliance, email, regardless of whatever new technologies are coming on board is still and has meant for quite some time the single most important form of business communications.

It is a place where all kinds of very, very important, very, very valuable intellectual property belonging to enterprises sits. Office 365 is also something that's becoming the default productivity suite with cloud‑based email replacing on‑premises exchange.

In fact, what we're finding now and MobileIron has been working in mobile space and working with Office 365 in a number of our customers for several years now is that email is still the number one priority in all of our large customers when they're moving to office 365.

Other services like SharePoint, Teams, Skype for Business, those are important too, but they're not the priority. Email is. That's why it's important for us to look at this in great detail because it's top in mind.

The other thing is that iOS 11 has recently been introduced. It's introduced something that has to do with native email on iOS devices and Office 365 that's both very exciting, a big leap forward, and yet it creates some challenges when it comes to securing email. That's what we're going to talk about, especially how MobileIron can bring all of this together.

Now, with that said, let's take a brief look at history and talk about securing email on iOS devices. Let's go all the way back to 2007. It isn't that long ago really, but it feels like it.

In 2007, the devices that you're seeing on the screen were the state of the art for business mobility. BlackBerries, Nokia e61s, Palm Treos. People loved these devices. Remember, that's when this term CrackBerry was being thrown about. People love their devices, or so they thought.

Then, Apple introduced the iPhone and changed the industry. What people discovered was they didn't really love their BlackBerries or Nokias or Treos all that much. They really loved the iPhones. What they loved about those other devices is that they got business services and especially email on them.

As a result, enterprise users started to demand and getting louder and louder to have business services on their iPhones. Soon, Apple recognized the demand and introduced support for ActiveSync‑based email accounts, particularly of course ActiveSync being a Microsoft technology for on‑premises Microsoft Exchange servers.

Exchange had really become the dominant email server platform, ActiveSync being the dominant protocol for mobile enterprise email. At this time, it's important to note that while business email could be supported on an iPhone, this was a user‑centric configuration.

In other words, users would add and configure their corporate email account services on their iPhones, but there were still issues for enterprise IT with this. What were these?

On this new class of device, I think many of you will remember if you worked in enterprise mobility back in those days, there was huge resistance in enterprise IT to bringing iPhones into corporate IT.

The prevailing argument of the day is that while people loved the iPhones, they were not secure enough for enterprise. What were the issues that enterprise IT were bringing up? The basic issues had to do with this bring your own device thing.

People wanted to bring their own iPhones, but questions had to do with what happens if a device gets lost or stolen? What happens if an employee is terminated? What if the device itself is compromised? How do I know that my email data is secured on that device from being leaked into other places, other email sources, other data stores?

How do I take email away from an employee who is terminated? If the device is lost or stolen, can I do a remote wipe to retrieve my email? Then of course, securing the data at rest and in transit were key concerns.

These were all things that were obstacles to the iPhone being an "enterprise‑ready secure mobile device." Fortunately for us, Apple addressed that. Apple introduced the mobile device management stack into the iPhone.

That gave us the concept of the managed device. A managed device is something that would have a relationship with an MDM server. As such, the managed device would have services such as WiFi, VPN, email, provisioned on that device.

There were also primitives in place such that a mobile device management server could check the device for compliance, could check that the device was in a secure state posture‑wise, and what have you.

This was a very huge development, moving forward, in making the iPhone "enterprise ready." Another concept there was the idea of the managed mail account. This is a mail account that's provisioned by corporate IT on the device and managed by corporate IT on the device.

That would require the MDM or mobile device management stack. A MDM also came with restrictions and controls, which gave IT a level of security on these devices, so that they could protect their data.

The good part about this, at least from our perspective, is once Apple introduced this, our young rising startup sound reason for being and took off. We at MobileIron were very happy about this back then.

Now let's move forward, to iOS 7. This is 2013. In iOS 7, it has introduced some additional enhancements. One of the things that they added was the concept of open‑end controls that were native in the operating system. What would open‑end controls provide?

Open‑end controls native to the operating system gave the administrators VLP controls. In other words, you could define the concept of a managed app and an unmanaged app and control whether data that was corporate data could be opened only in managed apps, or you would be able to open them in managed versus unmanaged. That was a level of control.

Another thing in iOS 7 was this concept of managed Safari domains, where you defined a domain‑based on the QDN that would trigger a per‑app VPN tunnel. This also applied to email.

Once you have these domains applied to mail accounts or managed mail accounts, then the open‑end controls would also apply to email. Why was that important?

Because it now gave you power over how email attachments, like PowerPoint files or Word documents or contracts in PDF form and what have you, what applications would be able to open and view these valuable documents from email accounts or managed email accounts.

This was actually really an important development in the evolution of iOS as an enterprise email secure platform. Then in iOS 9, Apple closed the one remaining data leakage gap by giving you, that IT administrator, the ability to define AirDrop as a managed destination.

Once AirDrop was a managed destination, not only could you apply open in‑controls to how email attachments might be opened, you also could now prevent users from airdropping those documents off of your phone onto an unsecured device.

All of this gave us a situation where we had email that was provisioned, protected on the device via MDM. Then you have MobileIron in place performing regular compliance policy checks.

Devices that might be out of compliance would be quarantined or remotely wiped, depending on the administrative policy. Lost or stolen devices, same thing could be applied there, and so on.

That still isn't the complete email security solution. Why not? Well, because users might still directly configure mail profiles on their device and have access to the ActiveSync server itself. Not to mention the fact, that ActiveSync itself as a protocol for mobile mail had its own limitations and was undesirable as a standalone mail protocol.

What do we do about that? Well, we introduced Century. MobileIron introduced the Century. For email, Century acts as an Active Sync proxy.

Unmanaged devices would be blocked from accessing the exchange server, out of policy devices, the same thing. Then email data in transit would be protected via strong security.

Now just for clarity, we will come back to some of these things in a little bit. Let's take a little bit of a deeper dive into how this actually works. In the picture here, you have on the left‑hand side, an unmanaged iPhone with a mail account.

The right‑hand side, you have MobileIron. This applies to both core and cloud for our EMM platform. Then you have the Century. What will happen is when the device enrolls with MobileIron, the mail account is provisioned on the device with what we'll call an active logon profile.

Within that active logon profile, you would have the mail server. The mail server, being defined as the publicly facing address of the Century. That could be IP or FUDN. As far as the device is concerned, as far as the mail account on the iPhone is concerned, the Century is your mail server.

There's also an active authentication profile. I will get into more details about what active authentication is in a bit because that's important for this discussion. That would be either basic auth, which is user name and password, something called [inaudible 13:15] or potentially [inaudible 13:18] off.

Once that's the case then, the mail account, in attempting to access mail, would go through the Century. The Century could check the device's posture on the core and cloud. If it checks out, then mail's closed.

What this did is it introduced a level of security into which devices, so that you could control access from managed versus unmanaged devices. Even in the case of managed devices, you would have the ability to dynamically check the device's compliance in process there and protect your email that way.

Now, let's take a look at the counter example of what happens just to clarify this point. If the user were to go and configure their mail account on an unmanaged device, which is an unmanaged mail account, they could enter the mail server with the Century address if they knew what it was as well as their active authentication credentials.

What would happen here is that the Century is going to check the posture of that and deny it because that's an unmanaged device. Now, there's one further thing that's worth discussing when it comes to that. That's the ability to support Kerberos constrained delegation.

In the case of Kerberos constrained delegation, what will happen is that, essentially, you can use this Kerberos service on the back‑end. The Century acts as a delegate, a Kerberos delegate. In the process of doing that provides a seamless sign on experience for the end user.

It's a better approach there, and it's a better user experience than the user having to enter in user credentials and whatnot. That's Kerberos constrained delegation.

Now we've just taken this walk through all of this because we want to establish some basics around what we've learned over the years. Goes into holistic email security for mobile, or specifically on iOS devices.

It starts with this concept of the managed device. That's a device that's been properly secured. It's compliant with security policies. The data's protected against compromise, and so on. You have the concept of managed mail accounts that are properly provisioned and subject to open in‑controls for Data Loss Protection, DLP.

You have the access control provided by the Century which protects the mail server from being accessed by unmanaged, or unauthorized, or out of compliant devices themselves. Mail is restricted to only managed devices. Then you're also able to address some of the ActiveSync limitations.

There's also secure authentication. Up until this point, we talked about secure authentication in the context of active authentication. We're going to get into that in more detail.

We went through all of this to provide a baseline, a framework for the most basic of data protection use cases. That is email. Of course, we talked about how MobileIron addresses that.

Back to the topic at hand. What does all of this have to do with Office 365 and iOS 11? Office 365 complicates things by moving the mail to the cloud from on‑premises. The mail server goes from something, the data center that's controlled and protected to something that's public and shared infrastructure.

There's some new architectural challenges presented, and we have to do a little bit of rethinking. That doesn't mean that the foundational security pillars change when it comes to email use cases. We're going to start by taking a look at access control and authentication for Office 365 in the next few minutes.

Let's look at access control for Office 365. We've been working for some time now with Office 365 and iOS and what many of the early adopters of Office 365 have simply done is they have kept the Sentry in place.

Sometimes they've kept it on premises. We also support Sentry in the cloud and Amazon Web Services or in Azure. What they do is they keep the Sentry in the flow path and use IP‑based claims rules for Office 365 to restrict email access exclusively to the Sentry.

What that does is, this still gives you the protection against unmanaged or out‑of‑compliant devices attaching themselves to the Office 365. This works reasonably well but it does have some limitations and as you'll see, it's not exactly a long‑term solution.

Let's look at how this works and what will be apparent is that we have to take a different approach. In this particular case, we have the same situation where the active log‑on profile is provisioned onto a managed mail account.

The mail server is configured out of the Sentry and then there's an active authentication mechanism that goes in place here. What will happen then is exactly the same flow. As long as the device checks out, the Sentry will allow this to go back through to Office 365 and service will be allowed based on IP claims rules and Azure active directory.

That's how this flow works. The IP claims rules are configured such that will only allow mail traffic to come from the Sentry itself, not from any old email out there. As you know, cloud services, people can go directly to the cloud service and so this is a way of creating control.

Now, the one thing that we need to point out here. This only works with active authentication. We'll see why in just a minute. By active authentication, this is username and password, basically. Cert‑based off can be supported here but you're going to go directly to Office 365 there.

Here's the thing about that. Active authentication is going to require the credentials be presented to a public cloud service and as we will see, for many customers, identity in a public, shared cloud service is just a bridge too far.

It's also not a scalable solution, because there are other cloud services that need to be supported and it also has limitations when it comes to supporting advanced features that people really need, like Seamless Sign‑On, Single Sign‑On, Multi‑Factor Authens, and things like that.

Just for a point of clarity here, with Office 365, when you're using IP‑based claims rules, because I want to make sure this is understood, since it's in the cloud there's no way of restricting unmanaged devices from trying to access this.

With these IP‑based claims rules, what this represents here is that if you haven't gone through the Sentry, it can be blocked with IP‑based claims rules that are in Azure.

This has been the traditional approach. There's a reason this isn't a long‑term approach, though, and we need to rethink this. This has to do with active versus passive authentication. We've already talked about active authentication quite a bit, so let's talk a little bit about passive authentication.

The notion of passive authentication is this, and this is the overall industry direction for cloud services. In the passive authentication flow, when users go to authenticate to a cloud service they're going to use some kind of a browser or web‑based client.

Instead of presenting credentials directly to the service and having the service do an active authentication against an identity provider, instead the users will get some kind of a redirect, typically to some kind of a portal through which they will authenticate to a standards‑based IdP.

A standards‑based IdP providers will support modern authentication open standards like Secure Assertion Markup Language or SAML. OpenID Connect is something you'll hear about, or WS‑Federation. There's also OAuth.

By doing it this way, with passive authentication, users get authenticated by the identity provider correctly. That identity provider could be an Identity‑as‑a‑Service, which you might find from companies like Ping Identity or Okta, or it could be something that is on‑premise like Active Directory Federated Services. It just depends on what the deployment is there.

It unifies identity across Office 365 and other cloud services and you can also support advanced features like Single Sign‑On or Multi‑Factor Auth and things like that.

Let's look at this in the case of passive authentication with Office 365. When the application on the device attempts to authenticate to Office 365, it's given a redirect to the identity provider and presented with some kind of a log‑on form.

There are other ways of doing this, but this is the typical way of doing this. Once the client is authenticated, the IdP passes a token back to the application. The application uses this token to authenticate itself to the service, and then data can flow. In this case, we're interested in email.

This is a various high‑level. Of course, the devil's in the details. Not everything works exactly this way, but this is a conceptual view of how this works with passive authentication or specifically, what you're probably going to be working with would SAML, WS Federation, or potentially OAuth.

Now that we've established all of that. It's finally time for us to circle back and talk about iOS 11. iOS 11 and modern authentication. One of the things is that prior to iOS 11, iOS email did not support modern authentication. However, starting in iOS 11, Apple's introduced OAuth 2 support for Office 365 email in the native email client.

Prior to this, if you wanted to use modern auth with Office 365, you would have had to go with not the native mail client. You would have to go with Outlook or Email Plus from us or something like that to support email.

We're talking about native mail. Of course, if you're familiar with MobileIron, since the beginning, we've always been about the native experience on iOS, because we think that's going to be superior unless there's a reason to go with something non‑native for super‑high security or what have you.

This is a good thing. Having support for modern authentication to Office 365 in the native email client on Apple or on Apple devices, excellent. Except for one thing. That is, this is a user‑configurable feature only right now. I'll let that sink in for a minute. It is a user‑configurable feature only right now.

This means that the only way to leverage modern auth with iOS 11 is for users to configure the accounts themselves. There's no MDM control built into provisioness on the device itself. Hopefully, Apple will build these in in the future, but for now, this is what we've got to deal with.

Getting back to our holistic email security requirements discussion here. We've got our four pillars. We think about that with this approach, sure, we got secure authentication, we've got modern auth. Fantastic.

However, managed devices? Nope. Managed mail accounts? Fortunately, not. Access control? Here's the thing ‑‑ user configurable accounts with modern authentication lets you go around the Sentry, so our IP‑ based claims rules won't work. They're [inaudible 27:46] .

This presents us with a challenge. Hopefully, Apple will add the instrumentation. That would address the managed devices and managed mail accounts situation here. However, we still got to deal with the challenge of access control.

From that, fortunately, we do have a solution. That solution is MobileIron Access. Now, if you're familiar with all of what we've been talking about lately, we've been talking a lot about MobileIron Access.

We're excited about this. It's a great solution as cloud services proliferate. Security in these cloud services is important. Access is a great thing that we have. Let's take look at this in greater detail.

Let's go back to our model that we had. Now, in the case of Office 365 with MobileIron Access, we've introduced our core cloud icons here. We still have Office 365 on the right‑hand side and we have the identity provider in place.

You'll notice that Access is now sitting in front of the identity provider. That's because what happens here is when this flow for modern auth happens, what happens is on this redirect, when the application goes to authenticate with the identity provider, MobileIron Access sits in that path. Think of it as an IdP proxy as opposed to an ActiveSync proxy.

What we can do is we can check that device posture against what we know in the EMM, make various assessments on that device and decide, "Do we allow this application on this device to authenticate or not?"

If it checks out, pass through to the IdP and the normal flow happens. The token comes back to the device and data will flow.

Now, on the other hand, let's look at what happens here in the case of an unmanaged device and an unmanaged mail account. In this case, think that this is iOS 11. A user has configured this new OAuth to support their mail account. What's going to happen here?

First of all, we see the path here. What happens is when Access checks on the posture of that device, it's going to see that it's an unmanaged device. Potentially, with unmanaged applications, those are not allowed. Instead of allowing this thing to authenticate with the IdP, it blocks this authentication transaction.

Instead, you would present the user with a notification that you're out of policy and you're not allowed to access this server. There's a remediation page. As part of the remediation flow, what you can configure is that enrollment workflow so that the user has the option then of enrolling that device in MobileIron and then having their mail account secured and thus getting access to their service.

Let's get back to what we were showing there with our holistic email security requirements. We noted that when we had iOS 11 on and these mail accounts configured without a managed mail account potentially on an unmanaged device, we had some issues. Introducing Access, then, lets us address all of these issues and of course, still maintains the secure authentication flow.

With Access, then, we're back to where we have a holistic email security solution in place through Office 365 with modern authentication. That's with MobileIron Access. A few more details on MobileIron Access that are in place. Access is supported with both MobileIron Core and Cloud.

It's supported across all of our platforms, Android, Android Enterprise, Windows 10, iOS. You might add recently, Mac OS is also supported but not shown on this slide. One of the nice things about this, of course, we've focused in in the presentation on Office 365 and specifically Office 365 email.

Right now, that is the biggest concern in terms of data, protecting enterprise data that we're seeing in our customer base. MobileIron Access works with any cloud service that uses standards‑based, modern authentication with an IdP.

You see a few listed here, Salesforce, Google Drive, Dropbox, Concur, Workplace, by Facebook, Workday, business intelligence tools like Tableau, any variety of cloud‑based services that you have in place, you can protect your data with those cloud‑based services and MobileIron Access.

We support all of your big identity providers, particularly probably the most common would be Active Directory Federated Services, but [inaudible 33:33] Identity, one log‑in, and so on, and we validate, and this list grows.

Finally, it isn't just a matter of being an IdP proxy for email. Conditional access policies can be applied to all of these different cloud services. It's checked the device posture. It checks the application posture as well as protect you against potentially rogue cloud services.

There are also user‑type features around native single sign‑on and seamless sign‑on that you can leverage there. Of course, since we're talking about authentication flows here, compliance reporting and visibility is very, very important and that is also something that's embedded in the overall access solution.

If you'd like to know more about MobileIron Access, please visit our Web page, our website, and you can see the link here ‑‑ MobileIron‑Access. You'll find details, whitepapers. You can sign up for a 30‑day trial. You could also contact your MobileIron partner or your MobileIron representatives and they can get you more detail about this. It's a very exciting solution.

Finally, I want to call out that more details on this particular webinar have been blogged. We've blogged about them. My colleague Rich Festante has done a tremendous amount of work proof‑of‑concepting all of these solutions in the lab and he's written a couple of blog entries there that are available on the blog right now.

One, "Practicing Safe Security with iOS 11 and Office 365" is a high‑level look at things. Then the one on the right‑hand side is a more technical look for those of you that like to dig in and look at XML and whatnot. That's all on the one on the right‑hand side, and you'll find these to be excellent resources.

With that, we've come to the end of this webinar. Thank you very much for your time. We do have a few minutes for questions. I'll turn it back to the moderator.

Female Moderator:  Thank you, Jake. Thank you, everyone, for joining us for today's presentation. We do have a number of questions so let's get started on that piece of it.

It looks like a lot of them have been answered in the Q&A panel. The first question is, "Is Access an on‑prem service, or cloud?"

Jake:  This is a great question. Is Access an on‑prem service or a cloud‑based service? There are actually two components for it. One is the administrative console, which is a cloud‑based service.

One thing I didn't quite clarify there is that Access is actually a feature that runs on the Sentry bits. You can deploy it on‑premise or you can deploy it in the cloud depending on your choices, so you have flexibility there.

Female Moderator:  Perfect. Next question is, "Since Access is in the middle supporting OAuth 2, will it support lower versions of iOS and Android with Outlook clients, and also, what pushes down the autoconfiguration, and will it work with Outlook?"

Jake:  We addressed that. It does work with Outlook. That's the first part. Let me go back. Yes, it will work with earlier versions of iOS other than iOS 11. Now, it works with modern auth. Any type of cloud‑based authentication that is modern like SAML or OAUTH‑based, it will work there. Hopefully, that helped with the question.

Female Moderator:  Perfect. When you say "Claim rules," are you referring to AD FS claim rules?

Jake:  In this particular case, they could be AD FS claims rules, depending on how you're authenticating your Office 365 email traffic. There could be Azure also.

Female Moderator:  Next question, "How do you differentiate between PC MAC and a mobile device? We would not want to proxy our PCs."

Jake:  This is a good question that comes up. That's an architectural question you want to have with your sales engineer. We do have the ability to support a pass‑through model for non‑mobile devices so that you wouldn't have them necessarily in the path there.

Female Moderator:  Next question, "Access is essentially sitting in front of the IdP and brokering access to or away from the IdP, correct?"

Jake:  That is correct.

Female Moderator:  Does MobileIron Access then need to be the front end for all Office 365 authentication, or can it be set up just for Access link?

Jake:  In general, what we've talked about here is email access, but usually, it's on or off. You may be using the same types of authentication, that's the whole idea with an IdP for different Office 365 services' SharePoint and what have you.

Female Moderator:  Perfect. What version of MobileIron do you need to have access?

Jake:  You caught me. Any current version, I believe, we began supporting that. Access is, believe it or not, is something that started out in the beginning of 2016, and it's been supported ever since then. As long as you're on a version...I'd honestly have to go and look at it on the documentation, but anything 9x or greater should be fine with Access.

Of course, if you're using Cloud you're going to be up to date anyway with the cloud and you'll be fine there.

Female Moderator:  I'll get two more questions. You mentioned that modern auth for iOS must be enabled by your user currently. Do you have any workarounds for making this more silent to the user?

Jake:  In the particular example that we had here, if the mail account is provisioned by MobileIron, which is what you want to do, the whole process is going to be transparent to the end user, and you can set it up such that when the device enrolls you provision the mail account. Then the user can just open the mail account and receive mail.

It's actually part of the whole enrollment flow that makes this very easy for the user. Details on how each of the things would work is probably out of scope for what we can explain in the time we have here. Certainly, we can do that.

Female Moderator:  The last question, and the rest we'll follow up via email. Does MobileIron provide a way to prevent attachments from a managed mail account from being saved into the new file apps in iOS 11?

Jake:  Yes. Here's where you would use native open‑end controls that are provided by Apple itself in the NDM stack. As long as it's a managed mail account and you've got that open‑end control set up such that you can only open from managed to managed, those open‑end controls will apply to the files app also.

Now, you would be able to save the attachment into the files app, but since those open end controls apply to the files app, then you would only be able to open those with other managed apps, which would, in the way things work, be the apps that you'd provisioned and secured from your MobileIron instance.

Now, there are some nuance and details to how this all works. I believe there are actually some interesting videos of this that are available on the MobileIron Community, so if you have access to the Community you can watch those and see those videos. There's some content that's been prepared there. I refer you to that.

If you're not a member of the MobileIron Community, then you can work with your partner ‑‑ the partner or reseller that you're working with ‑‑ or else your MobileIron account team to get that information and get those videos that show how all of that works.

Female Moderator:  Thank you, and thanks, Jake. Like I said, we will be sending this recording out via email after the event. I will include those links to the blog that Jake mentioned at the end of the presentation, so you'll have that.

All the other questions we'll answer via email, but thank you for joining us today and have a great rest of your day. Thanks.